[issue6324] "in" expression falls back to __iter__ before __getitem__
Anthony Foglia added the comment: I've added Python 2.7 to the list of versions. The development docs have the same issue. Let me try another stab at what the docs should say. Following the suggestion to add it to 3.3.5, perhaps it should be: " object.__contains__(self, item) Called to implement membership test operators. Should return true if item is in self, false otherwise. For mapping objects, this should consider the keys of the mapping rather than the values or the key-item pairs. If __contains__ is not provided but __iter__ is provided, the membership test "x in y" is true if and only if there is a value z reachable by iterating iter(y) before iter(y) throws a StopIteration exception. (If any other exception is raised, it is as if in raised that exception). If neither __contains__ nor __iter__ are provided but __getitem__ is provided, the membership test "x in y" is true if and only if there is a non-negative integer index i such that x == y[i], and all lower integer indices do not raise IndexError exception. (If any other exception is raised, it is as if in raised that exception). " I worry that this is becoming more a description of "in" rather than __contains__. Either way, the last sentence in paragraph 6 of section 5.9 should refer not just to 3.3.1 (Basic Customization) but also 3.3.5 (Emulating Container Types). The latter is where __contains__, __iter__ and __getitem__ are defined. Perhaps the new wording should be, "You can control comparison behavior of objects of non-built-in types by defining rich comparison methods like __gt__(), described in section Basic customization, and the membership test method __contains__(), described in section Emulating container types." -- versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue6324> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7434] pprint doesn't know how to print a namedtuple
New submission from Anthony Foglia : It would be nice if pprint could format namedtuples wrapping lines as it does with tuples. Looking at the code, this does not look like an easy task. Completely rewriting pprint to allow it to be extensible to user-created classes would be best, but involve a ton of work. Simple making all named tuples derive from a named tuple base class (itself derived from tuple) would be simpler, albeit more of a hack. -- components: Library (Lib) messages: 95968 nosy: afoglia severity: normal status: open title: pprint doesn't know how to print a namedtuple type: feature request versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue7434> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7542] segfault on cPickle.loads("0.")
New submission from Anthony Foglia :
cPickle in Python 2.6.4 segfaults when trying to load the string "0.".
pickle throws an error. cPickle should at the least not segfault.
$ python
Python 2.6.4 (r264:75706, Nov 2 2009, 14:44:17)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle, cPickle
>>> pickle.loads("0.")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.6/pickle.py", line 1374, in loads
return Unpickler(file).load()
File "/usr/lib/python2.6/pickle.py", line 858, in load
dispatch[key](self)
File "/usr/lib/python2.6/pickle.py", line 1138, in load_pop
del self.stack[-1]
IndexError: list assignment index out of range
>>> cPickle.loads("0.")
Segmentation fault (core dumped)
--
components: Library (Lib)
messages: 96580
nosy: afoglia
severity: normal
status: open
title: segfault on cPickle.loads("0.")
type: crash
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue7542>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6324] "in" expression falls back to __iter__ before __getitem__
New submission from Anthony Foglia : I was debugging a class where I defined __getitem__ and __iter__, but not __contains__. The documentation describing this case (at the end of section 5.9) is old and hasn't been updated for the iterator protocol. It should read something like: "For user-defined classes which do not define __contains__() and do define __iter__() or __getitem__(), x in y is true if and only if there is a value z reachable from iter(y) before iter(y) throws a StopIteration exception. (If any other exception is raised, it is as if in raised that exception)." Or something better worded. (I'm using Python 2.5, but I really doubt things have changes in 2.6 or 2.7. I don't know enough about 3.0 to know either way.) -- assignee: georg.brandl components: Documentation messages: 89607 nosy: afoglia, georg.brandl severity: normal status: open title: "in" expression falls back to __iter__ before __getitem__ versions: Python 2.5, Python 2.6, Python 2.7 ___ Python tracker <http://bugs.python.org/issue6324> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8836] Conflicting default values of parameter to __import__
New submission from Anthony Foglia :
Looking at the documentation for the __import__ builtin, the default value of
the level parameter is unclear. Two different values are mentioned. The
function signature is written:
__import__(name, globals={}, locals={}, fromlist=[], level=-1)
But the third paragraph begins: "level specifies whether to use absolute or
relative imports. 0 (the default) means only perform absolute imports."
So which is it, -1 or 0?
I'm guessing 0. If -1 is still a valid value, it needs to be described.
--
assignee: d...@python
components: Documentation
messages: 106621
nosy: afoglia, d...@python
priority: normal
severity: normal
status: open
title: Conflicting default values of parameter to __import__
versions: Python 3.1
___
Python tracker
<http://bugs.python.org/issue8836>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9391] Allow docstrings on dicts and named tuples outside of functions or classes.
Anthony Foglia added the comment:
I could see adding a doc parameter to the collections.namedtuple. So that
---
>>> Point = collections.namedtuple("Point", ("x", "y"), doc="My point class")
>>> Point.__doc__
My point class
---
(Or it could keep the currently created docstring and append the new doc after
an empty line.)
---
>>> Point = collections.namedtuple("Point", ("x", "y"), doc="My point class")
>>> Point.__doc__
Point(x, y)
My point class
---
That being said, I can't think of a strong use case. If you care enough to add
a docstring, you're probably making a type used repeatedly in the code. In
that case, you can just use the verbose parameter and paste the definition into
your code.
I'm still in favor of it, simply because it would be a nice parameter to have,
but I don't think it's important.
--
nosy: +afoglia
___
Python tracker
<http://bugs.python.org/issue9391>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25136] Python doesn't find Xcode 7 stub libraries
Changes by Anthony Foglia : -- nosy: +afoglia ___ Python tracker <http://bugs.python.org/issue25136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
