[issue9532] pipe.read hang, when calling commands.getstatusoutput in multi-threading code of python 2.4

Ross Lagerwall 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

[issue1535504] CGIHTTPServer doesn't handle path names with embeded space

Georg Brandl added the comment: Right, closing this one too. Thanks! -- resolution: -> wont fix status: open -> closed ___ Python tracker ___ ___

[issue1602] windows console doesn't print or input Unicode

sorin 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. -- _

[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation

Eli Bendersky 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

[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation

Georg Brandl added the comment: Sure. -- nosy: +georg.brandl ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation

Eli Bendersky added the comment: Committed the fix to py3k in r88009 -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation

Eli Bendersky added the comment: Backport to release31 branch in r88010 -- resolution: -> fixed status: open -> closed ___ Python tracker ___ __

[issue10913] Deprecate PyEval_AcquireLock() and PyEval_ReleaseLock()

New submission from Antoine Pitrou : 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 exa

[issue8754] ImportError: quote bad module name in message

Georg Brandl added the comment: Won't make it into 3.2. -- priority: deferred blocker -> high versions: +Python 3.3 -Python 3.2 ___ Python tracker ___ ___

[issue3243] Support iterable bodies in httplib

Georg Brandl added the comment: Anything left to do here, Senthil? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue10913] Deprecate PyEval_AcquireLock() and PyEval_ReleaseLock()

Antoine Pitrou added the comment: Done in r88018. -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker ___ __

[issue10914] Python sub-interpreter test

New submission from Antoine Pitrou : 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

[issue1977] Python reinitialization test

Antoine Pitrou added the comment: See also #10914. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation

Nick Coghlan 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 thr

[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation

Eli Bendersky 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 i

[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation

Nick Coghlan 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:

[issue10915] Make the PyGILState API compatible with multiple interpreters

New submission from Antoine Pitrou : 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 st

[issue10915] Make the PyGILState API compatible with multiple interpreters

Changes by Antoine Pitrou : -- nosy: +ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue10914] Python sub-interpreter test

Changes by Antoine Pitrou : -- nosy: +amaury.forgeotdarc, ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue10916] mmap segfault

New submission from Ross Lagerwall : 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

[issue5800] make wsgiref.headers.Headers accept empty constructor

Changes by SilentGhost : -- status: open -> languishing ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue10915] Make the PyGILState API compatible with multiple interpreters

Antoine Pitrou 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 track

[issue9532] pipe.read hang, when calling commands.getstatusoutput in multi-threading code of python 2.4

Changes by R. David Murray : -- resolution: -> out of date stage: -> committed/rejected status: open -> closed ___ Python tracker ___ ___

[issue10908] Improvements to trace._Ignore

SilentGhost 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

[issue10916] mmap segfault

Antoine Pitrou 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 __

[issue10896] trace module compares directories as strings (--ignore-dir)

Changes by SilentGhost : -- status: closed -> open ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue10908] Improvements to trace._Ignore

Changes by Alexander Belopolsky : -- nosy: +eli.bendersky ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue10896] trace module compares directories as strings (--ignore-dir)

Changes by SilentGhost : -- nosy: -SilentGhost ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue10908] Improvements to trace._Ignore

Changes by SilentGhost : -- dependencies: +trace module compares directories as strings (--ignore-dir) type: -> performance ___ Python tracker ___ __

[issue10915] Make the PyGILState API compatible with multiple interpreters

Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file20416/gilstateinterp.patch ___ Python tracker ___ ___ Python-bugs-list ma

[issue10915] Make the PyGILState API compatible with multiple interpreters

Changes by Antoine Pitrou : -- stage: needs patch -> patch review Added file: http://bugs.python.org/file20417/gilstateinterp.patch ___ Python tracker ___ ___

[issue10694] zipfile.py end of central directory detection not robust

Georg Brandl added the comment: Not important enough to block release. -- priority: deferred blocker -> critical ___ Python tracker ___ _

[issue3243] Support iterable bodies in httplib

Changes by Georg Brandl : -- priority: deferred blocker -> critical ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue8746] os.chflags() and os.lchflags() are not built when they should be be

Changes by Georg Brandl : -- priority: deferred blocker -> critical ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue10736] test_ttk_guionly fails on OS X using ActiveState Tcl 8.5.9 (Cocoa)

Changes by Georg Brandl : -- priority: deferred blocker -> critical ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue10734] test_ttk failure under Windows

Changes by Georg Brandl : -- priority: deferred blocker -> critical ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue8957] strptime(.., '%c') fails to parse output of strftime('%c', ..) in some locales

Alexander Belopolsky added the comment: On Sat, Jan 15, 2011 at 2:20 AM, Eli Bendersky 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 implementat

[issue8957] strptime(.., '%c') fails to parse output of strftime('%c', ..) in some locales

Alexander Belopolsky added the comment: 6. datetime.find(self.f_month[m]) >= 0 -> self.f_month[m] in datetime Python is not C! -- ___ Python tracker ___

[issue2275] urllib2 header capitalization

Rui Carmo 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 mangli

[issue3243] Support iterable bodies in httplib

Senthil Kumaran 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 m

[issue10916] mmap segfault

Antoine Pitrou added the comment: It also needed fixing on Windows: committed in r88036, r88037 and r88038. -- ___ Python tracker ___ ___

[issue3243] Support iterable bodies in httplib

Xuanji Li added the comment: Yes, I think we should close it. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue8957] strptime(.., '%c') fails to parse output of strftime('%c', ..) in some locales

Eli Bendersky 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 onl

[issue3243] Support iterable bodies in httplib

Senthil Kumaran 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 __

[issue3243] Support iterable bodies in httplib

Changes by Senthil Kumaran : -- priority: low -> normal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://m

[issue8957] strptime(.., '%c') fails to parse output of strftime('%c', ..) in some locales

Alexander Belopolsky 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 ___

[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation

Changes by Éric Araujo : -- nosy: +Devin Jeanpierre ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue10915] Make the PyGILState API compatible with multiple interpreters

Graham Dumpleton 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

[issue10915] Make the PyGILState API compatible with multiple interpreters

Antoine Pitrou 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 f

[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation

Changes by Raymond Hettinger : -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation

Raymond Hettinger 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 try

[issue10915] Make the PyGILState API compatible with multiple interpreters

Nick Coghlan 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

[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation

Nick Coghlan 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

[issue10903] ZipExtFile:_update_crc fails for CRC >= 0x80000000

Nadeem Vawda 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 b"a\n" (CRC 0xDDEAA107). -- nosy: +nvawda ___ Python tracker

[issue10915] Make the PyGILState API compatible with multiple interpreters

Antoine Pitrou 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 existen

[issue10915] Make the PyGILState API compatible with multiple interpreters

Graham Dumpleton 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

[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation

Raymond Hettinger 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@pytho

[issue10915] Make the PyGILState API compatible with multiple interpreters

Graham Dumpleton 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

[issue8957] strptime(.., '%c') fails to parse output of strftime('%c', ..) in some locales

Eli Bendersky 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 Py

[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation

Eli Bendersky 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 clari

[issue10912] PyObject_RichCompare differs in behaviour from PyObject_RichCompareBool ; difference not noted in documentation

Raymond Hettinger 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. -

[issue10917] PEP 333 link to CGI specification is broken

New submission from anatoly techtonik : 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 spe