Wrong reasons to enhancing the language
Carlos Ribeiro
carribeiro at yahoo.com
Sun Mar 18 22:19:18 EST 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