Py 2.6 changes

[Steven D'Aprano]

It seems to me that the right choice for thousands seperator is the
apostrophe.

You mean the character already used as a string delimiter?

 

[Alexander Schmolck]

You mean the character already used as a string delimiter?

Yup. No ambiguity or problem here; indeed unlike space seperation or '_' it
would work straighforwardly as a syntax extension in pretty much any
programming language I can think as well as end-user output (I think that
writing e.g. 1'000'000 on a website would be perfectly acceptable; unlike
1_000_000).

'as

 

[Alexander Schmolck]

A problem is that '1234' in Python is a string, so using ' in numbers
looks a bit dangerous to me (and my editor will color those numbers as
alternated strings, I think).

Yeah, editors, especially those with crummy syntax highlighting (like emacs)
might get it wrong. This should be easy enough to fix though. Indeed unlike
raw and tripplequoted strings which were adopted without major hitches this
new syntax wouldn't have any bearing on what's a valid string.

'as

 

[Fredrik Lundh]

Yeah, editors, especially those with crummy syntax highlighting (like emacs)
might get it wrong. This should be easy enough to fix though.

instead of forcing all editor developers to change their Python modes to
allow you to use a crude emulation of a typographic convention in your
Python source code, why not ask a few of them to implement the correct
typographic convention (thin spaces) in their Python mode?

</F>

 

[Alan G Isaac]

+1 on such a capability.

-1 on underscore as the separator.


When you proposed this last year, the counter-proposal was made
<URL:http://groups.google.com/group/comp.lang.python/msg/18123d100bba63b8?dmode=source>
to instead use white space for the separator, exactly as one can now
do with string literals.

Yuck.
Repeating a mistake means two mistakes.

But I would hate less the use of nobreak spaces,
since any decent editor can reveal them.

Alan Isaac

 

[Steven D'Aprano]

Yuck.
Repeating a mistake means two mistakes.

A lot of us don't think that white space between string literals was a
mistake. A lot of us consider it a desirable feature.

But I would hate less the use of nobreak spaces, since any decent editor
can reveal them.

How do you type a nobreak space?

It's also probably a bad idea for Python the language to depend on
developers using "a decent editor", since many people disagree on what a
decent editor is, and many other people don't have access to whatever you
consider "a decent editor".

 

[Tom Harris]

It's amazing that after over half a century of computing we still can't denote
numbers with more than 4 digits readably in the vast majority of contexts.

I agree. So did Forth's early designers. That is why Forth's number
parser considers a word that starts with a number and has embedded
punctuation to be a 32 bit integer, and simply ignores the
punctuation. I haven't used Forth in years, but it seems a neat
solution to the problem of decoding a long string of numbers: let the
user put in whatever they want, the parser ignores it. I usually used
a comma (with no surrounding whitespace of course), but it was your
choice. You could also do this in whatever base you were working in,
so you could punctuate a 32 bit hex number to correspond to the bit
fields inside it. Of course not applicable to Python.

 

[glen stark]

I agree. So did Forth's early designers. That is why Forth's number
parser considers a word that starts with a number and has embedded
punctuation to be a 32 bit integer, and simply ignores the punctuation.
I haven't used Forth in years, but it seems a neat solution to the
problem of decoding a long string of numbers: let the user put in
whatever they want, the parser ignores it. I usually used a comma (with
no surrounding whitespace of course), but it was your choice. You could
also do this in whatever base you were working in, so you could
punctuate a 32 bit hex number to correspond to the bit fields inside it.
Of course not applicable to Python.

That sounds like a great idea, except I'd specify non-period (.)
punctuation, so it would go for floating points as well.

Is there a language design guru who can say why inputs like 123,456.00
couldn't be handles as above? the only problem I can see is an abiguity
in argument lists (e.g. mult(2,4) ) which could be handled by the
inclusion of whitespace.