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)