Lambda the Ultimate

If you drop "_"s then do you add/require an adjective to method declarations that override builtins? That's not very Pythonesque (imho). Alternatively, by dropping "_"s and adding no new sytnax, you run the risk of breaking new code. In the past I think Perl has gone down this route (adding compiler warnings to help bitten users), but for pretty obscure stuff (iirc).

I'd go for no "_"s and a compiler warning, but Python is aimed at newbies and I don't think they'd want to run the risk of alienating people.

Ah, syntax... :-)

I don't feel that the (current) lack of static scoping, closures and tail recursion prevents me from getting my work done in any way. I would much rather see work done on interpreter to improve performance.

What would you do instead of _xxx_?

I guess to back up for a minute, I would have to guess why the signature was chosen. In Python, the leadin __ is a pseudo way to attain private methods. I would assume that all of these methods are supposed to be private methods that are not normally accessible through composition and object collaboration. The trailing __ is just a naming convention used that has no syntactic significance. Though many of these methods are used by the outside world - it's just that they are invoked by operators or more general functions.

It just may be me, but I find that it detracts from the readibility of the code. I don't think that Python will ever change the use of name mangling for the base object methods that are redefined in the subclasses. But I always like the idea of having the actual method names be as close as possible to the invocation names.

I don't feel that the (current) lack of static scoping, closures and tail recursion prevents me from getting my work done in any way.

I would much rather see work done on interpreter to improve performance.

__xxx__ was there from the beginning, while __xxx mangling is a relatively late addition (officially supported in 1.5).

__xxx__ names are not mangled.

Part of Python's charm (I think) is that it was until recently one man's vision of what a programming language should be. People responded to this and the community of users grew. Now, more and more features are being added, and I think Python may begin to lose its particular flavor. For example, I liked list comprehensions in Haskell and Miranda, but now that they're in Python, I'm not so sure how much I like them. Of course, this is also due to the fact that their implementation has not been optimized, so their performance lags compared to for. I'm not sure that tail recursion is necessary in a language that supports iteration, because the ability to use constant stack space is already present.

I would rather see work on the underlying interpreter done, so Python exhibits better speed and memory usage, rather than adding more questionable features or syntactic sugar. Down that road lies the way to PL/1 (or Ada !)

Now that I know more functional languages I can see that there are really better tools for the job, and Python can stick to doing what it does best. But maybe all I'm really saying is that I don't use Python much any more :-)

(The one place where I do use it is as a scripting language at work, in the hope that other software engineers, used to Java, will find it readable. So far that's proved a pretty vain hope and using list comprehensions and lambda certainly wouldn't help there.)