On 09.03.15 17:48, Neil Girdhar wrote:
So you agree that the ideal solution is composition, but you prefer
inheritance in order to not break code?
Yes, I agree. There is two advantages in the inheritance: larger
backward compatibility and simpler implementation.
Then,I think the big question
is how much code would actually break if you presented the ideal
interface. I imagine that 99% of the code using flags only uses __or__
to compose and __and__, __invert__ to erase flags.
I don't know and don't want to guess. Let just follow the way of bool
and IntEnum. When users will be encouraged to use IntEnum and IntFlags
instead of plain ints we could consider the idea of dropping inheritance
of bool, IntEnum and IntFlags from int. This is not near future.
> Here's another reason. What if someone wants to use an IntFlags object,
> but wants to use a fixed width type for storage, say numpy.int32? Why
> shouldn't they be able to do that? By using composition, you can easily
> provide such an option.
You can design abstract interface Flags that can be combined with
int or other type. But why you want to use numpy.int32 as storage?
This doesn't save much memory, because with composition the IntFlags
class weighs more than int subclass.
Maybe you're storing a bunch of flags in a numpy array having dtype
np.int32? It's contrived, I agree.
I afraid that composition will not help you with this. Can numpy array
pack int-like objects into fixed-width integer array and then restore
original type on unboxing?
_______________________________________________
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
