Pep 3105: the end of print?

[Edward K Ream]

The pros and cons of making 'print' a function in Python 3.x are well
discussed at:

http://mail.python.org/pipermail/python-dev/2005-September/056154.html

Alas, it appears that the effect of this pep would be to make it impossible
to use the name 'print' in a backward compatible manner. Indeed, if a
program is to compile in both Python 2.x and Python 3.x, the print function
(or the print statement with parentheses) can not use the 'sep', 'end' and
'file' keywords. This in turn makes it impossible to support the effect of
print with trailing comma in Python 2.x programs while retaining the name
'print'.

The only workaround would be to define yet another function, with a name
*other* than 'print'. This function, say print2, can support whatever
features the implementer wants because it does not collide with the Python
2.x print statement.

In short, pep 3105 will *discourage* rather than encourage the use of the
name 'print'. Rather than invalidating most Python 2.x programs, it would
seem more graceful for Python 3.x to define a [your name here] function that
can be used in addition to, rather than to the exclusion of, print.

Edward

P.S. The existence of an automated translation script does not change the
situation described above in any way. At best, such a script could change
print statements to [your name here] functions, but the effect would still
be the elimination of the name 'print' in all programs that aim to support
Python 2.x and Python 3.x.

EKR

 

[Steven Bethard]

The pros and cons of making 'print' a function in Python 3.x are well
discussed at:

http://mail.python.org/pipermail/python-dev/2005-September/056154.html

Alas, it appears that the effect of this pep would be to make it impossible
to use the name 'print' in a backward compatible manner.

You could offer up a patch for Python 2.6 so that you can do::

from __future__ import print_function

and have the 'print' statement replaced by the 'print' function.

That said, why can't you use ``file.write()`` instead of ``print``?
While I use print quite frequently in interactive use, it's pretty much
nonexistent in all my real code.

STeVe

 

[Edward K Ream]

You could offer up a patch for Python 2.6 so that you can do::

from __future__ import print_function

This would only work for Python 2.6. Developers might want to support Python
2.3 through 2.5 for awhile longer

why can't you use ``file.write()`` instead of ``print``?

Precisely my point: pep 3105 will force the elimination of the name 'print'.

Edward

 

[massimo s.]

Isn't the very concept of major releases (1.x, 2.x, 3.x) that they
*can* be not backwards-compatible with previous releases?

m.

 

[Edward K Ream]

Isn't the very concept of major releases (1.x, 2.x, 3.x) that they *can*

be not backwards-compatible with previous releases?

Not at all. Backwards compatibility means that one can still run old code
provided the code eschews new features. Python releases have generally
been backwards compatible with previous releases, with a few minor
exceptions. For example, my app runs fine on Python 2.2.2 through Python
2.5, and little work was required to make this happen. In fact, my app
should run find on Python 3.x, but that's because it doesn't use print

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

Edward

 

[Gabriel Genellina]

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

print is nice, and has a few advantages (like its own opcode!), and I use
it a lot on the interactive interpreter, but I almost never use it in
production code.

 

[Ben Finney]

Not at all.

In the context of the question, this answer seems to say that a major
release *must* be backwards-compatible (i.e. "can [may] not be not
backwards-compatible").

Is that what you intend to say?

If so, I disagree strongly. I assert that a major release *may* be
backwards-incompatible, in well-defined ways. That's the only way to
get rid of some kinds of cruft.

So long as it's done in a well-documented way, with a change in major
version number, it's a reasonable way (probably the *only* reasonable
way) to remove particular kinds of cruft from any application -- even
if that application is a programming language.

 

[Steven Bethard]

This would only work for Python 2.6. Developers might want to support Python
2.3 through 2.5 for awhile longer

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
on 3.0 -- though there's a pretty large contingent trying to make this true.

In short, if you need to support 2.3, you're not ready to be looking at 3.0.

STeVe

 

[Steven D'Aprano]

Not at all. Backwards compatibility means that one can still run old code
provided the code eschews new features. Python releases have generally
been backwards compatible with previous releases, with a few minor
exceptions.

That's fine, but Python 3 has been explicitly stated to be where Python
will have backwards _in_compatible changes made.

That's not to say that all Python 2.x programs will break under Python 3,
but some surely will.

For example, my app runs fine on Python 2.2.2 through Python
2.5, and little work was required to make this happen. In fact, my app
should run find on Python 3.x, but that's because it doesn't use print

It's too early to say for sure what will run under Python 3, because it
hasn't been decided fully yet, but it is quite probable that it will still
compile and/or run and possibly even do what you intended.

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

I'm pretty sure you're mistaken. Python 3 will be the release that breaks
code. Hopefully very little, but there almost certainly will be some.

 

[Eduardo \EdCrypt\ O. Padoan]

Isn't the very concept of major releases (1.x, 2.x, 3.x) that they *can*
be not backwards-compatible with previous releases?

Not at all. [...]

It is the only intent of Python 3.0: be free of backward compatibity
constraints.
There are a tool called "2to3" that translates things like "print foo"
to print(foo).

 

[Edward K Ream]

In short, if you need to support 2.3, you're not ready to be looking at

3.0.

I hope this turns out not to be true. As a developer, I have no way to
force people to 3.0, and no reason to want to. For me, maintaining two
incompatible code bases is out of the question.

It will be interesting to see how this plays out. Users, not developers,
will determine when Python 2.x becomes extinct.

Edward

 

[Edward K Ream]

There are a tool called "2to3" that translates things like "print foo" to

print(foo).

The point of my original post was that if I want to maintain a common code
base the tool must translate 'print foo' to 'print2(foo)'.

Edward

 

[Edward K Ream]

I'm pretty sure you're mistaken. Python 3 will be the release that breaks

code. Hopefully very little, but there almost certainly will be some.

Pep 3105 breaks a *lot* of code, despite the bland assertion that most
production programs don't use print.

Presumably, Guido wanted to improve print in such a way that *more* people
would use it. But the effect of the pep is that *less* people will be able
to use print, *regardless* of how backward compatible Python 3.x is
'allowed' to be.

Edward

 

[Edward K Ream]

Is that what you intend to say?

I intended to say what I did say: "Python releases have generally been
backwards compatible with previous releases, with a few
minor exceptions." Imo, this is compatible with what you are saying.

So long as it's done in a well-documented way, with a change in major
version number, it's a reasonable way (probably the *only* reasonable way)
to remove particular kinds of cruft from any application.

Agreed.

Edward

 

[Fuzzyman]

I hope this turns out not to be true. As a developer, I have no way to
force people to 3.0, and no reason to want to. For me, maintaining two
incompatible code bases is out of the question.

It will be interesting to see how this plays out. Users, not developers,
will determine when Python 2.x becomes extinct.

As has been mentioned 3.0 will deliberately break backwards
compatibilit in a few ways in order to remove cruft and make changes
that *can't* be done any other way.

That said, the changing of print feels to me like gratutitous breakage
- but then I've never had the need to go through old code replacing
print with logging code (the need that Guido cites as the reasn for
the change).

There are various of the 3.0 changes being discussed for inclusion (or
at least support) in Python 2.6 so it might be possible to write code
that will run unchanged on Python 2.6 and 3.0. (That is *some* code -
nt arbitrary code.)

There is also the 2to3 converter. The aim is that this will be
effective enough that coders should be able to maintain a 2.X (2.6 ?)
codebase, run it through 2to3 and have the result run unchanged on
Python 3. That way there will be no need to maintain two code bases.

Also bear in mind that people using Python 3.0 will be aware that most
existing libraries won't work - and it will be a long time (2 to 3
yearsafter the release of 3.0 final ?) before the majority of Python
users have switched. This will provide plenty of time for migration
patterns and tools to be established.

Fuzzyman
http://www.voidspace.org.uk/python/articles.shtml

 

[Edward K Ream]

There is also the 2to3 converter. The aim is that this will be
effective enough that coders should be able to maintain a 2.X (2.6 ?)
codebase, run it through 2to3 and have the result run unchanged on
Python 3. That way there will be no need to maintain two code bases.

I have offered a proof that the converter must change print to print2 (or
some other name) in order to maintain a common code base. How much clearer
can I be? If a common code base is desired, it *is* the end of print

Edward

 

[Peter Otten]

effective enough that coders should be able to maintain a 2.X (2.6 ?)
codebase, run it through 2to3 and have the result run unchanged on
Python 3. That way there will be no need to maintain two code bases.

I have offered a proof that the converter must change print to print2 (or
some other name) in order to maintain a common code base. How much
clearer
can I be? If a common code base is desired, it *is* the end of print

There could be something like

from __future__ import print_function

to remove the print keyword in 2.x.

Peter

 

[Edward K Ream]

There could be something like from __future__ import print_function

To repeat: this would be compatible only with Python 2.6.

Edward

 

[Peter Otten]

To repeat: this would be compatible only with Python 2.6.

Indeed. Don't lose your nerves over that bunch of casual readers of your
thread

Peter

 

[Fuzzyman]

effective enough that coders should be able to maintain a 2.X (2.6 ?)
codebase, run it through 2to3 and have the result run unchanged on
Python 3. That way there will be no need to maintain two code bases.

I have offered a proof that the converter must change print to print2 (or
some other name) in order to maintain a common code base. How much clearer
can I be? If a common code base is desired, it *is* the end of print

Why won't it be possible to make 'print' in Python 3 that supports all
the functionality of the current print statement, and then translate
to that ?

I saw an assertion to the effect that it wasn't possible - but no
proof.

It sounds relatively straightforward for me...

Fuzzyman
http://www.voidspace.org.uk/python/articles.shtml