classification
Title: The pdb print command prints repr instead of str in python3
Type: behavior Stage: committed/rejected
Components: Library (Lib) Versions: Python 3.4
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: cdosborn, python-dev, r.david.murray
Priority: normal Keywords: easy, patch

Created on 2013-08-16 23:16 by r.david.murray, last changed 2013-10-10 21:47 by cdosborn. This issue is now closed.

Files
File name Uploaded Description Edit
18764.patch cdosborn, 2013-09-24 06:49
18764-docs.patch cdosborn, 2013-10-10 21:24
Messages (14)
msg195439 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-08-16 23:16
In 2.7:

>>> import pdb
>>> from email import message_from_string as m
>>> x = m("To: me\nfrom: you\n\ntest\n")
>>> pdb.set_trace()
--Return--
> <stdin>(1)<module>()->None
(Pdb) print x
From nobody Fri Aug 16 19:06:58 2013
To: me
from: you

test


In 3.4:

>>> import pdb
>>> from email import message_from_string as m
>>> x = m("To: me\nfrom: you\n\ntest\n")
>>> pdb.set_trace()
--Return--
> <stdin>(1)<module>()->None
(Pdb) print x
<email.message.Message object at 0xb707b92c>


Since the print command masks the print function, it is difficult (though
not impossible) to actually get the print representation of something:

(Pdb) print(str(x))
'To: me\nfrom: you\n\ntest\n'
(Pdb) not print(x)
To: me
from: you

test

True


Because print is a function rather than a statement in python3, it might be better to just drop the print command from pdb.  Someone working in Python3 is likely to type "print(...)" at the python3 pdb command line and expect it to work like the print function.
msg198149 - (view) Author: Connor Osborn (cdosborn) * Date: 2013-09-20 14:51
Should the pretty print behavior remain?
msg198150 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-09-20 15:42
Ah, that's a very good question.  So perhaps the print command should be renamed 'pprint'.

Anyone else have thoughts about the API?  Do we instead need to fix the print command, for backward compatibility reasons?
msg198352 - (view) Author: Connor Osborn (cdosborn) * Date: 2013-09-24 06:49
In 2.7 there is no documented command *print, the docs are explicit on this (it's just the built in statement). However, 3.4 treats print like a feature of 2.7. Is this to maintain backwards compatibility? I would suggest preserving the original direction of the pdb, where a user has access to a p command but a user can always use the built in python print function.

in short:
-remove print from documented commands
-remove print alias

*This is my first patch :P Let me know if this is the correct direction, and what needs to be changed for acceptance, thanks.
msg198358 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-09-24 14:07
Looks good to me.

This seems like a mistake in the python3 port to me.  I'm in favor of fixing it as a bug.  As release manager and pdb expert, what do you think, Georg?
msg199392 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-10-10 15:17
It occurs to me, looking at the docs, that there are doc changes also required for this patch.  And given that there are doc changes, this clearly can't be treated as a bug fix.

If there is no objection to fixing it in 3.4, though, I'd like to do that in the next few days.  This is not normally the kind of change that I'd advocate for, since it does break backward compatibility, but in this case I think the benefits outweigh the possible problems, since there are probably very few people who script pdb sessions.
msg199396 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2013-10-10 16:10
Though I can't speak regarding the patch, your justification for breaking backward compatibility seems good enough to me (but I may not be the best judge :).  However, backward compatibility is a funny thing.  I've spent not insignificant time thinking about it with regards to the import system and PEP 451 particularly.

The problem is that, while there may not be much code using a feature now, there may be people that start to use it later under an earlier system Python (e.g. 3.2 or 3.3).  Then when their system upgrades Python to 3.4 their code breaks.  So a backward incompatible change can have a more adverse impact than is measurable right now.  That's a subtle but significant reason behind our aversion to breaking backward compatibility, I've come to realize.

Of course, doing so is still an option if the benefit outweighs the risk/cost.  It sounds like you are comfortable with the risk here, and I trust your judgement. :)
msg199398 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-10-10 16:45
Well, I'm not certain, to tell you the truth.  

However, the only non-backward-incompatible change that will work is to introduce a new command that gives one access to the "real" print function, and that to me feels really really ugly and, if I may be somewhat hyperbolic, undignified.

In other words, I am willing to break this particular "feature" in a feature release as the price of restoring pdb's consistency with the python language and the history of the changes between python2 and python3...because it is primarily a UI change and not a change that affects programs (in the general case, at least).

It shouldn't depend on only my view though.  If Georg doesn't want to decide, we should put it out to python-dev.
msg199399 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2013-10-10 16:49
Sounds good.
msg199403 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2013-10-10 18:33
patch looks good for 3.4; I probably didn't realize that "p" uses repr  when I added "print".
msg199414 - (view) Author: Connor Osborn (cdosborn) * Date: 2013-10-10 21:24
Here is the documentation patch:

I defaulted to the docs that were in 2.7.5, by noting that beside the p command the builtin print function could be used.

I also fixed a small code sample that still used print ... syntax.
msg199417 - (view) Author: Roundup Robot (python-dev) Date: 2013-10-10 21:34
New changeset 592579b89d8c by R David Murray in branch 'default':
#18764: p(rint) -> p in pdb docs.
http://hg.python.org/cpython/rev/592579b89d8c
msg199419 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-10-10 21:38
I applied the patch (with doc and test changes) in d4d886620a00, before I saw your patch.  But your patch fixes the main 'p' docs, which I somehow missed, so I applied it, too.

So, thanks Connor, and I think this is done.

A couple notes if you are going to continue to contribute, which I hope you do: diffs from the root of the checkout are easier to apply (ideally, 'hg diff', or 'git diff' if you use the git mirror).  And, please submit a contributor agreement (http://www.python.org/psf/contrib).
msg199423 - (view) Author: Connor Osborn (cdosborn) * Date: 2013-10-10 21:47
I'm hoping to ease into more involvement. Thanks for the review and tips, and I submitted the agreement(e-sign version).
History
Date User Action Args
2013-10-10 21:47:39cdosbornsetnosy: - georg.brandl, ezio.melotti, eric.snow
messages: + msg199423
2013-10-10 21:38:00r.david.murraysetstatus: open -> closed
resolution: fixed
messages: + msg199419

stage: needs patch -> committed/rejected
2013-10-10 21:34:06python-devsetnosy: + python-dev
messages: + msg199417
2013-10-10 21:24:08cdosbornsetfiles: + 18764-docs.patch

messages: + msg199414
2013-10-10 18:33:53georg.brandlsetmessages: + msg199403
2013-10-10 16:49:18eric.snowsetmessages: + msg199399
2013-10-10 16:45:01r.david.murraysetmessages: + msg199398
2013-10-10 16:10:45eric.snowsetnosy: + eric.snow
messages: + msg199396
2013-10-10 15:17:05r.david.murraysetmessages: + msg199392
versions: - Python 3.3
2013-09-24 14:07:22r.david.murraysetmessages: + msg198358
2013-09-24 06:49:56cdosbornsetfiles: + 18764.patch
keywords: + patch
messages: + msg198352
2013-09-20 15:42:52r.david.murraysetmessages: + msg198150
2013-09-20 14:51:50cdosbornsetnosy: + cdosborn
messages: + msg198149
2013-08-17 13:21:58ezio.melottisetnosy: + georg.brandl, ezio.melotti
type: behavior
2013-08-16 23:16:30r.david.murraycreate