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 ;-).
--
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Consulting & Company: http://www.egenix.com/
Python Software: http://www.lemburg.com/python/
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