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

[Samuele Pedroni]

From: M.-A. Lemburg <mal@lemburg.com>
> 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.

yes but that' my point, I simply pointed out  that the strategy that simply
re-interprets $r through a lexical transformation does not work.

regards.