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

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

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 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 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 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&R(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 
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&R(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 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 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 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

[Python-Dev] What is the design purpose of metaclasses vs code generating decorators? (was Re: PEP 557: Data Classes)

2017-10-12 Thread Nick Coghlan 
On 13 October 2017 at 04:21, Martin Teichmann 
wrote:

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

Metaclasses currently tend to serve two distinct purposes:

1. Actually altering the runtime behaviour of a class and its children in
non-standard ways (e.g. enums, ABCs, ORMs)
2. Boilerplate reduction in class definitions, reducing the amount of code
you need to write as the author of that class

Nobody has a problem with using metaclasses for the first purpose - that's
what they're for.

It's the second use case where they're problematic, as the fact that
they're preserved on the class becomes a leaky implementation detail, and
the lack of a JIT in CPython means they can also end up being expensive
from a runtime performance perspective.

Mixin classes have the same problem: something that the author may want to
handle as an internal implementation detail leaks through to the runtime
state of the class object.

Code generating decorators like functools.total_ordering and
dataclasses.dataclass (aka attr.s) instead aim at the boilerplate reduction
problem directly: they let you declare in the class body the parts that you
need to specify as the class designer, and then fill in at class definition
time the parts that can be inferred from that base.

If all you have access to is the runtime class, it behaves almost exactly
as if you had written out all the autogenerated methods by hand (there may
be subtle differences in the method metadata, such as the values of
`__qualname__` and `__globals__`).

Such decorators also do more work at class definition time in order to
reduce the amount of runtime overhead introduced by reliance on chained
method calls in a non-JITted Python runtime.

As such, the code generating decorators have a clear domain of
applicability: boilerplate reduction for class definitions without
impacting the way instances behave (other than attribute and method
injection), and without implicitly impacting subclass definitions (other
than through regular inheritance behaviour).

As far as the dataclass interaction with `__slots__` goes, that's a problem
largely specific to slots (and `__metaclass__` before it), in that they're
the only characteristics of a class definition that affect how CPython
allocates memory for the class object itself (the descriptors for the slots
are stored as a pointer array after the class struct, rather than only in
the class dict).

Given PEP 526 variable annotations, __slots__ could potentially benefit
from a __metaclass__ style makeover, allowing an "infer_slots=True" keyword
argument to type.__new__ to request that the list of slots be inferred from
__annotations__ (Slot inference would conflict with setting class level
default values, but that's a real conflict, as you'd be trying to use the
same name on the class object for both the slot descriptor and the default
value)

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