subject:"\[Python\-Dev\] PEP 557\: Data Classes"


On 12/3/2017 9:07 PM, Eric V. Smith wrote:


It also matches `attrs.asdict()`, which is what originally inspired it.


Make that `attr.asdict()`. So easy to get that wrong.

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/archive%40mail-archive.com

Re: [Python-Dev] PEP 557 Data Classes 5th posting


On 12/3/2017 8:31 PM, Guido van Rossum wrote:
On Sun, Dec 3, 2017 at 1:28 PM, Eric V. Smith > 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.

___
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

Re: [Python-Dev] PEP 557 Data Classes 5th posting

2017-12-03 Thread Guido van Rossum

On Sun, Dec 3, 2017 at 1:28 PM, Eric V. Smith  wrote:

> On 12/3/2017 3:33 PM, Antoine Pitrou wrote:
>
>> On Sat, 2 Dec 2017 09:02:37 -0500
>> "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/
>>>
>>
>> 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.

-- 
--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/archive%40mail-archive.com

Re: [Python-Dev] PEP 557 Data Classes 5th posting


On 12/3/2017 3:33 PM, Antoine Pitrou wrote:

On Sat, 2 Dec 2017 09:02:37 -0500
"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/


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.
___
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

Re: [Python-Dev] PEP 557 Data Classes 5th posting

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" > 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

>> 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

>

-- 
--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/archive%40mail-archive.com

Re: [Python-Dev] PEP 557 Data Classes 5th posting

2017-12-03 Thread Antoine Pitrou

On Sat, 2 Dec 2017 09:02:37 -0500
"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/

Thanks.  I have to ask: why don't "asdict" and "astuple" respect PEP 8
naming?

Regards

Antoine.


___
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

Re: [Python-Dev] PEP 557 Data Classes 5th posting

2017-12-03 Thread Guido van Rossum

On second thought I don't care that much.

On Dec 3, 2017 9:07 AM, "Eric V. Smith"  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 > > 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
>> > 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
>> 
>>
>>
>>
>>
>> --
>> --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/archive%40mail-archive.com

Re: [Python-Dev] PEP 557 Data Classes 5th posting


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 > 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 





--
--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/archive%40mail-archive.com

Re: [Python-Dev] PEP 557 Data Classes 5th posting

2017-12-03 Thread Guido van Rossum

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  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
>



-- 
--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/archive%40mail-archive.com

Re: [Python-Dev] PEP 557 Data Classes 5th posting

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/archive%40mail-archive.com

[Python-Dev] PEP 557 Data Classes 5th posting

2017-12-02 Thread Eric V. Smith

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/archive%40mail-archive.com

Re: [Python-Dev] PEP 557: Data Classes

2017-10-12 Thread Raymond Hettinger


> On Oct 12, 2017, at 7:46 AM, Guido van Rossum  wrote:
> 
> I am still firmly convinced that @dataclass is the right name for the 
> decorator (and `dataclasses` for the module).

+1 from me.  The singular/plural pair has the same nice feel as "from fractions 
import Fraction", "from itertools import product" and "from collections import 
namedtuple".


Raymond



___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-10-12 Thread Ethan Furman


On 10/12/2017 03:44 PM, Chris Barker wrote:

I think we've drifted into a new topic, but...



I was thinking about this last spring, when I tried to cram all sorts of python 
metaprogramming into one 3hr class...

Trying to come up with a an exam[ple for metclasses, I couldn't come up with 
anything that couldn't be done more claerly
(to me) with a class decorator.


The Enum data type requires metaclasses.

Any time you want to modify the behavior of a class (not its instances, the 
class itself) you need a metaclass.

Agreed that it's pretty rare, but we need them.

--
~Ethan~

___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-10-12 Thread Eric V. Smith


On 10/12/2017 6:33 PM, Chris Barker wrote:
On Thu, Oct 12, 2017 at 3:20 AM, Steve Holden > wrote:


  The reason I liked "row" as a name is because it resembles 
"vector" and hence is loosely assocaited with the concept of a tuple

as well as being familiar to database users. In fact the answer to a
relational query was, I believe, originally formally defined as a
set of tuples.


Is the intent that these things preserve order?


In the sense that the parameters to __init__(), the appearance in the 
repr, the order of the returned tuple in as_tuple(), and the order of 
comparisons will be the same as the order that the fields are defined, 
then yes.


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/archive%40mail-archive.com

Re: [Python-Dev] PEP 557: Data Classes

2017-10-12 Thread Chris Barker

I think we've drifted into a new topic, but...


 I was astonished to see them
> implemented using decorators, and I was not the only one.


...


> Python is at a weird point here. At about every new release of Python,
> a new idea shows up that could be easily solved using metaclasses, yet
> every time we hesitate to use them, because of said necessary manual
> intervention for metaclass combination.
>
> So I think we have two options now: We could deprecate metaclasses,
>

I was thinking about this last spring, when I tried to cram all sorts of
python metaprogramming into one 3hr class...

Trying to come up with a an exam[ple for metclasses, I couldn't come up
with anything that couldn't be done more claerly (to me) with a class
decorator.

I also found some commentary on the web (sorry, no links :-( ) indicating
that metacalsses were added before class decorators, and that they really
don't have a compelling use case any more.

Now it seem that not only do they not have a compelling  use case, in some
(many) instances, there are compelling reasons to NOT use them, and rather
use decorators.

So why deprecate them? or at least discourage their use?

The other option would be to simply make metaclasses work properly. We
> would just have to define a way to automatically combine metaclasses.
>

"just"?

Anyway, let's  say that is doable -- would you then be able to do something
with metaclasses that you could not do with decorators? or it in a cleaner,
easier to write or understand way?

There-should-be-one--and-preferably-only-one--obvious-way-to-do-it-ly yours,

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-10-12 Thread Chris Barker

On Thu, Oct 12, 2017 at 3:20 AM, Steve Holden  wrote:


>  The reason I liked "row" as a name is because it resembles  "vector" and
> hence is loosely assocaited with the concept of a tuple as well as being
> familiar to database users. In fact the answer to a relational query was, I
> believe, originally formally defined as a set of tuples.
>
>
Is the intent that these things preserve order? in which case, I like row
is OK (though still don't see what's wrong with record). I still dop'nt
love it though -- it gives the expectation of a row in a data table )or csv
file, or.. which will be a common use case, but really, it doesn't
conceptually have anything to do with tabular data.

in fact, one might want to store a bunch of these in, say, a 2D (or 3D)
array, then row would be pretty weird

I don't much like entity either -- it is either way to generic -- everyting
is an entity! even less specific than "object". Or two specific (and
incorrect) in the lexicon of particular domains.


-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-10-12 Thread Guido van Rossum

You're right that if it were easier to combine metaclasses we would not shy
away from them so easily.

Perhaps you and others interested in this topic can try to prototype an
implementation and see how it would work in practice (with some realistic
existing metaclasses)? Then the next step would be to write a PEP. But in
this case I really recommend trying to implement it first (in pure Python)
to see if it can actually work.

On Thu, Oct 12, 2017 at 11:21 AM, Martin Teichmann 
wrote:

> Hi list,
>
> first, a big thanks to the authors of PEP 557! Great idea!
>
> For me, the dataclasses were a typical example for inheritance, to be
> more precise, for metaclasses. I was astonished to see them
> implemented using decorators, and I was not the only one, citing
> Guido:
>
> > I think it would be useful to write 1-2 sentences about the problem with
> > inheritance -- in that case you pretty much have to use a metaclass, and
> the
> > use of a metaclass makes life harder for people who want to use their own
> > metaclass (since metaclasses don't combine without some manual
> > intervention).
>
> Python is at a weird point here. At about every new release of Python,
> a new idea shows up that could be easily solved using metaclasses, yet
> every time we hesitate to use them, because of said necessary manual
> intervention for metaclass combination.
>
> So I think we have two options now: We could deprecate metaclasses,
> going down routes like PEP 487's __init_subclass__. Unfortunately, for
> data classes __init_subclass__ it is too late in the class creation
> process for it to influence the __slots__ mechanism. A
> __new_subclass__, that acts earlier, could do the job, but to me that
> simply sounds like reinventing the wheel of metaclasses.
>
> The other option would be to simply make metaclasses work properly. We
> would just have to define a way to automatically combine metaclasses.
> Guido once mention once (here:
> https://mail.python.org/pipermail/python-dev/2017-June/148501.html)
> that he left out automatic synthesis of combined metaclasses on
> purpose, but given that this seems to be a major problem, I think it
> is about time to overthink this decision.
>
> So I propose to add such an automatic synthesis. My idea is that a
> metaclass author can define the __or__ and __ror__ methods for
> automatic metaclass synthesis. Then if a class C inherits from two
> classes A and B with metaclasses MetaA and MetaB, the metaclass would
> be MetaA | MetaB.
>
> Greetings
>
> Martin
> ___
> 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
>



-- 
--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/archive%40mail-archive.com

Re: [Python-Dev] PEP 557: Data Classes

2017-10-12 Thread Martin Teichmann

Hi list,

first, a big thanks to the authors of PEP 557! Great idea!

For me, the dataclasses were a typical example for inheritance, to be
more precise, for metaclasses. I was astonished to see them
implemented using decorators, and I was not the only one, citing
Guido:

> I think it would be useful to write 1-2 sentences about the problem with
> inheritance -- in that case you pretty much have to use a metaclass, and the
> use of a metaclass makes life harder for people who want to use their own
> metaclass (since metaclasses don't combine without some manual
> intervention).

Python is at a weird point here. At about every new release of Python,
a new idea shows up that could be easily solved using metaclasses, yet
every time we hesitate to use them, because of said necessary manual
intervention for metaclass combination.

So I think we have two options now: We could deprecate metaclasses,
going down routes like PEP 487's __init_subclass__. Unfortunately, for
data classes __init_subclass__ it is too late in the class creation
process for it to influence the __slots__ mechanism. A
__new_subclass__, that acts earlier, could do the job, but to me that
simply sounds like reinventing the wheel of metaclasses.

The other option would be to simply make metaclasses work properly. We
would just have to define a way to automatically combine metaclasses.
Guido once mention once (here:
https://mail.python.org/pipermail/python-dev/2017-June/148501.html)
that he left out automatic synthesis of combined metaclasses on
purpose, but given that this seems to be a major problem, I think it
is about time to overthink this decision.

So I propose to add such an automatic synthesis. My idea is that a
metaclass author can define the __or__ and __ror__ methods for
automatic metaclass synthesis. Then if a class C inherits from two
classes A and B with metaclasses MetaA and MetaB, the metaclass would
be MetaA | MetaB.

Greetings

Martin
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-10-12 Thread Mike Miller



On 2017-10-11 23:05, Nick Coghlan wrote:

It's akin to "static method", "class method", and "instance method" for function 
definitions (although the last one isn't a typical decorator, since it's the 
default behaviour for functions placed inside a class).


Thanks, I'm still thinking of it as inheritance for some reason.

-Mike

___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-10-12 Thread Stéfane Fermigier

On Thu, Oct 12, 2017 at 10:20 AM, Mike Miller 
wrote:

>
> On 2017-10-12 00:36, Stéfane Fermigier wrote:
>
>> "An object that is not defined by its attributes, but rather by a thread
>> of continuity and its identity." (from https://en.wikipedia.org/wiki/
>> Domain-driven_design#Building_blocks)
>>
>
> Not sure I follow all this, but Python objects do have identities once
> instantiated.  e.g. >>> id('')


Yes, for the lifetime of the object in the Python VM.

But if you are dealing with objects that are persisted using some kind of
ORM, ODM, OODB, then it wont work.

It's quite common (but not always the best solution) to use some kind of
UUID to represent the identity of each entity.

Also, there can be circumstances where two objects can exist at the same
time in the VM which represent the same object, in which case one should
ensure that a == b iff a.uid == a.uid (in the case 'uid' is the attribute
used to carry the unique identifier).


> I don't believe either module particularly supports or restricts
> immutability?


http://www.attrs.org/en/stable/examples.html#immutability
https://www.python.org/dev/peps/pep-0557/#frozen-instances

  S.


>
>
> -Mike
>
> ___
> 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/sfermigie
> r%2Blists%40gmail.com
>
>

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, Free Group / Systematic Cluster -
http://www.gt-logiciel-libre.org/
Co-Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyData Paris - http://pydata.fr/
---
“You never change things by ﬁghting the existing reality. To change
something, build a new model that makes the existing model obsolete.” — R.
Buckminster Fuller
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-10-12 Thread Stéfane Fermigier

On Wed, Oct 11, 2017 at 10:33 PM, Mike Miller 
wrote:

> (Apologies for reviving a dead horse, but may not be around at the blessed
> time.)
>
> As potential names of this concept, I liked record and row, but agreed
> they were a bit too specific and not quite exact.  In my recent (unrelated)
> reading however, I came across another term and think it might fit better,
> called an "entity."
>

I'm not familiar with ER modelling but I would advise against using the
term "entity", as it has, in domain-driven design (DDD) a very specific
meaning:

"An object that is not defined by its attributes, but rather by a thread of
continuity and its identity." (from
https://en.wikipedia.org/wiki/Domain-driven_design#Building_blocks)

See also the more general Wikipedia definition "An entity is something that
exists as itself, as a subject or as an object, actually or potentially,
concretely or abstractly, physically or not." (
https://en.wikipedia.org/wiki/Entity).

In the context of DDD, entities are usually opposed to value objects: "An
object that contains attributes but has no conceptual identity. They should
be treated as immutable.". (
https://en.wikipedia.org/wiki/Domain-driven_design#Building_blocks)

Attrs, and by extension the dataclass proposal (I guess), provide some
support for both:

- Providing support for quickly constructing immutable objects from a bag
of attributes, and providing equality based on those attributes, it helps
implement Value Objects (not sure much more is needed actually)

- By supporting equality based on some "primary key", it will also help
with maintaining the concept of "equality" in entities.

It would be great if the dataclass proposal could help implement DDD
technical concepts in Python, but its terminology should not conflict the
DDD terminology, if we want to avoid confusion.

Cheers,

  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Chairman, Free Group / Systematic Cluster -
http://www.gt-logiciel-libre.org/
Co-Chairman, National Council for Free & Open Source Software (CNLL) -
http://cnll.fr/
Founder & Organiser, PyData Paris - http://pydata.fr/
---
“You never change things by ﬁghting the existing reality. To change
something, build a new model that makes the existing model obsolete.” — R.
Buckminster Fuller
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-10-12 Thread Barry Warsaw

On Oct 12, 2017, at 10:46, Guido van Rossum  wrote:
> 
> I am still firmly convinced that @dataclass is the right name for the 
> decorator (and `dataclasses` for the module).

Darn, and I was going to suggest they be called EricTheHalfABees, with enums 
being renamed to EricTheHalfNotBees.

-Barry





signature.asc
Description: Message signed with OpenPGP
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-10-12 Thread Guido van Rossum

I am still firmly convinced that @dataclass is the right name for the
decorator (and `dataclasses` for the module).

-- 
--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/archive%40mail-archive.com

Re: [Python-Dev] PEP 557: Data Classes

2017-10-12 Thread Gustavo Carneiro

On 12 October 2017 at 11:20, Steve Holden  wrote:

> On Thu, Oct 12, 2017 at 9:20 AM, Mike Miller 
> wrote:
>
>>
>> On 2017-10-12 00:36, Stéfane Fermigier wrote:
>>
>>> "An object that is not defined by its attributes, but rather by a thread
>>> of continuity and its identity." (from https://en.wikipedia.org/wiki/
>>> Domain-driven_design#Building_blocks)
>>>
>>
>> Not sure I follow all this, but Python objects do have identities once
>> instantiated.  e.g. >>> id('')
>>
>> It seems to me that the quoted document is attempting to make a
> distinction similar to the one between classes (entities) and instances
> (value objects). The reason I liked "row" as a name is because it
> resembles  "vector" and hence is loosely assocaited with the concept of a
> tuple as well as being familiar to database users. In fact the answer to a
> relational query was, I believe, originally formally defined as a set of
> tuples.
>

But rows and tuples are usually immutable, at least in database terms.
These data classes are not immutable (by default).  If you want tuple-like
behaviour, you can continue to use tuples.

I see dataclasses as something closer to C `struct`.  Most likely someone
already considered `struct` as name; if not, please consider it.  Else
stick with dataclass, it's a good name IMHO.
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-10-12 Thread Steve Holden

On Thu, Oct 12, 2017 at 9:20 AM, Mike Miller 
wrote:

>
> On 2017-10-12 00:36, Stéfane Fermigier wrote:
>
>> "An object that is not defined by its attributes, but rather by a thread
>> of continuity and its identity." (from https://en.wikipedia.org/wiki/
>> Domain-driven_design#Building_blocks)
>>
>
> Not sure I follow all this, but Python objects do have identities once
> instantiated.  e.g. >>> id('')
>
> It seems to me that the quoted document is attempting to make a
distinction similar to the one between classes (entities) and instances
(value objects). The reason I liked "row" as a name is because it
resembles  "vector" and hence is loosely assocaited with the concept of a
tuple as well as being familiar to database users. In fact the answer to a
relational query was, I believe, originally formally defined as a set of
tuples.

Sometimes one can simply be too hifalutin' [
http://www.dictionary.com/browse/hifalutin], and language that attempts to
be precise obscures meaning to the less specialised reader.

See also the more general Wikipedia definition "An entity is something that
>> exists as itself, as a subject or as an object, actually or potentially,
>> concretely or abstractly, physically or not." (
>> https://en.wikipedia.org/wiki/Entity).
>>
>> In the context of DDD, entities are usually opposed to value objects: "An
>> object that contains attributes but has no conceptual identity. They should
>> be treated as immutable.". (https://en.wikipedia.org/wiki
>> /Domain-driven_design#Building_blocks)
>>
>> Attrs, and by extension the dataclass proposal (I guess), provide some
>> support for both:
>>
>> - Providing support for quickly constructing immutable objects from a bag
>> of attributes, and providing equality based on those attributes, it helps
>> implement Value Objects (not sure much more is needed actually)
>>
>> - By supporting equality based on some "primary key", it will also help
>> with maintaining the concept of "equality" in entities.
>>
>
> I don't believe either module particularly supports or restricts
> immutability?
>
> -Mike
>
>
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-10-12 Thread Mike Miller



On 2017-10-12 00:36, Stéfane Fermigier wrote:
"An object that is not defined by its attributes, but rather by a thread of 
continuity and its identity." (from 
https://en.wikipedia.org/wiki/Domain-driven_design#Building_blocks)


Not sure I follow all this, but Python objects do have identities once 
instantiated.  e.g. >>> id('')


See also the more general Wikipedia definition "An entity is something that 
exists as itself, as a subject or as an object, actually or potentially, 
concretely or abstractly, physically or not." 
(https://en.wikipedia.org/wiki/Entity).


In the context of DDD, entities are usually opposed to value objects: "An object 
that contains attributes but has no conceptual identity. They should be treated 
as immutable.". (https://en.wikipedia.org/wiki/Domain-driven_design#Building_blocks)


Attrs, and by extension the dataclass proposal (I guess), provide some support 
for both:


- Providing support for quickly constructing immutable objects from a bag of 
attributes, and providing equality based on those attributes, it helps implement 
Value Objects (not sure much more is needed actually)


- By supporting equality based on some "primary key", it will also help with 
maintaining the concept of "equality" in entities.


I don't believe either module particularly supports or restricts immutability?

-Mike
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-10-12 Thread Nick Coghlan

On 12 October 2017 at 14:49, Mike Miller  wrote:

>
> On 2017-10-11 19:56, Nick Coghlan wrote:
>
>>  From my perspective, the main benefit of a compound name like "data
>> class" is that it emphasises a deliberate behavioural choice (adopted from
>> attrs): data classes are just regular classes, with some definition time
>> logic to help define data fields.
>>
>
> IMO, the problem with the dataclass name isn't the data part, but the
> "class" part.  No other class has "class" in its name(?), not even object.
> The Department of Redundancy Department will love it.
>
> If it must be a compound name, it should rather be dataobject, no?
>

No, because dataclass is the name of a class decorator ("This class is a
data class"), not the name of a type.

It's akin to "static method", "class method", and "instance method" for
function definitions (although the last one isn't a typical decorator,
since it's the default behaviour for functions placed inside a class).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-10-11 Thread Mike Miller



On 2017-10-11 19:56, Nick Coghlan wrote:
 From my perspective, the main benefit of a compound name like "data class" is 
that it emphasises a deliberate behavioural choice (adopted from attrs): data 
classes are just regular classes, with some definition time logic to help define 
data fields.


IMO, the problem with the dataclass name isn't the data part, but the "class" 
part.  No other class has "class" in its name(?), not even object.  The 
Department of Redundancy Department will love it.


If it must be a compound name, it should rather be dataobject, no?

By contrast, if we give them their own name (as with suggestions like record, 
row, entity), that makes them start to sound more like enums: an alternative 
base class with different runtime behaviour from a regular class.


This pep also adds many methods for use at runtime, though perhaps the behavior 
is more subtle.


P.S. I'll grant that this reasoning doesn't entirely mesh with the naming of 
"Abstract Base Class", but that phrase at least explicitly has the word "base" 
in it, suggesting that inheritance is involved in the way it works.


There was some discussion over inheritance vs. decoration, not sure if it was 
settled.


(Just noticed that the abc module got away with a class name of "ABC," perhaps 
dataclass would be more palatable as "DC", though entity sounds a bit nicer.)


Cheers,
-Mike
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-10-11 Thread Nick Coghlan

On 12 October 2017 at 06:33, Mike Miller  wrote:

> (Apologies for reviving a dead horse, but may not be around at the blessed
> time.)
>
> As potential names of this concept, I liked record and row, but agreed
> they were a bit too specific and not quite exact.  In my recent (unrelated)
> reading however, I came across another term and think it might fit better,
> called an "entity."
>
> It has some nice properties:
>
> - Traditional dictionary definition, meaning "thing"
> - Same specificity as the current base-class name: object
> - Corresponds to a class or instance (depending on context) in data
>   terminology
>

>From my perspective, the main benefit of a compound name like "data class"
is that it emphasises a deliberate behavioural choice (adopted from attrs):
data classes are just regular classes, with some definition time logic to
help define data fields.

By contrast, if we give them their own name (as with suggestions like
record, row, entity), that makes them start to sound more like enums: an
alternative base class with different runtime behaviour from a regular
class.

Cheers,
Nick.

P.S. I'll grant that this reasoning doesn't entirely mesh with the naming
of "Abstract Base Class", but that phrase at least explicitly has the word
"base" in it, suggesting that inheritance is involved in the way it works.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-10-11 Thread Mike Miller


(Apologies for reviving a dead horse, but may not be around at the blessed 
time.)

As potential names of this concept, I liked record and row, but agreed they were 
a bit too specific and not quite exact.  In my recent (unrelated) reading 
however, I came across another term and think it might fit better, called an 
"entity."


It has some nice properties:

- Traditional dictionary definition, meaning "thing"
- Same specificity as the current base-class name: object
- Corresponds to a class or instance (depending on context) in data
  terminology


From: http://ewebarchitecture.com/web-databases/database-entities

An entity is a thing or object of importance about which data must be
captured. Information about an entity is captured in the form of attributes
and/or relationships.

All things aren't entities—only those about which information should be
captured. If something is a candidate for being an entity and it has no
attributes or relationships, it isn't an entity.


Thoughts?  Another candidate is "container" but is not very descriptive.

-Mike



On 2017-09-16 11:14, Steve Holden wrote:
I therefore propose "row", which is sufficiently neutral to avoid most current 
opposition and yet a common field-oriented mechanism for accessing units of 
retrieved data by name.

___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-09-18 Thread Glenn Linderman


On 9/18/2017 11:37 AM, Ethan Furman wrote:

On 09/11/2017 03:28 PM, Guido van Rossum wrote:

Oddly I don't like the enum (flag names get too long that way), but I 
do agree with everything else Barry said (it

should be a trivalue flag and please don't name it cmp).


Hmmm, named constants are one of the motivating factors for having an 
Enum type.  It's easy to keep the name a reasonable length, however: 
export them into the module-level namespace.  re is an excellent 
example; the existing flags were moved into a FlagEnum, and then (for 
backwards compatibility) aliased back to the module level:

snip

Likewise, if we had:

    class Compare(enum.Enum):
    NONE = 'each instance is an island'
    EQUAL = 'instances can be equal to each other'
    ORDERED = 'instances can be ordered and/or equal'
    globals().update(Compare.__members__)

then we can still use, for example, EQUAL, but get the more 
informative repr and str when we need to.


I tend to like the Enum also. But maybe this is a case where there 
should be multiple different decorators:


@dataclass
@equality_dataclass
@ordered_datatclass
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-09-18 Thread Ethan Furman


On 09/11/2017 03:28 PM, Guido van Rossum wrote:


Oddly I don't like the enum (flag names get too long that way), but I do agree 
with everything else Barry said (it
should be a trivalue flag and please don't name it cmp).


Hmmm, named constants are one of the motivating factors for having an Enum type.  It's easy to keep the name a 
reasonable length, however: export them into the module-level namespace.  re is an excellent example; the existing flags 
were moved into a FlagEnum, and then (for backwards compatibility) aliased back to the module level:


class RegexFlag(enum.IntFlag):
ASCII = sre_compile.SRE_FLAG_ASCII # assume ascii "locale"
IGNORECASE = sre_compile.SRE_FLAG_IGNORECASE # ignore case
LOCALE = sre_compile.SRE_FLAG_LOCALE # assume current 8-bit locale
UNICODE = sre_compile.SRE_FLAG_UNICODE # assume unicode "locale"
MULTILINE = sre_compile.SRE_FLAG_MULTILINE # make anchors look for 
newline
DOTALL = sre_compile.SRE_FLAG_DOTALL # make dot match newline
VERBOSE = sre_compile.SRE_FLAG_VERBOSE # ignore whitespace and comments
A = ASCII
I = IGNORECASE
L = LOCALE
U = UNICODE
M = MULTILINE
S = DOTALL
X = VERBOSE
# sre extensions (experimental, don't rely on these)
TEMPLATE = sre_compile.SRE_FLAG_TEMPLATE # disable backtracking
T = TEMPLATE
DEBUG = sre_compile.SRE_FLAG_DEBUG # dump pattern after compilation
globals().update(RegexFlag.__members__)

So we can still do re.I instead of re.RegexFlag.I.

Likewise, if we had:

class Compare(enum.Enum):
NONE = 'each instance is an island'
EQUAL = 'instances can be equal to each other'
ORDERED = 'instances can be ordered and/or equal'
globals().update(Compare.__members__)

then we can still use, for example, EQUAL, but get the more informative repr 
and str when we need to.

--
~Ethan~
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-09-16 Thread Steve Holden

I make this suggestion in trepidation, given that Guido called a halt on
the Great Naming Debate, but it seems that a short, neutral name with data
connotations previously not a part of many popular subsystems is required.

I therefore propose "row", which is sufficiently neutral to avoid most
current opposition and yet a common field-oriented mechanism for accessing
units of retrieved data by name.

regards
 Steve

Steve Holden

On Sat, Sep 16, 2017 at 3:44 PM, Sven R. Kunze  wrote:

> Thanks for the PEP! :)
>
> I like the naming. ;) Though, I would like to add to Michel's argument in
> favor of a base class.
>
>
> On 11.09.2017 08:38, Michel Desmoulin wrote:
>
>> - I read Guido talking about some base class as alternative to the
 generator version, but don't see it in the PEP. Is it still considered ?

>>> I'm going to put some words in explaining why I don't want to use base
>>> classes (I don't think it buys you anything). Do you have a reason for
>>> preferring base classes?
>>>
>> Not preferring, but having it as an alternative. Mainly for 2 reasons:
>>
>> 1 - data classes allow one to type in classes very quickly, let's
>> harvest the benefit from that.
>>
>> Typing a decorator in a shell is much less comfortable than using
>> inheritance. Same thing about IDE: all current ones have snippet with
>> auto-switch to the class parents on tab.
>>
>> All in all, if you are doing exploratory programming, and thus
>> disposable code, which data classes are fantastic for, inheritance will
>> keep you in the flow.
>>
>> 2 - it will help sell the data classes
>>
>> I train a lot of people to Python each year. I never have to explain
>> classes to people with any kind of programming background. I _always_
>> have to explain decorators.
>>
>> People are not used to it, and even kind fear it for quite some time.
>>
>> Inheritance however, is familiar, and will not only push people to use
>> data classes more, but also will let them do less mistakes: they know
>> the danger of parent ordering, but not the ones of decorators ordering.
>>
>
> 3)  - the order of base classes can arranged appropriately
>
> In our day-to-day work, we use mixins and cooperative multiple inheritance
> a lot.
> So, having dataclasses as a base class or a mixin would be great! :)
>
> Combined with 1) and 2), I am much in favor of having dataclasses as base
> class/mixin than as a decorator.
> What are the benefits of the decorator? Maybe both is possible?
>
> Cheers,
> Sven
>
>
> PS: @Michel good observation 1). Typing decorators in shell is annoying.
>
> ___
> 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/steve%
> 40holdenweb.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

Re: [Python-Dev] PEP 557: Data Classes

2017-09-16 Thread Sven R. Kunze


Thanks for the PEP! :)

I like the naming. ;) Though, I would like to add to Michel's argument 
in favor of a base class.



On 11.09.2017 08:38, Michel Desmoulin wrote:

- I read Guido talking about some base class as alternative to the
generator version, but don't see it in the PEP. Is it still considered ?

I'm going to put some words in explaining why I don't want to use base
classes (I don't think it buys you anything). Do you have a reason for
preferring base classes?

Not preferring, but having it as an alternative. Mainly for 2 reasons:

1 - data classes allow one to type in classes very quickly, let's
harvest the benefit from that.

Typing a decorator in a shell is much less comfortable than using
inheritance. Same thing about IDE: all current ones have snippet with
auto-switch to the class parents on tab.

All in all, if you are doing exploratory programming, and thus
disposable code, which data classes are fantastic for, inheritance will
keep you in the flow.

2 - it will help sell the data classes

I train a lot of people to Python each year. I never have to explain
classes to people with any kind of programming background. I _always_
have to explain decorators.

People are not used to it, and even kind fear it for quite some time.

Inheritance however, is familiar, and will not only push people to use
data classes more, but also will let them do less mistakes: they know
the danger of parent ordering, but not the ones of decorators ordering.


3)  - the order of base classes can arranged appropriately

In our day-to-day work, we use mixins and cooperative multiple 
inheritance a lot.

So, having dataclasses as a base class or a mixin would be great! :)

Combined with 1) and 2), I am much in favor of having dataclasses as 
base class/mixin than as a decorator.

What are the benefits of the decorator? Maybe both is possible?

Cheers,
Sven


PS: @Michel good observation 1). Typing decorators in shell is annoying.
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-09-15 Thread Mike Miller



On 2017-09-15 05:08, Michel Desmoulin wrote:

Because given how convenient it is, it will most probably becomes the
default way to write classes in Python. Not just for record.


Yes, would have been great if this was how the original object worked and the 
current barebones object was a base(object) or something like that.  Too late 
however.


Another option was "bag" which is more generic and brief, and might seem to fit 
better, but the discussion went towards record.


-Mike
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-09-15 Thread Michel Desmoulin

Le 14/09/2017 à 19:24, Mike Miller a écrit :
> 
> On 2017-09-12 21:05, Guido van Rossum wrote:
>> It's ironic that some people dislike "data classes" because these are
>> regular classes, not just for data, while others are proposing
>> alternative names that emphasize the data container aspect. So "data
>> classes" splits the difference, by referring to both data and classes.
> 
> True that these data-classes will be a superset of a traditional
> record.  But, we already have objects and inheritance for those use
> cases.  The data-class is meant to be used primarily like a record, so
> why not name it that way?

Because given how convenient it is, it will most probably becomes the
default way to write classes in Python. Not just for record.

Everybody end up wishing for a less verbose way to write day to day
classes after a while.
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-09-14 Thread Nick Coghlan

On 15 September 2017 at 02:56, Mike Miller  wrote:
>
> On 2017-09-12 19:09, Nick Coghlan wrote:
>>
>> On 13 September 2017 at 02:01, Chris Barker - NOAA Federal
>>  wrote:
>>>
>>> This really does match well with the record concept in databases, and
>>> most
>>> people are familiar with that.
>>
>>
>> No, most people aren't familiar with that - they only become familiar
>> with it *after* they've learned to program and learned what a database
>> is.
>
>
> Pretty sure he was talking about programmers, and they are introduced to the
> concept early.  Structs, objects with fields, random access files,
> databases, etc.  Lay-folks are familiar with "keeping records" as you
> mention, but they are not the primary customer it seems.

Python is an incredibly common first programming language, so we need
to keep folks with *zero* knowledge of programming jargon firmly in
mind when designing new features. That isn't always the most important
consideration, but it's always *a* consideration.

And, as Stefan notes in his reply, we also need to keep *misleading*
inferences in mind when we consider repurposing existing jargon for a
new use case - what seems like an obviously intuitive connection based
on our own individual experiences with a term may turn out to be
extremely counterintuitive for someone with a different experience of
the same term.

In such cases, it can make sense to look for new *semantically
neutral* terminology as the official glossary entry and API naming
scheme, and rely on documentation to indicate that this is a
realisation of a feature that goes by other names in other contexts.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-09-14 Thread Guido van Rossum

Let's all please take a time out from the naming discussion.

On Sep 14, 2017 11:15 AM, "Stefan Krah"  wrote:

> On Thu, Sep 14, 2017 at 11:06:15AM -0700, Mike Miller wrote:
> > On 2017-09-14 10:45, Stefan Krah wrote:
> > >I'd expect something like a C struct or an ML record.
> >
> > Struct is taken, and your second example is record.
>
> *If* the name were collections.record, I'd expect collections.record to
> be something like a C struct or an ML record. I'm NOT proposing "record".
>
>
> > > from dataclass import dataclass
> > >
> > >This is more intuitive, since the PEP example also has attached methods
> > >like total_cost().  I don't think this is really common for records.
> >
> > Every class can be extended, does that mean they can't be given
> appropriate names?
>
> A class is not a record. This brief conversation already convinced me that
> "record" is a bad name for the proposed construct.
>
>
>
> Stefan Krah
>
>
>
> ___
> 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
>
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-09-14 Thread Stefan Krah

On Thu, Sep 14, 2017 at 11:06:15AM -0700, Mike Miller wrote:
> On 2017-09-14 10:45, Stefan Krah wrote:
> >I'd expect something like a C struct or an ML record.
> 
> Struct is taken, and your second example is record.

*If* the name were collections.record, I'd expect collections.record to
be something like a C struct or an ML record. I'm NOT proposing "record".


> > from dataclass import dataclass
> >
> >This is more intuitive, since the PEP example also has attached methods
> >like total_cost().  I don't think this is really common for records.
> 
> Every class can be extended, does that mean they can't be given appropriate 
> names?

A class is not a record. This brief conversation already convinced me that
"record" is a bad name for the proposed construct.



Stefan Krah



___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-09-14 Thread Barry Warsaw

On Sep 14, 2017, at 09:56, Mike Miller  wrote:

> Record is the most common name for this ubiquitous concept.

Mind if we call them Eric Classes to keep it clear?  Because if its name is not 
Eric Classes, it will cause a little confusion.

g’day-bruce-ly y’rs,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-09-14 Thread Mike Miller



On 2017-09-14 10:45, Stefan Krah wrote:

I'd expect something like a C struct or an ML record.


Struct is taken, and your second example is record.



 from dataclass import dataclass

This is more intuitive, since the PEP example also has attached methods
like total_cost().  I don't think this is really common for records.


Every class can be extended, does that mean they can't be given appropriate 
names?

(Not to mention dataclass is hardly intuitive for something that can have 
methods added.)


-Mike
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-09-14 Thread Stefan Krah

On Thu, Sep 14, 2017 at 10:24:52AM -0700, Mike Miller wrote:
> An elegant name can make the difference between another obscure
> module thrown in the stdlib to be never seen again and one that gets
> used every day.  Which is more intuitive?
> 
> from collections import record

I'd expect something like a C struct or an ML record.


> from dataclass import dataclass

This is more intuitive, since the PEP example also has attached methods
like total_cost().  I don't think this is really common for records.



Stefan Krah



___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-09-14 Thread Mike Miller



On 2017-09-12 21:05, Guido van Rossum wrote:
It's ironic that some people dislike "data classes" because these are regular 
classes, not just for data, while others are proposing alternative names that 
emphasize the data container aspect. So "data classes" splits the difference, by 
referring to both data and classes.


True that these data-classes will be a superset of a traditional record.  But, 
we already have objects and inheritance for those use cases.  The data-class is 
meant to be used primarily like a record, so why not name it that way?


Almost everything is extensible in Python; that shouldn't prevent focused names, 
should it?




Let's bikeshed about something else.


An elegant name can make the difference between another obscure module thrown in 
the stdlib to be never seen again and one that gets used every day.  Which is 
more intuitive?


from collections import record

from dataclass import dataclass



Would the language be as nice if "object" was named an "instanceclass?"  Or 
perhaps the "requests" module could have been named "httpcall."  Much of the 
reluctance to use the attrs module is about its weird naming.


Due to the fact that this is a simple, potentially ubiquitous enhancement an 
elegant name is important.  "For humans," or something, haha.


-Mike
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-09-14 Thread Mike Miller



On 2017-09-12 19:09, Nick Coghlan wrote:

On 13 September 2017 at 02:01, Chris Barker - NOAA Federal
 wrote:

This really does match well with the record concept in databases, and most
people are familiar with that.


No, most people aren't familiar with that - they only become familiar
with it *after* they've learned to program and learned what a database
is.


Pretty sure he was talking about programmers, and they are introduced to the 
concept early.  Structs, objects with fields, random access files, databases, 
etc.  Lay-folks are familiar with "keeping records" as you mention, but they are 
not the primary customer it seems.


Record is the most common name for this ubiquitous concept.



whether its referring to the noun (wreck-ord) or the verb (ree-cord).


This can be grasped from context quickly, and due to mentioned ubiquity, not 
likely to be a problem in the real world.  "Am I going to ree-cord this class?"




Also, considering their uses, it might make sense to put them in the
collections module.


Data classes are things you're likely to put *in* a collection, rather
than really being collections themselves (they're only collections in
the same sense that all Python classes are collections of attributes,
and that's not the way the collections module uses the term).



Yes, a collection of attributes, not significantly different than the namedtuple 
(that began this thread) or the various dictionaries implemented there already. 
The criteria doesn't appear to be very strict, should it be?


(Also, could be put into a submodule and imported into it maintain modularity. 
Where it lands though isn't so important, just that collections is relatively 
likely to be imported already on medium sized projects, and I think the 
definition fits, collections == "bags of stuff".)


Cheers,
-Mike
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-09-13 Thread Eric V. Smith


On 9/10/2017 11:08 PM, Nathaniel Smith wrote:

Hi Eric,

A few quick comments:

Why do you even have a hash= argument on individual fields? For the 
whole class, I can imagine you might want to explicitly mark a whole 
class as unhashable, but it seems like the only thing you can do with 
the field-level hash= argument is to create a class where the __hash__ 
and __eq__ take different fields into account, and why would you ever 
want that?


See the discussion at 
https://github.com/ericvsmith/dataclasses/issues/44 for why we're 
keeping the field-level hash function.


Quick version, from Guido: "There's a legitimate reason for having a 
field in the eq but not in the hash. After all hash is always followed 
by an eq check and it is totally legit for the eq check to say two 
objects are not equal even though their hashes are equal."


This would be in the case where a field should be used for equality 
testing, but computing its hash is expensive.


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/archive%40mail-archive.com

Re: [Python-Dev] PEP 557: Data Classes

2017-09-12 Thread Guido van Rossum

On Tue, Sep 12, 2017 at 7:09 PM, Nick Coghlan  wrote:

> So in this case, the vagueness of "data class" is considered a feature
> - since it doesn't inherently mean *anything*, folks are more likely
> to realise that they need to look up "Python data class", and if I
> search for that in a private window, the first Google hit is
> https://stackoverflow.com/questions/3357581/using-python-class-as-a-data-
> container
> and the second is Eric's PEP.
>

I think "data classes" is a fine moniker for this concept.

It's ironic that some people dislike "data classes" because these are
regular classes, not just for data, while others are proposing alternative
names that emphasize the data container aspect. So "data classes" splits
the difference, by referring to both data and classes.

Let's bikeshed about something else.

-- 
--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/archive%40mail-archive.com

Re: [Python-Dev] PEP 557: Data Classes

2017-09-12 Thread Nick Coghlan

On 13 September 2017 at 02:01, Chris Barker - NOAA Federal
 wrote:
> This really does match well with the record concept in databases, and most
> people are familiar with that.

No, most people aren't familiar with that - they only become familiar
with it *after* they've learned to program and learned what a database
is.

> Though it will. E a touch confusing until (if
> ever) most of the database and cab traders, etc start using them.

Aside from the potential confusion with other technical uses of
"record", a further problem with "record" is that it's ambiguous as to
whether its referring to the noun (wreck-ord) or the verb (ree-cord).
Even if folks correctly interpret it as a noun, there's still plenty
of opportunities for folks to guess incorrectly about what it means
based on the other conventional English uses of the word (e.g. a
"personal record" will consist of multiple "records" in the database
sense).

So in this case, the vagueness of "data class" is considered a feature
- since it doesn't inherently mean *anything*, folks are more likely
to realise that they need to look up "Python data class", and if I
search for that in a private window, the first Google hit is
https://stackoverflow.com/questions/3357581/using-python-class-as-a-data-container
and the second is Eric's PEP.

> Also, considering their uses, it might make sense to put them in the
> collections module.

Data classes are things you're likely to put *in* a collection, rather
than really being collections themselves (they're only collections in
the same sense that all Python classes are collections of attributes,
and that's not the way the collections module uses the term).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-09-12 Thread Chris Barker - NOAA Federal

- record


+1

This really does match well with the record concept in databases, and most
people are familiar with that. Though it will. E a touch confusing until
(if ever) most of the database and cab traders, etc start using them.

It also matches pretty well with numpy "record arrays":

https://docs.scipy.org/doc/numpy-1.13.0/user/basics.rec.html

- bag


I also like this -- not many folks will have a ore-conceived notion of what
it is.

- declarative


Yeach-- that's an adjective (at least on most common use) -- and a
programming term that means something else.

Also, considering their uses, it might make sense to put them in the
collections module.


Yup.

-CHB
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-09-12 Thread Chris Barker - NOAA Federal

> On Sep 12, 2017, at 9:01 AM, Chris Barker - NOAA Federal 
>  wrote:

> This really does match well with the record concept in databases, and most 
> people are familiar with that. Though it will. E a touch confusing until (if 
> ever) most of the database and cab traders, etc start using them.

I REALLY need to stop quickly posting from my phone...


... Though it will be a touch confusing until (if ever) most of the
database and csv readers etc. start using them.

-CHB
___
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

Re: [Python-Dev] PEP 557: Data Classes

On Mon, Sep 11, 2017 at 8:21 PM, Barry Warsaw  wrote:

> On Sep 11, 2017, at 19:16, Guido van Rossum  wrote:
> >
> > Or we could just have two arguments, eq= and order=, and
> some rule so that you only need to specify one or the other but not both.
> (E.g. order=True implies eq=True.) That seems better than needing new
> constants just for this flag.
>
> You’d have to disallow the combination `order=True, eq=False` then,
> right?  Or would you ignore eq for any value of order=True?  Seems like a
> clumsier API than a single tri-value parameter.  Do the module constants
> bother you that much?

Yes they do. You may have to import them, or you have to prefix them with
the module name -- whereas keyword args and True/False require neither.

We could disallow order=True, eq=True. Or we could have the default being
to generate __eq__, __ne__ and __hash__, and a flag to prevent these (since
equality by object identity is probably less popular than equality by
elementwise comparison).

Perhaps:

order: bool = False
eq: bool = True

and disallowing order=True, eq=False.

-- 
--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/archive%40mail-archive.com

Re: [Python-Dev] PEP 557: Data Classes

On Sep 11, 2017, at 19:16, Guido van Rossum  wrote:
> 
> Or we could just have two arguments, eq= and order=, and some 
> rule so that you only need to specify one or the other but not both. (E.g. 
> order=True implies eq=True.) That seems better than needing new constants 
> just for this flag.

You’d have to disallow the combination `order=True, eq=False` then, right?  Or 
would you ignore eq for any value of order=True?  Seems like a clumsier API 
than a single tri-value parameter.  Do the module constants bother you that 
much?

-Barry

signature.asc
Description: Message signed with OpenPGP
___
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

Re: [Python-Dev] PEP 557: Data Classes

Or we could just have two arguments, eq= and order=, and some
rule so that you only need to specify one or the other but not both. (E.g.
order=True implies eq=True.) That seems better than needing new constants
just for this flag.

On Mon, Sep 11, 2017 at 6:49 PM, Barry Warsaw  wrote:

> On Sep 11, 2017, at 18:36, Eric V. Smith  wrote:
> > So if we don't do enums, I think the choices are ints, strs, or maybe
> True/False/None. Do you have a preference here?
> >
> > If int or str, I assume we'd want module-level constants.
> >
> > I like the name compare=, and 3 values makes sense: None, Equality,
> Ordered.
>
> +1 for the name, the 3 values, and making them module constants.  After
> that, I don’t think it really matters what their implementation is.  User
> code will look the same either way.  One minor nice effect of using an enum
> is that the dataclass function can use `is` instead of `==` to compare
> keyword argument values.
>
> -Barry
>
>
> ___
> 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
>
>


-- 
--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/archive%40mail-archive.com

Re: [Python-Dev] PEP 557: Data Classes

On Sep 11, 2017, at 18:36, Eric V. Smith  wrote:
> So if we don't do enums, I think the choices are ints, strs, or maybe 
> True/False/None. Do you have a preference here?
> 
> If int or str, I assume we'd want module-level constants.
> 
> I like the name compare=, and 3 values makes sense: None, Equality, Ordered.

+1 for the name, the 3 values, and making them module constants.  After that, I 
don’t think it really matters what their implementation is.  User code will 
look the same either way.  One minor nice effect of using an enum is that the 
dataclass function can use `is` instead of `==` to compare keyword argument 
values.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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

Re: [Python-Dev] PEP 557: Data Classes


On 9/11/2017 6:28 PM, Guido van Rossum wrote:
Oddly I don't like the enum (flag names get too long that way), but I do 
agree with everything else Barry said (it should be a trivalue flag and 
please don't name it cmp).


So if we don't do enums, I think the choices are ints, strs, or maybe 
True/False/None. Do you have a preference here?


If int or str, I assume we'd want module-level constants.

I like the name compare=, and 3 values makes sense: None, Equality, Ordered.

Eric.



On Mon, Sep 11, 2017 at 3:16 PM, Ethan Furman > wrote:


On 09/11/2017 03:00 PM, Barry Warsaw wrote:

On Sep 10, 2017, at 20:08, Nathaniel Smith wrote:


I've sometimes wished that attrs let me control whether it
generated equality methods (eq/ne/hash) separately from
ordering methods (lt/gt/...). Maybe the cmp= argument should
take an enum with options none/equality-only/full?


I have had use cases where I needed equality comparisons but not
ordered comparisons, so I’m in favor of the option to split
them.  (atm, I can’t bring up a specific case, but it’s not
uncommon.)

Given that you only want to support the three states that
Nathaniel describes, I think an enum makes the most sense, and
it certainly would read well.  I.e. there’s no sense in
supporting the ordered comparisons and not equality, so that’s
not a state that needs to be represented.

I’d make one other suggestion here: please let’s not call the
keyword `cmp`.  That’s reminiscent of Python 2’s `cmp` built-in,
which of course doesn’t exist in Python 3.  Using `cmp` is just
an unnecessarily obfuscating abbreviation.  I’d suggest just
`compare` with an enum like so:

enum Compare(enum.Enum):
      none = 1
      unordered = 2
      ordered = 3


I like the enum idea (suprise! ;) but I would suggest "equal" or
"equivalent" instead of "unordered"; better to say what they are
rather than what they are not.

--
~Ethan~

___
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 





--
--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%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

Re: [Python-Dev] PEP 557: Data Classes


On 9/11/2017 12:34 PM, Nathaniel Smith wrote:

On Mon, Sep 11, 2017 at 5:32 AM, Eric V. Smith  wrote:

On 9/10/17 11:08 PM, Nathaniel Smith wrote:

Why do you even have a hash= argument on individual fields? For the
whole class, I can imagine you might want to explicitly mark a whole
class as unhashable, but it seems like the only thing you can do with
the field-level hash= argument is to create a class where the __hash__
and __eq__ take different fields into account, and why would you ever
want that?



The use case is that you have a cache, or something similar, that doesn't
affect the object identity.


But wouldn't this just be field(cmp=False), no need to fiddle with hash=?


Ah, true. You're right, I can't see any good use for setting hash on a 
field that isn't already controlled by cmp. I think field level hash can go.



Though honestly I can see a reasonable argument for removing the
class-level hash= option too. And even if you keep it you might want to
error on some truly nonsensical options like defining __hash__ without
__eq__. (Also watch out that Python's usual rule about defining __eq__
blocking the inheritance of __hash__ does not kick in if __eq__ is added
after the class is created.)


At the class level, I think it makes more sense. But I'll write up some 
motivating examples.

I've sometimes wished that attrs let me control whether it generated
equality methods (eq/ne/hash) separately from ordering methods
(lt/gt/...). Maybe the cmp= argument should take an enum with options
none/equality-only/full?



Yeah, I've thought about this, too. But I don't have any use case in mind,
and if it hasn't come up with attrs, then I'm reluctant to break new ground
here.


https://github.com/python-attrs/attrs/issues/170

 From that thread, it feels like part of the problem is that it's
awkward to encode this using only boolean arguments, but they're sort
of stuck with that for backcompat with how they originally defined
cmp=, hence my suggestion to consider making it an enum from the start
:-).


I'll respond to other emails about this, probably tomorrow.

Eric.


The "why not attrs" section kind of reads like "because it's too popular
and useful"?



I'll add some words to that section, probably focused on typing
compatibility. My general feeling is that attrs has some great design
decisions, but goes a little too far (e.g., conversions, validations). As
with most things we add, I'm trying to be as minimalist as possible, while
still being widely useful and allowing 3rd party extensions and future
features.


If the question is "given that we're going to add something to the
stdlib, why shouldn't that thing be attrs?" then I guess it's
sufficient to say "because the attrs developers didn't want it". But I
think the PEP should also address the question "why are we adding
something to the stdlib, instead of just recommending people install
attrs".

-n
___
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

Re: [Python-Dev] PEP 557: Data Classes



On 2017-09-11 17:00, Barry Warsaw wrote:


I’ve used ‘bag’ too, but I’m not sure that’s descriptive enough for the stdlib.


Well, "the Pythons" were irreverent, were they not?  ;)

-Mike

___
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

Re: [Python-Dev] PEP 557: Data Classes

On Sep 11, 2017, at 16:51, Mike Miller  wrote:
> 
> On 2017-09-11 05:26, Eric V. Smith wrote:
>> On 9/10/17 10:27 PM, Raymond Hettinger wrote:
> 
> I've typically used these type of objects as records.  When in an irreverent 
> mood I've called them bags.

I’ve used ‘bag’ too, but I’m not sure that’s descriptive enough for the stdlib.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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

Re: [Python-Dev] PEP 557: Data Classes



On 2017-09-11 05:26, Eric V. Smith wrote:

On 9/10/17 10:27 PM, Raymond Hettinger wrote:


I've typically used these type of objects as records.  When in an irreverent 
mood I've called them bags.  The short name is helpful as they get used all over 
the place.  I'll add Nick's "declarative" as it describes the problem well from 
another angle:


- record
- bag
- declarative

Anyone like these?  I find them more intuitive than the existing name.

Also, considering their uses, it might make sense to put them in the collections 
module.


-Mike
___
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

Re: [Python-Dev] PEP 557: Data Classes




On 2017-09-10 18:20, Eric V. Smith wrote:

I'll think about adding some more language to the PEP about it.


Agreed, was only looking for mention or example that a specific type was not 
required.  Perhaps even dusting off the word "annotation" to describe them.


___
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

Re: [Python-Dev] PEP 557: Data Classes




On 2017-09-10 23:38, Michel Desmoulin wrote:

I'm going to put some words in explaining why I don't want to use base
classes (I don't think it buys you anything). Do you have a reason for
preferring base classes?


Not preferring, but having it as an alternative. Mainly for 2 reasons:

1 - data classes allow one to type in classes very quickly, let's
harvest the benefit from that.

Typing a decorator in a shell is much less comfortable than using
inheritance. Same thing about IDE: all current ones have snippet with
auto-switch to the class parents on tab.

All in all, if you are doing exploratory programming, and thus
disposable code, which data classes are fantastic for, inheritance will
keep you in the flow.

2 - it will help sell the data classes

I train a lot of people to Python each year. I never have to explain
classes to people with any kind of programming background. I _always_
have to explain decorators.

People are not used to it, and even kind fear it for quite some time.

Inheritance however, is familiar, and will not only push people to use
data classes more, but also will let them do less mistakes: they know
the danger of parent ordering, but not the ones of decorators ordering.


I also feel inheritance is more intuitive (and easily entered), but missed the 
reason it wasn't chosen.  ;)


-Mike

___
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

Re: [Python-Dev] PEP 557: Data Classes

On Sep 11, 2017, at 15:16, Ethan Furman  wrote:
>> 
>> enum Compare(enum.Enum):
>> none = 1
>> unordered = 2
>> ordered = 3
> 
> I like the enum idea (suprise! ;) but I would suggest "equal" or "equivalent" 
> instead of "unordered"; better to say what they are rather than what they are 
> not.

The language reference calls them “equality” comparisons, so maybe that’s the 
term we should use.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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

Re: [Python-Dev] PEP 557: Data Classes

Oddly I don't like the enum (flag names get too long that way), but I do
agree with everything else Barry said (it should be a trivalue flag and
please don't name it cmp).

On Mon, Sep 11, 2017 at 3:16 PM, Ethan Furman  wrote:

> On 09/11/2017 03:00 PM, Barry Warsaw wrote:
>
>> On Sep 10, 2017, at 20:08, Nathaniel Smith wrote:
>>
>>>
>>> I've sometimes wished that attrs let me control whether it generated
>>> equality methods (eq/ne/hash) separately from ordering methods (lt/gt/...).
>>> Maybe the cmp= argument should take an enum with options
>>> none/equality-only/full?
>>>
>>
>> I have had use cases where I needed equality comparisons but not ordered
>> comparisons, so I’m in favor of the option to split them.  (atm, I can’t
>> bring up a specific case, but it’s not uncommon.)
>>
>> Given that you only want to support the three states that Nathaniel
>> describes, I think an enum makes the most sense, and it certainly would
>> read well.  I.e. there’s no sense in supporting the ordered comparisons and
>> not equality, so that’s not a state that needs to be represented.
>>
>> I’d make one other suggestion here: please let’s not call the keyword
>> `cmp`.  That’s reminiscent of Python 2’s `cmp` built-in, which of course
>> doesn’t exist in Python 3.  Using `cmp` is just an unnecessarily
>> obfuscating abbreviation.  I’d suggest just `compare` with an enum like so:
>>
>> enum Compare(enum.Enum):
>>  none = 1
>>  unordered = 2
>>  ordered = 3
>>
>
> I like the enum idea (suprise! ;) but I would suggest "equal" or
> "equivalent" instead of "unordered"; better to say what they are rather
> than what they are not.
>
> --
> ~Ethan~
>
> ___
> 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
>



-- 
--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/archive%40mail-archive.com

Re: [Python-Dev] PEP 557: Data Classes

2017-09-11 Thread Ethan Furman

On 09/11/2017 03:00 PM, Barry Warsaw wrote:

On Sep 10, 2017, at 20:08, Nathaniel Smith wrote:

I've sometimes wished that attrs let me control whether it generated equality
methods (eq/ne/hash) separately from ordering methods (lt/gt/...). Maybe the
cmp= argument should take an enum with options none/equality-only/full?

I have had use cases where I needed equality comparisons but not ordered
comparisons, so I’m in favor of the option to split them. (atm, I can’t bring
up a specific case, but it’s not uncommon.)

Given that you only want to support the three states that Nathaniel describes,
I think an enum makes the most sense, and it certainly would read well. I.e.
there’s no sense in supporting the ordered comparisons and not equality, so
that’s not a state that needs to be represented.

I’d make one other suggestion here: please let’s not call the keyword `cmp`.
That’s reminiscent of Python 2’s `cmp` built-in, which of course doesn’t exist
in Python 3. Using `cmp` is just an unnecessarily obfuscating abbreviation.
I’d suggest just `compare` with an enum like so:

enum Compare(enum.Enum):
none = 1
unordered = 2
ordered = 3

I like the enum idea (suprise! ;) but I would suggest "equal" or "equivalent" instead of "unordered"; better to say what
they are rather than what they are not.

--
~Ethan~

___
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

Re: [Python-Dev] PEP 557: Data Classes

On Sep 10, 2017, at 20:08, Nathaniel Smith  wrote:
> 
> I've sometimes wished that attrs let me control whether it generated equality 
> methods (eq/ne/hash) separately from ordering methods (lt/gt/...). Maybe the 
> cmp= argument should take an enum with options none/equality-only/full?

I have had use cases where I needed equality comparisons but not ordered 
comparisons, so I’m in favor of the option to split them.  (atm, I can’t bring 
up a specific case, but it’s not uncommon.)

Given that you only want to support the three states that Nathaniel describes, 
I think an enum makes the most sense, and it certainly would read well.  I.e. 
there’s no sense in supporting the ordered comparisons and not equality, so 
that’s not a state that needs to be represented.

I’d make one other suggestion here: please let’s not call the keyword `cmp`.  
That’s reminiscent of Python 2’s `cmp` built-in, which of course doesn’t exist 
in Python 3.  Using `cmp` is just an unnecessarily obfuscating abbreviation.  
I’d suggest just `compare` with an enum like so:

enum Compare(enum.Enum):
none = 1
unordered = 2
ordered = 3

One thing I can’t avoid is DRY:

from dataclasses import Compare, dataclass

@dataclass(compare=Compare.unordered)
class Foo:
# …

Maybe exposing the enum items in the module namespace?

——dataclasses/__init__.py-
from enum import Enum

class Compare(Enum):
none = 1
unordered = 2
ordered =3

none = Compare.none
unordered = Compare.unordered
ordered = Compare.ordered
——dataclasses/__init__.py-

from dataclasses import dataclass, unordered

@dataclass(compare=unordered)
class Foo:
# …

Cheers,
-Barry

signature.asc
Description: Message signed with OpenPGP
___
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

Re: [Python-Dev] PEP 557: Data Classes

2017-09-11 Thread Nathaniel Smith

On Mon, Sep 11, 2017 at 5:32 AM, Eric V. Smith  wrote:
> On 9/10/17 11:08 PM, Nathaniel Smith wrote:
>>
>> Hi Eric,
>>
>> A few quick comments:
>>
>> Why do you even have a hash= argument on individual fields? For the
>> whole class, I can imagine you might want to explicitly mark a whole
>> class as unhashable, but it seems like the only thing you can do with
>> the field-level hash= argument is to create a class where the __hash__
>> and __eq__ take different fields into account, and why would you ever
>> want that?
>
>
> The use case is that you have a cache, or something similar, that doesn't
> affect the object identity.

But wouldn't this just be field(cmp=False), no need to fiddle with hash=?

>> Though honestly I can see a reasonable argument for removing the
>> class-level hash= option too. And even if you keep it you might want to
>> error on some truly nonsensical options like defining __hash__ without
>> __eq__. (Also watch out that Python's usual rule about defining __eq__
>> blocking the inheritance of __hash__ does not kick in if __eq__ is added
>> after the class is created.)
>>
>> I've sometimes wished that attrs let me control whether it generated
>> equality methods (eq/ne/hash) separately from ordering methods
>> (lt/gt/...). Maybe the cmp= argument should take an enum with options
>> none/equality-only/full?
>
>
> Yeah, I've thought about this, too. But I don't have any use case in mind,
> and if it hasn't come up with attrs, then I'm reluctant to break new ground
> here.

https://github.com/python-attrs/attrs/issues/170

>From that thread, it feels like part of the problem is that it's
awkward to encode this using only boolean arguments, but they're sort
of stuck with that for backcompat with how they originally defined
cmp=, hence my suggestion to consider making it an enum from the start
:-).

>> The "why not attrs" section kind of reads like "because it's too popular
>> and useful"?
>
>
> I'll add some words to that section, probably focused on typing
> compatibility. My general feeling is that attrs has some great design
> decisions, but goes a little too far (e.g., conversions, validations). As
> with most things we add, I'm trying to be as minimalist as possible, while
> still being widely useful and allowing 3rd party extensions and future
> features.

If the question is "given that we're going to add something to the
stdlib, why shouldn't that thing be attrs?" then I guess it's
sufficient to say "because the attrs developers didn't want it". But I
think the PEP should also address the question "why are we adding
something to the stdlib, instead of just recommending people install
attrs".

-n
___
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

Re: [Python-Dev] PEP 557: Data Classes

On Mon, Sep 11, 2017 at 6:51 AM, Eric V. Smith  wrote:

> On 9/11/17 9:43 AM, tds...@mailbox.org wrote:
>
>> Hi Eric,
>>
>> I have on question not addressed yet.
>> The implementation is based on "__annotations__" where the type is
>> specified.
>> But "__annotations__" is not always filled. An interpreter version with
>> special optimization
>> could remove all __annotations__ for performance reasons. (Discussed in
>> other threads)
>>
>> In this case the dataclass does not work or will there be a fallback?
>>
>> I know it is a little bit hypothetical because an interpreter with this
>> optimization is
>> not there yet. I am looking only in the future a bit.
>> Asking this because type annotations are stated as completely optional
>> for Python.
>> And this use case will break this assumption.
>>
>
> Yes, if there are no __annotations__, then Data Classes would break.
> typing.NamedTuple has the same issue. We discussed it a little bit last
> week, but I don't think we came to any conclusions.
>
> Since @dataclass ignores the value of the annotation (except for
> typing.ClassVar), it would continue to work if the type was present, buy
> maybe mapped to None or similar.
>

Let's not worry about a future where there's no __annotations__. Type
annotations will gradually become more mainstream. You won't have to use
them, but some newer features of the language will be inaccessible if you
don't. This has already started with the pattern based on inheriting from
typing.NamedTuple and using field annotations. Dataclasses are simply
another example.

(That said, I strongly oppose *runtime type checking* based on annotations.
It's by and large a mistaken idea. But this has nothing to do with that.)

-- 
--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/archive%40mail-archive.com

Re: [Python-Dev] PEP 557: Data Classes

2017-09-11 Thread tds333

Hi Eric,

I have on question not addressed yet.
The implementation is based on "__annotations__" where the type is specified.
But "__annotations__" is not always filled. An interpreter version with special 
optimization
could remove all __annotations__ for performance reasons. (Discussed in other 
threads)

In this case the dataclass does not work or will there be a fallback?

I know it is a little bit hypothetical because an interpreter with this 
optimization is
not there yet. I am looking only in the future a bit.
Asking this because type annotations are stated as completely optional for 
Python.
And this use case will break this assumption.

Personally I am a heavy user of attrs and happy to have a dataclass in the std 
lib.

Regards

Wolfgang
___
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

Re: [Python-Dev] PEP 557: Data Classes


On 9/11/17 9:43 AM, tds...@mailbox.org wrote:

Hi Eric,

I have on question not addressed yet.
The implementation is based on "__annotations__" where the type is specified.
But "__annotations__" is not always filled. An interpreter version with special 
optimization
could remove all __annotations__ for performance reasons. (Discussed in other 
threads)

In this case the dataclass does not work or will there be a fallback?

I know it is a little bit hypothetical because an interpreter with this 
optimization is
not there yet. I am looking only in the future a bit.
Asking this because type annotations are stated as completely optional for 
Python.
And this use case will break this assumption.


Yes, if there are no __annotations__, then Data Classes would break. 
typing.NamedTuple has the same issue. We discussed it a little bit last 
week, but I don't think we came to any conclusions.


Since @dataclass ignores the value of the annotation (except for 
typing.ClassVar), it would continue to work if the type was present, buy 
maybe mapped to None or similar.


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/archive%40mail-archive.com

Re: [Python-Dev] PEP 557: Data Classes


On 9/10/17 11:08 PM, Nathaniel Smith wrote:

Hi Eric,

A few quick comments:

Why do you even have a hash= argument on individual fields? For the
whole class, I can imagine you might want to explicitly mark a whole
class as unhashable, but it seems like the only thing you can do with
the field-level hash= argument is to create a class where the __hash__
and __eq__ take different fields into account, and why would you ever
want that?


The use case is that you have a cache, or something similar, that 
doesn't affect the object identity.



Though honestly I can see a reasonable argument for removing the
class-level hash= option too. And even if you keep it you might want to
error on some truly nonsensical options like defining __hash__ without
__eq__. (Also watch out that Python's usual rule about defining __eq__
blocking the inheritance of __hash__ does not kick in if __eq__ is added
after the class is created.)

I've sometimes wished that attrs let me control whether it generated
equality methods (eq/ne/hash) separately from ordering methods
(lt/gt/...). Maybe the cmp= argument should take an enum with options
none/equality-only/full?


Yeah, I've thought about this, too. But I don't have any use case in 
mind, and if it hasn't come up with attrs, then I'm reluctant to break 
new ground here.



The "why not attrs" section kind of reads like "because it's too popular
and useful"?


I'll add some words to that section, probably focused on typing 
compatibility. My general feeling is that attrs has some great design 
decisions, but goes a little too far (e.g., conversions, validations). 
As with most things we add, I'm trying to be as minimalist as possible, 
while still being widely useful and allowing 3rd party extensions and 
future features.


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/archive%40mail-archive.com

Re: [Python-Dev] PEP 557: Data Classes