[Python-Dev] Re: User extendable literal modifiers ?!

M.-A. Lemburg mal@lemburg.com
Fri, 27 Sep 2002 15:47:58 +0200

Samuele Pedroni wrote:
> From: Alex Martelli <aleax@aleax.it>
>>I thought this use would have to return the sequence of
>>tokens for identifier 'Rational', open parenthesis, literal
>>(value of) numerator, comma, literal (value of) denominator,
>>closed parenthesis -- which in turn is why I thought of an
>>arbitrary sequence of tokens.  If a single instance of any
>>arbitrary class may be returned and get treated as a
>>literal token by the parser, then that's much better
> indeed, because then otherwise
> $r"123/234" = literal transformation => Rational(123,234)
> would require Rational to be installed in the builtins, or some kind of
> implicit import (ugly) or people would have to rember to put an explicit from
> ... import Rational in all modules that use $r, one import per program just to
> register $r would not be enough.

These are implementation details, e.g. if Python would
provide a way to register new modifiers, these would only
start working after having been registered.

Let's say that a user wants 123I to map to mx.Number.Integer(123),
then he'd have to make sure that mx.Number is imported in
sitecustomize.py to have Python load modules containing the
123I literal using the registered object constructor for that
literal modifier. Otherwise, the compiler or module loader
would fail. There should not be any magic imports going on
behind the scenes.

Note that the whole point of the idea is to simplify
using really basic types. Anything more complicated
than a single character modifier would fail to meet
this requirement.

Marc-Andre Lemburg
CEO eGenix.com Software GmbH
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting:                               http://www.egenix.com/
Python Software:                    http://www.egenix.com/files/python/