[Python-Dev] Splitting the PEP for adding a decimal type to Python

[Guido van Rossum]

[me]
> > 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 ;-).

[Michael]
> I wasn't suggesting creating a separate interpreter, I was
> suggesting adding a simple mechanism for allowing a new dialect of
> Python to be added to the existing interpreter.

Understood.  I see no big difference in having two binaries or one
binary with a command line option; the two binaries effectively
contain the same functionality, just with a different default.  I
would vote for one binary; if you really think it's too much for your
users to say "python -d" instead of "dpython", give them a script.  (I
know that the -d option currently means something else.  That's a
detail to worry about later.)

> This new dialect would be easier to use for certain types of
> programming activities.  The use of a decimal number type as the
> default type in this new language dialect is only one change that
> was proposed.

I'm not very fond of having multiple dialects.  There are lots of
contexts where the dialect in use is not explicitly mentioned
(e.g. when people discuss fragments of Python code).

> Another would be to use Unicode as the default character set.  This
> would allow Unicode characters to be in strings without needing to
> escape them.

That's not a dialect, that's a different input encoding.  MAL already
has a PEP for that.

> The proposal also suggests removing the tab character from
> indentation of blocks.  The goal is to create a language that would
> clean up some of the warts in the Python syntax and take advantage
> of the capabilities of modern IDE environments.

What does removing tab characters have to do with decimal numbers?
One topic per PEP, please!

> The idea of adding a new language on top of the existing
> infrastructure isn't that unusual. The gcc compiler can process many
> languages to produce a common machine dependant object code.  I can
> envision taking my simple changes a few steps further and turning
> the entire tokenizer into a replaceable unit.  This approach would
> allows projects to build other languages on top of the Python byte
> code interpreter.  Imagine having Javascript, VBasic, or sh
> tokenizer frontends generating Python bytecodes.  Think of it as the
> pyNET architecture:-) This change probably belongs in Python4k.

Or in Python .NET.  Decoupling the various part of the parse+compile
pipeline is something I've considered.

But again this has nothing to do with decimal numbers: your proposal
allows the mixing of decimal and binary numbers (as long as one of
them uses an explicit base indicator) so you don't really need two
parsers -- you need one tokenizer plus a way to specify the default
numeric base for literals.

> Perhaps the PEP should be split into two parts.  The first PEP would
> be to add decimal characters with a 'd' suffix and also allow suffix
> characters to be added to the default float and integer types.  I
> think everyone agrees that this change is needed.

It's needed *if* we agree that we need a decimal data type.

> The second PEP will cover the proposed creation of the dpython
> dialect.  This PEP would be a container for proposed changes to the
> Python syntax that would make the language easier to teach to
> newbies and easier to use in a financial application.

I'll have to go back to your defense of the two dialect approach, but
I think it's neither sufficient nor necessary.

> Your suggestion to allow additional numerical types to be added by
> users would be included in the first PEP if the BDFL thinks this is
> a good idea.

Well, sometimes more generality than you need hurts.  I'm not
convinced that we need an open-ended set of numeric literals.  But in
the light of the unified numeric model, we may need ways to make
exactness or inexactness explicit, and/or we may need a way to specify
rational numbers.  If we can fit all of these in the
number-with-letter-suffix mold, that would be nice for the lexer, I
suppose.

--Guido van Rossum (home page: http://www.python.org/~guido/)