I'm writing the patch now.

What would it do?

Just return len(str(path)). I put the use case on the PR on GitHub.

The length of the object is the number of some items in the object. It is usually tied with iteration: len(obj) == len(list(obj)). Is this true for PurePath?

PurePath is not iterable but I would expect 

len(Path('/home/remi/src/cpython')) == 4


The fact the the path is stored as a string is an implementation detail, it seems leaky to get the length of the string here.

If it is not iterable, the length does not make sense.

Do you expect also len(-123) == 4?

Remi: Your use case is taken care of by `len(path.parts)`.

Serhiy: "If it is not iterable, the length does not make sense." I'm not sure this is a rule. I do see that the `collections.abc.Sized` class does not require an `__iter__` method to be defined.

> Remi: Your use case is taken care of by `len(path.parts)`.

Yes, and your use case is taken care of by `len(str(path))` which works as well.

The reason in the PR is to simplify:

sorted(paths, key=lambda path: len(str(path)), reverse=True)

to 

sorted(paths, key=len, reverse=True)

but why avoiding a few characters?


My remark is not that it __len__ should be len(path.parts) but that the semantics are unclear (I should have wrote "**if __len__ is defined** I would expect...")


Since the semantics are unclear I would except it not to be defined. Also, it's common to use a lambda or an helper function in sorted(), map(), filter(), etc. Most use case can't be covered using existing methods and shouldn't necessarely be.

I understand your argument. I think it relies on your earlier statement: "The fact the the path is stored as a string is an implementation detail."

This statement reminds me of the term "architecture astronaut". Pathlib builds a cool architecture over the concept of paths. But landing back in reality, all paths are strings, aren't they? On any OS, even looking at esoteric things such as UNC paths on Windows, they're all eventually strings and are treated by most tools as just strings.

If I'm missing any edge cases, let me know. But otherwise I think it's okay to look at `Path` as a string with bells and whistles.

Path is not a string with bells and whistles. It was intentionally made not a string subclass because some string operations (including len()) just do not make sense for path or are ambiguous.

I am closing this as it goes against the initial design of pathlib. If you disagree, discuss this idea on Python-ideas first and get the support of other core developers.