Why exception from os.path.exists()?

[Steven D'Aprano]

On Thu, 07 Jun 2018 15:38:39 -0400, Dennis Lee Bieber wrote:

> On Fri, 1 Jun 2018 23:16:32 +0000 (UTC), Steven D'Aprano
> <steve+comp.lang.python at pearwood.info> declaimed the following:
> 
>>It should either return False, or raise TypeError. Of the two, since
>>3.14159 cannot represent a file on any known OS, TypeError would be more
>>appropriate.
>>
> 	I wouldn't be so sure of that...

I would.

There is no existing file system which uses floats instead of byte- or 
character-strings for file names. If you believe different, please name 
the file


> Xerox CP/V allowed for embedding
> non-printable characters into file names

Just like most modern file systems.

Even FAT-16 supports a range of non-ASCII bytes with the high-bit set 
(although not the control codes with the high-bit cleared). Unix file 
systems typically support any byte except \0 and /. Most modern file 
systems outside of Unix support any Unicode character (or almost any) 
including ASCII control characters.

https://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits



[...]
> 	With some work, one could probably generate a file name 
containing the
> bytes used for storing a floating point value.

Any collection of bytes can be interpreted as any thing we like. 
(Possibly requiring padding or splitting to fit fixed-width data 
structures.) Sounds. Bitmaps. Coordinates in three dimension space. 
Floating point numbers is no challenge. A Python float is represented by 
an eight-byte C double. Provided we agree on a convention for splitting 
byte strings into eight-byte chunks, adding padding, and agree on big- or 
little-endianness, it is trivial to convert file names to one or more 
floats:

    /etc is equivalent to 2.2617901550715974e-80

(big endian, padding added to the right)

But just because I can do that conversion, doesn't mean that the file 
system uses floats for file names.



-- 
Steven D'Aprano
"Ever since I learned about confirmation bias, I've been seeing
it everywhere." -- Jon Ronson