R: [Python-Dev] Re: User extendable literal modifiers ?! (original) (raw)

Samuele Pedroni pedronis@bluewin.ch
Fri, 27 Sep 2002 15:45:57 +0200

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.