Proposal: Decimal literals in Python.
Lennart Benschop
type is ideal for financial calculations. Using this data type would be
more intuitive to computer novices than float as its rounding behaviour
matches more closely what humans expect. More to the point: 0.1 and 0.01
are exact in Decimal and not exact in float.
Unfortunately it is not very easy to access the Decimal data type. To obtain
the decimal number 12.34 one has to do something like this:
import decimal
x=decimal.Decimal("12.34")
Of course we can intruduce a single character function name as an alias for
the Decimal type constructor, but even then we have to use both parentheses
and quotes for each and every decimal constant. We cannot make it shorter
than D("12.34")
With Python 3000 major changes to the language are carried out anyway. My
proposal would require relatively minor changes.
My proposal:
- Any decimal constant suffixed with the letter "D" or "d" will be
interpreted as a literal of the Decimal type. This also goes for
decimal constants with exponential notation.
Examples of decimal literals:
1d
12.34d
1e-3d (equivalent to 0.001d)
1e3d (same value as 1000d, but without trailing zeros).
1.25e5d (same value as 125000d but without trailing zeros).
When we print a decimal number or convert it to a string with str(), a
trailing d should not be added. The repr function does yield strings with a
trailing d.
When decimal numbers are converted from strings, both numbers with and
without a trailing d should be accepted.
If we have decimal literals in the core language, we should probably have a
type constructor in the core namespace, e.g. dec() along with int()
and float(). We then need the decimal module only for the more advanced
stuff like setcontext.
Pros:
- the Decimal data type will be more readily accessible, especially
for novices.
- Traling characters at the end of a literal are already used (the L
for long).
- It does not conflict with the syntax of other numeric constants or
language constructs.
- It does not change the meaning of existing valid literal constants.
Constants that used to be float will continue to do so.
Cons:
- The lexical scanner of the Python interpreter will be slightly more
complex.
- The d suffix for constants with exponential notation is ugly.
- Decimal numbers with exponentail notation like 2e5d could be mistaken
for hex (by humans, not by the parser as hex requires the 0x prefix).
- It requires the decimal module to be part of the core Python
interpreter.
--
Lennart
Ben Finney
> Python has had the Decimal data type for some time now.
Since version 2.4 <URL:http://www.python.org/dev/peps/pep-0327>.
> Unfortunately it is not very easy to access the Decimal data
> type. To obtain the decimal number 12.34 one has to do something
> like this:
>
> import decimal
> x=decimal.Decimal("12.34")
Slightly nicer, if you need to create a lot of them::
>>> from decimal import Decimal
>>> foo = Decimal("12.34")
> Of course we can intruduce a single character function name as an
> alias for the Decimal type constructor, but even then we have to use
> both parentheses and quotes for each and every decimal constant. We
> cannot make it shorter than D("12.34")
Nor should we. A function or type name should be short but explicit,
and 'Decimal' is about as short as I'd want.
> With Python 3000
"Python 3000" is now in beta development, and is called Python version
3.0.
> major changes to the language are carried out anyway.
All of which have been decided for some time now. It's rather too late
to introduce behaviour changes and hope for them to be in Python 3.0.
> My proposal:
Feel free to file an actual proposal using the PEP process. You might
want to refer to the PEP that introduced the Decimal type for
inspiration.
--
\ "How many people here have telekenetic powers? Raise my hand." |
`\ -- Emo Philips |
_o__) |
Ben Finney
Steven D'Aprano
>> Of course we can intruduce a single character function name as an alias
>> for the Decimal type constructor, but even then we have to use both
>> parentheses and quotes for each and every decimal constant. We cannot
>> make it shorter than D("12.34")
>
> Nor should we. A function or type name should be short but explicit, and
> 'Decimal' is about as short as I'd want.
You don't like str, int, float, list, set, dict, or bool?
Or for that matter, enum
http://www.python.org/dev/peps/pep-0354/
*wink*
--
Steven.
Ben Finney
> On Fri, 26 Oct 2007 19:19:46 +1000, Ben Finney wrote:
> > Nor should we. A function or type name should be short but
> > explicit, and 'Decimal' is about as short as I'd want.
>
> You don't like str, int, float, list, set, dict, or bool?
They'd all make lousy names for a decimal type.
--
\ "Whatever you do will be insignificant, but it is very |
`\ important that you do it." -- Mahatma Gandhi |
_o__) |
Ben Finney
Shane Geiger
D = lambda x: decimal.Decimal(str(x))
>> D(3.2)
Decimal("3.2")
--
Shane Geiger
IT Director
National Council on Economic Education
sge...@ncee.net | 402-438-8958 | http://www.ncee.net
Leading the Campaign for Economic and Financial Literacy
Matimus
> for long).
The trailing L is going away in Python 3.0. For your consideration may
I suggest a '$' prefix. Though, I'm not sure I even support the idea
of a decimal literal, and I'm not even sure if I support the idea of
using a prefix '$' to identify that literal, it seems somewhat
fitting.
So...
Decimal("12.34") -> $12.34
Pros:
- Easier to see than appended character (I think)
- Notation is fitting when dealing with monetary values
- Easy to remember
Cons:
- Maybe too clever for its own good. Some people may be confused to
find out that it isn't actually a monetary type.
I'm sure there are more...
Matt
Ben Finney
> The trailing L [for 'long' literals] is going away in Python 3.0.
Yes. On the other hand, we are gaining '0bNNNN' for binary literals,
to go along with '0oNNNN' for octal and '0xNNNN' for hexadecimal.
So, the original poster might get further by proposing an '0dNNN.NNN'
syntax for 'decimal.Decimal' literals. At least the syntax would be
consistent and wouldn't add a new punctuation character to the
language...
> For your consideration may I suggest a '$' prefix.
... unlike this one.
--
\ "The illiterate of the future will not be the person who cannot |
`\ read. It will be the person who does not know how to learn." |
_o__) -- Alvin Toffler |
Ben Finney
J. Cliff Dyer
privilege one country, but still too region-centric. Generic currency
marker from ISO 8859-1 would be even less unnecessarily specific, but
also too obscure.
- Looks funny if you use more or fewer than 2 decimal places.
- Sacrifices clarity of meaning for brevity.
>
> Matt
My only problem with Decimal("12.34") is the quotation marks. It makes
it look like a string type.
Cheers,
Cliff
J. Cliff Dyer
> Matimus <mccr...@gmail.com> writes:
>
>
>> The trailing L [for 'long' literals] is going away in Python 3.0.
>>
>
> Yes. On the other hand, we are gaining '0bNNNN' for binary literals,
> to go along with '0oNNNN' for octal and '0xNNNN' for hexadecimal.
>
> So, the original poster might get further by proposing an '0dNNN.NNN'
> syntax for 'decimal.Decimal' literals.
Python 3.0a1 (py3k:57844, Aug 31 2007, 16:54:27) [MSC v.1310 32 bit
(Intel)] on win32
<snip>
>>> type(0b1)
<type 'int'>
>>> type(0o1)
<type 'int'>
>>> type(0x1)
<type 'int'>
>>> assert 0b1 is 0x1
>>>
<hypothetical code>
>>> type(0d1)
<class 'decimal.Decimal'>
>>> assert 0b1 is 0d1
Traceback (most recent call last):
File "<pyshell#8>", line 1, in <module>
assert 0b1 is 0d1
AssertionError
</hypothetical code>
It would also be unkind to people with dyslexia.
Cheers,
Cliff
Carl Banks
> Python has had the Decimal data type for some time now. The Decimal data
> type is ideal for financial calculations. Using this data type would be
> more intuitive to computer novices than float as its rounding behaviour
> matches more closely what humans expect. More to the point: 0.1 and 0.01
> are exact in Decimal and not exact in float.
>
> Unfortunately it is not very easy to access the Decimal data type. To obtain
> the decimal number 12.34 one has to do something like this:
>
> import decimal
> x=decimal.Decimal("12.34")
>
> Of course we can intruduce a single character function name as an alias for
> the Decimal type constructor, but even then we have to use both parentheses
> and quotes for each and every decimal constant. We cannot make it shorter
> than D("12.34")
>
> With Python 3000 major changes to the language are carried out anyway. My
> proposal would require relatively minor changes.
>
> My proposal:
> - Any decimal constant suffixed with the letter "D" or "d" will be
> interpreted as a literal of the Decimal type. This also goes for
> decimal constants with exponential notation.
This brings something to mind.
One thing I've always thought would be cool would be to have
programmable literals. (Note: Python 3 has a ban on programmable
syntax, and this is clearly falls under that umbrella, although in a
limited form. So this is not a proposal of any sort, just idle
chatter. :)
The idea is: the compiler would see the literal, evaluate it at
compile time, and marshal the evaluated value into the *.pyc file.
More easily said than done, yes, and I'm aware of the issues in doing
that. But it'd be pretty useful, I'd think.
Decimal literals has been mentioned.
In fact it could benefit a lot of numeric objects, such as those in
gmpy.
Regular expressions. A significant speed deficiency of regexps in
Python relative to Perl is that Python has to compile regular
expressions every time the program is invoked. What if you could
compile the regexp at, you know, compile time, and marshall the
compiled state? It could speed things up a bit, especially for small,
regexp heavy scripts.
Oh, well, you get the idea. It's not going to happen, but it'd be
cool while not anything crucial.
Carl Banks
Carl Banks
> Matimus wrote:
> >> - Traling characters at the end of a literal are already used (the L
> >> for long).
>
> > The trailing L is going away in Python 3.0. For your consideration may
> > I suggest a '$' prefix. Though, I'm not sure I even support the idea
> > of a decimal literal, and I'm not even sure if I support the idea of
> > using a prefix '$' to identify that literal, it seems somewhat
> > fitting.
>
> > So...
> > Decimal("12.34") -> $12.34
>
> > Pros:
> > - Easier to see than appended character (I think)
> > - Notation is fitting when dealing with monetary values
> > - Easy to remember
> > Cons:
> > - Maybe too clever for its own good. Some people may be confused to
> > find out that it isn't actually a monetary type.
> > I'm sure there are more...
>
> - Too U.S. centric. Euro would be a slight improvement, as it doesn't
> privilege one country, but still too region-centric. Generic currency
> marker from ISO 8859-1 would be even less unnecessarily specific, but
> also too obscure.
FYI: The $ sign is used to denote currency in many countries; as a
rule of thumb countties that call their currency "dollars" or "pesos"
use the $. So Mexico, Canada, Australia, much of Latin America, much
of the Pacific, not to mention countries in Africa (Zimbabwe) and Asia
(Singapore).
It's certainly less region-specific than the Euro is.
Carl Banks
Terry Reedy
"Shane Geiger" <sge...@ncee.net> wrote in message
news:4722398D...@ncee.net...
a buggy hack (copying your top post style)
>>> D(123456789.123456789)
Decimal("123456789.123")
Or what there an unwritten :-)?
Marc 'BlackJack' Rintsch
> Ben Finney wrote:
>> So, the original poster might get further by proposing an '0dNNN.NNN'
>> syntax for 'decimal.Decimal' literals.
> It would rather be remarkably inconsistent and confusing.
>
> Python 3.0a1 (py3k:57844, Aug 31 2007, 16:54:27) [MSC v.1310 32 bit
> (Intel)] on win32
> <snip>
>>>> type(0b1)
> <type 'int'>
>>>> type(0o1)
> <type 'int'>
>>>> type(0x1)
> <type 'int'>
>>>> assert 0b1 is 0x1
>>>>
That this doesn't raise `AssertionError` is an implementation detail.
It's not guaranteed the two objects are really the same.
Ciao,
Marc 'BlackJack' Rintsch
Paul Rubin
> >>>> assert 0b1 is 0x1
> That this doesn't raise `AssertionError` is an implementation detail.
> It's not guaranteed the two objects are really the same.
I think Ben is getting at 0b1 and 0x1 being the same type, while the
proposed 0d1 is a different type. I don't see anything wrong with 1d.
We already have 1j and I don't think that's going away in 3.0.
Raymond Hettinger
> My proposal:
> - Any decimal constant suffixed with the letter "D" or "d" will be
> interpreted as a literal of the Decimal type. This also goes for
> decimal constants with exponential notation.
There's nothing new here that hasn't already been proposed and
discussed on python-dev. There were no major objections to the idea;
however, it will need to wait until there is a good C implementation
of the decimal module (which is in the works but coming along very,
very slowly). Also, once we have a C coded decimal object, further
work would be needed to make it integrate well with the rest of the
language (i.e. making sure that everything allows numeric inputs can
handle a decimal object as a possible input).
FWIW, using the decimal module is not at all as onerous as the OP
makes it sound. I write:
from decimal import Decimal as D
print D(1) / D(7) + D('0.123456')
That isn't much of a burden compared with:
print 1d / 7d + 0.123456d
You would still need to import decimal so you can set the context
parameters (like precision and rounding).
Also, most non-toy scripts have *very* few literals in them; instead,
the decimal values arise from calculations, user inputs, and file of
data. Casting those to the correct type is really no more difficult
that it is with other types:
s = raw_input('Input temperature')
print int(s), Decimal(s), float(s)
Raymond
MRAB
wrote:
> Matimus <mccre...@gmail.com> writes:
> > The trailing L [for 'long' literals] is going away in Python 3.0.
>
> Yes. On the other hand, we are gaining '0bNNNN' for binary literals,
> to go along with '0oNNNN' for octal and '0xNNNN' for hexadecimal.
>
> So, the original poster might get further by proposing an '0dNNN.NNN'
> syntax for 'decimal.Decimal' literals. At least the syntax would be
> consistent and wouldn't add a new punctuation character to the
> language...
>
Some languages have or permit 0qNNNN or 0QNNNN for octal to reduce the
chance of confusion of 'O' (oh) with '0' (zero) in uppercase, eg.
0Q123 is clearer than 0O123 (0 oh 123), although lowercase is better,
eg. 0q123 or 0o123.
Paul Hankin
Even clearer is not to allow octal literals :) Is there *any* use for
them?
--
Paul Hankin
Tim Chase
> them?
+1
I find that anything I have even the remotest inkling of using
octal for can be done just as easily with hex.
-tkc
Dan Bishop
The mode argument to os.chmod.
Tim Chase
>> them?
>
> The mode argument to os.chmod.
You mean instead of
import this
os.chmod(filename, os.R_OK | os.W_OK | os.X_OK)
which explicitly (rather than implicitly) spells it out?
-tkc
Marc 'BlackJack' Rintsch
And the equivalent of ``os.chmod(filename, 0777)`` looks like what!?
Ciao,
Marc 'BlackJack' Rintsch
Neil Cerutti
os.chmod(filename, int('777', 8))
It's good enough for most other bases. ;)
--
Neil Cerutti
Hendrik van Rooyen
> Even clearer is not to allow octal literals :) Is there *any* use for
> them?
I tend to agree with this point of view - but I fear it will set up a howl
of protest amongst the Brits who cut their teeth on 24 bit ICT/ICL
equipment...
- Hendrik
Tim Roberts
My favorite notation for this comes from Ada, which allows arbitrary bases
from 2 to 16, and allows for underscores within numeric literals:
x23_bin : constant := 2#0001_0111#;
x23_oct : constant := 8#27#;
x23_dec : constant := 10#23#;
x23_hex : constant := 16#17#;
The opportunities for obfuscated coding by writing all constants in base 7
boggle the mind.
I'm not convinced you need delimiters on both ends; I think 16'fffe_3777
would be just as good.
Although, now that I think about the original thread, this doesn't have a
neat solution for the decimal problem...
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Tim Roberts
As a long-time Control Data employee, I know that 60-bit words and 18-bit
addresses meant that I could do octal arithmetic nearly as fast as decimal.
On the other hand, Python doesn't run on the 6000s...
Gabriel Genellina
escribi�:
> FYI: The $ sign is used to denote currency in many countries; as a
> rule of thumb countties that call their currency "dollars" or "pesos"
> use the $. So Mexico, Canada, Australia, much of Latin America, much
> of the Pacific, not to mention countries in Africa (Zimbabwe) and Asia
> (Singapore).
[OT] Furthermore, the $ sign was used originally to denote "pesos", or
Spanish reals (pieces of eight each). It was later that the US adopted the
sign to denote "dollars" too.
--
Gabriel Genellina
Scott David Daniels
> My favorite notation for this comes from Ada, which allows arbitrary bases
> from 2 to 16, and allows for underscores within numeric literals:
>
> x23_bin : constant := 2#0001_0111#;
> x23_oct : constant := 8#27#;
> x23_dec : constant := 10#23#;
> x23_hex : constant := 16#17#;
.f.123 == 0x123
.7.123 == 0o123
.1.1101 == 0b1101
That is, .<largest allowed digit>.<digits>
-- show the base by showing base-1 in the base.
I actually built this into "OZ," an interpretter.
--Scott David Daniels
Scott....@Acm.Org
MRAB
x23_bin = 2r0001_0111
x23_oct = 8r27
x23_dec = 10r23
x23_hex = 16r17