Ethan Furman added the comment:
No real-world use-cases have surfaced. Many thanks to everyone's explanations
and examples.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22766
___
Serhiy Storchaka added the comment:
I've posted to python-list and python-dev. I'll report back here the
findings, if any.
http://comments.gmane.org/gmane.comp.python.devel/150073
--
nosy: +serhiy.storchaka
___
Python tracker
Jim Jewett added the comment:
I wish there were an APIMismatchError superclass to unify
(AttributeError, TypeError). But the wart probably isn't enough to
justify the surgery.
On Thu, Nov 6, 2014 at 8:48 AM, Serhiy Storchaka rep...@bugs.python.org wrote:
Serhiy Storchaka added the comment:
Raymond Hettinger added the comment:
However, doing the check on 'other' and raising a TypeError
with an appropriate message would still be better
Let's be clear. These are duck-typed methods. A type check is inappropriate.
Anything with o.items() is allowed regardless of type.
Also, I
Ethan Furman added the comment:
Raymond declared:
Let's be clear. These are duck-typed methods. A type check is inappropriate.
Anything with o.items() is allowed regardless of type.
Wikipedia explains (http://en.wikipedia.org/wiki/Duck_typing):
R. David Murray added the comment:
There is no purpose served by changing the AttributeError into a TypeError.
It's just extra unneeded code.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22766
Ethan Furman added the comment:
I've posted to python-list and python-dev. I'll report back here the findings,
if any.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22766
___
Ethan Furman added the comment:
I don't want to change the kind of exception being raised (an API change from
AttributeError to TypeError) without a really good reason.
Subclasses cannot work with the current implementation.
In general, in-place methods are not required to return
R. David Murray added the comment:
On Mon, 03 Nov 2014 10:53:09 +, Ethan Furman rep...@bugs.python.org wrote:
Ethan Furman added the comment:
I don't want to change the kind of exception being raised (an API change
from
AttributeError to TypeError) without a really good reason.
Jim Jewett added the comment:
If I know that a Counter (or any class X) can be updated in place, I will be
surprised to find out that I'm using a different instance after a successful
in-place operation.
I would even consider that (replacement of the original instance) a security
risk,
Ethan Furman added the comment:
Ethan stated:
The only problem with the design is that it does not play well with others.
For
duck-typeable just do a check on 'other' to see if it has an .items()
method, and
return NotImplemented if it does not. Oh, and check that 'self' is Counter,
Ethan Furman added the comment:
Okay, the python-dev ruling is in, and raising an exception in the __ixxx__
methods is allowed, and even a good idea in the cases of mutable containers.
However, doing the check on 'other' and raising a TypeError with an appropriate
message would still be
Raymond Hettinger added the comment:
Sorry, I don't want to change the kind of exception being raised (an API change
from AttributeError to TypeError) without a really good reason.
In general, in-place methods are not required to return NotImplemented (for
example, (3).__iadd__(4.5) raises an
R. David Murray added the comment:
I agree with Raymond about the value of the more specific error message. And
the point about the in-place operators being qualitatively different from the
non-inplace operators is a good one.
--
___
Python
Raymond Hettinger added the comment:
Here is what other mutable types do:
s = []
s.__iadd__(1)
Traceback (most recent call last):
File pyshell#1, line 1, in module
s.__iadd__(1)
TypeError: 'int' object is not iterable
s = set()
s.__ior__(1)
NotImplemented
from collections import
Raymond Hettinger added the comment:
Note, the += operation is conceptually similar to update() methods with are
usually duck typeable:
d = {}
d.update(1)
Traceback (most recent call last):
File pyshell#16, line 1, in module
d.update(1)
TypeError: 'int' object is not iterable
s =
Ethan Furman added the comment:
The behavior exhibited by set() is correct, and the behavior for array and
bytearray are fine, as the error message is even more helpful.
Issues opened for list (issue22778) and deque (issue22779).
--
___
Python
Antoine Pitrou added the comment:
I think I've changed my mind on this. The important distinction is not between
ducktyping or cooperating. It's that this is an in-place mutating
operation. A mutating operation should always be the responsibility of the
receiver, and so it sounds wrong to be
Ethan Furman added the comment:
https://docs.python.org/2/reference/datamodel.html#object.__iadd__
--
[...] These methods should attempt to do the operation in-place (modifying
self) and return the result (which could be, but does
Antoine Pitrou added the comment:
You misread that paragraph:
For instance, to execute the statement x += y, where x is an instance of a
class that has an __iadd__() method, x.__iadd__(y) is called.
This is the present case, and the case of most mutable containers.
If x is an instance of a
Ethan Furman added the comment:
Nevertheless, that is the behavior if NotImplemented is returned by a method.
Here's some code to demonstrate:
--8---
from collections import Counter
class Spam(int):
for sake of example
def __radd__(self, other):
Antoine Pitrou added the comment:
Yes, it's true that the message is better. If we don't want to change
behaviour, we should simply catch the AttributeError and return NotImplemented
from there.
--
___
Python tracker rep...@bugs.python.org
New submission from Joshua Chin:
Currently, in-place operations on 'collections.Counter' with unsupported types
raises an 'AttributeError'.
Example:
import collections
counter = collections.Counter()
counter += 1
Traceback (most recent call last):
File stdin, line 1, in module
File
Changes by Ethan Furman et...@stoneleaf.us:
--
assignee: - rhettinger
nosy: +ethan.furman, rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22766
___
Changes by Ethan Furman et...@stoneleaf.us:
--
versions: +Python 2.7, Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22766
___
___
R. David Murray added the comment:
That would prevent it from working with work alike (duck type) classes,
though.
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22766
Ethan Furman added the comment:
As I noted in my review, the docstring specifically says other Counter.
If we want to relax that we could check for an 'items' attribute and 'return
NotImplemented' if it isn't there, but one or the other should definitely
happen.
--
R. David Murray added the comment:
'counter' in the docstrings is in lower case, so that says nothing dispositive.
However, __add__ does an ininstance check, so it is hard to see why __iadd__
does not.
Personally I'd drop the isinstance checks and let the errors bubble up as they
may. Why
Ethan Furman added the comment:
Indeed -- we mostly discuss with each other to try and sway his opinion. :)
stdlib types should not let every error bubble up. Consider a dict:
-- d = {}
-- d += 2
Traceback (most recent call
Antoine Pitrou added the comment:
I also think returning NotImplemented would be the right thing here.
--
nosy: +pitrou
type: behavior - enhancement
versions: -Python 2.7, Python 3.4
___
Python tracker rep...@bugs.python.org
30 matches
Mail list logo
