[issue9891] Minor doc typo at datamodel.rst: "list" -> "alist"
New submission from Rodrigo Bernardo Pimentel : The "Built-in methods" item of the "The standard type hierarchy" section of Doc/reference/datamodels.rst uses a list instance called "alist" as an example, and it says "__self__ is set to the object denoted by *list*." It should read "the object denoted by *alist*" This affects all releases, so I've marked them all. But I suppose we don't care about 2.5 anymore. All the others are listed on docs.python.org (or are "trunk"), and I think should be fixed. It's a trivial fix, and a single patch works 2.x and another for 3.x. -- assignee: d...@python components: Documentation files: alist_doc-2.x.patch keywords: patch messages: 116757 nosy: d...@python, rbp priority: normal severity: normal status: open title: Minor doc typo at datamodel.rst: "list" -> "alist" versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file18914/alist_doc-2.x.patch ___ Python tracker <http://bugs.python.org/issue9891> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9891] Minor doc typo at datamodel.rst: "list" -> "alist"
Changes by Rodrigo Bernardo Pimentel : Added file: http://bugs.python.org/file18915/alist_doc-3.x.patch ___ Python tracker <http://bugs.python.org/issue9891> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10047] python-2.6.6 coredump running newspipe
Rodrigo Bernardo Pimentel added the comment: Does this always happen with a particular feed? Could you provide us with a configuration that reproduces the problem? Also, as R. David Murray asked, does this happen with 2.7? -- nosy: +rbp ___ Python tracker <http://bugs.python.org/issue10047> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10017] pprint.pprint raises TypeError on dictionaries with user-defined types as keys
Rodrigo Bernardo Pimentel added the comment: FWIW, the problem still occurs on the most recent release31-maint checkout (as of r85323), and does not happen on py3k (3.2a2). -- nosy: +rbp ___ Python tracker <http://bugs.python.org/issue10017> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10017] pprint.pprint raises TypeError on dictionaries with user-defined types as keys
Rodrigo Bernardo Pimentel added the comment:
If I'm understanding this correctly, this fails on 3.1 and not (although,
actually, it does) on py3k/3.2 because:
* pprint._safe_key.__lt__ checks "rv = self.obj.__lt__(other.obj)" and falls
back to id comparison if rv is NotImplemented
* If the object passed to _safe_key is a class, self.obj.__lt__ will expect
*self* as well as the other object. Therefore the verification above fails with
"TypeError: expected 1 arguments, got 0". You can see that pprint works with an
instance:
>>> pprint.pprint({A(): 1, 1: 2})
{<__main__.A object at 0x8594d4c>: 1, 1: 2}
* Finally, this works on py3k *for your example* because, for some reason, on
py3k the comparison is being based on the 1 key. That is, the comparison on
_safe_key.__lt__ happens to be 1.__lt__(A), instead of A.__lt__(1). Perhaps
hashing changed after the 3.1 release?
Anyway, py3k still fails when you force the comparison to happen on the class:
>>> class B(object): pass
...
>>> pprint.pprint({A: 1, B: 2})
Traceback (most recent call last):
File "", line 1, in
File "/home/rbp/python/dev/py3k/Lib/pprint.py", line 55, in pprint
printer.pprint(object)
File "/home/rbp/python/dev/py3k/Lib/pprint.py", line 132, in pprint
self._format(object, self._stream, 0, 0, {}, 0)
File "/home/rbp/python/dev/py3k/Lib/pprint.py", line 155, in _format
rep = self._repr(object, context, level - 1)
File "/home/rbp/python/dev/py3k/Lib/pprint.py", line 245, in _repr
self._depth, level)
File "/home/rbp/python/dev/py3k/Lib/pprint.py", line 257, in format
return _safe_repr(object, context, maxlevels, level)
File "/home/rbp/python/dev/py3k/Lib/pprint.py", line 299, in _safe_repr
items = sorted(object.items(), key=_safe_tuple)
File "/home/rbp/python/dev/py3k/Lib/pprint.py", line 89, in __lt__
rv = self.obj.__lt__(other.obj)
TypeError: expected 1 arguments, got 0
>>>
So, basically, the fix on issue 3976 does't (always) work when there are
classes as dict keys. I think switching from
rv = self.obj.__lt__(other.obj)
if rv is NotImplemented:
to something like
try:
rv = self.obj < other.obj
except TypeError:
rv = (str(type(self.obj)), id(self.obj)) < \
(str(type(other.obj)), id(other.obj))
solves this. Or we can check first whether self.obj is a 'type', but I think it
gets convoluted.
If anyone can confirm that that's the way to go, I can produce one (though it's
a trivial one). Raymond?
--
___
Python tracker
<http://bugs.python.org/issue10017>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3976] pprint._safe_repr is not general enough in one instance
Rodrigo Bernardo Pimentel added the comment: Armin: this has the problem that, if the object you're trying to compare is a class, self.obj.__lt__ expects a different number of parameters (i.e., it expects the instance). See issue 10017 . Testing with "<" works. -- nosy: +rbp ___ Python tracker <http://bugs.python.org/issue3976> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5131] pprint doesn't know how to print a defaultdict
Changes by Rodrigo Bernardo Pimentel : -- nosy: +rbp ___ Python tracker <http://bugs.python.org/issue5131> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9305] Don't use east/west of UTC in date/time documentation
Changes by Rodrigo Bernardo Pimentel : -- nosy: +rbp ___ Python tracker <http://bugs.python.org/issue9305> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9305] Don't use east/west of UTC in date/time documentation
Rodrigo Bernardo Pimentel added the comment: 1. Done (it's on the patch I'm uploading). Sorry. 3. Ok, we've rewritten that sentence. As Henrique mentioned, we're working on a larger patch to make datetime documentation clearer, and we can include a definition of "standard time" there. 2. I assume you're talking about sentences like "(negative for west of UTC)". We removed that wording because it inevitably leads to associating UTC with a geographical reference. Even if we disregard that, it's not true that "utcoffset is negative west of UTC", since it will we zero for for UTC-1 (and even +1 for places physically "west of UTC" but at timezone UTC+0) when DST is effective. It seems that any sentence we add to that effect will be simply restating the definitions of UTC, timezones and DST (and their mathematical relationships). That is, "utcoffset will be negative when dt.tzinfo + dst() is negative". Perhaps we could include a more detailed discusion about the sign of utcoffset() on the larger doc patch I've mentioned? Or do you have any suggestions? -- Added file: http://bugs.python.org/file19709/datetime_doc_remove_east_west_2.diff ___ Python tracker <http://bugs.python.org/issue9305> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10220] Make generator state easier to introspect
Changes by Rodrigo Bernardo Pimentel : -- nosy: +rbp ___ Python tracker <http://bugs.python.org/issue10220> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10351] Add autocompletion for keys in dictionaries
Changes by Rodrigo Bernardo Pimentel : -- nosy: +rbp ___ Python tracker <http://bugs.python.org/issue10351> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10427] 24:00 Hour in DateTime
Rodrigo Bernardo Pimentel added the comment: I was writing tests for this issue, when something struck me: ok, datetime(year, month, day, 24) is valid. But is datetime(year, month, day, 24, 1) valid? Or datetime(year, month, day, 24, 0, 0, 1)? I would say those aren't valid, although that makes checking forvalid hour values slightly weird (as in not straightforward): 24 is valid if minutes, seconds and microseconds are all 0, but invalid otherwise. What do you think? -- nosy: +rbp ___ Python tracker <http://bugs.python.org/issue10427> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9063] TZ examples in datetime.rst are incorrect
Changes by Rodrigo Bernardo Pimentel : -- nosy: +rbp ___ Python tracker <http://bugs.python.org/issue9063> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3417] make the fix_dict fixer smarter
Rodrigo Bernardo Pimentel <[EMAIL PROTECTED]> added the comment: I haven't managed to successfully complete the summer of code, due to some personal problems, but I'm still working on 2to3 and on confidence ranking for it. There's a bzr branch with its current implementation at http://isnomore.net/bzr/2to3 . I did an initial implementation of confidence penalties on fix_dict for special contexts. I'm still working on it (and on confidence ranking in general), but please take a look and let me know what you think. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3417> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3417] make the fix_dict fixer smarter
Rodrigo Bernardo Pimentel <[EMAIL PROTECTED]> added the comment: (I've just realized it's not working properly for fix_dict; I'm fixing it and will drop a note here when it is) ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3417> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7583] Improve explanation of tab expansion in doctests
Rodrigo Bernardo Pimentel added the comment: I've just been bitten by this, and I agree the language in the docs is very inappropriate (made me angry for a minute :)). One suggestion: "While not everyone might believe tabs should mean that, doctests are primarily aimed at documentation, and, since it's very hard to get tabs to look consistent, keeping hard tabs would be potentially confusing. If you absolutely need to test for the presence of tabs at the output, you can capture it and use string comparison, or write your own DocTestParser class." -- nosy: +rbp ___ Python tracker <http://bugs.python.org/issue7583> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2532] file that breaks 2to3 (despite being correct python)
Changes by Rodrigo Bernardo Pimentel <[EMAIL PROTECTED]>: -- nosy: +rbp __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2532> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2805] 2to3 doesn't correct divisions
Rodrigo Bernardo Pimentel <[EMAIL PROTECTED]> added the comment: +1 for going ahead and writing a fixer. -- nosy: +rbp __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2805> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2803] heapq.heappush called with too few arguments in sched.py
Rodrigo Bernardo Pimentel <[EMAIL PROTECTED]> added the comment: +1 on the patch. IIRC, there won't be any more bugfix releases for 2.5.x, but, just in case: the patch doesn't work on 2.5 (though the issue lists it as an affected version - and it is!), so I'm uploading a patch for it (svn tag r252). I started writing a test for it, but it's such an obvious and trivial patch that I think it's unnecessary. -- nosy: +rbp Added file: http://bugs.python.org/file10244/sched.py.patch-r252 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2803> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2798] Crash on non-Windows if Python runs from a non-ASCII directory
Rodrigo Bernardo Pimentel <[EMAIL PROTECTED]> added the comment: The patch works for me, and I agree the test_xmlrpc is an xmlrpc issue. Perhaps unrelated to this issue, but I think it makes this whole unicode getargs situation fragile: I could not understand why the 'z' case (on the switch where this patch applies, starting on line 879 on the patched file) does a PyString_Check(arg) and a PyUnicode_Check(arg), while the corresponding section on case 's' (line 813) only does PyUnicode_Check(arg). Is this really an inconsistency? Maybe this should go into an issue to cleanup this switch, according to the comment at its beginning: /* XXX WH! 's', 'y', 'z', 'u', 'Z', 'e', 'w', 't' codes all need to be cleaned up! */ -- nosy: +rbp __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2798> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2723] Truncate __len__() at sys.maxsize
Rodrigo Bernardo Pimentel <[EMAIL PROTECTED]> added the comment:
I think returning sys.{maxint,maxsize} in this case is a plain lie.
That's not practicality, that's giving back false information.
Barring drastic language changes (such as having objects representing
"infinity" or "greater than" - which, of course, won't happen), I think
the current behaviour of raising an exception is the correct one. But,
although I think OverflowError is good enough, the current exception
message is a bit cryptic, especially for anyone who doesn't know C:
"""OverflowError: Python int too large to convert to C ssize_t"""
I've attached a simple patch (modified from Alexander's) to raise:
"""OverflowError: Length too large"""
(I thought about "Object too large", but our problem is actually that
the *length* itself is too large)
--
nosy: +rbp
Added file: http://bugs.python.org/file10270/len_message.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2723>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1713041] fix for 1712742: corrects pprint's handling of 'depth'
Rodrigo Bernardo Pimentel <[EMAIL PROTECTED]> added the comment: It seems that somewhere along the road between revision 55144 (where the first patch was generated) and current trunk (revision 63129), PrettyPrinter._format has stopped handling depth! I've attached a patch that fixes this, along with the fixes this issue originally proposed (including the tests and documentation updates). With this patch, unit tests and the documentation's doctests all pass. BTW, doctesting Doc/library/pprint.rst with optionflags=doctest.ELLIPSIS erroneously interprets pprint's '...' (indicating depth exceeded) as doctest ellipses! Testing without ELLIPSIS gives an error on output with something like "[]", testing with it hides errors. Ugh! -- nosy: +rbp -errebepe Added file: http://bugs.python.org/file10302/pprint-r63129.patch _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1713041> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1293741] doctest runner cannot handle non-ascii characters
Changes by Rodrigo Bernardo Pimentel : -- nosy: +rbp ___ Python tracker <http://bugs.python.org/issue1293741> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20208] Clarify some things in porting HOWTO
Rodrigo Bernardo Pimentel added the comment: I've created a patch that addresses the first criticism (explaining unicode_literals), as well as the first mention of print_function. It also addresses a small concern regarding "map", which I've mentioned in my G+ comment: """ Also, a friend was confused by http://docs.python.org/dev/howto/pyporting.html#update-map-for-imbalanced-input-sequences , until I understood that he didn't know map can take several sequences. I assume a lot of less experienced Python programmers only use map with a single sequence, and might be confused as well. A sentence mentioning that might help. """ I see that the current version of the doc on hg already addresses the 2to3 mention. -- keywords: +patch nosy: +rbp Added file: http://bugs.python.org/file33408/pyporting.patch ___ Python tracker <http://bugs.python.org/issue20208> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20208] Clarify some things in porting HOWTO
Rodrigo Bernardo Pimentel added the comment: BTW, there remains another concern I mentioned on G+: """ A note on formatting: I found some of 4th- and 5th-level headings too subtle. For instance, http://docs.python.org/dev/howto/pyporting.html#from-future-import-absolute-import got me thinking for a second if it was part of the previous paragraph or a new heading. Maybe underlining, or a bullet-like marker, or some indentation could help there. """ But I don't know enough of the formatting standards, so I haven't addressed this in the patch. -- ___ Python tracker <http://bugs.python.org/issue20208> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6583] 2to3 fails to fix test.test_support
Rodrigo Bernardo Pimentel added the comment: Pascal is correct, trunk Doc/library/test.rst still says: "The 2to3 tool will automatically adapt imports when converting your sources to 3.0." Perhaps this should simply be changed to "The 2to3 tool will not automatically convert this, so make sure you do, manually, if you port your code to Python 3." Please let me know if you require a patch for this (but I think it's trivial enough), or if you think this should raise a -3 warning. -- nosy: +rbp ___ Python tracker <http://bugs.python.org/issue6583> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2516] Instance methods are misreporting the number of arguments
Changes by Rodrigo Bernardo Pimentel : -- nosy: +rbp ___ Python tracker <http://bugs.python.org/issue2516> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
