I guess that's my most major beef with it. The upgrade has been tough, and a lot of the most inconsistent aspects of Python weren't fixed. (A good example: "len()")
BTW, I tried using Python 3 on that project in 2010, if that helps anyone gauge my opinion on it.
Yeah, sure, there are still some things in there that make me wonder why they didn't go one step further to fix it too. Little things even, like the names of the special methods to intercept attribute access: __getattr__ and __getattribute__ should have been swapped for consistency, since __getattribute__ is closer in behavior to __setattr__ and __delattr__, making the current __getattr__ the behavioral outlier.
But meh, any language has its odd little warts, and so has Python 3. It does have significantly less than Python 2, though.
However this is complete and utter bullshit.
Other languages are inconsistent? The answer is not to be inconsistent, and you can be consistent as a method or as a builtin function.
Don't know if it should be a method or an attribute? Python has properties now, the user doesn't have to care.
The 'special meaning' section that follows seems a bit confused as well. Why is it so special to get the length of a collection?
Sorry for going off on a rant, please correct me if I'm wrong here. I just get so frustrated with the eagerness of the Python community's apologetics for things that no longer make sense to be in the language.
I can feel it working within me too, I'm more and more on the fence about explicit self.
With dynamically typed languages, it is very hard to "be consistent as a method" since there are no tools to enforce that consistency. Social cues usually go 90% of the way, but not all the way whereas a function/generic method handles that just fine: to get a length, you call `len`. Period. The developer does not really have the option to do otherwise, unless he wants to opt out of the language's ecosystem.
Actually what I said above is not entirely true, there is one situation where it is "quite easy" to handle method consistency in a dynamically typed language: when you deal with mixins.
Because mixins have preconditions (methods and/or properties which need to exist for it to work), they enforce those names or they can't be used at all. And of course any method brought in by the mixin is "enforced" by default.
So is it with most things iteration in Ruby for instance: Enumerable mandates that a core internal iterator named `#each` exists (as well as #<=> optionally) and as a reward for doing so it gives about 30 methods "for free". That enforces consistency in collection traversal, because even if you reimplement some or all of these methods in the long term (for efficiency and whatnot) getting them "for free" out of the box is valuable.
If it is good design there, should others repeat it? For example, if a module author is defining a new protocol for a set of objects that anyone can implement should they provide functions that delegate to the methods in their protocol?
For myself I think that the python community can be counted on to be consistent without the need for this duplication and indirection.
No, because each collection type (mapping, sequence, set, ...) has very different addition semantics (and potentially arguments as well). On the other hand, there is a builtin to iterate over stuff.
And readability in itself, I mean alone in its own merit isn't a deciding factor for most projects today.
Far too many factors decide in choosing a language today, they rapidly change and will continue to change over time. Concurrency and JVM's feasibility is giving clojure great mileage in the mainstream.
The problem with python is, its brittle enough to break at any new syntax experiment. This doesn't do good for language evolution.
And evolution is what keeps you in the game. How else do you think Perl and Lisp have managed to survive and grow till today's date.
I don't sort of want to be making a negative point here. But hey Perl has been adding keywords and new syntax to Perl 5 without breaking backwards compatibility.
Some times flexibility is important.
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.
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.