Guido van Rossum wrote:
Just a suggestion which might also open the door for other numeric type extensions to play along nicely:
Would it make sense to have an extensible registry of constructors for numeric types which maps number literal modifiers to constructors ?
I am thinking of
123L -> long("123") 123i -> int("123") 123.45f -> float("123.45")
The registry would map 'L' to long(), 'i' to int(), 'f' to float() and be extensible in the sense, that e.g. an extension like mxNumber could register its own mappings which would make the types defined in these extensions much more accessible without having to path the interpreter. mxNumber for example could then register 'r' to map to mx.Number.Rational() and a user could then write 1/2r would map to 1 / mx.Number.Rational("2") and generate a Rational number object for 1/2.
The registry would have to be made smart enough to seperate integer notations from floating point ones and use two separate default mapping for these, e.g. '<int>' -> int() and '<float>' -> float().
The advantage of such a mechanism would be that a user could easily change the literal semantics at his/her taste.
Note that I don't think that we really need a separate interpreter just to add decimals or rationals to the core. All that is needed is some easy way to construct these number objects without too much programming overhead (i.e. number of keys to hit ;-).
Funny, I had a similar idea today in the shower (always the best place to think :-). I'm not sure exactly how it would work yet -- currently, literals are converted to values at compile-time, so the registry would have to be available to the compiler, but the concept seems to make more sense if it is available and changeable at runtime.
True, but deferring the conversion to runtime (by e.g. using literal descriptors ;-) would cause a significant slowdown. So, I believe that the compiler would have be told before starting the compile process or within the process by looking at some magical constant/comment in the source code (I think that this ought to be a per-file overrideable setting, since some code may simply fail to work if it suddenly starts to work with different types).
Nevertheless, we should keep this in mind.
I could reformat the above into a PEP or Michael could simply the idea as section to his PEP. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/