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/pyt...er/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
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Steven Bethard]

Edward K Ream wrote:

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

http://mail.python.org/pipermail/pyt...er/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
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[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
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Gabriel Genellina]

En Thu, 15 Feb 2007 22:04:34 -0300, Edward K Ream <ed*******@charter.net>
escribió:

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.

--
Gabriel Genellina

[Ben Finney]

"Edward K Ream" <ed*******@charter.netwrites:

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.

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.

--
\ "To stay young requires unceasing cultivation of the ability to |
`\ unlearn old falsehoods." -- Robert Anson Heinlein |
_o__) |
Ben Finney

[Steven Bethard]

Edward K Ream wrote:

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

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]

On Thu, 15 Feb 2007 19:04:34 -0600, Edward K Ream wrote:

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

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

[Eduardo \EdCrypt\ O. Padoan]

On 2/15/07, Edward K Ream <ed*******@charter.netwrote:

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

--
EduardoOPadoan (eopadoan->altavix::com)
Bookmarks: http://del.icio.us/edcrypt

[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 email: ed*******@charter.net
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[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 email: ed*******@charter.net
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[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 email: ed*******@charter.net
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[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
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Fuzzyman]

On Feb 16, 11:54 am, "Edward K Ream" <[e-mail]:

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.

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
--------------------------------------------------------------------
Edward K. Ream email: [e-mail]
Leo:http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[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
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Peter Otten]

Edward K Ream wrote:

>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

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
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Peter Otten]

Edward K Ream wrote:

> There could be something like from __future__ import print_function

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]

On Feb 16, 12:47 pm, "Edward K Ream" <[e-mail]:

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

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

Edward
--------------------------------------------------------------------
Edward K. Ream email: [e-mail]
Leo:http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Edward K Ream]

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.

As discussed in the original post, the problem is the reverse: the Python
2.x print statement does not support the keyword args required by the pep,
so that print(foo) **in Python 2.x** can not simulate the effect of the
print statement with a trailing comma. Here is the theorum carefully stated
and proved.

Theorem: is not possible to define a function called print in Python 3.x
such that

A) print (whatever) is syntaxtically valid in Python 2.x and

B) print(whatever) outputs what 'print whatever' outputs in Python 2.x for
all values of 'whatever'.

Proof:

It is impossible for the print function to simulate the effect of the print
statement with a trailing comma. Indeed, print ('line'), and print
('line',) (note the position of the commas) are valid in Python 2.x, but
neither does what is wanted. And print('line',end='') is invalid in Python
2.x. Let's look at some examples:

1. The following works (prints 'line after\n') in Python 2.x, but will not
suppress the newline in Python 3.x:

print('line'),
print('after')

2. The following doesn't work in Python 2.x. (It prints
"('line',)\nafter").

print ('line',)
print ('after')

3. print ('line',end='') produces a syntax error in Python 2.x:

print ('line',end='')
^
SyntaxError: invalid syntax

That's the proof. Can you find a flaw in it?

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Roel Schroeven]

Edward K Ream schreef:

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

AFAIK the intention is not primarily to get more people to use print.
Instead Guido has felt for some time that the print statement is a wart
in the language (see the references in PEP 3105 for his arguments), and
Python 3000 seems like a good opportunity to fix it once and for all.
Precisely because AFAIK the point of Python 3000 is to fix a number of
long-standing shortcomings, even if that means giving up a degree of
backward compatibility.

--
If I have been able to see further, it was only because I stood
on the shoulders of giants. -- Isaac Newton

Roel Schroeven

[Roel Schroeven]

Edward K Ream schreef:

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

At first sight it seems to me that it's pretty straightforward to
translate print(foo) to print2(foo) once "2to3" has done its job.

It looks your main issue is that you're complaining that Python 3000 is
going to break things in a non-backward compatible way. If you want to
change that, you're going to be fighting an uphill battle, as this quote
from PEP 3000 illustrates:

"We need a meta-PEP to describe the compatibility requirements. Python
3000 will break backwards compatibility. There is no requirement that
Python 2.9 code will run unmodified on Python 3.0.

I'm not sure whether it is reasonable to require that Python 2.x code
can be mechanically translated to equivalent Python 3.0 code; Python's
dynamic typing combined with the plans to change the semantics of
certain methods of dictionaries, for example, would make this task
really hard. However, it would be great if there was some tool that did
at least an 80% job of translation, pointing out areas where it wasn't
sure using comments or warnings. Perhaps such a tool could be based on
something like Pychecker."

--
If I have been able to see further, it was only because I stood
on the shoulders of giants. -- Isaac Newton

Roel Schroeven

[Steven D'Aprano]

On Fri, 16 Feb 2007 06:07:42 -0600, Edward K Ream wrote:

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

I don't think Guido cares about _how many_ people use print. I think he
cares about making print better. If that leads to more people using it,
that's a bonus. But your and my guesses about what Guido cares about
aren't terribly important.

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.

I don't think that follows at all. print is only a problem if you expect
your code to work under both Python 2.x and 3.x. I wouldn't imagine
that many people are going to expect that: I know I don't. There are
likely to be a whole lot of things which change, sometimes radically, from
one to the other. They'll support one or the other, or fork the code, or
in extreme cases take over maintenance of Python 2.x (it is open source,
you can do that).

If you want to "future-proof" your Python code, well, you can't fully
because nobody yet knows all the things which will change. But you can
start by not calling print directly. There are a number of alternatives,
depending on what you're doing. Here's a simple function that does very
close to what print currently does:

def print_(*args, where=None, newline=True):
if where is None:
where = sys.stdout
args = [str(arg) for arg in args]
where.write(' '.join(args))
if newline:
where.write('\n')

--
Steven.

[Fuzzyman]

On Feb 16, 2:01 pm, "Edward K Ream" <[e-mail]:

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.

As discussed in the original post, the problem is the reverse: the Python
2.x print statement does not support the keyword args required by the pep,
so that print(foo) **in Python 2.x** can not simulate the effect of the
print statement with a trailing comma. Here is the theorum carefully stated
and proved.

Theorem: is not possible to define a function called print in Python 3.x
such that

A) print (whatever) is syntaxtically valid in Python 2.x and

B) print(whatever) outputs what 'print whatever' outputs in Python 2.x for
all values of 'whatever'.

Proof:

It is impossible for the print function to simulate the effect of the print
statement with a trailing comma. Indeed, print ('line'), and print
('line',) (note the position of the commas) are valid in Python 2.x, but
neither does what is wanted. And print('line',end='') is invalid in Python
2.x. Let's look at some examples:

1. The following works (prints 'line after\n') in Python 2.x, but will not
suppress the newline in Python 3.x:

print('line'),
print('after')

2. The following doesn't work in Python 2.x. (It prints
"('line',)\nafter").

print ('line',)
print ('after')

3. print ('line',end='') produces a syntax error in Python 2.x:

print ('line',end='')
^
SyntaxError: invalid syntax

That's the proof. Can you find a flaw in it?

I mentioned the 2to3 translator- the goal of which is *precisely* to
allow you to write code that will run on Python 2.X and when
translated run under Python 3.0.

You then repeated the problem with the 'print' statement.

It may be true that you won't be able to write code that runs
untranslated on 2 and 3. That doesn't stop you writing code for Python
2.X, then translating a version for Python 3. (Uhm... indeed that's
the point of 2to3.)

So you only have one codebase to maintain and you can still use
print...

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

Edward
--------------------------------------------------------------------
Edward K. Ream email: [e-mail]
Leo:http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Edward K Ream]

print is only a problem if you expect your code to work under both Python

2.x and 3.x.

Exactly.

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Stefan Rank]

on 16.02.2007 13:02 Edward K Ream said the following:

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

I think you are misunderstanding the purpose of the 2to3 tool.
It is supposed to create a new version of the code that runs on py3,
while you can still run your *"old"* code on py2.x

There won't be a common code base for all python versions.
You will have to decide at what point you want to switch from developing
the 2.x code (and using the 2to3 tool to support py3) to developing the
py3 code.

(You might then develop a 3to2 tool, but I think this discussion is
getting way ahead of its time. ;-)

[Edward K Ream]

It looks your main issue is that you're complaining that Python 3000 is
going to break things in a non-backward compatible way.

No. My complaint is *only* that changing the meaning of 'print' is needless
pain.

Edward

--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Steven D'Aprano]

On Fri, 16 Feb 2007 08:01:11 -0600, Edward K Ream wrote:

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

As discussed in the original post, the problem is the reverse: the Python
2.x print statement does not support the keyword args required by the pep,
so that print(foo) **in Python 2.x** can not simulate the effect of the
print statement with a trailing comma. Here is the theorum carefully stated
and proved.

Theorem: is not possible to define a function called print in Python 3.x
such that

A) print (whatever) is syntaxtically valid in Python 2.x and

B) print(whatever) outputs what 'print whatever' outputs in Python 2.x for
all values of 'whatever'.

[snip]

That's the proof. Can you find a flaw in it?

No, but it doesn't matter. There's no particular reason why you have to
write "print (whatever)" in your code. What you need is *some function*
that is capable of duplicating the functionality of print, which can be
used under Python 2.x and 3. It isn't hard to write a function that will
duplicate print's functionality, so long as you give up the requirement
that it is called just like print.

The problem you describe with the print syntax only is a problem if you
insist on supporting Python 2.x and 3 from the same codebase. I don't
expect many people will try to do that. For those who do, don't use the
print syntax. As for the rest of us, we'll just continue to use print
using whichever syntax is appropriate.

--
Steven.

[Steven D'Aprano]

On Fri, 16 Feb 2007 06:42:55 -0800, Fuzzyman wrote:

I mentioned the 2to3 translator- the goal of which is *precisely* to
allow you to write code that will run on Python 2.X and when
translated run under Python 3.0.

Unfortunately, that is not a realistic goal for the 2to3 translator. The
goal is to accurately translate 80% of Python code that needs changing,
and issue warnings for the other 20%.

You then repeated the problem with the 'print' statement.

It may be true that you won't be able to write code that runs
untranslated on 2 and 3. That doesn't stop you writing code for Python
2.X, then translating a version for Python 3. (Uhm... indeed that's
the point of 2to3.)

So you only have one codebase to maintain and you can still use
print...

No, you have TWO sets of code. You have the code you write, and the code
you have run through 2to3. Even if 2to3 gives you 100% coverage, which it
won't, you still have two codebases.
--
Steven.

[Edward K Ream]

So you only have one codebase to maintain and you can still use print...

Not if the theorum is correct.

It may be true that you won't be able to write code that runs
untranslated on 2 and 3.

That's my definition of a common code base. That is the content of the
theorum.

That doesn't stop you writing code for Python
2.X, then translating a version for Python 3. (Uhm... indeed that's the
point of 2to3.)

That is not what I would call a common code base. The developer would have
to run the translater every time the code changed. And if the Python 3.0
code were considered the 'master' code, the developer would need a 3to2
translater.

Either disprove the theorum or give up the notion of having a common code
base that uses print.

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Edward K Ream]

>That's the proof. Can you find a flaw in it?

No, but it doesn't matter. There's no particular reason why you have to
write "print (whatever)" in your code. What you need is *some function*
that is capable of duplicating the functionality of print,

Precisely wrong. The title of this thread is 'the end of print', and the
whole point of my comments is that spelling matters.

I would have absolutely no objection to the pep if it specified some other
name for an 'official' print function. Pick any name, preferably longer
than two characters, that does not conflict with either an existing global
function or module.

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Fuzzyman]

On Feb 16, 2:54 pm, Steven D'Aprano
<[e-mail]:

On Fri, 16 Feb 2007 06:42:55 -0800, Fuzzyman wrote:

I mentioned the 2to3 translator- the goal of which is *precisely* to
allow you to write code that will run on Python 2.X and when
translated run under Python 3.0.

Unfortunately, that is not a realistic goal for the 2to3 translator. The
goal is to accurately translate 80% of Python code that needs changing,
and issue warnings for the other 20%.

Right, but it *was* a stated aim of the translator when discussed on
Python-dev recently.

You then repeated the problem with the 'print' statement.

It may be true that you won't be able to write code that runs
untranslated on 2 and 3. That doesn't stop you writing code for Python
2.X, then translating a version for Python 3. (Uhm... indeed that's
the point of 2to3.)

So you only have one codebase to maintain and you can still use
print...

No, you have TWO sets of code. You have the code you write, and the code
you have run through 2to3. Even if 2to3 gives you 100% coverage, which it
won't, you still have two codebases.

Only one of which you maintain - if the translator works 100% (which I
accept may be unrealistic).

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

--
Steven.

[Fuzzyman]

On Feb 16, 3:00 pm, "Edward K Ream" <[e-mail]:

So you only have one codebase to maintain and you can still use print...

Not if the theorum is correct.

It may be true that you won't be able to write code that runs
untranslated on 2 and 3.

That's my definition of a common code base. That is the content of the
theorum.

Ok - in which case it is very limited.

That doesn't stop you writing code for Python
2.X, then translating a version for Python 3. (Uhm... indeed that's the
point of 2to3.)

That is not what I would call a common code base.

But it is what I call a common code base. We are at an impasse. :-)

The developer would have
to run the translater every time the code changed. And if the Python 3.0
code were considered the 'master' code, the developer would need a 3to2
translater.

Either disprove the theorum or give up the notion of having a common code
base that uses print.

Yes the use of print is changing in a backwards incompatible way, no
one is disputing that.

Personally I wish it wasn't, print 'feels like a statement' to me. But
it's not the end of the world and it is *definitely* going to be able
to be handled by 2to3.

It's also not about to change.

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

Edward
--------------------------------------------------------------------
Edward K. Ream email: [e-mail]
Leo:http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Steven D'Aprano]

On Fri, 16 Feb 2007 09:07:02 -0600, Edward K Ream wrote:

>>That's the proof. Can you find a flaw in it?

No, but it doesn't matter. There's no particular reason why you have to
write "print (whatever)" in your code. What you need is *some function*
that is capable of duplicating the functionality of print,

Precisely wrong.

Are you trying to say that the name "print" is more important to you
than the functionality?

If not, then I have no idea why you say I'm wrong.

The title of this thread is 'the end of print', and the
whole point of my comments is that spelling matters.

That might be the point you are trying to make, but you haven't succeeded.

I would have absolutely no objection to the pep if it specified some other
name for an 'official' print function. Pick any name, preferably longer
than two characters, that does not conflict with either an existing global
function or module.

Huh? Now you're just not making sense. 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?

In software development there is a common saying: "Good, Fast, Cheap --
Pick any two". The same holds here:

Keep the print name;
Keep the print functionality;
Keep a single code base.

Pick any two.

--
Steven.

[Edward K Ream]

Keep the print name;

Keep the print functionality;
Keep a single code base.

Retain the print statement and its functionality, and define an
official_print_function to be used in the common code base. I would be
satisfied with this (it's what I do now), and it would cause no needless
problems for anyone. Having an official print function is a *good* idea,
provided it isn't called print :-)

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Steve Holden]

Jean-Paul Calderone wrote:

On Sat, 17 Feb 2007 01:32:21 +1100, Steven D'Aprano

>[snip]

I don't think that follows at all. print is only a problem if you expect
your code to work under both Python 2.x and 3.x. I wouldn't imagine
that many people are going to expect that: I know I don't.

I think some people are confused that the language "Python 3.x" has "Python"
in its name, since there is already a language with "Python" in its name,
with which it is not compatible.

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

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Blog of Note: http://holdenweb.blogspot.com
See you at PyCon? http://us.pycon.org/TX2007

[Tobias Brox]

[Edward K Ream]

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.

2.2 -2.5 is a minor step, the 2.2-code should in general work out on
2.5 without problems.

2.6 -3.0 will be a major step, and code written for 2.6 or earlier
will in general not run on python 3.0. Hopefully this issue can be
partially solved by automatic code converting.

--
Tobias Brox, 69°42'N, 18°57'E

[Klaas]

On Feb 16, 6:01 am, "Edward K Ream" <[e-mail]:

That's the proof. Can you find a flaw in it?

Casting this in terms of theorem proving only obfuscates the
discussion.

Here is how to maintain a single codebase for this feature:

1. Convert all your print statements to 3.0 print functions, named
something else (say, print2())
2. define a module called compat26 containing:

def print2(*args, **kwargs):
# code to convert the above to print statements (better still,
sys.stdout.write())

3. in your code:
try:
from compat26 import print2
except (ImportError, SyntaxError):
# python 3.0
print2 = print

-Mike

[Sam]

On 16 Feb 2007 13:48:29 -0800, Klaas <mi********@gmail.comwrote:

3. in your code:
try:
from compat26 import print2
except (ImportError, SyntaxError):
# python 3.0
print2 = print

Python 2.5c1 (r25c1:51305, Aug 17 2006, 10:41:11) [MSC v.1310 32 bit
(Intel)] on win32
Type "copyright", "credits" or "license()" for more information.

>>try:

from compat26 import print2
except (ImportError, SyntaxError):
# python 3.0
print2 = print
SyntaxError: invalid syntax

>>try:

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:

#_compat30.py
print2 = print

#compat.py
try:
from _compat30 import print2
except SyntaxErorr, ImportError):
def print2():
....

--Sam

[Klaas]

On Feb 16, 2:31 pm, Sam <[e-mail]:

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]

"Steve Holden" <st***@holdenweb.comwrote:

Jean-Paul Calderone wrote:

I think some people are confused that the language "Python 3.x" has "Python"
in its name, since there is already a language with "Python" in its name,
with which it is not compatible.

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]

Steven D'Aprano wrote:

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]

On Tue, 20 Feb 2007 00:44:24 +0000, Peter mayne wrote:

Steven D'Aprano wrote:

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

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

[Jay Tee]

Yo,

On Feb 16, 6:07 am, Steven Bethard <[e-mail]:

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]

Jay Tee wrote:

Yo,

On Feb 16, 6:07 am, Steven Bethard <[e-mail]:

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

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,

On Feb 20, 8:59 pm, Steven Bethard <[e-mail]:

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.

On 20 Feb 2007 08:49:10 -0800, Jay Tee <je**********@gmail.comwrote:

Yo,

On Feb 16, 6:07 am, Steven Bethard <[e-mail]:

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.

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

--
mvh Björn

[Paul Boddie]

Steven Bethard wrote:

>
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

On 2/20/07, BJörn Lindqvist <bj*****@gmail.comwrote:

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.