On 7/21/2020 7:36 PM, Rob Cliffe wrote:


On 21/07/2020 21:00, Eric V. Smith wrote:
f-strings call PyObject_Repr directly, without going through builtins.

If we added !p as described here, we'd need to call import every time we execute !p, because we don't know if it's been imported yet. At runtime, we'd call "pformat()" via sys.modules['pprint'] after the import. That could of course be monkey patched.

But I'm still not sure this is a good idea. I can't find the issue on bpo where this was mentioned, but some of the issues that spring to mind are:

- Most pprint output is multi-line. Is that a good thing with f-strings?
Why not?  f-strings (as of course you know) can already contain multiple lines, even if the usage is not frequent.  ISTM this objection has no substance.
But with pprint, it's not unusual, it's common. That feels qualitatively different to me.

- How to handle parameters to pprint.pformat()?
This doesn't seem insurmountable.  IIUC the relevant parameters are indent, width, depth, compact, sort_dicts.  They could be added after `!p` separated by some separator - let's say comma for the sake of argument - with absent parameters taking the default values.  So e.g.
    !p2        # means indent=2
    !p,60    # means width=60.  Etc.
If the pformat API were ever changed, adding extra parameters would not cause backward incompatibility.  Removing parameters or changing their order would, but both seem extremely unlikely to me (YMMV) and I expect users of !p could live with that.

I can't support embedding all of these params in the format string. Format strings are hard enough to understand as it is.

At this point, you'd be better off with calling pprint.pformat() explicitely.

f'value={pprint.pformat(value, indent=2, width=60)}'

I might be able to get behind sort of a "pprint context", like a decimal context, with a context manager to specify it.


- Is pprint.pformat() extensible enough? Can an object control how it is pretty printed?
I'm not sure if I fully understand this objection.  It seems to be suggesting a deficiency in the current pprint.pformat.  The proposal would not change anything here.
I'm not super familiar with pprint, but IIRC an object can't specify its own formatting, can it? If I wrote a dict-like object, not inheriting from dict, and I wanted to control how it's pprint'ed, can I do that?

I'm sure there are others.
Could you specify.?
I'll try and find the issues to see what else Raymond and I already wrote.

I'm not saying I'm +1 on the proposal.  Just that there don't seem to be any insurmountable obstacles to it.  My greatest unease is an implicit import.  Are there other areas of Python where this happens?

I'm not sure. But this part doesn't really bother me. Maybe it should, and it would be another reason not to move forward!

Eric

As I've said before, I'd prefer a revamped "pretty formatting" library, probably using singledispatch for extensibility. But even with that, issues like parameterizing the output remain.

Eric


On Tue, Jul 21, 2020 at 8:04 PM Rob Cliffe via Python-ideas <python-ideas@python.org> wrote:
That seems like a nice idea, but what would happen if pprint had not
been imported?  NameError?
Rob Cliffe

On 16/07/2020 05:34, Charles Machalow wrote:
> Right now in str.format(), we have !s, !r, and !a to allow us to call str(), repr(), and ascii() respectively on the given expression.
>
> I'm proposing that we add a !p conversion to have pprint.pformat() be called to convert the given expression to a 'pretty' string.
>
> Calling
> ```
> print(f"My dict: {d!p}")
> ```
>
> is a lot more concise than:
>
> ```
> import pprint
> print(f"My dict: {pprint.pformat(d)}")
> ```
>
> We may even be able to have a static attribute stored to change the various default kwargs of pprint.pformat().

_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/UUZLIVS67PU552IMRNP6JBNC5LHACVQ2/
Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/I5PLO5FUYMX45EXEENZF56PAPYJBC7QM/
Code of Conduct: http://python.org/psf/codeofconduct/