[Python-ideas] Fwd: Consider allowing the use of abstractmethod without metaclasses

INADA Naoki songofacandy at gmail.com
Thu Jul 20 20:51:45 EDT 2017

INADA Naoki  <songofacandy at gmail.com>

On Fri, Jul 21, 2017 at 2:59 AM, Ivan Levkivskyi <levkivskyi at gmail.com> wrote:
> On 20 July 2017 at 19:51, INADA Naoki <songofacandy at gmail.com> wrote:
>> On Fri, Jul 21, 2017 at 12:12 AM, Ivan Levkivskyi <levkivskyi at 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

More information about the Python-ideas mailing list