A better self
Alex Martelli
aleax at aleax.it
Wed Jul 24 03:55:20 EDT 2002
Michele Simionato wrote:
> Personally, I have no problems in conforming myself to the established
> tradition and to use the standard self. However many people don't like
> self. It has not been mentioned in this thread, but there a simple way to
> cope with this problem without changing the language: a Python
> preprocessor.
>
> Suppose one define the pseudocode
>
> --begin pseudo.py--
>
> from math import sin,sqrt
>
> class Example:
> y,z,t=1.0,1.0,1.0
> def f(,x):
> return sin(.t)*x**.y+sqrt(.z)
...
> The preprocessor idea is interesting, not only for people who want to
> create their own shortcuts to the language (I think it is better to use
> good habits and to use the standard language), but even for more serious
> jobs.
Yes, but it doesn't fit smoothly with Python's normal work organization.
Using an extension different than .py for the preprocessor-sources makes
it OK for languages normally handled with makefiles, but that's not how
you usually work in Python.
If you want preprocessing, I suggest you integrate it differently:
class Example(Prepro):
'''
y,z,t=1.0,1.0,1.0
def f(,x):
return sin(.t)*x**.y+sqrt(.z)
'''
Prepro is an otherwise empty class whose metaclass is MetaPrepro.
MetaPrepro's __new__ method gets Example's dict, containing only the
__docstring__ with all the above source. It can change that source
at will, the prepare the real dict with the needed entries and
finally delegate up to type.__new__.
I suggested a similar approach based on bytecodes, but even for
source to source transformation (which is easier and better portable
across different bytecode/VMs) I think it would be the right tack.
Alex
More information about the Python-list
mailing list