Totally agree On 9 Mar 2015 19:22, "Nick Coghlan" <ncogh...@gmail.com> wrote:
> > 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
