[issue5131] pprint doesn't know how to print a defaultdict
Nick Craig-Wood added the comment: Raymond Hettinger (rhettinger) wrote: > Ben, I don't think there is any value is opening more issues like > pprint-doesn't-handle-object-x (named tuples, defautdicts, deques, > generators, etc). > > As it is currently designed, pprint doesn't offer usable hooks and it is not > easy to build-out to handle new object types. For the most part, users just > cast to a list before calling pprint. I mildly disagree, IMHO pprint should be able to make a decent job of all the built in types otherwise it loses its value as a debugging tool. It is a suprise when a built in type doesn't pprint properly. This would surely be an excellent use of the abstract base classes defined in the collections module for pprint to make a best guess as to how to print types it doesn't understand directly? > ISTM, the RightAnswer(tm) is to overhaul pprint and add hooks for handling > new objects. Ideally, there would be flexible print options and reprlib-like > features for limiting output and for marking recursive constructs with "..." That is a very good idea, but might be unecessary with the ABC idea above -- ___ 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
[issue5131] pprint doesn't know how to print a defaultdict
Nick Craig-Wood added the comment: Terry J. Reedy (terry.reedy) wrote: > > IMHO pprint should be able to make a decent job of all the built in types > > Agreed, already true as far as I know, and irrelevant. This issue is not > about built-in types in the builtins module, as documented Lib Ref chapter 5 > *Built-in Types*. Collections is an Python-coded stdlib module that happens > to import a couple of its classes from _collections, written in C for speed. My bad - not precise enough! I meant all the stdlib types rather than the builtin types. -- ___ 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
[issue8264] hasattr doensn't show private (double underscore) attributes exist
New submission from Nick Craig-Wood : I just spend a while tracking down a bug in my code which turned out to be an unexpected behaviour of hasattr. Running this class Test(object): def __init__(self): self.__private = "Hello" def test(self): print(self.__private) print(hasattr(self, "__private")) print(getattr(self, "__private")) t = Test() t.test() Prints >>> t.test() Hello False Traceback (most recent call last): File "private_test.py", line 10, in t.test() File "private_test.py", line 7, in test print(getattr(self, "__private")) AttributeError: 'Test' object has no attribute '__private' >>> Indicating that even though we just printed self.__private hasattr() can't find it nor getattr(). I think this is probably the intended behaviour, but it does seem inconsistent. Probably all that is required is a documentation patch... Maybe something add something like this to the end of http://docs.python.org/library/functions.html#hasattr Note that hasattr won't find private (double underscore) attributes unless the mangled name is used. -- components: Interpreter Core messages: 101928 nosy: ncw severity: normal status: open title: hasattr doensn't show private (double underscore) attributes exist type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue8264> ___ ___ 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 set or a defaultdict
New submission from Nick Craig-Wood :
I noticed this the other day when debugging a program that neither set()
nor defaultdict() pprint() properly
Same under 3.1 and 2.5 (Not tried 2.6/2.7 but I assume it is the same)
>>> pprint(set(range(100)))
set([0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18,
19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36,
37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54,
55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72,
73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90,
91, 92, 93, 94, 95, 96, 97, 98, 99])
>>> from collections import defaultdict
>>> pprint(defaultdict(int).fromkeys(range(100)))
defaultdict(None, {0: None, 1: None, 2: None, 3: None, 4: None, 5: None,
6: None, 7: None, 8: None, 9: None, 10: None, 11: None, 12: None, 13:
None, 14: None, 15: None, 16: None, 17: None, 18: None, 19: None, 20:
None, 21: None, 22: None, 23: None, 24: None, 25: None, 26: None, 27:
None, 28: None, 29: None, 30: None, 31: None, 32: None, 33: None, 34:
None, 35: None, 36: None, 37: None, 38: None, 39: None, 40: None, 41:
None, 42: None, 43: None, 44: None, 45: None, 46: None, 47: None, 48:
None, 49: None, 50: None, 51: None, 52: None, 53: None, 54: None, 55:
None, 56: None, 57: None, 58: None, 59: None, 60: None, 61: None, 62:
None, 63: None, 64: None, 65: None, 66: None, 67: None, 68: None, 69:
None, 70: None, 71: None, 72: None, 73: None, 74: None, 75: None, 76:
None, 77: None, 78: None, 79: None, 80: None, 81: None, 82: None, 83:
None, 84: None, 85: None, 86: None, 87: None, 88: None, 89: None, 90:
None, 91: None, 92: None, 93: None, 94: None, 95: None, 96: None, 97:
None, 98: None, 99: None})
>>>
--
components: Library (Lib)
messages: 80948
nosy: ncw
severity: normal
status: open
title: pprint doesn't know how to print a set or a defaultdict
type: feature request
versions: Python 2.5, Python 3.1
___
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
[issue5131] pprint doesn't know how to print a set or a defaultdict
Nick Craig-Wood added the comment: I couldn't actually get this patch to apply to the py3k branch :-( $ patch -p0 --dry-run < issue_5131.patch patching file Misc/NEWS Hunk #1 FAILED at 2598. 1 out of 1 hunk FAILED -- saving rejects to file Misc/NEWS.rej patching file Misc/ACKS Hunk #1 succeeded at 147 (offset -1 lines). Hunk #2 succeeded at 791 (offset 3 lines). patching file Lib/pprint.py Hunk #1 FAILED at 37. Hunk #2 FAILED at 137. Hunk #3 FAILED at 168. 3 out of 3 hunks FAILED -- saving rejects to file Lib/pprint.py.rej patching file Lib/test/test_pprint.py Hunk #1 succeeded at 408 (offset -6 lines). $ svn info Path: . URL: http://svn.python.org/projects/python/branches/py3k Repository Root: http://svn.python.org/projects Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771 Revision: 70705 Node Kind: directory Schedule: normal Last Changed Author: antoine.pitrou Last Changed Rev: 70696 Last Changed Date: 2009-03-29 20:30:55 +0100 (Sun, 29 Mar 2009) -- ___ 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
[issue5131] pprint doesn't know how to print a set or a defaultdict
Nick Craig-Wood added the comment: Oops, my bad, I assumed the patch would by for py3k! I applied it to trunk and tested it. It works very well - thank you for fixing that :-) -- ___ 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
[issue9510] sqlite3.Warning isnt a subclass of exceptions.Warning
New submission from Nick Craig-Wood :
sqlite3.Warning isnt a subclass of exceptions.Warning
This causes this problem when trying to filter warnings
>>> import sqlite3 as DB
>>> from warnings import filterwarnings
>>> filterwarnings("always", category=DB.Warning)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.6/warnings.py", line 56, in filterwarnings
assert issubclass(category, Warning), "category must be a Warning subclass"
AssertionError: category must be a Warning subclass
>>>
Other databases do this correctly, eg
>>> import MySQLdb as DB
>>> from warnings import filterwarnings
>>> filterwarnings("always", category=DB.Warning)
>>>
--
components: Library (Lib)
files: sqlite3-warning-fix.patch
keywords: patch
messages: 112800
nosy: ncw
priority: normal
severity: normal
status: open
title: sqlite3.Warning isnt a subclass of exceptions.Warning
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file18383/sqlite3-warning-fix.patch
___
Python tracker
<http://bugs.python.org/issue9510>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9510] sqlite3.Warning isnt a subclass of exceptions.Warning
Nick Craig-Wood added the comment: I've attached a patch to fix the issue along with a revised test. -- ___ Python tracker <http://bugs.python.org/issue9510> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9510] sqlite3.Warning isnt a subclass of exceptions.Warning
Nick Craig-Wood added the comment: I re-worked the patch for python 3.x (py3k branch) - the other was for 2.x (trunk) Basically the same patch and fixes the issue according to my testing -- Added file: http://bugs.python.org/file18386/sqlite3-warning-fix-py3k.patch ___ Python tracker <http://bugs.python.org/issue9510> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9510] sqlite3.Warning isnt a subclass of exceptions.Warning
Nick Craig-Wood added the comment: I think the fact that sqlite may not be using the warnings properly is independent of this problem. Warnings should be filterable, but if sqlite isn't notifying them properly - that would be a different bug. BTW I came across this problem when trying to swap out MySQLdb with sqlite3. The existing code was filtering warnings, that didn't work with sqlite3, hence this bug report! -- ___ Python tracker <http://bugs.python.org/issue9510> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9510] sqlite3.Warning isnt a subclass of exceptions.Warning
Nick Craig-Wood added the comment: Reading PEP 0249 I can see Gerhard is correct, this patch would violate the PEP. I think that the PEP is slightly flawed in that users are encouraged to raise exceptions called "Warning". IMHO a Warning is never an exceptional condition and should be notified by the warnings framework. This obviously confused the authors of MySQLdb, who do indeed warn() their Warning classes rather than raise() them, and it is very useful to be able to filter them. To obey the letter of the PEP the authors of the MySQLdb interface multiply inherit their Warning class from exceptions.StandardError and exceptions.Warning. I could make a patch for sqlite3 to do this if anyone thinks it would be useful. -- ___ Python tracker <http://bugs.python.org/issue9510> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24049] Remove unused code in symtable.c and fix docs for import * checking
New submission from Nick Craig-Wood:
Here is a patch to remove some unused code in `symtable.c`
In Python3 `from x import *` was banned from use in functions completely.
This is detected by `symtable_visit_alias`
if (st->st_cur->ste_type != ModuleBlock) {
int lineno = st->st_cur->ste_lineno;
int col_offset = st->st_cur->ste_col_offset;
PyErr_SetString(PyExc_SyntaxError, IMPORT_STAR_WARNING);
However in `check_unoptimized` it checks for `import *` being used in a nested
function etc. This is the python2 behaviour which wasn't removed at the time
the new python3 behaviour was added.
According to my analysis and tests it is now impossible for `check_unoptimized`
to raise an error, since only valid uses of `import *` are left at the point it
is called.
I propose to remove that function entirely, its call, and fix some stray
documentation in this patch.
--
components: Interpreter Core
files: python3.5-symtable.patch
keywords: patch
messages: 241937
nosy: ncw
priority: normal
severity: normal
status: open
title: Remove unused code in symtable.c and fix docs for import * checking
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file39195/python3.5-symtable.patch
___
Python tracker
<http://bugs.python.org/issue24049>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
