Py 2.6 changes

[bearophileHUGS]

I have just re-read the list of changes in Python 2.6, it's huge,
there are tons of changes and improvements, I'm really impressed:
http://docs.python.org/dev/whatsnew/2.6.html

I'll need many days to learn all those changes! I can see it fixes
several of the missing things/problems I have found in Python in the
past, like the lack of information regarding the floating point it
uses, etc.
I have seen that many (smart) updates are from Hettinger.

You can see a language gets better when you can remove often-used
commodity functions/classes from your own 'bag of tricks' :-) (Like
the permutations() function, etc).

>Python now must be compiled with C89 compilers (after 19 years!). This means that the Python source tree has dropped its own implementations of memmove and strerror, which are in the C89 standard library.<

I presume it's better for me to not hold my breath while I wait
CPython to be written in C99 :-)
Now math has factorial:
http://docs.python.org/dev/library/m...math.factorial
Seen how reduce() is removed from Python 3 (I know it's in itertools),
and seeing that for me to write a productory() function was the first
usage I have had for reduce, years ago, I think the math module can
gain a productory() function too.
For Python 2.7/3.1 I'd now like to write a PEP regarding the
underscores into the number literals, like: 0b_0101_1111, 268_435_456
etc. I use such underscores all the time in the D language, and I
think they can be a tiny but significant improvement for Python (and
underscore is much better than just a space, because the underscore
helps the person that reads the code to understand that's a single
number).

Bye,
bearophile

[Christian Heimes]

be************@lycos.com wrote:

I presume it's better for me to not hold my breath while I wait
CPython to be written in C99 :-)

First you have to convince Microsoft to release C99 compiler ... good luck!

Christian

[Alan G Isaac]

be************@lycos.com wrote:

Now math has factorial:
http://docs.python.org/dev/library/m...math.factorial

That's rather underdocumented.
Does it really attempt exact calculation
for arbitrary integers?? Is there any
way to request a nice fast approximation
for large integers (e.g., with Gosper's
modification of Stirling's formula)?
Alan Isaac

[Steven D'Aprano]

On Mon, 01 Sep 2008 12:15:53 -0700, bearophileHUGS wrote:

Now math has factorial:
http://docs.python.org/dev/library/m...math.factorial Seen how
reduce() is removed from Python 3 (I know it's in itertools), and seeing
that for me to write a productory() function was the first usage I have
had for reduce, years ago, I think the math module can gain a
productory() function too.

productory() -- I don't know that function, and googling mostly comes up
with retail product searches. Do you mean product(), the analog of sum()
except that it multiplies instead of adds? Or perhaps you mean some sort
of generalization of factorial().

--
Steven

[bearophileHUGS]

Steven D'Aprano:

productory() -- I don't know that function, and googling mostly comes up
with retail product searches. Do you mean product(),

Darn my English, you are right, sorry, I meant a product() of
course :-)

Bye,
bearophile

[Mensanator]

On Sep 1, 6:55�pm, [e-mail] wrote:

Steven D'Aprano:

productory() -- I don't know that function, and googling mostly comes up
with retail product searches. Do you mean product(),

Darn my English, you are right, sorry, I meant a product() of
course :-)

But the name product() has already been taken by itertools to
mean Cartesian Product.

>
Bye,
bearophile

[Mensanator]

On Sep 1, 2:15�pm, [e-mail] wrote:

I have just re-read the list of changes in Python 2.6, it's huge,
there are tons of changes and improvements, I'm really impressed:http://docs.python.org/dev/whatsnew/2.6.html

I'll need many days to learn all those changes! I can see it fixes
several of the missing things/problems I have found in Python in the
past, like the lack of information regarding the floating point it
uses, etc.
I have seen that many (smart) updates are from Hettinger.

You can see a language gets better when you can remove often-used
commodity functions/classes from your own 'bag of tricks' :-) (Like
the permutations() function,

Don't get rid of the whole bag, they didn't implement Combinations
with Replcaement.

etc).

Python now must be compiled with C89 compilers (after 19 years!). This means that the Python source tree has dropped its own implementations of memmove and strerror, which are in the C89 standard library.<

I presume it's better for me to not hold my breath while I wait
CPython to be written in C99 :-)

Now math has factorial:http://docs.python.org/dev/library/m...math.factorial
Seen how reduce() is removed from Python 3 (I know it's in itertools),
and seeing that for me to write a productory() function was the first
usage I have had for reduce, years ago, I think the math module can
gain a productory() function too.

For Python 2.7/3.1 I'd now like to write a PEP regarding the
underscores into the number literals, like: 0b_0101_1111, 268_435_456
etc. I use such underscores all the time in the D language, and I
think they can be a tiny but significant improvement for Python (and
underscore is much better than just a space, because the underscore
helps the person that reads the code to understand that's a single
number).

Bye,
bearophile

[Ben Finney]

be************@lycos.com writes:

For Python 2.7/3.1 I'd now like to write a PEP regarding the
underscores into the number literals, like: 0b_0101_1111, 268_435_456
etc.

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

I don't see any good reason (other than your familiarity with the D
language) to use underscores for this purpose, and much more reason
(readability, consistency, fewer arbitrary differences in syntax,
perhaps simpler implementation) to use whitespace just as with string
literals.

--
\ “When in doubt tell the truth. It will confound your enemies |
`\ and astound your friends.� —Mark Twain, _Following the Equator_ |
_o__) |
Ben Finney

[bearophileHUGS]

Ben Finney:

I don't see any good reason (other than your familiarity with the D
language) to use underscores for this purpose, and much more reason
(readability, consistency, fewer arbitrary differences in syntax,
perhaps simpler implementation) to use whitespace just as with string
literals.

It's not just my familiarity, Ada language too uses underscore for
that purpose, I think, so there's a precedent, and Ada is a language
designed to always minimize programming errors, simple code mistakes
too.

And another thing to consider is that they so far have given me zero
problems...

Consider:

a = 125 125 125

a = 125, 125, 125

a = 125_125_125

For me the gestalt of the first line looks too much like the second
one, that is three separated things (note that this is relative to the
font you use, I am using a really good free font, Inconsolata, the
very best I have found to program (better than Consolas) that
separates things well). While in the third case the _ helps glue the
parts, creating a single gestalt to my eyes.

Note that it's not just a matter of font and familiarity, it's also a
matter of brains. Your brain may be different from mine, so it may be
possible that what's better for you isn't better for me. So in such
situation a popular voting may be the only way to choose. But for me
having spaces to split number literals in parts is _worse_ than not
having any way at all to split them. So I'm strong opposed to your
suggestion, so I may not even propose the PEP if lot of people agrees
with your tastes.

Bye,
bearophile

[Ben Finney]

be************@lycos.com writes:

Ben Finney:

I don't see any good reason (other than your familiarity with the
D language) to use underscores for this purpose, and much more
reason (readability, consistency, fewer arbitrary differences in
syntax, perhaps simpler implementation) to use whitespace just as
with string literals.

It's not just my familiarity, Ada language too uses underscore for
that purpose, I think, so there's a precedent, and Ada is a language
designed to always minimize programming errors, simple code mistakes
too.

I would argue that the precedent, already within Python, for using a
space to separate pieces of a string literal, is more important than
precedents from other programming languages.

Consider:

a = 125 125 125

a = 125, 125, 125

a = 125_125_125

For me the gestalt of the first line looks too much like the second
one, that is three separated things

This is no more the case than for literal strings:

a = "spam" "eggs" "ham"

a = "spam", "eggs", "ham"

Yet this is already a valid way in Python to specify, respectively, a
single literal string and a literal tuple of strings.

While in the third case the _ helps glue the parts, creating a
single gestalt to my eyes.

To my eyes, it's needlessly hard to read, and looks too similar to an
identifier, not a literal. On the other hand, the spaces version is
easy to see as analogous to the same syntax rules that already exist
for strings.

Note that it's not just a matter of font and familiarity, it's also a
matter of brains. Your brain may be different from mine, so it may be
possible that what's better for you isn't better for me. So in such
situation a popular voting may be the only way to choose. But for me
having spaces to split number literals in parts is _worse_ than not
having any way at all to split them. So I'm strong opposed to your
suggestion, so I may not even propose the PEP if lot of people agrees
with your tastes.

Thanks for making your position clear.

--
\ “The WWW is exciting because Microsoft doesn't own it, and |
`\ therefore, there's a tremendous amount of innovation |
_o__) happening.� —Steve Jobs |
Ben Finney

[Fredrik Lundh]

Ben Finney wrote:

I would argue that the precedent, already within Python, for using a
space to separate pieces of a string literal, is more important than
precedents from other programming languages.

that precedent also tells us that the whitespace approach is a common
source of errors. taking an approach that's known to be error-prone and
applying it to more cases isn't necessarily a great way to build a
better language.

</F>

[Steven D'Aprano]

On Tue, 02 Sep 2008 11:13:27 +1000, Ben Finney wrote:

be************@lycos.com writes:

>For Python 2.7/3.1 I'd now like to write a PEP regarding the
underscores into the number literals, like: 0b_0101_1111, 268_435_456
etc.

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

I don't see any good reason (other than your familiarity with the D
language) to use underscores for this purpose, and much more reason
(readability, consistency, fewer arbitrary differences in syntax,
perhaps simpler implementation) to use whitespace just as with string
literals.

At the risk of bike-shedding, I think that allowing arbitrary whitespace
between string literals is fine, because it aids readability to write
this:

do_something(
"first part of the string"
"another part of the string"
"yet more of the string"
"and a bit more"
"and so on..."
)

but I'm not sure that it is desirable to allow this:

do_something(
142325
93.8012
7113
)
-1/2 on arbitrary whitespace, +1/2 on a single space, and +0 on
underscores. If semi-colons didn't already have a use, I'd propose using
them to break up numeric literals:

14;232;593.801;271;13

--
Steven

[Steven D'Aprano]

On Mon, 01 Sep 2008 22:11:13 -0700, Dennis Lee Bieber wrote:

On Tue, 02 Sep 2008 13:51:16 +1000, Ben Finney
<bi****************@benfinney.id.audeclaimed the following in
comp.lang.python:

>This is no more the case than for literal strings:

a = "spam" "eggs" "ham"

a = "spam", "eggs", "ham"

But... Literal string still have the " (or ') delimiters around the
components. Such does not exist for you example with integers.

Consider

a = "spam, eggs", "ham"
vs
a = "spam, eggs" "ham"

Quite frankly, I think that it's a stretch to say that leaving out a
tuple delimiter is a problem with whitespace inside numeric literals.
That's hardly unique to whitespace:

atuple = 5,6,7,8
vs
atuple = 5,67,8

Look Ma, no whitespace!
But even if allowing whitespace inside numeric literals did create a new
avenue for errors which never existed before, it is a mistake to only
consider the downside without the upside. In my opinion, that would be
rather like declaring that the syntax for attribute access is a mistake
because you might do this:

x = MyClass()
xy = 4

instead of this:

x = MyClass()
x.y = 4

At some point the programmer has to take responsibility for typos instead
of blaming the syntax of the language. I agree that we should avoid
syntax that *encourages* typos, but I don't believe that allowing
whitespace inside numeric literals does that.

--
Steven

[Nick Craig-Wood]

be************@lycos.com <be************@lycos.comwrote:

Ben Finney:

I don't see any good reason (other than your familiarity with the D
language) to use underscores for this purpose, and much more reason
(readability, consistency, fewer arbitrary differences in syntax,
perhaps simpler implementation) to use whitespace just as with string
literals.

It's not just my familiarity, Ada language too uses underscore for
that purpose, I think, so there's a precedent, and Ada is a language
designed to always minimize programming errors, simple code mistakes
too.

And perl also

*ducks*
--
Nick Craig-Wood <ni**@craig-wood.com-- http://www.craig-wood.com/nick

[Peter Pearson]

On 02 Sep 2008 06:10:51 GMT, Steven D'Aprano wrote:

At the risk of bike-shedding,

[snip]

(startled noises) It is a delight to find a reference to
that half-century-old essay (High Finance) by the wonderful
C. Northcote Parkinson, but how many readers will catch the
allusion?

--
To email me, substitute nowhere->spamcop, invalid->net.

[Alan G Isaac]

On 02 Sep 2008 06:10:51 GMT, Steven D'Aprano wrote:

>At the risk of bike-shedding,

[snip]

Peter Pearson wrote:

(startled noises) It is a delight to find a reference to
that half-century-old essay (High Finance) by the wonderful
C. Northcote Parkinson, but how many readers will catch the
allusion?

It is pretty common geek speek:
http://en.wikipedia.org/wiki/Color_of_the_bikeshed

Cheers,
Alan Isaac

[Fredrik Lundh]

Peter Pearson wrote:

(startled noises) It is a delight to find a reference to
that half-century-old essay (High Finance) by the wonderful
C. Northcote Parkinson, but how many readers will catch the
allusion?

anyone that's been involved in open source on the development side for
more than, say, ten minutes.

http://www.bikeshed.com/

</F>

[Peter Pearson]

On Tue, 02 Sep 2008 17:18:58 GMT, Alan G Isaac <al********@gmail.comwrote:

>On 02 Sep 2008 06:10:51 GMT, Steven D'Aprano wrote:

>>At the risk of bike-shedding,

[snip]

Peter Pearson wrote:

>(startled noises) It is a delight to find a reference to
that half-century-old essay (High Finance) by the wonderful
C. Northcote Parkinson, but how many readers will catch the
allusion?

It is pretty common geek speek:
http://en.wikipedia.org/wiki/Color_of_the_bikeshed

Ah, the wondrous Wiki.

I thought I was a geek, for the past 40 years; but maybe its
time for me to be demoted to the dad on whose bookshelf
you'll find that old book.

--
To email me, substitute nowhere->spamcop, invalid->net.

[Christian Heimes]

Fredrik Lundh wrote:

Peter Pearson wrote:

>(startled noises) It is a delight to find a reference to
that half-century-old essay (High Finance) by the wonderful
C. Northcote Parkinson, but how many readers will catch the
allusion?

anyone that's been involved in open source on the development side for
more than, say, ten minutes.

Indeed! Thus speaks the experienced developer -- effbot :)

On some mailing lists the bikeshed issue comes hand in hand with the
Dunning-Kruger-effect. [1] *sigh*

Christian

[1] http://en.wikipedia.org/wiki/Dunning-Kruger_effect

[Ben Finney]

Peter Pearson <pp******@nowhere.invalidwrites:

I thought I was a geek, for the past 40 years; but maybe its time
for me to be demoted to the dad on whose bookshelf you'll find that
old book.

Once a geek, always a geek. You either stay sharp or get sloppy, but
you never stop being a geek :-)

--
\ “The best ad-libs are rehearsed.� —Graham Kennedy |
`\ |
_o__) |
Ben Finney

[Patrick Maupin]

On Sep 2, 6:35*am, Nick Craig-Wood <[e-mail]:

[e-mail] <[e-mail]:

*It's not just my familiarity, Ada language too uses underscore for
*that purpose, I think, so there's a precedent, and Ada is a language
*designed to always minimize programming errors, simple code mistakes
*too.

And perl also

Add Verilog to that list. The ability to embed underscores in numeric
literals, which the parser discards, is sometimes very useful in
hardware description, especially when dealing with binary bit vectors
which can sometimes be 32 bits or more long.

Underscores are great. I have actually wished for this in Python
myself, for those cases when I am doing binary. Spaces, not so much
-- as others have pointed out, this is error prone, partly because
spaces are "light weight" visually, and partly because the parser does
not currently distinguish between different kinds of whitespace. I
can't count how often I've forgotten a trailing comma on a line of
items.

To the complaints about the underscores getting in the way -- if the
number is short, you don't need either underscores or spaces, and if
the number is long, it's much easier to count underscores to find your
position than it is to count spaces. Also, on long numbers (where
this is most useful), the issue with mistaking a number for an
identifier is much less likely to happen in real life.

I think the issue of location sensitivity has already been flogged
enough, but I will give it one last hit -- long numbers, where this is
most useful, are often encountered in domain-specific mini languages,
where the number of digits in each portion of a number might have some
specific meaning. If the proposal were restricted to "once every 3
digits" or something similar, it would not be worth doing at all.

+1 on the original proposal.

Pat

[Chris Rebert]

On Mon, Sep 1, 2008 at 6:02 PM, Mensanator <me********@aol.comwrote:

On Sep 1, 6:55�pm, [e-mail] wrote:

>Steven D'Aprano:

productory() -- I don't know that function, and googling mostly comes up
with retail product searches. Do you mean product(),

Darn my English, you are right, sorry, I meant a product() of
course :-)

But the name product() has already been taken by itertools to
mean Cartesian Product.

We have this thing called "namespacing" and it's one honking great
idea that's perfect for these situations.

- Chris

>

>>
Bye,
bearophile

--
http://mail.python.org/mailman/listinfo/python-list

--
Follow the path of the Iguana...
http://rebertia.com

[Grant Edwards]

On 2008-09-02, Christian Heimes <li***@cheimes.dewrote:

Fredrik Lundh wrote:

>Peter Pearson wrote:

>>(startled noises) It is a delight to find a reference to
that half-century-old essay (High Finance) by the wonderful
C. Northcote Parkinson, but how many readers will catch the
allusion?

anyone that's been involved in open source on the development side for
more than, say, ten minutes.

Indeed! Thus speaks the experienced developer -- effbot :)

On some mailing lists the bikeshed issue comes hand in hand with the
Dunning-Kruger-effect. [1] *sigh*

Christian

[1] http://en.wikipedia.org/wiki/Dunning-Kruger_effect

That paper is really very interesting -- it explains a lot of
what one sees in corporate life.

--
Grant Edwards grante Yow! I just remembered
at something about a TOAD!
visi.com

[Cliff]

On Sep 2, 12:34*am, Fredrik Lundh <[e-mail]:

Ben Finney wrote:

I would argue that the precedent, already within Python, for using a
space to separate pieces of a string literal, is more important than
precedents from other programming languages.

that precedent also tells us that the whitespace approach is a common
source of errors. *taking an approach that's known to be error-prone and
applying it to more cases isn't necessarily a great way to build a
better language.

</F>

Also a source of mental complexity. The two proposals (whitespace vs.
underscores) are not just a question of what character to use, it's a
question of whether to create an integer (and possibly other numeric
type) literal that allows delimiters, or to allow separate literals to
be concatenated. In the second case, which of the following would be
proper syntax?

0b1001 0110
0b1001 0b0110

In the first case, the second literal, on its own, is an octal
literal, but we expect it to behave as a binary literal. In the
second case, we have more consistency with string literals (with which
you can do this: "abc" r'''\def''') but we lose the clarity of using
the concatenation to make the whole number more readable.

On the other hand, 0b1001_0110 has one clear meaning. It is one
literal that stands alone. I'm not super thrilled about the look (or
keyboard location) of the underscore, but it's better than anything
else that is available, and works within a single numeric literal.
For this reason I am +0 on the underscore and -1 on the space.

[Alexander Schmolck]

Ben Finney <bi****************@benfinney.id.auwrites:

be************@lycos.com writes:

>For Python 2.7/3.1 I'd now like to write a PEP regarding the
underscores into the number literals, like: 0b_0101_1111, 268_435_456
etc.

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

I don't see any good reason (other than your familiarity with the D
language) to use underscores for this purpose, and much more reason
(readability, consistency, fewer arbitrary differences in syntax,
perhaps simpler implementation) to use whitespace just as with string
literals.

It seems to me that the right choice for thousands seperator is the
apostrophe. It doesn't suffer from brittleness and editing problems as
whitespace does (e.g. consider filling and auto-line breaking). It is already
used in some locales for this function but never for the decimal point (so no
ambiguity, unlike '.' and ','). It also reads well, unlike the underscore
which is visually obstrusive and ugly (compare 123'456'890 to 123_456_789).

Having said that, I'd still have 123_456_789 over 123456789 any day.

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.

'as

[bearophileHUGS]

Alexander Schmolck:

It also reads well, unlike the underscore
which is visually obstrusive and ugly (compare 123'456'890 to 123_456_789).

I like that enough, in my language that symbol is indeed the standard
one to separate thousands, in large numbers. It's light, looks
natural, and as you say it's visually unobstrusive.

But in my language ' means just thousands, so it's used only in blocks
of 3 digits, not in blocks of any length, so something like this looks
a bit strange/wrong:

0b'0000'0000

While the underscore has no meaning, so it can be used in both
situations.

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

Note that for other people the ' denotes feet, while in my language it
denotes minutes, while I think the underscore has no meaning.

So for me the underscore is better :-)

Bye,
bearophile

[Steven D'Aprano]

On Thu, 04 Sep 2008 01:22:22 +0100, Alexander Schmolck wrote:

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

You mean the character already used as a string delimiter?

--
Steven

[Alexander Schmolck]

Steven D'Aprano <st***@REMOVE-THIS-cybersource.com.auwrites:

On Thu, 04 Sep 2008 01:22:22 +0100, Alexander Schmolck wrote:

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

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]

be************@lycos.com writes:

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]

Alexander Schmolck wrote:

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

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]

be************@lycos.com writes:

>

>For Python 2.7/3.1 I'd now like to write a PEP regarding the
underscores into the number literals, like: 0b_0101_1111, 268_435_456
etc.

+1 on such a capability.

-1 on underscore as the separator.

On 9/1/2008 9:13 PM Ben Finney apparently wrote:

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]

On Sat, 06 Sep 2008 23:30:03 +0000, Alan G Isaac wrote:

>be************@lycos.com writes:

>>For Python 2.7/3.1 I'd now like to write a PEP regarding the
underscores into the number literals, like: 0b_0101_1111, 268_435_456
etc.

+1 on such a capability.

-1 on underscore as the separator.

On 9/1/2008 9:13 PM Ben Finney apparently wrote:

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

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

--
Steven

[Tom Harris]

On Thu, Sep 4, 2008 at 10:22 AM, Alexander Schmolck
<a.********@gmail.comwrote:

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

--

Tom Harris <celephicus(AT)gmail(DOT)com>

[glen stark]

On Tue, 09 Sep 2008 08:32:29 +1000, Tom Harris wrote:

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.