when will python 2.5 take in mainstream?
Eric CHAO
needed not 2.5, ie. mysqldb. I've been using python for months. I
don't care about 2.4 or 2.5. But I like the default icons of python in
2.5. So I just use that, but some scripts can't work on that.
When will all these applications support 2.5?
Thanks.
paul
> A lot of application based on python claim that python 2.3 or 2.4 is
> needed not 2.5, ie. mysqldb. I've been using python for months. I
> don't care about 2.4 or 2.5. But I like the default icons of python in
> 2.5. So I just use that, but some scripts can't work on that.
scripts are happy ;)
thanks
Paul
Steven Bethard
Many applications that require 2.3 or 2.4 work fine in 2.5. Did you try
mysqldb and have it fail?
Steve
tleeuw...@gmail.com
One of the big things about Python is that its penetration slows it
down. There's more legacy code and interdependant systems around now
that Python is more successful and more mature.
Here's a thought -- perhaps it would be worth having some good ways to
interact with Python from Python. Suppose you have some 2.4 code
someplace, interacting with your mysqldb or whatever, and you don't
want to rewrite it. So long as you have some kind of object broker,
you could (plausibly) leave your 2.4 apps running with the old
interpreter, but wrap them for Python 2.5 and use that in your new
development.
Ditto 3.0.
Rather than having to re-write every interacting component, maybe it
could be straightforward to all Python2.4 from Python2.5 to execute
particular library calls. I'm not an expert, I don't know how you'd
build such a system, but I do know that re-writing stuff is a real
pain.
Perhaps APIs for 2.5 and 3.0 could have a special version flag, and if
not present or not compatible, a 2.4 interpreter could be called
instead...
Cheers,
-T
On Feb 5, 8:01 am, Dennis Lee Bieber <wlfr...@ix.netcom.com> wrote:
> On Sun, 4 Feb 2007 19:10:13 +0800, "Eric CHAO" <lionc...@gmail.com>
> declaimed the following in comp.lang.python:
>
> > When will all these applications support 2.5?
>
> cynical answer: when you download the sources and build them against
> the 2.5 headers
>
> In the case of MySQLdb, one problem is that, as I recall, the
> primary author does not have a Windows compatible build environment and
> essentially relies upon others doing the Linux port to Windows and
> releasing pre-built installers.
> --
> Wulfraed Dennis Lee Bieber KD6MOG
> wlfr...@ix.netcom.com wulfr...@bestiaria.com
> HTTP://wlfraed.home.netcom.com/
> (Bestiaria Support Staff: web-a...@bestiaria.com)
> HTTP://www.bestiaria.com/
Laurent Pointal
> When they have to ...
>
> One of the big things about Python is that its penetration slows it
> down. There's more legacy code and interdependant systems around now
> that Python is more successful and more mature.
>
> Here's a thought -- perhaps it would be worth having some good ways to
> interact with Python from Python. Suppose you have some 2.4 code
> someplace, interacting with your mysqldb or whatever, and you don't
> want to rewrite it. So long as you have some kind of object broker,
> you could (plausibly) leave your 2.4 apps running with the old
> interpreter, but wrap them for Python 2.5 and use that in your new
> development.
KISS please.
> Ditto 3.0.
>
> Rather than having to re-write every interacting component, maybe it
> could be straightforward to all Python2.4 from Python2.5 to execute
> particular library calls. I'm not an expert, I don't know how you'd
> build such a system, but I do know that re-writing stuff is a real
> pain.
Most of Python 2.4 source code is compatible with Python 2.5. Problems
come with native compiled modules, you must have those for you 2.X
Python version - some times just a compilation is enough.
For Python 3.0, AFAIK its a big rewrite and developers know that it will
be uncompatible in large parts with existing code.
> Perhaps APIs for 2.5 and 3.0 could have a special version flag, and if
> not present or not compatible, a 2.4 interpreter could be called
> instead...
Making Python interpreter bigger and more complex.
Some code already has "hacks", trying to import a newer module and
installing a fallback if its not available.
If really your old Python 2.4 software cant run under Python 2.5, then
you can have both Python 2.4 and 2.5 installed and running some code.
Setup Pyro [1] on both, and go throught remote object invocation.
And if you dont need new Python 2.5 stuff in your code evolution, just
stay with 2.4, it works well.
A+
Laurent.
[1] http://pyro.sourceforge.net/
Steven Bethard
> For Python 3.0, AFAIK its a big rewrite and developers know that it will
> be uncompatible in large parts with existing code.
Wrong on both counts. ;-) Python 3.0 is not a rewrite. It's based on the
same code base as the 2.X line, but with a lot of the old deprecated
things removed. And, while Python 3.0 is allowing itself to break
backwards compatibility, at least that the Python level, it should be
largely compatible with the 2.X line. There will be some breakages, but
(1) they shouldn't be too extensive and (2) there will be utilities to
help you update your code. In many cases, it will be possible to write
code that works in both Python 2.X and 3.0.
STeVe
Jean-Paul Calderone
>tleeuw...@gmail.com a écrit :
>> When they have to ...
>>
>> One of the big things about Python is that its penetration slows it
>> down. There's more legacy code and interdependant systems around now
>> that Python is more successful and more mature.
>>
>> Here's a thought -- perhaps it would be worth having some good ways to
>> interact with Python from Python. Suppose you have some 2.4 code
>> someplace, interacting with your mysqldb or whatever, and you don't
>> want to rewrite it. So long as you have some kind of object broker,
>> you could (plausibly) leave your 2.4 apps running with the old
>> interpreter, but wrap them for Python 2.5 and use that in your new
>> development.
>
>KISS please.
>
Requiring change is simpler than not requiring change? Okay, perhaps
you could make a case, but it's far from obvious this is always true.
>> Ditto 3.0.
>>
>> Rather than having to re-write every interacting component, maybe it
>> could be straightforward to all Python2.4 from Python2.5 to execute
>> particular library calls. I'm not an expert, I don't know how you'd
>> build such a system, but I do know that re-writing stuff is a real
>> pain.
>
>Most of Python 2.4 source code is compatible with Python 2.5. Problems
>come with native compiled modules, you must have those for you 2.X
>Python version - some times just a compilation is enough.
Do you have any data to actually back this assertion up? I have plenty
of evidence to the contrary.
>
>For Python 3.0, AFAIK its a big rewrite and developers know that it will
>be uncompatible in large parts with existing code.
>
How does knowing that it will not be compatible have any bearing on the
arguments made by the original poster? It doesn't change anything, as
far as I can tell.
Jean-Paul Calderone
Hopefully that will be the case. Misunderstandings aren't too surprising
though. Until recently, it didn't appear that this would be the case at
all. Of course, your statement isn't entirely accurate either. For example,
many things which _aren't_ deprecated are being removed as well. Some of
them may be deprecated in 2.x releases which haven't happened yet, but that
remains to be seen. And 3.0 won't be "largely compatible" with any _existing_
2.x release, but hopefully a future 2.x release will add a usable transition
path.
Jean-Paul
Laurent Pointal
Hum my brain just mix 3 and 3000. Sorry, just a factor 1000.
Laurent Pointal
> On Mon, 05 Feb 2007 10:19:26 +0100, Laurent Pointal
> <laurent...@limsi.fr> wrote:
>> tleeuw...@gmail.com a écrit :
>>> When they have to ...
>>>
>>> One of the big things about Python is that its penetration slows it
>>> down. There's more legacy code and interdependant systems around now
>>> that Python is more successful and more mature.
>>>
>>> Here's a thought -- perhaps it would be worth having some good ways to
>>> interact with Python from Python. Suppose you have some 2.4 code
>>> someplace, interacting with your mysqldb or whatever, and you don't
>>> want to rewrite it. So long as you have some kind of object broker,
>>> you could (plausibly) leave your 2.4 apps running with the old
>>> interpreter, but wrap them for Python 2.5 and use that in your new
>>> development.
>>
>> KISS please.
>>
>
> Requiring change is simpler than not requiring change?
> Okay, perhaps
> you could make a case, but it's far from obvious this is always true.
>
IMHO trying to have a binary compatibility with older compiled modules
by maintaining an ad-hoc layer to switch between 2.4/2.5 engines make
Python code more complex. And more complex code have generally more
bugs. This is the reason for my KISS hope about Python.
Its simple to require changes, not so sure that doing these
modifications keep things simple. Maybe an internal Python hacker can
give us his advice on such a modification (ie. staying compatible with
legacy modules compiled for previous versions).
A+
Laurent.
Jean-Paul Calderone
It's very easy to maintain compatibility in the C API. I'm much more
interested in compatibility at the Python layer, which is changed
incompatibly much, much more frequently than is the C layer.
Anyway, you didn't address my point. Maintaining compatibility in
Python itself might be more complex than not maintaining complexity.
But _not_ maintaining compatibility just pushes the complexity into
every program and library written with Python. Which one of these
things do you think results in more developer time being spent? (Hint:
it's the 2nd one.)
Don't mistake this for advocacy that Python never break any compatibility.
Whether or not I think that is the case is unrelated to whether or not
it is useful to understand and admit all of the costs associated with
breaking compatibility.
Jean-Paul
Paul Rubin
> IMHO trying to have a binary compatibility with older compiled modules
> by maintaining an ad-hoc layer to switch between 2.4/2.5 engines make
> Python code more complex. And more complex code have generally more
> bugs. This is the reason for my KISS hope about Python.
I haven't heard of other languages that seriously try to do that,
though maybe some do. I do know that in high-availability systems
it's common to expect to be able to upgrade the software without
interrupting the running system. Erlang has features for that, and
I've worked on C programs that implemented such hot-upgrade in painful
ways. It's done (at least in the one I worked on) by making fresh
copies in of all the important objects in a new address space,
converting if necessary from the old version's data formats to the new
version's, then switching from the old software and old space to the
new software and new space. I think Python isn't used much for this
type of application and so nobody has gone to such extremes.
Ben Sizer
> It's very easy to maintain compatibility in the C API. I'm much more
> interested in compatibility at the Python layer, which is changed
> incompatibly much, much more frequently than is the C layer.
Really? In all cases I've found, pure-Python extensions written for
2.4 work with 2.5. The same was true for 2.3 to 2.4 as well. And even
if I found one that didn't, it's highly likely I could fix it myself.
The same doesn't apply to any C compiled extensions. Updating Python
breaks these, every time, and users typically have to wait months for
the library developer to compile a new version, every time. Or maybe
they can wade through the morass of "how do I compile this library on
Windows" threads here. Perhaps the C API remains the same but the real
issue is the binary API between extensions and Python changes every
couple of years or so. That's why I run 2.4 anywhere that needs
extensions.
It would be great if someone could invest some time in trying to fix
this problem. I don't think I know of any other languages that require
recompilation of libraries for every minor version increase.
--
Ben Sizer
Paul Boddie
>
> Perhaps the C API remains the same but the real
> issue is the binary API between extensions and Python changes every
> couple of years or so. That's why I run 2.4 anywhere that needs
> extensions.
>
> It would be great if someone could invest some time in trying to fix
> this problem. I don't think I know of any other languages that require
> recompilation of libraries for every minor version increase.
On the python-dev mailing list there was discussion of some of these
issues in the context of the Linux Standard Base specifications:
http://mail.python.org/pipermail/python-dev/2006-November/070027.html
Despite the specificity implied by the LSB name, I think such work
would produce benefits for all Python developers with similar
concerns, regardless of their chosen platforms.
Paul
Jean-Paul Calderone
>On Feb 5, 4:15 pm, Jean-Paul Calderone <exar...@divmod.com> wrote:
>> It's very easy to maintain compatibility in the C API. I'm much more
>> interested in compatibility at the Python layer, which is changed
>> incompatibly much, much more frequently than is the C layer.
>
>Really? In all cases I've found, pure-Python extensions written for
>2.4 work with 2.5. The same was true for 2.3 to 2.4 as well. And even
>if I found one that didn't, it's highly likely I could fix it myself.
If you have to fix it yourself, then it's broken, wouldn't you say?
Huge amounts of my pure Python code was broken by Python 2.5. So yes,
it happens. The same _wasn't_ true for 2.3 to 2.4 though. Python 2.5
was pretty unusual in this regard.
>
>The same doesn't apply to any C compiled extensions. Updating Python
>breaks these, every time, and users typically have to wait months for
>the library developer to compile a new version, every time. Or maybe
>they can wade through the morass of "how do I compile this library on
>Windows" threads here. Perhaps the C API remains the same but the real
>issue is the binary API between extensions and Python changes every
>couple of years or so. That's why I run 2.4 anywhere that needs
>extensions.
Sure, this happens too. I didn't suggest it doesn't, I just pointed out
that I was less interested in it. :)
Jean-Paul
Aahz
Ben Sizer <kyl...@gmail.com> wrote:
>
>It would be great if someone could invest some time in trying to fix
>this problem. I don't think I know of any other languages that require
>recompilation of libraries for every minor version increase.
How do you define "minor version increase"? If you look at the
progression from 2.0 through 2.5, it's pretty clear that each version
doesn't particularly fit "minor version increase" even though each one
only increments by 0.1.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"I disrespectfully agree." --SJM
Ben Sizer
> Ben Sizer <kylo...@gmail.com> wrote:
>
> >It would be great if someone could invest some time in trying to fix
> >this problem. I don't think I know of any other languages that require
> >recompilation of libraries for every minor version increase.
>
> How do you define "minor version increase"? If you look at the
> progression from 2.0 through 2.5, it's pretty clear that each version
> doesn't particularly fit "minor version increase" even though each one
> only increments by 0.1.
I can't say I agree with that. In terms of naming, it's a minor
release because the 'major' release number has stayed at 2. In terms
of time, it's a minor release because it's only happening about once
every 18 months or so - a short period in computer language terms. In
terms of semantics, I'd argue they are minor releases because
generally the changes are just minor additions rather than large
revisions; I don't see much in the way of significant language
alterations for 2.5 apart from arguably 'unified try/except/finally',
nor in 2.4. I don't count addition of new types or modules as 'major'.
The language itself is fairly stable; it's just the way that it links
to extensions which is pretty fragile.
--
Ben Sizer
Chris Mellon
You're claiming that it's a minor increase because you didn't see
anything that "justifies" a major release. Well, the ABI changed, so
there you go.
It doesn't really matter what you call it - the Python releases are
numbered according to their own rules, and if you disagree you can
call 2.5 a major release all you want. Or you can call it a minor
release and accept that the ABI changes between minor releases. But
making up your own release rules and arguing from those is pretty much
a non-starter.
"Martin v. Löwis"
> modifications keep things simple. Maybe an internal Python hacker can
> give us his advice on such a modification (ie. staying compatible with
> legacy modules compiled for previous versions).
I think it should be possible to specify a Python API that then future
versions can guarantee. This would be a subset of what you can currently
do on the Python API, in particular, access to the structure layout of
Python objects would not be available.
Extension modules compiled against this API could then be compatible
across versions.
This would require both a change to the interpreter (to really mark
all API that is or is not "stable"), and to extension modules (to
restrict themselves to only this API).
Regards,
Martin
"Martin v. Löwis"
> Laurent Pointal <laurent...@limsi.fr> writes:
>> IMHO trying to have a binary compatibility with older compiled modules
>> by maintaining an ad-hoc layer to switch between 2.4/2.5 engines make
>> Python code more complex. And more complex code have generally more
>> bugs. This is the reason for my KISS hope about Python.
>
> I haven't heard of other languages that seriously try to do that,
> though maybe some do.
Languages typically achieve this by specifying an ABI (in addition
to the API), and then sticking to that.
The most prominent example is the language C, where you normally
can upgrade the C library on most current systems without having
to recompile all applications. Today, there is machinery to still
allow evolution of the C library. E.g. on Linux, there really
is a layer in the C library to provide binary compatibility with
earlier versions.
Another example is Java and JNI, which is an interface that just
won't change (AFAIK).
Similar to Python, Tcl has a layer of function pointers that is
designed to be version-indepdendent - whether this actually works,
I don't know.
There are many more examples.
Regards,
Martin
Paul Rubin
> I think it should be possible to specify a Python API that then future
> versions can guarantee. This would be a subset of what you can currently
> do on the Python API, in particular, access to the structure layout of
> Python objects would not be available.
An FFI like this is a reasonable idea, but it shouldn't look anything
like the current C API. It should be more like a Lisp FFI, or the
Java Native Interface. There might have to be a wrapper layer to get
it to work with CPython.
Paul Rubin
> > though maybe some do.
> Languages typically achieve this by specifying an ABI (in addition
> to the API), and then sticking to that.
Oh yes, at that level, it's reasonable and desirable.