homepage

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.

Should the pretty print behavior remain?

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?

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.

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?

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.

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

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.

Sounds good.

patch looks good for 3.4; I probably didn't realize that "p" uses repr when I added "print".

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.

New changeset 592579b89d8c by R David Murray in branch 'default':
#18764: p(rint) -> p in pdb docs.
http://hg.python.org/cpython/rev/592579b89d8c 

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

I'm hoping to ease into more involvement. Thanks for the review and tips, and I submitted the agreement(e-sign version).