On 10 Mar 2015 06:51, "Neil Girdhar" <mistersh...@gmail.com> wrote: > > > > On Mon, Mar 9, 2015 at 12:54 PM, Serhiy Storchaka <storch...@gmail.com> wrote: >> >> 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. >> > > Inheritance might be more backwards compatible, but I believe that you should check how much code is genuine not restricted to the idealized flags interface. It's not worth talking about "simpler implementation" since the two solutions differ by only a couple dozen lines.
We literally can't do this, as the vast majority of Python code in the world is locked up behind institutional firewalls or has otherwise never been published. The open source stuff is merely the tip of a truly enormous iceberg. If we want to *use* IntFlags in the standard library (and that's the only pay-off significant enough to justify having it in the standard library), then it needs to inherit from int. However, cloning the full enum module architecture to create flags.FlagsMeta, flags.Flags and flags.IntFlags would make sense to me. It would also make sense to try that idea out on PyPI for a while before incorporating it into the stdlib. Regards, Nick. > > On the other hand, composition is better design. It prevents you from making mistakes like adding to flags and having carries, or using flags in an unintended way. > >>> >>> 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. > > > I think it's the other way around. You should typically start with the modest interface and add methods as you need. If you start with full blown inheritance, you will find it only increasingly more difficult to remove methods in changing your solution. Using inheritance instead of composition is one of the most common errors in objected oriented programming, and I get the impression from your other paragraph that you're seduced by the slightly shorter code. I don't think it's worth giving in to that without proof that composition will actually break a significant amount of code. > > Regarding IntEnum — that should inherit from int since they are truly just integer constants. It's too late for bool; that ship has sailed unfortunately. > >> >> >> >>> > 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? > > > You're right. >> >> >> >> >> _______________________________________________ >> 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/mistersheik%40gmail.com > > > > _______________________________________________ > 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/ncoghlan%40gmail.com >
_______________________________________________ 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
