Proposal: Magic Constants

[John Roth]

Interesting thoughts. See my comments interspersed.

John Roth

"Chris Gonnerman" <chris.gonnerman at newcenturycomputers.net> wrote in message
news:mailman.1061989198.28274.python-list at python.org...
> A while back (a long while actually) I was a
> participant in a long argument over decimal and
> rational numbers, and their inclusion into the
> core of Python.
>
> Last night in a dream I came up with an
> interesting solution (no, really!) which, in the
> cold light of morning, still seems pretty cool.

Unusual, but what the heck, it does happen.

> The gist is this:  Constants would be allowed to
> be trailed by any single alphabetic character.
> When compiled, a constant with a nonstandard
> letter code would be stored in the compiled code
> in the form of a text literal, appropriately
> marked.
>
> When the code is executed, and the special
> literal is processed, the interpreter would look
> up a conversion function in an internal list.  If
> no conversion is found, a runtime error would be
> raised.

I'd prefer to start by handing it off to the object
that is most likely to want to process it first.
Although I'm not sure about how to identify that
object reliably.

> Modules to handle alternate numeric formats, such
> as decimal, fixed-point, rational, etc. would
> include a call to a builtin registration function
> which would allow them to "take over" a specific
> alphabetic specifier.

There's another namespace with a possibility
of collisions here, and also the same old "we
can't make one of these a builtin because it
might break user code." I'd suggest doing
something up front, like reserving lower case
letters for Python core enhancements, and
upper case letters for application useage.

> So, to use a supposed Decimal.py module, one
> would do thusly:
>
>     "decimal arithmetic example"
>
>     import Decimal
>
>     a = 1.05D
>
> and so on.
>
> Limitations:  The literal would be required by
> the compiler to match the format of a real number
> (float or integer); the conversion function could
> raise its own runtime error if the text string
> were out of its range.  So, to write a rational
> number:
>
>     "rational arithmetic example"
>
>     import Rational
>
>     b = 1R/15
>
> Note that the 1R is actually the rational 1/1,
> whereas the 15 is an integer; the division sign
> is not part of the rational here, but actually
> indicates division.  The result would be the
> rational 1/15, which is assigned to the variable
> b.

Rational isn't actually a problem, as long as
we ignore the silly idea that integer division
should yield a float. Either that, or provide
a rational divide operator that always returns
a rational if both operands are integers,
rationals or decimals.

> The only other disadvantage I can see is that a
> small class of syntax errors become runtime
> errors.  I'm don't think this is a major thing
> though.

That's always something that some people are
going to be on one side of, some on the other.

> Thoughts and opinions welcome...

One overall thought: why limit it to numbers?
The new datetime module would benefit from
a datetime literal, but that would have to be
a character string.

One point you need to emphasize in the PEP
(I presume you're going to write a PEP) is
that this isn't an optimization. for example,
decimal(10.687) won't work correctly. You
loose precision because 10.687 is a float.

Another thing to think about is whether
this could cause problems with existing
code. I can't immediately think of a case
where a literal can be next to a character,
but I'm also not a real deep authority on all
of the oddities of Python syntax.

John Roth

> Chris Gonnerman -- chris.gonnerman at newcenturycomputers.net
> http://newcenturycomputers.net
>
>