[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)

Mark Dickinson added the comment: It might be instructive to look at how NumPy itself manages sharing of ndarray data and ownership of the corresponding structs. I meant to find time to look at this over the break. -- ___ Python tracker

[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)

Mark Dickinson added the comment: BTW, I agree that it looks as though significant changes might be needed. I wonder whether it would make sense to exclude the Py_buffer struct fro m the Stable ABI PEP for now. -- ___ Python tracker

[issue10760] tarfile doesn't handle sysfs well

Changes by Lars Gustäbel : -- assignee: -> lars.gustaebel components: +Library (Lib) -None nosy: +lars.gustaebel ___ Python tracker ___ _

[issue10761] tarfile.extractall fails to overwrite symlinks

Changes by Lars Gustäbel : -- assignee: -> lars.gustaebel nosy: +lars.gustaebel ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue10516] Add list.clear() and list.copy()

Changes by Georg Brandl : -- stage: needs patch -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue10821] gethostbyname(gethostname()) is wrong when IP is changed

New submission from Petr Sklenář : version: tried python 2.6 on rhel55 tried python-2.7-8 on fedora14 Steps to Reproduce: 1. install machine, have a fixed hostname up to mac address 1.1.1.1 = machine.something.com 2. wait a week or longer when your local dhcp server changes your IP but not host

[issue5945] PyMapping_Check returns 1 for lists

Antoine Pitrou added the comment: > Right, calling PyMapping_Check() was never particularly reliable, and > extension modules depending on it probably always had subtle bugs. > Perhaps it would be nice if we provided a C API to at least some of > the ABC package. In the meantime, would it be

[issue10821] gethostbyname(gethostname()) is wrong when IP is changed

Georg Brandl added the comment: This is not a Python issue. gethostbyname() and gethostname() are just a wrapper for the OS's functions of the same name; you'd get the same result when coding the example in C. -- nosy: +georg.brandl resolution: -> invalid status: open -> closed ___

[issue10819] ValueError on repr(closed_socket_file)

STINNER Victor added the comment: Fixed by r87730. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-

[issue10785] parser: store the filename as an unicode object

STINNER Victor added the comment: err_clear() should set err->filename to NULL. -- versions: -Python 3.2 ___ Python tracker ___ ___

[issue10822] test_getgroups failure under Solaris

New submission from Antoine Pitrou : Under OpenSolaris, I get the following failure: $ pfexec ./python -m test test_posix [1/1] test_posix test test_posix failed -- Traceback (most recent call last): File "/home/antoine/py3k/cc/Lib/test/test_posix.py", line 402, in test_getgroups set(posi

[issue9344] please add posix.getgrouplist()

Antoine Pitrou added the comment: I can't say anything about the functionality, but the patch looks good to me (works under Linux and Solaris - the latter missing getgrouplist()). -- nosy: +pitrou stage: needs patch -> commit review ___ Python track

[issue9535] Pending signals are inherited by child processes

Antoine Pitrou added the comment: > Yes I'd do it in PyOS_AfterFork. Simpler patch based on gdb's > attached. Private functions shouldn't use the PyXX_CamelCase() convention :) Otherwise, looks good. -- ___ Python tracker

[issue8458] buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad file descriptor

Antoine Pitrou added the comment: > that race condition, if thats what this is, is likely not OS X > specific. the child process could complete or close its fds before we > reach that code on any OS. We either need to guard these > io.open(p2c*...) lines against EBADF OSError's or we should cr

[issue8992] convertsimple() doesn't need to call converterr() if an exception was already raised

STINNER Victor added the comment: Fixed by r87732 -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bu

[issue8992] convertsimple() doesn't need to call converterr() if an exception was already raised

STINNER Victor added the comment: (and by r87731) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue8719] buildbot: segfault on FreeBSD (signal 11)

STINNER Victor added the comment: > That may be what you meant, but "installed on this host" made me think > I could do something external on the buildbot which I don't > think would work given that the module has to be called from within > the tests themselves? If you install faulthandler on

[issue10823] "conversion from 'Py_ssize_t' to 'int', possible loss of data" in various files

New submission from STINNER Victor : On "AMD64 Windows Server 2008 3.x", there are many "conversion from 'Py_ssize_t' to 'int', possible loss of data" errors: Python\Python-ast.c(3403) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data Python\Python-ast

[issue10823] "conversion from 'Py_ssize_t' to 'int', possible loss of data" in various files

Changes by Antoine Pitrou : -- resolution: -> duplicate status: open -> closed superseder: -> Compilation warnings under x64 Windows ___ Python tracker ___

[issue9566] Compilation warnings under x64 Windows

Changes by Ralf Schmitt : -- nosy: +schmir ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.or

[issue9566] Compilation warnings under x64 Windows

STINNER Victor added the comment: r87733 fixes some conversions in: * Python/pythonrun.c * Objects/codeobject.c * Objects/typeobject.c * Objects/listobject.c * Modules/_ctypes/_ctypes.c * Modules/sha512module.c * Modules/unicodedata.c * Modules/selectmodule.c * Modules/pyexpat.c * Mod

[issue10512] regrtest ResourceWarning - unclosed sockets and files

Nadeem Vawda added the comment: r87710 introduces a ResourceWarning in test_threading. Fix attached. -- ___ Python tracker ___ ___ Py

[issue10512] regrtest ResourceWarning - unclosed sockets and files

Changes by Nadeem Vawda : Added file: http://bugs.python.org/file20255/test_threading.diff ___ Python tracker ___ ___ Python-bugs-list mailing

[issue9611] FileIO not 64-bit safe under Windows

STINNER Victor added the comment: r87734 fixes stdprinter.write(). -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue9554] test_argparse.py: use new unittest features

Sandro Tosi added the comment: Hi, I've applied the patch and it goes fine (except for some offsets and the fact it was generated inside Lib/test) and the tests are still all ok. I'd suggest to apply it. -- nosy: +sandro.tosi stage: -> commit review _

[issue9671] test_executable_without_cwd fails: AssertionError: 1 != 47

Sandro Tosi added the comment: Ok, so the situation is: - I've test on debian sid and it works fine - Dave on a Fedora 13 and it works - I asked a couple of guys to try it on their systems, that's Fedora14 and Gentoo and it works fine So I think we can conclude it's a Fedora Core 4 specific p

[issue10824] urandom should not block

New submission from Michal Čihař : Currently if /dev/urandom does not provide any data, unradom() call is just stuck infinitely waiting for data. I actually faced this issue when /dev/urandom was empty regular file (due to bug in pbuilder, but I don't think it matters how it did happen) and ur

[issue10825] use assertIsNone(...) instead of assertEquals(None, ...)

New submission from Sandro Tosi : Hello, after I saw that in issue9554, I created a small patch to replace all assertEquals(None, ...) with assertIsNone(...) It's not rocket science, but I think it makes test suite "better" and leverage new unittest features. Cheers, Sandro --

[issue10824] urandom should not block

Antoine Pitrou added the comment: This would change semantics of the library call, though. I see two possible solutions: - do nothing and let users tackle the issue if necessary (e.g. by calling open() themselves and using select() on the resulting fd) - add an optional "blocking" parameter to

[issue10825] use assertIsNone(...) instead of assertEquals(None, ...)

Antoine Pitrou added the comment: Looks good. -- nosy: +pitrou, r.david.murray ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue10824] urandom should not block

Michal Čihař added the comment: Well in this particular case (/dev/urandom is regular file), it might make sense to simply raise NotImplementedError -- ___ Python tracker ___ _

[issue10824] urandom should not block

Antoine Pitrou added the comment: > Well in this particular case (/dev/urandom is regular file), it might > make sense to simply raise NotImplementedError IMO it would be quite fragile to try to detect regular files vs special files. I suppose you noticed the issue quite quickly anyway, since y

[issue10824] urandom should not block

Georg Brandl added the comment: Is it really necessary to do something about this? /dev/urandom being a regular file is clearly a bug in your system configuration, and I don't want to know what all the other programs will do that rely on it... -- nosy: +georg.brandl

[issue10824] urandom should not block

Charles-Francois Natali added the comment: >From the documentation: "This function returns random bytes from an OS-specific randomness source." In your case, this problem shows up because of an OS misconfiguration : in that case, the behaviour is undefined (not much Python can do about it). No

[issue10824] urandom should not block

Michal Čihař added the comment: Yes, it was blocking, but deep in some program (which was actually called by dpkg postinst script), so it took some time to figure out. I don't think it's that fragile to figure out whether it is regular file using os.path.isfile. Indeed it was bug in a system

[issue10824] urandom should not block

Antoine Pitrou added the comment: > Note that since /dev/urandom is used, with a properly configured > system, this should never block Ok, suggesting closing then. -- resolution: -> invalid status: open -> pending ___ Python tracker

[issue9554] test_argparse.py: use new unittest features

Changes by Antoine Pitrou : -- nosy: +r.david.murray ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail

[issue10826] pass_fds sometimes fails

New submission from Antoine Pitrou : This happens selectively (and intermittently) on the Solaris buildbot: test_pass_fds (test.test_subprocess.POSIXProcessTestCase) ... -- maxfd = 256 [36787 refs] -- fds that should have been closed: {5, 6, 7, 8, 9, 10, 11, 12, 13} -- fds that remained open:

[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)

Nick Coghlan added the comment: Agreed. I'll put something on python-dev about that, so MvL sees it. -- ___ Python tracker ___ ___ Py

[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)

Nick Coghlan added the comment: More direct - added MvL to nosy list. Martin, we would like to exclude Py_buffer from the stable ABI for Python 3.2, until we have a chance to thrash out the missing pieces of the documentation for 3.3. I *think* it is a documentation problem, but until we're c

[issue10826] pass_fds sometimes fails

Antoine Pitrou added the comment: Another (perhaps more likely) possibility is that fd 5 was properly closed, but another one created at startup by the child Python interpreter. How could we diagnose that? -- ___ Python tracker

[issue10001] ~Py_buffer.obj field is undocumented, though not hidden

Nick Coghlan added the comment: Closing as a dupe of 10181, but transferring Lenard's comments over there. -- resolution: -> duplicate status: open -> closed superseder: -> Problems with Py_buffer management in memoryobject.c (and elsewhere?) ___

[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags

Antoine Pitrou added the comment: A new patch combining Ross' test with the simple approach from issue 976613. Works under Linux, OpenSolaris and Windows. -- Added file: http://bugs.python.org/file20257/nonblock2.patch ___ Python tracker

[issue10181] Problems with Py_buffer management in memoryobject.c (and elsewhere?)

Nick Coghlan added the comment: >From Lenard Lindstrom in issue 10001 (closed as dupe of this issue): The ~Py_buffer.obj field is undocumented. Yet memoryview, that acts as a wrapper, includes the field in gc traversal. Also, if the field is not initialized by bf_getbuffer its value can be in

[issue985064] plistlib crashes too easily on bad files

Mher Movsisyan added the comment: I've replaced plistlib.InvalidPlistError with ValueError -- Added file: http://bugs.python.org/file20258/plist_validation_v2.diff ___ Python tracker _

[issue9566] Compilation warnings under x64 Windows

Amaury Forgeot d'Arc added the comment: r87733 in pyexpat.c modified a call to PyErr_Format with a %zi format code. This format does not seem to be supported. %zd should be used instead. -- nosy: +amaury.forgeotdarc ___ Python tracker

[issue5945] PyMapping_Check returns 1 for lists

Guido van Rossum added the comment: > In the meantime, would it be reasonable to add the moral equivalent > of `hasattr(type(op), 'items')` to PyMapping_Check()? That all depends on what it is used for. Which is hard to say without someone following more of the links that Raymond posted. ---

[issue5945] PyMapping_Check returns 1 for lists

Antoine Pitrou added the comment: Modules/posixmodule.c: uses PyMapping_Size(), PyMapping_Keys() and PyMapping_Values() to parse an environment mapping (for execve() and friends). PyFrame_New(): validates the "locals" argument in pydebug mode (only used for module-level code). Note that funct

[issue1075356] exceeding obscure weakproxy bug

Amaury Forgeot d'Arc added the comment: It's not fixed. range() now uses the tp_index slot, in weakrefs this becomes: WRAP_UNARY(proxy_index, PyNumber_Index) and indeed PyNumber_Index does not accept strings. But try with time.sleep() instead; here the line WRAP_UNARY(proxy_float, PyNum

[issue6643] Throw away more radioactive locks that could be held across a fork in threading.py

Nadeem Vawda added the comment: r87710 introduces an AttributeError in test_thread's TestForkInThread test case. If os.fork() is called from a thread created by the _thread module, threading._after_fork() will get a _DummyThread (with no _block attribute) as the current thread. I've attached

[issue6643] Throw away more radioactive locks that could be held across a fork in threading.py

Changes by Antoine Pitrou : -- status: closed -> open ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue10827] Functions in time module should support year < 1900 when accept2dyear = 0

New submission from Alexander Belopolsky : """ > http://docs.python.org/library/time.html#time-y2kissues > "Values 100–1899 are always illegal." Why are these values illegal? The GNU libc accepts year in [1900-2^31; 2^31-1] (tm_year in [-2147483648; 2147481747]). If time.accept2dyear=False, we

[issue8013] time.asctime segfaults when given a time in the far future

Alexander Belopolsky added the comment: Committed in r87736. I opened a separate issue #10827 to address the lower bound. -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed ___ Python tracker

[issue985064] plistlib crashes too easily on bad files

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

[issue8013] time.asctime segfaults when given a time in the far future

Georg Brandl added the comment: Thanks! -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue10827] Functions in time module should support year < 1900 when accept2dyear = 0

Alexander Belopolsky added the comment: > The system libc would raise an error (return NULL) if it doesn't know > how to format years older than 1900. As experience with asctime has shown, system libc can do whatever it pleases with out of range values including overrunning a fixed size buffer

[issue10827] Functions in time module should support year < 1900 when accept2dyear = 0

Changes by Andreas Stührk : -- nosy: +Trundle ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue10751] REMOTE_USER and Remote-User collision in wsgiref

Alex Raitz added the comment: Yes, I was referring to REMOTE_USER, apologies for the conflation with HTTP_REMOTE_USER, which was one of the HTTP headers that a proxy which we were testing was setting. The customer that reported this issue to us was using FireFox with Tamper Data to set REMOT

[issue10827] Functions in time module should support year < 1900 when accept2dyear = 0

Alexander Belopolsky added the comment: I am attaching a patch. While working on the patch, I noticed that although time.accept2dyear is documented as boolean, the current code expects int and treats any non-int including True as 0: >>> time.accept2dyear = True; time.asctime((99,) + (0,)*8)

[issue6643] Throw away more radioactive locks that could be held across a fork in threading.py

Gregory P. Smith added the comment: eek, thanks for noticing that! r87740 fixes this in py3k. backporting to 3.1 and 2.7 now. -- nosy: +barry priority: normal -> release blocker ___ Python tracker ___

[issue1170766] weakref.proxy incorrect behaviour

Armin Rigo added the comment: Not for me (the last example I posted, on 2.7 head). But I will not fight for this. -- ___ Python tracker ___ _

[issue5945] PyMapping_Check returns 1 for lists

Guido van Rossum added the comment: The question is, if PyMapping_Check() returns True, and a list is passed, will the code segfault or raise an exception? A segfault would be unacceptable; an exception would be acceptable assuming that the code would have raised an exception anyway if PyMap

[issue10827] Functions in time module should support year < 1900 when accept2dyear = 0

Alexander Belopolsky added the comment: On Tue, Jan 4, 2011 at 1:30 PM, Alexander Belopolsky wrote: .. > This is clearly a bug.  (Although Y2K note contradicts time.accept2dyear > documentation.) > PyObject_IsTrue() may fail - this is probably the reason for the current odd logic. My patch s

[issue6643] Throw away more radioactive locks that could be held across a fork in threading.py

Gregory P. Smith added the comment: r87741 3.1 r87742 2.7 -- resolution: accepted -> fixed status: open -> closed ___ Python tracker ___ _

[issue5945] PyMapping_Check returns 1 for lists

Antoine Pitrou added the comment: Exceptions seem to be raised (for code that can be exercised in Python), but not very obvious ones: >>> eval("x", {}, []) Traceback (most recent call last): File "", line 1, in File "", line 1, in TypeError: list indices must be integers, not str $ ./py

[issue8458] buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad file descriptor

Gregory P. Smith added the comment: Off the top of my head I don't _think_ so.. at least for posix. I'm not sure about the implications of the if mswindows: code in there though. -- ___ Python tracker ___

[issue10827] Functions in time module should support year < 1900 when accept2dyear = 0

Georg Brandl added the comment: But if it fails, why not just let it fail? -- nosy: +georg.brandl ___ Python tracker ___ ___ Python-b

[issue8458] buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad file descriptor

Antoine Pitrou added the comment: Well we could try a run of it on the buildbots, then :) -- ___ Python tracker ___ ___ Python-bugs-li

[issue5945] PyMapping_Check returns 1 for lists

Guido van Rossum added the comment: It looks like PyMapping_Check() already checks for the presence of a fairly arbitrary special operation (mp_subscript). It sounds fine to replace that with a check for the presence of a keys() or items() method (I'm not sure which one is more representativ

[issue10827] Functions in time module should support year < 1900 when accept2dyear = 0

Alexander Belopolsky added the comment: On Tue, Jan 4, 2011 at 1:49 PM, Georg Brandl wrote: .. > But if it fails, why not just let it fail? > Sure. That's what I meant by fixing the patch. See new patch attached. -- Added file: http://bugs.python.org/file20261/issue10827a.diff

[issue8458] buildbot: test_cmd_line failure on Tiger: [Errno 9] Bad file descriptor

Antoine Pitrou added the comment: Trying it in r87744. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue10826] pass_fds sometimes fails

Antoine Pitrou added the comment: Happened also on the OpenIndiana buildbot: http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.x/builds/492/steps/test/logs/stdio -- ___ Python tracker

[issue9738] Document the encoding of functions bytes arguments of the C API

Alexander Belopolsky added the comment: Victor, Here is an interesting case for your collection: PyDict_GetItemString. Note that it is documented as not setting error, but in fact it may if encoding fails. This rarely an issue because most uses of PyDict_GetItemString are with an ASCII str

[issue10828] Cannot use nonascii utf8 in names of files imported from

New submission from ingemar : I have a set of programs written for Python3.1 and running well on Kubuntu. The source files are located on a Samba server on a Kubuntu box. Several of the programs contain Python/PyQt code to start other programs in the set ( QtCore.QProcess().startDetached(k

[issue8052] subprocess close_fds behavior should only close open fds

Ross Lagerwall added the comment: Does this mean that it's better to call the close() syscall 1000 or 1000 times rather than listing the open fds & closing say a handful? On Linux, the listdir function results in an open() syscall, 2 or so getdents() calls and a close() call - could this

[issue10824] urandom should not block

Martin v. Löwis added the comment: I wonder why reading from /dev/urandom has a loop in the first place, though - isn't it guaranteed that you can read as many bytes as you want in one go? This goes back to #934711, and apparently, even the original patch had the loop - for reasons that got n

[issue9566] Compilation warnings under x64 Windows

STINNER Victor added the comment: #10823 has been marked as a duplicate of this issue. -- ___ Python tracker ___ ___ Python-bugs-list

[issue9419] RUNSHARED needs LDFLAGS

Roumen Petrov added the comment: LDFLAGS make no sense for run time. The patch seems to me bogus. -- ___ Python tracker ___ ___ Python

[issue10824] urandom should not block

R. David Murray added the comment: Agreed that the original issue is invalid. So either the title should be changed so it can be used to address Martin's question, or it should be closed. -- nosy: +r.david.murray ___ Python tracker

[issue10828] Cannot use nonascii utf8 in names of files imported from

R. David Murray added the comment: Have you tried 3.2b2? -- nosy: +haypo, r.david.murray type: -> behavior ___ Python tracker ___ __

[issue9566] Compilation warnings under x64 Windows

Martin v. Löwis added the comment: haypo: please avoid introducing explicit casts (such as the one in pyexpat.c). Use SAFECASTs instead. If you are absolutely certain that a cast cannot possibly truncate, add a comment explaining why that is. In the specific case, I think it actually *is* pos

[issue10824] urandom should not block

Martin v. Löwis added the comment: Closing it. It seems that people feel more safe when urandom loops until it has enough data (see http://stackoverflow.com/questions/4598507/dev-urandom-maximum-size/4598534#4598534). I might still pursue this idea, but in a different issue. -- statu

[issue10824] urandom should not block

Charles-Francois Natali added the comment: > Martin v. Löwis added the comment: > > I wonder why reading from /dev/urandom has a loop in the first place, though > - isn't it guaranteed that you can read as many bytes as you want in one go? > This goes back to #934711, and apparently, even the

[issue9566] Compilation warnings under x64 Windows

STINNER Victor added the comment: amaury> r87733 in pyexpat.c modified a call to PyErr_Format with a %zi amaury> format code. This format does not seem to be supported. %zd amaury> should be used instead. Oh, that's surprising. Why %zd is supported but not %zi? PyUnicode_FromFormatV() supports

[issue9566] Compilation warnings under x64 Windows

STINNER Victor added the comment: > Python\pystrtod.c(902) : 'function' : conversion from 'Py_ssize_t' to 'int', > possible loss of data > Python\pystrtod.c(1023) : '=' : conversion from 'Py_ssize_t' to 'int', > possible loss of data I asked dmalcolm on IRC if int or Py_ssize_t should be used

[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags

Martin v. Löwis added the comment: I think this patch (nonblock2.patch) is wrong. If I have a non-blocking server socket on *BSD, and do accept, with no default timeout: IIUC, under the patch, I will get a blocking connection socket. However, according to the operating system API, I'm entitle

[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags

Antoine Pitrou added the comment: > I think this patch (nonblock2.patch) is wrong. If I have a > non-blocking server socket on *BSD, and do accept, with no default > timeout: IIUC, under the patch, I will get a blocking connection > socket. However, according to the operating system API, I'm ent

[issue10751] REMOTE_USER and Remote-User collision in wsgiref

Phillip J. Eby added the comment: I'm still baffled. How does this matter to anything? The HTTP headers you describe would end up in an HTTP_REMOTE_USER environment variable, with no impact on REMOTE_USER. REMOTE_USER could only be set by an actual web server, not via an HTTP header. So I

[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags

Antoine Pitrou added the comment: > Antoine Pitrou added the comment: > > > I think this patch (nonblock2.patch) is wrong. If I have a > > non-blocking server socket on *BSD, and do accept, with no default > > timeout: IIUC, under the patch, I will get a blocking connection > > socket. However

[issue10824] urandom should not block

Martin v. Löwis added the comment: > "It's a bug in random.c that doesn' t check for signal pending inside the > read(2) code, so you have no chance to kill the process via signals until > the read(2) syscall is finished, and it could take a lot of time before > return, if the buffer given to th

[issue10751] REMOTE_USER and Remote-User collision in wsgiref

Alex Raitz added the comment: Per the first line of my previous comment, please ignore HTTP_REMOTE_USER. The risk is that if the proxy does not place the user-supplied 'remote-user=VALUE1' before the proxy-supplied 'REMOTE_USER=VALUE2', wsgiref will overload REMOTE_USER with the value of REMO

[issue9566] Compilation warnings under x64 Windows

Martin v. Löwis added the comment: > MvL> If you are absolutely certain that a cast cannot possibly truncate, > MvL> add a comment explaining why that is. > > Ah yes, sorry, I forgot to add a comment: done in r87746. But the comment is actually wrong: It says len <= buf_size <= INT_MAX (see

[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags

Martin v. Löwis added the comment: > Well, either the defaulttimeout should have the priority over the parent > socket's settings (your argument in msg125135), or it shouldn't. I'm > fine with both, but I think any more complicated combination would end > up puzzling for the user :) Applying th

[issue10751] REMOTE_USER and Remote-User collision in wsgiref

Phillip J. Eby added the comment: You say it "would" do this. Have you actually *tested* it? Looking at the code in wsgiref again, I don't think it does what you think it does. The '_' substitution is done to keyword arguments for header *parameters* only; it's not done to header *names*.

[issue10828] Cannot use nonascii utf8 in names of files imported from

STINNER Victor added the comment: I think that this issue is a duplicate of #8611 (and #9425), it should be fixed in Python 3.2. -- ___ Python tracker ___ _

[issue5485] pyexpat has no unit tests for UseForeignDTD functionality

Sandro Tosi added the comment: Hi all, I think this patch would be nice to be applied, but before start working on it (like adapt it to new code & stuff), I'd like to know if we are really targetting 2.7 or should we instead targer 3.3. Cheers, Sandro -- nosy: +sandro.tosi stage: ->

[issue5485] pyexpat has no unit tests for UseForeignDTD functionality

Martin v. Löwis added the comment: I don't think we should adding tests to 2.7, perhaps unless there are also fixes for it. So targetting 3.3+ only seems reasonable. -- ___ Python tracker _

[issue9566] Compilation warnings under x64 Windows

STINNER Victor added the comment: > But the comment is actually wrong: It says > > len <= buf_size <= INT_MAX (see above) > > however, len > buf_size may happen, after this code: > > if (len > buf_size) { > PyErr_Format(PyExc_ValueError, > "read() returned too

[issue9566] Compilation warnings under x64 Windows

Martin v. Löwis added the comment: > Oh. Not only is the comment is wrong, but the code is also wrong. It > should return a negative value on error, whereas it returns the string > length which is always positive (except on a unlikely Py_ssize_t => int > overflow?). Right. See msg125367. -

[issue10751] REMOTE_USER and Remote-User collision in wsgiref

Alex Raitz added the comment: I had previously tested it against simple_server. However, in reviewing my test, I realized that you are correct that wsgiref headers is not misbehaving. It appears that in simple_server, the values of remote-user and remote_user both end up in HTTP_REMOTE_USE

  1   2   >