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