The real problem with Python 3 - no business case for conversion

[Ben Finney]

John Nagle <nagle at animats.com> writes:

> Where's the business case for moving to Python 3?   It's not faster.

It's faster to learn, because there's less to learn.

How do you know that it's not faster? That's a matter of the speed of
individual Python implementations. What data do you have?

> It doesn't do anything you can't do in Python 2.6.

In the trivial sense that Python doesn't do anything you can't do in
pure assembly language, that's true.

In the more interesting sense of what can the *programmer* do, there are
a number of improvements (dealing with Unicde more sanely; keyword-only
arguments; function annotations; etc.) that can't be done in Python 2.
That set will only grow over time.

> How can a business justify spending money on conversion to Python
> 3?

You'll have to ask the ones that *have* justified that expense. There
are major libraries that work with Python 3 now because people have been
funded to work on getting there, and others are happening now.

>    What I'm not seeing is a deployment plan along these lines:
>
>    1.	Identify key modules which must be converted before Python 3
> 	can be used in production environments.

This needs to be done by those who want to use Python. You can't expect
a single “key modules” for the whole of the Python ecosystem.

>    2.	Get those modules converted to Python 3.

Many of them have been converted, and many more are under active
development. But this is entirely dependent on which libraries the
specific use case demands.

>    3.	Put together a distribution for the major platforms (at least
> 	Linux and Windows) with builds of those modules.

The better path for the GNU distributions is to get the package
distributed by the operating system distributor, instead of expecting
every developer to also get the packaging right. Fortunately, for a
great many key libraries, that's already the case in Debian which is a
huge share of the “major platforms”.

>    4.	Get some major distros, like Debian and ActiveState, to
> 	include Python 3, as "python3", not as the primary Python,
> 	so there are no conflicts.  (Debian already has a formal
> 	policy to keep Python versions separate.)

You know this is already the case; why are you saying you don't see it?

>    5.	Get at least two major hosting services to put up Python 3.
>
>    6.	Get at least two popular end-user programs (not modules) to
> 	support Python 3.

And how is this part of a plan for the PYthon developers? What are you
suggesting they do to “get [someone] to support Python 3”? That's up to
the someone, surely?

>    7.	Publicize some success stories.
>
> Unless the Python 3 enthusiasts get their act together and work much
> harder on providing an easy transition experience, it's not going to
> happen.

Since you clearly don't count yourself in the set of “Python 3
enthusiasts”, why do you keep demanding that they do something you
expressly don't care about?

-- 
 \           “If you do not trust the source do not use this program.” |
  `\                                —Microsoft Vista security dialogue |
_o__)                                                                  |
Ben Finney