[issue10305] Cleanup up ResourceWarnings in multiprocessing

Ask Solem added the comment: ah, this is something I've seen as well, its part of a bug that I haven't created an issue for yet. -- ___ Python tracker ___ _

[issue10286] URLOpener => URLopener x2 in fix_urllib.py

Georg Brandl added the comment: Fixed in r86157. -- nosy: +georg.brandl resolution: -> fixed status: open -> closed ___ Python tracker ___ _

[issue10293] PyMemoryView object has obsolete members

Changes by Georg Brandl : -- assignee: -> pitrou nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue10198] wave module writes corrupt wav file for zero-length writeframes

Georg Brandl added the comment: I'm sorry, the actual revision is r85970. Why should it be irrelevant for other branches? -- ___ Python tracker ___ ___

[issue9015] f.write(s) for s > 2GB hangs in win64 (and win32?)

Martin Spacek added the comment: It turns out this isn't just a problem with array.array. It's a problem with Python's file.write() as well. Here's my test code: # file.write() test: FOURGBMINUS = 2**32 - 16 s = '0123456789012345' # 16 bytes longs = ''.join([s for i in xrange(FOURGBMINUS//len(

[issue9015] f.write(s) for s > 2GB hangs in win64 (and win32?)

Martin Spacek added the comment: I suppose someone should confirm this problem on Py > 2.6? -- components: +Extension Modules, Windows ___ Python tracker ___

[issue9015] f.write(s) for s > 2GB hangs in win64 (and win32?)

Amaury Forgeot d'Arc added the comment: It's still an issue with 2.7, and even with 3.2a2, see issue9611. -- nosy: +amaury.forgeotdarc ___ Python tracker ___

[issue9611] FileIO not 64-bit safe under Windows

Martin Spacek added the comment: We've got a near duplicate Issue9015. This thread seems more considered though :) Note that writing more than 2**32-1 bytes at once results in a hung process with 100% CPU in 64-bit Windows, which has to be killed with Task Manager. So I think that qualifies a

[issue9611] FileIO not 64-bit safe under Windows

Amaury Forgeot d'Arc added the comment: Fortunately, the lower-level write() has no such bug, at least when used in binary mode as FileIO does: it's almost a direct call to WriteFile(). This issue is more considered because it's not a bug in the Microsoft CRT, but in the Python implementation

[issue10308] Modules/getpath.c bugs

New submission from Hallvard B Furuseth : Patches for getpath.c in Python 2.7 and 3.2a3: 2.7 chunk#2: copy_absolute() would use uninitialized data if getcwd() failed. The fix is equivalent to what 3.2a3 does. 3.2a3 chunk#2: search_for_exec_prefix() did 'unsigned value >= 0' on the PyUnicode_As

[issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()

New submission from Hallvard B Furuseth : dlmalloc uses mremap() which is undeclared on Linux, needs _GNU_SOURCE. This can break at least on hosts where void* = 64 bits and int (default return type) 32 bits, since some bits in the return type are lost. A minimal patch is: --- Modules/_ctypes/li

[issue10297] decimal module documentation is misguiding

Changes by Baiju M : -- nosy: +baijum ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/ma

[issue10310] signed:1 bitfields rarely make sense

New submission from Hallvard B Furuseth : In Python 2.7 and 3.2a3, Modules/_io/textio.c uses signed:1 bitfields. They have value -1 or 0 in two's complement, but are not used thus here: gcc complains of = 1 overflow. If the point was that they are assigned signed values, well, unsigned:1 is pr

[issue10273] Clean-up Unittest API

Ezio Melotti added the comment: It should be noted that, if we re-use assertSameElements, the default behavior should be preserved for compatibility with 3.1, and that is different (and possibly less useful) than the one of assertItemsEqual. Ambiguities could be solved easily specifying the a

[issue10310] signed:1 bitfields rarely make sense

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

[issue10308] Modules/getpath.c bugs

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

[issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()

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

[issue10133] multiprocessing: conn_recv_string() broken error handling

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

[issue10086] test_sysconfig failure with site-packages

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

[issue2921] enable embedding: declare/#define only py* symbols in #includes

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

[issue10070] 2to3 wishes for already-2to3'ed files

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

[issue10231] SimpleHTTPRequestHandler directory bugs

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

[issue960325] "--require " option for configure/make (fail if building not possible)

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

[issue9611] FileIO not 64-bit safe under Windows

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

[issue9732] Addition of getattr_static for inspect module

Changes by Michael Foord : Removed file: http://bugs.python.org/file19483/static.py ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue9732] Addition of getattr_static for inspect module

Changes by Michael Foord : Removed file: http://bugs.python.org/file19484/test_static.py ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue9611] FileIO not 64-bit safe under Windows

Antoine Pitrou added the comment: > About the issue, I'd suggest to just clamp the length to 2**32-1, and > don't bother retrying; leave this to the buffered layer. Yes, I think it's reasonable. (or perhaps clamp to something page-aligned, such as 2**32-4096). Also, the signal issue which was r

[issue10311] Signal handlers must preserve errno

New submission from Hallvard B Furuseth : Signal handlers that can change errno, must restore it. I enclose a patch for <2.7, 3.2a3>/Modules/signalmodule.c which also rearranges the code to make this a bit easier. The patch does if (errno != save_errno) errno = save_errno; instead of just err

[issue9732] Addition of getattr_static for inspect module

Michael Foord added the comment: Further updated implementation. Now handles data descriptors correctly but removes the code that resolves the builtin descriptors (calling __get__ on slot and attribute descriptors). As it was resolving some descriptors but not all, and resolving getset descr

[issue9732] Addition of getattr_static for inspect module

Changes by Michael Foord : Added file: http://bugs.python.org/file19490/test_static.py ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue10311] Signal handlers must preserve errno

Antoine Pitrou added the comment: This is a good idea IMO. It would be better if you minimized style changes, so that the patch is easier to review. Also, is the while loop around write() necessary here? -- nosy: +exarkun, loewis, pitrou stage: -> patch review versions: +Python 2.7, P

[issue5391] mmap: read_byte/write_byte and object type

Hirokazu Yamamoto added the comment: Thank for pointing this out. I've looked at bytearray and bytes implementations, they actually return unsigned value. I fixed this in r86159(py3k) and r86160(release31-maint). -- ___ Python tracker

[issue10312] intcatcher() can deadlock

New submission from Hallvard B Furuseth : Parser/intrcheck.c:intcatcher() can do FILE* operations, which can deadlock if the interrupt happens while a FILE* operation on the same FILE holds a mutex for the FILE. I've seen this happen elsewhere. It'd rather be a pity to remove Py_Exit(), so I su

[issue10312] intcatcher() can deadlock

Changes by Antoine Pitrou : -- nosy: +benjamin.peterson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://

[issue10311] Signal handlers must preserve errno

Hallvard B Furuseth added the comment: Parser/intrcheck.c:intcatcher() should do the same. Covered in Issue 10312. Antoine Pitrou writes: > This is a good idea IMO. It would be better if you minimized style > changes, so that the patch is easier to review. I'm afraid the un-rearranged code wo

[issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()

Changes by Antoine Pitrou : -- assignee: -> theller nosy: +theller ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue10310] signed:1 bitfields rarely make sense

Changes by Antoine Pitrou : -- nosy: +amaury.forgeotdarc stage: -> patch review versions: +Python 2.7, Python 3.1 ___ Python tracker ___

[issue10306] Weakref callback exceptions should be turned into warnings.

Antoine Pitrou added the comment: The behaviour of weakrefs here mirrors what is already done for __del__ exceptions. Using warnings would mean that exceptions can get silenced implicitly (for example, if an exception happens twice at the same location) which is not very Pythonic: generally,

[issue10231] SimpleHTTPRequestHandler directory bugs

Changes by Hallvard B Furuseth : -- versions: +Python 2.7, Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue10133] multiprocessing: conn_recv_string() broken error handling

Changes by Hallvard B Furuseth : -- versions: +Python 2.7, Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue10308] Modules/getpath.c bugs

Changes by Hallvard B Furuseth : -- versions: +Python 2.7, Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()

Changes by Hallvard B Furuseth : -- versions: +Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue10312] intcatcher() can deadlock

Changes by Hallvard B Furuseth : -- versions: +Python 2.7, Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue10306] Weakref callback exceptions should be turned into warnings.

Julian added the comment: Thank you, Antoine, you make a good point. In my example, I am suppressing the warning, which, I agree isn't a good idea. In my real life usage, I was getting an unexpected exception in a callback in code written by another person. I wanted not to suppress the warnin

[issue10311] Signal handlers must preserve errno

Amaury Forgeot d'Arc added the comment: This issue is not really relevant on Windows: - signals are actually run in a new thread specially created. - errno is a thread-local variable; its value is thus local to the signal handler, same for WSAGetLastError(). -- nosy: +amaury.forgeotdar

[issue9931] test_ttk_guionly hangs on XP5

Hirokazu Yamamoto added the comment: I've created the patch to fix this. (This patch comes from #9055) -- keywords: +patch Added file: http://bugs.python.org/file19492/py3k_check_if_gui_is_really_available.patch ___ Python tracker

[issue9931] test_ttk_guionly hangs on XP5

Changes by Hirokazu Yamamoto : -- dependencies: -test_issue_8959_b fails when run from a service ___ Python tracker ___ ___ Python-bug

[issue10311] Signal handlers must preserve errno

Hallvard B Furuseth added the comment: Amaury Forgeot d'Arc writes: > This issue is not really relevant on Windows: > - signals are actually run in a new thread specially created. > - errno is a thread-local variable; its value is thus local to the > signal handler, same for WSAGetLastError().

[issue10311] Signal handlers must preserve errno

Amaury Forgeot d'Arc added the comment: > Nice. Then I suggest a config macro for whether this is needed. > Either a test for windows, or an autoconf thing in case some Unixes > are equally sensible. (Linux isn't, I checked.) I'm quite sure that all Unixes invoke signal handlers in some exist

[issue10313] Reassure user: test_os BytesWarning is OK

New submission from Hallvard B Furuseth : A test giving a strange warning can make a poor user nervous. Here's a minimal patch to calm his nerves. It would be better to only give the message if python -b (not -bb) is active, but I do not know how. diff -prU2 Lib/test/test_os.py Lib/test/test_o

[issue960325] "--require " option for configure/make (fail if building not possible)

Hallvard B Furuseth added the comment: Once upon a time, Terry J. Reedy wrote: > Hallvard, do you still consider this a live issue? If this general behavior remains, yes. It's been a while since I had a computer without these libraries to test it on. (Which is why I punted and then forgot to

[issue10311] Signal handlers must preserve errno

Hallvard B Furuseth added the comment: Amaury Forgeot d'Arc writes: > OTOH this is really a micro optimization. ["this" = only saving/restoring errno when needed] True, but practically nothing is officially safe to do in signal handlers, so it's good to avoid code which can be avoided there. If

[issue10313] Reassure user: test_os BytesWarning is OK

R. David Murray added the comment: I don't see any bytes warnings when I run test_os with -b or -bb on linux on py3k trunk. (If there were such a warning and it was expected, the fix would be to capture the warning and ignore it.) Under what circumstances do you see this warning? --

[issue10313] Reassure user: test_os BytesWarning is OK

Hallvard B Furuseth added the comment: R. David Murray writes: > I don't see any bytes warnings when I run test_os with -b or -bb on > linux on py3k trunk. (If there were such a warning and it was expected, > the fix would be to capture the warning and ignore it.) > > Under what circumstances

[issue10273] Clean-up Unittest API

Changes by Ezio Melotti : -- nosy: +flox, gregory.p.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue10311] Signal handlers must preserve errno

Antoine Pitrou added the comment: > ["this" = only saving/restoring errno when needed] > True, but practically nothing is officially safe to do in signal > handlers, so it's good to avoid code which can be avoided there. > If one can be bothered to, that is. I think it is extremely unlikely tha

[issue10311] Signal handlers must preserve errno

Antoine Pitrou added the comment: By the way, I'd like to clear out a potential misunderstanding: the function you are patching doesn't call Python signal handlers in itself (those registered using signal.signal()). It only schedules them for later execution. If you want to save errno around

[issue1602] windows console doesn't print utf8 (Py30a2)

STINNER Victor added the comment: I wrote a small function to call WriteConsoleOutputA() and WriteConsoleOutputW() in Python to do some tests. It works correclty, except if I change the code page using chcp command. It looks like the problem is that the chcp command changes the console code

[issue1602] windows console doesn't print utf8 (Py30a2)

STINNER Victor added the comment: sys_write_stdtout.patch: Create sys.write_stdout() test function to call WriteConsoleOutputA() or WriteConsoleOutputW() depending on the input types (bytes or str). -- keywords: +patch Added file: http://bugs.python.org/file19493/sys_write_stdout.patc

[issue1602] windows console doesn't print utf8 (Py30a2)

Χρήστος Γεωργίου (Christos Georgiou) added the comment: http://blogs.msdn.com/b/michkap/archive/2008/03/18/8306597.aspx If you want any kind of Unicode output in the console, the font must be an “official” MS console TTF (“official” as defined by the Windows version); I believe only Lucida C

[issue10030] Patch for zip decryption speedup

Shashank added the comment: I had uploaded an incorrect patch. New corrected patch against trunk (on Mac OS uploaded). -- Added file: http://bugs.python.org/file19494/zipdecrypt.patch ___ Python tracker _

[issue10030] Patch for zip decryption speedup

Changes by Shashank : Removed file: http://bugs.python.org/file19494/zipdecrypt.patch ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue10030] Patch for zip decryption speedup

Changes by Shashank : Added file: http://bugs.python.org/file19495/zipdecrypt.patch ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue10314] Improve JSON encoding with sort_keys=True

New submission from Antoine Pitrou : This patch makes sorting of keys when encoding a dict into JSON faster by not calling pure Python code. -- components: Library (Lib) files: jsonsort.patch keywords: patch messages: 120418 nosy: pitrou priority: normal severity: normal status: open ti

[issue10314] Improve JSON encoding with sort_keys=True

Raymond Hettinger added the comment: +1 -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue10314] Improve JSON encoding with sort_keys=True

Antoine Pitrou added the comment: Ok, committed in r86169. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___

[issue10198] wave module writes corrupt wav file for zero-length writeframes

Éric Araujo added the comment: I asked that because I didn’t see the fix backported :) -- ___ Python tracker ___ ___ Python-bugs-list

[issue6081] str.format_map()

Changes by Eric Smith : -- title: str.format_from_mapping() -> str.format_map() ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue6081] str.format_map()

Eric Smith added the comment: Committed to 3.2 in r86170. -- stage: patch review -> committed/rejected status: open -> closed ___ Python tracker ___ _

[issue10313] Reassure user: test_os BytesWarning is OK

R. David Murray added the comment: Can you give the exact command line you are using to run it, and the OS and version, and perhaps a printenv? I can't reproduce it in 3.1 or 3.2a3. -- ___ Python tracker ___

[issue10313] Reassure user: test_os BytesWarning is OK

R. David Murray added the comment: Running it with -E and seeing if that changes the behavior would also be useful. -- ___ Python tracker ___ ___

[issue10198] wave module writes corrupt wav file for zero-length writeframes

Georg Brandl added the comment: I always to the backports batched for these minor and docs fixes. -- ___ Python tracker ___ ___ Pytho

[issue10298] zipfile: incorrect comment size will prevent extracting

Changes by Éric Araujo : -- keywords: +needs review nosy: +alanmcintyre stage: -> patch review versions: +Python 3.1, Python 3.2 ___ Python tracker ___ _

[issue10198] wave module writes corrupt wav file for zero-length writeframes

Éric Araujo added the comment: Perfect, sorry for doubting you ;) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue3699] test_bigaddrspace broken

Sandro Tosi added the comment: The attached patch implements the same tests of byte for string objects. -- assignee: -> sandro.tosi stage: -> patch review Added file: http://bugs.python.org/file19497/issue3699-py3k-v2.patch ___ Python tracker

[issue1926] NNTPS support in nntplib

Julien ÉLIE added the comment: Hi Steven, > I also don't understand why START_TLS and AUTHINFO need to change > how the module is interfaced to (separating log in/authentication, etc) Because once you have used AUTHINFO, STARTTLS is no longer a valid command in a session. The authentication p

[issue10243] Packaged Pythons

Changes by Martin v. Löwis : -- resolution: -> wont fix status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue960325] "--require " option for configure/make (fail if building not possible)

Terry J. Reedy added the comment: I am closing this as some combination of wrong, inapplicable, out-of-date, and postponed. 1. In 3.1, ssl *is* documented as optional in the sense of dependent on an external library. "This module uses the OpenSSL library. It is available on all modern ... pl

[issue9611] FileIO not 64-bit safe under Windows

Martin v. Löwis added the comment: I propose a different solution: On Windows, instead of calling write(), we call WriteFile directly. We try to faithfully follow the CRT implementation as much as possible, knowing that what we write to actually is a binary file (in particular, the file handl

[issue9611] FileIO not 64-bit safe under Windows

Antoine Pitrou added the comment: > I propose a different solution: On Windows, instead of calling > write(), we call WriteFile directly. If I'm not mistaken, WriteFile takes the length as a DWORD, which is still 32 bits under Win64. -- ___ Python t

[issue10315] smtplib.SMTP_SSL new in 2.6

New submission from Henning Hraban Ramm : The docs tell us that smtplib.SMTP_SSL was only changed in 2.6, but it is new (i.e. it didn't exist in 2.5.x). -- assignee: d...@python components: Documentation messages: 120432 nosy: d...@python, hraban priority: normal severity: normal status

[issue10243] Packaged Pythons

Max Skaller added the comment: On Thu, Nov 4, 2010 at 5:19 PM, Ned Deily wrote: > > Ned Deily added the comment: > > For what it's worth, the python.org installers for Mac OS X do include a > libpython shared library. As of Python 2.7 (and 3.2), the installer > includes a symlink to make it

[issue9611] FileIO not 64-bit safe under Windows

Martin v. Löwis added the comment: > If I'm not mistaken, WriteFile takes the length as a DWORD, which is > still 32 bits under Win64. Oops, ignore me, then... I agree that clamping is fine, assuming the buffering layer takes that into account. -- _

[issue10243] Packaged Pythons

Changes by Martin v. Löwis : Removed file: http://bugs.python.org/file19498/unnamed ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue10293] PyMemoryView object has obsolete members

Antoine Pitrou added the comment: Well, there's this strange-looking thing in PyMemoryView_GetContiguous: if (buffertype == PyBUF_SHADOW) { /* return a shadowed memory-view object */ view->buf = dest; mem->base = PyTuple_Pack(2, obj, bytes); ... but I don't really w

[issue10293] PyMemoryView object has obsolete members

Antoine Pitrou added the comment: Done in r86174. -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-b

[issue3699] test_bigaddrspace broken

Antoine Pitrou added the comment: I've made cosmetic changes and applied in r86175 (3.2) and r86176 (3.1). Thank you! -- priority: high -> normal resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python track

[issue10316] tkFileDialog.askopenfilenames scrambling multiple file selection

New submission from Peter Hall : I am running the following : Linux Centos version 2.6.18 Python version 2.5 tk version 8.5 tcl version 8.5 I have a Python GUI program (importing Tkinter and tkFileDialog) which prompts the user to select a (one to many) list of file names. The code is : file

[issue10316] tkFileDialog.askopenfilenames scrambling multiple file selection

Changes by Peter Hall : -- type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue10313] Reassure user: test_os BytesWarning is OK

Antoine Pitrou added the comment: I guess you're not seeing them because Victor silenced them a couple of days ago in r85902. Hallvard, if you update your py3k working copy, do these warnings disappear? -- nosy: +pitrou ___ Python tracker

[issue10243] Packaged Pythons

Ned Deily added the comment: It's called Python because that's the way frameworks on OS X are generally structured: the shared library file has the same name as the framework. The Apple developer docs have lots of information on frameworks. Prior to 2.7 and the upcoming 3.2 releases, python.

[issue10302] Add class-functions to hash many small objects with hashlib

Antoine Pitrou added the comment: This sounds dangerously like a micro-optimization to me, and I'm not sure an additional API is ok for that. -- nosy: +gregory.p.smith, pitrou ___ Python tracker _

[issue10313] Reassure user: test_os BytesWarning is OK

R. David Murray added the comment: Ah, then this report is probably out of date. I just realized that I ran my 3.2a3 test incorrectly, so my report that I didn't see them there is invalid. -- ___ Python tracker

[issue9611] FileIO not 64-bit safe under Windows

Amaury Forgeot d'Arc added the comment: On a second thought... is there another example where a *blocking* stream does not write all the data without raising an exception? -- ___ Python tracker ___

[issue9611] FileIO not 64-bit safe under Windows

Martin v. Löwis added the comment: > On a second thought... is there another example where a *blocking* stream > does not write all the data without raising an exception? Why do you think this would be somehow an example for a blocking stream that does not write all data without raising an exc

[issue9611] FileIO not 64-bit safe under Windows

Amaury Forgeot d'Arc added the comment: > Why do you think this would be somehow an example for a blocking stream > that does not write all data without raising an exception? Well, that's what "clamping" means, isn't it? -- ___ Python tracker

[issue9611] FileIO not 64-bit safe under Windows

Antoine Pitrou added the comment: > On a second thought... is there another example where a *blocking* > stream does not write all the data without raising an exception? It can happen with pipes or sockets, if some buffer can only store part of the data. Or any regular stream if a signal is rec

[issue10283] New parameter for an NNTP newsgroup pattern in LIST ACTIVE

Antoine Pitrou added the comment: That's a fine addition, I've committed it in r86177. -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker _

[issue9611] FileIO not 64-bit safe under Windows

Martin v. Löwis added the comment: Am 04.11.2010 22:28, schrieb Amaury Forgeot d'Arc: > > Amaury Forgeot d'Arc added the comment: > >> Why do you think this would be somehow an example for a blocking stream >> that does not write all data without raising an exception? > Well, that's what "cla

[issue10279] test_gc failure on Windows x64

Antoine Pitrou added the comment: %Id is actually the expansion of PY_FORMAT_SIZE_T. Include/pyport.h says: /* PY_FORMAT_SIZE_T is a platform-specific modifier for use in a printf * format to convert an argument with the width of a size_t or Py_ssize_t. * C99 introduced "z" for this purpose,

  1   2   >