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

[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

[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

[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

[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

[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

[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

[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

[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

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

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

[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

[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

[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

[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

[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

[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