[Python-ideas] Working with Path objects: p-strings?

[Sven R. Kunze]

On 30.03.2016 00:03, Brett Cannon wrote:
>
>     I cannot believe that the current representation is so
>     bad and has been for so long and nobody, really nobody, has anything
>     done about it.
>
>
> [...] pathlib.Path is a better representation of a path than a plain 
> string and that strings on their own are nothing that special in terms 
> of representing a string that demands we defend it on its own grounds 
> as such.

I agree with the first part.

I disagree with the second (assuming you mean "representing a path"). 
Strings are extremely useful for informal working like exploration, 
debugging etc.


>     I think most "practicality beats purity" folks don't want that either.
>     They are just bloody lazy. They actually want the benefits of
>     both, the
>     pure datastructure with its convenience methods and the dirty str-like
>     thing with its convenience methods.
>
>     People don't like it when somebody takes one bag of convenience away
>     from them if they easily can have both. ;-)
>
>
> That's fine, but I also don't want to have the worry of latent bugs 
> lurking in code either due to implicit type compatibility and so that 
> clashes in this instance.

Could you give an example here?


> Sure, but that doesn't mean the situation can't be improved. You can 
> also get the string out of Path objects to hack on, but that doesn't 
> mean you should be shipping paths around in your code as strings 
> either. I'm not saying you *can't* use strings to represent a path, 
> just that it isn't the best option available from a higher-level 
> perspective.

Let me think of a recommendation here. I personally find the proposed 
idiom quite cumbersome and ugly but that's just me. However, it is 
basically not better than "latent bugs lurking in code" due to 
inheritance. Wrapping stuff up just because we don't know if it's a 
string or a path is always a bad idea.

In pathlibs current form, this would give use a recommendation for 
application developers:

1) pass a path if you need path methods
2) pass a path.path if you want to do string manipulations
3) don't try both at the same time

Would this makes sense?


>     Selling pathlib with the "getattr(path, 'path', path)" idiom is not
>     going to help those fellows. I mean, are you serious? It looks
>     ridiculous. :-/
>
>
> I disagree.

That's fine but that's something I would call toiled paper programming. 
Wrapping things up until it doesn't smell anymore. Seems like here I am 
the purist. ;-)
So, having only one place (the stdlib) dealing with this inconvenience 
would make things less worse I suppose.


> I suspect simple fixes like updating the docs and using `getattr(p, 
> 'path', p)` in the right places will be the kind of quick fixes the 
> GitHub migration will encourage.

I look forward to it. :)


Best,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160330/2091f13b/attachment.html>