[issue1517] lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool

Christian Heimes added the comment: Two questions: * Which versions of Python are vulnerable to the problem? You forgot to fill in the version list. * How do we fix the problem? Is it enough to incref the key or must startkey be protected, too? -- nosy: +tiran

[issue1518] Fast globals/builtins access (patch)

Christian Heimes added the comment: When I run the code of test_gc.py test_function() in a shell I'm getting the expected result of 2 collected items: gc: collectable dict 0xb78aa13c gc: collectable function 0xb78a9374 However the same code embedded in the test suite collects two additional

[issue1519] async_chat.__init__() parameters

New submission from Nadeem Vawda: The __init__() function for asynchat.async_chat doesn't allow the caller to specify a channel map. I thought it would make sense to add an optional 'map' parameter, for consistency with asyncore.dispatcher. If the parameter is not specified,

[issue1520] 'without make' documentation build anomaly

New submission from Joseph Armbruster: When I run the following from a windows command line, the resulting html can not be browsed stand-alone: python tools/sphinx-build.py -bhtml . build/htmlwin It looks like the paths are getting hosed up; for example: htmlcygwin/c-api/index.html contains:

[issue1521] string.decode() fails on long strings

New submission from Andreas Eisele: s.decode(utf-8) sometimes silently truncates the result if s has more than 2E9 Bytes, sometimes raises a fairly incomprehensible exception: Traceback (most recent call last): File stdin, line 2, in module File /usr/lib64/python2.5/encodings/utf_8.py,

[issue1518] Fast globals/builtins access (patch)

Chris Mellon added the comment: In funcobject.c:PyFunction_New, the declarations of op and __name__ need to be moved to the top of the function to compile in MSVC, and if accepted the fastglobals.c file needs to be added to PCBuild. In the test script, the use of import * generates syntax

[issue1521] string.decode() fails on long strings

Walter Dörwald added the comment: Can you attach a (small) example that demonstrates the bug? -- nosy: +doerwalter __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1521 __

[issue1521] string.decode() fails on long strings

Andreas Eisele added the comment: For instance: Python 2.5.1 (r251:54863, Aug 30 2007, 16:15:51) [GCC 4.1.0 (SUSE Linux)] on linux2 Type help, copyright, credits or license for more information. __[1] s= *int(5E9) 6.05 sec __[1] u=s.decode(utf-8) 4.71 sec __[1] len(u) 705032704

[issue1521] string.decode() fails on long strings

Andreas Eisele added the comment: An instance of the other problem: Python 2.5.1 (r251:54863, Aug 30 2007, 16:15:51) [GCC 4.1.0 (SUSE Linux)] on linux2 Type help, copyright, credits or license for more information. __[1] s= *int(25E8) 2.99 sec __[1] u=s.decode(utf-8) Traceback (most

[issue1522] pyvm module patch

New submission from Christian Heimes: I've created a pyvm module for Python 3.0. So far it just contains a bunch of internal types. What methods do you like to add to pyvm? Somebody suggested internal functions from sys like the check internal. -- components: Extension Modules,

[issue1521] string.decode() fails on long strings

Amaury Forgeot d'Arc added the comment: I don't have any 64bit machine to test with, but it seems to me that there is a problem in the function getargs.c::convertsimple(): the t# and w# formats use the buffer interface, but the code uses an int to store its length! Look for the variables

[issue1523] xdrlib fails to detect overflow (struct bug?)

New submission from Jack Lloyd: The XDR format requires integers to fit into 4 byte values. However (at least on x86-64) xdrlib will silently accept (and truncate) values larger than this (up to 2**64-1). Taking a (very brief) look at the xdrlib code, it appears this is actually a problem in the

[issue1522] pyvm module patch

Guido van Rossum added the comment: Hm... What if we just put these names in sys? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1522 __ ___ Python-bugs-list mailing list

[issue1518] Fast globals/builtins access (patch)

Chris Mellon added the comment: I may have had some old code in the build or something - I did a clean rebuild to look at some of the slowdowns and the fastglobals_test benchmarks are now even better than Neils. Pybench is still overall slower but it's mostly in float operations, which seems odd

[issue1517] lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool

Guido van Rossum added the comment: I can reproduce the segfault in 2.2 through 2.4; in 2.5 and 2.6 the output is this instead: Test 1, using __eq__(a, b).__nonzero__() this is never the right answer * Test 2, using tuple's tp_richcompare New Watch 0xf7f8cbac New Watch 0xf7f8cc0c Deleting

[issue1517] lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool

Guido van Rossum added the comment: Oops, the same code appeared twice. The new fix fixes both places. Added file: http://bugs.python.org/file8827/fix1517.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1517

[issue1517] lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool

Changes by Guido van Rossum: Removed file: http://bugs.python.org/file8826/fix1517.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1517 __ ___ Python-bugs-list mailing list

[issue1517] lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool

Christian Heimes added the comment: Guido van Rossum wrote: The key that needs to be INCREF'ed is actually startkey. Patch attached. What about the second PyObject_RichCompareBool(startkey, key, Py_EQ) a few lines below inside the for loop? Christian __

[issue1517] lookdict should INCREF/DECREF startkey around PyObject_RichCompareBool

Guido van Rossum added the comment: Committed revision 59222 (2.5.2). Committed revision 59223 (2.6). Thanks rhamporyncus and jorendorff!! -- keywords: +patch resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED]

[issue1506] func alloca inside ctypes lib needs #include alloca.h on solaris

Thomas Heller added the comment: Greg Couch added the comment: Turns out callproc.c forgot to include ffi_common.h after ffi.h which conditionally includes alloca.h. So it's a one-line fix. This would not work. ffi_common.h is a file private to libffi; when Python is configured to use

[issue1522] pyvm module patch

Christian Heimes added the comment: I don't see it as an option. I'd rather keep the types in the 'types' module than to add them to the sys module. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1522 __

[issue1522] pyvm module patch

Georg Brandl added the comment: If there's a new pyvm module, there are a few things in sys that should be moved there, I expect. -- nosy: +georg.brandl __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1522 __

[issue1522] pyvm module patch

Guido van Rossum added the comment: I don't see it as an option. I'd rather keep the types in the 'types' module than to add them to the sys module. Why such a strong opinion? 'sys' is pretty close to the VM too... __ Tracker [EMAIL PROTECTED]

[issue1506] func alloca inside ctypes lib needs #include alloca.h on solaris

Greg Couch added the comment: That's a disappointment. ffi_common.h has the right logic in it already. Perhaps it should be copied to callproc.c. I'm less concerned about alloca not being there at all because it seems to be a pervasive extension in non-gcc compilers, but using malloc is fine

[issue1516] make _ctypes work with non-gcc compilers

Greg Couch added the comment: The modications work on Tru64 and IRIX. cc has understood .s suffixes for a long time. You use cc instead of as because it knows how to run the C preprocessor (often /lib/cpp, but not on all systems). Looking at the Solaris cc manual page (via google), I see that

[issue1524] os.system() fails for commands with multiple quoted file names

New submission from Guy Mott: Given a call to os.system() with a command string like this: os.system('TheCommand MyOutput') # fails then the call fails with the following error message on the console: 'TheCommand MyOutput' is not recognized as an internal or external command,

[issue1522] pyvm module patch

Christian Heimes added the comment: Why such a strong opinion? 'sys' is pretty close to the VM too... sys is a very important and often used module, too. I don't like the idea to remove one module (types) and clutter an important module with its content. The list of types has grown pretty

[issue1522] pyvm module patch

Guido van Rossum added the comment: sys is a very important and often used module, too. I don't like the idea to remove one module (types) and clutter an important module with its content. Well, it is already pretty cluttered -- it contains many items that *I* don't recognize... :-) The

[issue1522] pyvm module patch

Brett Cannon added the comment: There has been talk in the past of cleaning up the sys module by splitting it up into a package, although I don't know how that would work for a built-in module, though. -- nosy: +brett.cannon __ Tracker [EMAIL PROTECTED]

[issue1522] pyvm module patch

Christian Heimes added the comment: Guido van Rossum wrote: Stuff in sys that people don't use doesn't really confuse anyone IMO. I really don't think that this warrants a new module. Many of the datatype-related types (e.g. dict_keys) should not go there but in _collections anyway. I

[issue1522] pyvm module patch

Christian Heimes added the comment: I've split the patch into two tasks. The first patch adds all types in Objects/ to the appropriate header files. I've renamed some types, too. The second patch contains the new pyvm.c module plus a modification to Modules/Setup.dist. Added file:

[issue1522] pyvm module patch

Christian Heimes added the comment: I like to apply the py3k_add_types_to_h.patch before the next alpha and discuss the fate of pyvm after the alpha. Added file: http://bugs.python.org/file8831/py3k_pyvm3.patch __ Tracker [EMAIL PROTECTED]

[issue1522] pyvm module patch

Changes by Christian Heimes: Removed file: http://bugs.python.org/file8824/py3k_pyvm.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1522 __ ___ Python-bugs-list mailing

[issue1522] pyvm module patch

Changes by Christian Heimes: Removed file: http://bugs.python.org/file8829/py3k_pyvm2.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1522 __ ___ Python-bugs-list mailing

[issue1518] Fast globals/builtins access (patch)

Changes by Guido van Rossum: -- keywords: +patch nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1518 __ ___ Python-bugs-list mailing list

[issue1522] pyvm module patch

Guido van Rossum added the comment: I like to apply the py3k_add_types_to_h.patch before the next alpha and discuss the fate of pyvm after the alpha. Sure, go ahead and submit the uncontroversial part. __ Tracker [EMAIL PROTECTED]

[issue1524] os.system() fails for commands with multiple quoted file names

Christian Heimes added the comment: I don't think that we can do anything about your problem. The user of os.system() is responsible to do the quoting himself. os.system() is just a tiny wrapper around the low level C function. We don't plan to chance the fact that os.system() doesn't handling

[issue1522] pyvm module patch

Christian Heimes added the comment: Guido van Rossum wrote: Sure, go ahead and submit the uncontroversial part. Applied py3k_add_types_to_h.patch in r59229 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1522 __

[issue1521] string.decode() fails on long strings

Amaury Forgeot d'Arc added the comment: Here is a patch, with a unit test (I was surprised that test_bigmem.py already contained a test_decode function, which was left empty). But I still don't have access to any 64bit machine. Can someone try and see if the new tests in test_bigmem.py fail,

[issue1518] Fast globals/builtins access (patch)

Neil Toronto added the comment: Christian: Thanks for that, I'll have to remember DEBUG_LEAK in the future. :) It looks like it may be acting correctly since there *is* now a fastglobals object that needs collecting, and also a new tuple built from co_names + __builtins__. I don't know why it

[issue1402] Interpreter cleanup: order of _PyGILState_Fini and PyInterpreterState_Clear

Amaury Forgeot d'Arc added the comment: Committed revision 59231 in trunk. -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1402 __

[issue1524] os.system() fails for commands with multiple quoted file names

Georg Brandl added the comment: Are you sure that the exact command line works in a Windows shell? Python does no processing on the string, it just hands it to the platform system() function, so if MS decided that to work different from a command prompt there's nothing we can do about.

[issue1443504] locale.getpreferredencoding() dies when setlocale fails

Heikki Toivonen added the comment: We noticed this too in Chandler. We worked around this issue with the patch I am attaching. Maybe not a correct fix, though. -- nosy: +heikki versions: +Python 2.5 Added file: http://bugs.python.org/file8833/patches-2.5.1-Linux

[issue1524] os.system() fails for commands with multiple quoted file names

Guy Mott added the comment: Are you sure that the exact command line works in a Windows shell? Yes, I tried running the exact same command line in a Windows shell and it worked fine. Note that the buggy.py script echoes the command line and then immediately calls os.system with it. E.g.:

[issue1269] Exception in pstats print_callers()

Changes by Georg Brandl: -- assignee: - georg.brandl nosy: +georg.brandl __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1269 __ ___ Python-bugs-list mailing list

[issue1705362] cannot change cursor color in IDLE

Changes by Georg Brandl: -- resolution: - fixed status: open - closed superseder: - IDLE - cursor color configuration bug _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1705362 _

[issue1774369] Unify __builtins__ - __builtin__

Changes by Georg Brandl: -- superseder: - Rename __builtins__ to __root_namespace__? _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1774369 _ ___

[issue1631171] implement warnings module in C

Brett Cannon added the comment: I see two ways of implementing the fetching of a source code line from __loader__.get_source(). One is to do it in Python. We have a function provided that can suppress the second line of output from a warning and just handle it in Python code. That has the