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

[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.c om/group/comp.lang.pytho n/msg/18123d100bba63b 8?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/18123d100bba63b 8?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.********@gma il.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.