[issue1020] pydoc doesn't work on pyexpat
New submission from Neal Norwitz: help(pyexpat) causes an exception: Traceback (most recent call last): File "", line 1, in File "/home/neal/python/dev/py3k/Lib/site.py", line 350, in __call__ return pydoc.help(*args, **kwds) File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 1685, in __call__ self.help(request) File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 1729, in help else: doc(request, 'Help on %s:') File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 1512, in doc pager(render_doc(thing, title, forceload)) File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 1490, in render_doc return title % desc + '\n\n' + text.document(object, name) File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 319, in document if inspect.ismodule(object): return self.docmodule(*args) File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 1076, in docmodule contents.append(self.document(value, key, name)) File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 320, in document if inspect.isclass(object): return self.docclass(*args) File "/home/neal/python/dev/py3k/Lib/pydoc.py", line 1126, in docclass mro = deque(inspect.getmro(object)) TypeError: 'NoneType' object is not iterable -- components: Library (Lib) messages: 55289 nosy: nnorwitz severity: normal status: open title: pydoc doesn't work on pyexpat versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1020> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1022] use bytes for code objects
New submission from Neal Norwitz: This patch has a hack to read in marshaled code objects. Bytes can't be marshaled currently (they are stored as strings). So when reading a marshaled code object, the hack converts them to bytes. All tests except test_modulefinder pass. The issue is that since bytes are mutable, they aren't suitable for code objects since a user could change them at any time. -- components: Interpreter Core files: code-bytes.patch messages: 55290 nosy: nnorwitz severity: normal status: open title: use bytes for code objects versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1022> __ code-bytes.patch Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1025] tracebacks from list comps (probably other comps) don't show full stack
New submission from Neal Norwitz: A traceback that occurs within a list comprehension (and probably all comprehensions) only shows the stack from the comprehension, not the entire scope: Traceback (most recent call last): File "Lib/test/test_multibytecodec_support.py", line 35, in test_chunkcoding for f in self.tstring]): File "Lib/test/test_multibytecodec_support.py", line 35, in for f in self.tstring]): UnicodeDecodeError: 'utf8' codec can't decode byte 0xa6 in position 0: unexpected code byte -- components: Interpreter Core keywords: py3k messages: 55303 nosy: nnorwitz severity: normal status: open title: tracebacks from list comps (probably other comps) don't show full stack versions: Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1025> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1031] py3k: compilation with VC2005
Neal Norwitz added the comment: Thanks for the patch. I tried to apply this patch, but almost everything failed. Could you make sure to do a svn update and then generate the patch? The only part of the patch that applied cleanly was to rmpyc.py. That was checked in as: Committed revision 57527. -- nosy: +nnorwitz __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1031> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1030] py3k: Adapt _winreg.c to the new buffer API
New submission from Neal Norwitz: Thanks! I can't test this, but I applied the change. It makes sense to me. Committed revision 57528. -- assignee: -> nnorwitz nosy: +nnorwitz resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1030> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1031] py3k: compilation with VC2005
Neal Norwitz added the comment: Hmmm, the patch was out of date (I had already removed cPickle). However, I don't think that was the reason for everything failing. I manually applied the changes to the files and python version. Things should be pretty good now. I didn't add the libraries. I'm not sure why they are needed now while they weren't necessary before. Committed revision 57529. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1031> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1031] py3k: compilation with VC2005
Neal Norwitz added the comment: I thought it might be line endings so I tried changing them, but that didn't help. I couldn't apply the new version of the patch either. I'm not sure if the problem is on your side or mine. :-( I missed some files from the original checkin. The new one hopefully has all the files and is just missing the libraries. Can you svn update and look at the new differences? Thanks. Committed revision 57530. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1031> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1028] Tkinter binding involving Control-spacebar raises unicode error
Neal Norwitz added the comment: I can confirm the problem and that your patch fixes the problem. Go ahead and check it in. Thanks! -- assignee: nnorwitz -> kbk nosy: +nnorwitz resolution: -> accepted __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1028> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1031] py3k: compilation with VC2005
Neal Norwitz added the comment: Awesome! I'm going to close this patch. Let me know if you have any more problems. Feel free to send messages to python-3000. I would like py3k to build on Windows for the alpha which will be coming out in about a week hopefully. -- assignee: -> nnorwitz resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1031> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1266] segfault in curses when calling redrawwin() before refresh()
Neal Norwitz added the comment:
What platform are you on? I can reproduce this with 2.5.1+ and trunk on
Ubuntu. I can reproduce with a trivial C program that does the same
thing. This could be a bug in the curses implementation. Or it could
be misuse of the API. I don't know enough to suggest which is the case.
The C program is:
#include
int main(int argc, char**argv) {
WINDOW *win = initscr();
WINDOW *win2 = newwin(50, 50, 50, 50);
redrawwin(win2);
return 0;
}
Perhaps a bug should be filed against curses.
--
components: +Extension Modules -Library (Lib)
nosy: +nnorwitz
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1266>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1233] bsddb.dbshelve.DbShelf.append doesn't work
Neal Norwitz added the comment: Gregory, could you take a look at this? -- assignee: -> gregory.p.smith components: +Extension Modules -Library (Lib) nosy: +gregory.p.smith, nnorwitz __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1233> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1216] Python2.5.1 fails to compile under VC.NET2002 ( 7.0 )
Neal Norwitz added the comment: Martin, it looks like you made some changes in rev 46064. Can you suggest anything? -- assignee: -> loewis components: +Extension Modules nosy: +loewis, nnorwitz __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1216> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1631171] implement warnings module in C
Neal Norwitz added the comment: I think this is good enough for now. The approach will probably stand even if the details change. Go for it! _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1631171> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1631171] implement warnings module in C
Changes by Neal Norwitz: -- assignee: nnorwitz -> brett.cannon _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1631171> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1307] smtpd.SMTPServer throws exception on MAIL command with no arg
Neal Norwitz added the comment: It would be great to get this into 2.5.2. -- assignee: nnorwitz -> gvanrossum __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1307> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1307] smtpd.SMTPServer throws exception on MAIL command with no arg
Neal Norwitz added the comment: Thanks for the patch. Committed revision 58599. (2.5) -- status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1307> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1313] Typo in Python Library Reference documentation: logging module
Neal Norwitz added the comment: Thanks for the report. Committed revision 58600. (2.5) Committed revision 58601. 3.0 will be fixed when we merge. -- assignee: -> nnorwitz nosy: +nnorwitz resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1313> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1307] smtpd.SMTPServer throws exception on MAIL command with no arg
Neal Norwitz added the comment: Committed revision 58625. (2.5) -- status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1307> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1329] Different 3.0a1 exit behavior
Neal Norwitz added the comment: Thanks for testing 3.0. Do you have any idea why they are no longer called? I don't recall any changes related to this area. Can you try to debug further? -- nosy: +nnorwitz __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1329> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1329] Different 3.0a1 exit behavior
Neal Norwitz added the comment: Maybe that's because site and io get cleaned up and then there is some fatal error that can't be printed? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1329> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1329] Different 3.0a1 exit behavior
Neal Norwitz added the comment: I suggest you configure --with-pydebug. That will disable optimization, enable debugging symbols and will make it easier to develop. Note that a debug version runs much slower due to asserts() and other internal changes. Otherwise, it should work the same. On Oct 26, 2007 4:55 PM, Jean Brouwers <[EMAIL PROTECTED]> wrote: > > Jean Brouwers added the comment: > > This is quite bizarre and difficult to reproduce. With gdb, 3.0a1 does > get to the very end of Py_Finalize, but without gdb it doesn't. > > Also, the call to static function call_all_exitfuncs is inlined, its > while loop is shown inside Py_Finalize on MacOS X. On Linux that is not > visible, probably due to differences in gcc/gdb, 4.0.1 or MacOS X and > 3.4.6 on Linux. > > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1329> > __ > __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1329> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1329] Different 3.0a1 exit behavior
Neal Norwitz added the comment:
When I run with the attached patch, I see the message:
*** dtor called in python ...
Is that the behavior you expect?
Added file: http://bugs.python.org/file8626/stdout-close.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1329>
__Index: Python/pythonrun.c
===
--- Python/pythonrun.c (revision 58681)
+++ Python/pythonrun.c (working copy)
@@ -725,7 +725,8 @@
}
PySys_SetObject("__stdin__", std);
PySys_SetObject("stdin", std);
- Py_DECREF(std);
+ /* Purposefully lose a ref to stdin so it is never closed. */
+ /* Py_DECREF(std); */
/* Set sys.stdout */
if (!(std = PyFile_FromFd(fileno(stdout), "", "w", -1,
@@ -734,7 +735,8 @@
}
PySys_SetObject("__stdout__", std);
PySys_SetObject("stdout", std);
- Py_DECREF(std);
+ /* Purposefully lose a ref to stdout so it is never closed. */
+ /* Py_DECREF(std); */
/* Set sys.stderr */
if (!(std = PyFile_FromFd(fileno(stderr), "", "w", -1,
@@ -743,7 +745,8 @@
}
PySys_SetObject("__stderr__", std);
PySys_SetObject("stderr", std);
- Py_DECREF(std);
+ /* Purposefully lose a ref to stderr so it is never closed. */
+ /* Py_DECREF(std); */
if (0) {
error:
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1631171] implement warnings module in C
Neal Norwitz added the comment: I think Brett summarized the issues well. I can't think of anything else that seems to need doing. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1631171> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1358] Compile error on OS X 10.5
Neal Norwitz added the comment: I don't have access to a 10.5 machine. My guess is that the difference is between configure not setting _XOPEN_SOURCE and/or _XOPEN_SOURCE_EXTENDED and it being set in pyconfig.h. At least those are both defined on 10.4. This page talks about needing to include unistd.h, but doesn't give enough info: http://developer.apple.com/documentation/Darwin/Reference/Manpages/man2/setpgid.2.html Hopefully someone else with access to 10.5 can confirm if this is the case and we can resolve this. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1358> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1574217] isinstance swallows exceptions
Neal Norwitz added the comment: Yeah, this seems like a bug and the patch seems correct. The patch also needs a test and add a space between if (. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1574217> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1490190] add os.chflags() and os.lchflags() where available
Neal Norwitz added the comment: Martin's patch from 2007-03-21 fixed the problem with test_posix. It now passes all the tests (test_posix and rest of test suite). The tests/interpreter do not exit prematurely. I think it is good to apply this patch. -- assignee: nnorwitz -> loewis _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1490190> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1346] Error using >>> from OpenGL.GLUT import *
Neal Norwitz added the comment: As gagenellina said, this problem appears to be with OpenGL, not python. OpenGL is not maintained here. You'll have to open a bug report with them. -- nosy: +nnorwitz resolution: -> rejected status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1346> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1705170] contextmanager eats StopIteration
Neal Norwitz added the comment: Nick, can you backport this and add a NEWS entry? Thanks. -- nosy: +nnorwitz _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1705170> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10399] AST Optimization: inlining of function calls
Neal Norwitz added the comment:
There is some precedent for allowing minor differences in -O mode.
http://mail.python.org/pipermail/python-dev/2008-February/077193.html
I think we should push this to see how practical we can make it.
Dave, this is great work, I'm really interested to see you continue to
make progress and get something integrated. Keep up the good work.
On Sat, Nov 20, 2010 at 1:11 PM, Dave Malcolm wrote:
>
> Dave Malcolm added the comment:
>
> Thanks for reading through this.
>
>> There are a couple places you mention not doing the optimization when
>> specific functions are used (e.g. dir, globals, locals), how exactly do you
>> verify that, given those functions could be bound to any name?
>
> I don't: I'm only looking at explicit references to these global names:
> BUILTINS_THAT_READ_LOCALS = {'locals', 'vars', 'dir'}
>
> but I haven't attempted to track these at the object level, just at the name
> level.
>
> This means that if someone is passing these around bound to a different name,
> the results could be "wrong": the optimizations that I'm doing are
> synthesizing new local and global variables (in each case with a '__'
> prefix), and sometimes eliminating local variables.
>
> However, it should work as expected for the simple and common case for code
> like this:
>
> def foo():
> ...
> pprint(locals())
> ...
>
> since the reference to "locals" can be seen at the name level.
>
> But it won't work for something like this:
>
> def inlined_fn(a):
> print(a())
>
> def not_inlinable_for_some_reason(b):
> inlined_fn(b) # assume this callsite is inlined
>
> def some_other_fn_perhaps_in_another_module():
> hidden_ref_to_locals = locals
> not_inlinable_for_some_reason(hidden_ref_to_locals)
>
> in that (if inlining happens) the local printed will be named "b", rather
> than "a".
>
> But this seems to me like a contrived example: how often in real code do
> people pass around these builtins, rather than calling them directly? I
> myself use them for debugging, but I only ever call them directly.
>
> At a high level, what I'm interested in is providing additional benefits for
> python 3 relative to python 2 (to encourage migration), and I picked
> speed-ups.
>
> I think it's reasonable to provide some kind of "optimized" mode that is
> allowed to take (limited) liberties with the language.
>
> Note that with other languages, people seem to accept some mild degradation
> of debuggability in return for compiler optimizations. I'd like to be able
> to provide a faster python under similar kinds of tradeoffs.
>
> Currently, Python's optimized mode doesn't seem to do much (just compile away
> assertions iirc). Perhaps these optimizations could be associated with the
> pre-existing optimizer flag; alternatively, perhaps a 3rd level could be
> provided?
>
> This seems like a PEP-level request, but here's an outline of my thoughts
> here:
>
> I'd like the highly-optimized mode to be permitted the following::
> - to create additional synthesized globals, with a "__" prefix; modification
> of these globals to lead to undefined behavior.
> - when querying locals under some circumstances (see below) for locals to
> not be present, or for additional locals to be present::
> - when using "inspect" and reading/modifying a Frame's f_locals
> - in "non-direct" invocations of "locals", "globals" and "dir" (however,
> when called directly by name, they must work)
> - as per globals, synthesized locals to have a prefix, and modification
> to lead to undefined behavior
> - a pony :)
> - more seriously, I'm planning to look next at inlining method calls (within
> one module), and type inference, and I may come up with additional
> requirements.
>
> I believe that the above covers all of the places where my patch is taking
> liberties with existing Python semantics (modulo bugs): I'm still supporting
> runtime rebinding of other names, and (I believe), preserving existing
> behavior. (please let me know if I'm missing something here!)
>
> There seems to be some precedent for this:
> http://docs.python.org/library/functions.html states:
>> Note Because dir() is supplied primarily as a convenience for use at an
>> interactive prompt, it tries to supply an interesting set of names more
>> than it tries to supply a rigorously or consistently defined set of names,
>> and its detailed behav
[issue1574217] isinstance swallows exceptions
Neal Norwitz <[EMAIL PROTECTED]> added the comment: > I'd like to clarify the approach to fixing these types of problems. > ... > However, I like constricting it to AttributeError only as that would > make it much less confusing. This might be something to bring up on > python-dev. I suspect that it might be on a case by case basis whether we want to constrain more or less. Bringing these cases up on python-dev should lead to speedy decisions. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1574217> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2620] Multiple buffer overflows in unicode processing
Neal Norwitz <[EMAIL PROTECTED]> added the comment: Committed revision 65261 for 2.5 Committed revision 65262 for 2.4. -- status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2620> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3627] apple security patches need to be forward ported to py3k
New submission from Neal Norwitz <[EMAIL PROTECTED]>: The trunk revision was 65335. -- components: Interpreter Core messages: 71608 nosy: nnorwitz priority: release blocker severity: normal status: open title: apple security patches need to be forward ported to py3k versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3627> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3656] unicode encoding has lots of leaks of bytes
New submission from Neal Norwitz <[EMAIL PROTECTED]>: Some of these leaks reported by valgrind are likely duplicates. I don't know how many individual cases of these leaks there are. 11,119 bytes in 14 blocks are possibly lost in loss record 86 of 119 realloc (vg_replace_malloc.c:429) _PyBytes_Resize (bytesobject.c:3159) multibytecodec_encode (multibytecodec.c:536) MultibyteCodec_Encode (multibytecodec.c:588) PyObject_Call (abstract.c:2181) PyEval_CallObjectWithKeywords (ceval.c:3283) PyCodec_Encode (codecs.c:354) PyUnicodeUCS2_AsEncodedString (unicodeobject.c:1347) unicode_encode (unicodeobject.c:6682) PyEval_EvalFrameEx (ceval.c:3403) PyEval_EvalFrameEx (ceval.c:3491) PyEval_EvalCodeEx (ceval.c:2840) 11,882 bytes in 15 blocks are possibly lost in loss record 87 of 119 malloc (vg_replace_malloc.c:207) PyBytes_FromStringAndSize (bytesobject.c:87) PyUnicodeUCS2_EncodeUTF8 (unicodeobject.c:2250) utf_8_encode (_codecsmodule.c:719) PyEval_EvalFrameEx (ceval.c:3403) PyEval_EvalFrameEx (ceval.c:3491) PyEval_EvalFrameEx (ceval.c:3491) PyEval_EvalCodeEx (ceval.c:2840) function_call (funcobject.c:628) PyObject_Call (abstract.c:2181) PyEval_EvalFrameEx (ceval.c:3704) PyEval_EvalCodeEx (ceval.c:2840) 271,937 bytes in 437 blocks are definitely lost in loss record 108 of 119 malloc (vg_replace_malloc.c:207) PyBytes_FromStringAndSize (bytesobject.c:87) PyEval_EvalFrameEx (ceval.c:3403) PyEval_EvalCodeEx (ceval.c:2840) PyEval_EvalFrameEx (ceval.c:3501) PyEval_EvalFrameEx (ceval.c:3491) PyEval_EvalCodeEx (ceval.c:2840) function_call (funcobject.c:628) PyObject_Call (abstract.c:2181) PyEval_EvalFrameEx (ceval.c:3704) PyEval_EvalCodeEx (ceval.c:2840) function_call (funcobject.c:628) 331,647 bytes in 277 blocks are definitely lost in loss record 111 of 119 realloc (vg_replace_malloc.c:429) _PyBytes_Resize (bytesobject.c:3159) PyUnicodeUCS2_EncodeUTF8 (unicodeobject.c:2256) _PyUnicodeUCS2_AsDefaultEncodedString (unicodeobject.c:1412) source_as_string (bltinmodule.c:504) builtin_exec (bltinmodule.c:788) PyEval_EvalFrameEx (ceval.c:3403) PyEval_EvalCodeEx (ceval.c:2840) PyEval_EvalFrameEx (ceval.c:3501) PyEval_EvalCodeEx (ceval.c:2840) PyEval_EvalCode (ceval.c:519) builtin_exec (bltinmodule.c:785) 274,686 bytes in 446 blocks are definitely lost in loss record 114 of 128 malloc (vg_replace_malloc.c:207) PyBytes_FromStringAndSize (bytesobject.c:87) PyEval_EvalFrameEx (ceval.c:3403) PyEval_EvalCodeEx (ceval.c:2840) PyEval_EvalFrameEx (ceval.c:3501) PyEval_EvalFrameEx (ceval.c:3491) PyEval_EvalCodeEx (ceval.c:2840) function_call (funcobject.c:628) PyObject_Call (abstract.c:2181) PyEval_EvalFrameEx (ceval.c:3704) PyEval_EvalCodeEx (ceval.c:2840) function_call (funcobject.c:628) 734,178 bytes in 293 blocks are definitely lost in loss record 121 of realloc (vg_replace_malloc.c:429) _PyBytes_Resize (bytesobject.c:3159) PyUnicodeUCS2_EncodeUTF8 (unicodeobject.c:2256) _PyUnicodeUCS2_AsDefaultEncodedString (unicodeobject.c:1412) source_as_string (bltinmodule.c:504) builtin_exec (bltinmodule.c:788) PyEval_EvalFrameEx (ceval.c:3403) PyEval_EvalCodeEx (ceval.c:2840) PyEval_EvalFrameEx (ceval.c:3501) PyEval_EvalCodeEx (ceval.c:2840) PyEval_EvalCode (ceval.c:519) builtin_exec (bltinmodule.c:785) -- components: Interpreter Core messages: 71825 nosy: nnorwitz priority: release blocker severity: normal status: open title: unicode encoding has lots of leaks of bytes type: resource usage versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3656> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3656] unicode encoding has lots of leaks of bytes
Neal Norwitz <[EMAIL PROTECTED]> added the comment:
There are also tons of reference leaks when running regrtest.py with -R.
Even code as simple as this leaks:
>>> eval('1')
1
[40731 refs]
>>> eval('1')
1
[40732 refs]
>>> eval('1')
1
[40733 refs]
>>> eval('1')
1
[40734 refs]
>>> eval('1')
1
[40735 refs]
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3656>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3651] eval() leaks 1 reference every time
Neal Norwitz <[EMAIL PROTECTED]> added the comment: This is a partial (or complete) duplicate of 3656. -- nosy: +nnorwitz ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3651> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3656] unicode encoding has lots of leaks of bytes
Neal Norwitz <[EMAIL PROTECTED]> added the comment: This is a partial (or complete) duplicate of 3651. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3656> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3657] pickle can pickle the wrong function
New submission from Neal Norwitz <[EMAIL PROTECTED]>: test_pickletools fails sporadically on at least two platforms I've seen. http://www.python.org/dev/buildbot/all/x86%20gentoo%20trunk/builds/4120/step-test/0 http://www.python.org/dev/buildbot/all/ppc%20Debian%20unstable%20trunk/builds/1908/step-test/0 File "/home/buildslave/python-trunk/trunk.norwitz-x86/build/Lib/pickletools.py", line ?, in pickletools.__test__.disassembler_test Failed example: dis(pickle.dumps(random.random, 0)) Expected: 0: cGLOBAL 'random random' 15: pPUT0 18: .STOP highest protocol among opcodes = 0 Got: 0: cGLOBAL 'bsddb.test.test_thread random' 31: pPUT0 34: .STOP highest protocol among opcodes = 0 ** 1 items had failures: 1 of 25 in pickletools.__test__.disassembler_test -- components: Interpreter Core messages: 71830 nosy: nnorwitz priority: release blocker severity: normal status: open title: pickle can pickle the wrong function versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3657> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3627] apple security patches need to be forward ported to py3k
Neal Norwitz <[EMAIL PROTECTED]> added the comment: Committed revision 66009. -- assignee: -> nnorwitz resolution: -> fixed status: open -> closed type: -> security ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3627> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3651] eval() leaks 1 reference every time
Neal Norwitz <[EMAIL PROTECTED]> added the comment: Even with the patch, there are still tons of leaks. I don't know if it's due to the same problem or not. So far there is: test_unittest leaked [124, 124] references, sum=248 test_array leaked [110, 110] references, sum=220 test_audioop leaked [75, 75] references, sum=150 test_binascii leaked [4, 4] references, sum=8 There are probably more. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3651> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2744] Fix test_cProfile
Changes by Neal Norwitz <[EMAIL PROTECTED]>: -- priority: critical -> release blocker ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2744> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3660] reference leaks in 3.0
New submission from Neal Norwitz <[EMAIL PROTECTED]>: Even after adding the current patch in http://bugs.python.org/issue3651 there are many reference leaks. This bug can be a placeholder for all the reference leaks returned from: ./python ./Lib/test/regrtest.py -R 3:2 -uall,-bsddb The current list is: test_unittest leaked [124, 124] references, sum=248 test_array leaked [110, 110] references, sum=220 test_audioop leaked [75, 75] references, sum=150 test_binascii leaked [4, 4] references, sum=8 test_binhex leaked [4, 4] references, sum=8 test_codecs leaked [3, 3] references, sum=6 test_ctypes leaked [9, 9] references, sum=18 test_dbm leaked [194, 194] references, sum=388 test_dbm_gnu leaked [2, 2] references, sum=4 test_fcntl leaked [2, 2] references, sum=4 test_file leaked [8, 8] references, sum=16 test_fileio leaked [1, 1] references, sum=2 test_memoryio leaked [3, 3] references, sum=6 test_minidom leaked [5, 5] references, sum=10 test_mmap leaked [307, 307] references, sum=614 test_ossaudiodev leaked [2, 2] references, sum=4 test_pickle leaked [130, 130] references, sum=260 test_pickletools leaked [503, 503] references, sum=1006 test_pyexpat leaked [1, 1] references, sum=2 test_re leaked [4, 4] references, sum=8 test_site leaked [88, 88] references, sum=176 test_socket leaked [13, 13] references, sum=26 test_sqlite leaked [17, 17] references, sum=34 test_ssl leaked [82, 82] references, sum=164 test_struct leaked [5, 5] references, sum=10 test_unicode leaked [2, 2] references, sum=4 test_urllib2_localnet leaked [3, 3] references, sum=6 test_xmlrpc leaked [18, 18] references, sum=36 test_xmlrpc_net leaked [1, 1] references, sum=2 test_zlib leaked [10, 10] references, sum=20 -- components: Interpreter Core messages: 71851 nosy: nnorwitz priority: release blocker severity: normal status: open title: reference leaks in 3.0 versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3660> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3610] Fix gdbinit for Python 3.0
Neal Norwitz <[EMAIL PROTECTED]> added the comment: I fixed some problems in r66016. This patch seems like it has other things which might be useful, so I'll keep it open until it's handled. -- nosy: +nnorwitz ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3651] eval() leaks 1 reference every time
Neal Norwitz <[EMAIL PROTECTED]> added the comment: Another PyBuffer_Release(&pin); looks necessary at @@ -805,6 +807,7 @@. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3651> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3304] invalid call to PyMem_Free() in fileio_init()
Neal Norwitz <[EMAIL PROTECTED]> added the comment: In 3.0 the free is necessary, though see http://bugs.python.org/issue3662 . -- nosy: +nnorwitz status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3304> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3662] _fileio._FileIO segfaults
Neal Norwitz <[EMAIL PROTECTED]> added the comment: Daniel, thanks for running the fuzzer! It would be great if you could keep running it and find any more problems before releasing 2.6 and 3.0. I agree with Benjamin and Amaury. PyArg_ParseTupleAndKeywords() shouldn't update the pointer if it failed. Given the test, it's unlikely for this to create a problem in the future. Either as a crash or as a memory leak. Committed revision 66018. (2.6) Committed revision 66019. (3.0) -- assignee: -> nnorwitz components: +Interpreter Core nosy: +nnorwitz resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3662> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1375] hotshot IndexError when loading stats
Changes by Neal Norwitz <[EMAIL PROTECTED]>: -- type: crash -> behavior ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1375> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2456] Make sysmodule.c compatible with Bazaar
Changes by Neal Norwitz <[EMAIL PROTECTED]>: -- type: crash -> feature request ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2456> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1210] imaplib does not run under Python 3
Neal Norwitz <[EMAIL PROTECTED]> added the comment: Is this still a problem? -- nosy: +nnorwitz type: crash -> behavior ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1210> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1658] "RuntimeError: dictionary changed size during iteration" in Tkinter
Changes by Neal Norwitz <[EMAIL PROTECTED]>: -- type: crash -> behavior ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1658> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1840] Tools/i18n/msgfmt.py fixes for Python 3.0
Neal Norwitz <[EMAIL PROTECTED]> added the comment: Is this still a problem? -- nosy: +nnorwitz type: crash -> behavior ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1840> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2747] Documentation of new gobject types fails
Changes by Neal Norwitz <[EMAIL PROTECTED]>: -- type: crash -> behavior ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2747> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2562] Cannot use non-ascii letters in disutils if setuptools is used.
Changes by Neal Norwitz <[EMAIL PROTECTED]>: -- type: crash -> behavior ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2562> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1838] Ctypes C-level infinite recursion
Changes by Neal Norwitz <[EMAIL PROTECTED]>: -- assignee: -> theller components: +ctypes -Extension Modules nosy: +theller ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1838> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3657] pickle can pickle the wrong function
Neal Norwitz <[EMAIL PROTECTED]> added the comment: The valgrind errors below are possibly related. Conditional jump or move depends on uninitialised value(s) PyUnicodeUCS2_EncodeUTF8 (unicodeobject.c:2216) _PyUnicode_AsString (unicodeobject.c:1417) save (_pickle.c:930) Pickler_dump (_pickle.c:2292) Conditional jump or move depends on uninitialised value(s) PyUnicodeUCS2_EncodeUTF8 (unicodeobject.c:2220) _PyUnicode_AsString (unicodeobject.c:1417) save (_pickle.c:930) Pickler_dump (_pickle.c:2292) Conditional jump or move depends on uninitialised value(s) PyUnicodeUCS2_EncodeUTF8 (unicodeobject.c:2227) _PyUnicode_AsString (unicodeobject.c:1417) save (_pickle.c:930) Pickler_dump (_pickle.c:2292) Conditional jump or move depends on uninitialised value(s) PyUnicodeUCS2_EncodeUTF8 (unicodeobject.c:2229) _PyUnicode_AsString (unicodeobject.c:1417) save (_pickle.c:930) Pickler_dump (_pickle.c:2292) Conditional jump or move depends on uninitialised value(s) PyUnicodeUCS2_EncodeUTF8 (unicodeobject.c:2233) _PyUnicode_AsString (unicodeobject.c:1417) save (_pickle.c:930) Pickler_dump (_pickle.c:2292) ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3657> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3651] eval() leaks 1 reference every time
Neal Norwitz <[EMAIL PROTECTED]> added the comment: With the latest patch (and the one addition PyBuffer_Release() I noted above), valgrind is happy wrt memory leaks. The only problem valgrind found is a read of uninitialized memory. See http://bugs.python.org/issue3657 . I don't know the buffer code to know if this is the correct fix. However, it fixes the problems and that's probably good enough for now. If you can get someone familiar with the buffer code to review, that would be great. If not, this patch should be applied. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3651> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3651] eval() leaks 1 reference every time
Neal Norwitz <[EMAIL PROTECTED]> added the comment: Also there should be a Misc/NEWS entry added. Also check the doc to see it needs updating wrt ownership. -- type: -> resource usage ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3651> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3657] pickle can pickle the wrong function
Neal Norwitz <[EMAIL PROTECTED]> added the comment: Indeed. The problem was an incorrect conversion of str -> unicode, instead of converting to bytes. On getting the buffer from unicode, it tried to read data which was uninitialized. Hmmm, this fix is for 3.0 only, but the problem is happening in 2.6. Leaving open. Committed revision 66021. -- assignee: -> nnorwitz ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3657> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3673] bsddb module leaks memory
New submission from Neal Norwitz <[EMAIL PROTECTED]>: The attached patch against 2.6 fixes the memory leaks reported against the bsddb module. There are still (probably) reference leaks. Jesus, it would be great if you can look at this before the release. -- assignee: jcea components: Extension Modules files: bsddb.patch keywords: patch, patch messages: 71907 nosy: jcea, nnorwitz priority: critical severity: normal status: open title: bsddb module leaks memory type: resource usage versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file11238/bsddb.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3673> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3657] pickle can pickle the wrong function
Neal Norwitz <[EMAIL PROTECTED]> added the comment: It seems that if the tests are run in this order: ./python -E -tt ./Lib/test/regrtest.py -u all test_xmlrpc test_ctypes test_json test_bsddb3 test_pickletools The error will trigger consistently. That is in 2.6 with a debug build on a dual cpu box. A debug build of 3.0 on the same machine did not fail though I don't know if 3.0 has this problem. I was unable to prune the list further. The 3 tests (xmlrpc, ctypes and json) can be run in any order prior to bsdb3 and then pickletools. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3657> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1210] imaplib does not run under Python 3
Neal Norwitz <[EMAIL PROTECTED]> added the comment: This may not be a real release blocker, but I want to raise the priority. It is a regression and we should try to fix it, especially if it's easy. -- priority: normal -> release blocker ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1210> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3660] reference leaks in 3.0
Neal Norwitz <[EMAIL PROTECTED]> added the comment: The only one that is probably an issue based on Antoine's info is: test_unicode leaked [1, 1] references, sum=2 I've seen test_urllib2_localnet leak 3 before. I don't know that it's a real leak. I'm pretty sure it is not a regression though. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3660> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32
Neal Norwitz added the comment: Thanks for taking care of this guys. Sorry, I got swamped with mail and had to archive 3,000+ messages. It looks like it's in good hands. Let me know if there's anything you need. I may not have access to the box anymore, however, I can always contact Kurt. -- ___ Python tracker <http://bugs.python.org/issue4970> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1617] Rare exception in test_urllib2net
Neal Norwitz added the comment: This may happen every time on the MIPS buildbot. Here is a recent run. http://www.python.org/dev/buildbot/all/MIPS%20Debian%20trunk/builds/190/step-test/0 My guess is that there is some exception happening in C code and that propagates back up to the error we see. I could never find the root cause when I tried to trace I down though. -- nosy: +nnorwitz __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1617> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1303614] Bypassing __dict__ readonlyness
Changes by Neal Norwitz: -- nosy: +nnorwitz _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1303614> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1303614] Bypassing __dict__ readonlyness
Neal Norwitz added the comment: I looked at Guido's latest deldict.diff patch--the one to Objects/object.c only. It seems good. I can't convince myself either way about the change to Objects/typeobject.c. I can't think of a way to cause a problem. It seems safer to use Py_CLEAR in this case though. There are several other uses of _PyObject_GetDictPtr in Objects/typeobject.c. It was pretty much the same--I can't convince myself either way. Can Py_VISIT cause any Python code to execute that might lead to a problem? The other uses of _PyObject_GetDictPtr in Objects/typeobject.c seemed safer. Not a very useful review. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1303614> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1617] Rare exception in test_urllib2net
Neal Norwitz added the comment: This started happening consistently on my box and I was able to reproduce it. Revision 60233 should fix this problem. I forwarded the checkin to Greg. Hopefully he can comment if there is a problem. (Also cc'd him on this bug report that I'm now closing.) -- assignee: -> nnorwitz nosy: +gregory.p.smith resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1617> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1621] Do not assume signed integer overflow behavior
Changes by Neal Norwitz: -- nosy: +nnorwitz __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1621> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1621] Do not assume signed integer overflow behavior
Neal Norwitz added the comment: I'm just starting to look at the patch. The first one changes i to unsigned in Modules/_csv.c. Hopefully most of them are like this. The code is fine as it is. There is no reliance on overflow AFAICT. It's just that the breaking condition from the loop is not in the for (...). I think this change is fine to avoid a warning. Just pointing out that in this one case, it's not a real problem. Change to heapq doesn't seem needed. I looked at the warning generated from this and it's if (!n). This seems to indicate the compiler thinks that n could be negative. That should not be possible. It came from PyList_GET_SIZE. We had verified the object was already a list. So this value should be between 0 and PY_SSIZE_T_MAX. We check for 0, so it might be > 0. After decrementing n, it should be between 0 and PY_SSIZE_T_MAX-1. Of course, the compiler can't know the value can't be negative (or PY_SSIZE_T_MIN) which would cause an underflow. Change to hotshot should avoid a cast, so it's slightly better with this approach. Although with the change to size_t, the cast in flush_data can be removed (just after the fwrite). I don't see the reason to need for the change in sre.c, but I'm pretty sure there are other overflows. audioop definitely looks needed. cPickle looks necessary. expat/xmlparse.c is interesting--not sure if it's really necessary. In practice this probably can't be reached. gc can't really overflow given that NUM_GENERATIONS is 3 and not likely to grow much more. :-) I stopped looking at this point. It looks like some of these are really needed. Others are not possible given other invariants (the compiler can't know about). I like the idea of silencing compiler warnings. However, I fear this may generate a different problem. Namely signed/unsigned mismatches. What happens if you add this warning: -Wsign-compare I think we got rid of most of those before (probably not true as much for Modules/*.c). I think this introduces many more. Would it be possible to come up with a patch that doesn't introduce more warnings w/-Wsign-compare? One potential issue with this patch is that while the additions might have guaranteed semantics, we might have other problems when doing: size_t value = PyXXX_Size(); if (value < 0) ... I'm hoping that if we can use both -Wstrict-overflow and -Wsign-conversion, eliminate all warnings, resulting in better code. (You could also try building with g++. The core used to work without warnings. The modules still had a ways to go.) Also what is the current state? What has been implemented and what else needs to be done? Perhaps we should make other bug report(s) to address other tangents that were discussed in this thread. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1621> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1621] Do not assume signed integer overflow behavior
Neal Norwitz added the comment:
I just added -Wstrict-overflow to the code in sysmodule.c
(sys_getframe) and tried with gcc 4.2.1. It doesn't warn. I wonder
if 4.3 is more picky or warns when it shouldn't?
Unless if I changed the code so it doesn't work:
typedef struct {int ref;} PyObject;
typedef struct { PyObject* f_back; } PyFrameObject;
int PyArg_ParseTuple(PyObject*, const char*, int*);
PyObject *
sys_getframe(PyFrameObject *f, PyObject *self, PyObject *args)
{
int depth = -1;
if (!PyArg_ParseTuple(args, "|i:_getframe", &depth))
return 0;
while (depth > 0 && f != 0) {
f = (PyFrameObject*)f->f_back;
--depth;
}
return (PyObject*)f;
}
Compiled with:
gcc-4.2.1-glibc-2.3.2/x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu-gcc
-Wstrict-overflow -c xx.c
produced no warnings. This is not a stock gcc 4.2.1, so that could
also be an issue. Did I run it correctly. Is there anything else I
need to do? If you run the code above with gcc 4.3, does it produce a
warning?
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1621>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1621] Do not assume signed integer overflow behavior
Neal Norwitz added the comment: On Jan 27, 2008 6:45 PM, Ismail Donmez <[EMAIL PROTECTED]> wrote: > > Can you try with -Wstrict-overflow=3 , but yes I am using gcc 4.3 trunk. I just tried with =1, =2, =3, and no =. All the same result: no warning. Ismail, thanks for going through all this effort. It's very helpful. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1621> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1953] Compact int and float freelists
Neal Norwitz added the comment: I think sys is appropriate for clearing the cache. Lib/test/regrtest.py still has a reference to gc rather than sys. Why do the CompactFreeList APIs return an int that is always 0? Seems like they should return a real value or be void. I'm not sure why you changed the functions to keep a block_list_length. I doubt this API would be requested very often. Seems like it would be better to just calculate when necessary (or perhaps not even add the APIs). The only issue I have with the patch is the casting in the printf calls. These can lose information. On Win64, long is 32-bits, but size_t is 64-bits. See PY_FORMAT_SIZE_T in Include/pyport.h for how to handle this. -- assignee: nnorwitz -> tiran resolution: -> accepted __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1953> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1750076] Python 2.5+ skips while statements in debuggers
Neal Norwitz added the comment: I was hoping you could get rid of my entire hack. I didn't (still don't) completely understand the intention of the code, so can't really offer any more advice. IMO, the patch is an improvement so you should check it in. -- assignee: nnorwitz -> amaury.forgeotdarc resolution: -> accepted _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1750076> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2147] int operations no longer overflow
New submission from Neal Norwitz: Georg, I hope you don't mind me assigning this to you. Feel free to unassign. A colleague pointed me to section 5.7 in the old ref doc: http://docs.python.org/ref/shifting.html It says that shifting operations lose data on overflow. This info is outdated based on PEP 237. I suspect there may be other inaccuracies related to int overflow. So the purpose of this bug is to point out the specific problem as well as to log that we need to find all invalid references to overflow. -- assignee: georg.brandl components: Documentation messages: 62586 nosy: georg.brandl, nnorwitz severity: normal status: open title: int operations no longer overflow versions: Python 2.5, Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2147> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2181] optimize out local variables at end of function
New submission from Neal Norwitz: This patch optimizes code like: x = any_expression return x to: return any_expression Currently it only optimizes out the local variable if there is a return because it can't determine if this is the last use of the variable or not. This shouldn't change behaviour under normal circumstances, but would change behaviour with a debugger. Perhaps this optimization should only be performed if -O is passed on the command line? This optimization saves two trips around the eval loop (STORE_FAST and LOAD_FAST) and 6 bytes in the byte code. -- components: Interpreter Core files: opt-out-local-var.patch keywords: patch, patch messages: 62957 nosy: nnorwitz severity: normal status: open title: optimize out local variables at end of function type: resource usage Added file: http://bugs.python.org/file9544/opt-out-local-var.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2181> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2181] optimize out local variables at end of function
Neal Norwitz added the comment: I forgot to mention that if another loop was added to PyCode_Optimize that kept track of the # of times each local variable was LOAD_FAST/STORE_FAST/DELETE_FAST and that the count was 2, we could perform a similar optimization without requiring the return. Bonus points for other cases like if it was the last use inside a list comprehension or the variable is otherwise unaccessible. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2181> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2183] optimize list comprehensions
New submission from Neal Norwitz: Optimize list comprehensions by using the list on the stack, rather than storing in a (local/global) variable. This reduces the size of the stack by one pointer, reduces the bytecode size by 8, and reduces the iterations in the eval loop by 2 + # of iterations to create the new list. It also eliminates internal variables in varnames. List comps in module/class scope execute faster by avoiding more costly dict lookups in globals. For this source code: def f(): return [x for x in s] Byte code before change: 1 0 BUILD_LIST 0 3 DUP_TOP 4 STORE_FAST 0 (_[1]) 7 LOAD_GLOBAL 1 (s) 10 GET_ITER >> 11 FOR_ITER13 (to 27) 14 STORE_FAST 1 (x) 17 LOAD_FAST0 (_[1]) 20 LOAD_FAST1 (x) 23 LIST_APPEND 24 JUMP_ABSOLUTE 11 >> 27 DELETE_FAST 0 (_[1]) 30 RETURN_VALUE New byte code: 1 0 BUILD_LIST 0 3 LOAD_GLOBAL 0 (s) 6 GET_ITER >>7 FOR_ITER12 (to 22) 10 STORE_FAST 0 (x) 13 LOAD_FAST0 (x) 16 LIST_APPEND 2 19 JUMP_ABSOLUTE7 >> 22 RETURN_VALUE DUP_TOP/STORE_FAST are eliminated before the loop. One LOAD_FAST is eliminated inside the loop. LIST_APPEND is changed to reference the value on the stack. Is it a problem to change the opcode of LIST_APPEND? This might make debugging harder. I'm not sure how debuggers work with list comps. A similar optimization could probably be done to eliminate all uses of the temporary variables (WITH_CLEANUP at least). This patch still needs to update docs and the compiler package implemented in Python. -- components: Interpreter Core files: list-comp-opt2.patch keywords: patch, patch messages: 62961 nosy: nnorwitz severity: normal status: open title: optimize list comprehensions type: resource usage versions: Python 2.6 Added file: http://bugs.python.org/file9545/list-comp-opt2.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2183> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2181] optimize out local variables at end of function
Neal Norwitz added the comment: I forgot to mention that if another loop was added to PyCode_Optimize that kept track of the # of times each local variable was LOAD_FAST/STORE_FAST/DELETE_FAST and that the count was 2, we could perform a similar optimization without requiring the return. Bonus points for other cases like if it was the last use inside a list comprehension or the variable is otherwise unaccessible. -- versions: +Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2181> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1394] simple patch, improving unreachable bytecode removing
Neal Norwitz added the comment: It would be great to see test cases with this change. That would help answer Alexander's question too. -- nosy: +nnorwitz __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1394> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2185] code objects should conserve memory
New submission from Neal Norwitz: Various bits are often duplicated in code objects. For example, sometimes names and varnames are equal. In this case, we don't need two objects since they are both const. This patch implements a trivial fix for this case. However, there are more cases. We should profile where the memory is being used and do simple/cheap consolidations where possible. Another example would be a 1-element tuple containing: (None,) for consts. Some (all?) of these sorts of optimizations should probably be done in the code object itself. -- files: marshal-mem.patch keywords: patch, patch messages: 62965 nosy: nnorwitz severity: normal status: open title: code objects should conserve memory type: resource usage versions: Python 2.6 Added file: http://bugs.python.org/file9547/marshal-mem.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2185> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2181] optimize out local variables at end of function
Neal Norwitz added the comment: Guido says to do it only with -O. http://mail.python.org/pipermail/python-dev/2008-February/077193.html __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2181> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1691070] Speed up PyArg_ParseTupleAndKeywords() and improve error msg
Neal Norwitz added the comment: Christian, Could you clean this patch up? Specifically: * Put everything into one patch * Eliminate unnecessary changes (changing variable name or whitespace) * Conform to the style in the file * Verify all the tests run with regrtest.py -u all when built --without-pydebug * Verify it runs faster _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1691070> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1518] Fast globals/builtins access (patch)
Neal Norwitz added the comment:
I've gone over this at a high-level and looked for various outstanding
issues. Below are my comments. I didn't delve into this in detail.
There are a lot of questions too.
I think this is very interesting and hope that we can get it working,
100% robust, and verify the improved perf.
In Include/fastglobals.h, num_entries says it is len(names). But
there is also an entries field. This is confusing. The name should
be num_names if it is the length of names.
isbuiltin is an array of integers that hold boolean values? So most
of the memory is wasted? How many entries do you expect in isbuiltin?
This field should probably be packed using each bit. Its type should then
be unsigned. If there were a small number of PyFastGlobalsObjects it
wouldn't be a big deal. But from the comment it seems there will be
one of these objects for each function.
Did you measure the difference in memory size? For example the size
at startup with and without the patch. Did you measure the startup
time? How big is python at the end of a regression test run with and
without this patch?
Is there ever an access to the old globals in the old code? I wonder
if it's worthwhile to change the names in ceval.c, etc.
Does PyFastGlobals_GET_ITEM_INPLACE really need to be a macro? It's a
pain to debug macros. If it were a static function in the header
file, it would almost definitely get inlined.
PyFastGlobals_ENTRY(op, index) should be captured in a local variable.
I'm thinking that entryversion should be unsigned. Signed integer
overflow is not defined (we had some problems recently with this).
PyFastGlobals_VERSION_SET(op) can overflow.
I like the removal of one pointer from the frame object.
How does this interact with multiple interpreters? I see the static
of __builtins__ in fastglobal.c. See PyInterpreterState in
Include/pystate.h. (I see that __builtins__ is a string, so this
access should be fine, but the question is still valid. I just want
to make sure there aren't any bad interactions.)
Regarding:
/* XXX A clever adversary could prevent this from terminating */
How about the loop is limited to 10 runs or something reasonable?
That way there cannot be a DoS attack. You can raise a RuntimeError
if the max iterations is reached.
Since PyFastGlobals_Update() is public, you should not assert that the
op is a fast globals, but rather check and set
PyErr_BadInternalCall(). That's true of all public APIs. Internal
APIs are fine to have asserts.
In fg_check_builtins() you may be able to speed this up by checking
the most common paths first. I know this code is taken from
frameobject. See
http://coverage.livinglogic.de/Objects/frameobject.c.html . Hmmm,
that isn't showing any data currently. I'll ping Walter and ask him
if he can get that working again.
I don't understand this comment in PyFastGlobals_CheckBuiltins:
/* Make sure fg->builtins_entry is updated first */
It says what the code does, but I don't understand *why* it does it.
Instead of:
PyErr_NoMemory();
Py_DECREF(newnames);
return NULL;
You can do:
Py_DECREF(newnames);
return PyErr_NoMemory();
In PyFastGlobals_New(), you should verify that num_entries doesn't
overflow before creating a new tuple by increasing the size by 1.
In this code:
isbuiltin = PyMem_NEW(int, num_entries);
if (isbuiltin == NULL) {
PyErr_NoMemory();
Py_DECREF(newnames);
PyMem_FREE(isbuiltin);
return NULL;
}
The free of isbuiltin should be entries.
If these arrays will be small (< 256 bytes), it would be better (faster)
to use
pymalloc rather than the PyMem interface.
PyDict_GetEntry should be prefixed with an underscore. I don't think
this should become part of the public API. How about passing an int
pointer to GetEntry that will be set if the key is found or clear if not
found?
This needs to be addressed:
+ /* This is a bad idea now: if gc breaks a cycle by clearing
+ f_fastglobals, when a generator is finally collected it does this
+ sequence of calls: gen_del->gen_close->gen_send_ex->
+ PyEval_EvalFrameEx. But PyEval_EvalFrameEx references
+ f_fastglobals->globals, which will be cleared by then, resuling
+ in a segfault.
+ ??? Is there a way to preserve this traversal? */
+ /* Py_VISIT(f->f_fastglobals); */
--
nosy: +nnorwitz
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1518>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2168] gdbm needs to be iterable
Neal Norwitz added the comment: Thomas, thanks for fixing this. I didn't see any specific problems with the patch, but I'm wondering why the code doesn't just call has_key in both cases? -- nosy: +nnorwitz __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2168> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1691070] Speed up PyArg_ParseTupleAndKeywords() and improve error msg
Neal Norwitz added the comment:
I looked over the new patch Christian uploaded and I think I understand
what's going on. I didn't do a through comparison, but if all the tests
pass, I think that's good enough. Good work!
Here are the issues I would like to see fixed before check in (all small
and easy):
* Fix the format nits. There were missing spaces around = and ==.
* Remove the comment that says:
+* XXX TypeError doesn't seem right for this,
+* maybe create an ArgumentError ???
+* XXX Arg positions currently reported as
+* 1-based, contrary to most things in
+* python ???
The first line of that comment should stay.
* Expand the comment that says: Maybe skip this in debug build ?
Add a XXX or TODO and explain why. I think it's just that it would
give extra testing. I'm not sure it's worth it since that would be
added code, but it's a valid question.
* Verify that it's faster by compiling python in a release build (ie,
optimized, not debug with assertions) and do something that would
trivially execute the code. For example:
* ''.split()
* ''.split('', 1)
* (1,).index(1)
* (1,).index(1, 0, 1)
That might be a decent set. I just grepped for PyArg_ParseTuple
Objects/*.c and found some common cases where this code would be used.
It would be great to add the timing info from the test cases above (as
well as the pybench results) to the check in message.
* In the test do a single import at the top of the file.
* Use raise Error('') instead of raise Error, '' in the test. Actually
instead of raising an exception, call self.fail(error_message)
--
resolution: -> accepted
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1691070>
_
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1691070] Speed up PyArg_ParseTupleAndKeywords() and improve error msg
Changes by Neal Norwitz: -- assignee: nnorwitz -> tiran _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1691070> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1394] simple patch, improving unreachable bytecode removing
Neal Norwitz added the comment: Can you add more tests? It seems that almost all the examples given in this thread are good examples. Also something like: while 1: if cond: return 1 return 2 return 3 There are a bunch more cases that could be added for where the code should be optimized or might be optimized wrong that. The #if 0 code should be removed in the patch. Also, since CONTINUE_LOOP is removed in this patch, it would be good to explicitly add a test for that. This patch looks good to me, but I'll let Raymond decide. Did all the entire test suite run? Note, you must remove all the .pyc files to test this patch or change the MAGIC number in Python/import.c. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1394> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1691070] Speed up PyArg_ParseTupleAndKeywords() and improve error msg
Neal Norwitz added the comment: On Tue, Feb 26, 2008 at 12:51 AM, Christian Heimes <[EMAIL PROTECTED]> wrote: > > > * Verify that it's faster by compiling python in a release build > > It's roughly the same speed. :/ The variation between timeit runs is > quite high on my machine. The new code is neither significant faster nor > noticeable slower. Use your best judgment. I haven't looked at the resulting code, only the patch so it's hard for me to know for certain. It appears the patch simplifies the code, so even if there is no speed benefit, there may be a maintainability benefit. It's up to you. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1691070> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2181] optimize out local variables at end of function
Neal Norwitz added the comment: > I suppose you are aware that performing this optimization in general > would break a lot of existing code that uses inspect.getstack() or > sys._getframe() to peek at the caller's local variables. I know this Yes, with this optimization the variable might never be set or when the function exits, the value would be set to the previous value. Note that the current optimization only works just before a return and only for local variables. It doesn't generally optimize out variables, although that would be a good next step. > because it's one thing that Psyco doesn't do correctly, and one of the > most common causes I'm aware of for a random existing program to break > under Psyco. How often does this cause problems? Do you view this as psyco's problem or broken user code? I don't view this any different that a C compiler optimizing out variables. It can make debugging harder since the symbols no longer exist. In this case the variable name is not removed from the co_varnames even if it is the only reference. That would also be nice, but left for another patch. Since this will only be used with -O and is currently limited, this seems reasonable to me. But I would like to know if others disagree. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2181> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx
Neal Norwitz <[EMAIL PROTECTED]> added the comment: I bet with just a little more work, you could get rid of t and stream. t is only used for a single set of opcodes (STORE_SLICE+n). stream is only used for the PRINT opcodes. The code in print could be moved to a function which might allow the compiler to do a better job. I'll benchmark this later on amd64 and amd x86 linux boxes. Maybe mac ppc g4 if I'm adventurous. :-) -- nosy: +nnorwitz __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2262> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx
Neal Norwitz <[EMAIL PROTECTED]> added the comment: Can't next_instr and stack_pointer move inside the for loop too? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2262> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2291] Catching all exceptions with 'object'
Neal Norwitz <[EMAIL PROTECTED]> added the comment: See PEP 352. Currently this is slated for python 2.8. Perhaps the schedule should be sped up a bit in light the current release schedule. Brett, any comments? We should add all the warnings from PEP 352 with the -3 flag to 2.6. -- nosy: +brett.cannon, nnorwitz versions: +Python 2.6 -Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2291> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2185] code objects should conserve memory
Neal Norwitz <[EMAIL PROTECTED]> added the comment: Marshal is the wrong place for this sort of thing (the code object is where it should be done). I botched the analysis. The case is common, but only for the empty tuple which I forgot to ignore. (None,) was a common case when I measured it. We should measure the actual memory savings before anything is implemented. To answer your question, the case were this happens is: def foo(self): return self.self -- resolution: -> rejected status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2185> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2321] return more memory from unicode objects to system
New submission from Neal Norwitz <[EMAIL PROTECTED]>: This patch returns more memory to the system when doing: >>> x = [unicode(i) for i in xrange(100)] >>> del x If the above code is done, the memory before and after is quite different. After this patch, the memory of the process as reported by the system (like top/ps) should be approximately the same -- components: Interpreter Core files: uni.diff keywords: patch, patch messages: 63654 nosy: nnorwitz severity: normal status: open title: return more memory from unicode objects to system type: resource usage versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file9689/uni.diff __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2321> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2321] return more memory from unicode objects to system
Neal Norwitz <[EMAIL PROTECTED]> added the comment: On Mon, Mar 17, 2008 at 11:55 AM, Alec Thomas <[EMAIL PROTECTED]> wrote: > > Alec Thomas <[EMAIL PROTECTED]> added the comment: > > Hi Neal, > > This seems to be a more general problem than just unicode. Kinda, sorta. The general issue is the pattern of memory allocation/deallocation. In the case of >>> x = [(1, 2, 3, 4, i) for i in xrange(80)] The memory that is not returned is in the integer free list. If this code is changed to: >>> for x in ((1, 2, 3, 4, i) for i in xrange(80)): pass That doesn't hold on to any extra memory. The problem is that holes are left in memory and a lot of it can't always be returned to the O/S. It can still be re-used by python. > Both exhibit the same behaviour. Naively to me it seems like using the > custom allocator uniformly would fix this problem. In general, we should find places (like unicode) that use PyMem_* (ie, system malloc) and replace them with PyObject_* (pymalloc). That should improve the behaviour, but there will always be some allocation patterns that will be suboptimal. Note that using pymalloc will only help for objects < 256 bytes. Larger objects are delegated to the system malloc and will still exhibit some of the bad problems. Alec, can you find places that are using the PyMem_* interface and create a patch to fix them. That would be great! __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2321> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2375] PYTHON3PATH environment variable to supersede PYTHONPATH for multi-Python environments
Changes by Neal Norwitz <[EMAIL PROTECTED]>: -- assignee: -> nnorwitz nosy: +nnorwitz priority: -> urgent __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2375> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2321] return more memory from unicode objects to system
Neal Norwitz <[EMAIL PROTECTED]> added the comment: After discussing this with MvL, I'll check this patch into trunk and 2.5. Alec, if you find other issues, please create a new patch. Committed revision 61458. Committed revision 61485. (2.5) __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2321> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2321] return more memory from unicode objects to system
Changes by Neal Norwitz <[EMAIL PROTECTED]>: -- assignee: -> nnorwitz resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2321> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2321] return more memory from unicode objects to system
Changes by Neal Norwitz <[EMAIL PROTECTED]>: __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2321> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2332] Renaming of attributes on functions need to be backported.
Neal Norwitz <[EMAIL PROTECTED]> added the comment: Committed revision 61492. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2332> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2400] from .foo import * should work
New submission from Neal Norwitz <[EMAIL PROTECTED]>: Explicit relative imports using from .foo import * should work. http://mail.python.org/pipermail/python-3000/2008-March/012564.html -- components: Interpreter Core messages: 63942 nosy: nnorwitz priority: critical severity: normal status: open title: from .foo import * should work versions: Python 2.6 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2400> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
