Python 3.0 migration plans?

[Steve Holden]

I wondered if a straw poll could get some idea of readers' thoughts
about when they will be migrating to 3.0 on, so I used the new widget on
Blogger to add a poll for that.

I'd appreciate if if you would go to

http://holdenweb.blogspot.com/

and register your vote on your intended migration timescale.

Thanks!
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline

 

[Richard Jones]

I wondered if a straw poll could get some idea of readers' thoughts
about when they will be migrating to 3.0 on, so I used the new widget on
Blogger to add a poll for that.

I'd appreciate if if you would go to

http://holdenweb.blogspot.com/

and register your vote on your intended migration timescale.

I'll use the "no plans" response for my actual "no simple answer" real
response.


Richard

 

[James Stroud]

I wondered if a straw poll could get some idea of readers' thoughts
about when they will be migrating to 3.0 on, so I used the new widget on
Blogger to add a poll for that.

I'd appreciate if if you would go to

http://holdenweb.blogspot.com/

and register your vote on your intended migration timescale.

Thanks!

I'm going to abstain voting until 'public beta + about 1 year' is a choice.

James

 

[Steve Holden]

I'm going to abstain voting until 'public beta + about 1 year' is a choice.

> I'll use the "no plans" response for my actual "no simple answer" real
> response.
>
>

So what we need is a poll on what the questions should be. I *love* c.l.py.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline

 

[TheFlyingDutchman]

It seems that Python 3 is more significant for what it removes than
what it adds.

What are the additions that people find the most compelling?

 

[Paul Rubin]

So what we need is a poll on what the questions should be. I *love* c.l.py.

One of the offered answers to the current question should be "never".
That is, I'm hoping to skip 3.0 and switch directly to PyPy.

 

[Aahz]

I wondered if a straw poll could get some idea of readers' thoughts
about when they will be migrating to 3.0 on, so I used the new widget on
Blogger to add a poll for that.

I'd appreciate if if you would go to

http://holdenweb.blogspot.com/

and register your vote on your intended migration timescale.

Does this require JavaScript? If yes, count me as another "no" vote on
your survey. ;-)

 

[Ben Finney]

It seems that Python 3 is more significant for what it removes than
what it adds.

That's certainly the focus of an explicitly backward-incompatible
upgrade, yes.

What are the additions that people find the most compelling?

Most of the additions that will go into 2.6 are doing so because
they'll appear in 3.0. That's a benefit: anything from 3.0 that makes
sense to add to 2.6 will go in; the rest of 3.0's changes are mostly
backwards-incompatible (i.e. removals and conflicting changes).

I find the following compelling:

- 'str' becomes Unicode type, 'int' becomes unified-int-and-long
type <URL:http://www.python.org/dev/peps/pep-3100/>

- Consistent, unambiguous integer literal syntax
<URL:http://www.python.org/dev/peps/pep-3127/> and the 'bytes'
type for non-text strings
<URL:http://www.python.org/dev/peps/pep-3112/>

- Default source encoding is UTF-8
<URL:http://www.python.org/dev/peps/pep-3120/> and support for
non-ASCII identifiers
<URL:http://www.python.org/dev/peps/pep-3131/>

- Reorganisation of the standard library for consistency
<URL:http://www.python.org/dev/peps/pep-3108/>

- Renaming raw_input to input, so 'input()' does the obvious thing
<URL:http://www.python.org/dev/peps/pep-3111/>

- Clarification of 'raise' and 'except' semantics
<URL:http://www.python.org/dev/peps/pep-3109/>,
<URL:http://www.python.org/dev/peps/pep-3110/>

- Abstract Base Classes
<URL:http://www.python.org/dev/peps/pep-3119/>

- everything that's being added to 2.6

 

[Steve Holden]

One of the offered answers to the current question should be "never".
That is, I'm hoping to skip 3.0 and switch directly to PyPy.

Well, "No current plans" certainly includes "never", even though it
might not be quite assertive enough for your tastes.

I hope that PyPy will eventually become good enough to overtake CPython
as the preferred implementation - it certainly seems to have much
greater optimization possibilities than CPython.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline

 

[TheFlyingDutchman]

- Abstract Base Classes
<URL:http://www.python.org/dev/peps/pep-3119/>

I like how someone here characterized decorators - those silly @
things. They remind me of Perl. Not adding keywords for abstract and
static is like Perl not adding a keyword for class. But I know all
such additions are vigorously defended by the most ardent users of
each language.

 

[Eduardo O. Padoan]

It seems that Python 3 is more significant for what it removes than
what it adds.

What are the additions that people find the most compelling?

- dict.items(), .values() and .keys() returns "dict views", and the
..iter*() removal
http://www.python.org/dev/peps/pep-3106/
- the new super()
http://www.python.org/dev/peps/pep-3135/

etc...

 

[John Nagle]

It seems that Python 3 is more significant for what it removes than
what it adds.

What are the additions that people find the most compelling?

I'd rather see Python 2.5 finished, so it just works.
All the major third-party libraries working and available with
working builds for all major platforms. That working set
of components in all the major distros used on servers.
The major hosting companies having that up and running on
their servers. Windows installers that install a collection
of components that all play well together.

That's what I mean by "working".

John Nagle

 

[Diez B. Roggisch]

I like how someone here characterized decorators - those silly @
things. They remind me of Perl. Not adding keywords for abstract and
static is like Perl not adding a keyword for class. But I know all
such additions are vigorously defended by the most ardent users of
each language.

The fact that you compare and criticise the simple annotations like
static or abstract with the much more powerful decorator concept shows
that, despite being the maintainer of a
soon-to-be-ruling-the-python-world Python 3 fork, lack understanding of
even the most basic language features. Which isn't exactly news.[1]

The decorator syntax was vigorously discussed. I personally don't mind
the @-based syntax, but could live with anything else - because I like
and often need the feature for it's capabilities.

Maybe you should start using python more and _then_ start discussions
about it's features, when you have good grounds and can provide viable
alternatives? But I guess that's a wish that won't be granted....

Diez


[1]
http://groups.google.de/group/comp....694148fc52c/28c9ee2e1c64cdde#28c9ee2e1c64cdde

 

[TheFlyingDutchman]

The fact that you compare and criticise the simple annotations like
static or abstract with the much more powerful decorator concept shows
that, despite being the maintainer of a
soon-to-be-ruling-the-python-world Python 3 fork, lack understanding of
even the most basic language features. Which isn't exactly news.[1]

Don't you mean "lack appreciation for the non-basic language
features"? static, class and abstract
are basic language features that I appreciate. "decorators" have been
in Python for only a small part of its existence, they aren't in the
vast majority of languages (if any other language even has them) which
means people write all kinds of software without them. Or rather, most
of the software ever written didn't use decorators. Doesn't sound
basic at all.

Maybe you should start using python more and _then_ start discussions
about it's features, when you have good grounds and can provide viable
alternatives? But I guess that's a wish that won't be granted....

static and abstract keywords would seem to be very viable
alternatives. Viable enough that several language designers used them.

 

[egbert]

So what we need is a poll on what the questions should be. I *love* c.l.py.

I will switch as soon as Debian has all the tools for an easy conversion
available, and Python 3000 has reached the default release status.
e

 

[Diez B. Roggisch]

The fact that you compare and criticise the simple annotations like
static or abstract with the much more powerful decorator concept shows
that, despite being the maintainer of a
soon-to-be-ruling-the-python-world Python 3 fork, lack understanding of
even the most basic language features. Which isn't exactly news.[1]

Don't you mean "lack appreciation for the non-basic language
features"? static, class and abstract
are basic language features that I appreciate. "decorators" have been
in Python for only a small part of its existence, they aren't in the
vast majority of languages (if any other language even has them) which
means people write all kinds of software without them. Or rather, most
of the software ever written didn't use decorators. Doesn't sound
basic at all.

People did write all kinds of software in Assembler. And large portions of
these people complained about every feature that some new language
introduced.

All serious languages are turing-complete. So can we put away with this
non-sense argument right away, please?

static and abstract keywords would seem to be very viable
alternatives. Viable enough that several language designers used them.

As I said - you don't get it. The decorators (in conjunction with the
descriptor protocol - ever heard of that?) are very powerful yet lead as an
artifact to simple, declarative implementations of features you like,
namely static and abstract methods.

And as you seem being so reluctant to let new features creep into the
language, the introduction of new keywords you like?

Besides, those 'several language designers' seem to think that the
introduction of keywords isn't enough, but a general purpose annotation
scheme seems to be viable - or how do you explain e.g. JDK 1.5 Annotations?

Diez

 

[Erik Jones]

So what we need is a poll on what the questions should be. I *love*
c.l.py.

Does professional vs. personal use matter here? What if I plan to
switch in the morning or at midnight on the first solstice after the
second alpha release? Is Mercury or Venus in retrograde? These
things matter...

Erik Jones

Software Developer | Emma®
(e-mail address removed)
800.595.4401 or 615.292.5888
615.292.0777 (fax)

Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com

 

[Alex Martelli]

I'd rather see Python 2.5 finished, so it just works.

And I'd rather see peace on Earth and goodwill among men than _either_
Python 3 or your cherished "finished" 2.5 -- the comparison and implied
tradeoff make about as much sense as yours.

All the major third-party libraries working and available with
working builds for all major platforms. That working set
of components in all the major distros used on servers.
The major hosting companies having that up and running on
their servers. Windows installers that install a collection
of components that all play well together.

That's what I mean by "working".

I.e., you mean tasks appropriate for maintainers of all the major
third-party libraries, distros, and hosting companies -- great, go
convince them, or go convince all warmongers on Earth to make peace if
you want an even harder tasks with even better potential impact on the
state of the world, then.


Alex

 

[TheFlyingDutchman]

The fact that you compare and criticise the simple annotations like
static or abstract with the much more powerful decorator concept shows
that, despite being the maintainer of a
soon-to-be-ruling-the-python-world Python 3 fork, lack understanding of
even the most basic language features. Which isn't exactly news.[1]

Don't you mean "lack appreciation for the non-basic language
features"? static, class and abstract
are basic language features that I appreciate. "decorators" have been
in Python for only a small part of its existence, they aren't in the
vast majority of languages (if any other language even has them) which
means people write all kinds of software without them. Or rather, most
of the software ever written didn't use decorators. Doesn't sound
basic at all.

People did write all kinds of software in Assembler. And large portions of
these people complained about every feature that some new language
introduced.

All serious languages are turing-complete. So can we put away with this
non-sense argument right away, please?

You said it was a most basic language feature. I still haven't heard
anything that leads me to believe that statement is correct. What
languages implemented decorators as a most basic language feature?
Python didn't have them for over a decade so it doesn't qualify.

As I said - you don't get it. The decorators (in conjunction with the
descriptor protocol - ever heard of that?) are very powerful yet lead as an
artifact to simple, declarative implementations of features you like,
namely static and abstract methods.

You said I had to provide a viable alternative. I did that. I haven't
heard of the descriptor protocol.

One of the problems with "getting" decorators is that they are not in
older books at all and newer books like Beginning Python from Novice
to Professional (c) 2005 Magnus Lie Hetland, that I own, devote almost
nothing to them. Out of 640 pages they are only mentioned
in one paragraph that is in a section titled "Static Methods and Class
Methods",(and followed by a class example with @staticmethod and
@classmethod).

So it seems like Magnus Lie Hetland didn't think they were very
important and he had Professional in his book title.

And as you seem being so reluctant to let new features creep into the
language, the introduction of new keywords you like?

I'm not against additions on principle.

Besides, those 'several language designers' seem to think that the
introduction of keywords isn't enough, but a general purpose annotation
scheme seems to be viable - or how do you explain e.g. JDK 1.5 Annotations?

I certainly wouldn't call them a basic language feature. Java 1.0 came
out in January 1996, Java 1.5 in September 2004. It doesn't appear
that the language designer of Java, James Gosling, is still at the
wheel or BDFL. But yes, Java is showing signs of "complexity creep".
You'll be happy to know that I really dislike the C++ template syntax
and Java has decided to add something similar.

 

[Paul Rubin]

All serious languages are turing-complete. So can we put away with this
non-sense argument right away, please?

Actually the so called "total" languages aren't Turing-complete. I
think Coq is an example: every Coq function must return a value. So
Coq doesn't have any way to write an infinite loop, because that would
allow writing functions that fail to return. So there is no halting
program in Coq (every Coq program halts), which means Coq is not
Turing-complete. That allows Coq to generate code about which it can
make all kinds of guarantees that most languages can't (not simply
that the programs halt but that they actually fulfill their
computational specifications), so it's being used in various
high-assurance applications, though usually to write just the most
critical parts of a program, not the entire program. Of course it's a
matter of semantics but in some meaningful ways, I'd say Coq is a more
serious language than Python.

Here is a famous early paper explaining why Turing-completeness isn't
all it's cracked up to be:

http://sblp2004.ic.uff.br/papers/turner.pdf

This paper shows some of the advantages of the total approach.