Wrong reasons to enhancing the language

Carlos Ribeiro carribeiro at yahoo.com
Mon Mar 19 04:19:18 CET 2001


Le me try to summarize what I've seen on the past ten days or so on this 
list, regarding the awful lot of "enhancements" proposed to the Python 
language.

1) Proposing "syntactic sugar" changes to make some particular code 
constructions look better;
2) Proposing new operators because of speed concerns;
3) Fixing the semantic of the language to fix incompatibilities with other 
languages/modules/theoretical model;
4) Including new constructions because some other language support them;
5) Avoiding the inclusion of some constructions because some other language 
support them (yes, that also happens sometimes).

In my opinion, none of the above reasons is good enough to justify alone 
changes to the language. There are other criteria that need to be met. Are 
the extensions useful to many people? Are they generic and extensible? Do 
they cause any compatibility issue?

I dont think that we'll ever see a perfect language. Every one will have 
some issues or limitations, and thats part of the design decisions. Trying 
to make too much inside of the constraints of a single language is 
overkill. Small incompatibilities are impossible to avoid, partly because 
there are so many different things around. Some problems are just not worth 
the time to "fix" them. Maybe a different language is the answer for them. 
I think that is better to focus the effort where Python is already good, to 
make it stronger. There is no sense in trying to make Python the best tool 
for all jobs - it is an unattainable goal.

Synctatic sugar may make things clear for some, but makes it also a little 
bit harder for the others. If some code is speed critical, let's do it in 
C, C++, whatever compiled language you want. Python makes it extremely 
simple both ways, either to have embedded Python in a compiled language 
application, or to call compiled modules from Python code. Alternatively, 
I'm sure there is a lot of enhancements that could be done to the compiler 
to shave off precious CPU cycles. Why not spend more energy on this? 
Sometimes Python cant do what you want - maybe it's better to use another tool.

Note that I'm not against all change. I found the list comprehensions to be 
extremely effective. Also for the nested scopes - we all know that it 
didn't make it before for practical reasons. But some PEPs... sound silly 
at best.





_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com





More information about the Python-list mailing list