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.On 7/21/2020 2:54 PM, Alex Hall wrote:
It should do the import for you. As was proposed:
```
print(f"My dict: {d!p}")
```
should be equivalent to
```
import pprint
print(f"My dict: {pprint.pformat(d)}")
```
The import should happen in the same scope. Modifying the global namespace could be confusing.
A quick test shows that adding `import pprint` to `pprint.pformat({1:2})` slows things down by about 4% on my machine, which I don't think is worth being concerned about. If the dict has 100 elements, the difference becomes too small to measure.f-strings call PyObject_Repr directly, without going through builtins.My first instinct is that monkeypatching the pprint module should affect !p, but I see that monkeypatching builtins.repr doesn't affect !r, so I'm not sure.
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?
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.
- How to handle parameters to pprint.pformat()?
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.
- Is pprint.pformat() extensible enough? Can an object control how it is pretty printed?
Could you specify.?
I'm sure there are others.
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/