[Python-Dev] binary operation heuristics -- bug or undocumented?
Hi, A friend of mine stumbled upon the following behavior: ---cut--- >>> class A(object): pass ... >>> class B(object): ... def __add__(self, other): ... print 'B: adding B and %s objects.' % other.__class__.__name__ ... >>> class C(object): ... def __radd__(self, other): ... print 'C: adding C and %s objects.' % other.__class__.__name__ ... >>> a, b, c = A(), B(), C() >>> b + c B: adding B and C objects. >>> a + c C: adding C and A objects. # so far, quite logical. now let's do this: >>> 1 + c C: adding C and int objects. --uncut-- My first expectation would be to get a TypeError here, as ints indeed have an __add__ method, and they do not know anything about C objects (obviously :) ). On second thought, giving client code priority to handle things has it's merits. The problem is that I found no mention of this behavior in the docs. P.S. tested in 2.5 through 3.0 and PyPy Thanks. -- Alex. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] binary operation heuristics -- bug or undocumented?
Thanks! On Fri, Mar 19, 2010 at 16:05, Michael Foord wrote: > On 19/03/2010 12:46, Alex A. Naanou wrote: >> >> [snip...] >>>>> >>>>> class C(object): >>>>> >> >> ... def __radd__(self, other): >> ... print 'C: adding C and %s objects.' % other.__class__.__name__ >> ... >> >>>>> >>>>> a, b, c = A(), B(), C() >>>>> 1 + c >>>>> >> >> C: adding C and int objects. >> >> >> > > That is the whole point of the __radd__ method. ints don't know how to add > themselves to C objects, so int.__add__ will return NotImplemented and then > Python will try C.__radd__. > > All the best, > > Michael > >> --uncut-- >> >> My first expectation would be to get a TypeError here, as ints indeed >> have an __add__ method, and they do not know anything about C objects >> (obviously :) ). On second thought, giving client code priority to >> handle things has it's merits. >> >> The problem is that I found no mention of this behavior in the docs. >> >> >> P.S. tested in 2.5 through 3.0 and PyPy >> >> Thanks. >> >> > > > -- > http://www.ironpythoninaction.com/ > http://www.voidspace.org.uk/blog > > READ CAREFULLY. By accepting and reading this email you agree, on behalf of > your employer, to release me from all obligations and waivers arising from > any and all NON-NEGOTIATED agreements, licenses, terms-of-service, > shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, > non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have > entered into with your employer, its partners, licensors, agents and > assigns, in perpetuity, without prejudice to my ongoing rights and > privileges. You further represent that you have the authority to release me > from any BOGUS AGREEMENTS on behalf of your employer. P.S. like the licence :) > > > -- Alex. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] odd "tuple does not support assignment" confusion...
Hi everyone, Just stumbled on a fun little thing: We create a simple structure... l = ([],) Now modify the list, and... l[0] += [1] ...we fail: ## Traceback (most recent call last): ## File "F:\work\ImageGrid\cur\ImageGrid\src\test\python-bug.py", line 17, in ## l[0] += [1] ## TypeError: 'tuple' object does not support item assignment Tested on 2.5, 2.7, 3.1, PyPy1.8 on win32 and 2.7 on x86-64 Debian (just in case). I was expecting this to succeed, is this picture wrong or am I missing something? ...am I really the first one to try and modify a list within a tuple directly?! It's even more odd that I did not try this myself since first started with Python back in 99 :) I could not google this "feature" out either... BTW, It is quite trivial (and obvious) to trick the interpreter to get the desired result... e = l[0] e += [1] P.S. the attachment is runnable version of the above code... -- Thanks! Alex. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] odd "tuple does not support assignment" confusion...
I knew this was a feature!!! features such as these should be fixed! %) On Sat, Mar 3, 2012 at 03:38, R. David Murray wrote: > On Sat, 03 Mar 2012 03:06:33 +0400, "Alex A. Naanou" > wrote: >> Hi everyone, >> >> Just stumbled on a fun little thing: >> >> We create a simple structure... >> >> l = ([],) >> >> >> Now modify the list, and... >> >> l[0] += [1] >> >> >> ...we fail: >> ## Traceback (most recent call last): >> ## File "F:\work\ImageGrid\cur\ImageGrid\src\test\python-bug.py", >> line 17, in >> ## l[0] += [1] >> ## TypeError: 'tuple' object does not support item assignment > > What is even more fun is that the append actually worked (try printing > l). > > This is not a bug, it is a quirk of how extended assignment works. > I think there's an issue report in the tracker somewhere that > discusses it. > > --David -- Alex. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] inconsistency when swapping obj.__dict__ with a dict-like object...
Hi!
here is a simple piece of code
---cut---
class Dict(dict):
def __init__(self, dct={}):
self._dict = dct
def __getitem__(self, name):
return self._dct[name]
def __setitem__(self, name, value):
self._dct[name] = value
def __delitem__(self, name):
del self._dct[name]
def __contains__(self, name):
return name in self._dct
def __iter__(self):
return iter(self._dct)
class A(object):
def __new__(cls, *p, **n):
o = object.__new__(cls)
o.__dict__ = Dict()
return o
a = A()
a.xxx = 123
print a.__dict__._dict
a.__dict__._dict['yyy'] = 321
print a.yyy
--uncut--
Here there are two problems, the first is minor, and it is that
anything assigned to the __dict__ attribute is checked to be a
descendant of the dict class (mixing this in does not seem to work)...
and the second problem is a real annoyance, it is that the mapping
protocol supported by the Dict object in the example above is not used
by the attribute access mechanics (the same thing that once happened
in exec)...
P.S. (IMHO) the type check here is not that necessary (at least in its
current state), as what we need to assert is not the relation to the
dict class but the support of the mapping protocol
thanks.
--
Alex.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
