It's an interesting article, as a tour of some Python internals.
But it comes off as a rant without a real suggestion.
Python 3 was an internal interpreter cleanup. That's actually part of its lack of widespread popularity. The core developers didn't add a ton of unique functionality (and most of the new stuff was backported to 2.7 anyway), but they fixed some annoying problems in the CPython codebase and broke some things in the name of cleanup/unification of concepts. They made Python easier to maintain and easier to build new features atop. They sharpened the axe.
Yes, they didn't clean up Armin's pet thing -- slots. And they created new problems for library developers in their bytes vs unicode changes. But they cleaned up a whole lot of other stuff.
I personally think with the maturity of pypy and the stability of both the 2.7 and 3.4 lines of development, the Python ecosystem has never been more exciting. The advances in pypy make Python attractive for CPU-bound work and the inclusion of asyncio in the stdlib will make it more and more attractive for I/O-bound work over time. Python has long been a winner for mixed workloads, and the ecosystem around Python, especially pydata utilities like numpy and pandas, keep getting better. Stop complaining -- let's just build an awesome future atop this marvelous language.
>But it comes off as a rant without a real suggestion.
Did you actually read TFA? It makes some very real suggestions towards the end, and pinpoints clear issues and how they could be changed all the way through.
>But they cleaned up a whole lot of other stuff.
Which is irrelevant to the current discussion. How is "they cleaned X" a response for "they should clean Y"?
> But it comes off as a rant without a real suggestion.
How exactly is that a rant? It's an exploration about a design decision / mistake that was carried through Python for 25 years and has left an impact. There is no complaint and there is no suggestion for Python.
As I said in the early paragraph it's something that's interesting for people that are interested in language design.
I think I mis-spoke. I didn't really mean "rant", I meant "nit-pick". It's akin to the frequent complaints I hear about `len()` being a function rather than a method on `list` and `str` types.
This internal detail you focused on solves real problems; it's also a wart internally. OK, we get it. It's also not a hugely important wart, IMO. I don't think it's holding Python back.
But, like I said, I think the article was an interesting walkthrough of the internals. I enjoyed it overall :)
I think this is a bad comparison, because len() vs. foo.len() is just syntax, and isolated syntax at that. It's valuable to get syntax right, but this particular decision doesn't really impact anything outside of itself.
In contrast, the article suggests that the implementation of method dispatch slots (not __slots__!) actually constraints the optimizations you can make.
I get that you're trying to suggest that they're both small, but I think that this analogy only serves to confuse things.
It's a rant because the solution was ill defined. If the title of the article is 'The Python I Would Like To See', you should expect more detail of how to implement the solution.
I hope it is valid to describe a situation and voice a wish for a situation that would look different without having to provide a concrete step towards that.
The removal of the slot system would be a backwards incompatible change with very little direct benefit for developers. It could be interesting as a general goal for a hypothetical Python 4 but I do not believe it makes any sense to discuss this as anything more than a hypothetical case for the next few years.
> Instead of having slots and dictionaries as a vtable thing, let's experiment with just dictionaries. Objective-C as a language is entirely based on messages and it has made huge advances in making their calls fast. Their calls are from what I can see much faster than Python's calls in the best case. Strings are interned anyways in Python, making comparisons very fast. I bet you it's not slower and even if it was a tiny bit slower, it's a much simpler system that would be easier to optimize.
Breaking the print statement is probably a large reason for lack of adoption. It used to be much more convenient. They've lost sight of 'practicality beats purity'. What used to be print a,b,c is now print(a + " " + b + " " + c), or using the string formatting method. What used to be
print linewithnonewline,
with the comma indicating the lack of newline, now has to be done through print(line, end=""). Which is more practical and pythonic?
But it comes off as a rant without a real suggestion.
Python 3 was an internal interpreter cleanup. That's actually part of its lack of widespread popularity. The core developers didn't add a ton of unique functionality (and most of the new stuff was backported to 2.7 anyway), but they fixed some annoying problems in the CPython codebase and broke some things in the name of cleanup/unification of concepts. They made Python easier to maintain and easier to build new features atop. They sharpened the axe.
Yes, they didn't clean up Armin's pet thing -- slots. And they created new problems for library developers in their bytes vs unicode changes. But they cleaned up a whole lot of other stuff.
I personally think with the maturity of pypy and the stability of both the 2.7 and 3.4 lines of development, the Python ecosystem has never been more exciting. The advances in pypy make Python attractive for CPU-bound work and the inclusion of asyncio in the stdlib will make it more and more attractive for I/O-bound work over time. Python has long been a winner for mixed workloads, and the ecosystem around Python, especially pydata utilities like numpy and pandas, keep getting better. Stop complaining -- let's just build an awesome future atop this marvelous language.