On 11/26/2017 12:23 AM, Carl Meyer wrote:
Hi Eric,
Really excited about this PEP, thanks for working on it.
Thanks, Carl.
A couple minor
questions:
If compare is True, then eq is ignored, and __eq__ and __ne__ will be
automatically generated.
IMO it's generally preferable to make nonsensical parameter combinations
an immediate error, rather than silently ignore one of them. Is there a
strong reason for letting nonsense pass silently here?
(I reviewed the previous thread; there was a lot of discussion about
enums/flags vs two boolean params, but I didn't see explicit discussion
of this issue; the only passing references I noticed said the invalid
combo should be "disallowed", e.g. Guido in [1], which to me implies "an
error.")
I think you're right here. I'll change it to a ValueError.
isdataclass(instance): Returns True if instance is an instance of a
Data Class, otherwise returns False.
Something smells wrong with the naming here. If I have
@dataclass
class Person:
name: str
I think it would be considered obvious and undeniable (in English prose,
anyway) that Person is a dataclass. So it seems wrong to have
`isdataclass(Person)` return `False`. Is there a reason not to let it
handle either a class or an instance (looks like it would actually
simplify the implementation)?
I think of this as really "isdataclassinstance". Let's see what others
think. There are places in dataclasses.py where I need to know both
ways: for example fields() works with either a class or instance, but
asdict() just an instance.
For what it's worth, the equivalent attrs API, attr.has(), returns True
for both an instance and a class. And the recommended solution for a
namedtuple (check for existence of _fields) would also work for an
instance and a class. And I suppose it's easy enough for the caller to
further disallow a class, if that's what they want.
Eric.
Carl
[1] https://mail.python.org/pipermail/python-dev/2017-September/149505.html
On 11/25/2017 01:06 PM, Eric V. Smith wrote:
The updated version should show up at
https://www.python.org/dev/peps/pep-0557/ shortly.
The major changes from the previous version are:
- Add InitVar to specify initialize-only fields.
- Renamed __dataclass_post_init__() to __post_init().
- Rename cmp to compare.
- Added eq, separate from compare, so you can test
unorderable items for equality.
- Flushed out asdict() and astuple().
- Changed replace() to just call __init__(), and dropped
the complex post-create logic.
The only open issues I know of are:
- Should object comparison require an exact match on the type?
https://github.com/ericvsmith/dataclasses/issues/51
- Should the replace() function be renamed to something else?
https://github.com/ericvsmith/dataclasses/issues/77
Most of the items that were previously discussed on python-dev were
discussed in detail at https://github.com/ericvsmith/dataclasses. Before
rehashing an old discussion, please check there first.
Also at https://github.com/ericvsmith/dataclasses is an implementation,
with tests, that should work with 3.6 and 3.7. The only action item for
the code is to clean up the implementation of InitVar, but that's
waiting for PEP 560. Oh, and if PEP 563 is accepted I'll also need to do
some work.
Feedback is welcomed!
Eric.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/carl%40oddbird.net
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
