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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4