Proposal: Decimal literals in Python.

[Marc 'BlackJack' Rintsch]

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

 

[Dennis Lee Bieber]

Even clearer is not to allow octal literals Is there *any* use for
them?

Useful for writing the command set of the 8080 processor family <G>

Something like the old
mov src, dest
instruction was represented as

01 sss ddd (in binary), or 1SD (octal) were S and D ran the range
of 0 - 7 (registers A, B/C, D/E, H/L, M[emory], as I recall)
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[Neil Cerutti]

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.

 

[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]

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...

[snip]
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.

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]

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...

 

[Gabriel Genellina]

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.

 

[MRAB]

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