<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, 5 Apr 2016 at 15:55 Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's been provisional since 3.4. I think if it is still there in 3.6.0<br>
it should be considered no longer provisional. But this may indeed be<br>
a test case for the ultimate fate of provisional modules -- should we<br>
remove it?<br>
<br>
I have to admit I got tired of the discussions and muted them all.<br></blockquote><div><br></div><div>:) I figured. I was close myself until I decided to be the "not inheriting from str is a sane decision" camp because people weren't understanding where the design decision probably came from, hence <a href="http://www.snarky.ca/why-pathlib-path-doesn-t-inherit-from-str">http://www.snarky.ca/why-pathlib-path-doesn-t-inherit-from-str</a> .<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Personally I am not worried about the light use (I always expected it<br>
would take a long time to get adoption)</blockquote><div><br></div><div>Ditto. My expectation/hope is that once we stop having it be provisional and we start using it in the stdlib then usage will pick up, especially if libraries pick up the `getattr(path, 'path', path)` idiom as an easy transition technique until they decide to drop support for str-based paths. The main motivation of this email is actually to have newcomers to the sprints at PyCon US sprint on adding support for pathlib (after we add "path-like object" to the glossary to say something like "a `str` object or an object that has a `path` attribute that itself is a `str`").</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> but I am worried about the<br>
hostility towards the module. My last/only comment in the discussion<br>
was about there possibly being a dichotomy between people who use<br>
Python for scripting and those who use it to write more substantial<br>
programs (I'm trying not to judge one group more important than<br>
another -- I'm just observing there seem to be these two groups). But<br>
I didn't stick around long enough to watch for responses to this idea.<br></blockquote><div><br></div><div>Nope, no response (as Alexander pointed out).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Would making it inherit from str cause most hostility to disappear?<br></blockquote><div><br></div><div>Probably. Most people were upset with pathlib because they couldn't use it immediately with all of the third-party libraries out there on top of the stdlib because adoption has been so low. Now if we make a concerted effort to accept pathlib in the stdlib then this may be the kick in the pants that it takes to start getting people to accept it externally and the transition band-aid of inheriting from str may not be needed.</div><div><br></div><div>To me it seems to basically be a question of whether people can be patient during a transition and embrace pathlib over time or if they will simply refuse to add support in libraries and refuse to use `getattr(path, 'path', path)` or `str(path)` in the mean time. Personally, if we can wait out the Python 3 transition I have no issue waiting on a transition like this that has no backward-compatibility issues and has a one-liner solution for adding shallow support (and thus is ripe for quick patches to projects).</div><div><br></div><div>After the whole str thing the only other major topic was coming up with some easier way to produce pathlib.Path instances (e.g. the p-string suggestion). Nothing really came of those discussions that seemed concrete and reach consensus, though (I think that may have been where your scripting/substantial programming comment came from).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm sure there was a discussion about this when PEP 428 was originally<br>
proposed, and I recall I was strongly in the camp of "it should not<br>
inherit from str", but unfortunately the PEP has no mention of this<br>
discussion or even the stated reason.<br></blockquote><div><br></div><div><a href="https://www.python.org/dev/peps/pep-0428/#no-confusion-with-builtins">https://www.python.org/dev/peps/pep-0428/#no-confusion-with-builtins</a> is the best you get in the PEP.<br></div><div><br></div><div>-Brett</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--Guido<br>
<br>
<br>
On Tue, Apr 5, 2016 at 3:41 PM, Brett Cannon <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>> wrote:<br>
> After a rather extensive discussion on python-ideas about pathlib.PurePath<br>
> not inheriting from str, another point that came up was that the use of<br>
> pathlib has been rather light. Unfortunately even the stdlib doesn't really<br>
> use pathlib because it's currently marked as provisional (or at least that's<br>
> why I haven't tried to use it where possible in importlib).<br>
><br>
> Do we have a plan of what is required to remove the provisional label from<br>
> pathlib?<br>
><br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe:<br>
> <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/guido%40python.org</a><br>
><br>
<br>
<br>
<br>
--<br>
--Guido van Rossum (<a href="http://python.org/~guido" rel="noreferrer" target="_blank">python.org/~guido</a>)<br>
</blockquote></div></div>