[issue9532] pipe.read hang, when calling commands.getstatusoutput in multi-threading code of python 2.4
Ross Lagerwall rosslagerw...@gmail.com added the comment: After trying to reproduce this bug in 2.7.1 3.2b2 and failing, I think this should be closed (even the OP couldn't reproduce it in anything other than 2.4). -- nosy: +rosslagerwall ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9532 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1535504] CGIHTTPServer doesn't handle path names with embeded space
Georg Brandl ge...@python.org added the comment: Right, closing this one too. Thanks! -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1535504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
sorin sorin.sbar...@gmail.com added the comment: remeber that cp65001 cannot be set on windows. Also please read http://blogs.msdn.com/b/michkap/archive/2010/10/07/10072032.aspx and contact the author, Michael Kaplan from Microsoft, if you have more questions. I'm sure he will be glad to help. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation
Eli Bendersky eli...@gmail.com added the comment: I agree that the difference in behavior between the two functions is unfortunate, but that's unlikely to change now. The least we can do is make the documentation precise. I'm attaching a proposed patch to Doc/c-api/object.rst Nick/Terry/Georg - if this looks OK I can commit. -- keywords: +easy, patch nosy: +eli.bendersky, ncoghlan, terry.reedy -Devin Jeanpierre type: - behavior Added file: http://bugs.python.org/file20413/issue10912.py3k.1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation
Georg Brandl ge...@python.org added the comment: Sure. -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation
Eli Bendersky eli...@gmail.com added the comment: Committed the fix to py3k in r88009 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation
Eli Bendersky eli...@gmail.com added the comment: Backport to release31 branch in r88010 -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10913] Deprecate PyEval_AcquireLock() and PyEval_ReleaseLock()
New submission from Antoine Pitrou pit...@free.fr: These two functions are very low-level and no good to use outside the interpreter core (actually, inside the core I don't think they are useful either). We should deprecate them and recommend the thread-state aware functions instead. See #1720250 for an example confusion. -- assignee: pitrou components: Documentation messages: 126324 nosy: grahamd, pitrou priority: high severity: normal status: open title: Deprecate PyEval_AcquireLock() and PyEval_ReleaseLock() type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10913 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8754] ImportError: quote bad module name in message
Georg Brandl ge...@python.org added the comment: Won't make it into 3.2. -- priority: deferred blocker - high versions: +Python 3.3 -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8754 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3243] Support iterable bodies in httplib
Georg Brandl ge...@python.org added the comment: Anything left to do here, Senthil? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10913] Deprecate PyEval_AcquireLock() and PyEval_ReleaseLock()
Antoine Pitrou pit...@free.fr added the comment: Done in r88018. -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10913 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10914] Python sub-interpreter test
New submission from Antoine Pitrou pit...@free.fr: Here is a prototype test for embedding and sub-interpreters. -- components: Interpreter Core, Tests files: embedtest.patch keywords: patch messages: 126328 nosy: christian.heimes, grahamd, haypo, loewis, pitrou priority: normal severity: normal status: open title: Python sub-interpreter test versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file20414/embedtest.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10914 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1977] Python reinitialization test
Antoine Pitrou pit...@free.fr added the comment: See also #10914. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1977 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation
Nick Coghlan ncogh...@gmail.com added the comment: For the record, the gory details as to *why* RichCompareBool makes more assumptions as to the meaning of equality than the basic RichCompare function can be found in issue 4296 (I just found that issue myself by looking at Mark's response to the python-list thread). It may be worth explicitly pointing out that use cases where this assumption is unacceptable would be better served by direct invocation RichCompare function. -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation
Eli Bendersky eli...@gmail.com added the comment: Nick, I read the protocol of issue 4296 and I understand the reasoning behind the code, but I still think the naming is mightily confusing. Two distinct changes went into a single function (A) Return -1/0/+1 instead of PyObject and (B) the id() shortcut, and its name is inappropriate. Were an API change feasible, some other naming would be better. It may be worth explicitly pointing out that use cases where this assumption is unacceptable would be better served by direct invocation RichCompare function. Do you mean write it down in the docs? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation
Nick Coghlan ncogh...@gmail.com added the comment: Yeah, to prevent perfectly reasonable why questions, it is probably worth providing a little extra justification as an addendum to your new note (which is already an improvement on the complete silence on the topic that existed before). A possible addition: ... This assumption allows invariants such as x in [x] to be more easily guaranteed by the interpreter. If the assumption is not valid for a given use case, call PyObject_RichCompare() directly instead of using this function. For 3.3, it *may* make sense to provide a PyObject_RichCompareBoolEx() function which includes an additional reflexive parameter. Then the existing PyObject_RichCompareBool() semantics would just be the new function with the reflexive argument set to 1. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10915] Make the PyGILState API compatible with multiple interpreters
New submission from Antoine Pitrou pit...@free.fr: It should be relatively easy to devise a new PyGILState API with support for multiple interpreters. We just need two new functions (similar to the two existing ones) taking a PyInterpreterState* parameter; a TLS key can be added to the PyInterpreterState structure (instead of the current global TLS key). It will be up to the caller to know which interpreter they want to hook into when calling these functions (which is application-dependent and is normally well-defined, e.g. when calling a Python callback, you should call it with the interpreter which was in use when registering the callback (i.e. ``PyThreadState_Get()-interp``)). -- components: Interpreter Core messages: 126333 nosy: amaury.forgeotdarc, grahamd, loewis, pitrou priority: normal severity: normal stage: needs patch status: open title: Make the PyGILState API compatible with multiple interpreters type: feature request versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10915] Make the PyGILState API compatible with multiple interpreters
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10914] Python sub-interpreter test
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +amaury.forgeotdarc, ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10914 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10916] mmap segfault
New submission from Ross Lagerwall rosslagerw...@gmail.com: If a mmap length 0 is used and an offset is used as well, the size to mmap() is calculated as the size of the file instead of the size of the file minus offset. This means that trying to access a certain part does not result in an index error but a segfault (bus error). Attached is a patch that fixes the issue + a unit test. -- components: Extension Modules files: mmap.patch keywords: patch messages: 126334 nosy: amaury.forgeotdarc, loewis, pitrou, r.david.murray, rosslagerwall priority: normal severity: normal status: open title: mmap segfault type: crash versions: Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file20415/mmap.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10916 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5800] make wsgiref.headers.Headers accept empty constructor
Changes by SilentGhost ghost@gmail.com: -- status: open - languishing ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5800 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10915] Make the PyGILState API compatible with multiple interpreters
Antoine Pitrou pit...@free.fr added the comment: Here is a sketch, including conversion of ctypes to the new API. Converting sqlite would require a bit more work. -- keywords: +patch Added file: http://bugs.python.org/file20416/gilstateinterp.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9532] pipe.read hang, when calling commands.getstatusoutput in multi-threading code of python 2.4
Changes by R. David Murray rdmur...@bitdance.com: -- resolution: - out of date stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9532 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10908] Improvements to trace._Ignore
SilentGhost ghost@gmail.com added the comment: The patch aside from fixing directory names on case-insensitive file systems, also: * implements more efficient handling of directory and module comparison (put into _Ignoore.__init__ instead of _Ignore.names). * changes integer return codes to boolean * doesn't require any more that the directory is actually a directory name. * moves --ignore-dir processing into a directory so that it can be expanded if $prefix support on windows is needed. * adds tests. -- stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10908 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10916] mmap segfault
Antoine Pitrou pit...@free.fr added the comment: Thanks for the patch. Committed in r88022 (3.2), r88023 (3.1) and r88024 (2.7). -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10916 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10896] trace module compares directories as strings (--ignore-dir)
Changes by SilentGhost ghost@gmail.com: -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10908] Improvements to trace._Ignore
Changes by Alexander Belopolsky belopol...@users.sourceforge.net: -- nosy: +eli.bendersky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10908 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10896] trace module compares directories as strings (--ignore-dir)
Changes by SilentGhost ghost@gmail.com: -- nosy: -SilentGhost ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10908] Improvements to trace._Ignore
Changes by SilentGhost ghost@gmail.com: -- dependencies: +trace module compares directories as strings (--ignore-dir) type: - performance ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10908 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10915] Make the PyGILState API compatible with multiple interpreters
Changes by Antoine Pitrou pit...@free.fr: Removed file: http://bugs.python.org/file20416/gilstateinterp.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10915] Make the PyGILState API compatible with multiple interpreters
Changes by Antoine Pitrou pit...@free.fr: -- stage: needs patch - patch review Added file: http://bugs.python.org/file20417/gilstateinterp.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10694] zipfile.py end of central directory detection not robust
Georg Brandl ge...@python.org added the comment: Not important enough to block release. -- priority: deferred blocker - critical ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10694 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3243] Support iterable bodies in httplib
Changes by Georg Brandl ge...@python.org: -- priority: deferred blocker - critical ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8746] os.chflags() and os.lchflags() are not built when they should be be
Changes by Georg Brandl ge...@python.org: -- priority: deferred blocker - critical ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8746 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10736] test_ttk_guionly fails on OS X using ActiveState Tcl 8.5.9 (Cocoa)
Changes by Georg Brandl ge...@python.org: -- priority: deferred blocker - critical ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10736 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10734] test_ttk failure under Windows
Changes by Georg Brandl ge...@python.org: -- priority: deferred blocker - critical ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10734 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8957] strptime(.., '%c') fails to parse output of strftime('%c', ..) in some locales
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: On Sat, Jan 15, 2011 at 2:20 AM, Eli Bendersky rep...@bugs.python.org wrote: .. This solution is a hack, but so is the whole __calc_date_time function :-) [IMHO] I am not sure how to proceed. On one hand, I opened this issue to demonstrate that the current implementation is flawed, on the other hand, Eli has succeeded in improving the hack so that we can live with it a bit longer. Note that I did not have any real life application that would misbehave because of this bug and I don't think developers expect %c format to be parseable in the first place. I made this issue depend on #8915 because I think strptime should query the locale for format information directly rather than reverse engineer what strftime does. I don't think this fix solves all the problems. For example, in most locales (including plain C locale), day of the month in %c format uses %e format, but current implementation guesses it as %d: '%a %b %e %H:%M:%S %Y' LocaleTime().LC_date_time '%a %b %d %H:%M:%S %Y' This does not seem to be an issue because strptime with %d seems to be able to parse space-filled as well as zero-filled numbers. However, there may be platforms that are less forgiving. On the patch itself: 1. Unit tests are needed. 2. Please don't use datetime as a local variable. 3. I am not sure what the purpose of .lower() is. Are a_month and f_month lowercased? 4. Please keep lines under 79 characters long. 5. for m in range(1, 13) loop is better written as for am, fm in zip(self.a_month, self.f_month) Eli, what do you think yourself: should we try to perfect the hack or is it better to reimplement strptime using locale? Note that the latter may be a stepping stone to implementing strftime as well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8957 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8957] strptime(.., '%c') fails to parse output of strftime('%c', ..) in some locales
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: 6. datetime.find(self.f_month[m]) = 0 - self.f_month[m] in datetime Python is not C! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8957 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2275] urllib2 header capitalization
Rui Carmo rca...@gmail.com added the comment: I'd like to add that when supplying custom headers for things like UPNP (which uses SOAPACTION as a header to talk to frequently very limited servers), the library shouldn't mangle the headers in any way whatsoever and send them verbatim. (I consider that mangling to be a bug, and not a new feature. HTTP headers may be case-insensitve according to standards, but embedded implementations require us to have a degree of control over the headers, and failing to preserve header case is a bug.) Right now I've had to replace httplib and urllib2 with my own custom code because the SOAPACTION header is capitalized and sent to the server as Soapaction, which breaks the Intel embedded UPNP daemon. -- nosy: +Rui.Carmo type: feature request - behavior versions: +Python 2.7 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2275 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3243] Support iterable bodies in httplib
Senthil Kumaran orsent...@gmail.com added the comment: Hi Georg, In the previous comment, I had written that 'let me see if we have to accommodate those very special case where data can be a zero length string just to accommodate the mistake it was present in the earlier version.' More, I think about it, the more it seems to me that accommodating that special wrong case is not required. The decision boils down to this. 1. In py3k, data for POST should be bytes. 2. But urllib.request had a 'bug/hole' that when a zero length string was passed as a data, it did not raise an exception. There were cases in test_urllib2 where zero length string was passed. I argue that it was more of a mistake than, what we actually wanted to test it. Because there is NO practical scenario where Zero length data as a POST is useful. 3. Now, with the introduction of this feature requested in this issue, this zero length string would raise an Exception and would demand that even if it is zero length, please send it as bytes. IMO, this is correct behavior and we need not accommodate the previous one. So, I would recommend closing this bug as Fixed without further change. At most, a NEWS item can be added to explain point 2. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10916] mmap segfault
Antoine Pitrou pit...@free.fr added the comment: It also needed fixing on Windows: committed in r88036, r88037 and r88038. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10916 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3243] Support iterable bodies in httplib
Xuanji Li xua...@gmail.com added the comment: Yes, I think we should close it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8957] strptime(.., '%c') fails to parse output of strftime('%c', ..) in some locales
Eli Bendersky eli...@gmail.com added the comment: Alexander, 1) Patch comments - thanks for those. Will have them fixed. 2) General strategy for implementing strptime. I must confess I don't fully understand the reason for doing what the _strptime module does. Standard C AFAIK has nothing of the sort - it only has strftime and strptime, both using a given format string. Neither tries to guess it from an actual formatted time! Does it exist just to circumvent platforms where strptime isn't implemented in C or is buggy? Can you please shed some light on this (or point me somewhere)? With understanding of (2) I will be able to also logically reason about the next steps :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8957 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3243] Support iterable bodies in httplib
Senthil Kumaran orsent...@gmail.com added the comment: Thanks for the note. I shall some details to the NEWS entry before the release. Closing this report. -- priority: critical - low status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3243] Support iterable bodies in httplib
Changes by Senthil Kumaran orsent...@gmail.com: -- priority: low - normal ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8957] strptime(.., '%c') fails to parse output of strftime('%c', ..) in some locales
Alexander Belopolsky alexander.belopol...@gmail.com added the comment: You pretty much hit the nail on the head. Some platforms don't have strptime or did not have it at the time this code was written. The locale module is probably more recent than this code as well. -- nosy: +Alexander.Belopolsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8957 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation
Changes by Éric Araujo mer...@netwok.org: -- nosy: +Devin Jeanpierre ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10915] Make the PyGILState API compatible with multiple interpreters
Graham Dumpleton graham.dumple...@gmail.com added the comment: Can you please provide an example of what user would do and what changes existing extension modules would need to make? When I looked at this exact problem some time back, I worked out that you probably only need a single new public API function. This would be something like PyInterpreterState_Swap(). By default stuff would work on the main interpreter, but if for a specific thread it wanted to operate in context of a different sub interpreter, would call PyInterpreterState_Swap() to indicate that. That would store in TLS outside of any existing data structures. Functions like existing PyGILState_Ensure()/PyGILState_Release() would then look up that TLS variable to know which interpreter they are working with. Doing it this way meant that no C extension modules using PyGILState_??? functions would need to change at all, as what interpreter is being operated on dictated by who created the thread and initiated call in to Python interpreter. You probably want validation checks to say that PyInterpreterState_Swap() can only be called when not GIL lock held. It worries me that you are talking about new PyGILState_??? functions as that would suggest to me that extension modules would need to change to be aware of this stuff. That you are saying that sqlite needs changes is what makes me things the way you are going is a problem. It isn't practical to make SWIG change to use something other than PyGILState_Ensure()/PyGILState_Release(), it should be transparent and required no changes to existing C extensions. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10915] Make the PyGILState API compatible with multiple interpreters
Antoine Pitrou pit...@free.fr added the comment: Can you please provide an example of what user would do and what changes existing extension modules would need to make? The patch contains such a change for ctypes. It's quite simple actually. By default stuff would work on the main interpreter, but if for a specific thread it wanted to operate in context of a different sub interpreter, would call PyInterpreterState_Swap() to indicate that. That would store in TLS outside of any existing data structures. Functions like existing PyGILState_Ensure()/PyGILState_Release() would then look up that TLS variable to know which interpreter they are working with. That sounds like an ugly hack to avoid passing the desired interpreter state directly to PyGILState_Ensure()/PyGILState_Release(). Besides, it will only work if a thread always serves the same sub-interpreter. Doing it this way meant that no C extension modules using PyGILState_??? functions would need to change at all, as what interpreter is being operated on dictated by who created the thread and initiated call in to Python interpreter. Who would do that, if it's not the extensions in question? who created the thread is often a third-party library (e.g. sqlite) that has no notion of a Python interpreter. That's the whole point of using the PyGILState_* API, really. So extensions *will* have to be fixed. That you are saying that sqlite needs changes is what makes me things the way you are going is a problem. It isn't practical to make SWIG change to use something other than PyGILState_Ensure()/PyGILState_Release(), it should be transparent and required no changes to existing C extensions. What does SWIG use them for? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation
Changes by Raymond Hettinger rhettin...@users.sourceforge.net: -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: -1 on PyObject_RichCompareBoolEx() for 3.3 -- it is simply an invitation to shoot yourself (or others) in the foot. I've not seen real world code using bool(a==b) or its C equivalent, so it's hard to believe that there is a use case here (unless you're trying to commit atrocities with NaN-like objects). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10915] Make the PyGILState API compatible with multiple interpreters
Nick Coghlan ncogh...@gmail.com added the comment: A TLS based approach would presumably allow an embedding application like mod_wsgi to tinker with the state of threads created by naive modules that are unaware of the existence of subinterpreters. That said, I don't see anything that prevents us from pursuing a TLS based override for the existing PyGILState functions later if the simpler, more explicit approach proves inadequate. As it stands, the new explicit calls allow something like mod_wsgi to define its *own* TLS location for the interpreter that is currently handling callbacks into Python, then use SWIG to generate PyGILState_*Ex calls in callback wrappers that reference that TLS interpreter state. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation
Nick Coghlan ncogh...@gmail.com added the comment: Indeed. I was actually wondering if it would be worth trying to write up a section for the language reference to describe the cases where a Python implementation is *expected* to assume reflexive equality. We (IMO) have a problem at the moment due to situations like: class PyContains(list): ... def __contains__(self, obj): ... return any(x==obj for x in self) ... nan = float(nan) nan in [nan] True nan in PyContains([nan]) False This is a bug in the __contains__ definition (it should use x is obj or x == obj rather than just the latter expression) but there isn't anything in the language reference to point that out. Assuming reflexive equality in some places and not in others based on the underlying implementation language is going to be a source of subtle bugs relating to types like float and decimal.Decimal. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10903] ZipExtFile:_update_crc fails for CRC = 0x80000000
Nadeem Vawda nadeem.va...@gmail.com added the comment: I have been unable to reproduce this on either 3.2rc1 or 2.6. I used a Zip archive containing a single file with the data ba\n (CRC 0xDDEAA107). -- nosy: +nvawda ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10903 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10915] Make the PyGILState API compatible with multiple interpreters
Antoine Pitrou pit...@free.fr added the comment: A TLS based approach would presumably allow an embedding application like mod_wsgi to tinker with the state of threads created by naive modules that are unaware of the existence of subinterpreters. The question is how mod_wsgi could know about the existence of these threads, let alone decide which subinterpreter an arbitrary OS thread should belong to; only the extension module can safely tell. And it becomes totally hopeless if those threads are actually *shared* between subinterpreters, as might be the case with a 3rd-party library managing its own helper threads (I don't know if that's the case with sqlite). IMO we should really promote clean APIs which allow solving the whole problem, rather than devise an internal hack to try to improve things slightly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10915] Make the PyGILState API compatible with multiple interpreters
Graham Dumpleton graham.dumple...@gmail.com added the comment: The bulk of use cases is going to be simple callbacks via the same thread that called out of Python in the first place. Thus ultimately all it is doing is: Py_BEGIN_ALLOW_THREADS Call into some foreign C library. C library wants to do a callback into Python. PyGILState_STATE gstate; gstate = PyGILState_Ensure(); /* Perform Python actions here. */ result = CallSomeFunction(); /* evaluate result or handle exception */ /* Release the thread. No Python API allowed beyond this point. */ PyGILState_Release(gstate); More stuff in C library. Return back into the C extension wrapper. Py_END_ALLOW_THREADS This is what SWIG effectively does in its generated wrappers for callbacks. Using a TLS solution, all these modules that simply do this will now start working where as they currently usually deadlock or have other problems. In your solution, all these modules would need to be modified to some how transfer information about the current interpreter into the callback which is called by the foreign C library and use new PyGILState_??? functions rather than the old. I do accept that more complicated extension modules which create their own foreign threads and perform the call back into interpreter from that thread, or systems like mod_wsgi which have a persistent thread pool from which calls originate, will have to be modified, but this is the lessor use case from what I have seen. Overall, it is an easy win if TLS is used because a lot of code wouldn't need to change. Some will, but expect that a lot of the common stuff like lxml for example wouldn't. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: If something needs to be written about NaNs or other invariant destroying objects, perhaps a FAQ entry would suffice (perhaps referencing http://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-civilization/ ). -- assignee: docs@python - rhettinger keywords: -easy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10915] Make the PyGILState API compatible with multiple interpreters
Graham Dumpleton graham.dumple...@gmail.com added the comment: As to the comment: IMO we should really promote clean APIs which allow solving the whole problem, rather than devise an internal hack to try to improve things slightly. The reality is that if you force a change on every single extension module doing callbacks into the interpreter without having the GIL first, you will never see people update their code as they will likely not care about this special use case. And so the whole point of adding the additional APIs will be wasted effort and have achieved nothing. The TLS solution means many modules will work without the authors having to do anything. You therefore have to balance between what you perceive as a cleaner API and what is actually going to see a benefit without having to wait a half dozen years before people realise they should change their ways. BTW, TLS is currently used for current thread state for simplified GIL API, why isn't that use of TLS a hack where as doing the same for interpreter is? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10915 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8957] strptime(.., '%c') fails to parse output of strftime('%c', ..) in some locales
Eli Bendersky eli...@gmail.com added the comment: Alexander, but still - this isn't just an implementation of strptime. strptime, AFAIU strptime gets the format string as a parameter and uses it to parse a date string into a tm struct. So why do we need to parse a date string *without* a format string in Python, resorting to heuristics and pseudo-AI instead? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8957 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation
Eli Bendersky eli...@gmail.com added the comment: Raymond, I initially set easy on this issue because I considered it a documentation issue, not the place to resolve the harder debate of the semantics of these functions. Perhaps I was wrong? Also, I agree with Nick that the difference must be further clarified in stronger words. If there's no debate on this issue, I will commit a fix after the freeze is over. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Yes, it is a doc issue but sometimes those aren't easy to get right (in terms of being beneficial to the reader and in good alignment with the design intentions). Please attach the doc patch you want to go in and I'll review it sometime the freeze. -- priority: normal - low ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10912 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10917] PEP 333 link to CGI specification is broken
New submission from anatoly techtonik techto...@gmail.com: http://www.python.org/dev/peps/pep-0333/#id7 Link to CGI spec is broken. -- assignee: docs@python components: Documentation messages: 126361 nosy: docs@python, techtonik priority: normal severity: normal status: open title: PEP 333 link to CGI specification is broken versions: 3rd party, Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10917 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
