[issue43080] pprint for dataclass instances

2021-04-13 Thread Eric V. Smith
Eric V. Smith added the comment: Thanks for all of the work, LewisGaul. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue43080] pprint for dataclass instances

2021-04-13 Thread Eric V. Smith
Eric V. Smith added the comment: New changeset 11159d2c9d6616497ef4cc62953a5c3cc8454afb by Lewis Gaul in branch 'master': bpo-43080: pprint for dataclass instances (GH-24389) https://github.com/python/cpython/commit/11159d2c9d6616497ef4cc62953a5c3cc8454afb --

[issue43080] pprint for dataclass instances

2021-03-20 Thread Gregory P. Smith
Gregory P. Smith added the comment: +0.5 I lean towards just accepting this under the conditions Eric describes given that dataclass is a stdlib concept and nobody is likely to claim that such output from pprint is a bad thing. The larger "some form of protocol for pprint to work on all

[issue43080] pprint for dataclass instances

2021-03-16 Thread Lewis Gaul
Lewis Gaul added the comment: > FWIW, we've not had a feature request for this ever, nor has there been a > request for pprint to support attrs, nor any other hand-rolled class that > implements methods similar to those generated by dataclasses. I wouldn't expect core Python to support a

[issue43080] pprint for dataclass instances

2021-03-15 Thread Raymond Hettinger
Raymond Hettinger added the comment: FWIW, we've not had a feature request for this ever, nor has there been a request for pprint to support attrs, nor any other hand-rolled class that implements methods similar to those generated by dataclasses. AFAICT, this tracker issue wasn't motivated

[issue43080] pprint for dataclass instances

2021-03-15 Thread Eric V. Smith
Eric V. Smith added the comment: I'm leaning toward accepting this on the condition that it only be invoked for dataclasses where __repr__ was the version generated by @dataclass. And also that it use the same fields that the generated __repr__ would use (basically skipping repr=False

[issue43080] pprint for dataclass instances

2021-01-31 Thread Eric V. Smith
Eric V. Smith added the comment: I agree that we need a better pprint. I think it would be easier to create something new rather than try and morph the existing pprint, but maybe I lack enough imagination. I'd prefer to use functools.singledispatch instead of a __pprint__ method, but it

[issue43080] pprint for dataclass instances

2021-01-31 Thread Raymond Hettinger
Raymond Hettinger added the comment: At some point, we need a modern redesign alternative to pprint. It could have its own __pprint__ method to communicate how it wants to be pretty printed. Until then, I think the existing pprint module should only grow custom support for classes that

[issue43080] pprint for dataclass instances

2021-01-31 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: Good idea Eric, it should work. But it can make the code of pprint potentially less flexible. Currently it uses a mapping which maps __repr__ to corresponding pprint implementation. Only exception is for dicts, for historical reasons. It potentially can

[issue43080] pprint for dataclass instances

2021-01-31 Thread Lewis Gaul
Lewis Gaul added the comment: @Serhiy - Yes, I noted that problem in the PR. Thanks for pointing me to that issue, I agree it would be good to make pprint properly extensible (my current solution is to maintain a fork of the pprint module with dataclass support added). Eric's suggestion

[issue43080] pprint for dataclass instances

2021-01-31 Thread Eric V. Smith
Eric V. Smith added the comment: Adding an attribute on the __repr__ (and other methods?) signifying that they were generated would let us distinguish them. Say, checking getattr(__repr__, '__is_generated__', False), or similar. -- ___ Python

[issue43080] pprint for dataclass instances

2021-01-31 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: For all other classes we check that there is no user defined __repr__. But it is difficult to check this for dataclass or namedtuple because there is no base class for dataclasses or namedtuples which provides standard __repr__ implementation. All

[issue43080] pprint for dataclass instances

2021-01-31 Thread Lewis Gaul
Lewis Gaul added the comment: > a dataclass can do anything a regular class can do Agreed, but isn't that also true of any subclasses of currently supported types? In particular 'UserDict', 'UserList' and 'UserString', which all have explicit support in pprint and are intended for "easier

[issue43080] pprint for dataclass instances

2021-01-31 Thread Raymond Hettinger
Raymond Hettinger added the comment: Since a dataclass can do anything a regular class can do, it is probably too general to have a special case for pprint. -- assignee: -> eric.smith nosy: +eric.smith ___ Python tracker

[issue43080] pprint for dataclass instances

2021-01-30 Thread Lewis Gaul
Change by Lewis Gaul : -- keywords: +patch pull_requests: +23204 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24389 ___ Python tracker ___

[issue43080] pprint for dataclass instances

2021-01-30 Thread Lewis Gaul
New submission from Lewis Gaul : Currently the pprint module does not have support for dataclasses. I have implemented support for this and will link the PR once I have the issue number! See also issue37376 for SimpleNamespace support. -- components: Library (Lib) messages: 386002