When will Python 3 be fully deployed
vsoler
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
You'll have some answers here: http://jessenoller.com/2009/12/04/pythons-moratorium-lets-think-about-this/
Edward A. Falk
vsoler <vicent...@gmail.com> wrote:
>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.
--
-Ed Falk, fa...@despams.r.us.com
http://thespamdiaries.blogspot.com/
Colin W.
2.7 is now available.
Work is going on numpy with Python 3.0
Colin W.
Martin P. Hellwig
<cut>
> 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.
--
MPH
http://blog.dcuktec.com
'If consumed, best digested with added seasoning to own preference.'
vsoler
wrote:
> Edward A. Falk wrote:
>
> <cut>
>
> > 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.
>
> --
> 'If consumed, best digested with added seasoning to own preference.'
Your posts have been very enlightening. Thank you very much!!!
Ben Finney
> 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.
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. This defeats one of the many benefits of a
package management operating system: that libraries, updated once, will
benefit any other package depending on them.
Please reconsider policies like including duplicates of third-party
code. Don't Repeat Yourself is a good principle not just within source
code, but has important security implications within the operating
system packages too.
--
\ “Our task must be to free ourselves from our prison by widening |
`\ our circle of compassion to embrace all humanity and the whole |
_o__) of nature in its beauty.” —Albert Einstein |
Ben Finney
Martin P. Hellwig
>
> 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.
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.
Ben Finney
> Ben Finney wrote:
> > 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.
> 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
Those are orthogonal issues. They're good practice, but don't address
the problem I'm describing.
> - 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.
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 took it easy today. I just pretty much layed around in my |
`\ underwear all day. … Got kicked out of quite a few places, |
_o__) though.” —Bug-Eyed Earl, _Red Meat_ |
Ben Finney
Martin P. Hellwig
<cut>
> 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
> Ben Finney wrote:
>> "Martin P. Hellwig" <martin....@dcuktec.org> writes:
> <cut>
>>
>> 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.
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
<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
> On Tue, Dec 8, 2009 at 9:02 PM, Lie Ryan<lie....@gmail.com> wrote:
>
>> 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,
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.
--
Grant Edwards grante Yow! JAPAN is a WONDERFUL
at planet -- I wonder if we'll
visi.com ever reach their level of
COMPARATIVE SHOPPING ...
Martin P. Hellwig
<cut>
>
> 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
><cut>
>>
>> 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,
Does windows even _have_ a library dependancy system that lets
an application specify which versions of which libraries it
requires?
> although I use Ubuntu as my main developer machine.
--
Grant Edwards grante Yow! My life is a patio
at of fun!
visi.com
Martin P. Hellwig
<cut>
> Does windows even _have_ a library dependancy system that lets
> an application specify which versions of which libraries it
> requires?
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
>>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.
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.
--------
Rami Chowdhury
"Never assume malice when stupidity will suffice." -- Hanlon's Razor
408-597-7068 (US) / 07875-841-046 (UK) / 0189-245544 (BD)
Nobody
>> 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.
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
> On Wed, 09 Dec 2009 10:28:40 -0800, Rami Chowdhury wrote:
>
>>> 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.
>
> 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.
John Nagle
I'd argue against using Python 2.6 for production work. Either use Python
2.5, which is stable, or 3.x, which is bleeding-edge. 2.6 has some of the
features of Python 3.x, but not all of them, and is neither fish nor fowl
as a result. 2.6 is really more of a sideline that was used for trying
out new features, not something suitable for production.
I think the idea is to run your 2.5 code through '2to3" and see if it
works in 3.x.
Anyway, it will be years, if ever, before Python 3.x gets any real support.
Too many major packages still aren't fully supported on it, and some popular
packages, like SGMLlib and Feedparser, are being dropped.
When a few major Linux distros ship with Python 3.x and enough of the binary
packages to run a web site, take a look at it again.
John Nagle
Ned Deily
John Nagle <na...@animats.com> wrote:
> I'd argue against using Python 2.6 for production work. Either use
> Python
> 2.5, which is stable, or 3.x, which is bleeding-edge. 2.6 has some of the
> features of Python 3.x, but not all of them, and is neither fish nor fowl
> as a result. 2.6 is really more of a sideline that was used for trying
> out new features, not something suitable for production.
I disagree with that advice, strongly. 2.6 not only has new features
but it has many bug fixes that have not and will not be applied to 2.5.
It is hardly a sideline.
See http://www.python.org/download/releases/2.5.4/ for the official
policy on 2.5, in particular:
"Future releases of Python 2.5 [ -- that is, should the need arise -- ]
will only contain security patches; no new features are being added, and
no 'regular' bugs will be fixed anymore."
"If you want the latest production version of Python, use Python 2.6.1
or later." [2.6.4 is the latest version].
Then see http://www.python.org/download/releases/2.6.4/
Note that Python 2.6 is considered the stable version and is "now in
bugfix-only mode; no new features are being added". Per normal python
development policy, new features are added to the next major release
cycles, now under development: Python 2.7 and Python 3.2.
--
Ned Deily,
n...@acm.org
Gabriel Genellina
escribi�:
> Luis M. Gonz�lez wrote:
>> On Dec 6, 3:21 pm, vsoler <vicente.so...@gmail.com> wrote:
>
> I'd argue against using Python 2.6 for production work. Either use
> Python 2.5, which is stable, or 3.x, which is bleeding-edge. 2.6 has
> some of the
> features of Python 3.x, but not all of them, and is neither fish nor fowl
> as a result. 2.6 is really more of a sideline that was used for trying
> out new features, not something suitable for production.
>
> I think the idea is to run your 2.5 code through '2to3" and see if it
> works in 3.x.
In addition to Ned Deily's previous comments, I'd like to note that 2to3
assumes the source is valid 2.6 code - you have to ensure the code runs
fine with Python 2.6 before using 2to3 to convert to 3.x
--
Gabriel Genellina
Ben Finney
> In addition to Ned Deily's previous comments, I'd like to note that
> 2to3 assumes the source is valid 2.6 code - you have to ensure the
> code runs fine with Python 2.6 before using 2to3 to convert to 3.x
To achieve that, you're strongly encouraged to follow Step 0 of the
transition guidelines
<URL:http://www.python.org/dev/peps/pep-3000/#compatibility-and-transition>.
--
\ “It was half way to Rivendell when the drugs began to take |
`\ hold” —Hunter S. Tolkien, _Fear and Loathing in Barad-Dûr_ |
_o__) |
Ben Finney
Martin v. Loewis
> assumes the source is valid 2.6 code - you have to ensure the code runs
> fine with Python 2.6 before using 2to3 to convert to 3.x
That's wrong - 2to3 works just fine on, say, 2.3 code that has never
been run on 2.6.
Regards,
Martin
Aahz
Ned Deily <n...@acm.org> wrote:
>In article <4b20ac0a$0$1596$742e...@news.sonic.net>,
> John Nagle <na...@animats.com> wrote:
>>
>> I'd argue against using Python 2.6 for production work. Either use
>> Python 2.5, which is stable, or 3.x, which is bleeding-edge. 2.6
>> has some of the features of Python 3.x, but not all of them, and is
>> neither fish nor fowl as a result. 2.6 is really more of a sideline
>> that was used for trying out new features, not something suitable for
>> production.
>
>I disagree with that advice, strongly. 2.6 not only has new features
>but it has many bug fixes that have not and will not be applied to 2.5.
>It is hardly a sideline.
Ditto -- we had some webserver crashes that were fixed by upgrading from
2.4 to 2.6 (we were already using 2.6 in the client and decided that
skipping 2.5 on the server was best).
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
Looking back over the years, after I learned Python I realized that I
never really had enjoyed programming before.
Roy Smith
wrote:
> Looking back over the years, after I learned Python I realized that I
> never really had enjoyed programming before.
That's a sad commentary. Python is fun to use, but surely there are other
ways you can enjoy programming?
The first thing I learned how to program was an HP-9810
(http://www.hpmuseum.org/hp9810.htm). I had LOADS of fun with that. Then
I learned BASIC (using my high school's ASR-33 hookup to a HP-3000 a couple
of towns away). Lots of fun there too.
Then came Fortran. I guess I had fun with that, at least in the beginning.
I did a bunch of assembler. Some of it was fun (pdp-11, 6800), some of it
was not (pdp-10, IBM-1130). Lisp was fun for a while, but I never really
got into it.
C was fun at the beginning, but quickly became a drag. C++ was was evil
and horrible at the beginning. As opposed to now, when I'm somewhat of an
expert in it, and it's still evil and horrible.
Learning PostScript was blast! One of the true epiphanies of my
programming career was hooking a video terminal up to the RS-232 port on an
Apple LaserWriter, typing a few lines of PostScript at it, and watching a
page come out with a square drawn on it.
Everybody should learn PostScript. People think of it as just some
document printing thing, but it's a real (Turing-complete) programming
language. Not just that, but it's a fun language to learn, and lets you
explore some corners of the language design space which most people never
see. Go forth and learn PostScript!
Learning Java was about as much fun as kissing your sister.
I'm sure I've left a few out, but the point is there are plenty of ways to
have fun programming besides Python.
Aahz
Roy Smith <r...@panix.com> wrote:
>In article <hgll51$cv0$1...@panix5.panix.com>, aa...@pythoncraft.com (Aahz)
>wrote:
>>
>> never really had enjoyed programming before.
>
>That's a sad commentary. Python is fun to use, but surely there are other
>ways you can enjoy programming?
Not really. I've been programming more than thirty years, and the
closest I came previously to enjoying programming was Turbo Pascal, and
even that has too much tedium and lack of brain-fit.
Before Turbo Pascal, there was BASIC on an HP-1000. Afterward came
HP-41, Ada, FORTRAN, Paradox PAL, C, Perl, and there must be some others
I'm forgetting. Thankfully, I didn't learn Java until after I'd been
programming in Python for a while. (And arguably I still haven't learned
Java despite writing a PGP encryption wrapper around BouncyCastle.)
Programming is difficult to begin with, and everything other than Python
just gets in my way.
To be fair, my quote isn't entirely honest: I never called myself a
programmer before I learned Python because I didn't really like it. It
took Python to make me realize that programming *could* be fun, or at
least not annoying enough to keep me from making a career of programming.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
Looking back over the years, after I learned Python I realized that I
Ben Finney
> I never called myself a programmer before I learned Python because I
> didn't really like it. It took Python to make me realize that
> programming *could* be fun, or at least not annoying enough to keep me
> from making a career of programming.
+1 QOTW
--
\ “Two hands working can do more than a thousand clasped in |
`\ prayer.” —Anonymous |
_o__) |
Ben Finney