Python compilers?

Günter Jantzen nc-jantzegu at netcologne.de
Sat May 22 17:46:15 EDT 2004


"Terry Reedy" <tjreedy at udel.edu> schrieb im Newsbeitrag
news:mailman.183.1085238574.6949.python-list at python.org...
>
> > So compiled Lisp is a less dynamic than Python,
>
> The balance between flexibity and speed continues to be debated by the
> developers.

And should be debated by the users, too.

Not all of Pythons dynamics is really necessary to write good programms.
Writing good software needs creativity and discipline. We like to work with
Python, because it allows us creativitity. Sometimes to enforce a grain of
discipline in Python would not be bad. There have been many discussions
about programming idioms and design patterns in the last years. They give
not so high level languages the ability to simulate high level features.
They could also help to give a very high level language more solid ground.
And they normalize the way to handle common classes of problems

"""There should be one-- and preferably only one --obvious way to do it.
"""
We could try to search  patterns, idioms, antipatterns which could establish
a better way to use the Python language:
-- to avoid unnecessary dynamics
-- to avoid unnecessary features
-- to establish the 'obvious way to do it'
-- without loosing the power and expressiveness of python

"""In the face of ambiguity, refuse the temptation to guess.
"""
Possible sideeffect:.- it could be easier for mechanical tools (Pyrex,
Psycho, PyPy, Starkiller) to make Python faster

Not all people will agree about a useful set of patterns. But this is not
necessary now.
Patterns and idioms do not change a language immediately. They do not fall
from heaven, it is necessary to play around and to gain some experience.

I think patterns define a subset of a language and some constraints on
programms
Maybe this constrained subset (or subsets if there are controversal ideas)
can be formalized and be checked by 'pylintplus' or 'pythoncheckerX' (do not
google).
Or there would be a configurable universal 'Monsterchecker'. In the first
line of our sources we expose a checkpolicy and the checker will follow this
policy.
If patterns can not be formalized so easy, they can be established by
convention.

I do not know the result of this process ...
Now some ideas what could be done in the near future

1) Integration of Pyrex into Python.
[strong variant]
Syntactically this languages are close. Maybe they could be changed so, that
every valid Pyrex source is also a valid Python source with -hopefully- the
same semantics. Special Pyrex tokens would be allowed, but meaningless when
used in the Python context.
Benefit: more homogenous environment. Little changes in the program could be
made without a C-Compilation step.
Maybe the support of interfaces would be necessary in Python, but this is
not a bad idea.
Then rewrite some parts of the standard library in Pyrex

[weak variant]
Rewrite some parts of the standard library in Pyrex

2) Find a set of constraints which make it easier for Psyco (now) and
Starkiller (later) to do their job

3) Implement Monsterchecker modes for 1 and 2

Regards
Guenter





More information about the Python-list mailing list