Pep 3105: the end of print?

[Steven D'Aprano]

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.

Python has a compiler, just like Java. That's where the .pyc files come
from.

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.

 

[Aahz]

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

Backwards compatibility is a consideration AND there will be problems.
That is, the goal of 3.0 is to lower the priority of backwards
compatibility enough to make some incompatible changes, but not to reduce
the priority of compatibility to zero. Just for example, "foo" will
become a Unicode string.

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.

 

[olsongt]

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 d evelopers 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

I don't know the specifics of your app, but why does everyone insist
that they need to use the 'system' python?

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.

-Grant

 

[Jay Tee]

I don't know the specifics of your app, but why does everyone insist
that they need to use the 'system' python?

Hey Grant, don't worry it's not a rant. A completely valid question.
Again it's a problem of dependency management ... one of the things
we've had to deal with is one of the applications : they have a
framework largely built in python, and I think they were indeed at one
point shipping their own python because they used features not present
in the "system" python.

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

JT

 

[sjdevnull]

Note that I believe it will be many years, perhaps even a decade, before
"python" on a Unix system starts up Python 3.0.

That's a pretty safe bet considering that the factory-installed
"python" on my Linux system is still 1.x and you run "python2" to get
2.x (I haven't done a new OS install in a couple of years, but 2.x had
been out for years when I did the install). And 2.x is much less
likely to break 1.x code than 3.x will be to break 2.x code.

 

[Peter Mayne]

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?

Because it's compatible between Python 2.x and Python 3.x?
Because without print as a keyword, I can say "print = sys.stdout.write"
and still have (some) convenience? (Albeit still one import and one
lookup, though given the probable time taken to do the I/O, why worry
about the lookup?) Or, if your editor has an abbreviation facility like
Eclipse, you can type sys.stdout.write with less than 5 keystrokes.

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

Why use print in the interactive interpreter? Just type the expression.

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

....
3

.... i
....
0
1
2

PJDM

 

[Steven D'Aprano]

Why use print in the interactive interpreter? Just type the expression.

Many reasons. Here are four:
(1, 2, 3)


I'm sure you can find your own examples.

 

[skip]

Jeff> My post was entitled "Python 3.0 unfit for serious work", you just
Jeff> indicated that the Linux distros will agree with me, in order to
Jeff> be taken seriously, the distros will have to include 2.x python
Jeff> for a very long time. If 3.0 and 2.x have any serious degree of
Jeff> incompatibility, python will be a favorite subject for religious
Jeff> rants and heated arguments for many people.

The notion that Python 3.0 was going to fix design/implementation issues in
earlier versions of Python and thus cause some breakage has been known for a
long time, at least since Guido's UK Python talk in March 2003. Python 2.x
released will continue to be created for some time after Python 3.0 is
released. From PEP-3000:

I expect that there will be parallel Python 2.x and 3.x releases for
some time; the Python 2.x releases will continue for a longer time than
the traditional 2.x.y bugfix releases. Typically, we stop releasing
bugfix versions for 2.x once version 2.(x+1) has been released. But I
expect there to be at least one or two new 2.x releases even after 3.0
(final) has been released, probably well into 3.1 or 3.2. This will to
some extend depend on community demand for continued 2.x support,
acceptance and stability of 3.0, and volunteer stamina.

The whole intention is to give authors a long period of time to port to
Python 3.x. I believe your fear is just a knee jerk reaction to the notion
that there will be some stated incompatibilities between 2.x and 3.x without
having done any investigation of the transition process. Nobody is forcing
you to do anything right now or completely abandon your code base. Python
2.x still has a long shelf life. Hell, 3.0a1 isn't even out yet. If you
hang on for a few days I'm sure Guido's keynote about Python 3 from the
PyCon just wrapping up in Dallas will be available online. There might be
something in there of interest to you. If you poke around a bit you will
probably find nearly live blogs from the conference as well.

Skip

 

[=?ISO-8859-15?Q?=22Martin_v=2E_L=F6wis=22?=]

In other words, the consequence of pep 3105 will be that *nobody* who wants
their app to be portable will be able to use print until *everybody* has
converted to Python 3.x. I doubt that is what Guido had in mind, but I may
be mistaken

That's not true. Many uses of print work just fine whether print is a
function. For example, from the standard library:

quopri.py: print "-t: quote tabs"
can be rewritten as
print("-t: quote tabs")


shlex.py: print 'shlex: reading from %s, line %d' \
% (self.instream, self.lineno)
can be rewritten as
print('shlex: reading from %s, line %d' \
% (self.instream, self.lineno))

So people can rewrite their code so that it uses print, and still works
in both Python 1.5 and 3.0.

Of course, there are many uses that cannot be converted this way, but
it's not true that *nobody* who want there app to be portable will be
able to use print until *everybody* has converted to Python 3.x.

Regards,
Martin

 

[Jay Tee]

Hey,

Python 3.x. I believe your fear is just a knee jerk reaction to the notion
that there will be some stated incompatibilities between 2.x and 3.x without
having done any investigation of the transition process. Nobody is forcing
you to do anything right now or completely abandon your code base. Python
2.x still has a long shelf life. Hell, 3.0a1 isn't even out yet. If you

Thanks to the pointer to PyCon, if there is anything relevant maybe
you can send me off a mail (or post here) with some links. About the
above : it isn't fear, I'm just telling you what I suspect might
happen. My own little piece of code in the giant picture will remain
in python, unless i am mandated to move it to something else : I
*like* python.

I threw in my few cents here just because I suspect the python
community does not intend to move itself into the realm of
"interesting but not serious languages" like Oberon did. I could be
wrong, both in the sense that maybe that *is* the intention, or maybe
making a backwards-incompatible "evolution" of the language won't hurt
python or it's users. We now return to your regularly scheduled
program.

J "back to the grind" T