Third and hopefully final post: PEP 557, Data Classes
I've posted a new version of PEP 557, it should soon be available at https://www.python.org/dev/peps/pep-0557/.
The only significant changes since the last version are:
- changing the "compare" parameter to be "order", since that more accurately reflects what it does. - Having the combination of "eq=False" and "order=True" raise an exception instead of silently changing eq to True.
There were no other issues raised with the previous version of the PEP.
So with that, I think it's ready for a pronouncement.
Eric.
I plan to accept this on Monday if no new objections are raised.
On Nov 29, 2017 3:28 PM, "Eric V. Smith" eric@trueblade.com wrote:
I've posted a new version of PEP 557, it should soon be available at https://www.python.org/dev/peps/pep-0557/.
The only significant changes since the last version are:
- changing the "compare" parameter to be "order", since that more
accurately reflects what it does.
- Having the combination of "eq=False" and "order=True" raise an exception
instead of silently changing eq to True.
There were no other issues raised with the previous version of the PEP.
So with that, I think it's ready for a pronouncement.
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/guido% 40python.org
On 11/29/2017 03:26 PM, Eric V. Smith wrote:
I've posted a new version of PEP 557, it should soon be available at https://www.python.org/dev/peps/pep-0557/.
The only significant changes since the last version are:
- changing the "compare" parameter to be "order", since that more
accurately reflects what it does.
- Having the combination of "eq=False" and "order=True" raise an
exception instead of silently changing eq to True.
There were no other issues raised with the previous version of the PEP.
Not quite; I also raised the issue of isdataclass(ADataClass) returning False. I still think that's likely to be a cause of bug reports if left as-is.
Carl
On 11/29/2017 6:51 PM, Carl Meyer wrote:
On 11/29/2017 03:26 PM, Eric V. Smith wrote:
I've posted a new version of PEP 557, it should soon be available at https://www.python.org/dev/peps/pep-0557/.
The only significant changes since the last version are:
- changing the "compare" parameter to be "order", since that more
accurately reflects what it does.
- Having the combination of "eq=False" and "order=True" raise an
exception instead of silently changing eq to True.
There were no other issues raised with the previous version of the PEP.
Not quite; I also raised the issue of isdataclass(ADataClass) returning False. I still think that's likely to be a cause of bug reports if left as-is.
Oops, sorry about that!
I think you're probably right. attr.has(), which is the equivalent attrs API, returns True for both classes and instances (although interestingly, the code only talks about it working on classes).
https://github.com/ericvsmith/dataclasses/issues/99
Eric.
On Wed, Nov 29, 2017 at 3:51 PM, Carl Meyer carl@oddbird.net wrote:
On 11/29/2017 03:26 PM, Eric V. Smith wrote:
I've posted a new version of PEP 557, it should soon be available at https://www.python.org/dev/peps/pep-0557/.
The only significant changes since the last version are:
- changing the "compare" parameter to be "order", since that more
accurately reflects what it does.
- Having the combination of "eq=False" and "order=True" raise an
exception instead of silently changing eq to True.
There were no other issues raised with the previous version of the PEP.
Not quite; I also raised the issue of isdataclass(ADataClass) returning False. I still think that's likely to be a cause of bug reports if left as-is.
I tried to look up the discussion but didn't find much except that you flagged this as an issue. To repeat, your concern is that isdataclass() applies to *instances*, not classes, which is how Eric has designed it, but you worry that either through the name or just because people don't read the docs it will be confusing. What do you suppose we do? I think making it work for classes as well as for instances would cause another category of bugs (confusion between cases where a class is needed vs. an instance abound in other situations -- we don't want to add to that). Maybe it should raise TypeError when passed a class (unless its metaclass is a dataclass)? Maybe it should be renamed to isdataclassinstance()? That's a mouthful, but I don't know how common the need to call this is, and people who call it a lot can define their own shorter alias.
On 11/29/2017 6:26 PM, Eric V. Smith wrote:
I've posted a new version of PEP 557, it should soon be available at https://www.python.org/dev/peps/pep-0557/.
Also, I've posted version 0.2 to PyPI as dataclasses, so you can play with it on 3.6 and 3.7.
Eric.
isdataclass() testing for instance-ship does sound like a bug magnet to me.
If isdataclassinstance() is too long (that's understandable), how about isdatainstance()?
Regards
Antoine.
On Wed, 29 Nov 2017 17:02:21 -0800 Guido van Rossum guido@python.org wrote:
On Wed, Nov 29, 2017 at 3:51 PM, Carl Meyer carl@oddbird.net wrote:
On 11/29/2017 03:26 PM, Eric V. Smith wrote:
I've posted a new version of PEP 557, it should soon be available at https://www.python.org/dev/peps/pep-0557/.
The only significant changes since the last version are:
- changing the "compare" parameter to be "order", since that more
accurately reflects what it does.
- Having the combination of "eq=False" and "order=True" raise an
exception instead of silently changing eq to True.
There were no other issues raised with the previous version of the PEP.
Not quite; I also raised the issue of isdataclass(ADataClass) returning False. I still think that's likely to be a cause of bug reports if left as-is.
I tried to look up the discussion but didn't find much except that you flagged this as an issue. To repeat, your concern is that isdataclass() applies to *instances*, not classes, which is how Eric has designed it, but you worry that either through the name or just because people don't read the docs it will be confusing. What do you suppose we do? I think making it work for classes as well as for instances would cause another category of bugs (confusion between cases where a class is needed vs. an instance abound in other situations -- we don't want to add to that). Maybe it should raise TypeError when passed a class (unless its metaclass is a dataclass)? Maybe it should be renamed to isdataclassinstance()? That's a mouthful, but I don't know how common the need to call this is, and people who call it a lot can define their own shorter alias.
Could these be things in types?
types.ClassType types.InstanceType
types.DataClass types.DataClassInstanceType (?)
I sent a PR with typo fixes and ``.. code:: python`` directives so that syntax highlighting works (at least on GitHub).
https://github.com/python/peps/blob/master/pep-0557.rst
https://github.com/python/peps/pull/488
Additional notes:
- "DataClass" instead of "Data Class" would be easier to search for. s/DataClass/Data Class/g? - It's probably worth mentioning how hash works when frozen=True also here: https://github.com/python/peps/blob/master/pep-0557.rst#frozen-instances - The `hash` explanation could be a two column table for easier readability
What a great feature.
- Runtime data validation from annotations (like PyContracts,) would be cool - __slots__ are worth the time
On Thursday, November 30, 2017, Antoine Pitrou solipsis@pitrou.net wrote:
isdataclass() testing for instance-ship does sound like a bug magnet to me.
If isdataclassinstance() is too long (that's understandable), how about isdatainstance()?
Regards
Antoine.
On Wed, 29 Nov 2017 17:02:21 -0800 Guido van Rossum <guido@python.org javascript:;> wrote:
On Wed, Nov 29, 2017 at 3:51 PM, Carl Meyer <carl@oddbird.net
javascript:;> wrote:
On 11/29/2017 03:26 PM, Eric V. Smith wrote:
I've posted a new version of PEP 557, it should soon be available at https://www.python.org/dev/peps/pep-0557/.
The only significant changes since the last version are:
- changing the "compare" parameter to be "order", since that more
accurately reflects what it does.
- Having the combination of "eq=False" and "order=True" raise an
exception instead of silently changing eq to True.
There were no other issues raised with the previous version of the
PEP.
Not quite; I also raised the issue of isdataclass(ADataClass) returning False. I still think that's likely to be a cause of bug reports if left as-is.
I tried to look up the discussion but didn't find much except that you flagged this as an issue. To repeat, your concern is that isdataclass() applies to *instances*, not classes, which is how Eric has designed it,
but
you worry that either through the name or just because people don't read the docs it will be confusing. What do you suppose we do? I think making
it
work for classes as well as for instances would cause another category of bugs (confusion between cases where a class is needed vs. an instance abound in other situations -- we don't want to add to that). Maybe it should raise TypeError when passed a class (unless its metaclass is a dataclass)? Maybe it should be renamed to isdataclassinstance()? That's a mouthful, but I don't know how common the need to call this is, and
people
who call it a lot can define their own shorter alias.
Python-Dev mailing list Python-Dev@python.org javascript:; https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ wes.turner%40gmail.com
Sorry, this one shouldn't be "an"; " a" was correct::
``repr``: If true (the default), an ``__repr__`` method will be generated.
Note that __repr__ can be dangerous with user-supplied input because of terminal control character injection (e.g. broken syntax highlighting, \r, character set, LEDs,)
On Thursday, November 30, 2017, Wes Turner wes.turner@gmail.com wrote:
Could these be things in types?
types.ClassType types.InstanceType
types.DataClass types.DataClassInstanceType (?)
I sent a PR with typo fixes and ``.. code:: python`` directives so that syntax highlighting works (at least on GitHub).
https://github.com/python/peps/blob/master/pep-0557.rst
https://github.com/python/peps/pull/488
Additional notes:
- "DataClass" instead of "Data Class" would be easier to search for.
s/DataClass/Data Class/g?
- It's probably worth mentioning how hash works when frozen=True also here: https://github.com/python/peps/blob/master/pep-0557.rst#frozen-instances
- The `hash` explanation could be a two column table for easier readability
What a great feature.
- Runtime data validation from annotations (like PyContracts,) would be
cool
- __slots__ are worth the time
On Thursday, November 30, 2017, Antoine Pitrou <solipsis@pitrou.net javascript:_e(%7B%7D,'cvml','solipsis@pitrou.net');> wrote:
isdataclass() testing for instance-ship does sound like a bug magnet to me.
If isdataclassinstance() is too long (that's understandable), how about isdatainstance()?
Regards
Antoine.
On Wed, 29 Nov 2017 17:02:21 -0800 Guido van Rossum guido@python.org wrote:
On Wed, Nov 29, 2017 at 3:51 PM, Carl Meyer carl@oddbird.net wrote:
On 11/29/2017 03:26 PM, Eric V. Smith wrote:
I've posted a new version of PEP 557, it should soon be available at https://www.python.org/dev/peps/pep-0557/.
The only significant changes since the last version are:
- changing the "compare" parameter to be "order", since that more
accurately reflects what it does.
- Having the combination of "eq=False" and "order=True" raise an
exception instead of silently changing eq to True.
There were no other issues raised with the previous version of the
PEP.
Not quite; I also raised the issue of isdataclass(ADataClass)
returning
False. I still think that's likely to be a cause of bug reports if
left
as-is.
I tried to look up the discussion but didn't find much except that you flagged this as an issue. To repeat, your concern is that isdataclass() applies to *instances*, not classes, which is how Eric has designed it,
but
you worry that either through the name or just because people don't read the docs it will be confusing. What do you suppose we do? I think
making it
work for classes as well as for instances would cause another category
of
bugs (confusion between cases where a class is needed vs. an instance abound in other situations -- we don't want to add to that). Maybe it should raise TypeError when passed a class (unless its metaclass is a dataclass)? Maybe it should be renamed to isdataclassinstance()? That's
a
mouthful, but I don't know how common the need to call this is, and
people
who call it a lot can define their own shorter alias.
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/wes. turner%40gmail.com
30.11.17 03:02, Guido van Rossum пише:
I tried to look up the discussion but didn't find much except that you flagged this as an issue. To repeat, your concern is that isdataclass() applies to *instances*, not classes, which is how Eric has designed it, but you worry that either through the name or just because people don't read the docs it will be confusing. What do you suppose we do? I think making it work for classes as well as for instances would cause another category of bugs (confusion between cases where a class is needed vs. an instance abound in other situations -- we don't want to add to that). Maybe it should raise TypeError when passed a class (unless its metaclass is a dataclass)? Maybe it should be renamed to isdataclassinstance()? That's a mouthful, but I don't know how common the need to call this is, and people who call it a lot can define their own shorter alias.
There is isdatadescriptor() which is not too shorter.
Or, simply, is_dataclass_instance(), which is even longer, but far more readable thanks to explicit word boundaries :-)
On Thu, 30 Nov 2017 10:16:58 +0100 Antoine Pitrou solipsis@pitrou.net wrote:
isdataclass() testing for instance-ship does sound like a bug magnet to me.
If isdataclassinstance() is too long (that's understandable), how about isdatainstance()?
Regards
Antoine.
On Wed, 29 Nov 2017 17:02:21 -0800 Guido van Rossum guido@python.org wrote:
On Wed, Nov 29, 2017 at 3:51 PM, Carl Meyer carl@oddbird.net wrote:
On 11/29/2017 03:26 PM, Eric V. Smith wrote:
I've posted a new version of PEP 557, it should soon be available at https://www.python.org/dev/peps/pep-0557/.
The only significant changes since the last version are:
- changing the "compare" parameter to be "order", since that more
accurately reflects what it does.
- Having the combination of "eq=False" and "order=True" raise an
exception instead of silently changing eq to True.
There were no other issues raised with the previous version of the PEP.
Not quite; I also raised the issue of isdataclass(ADataClass) returning False. I still think that's likely to be a cause of bug reports if left as-is.
I tried to look up the discussion but didn't find much except that you flagged this as an issue. To repeat, your concern is that isdataclass() applies to *instances*, not classes, which is how Eric has designed it, but you worry that either through the name or just because people don't read the docs it will be confusing. What do you suppose we do? I think making it work for classes as well as for instances would cause another category of bugs (confusion between cases where a class is needed vs. an instance abound in other situations -- we don't want to add to that). Maybe it should raise TypeError when passed a class (unless its metaclass is a dataclass)? Maybe it should be renamed to isdataclassinstance()? That's a mouthful, but I don't know how common the need to call this is, and people who call it a lot can define their own shorter alias.
On 11/30/2017 6:59 AM, Antoine Pitrou wrote:
Or, simply, is_dataclass_instance(), which is even longer, but far more readable thanks to explicit word boundaries :-)
That actually doesn't bother me. I think this API will be used rarely, if ever. Or more realistically, it should be used rarely: what actually happens will no doubt surprise me.
So I'm okay with is_dataclass_instance() and is_dataclass_class().
But then I'm also okay with dropping the API entirely. nametuple has lived for years without it, although Raymond's advice there is that if you really want to know, look for _fields. See https://bugs.python.org/issue7796#msg99869 and the following discussion.
Eric.
On Thu, 30 Nov 2017 10:16:58 +0100 Antoine Pitrou solipsis@pitrou.net wrote:
isdataclass() testing for instance-ship does sound like a bug magnet to me.
If isdataclassinstance() is too long (that's understandable), how about isdatainstance()?
Regards
Antoine.
On Wed, 29 Nov 2017 17:02:21 -0800 Guido van Rossum guido@python.org wrote:
On Wed, Nov 29, 2017 at 3:51 PM, Carl Meyer carl@oddbird.net wrote:
On 11/29/2017 03:26 PM, Eric V. Smith wrote:
I've posted a new version of PEP 557, it should soon be available at https://www.python.org/dev/peps/pep-0557/.
The only significant changes since the last version are:
- changing the "compare" parameter to be "order", since that more
accurately reflects what it does.
- Having the combination of "eq=False" and "order=True" raise an
exception instead of silently changing eq to True.
There were no other issues raised with the previous version of the PEP.
Not quite; I also raised the issue of isdataclass(ADataClass) returning False. I still think that's likely to be a cause of bug reports if left as-is.
I tried to look up the discussion but didn't find much except that you flagged this as an issue. To repeat, your concern is that isdataclass() applies to *instances*, not classes, which is how Eric has designed it, but you worry that either through the name or just because people don't read the docs it will be confusing. What do you suppose we do? I think making it work for classes as well as for instances would cause another category of bugs (confusion between cases where a class is needed vs. an instance abound in other situations -- we don't want to add to that). Maybe it should raise TypeError when passed a class (unless its metaclass is a dataclass)? Maybe it should be renamed to isdataclassinstance()? That's a mouthful, but I don't know how common the need to call this is, and people who call it a lot can define their own shorter alias.
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%40tru...
On Thu, 30 Nov 2017 at 05:00 Eric V. Smith eric@trueblade.com wrote:
On 11/30/2017 6:59 AM, Antoine Pitrou wrote:
Or, simply, is_dataclass_instance(), which is even longer, but far more readable thanks to explicit word boundaries :-)
That actually doesn't bother me. I think this API will be used rarely, if ever. Or more realistically, it should be used rarely: what actually happens will no doubt surprise me.
So I'm okay with is_dataclass_instance() and is_dataclass_class().
But then I'm also okay with dropping the API entirely. nametuple has lived for years without it, although Raymond's advice there is that if you really want to know, look for _fields. See https://bugs.python.org/issue7796#msg99869 and the following discussion.
My question was going to be whether this is even necessary. :) Perhaps we just drop it for now and add it in if we find there's a public need for it?
-Brett
Eric.
On Thu, 30 Nov 2017 10:16:58 +0100 Antoine Pitrou solipsis@pitrou.net wrote:
isdataclass() testing for instance-ship does sound like a bug magnet to me.
If isdataclassinstance() is too long (that's understandable), how about isdatainstance()?
Regards
Antoine.
On Wed, 29 Nov 2017 17:02:21 -0800 Guido van Rossum guido@python.org wrote:
On Wed, Nov 29, 2017 at 3:51 PM, Carl Meyer carl@oddbird.net
wrote:
On 11/29/2017 03:26 PM, Eric V. Smith wrote:
I've posted a new version of PEP 557, it should soon be available at https://www.python.org/dev/peps/pep-0557/.
The only significant changes since the last version are:
- changing the "compare" parameter to be "order", since that more
accurately reflects what it does.
- Having the combination of "eq=False" and "order=True" raise an
exception instead of silently changing eq to True.
There were no other issues raised with the previous version of the
PEP.
Not quite; I also raised the issue of isdataclass(ADataClass)
returning
False. I still think that's likely to be a cause of bug reports if
left
as-is.
I tried to look up the discussion but didn't find much except that you flagged this as an issue. To repeat, your concern is that isdataclass() applies to *instances*, not classes, which is how Eric has designed
it, but
you worry that either through the name or just because people don't
read
the docs it will be confusing. What do you suppose we do? I think
making it
work for classes as well as for instances would cause another category
of
bugs (confusion between cases where a class is needed vs. an instance abound in other situations -- we don't want to add to that). Maybe it should raise TypeError when passed a class (unless its metaclass is a dataclass)? Maybe it should be renamed to isdataclassinstance()?
That's a
mouthful, but I don't know how common the need to call this is, and
people
who call it a lot can define their own shorter alias.
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%40tru...
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/brett%40python.org
On 11/29/2017 05:02 PM, Guido van Rossum wrote:
I tried to look up the discussion but didn't find much except that you flagged this as an issue. To repeat, your concern is that isdataclass() applies to *instances*, not classes, which is how Eric has designed it, but you worry that either through the name or just because people don't read the docs it will be confusing. What do you suppose we do? I think making it work for classes as well as for instances would cause another category of bugs (confusion between cases where a class is needed vs. an instance abound in other situations -- we don't want to add to that). Maybe it should raise TypeError when passed a class (unless its metaclass is a dataclass)? Maybe it should be renamed to isdataclassinstance()? That's a mouthful, but I don't know how common the need to call this is, and people who call it a lot can define their own shorter alias.
Yeah, I didn't propose a specific fix because I think there are several options (all mentioned in this thread already), and I don't really have strong feelings about them:
1) Keep the existing function and name, let it handle either classes or instances. I agree that this is probably not the best option available, though IMO it's still marginally better than the status quo).
2) Punt the problem by removing the function; don't add it to the public API at all until we have demonstrated demand.
3) Rename it to "is_dataclass_instance" (and maybe also keep a separate "is_dataclass" for testing classes directly). (Then there's also the choice about raising TypeError vs just returning False if a function is given the wrong type; I think TypeError is better.)
Carl
+1 to (3), I like the type error idea, too.
I don't care much about naming... but if I were to bikeshed this, I'd go for
isdataclass (like issubclass) isdatainstance (like isinstance)
- Ł
On Nov 30, 2017, at 12:35 PM, Carl Meyer carl@oddbird.net wrote:
On 11/29/2017 05:02 PM, Guido van Rossum wrote:
I tried to look up the discussion but didn't find much except that you flagged this as an issue. To repeat, your concern is that isdataclass() applies to *instances*, not classes, which is how Eric has designed it, but you worry that either through the name or just because people don't read the docs it will be confusing. What do you suppose we do? I think making it work for classes as well as for instances would cause another category of bugs (confusion between cases where a class is needed vs. an instance abound in other situations -- we don't want to add to that). Maybe it should raise TypeError when passed a class (unless its metaclass is a dataclass)? Maybe it should be renamed to isdataclassinstance()? That's a mouthful, but I don't know how common the need to call this is, and people who call it a lot can define their own shorter alias.
Yeah, I didn't propose a specific fix because I think there are several options (all mentioned in this thread already), and I don't really have strong feelings about them:
- Keep the existing function and name, let it handle either classes or
instances. I agree that this is probably not the best option available, though IMO it's still marginally better than the status quo).
- Punt the problem by removing the function; don't add it to the public
API at all until we have demonstrated demand.
- Rename it to "is_dataclass_instance" (and maybe also keep a separate
"is_dataclass" for testing classes directly). (Then there's also the choice about raising TypeError vs just returning False if a function is given the wrong type; I think TypeError is better.)
Carl
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/lukasz%40langa.pl
On 11/30/2017 1:30 PM, Brett Cannon wrote:
On Thu, 30 Nov 2017 at 05:00 Eric V. Smith <eric@trueblade.com mailto:eric@trueblade.com> wrote:
On 11/30/2017 6:59 AM, Antoine Pitrou wrote: > > Or, simply, is_dataclass_instance(), which is even longer, but far more > readable thanks to explicit word boundaries :-) That actually doesn't bother me. I think this API will be used rarely, if ever. Or more realistically, it should be used rarely: what actually happens will no doubt surprise me. So I'm okay with is_dataclass_instance() and is_dataclass_class(). But then I'm also okay with dropping the API entirely. nametuple has lived for years without it, although Raymond's advice there is that if you really want to know, look for _fields. See https://bugs.python.org/issue7796#msg99869 and the following discussion.My question was going to be whether this is even necessary. :) Perhaps we just drop it for now and add it in if we find there's a public need for it?
That's what I'm leaning toward. I've been trying to figure out what attr.has() or hasattr(obj, '_fields') are actually used for. The attrs version is hard to search for, and while I see the question about namedtuples asked fairly often on SO, I haven't seen an actual use case.
It's easy enough for someone to write their own isdataclass(), admittedly using an undocumented feature.
So I'm thinking let's drop it and then gauge the demand for it, if any.
Eric.
On Thursday, November 30, 2017, Wes Turner wes.turner@gmail.com wrote:
Could these be things in types?
types.ClassType types.InstanceType
types.DataClass types.DataClassInstanceType (?)
types.DataClass(types.ClassType) types.DataClassInstanceType(types.InstanceType)
Would be logical?
I sent a PR with typo fixes and ``.. code:: python`` directives so that syntax highlighting works (at least on GitHub).
https://github.com/python/peps/blob/master/pep-0557.rst
https://github.com/python/peps/pull/488
Additional notes:
- "DataClass" instead of "Data Class" would be easier to search for.
s/DataClass/Data Class/g?
- It's probably worth mentioning how hash works when frozen=True also here: https://github.com/python/peps/blob/master/pep-0557.rst#frozen-instances
- The `hash` explanation could be a two column table for easier readability
What a great feature.
- Runtime data validation from annotations (like PyContracts,) would be
cool
- __slots__ are worth the time
On Thursday, November 30, 2017, Antoine Pitrou <solipsis@pitrou.net javascript:_e(%7B%7D,'cvml','solipsis@pitrou.net');> wrote:
isdataclass() testing for instance-ship does sound like a bug magnet to me.
If isdataclassinstance() is too long (that's understandable), how about isdatainstance()?
Regards
Antoine.
On Wed, 29 Nov 2017 17:02:21 -0800 Guido van Rossum guido@python.org wrote:
On Wed, Nov 29, 2017 at 3:51 PM, Carl Meyer carl@oddbird.net wrote:
On 11/29/2017 03:26 PM, Eric V. Smith wrote:
I've posted a new version of PEP 557, it should soon be available at https://www.python.org/dev/peps/pep-0557/.
The only significant changes since the last version are:
- changing the "compare" parameter to be "order", since that more
accurately reflects what it does.
- Having the combination of "eq=False" and "order=True" raise an
exception instead of silently changing eq to True.
There were no other issues raised with the previous version of the
PEP.
Not quite; I also raised the issue of isdataclass(ADataClass)
returning
False. I still think that's likely to be a cause of bug reports if
left
as-is.
I tried to look up the discussion but didn't find much except that you flagged this as an issue. To repeat, your concern is that isdataclass() applies to *instances*, not classes, which is how Eric has designed it,
but
you worry that either through the name or just because people don't read the docs it will be confusing. What do you suppose we do? I think
making it
work for classes as well as for instances would cause another category
of
bugs (confusion between cases where a class is needed vs. an instance abound in other situations -- we don't want to add to that). Maybe it should raise TypeError when passed a class (unless its metaclass is a dataclass)? Maybe it should be renamed to isdataclassinstance()? That's
a
mouthful, but I don't know how common the need to call this is, and
people
who call it a lot can define their own shorter alias.
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/wes. turner%40gmail.com
On 11/30/2017 7:22 PM, Eric V. Smith wrote:
On 11/30/2017 1:30 PM, Brett Cannon wrote:
On Thu, 30 Nov 2017 at 05:00 Eric V. Smith <eric@trueblade.com mailto:eric@trueblade.com> wrote:
On 11/30/2017 6:59 AM, Antoine Pitrou wrote: > > Or, simply, is_dataclass_instance(), which is even longer, but far more > readable thanks to explicit word boundaries :-)
That actually doesn't bother me. I think this API will be used rarely, if ever. Or more realistically, it should be used rarely: what actually happens will no doubt surprise me.
So I'm okay with is_dataclass_instance() and is_dataclass_class().
But then I'm also okay with dropping the API entirely. nametuple has lived for years without it, although Raymond's advice there is that if you really want to know, look for _fields. See https://bugs.python.org/issue7796#msg99869 and the following discussion.
My question was going to be whether this is even necessary. :) Perhaps we just drop it for now and add it in if we find there's a public need for it?
That's what I'm leaning toward. I've been trying to figure out what attr.has() or hasattr(obj, '_fields') are actually used for. The attrs version is hard to search for, and while I see the question about namedtuples asked fairly often on SO, I haven't seen an actual use case.
It's easy enough for someone to write their own isdataclass(), admittedly using an undocumented feature.
Actually there's a supported way to write your own isdataclass(): call dataclasses.fields(obj). If it throws a TypeError, it's not a dataclass instance or class. I'll add a note to the PEP.
Eric.
So I'm thinking let's drop it and then gauge the demand for it, if any.
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/eric%2Ba-python-dev%40tru...
On 11/30/2017 3:35 PM, Carl Meyer wrote:
On 11/29/2017 05:02 PM, Guido van Rossum wrote:
I tried to look up the discussion but didn't find much except that you flagged this as an issue. To repeat, your concern is that isdataclass() applies to *instances*, not classes, which is how Eric has designed it, but you worry that either through the name or just because people don't read the docs it will be confusing. What do you suppose we do? I think making it work for classes as well as for instances would cause another category of bugs (confusion between cases where a class is needed vs. an instance abound in other situations -- we don't want to add to that). Maybe it should raise TypeError when passed a class (unless its metaclass is a dataclass)? Maybe it should be renamed to isdataclassinstance()? That's a mouthful, but I don't know how common the need to call this is, and people who call it a lot can define their own shorter alias.
Yeah, I didn't propose a specific fix because I think there are several options (all mentioned in this thread already), and I don't really have strong feelings about them:
- Keep the existing function and name, let it handle either classes or
instances. I agree that this is probably not the best option available, though IMO it's still marginally better than the status quo).
- Punt the problem by removing the function; don't add it to the public
API at all until we have demonstrated demand.
- Rename it to "is_dataclass_instance" (and maybe also keep a separate
"is_dataclass" for testing classes directly). (Then there's also the choice about raising TypeError vs just returning False if a function is given the wrong type; I think TypeError is better.)
In that case, you can spell "is_dataclass_instance":
def isdataclass_instance(obj): dataclasses.fields(obj) # raises TypeError for non-dataclass # classes or instances if not isinstance(obj, type): raise TypeError('not an instance') return True
Since this is easy enough to do in your own code, and I still don't see a use case, I'll just add a note to the PEP and omit delete isdataclass().
Plus, you can decide for yourself how to deal with the question of returning true for classes or instances or both.
Eric.
Since this is easy enough to do in your own code, and I still don't see a use case, I'll just add a note to the PEP and delete isdataclass().
Plus, you can decide for yourself how to deal with the question of returning true for classes or instances or both.
I've updated the PEP and reposted it. The only change is removing isdataclass().
Eric.
See https://github.com/ericvsmith/dataclasses/issues/104 for a discussion on making order=False the default. This matches regular classes in Python 3, which cannot be ordered.
Eric.
On 2 December 2017 at 08:15, Eric V. Smith eric@trueblade.com wrote:
See https://github.com/ericvsmith/dataclasses/issues/104 for a discussion on making order=False the default. This matches regular classes in Python 3, which cannot be ordered.
+1 for making "order=True" be explicitly opt-in.
Cheers, Nick.
participants (10)
-
Antoine Pitrou -
Brett Cannon -
Carl Meyer -
Eric V. Smith -
Guido van Rossum -
Guido van Rossum -
Lukasz Langa -
Nick Coghlan -
Serhiy Storchaka -
Wes Turner