As you might have noticed, I have wrapped several parts of the GMP Multi-Precision (GMP) library in form of Python types in mxNumber. Since these are numbers, it would be convenient if there were some way to create them in form of literals, much like 123L creates longs instead of integers or u"abc" gives you Unicode instead of an 8-bit string. I was wondering whether it would be worth adding something like a registry of literal modifiers to Python, so that extensions can register new modifiers with the compiler, e.g. sitecustomize.py: def create_I_literal(literal_string): return 'mx.Number.Integer(%s)' % literal_string sys.register_numberlitmod('I', create_I_literal) test.py: x = 123I * 456I print x, 234I -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
In article <3D9423FB.9070303@lemburg.com>, M.-A. Lemburg wrote:
[mxNumber] I was wondering whether it would be worth adding something like a registry of literal modifiers to Python,
Especially for this purpose, that would be great. And have potential for misuse, too. Just like, say, operator overloading. But in the context of Python, I didn't see any misuse of operator overloading, yet.
[...] so that extensions can register new modifiers with the compiler, e.g.
sitecustomize.py: def create_I_literal(literal_string): return 'mx.Number.Integer(%s)' % literal_string sys.register_numberlitmod('I', create_I_literal)
A single literal, however, doesn't (easily) allow you to give precision and scale arguments to your decimal literal. That's of course easy if you can declare your variable, which you can't in Python. So we're back to constructors/factory functions here, right? -- Gerhard
Gerhard Häring wrote:
In article <3D9423FB.9070303@lemburg.com>, M.-A. Lemburg wrote:
[mxNumber] I was wondering whether it would be worth adding something like a registry of literal modifiers to Python,
Especially for this purpose, that would be great. And have potential for misuse, too. Just like, say, operator overloading. But in the context of Python, I didn't see any misuse of operator overloading, yet.
I was thinking of giving the current concept of literal modifiers a more general scope. Of course, this can be misused, but then we could e.g. put certain constraints on the possible modifiers, say only allow a predefined number of modifiers and then have the compiler at compile time or the interpreter at run-time apply the necessary logic to the literal to turn it into an object. We currently have 'u', 'r', 'U', 'R' as modifiers for strings (prefixes) and 'l', 'L', 'j', 'J' for numbers (postfix).
[...] so that extensions can register new modifiers with the compiler, e.g.
sitecustomize.py: def create_I_literal(literal_string): return 'mx.Number.Integer(%s)' % literal_string sys.register_numberlitmod('I', create_I_literal)
A single literal, however, doesn't (easily) allow you to give precision and scale arguments to your decimal literal. That's of course easy if you can declare your variable, which you can't in Python. So we're back to constructors/factory functions here, right?
Not really, since mxNumber Integers have arbitrary precision, so scale and precision are not needed. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
"M.-A. Lemburg" <mal@lemburg.com> writes:
Since these are numbers, it would be convenient if there were some way to create them in form of literals, much like 123L creates longs instead of integers or u"abc" gives you Unicode instead of an 8-bit string.
How would you marshal them? Curious, Martin
Martin v. Loewis wrote:
"M.-A. Lemburg" <mal@lemburg.com> writes:
Since these are numbers, it would be convenient if there were some way to create them in form of literals, much like 123L creates longs instead of integers or u"abc" gives you Unicode instead of an 8-bit string.
How would you marshal them?
Using a new marshal token which only stores the modifier together with the literal as string. marshal.load() would then restore the object by looking up the constructor in the modifier registry and calling it with the string argument. But that's just an implementation detail. What's more important is whether this ideas raises interest or not. I'm not sure myself whether it's a good idea and that's why I posted the idea here. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
What's more important is whether this ideas raises interest or not. I'm not sure myself whether it's a good idea and that's why I posted the idea here.
There are lots of possibilities for overgeneralization here. E.g. most of the examples of the $x"..." syntax are just as easily done using a function call, either passing a string or a few numbers. One danger of new notations is that it could be much harder to find out what it means if you're not familiar with a program. If you see a call to Frobozz(1, 2), it usually isn't hard to find the definition of Frobozz -- at the worst, it's hidden in an "import *", and that's one reason to avoid those. But if you see $f"1 2" in a file, you may have to grep all code that is imported by the program containing that file for calls to sys.register. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido> But if you see $f"1 2" in a file, you may have to grep all code Guido> that is imported by the program containing that file for calls to Guido> sys.register. Even worse, if you happen to see it in isolation (a module disconnected from the program it was written for), you might have no way to find out what the $f prefix means. Skip
Guido van Rossum wrote:
What's more important is whether this ideas raises interest or not. I'm not sure myself whether it's a good idea and that's why I posted the idea here.
There are lots of possibilities for overgeneralization here. E.g. most of the examples of the $x"..." syntax are just as easily done using a function call, either passing a string or a few numbers.
One danger of new notations is that it could be much harder to find out what it means if you're not familiar with a program. If you see a call to Frobozz(1, 2), it usually isn't hard to find the definition of Frobozz -- at the worst, it's hidden in an "import *", and that's one reason to avoid those. But if you see $f"1 2" in a file, you may have to grep all code that is imported by the program containing that file for calls to sys.register.
You're probably right. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
participants (5)
-
Gerhard Häring -
Guido van Rossum -
M.-A. Lemburg -
martin＠v.loewis.de -
Skip Montanaro