INADA Naoki <songofaca...@gmail.com>
On Fri, Jul 21, 2017 at 2:59 AM, Ivan Levkivskyi <levkivs...@gmail.com> wrote: > On 20 July 2017 at 19:51, INADA Naoki <songofaca...@gmail.com> wrote: >> >> On Fri, Jul 21, 2017 at 12:12 AM, Ivan Levkivskyi <levkivs...@gmail.com> >> wrote: >> > To be honest, I am not very happy with addition of a new special class. >> > Imagine that the PEP 544 will be accepted (and I hope so). >> > Then we would have, abstract classes, abstract base classes, and >> > protocols. >> > I think users will be overwhelmed by having >> > three similar concepts instead of one. >> >> Hmm, couldn't split protocol and ABC? >> > > Unfortunately no, it was considered and rejected for various reasons (in > particular to provide smooth transition to protocols). > Sorry about my poor English. "split" meant "optionally ABC". I understand that existing classes (like typing.Sequence) must be ABC. But why new user defined protocol must be ABC? >> > by >> > optimizing various parts and reimplementing some parts in C. >> > In fact, my desire to optimize and rewrite ABCMeta in C is partially due >> > to >> > reluctance to add yet another concept of "abstractness". >> > >> >> Even if it's implemented in C, issubclass implementation is much >> complicated >> than normal type. >> I don't want to introduce unnecessary complexity because I'm minimalist. >> > > This complexity is already there, and attempt to reduce might lead to > actually an increase of complexity. > This is probably the case where I would be with Raymond in terms of > performance vs ease of maintenance. > Sorry again. I meant I don't want import the complexity to my class when I don't need it. In other words, I hate inheriting ABC when I don't need register based subclass. > -- > Ivan > > _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
