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