[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, pp

[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

[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

[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, 1

[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

[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/issue5

[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

[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/i

[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

[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 tryi

[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

[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 linen