classification
Title: Implement PurePath.__len__
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.10
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: SilentGhost, brandtbucher, cool-RR, pitrou, remi.lapeyre, serhiy.storchaka
Priority: normal Keywords: patch

Created on 2020-05-24 08:04 by cool-RR, last changed 2020-05-24 11:09 by serhiy.storchaka. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 20348 closed cool-RR, 2020-05-24 08:12
Messages (10)
msg369767 - (view) Author: Ram Rachum (cool-RR) * Date: 2020-05-24 08:04
I'm writing the patch now.
msg369768 - (view) Author: SilentGhost (SilentGhost) * (Python triager) Date: 2020-05-24 08:11
What would it do?
msg369769 - (view) Author: Ram Rachum (cool-RR) * Date: 2020-05-24 08:12
Just return len(str(path)). I put the use case on the PR on GitHub.
msg369771 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-05-24 09:35
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?
msg369773 - (view) Author: Rémi Lapeyre (remi.lapeyre) * Date: 2020-05-24 09:40
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.
msg369774 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-05-24 09:49
If it is not iterable, the length does not make sense.

Do you expect also len(-123) == 4?
msg369778 - (view) Author: Ram Rachum (cool-RR) * Date: 2020-05-24 10:22
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.
msg369779 - (view) Author: Rémi Lapeyre (remi.lapeyre) * Date: 2020-05-24 10:33
> 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.
msg369780 - (view) Author: Ram Rachum (cool-RR) * Date: 2020-05-24 10:43
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.
msg369784 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-05-24 11:09
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.
History
Date User Action Args
2020-05-24 11:09:49serhiy.storchakasetstatus: open -> closed
resolution: rejected
messages: + msg369784

stage: patch review -> resolved
2020-05-24 10:43:34cool-RRsetmessages: + msg369780
2020-05-24 10:33:28remi.lapeyresetmessages: + msg369779
2020-05-24 10:22:12cool-RRsetnosy: + brandtbucher
messages: + msg369778
2020-05-24 09:49:38serhiy.storchakasetmessages: + msg369774
2020-05-24 09:40:27remi.lapeyresetnosy: + remi.lapeyre
messages: + msg369773
2020-05-24 09:35:48serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg369771
2020-05-24 08:12:57cool-RRsetmessages: + msg369769
2020-05-24 08:12:10cool-RRsetkeywords: + patch
stage: patch review
pull_requests: + pull_request19611
2020-05-24 08:11:33SilentGhostsetnosy: + SilentGhost, pitrou
messages: + msg369768
2020-05-24 08:04:44cool-RRcreate