R: [Python-Dev] Re: User extendable literal modifiers ?!
Fri, 27 Sep 2002 15:45:57 +0200
From: M.-A. Lemburg <firstname.lastname@example.org>
> Samuele Pedroni wrote:
> > From: Alex Martelli <email@example.com>
> >>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
> > ... import Rational in all modules that use $r, one import per program just
> > 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.