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 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.