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/152703.html below:

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

[Python-Dev] PEP 575: Unifying function/method classesJeroen Demeyer J.Demeyer at UGent.be
Sat Apr 14 05:17:25 EDT 2018
On 2018-04-13 21:30, Raymond Hettinger wrote:
> It would be nice to have a section that specifically discusses the implications with respect to other existing function-like tooling:  classmethod, staticmethod, partial, itemgetter, attrgetter, methodgetter, etc.

My hope is that there are no such implications. An important design goal 
of this PEP (which I believe I achieved) is that as long as you're doing 
duck typing, you should be safe. I believe that the tools in your list 
do exactly that.

It's only when you use inspect or when you do type checks that you will 
see the difference with this PEP.

After implementing the C code part of my PEP, there were only a 
relatively small number of test failures. You can look at this commit 
which contains all Python code changes of my implementation, it doesn't 
look so bad:

https://github.com/jdemeyer/cpython/commit/c404a8f1b7d9525dd2842712fe183a051a4b5094

> For example, I would need to update the code in random._randbelow().

For the record, there are no test failures related to this, but maybe 
that's just because tests for this are missing.
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