[issue11446] Incorrect PEP link in Language Reference section 7.7

2011-03-08 Thread Terrence Cole
New submission from Terrence Cole : At the bottom of section 7.7 Class Definitions in the Python Language Reference: http://docs.python.org/py3k/reference/compound_stmts.html#class-definitions The text is: See also: PEP 3116 - Metaclasses in Python 3 PEP 3129 - Class Decorators This appears to

[issue8814] functools.WRAPPER_ASSIGNMENTS should include __annotations__

2010-08-04 Thread Terrence Cole
Terrence Cole added the comment: Awesome! I greatly appreciate the 3.1 backport, as that's what I'm going to be using for the foreseeable future. -- versions: +Python 3.2 -Python 3.1 ___ Python tracker <http://bugs.python.

[issue8814] functools.WRAPPER_ASSIGNMENTS should include __annotations__

2010-08-04 Thread Terrence Cole
Terrence Cole added the comment: Is there still a chance to get this fix in 3.2? -- ___ Python tracker <http://bugs.python.org/issue8814> ___ ___ Python-bug

[issue9158] PyArg_ParseTuple y* documentation is incorrect

2010-07-05 Thread Terrence Cole
Terrence Cole added the comment: Awesome! Thanks, and sorry for communicating the problem so poorly initially. -- ___ Python tracker <http://bugs.python.org/issue9

[issue9158] PyArg_ParseTuple y* documentation is incorrect

2010-07-05 Thread Terrence Cole
Terrence Cole added the comment: @Victor: "y* and z* result is a Py_buffer" Correct, so why is z* documented as [Py_buffer] and y* documented as [Py_buffer*]? If I make 'buffer' from your example a Py_buffer*, as documented, then python puts writes sizeof(Py_buffer) byte

[issue9158] PyArg_ParseTuple y* documentation is incorrect

2010-07-04 Thread Terrence Cole
New submission from Terrence Cole : The documented C type for y* should be [Py_buffer], not [Py_buffer *], as with the documentation for z* and the convention followed by the other types. I'm not sure what 'type' this issue should have. I've set it at 'crash' i

[issue8814] functools.WRAPPER_ASSIGNMENTS should include __annotations__

2010-06-16 Thread Terrence Cole
Terrence Cole added the comment: Alright, I've added several tests. I also modified update_wrapper to not copy missing attributes (like __annotations__ on builtin methods) -- see issue 1576241. (I also finally see what you mean with removing 3.3 from the versions list. Sorry I didn&#

[issue8814] functools.WRAPPER_ASSIGNMENTS should include __annotations__

2010-05-24 Thread Terrence Cole
Terrence Cole added the comment: Thank you for looking it over! The updated patch adds __annotations__ to the documentation where the value of WRAPPER_ASSIGNMENTS is given. I think it would be nice if the documentation showed WRAPPER_ASSIGNMENTS and WRAPPER_UPDATES in their own section

[issue8814] functools.WRAPPER_ASSIGNMENTS should include __annotations__

2010-05-24 Thread Terrence Cole
New submission from Terrence Cole : __annotations__ should be included in the set of attributes copied by default to a wrapped method. An example of the problem: >>> from functools import wraps >>> def mydecorator(fn): ... @wraps(fn) ... def inner(*args, **kwargs):

[issue8778] typo in docs for symtable.SymbolTable.has_import_star

2010-05-20 Thread Terrence Cole
New submission from Terrence Cole : The documentation for symtable.SymbolTable [http://docs.python.org/py3k/library/symtable.html] lists the function has_import_start. This should be has_import_star, as listed in help(symtable.SymbolTable). I've attached a patch, although it would pro

[issue7889] random produces different output on different architectures

2010-02-09 Thread Terrence Cole
Terrence Cole added the comment: Thank you for all the help! I'm glad to see that the use of hash() on buffer compatible objects is an actual gotcha and not just me being obtuse. Also, for those googling who, like me, won't be able to use 3.2's from_bytes until 3.2 is relea

[issue7889] random produces different output on different architectures

2010-02-08 Thread Terrence Cole
New submission from Terrence Cole : This code: >>> random.seed(b'foo') >>> random.getrandbits(8) ...repeated 7 more times... Yields the sequence of values: amd64: 227, 199, 34, 218, 83, 115, 236, 254 x86: 245, 198, 204, 66, 219, 4, 168, 93 Comments in the so

[issue6766] Cannot modify dictionaries inside dictionaries using Managers from multiprocessing

2010-01-29 Thread Terrence Cole
Terrence Cole added the comment: Kaushik, in your example, d is a dict proxy, so assignment to d['f'] correctly ferries the assignment (a new normal dict) to the d['f'] in the original process. The new dict, however, is not a dict proxy, it's just a dict, so assignm

[issue6766] Cannot modify dictionaries inside dictionaries using Managers from multiprocessing

2009-10-13 Thread Terrence Cole
Terrence Cole added the comment: The tests for the SyncManager are being automagically generated at import time -- I was not quite able to follow that well enough to know exactly what is getting tested, or if they are even enabled. It did not appear to contain any recursion, however

[issue6766] Cannot modify dictionaries inside dictionaries using Managers from multiprocessing

2009-10-13 Thread Terrence Cole
Terrence Cole added the comment: When a manager receives a message, it unpickles the arguments; this calls BaseProxy.__reduce__, which calls RebuildProxy. If we are in the manager, this returns the actual object, otherwise it returns a new proxy. If we naively disable the ability for proxied

[issue6766] Cannot modify dictionaries inside dictionaries using Managers from multiprocessing

2009-10-13 Thread Terrence Cole
Terrence Cole added the comment: I get the same results on: Python 2.6.2 (r262:71600, Sep 14 2009, 18:47:57) [GCC 4.3.2] on linux2 I think this is the same issue I was seeing yesterday. You can exercise the issue and cause an exception with just 6 lines: # CODE # from multiprocessing