PEP 557 Data Classes 5th posting
I've pushed another version of PEP 557. The only difference is changing the default value of "order" to False instead of True. This matches regular classes: instances can be tested for equality, but are unordered.
Discussion at https://github.com/ericvsmith/dataclasses/issues/104
It's already available at https://www.python.org/dev/peps/pep-0557/
I've updated the implementation on PyPI to reflect this change: https://pypi.python.org/pypi/dataclasses/0.3
Eric.
I've made a minor change: the return type of fields() is now a tuple, it was a list.
Eric.
On 12/2/2017 9:02 AM, Eric V. Smith wrote:
I've pushed another version of PEP 557. The only difference is changing the default value of "order" to False instead of True. This matches regular classes: instances can be tested for equality, but are unordered.
Discussion at https://github.com/ericvsmith/dataclasses/issues/104
It's already available at https://www.python.org/dev/peps/pep-0557/
I've updated the implementation on PyPI to reflect this change: https://pypi.python.org/pypi/dataclasses/0.3
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...
Not sure I like that better. It's an open-ended sequence of homogeneous types. What's the advantage of a tuple? I don't want to blindly follow existing APIs.
On Sun, Dec 3, 2017 at 6:55 AM, Eric V. Smith eric@trueblade.com wrote:
I've made a minor change: the return type of fields() is now a tuple, it was a list.
Eric.
On 12/2/2017 9:02 AM, Eric V. Smith wrote:
I've pushed another version of PEP 557. The only difference is changing the default value of "order" to False instead of True. This matches regular classes: instances can be tested for equality, but are unordered.
Discussion at https://github.com/ericvsmith/dataclasses/issues/104
It's already available at https://www.python.org/dev/peps/pep-0557/
I've updated the implementation on PyPI to reflect this change: https://pypi.python.org/pypi/dataclasses/0.3
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%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/guido% 40python.org
On 12/3/2017 11:56 AM, Guido van Rossum wrote:
Not sure I like that better. It's an open-ended sequence of homogeneous types. What's the advantage of a tuple? I don't want to blindly follow existing APIs.
So people don't modify it, but consenting adults would say "don't do that". I currently return a new tuple in each call to fields(), but in the future I might return the same one every time (per class).
I really don't care so much. The only reason I made any change was because the implementation was returning an OrderedDict, so I was changing the tests anyway. I'm happy to change it back to a list, based on the convention of homogeneous types being in a list.
Eric.
On Sun, Dec 3, 2017 at 6:55 AM, Eric V. Smith <eric@trueblade.com mailto:eric@trueblade.com> wrote:
I've made a minor change: the return type of fields() is now a tuple, it was a list. Eric. On 12/2/2017 9:02 AM, Eric V. Smith wrote: I've pushed another version of PEP 557. The only difference is changing the default value of "order" to False instead of True. This matches regular classes: instances can be tested for equality, but are unordered. Discussion at https://github.com/ericvsmith/dataclasses/issues/104 <https://github.com/ericvsmith/dataclasses/issues/104> It's already available at https://www.python.org/dev/peps/pep-0557/ <https://www.python.org/dev/peps/pep-0557/> I've updated the implementation on PyPI to reflect this change: https://pypi.python.org/pypi/dataclasses/0.3 <https://pypi.python.org/pypi/dataclasses/0.3> Eric. _______________________________________________ Python-Dev mailing list Python-Dev@python.org <mailto:Python-Dev@python.org> https://mail.python.org/mailman/listinfo/python-dev <https://mail.python.org/mailman/listinfo/python-dev> Unsubscribe: https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com <https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com> _______________________________________________ Python-Dev mailing list Python-Dev@python.org <mailto:Python-Dev@python.org> https://mail.python.org/mailman/listinfo/python-dev <https://mail.python.org/mailman/listinfo/python-dev> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org <https://mail.python.org/mailman/options/python-dev/guido%40python.org>-- --Guido van Rossum (python.org/~guido http://python.org/%7Eguido)
On second thought I don't care that much.
On Dec 3, 2017 9:07 AM, "Eric V. Smith" eric@trueblade.com wrote:
On 12/3/2017 11:56 AM, Guido van Rossum wrote:
Not sure I like that better. It's an open-ended sequence of homogeneous types. What's the advantage of a tuple? I don't want to blindly follow existing APIs.
So people don't modify it, but consenting adults would say "don't do that". I currently return a new tuple in each call to fields(), but in the future I might return the same one every time (per class).
I really don't care so much. The only reason I made any change was because the implementation was returning an OrderedDict, so I was changing the tests anyway. I'm happy to change it back to a list, based on the convention of homogeneous types being in a list.
Eric.
On Sun, Dec 3, 2017 at 6:55 AM, Eric V. Smith <eric@trueblade.com mailto:eric@trueblade.com> wrote:
I've made a minor change: the return type of fields() is now a tuple, it was a list. Eric. On 12/2/2017 9:02 AM, Eric V. Smith wrote: I've pushed another version of PEP 557. The only difference is changing the default value of "order" to False instead of True. This matches regular classes: instances can be tested for equality, but are unordered. Discussion at https://github.com/ericvsmith/dataclasses/issues/104 <https://github.com/ericvsmith/dataclasses/issues/104> It's already available at https://www.python.org/dev/peps/pep-0557/ <https://www.python.org/dev/peps/pep-0557/> I've updated the implementation on PyPI to reflect this change: https://pypi.python.org/pypi/dataclasses/0.3 <https://pypi.python.org/pypi/dataclasses/0.3> Eric. _______________________________________________ Python-Dev mailing list Python-Dev@python.org <mailto:Python-Dev@python.org> https://mail.python.org/mailman/listinfo/python-dev <https://mail.python.org/mailman/listinfo/python-dev> Unsubscribe: https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com https://mail.python.org/mailman/options/python-dev/eric% 2Ba-python-dev%40trueblade.com
_______________________________________________ Python-Dev mailing list Python-Dev@python.org <mailto:Python-Dev@python.org> https://mail.python.org/mailman/listinfo/python-dev <https://mail.python.org/mailman/listinfo/python-dev> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.orghttps://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido http://python.org/%7Eguido)
Me, either. So I'm going to leave it as a tuple. Unless I find something while reviewing it tonight, I'm done.
Eric.
On 12/3/2017 3:02 PM, Guido van Rossum wrote:
On second thought I don't care that much.
On Dec 3, 2017 9:07 AM, "Eric V. Smith" <eric@trueblade.com mailto:eric@trueblade.com> wrote:
On 12/3/2017 11:56 AM, Guido van Rossum wrote: Not sure I like that better. It's an open-ended sequence of homogeneous types. What's the advantage of a tuple? I don't want to blindly follow existing APIs. So people don't modify it, but consenting adults would say "don't do that". I currently return a new tuple in each call to fields(), but in the future I might return the same one every time (per class). I really don't care so much. The only reason I made any change was because the implementation was returning an OrderedDict, so I was changing the tests anyway. I'm happy to change it back to a list, based on the convention of homogeneous types being in a list. Eric. On Sun, Dec 3, 2017 at 6:55 AM, Eric V. Smith <eric@trueblade.com <mailto:eric@trueblade.com> <mailto:eric@trueblade.com <mailto:eric@trueblade.com>>> wrote: I've made a minor change: the return type of fields() is now a tuple, it was a list. Eric. On 12/2/2017 9:02 AM, Eric V. Smith wrote: I've pushed another version of PEP 557. The only difference is changing the default value of "order" to False instead of True. This matches regular classes: instances can be tested for equality, but are unordered. Discussion at https://github.com/ericvsmith/dataclasses/issues/104 <https://github.com/ericvsmith/dataclasses/issues/104> <https://github.com/ericvsmith/dataclasses/issues/104 <https://github.com/ericvsmith/dataclasses/issues/104>> It's already available at https://www.python.org/dev/peps/pep-0557/ <https://www.python.org/dev/peps/pep-0557/> <https://www.python.org/dev/peps/pep-0557/ <https://www.python.org/dev/peps/pep-0557/>> I've updated the implementation on PyPI to reflect this change: https://pypi.python.org/pypi/dataclasses/0.3 <https://pypi.python.org/pypi/dataclasses/0.3> <https://pypi.python.org/pypi/dataclasses/0.3 <https://pypi.python.org/pypi/dataclasses/0.3>> Eric. _______________________________________________ Python-Dev mailing list Python-Dev@python.org <mailto:Python-Dev@python.org> <mailto:Python-Dev@python.org <mailto:Python-Dev@python.org>> https://mail.python.org/mailman/listinfo/python-dev <https://mail.python.org/mailman/listinfo/python-dev> <https://mail.python.org/mailman/listinfo/python-dev <https://mail.python.org/mailman/listinfo/python-dev>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com <https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com> <https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com <https://mail.python.org/mailman/options/python-dev/eric%2Ba-python-dev%40trueblade.com>> _______________________________________________ Python-Dev mailing list Python-Dev@python.org <mailto:Python-Dev@python.org> <mailto:Python-Dev@python.org <mailto:Python-Dev@python.org>> https://mail.python.org/mailman/listinfo/python-dev <https://mail.python.org/mailman/listinfo/python-dev> <https://mail.python.org/mailman/listinfo/python-dev <https://mail.python.org/mailman/listinfo/python-dev>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org <https://mail.python.org/mailman/options/python-dev/guido%40python.org> <https://mail.python.org/mailman/options/python-dev/guido%40python.org <https://mail.python.org/mailman/options/python-dev/guido%40python.org>> -- --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido> <http://python.org/%7Eguido>)
On Sat, 2 Dec 2017 09:02:37 -0500 "Eric V. Smith" eric@trueblade.com wrote:
I've pushed another version of PEP 557. The only difference is changing the default value of "order" to False instead of True. This matches regular classes: instances can be tested for equality, but are unordered.
Discussion at https://github.com/ericvsmith/dataclasses/issues/104
It's already available at https://www.python.org/dev/peps/pep-0557/
Thanks. I have to ask: why don't "asdict" and "astuple" respect PEP 8 naming?
Regards
Antoine.
On 12/3/2017 3:33 PM, Antoine Pitrou wrote:
On Sat, 2 Dec 2017 09:02:37 -0500 "Eric V. Smith" eric@trueblade.com wrote:
I've pushed another version of PEP 557. The only difference is changing the default value of "order" to False instead of True. This matches regular classes: instances can be tested for equality, but are unordered.
Discussion at https://github.com/ericvsmith/dataclasses/issues/104
It's already available at https://www.python.org/dev/peps/pep-0557/
Thanks. I have to ask: why don't "asdict" and "astuple" respect PEP 8 naming?
I guess it depends if you think the underscore is needed to improve readability. "Function names should be lowercase, with words separated by underscores as necessary to improve readability."
I don't feel strongly enough about it to change it, but part of that is because I'm burned out on the PEP, so I might not be a good one to judge at this point. I guess if I clear my head and I were doing it from scratch again I'd make them as_dict and as_tuple, so maybe I should brush aside inertia and make the change.
Eric.
On Sun, Dec 3, 2017 at 1:28 PM, Eric V. Smith eric@trueblade.com wrote:
On 12/3/2017 3:33 PM, Antoine Pitrou wrote:
On Sat, 2 Dec 2017 09:02:37 -0500 "Eric V. Smith" eric@trueblade.com wrote:
I've pushed another version of PEP 557. The only difference is changing the default value of "order" to False instead of True. This matches regular classes: instances can be tested for equality, but are unordered.
Discussion at https://github.com/ericvsmith/dataclasses/issues/104
It's already available at https://www.python.org/dev/peps/pep-0557/
Thanks. I have to ask: why don't "asdict" and "astuple" respect PEP 8 naming?
I guess it depends if you think the underscore is needed to improve readability. "Function names should be lowercase, with words separated by underscores as necessary to improve readability."
I don't feel strongly enough about it to change it, but part of that is because I'm burned out on the PEP, so I might not be a good one to judge at this point. I guess if I clear my head and I were doing it from scratch again I'd make them as_dict and as_tuple, so maybe I should brush aside inertia and make the change.
The Python stdlib is incredibly inconsistent where it comes to inserting underscores. I think in this case it matches `namedtuple._asdict()` and that's good enough for me.
On 12/3/2017 8:31 PM, Guido van Rossum wrote:
On Sun, Dec 3, 2017 at 1:28 PM, Eric V. Smith <eric@trueblade.com mailto:eric@trueblade.com> wrote:
On 12/3/2017 3:33 PM, Antoine Pitrou wrote:
Thanks. I have to ask: why don't "asdict" and "astuple" respect PEP 8 naming? I guess it depends if you think the underscore is needed to improve readability. "Function names should be lowercase, with words separated by underscores as necessary to improve readability." I don't feel strongly enough about it to change it, but part of that is because I'm burned out on the PEP, so I might not be a good one to judge at this point. I guess if I clear my head and I were doing it from scratch again I'd make them as_dict and as_tuple, so maybe I should brush aside inertia and make the change.The Python stdlib is incredibly inconsistent where it comes to inserting underscores. I think in this case it matches `namedtuple._asdict()` and that's good enough for me.
It also matches `attrs.asdict()`, which is what originally inspired it.
Eric.
On 12/3/2017 9:07 PM, Eric V. Smith wrote:
On 12/3/2017 8:31 PM, Guido van Rossum wrote:
On Sun, Dec 3, 2017 at 1:28 PM, Eric V. Smith <eric@trueblade.com mailto:eric@trueblade.com> wrote:
On 12/3/2017 3:33 PM, Antoine Pitrou wrote:
Thanks. I have to ask: why don't "asdict" and "astuple" respect PEP 8 naming?
I guess it depends if you think the underscore is needed to improve readability. "Function names should be lowercase, with words separated by underscores as necessary to improve readability."
I don't feel strongly enough about it to change it, but part of that is because I'm burned out on the PEP, so I might not be a good one to judge at this point. I guess if I clear my head and I were doing it from scratch again I'd make them as_dict and as_tuple, so maybe I should brush aside inertia and make the change.
The Python stdlib is incredibly inconsistent where it comes to inserting underscores. I think in this case it matches `namedtuple._asdict()` and that's good enough for me.
It also matches `attrs.asdict()`, which is what originally inspired it.
After a brief discussion at https://github.com/ericvsmith/dataclasses/issues/110, the decision is to leave the function names as-is, without underscores, to be consistent with namedtuples and attrs.
I'll add a note in the PEP's discussion section.
Eric.
And with this, I'm accepting PEP 557, Data Classes.
Eric, congrats with your efforts in proposing and implementing this PEP and guiding it through the discussion! It's been great to see this idea come to fruition. Thanks also to the many people who reviewed drafts or implementation code, including the very generous authors and maintainers of "attrs", from which this has taken many ideas.
Thanks, Guido. And indeed, thanks to everyone else who provided inspiration and feedback. I too would like to thank Hynek and the other authors of “attrs”.
I’ll get the implementation committed in the next day or so.
-- Eric.
On Dec 4, 2017, at 12:17 PM, Guido van Rossum guido@python.org wrote:
And with this, I'm accepting PEP 557, Data Classes.
Eric, congrats with your efforts in proposing and implementing this PEP and guiding it through the discussion! It's been great to see this idea come to fruition. Thanks also to the many people who reviewed drafts or implementation code, including the very generous authors and maintainers of "attrs", from which this has taken many ideas.
-- --Guido van Rossum (python.org/~guido) _______________________________________________ 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 Dec 4, 2017, at 9:17 AM, Guido van Rossum guido@python.org wrote:
And with this, I'm accepting PEP 557, Data Classes.
Woohoo! I think everyone was looking forward to this moment.
Raymond
Congratulations, Eric! This is a great PEP and I am looking forward to implement support for it in mypy ;-)
-- Ivan
On 4 December 2017 at 18:17, Guido van Rossum guido@python.org wrote:
And with this, I'm accepting PEP 557, Data Classes.
Eric, congrats with your efforts in proposing and implementing this PEP and guiding it through the discussion! It's been great to see this idea come to fruition. Thanks also to the many people who reviewed drafts or implementation code, including the very generous authors and maintainers of "attrs", from which this has taken many ideas.
-- --Guido van Rossum (python.org/~guido)
On 12/4/2017 5:19 PM, Ivan Levkivskyi wrote:
Congratulations, Eric! This is a great PEP and I am looking forward to implement support for it in mypy ;-)
Thanks for all of your help, Ivan, especially for design decisions that help interoperability with mypy. I'm looking forward to mypy support, too!
Eric.
participants (6)
-
Antoine Pitrou -
Eric V. Smith -
Ethan Furman -
Guido van Rossum -
Ivan Levkivskyi -
Raymond Hettinger