How ahead are you guys in the (Python) real world?

[Ray]

Since I haven't used Python at work, I am using Python 2.5 right now.
However I wonder, how fast are you guys moving from version to version
at work? As an illustration my ex-company just moved to Java 5, which
was released around... what, 2-3 years ago? (While I am running Java 6
at home)

Is it the same in the Python world? What version of Python is used in,
say, Google? Is it even 2.4 yet?

[sjdevnull]

Ray wrote:

Since I haven't used Python at work, I am using Python 2.5 right now.
However I wonder, how fast are you guys moving from version to version
at work? As an illustration my ex-company just moved to Java 5, which
was released around... what, 2-3 years ago? (While I am running Java 6
at home)

We are using 2.2 most places, with 2.3 on a few dev boxes. We're
planning an update to 2.4 in the next couple of months.

[John Salerno]

Ray wrote:

However I wonder, how fast are you guys moving from version to version
at work?

Interesting question. Just as a curious follow-up (not being someone who
works in the programming world), why does it take so long to move to the
latest version, especially when there aren't (I don't think) any changes
that would break existing code, such as moving to Python 2.4 from 2.2 or
2.3?

Thanks.

[Fredrik Lundh]

John Salerno wrote:

when there aren't (I don't think) any changes that would break existing code,

in practice, in a large enough system, there's always something.

(external libraries are a common problem, especially if you have to rebuild them,
or update them to a new version to work around some incompatibility , and then
end up with your code being incompatible with the new version, etc)

</F>

[Ray]

John Salerno wrote:

However I wonder, how fast are you guys moving from version to version
at work?

Interesting question. Just as a curious follow-up (not being someone who
works in the programming world), why does it take so long to move to the
latest version, especially when there aren't (I don't think) any changes
that would break existing code, such as moving to Python 2.4 from 2.2 or
2.3?

Well, the thing is that migration in practice is usually a messy
business, especially as your application grows in size + complexity.
When your application is small and simple, usually migration is
relatively painless, and the assumption that a release is compatible
with the previous ones therefore your application shouldn't break
usually holds true.

However, when your apps are big and mission critical... for some reason
they just break more often ;-) Like last time we migrated our automated
build system to the latest bugfix release of the software (Ant,
specifically--see ant.apache.org if you're curious).

Everything *should* be working just fine, after all it's just a bugfix
release. But it turned out that one of the bugfixes (which was meant to
optimize the build cycle) actually broke our system in a subtle and
mysterious way, and for the longest time we resisted rolling back our
system because nobody was willing to believe that Ant, which is an
Apache project, and written by people probably smarter than us, and
being used by a LOT of Java teams around the world, could be the cause.
That was just one example from the Enterprise Java world, I'm sure the
others can supply a lot more stories from the Python world...

Regards,
Ray

>
Thanks.

[skip]

JohnInteresting question. Just as a curious follow-up (not being
Johnsomeone who works in the programming world), why does it take so
Johnlong to move to the latest version, especially when there aren't
John(I don't think) any changes that would break existing code, such
Johnas moving to Python 2.4 from 2.2 or 2.3?

There are often lots of binary interdependenci es between the Python version
and internal or external packages. For instance, all the database adaptors
I'm aware of for SQL-based databases have extension modules written in C.
Then consider GUI stuff (PyGtk, wxPython, etc), scientific (SciPy, Numeric,
VTK, ...). The list can be nearly endless. At work we have lots of
in-house C++ libraries, many of which have been exposed to Python
programmers via SWIG or Boost.Python. All that stuff at minimum needs to be
recompiled with the new version of Python's header files (which can and do
change between versions). Then you have to test it.

While it's true that there are generally no semantic or syntactic
differences between versions and for the most part the developers try hard
not to break things, differences do creep into the Python level and can be
subtle to discover.

In short, it takes a fair amount of work to move from one version to
another.

Skip

[Grant Edwards]

On 2006-08-30, John Salerno <jo******@NOSPA Mgmail.comwrote :

Ray wrote:

>However I wonder, how fast are you guys moving from version to version
at work?

Interesting question. Just as a curious follow-up (not being
someone who works in the programming world), why does it take
so long to move to the latest version,

Two reasons:

1) "If it ain't broke, don't f*** with it."

2) There's always something else that is broke.

especially when there aren't (I don't think) any changes that
would break existing code,

After doing a few sowftware upgrades you quickly learn to
never, ever believe that. The best working hypothesis is that
upgrading will break things. So the questions when considering
an upgrade are:

1) Is there a new feature I want?

2) Is that feature worth fixing the update breaking?

--
Grant Edwards grante Yow! CALIFORNIA is where
at people from IOWA or NEW
visi.com YORK go to subscribe to
CABLE TELEVISION!!

[skip]

GrantSo the questions when considering an upgrade are:

Grant 1) Is there a new feature I want?

Grant 2) Is that feature worth fixing the update breaking?

3) Has the version I'm running reached "end of support"?

If it has and you encounter a bug, you may be forced to upgrade at an
inopportune time.

Skip

[sjdevnull]

John Salerno wrote:

Interesting question. Just as a curious follow-up (not being someone who
works in the programming world), why does it take so long to move to the
latest version, especially when there aren't (I don't think) any changes
that would break existing code, such as moving to Python 2.4 from 2.2 or
2.3?

Well, let's see. We have about 5 live servers that would need to be
upgraded. They're running an old enough version of the OS that 2.2 is
the last supported release. Fine, building a new python release
ourself is not a huge deal--but it means that we're no longer on the
vendor's automatic update system for python and related packages.

And, of course, we use mod_python. That needs to be rebuilt against
the new python version. We also have a number of 3rd-party packages
installed; each of those needs to be re-installed for the new python
version, and possibly rebuilt first if it has any C extension modules.

The real question in most production environments isn't "why not
upgrade?", it's "why upgrade?". Until a new release has features that
are going to be valuable enough to your project to offset the cost of
upgrading, why would you bother?

[John Salerno]

sj*******@yahoo .com wrote:

The real question in most production environments isn't "why not
upgrade?", it's "why upgrade?".

Good way to put it. Now I'm starting to see how much of a pain it can be. :)

[Aahz]

In article <11************ **********@p79g 2000cwp.googleg roups.com>,
Ray <ra********@yah oo.comwrote:

>
Since I haven't used Python at work, I am using Python 2.5 right now.
However I wonder, how fast are you guys moving from version to version
at work? As an illustration my ex-company just moved to Java 5, which
was released around... what, 2-3 years ago? (While I am running Java 6
at home)

My company uses 2.2 and 2.3; we hope to drop 2.2 Real Soon Now.
--
Aahz (aa**@pythoncra ft.com) <* http://www.pythoncraft.com/

I support the RKAB