Pep 3105: the end of print?

[Klaas]

pass
except (ImportError, SyntaxError):
# python 3.0
print2 = print
SyntaxError: invalid syntax

Any and all aliasing must happen in compat26.py. My suggested solution is this:

Good catch. Point is that it is not impossible.

-mike

 

[Hendrik van Rooyen]

Jean-Paul Calderone wrote:
Right. Let's call Python 3.0 something different but related. How about
"snake oil"? ;-)

I kind of like this idea - it means that the initiates can go on caravan tours
of America, selling it as a panacea for all ills, IT related or not...

A whole new industry.

- Hendrik

 

[Peter mayne]

If Python 3 dropped the print
statement and replaced it with official_print_function(), how would that
help you in your goal to have a single code base that will run on both
Python 2.3 and Python 3, while still using print?

Is there any reason why official_print_function isn't sys.stdout.write?

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.

PJDM

 

[Steven D'Aprano]

Is there any reason why official_print_function isn't sys.stdout.write?

Why would you want a convenience function like print to take one import,
three look-ups and 16 characters instead of always available, one look-up
and five characters?

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.

print is important for the convenience, for short-lived debugging, and for
use in the interactive interpreter.

 

[Jay Tee]

Yo,

Python 3.0 is determined not to be hampered by backwards incompatibility
concerns. It's not even clear yet that your average 2.6 code will work

Then Python is pretty much determined to remove itself from
consideration
from various kinds of international projects like the one I work on.
We're already catching flack from people due to a few things that were
valid
in 2.2 that are not valid in 2.3 (I don't have the details but could
scare them
up). The project we work on contains code from many different people
and has to
run on thousands of computers all over the world. The installed base
at the
moment is a mix of RHEL 3, RHEL 4, and Debian, with a few other
machines thrown in.
The relevant Python versions at this moment IIRC are 2.2.3 and 2.3.4,
because these
are the native versions on those platforms.

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.

Bottom line: practicality and beauty is always a tradeoff. Oberon is
the most beautiful
language I ever saw, but there is almost nobody using it any more.
Too many beauty contests over who had the best proposal for a standard
library.

 

[Steven Bethard]

Yo,



Then Python is pretty much determined to remove itself from
consideration
from various kinds of international projects like the one I work on.

You snipped the rest of that comment:

"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

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.

Well, Python 2.4 code will work on Python 2.6 and 2.7 so just because
your code isn't yet compatible with Python 3.0 doesn't mean you should
give up on Python.

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?

STeVe

 

[Jay Tee]

Hi,

You snipped the rest of that comment:

"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."

Thanks for pointing this out. I voted for the comp.lang.python
newsgroup back in the early 90's, my active days of python
'development' are over, it's all i can do to hang on to the code i've
been posting about.

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?

As long as when python 3.0 shows up, i don't have to do a massive
rewrite. I think I've really only had to change two or three things
over the years .. one was that I used to use words like "dict" and
"list" in my code, which broke in subtle ways when d = dict() became
legal.

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.

JT

 

[=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=]

What a load of bull crap. Python is one of the simplest packages to
have multiple version of installed. When Python 3.0 is released, all
Linux distros will acquire a symlink at /usr/bin/python2 pointing to
the latest Python 2.x version installed. Or something equivalent.
Rest assured that Linux distributors will not drop Python 2.x support
in the nearest decade. They are not stupid.

 

[Paul Boddie]

Well, Python 2.4 code will work on Python 2.6 and 2.7 so just because
your code isn't yet compatible with Python 3.0 doesn't mean you should
give up on Python.

Perhaps the most important concern in the context of Python 3.0 is
what the term "Python" will come to mean to the different communities
using the language. Some people will be maintaining software that
needs to be compatible with older releases; these people aren't
technologically backwards: they just find that such older releases
provide sufficient capabilities for the implementation of their
solutions. For such people, "Python" will be the language they've
always used, with a gradual accumulation of features, some known
quirks, and some relatively minor incompatibility issues over the
years.

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.

Paul

 

[Jeff Templon]

yo,

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

 

[Jay Tee]

Hi,

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 ...

J "actie-reactie is what my ex-brother-in-law would say" T

 

[Steven Bethard]

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
=========================

Well, the problem of multiple standards shouldn't really apply in the
same way to Python. Right now, Python 2.X is the standard. Python 2.6,
2.7 and any later 2.X versions are intended to be transitional versions
while the standard is migrating to Python 3.X. At some point, the 2.X
line will almost certainly be discontinued.

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.

STeVe

 

[Paul Boddie]

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.

I don't know if I've delimited the scope of any situation, really.
However...

[...]

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",

[...]

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.

Paul

 

[=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=]

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.

This is why I said that your post was a load of bull crap:

"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?

 

[John Nagle]

So as a Python programmer, the path is clear. As soon as possible, you
should make your code compatible with Python 3.0.

There's always the possiblity that Python 3 won't happen. Look at
what happened with Perl 6. That's been talked about for
seven years now. The user base just wasn't interested.
Perl 5 was good enough, and users migrated to PHP for the
little stuff and other languages for the bigger stuff.
As Wikipedia says, "As of 2007, Perl 6 was still under development,
with no planned completion date."

John Nagle

 

[Paul Rubin]

There's always the possiblity that Python 3 won't happen. Look at
what happened with Perl 6. That's been talked about for
seven years now. The user base just wasn't interested.
Perl 5 was good enough, and users migrated to PHP for the
little stuff and other languages for the bigger stuff.
As Wikipedia says, "As of 2007, Perl 6 was still under development,
with no planned completion date."

I like to think PyPy will replace CPython as the main Python
implementation. Python 3.0 can then fork the language fairly
radically, like C++ vs C (ok, not so attractive an example) or Scheme
vs Lisp. Both dialects would stay active.

It seems to me that the flavor of Python programming has changed
significantly over the past few releases. That trend will likely
continue and even accelerate.

 

[Steven Bethard]

> So as a Python programmer, the path is clear. As soon as possible, you
> should make your code compatible with Python 3.0.

There's always the possiblity that Python 3 won't happen.

That's not really a possibility. Unlike Perl 6, Python 3 is not a new
language. And you can see Guido's release plan here:

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

STeVe

 

[John Nagle]

I like to think PyPy will replace CPython as the main Python
implementation.

Well, something faster really should take over. It's a bit
embarassing that the main implementation of Python is still a
pure interpreter. Even Javascript has a JIT compiler now.
And it's tiny, under 1MB.

John Nagle

 

[greg]

It's a bit
embarassing that the main implementation of Python is still a
pure interpreter. Even Javascript has a JIT compiler now.

Pure interpreted Python has always seemed more responsive
to me than any Java application I've tried to use. So I
can't help feeling that this JIT business is over-hyped.

 

[Jay Tee]

[ citing me ]

"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?

This isn't versioning. At least not the way I see it. Versioning has
to do with changes in your own product. Indeed one needs to know how
to handle it. Lately our project has been doing OK on this front, a
couple years ago was a different story.

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"):

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?

If backwards compatibility is not a consideration, then it would be a
miracle if there were no problems.

JT