Re: [Python-Dev] PEP 557: Data Classes
(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
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
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
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
