Re: Proposal: Decimal literals in Python.
Tim Roberts wrote: 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#; And mine is one w/o the base 10 bias: .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.dani...@acm.org -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
Scott David Daniels wrote: Tim Roberts wrote: 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#; And mine is one w/o the base 10 bias: .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. Smalltalk uses r (for radix). If we also permit underscores: x23_bin = 2r0001_0111 x23_oct = 8r27 x23_dec = 10r23 x23_hex = 16r17 -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
Paul Hankin p...l.comwrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
MRAB [EMAIL PROTECTED] wrote: On Oct 27, 12:12 am, Ben Finney [EMAIL PROTECTED] wrote: Matimus [EMAIL PROTECTED] writes: The trailing L [for 'long' literals] is going away in Python 3.0. Yes. On the other hand, we are gaining '0b' for binary literals, to go along with '0o' for octal and '0x' 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... [snip] Some languages have or permit 0q or 0Q 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. 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, [EMAIL PROTECTED] Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
Hendrik van Rooyen [EMAIL PROTECTED] wrote: Paul Hankin p...l.comwrote: 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... 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... -- Tim Roberts, [EMAIL PROTECTED] Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
[OT] Re: Proposal: Decimal literals in Python.
En Fri, 26 Oct 2007 23:28:31 -0300, Carl Banks [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
Marc 'BlackJack' Rintsch [EMAIL PROTECTED] writes: 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
On Oct 26, 1:54 am, Lennart Benschop [EMAIL PROTECTED] wrote:
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
--
http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
On Oct 27, 12:12 am, Ben Finney [EMAIL PROTECTED] wrote: Matimus [EMAIL PROTECTED] writes: The trailing L [for 'long' literals] is going away in Python 3.0. Yes. On the other hand, we are gaining '0b' for binary literals, to go along with '0o' for octal and '0x' 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... [snip] Some languages have or permit 0q or 0Q 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
On Oct 27, 3:09 pm, MRAB [EMAIL PROTECTED] wrote: On Oct 27, 12:12 am, Ben Finney [EMAIL PROTECTED] wrote: Matimus [EMAIL PROTECTED] writes: The trailing L [for 'long' literals] is going away in Python 3.0. Yes. On the other hand, we are gaining '0b' for binary literals, to go along with '0o' for octal and '0x' 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... [snip] Some languages have or permit 0q or 0Q 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. Even clearer is not to allow octal literals :) Is there *any* use for them? -- Paul Hankin -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
Even clearer is not to allow octal literals :) Is there *any* use for 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
On Oct 27, 10:27 am, Paul Hankin [EMAIL PROTECTED] wrote: On Oct 27, 3:09 pm, MRAB [EMAIL PROTECTED] wrote: On Oct 27, 12:12 am, Ben Finney [EMAIL PROTECTED] wrote: Matimus [EMAIL PROTECTED] writes: The trailing L [for 'long' literals] is going away in Python 3.0. Yes. On the other hand, we are gaining '0b' for binary literals, to go along with '0o' for octal and '0x' 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... [snip] Some languages have or permit 0q or 0Q 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. Even clearer is not to allow octal literals :) Is there *any* use for them? The mode argument to os.chmod. -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
Even clearer is not to allow octal literals :) Is there *any* use for 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
On Sat, 27 Oct 2007 13:28:02 -0500, Tim Chase wrote: Even clearer is not to allow octal literals :) Is there *any* use for 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? And the equivalent of ``os.chmod(filename, 0777)`` looks like what!? Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
Marc 'BlackJack' Rintsch wrote: On Sat, 27 Oct 2007 13:28:02 -0500, Tim Chase wrote: Even clearer is not to allow octal literals :) Is there *any* use for 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? And the equivalent of ``os.chmod(filename, 0777)`` looks like what!? Ciao, Marc 'BlackJack' Rintsch Ugly. But is one function in one library, which doesn't even exist in one of the major operating systems really worth its own syntactic construct in the language? It seems that it would be fairly simple for python to treat the octal argument as a string, rather than an int: os.chmod(filename, 777) If somebody had a good *general* use for octal, it might be worth having in the language. Otherwise, it seems like an unused which is only kept around because it used to get played with. (back in the days of six bit hardware?) Cheers, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
On 2007-10-27, Marc 'BlackJack' Rintsch [EMAIL PROTECTED] wrote:
On Sat, 27 Oct 2007 13:28:02 -0500, Tim Chase wrote:
Even clearer is not to allow octal literals :) Is there *any* use for
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?
And the equivalent of ``os.chmod(filename, 0777)`` looks like what!?
os.chmod(filename, int('777', 8))
It's good enough for most other bases. ;)
--
Neil Cerutti
--
http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
Lennart Benschop [EMAIL PROTECTED] writes: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
On Fri, 26 Oct 2007 19:19:46 +1000, Ben Finney wrote: 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
Steven D'Aprano [EMAIL PROTECTED] writes: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
D = lambda x: decimal.Decimal(str(x)) D(3.2) Decimal(3.2) Steven D'Aprano wrote: On Fri, 26 Oct 2007 19:19:46 +1000, Ben Finney wrote: 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* -- Shane Geiger IT Director National Council on Economic Education [EMAIL PROTECTED] | 402-438-8958 | http://www.ncee.net Leading the Campaign for Economic and Financial Literacy begin:vcard fn:Shane Geiger n:Geiger;Shane org:National Council on Economic Education (NCEE) adr:Suite 215;;201 N. 8th Street;Lincoln;NE;68508;United States email;internet:[EMAIL PROTECTED] title:IT Director tel;work:402-438-8958 url:http://www.ncee.net version:2.1 end:vcard -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
- 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... Matt -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
Matimus [EMAIL PROTECTED] writes: The trailing L [for 'long' literals] is going away in Python 3.0. Yes. On the other hand, we are gaining '0b' for binary literals, to go along with '0o' for octal and '0x' 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
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. - 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
Ben Finney wrote: Matimus [EMAIL PROTECTED] writes: The trailing L [for 'long' literals] is going away in Python 3.0. Yes. On the other hand, we are gaining '0b' for binary literals, to go along with '0o' for octal and '0x' for hexadecimal. 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 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
On Oct 26, 7:17 pm, J. Cliff Dyer [EMAIL PROTECTED] wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
Shane Geiger [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] a buggy hack (copying your top post style) D(123456789.123456789) Decimal(123456789.123) Or what there an unwritten :-)? | D = lambda x: decimal.Decimal(str(x)) | | D(3.2) | Decimal(3.2) -- http://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Decimal literals in Python.
On Fri, 26 Oct 2007 19:29:47 -0400, J. Cliff Dyer wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
