[issue1164] tp_print slots don't release the GIL

Armin Rigo added the comment: We need to start from PyFile_WriteString() and PyFile_WriteObject() and PyObject_Print(), which are what the PRINT_* opcodes use, and make sure there is no single fprintf() or fputs() that occurs with the GIL held. It is not enough to fix a few places that could cle

[issue1165] Should itertools.count work for arbitrary integers?

New submission from Eduardo Padoan: Currently, itertools.count.__next__ checks wether the current value is > PY_SSIZE_T_MAX and raises OverflowError if so. Shouldn't the value be stored as "long", at least in Py3k? Not that I have any use case for it, so it is minor. -- components: Libra

[issue1165] Should itertools.count work for arbitrary integers?

Eric S. R-e-mond added the comment: Hi guys. -- assignee: -> esr nosy: +esr __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing

[issue1165] Should itertools.count work for arbitrary integers?

Changes by Eric S. R-e-mond: -- severity: minor -> critical __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe

[issue1165] Should itertools.count work for arbitrary integers?

Changes by Eric S. R-e-mond: -- keywords: +r-eyyy-mond __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue1165] Should itertools.count work for arbitrary integers?

Changes by Eric S. R-e-mond: -- versions: +3rd party, Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6 __ Tracker <[EMAIL PROTECTED]> _

[issue1165] Should itertools.count work for arbitrary integers?

Changes by Eric S. R-e-mond: -- type: behavior -> compile error __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubsc

[issue1165] Should itertools.count work for arbitrary integers?

Changes by Eric S. R-e-mond: -- dependencies: +--install-base not honored on win32 type: compile error -> behavior versions: -3rd party, Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6 ___

[issue1165] Should itertools.count work for arbitrary integers?

Changes by Eric S. R-e-mond: -- dependencies: + Elemental Security contribution - pgen2 package __ Tracker <[EMAIL PROTECTED]> __ ___ Python

[issue1166] NameError when calling malloc

New submission from Eric S. R-e-mond: I tried this code, and it blew up in my face. >>> foo = malloc(4096) NameError: name 'malloc' is not defined Why? -- components: Library (Lib) keywords: r-eyyy-mond messages: 55929 nosy: esr priority: high severity: normal status: open title: N

[issue1164] tp_print slots don't release the GIL

Guido van Rossum added the comment: Plese do submit a patch. FWIW I think it's solved in Py3k, the tp_print slot is dead (as is any use of the C stdio library). -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> __

[issue1164] tp_print slots don't release the GIL

Changes by Brett Cannon: -- versions: +Python 2.6 __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue1164] tp_print slots don't release the GIL

Brett Cannon added the comment: Since I already did this once I just did a more thorough job; patch is attached. PyObject_WriteString() just calls PyFile_WriteObject() which ends up using PyObject_Print(), so it is was simple to handle those cases. I then released the GIL for strings, lists, an

[issue1164] tp_print slots don't release the GIL

Changes by Brett Cannon: -- keywords: +patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue1134] Parsing a simple script eats all of your memory

Alexey Suda-Chen added the comment: --- tokenizer.c (revision 58161) +++ tokenizer.c (working copy) @@ -402,6 +402,8 @@ if (allocated) { Py_DECREF(bufobj); } + Py_XDECREF(tok->decoding_buffer); + tok->decoding_buffer = 0; return s; -- nosy: +alex

[issue1165] Should itertools.count work for arbitrary integers?

Changes by Martin v. Löwis: -- assignee: esr -> __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue1165] Should itertools.count work for arbitrary integers?

Changes by Martin v. Löwis: -- keywords: +patch -r-eyyy-mond __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe:

[issue1165] Should itertools.count work for arbitrary integers?

Changes by Martin v. Löwis: -- dependencies: - Elemental Security contribution - pgen2 package, --install-base not honored on win32 __ Tracker <[EMAIL PROTECTED]> __

[issue1165] Should itertools.count work for arbitrary integers?

Changes by Martin v. Löwis: -- keywords: +py3k -patch __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue1166] NameError when calling malloc

Martin v. Löwis added the comment: I doubt you are esr, although I'm uncertain how you hijacked his account. Please stop spamming this tracker. -- nosy: +loewis resolution: -> invalid status: open -> closed __ Tracker <[EMAIL PROTECTED]>

[issue1134] Parsing a simple script eats all of your memory

Brett Cannon added the comment: Note the patch is inlined in a message. -- keywords: +patch, py3k nosy: +brett.cannon __ Tracker <[EMAIL PROTECTED]> __

[issue1164] tp_print slots don't release the GIL

Guido van Rossum added the comment: Looks Good, except I think it's a bad idea to release/acquire the GIL for each character when writing the repr() of a string. Given that the string is immutable and its refcount kept alive by the caller I don't see a reason why you can't just reference the obj

[issue1165] Should itertools.count work for arbitrary integers?

Changes by Paul F. Dubois: __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/pyth

[issue1165] Should itertools.count work for arbitrary integers?

Changes by Paul F. Dubois: -- nosy: -esr __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue1164] tp_print slots don't release the GIL

Brett Cannon added the comment: Good point. I changed it on my machine and it cut that whole section down to a single release/acquire. I will go ahead and do this for the other types and then upload another patch to be reviewed when it's ready. __ Tracker <[EMAI

[issue1164] tp_print slots don't release the GIL

Brett Cannon added the comment: OK, every PyTypeObject in Objects and Modules has its tp_print release the GIL. Once someone OKs the patch I will apply it. __ Tracker <[EMAIL PROTECTED]> __ GIL_r

[issue1727780] 64/32-bit issue when unpickling random.Random

Changes by sligocki: -- versions: +Python 2.5 -Python 2.4 _ Tracker <[EMAIL PROTECTED]> _ ___ Python-bugs-list mailing list Unsubscr

[issue1727780] 64/32-bit issue when unpickling random.Random

sligocki added the comment: I've had this same problem with 2.5.1 Pickling random.getstate() on 64bit and then loading it back with random.setstate() on 32bit does not work (crashes because of trying cast 64bit ints to 32bit). The other way around is even worse. It loads but is in a faulty stat

[issue1167] gdbm/ndbm 1.8.1+ needs libgdbm_compat.so

New submission from Ian Kelly: The ndbm functions in gdbm 1.8.1+ require the gdbm_compat library in addition to gdbm. -- components: Build, Extension Modules files: gdbm_ndbm.diff messages: 55939 nosy: ikelly severity: normal status: open title: gdbm/ndbm 1.8.1+ needs libgdbm_compat.so t