Re: [Python-Dev] The role of NotImplemented: What is it for and when should it be used?
It's worth noting that as far as I am aware, all the cases where CPython currently raises TypeError directly rather than returning NotImplemented are due to a longstanding bug in the handling concatenation and repetition of sequences implemented entirely in C (which includes the builtins): http://bugs.python.org/issue11477 The coercion dance in abstract.c currently gets the operand precedence wrong for sq_concat and sq_repeat, and also doesn't check their return values for NotImplemented. Types implemented in Python work correctly (including respecting NotImplemented return values), as those fill in both the nb_* and the sq_* slots. That's why this bug is in the "annoying implementation quirk" category rather than the "major correctness flaw" category. I tried to fix it ages ago directly in abstract.c, but the result was an unmaintainable mess. (The test changes in the draft patch will hopefully still prove useful some day). There's another possible implementation strategy, which is to change type creation to populate nb_add and nb_multiply when sq_concat and sq_repeat are defined, and then never call those two methods directly from abstract.c. I've never found the time myself to go back and try that version of the fix, but it's definitely an issue I'd love to see fixed at some point. Regards, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #22773: fix failing test with old readline versions due to issue #19884.
On Tue, Nov 4, 2014, at 09:55, antoine.pitrou wrote: > https://hg.python.org/cpython/rev/eba6e68e818c > changeset: 93382:eba6e68e818c > branch: 2.7 > parent: 93379:e54d0b197c82 > user:Antoine Pitrou > date:Tue Nov 04 14:52:10 2014 +0100 > summary: > Issue #22773: fix failing test with old readline versions due to issue > #19884. > > files: > Lib/test/test_readline.py | 4 > Modules/readline.c| 3 +++ > 2 files changed, 7 insertions(+), 0 deletions(-) > > > diff --git a/Lib/test/test_readline.py b/Lib/test/test_readline.py > --- a/Lib/test/test_readline.py > +++ b/Lib/test/test_readline.py > @@ -43,6 +43,10 @@ > > > class TestReadline(unittest.TestCase): > + > +@unittest.skipIf(readline._READLINE_VERSION < 0x0600 Shouldn't this use the runtime version? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #22773: fix failing test with old readline versions due to issue #19884.
On Tue, 04 Nov 2014 09:58:29 -0400 Benjamin Peterson wrote: > > On Tue, Nov 4, 2014, at 09:55, antoine.pitrou wrote: > > https://hg.python.org/cpython/rev/eba6e68e818c > > changeset: 93382:eba6e68e818c > > branch: 2.7 > > parent: 93379:e54d0b197c82 > > user:Antoine Pitrou > > date:Tue Nov 04 14:52:10 2014 +0100 > > summary: > > Issue #22773: fix failing test with old readline versions due to issue > > #19884. > > > > files: > > Lib/test/test_readline.py | 4 > > Modules/readline.c| 3 +++ > > 2 files changed, 7 insertions(+), 0 deletions(-) > > > > > > diff --git a/Lib/test/test_readline.py b/Lib/test/test_readline.py > > --- a/Lib/test/test_readline.py > > +++ b/Lib/test/test_readline.py > > @@ -43,6 +43,10 @@ > > > > > > class TestReadline(unittest.TestCase): > > + > > +@unittest.skipIf(readline._READLINE_VERSION < 0x0600 > > Shouldn't this use the runtime version? I suppose in most libreadline deployments it shouldn't make a difference (you usually get it through your Linux distro; other OSes use non-GNU replacements, if any). Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Dinamically set __call__ method
Hi folks,
I am trying to replace dinamically the __call__ method of an object using
setattr.
Example:
$ cat testcall.py
class A:
def __init__(self):
setattr(self, '__call__', self.newcall)
def __call__(self):
print("OLD")
def newcall(self):
print("NEW")
a=A()
a()
I expect to get "NEW" instead of "OLD", but in Python 3.4 I get "OLD".
$ python2.7 testcall.py
NEW
$ python3.4 testcall.py
OLD
I have a few questions:
- Is this an expected behavior?
- Is possible to replace __call__ dinamically in Python 3? How?
Best regards,
Roberto
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dinamically set __call__ method
On Tue, Nov 4, 2014 at 4:52 PM, Roberto Martínez
wrote:
> Hi folks,
>
> I am trying to replace dinamically the __call__ method of an object using
> setattr.
> Example:
>
> $ cat testcall.py
> class A:
> def __init__(self):
> setattr(self, '__call__', self.newcall)
>
> def __call__(self):
> print("OLD")
>
> def newcall(self):
> print("NEW")
>
> a=A()
> a()
>
> I expect to get "NEW" instead of "OLD", but in Python 3.4 I get "OLD".
>
> $ python2.7 testcall.py
> NEW
> $ python3.4 testcall.py
> OLD
>
> I have a few questions:
>
> - Is this an expected behavior?
> - Is possible to replace __call__ dinamically in Python 3? How?
For new-style classes, special methods like __call__ are looked up
directly on the class, not on the object itself. If you want to change
the result of doing a(), then you need to reassign A.__call__, not
a.__call__.
In python 3, all classes are new-style classes. In python 2, only
classes that inherit from 'object' are new-style classes. (If you
replace 'class A:' with 'class A(object):' then you'll see the same
behaviour on both py2 and py3.)
Easy workaround:
def __call__(self, *args, **kwargs):
return self._my_call(*args, **kwargs)
Now you can assign a._my_call to be whatever you want.
-n
--
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dinamically set __call__ method
This list is for the development _of_ Python, not development _with_ Python.
Try asking on Python List.
(forwarding...)
On 11/04/2014 08:52 AM, Roberto Martínez wrote:
I am trying to replace dinamically the __call__ method of an object using
setattr.
Example:
$ cat testcall.py
class A:
def __init__(self):
setattr(self, '__call__', self.newcall)
def __call__(self):
print("OLD")
def newcall(self):
print("NEW")
a=A()
a()
I expect to get "NEW" instead of "OLD", but in Python 3.4 I get "OLD".
$ python2.7 testcall.py
NEW
$ python3.4 testcall.py
OLD
I have a few questions:
- Is this an expected behavior?
- Is possible to replace __call__ dinamically in Python 3? How?
In 2.7 that would be a classic class, about which I know little.
In 3.x you have a new class, one which inherits from 'object'. When you replace __call__ you need to replace it the
class, not on the instance:
setattr(__self__.__class__, self.newcall)
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dinamically set __call__ method
On Tue, Nov 4, 2014 at 10:52 AM, Roberto Martínez < robertomartin...@gmail.com> wrote: > $ cat testcall.py > class A: > You are using old-style classes in Python 2.7 unless you explicitly inherit from object. If I vary the class line to be "class A(object):" I get the same behavior with 2.7 as you see with 3.4. My guess is this causes the different behavior between versions. You might also find it useful to "print A.__call__" and "print a.__call__" with different class statements. Skip ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
