[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

2009-12-28 Thread Benjamin Peterson
Benjamin Peterson added the comment: Fixed in r77093. -- resolution: -> accepted status: open -> closed ___ Python tracker ___ ___ Py

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

2009-12-25 Thread Joe Amenta
Joe Amenta added the comment: To elaborate on my last comment: - touch_import looks for the required import binding in any scope, and it will add a global import if not found, otherwise it leaves it alone - the import added does not have a newline prefix, so if the newlines were left in, (wit

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

2009-12-25 Thread Joe Amenta
Joe Amenta added the comment: I believe that this patch works like you described... Attached a patch with more test cases to show this. (the [1:] parts are to make the test cases readable; they will still pass if all the leading newlines are removed from the triple-quoted strings and all [1:

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

2009-12-25 Thread Nick Coghlan
Nick Coghlan added the comment: Ah yes, I misread the example. Agreed that that is a change in behaviour then - it is possible to clear the caches if absolutely necessary, but doing so isn't particularly portable. -- ___ Python tracker

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

2009-12-25 Thread Trundle
Trundle added the comment: What Joe Amenta stumbled across is that ABCMeta caches its subclass checks. If you call ``isinstance(spam, Callable)`` and after that delete `type(spam).__call__`, every other call of ``isinstance(spam, Callable)`` will still return True. -- __

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

2009-12-24 Thread Nick Coghlan
Nick Coghlan added the comment: The patch however does not look correct - the import should be added as a global import at the beginning of affected files rather than inline with each callable check. -- ___ Python tracker

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

2009-12-24 Thread Nick Coghlan
Nick Coghlan added the comment: Just confirming that 2.x also correctly ignores instance attributes (as it should, since it looks at the tp_call slot): >>> odd = Spam() >>> odd.__call__ = lambda: 'very odd' >>> callable(odd) False -- ___ Python trac

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

2009-12-24 Thread Nick Coghlan
Nick Coghlan added the comment: That isn't a semantic change, it is exactly the same semantics as callable() in 2.x: >>> class Spam(object): ... def __call__(self): pass ... >>> callable(Spam()) True >>> del Spam.__call__ >>> callable(Spam()) False -- ___

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

2009-12-24 Thread Joe Amenta
Joe Amenta added the comment: One such weird corner case: from collections import Callable class Spam(object): def __call__(self): return self can_of_spam = Spam() print callable(can_of_spam) == isinstance(can_of_spam, Callable) # True del Spam.__call__ can_of_spam.__call__ = lambda c

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

2009-11-18 Thread Nick Coghlan
Nick Coghlan added the comment: Antoine Pitrou wrote: > Antoine Pitrou added the comment: > > I also think isinstance(x, collections.Callable) is the correct > replacement. Even though it might give a different answer on weird > corner cases, it is semantically what you are looking for. > (too

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

2009-11-17 Thread Antoine Pitrou
Antoine Pitrou added the comment: I also think isinstance(x, collections.Callable) is the correct replacement. Even though it might give a different answer on weird corner cases, it is semantically what you are looking for. (too bad it has a stupid module placement) -- nosy: +pitrou __

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

2009-11-17 Thread Jean-Paul Calderone
Jean-Paul Calderone added the comment: How about bringing callable back since there is no obvious replacement for it? It's valuable as a LYBL check in circumstances where an object submitted far away from the place where it's invoked. Such uses can't easily be replaced with direct calls to fol

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

2009-10-23 Thread Georg Brandl
Georg Brandl added the comment: Not really, that was the last thing to get this issue closed. -- ___ Python tracker ___ ___ Python-bug

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

2009-10-22 Thread Benjamin Peterson
Benjamin Peterson added the comment: 2009/10/22 Georg Brandl : > > Georg Brandl added the comment: > > 2to3 still uses hasattr(x, 'callable') Do you have strong opinions about this? IMO, hasattr(x, '__call__') is compatible enough. -- ___ Python tr

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

2009-10-22 Thread Georg Brandl
Georg Brandl added the comment: 2to3 still uses hasattr(x, 'callable'). -- assignee: georg.brandl -> benjamin.peterson ___ Python tracker ___

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

2009-10-03 Thread Trundle
Trundle added the comment: As every type is an instance of `type`, every type also has a `__call__` attribute which means ``hasattr(type(x), '__call__')`` is always true. `callable()` checks whether `tp_call` is set on the type, which cannot be done in Python directly. -- nosy: +Trundle

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

2009-10-02 Thread Ezio Melotti
Ezio Melotti added the comment: Benjamin already replaced hasattr(x, "__call__") with hasattr(type(x), "__call__") in the Python 3.0 "What's New" in r75090 and r75094, but this still doesn't match completely the behavior of callable(): >>> class Foo(object): pass ... >>> foo = Foo() >>> callabl

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

2009-10-02 Thread Nick Coghlan
Nick Coghlan added the comment: Although we should seriously consider properly exposing special method lookup at the Python level... -- ___ Python tracker ___ ___

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

2009-10-02 Thread Nick Coghlan
Nick Coghlan added the comment: hasattr(type(x), "__call__") is technically a more valid replacement due to the usual matter of metaclass confusion. (Although putting special methods on instance objects is a recipe for trouble in more ways than just this one). -- nosy: +ncoghlan _

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

2009-09-27 Thread Milko Krachounov
Milko Krachounov added the comment: My suggestion is not only unreadable, but wrong. It's even less accurate than hasattr(x, '__call__'), as it doesn't look in all the classes in the MRO. Using isinstance(x, collections.Callable) should probably be the correct replacement for 2to3 and situation

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

2009-09-27 Thread Ezio Melotti
Ezio Melotti added the comment: In the PEP3100 [1] there's written, in the "to be removed" list: "callable(): just use hasattr(x, '__call__') (?) [2] [done]" and the note refers to a pdf [2] that instead says: "callable(): just call it, already" If callable() was removed to encourage the EA

[issue7006] The replacement suggested for callable(x) in py3k is not equivalent

2009-09-27 Thread Milko Krachounov
New submission from Milko Krachounov : hasattr(x, '__call__') has been suggested as a replacement for callable(x) in the documentation and in the warning when running python2.6 with -3. It is also what 2to3 replaces it with. However, the two are not equivalent. 1. I can add a __call__ attribute