473,574 Members | 2,639 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Pep 3105: the end of print?

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



Feb 15 '07 #1
69 3203
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
Feb 15 '07 #2
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*******@chart er.net
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Feb 15 '07 #3
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.

Feb 15 '07 #4
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*******@chart er.net
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------
Feb 16 '07 #5
En Thu, 15 Feb 2007 22:04:34 -0300, Edward K Ream <ed*******@char ter.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

Feb 16 '07 #6
"Edward K Ream" <ed*******@char ter.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

Feb 16 '07 #7
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
Feb 16 '07 #8
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.

Feb 16 '07 #9
On 2/15/07, Edward K Ream <ed*******@char ter.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
Feb 16 '07 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

12
2389
by: Michael Foord | last post by:
Here's a little oddity with 'print' being a reserved word... >>> class thing: pass >>> something = thing() >>> something.print = 3 SyntaxError: invalid syntax >>> print something.__dict__ {}
1
2316
by: Steff | last post by:
I am wandering if my code is making sense... I use a lot the print function. Is it weird in this case where I have to display an array ? I thought it would be better to have the entire array in php but now I am not sure if that makes sense. Can you tell me please ? <html> <head>
0
8066
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. ...
0
8249
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that...
0
8106
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
0
6461
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
1
5631
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes...
0
3743
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in...
0
3755
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
1350
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
0
1066
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.