[issue10243] Packaged Pythons
Ned Deily n...@acm.org 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 easier to find: $ cd /Library/Frameworks/Python.framework/Versions/2.7/lib $ ls -l libpython2.7.dylib $ lrwxr-xr-x 1 root admin 9 Oct 27 20:46 libpython2.7.dylib@ - ../Python $ file ../Python ../Python: Mach-O universal binary with 2 architectures ../Python (for architecture ppc): Mach-O dynamically linked shared library ppc ../Python (for architecture i386): Mach-O dynamically linked shared library i386 $ cd /Library/Frameworks/Python.framework/Versions/2.6 $ file Python Python: Mach-O universal binary with 2 architectures Python (for architecture ppc): Mach-O dynamically linked shared library ppc Python (for architecture i386): Mach-O dynamically linked shared library i386 In Debian and Ubuntu releases, the shared library is put into its own optionally installed package, libpythonx.x. -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10243] Packaged Pythons
Changes by Ned Deily n...@acm.org: Removed file: http://bugs.python.org/file19480/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10300] Documentation of three PyDict_* functions
Hagen Fürstenau ha...@zhuliguan.net added the comment: The ReST links in http://docs.python.org/py3k/c-api/dict.html#PyDict_Items seem to be broken. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10305] Cleanup up ResourceWarnings in multiprocessing
Ask Solem a...@opera.com 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 rep...@bugs.python.org http://bugs.python.org/issue10305 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10286] URLOpener = URLopener x2 in fix_urllib.py
Georg Brandl ge...@python.org added the comment: Fixed in r86157. -- nosy: +georg.brandl resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10286 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10293] PyMemoryView object has obsolete members
Changes by Georg Brandl ge...@python.org: -- assignee: - pitrou nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10293 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10198] wave module writes corrupt wav file for zero-length writeframes
Georg Brandl ge...@python.org added the comment: I'm sorry, the actual revision is r85970. Why should it be irrelevant for other branches? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10198 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9015] f.write(s) for s 2GB hangs in win64 (and win32?)
Martin Spacek pyt...@mspacek.mm.st 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(s))])
assert len(longs) == FOURGBMINUS
f = open('test.txt', 'w')
f.write(longs) # completes successfully
f.close()
FOURGB = 2**32
s = '0123456789012345' # 16 bytes
longs = ''.join([s for i in xrange(FOURGB//len(s))])
assert len(longs) == FOURGB
f = open('test.txt', 'w')
f.write(longs) # hangs with 100% CPU, file is 0 bytes
f.close()
SIXGB = 2**32 + 2**31
s = '0123456789012345' # 16 bytes
longs = ''.join([s for i in xrange(SIXGB//len(s))])
assert len(longs) == SIXGB
f = open('test.txt', 'w')
f.write(longs) # hangs with 100% CPU, file is 2**31 bytes
f.close()
# file.read test:
TWOGB = 2**31
TWOGBPLUS = TWOGB + 16
s = '0123456789012345' # 16 bytes
longs = ''.join([s for i in xrange(TWOGBPLUS//len(s))])
assert len(longs) == TWOGBPLUS
f = open('test.txt', 'w')
f.write(longs) # completes successfully
f.close()
f = open('test.txt', 'r')
longs = f.read() # works, but takes 30 min, memory usage keeps jumping around
f.close()
del longs
# maybe f.read() reads 1 char at a time til it hits EOL. try this instead:
f = open('test.txt', 'r')
longs = f.read(TWOGBPLUS) # OverflowError: long int too large to convert to int
longs = f.read(TWOGB) # OverflowError: long int too large to convert to int
longs = f.read(TWOGB - 1) # works, takes only seconds
f.close()
So, I guess in windows (I've only tested in 64-bit Windows 7, Python 2.6.6
amd64), file.write() should call fwrite multiple times in chunks no greater
than 2**31 bytes or so. Also, calling f.read(nbytes) where nbytes = 2**31
raises OverflowError: long int too large to convert to int. I don't have
either of these problems in 64-bit Linux (Ubuntu 10.10) on the same machine
(i7, 12GB).
--
components: +IO -Extension Modules
title: array.array.tofile cannot write arrays of sizes 4GB, even compiled for
amd64 - f.write(s) for s 2GB hangs in win64 (and win32?)
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9015
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9015] f.write(s) for s 2GB hangs in win64 (and win32?)
Martin Spacek pyt...@mspacek.mm.st added the comment: I suppose someone should confirm this problem on Py 2.6? -- components: +Extension Modules, Windows ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9015 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9015] f.write(s) for s 2GB hangs in win64 (and win32?)
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: It's still an issue with 2.7, and even with 3.2a2, see issue9611. -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9015 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9611] FileIO not 64-bit safe under Windows
Martin Spacek pyt...@mspacek.mm.st 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 as a crash. This is apparently due to fwrite limitations in msvc, even in win64. -- components: +IO nosy: +mspacek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9611] FileIO not 64-bit safe under Windows
Amaury Forgeot d'Arc amaur...@gmail.com 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 of the IO stack. 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. -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10308] Modules/getpath.c bugs
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no: 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_AsWideChar() result. (The fix just renames n to k of signed type, and moves the variables. An outer uninitialized 'size_t n' is in scope, so renaming the inner n to k leaves 'n=fread()' still a size_t.) Chunk #1, both versions: Fix an unlikely 'n+k' wraparound bug while I'm at it. The code has just checked that MAXPATHLEN-n will not wrap. -- files: getpath.diff keywords: patch messages: 120390 nosy: hfuru priority: normal severity: normal status: open title: Modules/getpath.c bugs type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file19486/getpath.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10308 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no: 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/libffi/src/dlmalloc.c +++ Modules/_ctypes/libffi/src/dlmalloc.c @@ -459,2 +459,4 @@ #define MMAP_CLEARS 0 /* WINCE and some others apparently don't clear */ +#elif !defined _GNU_SOURCE +#define _GNU_SOURCE 1 /* mremap() in Linux sys/mman.h */ #endif /* WIN32 */ However the (char*)CALL_MREMAP() cast looks like a broken fix for this, it suppresses a warning instead of fixing it. Maybe you should remove the cast and instead assign CALL_MREMAP() to a void*, to catch any similar trouble in the future. -- components: Extension Modules messages: 120391 nosy: hfuru priority: normal severity: normal status: open title: dlmalloc.c needs _GNU_SOURCE for mremap() type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10309 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10297] decimal module documentation is misguiding
Changes by Baiju M baiju.m.m...@gmail.com: -- nosy: +baijum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10297 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10310] signed:1 bitfields rarely make sense
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no: 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 bitfield = 1 overflow. If the point was that they are assigned signed values, well, unsigned:1 is promoted to signed int. I also fix a strange (int) cast doing (truncate flag to int) 1. My guess is someone shut up a compiler warning about the above, by cleaning up in the wrong place. I kept a cast in case that's not it, and some compiler would get noisy anyway. There are possibly-signed 1-bit fields Modules/_ctypes/_ctypes_test.c: struct BITS too, but I don't know what that code is for. It does not specify signedness of the bitfields, which (as with char) makes it the compiler's choice. That's usually a bad idea, but maybe that code is for exploring the compiler? -- components: IO files: signed-1-bitfield.diff keywords: patch messages: 120392 nosy: hfuru priority: normal severity: normal status: open title: signed:1 bitfields rarely make sense type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file19487/signed-1-bitfield.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10310 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10273] Clean-up Unittest API
Ezio Melotti ezio.melo...@gmail.com 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 args explicitly every time though. Regarding assertLT I'm still -1. The current names are imho the best compromise between being short and descriptive. They also match nicely assertEqual (assertLT - assertEQ; assertLessThan - assertEqualTo; but assertLess - assertEqual). Also it might not be immediately obvious what assertGE does, if one is not familiar with the special methods or if taken out of context (it's easy to recognize it if it's together with assertLT/LE/GT, but alone might just look a specialized method with a bad name). Moreover people who are used to the current spelling will have to notice the change, note that one name is now deprecated, update their code, remember if the correct name is assertLess or assertLT, wonder if assertEqual has been deprecated in favor of assertEQ too, remember the version where the name changed (e.g. if they try assertLT on 3.1 it won't work) and so on. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10273 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10310] signed:1 bitfields rarely make sense
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10310 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10308] Modules/getpath.c bugs
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10308 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10309 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10133] multiprocessing: conn_recv_string() broken error handling
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10133 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10086] test_sysconfig failure with site-packages
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10086 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2921] enable embedding: declare/#define only py* symbols in #includes
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2921 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10070] 2to3 wishes for already-2to3'ed files
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10070 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10231] SimpleHTTPRequestHandler directory bugs
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10231 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue960325] --require feature option for configure/make (fail if building not possible)
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue960325 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9611] FileIO not 64-bit safe under Windows
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9732] Addition of getattr_static for inspect module
Changes by Michael Foord mich...@voidspace.org.uk: Removed file: http://bugs.python.org/file19483/static.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9732 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9732] Addition of getattr_static for inspect module
Changes by Michael Foord mich...@voidspace.org.uk: Removed file: http://bugs.python.org/file19484/test_static.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9732 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9611] FileIO not 64-bit safe under Windows
Antoine Pitrou pit...@free.fr 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 raised by Martin above has since been fixed in r84239. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10311] Signal handlers must preserve errno
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no: 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 errno = save_errno; in case it's less thread-safe to write than to read errno, which would not surprise me but may be pointless paranoia. I don't know what needs to be done on non-Unix systems, like Windows' WSAError stuff. -- components: Interpreter Core files: signalmodule-errno.diff keywords: patch messages: 120395 nosy: hfuru priority: normal severity: normal status: open title: Signal handlers must preserve errno type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file19488/signalmodule-errno.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9732] Addition of getattr_static for inspect module
Michael Foord mich...@voidspace.org.uk 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 descriptors could still trigger execution in C extensions, Benjamin felt it was more consistent and cleaner to return descriptor objects rather than resolving them. As a bonus it makes the code shorter too. I would add to the documentation some example code showing how to handle the descriptor if the user wants to resolve them herself. (Example code shown in the tests.) The only remaining cases that are handled incorrectly are pathological ones. (See the notes in the tests.) -- Added file: http://bugs.python.org/file19489/static.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9732 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9732] Addition of getattr_static for inspect module
Changes by Michael Foord mich...@voidspace.org.uk: Added file: http://bugs.python.org/file19490/test_static.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9732 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10311] Signal handlers must preserve errno
Antoine Pitrou pit...@free.fr 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, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5391] mmap: read_byte/write_byte and object type
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp 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 rep...@bugs.python.org http://bugs.python.org/issue5391 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10312] intcatcher() can deadlock
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no: 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 suggest switch(interrupted++) gets a case 3 or 4: which does _exit(1), and 'interrupted = 0;' is moved there from case 2. Also 'interrupted' should be volatile sig_atomic_t, and the function should save/restore errno as in Issue 10311. BTW, you could use strlen(message) instead of sizeof(message)-1. -- components: Interpreter Core files: intrcheck.diff keywords: patch messages: 120399 nosy: hfuru priority: normal severity: normal status: open title: intcatcher() can deadlock type: behavior versions: Python 3.2 Added file: http://bugs.python.org/file19491/intrcheck.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10312 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10312] intcatcher() can deadlock
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10312 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10311] Signal handlers must preserve errno
Hallvard B Furuseth h.b.furus...@usit.uio.no 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 would be fairly ugly, so I cleaned up first. Single exit point. Also, is the while loop around write() necessary here? Whoops, I'd forgotten I did that too, it was on my TODO list to check if Python makes it unnecessary by making write restartable. I don't remember if that's possible to ensure on all modern Posixes -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()
Changes by Antoine Pitrou pit...@free.fr: -- assignee: - theller nosy: +theller ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10309 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10310] signed:1 bitfields rarely make sense
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +amaury.forgeotdarc stage: - patch review versions: +Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10310 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10306] Weakref callback exceptions should be turned into warnings.
Antoine Pitrou pit...@free.fr 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, if you want to silence an exception, you have to do it explicitly through try...except. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10306 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10231] SimpleHTTPRequestHandler directory bugs
Changes by Hallvard B Furuseth h.b.furus...@usit.uio.no: -- versions: +Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10231 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10133] multiprocessing: conn_recv_string() broken error handling
Changes by Hallvard B Furuseth h.b.furus...@usit.uio.no: -- versions: +Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10133 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10308] Modules/getpath.c bugs
Changes by Hallvard B Furuseth h.b.furus...@usit.uio.no: -- versions: +Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10308 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()
Changes by Hallvard B Furuseth h.b.furus...@usit.uio.no: -- versions: +Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10309 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10312] intcatcher() can deadlock
Changes by Hallvard B Furuseth h.b.furus...@usit.uio.no: -- versions: +Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10312 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10306] Weakref callback exceptions should be turned into warnings.
Julian python_...@somethinkodd.com 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 warning, but to turn it into an exception to help trace the cause. Thinking about this further, (if it was a warning, as I suggest,) I now believe that would raise that exception into the garbage collector which might have some unpredictable consequences. I have rejected my own Issue for this reason. I maintain that the current solution isn't terribly helpful. Getting this output to stderr is neither helpful to me, in development (i.e. nothing in the error indicated it was related to the weakref functionality) nor my users in production (fortunately the problem was caught before then!) However, I concede my proposal isn't the right solution. Thank you again for your comment. -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10306 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10311] Signal handlers must preserve errno
Amaury Forgeot d'Arc amaur...@gmail.com 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.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9931] test_ttk_guionly hangs on XP5
Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp 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 rep...@bugs.python.org http://bugs.python.org/issue9931 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9931] test_ttk_guionly hangs on XP5
Changes by Hirokazu Yamamoto ocean-c...@m2.ccsnet.ne.jp: -- dependencies: -test_issue_8959_b fails when run from a service ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9931 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10311] Signal handlers must preserve errno
Hallvard B Furuseth h.b.furus...@usit.uio.no 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(). 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.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10311] Signal handlers must preserve errno
Amaury Forgeot d'Arc amaur...@gmail.com 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 existing thread. So even if errno is thread-local, it needs to be saved and restored. OTOH this is really a micro optimization. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10313] Reassure user: test_os BytesWarning is OK
New submission from Hallvard B Furuseth h.b.furus...@usit.uio.no:
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_os.py
--- Lib/test/test_os.py
+++ Lib/test/test_os.py
@@ -443,4 +443,7 @@ class EnvironTests(mapping_tests.BasicTe
test_env = {'PATH': os.pathsep.join(test_path)}
+if os.supports_bytes_environ:
+print(This test may give some 'BytesWarning's., file=sys.stderr)
+
saved_environ = os.environ
try:
--
components: Tests
messages: 120407
nosy: hfuru
priority: normal
severity: normal
status: open
title: Reassure user: test_os BytesWarning is OK
type: feature request
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10313
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue960325] --require feature option for configure/make (fail if building not possible)
Hallvard B Furuseth h.b.furus...@usit.uio.no 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 answer, sorry.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue960325 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10311] Signal handlers must preserve errno
Hallvard B Furuseth h.b.furus...@usit.uio.no 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 one can be bothered to, that is. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10313] Reassure user: test_os BytesWarning is OK
R. David Murray rdmur...@bitdance.com 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? -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10313] Reassure user: test_os BytesWarning is OK
Hallvard B Furuseth h.b.furus...@usit.uio.no 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 do you see this warning? Python 3.2a3, test_os with python -b. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10273] Clean-up Unittest API
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +flox, gregory.p.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10273 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10311] Signal handlers must preserve errno
Antoine Pitrou pit...@free.fr 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 that mutating errno in a signal handler is unsafe (after all, the library functions called from that handler can mutate errno too: that's the whole point of the patch IIUC). Adding some configure machinery for this seems unwarranted to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10311] Signal handlers must preserve errno
Antoine Pitrou pit...@free.fr 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 Python signal handlers themselves, PyErr_CheckSignals must be patched as well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10311 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print utf8 (Py30a2)
STINNER Victor victor.stin...@haypocalc.com 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 page and the ANSI code page, but it should only changes the ANSI code page (and not the console code page). chcp command The chcp command changes the console code page, but in practice, the console still expects the OEM code page (eg. cp850 on my french setup). Example: C:\... python.exe -c import sys; print(sys.stdout.encoding) cp850 C:\... chcp 65001 C:\... python.exe Fatal Python error: Py_Initialize: can't initialize sys standard streams LookupError: unknown encoding: cp65001 C:\... SET PYTHONIOENCODING=utf-8 C:\... python.exe import sys sys.stdout.write(\xe9\n) é 2 sys.stdout.buffer.write(\xe9\n.encode(utf8)) é 3 sys.stdout.buffer.write(\xe9\n.encode(cp850)) é 2 os.device_encoding(1) uses GetConsoleOutputCP() which gives 65001. It should maybe use GetOEMCP() instead? Or chcp command should be fixed? Set the console code page looks to be a bad idea, because if I type é using my keyboard, a random character (eg. U+0002) is displayed instead... WriteConsoleOutputA() and WriteConsoleOutputW() === Without touching the code page -- If the character can be rendered by the current font (eg. U+00E9): WriteConsoleOutputA() and WriteConsoleOutputW() work correctly. If the character cannot be rendered by the current font, but there is a replacment character (eg. U+0141 replaced by U+0041): WriteConsoleOutputA() cannot be used (U+0141 cannot be encoded to the code page), WriteConsoleOutputW() writes U+0141 but the console contains U+0041 (I checked using ReadConsoleOutputW()) and U+0041 is displayed. It works like the mbcs encoding, the behaviour looks correct. If the character cannot be rendered by the current font, but there is a replacment character (eg. U+042D): WriteConsoleOutputA() cannot be used (U+042D cannot be encoded to the code page), WriteConsoleOutputW() writes U+042D but U+003d (?) is displayed instead. The behaviour looks correct. chcp 65001 -- Using chcp 65001 command (+ set PYTHONIOENCODING=utf-8 to avoid the fatal error), it becomes worse: the result depends on the font... Using raster font: - (ANSI) write \xe9.encode(cp850) using WriteConsoleOutputA() displays U+00e9 (é), whereas the console output code page is cp65001 (I checked using GetConsoleOutputCP()) - (ANSI) write \xe9.encode(utf-8) using WriteConsoleOutputA() displays é (mojibake!) - (UNICODE) write \xe9 using WriteConsoleOutputW() displays... a random character (U+0002, U+0008, U+0069, U+00b0, ...) Using Lucida (TrueType font): - (ANSI) write \xe9.encode(cp850) using WriteConsoleOutputA() displays U+ !? - (UNICODE) write \xe9 using WriteConsoleOutputW() works correctly (display U+00e9), even with \u0141, it works correctly (display U+0141) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print utf8 (Py30a2)
STINNER Victor victor.stin...@haypocalc.com 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.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print utf8 (Py30a2)
Χρήστος Γεωργίου (Christos Georgiou) t...@users.sourceforge.net 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 Console and Consolas are the ones with all MS private settings turned on inside the font file. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10030] Patch for zip decryption speedup
Shashank shashank.sunny.si...@gmail.com 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 rep...@bugs.python.org http://bugs.python.org/issue10030 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10030] Patch for zip decryption speedup
Changes by Shashank shashank.sunny.si...@gmail.com: Removed file: http://bugs.python.org/file19494/zipdecrypt.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10030 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10030] Patch for zip decryption speedup
Changes by Shashank shashank.sunny.si...@gmail.com: Added file: http://bugs.python.org/file19495/zipdecrypt.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10030 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10314] Improve JSON encoding with sort_keys=True
New submission from Antoine Pitrou pit...@free.fr: 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 title: Improve JSON encoding with sort_keys=True type: performance versions: Python 3.2 Added file: http://bugs.python.org/file19496/jsonsort.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10314 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10314] Improve JSON encoding with sort_keys=True
Raymond Hettinger rhettin...@users.sourceforge.net added the comment: +1 -- nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10314 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10314] Improve JSON encoding with sort_keys=True
Antoine Pitrou pit...@free.fr added the comment: Ok, committed in r86169. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10314 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10198] wave module writes corrupt wav file for zero-length writeframes
Éric Araujo mer...@netwok.org added the comment: I asked that because I didn’t see the fix backported :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10198 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6081] str.format_map()
Changes by Eric Smith e...@trueblade.com: -- title: str.format_from_mapping() - str.format_map() ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6081 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6081] str.format_map()
Eric Smith e...@trueblade.com added the comment: Committed to 3.2 in r86170. -- stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6081 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10313] Reassure user: test_os BytesWarning is OK
R. David Murray rdmur...@bitdance.com 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 rep...@bugs.python.org http://bugs.python.org/issue10313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10313] Reassure user: test_os BytesWarning is OK
R. David Murray rdmur...@bitdance.com added the comment: Running it with -E and seeing if that changes the behavior would also be useful. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10198] wave module writes corrupt wav file for zero-length writeframes
Georg Brandl ge...@python.org added the comment: I always to the backports batched for these minor and docs fixes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10198 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10298] zipfile: incorrect comment size will prevent extracting
Changes by Éric Araujo mer...@netwok.org: -- keywords: +needs review nosy: +alanmcintyre stage: - patch review versions: +Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10298 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10198] wave module writes corrupt wav file for zero-length writeframes
Éric Araujo mer...@netwok.org added the comment: Perfect, sorry for doubting you ;) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10198 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3699] test_bigaddrspace broken
Sandro Tosi sandro.t...@gmail.com 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 rep...@bugs.python.org http://bugs.python.org/issue3699 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1926] NNTPS support in nntplib
Julien ÉLIE jul...@trigofacile.com 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 part is currently delt with in the init function (in nntplib) so it needs to be separated because one could want to first use STARTTLS, and then AUTHINFO. Currently, AUTHINFO is sent just after the initial log in; it is therefore better to have AUTHINFO handled in another function. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1926 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10243] Packaged Pythons
Changes by Martin v. Löwis mar...@v.loewis.de: -- resolution: - wont fix status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue960325] --require feature option for configure/make (fail if building not possible)
Terry J. Reedy tjre...@udel.edu 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 ... platforms, as long as OpenSSL is installed on that platform. For bz2, there is This module provides a comprehensive interface for the bz2 compression library. If the library is not there, then the module obviously cannot function. Tkinter depends on tcl/tT being installed. I believe some crypto modules also require possibly absent libraries. (The PSF/Löwis Windows installer nicely provides all.) If someone wants to review the docs for all such dependencies (and perhaps whatever build docs or help strings or comments there are) and propose doc revision, that could be a separate issue. 2. I think the current default build process is right for most users. 3. Except for the PSF provided binaries, building is ultimately out of our hands. Distributions do what they do. I presume individual persons and organizations can patch the default build files to be stricter if they wish. If they cannot, neither can we ;-). 4. This seems to have become pretty much a non-issue. The OP says he has no further concrete interest because It's been a while since I had a computer without these libraries I am suspecting this is pretty much true for everyone who might otherwise care enough to provide a patch. -- resolution: - out of date stage: - needs patch status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue960325 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9611] FileIO not 64-bit safe under Windows
Martin v. Löwis mar...@v.loewis.de 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 handle should get locked). We should perhaps make an exception for the standard handles (0,1,2), and fall back to call the CRT write unless we determine they are also in binary mode. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9611] FileIO not 64-bit safe under Windows
Antoine Pitrou pit...@free.fr 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 tracker rep...@bugs.python.org http://bugs.python.org/issue9611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10315] smtplib.SMTP_SSL new in 2.6
New submission from Henning Hraban Ramm hra...@fiee.net: 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: open title: smtplib.SMTP_SSL new in 2.6 versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10315 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10243] Packaged Pythons
Max Skaller max.skal...@gmail.com added the comment: On Thu, Nov 4, 2010 at 5:19 PM, Ned Deily rep...@bugs.python.org wrote: Ned Deily n...@acm.org 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 easier to find: $ cd /Library/Frameworks/Python.framework/Versions/2.7/lib $ ls -l libpython2.7.dylib Ok.. so why is it called Python instead of Python.dylib? /Library/Frameworks/Python.frameworkfile Python Python: broken symbolic link to Versions/Current/Python /Library/Frameworks/Python.framework/Versions/3.1file Python Python: Mach-O universal binary with 2 architectures Python (for architecture ppc): Mach-O dynamically linked shared library ppc Python (for architecture i386): Mach-O dynamically linked shared library i386 Hmm .. i386? Oh dear, I'm running Snow Leopard and I generate 64 bit code. -- Added file: http://bugs.python.org/file19498/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10243 ___brbrdiv class=gmail_quoteOn Thu, Nov 4, 2010 at 5:19 PM, Ned Deily span dir=ltrlt;a href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;/span wrote:brblockquote class=gmail_quote style=margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex; br Ned Deily lt;a href=mailto:n...@acm.org;n...@acm.org/agt; added the comment:br br For what it#39;s worth, the a href=http://python.org; target=_blankpython.org/a 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 easier to find:br br $ cd /Library/Frameworks/Python.framework/Versions/2.7/libbr $ ls -l libpython2.7.dylibbr/blockquote/divbrOk.. so why is it called Python instead of Python.dylib?brbr/Library/Frameworks/Python.frameworkgt;file PythonbrPython: broken symbolic link to Versions/Current/Pythonbr br/Library/Frameworks/Python.framework/Versions/3.1gt;file PythonbrPython: Mach-O universal binary with 2 architecturesbrPython (for architecture ppc):Â Mach-O dynamically linked shared library ppcbrPython (for architecture i386): Mach-O dynamically linked shared library i386br brHmm .. i386? Oh dear, I#39;m running Snow Leopard and I generate 64 bit code.brbr ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9611] FileIO not 64-bit safe under Windows
Martin v. Löwis mar...@v.loewis.de 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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10243] Packaged Pythons
Changes by Martin v. Löwis mar...@v.loewis.de: Removed file: http://bugs.python.org/file19498/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10293] PyMemoryView object has obsolete members
Antoine Pitrou pit...@free.fr 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 want to bother. Let's remove it.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10293
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10293] PyMemoryView object has obsolete members
Antoine Pitrou pit...@free.fr added the comment: Done in r86174. -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10293 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3699] test_bigaddrspace broken
Antoine Pitrou pit...@free.fr 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 tracker rep...@bugs.python.org http://bugs.python.org/issue3699 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10316] tkFileDialog.askopenfilenames scrambling multiple file selection
New submission from Peter Hall peter.f.h...@nasa.gov: 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 : fileList = tkFileDialog.askopenfilenames(initialdir=self.startfiledir, title=Select Files for Processing, filetypes=self.ftypes, multiple=1) where startfiledir and ftypes are defined elsewhere. When this code is run a file selection box pops up listing the chosen directory. Selecting just one file works fine. To select multiple files the user highlights a selection of the displayed files by dragging the cursor over them with SHIFT left-mouse-button pressed. It also lists ALL the selected files in the File names: selection field at the bottom of the selection box. These are separated by spaces. Clicking Open results in the selection box program trying to treat the entire list as a single file name. IE. It looks for a single file called /home/mydir/file1 file2 file3 file4. Since there is no such file an error pop-up box appears with a File ... does not exist. message. It appears that the file name list is not being parsed into indivdual file names. I have tried combinations with askopenfilename instead of askopenfilenames and including/omitting multiple=1. I have also tried multiple=bool(1) and multiple=xxx where xxx=1 and xxx=bool(1). None of these change the behaviour. Is there a fault with my code ? Is this a bug in tkFileDialog.askopenfilenames ? Is there a workaround ? Suggestions are welcome. -- components: Tkinter messages: 120438 nosy: pfhall priority: normal severity: normal status: open title: tkFileDialog.askopenfilenames scrambling multiple file selection versions: Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10316 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10316] tkFileDialog.askopenfilenames scrambling multiple file selection
Changes by Peter Hall peter.f.h...@nasa.gov: -- type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10316 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10313] Reassure user: test_os BytesWarning is OK
Antoine Pitrou pit...@free.fr 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 rep...@bugs.python.org http://bugs.python.org/issue10313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10243] Packaged Pythons
Ned Deily n...@acm.org 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.org installers (including for 3.1) have been 32-bit only. Starting with 2.7 and the latest 3.2 alpha, there are two OS X installer downloads for each release, one 32-bit only (10.3 and later) and the other 32-bit/64-bit for use on 10.6. Also the Apple-supplied Python 2.6 in 10.6 is 32-bit/64-bit. Otherwise, if you need 64-bit for earlier releases, you will need to look elsewhere. For example, some of the third-party open source distributors for OS X like MacPorts support 64-bit builds of Python 2.6 and 3.1. Or you will need to build from scratch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10243 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10302] Add class-functions to hash many small objects with hashlib
Antoine Pitrou pit...@free.fr 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 rep...@bugs.python.org http://bugs.python.org/issue10302 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10313] Reassure user: test_os BytesWarning is OK
R. David Murray rdmur...@bitdance.com 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 rep...@bugs.python.org http://bugs.python.org/issue10313 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9611] FileIO not 64-bit safe under Windows
Amaury Forgeot d'Arc amaur...@gmail.com 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 rep...@bugs.python.org http://bugs.python.org/issue9611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9611] FileIO not 64-bit safe under Windows
Martin v. Löwis mar...@v.loewis.de 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 exception? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9611] FileIO not 64-bit safe under Windows
Amaury Forgeot d'Arc amaur...@gmail.com 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 rep...@bugs.python.org http://bugs.python.org/issue9611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9611] FileIO not 64-bit safe under Windows
Antoine Pitrou pit...@free.fr 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 received after part of the data has been written. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9611 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
