[Python-Dev] When should pathlib stop being provisional? (original) (raw)

Stephen J. Turnbull stephen at xemacs.org
Wed Apr 6 01:40:06 EDT 2016

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.

More information about the Python-Dev mailing list