Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23757
___
Roundup Robot added the comment:
New changeset c79530e08985 by Raymond Hettinger in branch '3.4':
Issue #23757: Only call the concrete list API for exact lists.
https://hg.python.org/cpython/rev/c79530e08985
--
___
Python tracker
Roundup Robot added the comment:
New changeset b6121a4afad7 by Raymond Hettinger in branch '2.7':
Issue #23757: Only call the concrete list API for exact lists.
https://hg.python.org/cpython/rev/b6121a4afad7
--
nosy: +python-dev
___
Python tracker
Serhiy Storchaka added the comment:
Raymond's patch LGTM. Here is updated patch with tests.
--
assignee: - rhettinger
keywords: +patch
stage: needs patch - commit review
Added file: http://bugs.python.org/file39404/fix_list_to_tuple_2.diff
___
Raymond Hettinger added the comment:
Added a patch. Needs to have the OP's test case added.
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23757
___
Serhiy Storchaka added the comment:
And it would be nice to add the same test for list, set, etc (if they don't
exist).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23757
___
Stuart Bishop added the comment:
Can we get this reopened? As David MacIver points out, this seems entirely a
wart in tuple's constructor (compared to all the other builtin types), whereas
10977 is worrying about how 3rd party code using the C API can corrupt
subclasses of builtin types (a
Changes by R. David Murray rdmur...@bitdance.com:
--
resolution: duplicate -
stage: resolved - needs patch
status: closed - open
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23757
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
keywords: +patch
Added file: http://bugs.python.org/file39365/fix_list_to_tuple.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23757
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
keywords: +easy -patch
priority: normal - high
versions: +Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23757
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23757
___
___
David MacIver added the comment:
Ah, I hadn't seen that. Thanks for the link.
But... is it really? They have basically the same root cause, but the general
problem seems to be hard to fix, while the specific problem here seems to be
basically don't use the concrete API here because it breaks
R. David Murray added the comment:
Right, but unless I miss my guess (I haven't looked at the code) it isn't that
the concrete api is being used by the constructor, it's that the concrete API
is being used by the iterator protocol called by the constructor. If I'm wrong
it would be sensible
R. David Murray added the comment:
This is a specific instance of the general problem covered by issue 10977.
--
nosy: +r.david.murray
resolution: - duplicate
stage: - resolved
status: open - closed
superseder: - Concrete object C API considered harmful to subclasses of
builtin
New submission from David MacIver:
Converting a list to a tuple appears to have an optimisation that is wrong in
the presence of subclassing to override __iter__. It ignores the user defined
iter and uses the normal list one. I've attached a file with a test case to
demonstrate this.
I've
David MacIver added the comment:
So as a data point, this problem seems to be unique to tuple. set(x), list(x),
tuple(iter(x)) all seem to work as expected and respect the overridden __iter__
(set and list were both included in the test case I attached to demonstrated
this, iter I just
16 matches
Mail list logo
