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