[issue1255] Strange Python hangup
Jiri Krivanek added the comment: In the mena time, by intuition, I have resolved my troube exactly the way you recommend. Thanks to you, currently I also know what is he core of the problem. So the issue can be closed... __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1255 __ ___ 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
[issue1328] feature request: force BOM option
James G. sack (jim) added the comment: Feature Request REVISION Upon reflection and more playing around with some test cases, I wish to revise my feature request. I think the utf8 codecs should accept input with or without the sig. On output, only the utf_8_sig should write the 3-byte sig. This behavior change would not seem disruptive to current applications. For utf16, (arguably) a missing BOM should merely assume machian endianess. For utf_16_le, utf_16_be input, both should accept discard a BOM. On output, I'm not sure; maybe all should write a BOM unless passed a flag signifying no bom? Or to preserve backward compat, could have a parm write_bom defaulting to True for utf16 and False for utf_16_le and utf_16_be. This is a modification of the originial request (for a force_bom flag). Unless I have confused myself with my test cases, the current codecs are slightly inconsistent for the utf8 codecs: utf8 treats sig as real data, if present, but.. utf_8_sig works right even without the sig (so this one I like as is!) The 16'ers seem to match the (inferred) specs, but for completeness here: utf_16 refuses to proceed w/o BOM (even with correct endian input data) utf_16_le treats BOM as data utf_16_be treats BOM as data Regards, ..jim __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1328 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1328] feature request: force BOM option
James G. sack (jim) added the comment: Later note: kind of weird! On my LE machine, utf16 reads my BE-formatted test data (no BOM) apparently assumng some kind of surrogate format, until it finds an illegal UTF-16 surrogate. That I fail to understand, especially since it quits upon seeing a BOM with valid LE data. Test data and test code available on request. Regards, ..jim __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1328 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1089358] need siginterrupt() on Linux - impossible to do timeouts
Ralf Schmitt added the comment: PyOS_setsig in pythonrun.c now calls siginterrupt(sig, 1) (in Python 2.4.4/Python 2.5.1, but not in Python 2.3). So you should be able to timeout the system calls with a signal.alarm call. However, having siginterrupt available would still be useful. I have some patches for the signal module and will clean them up in some days and attach to this bug. Here's an implementation using ctypes: def siginterrupt(signum, flag): change restart behavior when a function is interrupted by the specified signal. see man siginterrupt. import ctypes import sys if flag: flag = 1 else: flag = 0 if sys.platform=='darwin': libc = ctypes.CDLL(libc.dylib) elif sys.platform=='linux2': libc = ctypes.CDLL(libc.so.6) else: libc = ctypes.CDLL(libc.so) if libc.siginterrupt(signum, flag)!=0: raise OSError(siginterrupt failed) -- nosy: +schmir _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1089358 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] platform.dist() has unpredictable result under Linux
Christian Heimes added the comment: Can you also use a global variable instead of /etc? Something like ETC_DIR = /etc for example. It would allow you to ship samples from several distribution and run unit tests against each. I've attached the two relevant files from Ubuntu 7.10 Gutsy. Added file: http://bugs.python.org/file8616/debian_version Added file: http://bugs.python.org/file8617/lsb-release __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1322 __lenny/sid DISTRIB_ID=Ubuntu DISTRIB_RELEASE=7.10 DISTRIB_CODENAME=gutsy DISTRIB_DESCRIPTION=Ubuntu 7.10 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] platform.dist() has unpredictable result under Linux
Yann Cointepas added the comment: I am writing a patch but I have a few questions: 1) There are at most three places where the distribution name can be found. What is the priority order to select only one name ? The three places are: a) Inside the /etc/lsb-release file b) In the name of the /etc/distrib-release file c) In the content of the /etc/distrib-release file For instance, on Mandriva 2007.1 the possible names are: a) 'MandrivaLinux' b) 'mandriva' c) 'Mandriva Linux' I would suggest to put a) first to be compatible with LSB but on most systems it would change the value returned by platform.dist after the patch (is it a problem ?). I would have liked to use c) as second choice but this space in the name set by Mandriva could be a problem (It's possible to suppress spaces in the result though). 2) Can I remove supported_dists parameter of platform.dist ? There could be a list of supported distributions but why as a parameter of this function ? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1322 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1335] bytesiterator patch
New submission from Christian Heimes:
Here is the long promised bytes iterator view. It was much, *much*
easier to write it than I have thought. In fact I spent more time fixing
the indention than to modify the code from striterator.
I haven't written an unit test for it. The other iterators don't have
extra tests, too.
iter(bytes(babc))
bytesiterator object at 0xb7cc578c
for i in iter(bytes(babc)): print(i)
...
97
98
99
for i in bytes(babc): print(i)
...
97
98
99
--
components: Interpreter Core
files: py3k_bytesiterator.patch
messages: 56789
nosy: gvanrossum, tiran
severity: normal
status: open
title: bytesiterator patch
type: rfe
versions: Python 3.0
Added file: http://bugs.python.org/file8619/py3k_bytesiterator.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1335
__Index: Objects/bytesobject.c
===
--- Objects/bytesobject.c (revision 58663)
+++ Objects/bytesobject.c (working copy)
@@ -3023,6 +3023,8 @@
\n\
If an argument is given it must be an iterable yielding ints in range(256).);
+static PyObject *bytes_iter(PyObject *seq);
+
PyTypeObject PyBytes_Type = {
PyVarObject_HEAD_INIT(PyType_Type, 0)
bytes,
@@ -3050,7 +3052,7 @@
0, /* tp_clear */
(richcmpfunc)bytes_richcompare, /* tp_richcompare */
0, /* tp_weaklistoffset */
-0, /* tp_iter */
+bytes_iter, /* tp_iter */
0, /* tp_iternext */
bytes_methods, /* tp_methods */
0, /* tp_members */
@@ -3065,3 +3067,121 @@
PyType_GenericNew, /* tp_new */
PyObject_Del, /* tp_free */
};
+
+/*** Bytes Iterator /
+
+typedef struct {
+PyObject_HEAD
+Py_ssize_t it_index;
+PyBytesObject *it_seq; /* Set to NULL when iterator is exhausted */
+} bytesiterobject;
+
+static void
+bytesiter_dealloc(bytesiterobject *it)
+{
+_PyObject_GC_UNTRACK(it);
+Py_XDECREF(it-it_seq);
+PyObject_GC_Del(it);
+}
+
+static int
+bytesiter_traverse(bytesiterobject *it, visitproc visit, void *arg)
+{
+Py_VISIT(it-it_seq);
+return 0;
+}
+
+static PyObject *
+bytesiter_next(bytesiterobject *it)
+{
+PyBytesObject *seq;
+PyObject *item;
+
+assert(it != NULL);
+seq = it-it_seq;
+if (seq == NULL)
+return NULL;
+assert(PyBytes_Check(seq));
+
+if (it-it_index PyBytes_GET_SIZE(seq)) {
+item = PyInt_FromLong(
+(unsigned char)seq-ob_bytes[it-it_index]);
+if (item != NULL)
+++it-it_index;
+return item;
+}
+
+Py_DECREF(seq);
+it-it_seq = NULL;
+return NULL;
+}
+
+static PyObject *
+bytesiter_len(bytesiterobject *it)
+{
+Py_ssize_t len = 0;
+if (it-it_seq)
+len = PyBytes_GET_SIZE(it-it_seq) - it-it_index;
+return PyInt_FromSsize_t(len);
+}
+
+PyDoc_STRVAR(length_hint_doc,
+Private method returning an estimate of len(list(it)).);
+
+static PyMethodDef bytesiter_methods[] = {
+{__length_hint__, (PyCFunction)bytesiter_len, METH_NOARGS,
+ length_hint_doc},
+{NULL, NULL} /* sentinel */
+};
+
+PyTypeObject PyBytesIter_Type = {
+PyVarObject_HEAD_INIT(PyType_Type, 0)
+bytesiterator, /* tp_name */
+sizeof(bytesiterobject), /* tp_basicsize */
+0, /* tp_itemsize */
+/* methods */
+(destructor)bytesiter_dealloc, /* tp_dealloc */
+0, /* tp_print */
+0, /* tp_getattr */
+0, /* tp_setattr */
+0, /* tp_compare */
+0, /* tp_repr */
+0, /* tp_as_number */
+0, /* tp_as_sequence */
+0, /* tp_as_mapping */
+0, /* tp_hash */
+0, /* tp_call */
+0, /* tp_str */
+PyObject_GenericGetAttr, /* tp_getattro */
+0, /* tp_setattro */
+0, /* tp_as_buffer */
+Py_TPFLAGS_DEFAULT | Py_TPFLAGS_HAVE_GC, /* tp_flags */
+0, /* tp_doc */
+(traverseproc)bytesiter_traverse, /* tp_traverse */
+0, /* tp_clear */
+0, /* tp_richcompare */
+0, /* tp_weaklistoffset */
+PyObject_SelfIter, /* tp_iter */
+(iternextfunc)bytesiter_next, /*
[issue1334] IDLE - Fix several highlighting bugs
New submission from Tal Einat: This patch fixes the following bugs: * Configured selection highlighting colors were ignored * Updating highlighting in the config dialog would cause non-Python files to be colored as if they were Python source Additionally, adding and removing of ColorDelegators to the Percolator was not being done in an organized fashion, causing multiple colorizers to be present simultaneously in certain cases. This patch ensures that there will always be at most one colorizer present in the Percolator. This patch also reduces code duplication by grouping colorization code into EditorWindow.ResetColorizer, and having __init__ let ResetColorizer do its thing. There is one side effect to this patch - applying a new highlighting scheme or renaming a file causes the screen to blink. This can be avoided without too much work, but IMHO is minor enough to leave as it is. -- components: IDLE files: IDLE_highlighting.071026.patch messages: 56788 nosy: kbk, taleinat severity: normal status: open title: IDLE - Fix several highlighting bugs versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file8618/IDLE_highlighting.071026.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1334 __ IDLE_highlighting.071026.patch Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1336] subprocess.Popen hangs when child writes to stderr
New submission from Jonathan Amsterdam: This is under Linux (2.6). I occasionally see subprocess.Popen() fail to return, and I have finally figured out roughly what's going on. It involves the GC and stderr. 1. os.fork() 2. Parent blocks reading from errpipe_read (subprocess.py:982) 3. In child, a GC occurs before the exec. 4. The GC attempts to free a file descriptor, calling file_dealloc. 5. That function gets an error closing the descriptor (close failed: [Errno 9] Bad file descriptor\n, is the string I extracted via gdb). 6. It attempts to write the error to stderr and blocks. Since it never execs or writes to errpipe_write, both child and parent are hung. Here is the pstack output on the child: #0 0x006587a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x0072f11b in __write_nocancel () from /lib/tls/libc.so.6 #2 0x006d409f in _IO_new_file_write () from /lib/tls/libc.so.6 #3 0x006d42ec in _IO_new_file_xsputn () from /lib/tls/libc.so.6 #4 0x006afce9 in buffered_vfprintf () from /lib/tls/libc.so.6 #5 0x006afe8b in vfprintf () from /lib/tls/libc.so.6 #6 0x080dd4af in mywrite () #7 0x080dd505 in PySys_WriteStderr () #8 0x08064cd0 in file_dealloc () #9 0x08079c88 in dict_dealloc () #10 0x0808931d in subtype_dealloc () #11 0x08079af3 in PyDict_Clear () #12 0x0807bb6a in dict_tp_clear () #13 0x080e0ead in collect () #14 0x080e1912 in _PyObject_GC_New () #15 0x0805e50b in PyInstance_NewRaw () #16 0x0805e5d7 in PyInstance_New () #17 0x0805bdc0 in PyObject_Call () #18 0x080aecef in PyEval_CallObjectWithKeywords () #19 0x080ca975 in PyErr_NormalizeException () #20 0x080b492c in PyEval_EvalFrame () #21 0x080b5eb2 in PyEval_EvalCodeEx () #22 0x080b3c83 in PyEval_EvalFrame () #23 0x080b5734 in PyEval_EvalFrame () #24 0x080b5eb2 in PyEval_EvalCodeEx () #25 0x080fce92 in function_call () #26 0x0805bdc0 in PyObject_Call () #27 0x080641e5 in instancemethod_call () #28 0x0805bdc0 in PyObject_Call () #29 0x0808ffce in slot_tp_init () #30 0x08088b3a in type_call () #31 0x0805bdc0 in PyObject_Call () #32 0x080b0f05 in PyEval_EvalFrame () #33 0x080b5eb2 in PyEval_EvalCodeEx () #34 0x080fce92 in function_call () #35 0x0805bdc0 in PyObject_Call () #36 0x080641e5 in instancemethod_call () #37 0x0805bdc0 in PyObject_Call () #38 0x0808ffce in slot_tp_init () #39 0x08088b3a in type_call () #40 0x0805bdc0 in PyObject_Call () #41 0x080b0f05 in PyEval_EvalFrame () #42 0x080b5734 in PyEval_EvalFrame () #43 0x080b5eb2 in PyEval_EvalCodeEx () #44 0x080fce92 in function_call () #45 0x0805bdc0 in PyObject_Call () #46 0x080641e5 in instancemethod_call () #47 0x0805bdc0 in PyObject_Call () #48 0x0808ffce in slot_tp_init () #49 0x08088b3a in type_call () #50 0x0805bdc0 in PyObject_Call () #51 0x080b0f05 in PyEval_EvalFrame () #52 0x080b5eb2 in PyEval_EvalCodeEx () #53 0x080fce92 in function_call () #54 0x0805bdc0 in PyObject_Call () #55 0x080b075f in PyEval_EvalFrame () #56 0x080b5734 in PyEval_EvalFrame () #57 0x080b5734 in PyEval_EvalFrame () #58 0x080b5734 in PyEval_EvalFrame () #59 0x080b5eb2 in PyEval_EvalCodeEx () #60 0x080b3c83 in PyEval_EvalFrame () #61 0x080b5734 in PyEval_EvalFrame () #62 0x080b5734 in PyEval_EvalFrame () #63 0x080b5eb2 in PyEval_EvalCodeEx () #64 0x080b3c83 in PyEval_EvalFrame () #65 0x080b5eb2 in PyEval_EvalCodeEx () #66 0x080b3c83 in PyEval_EvalFrame () #67 0x080b5eb2 in PyEval_EvalCodeEx () #68 0x080b3c83 in PyEval_EvalFrame () #69 0x080b5734 in PyEval_EvalFrame () #70 0x080b5734 in PyEval_EvalFrame () #71 0x080b5734 in PyEval_EvalFrame () #72 0x080b5734 in PyEval_EvalFrame () #73 0x080b5734 in PyEval_EvalFrame () #74 0x080b5eb2 in PyEval_EvalCodeEx () #75 0x080fce92 in function_call () #76 0x0805bdc0 in PyObject_Call () #77 0x080b075f in PyEval_EvalFrame () #78 0x080b5eb2 in PyEval_EvalCodeEx () #79 0x080b3c83 in PyEval_EvalFrame () #80 0x080b5eb2 in PyEval_EvalCodeEx () #81 0x080b3c83 in PyEval_EvalFrame () #82 0x080b5eb2 in PyEval_EvalCodeEx () #83 0x080b3c83 in PyEval_EvalFrame () #84 0x080b5734 in PyEval_EvalFrame () #85 0x080b5734 in PyEval_EvalFrame () #86 0x080b5eb2 in PyEval_EvalCodeEx () #87 0x080b601a in PyEval_EvalCode () #88 0x080d9ff4 in PyRun_FileExFlags () #89 0x080da8d6 in PyRun_SimpleFileExFlags () #90 0x08055617 in Py_Main () #91 0x08054e3f in main () -- components: Library (Lib) messages: 56790 nosy: jba severity: normal status: open title: subprocess.Popen hangs when child writes to stderr type: crash versions: Python 2.4 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1336 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1337] Tools/msi/msi.py does not work with PCBuild8
New submission from Kevin Watters: The msi.py script for creating an Windows MSI installer from a Python source tree has hardcoded values for PCBuild. The newer MSVC 2005 build directory is PCBuild8 and has a slightly different structure. msi.py needs to be changed to be able to work with a 2005-built Python tree as well. -- components: Build messages: 56791 nosy: kevinwatters severity: normal status: open title: Tools/msi/msi.py does not work with PCBuild8 type: rfe versions: Python 2.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1337 __ ___ 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
Jean Brouwers added the comment: Here is one thought, maybe 3.0a calls _exit() while 2.x uses exit() to terminate. With _exit() any functions installed with atexit() or on_exit() are *not* called. That would explain the difference but only if destructor functions are installed with atexit() or on_exit(). I do not know whether that. __ 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
Jean Brouwers added the comment: Sorry, premature submit. I will try using atexit() and report what happens there. __ 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
[issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmclib
Eric Sammons added the comment: I have tested 2.4.4 and 2.5.1 from python.org and both suffer from the exact same issue. I have also compared ceval.c from 2.3, the last known working copy and ceval.c from 2.4+ and found that ceval.c has undergone some pretty significant changes. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1327 __ ___ 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
Jean Brouwers added the comment: Using atexit() to install the destructor function does not help. The function in not called when 3.0a1 exits, but with 2.5.1 it is. Same behavior on Linux and MacOS X. Btw, that would mean that any C extension which uses atexit() directly may be affected by this issue. Running python with the debugger shows that 3.0a1 and 2.5.1 both exit thru exit() and not _exit(). A breakpoint at _exit is hit, but the call originates from exit and not anywhere in the python binary. There is a new atexitmodule.c in 3.0a1 which did not exits in 2.5.1. But that is handling the atexit functionality at the Python level and not C. This man page http://linux.die.net/man/3/atexit mentions that all registered atexit functions are removed after a fork+exec. But breakpoints set at fork, fork1, forkpty and vfork are never hit by 3.0a1. That is as far as I got. __ 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
[issue1330] Fix truncate on Windows, this time for real
Guido van Rossum added the comment: Committed revision 58673. I made one change, hopefully I didn't screw it up: skip the positional restore if the truncation itself failed. Otherwise the positional restore might overwrite the error from the truncation. After an error from this function they shouldn't make any assumptions about the position anyway! -- resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1330 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1311] os.path.exists(os.devnull) regression on windows
Facundo Batista added the comment: import os.path os.path.exists(con) False os.path.exists(nul) False os.path.exists(prn) False This is in Windows 2000 (5.00.2195) sp4, using *both* Python 2.3.5 and 2.5.1, no cygwin. Personally, I'm +1 with Mark Hammond about this: I agree it is unfortunate that the behaviour has changed, but these special names are broken enough on Windows that rely on the kernel32 function and behaves like it says seems the sanest thing to do. Taking in consideration that *now* it behaves equally in different windows systems, but not before, I think this issue should be closed as invalid (it's not a bug). I'll wait some days to get more behaviour responses, though. Regards, __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1311 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1335] bytesiterator patch
Guido van Rossum added the comment: Committed revision 58674. I added a change to _abcoll.py to remove the registration of bytes as a subclass of Iterable. -- resolution: - accepted status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1335 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1325] zipimport.zipimporter.archive undocumented and untested
Guido van Rossum added the comment: If you submit a patch that adds docs and a unit test, your wish will be fulfilled. -- nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1325 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1326] internal zipimport.zipimporter feature untested
Guido van Rossum added the comment: Please submit a patch for docs and a unittest... -- nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1326 __ ___ 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
Guido van Rossum added the comment: Can you provide a very small shared library that demonstrates this problem? (E.g. you could start by modifying Modules/xxmodule.c, adding a 'destructor' function.) -- nosy: +gvanrossum __ 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
[issue1328] feature request: force BOM option
Guido van Rossum added the comment: Can't you force a BOM by simply writing \ufffe at the start of the file? -- nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1328 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
Guido van Rossum added the comment: Can you step through it with a C/C++ debugger to see where it goes wrong? -- nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1332 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1333] merge urllib and urlparse functionality
Guido van Rossum added the comment: You missed urllib2 I think. :-) I agree it's a mess. I'm sure it all started out with backwards compatibility in mind. I find myself often importing cgi only to use the tiny function escape() that is defined there... I wonder if web-sig wouldn't be a good place to get some kindred spirits together to redesign these APIs for Py3k? -- nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1333 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1336] subprocess.Popen hangs when child writes to stderr
Guido van Rossum added the comment: I don't think we can prevent GC from occurring between fork and exec -- it's legal to just call os.fork() and execute Python code in the subprocess forever. I think the right solution might be to ignore errors in file_close(). Can you try to whip up a patch for that and test it? -- nosy: +gvanrossum __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1336 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1338] pickling bytes?
New submission from Guido van Rossum: Alexandre Vassalotti suggested the following: A simple way to add specific pickling support for bytes/buffer objects would be to define two new constants: BYTES = b'\x8c' # push a bytes object BUFFER = b'\x8d' # push a buffer object And add the following pickling and unpickling procedures: def save_bytes(self, obj, pack=struct.pack): n = len(obj) self.write(BYTES + pack(i, n) + obj) def save_buffer(self, obj, pack=struct.pack): n = len(obj) self.write(BUFFER + pack(i, n) + obj) def load_bytes(self): len = mloads(b'i' + self.read(4)) self.append(self.read(len)) def load_buffer(self): len = mloads(b'i' + self.read(4)) self.append(buffer(self.read(len))) The only problem with this approach is that bytes object bigger than 4GB cannot be pickled. Currently, this applies to all string-like objects, so I don't think this restriction will cause any trouble. Also, it would be a good idea to bump the protocol version to 3 to ensure that older Python versions don't try to load pickle streams created with these new constants. By the way, would it be a good idea to add specific pickling support for sets (and frozensets)? -- keywords: py3k messages: 56809 nosy: gvanrossum priority: normal severity: normal status: open title: pickling bytes? versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1338 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
Warren DeLano added the comment: Hmm. Well, for one thing, we're falling back on Python's interlocked_cmp_xchg instead of using Windows' InterlockedCompareExchange (or should it InterlockCompareExchange64?). Python's implementation is clearly assuming 64 bit counters, but the other native Windows Interlocked* functions may indeed be operating on 32 bit counters, hence the mismatch. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1332 __ ___ 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
Jean Brouwers added the comment: Yes, I will make a small library. But first, here is another piece of evidence. As I mentioned, using std atexit does not work on 3.0a1. But surprisingly, the destructor function is not called either when installed with Py_AtExit on 3.0a1. On 2.5.1 it is. There must something in Py_Terminate or Py_Finalize which is different in 3.0a1. __ 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
[issue1338] pickling bytes?
Georg Brandl added the comment:
Having explicit support for sets at least would be consistent with all
other types for which there is a display form.
(Or else, {1,2,3} could be a different thing after unpickling if the set
builtin is overwritten.)
--
nosy: +georg.brandl
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1338
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
Warren DeLano added the comment: Disabling Python's emulated InterlockedCompareExchange (for Win95 compatibility) cures the problem, so the underlying question is why the existence of InterlockedCompareExchange is not being autodetected on 64 bit systems -- and that is apparently because GetProcAddress (kernel,InterlockedCompareExchange) returns NULL -- which makes sense since InterlockedCompareExchange appears to be implemented using macros instead of being served up through kernel32.dll. So is Win95 still a supported platform? If not, then perhaps InterlockedCompareExchange emulation can simply be deleted. If so, then either some other approach needs to be adopted to activate emulation, or the emulated code needs to be fixed to behave like the native windows functions (which appear to only operate on the lowest 32 bits). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1332 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
Guido van Rossum added the comment: Disabling Python's emulated InterlockedCompareExchange (for Win95 compatibility) cures the problem, so the underlying question is why the existence of InterlockedCompareExchange is not being autodetected on 64 bit systems -- and that is apparently because GetProcAddress (kernel,InterlockedCompareExchange) returns NULL -- which makes sense since InterlockedCompareExchange appears to be implemented using macros instead of being served up through kernel32.dll. So is Win95 still a supported platform? Heavens no! If not, then perhaps InterlockedCompareExchange emulation can simply be deleted. Patch please? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1332 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1328] feature request: force BOM option
Guido van Rossum added the comment: If you can, please submit a patch that fixes all those issues, with unit tests and doc changes if at all possible. That will make it much easier to evaluate the ramifications of your proposal(s). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1328 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1328] feature request: force BOM option
James G. sack (jim) added the comment: re: msg56782 Yes, of course I can explicitly write the BOM. I did realize that after my first post ( my-'duh' :-[ ). But after playing some more, I do think this issue has become a worthwhile one. My second post msg56780 asks that utf_8 be tolerant of the 3-byte sig BOM, and uf_16_[be]e be tolerant of their BOMs, which I argue is consistent with be liberal on what you accept. A second half of that message suggests that it might be worth considering something like a write_bom parameter with utf_16 defaulting to True, and utf_16_[bl]e defaulting to False. My third post (m56782) may actually represent a bug. I have a unittest for this and would be glad to provide (although I need to reduuce a larger test to a simple case). I will look at this again, and re-pester you as required. Regards (and thanks for the reply), ..jim __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1328 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1328] feature request: force BOM option
James G. sack (jim) added the comment: OK, I will work on it. I have just downloaded trunk and will see what I can do. Might be a week or two. ..jim __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1328 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
Warren DeLano added the comment:
Patch attached. Do note that this patch will break threading on Win95
in order to achieve 64-bit compatibility. Win98 and up should be
fine -- however, that assertion has not yet been confirmed.
Added file: http://bugs.python.org/file8621/thread_nt_fix.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1332
__*** thread_nt.h Fri Oct 26 21:03:09 2007
--- Python-2.5.1/Python/thread_nt.h Fri Oct 26 21:03:34 2007
***
*** 1,9
--- 1,10
/* This code implemented by [EMAIL PROTECTED] */
/* Fast NonRecursiveMutex support by Yakov Markovitch, [EMAIL PROTECTED] */
/* Eliminated some memory leaks, [EMAIL PROTECTED] */
+ /* Nixed InterlockedCompareExchange emulation (x86_64:1, Win95:0), [EMAIL
PROTECTED] */
#include windows.h
#include limits.h
#ifdef HAVE_PROCESS_H
#include process.h
***
*** 13,88
LONG owned ;
DWORD thread_id ;
HANDLE hevent ;
} NRMUTEX, *PNRMUTEX ;
- typedef PVOID WINAPI interlocked_cmp_xchg_t(PVOID *dest, PVOID exc, PVOID
comperand) ;
-
- /* Sorry mate, but we haven't got InterlockedCompareExchange in Win95! */
- static PVOID WINAPI
- interlocked_cmp_xchg(PVOID *dest, PVOID exc, PVOID comperand)
- {
- static LONG spinlock = 0 ;
- PVOID result ;
- DWORD dwSleep = 0;
-
- /* Acqire spinlock (yielding control to other threads if cant aquire
for the moment) */
- while(InterlockedExchange(spinlock, 1))
- {
- // Using Sleep(0) can cause a priority inversion.
- // Sleep(0) only yields the processor if there's
- // another thread of the same priority that's
- // ready to run. If a high-priority thread is
- // trying to acquire the lock, which is held by
- // a low-priority thread, then the low-priority
- // thread may never get scheduled and hence never
- // free the lock. NT attempts to avoid priority
- // inversions by temporarily boosting the priority
- // of low-priority runnable threads, but the problem
- // can still occur if there's a medium-priority
- // thread that's always runnable. If Sleep(1) is used,
- // then the thread unconditionally yields the CPU. We
- // only do this for the second and subsequent even
- // iterations, since a millisecond is a long time to wait
- // if the thread can be scheduled in again sooner
- // (~100,000 instructions).
- // Avoid priority inversion: 0, 1, 0, 1,...
- Sleep(dwSleep);
- dwSleep = !dwSleep;
- }
- result = *dest ;
- if (result == comperand)
- *dest = exc ;
- /* Release spinlock */
- spinlock = 0 ;
- return result ;
- } ;
-
- static interlocked_cmp_xchg_t *ixchg;
-
BOOL
InitializeNonRecursiveMutex(PNRMUTEX mutex)
{
- if (!ixchg)
- {
- /* Sorely, Win95 has no InterlockedCompareExchange API (Win98
has), so we have to use emulation */
- HANDLE kernel = GetModuleHandle(kernel32.dll) ;
- if (!kernel || (ixchg = (interlocked_cmp_xchg_t
*)GetProcAddress(kernel, InterlockedCompareExchange)) == NULL)
- ixchg = interlocked_cmp_xchg ;
- }
-
mutex-owned = -1 ; /* No threads have entered NonRecursiveMutex */
mutex-thread_id = 0 ;
mutex-hevent = CreateEvent(NULL, FALSE, FALSE, NULL) ;
return mutex-hevent != NULL ; /* TRUE if the mutex is created */
}
- #ifdef InterlockedCompareExchange
- #undef InterlockedCompareExchange
- #endif
- #define InterlockedCompareExchange(dest,exchange,comperand) (ixchg((dest),
(exchange), (comperand)))
-
VOID
DeleteNonRecursiveMutex(PNRMUTEX mutex)
{
/* No in-use check */
CloseHandle(mutex-hevent) ;
--- 14,32
***
*** 96,106
DWORD ret ;
/* InterlockedIncrement(mutex-owned) == 0 means that no thread
currently owns the mutex */
if (!wait)
{
! if (InterlockedCompareExchange((PVOID *)mutex-owned,
(PVOID)0, (PVOID)-1) != (PVOID)-1)
return WAIT_TIMEOUT ;
ret = WAIT_OBJECT_0 ;
}
else
ret = InterlockedIncrement(mutex-owned) ?
--- 40,50
DWORD ret ;
/* InterlockedIncrement(mutex-owned) == 0 means that no thread
currently owns the mutex */
if (!wait)
{
! if (InterlockedCompareExchange(mutex-owned, 0, -1) != -1)
return WAIT_TIMEOUT ;
ret = WAIT_OBJECT_0 ;
}
else
ret = InterlockedIncrement(mutex-owned) ?
___
[issue1329] Different 3.0a1 exit behavior
Jean Brouwers added the comment:
Here is the same file with an #if to use to Py_AtExit or destructor case.
Please us this one instead of the earlier one.
Added file: http://bugs.python.org/file8622/dlibtest.c
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1329
__
#include stdio.h
#ifndef __GNUC__
# error require GNU compiler
#endif
#if 0 /* pick this ... */
static void __attribute__((constructor)) /* called on main() */
_ctor (void)
{
printf(*** %s called ...\n, ctor);
}
static void __attribute__((destructor)) /* called on exit() */
_dtor (void)
{
printf(*** %s called ...\n, dtor);
}
#else /* ... or this case */
static void /* called on Python exit */
_dtor (void)
{
printf(*** %s called ...\n, dtor);
}
extern int Py_AtExit (void(*func)(void));
static void __attribute__((constructor)) /* called on main() */
_ctor (void)
{
printf(*** %s called ...\n, ctor);
if (Py_AtExit(_dtor) 0) {
printf(%s failed ...\n, Py_AtExit);
}
}
#endif
/* =
Build this file into a shared library, then pre-load
that library with the Python binary as follows.
On Linux, compile as
gcc -o dlibtest.os -c -m32 -Wall -Werror -fPIC dlibtest.c
gcc -o dlibtest.so -m32 -ldl -shared dlibtest.os
and then run
env LD_PRELOAD dlibtest.so .../python
On MacOS X, compile as
gcc -o dlibtest.os -c -Wall -Werror -march=i686 -fPIC dlibtest.c
gcc -o dlibtest.dylib -undefined dynamic_lookup -lpthread -dynamiclib
dlibtest.os
and run
env DYLD_INSERT_LIBRARIES=./dlibtest.dylib .../python.exe
After Ctrl-D two messages should have been printed, but 3.0a1
prints only the first one.
Here is a log from Linux with my 3.0a1 and 2.51 builds and
with 2.3.4 included with the Linux distro:
$ gcc -o dlibtest.os -c -m32 -Wall -Werror -fPIC dlibtest.c
$ gcc -o dlibtest.so -m32 -ldl -shared dlibtest.os
$ env LD_PRELOAD=./dlibtest.so ~/Python-3.0a1/python
*** ctor called ...
Python 3.0a1 (py3k, Oct 26 2007, 09:45:17)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type help, copyright, credits or license for more information.
$ env LD_PRELOAD=./dlibtest.so ~/Python-2.5.1/python
*** ctor called ...
Python 2.5.1 (r251:54863, Oct 22 2007, 16:19:11)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type help, copyright, credits or license for more information.
*** dtor called ...
$ env LD_PRELOAD=./dlibtest.so /usr/bin/python
*** ctor called ...
Python 2.3.4 (#1, May 2 2007, 19:26:00)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type help, copyright, credits or license for more information.
*** dtor called ...
Similarly on MacOS X with Python 2.3.5 distributed by Apple:
% env DYLD_INSERT_LIBRARIES=./dlibtest.dylib ~/Python-3.0a1/python.exe
*** ctor called ...
Python 3.0a1 (py3k, Oct 25 2007, 14:55:57)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type help, copyright, credits or license for more information.
^D
% env DYLD_INSERT_LIBRARIES=./dlibtest.dylib ~/Python-2.5.1/python.exe
*** ctor called ...
Python 2.5.1 (r251:54863, Oct 22 2007, 16:18:08)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type help, copyright, credits or license for more information.
^D
*** dtor called ...
% env DYLD_INSERT_LIBRARIES=./dlibtest.dylib /usr/bin/python
*** ctor called ...
Python 2.3.5 (#1, Jan 13 2006, 20:13:11)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type help, copyright, credits or license for more information.
^D
*** dtor called ...
/Jean Brouwers [EMAIL PROTECTED]
PS) For more details on the con/destructor attributes, see the GNU
gcc documentation at
http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Function-Attributes.html
See also Apple's documentation DynamicLibrary.pdf which
contains some excellent examples plus special MacOS X
features. E.g. c/dtor must be ZPRIVATE and a static
ctor can have main-like argc, argv and envp arguments!
= */
___
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
Jean Brouwers added the comment:
Attached is a simple test case which demonstrates the problem on Linux
and MacOS X. It is not an xxmodule example, though and hope this is OK.
See the comments for build steps and example output with 3 different
Python builds on both platforms.
If you need another test case which uses Py_AtExit, let me know.
Added file: http://bugs.python.org/file8620/dlibtest.c
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1329
__
#include stdio.h
#ifndef __GNUC__
# error require GNU compiler
#endif
static void __attribute__((constructor)) /* called on main() */
_ctor (void)
{
printf(*** %s called ...\n, ctor);
}
static void __attribute__((destructor)) /* called on exit() */
_dtor (void)
{
printf(*** %s called ...\n, dtor);
}
/* =
Build this file into a shared library, then pre-load
that library with the Python binary as follows.
On Linux, compile as
gcc -o dlibtest.os -c -m32 -Wall -Werror dlibtest.c
gcc -o dlibtest.so -m32 -ldl -shared dlibtest.os
and then run
env LD_PRELOAD dlibtest.so .../python
On MacOS X, compile as
gcc -o dlibtest.os -c -Wall -Werror -march=i686 -fPIC dlibtest.c
gcc -o dlibtest.dylib -undefined dynamic_lookup -lpthread -dynamiclib
dlibtest.os
and run
env DYLD_INSERT_LIBRARIES=./dlibtest.dylib .../python.exe
After Ctrl-D two messages should have been printed, but 3.0a1
prints only the first one.
Here is a log from Linux with my 3.0a1 and 2.51 builds and
with 2.3.4 included with the Linux distro:
$ gcc -o dlibtest.os -c -m32 -Wall -Werror dlibtest.c
$ gcc -o dlibtest.so -m32 -ldl -shared dlibtest.os
$ env LD_PRELOAD=./dlibtest.so ~/Python-3.0a1/python
*** ctor called ...
Python 3.0a1 (py3k, Oct 26 2007, 09:45:17)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type help, copyright, credits or license for more information.
$ env LD_PRELOAD=./dlibtest.so ~/Python-2.5.1/python
*** ctor called ...
Python 2.5.1 (r251:54863, Oct 22 2007, 16:19:11)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type help, copyright, credits or license for more information.
*** dtor called ...
$ env LD_PRELOAD=./dlibtest.so /usr/bin/python
*** ctor called ...
Python 2.3.4 (#1, May 2 2007, 19:26:00)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type help, copyright, credits or license for more information.
*** dtor called ...
Similarly on MacOS X with Python 2.3.5 distributed by Apple:
% env DYLD_INSERT_LIBRARIES=./dlibtest.dylib ~/Python-3.0a1/python.exe
*** ctor called ...
Python 3.0a1 (py3k, Oct 25 2007, 14:55:57)
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type help, copyright, credits or license for more information.
^D
% env DYLD_INSERT_LIBRARIES=./dlibtest.dylib ~/Python-2.5.1/python.exe
*** ctor called ...
Python 2.5.1 (r251:54863, Oct 22 2007, 16:18:08)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type help, copyright, credits or license for more information.
^D
*** dtor called ...
% env DYLD_INSERT_LIBRARIES=./dlibtest.dylib /usr/bin/python
*** ctor called ...
Python 2.3.5 (#1, Jan 13 2006, 20:13:11)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin
Type help, copyright, credits or license for more information.
^D
*** dtor called ...
/Jean Brouwers [EMAIL PROTECTED]
PS) For more details on the con/destructor attributes, see the GNU
gcc documentation at
http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Function-Attributes.html
See also Apple's documentation DynamicLibrary.pdf which
contains some excellent examples plus special MacOS X
features. E.g. c/dtor must be ZPRIVATE and a static
ctor can have main-like argc, argv and envp arguments!
= */
___
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
Guido van Rossum added the comment: OK, confirmed. But no insignt in what happened yet... Do you know where the atexit stuff happens in 2.5? __ 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
Changes by Guido van Rossum: Removed file: http://bugs.python.org/file8620/dlibtest.c __ 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
Jean Brouwers added the comment: One more thing. Stepping with the debugger thru Py_Finalize looks exactly the same for 2.5.1 and 3.0a1 in the last part of that function. __ 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
Jean Brouwers added the comment: The Py_AtExit function is in Python/pythonrun.c. The calls to all installed C functions are made in call_ll_exitfuncs, also in pythonrun.c. The call to call_ll_exitfuncs is at the very end of Py_Finalize also in pythonrun.c. I am just getting down there now and Py_Finalize is called and reaches the call to PyGrammar_RemoveAccelerators a few lines higher. But call_ll_exitfuncs is not called, as far as I can tell. __ 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
Jean Brouwers added the comment: I put a bunch of printf's in the Py_Finalize function of 2.5.1 and 3.0a1. All those show up when 2.5.1 exists including the call to call_ll_exitfuncs. But in 3.0a1 only a few show up and the last one is just before the call to PyImport_Cleanup near line 393. It looks like that call never returns. That call never returns, it seems. __ 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
[issue1339] smtplib starttls() should ehlo() if it needs to
New submission from Bill Fenner: smtplib's complex methods, login and sendmail, try to EHLO or HELO if it hasn't been done yet. login also checks to see if the EHLO response included the ability to do authorization. starttls seems to me to be similar in nature: why should it not try to EHLO or HELO, and check that self.has_extn(starttls)? -- components: Library (Lib) messages: 56829 nosy: fenner severity: normal status: open title: smtplib starttls() should ehlo() if it needs to type: rfe versions: Python 2.4 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1339 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1340] correction for test_tempfile in py3k on Windows
New submission from Amaury Forgeot d'Arc:
This tiny patch correct a failure in test_tempfile on Windows: in
SpooledTemporaryFile, avoid translating the newlines twice.
Otherwise, in universal text mode, \n gets transformed to \r\n, then
to \r\r\n, which is read as \n\n.
Passing the encoding is OK, since the round-trip gives the same result,
and it allow encoding errors to occur at the right place.
Index: Lib/tempfile.py
===
--- Lib/tempfile.py (revision 58680)
+++ Lib/tempfile.py (working copy)
@@ -495,7 +495,7 @@
if 'b' in mode:
self._file = _io.BytesIO()
else:
-self._file = _io.StringIO(encoding=encoding, newline=newline)
+self._file = _io.StringIO(encoding=encoding)
self._max_size = max_size
self._rolled = False
self._TemporaryFileArgs = {'mode': mode, 'buffering': buffering,
--
components: Windows
messages: 56830
nosy: amaury.forgeotdarc
severity: normal
status: open
title: correction for test_tempfile in py3k on Windows
versions: Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1340
__
___
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
[issue829951] Fixes smtplib starttls HELO errors
Bill Fenner added the comment: Yes, the state that should be reset includes helo_resp, ehlo_resp, esmtp_features, and does_esmtp. The workaround commonly proposed is to always call ehlo() after starttls() . While this works (most of the time?), it seems arbitrary to require an explicit ehlo() call in this case but not other cases. -- nosy: +fenner versions: +Python 2.4 Tracker [EMAIL PROTECTED] http://bugs.python.org/issue829951 ___ 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
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 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1341] correction for test_fileinput in py3k on Windows
New submission from Amaury Forgeot d'Arc: This patch corrects test_fileinput on Windows: when redirecting stdout, os.open should be given O_BINARY, because the file descriptor is then wrapped in a text-mode file; os.fdopen(fd, w). -- files: fileinput.diff messages: 56833 nosy: amaury.forgeotdarc severity: normal status: open title: correction for test_fileinput in py3k on Windows Added file: http://bugs.python.org/file8623/fileinput.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1341 __ fileinput.diff Description: Binary data ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1341] correction for test_fileinput in py3k on Windows
Changes by Amaury Forgeot d'Arc: -- components: +Windows versions: +Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1341 __ ___ 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
Jean Brouwers added the comment: OK, I try that. __ 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
[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
Warren DeLano added the comment: No need -- turns out the problem was fixed on April 21st a mere three days after Python 2.5.1 was released. Please close this issue -- my rookie mistake not working with SVN source from the start! (gee, I should have known better...) Sorry for wasting your time and mine. However, considering the severity of this problem (threading.Lock.acquire(0) broken on 64-bit Windows), what do you think about issuing a 2.5.2 maintenance release? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1332 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
Guido van Rossum added the comment: However, considering the severity of this problem (threading.Lock.acquire(0) broken on 64-bit Windows), what do you think about issuing a 2.5.2 maintenance release? Neal Norwitz and Anthony Baxter have been planning to release 2.5.2 for a while now; unfortunately both seem too busy to make much progress. Any volunteers? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1332 __ ___ 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
Jean Brouwers added the comment: The 3.0a1 build --with-pydebug behaves the same as before (on Linux). The problem does occur without gdb but not with gdb. __ 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
[issue1332] threading.RLock().aquire(0) fails with python-2.5.1.amd64.msi
Warren DeLano added the comment: I wouldn't know how take the lead, but with customers breathing down my neck for x64 support, my own threading.Rlock-dependent software product cannot support x64 until an official Python release supports it. So I guess that automatically puts me in the **highly- motivated/willing-to-help** camp, if there's anything useful I can actually do towards 2.5.2. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1332 __ ___ 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
Jean Brouwers added the comment: It looks like the problem may indeed just be that I/O is being shut down somewhere inside PyImport_Cleanup. I am modifying the test case to demonstrate that and will submit that version as soon as it runs. __ 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
[issue1342] Crash on Windows if Python runs from a directory with umlauts
New submission from Christian Heimes: Python 3.0 doesn't run from a directory with umlauts and possible other non ASCII chars. I renamed my development folder from C:\dev\ to c:\test äöüß name\. Python crashes after a few moments before it can reach its shell. python30.dll!PyErr_SetObject(_object * exception=0x1e1b9888, _object * value=0x00a0b8a0) Zeile 56 + 0xb Bytes C python30.dll!PyErr_SetString(_object * exception=0x1e1b9888, const char * string=0x1e18c358) Zeile 77 + 0xd Bytes C python30.dll!find_module(char * fullname=0x0021fcc0, char * subname=0x, _object * path=0x, char * buf=0x0021fb70, unsigned int buflen=257, _iobuf * * p_fp=0x0021fb64, _object * * p_loader=0x0021fb68) Zeile 1228 + 0x10 Bytes C python30.dll!import_submodule(_object * mod=0x1e1c6a88, char * subname=0x0021fcc0, char * fullname=0x) Zeile 2313 + 0x27 Bytes C python30.dll!load_next(_object * mod=0x1e1c6a88, _object * altmod=0x1e1c6a88, char * * p_name=0x, char * buf=0x0021fcc0, int * p_buflen=0x0021fcbc) Zeile 2127 + 0x15 Bytes C python30.dll!import_module_level(char * name=0x, _object * globals=0x, _object * locals=0x1e069ec3, _object * fromlist=0x, int level=0) Zeile 1908 + 0x1a Bytes C python30.dll!PyImport_ImportModuleLevel(char * name=0x1e184b04, _object * globals=0x, _object * locals=0x, _object * fromlist=0x, int level=0) Zeile 1979 + 0x18 Bytes C python30.dll!_PyCodecRegistry_Init() Zeile 841 + 0x12 BytesC python30.dll!PyCodec_LookupError(const char * name=0x) Zeile 436 + 0xc Bytes C python30.dll!unicode_decode_call_errorhandler(const char * errors=0x, _object * * errorHandler=0x0009, const char * encoding=0x1e1979ec, const char * reason=0x, const char * * input=0x0021fe80, const char * * inend=0x0021fe84, int * startinpos=0x0021fe6c, int * endinpos=0x0021fe68, _object * * exceptionObject=0x, const char * * inptr=0x0021fe90, _object * * output=0x0021fe70, int * outpos=0x0021fe88, unsigned short * * outptr=0x0021fe74) Zeile 1384 + 0xa Bytes C python30.dll!PyUnicodeUCS2_DecodeUTF8Stateful(const char * s=0x1e1dd010, int size=48, const char * errors=0x, int * consumed=0x) Zeile 1967 + 0x47 Bytes C python30.dll!PyUnicodeUCS2_FromStringAndSize(const char * u=0x1e1dd008, int size=48) Zeile 464 + 0xb Bytes C python30.dll!PyUnicodeUCS2_FromString(const char * u=0x1e1dd008) Zeile 482 + 0x7 Bytes C python30.dll!_PySys_Init() Zeile 1084 + 0xb Bytes C python30.dll!Py_InitializeEx(int install_sigs=1) Zeile 220 C python30.dll!Py_Initialize() Zeile 292 + 0x7 Bytes C python30.dll!Py_Main(int argc=2, char * * argv=0x0001) Zeile 432 C python.exe!mainCRTStartup() Zeile 398 + 0xe Bytes C kernel32.dll!7c816fd7() -- components: Interpreter Core messages: 56841 nosy: tiran severity: normal status: open title: Crash on Windows if Python runs from a directory with umlauts type: crash versions: Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1342 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1042] test_glob fails with UnicodeDecodeError
Christian Heimes added the comment: I think the problem is solved now. I haven't seen glob crashing for a while. -- nosy: +tiran __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1042 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1247] PEP 3137 patch (repr, names, parser)
Christian Heimes added the comment:
Here is the patch that contains only the harmless parts of the previous
patches. It changes a bunch of doc strings, changes the name of the
types and their repr() and str(). It also adds __builtin__.buffer but it
leaves __builtin__.bytes, __builtin__.str8 and b'' as they are.
Added file: http://bugs.python.org/file8624/py3k-pep3137_harmless.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1247
__Index: Python/bltinmodule.c
===
--- Python/bltinmodule.c (revision 58683)
+++ Python/bltinmodule.c (working copy)
@@ -1797,6 +1797,7 @@
SETBUILTIN(True, Py_True);
SETBUILTIN(bool, PyBool_Type);
SETBUILTIN(memoryview,PyMemoryView_Type);
+ SETBUILTIN(buffer, PyBytes_Type);
SETBUILTIN(bytes, PyBytes_Type);
SETBUILTIN(classmethod, PyClassMethod_Type);
#ifndef WITHOUT_COMPLEX
Index: Objects/bytesobject.c
===
--- Objects/bytesobject.c (revision 58683)
+++ Objects/bytesobject.c (working copy)
@@ -395,7 +395,7 @@
if (i 0)
i += Py_Size(self);
if (i 0 || i = Py_Size(self)) {
-PyErr_SetString(PyExc_IndexError, bytes index out of range);
+PyErr_SetString(PyExc_IndexError, buffer index out of range);
return NULL;
}
return PyInt_FromLong((unsigned char)(self-ob_bytes[i]));
@@ -414,7 +414,7 @@
i += PyBytes_GET_SIZE(self);
if (i 0 || i = Py_Size(self)) {
-PyErr_SetString(PyExc_IndexError, bytes index out of range);
+PyErr_SetString(PyExc_IndexError, buffer index out of range);
return NULL;
}
return PyInt_FromLong((unsigned char)(self-ob_bytes[i]));
@@ -451,7 +451,7 @@
}
}
else {
-PyErr_SetString(PyExc_TypeError, bytes indices must be integers);
+PyErr_SetString(PyExc_TypeError, buffer indices must be integers);
return NULL;
}
}
@@ -551,7 +551,7 @@
i += Py_Size(self);
if (i 0 || i = Py_Size(self)) {
-PyErr_SetString(PyExc_IndexError, bytes index out of range);
+PyErr_SetString(PyExc_IndexError, buffer index out of range);
return -1;
}
@@ -587,7 +587,7 @@
i += PyBytes_GET_SIZE(self);
if (i 0 || i = Py_Size(self)) {
-PyErr_SetString(PyExc_IndexError, bytes index out of range);
+PyErr_SetString(PyExc_IndexError, buffer index out of range);
return -1;
}
@@ -619,7 +619,7 @@
}
}
else {
-PyErr_SetString(PyExc_TypeError, bytes indices must be integer);
+PyErr_SetString(PyExc_TypeError, buffer indices must be integer);
return -1;
}
@@ -889,11 +889,14 @@
bytes_repr(PyBytesObject *self)
{
static const char *hexdigits = 0123456789abcdef;
-size_t newsize = 3 + 4 * Py_Size(self);
+const char *quote_prefix = buffer(b';
+const char *quote_postfix = ');
+/* 9 prefix + 2 postfix */
+size_t newsize = 11 + 4 * Py_Size(self);
PyObject *v;
-if (newsize PY_SSIZE_T_MAX || newsize / 4 != Py_Size(self)) {
+if (newsize PY_SSIZE_T_MAX || (newsize-11) / 4 != Py_Size(self)) {
PyErr_SetString(PyExc_OverflowError,
-bytes object is too large to make repr);
+buffer object is too large to make repr);
return NULL;
}
v = PyUnicode_FromUnicode(NULL, newsize);
@@ -904,17 +907,17 @@
register Py_ssize_t i;
register Py_UNICODE c;
register Py_UNICODE *p;
-int quote = '\'';
p = PyUnicode_AS_UNICODE(v);
-*p++ = 'b';
-*p++ = quote;
+while (*quote_prefix)
+*p++ = *quote_prefix++;
+
for (i = 0; i Py_Size(self); i++) {
/* There's at least enough room for a hex escape
and a closing quote. */
assert(newsize - (p - PyUnicode_AS_UNICODE(v)) = 5);
c = self-ob_bytes[i];
-if (c == quote || c == '\\')
+if (c == '\'' || c == '\\')
*p++ = '\\', *p++ = c;
else if (c == '\t')
*p++ = '\\', *p++ = 't';
@@ -934,7 +937,9 @@
*p++ = c;
}
assert(newsize - (p - PyUnicode_AS_UNICODE(v)) = 1);
-*p++ = quote;
+while (*quote_postfix) {
+ *p++ = *quote_postfix++;
+}
*p = '\0';
if (PyUnicode_Resize(v, (p - PyUnicode_AS_UNICODE(v {
Py_DECREF(v);
@@ -947,7 +952,7 @@
static PyObject *
bytes_str(PyBytesObject *self)
{
-return PyString_FromStringAndSize(self-ob_bytes, Py_Size(self));
+return bytes_repr(self);
}
static PyObject *
@@ -2028,7 +2033,7 @@
PyDoc_STRVAR(replace__doc__,
B.replace (old, new[, count]) - bytes\n\
\n\
-Return a copy of bytes B with all
