> On 11 Jun 2018, at 01:28, Steven D'Aprano 
> <steve+comp.lang.pyt...@pearwood.info> wrote:
> 
> On Sun, 10 Jun 2018 22:09:39 +0100, Barry Scott wrote:
> 
>> Singling out os.path.exists as a special case I do think is reasonable.
>> All functions that take paths need to have a consistent response to data
> 
> The *mere existence* of os.path.exists means that there is not a 
> consistent response to file names:
> 
>    open(foo) raises an exception if foo doesn't exist;
> 
>    os.path.exists(foo) returns False if foo doesn't exist.
> 
> There is no requirement that different functions do the same thing with 
> the same bad input. The *whole point* of o.p.exists is to return False, 
> not raise an exception.

I meant that if you cannot call the OS function then always deal with
that error the same way and python does.

How the result of the OS call is reported to the user is another matter.
returning a bool is fine for a predicate and raising an exception is fine for 
open etc.

> 
> 
>> that is impossible to pass to the OS.
> 
> Even if it were true that file names cannot contain certain characters, 
> and it is not, why is that a distinction that anyone gives a shit about?
> 
> I do not expect that there are more than a handful of use-cases for 
> distinguishing "file names which cannot be passed to the OS" versus "any 
> other illegal file name". And even that is generous.
> 
> Besides, it is certainly not true that there are no OSes that can deal 
> with NULs in file names. Classic Mac OS can, as filenames there are 
> represented as Pascal strings (a length byte followed by an array of 
> arbitrary bytes), not NUL-terminated C strings.

Any OS that can take NUL would have the string passed with the NUL by python
and it would then leave it up to the OS figure out if the NUL is valid.

I think the rule is, if python can pass the string faithfully to the OS, then 
do so,
otherwise raise an exception that tells the programmer that they are doing
something that the OS does not allow for.

Barry

-- 
https://mail.python.org/mailman/listinfo/python-list

Reply via email to