On Thu, Apr 14, 2016, at 13:56, Koos Zevenhoven wrote: > (1) Code that has access to pathname/filename data and has some level > of control over what data type comes in. This code may for instance > choose to deal with either bytes or str > > (2) Code that takes the path or file name that it happens to get and > does something with it. This type of code can be divided into > subgroups as follows: > > (2a) Code that accepts only one type of paths (e.g. str, bytes or > pathlib) and fails if it gets something else.
Ideally, these should go away. > (2b) Code that wants to support different types of paths such as > str, bytes or pathlib objects. This includes os.path.*, os.scandir, > and various other standard library code. Presumably there is also > third-party code that does the same. These functions may want to > preserve the str-ness or bytes-ness of the paths in case they return > paths, as the stdlib now does. But new code may even want to return > pathlib objects when they get such objects as inputs. Hold on. None of the discussion I've seen has included any way to specify how to construct a new object representing a different path other than the ones passed in. Surely you're not suggesting type(a)(b). Also, how does DirEntry fit in with any of this? > This is the > duck-typing or polymorphic code we have been talking about. Code of > this type (2b) may want to avoid implicit conversions because it makes > the life of code of the other types more difficult. As long as the type it returns is still a path/bytes/str (and therefore can be accepted when the caller passes it somewhere else) what's the problem? _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
