No language feature is optional
Please contact me for text I would also sign, not only acknowledge or if post got broken during one of many server upgrades. I will be most grateful.
Until recently I’ve been using Python 2.3.x almost exclusively and I thought it was about time I get more familiar with what 2.4 series has to offer. I’ve skimmed the list of new features when point zero version came out and found some things that I like (e.g sets) and some that I disliked (e.g. decorators).
So, this time I invested a bit more time to actually read and understand what was on offer and how these features came about. I still haven’t found a need or a sympathy for decorators, although I can see why some people want them. Personally, I believe they’ll more likely be a cause for less readable and harder to understand Python code than they prove to be useful.
I still think Python is a wonderful language, but gone are the days when I was looking forward to each release and goodness it brought. These days I’m afraid to look and discover another feature that helps more with keeping habits from other languages than adding something new and genuinely useful.
I like minimalism in all things and therefore see every new feature as a burden that should be more than offset by its usefulness. I’m not a language designer and hence can’t really say or tell if Python is going down the wrong track, but there is something that I find most annoying.
I’ve been thinking about languages quite a lot recently; how we use and abuse them and what impact our language proficiency has on our communications. There’s one thing I find very different with programming languages than those used for normal human interaction.
There’s very little optional about them.
It really gets my goat when a language feature is defended as being optional. You may have a choice in using a feature, but you certainly don’t get a choice in learning and understanding its use. Even if you don’t use it yourself, you’ll quite likely have to interact with somebody else’s code, which does and unlike with English, it’s not enough to just get a sense of meaning from its context. You actually have to really understand what it does and hence need to be familiar with feature itself.
It might still be worthwhile to add it, but let’s not pretend when we do that it’s completely optional.
P.S: Isn’t it amazing that after all these years, we still have a global interpreter lock? Wouldn’t it be better if we worked on removing that disgrace?
I’m a Python-head myself (since 2 years or so) and I tend to agree with your observations. Also keep in mind that for Python 3 some cruft will be removed, I’m very happy about that.
Recently I’ve started to read more about Smalltalk and if you are looking for language minimalism and extensibility and the same time take a look at it. The smalltalkers write statements like ifS and whileS with methods and blocks.
”Isn’t it amazing that after all these years, we still have a global interpreter lock? Wouldn’t it be better if we worked on removing that disgrace?”
They are talking *again* about the GIL right now on python-dev list.
– deelan
Comment by deelan — September 21, 2005 @ 2:24 pm
markos,
Check out the motivation (http://www.python.org/peps/pep-0318.html#motivation) for decorators if you haven’t already. That might help see how they can improve readability.
I hear you about simplicity and concern of where Python is heading. A good example is the use of anonymous code blocks in Ruby compared to their use in Python. Ruby has a general syntax that can be applied to solve different problems, Python has a different syntax for each problem set. Think list comprehension syntax vs. the proposed ‘with EXPR as VAR: BLOCK’ syntax for automatic resource cleanup.
Comment by mrevelle — September 21, 2005 @ 2:29 pm
I agree with you in some sense, but I think Guido is stemming the tide of convenience features, and is starting to add things that are genuinely useful, like PEP’s 342 and 343.
Why are you complaining about the GIL? Is the convenience of writing extension modules too much for you? Would you like to make it much more complex? Are you enamored by threads?
I posted about this just the other day: http://cleverdevil.org/computing/30
Comment by Jonathan LaCour — September 21, 2005 @ 4:03 pm
“”"Wouldn’t it be better if we worked on removing that disgrace?”"”
Sure. You first.
Or, as Guido recently said on Python-Dev:
“”"Talk is cheap; instead of arguing my
points (all of which can be argued ad infinitum), come back when
you’ve got a working GIL-free Python. Doesn’t have to be CPython-based
– C# would be fine too.”"”
Comment by Phillip J. Eby — September 21, 2005 @ 5:44 pm
Boy, I’ve never imagined that my post would provoke such a response.
I’ve certainly been ignorant when it comes to GIL’s role in development of extension modules. From that perspective GIL might not be so bad, although I think it made more sense when multiproc multicore machines weren’t so cheap and widely used.
I’m not a threads fan, but I do recognize that they are used, sometimes even with obvious speed advantage (apache) and Python integration with such codebase often leaves something to be desired.
Also true is that I’m not the right person to complain since I haven’t provided a patch to fix GIL or anything of the sort, but then again, I thought my post was mainly about optionality of features.
P.S: Thanks for links. They’ve certainly expanded my horizons.
Comment by markos — September 21, 2005 @ 6:01 pm
I actually think Python development really follows this principle (no optional features) more than others (e.g., Ruby, Perl, PHP). It’s not to say that some people say “if you don’t like it, don’t use it”, but that’s not something Guido says, and I don’t believe that’s a sentiment that takes place when the design is really happening. And, for example, if-else conditions were kept out largely because — though they could sometimes be nice, and some people liked them — they didn’t seem right for everyone all the time.
I could go on at length about the benefit of decorators, though I’ll admit in some ways the mechanics overshadow the concept itself — but really the mechanics are pleasantly simple enough that it’s okay. But I think we shouldn’t go overboard and worship the altar of simplicity — people have been obsessing lately over what we can remove from __builtins__, and for what? Some Schemy aesthetic that says small is beautiful. Big isn’t beautiful, but beauty is a little more subtle than size.
Comment by Ian Bicking — September 21, 2005 @ 7:14 pm
If you have speed critical bits which run in C you can tell the GIL not to lock for your speed critical bit in C.
Multiple processes are also good for multiple processors, and multiple cores to get high CPU usage. Async, and events are usually better performant for IO compared to threads too.
So in practice the GIL doesn’t really matter for performance, and makes our lives safer, and simpler.
ps. Did you know that threads in linux are just processes? Check out the clone man page.
Comment by Rene Dudfield — September 22, 2005 @ 9:15 am
One of the few things that bothers me about Python: community excuses for Python weaknesses.
The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software
http://www.gotw.ca/publications/concurrency-ddj.htm
Comment by is not BDFL — September 22, 2005 @ 8:06 pm
Ian, I would agree with you, if it weren’t that Guido and a lot of other people keep trumpeting the *optional* nature of upcoming typechecking. About every third word in the posts on the topic, including Guido’s, seems to be optional, presumably to deflect the ire and attention of people like myself who between type checking and interfaces are wondering why we stopped using Java as our primary language.
Comment by John Withers — September 22, 2005 @ 9:30 pm
About multicores and processes – I think that at least for intel’s hyperthreads technology the multicore only works for threads. That’s because all the cores share the same virtual memory page table – which processes do not share while threads do.
Comment by Yair — September 24, 2005 @ 10:30 pm