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/2010-June/100576.html below:

[Python-Dev] Are PyCFunctions supposed to invisibly consume self when used as a method?

[Python-Dev] Are PyCFunctions supposed to invisibly consume self when used as a method?Michael Foord fuzzyman at voidspace.org.uk
Sat Jun 12 23:17:33 CEST 2010
On 12 Jun 2010, at 20:59, Guido van Rossum <guido at python.org> wrote:

> On Sat, Jun 12, 2010 at 10:19 AM, Philip Jenvey  
> <pjenvey at underboss.org> wrote:
>> +1 on changing this, it's annoying for alternate implementations.  
>> They oftentimes implement functions in pure Python whereas user  
>> code might be expecting the PYCFunction behavior.
>>
>> Jython's had a couple cases of this incompatibility reported. It's  
>> a rare occurrence but it's very mysterious to the user when it  
>> happens.
>
> Well, yeah, but you're presenting an argument *against* changing this
> -- existing code will break if it is changed.
>
> I can think of only way out without just breaking such code: Start
> issuing warnings when a bare PyCFunction exists at the class level,
> and introduce/recommend decorators that can be used to disambiguate
> the two possible intended meanings.
>
> As Brett says, f = staticmethod(func) will work to insist on the
> existing PyCFunction semantics. We should also introduce a new one
> decorator that treats any callable the same way as pure-Python
> functions work today: bind the instance to the first argument when it
> is called on an instance. I can't think of a good name for that one
> right now, but we'll think of one.
>

method or instancemethod perhaps?

Michael







> I wish the warning could happen at class definition time, but I expect
> that there are use cases where the warning is unnecessary (because the
> code happens to be structured so as to never call it through the
> instance) or even wrong (who knows what introspection might be
> thwarted by wrapping something in staticmethod). Perhaps the warning
> can be done by adding a __get__ method to PyCFunction that issues the
> warning and then returns the original value.
>
> I'm not sure how we'll ever get rid of the warning except in Py4k.
>
> -- 
> --Guido van Rossum (python.org/~guido)
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
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