I can't remember the last time I used print in actual code (apart from
short-lived debugging lines), so I'm bewildered as to why print seems to
be so important.

On Feb 16, 6:07 am, Steven Bethard <steven.beth...@gmail.com> wrote:

We are estimating, due to the speed at which our applications follow
OS releases, that
we can drop RHEL 3 (and hence Python 2.2) support a year from now.  Go
figure when you
think we might be ready to require that all programs run on python
3.0.  If it's not
backwards compatible, meaning if 2.4 code doesn't run on 3.0, it's
rather likely that
strong pressure will be applied to port *away* from Python into
something less capricious.

Fortran 90 was a superset of Fortran 77, so standard-conforming
Fortran 77 programs have the same meaning when compiled with an F90
compiler. The committee does not consider changing things like the
meaning of 1/2. Even though WRITE provides a superset of the
functionality of PRINT, the committee would not dream of breaking so
much code by removing PRINT. No feature is deleted without being
declared obsolescent in a previous standard, which makes it easier to
plan ahead. In practice Fortran 95 compilers accept deleted features,
but they are required to a have a switch that identifies non-standard
code.

"It's not even clear yet that your average 2.6 code will work on 3.0 --
though there's a pretty large contingent trying to make this true."

If you want to make sure average 2.6 code works on 3.0, please help
contribute to Python. You can find out where best to focus your efforts
by asking on python-dev:

     http://mail.python.org/mailman/listinfo/python-dev

Python 2.2 was released in early 2003 and you said you'd be dropping
support for 2.2 in early 2008, so I conclude that since Python 2.5 was
released in late 2006, you'll be ready to drop Python 2.5 support (and
have 2.6/3.0 compatible code) by late 2011. Sure, it's a long way off,
but you're writing 2.2 compatible code *now*. Is it really that bad to
wait four years for Python 3.0?

On Feb 20, 8:59 pm, Steven Bethard <steven.beth...@gmail.com> wrote:

I just dug out some code laying around on disk from 1994, and ran it,
unchanged, under python 2.3.5. If I can achieve this (running 2007
code under python3.0 in 2011 with no modifications), that'd be OK.

On 20 Feb 2007 08:49:10 -0800, Jay Tee <jeff.temp...@gmail.com> wrote:

Meanwhile, the risk is that the core developers will only consider
Python 3.0 as "Python" and that people doing anything with older
releases will be on their own. If the gap is too wide between 2.x and
3.x, any lack of maintenance in the 2.x series will be perceived as an
abandonment of "Python" for certain kinds of user, and the result will
probably be a loss of confidence in both variants of the language.
Although I believe that some of the recent attempts to lower the
disruptiveness of Python 3.0 may have helped to maintain "Python" as a
single narrow continuum, I think some people overlook how fortunate
the relationship between Python's evolution and momentum has been, and
how easily such a relationship can be broken.

Bjorn, I am not sure I see why my post is bull crap.  I think all you
are doing is agreeing with me.  My post was entitled "Python 3.0 unfit
for serious work", you just indicated that the Linux distros will
agree with me, in order to be taken seriously, the distros will have
to include 2.x python for a very long time.  If 3.0 and 2.x have any
serious degree of incompatibility, python will be a favorite subject
for religious rants and heated arguments for many people.  And if we
don't manage to restrain our developers from using features that force
us prematurely to move to 3.0 ... and don't underestimate what this
means, because this means other things will have to move as well,
which may have dependencies on yet other things like C++ library
versions ... then I would have to, for reasons of maintainability,
argue against continuing to allow python code development in the
project.  I love python, but not enough to make 20+ people's lives
difficult.

There are already people making this sort of argument in our project.

                       JT

On 2/20/07, BJörn Lindqvist <bjou...@gmail.com> wrote:

Paul, thanks for this, I didn't realize the scope of the situation.  I
agree with your assessment to the extent that I understand what the
whole python 3.0 thing is about.

Let's see if I can scare up something I wrote about ten years ago on a
now-dead language that I really wanted to use (wound up sticking with
python instead because "it was supported" ;-)

=======================
to figure out how to work things.  The fact that there are three (or
four depending if you count Linz V4) different Oberon System
implementations, and several different compilers, and even four or
five separate dialects of Oberon with none of them appearing to be
really "official", gives the impression of a fragmented, directionless
development effort, and a probability bordering on 1.0000 that
whatever you try to do will be incompatible with all but a small
subset of what's available (unless you stick to writing small programs
like in the books.)  It does not matter if you tell people that this
is not so; something has to clearly stand out as being THE STANDARD
STUFF and all the other stuff as INTERESTING BUT NONTHREATENING SIDE
PROJECTS.  The STANDARD STUFF must include a sufficient number of
=========================

Oberon is really really cool, seriously, ... but nobody is using it.
People working on python development are of course free to do what
they want, but so are the users ...

So as a Python programmer, the path is clear. As soon as possible, you
should make your code compatible with Python 3.0. That will likely mean
taking advantage of some new features in Python 2.6, so "as soon as
possible" may still mean many years for projects that need to support
older versions of Python. Still, once Python 2.6 is installed everywhere
by default, it shouldn't be difficult to start making code compatible
with the new standard, Python 3.0.

[...]

The fortunate thing about different Python implementations and in
contrast to a lot of other languages and their implementations is that
the most actively developed Python implementation, CPython, is very
portable and is present on all major operating systems of consequence
(capable of running it). Other languages have suffered because there'd
be a UNIX version and then a version for Windows or the Mac which
wasn't as well maintained, or perhaps no version at all for one or
more of these platforms. So with Python, even if one implementation is
lagging behind (eg. Jython) there's still likely to be some deployment
solution on one's operating system of choice, given some level of
flexibility.

Where incompatibilities may arise with Python implementations is in
the level of support for recent language developments and additions.
Again, CPython's portability prevents this from becoming an operating
system issue, but we see rifts between implementations targeting
different runtime platforms, and whilst CPython 2.x and CPython 3.x
may continue to cover similar operating systems (although a desire to
drop support for various operating systems was stated), it's the rift
between them that presents the risk to any common notion of what
Python actually is.

"Then Python is pretty much determined to remove itself from
consideration from various kinds of international projects like the
one I work on [unless py3k is backwards compatible with python 2.x]."

You did not explain why this is so.

"if 2.4 code doesn't run on 3.0, it's rather likely that strong
pressure will be applied to port *away* from Python into something
less capricious."

Who are these people that are applying the strong pressure? How can
you run a international and seemingly very important project without
knowing basic things about how to handle versioning problems?

I mean, they would rather port this big system, deployed on thousands
of computers all over the world, to an entirely different programming
language than to continue using Python 2.x because Python 3.x, when it
is released, MIGHT cause them some problems several YEARS from now?

     http://www.python.org/dev/peps/pep-3000/

In brief:

* An alpha in the first half of 2007
* First real release in the first half of 2008

[ citing me ]

Underlying technology is a different story.  This should be reasonably
stable.  Small changes are inevitable but even these are a major pain,
since we have dependency links like the following:

  OS release links to
  Python release which changes an
  Third-party extension module which requires
  A third party library whose
  Version needs to be upgraded but which
  Is used by some other non-python means that
  Requires the earlier version.

Or the earlier problem, an OS upgrade comes with a new python version
on which existing code breaks.

The fraction of code in our system that's written in python is
something like 10% -- it's not a big pure-python system.

Now you're talking about major changes in the underlying technology,
forcing, at some point in the future, an extensive rewrite of the
python code.  Yes, at that point, some people would make the comment
that a language which changes to that extent by major versions is not
fit for production work, and if one was going to have to rewrite, it
would be better to rewrite in a more stable language.

And finally, remember the original post I replied to said that python
3.0 was determined not to be hampered by backwards compatibility.
This is quite a bit different than what you say here ("MIGHT cause
problems"):

You might also notice the built-in function "compile", which compiles text
strings into byte-code and puts it into a code object. The dis module may
also be of interest.

Note that I believe it will be many years, perhaps even a decade, before
"python" on a Unix system starts up Python 3.0.  Python 2.x will have at
least two releases after 3.0 gets released, and I can't imagine that any
OS will have "python" refer to 3.0 while 2.x is still under active
development or even for a while after.  I'd expect any OS to provide a
python3.
--
Aahz (a...@pythoncraft.com)           <*>         http://www.pythoncraft.com/

At least one commercial python app I work with installs it's own
completely independant version of python.  For many apps where
predictible behaviour is required you can install 'your' python,
under /opt/myapp or /usr/local/myapp or whatever instead of python,
python2.2, python3, etc.  The downside is that you'll waste another
15Mb harddrive space, and you'll need to update your internal source
tree 4 or 5 times when maintenance releases come out.

Apologies if this sounds like a rant, I really mean it in a
constructive way.

However, they did use the middleware installed on the system, and this
middleware is also partially written in python ... except it was
expecting the system python.  So you get into very tricky things
having to sanity check the PYTHONPATH, that the "user" python path is
not getting exported into middleware land, nor is the application's
desired PYTHONPATH being destroyed by middleware.  We had just such an
issue here last week, we had solved the problem for bourne shell
users, but csh for some reason had a different behavior, and the user
app could not longer find its python modules.

About the only code for which we don't seem to have these issues is
compiled C.  C++ is nasty because the compilers are still catching up
to the standard; the last I heard, a big segment of C++ code was stuck
because it was full of apparently illegal constructs that the previous
compiler (the g++ shipped stock with RHEL3) accepted, but the RHEL-4
native version refused to compile.

A colleague of mine pointed out today that this is an old problem, and
used to be handled by automake at compile time, with code full of
ifdefs ... now we've moved the problem to run time.  Which I think is
harder, because sometimes we don't find the problem until our binary
is halfway across the world ...

Hmm, I was expecting that that wouldn't always work, but:

 >>> x=3
 >>> if x==3: x
...
3
 >>> for i in range(x):
...   i
...
0
1
2