On 03/19/2016 02:38 AM, Steven D'Aprano wrote: > On Sat, 19 Mar 2016 01:30 pm, Random832 wrote: > >> On Fri, Mar 18, 2016, at 20:55, Chris Angelico wrote: >>> On Sat, Mar 19, 2016 at 9:03 AM, Marko Rauhamaa <ma...@pacujo.net> wrote: >>>> Also, special-casing '\0' and '/' is >>>> lame. Why can't I have "Results 1/2016" as a filename? >>> >>> Would you be allowed to have a directory named "Results 1" as well? >> >> If I were designing a new operating from scratch and didn't have to be >> compatible with anything, I would probably have pathnames be tuples of >> strings (maybe represented at the low level with percent-escaping), >> rather than having a directory separator. > > > ls -l /home/user/documents/stuff/foo > > > ls -l "home","user","documents","stuff","foo" > > > I think users of command line tools and shells will hate you.
Of course not. Shells already associate specific meaning with certain characters that can be used in file names. For example the various quoting characters, such as ' or ". These can be used in file names but when referred to in the shell are escaped. So it could be with path separators. The file system itself could have no separators at all and the shell could still use "/" to delineate the parts of the path on the command line. so ls -l /home/user/documents/stuff/foo would still work as would: ls -l /home/user/documents/music\/fun/foo. Even better directory delimiters could be set by an environment variable (kind of like how sed lets you select a delimiter). DIRSEP=| ls -l "|home|user|documents|music/fun|foo" This whole scheme breaks down when it comes to actually writing programs, though. Either you force all the libc apis to use lists of strings for referring to paths (not so horrible but not backwards-compatible), or you implement a similar escaping scheme in the path names. I think we'll stick with disallowing certain characters in file names forever. -- https://mail.python.org/mailman/listinfo/python-list