When will Python 3 be fully deployed

[vsoler]

I recently read that many libraries, including Numpy have not been
ported to Python 3.

When do you think that Python 3 will be fully deployed?

Should I stick, so far, to Python 2.6?

Regards

Vicente Soler

 

[Luis M. González]

I recently read that many libraries, including Numpy have not been
ported to Python 3.

When do you think that Python 3 will be fully deployed?

Should I stick, so far, to Python 2.6?

Regards

Vicente Soler

You'll have some answers here: http://jessenoller.com/2009/12/04/pythons-moratorium-lets-think-about-this/

 

[Edward A. Falk]

I recently read that many libraries, including Numpy have not been
ported to Python 3.

When do you think that Python 3 will be fully deployed?

It will never be fully deployed. There will always be people out there who
haven't felt it necessary to upgrade their systems.

The question you should be asking is "when will the percentage of systems
without Python 3 be so small that I don't care about the customers I'll lose
if I switch?"

I can say personally that I still haven't seen any needs pressing enough to
upgrade my perfectly-function Ubuntu 8 system. That means I can't even run
Python 2.6 code. I'm still using 2.5.

Should I stick, so far, to Python 2.6?

For development purposes, you should stick with the oldest version that will
actually run your code. Every time you move to a more modern version, you're
leaving potential users/customers out in the cold.

 

[Colin W.]

You'll have some answers here: http://jessenoller.com/2009/12/04/pythons-moratorium-lets-think-about-this/

2.7 is now available.

Work is going on numpy with Python 3.0

Colin W.

 

[Martin P. Hellwig]

Edward A. Falk wrote:

For development purposes, you should stick with the oldest version that will
actually run your code. Every time you move to a more modern version, you're
leaving potential users/customers out in the cold.

If the fear of customers disatification prevents you from using a
certain version of X, you should consider a deployment strategy that
cuts out dependencies as much as possible. Although this will result in
a larger end package and possible high amount of duplication, it is
still preferable to just stop supporting popular platforms or be swamped
away with bugs due to version mismatches.

 

[vsoler]

Edward A. Falk wrote:



If the fear of customers disatification prevents you from using a
certain version of X, you should consider a deployment strategy that
cuts out dependencies as much as possible. Although this will result in
a larger end package and possible high amount of duplication, it is
still preferable to just stop supporting popular platforms or be swamped
away with bugs due to version mismatches.

Your posts have been very enlightening. Thank you very much!!!

 

[Martin P. Hellwig]

"Martin P. Hellwig" <[email protected]> writes:

Along with the duplication this introduces, it also means that any bug
fixes — even severe security fixes — in the third-party code will not be
addressed in your duplicate.

<cut>
I disagree, what you need is:
- An automated build system for your deliveries, something you should
have anyway
- An method of tracking versions of your dependencies, again something
you should have anyway
- And a policy that you incorporate bug fixes from your dependencies in
your deliveries, something you should do anyway if you are serious about
your product.

 

[Martin P. Hellwig]

Ben Finney wrote:

This omits the heart of the problem: There is an extra delay between
release and propagation of the security fix. When the third-party code
is released with a security fix, and is available in the operating
system, the duplicate in your application will not gain the advantage of
that fix until you release a new version of your application *and* that
new version makes its way onto the affected computer.

That is an additional delay, that only occurs because the hypothetical
security bug exists in a duplicate copy of the third party code. That
delay is entirely eradicated if your application instead uses a
system-installed library; your application then gains the security fix
immediately when they upgrade the system-installed library, without the
user having to upgrade the application at all.

I fully agree with your reasoning and I think you raised a valid point.

However, for me (as in YMMV), I have observed the following behaviour:
- Distribution security fixes are time wise at best on-par with my releases.
- Although some distribution (like ubuntu) offer updates on third party
dependencies (like the Python interpreter), most of them don't (windows).
- A user is more likely to update a program he uses than a third party
dependency he doesn't think he uses, especially if that program has an
auto-update feature and the dependency doesn't.
- In the ideal world, a upgrade of a dependency won't break your
program, in reality users fear upgrading dependencies because they don't
know for sure it won't result in a dll hell type of problem.

With these observations in mind and that it gives me more control on
what I am delivering, I made the trade off that I send platform specific
fully self contained (as far as possible) executables.

But you are right that it does give me the obligation to provide a way
to the customer to get updates ASAP if there is a security issue in my
program, whether this comes originally from a third party library or not
is in the users perspective, rightfully so, beside the point.

 

[Lie Ryan]

<cut>
I disagree, what you need is:
- An automated build system for your deliveries, something you should
have anyway
- An method of tracking versions of your dependencies, again something
you should have anyway
- And a policy that you incorporate bug fixes from your dependencies in
your deliveries, something you should do anyway if you are serious about
your product.

I disagree, what you should have is an Operating System with a package
management system that addresses those issues. The package management
must update your software and your dependencies, and keep track of
incompatibilities between you and your dependencies.

The package management systems have in many popular Linux distro is
close to it. The point is, those issues should not be your issue in the
first place; the OS is the one in charge of coordination between
multiple software (or else why would we have an OS for?).

In the Windows\b\b\b\b\b\b\b Real world, some OS let off *their
responsibility* and told their users to manage dependency by their own.
Obviously most users don't have the knowledge to do so, and the undue
burden then goes to software developers. A software ideally shouldn't
need to care about how the machine is configured ("Separation of Concern").

I never liked the idea of each software to have its own software
updater, they are sign of bloated software. There should ideally be one
software updater in the system ("Don't Repeat Yourself"). Many automatic
updater by big companies is configured to run on computer startup and
doesn't shutdown without an order from the Task Manager. They then
reinstall their autorun entry in the registry when the user deletes
them, trying to outsmart the user since they think the user is just
ain't smart enough.

In my Windows computer, the only software I give my blessing to
auto-update is the antivirus; anything else just bloats the system. A
good-behaviored software would just notify me about update (e.g.
OpenOffice and Pidgin), and even then only when I'm using the software
(not every time you open your computer).

I'm glad I don't have such chaos when using my Gentoo or Ubuntu, the
system software updater handles all those just fine.

 

[Martin P. Hellwig]

Lie Ryan wrote:
<cut dependencies should be done by the OS>

Yes from an argumentative perspective you are right.
But given the choice of being right and alienate the fast majority of my
potential user base, I rather be wrong.

For me the 'Although practicality beats purity' is more important than
trying to beat a dead horse that is a platform independent package
manager actively supported by all mayor operating systems.

But hey if it works for you, great!

 

[David Cournapeau]

I disagree, what you should have is an Operating System with a package
management system that addresses those issues. The package management must
update your software and your dependencies, and keep track of
incompatibilities between you and your dependencies.

This has many problems as well: you cannot install/update softwares
without being root, there are problems when you don't have the right
version, when the library/code is not packaged, etc... Don't get me
wrong, I am glad that things like debian, rpm exist, but it is no
panacea. There are simply no silver bullet to the deployment problem,
and difference cases/user target may require different solutions.

David

 

[Lie Ryan]

This has many problems as well: you cannot install/update softwares
without being root,

A package manager with setuid, though dangerous, can run without being
root. Some package manager (e.g. Gentoo's Portage w/ prefix) allow user
to set to install in a non-default directory (one that doesn't require
root access).

there are problems when you don't have the right version,

That's the whole point of package management system! A package
management system are not just plain software installers (like MSI and
NSIS), they go beyond and figure out the "right version" of your
dependencies.

In many package management system, bleeding edge packages are run by
testers that will figure out the dependency your software requires. If
you are nice (it is your responsibility anyway), you can save them some
work by telling them the dependency version you've tested your software
with.

> when the library/code is not packaged, etc...

Don't worry, the majority of users are willing to wait a few weeks until
the library/code gets packaged. Some even _refuses_ to use anything
younger than a couple of years.

> Don't get me wrong, I am glad that things like debian, rpm exist,
> but it is no panacea

They're not; but software developers should maximize functionality
provided by package managers rather than trying to build their own
ad-hoc updater and dependency manager.

> There are simply no silver bullet to the
> deployment problem, and difference cases/user target may require
> different solutions.

The only thing that package managers couldn't provide is for the
extremist bleeding edge; those that want the latest and the greatest in
the first few seconds the developers releases them. The majority of
users don't fall into that category, most users are willing to wait a
few weeks to let all the just-released bugs sorted out and wait till the
package (and their dependencies) stabilize.

 

[Grant Edwards]

- In the ideal world, a upgrade of a dependency won't break
your program, in reality users fear upgrading dependencies
because they don't know for sure it won't result in a dll
hell type of problem.

In my experience with binary-based distros (RedHat, Windows,
Debian, etc.), upgrading libraries broke things as often as
not. I've had significantly better results with Gentoo.
However, were I shipping a significant product that dependended
up updates to external libraries, I'd be very worried.

It also seems like a lot of work to provide the product in all
of the different package-management formats used by customers.
Even considering the extra updates that might be required for
library fixes, shipping a single stand-alone system sounds like
a lot less work.

 

[Martin P. Hellwig]

Lie Ryan wrote:

The only thing that package managers couldn't provide is for the
extremist bleeding edge; those that want the latest and the greatest in
the first few seconds the developers releases them. The majority of
users don't fall into that category, most users are willing to wait a
few weeks to let all the just-released bugs sorted out and wait till the
package (and their dependencies) stabilize.

Well you majority of your users still fall into my category of minority,
as most of my paid support clients use windows, although I use Ubuntu as
my main developer machine.

 

[Grant Edwards]

Lie Ryan wrote:


Well you majority of your users still fall into my category of minority,
as most of my paid support clients use windows,

Does windows even _have_ a library dependancy system that lets
an application specify which versions of which libraries it
requires?

 

[Martin P. Hellwig]

Grant Edwards wrote:

Does windows even _have_ a library dependancy system that lets
an application specify which versions of which libraries it
requires?

<cut>
Well you could argue that easy_install does it a bit during install.
Then there is 'Windows Side By Side' (winsxs) system which sorta does it
during run time.

 

[Nobody]

It will never be fully deployed. There will always be people out there who
haven't felt it necessary to upgrade their systems.

Moreover, there will always be people out there who have felt it necessary
not to upgrade their systems.

IMNSHO, Python 2 will still be alive when Python 4 is released. If
python.org doesn't want to maintain it, ActiveState will.

In particular: for Unix scripting, Python 3's Unicode obsession just gets
in the way. Ultimately, argv, environ, filenames, etc really are just byte
strings. Converting to Unicode just means that the first thing that the
script does is to convert back to bytes.

I'm sure that the Unicode approach works great on Windows, where wchar_t
is so pervasive that Microsoft may as well have just redefined "char"
(even to the point of preferring UTF-16-LE for text files over UTF-8,
ASCII-compatibility be damned).

But on Unix, it's a square-peg-round-hole situation.

 

[Rami Chowdhury]

I'm sure that the Unicode approach works great on Windows, where wchar_t
is so pervasive that Microsoft may as well have just redefined "char"
(even to the point of preferring UTF-16-LE for text files over UTF-8,
ASCII-compatibility be damned).

But on Unix, it's a square-peg-round-hole situation.

I dunno, I find it rather useful not to have to faff about with
encoding to/from when working with non-ASCII files (with non-ASCII
filenames) on Linux.

 

[Nobody]

I dunno, I find it rather useful not to have to faff about with
encoding to/from when working with non-ASCII files (with non-ASCII
filenames) on Linux.

For the kind of task I'm referring to, there is no encoding or decoding.
You get byte strings from argv, environ, files, etc, and pass them to
library functions. What those bytes "mean" as text (if anything) never
enters the equation.

For cases where you *need* text (e.g. GUIs), Python 3 makes the simplest
cases easier. The more complex cases (e.g. where each data source may have
its own encoding, or even multiple encodings) aren't much different
between Python 2 and Python 3.

 

[Rami Chowdhury]

For the kind of task I'm referring to, there is no encoding or decoding.
You get byte strings from argv, environ, files, etc, and pass them to
library functions. What those bytes "mean" as text (if anything) never
enters the equation.

Perhaps we're referring to slightly different tasks, then. I'm
thinking of scripts to move log files around, or archive documents,
where some manipulation of file and folder names is necessary --
that's where I personally have been bitten by encodings and the like
(especially since I was moving around between filesystems, as well).
But I take your point that the more complex cases are complex
regardless of Python version.