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

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

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.pytho n:

>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********@gma il.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******@nowhe re.invalidwrite s:

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