Proposal: Magic Constants

[Chris Gonnerman]

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.

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.

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.

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.

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.

Thoughts and opinions welcome...

Chris Gonnerman -- chris.gonnerman @newcenturycomp uters.net

http://newcenturycomputers.net

[Bernhard Herzog]

Re: Proposal: Magic Constants

"John Roth" <newsgroups@jhr othjr.com> writes:
[color=blue]
> "Chris Gonnerman" <chris.gonnerma n@newcenturycom puters.net> wrote:[color=green]
>> 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.[/color]
>
> 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."[/color]

This could be alleviated by doing something similar to how metaclasses
can be specified at the module level. Put a dictionary mapping suffixes
to constructors into a module level variable called e.g. __literals__ so
that you'd either do it by hand like this:

__literals__ = {"r": Rational}

or if you only need e.g. rational literals in your module could do

from rational import __literals__

Assuming the rational module provides a suitable dictionary for the
user's convenience.
[color=blue]
> 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.[/color]

Indeed.

Allowing this for strings would also provide a way to get self
interpolating string literals because the constructor could use
introspection to get a dictionary with all local variables in the
calling scope.
[color=blue]
> 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,[/color]

I think "1.or 2" would have to produce a syntax error under the new
rules.


Bernhard

--
Intevation GmbH http://intevation.de/
Sketch http://sketch.sourceforge.net/
Thuban http://thuban.intevation.org/

[Robert Kern]

Re: Proposal: Magic Constants

In article <vkpgjd74ub06ae @news.supernews .com>,
"John Roth" <newsgroups@jhr othjr.com> writes:

[snip]
[color=blue]
> 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.[/color]

10L
0X
1e+10
10j
[color=blue]
> John Roth[/color]

--
Robert Kern
kern@caltech.ed u

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Raymond Hettinger]

Re: Proposal: Magic Constants

[Chris Gonnerman][color=blue]
> 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.
>
> 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.[/color]

-1

This should not be done for several reasons:

* Constructors are more explicit: Rational(12, 3)

* The appearance unpleasantly reminds me of VB

* There are potential conflicts between alphabetic specifiers which
results in hard to spot bugs. Doest "1.25D" represent the
decimal class, Dewey decimals, or US dollars?

* Previous discussions on special syntaxes initially found them
to be enticing and then someone would realize that real programs
rarely have more than a handful of constants that would benefit
from the syntax. For instance, an accounting program is not
filled with specific values like $1.83. Instead, it constructs
nearly all of its data from user input or files. The program itself
likely checks for zero and amounts being under $1.00. Those
constants are easily and explicitly codeable with a normal
constructor: Decimal("1.00", 2) or some such.

* The registration process by-passes Python's elegant namespaces
and makes global changes resulting in hard to diagnose effects:

import bookaccounting # Hmm, did this just set D to DeweyDecimal?
import Decimal # Did this just reset the value of D or
was it F?
. . .
if foreign_currenc y:
import Francs
val = 15F # Was this the original F (for Fixed)
or the
# new F (for Francs) ?
# Does it automatically convert
from Euros?

* Guido is already uncomfortable with the number of kinds of string literals:
'abc', u'abc', ur'abc', r'abc', etc. He is unlikely to adopt any related
ideas
for numbers.

Other than that, it is a great idea ;-)


Raymond Hettinger

[Michael Hudson]

Re: Proposal: Magic Constants

"John Roth" <newsgroups@jhr othjr.com> writes:
[color=blue]
> But these are existing literal syntax. I was thinking
> more of random code where someone could currently
> juxtapose a literal and an identifier, say, without an
> intervening white space character.[/color]
[color=blue][color=green][color=darkred]
>>> 10and 1[/color][/color][/color]
1[color=blue][color=green][color=darkred]
>>> 5or 7[/color][/color][/color]
5

Very much a wart of the tokenizer, though.

Cheers,
mwh

--
"Well, the old ones go Mmmmmbbbbzzzztt teeeeeep as they start up and
the new ones go whupwhupwhupwho oopwhooooopwhoo ooooommmmmmmmmm ."
-- Graham Reed explains subway engines on asr

[John Roth]

Re: Proposal: Magic Constants


"Michael Hudson" <mwh@python.net > wrote in message
news:7h3r837ce1 2.fsf@pc150.mat hs.bris.ac.uk.. .[color=blue]
> "John Roth" <newsgroups@jhr othjr.com> writes:
>[color=green]
> > But these are existing literal syntax. I was thinking
> > more of random code where someone could currently
> > juxtapose a literal and an identifier, say, without an
> > intervening white space character.[/color]
>[color=green][color=darkred]
> >>> 10and 1[/color][/color]
> 1[color=green][color=darkred]
> >>> 5or 7[/color][/color]
> 5
>
> Very much a wart of the tokenizer, though.[/color]

Ah, right. I forgot about alphabetic operators.

Why do you call it a wart, though? I would have
thought that not requiring white space in that context
was a feature.

John Roth
[color=blue]
>
> Cheers,
> mwh
>
> --
> "Well, the old ones go Mmmmmbbbbzzzztt teeeeeep as they start up and
> the new ones go whupwhupwhupwho oopwhooooopwhoo ooooommmmmmmmmm ."
> -- Graham Reed explains subway engines on asr[/color]

[Raymond Hettinger]

Re: Proposal: Magic Constants

> > > But these are existing literal syntax. I was thinking[color=blue][color=green][color=darkred]
> > > more of random code where someone could currently
> > > juxtapose a literal and an identifier, say, without an
> > > intervening white space character.[/color]
> >[color=darkred]
> > >>> 10and 1[/color]
> > 1[color=darkred]
> > >>> 5or 7[/color]
> > 5
> >
> > Very much a wart of the tokenizer, though.[/color]
>
> Ah, right. I forgot about alphabetic operators.
>
> Why do you call it a wart, though? I would have
> thought that not requiring white space in that context
> was a feature.[/color]

Because the human eye/mind parses 10and as single a token.


Raymond Hettinger

[Michael Hudson]

Re: Proposal: Magic Constants

"John Roth" <newsgroups@jhr othjr.com> writes:
[color=blue]
> "Michael Hudson" <mwh@python.net > wrote in message
> news:7h3r837ce1 2.fsf@pc150.mat hs.bris.ac.uk.. .[color=green]
> > "John Roth" <newsgroups@jhr othjr.com> writes:
> >[color=darkred]
> > > But these are existing literal syntax. I was thinking
> > > more of random code where someone could currently
> > > juxtapose a literal and an identifier, say, without an
> > > intervening white space character.[/color]
> >[color=darkred]
> > >>> 10and 1[/color]
> > 1[color=darkred]
> > >>> 5or 7[/color]
> > 5
> >
> > Very much a wart of the tokenizer, though.[/color]
>
> Ah, right. I forgot about alphabetic operators.
>
> Why do you call it a wart, though? I would have
> thought that not requiring white space in that context
> was a feature.[/color]

Well, it's just odd. I'm pretty sure it's not intentional, and fairly
sure it's not documented. I don't care enough to check, though :-)

Cheers,
mwh

--
In many ways, it's a dull language, borrowing solid old concepts
from many other languages & styles: boring syntax, unsurprising
semantics, few automatic coercions, etc etc. But that's one of
the things I like about it. -- Tim Peters, 16 Sep 93

[John Roth]

Re: Proposal: Magic Constants


"Raymond Hettinger" <vze4rx4y@veriz on.net> wrote in message
news:eM53b.6461 $zL2.689@nwrdny 01.gnilink.net. ..[color=blue][color=green][color=darkred]
> > > > But these are existing literal syntax. I was thinking
> > > > more of random code where someone could currently
> > > > juxtapose a literal and an identifier, say, without an
> > > > intervening white space character.
> > >
> > > >>> 10and 1
> > > 1
> > > >>> 5or 7
> > > 5
> > >
> > > Very much a wart of the tokenizer, though.[/color]
> >
> > Ah, right. I forgot about alphabetic operators.
> >
> > Why do you call it a wart, though? I would have
> > thought that not requiring white space in that context
> > was a feature.[/color]
>
> Because the human eye/mind parses 10and as single a token.[/color]

Well, to be truthful about it, I'd just as soon require white
space between all tokens except for the delimiter types.
However, that's not going to happen because of the backwards
compatability issues.

John Roth[color=blue]
>
>
> Raymond Hettinger
>
>[/color]

[John Roth]

Re: Proposal: Magic Constants


"Michael Hudson" <mwh@python.net > wrote in message
news:7h365kj6jp 8.fsf@pc150.mat hs.bris.ac.uk.. .[color=blue]
> "John Roth" <newsgroups@jhr othjr.com> writes:
>[color=green]
> > "Michael Hudson" <mwh@python.net > wrote in message
> > news:7h3r837ce1 2.fsf@pc150.mat hs.bris.ac.uk.. .[color=darkred]
> > > "John Roth" <newsgroups@jhr othjr.com> writes:
> > >
> > > > But these are existing literal syntax. I was thinking
> > > > more of random code where someone could currently
> > > > juxtapose a literal and an identifier, say, without an
> > > > intervening white space character.
> > >
> > > >>> 10and 1
> > > 1
> > > >>> 5or 7
> > > 5
> > >
> > > Very much a wart of the tokenizer, though.[/color]
> >
> > Ah, right. I forgot about alphabetic operators.
> >
> > Why do you call it a wart, though? I would have
> > thought that not requiring white space in that context
> > was a feature.[/color]
>
> Well, it's just odd. I'm pretty sure it's not intentional, and fairly
> sure it's not documented. I don't care enough to check, though :-)[/color]

The whitespace rule (from the Python Language Reference Manual)
is:

[begin excerpt LRM 2.1.8 in Python 2.2.3]
Except at the beginning of a logical line or in string literals, the
whitespace characters space, tab and formfeed can be used interchangeably to
separate tokens. Whitespace is needed between two tokens only if their
concatenation could otherwise be interpreted as a different token (e.g., ab
is one token, but a b is two tokens).
[end excerpt]

John Roth[color=blue]
>
> Cheers,
> mwh
>
> --
> In many ways, it's a dull language, borrowing solid old concepts
> from many other languages & styles: boring syntax, unsurprising
> semantics, few automatic coercions, etc etc. But that's one of
> the things I like about it. -- Tim Peters, 16 Sep 93[/color]