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, bearophileH...@ lycos.com 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, bearophileH...@ lycos.com 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.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.

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