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.pyt...@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 -- https://mail.python.org/mailman/listinfo/python-list