On 04/05/2016 03:55 PM, Guido van Rossum wrote:
It's been provisional since 3.4. I think if it is still there in 3.6.0
it should be considered no longer provisional. But this may indeed be
a test case for the ultimate fate of provisional modules -- should we
remove it?
We should either remove it or make the rest of the stdlib work with it.
Currently, pathlib.*Paths are second-class citizens, and working with
them is not significantly better than working with os.path.* simply
because we have to cast to str every time we want to deal with any other
part of the stdlib.
Would making it inherit from str cause most hostility to disappear?
I don't think that is necessary. The hostility (of which I have some)
is because we can't do:
app_root = Path(...)
config = app_root/'settings.cfg'
with open(config) as blah:
# whatever
It feels like instead of addressing this basic disconnect, the answer
has instead been: add that to pathlib! Which works great -- until a
user or a library gets this path object and tries to use something from
os on it.
To come at this from a different angle: Python now has Enum; it is
arguable that Path is more important, or at least much more useful. We
have IntEnum whose sole purpose in life is to make it possible to
(mostly) seamlessly work with the stdlib and other libraries where ints
are being used to represent enumerations; and in pathlib we have . . .
absolutely nothing. We have the promise of great things and wonderful
usability, but in reality we have just as much pain as before -- or more
if we forget to str(path) somewhere.
I said that pathlib.Path does not need to inherit from str, and I still
think that; however, to be a good stepping stone / transitional library
I think the pathlib backport does need to have its Paths inherit from str.
--
~Ethan~
_______________________________________________
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
