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 [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline

[Richard Jones]

Steve Holden wrote:

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]

Steve Holden wrote:

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]

James Stroud wrote:

Steve Holden wrote:

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

Richard Jones wrote:

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 [phone] [phone]
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]

Steve Holden <st***@holdenweb.comwrites:

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]

In article <ma**************************************@python.o rg>,
Steve Holden <st***@holdenweb.comwrote:

>
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. ;-)
--
Aahz (aa**@pythoncraft.com) <* http://www.pythoncraft.com/

The best way to get information on Usenet is not to ask a question, but
to post the wrong information.

[Ben Finney]

TheFlyingDutchman <zz******@aol.comwrites:

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

--
\ "I bought a self learning record to learn Spanish. I turned it |
`\ on and went to sleep; the record got stuck. The next day I |
_o__) could only stutter in Spanish." -- Steven Wright |
Ben Finney

[Steve Holden]

Paul Rubin wrote:

Steve Holden <st***@holdenweb.comwrites:

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

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 [phone] [phone]
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]

On 9/27/07, TheFlyingDutchman <zz******@aol.comwrote:

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

--
http://www.advogato.org/person/eopadoan/
Bookmarks: http://del.icio.us/edcrypt

[John Nagle]

TheFlyingDutchman wrote:

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]

TheFlyingDutchman schrieb:

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

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

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

[Diez B. Roggisch]

TheFlyingDutchman wrote:

>

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

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

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

[egbert]

On Thu, Sep 27, 2007 at 09:17:30PM -0400, Steve Holden wrote:

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
--
Egbert Bouwman - Keizersgracht 197 II - 1016 DS Amsterdam - 020 6257991
================================================== ======================

[Erik Jones]

On Sep 27, 2007, at 8:17 PM, Steve Holden wrote:

James Stroud wrote:

>Steve Holden wrote:

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

Richard Jones wrote:

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

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®
er**@myemma.com
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]

John Nagle <na***@animats.comwrote:

TheFlyingDutchman wrote:

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.

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

[Paul Rubin]

"Diez B. Roggisch" <de***@nospam.web.dewrites:

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.

[John Nagle]

Alex Martelli wrote:

John Nagle <na***@animats.comwrote:

>TheFlyingDutchman wrote:

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

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.

Insofar as Python has an organization, it's not adequately managing
extension modules. Each extension module has its own infrastructure,
with its own build procedures, its own bug list, and its own maintainers.
There's not even an archive. Unlike CPAN, Cheese Shop is just a directory of
URLs.

Take a look at how Perl does it. Here are the instructions on
how to contribute to CPAN:

http://www.cpan.org/modules/04pause.html

There's a way to get your module into the system, a standardized format,
build, and installation procedure, and an archive which is mirrored.
There's a common bug reporting system. Modules abandoned by their
original developers are not lost, and can be "adopted" by someone else.

Python doesn't have any of this. And that's far more of a problem
than Python 3.x.

John Nagle

[Diez B. Roggisch]

Paul Rubin wrote:

"Diez B. Roggisch" <de***@nospam.web.dewrites:

>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

<snip/>

Please, Paul. There is no need to hijack every thread to show off your mad
functional and wicked staticly typed programming language skillz. We had
that discussion at a different time, and you very well know that with
serious I didn't mean "can be used to program rockets that don't fall of
the earth", but that aren't toy-languages used to solve real-world
problems.

Diez

[George Sakkis]

On Sep 28, 11:53 am, John Nagle <[e-mail]:

Alex Martelli wrote:

John Nagle <[e-mail]:

TheFlyingDutchman wrote:
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.

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.

Insofar as Python has an organization, it's not adequately managing
extension modules. Each extension module has its own infrastructure,
with its own build procedures, its own bug list, and its own maintainers.
There's not even an archive. Unlike CPAN, Cheese Shop is just a directory of
URLs.

Take a look at how Perl does it. Here are the instructions on
how to contribute to CPAN:

http://www.cpan.org/modules/04pause.html

There's a way to get your module into the system, a standardized format,
build, and installation procedure, and an archive which is mirrored.
There's a common bug reporting system. Modules abandoned by their
original developers are not lost, and can be "adopted" by someone else.

Python doesn't have any of this. And that's far more of a problem
than Python 3.x.

Does Perl support extension modules, and if so, are they so prevalent
as in Python ? Either case, bringing up CPAN is moot in this case;
nothing can force an external open source contributor to maintain or
provide binaries for his packages. How is this a problem of the
*language* ?

George

[Kay Schluehr]

On 28 Sep., 17:53, John Nagle <[e-mail]:

Alex Martelli wrote:

John Nagle <[e-mail]:

TheFlyingDutchman wrote:
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.

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.

Insofar as Python has an organization, it's not adequately managing
extension modules. Each extension module has its own infrastructure,
with its own build procedures, its own bug list, and its own maintainers.
There's not even an archive. Unlike CPAN, Cheese Shop is just a directory of
URLs.

John, can't you please piss off?

Thanks, Kay

[Steve Holden]

Kay Schluehr wrote:

On 28 Sep., 17:53, John Nagle <[e-mail]:

>Alex Martelli wrote:

>>John Nagle <[e-mail]:
TheFlyingDutchman wrote:
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.
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.

Insofar as Python has an organization, it's not adequately managing
extension modules. Each extension module has its own infrastructure,
with its own build procedures, its own bug list, and its own maintainers.
There's not even an archive. Unlike CPAN, Cheese Shop is just a directory of
URLs.

John, can't you please piss off?

Thanks, Kay

Oops! Let's get back to goodwill and peace to all men, can we -
including {Flying Dutch,wo}men?

crabbi-ly y'rs - steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline

[Steve Holden]

Kay Schluehr wrote:

On 28 Sep., 17:53, John Nagle <[e-mail]:

>Alex Martelli wrote:

>>John Nagle <[e-mail]:
TheFlyingDutchman wrote:
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.
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.

Insofar as Python has an organization, it's not adequately managing
extension modules. Each extension module has its own infrastructure,
with its own build procedures, its own bug list, and its own maintainers.
There's not even an archive. Unlike CPAN, Cheese Shop is just a directory of
URLs.

John, can't you please piss off?

Thanks, Kay

Oops! Let's get back to goodwill and peace to all men, can we -
including {Flying Dutch,wo}men?

crabbi-ly y'rs - steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline

[Richard Jones]

John Nagle wrote:

Insofar as Python has an organization, it's not adequately managing
extension modules. Each extension module has its own infrastructure,
with its own build procedures, its own bug list, and its own maintainers.
There's not even an archive. Unlike CPAN, Cheese Shop is just a directory
of URLs.

Ah, it's not usenet without someone speaking from ignorance! :)
Richard

[John Nagle]

George Sakkis wrote:

On Sep 28, 11:53 am, John Nagle <[e-mail]:

>Alex Martelli wrote:

>>John Nagle <[e-mail]:
TheFlyingDutchman wrote:
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.
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.

Insofar as Python has an organization, it's not adequately managing
extension modules. Each extension module has its own infrastructure,
with its own build procedures, its own bug list, and its own maintainers.
There's not even an archive. Unlike CPAN, Cheese Shop is just a directory of
URLs.

Take a look at how Perl does it. Here are the instructions on
how to contribute to CPAN:

http://www.cpan.org/modules/04pause.html

There's a way to get your module into the system, a standardized format,
build, and installation procedure, and an archive which is mirrored.
There's a common bug reporting system. Modules abandoned by their
original developers are not lost, and can be "adopted" by someone else.

Python doesn't have any of this. And that's far more of a problem
than Python 3.x.

Does Perl support extension modules, and if so, are they so prevalent
as in Python ?

Yes, Perl supports non-Perl extension modules. But most of the
important ones are either maintained as part of the standard Perl distribution,
or supported by the organization that provides whatever they link to.
For example, MySQL AB supports a Perl binding to MySQL, but not a
Python binding.

John Nagle

[Ant]

I've posted my vote. However, I guess it won't be that simple in
practice. I suspect that the following is more likely:

1) Migrate to 3000 fairly soon after release for scripts and new
projects for which required third party modules are available for 3k
2) Migrate existing projects to 3k a) when frameworks/modules that
they use are available and b) if and when doing so would be
advantageous.

I suspect that many of the projects I have that are solid and are in
no imminent need of development will remain <3k for several years.

Cheers,

--
Ant

[Carsten Haese]

On Sat, 2007-09-29 at 04:09 +0000, John Nagle wrote:

[...]
For example, MySQL AB supports a Perl binding to MySQL, but not a
Python binding.

And what's your point, other than that apparently MySQL AB doesn't care
about Python?

--
Carsten Haese
http://informixdb.sourceforge.net

[John Roth]

On Sep 27, 5:37 pm, Steve Holden <[e-mail]:

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 [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden

Sorry, the dog ate my .sigline

I was thinking of starting work on converting Python FIT to 3.0, and
then they posted PEP 3137. I think it's a real good idea, but it shows
that 3.0a1 isn't ready for a conversion effort.

http://www.python.org/dev/peps/pep-3137/

I'll look at it again in a year or so.

John Roth

[NickC]

On Sep 30, 2:29 am, John Roth <[e-mail]:

I was thinking of starting work on converting Python FIT to 3.0, and
then they posted PEP 3137. I think it's a real good idea, but it shows
that 3.0a1 isn't ready for a conversion effort.

http://www.python.org/dev/peps/pep-3137/

I'll look at it again in a year or so.

John Roth

When 3.0b1 comes out is probably the time to start looking seriously
at conversion. Until then, major course corrections (like PEP 3137)
will still be a possibility. Before the first beta, the best idea is
probably just to keep a watchful eye on the development to see if you
spot any show-stopper problems that might lead to the need for such a
course correction :)

Regards,
Nick.

[Terry Reedy]

"NickC" <nc******@gmail.comwrote in message
news:11**********************@r29g2000hsg.googlegr oups.com...
| When 3.0b1 comes out is probably the time to start looking seriously
| at conversion. Until then, major course corrections (like PEP 3137)
| will still be a possibility. Before the first beta, the best idea is
| probably just to keep a watchful eye on the development to see if you
| spot any show-stopper problems that might lead to the need for such a
| course correction :)

It was people who did that, partly by trying to convert or write small
snippets of code, who found problems and persuaded Guido that PEP 3137 was
needed.

[Alia Khouri]

Couldn't agree with you more. What would be fantastic is if I could
drop into the Pypi (and/or use easy_install) and download
automatically compiled versions of extension modules for different
versions of python.

I'm sure the community at large would be happy to chip in an annual
fee to help build/maintain this infrastructure: I know my firm would.

PS: IMHO The growth of Ruby is, to a large extent, due to easy
installation of modules via its gem system...

On Sep 28, 6:53 pm, John Nagle <[e-mail]:

Insofar as Python has an organization, it's not adequately managing
extension modules. Each extension module has its own infrastructure,
with its own build procedures, its own bug list, and its own maintainers.
There's not even an archive. Unlike CPAN, Cheese Shop is just a directory of
URLs.

Take a look at how Perl does it. Here are the instructions on
how to contribute to CPAN:

http://www.cpan.org/modules/04pause.html

There's a way to get your module into the system, a standardized format,
build, and installation procedure, and an archive which is mirrored.
There's a common bug reporting system. Modules abandoned by their
original developers are not lost, and can be "adopted" by someone else.

Python doesn't have any of this. And that's far more of a problem
than Python 3.x.

John Nagle