Using print in python 3 I would like to simple "replace" print with
pprint.pprint. However pprint cannot be called with no arguments, so
this cannot currently be done (the error is "TypeError: pprint() takes
at least 1 positional argument (0 given)").

A simple improvement is to allow no object to be passed in and pprint
would then print a newline rather than fail.

Another problem is that if you try this:

 print('hello', True)

and replace print with print, the second arg gets interpreted as the
"stream" parameter.


Both of the above can be fixed (I think) by changing pprint.py as follows:

instead of the current code:
def pprint(object, stream=None, indent=1, width=80, depth=None):

change to this:
def pprint(object='\n', *args, stream=None, indent=1, width=80, depth=None)

Sorry: you also need to print out the args! :) .. like this:

def pprint(object='\n', *args, stream=None, indent=1, width=80, depth=None):
    """Pretty-print a Python object to a stream [default is sys.stdout]."""
    printer = PrettyPrinter(
        stream=stream, indent=indent, width=width, depth=depth)
    printer.pprint(object)
    for arg in args:
        printer.pprint(arg)

I've included a patched version. I went with using a function signature
of def pprint(*object, stream=None, indent=1, width=80, depth=None)

Changing the signature of a well-used function is dangerous.
Why not add a function named pprint.print, with the exact same signature 
as __builtin__.print?

And use keyword-only arguments :)

Here’s a first draft at a patch.  I’ve added a module-level print function and a PrettyPrinter.print method which does the real work.

The functions have a signature compatible with print, but I have changed one default value: sep defaults to ',\n', because I think that the output is more useful and more pleasing (otherwise you’d have strange-looking indentation with containers).

If this looks good, I’ll work on doc and tests.  I guess I’ll reuse the helpers in test_print.

@Éric I'd be interested in using this as print/pprint are part of my debugging kit, so could you take this forward please?

Still waiting for a review.

I don't understand how this is supposed to work or what the point is. By construction, pprint prints a *single* object, and it will split the representation over several lines if necessary. Therefore the print() semantics (print several objects one after another, without linebreak) are incompatible with pprint.

Maybe pprint.print() should specify sep='\n' by default?

Antoine: the desired behavior is to have a function with the same signature as print (so multiple objects to print are supported), but which calls pprint.pformat instead of str.  It lets people monkey-patch builtins.print or somemodule.print with pprint.print and get nicer output.  (I rarely use print these days, as I work in web applications that use logging and responses, but in many other cases people use print and might want a quick way to make it pretty-print.)

> Antoine: the desired behavior is to have a function with the same
> signature as print (so multiple objects to print are supported), but
> which calls pprint.pformat instead of str.

But it can't work. pprint() uses all the width for a single object. How
are you supposed to print multiple objects?

> But it can't work. pprint() uses all the width for a single object.
> How are you supposed to print multiple objects?

On multiple lines?

> Amaury Forgeot d'Arc added the comment:
> 
> > But it can't work. pprint() uses all the width for a single object.
> > How are you supposed to print multiple objects?
> 
> On multiple lines?

But then, it doesn't have anything similar to print() except that it takes
multiple arguments (which is a very weak similarity). It can only be confusing
to name it print(), not to mention that shadowing builtins is generally
considered bad.

Overall, -1 from me.

> But then, it doesn't have anything similar to print()

It has the same signature.  Isn't that the point of the whole issue?

> > But then, it doesn't have anything similar to print()
> 
> It has the same signature.  Isn't that the point of the whole issue?

This is becoming stupid. How about making it the same signature as sum()
or max() too?

-1 from me as well. Such kind of debatable (in terms of usefulness and inclusion) things are usually better off being served by a custom function in user's code.

Closing as per Ezio's suggestion on #python-dev.

To clarify, the request seems reasonable to me, but the use cases are somewhat limited and it's not obvious what the best implementation should be.  Given that others are -1 on this, I suggested to close it rather than leaving it open and languishing.