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.
 

Right, but those would be rather ephemeral vs more potentially long lived members.  It'll certainly depend upon the usage pattern whether or not it's worth it.  And the point of using __slots__ is that you've decided you're tight on space but we don't force usage of Cython to go dict-free.

But you could do that without the wacky API by just naming the slots _foo, _bar and have properties foo, bar.

You can also just mutate the type after the fact and replace the descriptor with the wrapped descriptor.  Wouldn't the prefixed solution work just as well for dataclasses in some form as well?

On Sat, Sep 28, 2019 at 5:16 PM Guido van Rossum <guido@python.org> wrote:
On Sat, Sep 28, 2019 at 5:04 PM Dino Viehland <dinoviehland@gmail.com> wrote:
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)