undefined | Better HN

0 pointsirahul14y ago0 comments

> Don't know if it should be a method or an attribute? Python has properties now, the user doesn't have to care.

Python didn't have properties when the len protocol was implemented. What exactly will be gained if Python replaces len(a) with a.length(where a.length translates to a.__len__())? If properties were there from the beginning, that would have been the implementation; but since they weren't, len(a) is just fine and I don't see any reason for it to be changed.

> The 'special meaning' section that follows seems a bit confused as well. Why is it so special to get the length of a collection?

Personally I would have preferred __len__ to be just length, because length of a sequence is part of it's public interface, as opposed to other special methods viz. __getattr__, __getitem__. Apart from that, his 'special meaning' section is just saying that following a weird naming convention for the special methods permits programttacily differentiating between public interface and special methods.

> I can feel it working within me too, I'm more and more on the fence about explicit self.

The main reason it is that way is decorators.

http://neopythonic.blogspot.in/2008/10/why-explicit-self-has...

> However this is complete and utter bullshit.

This isn't an appropriate response to a well thought out article.

0 comments

2 comments · 2 top-level

rictic14y ago

len and __len__ may have made sense when they were first implemented, I do not disagree.

Having tutored students learning python as their first experience programming, I recall that it was confusing that len was a function which merely calls a method on its argument. They wanted to know when they should write their own functions in a similar style.

I looked into it, and the best answer I came up with was that len is an historical artifact. If it were designed with the capabilities of modern Python, then there would be no good reason for doing it that way that I can find. Please correct me if I'm wrong.

The article as a whole is quite good. Its arguments in favor of len being a builtin function are quite bad. I've noticed this as something of a pattern in the Python community that I'm speaking out against. It's ok for there to be things in a project the size and age of Python that are historical artifacts. Python is certainly far and away better in this regard than its sibling languages.

Defending them as good design is counterproductive. I don't want newly designed languages to ape the mistakes of the old.

rictic14y ago

On reflection, the bullshit comment was overblown. The author was not trying to be deceptive or anything. I take it back.

j / k navigate · click thread line to collapse

0 comments

2 comments · 2 top-level

rictic14y ago

len and __len__ may have made sense when they were first implemented, I do not disagree.

Defending them as good design is counterproductive. I don't want newly designed languages to ape the mistakes of the old.

rictic14y ago

On reflection, the bullshit comment was overblown. The author was not trying to be deceptive or anything. I take it back.

j / k navigate · click thread line to collapse