[Python-Dev] When should pathlib stop being provisional?

[Stephen J. Turnbull]

Ethan Furman writes:

 > No, Stephen, that is not what this is about.

Wrong Steven.  Spelling matters in email too.  And he's more worth
paying attention to than I am.  But I'll have my say anyway. ;-)

 > This is about the ugliness of code with str(path) this and
 > str(path) that

-1 Not good enough.  I wouldn't do it that often that "ugly" overrides
the reasoning Brett presented, and if you do, I bet one or two
personal helpers would clean up 95% of your cases.  But see Nick's
comment that "str(var)" is too permissive.  I'll have to think about
that, but my first take is he's right, and we need to do something
about making use of Path more straightforward within the stdlib.
Whatever that is, preferably would make life easier for 3rd party
usage too, of course.

Is error-checking within Path sufficiently robust in the light of "too
permissive"?  (I don't know exactly what I mean by that, but something
like if "str(var_purporting_to_be_Path)" is too permissive, are we
sure that "str(really_is_Path_var)" is "safe"?  Apparently we haven't
had a lot of beta testing.)

 > and let's not forget the Path(this_returned_string) and
 > Path(that_returned_string),

But we don't object to (de)serializing dicts to (from) str (as JSON or
pickle).  I think Path vs. string is similarly different to justify
saying so (especially when treating user input).  Note, too, that
based on discussion in that thread it seems likely that Path is likely
to be inappropriate as an internal representation of URL.RFC3986.Path.
Thus, strings that look like paths (as strings) actually will have
multiple internal representations, similarly to the way that a dict
can have multiple serializations.  If representation transformation is
not invertible, EIBTI says we need the "boilerplate".

YMMV, but that's my take.