> I'd be interested to see the "display utility" point of view expanded.
For me there are two use cases: I use devtool's debug() command instead of print() ALL THE TIME when debugging, so does the rest of my office and others who I've demonstrated its merits to. I use this sitecustomize trick <https://github.com/samuelcolvin/python-devtools#usage-without-import> to avoid having to import debug(). Using debug() over print() or pprint() for debugging has the following advantages, some more obvious than others: - It's much easier to read, particularly for big/complex/nested objects. Coloured output helps a lot here, so does better support for non std-lib objects like pandas dataframes, django querysets, multidict dictionaries, pydantic models etc. - I don't need to constantly write print('user.profile.age:', repr(user.profile.bio)) - just debug(user.profile.bio) takes care of showing the variable or expression I want to display as well as its value - debug() uses repr() which is mostly more useful when debugging than str() - debug() uses a slightly different logic to display nested objects compared to pprint(), you can think of it as looking much more like json.dumps(..., indent=4), maybe it's just that I'm the JSON generation, but I find it much easier to read than pprint(...) - having the file and line number saves me having to try and dig around to find where the print state is - this is particularly useful when debugging code in installed packages or in large code cases - debug() does a decent (if not perfect) job of displaying objects (e.g. strings) how I would want them in code so it can be super quick to add a test based on the value or copy it to code elsewhere - the sitecustomize trick means flake8 fails if I forget to remove debug() statements, similarly it means tests fail if I forget to remove them The second case is displaying objects to developers-as-users. For example aio-libs/aiohttp-devtools uses devtools to print request bodies and headers to aid debugging of unexpected http response codes (as far as I remember). Here I'm using devtools.pformat, it's convenient to use that method rather than have to write lots of display logic in each package. *Side Note:* I'm aware I'm talking about the devtools package (which I maintain) a lot, I'm waiting for the moment someone get's cross that I'm promoting my package. Sorry if it seems like that, but that's not what I'm trying to do, devtools isn't perfect and I wish it didn't exist. I think the python standard library should have a debug print command that knows how to print common object types but also respects a dunder method on objects which want to customise how they're displayed when debugging. The name of the debug command and the name of the dunder method don't bother me much. I'm just using devtools as an example of what I think should be in the standard library. Samuel
_______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/AAG3FNAC5GMIJCG7DG5DKCYF2J5L2MRY/ Code of Conduct: http://python.org/psf/codeofconduct/
