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

Changes by Lenard Lindstrom : -- nosy: +kermode ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue10812] Add some posix functions

Ross Lagerwall added the comment: This patch: Fixes test_lutimes(), Ignores a posix_fallocate() failure on Solaris due to ZFS, Changes readv() & writev() signatures such that they take sequences instead of tuples, Changes readv() so that it takes a number of writable buffers, fills them and r

[issue2193] Cookie Colon Name Bug

karl added the comment: Ah the server is back the rules for the User Agents are defined here http://tools.ietf.org/html/draft-ietf-httpstate-cookie#section-5 -- ___ Python tracker _

[issue2193] Cookie Colon Name Bug

karl added the comment: The rules for parsing and setting the cookies are different. Server should always produce strict cookies only. So the production rules are to be done accordingly to the specification. Adam Barth is working right now on an update of the "HTTP State Management Mechanis

[issue10818] pydoc: Remove old server and tk panel

Ron Adam added the comment: Here is a patch for this. Not much to it as the hard parts were already done. Apparently there was no tests for this, test_pydoc still passes without it. Does there need to be any messages for the -g option? Pydoc help is displayed in the case -g is used. That a

[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0

Glenn Linderman added the comment: R. David said: >From looking over the cgi code it is not clear to me whether Pierre's approach >is simpler or more complex than the alternative approach of starting with >binary input and decoding as appropriate. From a consistency perspective I >would pref

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

Changes by STINNER Victor : Removed file: http://bugs.python.org/file20184/parser_filename_obj-2.patch ___ Python tracker ___ ___ Python-bugs-

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

Changes by STINNER Victor : Removed file: http://bugs.python.org/file20180/parser_filename_obj.patch ___ Python tracker ___ ___ Python-bugs-li

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

STINNER Victor added the comment: Version 3 of the patch to fix also #9319. -- Added file: http://bugs.python.org/file20271/parser_filename_obj-3.patch ___ Python tracker ___ __

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

ingemar added the comment: Have I tried 3.2b2? No. I will have to wait for 3.2, or more exactly for a Windows installer for PyQt for 3.2 to become available. Compiling that on Windows is beyond my resources and experience. I will make a point to tell you then. --

[issue10512] regrtest ResourceWarning - unclosed sockets and files

STINNER Victor added the comment: > r87736 introduces another DeprecationError; this time in test_time (line 150; > s/assertEquals/assertEqual/). Fixed by r87759. -- ___ Python tracker __

[issue10512] regrtest ResourceWarning - unclosed sockets and files

STINNER Victor added the comment: > r87710 introduces a ResourceWarning in test_threading. Fix attached. Fixed by r87757 (I wrote a different patch). -- ___ Python tracker ___

[issue10756] Error in atexit._run_exitfuncs [...] Exception expected for value, str found

STINNER Victor added the comment: Commited as r87755+r87758. Wait for the buildbot before backporting to other versions. -- nosy: +haypo ___ Python tracker ___

[issue10833] Replace %.100s by %s in PyErr_Format(): the arbitrary limit of 500 bytes is outdated

STINNER Victor added the comment: Woops, I didn't want to do it, but I already commited the simple part of this issue (U format, eg. %.100U): r87753. -- ___ Python tracker ___

[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0

R. David Murray added the comment: Here is a modified version of the unittest file from unittest.zip that can be run against Pierre's code (it feeds FieldStorage a text stream with a buffer). Running the tests require the data files from the zip. They do not pass, in a very different way fro

[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0

R. David Murray added the comment: A day late, but I've looked at the patch. Now, I'm not all that knowledgeable about CGI, so other people will probably want to chime in here First, I'm uploading a new version of the patch as an svn diff (can be applied to a checkout using 'patch -p0 Fr

[issue10832] Add support of bytes objects in PyBytes_FromFormatV()

STINNER Victor added the comment: Patch implementing this feature. It only supports bytes. -- keywords: +patch Added file: http://bugs.python.org/file20268/pybytes_fromformat_y.patch ___ Python tracker ___

[issue10829] PyUnicode_FromFormatV() bugs with "%" and "%%" format strings

Changes by STINNER Victor : Removed file: http://bugs.python.org/file20262/pyunicode_fromformatv.patch ___ Python tracker ___ ___ Python-bugs-

[issue10833] Replace %.100s by %s in PyErr_Format(): the arbitrary limit of 500 bytes is outdated

STINNER Victor added the comment: use_format.patch is a patch to avoid PyOS_snprintf() with a fixed buffer: use directly PyUnicode_FromFormat(), PyErr_Format() or PySys_FormatStderr() instead. This patch is just a draft, it should be tested :-) There are other calls to PyOS_snprintf() that ca

[issue10833] Replace %.100s by %s in PyErr_Format(): the arbitrary limit of 500 bytes is outdated

New submission from STINNER Victor : Guido created the "convenience function" PyErr_Format() 13 years ago (r7580) with a naive implementation using char buffer[500] and vsprintf(). He added a comment: /* Caller is responsible for limiting the format */ Ok, that was true 13 years ago. But toda

[issue10832] Add support of bytes objects in PyBytes_FromFormatV()

New submission from STINNER Victor : It would be very practical use have a format, eg. '%y', to accept bytes object in PyBytes_FromFormatV(). Example (extracted from posixmodule.c): k = PyBytes_AsString(key2); v = PyBytes_AsString(val2); len = PyBytes_GET_SIZE(key2) + P

[issue10829] PyUnicode_FromFormatV() bugs with "%" and "%%" format strings

STINNER Victor added the comment: PyBytes_FromFormatV() has the same issue. -- ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue4953] cgi module cannot handle POST with multipart/form-data in 3.0

Changes by STINNER Victor : -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue10831] PyUnicode_FromFormatV() doesn't support %li, %lli, %zi

Changes by STINNER Victor : -- nosy: +amaury.forgeotdarc ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:/

[issue10831] PyUnicode_FromFormatV() doesn't support %li, %lli, %zi

New submission from STINNER Victor : PyUnicode_FromFormatV() supports %d, %ld, %lld, %zd, %u, %lu, %llu, %zu, %i. But it doesn't support %li, %lli, %zi. Attached patch implements the 3 missing formats, and add unit tests for all these formats. -- components: Interpreter Core, Unicode

[issue10790] Header.append's charset logic is bogus, 'shift_jis' and "euc_jp' don't work as charsets

R. David Murray added the comment: Committed to py3k in r87750 and 3.1 in r87751. -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker __

[issue10830] PyUnicode_FromFormatV("%c") doesn't support non-BMP characters on narrow build

New submission from STINNER Victor : PyUnicode_FromFormatV("%c") supposes that an unicode character is always stored as a single Py_UNICODE word: but that's wrong on narrow build with characters in [U+1; U+10]. Attached patch fixes this bug. See also #10829. -- components: In

[issue10829] PyUnicode_FromFormatV() bugs with "%" and "%%" format strings

STINNER Victor added the comment: Oh, my first patch was wrong: it failed on %c format (in zipimport with "%U%c%U"). The second version of the patch should be better. -- Added file: http://bugs.python.org/file20264/pyunicode_fromformatv-2.patch ___

[issue10512] regrtest ResourceWarning - unclosed sockets and files

Nadeem Vawda added the comment: r87736 introduces another DeprecationError; this time in test_time (line 150; s/assertEquals/assertEqual/). -- ___ Python tracker ___ __

[issue9566] Compilation warnings under x64 Windows

STINNER Victor added the comment: pyexpat.patch: new try, does it look better? -- keywords: +patch Added file: http://bugs.python.org/file20263/pyexpat.patch ___ Python tracker _

[issue8052] subprocess close_fds behavior should only close open fds

Antoine Pitrou added the comment: > Of course, procfs isn't standard in any case; would it be necessary to > have a fallback for systems without it? Or do all *nix systems that we > care about provide it? /proc/self doesn't exist under OpenSolaris. You have to use /proc/. And I suppose there ca

[issue8052] subprocess close_fds behavior should only close open fds

Nadeem Vawda added the comment: According to POSIX [1], if a multi-threaded program calls fork(), the child process may only use async-signal-safe system calls between fork() and exec*(). readdir() is not required to be async-safe [2], so reading /proc/self/fds in the child process is undefin

[issue10829] PyUnicode_FromFormatV() bugs with "%" and "%%" format strings

New submission from STINNER Victor : Steps 1 and 3 of PyUnicode_FromFormatV() doesn't handle the format string "%%" correctly. The loop responsible to skip the precision moves outside the format string, and the function will then read uninitialized memory. The loop: while (*++f &&

[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

[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. -

[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

[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 _

[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: ->

[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 ___ _

[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*.

[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

[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

[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

[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

[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

[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: > 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

[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

[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

[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

[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

[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

[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

[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 ___ __

[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

[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

[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

[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

[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

[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

[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

[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

[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:

[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

[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

[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

[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

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 ___

[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

[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 ___ _

[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

[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

[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 ___ _

[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 ___

[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)

[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

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

[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

[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

[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

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

[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

[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

[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

[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

[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

[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. ---

[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

[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 _

[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

[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

[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?) ___

[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

[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

[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

[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:

[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

[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

[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

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

  1   2   >