A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2018-April/152791.html below:

[Python-Dev] PEP 575: Unifying function/method classes

[Python-Dev] PEP 575: Unifying function/method classes [Python-Dev] PEP 575: Unifying function/method classesJeroen Demeyer J.Demeyer at UGent.be
Fri Apr 20 06:02:44 EDT 2018
On 2018-04-14 23:14, Guido van Rossum wrote:
> That actually sounds like a pretty big problem. I'm sure there is lots
> of code that doesn't *just* duck-type nor calls inspect but uses
> isinstance() to decide how to extract the desired information.

I have been thinking about this some more...

One solution to improve backwards compatibility would be to duplicate 
some classes. For example, make a separate class for bound methods in 
extension types, which would be literally a duplicate of the existing 
types.MethodType class (possibly with a different name). In other words, 
a bound method of an extension type would work exactly the same way as 
an existing bound method but it would artificially be a different class 
for the benefit of non-duck-typing.
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4