On Sat, Sep 28, 2019 at 2:26 PM Ricky Teachey <ricky@teachey.org> wrote:
But it would silently do nothing if there was no class decorator to look
at it.
This doesn't seem like such a big deal to me. It would simply be the way slots works.
I was thinking it's currently an error. And you chose a name (__slot_conflics__) suggesting that there still was a problem. But yeah, maybe other than that it's no big deal.
However if we did `__slots__ = "__auto__"` then we might finagle it so
that the initializers could be preserved:
class C: __slots__ = "__auto__" # or MRAB's suggested __slots__ = ... x: float = 0.0 y: float = 0.0
I do like this idea a lot.
Saving, or preserving, the initialized values somewhere is mainly what I was driving at with the so called __slots_conflicts__ idea. Perhaps instead the slots descriptor object could store the value? Something like:
class C: __slots__ = ... x: float = 0.0 y: float = 0.0
assert C.x.__value__ == 0.0 assert C.y.__value__ == 0.0
Why not -- they have to go somewhere. :-/
If that becomes the way this is solved, should slots be made to also accept a dict to create starting values?
class C: __slots__ = dict(x = 0.0, y = 0.0)
assert C.x.__value__ == 0.0 assert C.y.__value__ == 0.0
But what would be the use case for that? When would you ever prefer to write this rather than the first version? I guess if the slots are computed -- but who uses computed slots nowadays?
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>