Chris Barker - NOAA Federal wrote: > Why in the world do the os.path functions need to work with Path > objects? So that applications using path objects can pass them to library code that uses os.path to manipulate them. > I'm confused about what a bytes path IS -- is it encoded? It's a sequence of bytes identifying a file. Often it will be an encoding of som piece of text in the file system encoding, but there's no guarantee of that. > Can you assume it can be decoded ? Only if you use an encoding in which all byte sequences are valid, such as latin1 or utf8+surrogateescape. > So the ONLY thing > you should do with it is pass it along to another low level system > call. Not quite -- you can separate it into components and work with them. Essentially the same set of operations that os.path provides. >>- the names would be fspath and __fspath__, since the result may be >>either a path name as text, or an encoded path name as bytes > > I like __pathname__ better because this entire effort is because we' > be decided itMs important to make the distinction between a "path" and > the text representation of said path. I agree -- the term "pathname" can cover both text and bytes. When posix talks about pathnames it's really talking about bytes. -- Greg
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4