On Sat, Sep 28, 2019 at 5:04 PM Dino Viehland
One thought I've had about __slots__ would be it'd be nice to take a dictionary in the form of:
class C: __slots__ = {'a': ???, 'b': ???}
You could actually provide this dictionary today, but the values would be ignored. The values could start to do interesting things. One flavor of that would be that they could indicate the underlying storage used for the slots (maybe with 'i' for int32, 'b' for byte, 'l' for long, or whatever color encoding sounds good). This is just mapping into the available storage types that are already available in structmember.c. That's just extending the existing use case of slots as being a more memory efficient storage representation, and might help people avoid dropping into Cython just to get compact instance members.
Hm... But then you'd be paying for boxing/unboxing cost on each access. I'm actually okay with needing to use Cython if you're really that tight for space.
But another application of that could be accepting a callable which would then receive the descriptor, and return a new descriptor. One example of what that'd let you do is build a cached-property decorator that would do the get/sets into the slot. But presumably it would also provide a way for other scenarios where you want to explicitly collide with the get/set descriptor with a member. It doesn't help so much with the verbosity of defining these things that I think was mentioned elsewhere in this thread. And it doesn't play so well w/ class decorators, but could be more usable with meta-classes.
But you could do that without the wacky API by just naming the slots _foo, _bar and have properties foo, bar. -- --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...