I suppose it's better than nothing, since right now libraries are
(rightfully) afraid to modify it or rely on its behaviour. Although I
expect this will lead to a lot of repeated code, that looks a lot like the
`__abstractmethods__` population in `_py_abc`. I think it's preferable to
ease abstract
That might work (though not for older Python versions). What kind of API
were you thinking of for adding and deleting abstract methods?
On Thu, Oct 1, 2020 at 01:07 Ben Avrahami wrote:
>
>
> I suppose it's better than nothing, since right now libraries are
> (rightfully) afraid to modify it or r
I have a suggestion for an API, how about a keyword argument to
"abstractmethod" that allows to set the abstract method as "optional" meaning
that sub-implementations can either implement their own version or use the
ABC's own, infact, I think the STDLIB could use this itself (I haven't looked
In theory, all that's necessary is to just run `_py_abc`'s abstract method
population again (`ABCMeta.__new__`, with slight adjustments):
def update_abstractmethods(cls):
if not isinstance(cls, ABCMeta):
return cls
abstracts = set()
# include only abstract m
On Thu, Oct 1, 2020 at 7:51 AM William Pickard
wrote:
> I have a suggestion for an API, how about a keyword argument to
> "abstractmethod" that allows to set the abstract method as "optional"
> meaning that sub-implementations can either implement their own version or
> use the ABC's own, infact,
Hm, having a public API to do that would be nice. It seems there are two
implementations, one in Python, one in C. Maybe it's time you opened a bpo
issue and started working on a PR? This just seems too reasonable to keep
bugging python-ideas...
On Thu, Oct 1, 2020 at 7:55 AM Ben Avrahami wrote:
-1 for various reasons expressed by several authors. But I'm not sure
I agree with this:
Steven D'Aprano writes:
> I think this might make good sense for string methods:
>
> mystring = mystring.upper()
> mystring .= upper()
>
> but less so for arbitrary objects with methods retur
On Fri, Oct 02, 2020 at 11:49:02AM +0900, Stephen J. Turnbull wrote:
> -1 for various reasons expressed by several authors. But I'm not sure
> I agree with this:
>
> Steven D'Aprano writes:
>
> > I think this might make good sense for string methods:
> >
> > mystring = mystring.upper()
>
