From report at bugs.python.org Wed May 1 00:02:18 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 30 Apr 2013 22:02:18 +0000 Subject: [issue12458] Tracebacks should contain the first line of continuation lines In-Reply-To: <1309499207.17.0.676241559437.issue12458@psf.upfronthosting.co.za> Message-ID: <1367359338.27.0.573518383821.issue12458@psf.upfronthosting.co.za> Terry J. Reedy added the comment: idlelib has two files that *might* be helpful to anyone who wants to pursue this: PyParse.py and HyperParser.py. One use of the latter is for calltips. When the user types '(', the HyperParser is used first to determine whether the '(' is preceded by an operator (making it a grouper) or not (making it a call operator). In the later case, it parses backwards to find the beginning of the callable expression, which is then evaluated to get the callable (if it does not contain an embedded call) and hence the signature. Parsing forward and back from a given line might be similar. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 00:06:19 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Apr 2013 22:06:19 +0000 Subject: [issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function In-Reply-To: <1367269025.02.0.400879045482.issue17870@psf.upfronthosting.co.za> Message-ID: <1367359579.01.0.171966633468.issue17870@psf.upfronthosting.co.za> STINNER Victor added the comment: Here is a first patch adding the following functions: PyObject* PyLong_FromIntMax_t(intmax_t v); PyObject* PyLong_FromUintMax_t(uintmax_t v); intmax_t PyLong_AsIntMax_t(PyObject *pylong); uintmax_t PyLong_AsUintMax_t(PyObject *pylong); I used AC_TYPE_INTMAX_T and AC_TYPE_UINTMAX_T in configure.ac, so intmax_t and uintmax_t are defined if the platform does not provide them. (I guess that these types are defined in pyconfig.h.) On Windows, Visual Studio 2010 supports stdint.h, and so these types are available. autoheader && autoconf must be called to regenerate configure script and pyconfig.h.in template. ---------- keywords: +patch Added file: http://bugs.python.org/file30082/intmax_t.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 00:17:55 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Apr 2013 22:17:55 +0000 Subject: [issue17712] test_gdb failures In-Reply-To: <1365856245.17.0.785295424505.issue17712@psf.upfronthosting.co.za> Message-ID: <3b0cYt2XY8z7Lmk@mail.python.org> Roundup Robot added the comment: New changeset 4e58cafbebfc by Antoine Pitrou in branch '3.3': Issue #17712: Fix test_gdb failures on Ubuntu 13.04. http://hg.python.org/cpython/rev/4e58cafbebfc New changeset 4e186581fea7 by Antoine Pitrou in branch 'default': Issue #17712: Fix test_gdb failures on Ubuntu 13.04. http://hg.python.org/cpython/rev/4e186581fea7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 00:21:21 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 30 Apr 2013 22:21:21 +0000 Subject: [issue17712] test_gdb failures In-Reply-To: <1365856245.17.0.785295424505.issue17712@psf.upfronthosting.co.za> Message-ID: <3b0cdr3pH8z7Lkk@mail.python.org> Roundup Robot added the comment: New changeset c241831a91f2 by Antoine Pitrou in branch '2.7': Issue #17712: Fix test_gdb failures on Ubuntu 13.04. http://hg.python.org/cpython/rev/c241831a91f2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 00:22:14 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 30 Apr 2013 22:22:14 +0000 Subject: [issue17712] test_gdb failures In-Reply-To: <1365856245.17.0.785295424505.issue17712@psf.upfronthosting.co.za> Message-ID: <1367360534.41.0.671742206069.issue17712@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 00:52:46 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Apr 2013 22:52:46 +0000 Subject: [issue17884] Try to reuse stdint.h types like int32_t Message-ID: <1367362366.81.0.489465512002.issue17884@psf.upfronthosting.co.za> New submission from STINNER Victor: In different places, macros like SIZEOF_VOID_P or SIZEOF_LONG to choose a type, whereas the C language proposes standard types since ISO C99: intXX_t and uintXX_t (8, 16, 32, 64), intptr_t, etc. Python should rely on these new types instead of trying to reimplement this standard. autotools provides missing types if needed. On Windows, stdint.h is supported in Microsoft Visual Studio 2010. Attached patch reuses stdint.h types in different places. I only tested it on Linux Fedora 11. sha3 module should also be modified. I don't know if int64_t and uint64_t are always supported, nor if we can rely on them. Does Python support platform without 64-bit integer type? The md5 module uses PY_LONG_LONG to get a 64-bit type. Does anyone know a platform where the md5 module is not compiled? ---------- files: reuse_stdint_types.patch keywords: patch messages: 188192 nosy: Devin Jeanpierre, haypo, mark.dickinson priority: normal severity: normal status: open title: Try to reuse stdint.h types like int32_t versions: Python 3.4 Added file: http://bugs.python.org/file30083/reuse_stdint_types.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 00:53:11 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Apr 2013 22:53:11 +0000 Subject: [issue17884] Try to reuse stdint.h types like int32_t In-Reply-To: <1367362366.81.0.489465512002.issue17884@psf.upfronthosting.co.za> Message-ID: <1367362391.62.0.199045447052.issue17884@psf.upfronthosting.co.za> STINNER Victor added the comment: See also issue #17870 related to intmax_t and uintmax_t. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 00:53:25 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Apr 2013 22:53:25 +0000 Subject: [issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function In-Reply-To: <1367269025.02.0.400879045482.issue17870@psf.upfronthosting.co.za> Message-ID: <1367362405.87.0.577247399807.issue17870@psf.upfronthosting.co.za> STINNER Victor added the comment: See also issue #17884. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 01:31:56 2013 From: report at bugs.python.org (Eric Schulz) Date: Tue, 30 Apr 2013 23:31:56 +0000 Subject: [issue16177] IDLE Crash on Open Parens In-Reply-To: <1349800735.66.0.856769538072.issue16177@psf.upfronthosting.co.za> Message-ID: <1367364716.17.0.667037415385.issue16177@psf.upfronthosting.co.za> Eric Schulz added the comment: I can repo with MacOS 10.8.3 and Tcl 8.5.13. I'm fairly certian it is triggered by the calltip. However, it is intermittent. I can work for a while, get comfortable and let my guard down, then hit the crash. Typically after I have a good amount of unsaved work. Once I hit it, it'll repro easily for the rest of the day. See excerpts below, full stack trace attached. ----------------------- Process: Python [1036] Path: /Applications/Python 2.7/IDLE.app/Contents/MacOS/Python Identifier: org.python.IDLE Version: 2.7.3 (2.7.3) Code Type: X86 (Native) Parent Process: launchd [844] User ID: 501 Date/Time: 2013-04-30 16:07:14.372 -0700 OS Version: Mac OS X 10.8.3 (12D78) Report Version: 10 Interval Since Last Report: 136409 sec Crashes Since Last Report: 8 Per-App Interval Since Last Report: 82331 sec Per-App Crashes Since Last Report: 5 Anonymous UUID: 2FC95C75-D434-7DE8-F643-1CC8AA4EB026 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BREAKPOINT (SIGTRAP) Exception Codes: 0x0000000000000002, 0x0000000000000000 Application Specific Information: *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1000) creating window shape' 0x476000 - 0x547ff7 +Tcl (8.5.13 - 8.5.13) <5038805B-75D8-4B2F-ACE5-55397CE37577> /Library/Frameworks/Tcl.framework/Versions/8.5/Tcl 0x571000 - 0x66ffe7 +Tk (8.5.13 - 8.5.13) <0F00C53A-5891-5B7A-1914-290EDC0E4612> /Library/Frameworks/Tk.framework/Versions/8.5/Tk ---------- Added file: http://bugs.python.org/file30084/issue16177_stack_trace.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 01:45:27 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 30 Apr 2013 23:45:27 +0000 Subject: [issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function In-Reply-To: <1367269025.02.0.400879045482.issue17870@psf.upfronthosting.co.za> Message-ID: <1367365527.67.0.884562273484.issue17870@psf.upfronthosting.co.za> STINNER Victor added the comment: Another patch to use PyLong_FromIntMax_t(). ---------- Added file: http://bugs.python.org/file30085/use_intmax_t.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 03:28:02 2013 From: report at bugs.python.org (HCT) Date: Wed, 01 May 2013 01:28:02 +0000 Subject: [issue17885] multiprocessing.Process child process imports package instead of parent file Message-ID: <1367371682.48.0.908300768897.issue17885@psf.upfronthosting.co.za> New submission from HCT: created a project with the following content CODEC/ CODEC/video.py CODEC/audio.py CODEC/__init__.py CRC/ CRC/crc24.py CRC/crc32.py CRC/__init__.py TEST/test_crc.py TEST/test_codec.py TEST/__init__.py __init__.py test.py main.py test.py contain tests that launches multiple multiprocessing.Process to test diffferent module in parallel, but always fail to launch child processes for test with AttributeError. I spent lots of time trying to figure out why my code don't work. I also tried to use the examples from http://docs.python.org/dev/library/multiprocessing.html#the-process-class and they also gives AttributeError when launching child process. in the end, I figured out it's because Pythong file test.py has same name as package TEST. change test.py to test_all.py and everything worked. It looks multiprocessing import defaults to import package, not the parent file when file name without suffix is same as package. ---------- components: Library (Lib) messages: 188197 nosy: hct priority: normal severity: normal status: open title: multiprocessing.Process child process imports package instead of parent file type: compile error versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 03:38:09 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 01 May 2013 01:38:09 +0000 Subject: [issue17885] multiprocessing.Process child process imports package instead of parent file In-Reply-To: <1367371682.48.0.908300768897.issue17885@psf.upfronthosting.co.za> Message-ID: <1367372289.48.0.749536855666.issue17885@psf.upfronthosting.co.za> R. David Murray added the comment: I take it you are on a case insensitive file system, in which case this is just the way imports work in Python: a package is preferred to a .py file with the same name. ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed type: compile error -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 03:49:50 2013 From: report at bugs.python.org (Decade) Date: Wed, 01 May 2013 01:49:50 +0000 Subject: [issue17874] ProcessPoolExecutor in interactive shell doesn't work in Windows In-Reply-To: <1367291797.68.0.0512798150346.issue17874@psf.upfronthosting.co.za> Message-ID: <1367372990.09.0.0557237500029.issue17874@psf.upfronthosting.co.za> Decade added the comment: Ah. Then, a documentation error. The error message ("queue.Full"?) and the documentation are totally not clear about that. Does ProcessPoolExecutor just not require tasks to be picklable in Unix? Also, this raises questions about what exactly "picklable" means, and why it's not defined in the documentation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 04:20:00 2013 From: report at bugs.python.org (Hank Christian) Date: Wed, 01 May 2013 02:20:00 +0000 Subject: [issue17886] Invitation to connect on LinkedIn Message-ID: <1812581655.1517967.1367374798003.JavaMail.app@ela4-app0132.prod> New submission from Hank Christian: LinkedIn ------------ Python, I'd like to add you to my professional network on LinkedIn. - Henry Henry Christian ADJUNCT PROFESSOR at Central Texas College Greater Los Angeles Area Confirm that you know Henry Christian: https://www.linkedin.com/e/-3qcne3-hg5vnelc-3m/isd/10674146693/f8KKDSuG/?hs=false&tok=0pSa4dW8LbLlI1 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/-3qcne3-hg5vnelc-3m/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I4269541394_1/?hs=false&tok=3ubW__G4DbLlI1 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. ---------- messages: 188200 nosy: hankchristian priority: normal severity: normal status: open title: Invitation to connect on LinkedIn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 04:22:26 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 01 May 2013 02:22:26 +0000 Subject: [issue17886] spam In-Reply-To: <1812581655.1517967.1367374798003.JavaMail.app@ela4-app0132.prod> Message-ID: <1367374946.11.0.217697220878.issue17886@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> invalid status: open -> closed title: Invitation to connect on LinkedIn -> spam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 04:23:13 2013 From: report at bugs.python.org (Kyle Roberts) Date: Wed, 01 May 2013 02:23:13 +0000 Subject: [issue15984] Wrong documentation for PyUnicode_FromObject() and PyUnicode_FromEncodedObject() In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za> Message-ID: <1367374993.02.0.329691791268.issue15984@psf.upfronthosting.co.za> Kyle Roberts added the comment: I've uploaded a new patch with the obj argument properly marked up. Brian, I think *obj* is what we want based on other examples in that file. It looks like italics is typically used when discussing parameters since each parameter is italicized in the signature. R.David and Serhiy, I thought about the use of "coercion" some more and I think the current wording is fine. "Type coercion/conversion" is a commonly used phrase with some languages, so I think the phrase is applicable here as well (for a python example: http://docs.python.org/release/2.5.2/ref/coercion-rules.html). Let me know if you'd still like to see it changed. Thanks. ---------- Added file: http://bugs.python.org/file30086/from_object_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 05:48:18 2013 From: report at bugs.python.org (Ned Deily) Date: Wed, 01 May 2013 03:48:18 +0000 Subject: [issue16177] Typing left parenthesis in IDLE causes intermittent Cocoa Tk crash on OS X In-Reply-To: <1349800735.66.0.856769538072.issue16177@psf.upfronthosting.co.za> Message-ID: <1367380098.77.0.0718973878431.issue16177@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the report, Eric. It confirms that the problem still exists with everything current. I'm sorry you are hitting the crash. Without being able to reliably reproduce the problem, it's difficult to be able to help. Are there any hints you can give about what you were doing leading up to the crash, e.g. how many IDLE windows open, how large and where were they placed on the desktop, any hidden IDLE windows, how large a file if editing (is the window scrolling)? The only other practical thing I can think of is to try a debug build of Python and of Tcl/Tk in the hopes of getting a more precise stack trace. (I could supply that.) I suspect opening a Tk or an Apple incident without more to go will not be very productive. ---------- components: -IDLE nosy: +wordtech stage: -> test needed title: IDLE Crash on Open Parens -> Typing left parenthesis in IDLE causes intermittent Cocoa Tk crash on OS X _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 08:34:48 2013 From: report at bugs.python.org (anatoly techtonik) Date: Wed, 01 May 2013 06:34:48 +0000 Subject: [issue17887] docs: summary page - generator vs iterator vs iterable Message-ID: <1367390087.97.0.0883934646573.issue17887@psf.upfronthosting.co.za> New submission from anatoly techtonik: Docs lack a good summary page comparing three concepts. The main question is how do I tell if something is a sequence, generator, iterator or iterable? I found myself puzzled that range() is neither generator or iterator. ---------- assignee: docs at python components: Documentation messages: 188203 nosy: docs at python, techtonik priority: normal severity: normal status: open title: docs: summary page - generator vs iterator vs iterable _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 10:57:05 2013 From: report at bugs.python.org (Paul Melis) Date: Wed, 01 May 2013 08:57:05 +0000 Subject: [issue10513] sqlite3.InterfaceError after commit In-Reply-To: <1290515734.43.0.643837241692.issue10513@psf.upfronthosting.co.za> Message-ID: <1367398625.72.0.673784507237.issue10513@psf.upfronthosting.co.za> Paul Melis added the comment: Just a bit more info on the patch. When running stock Python 2.7.4 the attached test script bug-binding_parameter_0.py returns: module: 2.6.0 sqlite: 3.7.9 Archives Archives/2011 Archives/2012 Traceback (most recent call last): File "bug-binding_parameter_0.py", line 45, in cur = dbconn.execute('select uidvalidity from folders where name=?', (folder,)) sqlite3.InterfaceError: Error binding parameter 0 - probably unsupported type. The error suggests a misuse of the sqlite3 API, but the actual SQLite error is masked. After altering _sqlite/statement.c to include the SQLite error code (as in the patch), we get: module: 2.6.0 sqlite: 3.7.9 Archives Archives/2011 Archives/2012 Traceback (most recent call last): File "bug-binding_parameter_0.py", line 45, in cur = dbconn.execute('select uidvalidity from folders where name=?', (folder,)) sqlite3.InterfaceError: Error binding parameter 0 - probably unsupported type. (sqlite error 21) Error 21 = SQLITE_MISUSE, suggesting something is definitely wrong in the way the SQLite API is used (for this test case). Commenting out the ACTION_RESET all works fine again: module: 2.6.0 sqlite: 3.7.9 Archives Archives/2011 Archives/2012 ---------- Added file: http://bugs.python.org/file30087/bug-binding_parameter_0.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 12:19:21 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 01 May 2013 10:19:21 +0000 Subject: [issue17874] ProcessPoolExecutor in interactive shell doesn't work in Windows In-Reply-To: <1367291797.68.0.0512798150346.issue17874@psf.upfronthosting.co.za> Message-ID: <1367403561.89.0.296497432034.issue17874@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > Ah. Then, a documentation error. The error message ("queue.Full"?) and > the documentation are totally not clear about that. Once something goes wrong you are likely to get a cascade of errors, and the first one reported is not necessarily the original cause. > Does ProcessPoolExecutor just not require tasks to be picklable in Unix? On Unix the main process forks using os.fork() when the executor is created. The forked processes inherit all the definitions previously created in the main process. > Also, this raises questions about what exactly "picklable" means, and why > it's not defined in the documentation. Since concurrent.futures uses multiprocessing the following section applies http://docs.python.org/dev/library/multiprocessing.html#windows ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 12:54:47 2013 From: report at bugs.python.org (Nidan) Date: Wed, 01 May 2013 10:54:47 +0000 Subject: [issue16133] asyncore.dispatcher.recv doesn't handle EAGAIN / EWOULDBLOCK In-Reply-To: <1349366792.42.0.417654527681.issue16133@psf.upfronthosting.co.za> Message-ID: <1367405687.27.0.33607733607.issue16133@psf.upfronthosting.co.za> Nidan added the comment: Why should asynchat.handle_read care about closed sockets if asyncore.recv does that already? Currently asynchat.handle_read handles empty strings from asycore.recv gracefully (by doing some unnecessary work aka executing the remainder of the function), it doesn't treat them specially. The only path that might cause asynchat.handle_read to close the socket requires asycore.recv to throw. Introducing None as possible return value from asyncore.recv therefore seems unnecessary to me. Changed the patch accordingly. ---------- Added file: http://bugs.python.org/file30088/issue16133.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 13:13:20 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 May 2013 11:13:20 +0000 Subject: [issue16518] add "buffer protocol" to glossary In-Reply-To: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za> Message-ID: <3b0xmb6SCJz7LjZ@mail.python.org> Roundup Robot added the comment: New changeset d1aa8a9eba44 by Ezio Melotti in branch '2.7': #16518: fix links in glossary entry. http://hg.python.org/cpython/rev/d1aa8a9eba44 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 13:40:59 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 01 May 2013 11:40:59 +0000 Subject: [issue16518] add "buffer protocol" to glossary In-Reply-To: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za> Message-ID: <1367408459.06.0.27015617379.issue16518@psf.upfronthosting.co.za> Ezio Melotti added the comment: The attached patch replaces things like "object that support the buffer protocol/interface/API" with "bytes-like objects" throughout the docs. The patch doesn't change error messages/docstrings. I also noticed that on 2.7[0], the section about the buffer protocol in Doc/c-api/buffer.rst is called "Buffers and Memoryview Objects" and it's not as clear as the one on 3.x[1]. Should this section be backported? [0]: http://docs.python.org/2.7/c-api/buffer.html#bufferobjects [1]: http://docs.python.org/dev/c-api/buffer.html#bufferobjects ---------- Added file: http://bugs.python.org/file30089/issue16518-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 13:42:15 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 May 2013 11:42:15 +0000 Subject: [issue16518] add "buffer protocol" to glossary In-Reply-To: <1367408459.06.0.27015617379.issue16518@psf.upfronthosting.co.za> Message-ID: <1367408532.2541.0.camel@fsol> Antoine Pitrou added the comment: > I also noticed that on 2.7[0], the section about the buffer protocol > in Doc/c-api/buffer.rst is called "Buffers and Memoryview Objects" and > it's not as clear as the one on 3.x[1]. Should this section be > backported? The "buffer protocol" situation is different on 2.x, please let's concentrate on 3.x :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 13:50:28 2013 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 01 May 2013 11:50:28 +0000 Subject: [issue17884] Try to reuse stdint.h types like int32_t In-Reply-To: <1367362366.81.0.489465512002.issue17884@psf.upfronthosting.co.za> Message-ID: <1367409028.36.0.36581061572.issue17884@psf.upfronthosting.co.za> Mark Dickinson added the comment: Relying on things like int64_t or uint64_t is tricky, both in principle *and* in practice. C99 (7.18.1.1) specifies that the types are optional, but that if the implementation provides types with the appropriate characteristics then the typenames should exist. I think we could probably get away with assuming the existence of uint32_t and int32_t and smaller types, but uint64_t and int64_t may be a stretch, particularly on ARM-style platforms. In practice, we've had significant difficulties in the past simply finding and identifying exact-width types in our autoconf machinery: whether they're defined in or seems to vary from platform to platform, as does whether they're defined as typedef's or preprocessor macros. I *think* that since the issue #10052 fix, the current autoconf machinery is now fairly good at finding those types across platforms, but I wouldn't want to make any bets. I do agree that in principle it would be nice to define conversions for the fixed-width types and have everything else defer to those. There's also some cleanup to be done with respect to semantics; I think it's still the case that the various PyLong_FromXXX functions have different behaviours with respect to overflow, __int__, __index__ and the like. If we just blindly map the old functions to the fixed-width versions we're going to end up changing those semantics on some platforms. I'd be quite happy to see fixed-width conversion functions that *completely ignore* __int__ and __index__, and leave the magic stuff to general PyNumber_... functions. Adding skrah to the nosy, since this is something I think he's spent some time thinking about, too. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 13:58:24 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 May 2013 11:58:24 +0000 Subject: [issue11078] Have test___all__ check for duplicates In-Reply-To: <1296489333.39.0.726513534716.issue11078@psf.upfronthosting.co.za> Message-ID: <3b0ymb5Tbzz7LjZ@mail.python.org> Roundup Robot added the comment: New changeset 3f1bcfbed022 by Ezio Melotti in branch 'default': #11078: test___all__ now checks for duplicates in __all__. Initial patch by R. David Murray. http://hg.python.org/cpython/rev/3f1bcfbed022 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 13:58:31 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 01 May 2013 11:58:31 +0000 Subject: [issue16141] Possible simplification for old-style exception handling code in stdlib In-Reply-To: <1349448386.51.0.852233729423.issue16141@psf.upfronthosting.co.za> Message-ID: <1367409511.45.0.582122199705.issue16141@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Shouldn't this issue be closed? (the proposed patch was applied in Oct. last year) ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 13:59:15 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 01 May 2013 11:59:15 +0000 Subject: [issue11078] Have test___all__ check for duplicates In-Reply-To: <1296489333.39.0.726513534716.issue11078@psf.upfronthosting.co.za> Message-ID: <1367409555.2.0.884048383635.issue11078@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> ezio.melotti resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 14:02:36 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 01 May 2013 12:02:36 +0000 Subject: [issue4965] Can doc index of html version be separately scrollable? In-Reply-To: <1232148633.29.0.602528403512.issue4965@psf.upfronthosting.co.za> Message-ID: <1367409756.82.0.618411333243.issue4965@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 14:23:06 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 01 May 2013 12:23:06 +0000 Subject: [issue7855] Add test cases for ctypes/winreg for issues found in IronPython In-Reply-To: <1265311030.9.0.277359551887.issue7855@psf.upfronthosting.co.za> Message-ID: <1367410986.49.0.635191533989.issue7855@psf.upfronthosting.co.za> Ezio Melotti added the comment: The attached patch now passes on Linux. I raised a SkipTest on non-Windows platforms and changed Lib/ctypes/test/__init__.py to handle it. If someone can confirm that the patch works on Windows I'll commit it. The ValueError I reported in my previous message has also been reported in #16396 and should be fixed. ---------- nosy: +terry.reedy, zach.ware versions: -Python 3.2 Added file: http://bugs.python.org/file30090/issue7855.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 14:23:50 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 01 May 2013 12:23:50 +0000 Subject: [issue16396] Importing ctypes.wintypes on Linux gives a traceback In-Reply-To: <1351956172.0.0.64927799046.issue16396@psf.upfronthosting.co.za> Message-ID: <1367411030.12.0.841504955032.issue16396@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> needs patch type: -> behavior versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 14:34:31 2013 From: report at bugs.python.org (Thomas Fenzl) Date: Wed, 01 May 2013 12:34:31 +0000 Subject: [issue17841] Remove missing aliases from codecs documentation In-Reply-To: <1366878629.86.0.715834730144.issue17841@psf.upfronthosting.co.za> Message-ID: <1367411671.85.0.201343624452.issue17841@psf.upfronthosting.co.za> Thomas Fenzl added the comment: This is a documentation patch against 3.3 with the aliases removed. ---------- keywords: +patch nosy: +Thomas Fenzl Added file: http://bugs.python.org/file30091/issue17841_codecs_docu.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 14:44:05 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 01 May 2013 12:44:05 +0000 Subject: [issue13515] Consistent documentation practices for security concerns and considerations In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za> Message-ID: <1367412245.21.0.653804330933.issue13515@psf.upfronthosting.co.za> Ezio Melotti added the comment: Attached a patch that includes the section proposed by Nick in the first message. I also changed "in-line text" with "a note" as suggested in msg148720. I didn't specify a "ReST note" because I think that depending on the situation, an actual warning, a note, or even an in-line text might be acceptable. ---------- components: +Devguide -Documentation stage: needs patch -> patch review Added file: http://bugs.python.org/file30092/issue13515-devguide.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 14:44:50 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 01 May 2013 12:44:50 +0000 Subject: [issue14097] Improve the "introduction" page of the tutorial In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za> Message-ID: <1367412290.62.0.304569792953.issue14097@psf.upfronthosting.co.za> Ezio Melotti added the comment: If there aren't any comments I will commit this soon. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 14:46:55 2013 From: report at bugs.python.org (Georg Brandl) Date: Wed, 01 May 2013 12:46:55 +0000 Subject: [issue17857] sqlite modules doesn't build with 2.7.4 on Mac OS X 10.4 In-Reply-To: <1367088365.18.0.161187485212.issue17857@psf.upfronthosting.co.za> Message-ID: <1367412415.31.0.837410099039.issue17857@psf.upfronthosting.co.za> Georg Brandl added the comment: Would be nice, yes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 14:55:14 2013 From: report at bugs.python.org (anatoly techtonik) Date: Wed, 01 May 2013 12:55:14 +0000 Subject: [issue17888] docs: more information on documentation team Message-ID: <1367412914.06.0.588625037016.issue17888@psf.upfronthosting.co.za> New submission from anatoly techtonik: To help people understand that they can actually improve Python docs themselves, how about the following changes: http://docs.python.org/3/bugs.html - rename from "Reporting Bugs" to "Dealing with Bugs". Explain that sometimes fixing bug is easier than reporting, because it involves less time from all people in total. Link to step-by-step documentation for the process and include channel for proposals how to make the process more streamlined. Add links to archive and docs at python.org mailing list info http://mail.python.org/mailman/listinfo/docs On this info page make it clear that "Python documentation team" is not a team in common narrow sense, but a group of volunteers open for everybody. Either by providing a link to team page with listed members, or by replacing the text: - "Mailing list for the Python documentation team" + "Mailing list for people collaborating on Python docs" ---------- assignee: docs at python components: Documentation messages: 188218 nosy: docs at python, techtonik priority: normal severity: normal status: open title: docs: more information on documentation team _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 14:57:25 2013 From: report at bugs.python.org (Georg Brandl) Date: Wed, 01 May 2013 12:57:25 +0000 Subject: [issue17888] docs: more information on documentation team In-Reply-To: <1367412914.06.0.588625037016.issue17888@psf.upfronthosting.co.za> Message-ID: <1367413045.37.0.518904808295.issue17888@psf.upfronthosting.co.za> Georg Brandl added the comment: Sounds good, please prepare a patch. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 15:00:52 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 01 May 2013 13:00:52 +0000 Subject: [issue17888] docs: more information on documentation team In-Reply-To: <1367412914.06.0.588625037016.issue17888@psf.upfronthosting.co.za> Message-ID: <1367413252.86.0.567474745927.issue17888@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 15:09:49 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 May 2013 13:09:49 +0000 Subject: [issue14679] Define an __all__ for html.parser In-Reply-To: <1335470773.41.0.349037543033.issue14679@psf.upfronthosting.co.za> Message-ID: <3b10M05DyQzQyw@mail.python.org> Roundup Robot added the comment: New changeset 1f7ce8af3356 by Ezio Melotti in branch 'default': #14679: add an __all__ (that contains only HTMLParser) to html.parser. http://hg.python.org/cpython/rev/1f7ce8af3356 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 15:11:38 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 01 May 2013 13:11:38 +0000 Subject: [issue14679] Define an __all__ for html.parser In-Reply-To: <1335470773.41.0.349037543033.issue14679@psf.upfronthosting.co.za> Message-ID: <1367413898.94.0.736537497205.issue14679@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 15:16:31 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 May 2013 13:16:31 +0000 Subject: [issue17529] fix os.sendfile() documentation regarding the type of file descriptor In-Reply-To: <1364040887.67.0.333340627096.issue17529@psf.upfronthosting.co.za> Message-ID: <3b10Vl1FT3zSPZ@mail.python.org> Roundup Robot added the comment: New changeset 4f45f9cde9b4 by Charles-Francois Natali in branch '3.3': Issue #17529: Fix os.sendfile() documentation regarding the type of file http://hg.python.org/cpython/rev/4f45f9cde9b4 New changeset 538055b28ba6 by Charles-Francois Natali in branch 'default': Issue #17529: Fix os.sendfile() documentation regarding the type of file http://hg.python.org/cpython/rev/538055b28ba6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 15:17:36 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 01 May 2013 13:17:36 +0000 Subject: [issue17529] fix os.sendfile() documentation regarding the type of file descriptor In-Reply-To: <1364040887.67.0.333340627096.issue17529@psf.upfronthosting.co.za> Message-ID: <1367414256.39.0.0194217829624.issue17529@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 15:20:15 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 May 2013 13:20:15 +0000 Subject: [issue17802] html.HTMLParser raises UnboundLocalError: In-Reply-To: <1366455496.44.0.252693262326.issue17802@psf.upfronthosting.co.za> Message-ID: <3b10b265Fhz7LkG@mail.python.org> Roundup Robot added the comment: New changeset 9cb90c1a1a46 by Ezio Melotti in branch '3.3': #17802: Fix an UnboundLocalError in html.parser. Initial tests by Thomas Barlow. http://hg.python.org/cpython/rev/9cb90c1a1a46 New changeset 20be90a3a714 by Ezio Melotti in branch 'default': #17802: merge with 3.3. http://hg.python.org/cpython/rev/20be90a3a714 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 15:24:37 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 01 May 2013 13:24:37 +0000 Subject: [issue13633] Handling of hex character references in HTMLParser.handle_charref In-Reply-To: <1324277757.56.0.0733657691883.issue13633@psf.upfronthosting.co.za> Message-ID: <1367414677.64.0.319437487119.issue13633@psf.upfronthosting.co.za> Ezio Melotti added the comment: Another option is to add a new "convert_entities" option that, when True, automatically converts character references and doesn't call handle_charref and handle_entityref. (See also #17802.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 15:25:05 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 01 May 2013 13:25:05 +0000 Subject: [issue17802] html.HTMLParser raises UnboundLocalError: In-Reply-To: <1366455496.44.0.252693262326.issue17802@psf.upfronthosting.co.za> Message-ID: <1367414705.93.0.137046531243.issue17802@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the report! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 15:46:54 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 01 May 2013 13:46:54 +0000 Subject: [issue16141] Possible simplification for old-style exception handling code in stdlib In-Reply-To: <1349448386.51.0.852233729423.issue16141@psf.upfronthosting.co.za> Message-ID: <1367416014.04.0.0268276285708.issue16141@psf.upfronthosting.co.za> R. David Murray added the comment: I'm guessing Serhiy left it open because of the question about multiprocessing and asyncore. Given that he rated them as dubious, let's just close it. ---------- nosy: +r.david.murray resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 15:57:11 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 01 May 2013 13:57:11 +0000 Subject: [issue16523] attrgetter and itemgetter signatures in docs need cleanup In-Reply-To: <1353510966.46.0.566270540705.issue16523@psf.upfronthosting.co.za> Message-ID: <1367416631.45.0.805655457752.issue16523@psf.upfronthosting.co.za> Ezio Melotti added the comment: Attached an updated patch that uses the double signature. ---------- stage: patch review -> commit review versions: -Python 3.2 Added file: http://bugs.python.org/file30093/issue16523-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 16:18:25 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 May 2013 14:18:25 +0000 Subject: [issue17810] Implement PEP 3154 (pickle protocol 4) In-Reply-To: <1366526938.19.0.00976593994103.issue17810@psf.upfronthosting.co.za> Message-ID: <1367417905.74.0.286751126367.issue17810@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is an updated framing patch which supports pickletools.optimize(). ---------- Added file: http://bugs.python.org/file30094/framing2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 16:38:47 2013 From: report at bugs.python.org (SilentGhost) Date: Wed, 01 May 2013 14:38:47 +0000 Subject: [issue17889] argparse subparsers break without without argument Message-ID: <1367419127.75.0.745110638267.issue17889@psf.upfronthosting.co.za> New submission from SilentGhost: If you run attached file w/ 3.2 and 3.3 (and later) versions, you'll notice that the new version of parser doesn't handle empty argument list: $ python3.2 test.py usage: test.py [-h] {demo} ... test.py: error: too few arguments $ python3.3 test.py Namespace() Everything is naturally failing in 3.3 version as the execution continues with the empty Namespace. I suspect this is due to the issue10424 that removed explicit check for positionals. ---------- components: Library (Lib) files: test.py keywords: 3.3regression messages: 188228 nosy: SilentGhost, bethard, maker, r.david.murray priority: normal severity: normal status: open title: argparse subparsers break without without argument type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30095/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 16:51:49 2013 From: report at bugs.python.org (anatoly techtonik) Date: Wed, 01 May 2013 14:51:49 +0000 Subject: [issue17888] docs: more information on documentation team In-Reply-To: <1367412914.06.0.588625037016.issue17888@psf.upfronthosting.co.za> Message-ID: <1367419909.97.0.254550633534.issue17888@psf.upfronthosting.co.za> anatoly techtonik added the comment: May take a few days. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 16:58:13 2013 From: report at bugs.python.org (Kyle Roberts) Date: Wed, 01 May 2013 14:58:13 +0000 Subject: [issue17282] document the defaultTest parameter to unittest.main() In-Reply-To: <1361664894.83.0.085559336561.issue17282@psf.upfronthosting.co.za> Message-ID: <1367420293.29.0.512066738433.issue17282@psf.upfronthosting.co.za> Changes by Kyle Roberts : ---------- keywords: +patch Added file: http://bugs.python.org/file30096/default_test_3.4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 17:00:14 2013 From: report at bugs.python.org (Kyle Roberts) Date: Wed, 01 May 2013 15:00:14 +0000 Subject: [issue17282] document the defaultTest parameter to unittest.main() In-Reply-To: <1361664894.83.0.085559336561.issue17282@psf.upfronthosting.co.za> Message-ID: <1367420414.67.0.563212457849.issue17282@psf.upfronthosting.co.za> Kyle Roberts added the comment: I've uploaded a patch documenting defaultTest in the latest branch and also in the previous branches. ---------- nosy: +kyle.roberts Added file: http://bugs.python.org/file30097/default_test_2.7-3.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 17:07:56 2013 From: report at bugs.python.org (SilentGhost) Date: Wed, 01 May 2013 15:07:56 +0000 Subject: [issue17889] argparse subparsers break without arguments In-Reply-To: <1367419127.75.0.745110638267.issue17889@psf.upfronthosting.co.za> Message-ID: <1367420876.13.0.68168513847.issue17889@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- title: argparse subparsers break without without argument -> argparse subparsers break without arguments _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 18:01:32 2013 From: report at bugs.python.org (Zachary Ware) Date: Wed, 01 May 2013 16:01:32 +0000 Subject: [issue7855] Add test cases for ctypes/winreg for issues found in IronPython In-Reply-To: <1265311030.9.0.277359551887.issue7855@psf.upfronthosting.co.za> Message-ID: <1367424092.42.0.555581915943.issue7855@psf.upfronthosting.co.za> Zachary Ware added the comment: The patch works fine on Win 7 for me. I left a couple comments on Rietveld, neither of which is of great importance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 18:02:11 2013 From: report at bugs.python.org (Michael Foord) Date: Wed, 01 May 2013 16:02:11 +0000 Subject: [issue7855] Add test cases for ctypes/winreg for issues found in IronPython In-Reply-To: <1265311030.9.0.277359551887.issue7855@psf.upfronthosting.co.za> Message-ID: <1367424131.73.0.524271387664.issue7855@psf.upfronthosting.co.za> Changes by Michael Foord : ---------- nosy: -michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 18:31:15 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 01 May 2013 16:31:15 +0000 Subject: [issue14097] Improve the "introduction" page of the tutorial In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za> Message-ID: <1367425875.36.0.676267214237.issue14097@psf.upfronthosting.co.za> R. David Murray added the comment: Review comments added. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 18:37:54 2013 From: report at bugs.python.org (Devin Jeanpierre) Date: Wed, 01 May 2013 16:37:54 +0000 Subject: [issue17884] Try to reuse stdint.h types like int32_t In-Reply-To: <1367362366.81.0.489465512002.issue17884@psf.upfronthosting.co.za> Message-ID: <1367426274.64.0.440055325478.issue17884@psf.upfronthosting.co.za> Devin Jeanpierre added the comment: I don't know what context these types are being used in, but would int_least64_t suffice? C99 does require the existence of the [u]int_leastN_t types (for N in {8,16,32,64}), unlike [u]intN_t. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 19:09:47 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 01 May 2013 17:09:47 +0000 Subject: [issue17889] argparse subparsers break without arguments In-Reply-To: <1367419127.75.0.745110638267.issue17889@psf.upfronthosting.co.za> Message-ID: <1367428187.31.0.088900373408.issue17889@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> Undocumented (?) behaviour change in argparse from 3.2.3 to 3.3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 19:38:35 2013 From: report at bugs.python.org (Zachary Ware) Date: Wed, 01 May 2013 17:38:35 +0000 Subject: [issue16523] attrgetter and itemgetter signatures in docs need cleanup In-Reply-To: <1353510966.46.0.566270540705.issue16523@psf.upfronthosting.co.za> Message-ID: <1367429915.6.0.152431733694.issue16523@psf.upfronthosting.co.za> Zachary Ware added the comment: I left a couple of Rietveld comments. Other than those nitpicks it looks good to me, and I could be convinced otherwise on the nitpicks :) Also, thanks for catching the extra commas after the "After"s in operator.rst; I had meant to include those in the same patch that took them out of _operator.c, but apparently I missed it. ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 20:52:15 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 May 2013 18:52:15 +0000 Subject: [issue13721] ssl.wrap_socket on a connected but failed connection succeeds and .peer_certificate gives AttributeError In-Reply-To: <1325871512.71.0.286774610121.issue13721@psf.upfronthosting.co.za> Message-ID: <3b17y70P8Tz7Ll3@mail.python.org> Roundup Robot added the comment: New changeset e6b962fa44bb by Antoine Pitrou in branch 'default': Issue #13721: SSLSocket.getpeercert() and SSLSocket.do_handshake() now raise an OSError with ENOTCONN, instead of an AttributeError, when the SSLSocket is not connected. http://hg.python.org/cpython/rev/e6b962fa44bb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 20:57:52 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 May 2013 18:57:52 +0000 Subject: [issue13721] ssl.wrap_socket on a connected but failed connection succeeds and .peer_certificate gives AttributeError In-Reply-To: <1325871512.71.0.286774610121.issue13721@psf.upfronthosting.co.za> Message-ID: <1367434672.02.0.165241165849.issue13721@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, this is fixed now. Thanks for the comments! ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 21:22:00 2013 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 May 2013 19:22:00 +0000 Subject: [issue17884] Try to reuse stdint.h types like int32_t In-Reply-To: <1367426274.64.0.440055325478.issue17884@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: "Relying on things like int64_t or uint64_t is tricky, both in principle *and* in practice. (...) uint64_t and int64_t may be a stretch, particularly on ARM-style platforms." I don't understand. Python is already using 64-bit types, in md5 module for example (MD5_INT64). This module is not compiled on ARM? "In practice, we've had significant difficulties in the past simply finding and identifying exact-width types in our autoconf machinery: whether they're defined in or seems to vary from platform to platform, as does whether they're defined as typedef's or preprocessor macros." I don't understand. AC_TYPE_UINT64_T is supposed to provide the uint64_t (unsigned integer of 64-bit). Autotool can also generate the stdint.h header if it is not available. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 21:35:41 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 May 2013 19:35:41 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1367436941.53.0.831712730097.issue5845@psf.upfronthosting.co.za> Changes by Antoine Pitrou : Added file: http://bugs.python.org/file30098/c43e264256e4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 21:35:48 2013 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 May 2013 19:35:48 +0000 Subject: [issue17884] Try to reuse stdint.h types like int32_t In-Reply-To: <1367362366.81.0.489465512002.issue17884@psf.upfronthosting.co.za> Message-ID: <1367436948.49.0.516911816398.issue17884@psf.upfronthosting.co.za> STINNER Victor added the comment: > I *think* that since the issue #10052 fix, the current autoconf > machinery is now fairly good at finding those types across platforms, > but I wouldn't want to make any bets. The issue #10052 was not that the int32_t was not present, but an #ifdef issue: "This error occurs when HAVE_UINT32_T or HAVE_INT32_T are not defined". I don't understand why "#ifdef HAVE_UINT32_T" is tested, since configure ensures that uint32_t is always defined. (If it is not, it is defined in pyconfig.h using a #define.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 22:00:11 2013 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 01 May 2013 20:00:11 +0000 Subject: [issue17884] Try to reuse stdint.h types like int32_t In-Reply-To: <1367362366.81.0.489465512002.issue17884@psf.upfronthosting.co.za> Message-ID: <1367438411.26.0.116092316366.issue17884@psf.upfronthosting.co.za> Mark Dickinson added the comment: > I don't understand why "#ifdef HAVE_UINT32_T" is tested, since configure ensures that uint32_t is always defined. Take a look at the explanations in the autoconf file and in pyport.h. No, configure does *not* always ensure that uint32_t is defined: it does that only if the platform *doesn't* provide uint32_t, but does provide a 32-bit exact-width unsigned integer type (two's complement, no padding bits, etc. etc.). Which is why we need to make a second check for the case that the platform *does* define uint32_t directly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 22:02:56 2013 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 01 May 2013 20:02:56 +0000 Subject: [issue17884] Try to reuse stdint.h types like int32_t In-Reply-To: <1367362366.81.0.489465512002.issue17884@psf.upfronthosting.co.za> Message-ID: <1367438576.87.0.139810466775.issue17884@psf.upfronthosting.co.za> Mark Dickinson added the comment: > I don't understand. Python is already using 64-bit types, in md5 > module for example (MD5_INT64). This module is not compiled on ARM? No idea. Do you have good evidence that 64-bit integer types *will* be supported on all platforms that we care about Python compiling on? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 22:16:26 2013 From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=) Date: Wed, 01 May 2013 20:16:26 +0000 Subject: [issue16308] Undocumented (?) behaviour change in argparse from 3.2.3 to 3.3.0 In-Reply-To: <1351070553.1.0.217274613803.issue16308@psf.upfronthosting.co.za> Message-ID: <1367439386.6.0.403336972259.issue16308@psf.upfronthosting.co.za> Changes by Michele Orr? : ---------- nosy: +maker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 22:31:41 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 May 2013 20:31:41 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1367440301.58.0.763158135596.issue5845@psf.upfronthosting.co.za> Antoine Pitrou added the comment: In the spirit of pushing this forward, here is an updated patch using the sys.__interactivehook__ approach. I didn't add any tests since it doesn't seem very easy to write any. If nobody objects, I would like to commit this soon. ---------- Added file: http://bugs.python.org/file30099/defaultreadline.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 22:53:14 2013 From: report at bugs.python.org (Dmi Baranov) Date: Wed, 01 May 2013 20:53:14 +0000 Subject: [issue17319] http.server.BaseHTTPRequestHandler send_response_only doesn't check the type and value of the code. In-Reply-To: <1362024725.4.0.923647295599.issue17319@psf.upfronthosting.co.za> Message-ID: <1367441594.57.0.389729994147.issue17319@psf.upfronthosting.co.za> Dmi Baranov added the comment: Attached patch for checking status code based at RFC 2616 [1]. Covered by tests. [1] http://tools.ietf.org/html/rfc2616#section-6.1.1 ---------- keywords: +patch nosy: +dmi.baranov Added file: http://bugs.python.org/file30100/issue17319.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 23:09:04 2013 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 May 2013 21:09:04 +0000 Subject: [issue17884] Try to reuse stdint.h types like int32_t In-Reply-To: <1367362366.81.0.489465512002.issue17884@psf.upfronthosting.co.za> Message-ID: <1367442544.15.0.0315249902469.issue17884@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, I think I understood the issue :-) The problem is when the uint32_t type is present but is not exactly 32-bit width. When using uint32_t, *I* expect that an array of uint32_t items will takes 4 x n bytes. In which case is it interesting to use an uint32_t which may be bigger? If there is an use case (speed maybe?), we should define a Py_uint32_t which is always present and always exaclty 32 bits. If there is no use case (ex: int_fast32_t or int_least32_t can be used instead), it is maybe better to replace the available type using a #define to use the expect type. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 23:30:20 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 01 May 2013 21:30:20 +0000 Subject: [issue17833] test_gdb broken PPC64 Linux In-Reply-To: <1366828530.65.0.489906336326.issue17833@psf.upfronthosting.co.za> Message-ID: <1367443820.81.0.966583103581.issue17833@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- assignee: -> dmalcolm stage: -> commit review type: -> behavior versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 1 23:58:13 2013 From: report at bugs.python.org (Stefan Krah) Date: Wed, 01 May 2013 21:58:13 +0000 Subject: [issue17884] Try to reuse stdint.h types like int32_t In-Reply-To: <1367438576.87.0.139810466775.issue17884@psf.upfronthosting.co.za> Message-ID: <20130501215814.GA9859@sleipnir.bytereef.org> Stefan Krah added the comment: Mark Dickinson wrote: > No idea. Do you have good evidence that 64-bit integer types *will* be > supported on all platforms that we care about Python compiling on? I'm not sure how many people have tried to compile Python 3.3 on obscure platforms, but libmpdec currently requires manual intervention to switch on the "without uint64_t" mode: /* The following #error is just a warning. If the compiler indeed does * not have uint64_t, it is perfectly safe to comment out the #error. */ #error "Warning: Compiler without uint64_t. Comment out this line." I did this because I'm almost certain that a failure to detect uint64_t is more likely a ./configure issue than an actual absence of the type. So far there have been no reports. libmpdec also uses stdint.h directly, and there haven't been any reports either. Some commercial Unix buildbots have loads of problems, but support stdint.h, static inline functions in headers and even the tricky extern inline C99 functions (See: http://www.greenend.org.uk/rjk/tech/inline.html). If other developers support it, I'd actually like to write a PEP that allows unrestricted direct use of stdint.h and static inline functions in header files for Python 3.4. My gut feeling is that if a platform doesn't have these features, it will likely be the least of their problems. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 00:16:42 2013 From: report at bugs.python.org (Dmi Baranov) Date: Wed, 01 May 2013 22:16:42 +0000 Subject: [issue16396] Importing ctypes.wintypes on Linux gives a traceback In-Reply-To: <1351956172.0.0.64927799046.issue16396@psf.upfronthosting.co.za> Message-ID: <1367446602.54.0.218292192963.issue16396@psf.upfronthosting.co.za> Dmi Baranov added the comment: Found only this "patch" [1] :) I think is possible to change VARIANT_BOOL._type_ to any of short types [2] for non-"nt" platforms? [1] https://code.launchpad.net/~mandel/python-distutils-extra/import_issues/+merge/53519 [2] http://msdn.microsoft.com/en-us/library/cc237864.aspx ---------- nosy: +dmi.baranov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 00:26:24 2013 From: report at bugs.python.org (Stefan Krah) Date: Wed, 01 May 2013 22:26:24 +0000 Subject: [issue17884] Try to reuse stdint.h types like int32_t In-Reply-To: <1367409028.36.0.36581061572.issue17884@psf.upfronthosting.co.za> Message-ID: <20130501222625.GA11623@sleipnir.bytereef.org> Stefan Krah added the comment: Mark Dickinson wrote: > There's also some cleanup to be done with respect to semantics; I think it's still the case that the various PyLong_FromXXX functions have different behaviours with respect to overflow, __int__, __index__ and the like. If we just blindly map the old functions to the fixed-width versions we're going to end up changing those semantics on some platforms. That could be a problem. It's tempting though, since we'd finally have a uniform behavior for the PyLong_FromXXX functions (#12965). > I'd be quite happy to see fixed-width conversion functions that *completely ignore* __int__ and __index__, and leave the magic stuff to general PyNumber_... functions. Definitely. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 00:48:52 2013 From: report at bugs.python.org (Martin Morrison) Date: Wed, 01 May 2013 22:48:52 +0000 Subject: [issue17170] string method lookup is too slow In-Reply-To: <1360425571.01.0.152514473227.issue17170@psf.upfronthosting.co.za> Message-ID: <1367448532.67.0.875487634018.issue17170@psf.upfronthosting.co.za> Changes by Martin Morrison : ---------- nosy: +isoschiz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 01:59:18 2013 From: report at bugs.python.org (Dmi Baranov) Date: Wed, 01 May 2013 23:59:18 +0000 Subject: [issue17878] There is no way to get a list of available codecs In-Reply-To: <1367315517.44.0.647690228885.issue17878@psf.upfronthosting.co.za> Message-ID: <1367452758.85.0.607364492911.issue17878@psf.upfronthosting.co.za> Dmi Baranov added the comment: I think its not possible while codecs registry contains search callbacks (stateless-registry) ---------- components: +Library (Lib) nosy: +dmi.baranov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 02:30:50 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 02 May 2013 00:30:50 +0000 Subject: [issue16133] asyncore.dispatcher.recv doesn't handle EAGAIN / EWOULDBLOCK In-Reply-To: <1349366792.42.0.417654527681.issue16133@psf.upfronthosting.co.za> Message-ID: <1367454650.7.0.0218231669038.issue16133@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: recv() returning an empty string has always been an alias for "connection lost" though, that is why it cannot be used and I was proposing returning a new type in Python 3.4. Point is we're paying a bad design decision: asyncore shouldn't have asked the user to call recv() directly in the first place and call a data_received(chunk) callback method instead. Deciding what's best to do at this point without breaking existent code is not easy, that is why I think that on python <= 3.3 we should fix *asynchat* in order to take EAGAIN/EWOULDBLOCK into account and leave asyncore's recv() alone. The issue would still exist but it would be mitigated by the fact that who wants to write a protocol is likely to use asynchat, not asyncore. As for Python 3.4 we can: - make asyncore's recv() return None and document it - deprecate recv() - introduce data_received(chunk) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 02:35:53 2013 From: report at bugs.python.org (Nils Bruin) Date: Thu, 02 May 2013 00:35:53 +0000 Subject: [issue17816] Weak*Dictionary KeyErrors during callbacks In-Reply-To: <1366648864.21.0.829843721965.issue17816@psf.upfronthosting.co.za> Message-ID: <1367454953.8.0.3369937733.issue17816@psf.upfronthosting.co.za> Nils Bruin added the comment: One solution is to patch both WeakValueDictionary and WeakKeyDictionary with their own clear methods where we first store the strong links (to keys, resp. values) in a list, then clear the underlying dictionaries (this will now trigger the deletion of the weakrefs, so all callbacks are neutralized), and then delete the list. It does use more storage that way, but it gets rid of the ignored key errors. This is a different problem from issue7105, which deals with the (much more complicated) scenario of avoiding dictionary reshaping due to GC when iterators are still (potentially) active. ---------- keywords: +patch Added file: http://bugs.python.org/file30101/17816_custom_clear.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 02:43:02 2013 From: report at bugs.python.org (Garrett Holmstrom) Date: Thu, 02 May 2013 00:43:02 +0000 Subject: [issue17890] argparse: mutually exclusive groups full of suppressed args can cause AssertionErrors Message-ID: <1367455382.45.0.0611766927148.issue17890@psf.upfronthosting.co.za> New submission from Garrett Holmstrom: When it goes to format a usage message, argparse seems to (correctly) fail to satisfy one of its assertions when all of the following are true: 1. A mutually exclusive group contains only args that are suppressed 2. An unsuppressed arg follows that group 3. The usage is long enough to need to line-wrap The cause seems to be that the set of regular expressions that argparse uses to clean up mutually exclusive groups' separators doesn't handle the space that follows what would otherwise be an empty pair of square braces, sort of like this: 1. [-h] [ ] [--spam] ... 2. [-h] [] [--spam] ... 3. [-h] [--spam] ... A test case is attached. I was able to reproduce this with python-2.7.3-13.fc18.x86_64 on Fedora as well as with commit 83588:e6b962fa44bb in 3.4 mainline. I have a small patch for the latter that I'll submit shortly. Sorry if I missed anything. This is my first bug report against python proper. ---------- components: Library (Lib) files: argparse-assertfail.py messages: 188250 nosy: gholms priority: normal severity: normal status: open title: argparse: mutually exclusive groups full of suppressed args can cause AssertionErrors type: behavior versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file30102/argparse-assertfail.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 02:49:34 2013 From: report at bugs.python.org (Meador Inge) Date: Thu, 02 May 2013 00:49:34 +0000 Subject: [issue17449] dev guide appears not to cover the benchmarking suite In-Reply-To: <1363579697.14.0.518781563777.issue17449@psf.upfronthosting.co.za> Message-ID: <1367455774.27.0.805050033529.issue17449@psf.upfronthosting.co.za> Meador Inge added the comment: I think this will be useful information. I tend to doing benchmarks rather infrequently. Whenever I do them I forgot how I setup the suite the previous time around. In fact, I found this issue just now while googling for how to setup and run the official benchmark suite :-) ---------- nosy: +meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 02:49:37 2013 From: report at bugs.python.org (Garrett Holmstrom) Date: Thu, 02 May 2013 00:49:37 +0000 Subject: [issue17890] argparse: mutually exclusive groups full of suppressed args can cause AssertionErrors In-Reply-To: <1367455382.45.0.0611766927148.issue17890@psf.upfronthosting.co.za> Message-ID: <1367455777.95.0.27155930551.issue17890@psf.upfronthosting.co.za> Changes by Garrett Holmstrom : ---------- hgrepos: +187 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 07:05:34 2013 From: report at bugs.python.org (Berker Peksag) Date: Thu, 02 May 2013 05:05:34 +0000 Subject: [issue17319] http.server.BaseHTTPRequestHandler send_response_only doesn't check the type and value of the code. In-Reply-To: <1362024725.4.0.923647295599.issue17319@psf.upfronthosting.co.za> Message-ID: <1367471134.83.0.457495163884.issue17319@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 08:46:15 2013 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 02 May 2013 06:46:15 +0000 Subject: [issue17878] There is no way to get a list of available codecs In-Reply-To: <1367452758.85.0.607364492911.issue17878@psf.upfronthosting.co.za> Message-ID: <51820BB5.30104@egenix.com> Marc-Andre Lemburg added the comment: On 02.05.2013 01:59, Dmi Baranov wrote: > > Dmi Baranov added the comment: > > I think its not possible while codecs registry contains search callbacks (stateless-registry) It is possible: we'd just need to invent a way to ask search functions for the list of available codecs, e.g. by moving from plain function objects to CodecSearchFunction objects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 09:04:20 2013 From: report at bugs.python.org (paul j3) Date: Thu, 02 May 2013 07:04:20 +0000 Subject: [issue17890] argparse: mutually exclusive groups full of suppressed args can cause AssertionErrors In-Reply-To: <1367455382.45.0.0611766927148.issue17890@psf.upfronthosting.co.za> Message-ID: <1367478260.41.0.88231829418.issue17890@psf.upfronthosting.co.za> paul j3 added the comment: Looks like the text = text.strip() at the end of the set of regex (in _format_actions_usage) needs to be replaced with something that removes all excess spaces, e.g. text = _re.sub( '\s+', ' ', text ).strip() ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 09:37:39 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 May 2013 07:37:39 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1367480259.67.0.778721617059.issue5845@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 09:48:41 2013 From: report at bugs.python.org (Ben Hoyt) Date: Thu, 02 May 2013 07:48:41 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1299320278.86.0.403600489598.issue11406@psf.upfronthosting.co.za> Message-ID: <1367480921.28.0.468648644876.issue11406@psf.upfronthosting.co.za> Ben Hoyt added the comment: Ah, this is great. I definitely like the idea of a generator version of os.listdir(). And I like the name iterdir() -- it fits with iteritems() etc. They've gone in 3.x, of course, but listdir didn't change to an iterator, so... See also Betterwalk, my work-in-progress with very similar goals: https://github.com/benhoyt/betterwalk#readme It implements iterdir(), as well as iterdir_stat() which yields (name, stat) tuples. iterdir_stat() is especially important on Windows, where the directory iteration functions (FindFirstFile/FindNextFile) already give you full stat information. The intent of Betterwalk is to use these functions to speed up os.walk() by 2-3 times (and that's with the ctypes version, so it'll only get better in pure C). So I'm +1 for adding iterdir(), and I'd love to see iterdir_stat() so users can write fast os.walk() type functions without resorting to C. I'll look over the attached patches at some stage, especially the Windows code. ---------- nosy: +benhoyt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 10:08:09 2013 From: report at bugs.python.org (Alonso Vidales) Date: Thu, 02 May 2013 08:08:09 +0000 Subject: [issue17891] Wrong MD5 calculation on really long strings and the Hashlib Message-ID: <1367482089.28.0.00515501399845.issue17891@psf.upfronthosting.co.za> New submission from Alonso Vidales: Taking part on a contest I found a bug working with a string of 6227020800 characters, all the characters are the 'a' char. When I execute: hashlib.md5(string).hexdigest() On Python, is takes a pair of seconds (need more to calculate this md5, I think that it crashes without launch any exception), and returns the hash: 8adbd18519be193db41dd5341a260963 When I execute the same code using Pypy the hash is: 38fe0c01bfa0eb9d153b034f8408a8b7 In order to know witch one is the correct hash, I created a file with 6227020800 characters on my system and I executed the "md5" of OpenSSL, I think that we can trust on it, obtaining the same result as Pypy: unknown7cd1c3ecbb9b:Downloads socialpoint$ wc -c md5_test 6227020800 md5_test unknown7cd1c3ecbb9b:Downloads socialpoint$ md5 md5_test MD5 (md5_test) = 38fe0c01bfa0eb9d153b034f8408a8b7 Then Python are doing something wrong. Pls, find attached a screenshot that shows the result of the tests. If you can't reproduce it, or need more information, please let me know. My Python version: Python 2.7.1 (r271:86832, Aug 5 2011, 03:30:24) [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin Pypy version: Python 2.7.2 (341e1e3821ff, Jun 07 2012, 15:42:54) [PyPy 1.9.0 with GCC 4.2.1] on darwin ---------- components: Library (Lib) files: Screen Shot 2013-05-02 at 3.13.48 AM.png messages: 188255 nosy: Alonso.Vidales priority: normal severity: normal status: open title: Wrong MD5 calculation on really long strings and the Hashlib type: security versions: Python 2.7 Added file: http://bugs.python.org/file30103/Screen Shot 2013-05-02 at 3.13.48 AM.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 10:26:49 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 May 2013 08:26:49 +0000 Subject: [issue17891] Wrong MD5 calculation on really long strings and the Hashlib In-Reply-To: <1367482089.28.0.00515501399845.issue17891@psf.upfronthosting.co.za> Message-ID: <1367483209.33.0.550515921319.issue17891@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 10:28:34 2013 From: report at bugs.python.org (Ben Hoyt) Date: Thu, 02 May 2013 08:28:34 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1299320278.86.0.403600489598.issue11406@psf.upfronthosting.co.za> Message-ID: <1367483314.14.0.571258985959.issue11406@psf.upfronthosting.co.za> Ben Hoyt added the comment: Some folks have asked about benchmarks. I don't know about iterdir() vs listdir() -- I kind of suspect the speed gains there wouldn't be big. However, the reason I'm keen on iterdir_stat() is that I'm seeing it speed up os.walk() by a factor of 10 in my recent tests (note that I've made local mods, so these results aren't reproducible for others yet). This is doing a walk on a dir tree with 7800 files and 155 dirs: Using fast _betterwalk Priming the system's cache... Benchmarking walks on C:\Work\betterwalk\benchtree, repeat 1/3... Benchmarking walks on C:\Work\betterwalk\benchtree, repeat 2/3... Benchmarking walks on C:\Work\betterwalk\benchtree, repeat 3/3... os.walk took 0.178s, BetterWalk took 0.017s -- 10.5x as fast Sometimes Windows will go into this "I'm really caching stat results good" mode -- I don't know what heuristic determines this -- and then I'm seeing a 40x speed increase. And no, you didn't read that wrong. :-) Sorry, I'm getting carried away. This bug is really more about iterdir. But seeing Martin suggested the stat/d_type info... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 10:45:28 2013 From: report at bugs.python.org (Alexandre Vassalotti) Date: Thu, 02 May 2013 08:45:28 +0000 Subject: [issue17892] Fix the name of _PyObject_CallMethodObjIdArgs Message-ID: <1367484328.27.0.711184953583.issue17892@psf.upfronthosting.co.za> New submission from Alexandre Vassalotti: The changeset 2dd046be2c88 introduced _PyObject_CallMethodObjIdArgs. This API should have been named _PyObject_CallMethodIdObjArgs since it is the variant of _PyObject_CallMethodId which takes object arguments instead of building arguments from a format string. I would fix it myself. However, I am not sure how we should proceed with regard to backward incompatibility. ---------- assignee: brett.cannon components: Interpreter Core files: rename_PyObject_CallMethodIdObjArgs.patch keywords: patch messages: 188257 nosy: alexandre.vassalotti, brett.cannon priority: normal severity: normal stage: patch review status: open title: Fix the name of _PyObject_CallMethodObjIdArgs type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file30104/rename_PyObject_CallMethodIdObjArgs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 10:49:34 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 May 2013 08:49:34 +0000 Subject: [issue17892] Fix the name of _PyObject_CallMethodObjIdArgs In-Reply-To: <1367484328.27.0.711184953583.issue17892@psf.upfronthosting.co.za> Message-ID: <1367484574.1.0.809878766321.issue17892@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 10:59:59 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 02 May 2013 08:59:59 +0000 Subject: [issue17891] Wrong MD5 calculation on really long strings and the Hashlib In-Reply-To: <1367482089.28.0.00515501399845.issue17891@psf.upfronthosting.co.za> Message-ID: <1367485199.53.0.908288709012.issue17891@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: I'm getting the same hash as CPython with md5sum and openssl, on Linux: $ wc -c data 6227020800 data $ md5sum data 8adbd18519be193db41dd5341a260963 data $ openssl md5 data MD5(data)= 8adbd18519be193db41dd5341a260963 So it's correct, and your system's openssl version is borked. As for why Pypy returns the same result, I've no clue: maybe it's linked with your system libraries. ---------- nosy: +neologix resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 11:20:48 2013 From: report at bugs.python.org (Alonso Vidales) Date: Thu, 02 May 2013 09:20:48 +0000 Subject: [issue17891] Wrong MD5 calculation on really long strings and the Hashlib In-Reply-To: <1367482089.28.0.00515501399845.issue17891@psf.upfronthosting.co.za> Message-ID: <1367486448.7.0.874842232202.issue17891@psf.upfronthosting.co.za> Alonso Vidales added the comment: Seems a problem with the system libs (I use MacOS 10.7.5), I just create a file with 6227020800 'a' chars on a Linux env, and the result is: 8adbd18519be193db41dd5341a260963 I'll try to confirm this. root at tras2:/var/tmp# pypy create_input.py root at tras2:/var/tmp# wc -c md5_test 6227020800 md5_test root at tras2:/var/tmp# md5sum md5_test 8adbd18519be193db41dd5341a260963 md5_test root at tras2:/var/tmp# cat create_input.py f = open('md5_test', 'w') for count in xrange(0, 622702080): f.write('aaaaaaaaaa') f.close() root at tras2:/var/tmp# cat /proc/version Linux version 3.2.13-xxxx-std-ipv6-64 (root at kernel-64.ovh.net) (gcc version 4.3.2 (Debian 4.3.2-1.1) ) #1 SMP Wed Mar 28 11:20:17 UTC 2012 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 11:48:54 2013 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 May 2013 09:48:54 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1299320278.86.0.403600489598.issue11406@psf.upfronthosting.co.za> Message-ID: <1367488134.58.0.524374710482.issue11406@psf.upfronthosting.co.za> Nick Coghlan added the comment: I've had the local Red Hat release engineering team express their displeasure at having to stat every file in a network mounted directory tree for info that is present in the dirent structure, so a definite +1 to os.scandir from me, so long as it makes that info available. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 11:53:07 2013 From: report at bugs.python.org (Alexandre Vassalotti) Date: Thu, 02 May 2013 09:53:07 +0000 Subject: [issue17893] Refactor reduce protocol implementation Message-ID: <1367488387.09.0.179973942781.issue17893@psf.upfronthosting.co.za> New submission from Alexandre Vassalotti: I have tried to clean up a bit of the implementation of the reduce protocol in typeobject.c in preparation for PEP 3154's support of classes with __new__ using keyword-only arguments. I am not quite done yet with the refactorings, but I would appreciate some early feedback about whether the changes looks right or other refactoring ideas you might have. ---------- assignee: alexandre.vassalotti components: Interpreter Core files: refactor_reduce.patch keywords: patch messages: 188261 nosy: alexandre.vassalotti, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Refactor reduce protocol implementation type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file30105/refactor_reduce.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 11:53:56 2013 From: report at bugs.python.org (Alexandre Vassalotti) Date: Thu, 02 May 2013 09:53:56 +0000 Subject: [issue17810] Implement PEP 3154 (pickle protocol 4) In-Reply-To: <1366526938.19.0.00976593994103.issue17810@psf.upfronthosting.co.za> Message-ID: <1367488436.83.0.540093660305.issue17810@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti : ---------- dependencies: +Refactor reduce protocol implementation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 12:06:40 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 May 2013 10:06:40 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1299320278.86.0.403600489598.issue11406@psf.upfronthosting.co.za> Message-ID: <1367489200.56.0.884175362477.issue11406@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 12:22:43 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 02 May 2013 10:22:43 +0000 Subject: [issue17851] Grammar errors in threading.Lock documentation In-Reply-To: <1367038556.41.0.738438135734.issue17851@psf.upfronthosting.co.za> Message-ID: <1367490163.6.0.743486655621.issue17851@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 14:38:08 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Thu, 02 May 2013 12:38:08 +0000 Subject: [issue17871] Wrong signature of TextTestRunner's init function In-Reply-To: <1367269592.44.0.115946830805.issue17871@psf.upfronthosting.co.za> Message-ID: <1367498288.0.0.721188987085.issue17871@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: The changes in Docs/library/unittest.rst have been made to reflect proper arguments from Lib/unittest/runner.py ---------- keywords: +patch nosy: +Yogesh.Chaudhari Added file: http://bugs.python.org/file30106/mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 14:50:36 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 May 2013 12:50:36 +0000 Subject: [issue1722] Undocumented urllib functions In-Reply-To: <1199298780.6.0.893928826633.issue1722@psf.upfronthosting.co.za> Message-ID: <3b1btN0G7cz7LjY@mail.python.org> Roundup Robot added the comment: New changeset c3656dca65e7 by Senthil Kumaran in branch '2.7': # 1722 - Add a note on urllib helper functions like splittype, splithost etc. http://hg.python.org/cpython/rev/c3656dca65e7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 14:53:37 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 02 May 2013 12:53:37 +0000 Subject: [issue1722] Undocumented urllib functions In-Reply-To: <1199298780.6.0.893928826633.issue1722@psf.upfronthosting.co.za> Message-ID: <1367499217.0.0.26681155849.issue1722@psf.upfronthosting.co.za> Senthil Kumaran added the comment: I had added a note in the documentation c3656dca65e7 conveying that splittype, splithost should not be relied upon, and urlparse should be used for parsing. Also, Python3 does not include these in __all__ - It is in Python2 for backwards compatibility purposes. It is not possible provide deprecation warning to things we leave off from __all__ from subsequent versions of python. I consider this request as resolved. Thanks! ---------- resolution: -> fixed status: open -> closed versions: -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 15:26:29 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 02 May 2013 13:26:29 +0000 Subject: [issue17805] No such class: multiprocessing.pool.AsyncResult In-Reply-To: <1366494249.42.0.0654021028594.issue17805@psf.upfronthosting.co.za> Message-ID: <1367501189.72.0.878593465822.issue17805@psf.upfronthosting.co.za> Richard Oudkerk added the comment: It might be simplest to make the implementation match the docs by making AsyncResult an alias for ApplyResult. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 15:28:09 2013 From: report at bugs.python.org (Brett Cannon) Date: Thu, 02 May 2013 13:28:09 +0000 Subject: [issue17892] Fix the name of _PyObject_CallMethodObjIdArgs In-Reply-To: <1367484328.27.0.711184953583.issue17892@psf.upfronthosting.co.za> Message-ID: <1367501289.33.0.0294950293521.issue17892@psf.upfronthosting.co.za> Brett Cannon added the comment: It has a leading underscore for a reason; there is no backwards-compatibility guarantee as it's private to CPython internals. Refactor to your heart's content. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 15:28:16 2013 From: report at bugs.python.org (Brett Cannon) Date: Thu, 02 May 2013 13:28:16 +0000 Subject: [issue17892] Fix the name of _PyObject_CallMethodObjIdArgs In-Reply-To: <1367484328.27.0.711184953583.issue17892@psf.upfronthosting.co.za> Message-ID: <1367501296.81.0.601917196305.issue17892@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: brett.cannon -> alexandre.vassalotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 15:45:45 2013 From: report at bugs.python.org (Dmi Baranov) Date: Thu, 02 May 2013 13:45:45 +0000 Subject: [issue17878] There is no way to get a list of available codecs In-Reply-To: <1367315517.44.0.647690228885.issue17878@psf.upfronthosting.co.za> Message-ID: <1367502345.42.0.12700051321.issue17878@psf.upfronthosting.co.za> Dmi Baranov added the comment: I think the "function" is a bit misleading. I suggest something like CodecsSearcher, please look at attached implementation (dirty code, just for start discussion about interfaces, lazy caches, etc). ---------- Added file: http://bugs.python.org/file30107/codecs_searchers.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 15:53:44 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Thu, 02 May 2013 13:53:44 +0000 Subject: [issue17890] argparse: mutually exclusive groups full of suppressed args can cause AssertionErrors In-Reply-To: <1367455382.45.0.0611766927148.issue17890@psf.upfronthosting.co.za> Message-ID: <1367502824.89.0.273703714812.issue17890@psf.upfronthosting.co.za> Changes by Yogesh Chaudhari : ---------- keywords: +patch Added file: http://bugs.python.org/file30108/7691d1d4b955.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 16:41:44 2013 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 May 2013 14:41:44 +0000 Subject: [issue17878] There is no way to get a list of available codecs In-Reply-To: <1367315517.44.0.647690228885.issue17878@psf.upfronthosting.co.za> Message-ID: <1367505704.87.0.654128646437.issue17878@psf.upfronthosting.co.za> Nick Coghlan added the comment: This is actually similar to the problem with getting the list of modules an importer provides (that is, we don't currently have an officially defined method in the importer protocol for that, although pkgutil.iter_importer_modules implicitly looks for an "iter_modules" method, due to the old import emulation used until Python 3.2). I see three possibilities: 1. Use independent purpose specific protocols to get a list of entries out of these objects. 2. Create a new, common protocol for extracting lists of entries from search hooks like importers and codec search functions 3. Use the existing __iter__ protocol I'm currently thinking option 3 might be a reasonable way forward. That is, if a codec search hook wants to provide a listing of available codecs, it can just define __iter__ in addition to __call__. Importers could define __iter__ in addition to the other methods in the importer API. Thoughts? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 16:45:58 2013 From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=) Date: Thu, 02 May 2013 14:45:58 +0000 Subject: [issue17878] There is no way to get a list of available codecs In-Reply-To: <1367315517.44.0.647690228885.issue17878@psf.upfronthosting.co.za> Message-ID: <1367505958.56.0.481860488119.issue17878@psf.upfronthosting.co.za> Walter D?rwald added the comment: The point of using a function is to allow the function special hanling of the encoding name, which goes beyond a simple map lookup, i.e. you could do the following: import codecs def search_function(encoding): if not encoding.startswith("append-"): return None suffix = encoding[7:] def encode(s, errors="strict"): s = (s + suffix).encode("utf-8", errors) return (s, len(s)) def decode(s, errors="strict"): s = bytes(s).decode("utf-8", errors) if s.endswith(suffix): s = s[:-len(suffix)] return (s, len(s)) return codecs.CodecInfo(encode, decode, name=encoding) codecs.register(search_function) $ python Python 3.3.1 (default, Apr 29 2013, 15:35:47) [GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.24)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import appendcodec >>> 'foo'.encode('append-bar') b'foobar' >>> b'foobar'.decode('append-bar') 'foo' The search function can't return a list of codec names in this case, as the list is infinite. ---------- nosy: +doerwalter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 16:47:27 2013 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 02 May 2013 14:47:27 +0000 Subject: [issue17878] There is no way to get a list of available codecs In-Reply-To: <1367505704.87.0.654128646437.issue17878@psf.upfronthosting.co.za> Message-ID: <51827C7D.2080102@egenix.com> Marc-Andre Lemburg added the comment: On 02.05.2013 16:41, Nick Coghlan wrote: > > Nick Coghlan added the comment: > > This is actually similar to the problem with getting the list of modules an importer provides (that is, we don't currently have an officially defined method in the importer protocol for that, although pkgutil.iter_importer_modules implicitly looks for an "iter_modules" method, due to the old import emulation used until Python 3.2). > > I see three possibilities: > > 1. Use independent purpose specific protocols to get a list of entries out of these objects. > > 2. Create a new, common protocol for extracting lists of entries from search hooks like importers and codec search functions > > 3. Use the existing __iter__ protocol > > I'm currently thinking option 3 might be a reasonable way forward. That is, if a codec search hook wants to provide a listing of available codecs, it can just define __iter__ in addition to __call__. Importers could define __iter__ in addition to the other methods in the importer API. > > Thoughts? Too obscure :-) Let the object expose a method: .list_codecs() -> returns a list of supported codecs as CodecInfo objects. We may also deprecate the .__call__() in favor of: .find_codec(encoding) -> return codec implementing encoding. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 16:51:01 2013 From: report at bugs.python.org (Paul Moore) Date: Thu, 02 May 2013 14:51:01 +0000 Subject: [issue17878] There is no way to get a list of available codecs In-Reply-To: <1367315517.44.0.647690228885.issue17878@psf.upfronthosting.co.za> Message-ID: <1367506261.41.0.0784135214432.issue17878@psf.upfronthosting.co.za> Paul Moore added the comment: @doerwalter In that case, I'd take the view that such a codec should simply not return anything. The discovery mechanism can be limited to returning only statically discoverable codec names (and it can be documented as such). The original use case was to support functionality like iconv -l. Omitting edge cases like this is probably reasonable in that context. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 16:53:14 2013 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 02 May 2013 14:53:14 +0000 Subject: [issue17878] There is no way to get a list of available codecs In-Reply-To: <1367505958.56.0.481860488119.issue17878@psf.upfronthosting.co.za> Message-ID: <51827DD8.8050008@egenix.com> Marc-Andre Lemburg added the comment: On 02.05.2013 16:45, Walter D?rwald wrote: > ... > The search function can't return a list of codec names in this case, as the list is infinite. True. The search object will have to be allowed to raise a NotImplementedError or some other error/return value to signal that the list of supported codecs is not available. Note that the search object should only return a list of supported canonical encoding names with .list_codecs(), not all possible ones :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 17:24:24 2013 From: report at bugs.python.org (Zachary Ware) Date: Thu, 02 May 2013 15:24:24 +0000 Subject: [issue17846] Building Python on Windows - Supplementary info In-Reply-To: <1366919664.94.0.0931557904055.issue17846@psf.upfronthosting.co.za> Message-ID: <1367508264.81.0.290744453725.issue17846@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 17:35:50 2013 From: report at bugs.python.org (Dmi Baranov) Date: Thu, 02 May 2013 15:35:50 +0000 Subject: [issue17878] There is no way to get a list of available codecs In-Reply-To: <1367315517.44.0.647690228885.issue17878@psf.upfronthosting.co.za> Message-ID: <1367508950.46.0.570113355298.issue17878@psf.upfronthosting.co.za> Dmi Baranov added the comment: My +1 for __iter__ with default `raise StopIteration`, it is more elegant solution than declaration and guarantee of the interfaces (based at collections.abc.Callable and collections.abc.Iterator). Paul, result as iterable of CodecInfo objects is gives much more flexibility than the names of codecs (whats if you will have a few codecs with the same name in different SearchObjects?) As I see, you would like use this as: encoded_data = 'abc' for codecs in codecs.registered_codecs(): decoded_data = codecs.decode(data) if decoded_data == 'cba': # cracked break Whats about backward compatibly with Lib/encoding modules (initial item in interp->codec_search_path)? Can we skip anything in search_path, if its not supports iteration? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 17:40:54 2013 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 02 May 2013 15:40:54 +0000 Subject: [issue17878] There is no way to get a list of available codecs In-Reply-To: <51827DD8.8050008@egenix.com> Message-ID: <51828903.8050309@egenix.com> Marc-Andre Lemburg added the comment: On 02.05.2013 16:53, Marc-Andre Lemburg wrote: > > Marc-Andre Lemburg added the comment: > > On 02.05.2013 16:45, Walter D?rwald wrote: >> ... >> The search function can't return a list of codec names in this case, as the list is infinite. > > True. > > The search object will have to be allowed to raise a > NotImplementedError or some other error/return value > to signal that the list of supported codecs is not available. > > Note that the search object should only return a list of > supported canonical encoding names with .list_codecs(), > not all possible ones :-) Scratch that last sentence. Returning CodecInfo instances, as I originally wrote, is a better way to go. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 17:43:58 2013 From: report at bugs.python.org (Paul Moore) Date: Thu, 02 May 2013 15:43:58 +0000 Subject: [issue17878] There is no way to get a list of available codecs In-Reply-To: <1367508950.46.0.570113355298.issue17878@psf.upfronthosting.co.za> Message-ID: Paul Moore added the comment: On 2 May 2013 16:35, Dmi Baranov wrote: > Paul, result as iterable of CodecInfo objects is gives much more > flexibility than the names of codecs (whats if you will have a few codecs > with the same name in different SearchObjects?) Works for me. My usage would be def list_supported_codecs(): for codec in codecs.registered_codecs(): print(codec.name) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 17:48:12 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 02 May 2013 15:48:12 +0000 Subject: [issue13831] get method of multiprocessing.pool.Async should return full traceback In-Reply-To: <1327006000.05.0.152231015377.issue13831@psf.upfronthosting.co.za> Message-ID: <1367509692.05.0.258880926186.issue13831@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Attached is a patch for 3.4 which uses the __cause__ hack to embed the remote traceback in the local traceback. It will not work for 2.x though. >>> import multiprocessing, subprocess >>> with multiprocessing.Pool() as p: p.apply(subprocess.Popen, (1,)) ... multiprocessing.pool.RemoteTraceback: """ Traceback (most recent call last): File "/home/oudkerk/Repos/py-default/Lib/multiprocessing/pool.py", line 114, in worker result = (True, func(*args, **kwds)) File "/home/oudkerk/Repos/py-default/Lib/subprocess.py", line 838, in __init__ restore_signals, start_new_session) File "/home/oudkerk/Repos/py-default/Lib/subprocess.py", line 1317, in _execute_child args = list(args) TypeError: 'int' object is not iterable """ The above exception was the direct cause of the following exception: Traceback (most recent call last): File "", line 1, in File "/home/oudkerk/Repos/py-default/Lib/multiprocessing/pool.py", line 245, in apply return self.apply_async(func, args, kwds).get() File "/home/oudkerk/Repos/py-default/Lib/multiprocessing/pool.py", line 588, in get raise self._value TypeError: 'int' object is not iterable ---------- keywords: +patch Added file: http://bugs.python.org/file30109/pool-traceback.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 18:00:48 2013 From: report at bugs.python.org (Dmi Baranov) Date: Thu, 02 May 2013 16:00:48 +0000 Subject: [issue17878] There is no way to get a list of available codecs In-Reply-To: <1367315517.44.0.647690228885.issue17878@psf.upfronthosting.co.za> Message-ID: <1367510448.15.0.241438688627.issue17878@psf.upfronthosting.co.za> Dmi Baranov added the comment: Sorry for additional nose - currently there is no way to change the codecs_search_path. Similarly with sys.patch_hooks is a great way to increase the level of customization (maybe I have a faster codec?). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 18:22:44 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Thu, 02 May 2013 16:22:44 +0000 Subject: [issue17890] argparse: mutually exclusive groups full of suppressed args can cause AssertionErrors In-Reply-To: <1367455382.45.0.0611766927148.issue17890@psf.upfronthosting.co.za> Message-ID: <1367511764.18.0.512314451685.issue17890@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: Made similar required changes for version 2.7 ---------- nosy: +Yogesh.Chaudhari Added file: http://bugs.python.org/file30110/Issue17890-27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 18:26:17 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Thu, 02 May 2013 16:26:17 +0000 Subject: [issue17890] argparse: mutually exclusive groups full of suppressed args can cause AssertionErrors In-Reply-To: <1367455382.45.0.0611766927148.issue17890@psf.upfronthosting.co.za> Message-ID: <1367511977.32.0.0838618050509.issue17890@psf.upfronthosting.co.za> Changes by Yogesh Chaudhari : Removed file: http://bugs.python.org/file30108/7691d1d4b955.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 19:44:25 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 May 2013 17:44:25 +0000 Subject: [issue17892] Fix the name of _PyObject_CallMethodObjIdArgs In-Reply-To: <1367484328.27.0.711184953583.issue17892@psf.upfronthosting.co.za> Message-ID: <3b1kPN3yqnz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 8a364deb0225 by Alexandre Vassalotti in branch 'default': Closes #17892: Fix the name of _PyObject_CallMethodObjIdArgs http://hg.python.org/cpython/rev/8a364deb0225 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 23:00:01 2013 From: report at bugs.python.org (Alexandre Vassalotti) Date: Thu, 02 May 2013 21:00:01 +0000 Subject: [issue17810] Implement PEP 3154 (pickle protocol 4) In-Reply-To: <1366526938.19.0.00976593994103.issue17810@psf.upfronthosting.co.za> Message-ID: <1367528401.47.0.364612925247.issue17810@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: The latest framing patch looks pretty nice overall. One concern is we need to make sure the C implementation call _Pickler_OpcodeBoundary often enough to keep the frames around the sizes. For example, batch_save_list and batch_save_dict can currently create a frame much larger than expected. Interestingly enough, I found pickle, with patch applied, crashes when handling such frames: 13:44:43 pep-3154 $ ./python -c "import pickle, io; pickle.dump(list(range(10**5)), io.BytesIO(), 4)" Debug memory block at address p=0x1e96b10: API 'o' 52 bytes originally requested The 7 pad bytes at p-7 are FORBIDDENBYTE, as expected. The 8 pad bytes at tail=0x1e96b44 are not all FORBIDDENBYTE (0xfb): at tail+0: 0x00 *** OUCH at tail+1: 0x00 *** OUCH at tail+2: 0x00 *** OUCH at tail+3: 0x00 *** OUCH at tail+4: 0x4d *** OUCH at tail+5: 0x75 *** OUCH at tail+6: 0x5b *** OUCH at tail+7: 0xfb The block was made by call #237465 to debug malloc/realloc. Data at p: 00 00 00 00 00 00 00 00 ... ff ff ff ff 00 00 00 00 Fatal Python error: bad trailing pad byte Current thread 0x00007f5dea491700: File "", line 1 in Aborted (core dumped) Also, I think we should try to make pickletools.dis display the frame boundaries to help with debugging. This could be implemented by adding an option to pickletools.genops which could be helpful for testing the framing implementation as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 23:16:18 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 May 2013 21:16:18 +0000 Subject: [issue17810] Implement PEP 3154 (pickle protocol 4) In-Reply-To: <1367528401.47.0.364612925247.issue17810@psf.upfronthosting.co.za> Message-ID: <1367529375.2551.14.camel@fsol> Antoine Pitrou added the comment: > One concern is we need to make sure the C implementation call > _Pickler_OpcodeBoundary often enough to keep the frames around the > sizes. For example, batch_save_list and batch_save_dict can currently > create a frame much larger than expected. I don't understand how that can happen. batch_list() and batch_dict() both call save() for each item, and save() calls _Pickler_OpcodeBoundary() at the end. Have I missed something? > Interestingly enough, I found pickle, with patch applied, crashes when > handling such frames: Interesting, I'll take a look when I have some time. > Also, I think we should try to make pickletools.dis display the frame > boundaries to help with debugging. This could be implemented by adding > an option to pickletools.genops which could be helpful for testing the > framing implementation as well. Agreed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 23:20:30 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 May 2013 21:20:30 +0000 Subject: [issue15984] Wrong documentation for PyUnicode_FromObject() and PyUnicode_FromEncodedObject() In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za> Message-ID: <1367529630.1.0.760221006357.issue15984@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 2 23:34:36 2013 From: report at bugs.python.org (Alexandre Vassalotti) Date: Thu, 02 May 2013 21:34:36 +0000 Subject: [issue17810] Implement PEP 3154 (pickle protocol 4) In-Reply-To: <1366526938.19.0.00976593994103.issue17810@psf.upfronthosting.co.za> Message-ID: <1367530476.23.0.929791280234.issue17810@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: > I don't understand how that can happen. batch_list() and batch_dict() > both call save() for each item, and save() calls > _Pickler_OpcodeBoundary() at the end. Have I missed something? Ah, you're right. I was thinking in terms of my fast dispatch patch in issue #17787. Sorry for the confusion! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 00:10:14 2013 From: report at bugs.python.org (Alexandre Vassalotti) Date: Thu, 02 May 2013 22:10:14 +0000 Subject: [issue4727] pickle/copyreg doesn't support keyword only arguments in __new__ In-Reply-To: <1229999703.52.0.11232958698.issue4727@psf.upfronthosting.co.za> Message-ID: <1367532614.29.0.295056359769.issue4727@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti : ---------- dependencies: +Implement PEP 3154 (pickle protocol 4) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 00:20:52 2013 From: report at bugs.python.org (Matthias Klose) Date: Thu, 02 May 2013 22:20:52 +0000 Subject: [issue17819] removes need for CONFIG_SITE external configuration In-Reply-To: <1366676555.13.0.0940928027778.issue17819@psf.upfronthosting.co.za> Message-ID: <1367533252.28.0.841280727336.issue17819@psf.upfronthosting.co.za> Matthias Klose added the comment: An external config.site is not the only option, you can pass these values in the environment or on the configure command line too. These would not be the only two options, there are more where features of the running kernel are tested, or where a test uses AC_TRY_RUN. Adding a configure option for each of these doesn't sound like the right thing to do, there I feel a config.site file is more appropriate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 00:43:31 2013 From: report at bugs.python.org (Alexandre Vassalotti) Date: Thu, 02 May 2013 22:43:31 +0000 Subject: [issue11872] cPickle gives strange error for large objects. In-Reply-To: <1303200362.9.0.587954333494.issue11872@psf.upfronthosting.co.za> Message-ID: <1367534611.91.0.716935961774.issue11872@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: It is an integer overflow issue. It is easy to reproduce without numpy: $ python2.7 -c "import cPickle; cPickle.dumps('\x00' * 2**31)" Traceback (most recent call last): File "", line 1, in SystemError: error return without exception set We fixed this in Python 3. It may be worthwhile to fix cPickle as well. ---------- nosy: +alexandre.vassalotti stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 00:46:38 2013 From: report at bugs.python.org (Martin Morrison) Date: Thu, 02 May 2013 22:46:38 +0000 Subject: [issue7475] codecs missing: base64 bz2 hex zlib hex_codec ... In-Reply-To: <1260484060.32.0.471733830707.issue7475@psf.upfronthosting.co.za> Message-ID: <1367534798.96.0.98806528165.issue7475@psf.upfronthosting.co.za> Changes by Martin Morrison : ---------- nosy: +isoschiz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 02:28:45 2013 From: report at bugs.python.org (Alexandre Vassalotti) Date: Fri, 03 May 2013 00:28:45 +0000 Subject: [issue9276] pickle should support methods In-Reply-To: <1279308320.41.0.159043379114.issue9276@psf.upfronthosting.co.za> Message-ID: <1367540925.49.0.508792370981.issue9276@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti : ---------- dependencies: +Implement PEP 3154 (pickle protocol 4) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 02:51:43 2013 From: report at bugs.python.org (Alexandre Vassalotti) Date: Fri, 03 May 2013 00:51:43 +0000 Subject: [issue17565] segfaults during serialization In-Reply-To: <1364427295.89.0.0369789736711.issue17565@psf.upfronthosting.co.za> Message-ID: <1367542303.58.0.968475767121.issue17565@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: If you are pickling large objects, you're likely hitting issue #11872. We fixed most 64-bit issues in Python 3, so upgrading might be solution if possible. Since the particular bug you are hitting cannot be reproduced with your test case, I am closing this issue. Feel free to reopen if you come up with a reproducible test case. ---------- nosy: +alexandre.vassalotti resolution: -> works for me stage: -> committed/rejected status: open -> closed type: -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 02:59:44 2013 From: report at bugs.python.org (Alexandre Vassalotti) Date: Fri, 03 May 2013 00:59:44 +0000 Subject: [issue14290] Importing script as module causes ImportError with pickle.load In-Reply-To: <1331667642.01.0.680129740358.issue14290@psf.upfronthosting.co.za> Message-ID: <1367542784.15.0.785271523918.issue14290@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Without a test case, we cannot tell if this is a bug in pickle or not. Anyhow, Floris's explanation is pretty much on the dot as why you might see this error. ---------- nosy: +alexandre.vassalotti resolution: -> works for me stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 03:17:15 2013 From: report at bugs.python.org (Alexandre Vassalotti) Date: Fri, 03 May 2013 01:17:15 +0000 Subject: [issue12596] cPickle - stored data differ for same dictionary In-Reply-To: <1311178852.37.0.806818029519.issue12596@psf.upfronthosting.co.za> Message-ID: <1367543835.33.0.0235003118809.issue12596@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: There is no guarantee the binary representation of pickled data will be same between different runs. We try to make it mostly consistent when we can, but there are cases, like this one, where we cannot ensure consistency without hurting performance significantly. ---------- nosy: +alexandre.vassalotti resolution: -> works for me stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 03:33:11 2013 From: report at bugs.python.org (Alexandre Vassalotti) Date: Fri, 03 May 2013 01:33:11 +0000 Subject: [issue892902] problem with pickling newstyle class instances Message-ID: <1367544791.84.0.781926255549.issue892902@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: I fixed this while working on PEP 3154 [http://hg.python.org/features/pep-3154-alexandre/rev/eed9142d664f]. The relevant piece is @@ -420,7 +424,13 @@ class _Pickler: write(REDUCE) if obj is not None: - self.memoize(obj) + # If the object is already in the memo, this means it is + # recursive. In this case, throw away everything we put on the + # stack, and fetch the object back from the memo. + if id(obj) in self.memo: + write(POP + self.get(self.memo[id(obj)][0])) + else: + self.memoize(obj) # More new special cases (that work with older protocols as # well): when __reduce__ returns a tuple with 4 or 5 items, It would be pretty easy to backport this to 2.7 and 3.3. It is also good to mention that that only protocol 0 and 1 are affected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 04:04:55 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 03 May 2013 02:04:55 +0000 Subject: [issue17546] Document the circumstances where the locals() dict get updated In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za> Message-ID: <1367546695.03.0.998850870091.issue17546@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ncoghlan stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 04:11:52 2013 From: report at bugs.python.org (Ned Batchelder) Date: Fri, 03 May 2013 02:11:52 +0000 Subject: [issue17894] Edits to descriptor howto Message-ID: <1367547112.04.0.920947702161.issue17894@psf.upfronthosting.co.za> New submission from Ned Batchelder: I find the explanations in the Descriptor howto to be difficult to understand. I took a stab at changing the first few sections to introduce the concepts in an easier-to-grasp style. Issue 12077 also covers a little bit of this. ---------- assignee: docs at python components: Documentation files: descriptor_howto.patch keywords: patch messages: 188289 nosy: docs at python, nedbat priority: normal severity: normal status: open title: Edits to descriptor howto versions: Python 3.4 Added file: http://bugs.python.org/file30111/descriptor_howto.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 06:38:55 2013 From: report at bugs.python.org (Adam Brenecki) Date: Fri, 03 May 2013 04:38:55 +0000 Subject: [issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper In-Reply-To: <1366979224.14.0.876475494511.issue17849@psf.upfronthosting.co.za> Message-ID: <1367555935.92.0.296079696669.issue17849@psf.upfronthosting.co.za> Changes by Adam Brenecki : ---------- nosy: +adambrenecki _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 06:50:06 2013 From: report at bugs.python.org (Roger Serwy) Date: Fri, 03 May 2013 04:50:06 +0000 Subject: [issue17838] Can't assign a different value for sys.stdin in IDLE In-Reply-To: <1366872984.94.0.234893757031.issue17838@psf.upfronthosting.co.za> Message-ID: <1367556606.2.0.644222252086.issue17838@psf.upfronthosting.co.za> Roger Serwy added the comment: Keeping the sys.stdin reference alive and then reassigning sys.stdin prevents exit() and quit() from actually closing IDLE since site.py's code closes sys.stdin which then does not trigger PyShell's close() method. I updated Terry's patch to explicitly call the close method when SystemExit gets raised. IDLE's subprocess clears atexit handlers before shutdown so they never get called. See exit() from Lib/idlelib/run.py. The debugger can not handle stepping through a "raise SystemExit" from the shell, even long before any sys.std* patches got applied. That's a separate issue that should be opened. I mention that so that if anyone manually tests with the debugger that this behavior is "expected". ---------- Added file: http://bugs.python.org/file30112/Terry17838_rev1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 07:23:25 2013 From: report at bugs.python.org (paul j3) Date: Fri, 03 May 2013 05:23:25 +0000 Subject: [issue17890] argparse: mutually exclusive groups full of suppressed args can cause AssertionErrors In-Reply-To: <1367455382.45.0.0611766927148.issue17890@psf.upfronthosting.co.za> Message-ID: <1367558605.66.0.672960155093.issue17890@psf.upfronthosting.co.za> paul j3 added the comment: In the test case: class TestMutuallyExclusiveManySuppressed even with a short 'eggs' argument, there is a difference Old usage would be: usage: PROG [-h] [--eggs EGGS] new usage: PROG [-h] [--eggs EGGS] i.e. 2 v 1 space. But extra spaces are not as dramatic a failure as an assertion error. It would also be good to check what happens when there are 2 suppressed groups. If the text before all trimming is: [ -h ] [] () [ --eggs EGGS ] does it reduce to? [-h] [--eggs EGGS] The old code would have left 3 spaces. I can't think of a situation in which a user would want a (generated) usage line with multiple spaces. If some sort of special formatting is needed, there is always the option of specifying an explicit usage line. parser = ArugmentParser(usage='one \ttwo \nthree four') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 07:37:00 2013 From: report at bugs.python.org (Georg Brandl) Date: Fri, 03 May 2013 05:37:00 +0000 Subject: [issue17838] Can't assign a different value for sys.stdin in IDLE In-Reply-To: <1366872984.94.0.234893757031.issue17838@psf.upfronthosting.co.za> Message-ID: <1367559420.47.0.755960062327.issue17838@psf.upfronthosting.co.za> Georg Brandl added the comment: Is this applicable to 3.2? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 09:03:27 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 03 May 2013 07:03:27 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1367483314.14.0.571258985959.issue11406@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > However, the reason I'm keen on iterdir_stat() is that I'm seeing it speed up os.walk() by a factor of 10 in my recent tests (note that I've made local mods, so these results aren't reproducible for others yet). This is doing a walk on a dir tree with 7800 files and 155 dirs: > > Using fast _betterwalk > Priming the system's cache... > Benchmarking walks on C:\Work\betterwalk\benchtree, repeat 1/3... > Benchmarking walks on C:\Work\betterwalk\benchtree, repeat 2/3... > Benchmarking walks on C:\Work\betterwalk\benchtree, repeat 3/3... > os.walk took 0.178s, BetterWalk took 0.017s -- 10.5x as fast > > Sometimes Windows will go into this "I'm really caching stat results good" mode -- I don't know what heuristic determines this -- and then I'm seeing a 40x speed increase. And no, you didn't read that wrong. :-) I/O benchmarks shouldn't use timeit or repeated calls: after the first run, most of your data is in cache, so subsequent runs are meaningless. I don't know about Windows, but on Linux you should do something like: # echo 3 > /proc/sys/vm/drop_caches to start out clean. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 09:59:33 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 May 2013 07:59:33 +0000 Subject: [issue15535] Fix pickling efficiency of named tuples in 2.7.3 In-Reply-To: <1343915086.31.0.252328658724.issue15535@psf.upfronthosting.co.za> Message-ID: <3b25N439gHz7LjQ@mail.python.org> Roundup Robot added the comment: New changeset 18303391b981 by Raymond Hettinger in branch '2.7': Issue #15535: Fix regression in pickling of named tuples. http://hg.python.org/cpython/rev/18303391b981 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 10:45:25 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Fri, 03 May 2013 08:45:25 +0000 Subject: [issue17890] argparse: mutually exclusive groups full of suppressed args can cause AssertionErrors In-Reply-To: <1367455382.45.0.0611766927148.issue17890@psf.upfronthosting.co.za> Message-ID: <1367570725.71.0.663161793993.issue17890@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: A user generated line with multiple spaces may be essential if we are getting the usage data (particularly from) a csv file (that may have random spaces in certain fields) or some other form of stored or auto-generated data. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 11:41:58 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 May 2013 09:41:58 +0000 Subject: [issue15535] Fix pickling efficiency of named tuples in 2.7.3 In-Reply-To: <1343915086.31.0.252328658724.issue15535@psf.upfronthosting.co.za> Message-ID: <3b27fF3DcWz7LlC@mail.python.org> Roundup Robot added the comment: New changeset 65cd71abebc8 by Raymond Hettinger in branch '3.3': Issue #15535: Fix pickling of named tuples. http://hg.python.org/cpython/rev/65cd71abebc8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 11:42:40 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 03 May 2013 09:42:40 +0000 Subject: [issue15535] Fix pickling efficiency of named tuples in 2.7.3 In-Reply-To: <1343915086.31.0.252328658724.issue15535@psf.upfronthosting.co.za> Message-ID: <1367574160.63.0.58744927722.issue15535@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- Removed message: http://bugs.python.org/msg188064 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 11:43:05 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 03 May 2013 09:43:05 +0000 Subject: [issue15535] Fix pickling efficiency of named tuples in 2.7.3 In-Reply-To: <1343915086.31.0.252328658724.issue15535@psf.upfronthosting.co.za> Message-ID: <1367574185.5.0.0820343706642.issue15535@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: amaury.forgeotdarc -> rhettinger resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 11:47:26 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 03 May 2013 09:47:26 +0000 Subject: [issue17894] Edits to descriptor howto In-Reply-To: <1367547112.04.0.920947702161.issue17894@psf.upfronthosting.co.za> Message-ID: <1367574446.51.0.151622087508.issue17894@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger nosy: +rhettinger priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 11:48:34 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 03 May 2013 09:48:34 +0000 Subject: [issue12077] Harmonizing descriptor protocol documentation In-Reply-To: <1305381385.94.0.81554539251.issue12077@psf.upfronthosting.co.za> Message-ID: <1367574514.03.0.137249340301.issue12077@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 11:53:57 2013 From: report at bugs.python.org (Ben Hoyt) Date: Fri, 03 May 2013 09:53:57 +0000 Subject: [issue15535] Fix pickling efficiency of named tuples in 2.7.3 In-Reply-To: <1343915086.31.0.252328658724.issue15535@psf.upfronthosting.co.za> Message-ID: <1367574837.52.0.49168534299.issue15535@psf.upfronthosting.co.za> Ben Hoyt added the comment: 2.7 fix works for me, thanks! Just curious -- why the different fix for 3.3 (addition of __getstate__ instead of removal of __dict__)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 12:06:04 2013 From: report at bugs.python.org (Ben Hoyt) Date: Fri, 03 May 2013 10:06:04 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: Message-ID: Ben Hoyt added the comment: Thanks. I thought about that -- but I think I *want* to benchmark it when they're cached, so that we're comparing apples with apples, cached system calls with cached systems calls. The benchmark would almost certainly be a lot "better" (BetterWalk would be even faster) if I was comparing the non-cached results. I'll think about it some more though. Thoughts? -Ben On Fri, May 3, 2013 at 7:03 PM, Charles-Fran?ois Natali < report at bugs.python.org> wrote: > > Charles-Fran?ois Natali added the comment: > > > However, the reason I'm keen on iterdir_stat() is that I'm seeing it > speed up os.walk() by a factor of 10 in my recent tests (note that I've > made local mods, so these results aren't reproducible for others yet). This > is doing a walk on a dir tree with 7800 files and 155 dirs: > > > > Using fast _betterwalk > > Priming the system's cache... > > Benchmarking walks on C:\Work\betterwalk\benchtree, repeat 1/3... > > Benchmarking walks on C:\Work\betterwalk\benchtree, repeat 2/3... > > Benchmarking walks on C:\Work\betterwalk\benchtree, repeat 3/3... > > os.walk took 0.178s, BetterWalk took 0.017s -- 10.5x as fast > > > > Sometimes Windows will go into this "I'm really caching stat results > good" mode -- I don't know what heuristic determines this -- and then I'm > seeing a 40x speed increase. And no, you didn't read that wrong. :-) > > I/O benchmarks shouldn't use timeit or repeated calls: after the first > run, most of your data is in cache, so subsequent runs are > meaningless. > > I don't know about Windows, but on Linux you should do something like: > # echo 3 > /proc/sys/vm/drop_caches > > to start out clean. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 12:07:01 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 03 May 2013 10:07:01 +0000 Subject: [issue15535] Fix pickling efficiency of named tuples in 2.7.3 In-Reply-To: <1343915086.31.0.252328658724.issue15535@psf.upfronthosting.co.za> Message-ID: <1367575621.54.0.338265985978.issue15535@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > why the different fix for 3.3 I reverted the 2.7.4 addition of __dict__ rather than introduce more differences between point releases with possible unintended effects. In 3.3, the __dict__ attribute was there from the outset and was advertised in the docs, so it made more sense to leave it in and just suppress its inclusion in pickling. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 13:57:01 2013 From: report at bugs.python.org (Christian Heimes) Date: Fri, 03 May 2013 11:57:01 +0000 Subject: [issue11016] Add S_ISDOOR to the stat module In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za> Message-ID: <1367582221.74.0.968746860514.issue11016@psf.upfronthosting.co.za> Christian Heimes added the comment: The stat module (or whatever it is going to be in Python 3.4) is missing more checks than S_ISDOOR: # Solaris S_ISDOOR() S_ISPORT() # POSIX 1.b real-time extension S_ISMSG() S_ISSEM() S_ISSHM() # whiteout, translucent file systems S_ISWHT ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 15:53:52 2013 From: report at bugs.python.org (Roger Serwy) Date: Fri, 03 May 2013 13:53:52 +0000 Subject: [issue17838] Can't assign a different value for sys.stdin in IDLE In-Reply-To: <1366872984.94.0.234893757031.issue17838@psf.upfronthosting.co.za> Message-ID: <1367589232.86.0.234617586402.issue17838@psf.upfronthosting.co.za> Roger Serwy added the comment: 3.2 still has the problem fixed in issue17585 for 3.3 and 3.4. This only applies if issue17585 patch gets applied to 3.2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 16:47:27 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 May 2013 14:47:27 +0000 Subject: [issue15902] imp.load_module won't accept None for the file argument for a C extension In-Reply-To: <1347278689.78.0.295593798435.issue15902@psf.upfronthosting.co.za> Message-ID: <3b2GQk4pcgz7LkH@mail.python.org> Roundup Robot added the comment: New changeset c0a21617dbee by Brett Cannon in branch '3.3': Issue #15902: Fix imp.load_module() to accept None as a file when http://hg.python.org/cpython/rev/c0a21617dbee New changeset 322c556260d5 by Brett Cannon in branch 'default': #15902: merge w/ 3.3 http://hg.python.org/cpython/rev/322c556260d5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 16:53:18 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 03 May 2013 14:53:18 +0000 Subject: [issue15902] imp.load_module won't accept None for the file argument for a C extension In-Reply-To: <1347278689.78.0.295593798435.issue15902@psf.upfronthosting.co.za> Message-ID: <1367592798.91.0.146919739318.issue15902@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 17:16:41 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 May 2013 15:16:41 +0000 Subject: [issue15984] Wrong documentation for PyUnicode_FromObject() and PyUnicode_FromEncodedObject() In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za> Message-ID: <1367594201.57.0.289006300652.issue15984@psf.upfronthosting.co.za> R. David Murray added the comment: Well, while 'coercion' does refer to changing from one type to another, and technically we are doing that here, in OO we generally think of subclasses as more-or-less being of the same type as the superclass. So I think it would be clearer to spell out that we are changing the object type to be that of the superclass. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 18:28:39 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 03 May 2013 16:28:39 +0000 Subject: [issue17859] improve error message for saving ints to file In-Reply-To: <1367134676.21.0.161863892006.issue17859@psf.upfronthosting.co.za> Message-ID: <1367598519.72.0.846543858613.issue17859@psf.upfronthosting.co.za> ?ric Araujo added the comment: Ah, right, I missed the part about the file being opened in binary mode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 18:38:43 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 03 May 2013 16:38:43 +0000 Subject: [issue17860] subprocess docs lack info how to use output result In-Reply-To: <1367159799.26.0.456231833917.issue17860@psf.upfronthosting.co.za> Message-ID: <1367599123.53.0.302393464597.issue17860@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 18:44:10 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 03 May 2013 16:44:10 +0000 Subject: [issue17888] docs: more information on documentation team In-Reply-To: <1367412914.06.0.588625037016.issue17888@psf.upfronthosting.co.za> Message-ID: <1367599450.7.0.132224883033.issue17888@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 18:54:17 2013 From: report at bugs.python.org (Julian Taylor) Date: Fri, 03 May 2013 16:54:17 +0000 Subject: [issue17895] TemporaryFile name returns an integer in python3 Message-ID: <1367600057.19.0.0234960166216.issue17895@psf.upfronthosting.co.za> New submission from Julian Taylor: sys.version_info(major=3, minor=3, micro=1, releaselevel='final', serial=0) In [3]: type(tempfile.TemporaryFile().name) Out[3]: builtins.int in python2 it returned a string, this is a somewhat pointless api change which breaks some third party code, e.g. numpy (https://github.com/numpy/numpy/issues/3302) ---------- components: Library (Lib) messages: 188305 nosy: jtaylor priority: normal severity: normal status: open title: TemporaryFile name returns an integer in python3 type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 18:56:02 2013 From: report at bugs.python.org (paul j3) Date: Fri, 03 May 2013 16:56:02 +0000 Subject: [issue17890] argparse: mutually exclusive groups full of suppressed args can cause AssertionErrors In-Reply-To: <1367455382.45.0.0611766927148.issue17890@psf.upfronthosting.co.za> Message-ID: <1367600162.83.0.316707745581.issue17890@psf.upfronthosting.co.za> paul j3 added the comment: I see three solutions - 1) gholms' patch which removes '() ' and [] ' 2) Yogesh's patch which removes all duplicated spaces. 3) remove the 2 asserts. The first 2 do the same thing most of the time, but may differ if the user somehow inserts spaces into names. The third leaves the extra blanks, but renders them innocuous. I doubt if the asserts were written to catch this problem. They probably were included to verify the usage line had been split up as expected prior to reassembling on multiple lines. As best I can tell test_argparse.py does not test for these spaces. Curiously though a port of argparse to javascript does have a test case with the extra space. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 19:07:29 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 May 2013 17:07:29 +0000 Subject: [issue15834] 2to3 benchmark not working under Python 3 In-Reply-To: <1346452040.3.0.632075344934.issue15834@psf.upfronthosting.co.za> Message-ID: <3b2KXK0lSjzSPS@mail.python.org> Roundup Robot added the comment: New changeset 66f168b468c3 by Brett Cannon in branch 'default': #15834: Make 2to3 so it can actually be proper translated. http://hg.python.org/benchmarks/rev/66f168b468c3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 19:08:16 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 03 May 2013 17:08:16 +0000 Subject: [issue15834] 2to3 benchmark not working under Python 3 In-Reply-To: <1346452040.3.0.632075344934.issue15834@psf.upfronthosting.co.za> Message-ID: <1367600896.67.0.662049542277.issue15834@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 19:13:41 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 03 May 2013 17:13:41 +0000 Subject: [issue15902] imp.load_module won't accept None for the file argument for a C extension In-Reply-To: <1347278689.78.0.295593798435.issue15902@psf.upfronthosting.co.za> Message-ID: <1367601221.43.0.491059432035.issue15902@psf.upfronthosting.co.za> Brett Cannon added the comment: Leaving it up to the release manager to decide if this is worth cherrypicking or just waiting for the next bugfix release. ---------- nosy: +larry priority: normal -> release blocker status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 19:16:17 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 03 May 2013 17:16:17 +0000 Subject: [issue15902] imp.load_module won't accept None for the file argument for a C extension In-Reply-To: <1347278689.78.0.295593798435.issue15902@psf.upfronthosting.co.za> Message-ID: <1367601377.99.0.166270982476.issue15902@psf.upfronthosting.co.za> Changes by Brett Cannon : _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 19:18:26 2013 From: report at bugs.python.org (Zachary Ware) Date: Fri, 03 May 2013 17:18:26 +0000 Subject: [issue17896] Move Windows external libs from \..\ to \externals Message-ID: <1367601506.45.0.508953342953.issue17896@psf.upfronthosting.co.za> New submission from Zachary Ware: PCbuild\readme.txt has a comment from Trent Nelson dated 2-April-2008 suggesting moving the external library location for Windows from "\..\" to "\external\" to make switching between versions easier. I've gotten rather annoyed with having all of the external libs cluttering the folder holding my cpython checkout, so I've written a patch that moves them :). The patch actually moves the external libs into "\external-34", because in most cases it's best to have separately built externals for each Python version. The idea is to then have an "external-35" after 3.4 is released, and possibly "external-27" and "external-33" if it is permissible to backport this kind of change. There are only four places that would need to be changed in other versions; PCbuild/pyproject.props:19, PCbuild/rt.bat:41, Tools/buildbot/external-common.bat:4 and 5, and Lib/tkinter/_fix.py:52. All four are simple replacements which I believe could be automated by the release script. PCbuild/build_ssl.py is patched to find the externals dir in PCbuild/pyproject.props while finding the OpenSSL version there. A few of the benefits to this that have occurred to me are: - the fact that the dir holding your cpython checkout doesn't get cluttered up with external libs - it becomes very easy to rebuild all of the externals (just `rmdir /s /q external-34` and run external(-amd64).bat again) - no possibility of problems arising from one version trying to use an external lib built by/for another version The only real downsides I'm aware of are that it is a change from what everyone is accustomed to, and that it will use up a bit more disk space (which could be mitigated by using junctions, as Trent suggested in the comment in readme.txt). Also, committing this would cause an extra long build time on the buildbots due to having to recompile Tcl/Tk and OpenSSL. Everything builds and works for me using the buildbot scripts after the patch. All comments welcome :) Thanks, Zach ---------- components: Build, Extension Modules, Windows files: move_externals.diff keywords: patch messages: 188309 nosy: brian.curtin, tim.golden, trent, zach.ware priority: normal severity: normal status: open title: Move Windows external libs from \..\ to \externals type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file30113/move_externals.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 19:24:22 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 May 2013 17:24:22 +0000 Subject: [issue15984] Wrong documentation for PyUnicode_FromObject() and PyUnicode_FromEncodedObject() In-Reply-To: <1348157907.35.0.947782583816.issue15984@psf.upfronthosting.co.za> Message-ID: <1367601862.28.0.345548190036.issue15984@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In other languages usually the world "coercion" is used for implicit conversion, i.e. int->long, int->float, float->complex. str->unicode in Python 2 (that's what PyUnicode_FromObject() does). But the last conversion is not supported in Python 3. The term "coercion" has also been used in Python 2 in the narrow sense (see the __coerce__() method), and in this sense Python 3 does not support "coercion". Therefore, I believe that it is better to avoid the use of this term. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 19:30:45 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 May 2013 17:30:45 +0000 Subject: [issue17895] TemporaryFile name returns an integer in python3 In-Reply-To: <1367600057.19.0.0234960166216.issue17895@psf.upfronthosting.co.za> Message-ID: <1367602245.68.0.672718724017.issue17895@psf.upfronthosting.co.za> R. David Murray added the comment: The 'name' attribute of TemporaryFile is not part of the API. It happens to exist only because the underlying file object has a 'name' attribute. On posix platforms the value is not really useful for anything. In other words, that numpy code was buggy to start with, the bug was just hidden by the fact that in python2 name happened to be a string (''), and nobody looked at the result. What numpy was doing with it produced a nonsense value, but I guess nobody noticed. Now, that said, I don't know why the value changed between Python2 and Python3, and that might conceivably be a bug of some sort. I'm guessing it is a consequence of the IO system rewrite and is not a bug per-se, but it might also be that there are improvements that could be made here. ---------- nosy: +pitrou, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 19:37:22 2013 From: report at bugs.python.org (Alexandre Vassalotti) Date: Fri, 03 May 2013 17:37:22 +0000 Subject: [issue17810] Implement PEP 3154 (pickle protocol 4) In-Reply-To: <1366526938.19.0.00976593994103.issue17810@psf.upfronthosting.co.za> Message-ID: <1367602642.59.0.966054663456.issue17810@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: I am currently fleshing out an improved implementation for the reduce protocol version 4. One thing I am curious about is whether we should keep the special cases we currently have there for dict and list subclasses. I recall Raymond expressed disagreement in #msg83098 about this behavior. I agree that having __setitem__ called before __init__ make it harder for dict and list subclasses to support pickling. To take advantage of the special case, subclasses need to do their required initialization in the __new__ method. On the other hand, it does decrease the memory requirements for unpickling such subclasses---i.e., we can build the object in-place instead of building an intermediary list or dict. Reading PEP 307 confirms indeed that was the original intention. One possible solution, other than removing the special case completely, is to make sure we initialize the object (using the BUILD opcode) before we call __setitem__ or append on it. This would be a simple change that would solve the initialization issue. However, I would still feel uneasy about the default object.__reduce__ behavior depending on the object's subtype. I think it could be worthwhile to investigate a generic API for pickling collections in-place. For example, a such API would helpful for pickling set subclasses in-place. __items__() or Return an iterator of the items in the collection. Would be __getitems__() equivalent to iter(dict.items()) on dicts and iter(list) on lists. __additems__(items) Add a batch of items to the collection. By default, it would be defined as: for item in items: self.__additem__(item) However, subclasses would be free to provide a more efficient implementation of the method. Would be equivalent to dict.update on dicts and list.extend on lists. __additem__(item) Add a single item to the collection. Would be equivalent to dict[item[0]] = item[1] on dicts and list.append on lists. The collections module's ABCs could then provide default implementations of this API, which would give its users efficient in-place pickling automatically. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 19:39:59 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 May 2013 17:39:59 +0000 Subject: [issue1159051] Handle corrupted gzip files with unexpected EOF Message-ID: <1367602798.99.0.128000282197.issue1159051@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In both cases broken applications use the undocumented implementation details. But such changes are extremely strong for bugfix release and they should not be done without a special need. I propose to revert these changes in 2.7, 3.2 and 3.3 (possibly leaving in the default branch). Unfortunately, I was not online right before the release of the latest bugfix release and failed to do this. Fortunately, it is now possible to fix this in regression fix releases. ---------- nosy: +benjamin.peterson, georg.brandl priority: normal -> release blocker type: enhancement -> behavior versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 19:40:31 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 May 2013 17:40:31 +0000 Subject: [issue17895] TemporaryFile name returns an integer in python3 In-Reply-To: <1367600057.19.0.0234960166216.issue17895@psf.upfronthosting.co.za> Message-ID: <1367602831.62.0.668001621739.issue17895@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Given the following property of TemporaryFile: "Under Unix, the directory entry for the file is removed immediately after the file is created. Other platforms do not support this; your code should not rely on a temporary file created using this function having or not having a visible name in the file system." (from http://docs.python.org/dev/library/tempfile.html#tempfile.TemporaryFile) I find it absurd to expect the name attribute to return an actual filename, since it won't exist anymore by the time you use it (under Unix, at least). So, we could return an invalid filename, but I don't see the point, and the current behaviour is as good as any other. If you want a usable name, by definition you must use NamedTemporaryFile. Recommend closing. ---------- nosy: +georg.brandl, ncoghlan resolution: -> rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 19:42:37 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 May 2013 17:42:37 +0000 Subject: [issue17810] Implement PEP 3154 (pickle protocol 4) In-Reply-To: <1367602642.59.0.966054663456.issue17810@psf.upfronthosting.co.za> Message-ID: <1367602955.2556.1.camel@fsol> Antoine Pitrou added the comment: > I think it could be worthwhile to investigate a generic API for > pickling collections in-place. For example, a such API would helpful > for pickling set subclasses in-place. Is the use case important enough? Otherwise, this is more __special_method__ complication that we'll have to maintain for pickle's only use. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 19:55:32 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 May 2013 17:55:32 +0000 Subject: [issue17896] Move Windows external libs from \..\ to \externals In-Reply-To: <1367601506.45.0.508953342953.issue17896@psf.upfronthosting.co.za> Message-ID: <1367603732.94.0.467483033748.issue17896@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 19:57:11 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 May 2013 17:57:11 +0000 Subject: [issue17895] TemporaryFile name returns an integer in python3 In-Reply-To: <1367600057.19.0.0234960166216.issue17895@psf.upfronthosting.co.za> Message-ID: <1367603831.47.0.648398486439.issue17895@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: http://docs.python.org/3/library/io.html#io.FileIO.name The file name. This is the file descriptor of the file when no name is given in the constructor. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 20:16:39 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 May 2013 18:16:39 +0000 Subject: [issue17897] Optimize unpickle prefetching Message-ID: <1367604999.94.0.501171592637.issue17897@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: When C implementation of the unpickle reads a data, it also prefetches some data using peek() (if available) and then concatenates read and peeked chunks in the one input buffer. This causes an additional copying when a large data is read. The proposed patch gets rid of concatenating by moving a peeking before reading. ---------- components: Extension Modules files: pickle_peek.patch keywords: patch messages: 188317 nosy: alexandre.vassalotti, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Optimize unpickle prefetching type: performance versions: Python 3.4 Added file: http://bugs.python.org/file30114/pickle_peek.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 20:19:46 2013 From: report at bugs.python.org (Steve Strassmann) Date: Fri, 03 May 2013 18:19:46 +0000 Subject: [issue17898] gettext bug while parsing plural-forms metadata Message-ID: <1367605186.32.0.57972582146.issue17898@psf.upfronthosting.co.za> New submission from Steve Strassmann: The gettext.py parser used by django (lib/python2.7/gettext.py), GNUTranslations._parse(), around line 313 does not use clean values for k,v on each iteration ("for item in tmsg.splitlines():") To reproduce the problem (see traceback, below), try parsing a .PO file containing two headers like this, with a comment header immediately following a plurals header. This example was created by calling msgcat to combine several .po files into a single .po file. Msgcat inserted the comment line. "Plural-Forms: nplurals=2; plural=(n != 1);\n" "#-#-#-#-# messages.po (EdX Studio) #-#-#-#-#\n" Parsing the first header binds the inner loop variables: k= plural-forms v= ['nplurals=2', ' plural=(n != 1)', ''] Parsing the second header leaves k,v untouched, which then causes an improper attempt to parse (since it's a comment, no further parsing of k,v should occur) v = v.split(';') Bug workaround: I use polib to read and immediately save the file. This reorders the metadata to avoid presenting the parser with something that will break it. Recommended bug fix: on each iteration over tmsg.splitlines, reset the values of k,v = (None, None) -------------------- Traceback: File "/Users/sstrassmann/src/mitx_all/python/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response 89. response = middleware_method(request) File "/Users/sstrassmann/src/mitx_all/python/lib/python2.7/site-packages/django/middleware/locale.py" in process_request 24. translation.activate(language) File "/Users/sstrassmann/src/mitx_all/python/lib/python2.7/site-packages/django/utils/translation/__init__.py" in activate 105. return _trans.activate(language) File "/Users/sstrassmann/src/mitx_all/python/lib/python2.7/site-packages/django/utils/translation/trans_real.py" in activate 201. _active.value = translation(language) File "/Users/sstrassmann/src/mitx_all/python/lib/python2.7/site-packages/django/utils/translation/trans_real.py" in translation 191. current_translation = _fetch(language, fallback=default_translation) File "/Users/sstrassmann/src/mitx_all/python/lib/python2.7/site-packages/django/utils/translation/trans_real.py" in _fetch 180. res = _merge(localepath) File "/Users/sstrassmann/src/mitx_all/python/lib/python2.7/site-packages/django/utils/translation/trans_real.py" in _merge 156. t = _translation(path) File "/Users/sstrassmann/src/mitx_all/python/lib/python2.7/site-packages/django/utils/translation/trans_real.py" in _translation 138. t = gettext_module.translation('django', path, [loc], DjangoTranslation) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/gettext.py" in translation 480. t = _translations.setdefault(key, class_(fp)) File "/Users/sstrassmann/src/mitx_all/python/lib/python2.7/site-packages/django/utils/translation/trans_real.py" in __init__ 76. gettext_module.GNUTranslations.__init__(self, *args, **kw) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/gettext.py" in __init__ 180. self._parse(fp) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/gettext.py" in _parse 315. v = v.split(';') Exception Type: AttributeError at / Exception Value: 'list' object has no attribute 'split' ---------- components: Library (Lib) messages: 188318 nosy: straz priority: normal severity: normal status: open title: gettext bug while parsing plural-forms metadata type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 20:24:05 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 03 May 2013 18:24:05 +0000 Subject: [issue17636] Modify IMPORT_FROM to fallback on sys.modules In-Reply-To: <1365124502.39.0.727243640375.issue17636@psf.upfronthosting.co.za> Message-ID: <1367605445.89.0.775517272704.issue17636@psf.upfronthosting.co.za> Brett Cannon added the comment: I have uploaded a patch with failing tests that should work after this is all said and done. Philip, please make sure I covered your tests as expected (I tweaked one because it already was working the way I did it). This way we at least know what we are aiming for in terms of results. ---------- keywords: +patch Added file: http://bugs.python.org/file30115/circular_import_tests.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 20:39:20 2013 From: report at bugs.python.org (Alexandre Vassalotti) Date: Fri, 03 May 2013 18:39:20 +0000 Subject: [issue17810] Implement PEP 3154 (pickle protocol 4) In-Reply-To: <1366526938.19.0.00976593994103.issue17810@psf.upfronthosting.co.za> Message-ID: <1367606360.15.0.950380721792.issue17810@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Those methods wouldn't be much more a maintenance burden than the special cases already present in the implementation of __reduce__. These methods would only need to be provided by classes that wishes to support efficient in-place pickling provided by protocol 4. As such, this approach better as it would rely on duck typing rather than concrete type checks, which IMHO do not belong in the default object implementation. Plus, having this generic API would allow pickle to share the same pickling and unpickling code for lists, dicts, sets and other mutable collections. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 20:40:33 2013 From: report at bugs.python.org (Ned Batchelder) Date: Fri, 03 May 2013 18:40:33 +0000 Subject: [issue17898] gettext bug while parsing plural-forms metadata In-Reply-To: <1367605186.32.0.57972582146.issue17898@psf.upfronthosting.co.za> Message-ID: <1367606433.86.0.542741184615.issue17898@psf.upfronthosting.co.za> Changes by Ned Batchelder : ---------- nosy: +nedbat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 20:41:12 2013 From: report at bugs.python.org (Ned Batchelder) Date: Fri, 03 May 2013 18:41:12 +0000 Subject: [issue12077] Harmonizing descriptor protocol documentation In-Reply-To: <1305381385.94.0.81554539251.issue12077@psf.upfronthosting.co.za> Message-ID: <1367606472.96.0.499633125008.issue12077@psf.upfronthosting.co.za> Changes by Ned Batchelder : ---------- nosy: +nedbat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 21:02:20 2013 From: report at bugs.python.org (Evgeny Kapun) Date: Fri, 03 May 2013 19:02:20 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1299320278.86.0.403600489598.issue11406@psf.upfronthosting.co.za> Message-ID: <1367607740.5.0.564886538835.issue11406@psf.upfronthosting.co.za> Changes by Evgeny Kapun : ---------- nosy: +abacabadabacaba _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 21:07:03 2013 From: report at bugs.python.org (Christian Heimes) Date: Fri, 03 May 2013 19:07:03 +0000 Subject: [issue11016] Add S_ISDOOR to the stat module In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za> Message-ID: <1367608023.16.0.692795882783.issue11016@psf.upfronthosting.co.za> Christian Heimes added the comment: I have done some research. The POSIX 1.b extensions aren't used on any supported system (neither Linux nor BSD, Solaris or AIX). random832 at fastmail.us has compiled a list of even more file types: Heirloom toolchest "ls" supports: http://heirloom.cvs.sourceforge.net/viewvc/heirloom/heirloom/ls/ls.c?revision=1.9&view=markup http://heirloom.cvs.sourceforge.net/viewvc/heirloom/heirloom/ls/ls.1?revision=1.5&view=markup S_IFNWK HP-UX network special file S_IFNAM XENIX special named file S_INSEM XENIX semaphore subtype of IFNAM (looked up from s->rdev) S_INSHD XENIX shared data subtype of IFNAM " " " " Of these, GNU coreutils ls only supports doors and whiteouts. Chasing after a random hunch (something about AIX), I found these: http://cd.textfiles.com/transameritech2/EXTRAS/JOVE-4.6/ASK.C S_ISHIDDEN Hidden Directory [aix] S_ISCDF Context Dependent Files [hpux] S_ISNWK Network Special [hpux] http://lists.gnu.org/archive/html/bug-gnulib/2012-12/msg00084.html S_ISMPX AIX "MPX" file (multiplex device?) https://github.com/gagern/gnulib/blob/master/tests/test-sys_stat.c has a massive pile of macros with no comments S_ISCTG S_ISMPB S_ISMPX S_ISNAM S_ISNWK S_ISOFD S_ISOFL S_ISPORT http://lists.gnu.org/archive/html/bug-gnulib/2004-08/msg00017.html S_ISOFD Cray DMF (data migration facility): off line, with data S_ISOFL Cray DMF (data migration facility): off line, with no data S_ISCTG Contiguous (It's possible that these may not be file types) http://doiso.googlecode.com/svn/trunk/Source/mkisofs-1.12b5/include/statdefs.h S_ISMPC UNUSED multiplexed c S_ISNAM Named file (XENIX) S_ISMPB UNUSED multiplexed b S_ISCNT Contiguous file S_ISSHAD Solaris shadow inode http://www.opensource.apple.com/source/gnutar/gnutar-450/gnutar/lib/sys_stat_.h S_ISMPB /* V7 */ S_ISPORT /* Solaris 10 and up */ S_TYPEISSEM S_TYPEISSHM - macros to check the XENIX IFNAM types mentioned above S_TYPEISMQ S_TYPEISTMO ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 21:16:26 2013 From: report at bugs.python.org (Evgeny Kapun) Date: Fri, 03 May 2013 19:16:26 +0000 Subject: [issue17899] os.listdir() leaks FDs if invoked on FD pointing to a non-directory Message-ID: <1367608586.39.0.0815102318744.issue17899@psf.upfronthosting.co.za> New submission from Evgeny Kapun: When called with a file descriptor as an argument, os.listdir() duplicates it to pass to fdopendir(3). If this call fails, the new file descriptor is not closed, which leads to file descriptor leak. ---------- components: Library (Lib) messages: 188322 nosy: abacabadabacaba priority: normal severity: normal status: open title: os.listdir() leaks FDs if invoked on FD pointing to a non-directory type: resource usage versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 21:27:09 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 May 2013 19:27:09 +0000 Subject: [issue17898] gettext bug while parsing plural-forms metadata In-Reply-To: <1367605186.32.0.57972582146.issue17898@psf.upfronthosting.co.za> Message-ID: <1367609229.35.0.826471007525.issue17898@psf.upfronthosting.co.za> R. David Murray added the comment: Does this bear any relationship to issue 1475523? (And yes, I know it is...sad...that that issue hasn't been fixed yet.) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 21:38:04 2013 From: report at bugs.python.org (Steve Strassmann) Date: Fri, 03 May 2013 19:38:04 +0000 Subject: [issue17898] gettext bug while parsing plural-forms metadata In-Reply-To: <1367605186.32.0.57972582146.issue17898@psf.upfronthosting.co.za> Message-ID: <1367609884.01.0.642089899104.issue17898@psf.upfronthosting.co.za> Steve Strassmann added the comment: There seem to be several bugs involving this particular inner loop in gettext._parse(), but I don't think they're equivalent. The present bug (issue17898) is that parsing a plural header breaks the following header when it happens to be a comment. issue1475523 seems to involve multi-line handling issue12425 seems to involve breaking when the plural-forms value is empty. Perhaps a useful design pattern to follow for code which executes this inner loop would be to have some initialization and loop invariants which are asserted true on each iteration. For example, properly initializing k and v on each iteration. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 21:40:16 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 May 2013 19:40:16 +0000 Subject: [issue17900] Recursive OrderedDict pickling Message-ID: <1367610016.74.0.566900545996.issue17900@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Here is a patch which allows pickling of recursive OrderedDicts. Actually it simplifies __reduce__() code. ---------- components: Library (Lib) files: OrderedDict_pickle_recursive.patch keywords: patch messages: 188325 nosy: alexandre.vassalotti, pitrou, rhettinger, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Recursive OrderedDict pickling type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file30116/OrderedDict_pickle_recursive.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 21:56:56 2013 From: report at bugs.python.org (Aaron Oakley) Date: Fri, 03 May 2013 19:56:56 +0000 Subject: [issue17901] _elementtree.TreeBuilder raises IndexError on end if constructed with element_factory=None Message-ID: <1367611016.77.0.197383711231.issue17901@psf.upfronthosting.co.za> New submission from Aaron Oakley: When the _elementtree module is in use, the TreeBuilder class will raise an IndexError in treebuilder_handle_end if __init__ was passed "None". I discovered this while writing a subclass of TreeBuilder with a modified __init__ method that delegated to TreeBuilder: class MyTreeBuilder(ET.TreeBuilder): def __init__(self, element_factory=None): super().__init__(element_factory) Used as a target, this class (and also simply "TreeBuilder(None)") will cause the IndexError when "parser.feed(data)" is called. >>> import xml.etree.ElementTree as ET >>> parser = ET.XMLParser(target=ET.TreeBuilder(None)) >>> parser.feed('22') Traceback (most recent call last): File "", line 1, in IndexError: pop from empty stack The error is raised from treebuilder_handle_end, but the cause appears to be in treebuilder_handle_start. if (self->element_factory) { node = PyObject_CallFunction(self->element_factory, "OO", tag, attrib); } else { node = create_new_element(tag, attrib); } I included a patch adding a check against Py_None to the "if" test above which seems to fix the issue. I also included a simple test case for it. ---------- components: XML files: _elementtree.c-340a0.patch keywords: patch messages: 188326 nosy: Aaron.Oakley priority: normal severity: normal status: open title: _elementtree.TreeBuilder raises IndexError on end if constructed with element_factory=None type: behavior versions: Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30117/_elementtree.c-340a0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 22:07:59 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 May 2013 20:07:59 +0000 Subject: [issue17849] Missing size argument in readline() method for httplib's class LineAndFileWrapper In-Reply-To: <1366979224.14.0.876475494511.issue17849@psf.upfronthosting.co.za> Message-ID: <1367611679.76.0.40831172112.issue17849@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +orsenthil, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 22:12:35 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 May 2013 20:12:35 +0000 Subject: [issue17810] Implement PEP 3154 (pickle protocol 4) In-Reply-To: <1366526938.19.0.00976593994103.issue17810@psf.upfronthosting.co.za> Message-ID: <1367611955.42.0.694049745456.issue17810@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is an updated framing patch which fixes the issue reported by Alexandre. There are also a couple added tests. ---------- Added file: http://bugs.python.org/file30118/framing3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 22:44:10 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 May 2013 20:44:10 +0000 Subject: [issue17854] symmetric difference operation applicable to more than two sets In-Reply-To: <1367063240.22.0.643670001227.issue17854@psf.upfronthosting.co.za> Message-ID: <1367613850.37.0.736891281413.issue17854@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Sets have methods that do not have operators (such as len, isdisjoint), operators that do not have non-special methods (such as in, <), and method-operator pairs that do the same thing (such as (union, |), (symmetric_difference, ^)). For the pairs, it gives the method signature and the *equivalent* operator expression. Since .union takes multiple 'other' args, the equivalent operator expression does too. Since .symmetric_difference only takes one 'other' arg, so does the expression. A coherent proposal would change the method code and doc to the following: symmetric_difference(other, ...) set ^ other ^ ... Return a new set with elements in an odd number of the sets. s={1,2, 5} t={2,3, 5} u={3,4, 5} print(s^t^u) >>> {1, 4, 5} I believe the proposal was once considered, and rejected. An argument for is that the effect of chained symmetric differences is not obvious, as evidenced by Amit's mistaken characterization. I had to think a bit before I was sure of the answer. An argument against is that what one actually gets is seldom wanted, so that allowing more than two inputs to the method would have little benefit. What might be done is to document the symmetric different of multiple sets with a parenthetical comment such as "(The symmetric difference of multiple sets, a ^ b ^ c ^ ..., is a new set with elements appearing in an odd number of input sets.)" This would let people know what to expect from such expressions, in a situation where the effect is less obvious than usual. ---------- nosy: +rhettinger, terry.reedy stage: -> patch review versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 3 22:56:18 2013 From: report at bugs.python.org (Aaron Oakley) Date: Fri, 03 May 2013 20:56:18 +0000 Subject: [issue17902] Document that _elementtree C API cannot use custom TreeBuilder for iterparse or IncrementalParser Message-ID: <1367614578.64.0.34953241054.issue17902@psf.upfronthosting.co.za> New submission from Aaron Oakley: It would really help to document that the C API can only use the default xml.etree.ElementTree.TreeBuilder for targets with iterparse (and by extension, IncrementalParser). I got a nice surprise about that when I went from 3.2 to 3.3 and started getting "TypeError: event handling only supported for ElementTree.TreeBuilder targets". I included a patch to add notes to iterparse and IncrementalParser, but I'm not sure what to refer to the C module as since xml.etree.cElementTree is deprecated. ---------- assignee: docs at python components: Documentation, XML files: elementtree.rst-340a0.patch keywords: patch messages: 188329 nosy: Aaron.Oakley, docs at python priority: normal severity: normal status: open title: Document that _elementtree C API cannot use custom TreeBuilder for iterparse or IncrementalParser type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file30119/elementtree.rst-340a0.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 00:18:42 2013 From: report at bugs.python.org (Alexandre Vassalotti) Date: Fri, 03 May 2013 22:18:42 +0000 Subject: [issue17810] Implement PEP 3154 (pickle protocol 4) In-Reply-To: <1366526938.19.0.00976593994103.issue17810@psf.upfronthosting.co.za> Message-ID: <1367619522.33.0.167094102273.issue17810@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: The framing patch seems to have a significant negative effect on performance. Report on Linux avassalotti 3.2.5-gg1130 #1 SMP Mon Feb 4 02:25:47 PST 2013 x86_64 x86_64 Total CPU cores: 12 ### fastpickle ### Min: 0.447194 -> 0.505841: 1.13x slower Avg: 0.455517 -> 0.509537: 1.12x slower Significant (t=-22.05) Stddev: 0.01438 -> 0.00967: 1.4875x smaller ### fastunpickle ### Min: 0.583922 -> 0.638744: 1.09x slower Avg: 0.589183 -> 0.649506: 1.10x slower Significant (t=-21.77) Stddev: 0.00939 -> 0.01720: 1.8324x larger Would it be possible to mitigate the regression? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 00:28:02 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 May 2013 22:28:02 +0000 Subject: [issue17810] Implement PEP 3154 (pickle protocol 4) In-Reply-To: <1367619522.33.0.167094102273.issue17810@psf.upfronthosting.co.za> Message-ID: <1367620079.2556.4.camel@fsol> Antoine Pitrou added the comment: > The framing patch seems to have a significant negative effect on > performance. I wouldn't call it significant. Any speedup or slowdown less than 50% is unlikely to be noticeable in real-world applications. Mitigating the regression is probably a matter of tweaking the read/write fast paths (optimizing for the common case where a frame is ongoing and the buffer is neither full nor empty). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 01:19:30 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 May 2013 23:19:30 +0000 Subject: [issue17859] improve error message for saving ints to file In-Reply-To: <1367134676.21.0.161863892006.issue17859@psf.upfronthosting.co.za> Message-ID: <1367623170.42.0.0952826095107.issue17859@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I think the point is that the error message does not make much sense unless one knows a) that the file is open in binary mode (and that could have happened in a different file) and b) that 'does not support the buffer interface' means 'is not a bytes-like object'. A possible replacement that addresses both problems: binary-mode write requires bytes-like object, not 'int' ---------- nosy: +terry.reedy stage: -> needs patch versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 01:23:51 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 May 2013 23:23:51 +0000 Subject: [issue17899] os.listdir() leaks FDs if invoked on FD pointing to a non-directory In-Reply-To: <1367608586.39.0.0815102318744.issue17899@psf.upfronthosting.co.za> Message-ID: <1367623431.52.0.952413811854.issue17899@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +larry stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 01:24:40 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 May 2013 23:24:40 +0000 Subject: [issue17862] itertools.chunks(iterable, size, fill=None) In-Reply-To: <1367165590.04.0.46648726654.issue17862@psf.upfronthosting.co.za> Message-ID: <1367623480.56.0.898354581507.issue17862@psf.upfronthosting.co.za> Terry J. Reedy added the comment: [Anatoly, 'Versions 3.5' is for changes that should *not* happen in 3.4, such as a planned removal for something deprecated in 3.3.] ---------- nosy: +terry.reedy versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 01:24:55 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 03 May 2013 23:24:55 +0000 Subject: [issue17902] Document that _elementtree C API cannot use custom TreeBuilder for iterparse or IncrementalParser In-Reply-To: <1367614578.64.0.34953241054.issue17902@psf.upfronthosting.co.za> Message-ID: <1367623495.93.0.681246323077.issue17902@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +eli.bendersky stage: -> patch review versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 01:42:01 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 May 2013 23:42:01 +0000 Subject: [issue17887] docs: summary page - generator vs iterator vs iterable In-Reply-To: <1367390087.97.0.0883934646573.issue17887@psf.upfronthosting.co.za> Message-ID: <1367624521.32.0.89480795063.issue17887@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Briefly, An iterable is an object that can be iterated with an iterator. An iterator is an iterable that responds to next() calls, including the implicit calls in a for statement. A generator is an iterator created by a generator function, which is a function with a yield keyword in its body. A sequence is an iterable with minimal sequence methods. The four terms are all in the glossary. The entry for iterable already points to the other three. What do you think is missing? A range (as documented) is an immutable sequence. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 01:50:37 2013 From: report at bugs.python.org (Alexandre Vassalotti) Date: Fri, 03 May 2013 23:50:37 +0000 Subject: [issue17897] Optimize unpickle prefetching In-Reply-To: <1367604999.94.0.501171592637.issue17897@psf.upfronthosting.co.za> Message-ID: <1367625037.94.0.650424050336.issue17897@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Do you have benchmark results to show the code with the patch is faster? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 01:51:43 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 May 2013 23:51:43 +0000 Subject: [issue17887] docs: summary page - generator vs iterator vs iterable In-Reply-To: <1367390087.97.0.0883934646573.issue17887@psf.upfronthosting.co.za> Message-ID: <1367625103.08.0.168332698642.issue17887@psf.upfronthosting.co.za> Terry J. Reedy added the comment: To make the subset relationships clear in the iterable entry, perhaps replace See also iterator, sequence, and generator. with Some iterables are iterators and some iterators are generators. Some iterables are sequences. For details, see iterator, sequence, and generator. I see that 'generator' is currently used in the 3.3.1 glossary for 'generator function' and there is no entry for generator (object) proper. I thought that had been fixed after pydev discussion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 01:59:38 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 May 2013 23:59:38 +0000 Subject: [issue17890] argparse: mutually exclusive groups full of suppressed args can cause AssertionErrors In-Reply-To: <1367455382.45.0.0611766927148.issue17890@psf.upfronthosting.co.za> Message-ID: <1367625578.43.0.795895823322.issue17890@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Garrett and Yogesh, please submit contributor license agreements http://www.python.org/psf/contrib/contrib-form/ if you have not yet. When one is properly recorded, a * appears after your name. ---------- nosy: +terry.reedy versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 02:03:24 2013 From: report at bugs.python.org (STINNER Victor) Date: Sat, 04 May 2013 00:03:24 +0000 Subject: [issue17897] Optimize unpickle prefetching In-Reply-To: <1367604999.94.0.501171592637.issue17897@psf.upfronthosting.co.za> Message-ID: <1367625804.91.0.52273993718.issue17897@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 02:07:17 2013 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sat, 04 May 2013 00:07:17 +0000 Subject: [issue17810] Implement PEP 3154 (pickle protocol 4) In-Reply-To: <1366526938.19.0.00976593994103.issue17810@psf.upfronthosting.co.za> Message-ID: <1367626037.15.0.303797310624.issue17810@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Antoine, can you share the code for your benchmarks which show performance improvements when framing is enabled? I am seeing the same 10-15% slowdown even when pickling stuff to pure Python objects: ### Without the patch ./python -m timeit -r 50 -s "import pickle, _pyio; f = _pyio.BytesIO(); x = list(range(1000))" "pickle.dump(x, f, protocol=4)" 10000 loops, best of 50: 28.5 usec per loop ### With the patch ./python -m timeit -r 50 -s "import pickle, _pyio; f = _pyio.BytesIO(); x = list(range(1000))" "pickle.dump(x, f, protocol=4)" 10000 loops, best of 50: 32.9 usec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 02:19:24 2013 From: report at bugs.python.org (Larry Hastings) Date: Sat, 04 May 2013 00:19:24 +0000 Subject: [issue17899] os.listdir() leaks FDs if invoked on FD pointing to a non-directory In-Reply-To: <1367608586.39.0.0815102318744.issue17899@psf.upfronthosting.co.za> Message-ID: <1367626764.62.0.174892471838.issue17899@psf.upfronthosting.co.za> Larry Hastings added the comment: Patch attached. I don't know how to make fdopendir fail, so I had to do it by inspection. While I was in there, I ifdef'd out the variable that should only be used if fdopendir is available. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file30120/larry.listdir.fd.leakage.bug.1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 07:50:27 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 04 May 2013 05:50:27 +0000 Subject: [issue17862] itertools.chunks(iterable, size, fill=None) In-Reply-To: <1367165590.04.0.46648726654.issue17862@psf.upfronthosting.co.za> Message-ID: <1367646627.79.0.422833794695.issue17862@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 08:14:58 2013 From: report at bugs.python.org (Evgeny Kapun) Date: Sat, 04 May 2013 06:14:58 +0000 Subject: [issue17899] os.listdir() leaks FDs if invoked on FD pointing to a non-directory In-Reply-To: <1367608586.39.0.0815102318744.issue17899@psf.upfronthosting.co.za> Message-ID: <1367648098.8.0.153705610073.issue17899@psf.upfronthosting.co.za> Evgeny Kapun added the comment: To make fdopendir fail, just pass any valid FD which points to a non-directory, such as a file or a pipe. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 08:17:17 2013 From: report at bugs.python.org (Evgeny Kapun) Date: Sat, 04 May 2013 06:17:17 +0000 Subject: [issue17899] os.listdir() leaks FDs if invoked on FD pointing to a non-directory In-Reply-To: <1367608586.39.0.0815102318744.issue17899@psf.upfronthosting.co.za> Message-ID: <1367648237.87.0.344959468255.issue17899@psf.upfronthosting.co.za> Evgeny Kapun added the comment: Simple test: while True: try: listdir(0) except NotADirectoryError: pass ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 09:56:06 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 04 May 2013 07:56:06 +0000 Subject: [issue17862] itertools.chunks(iterable, size, fill=None) In-Reply-To: <1367165590.04.0.46648726654.issue17862@psf.upfronthosting.co.za> Message-ID: <1367654166.0.0.196230674777.issue17862@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The reasons for the previous rejections still hold: more tools make the overall toolset harder to use, not being a primitive operation, dearth of real-world use-cases, not being prevalent in other functional languages, easily expressible with existing tools, non-consensus on what to do with odd-sizes, lack of adoption of the published recipe, and a hard-to-guess function name. In addition to previously listed reasons, I have vague feelings that this isn't the right thing to do. The feelings are in-part based on poor user experience with itertools.groupby(), a function that developers said they wanted but ended-up being awkward to fit into real applications, confusing to some users, and rarely used in practice. Another source of misgivings is that iterators may not be the right tool for this kind of task. For example, when partitioning data into subgroups for a map/reduce operation, iterators won't help because they are evaluated serially which precludes any chance of parallelization. Even in cases of serial processing such reading blocks from a socket, the chunks iterator would be useless or awkward (i.e. we need more versatility than iterator.next() to manage the control-flow, time-outs, out-of-band control, separating headers from content, etc.) In other words, I have a sense that the generic concept of "break data into chunks" tends to occur is situations where the iterator protocol would be at odds with a clean solution. That said, I'll leave this open for a while and do my best to try to warm-up to it. Your recurring enthusiasm for it is a positive point. Another is its the faint resemblance to a numpy reshape operation. P.S. In prior discussions, the only real use case that ever surfaced was printing long sequences of data across multiple columns. Even that use case was suspect because the desired order is typically in column-major order (for example, look at the output of the *nix "ls" command). ---------- priority: normal -> low versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 10:08:09 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 May 2013 08:08:09 +0000 Subject: [issue17897] Optimize unpickle prefetching In-Reply-To: <1367604999.94.0.501171592637.issue17897@psf.upfronthosting.co.za> Message-ID: <1367654889.54.0.693068964521.issue17897@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: No, I have no any interesting results. ;) If an effect exists, it should reveal itself only in rare cases and be very small. This patch may be considered rather as a tiny refactoring (it decreases a number of code lines). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 10:08:18 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 May 2013 08:08:18 +0000 Subject: [issue17900] Recursive OrderedDict pickling In-Reply-To: <1367610016.74.0.566900545996.issue17900@psf.upfronthosting.co.za> Message-ID: <1367654898.78.0.241007787735.issue17900@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In additional the patch decreases the size of the pickled data, speeds up pickling and unpickling. $ ./python -c "import collections, pickle; od = collections.OrderedDict((i, i) for i in range(100000)); print(len(pickle.dumps(od)))" Without patch: 1536827. With patch: 737578. $ ./python -m timeit -s "from pickle import dumps; import collections; od = collections.OrderedDict((i, i) for i in range(100000))" "dumps(od)" Without patch: 454 msec. With patch: 361 msec. $ ./python -m timeit -s "from pickle import dumps, loads; import collections; od = collections.OrderedDict((i, i) for i in range(100000)); x = dumps(od)" "loads(x)" Without patch: 1.41 sec. With patch: 1.15 sec. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 10:29:33 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 May 2013 08:29:33 +0000 Subject: [issue17899] os.listdir() leaks FDs if invoked on FD pointing to a non-directory In-Reply-To: <1367608586.39.0.0815102318744.issue17899@psf.upfronthosting.co.za> Message-ID: <1367656173.28.0.361728269555.issue17899@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 11:06:41 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 May 2013 09:06:41 +0000 Subject: [issue17872] Crash in marshal.load() with bad reader In-Reply-To: <1367270952.48.0.351702678796.issue17872@psf.upfronthosting.co.za> Message-ID: <1367658401.06.0.441065769533.issue17872@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- type: behavior -> crash _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 11:26:18 2013 From: report at bugs.python.org (=?utf-8?q?Damien_Mari=C3=A9?=) Date: Sat, 04 May 2013 09:26:18 +0000 Subject: [issue17776] IDLE Internationalization In-Reply-To: <1366207983.79.0.104817094716.issue17776@psf.upfronthosting.co.za> Message-ID: <1367659578.14.0.785770156803.issue17776@psf.upfronthosting.co.za> Damien Mari? added the comment: A side note to justify the localization of IDLE: I think the internationalization part is important, It's a nearly invisible overhead for the code but it will be helpful for example: - In France, most of the highschool student have to learn python so they learn keyword and logic but most of them don't master english. And also in prep school like statued in the issue 17760 - Making the beginners more confident with the tool (as it's mostly used by beginners) - Most of the IDE are localized and the OS is localized, it's a matter of consistency to localize the IDLE UI But I'm against localizing exception messages and anything built into python I hope I responsed to some concerns. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 11:42:58 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 May 2013 09:42:58 +0000 Subject: [issue17868] pprint long non-printable bytes as hexdump In-Reply-To: <1367259569.59.0.63399196745.issue17868@psf.upfronthosting.co.za> Message-ID: <1367660578.42.0.494949959363.issue17868@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > 1) A separate function might be better. I think this kind of output would be more useful while inspecting individual byte objects, rather than having it for arbitrary byte objects (that might be inside other containers). I don't think the general hexdump() function is worth to including in the stdlib. It should have too many options (How many bytes display in one line? How group hexdigits? What replacemant character for non-printables? Whether or not to display addresses? Whether or not to display chars? What are delimiters between hexdigits and chars, address and hexdigits? What are line prefix and suffix? How display last incomplete line? How display first incomplete line?) and this makes it complicated. An application which outputs a hexdump on more rich device (a html file or a ANSI-colored terminal) needs advanced options. However a simple specialized code can be used for special purposes, i.e. internally in the pprint module. I don't see how it can be reused and don't interested in a general function. > 2) I don't know if the output of pprint is supposed to be eval()uable, but I don't like too much the base64.b16decode(...).replace(' ', '') in the output (especially if the byte objects are short). If a separate function is used as suggested in 1) this won't be a problem. Using the hex_codec might be another option. An alternative option is first output a bytes object as is (perhaps splitting it on multiple line as in issue17530) and then output a hexdamp as a comment. [b'\x7fELF\x01\x01\x01\x00\x00\n' b'\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00\x01' # 7F 45 4C 46 01 01 01 00 00 0A 00 00 00 00 00 00 | .ELF............ # 02 00 03 00 01 | ..... ] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 11:55:28 2013 From: report at bugs.python.org (Daniel Urban) Date: Sat, 04 May 2013 09:55:28 +0000 Subject: [issue16429] Emit SyntaxWarning for code that risks UnboundLocalError In-Reply-To: <1352300366.42.0.384864300614.issue16429@psf.upfronthosting.co.za> Message-ID: <1367661328.75.0.356720277845.issue16429@psf.upfronthosting.co.za> Changes by Daniel Urban : ---------- nosy: +daniel.urban _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 12:12:42 2013 From: report at bugs.python.org (Paul Moore) Date: Sat, 04 May 2013 10:12:42 +0000 Subject: [issue17903] Python launcher for windows should search path for #!/usr/bin/env Message-ID: <1367662362.6.0.575670511803.issue17903@psf.upfronthosting.co.za> New submission from Paul Moore: The Python launcher for windows should recognise a hashbang line of #!/usr/bin/env python, and use the python executable found on PATH to run the script. If no python executable is present on PATH the launcher should fall back to the current behaviour (using the default python, as if #!/usr/bin/python were present). This matches the behaviour on other platforms where env is used to ensure that the script uses the user's currently activated Python, and is particularly important when virtualenvs are being used. ---------- assignee: vinay.sajip components: Windows messages: 188347 nosy: pmoore, vinay.sajip priority: normal severity: normal status: open title: Python launcher for windows should search path for #!/usr/bin/env type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 12:27:44 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 May 2013 10:27:44 +0000 Subject: [issue17868] pprint long non-printable bytes as hexdump In-Reply-To: <1367259569.59.0.63399196745.issue17868@psf.upfronthosting.co.za> Message-ID: <1367663264.81.0.246760369064.issue17868@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is an alternative patch which outputs a bytes literal and a hexdump as a comment. ---------- Added file: http://bugs.python.org/file30121/pprint_bytes_hex_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 12:34:39 2013 From: report at bugs.python.org (Florent Xicluna) Date: Sat, 04 May 2013 10:34:39 +0000 Subject: [issue17904] bytes should be listed as built-in function for 2.7 Message-ID: <1367663679.93.0.0164308850832.issue17904@psf.upfronthosting.co.za> New submission from Florent Xicluna: Looking into the summary table, there's no information about the `bytes` built-in alias for `str`: http://docs.python.org/2/library/functions.html IMHO it should appear in this table (as str, unicode, bytearray) with the appropriate `.. versionadded:`. ---------- assignee: docs at python components: Documentation messages: 188349 nosy: docs at python, flox priority: normal severity: normal status: open title: bytes should be listed as built-in function for 2.7 type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 12:34:40 2013 From: report at bugs.python.org (Ger Luijten) Date: Sat, 04 May 2013 10:34:40 +0000 Subject: [issue5492] Error on leaving IDLE with quit() or exit() under Linux In-Reply-To: <1366423849.57.0.901019237914.issue5492@psf.upfronthosting.co.za> Message-ID: Ger Luijten added the comment: Hello Roger, Thanks for the clear explanation! Greetings, Ger 2013/4/20 Roger Serwy > > Roger Serwy added the comment: > > Good catch Terry! I've been testing using "python -m idlelib.idle" instead > of importing it from an interactive prompt. I'll need to remember to > consider that test vector in the future. > > I figured out why those messages are popping up. The Tk event loop remains > running when in the interactive Python REPL due to a PyOS_InputHook driving > the Tk loop periodically. Some .after callbacks expire and Tcl tries > calling into a Python function that no longer exists. The ColorDelegator's > recolorize() and PyShell's poll_subprocess() are the callbacks. (Adding a > "print(name, func)" to the after() function in Lib/tkinter/__init__.py > revealed the link between the Tcl reference name and the Python reference > name.) > > The extra ColorDelegator call is actually a bug, related to #13495. (I > need to expand it that issue to include this new problem.) Two > ColorDelegators get loaded, and only one gets its close() method called > which properly cancels the .after callback into recolorize. The "orphaned" > ColorDelegator still exists in the delegator chain with an active .after > callback. > > Once both those .after callbacks are canceled, then the error messages > Terry sees are no longer shown. > > The rev1 patch includes extra code to handle cancellation of the > poll_subprocess .after callback. I'll be posting the multi-color delegator > fix to #13495. > > ---------- > dependencies: +IDLE: Regressions - Two ColorDelegator instances loaded and > -e no longer edits new files. > Added file: http://bugs.python.org/file29945/issue5492_rev1.patch > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 12:45:45 2013 From: report at bugs.python.org (Alejandro Rodas) Date: Sat, 04 May 2013 10:45:45 +0000 Subject: [issue3405] Add support for the new data option supported by event generate (Tk 8.5) In-Reply-To: <1216385566.01.0.7972232454.issue3405@psf.upfronthosting.co.za> Message-ID: <1367664345.08.0.810096370708.issue3405@psf.upfronthosting.co.za> Changes by Alejandro Rodas : ---------- nosy: +alex.rodas _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 13:12:07 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 11:12:07 +0000 Subject: [issue17810] Implement PEP 3154 (pickle protocol 4) In-Reply-To: <1367626037.15.0.303797310624.issue17810@psf.upfronthosting.co.za> Message-ID: <1367665923.2570.0.camel@fsol> Antoine Pitrou added the comment: > Antoine, can you share the code for your benchmarks which show > performance improvements when framing is enabled? I am seeing the same > 10-15% slowdown even when pickling stuff to pure Python objects: The performance improvement is when unpickling, not when pickling. Pickling always buffers data, so framing doesn't bring anything on this side of the fence. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 13:17:24 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 11:17:24 +0000 Subject: [issue17868] pprint long non-printable bytes as hexdump In-Reply-To: <1367660578.42.0.494949959363.issue17868@psf.upfronthosting.co.za> Message-ID: <1367666241.2570.4.camel@fsol> Antoine Pitrou added the comment: Le samedi 04 mai 2013 ? 09:42 +0000, Serhiy Storchaka a ?crit : > > However a simple specialized code can be used for special purposes, > i.e. internally in the pprint module. I don't see how it can be reused > and don't interested in a general function. I don't understand how it would be useful in the pprint module if it can't be useful as a general function. The general intent is the same: print something in a "nice" way. Just the nice way is different depending on the situations: if my bytes object is simply a bunch of HTTP headers, I don't want to have a hexdump. > An alternative option is first output a bytes object as is (perhaps > splitting it on multiple line as in issue17530) and then output a > hexdamp as a comment. > > [b'\x7fELF\x01\x01\x01\x00\x00\n' > b'\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00\x01' > # 7F 45 4C 46 01 01 01 00 00 0A 00 00 00 00 00 00 | .ELF............ > # 02 00 03 00 01 | ..... > ] This won't work very nicely in smaller display widths. You'll need too many lines to represent a bytes object. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 13:48:36 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 May 2013 11:48:36 +0000 Subject: [issue17806] Add keyword args support to str/bytes.expandtabs() In-Reply-To: <1366507154.61.0.217389659931.issue17806@psf.upfronthosting.co.za> Message-ID: <1367668116.39.0.916799170272.issue17806@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > FTR the reason to add this is consistency This always was a weak reason. > and readability It is a matter of taste. For me s.expandtabs(3) looks more readable than s.expandtabs(tabsize=3). I don't see an urgent need for this feature and don't like a complication. Let's defer this change until the passing of the keyword arguments will not be significantly optimized. I'm -0 for committing right now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 13:52:59 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 May 2013 11:52:59 +0000 Subject: [issue17868] pprint long non-printable bytes as hexdump In-Reply-To: <1367259569.59.0.63399196745.issue17868@psf.upfronthosting.co.za> Message-ID: <1367668379.42.0.981945572664.issue17868@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file30121/pprint_bytes_hex_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 13:53:23 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 May 2013 11:53:23 +0000 Subject: [issue17868] pprint long non-printable bytes as hexdump In-Reply-To: <1367259569.59.0.63399196745.issue17868@psf.upfronthosting.co.za> Message-ID: <1367668403.18.0.615762581628.issue17868@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file30122/pprint_bytes_hex_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 14:05:21 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 May 2013 12:05:21 +0000 Subject: [issue17868] pprint long non-printable bytes as hexdump In-Reply-To: <1367259569.59.0.63399196745.issue17868@psf.upfronthosting.co.za> Message-ID: <1367669121.42.0.775080731282.issue17868@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > I don't understand how it would be useful in the pprint module if it > can't be useful as a general function. How can it be used besides pprint/pformat functions? > Just the nice way is different > depending on the situations: if my bytes object is simply a bunch of > HTTP headers, I don't want to have a hexdump. Then perhaps a new parameter for pprint/pformat needed (hex=True?). I think printing integers in hexadecimal can sometimes be useful too. > This won't work very nicely in smaller display widths. You'll need too > many lines to represent a bytes object. This is a nature of hexdumps. Every byte requires 4+ characters (or 3+ if group hexdigits tighter). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 14:14:42 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 12:14:42 +0000 Subject: [issue17868] pprint long non-printable bytes as hexdump In-Reply-To: <1367669121.42.0.775080731282.issue17868@psf.upfronthosting.co.za> Message-ID: <1367669680.2570.6.camel@fsol> Antoine Pitrou added the comment: > > I don't understand how it would be useful in the pprint module if it > > can't be useful as a general function. > > How can it be used besides pprint/pformat functions? I don't understand your question. Do you never print some data at the command-line prompt? Or even as part of small test programs? > Then perhaps a new parameter for pprint/pformat needed (hex=True?). I > think printing integers in hexadecimal can sometimes be useful too. Passing type-specific parameters to pprint/pformat sounds like a bad idea to me. And I don't think you'd want to print *all* integers as hex. > > This won't work very nicely in smaller display widths. You'll need too > > many lines to represent a bytes object. > > This is a nature of hexdumps. Every byte requires 4+ characters (or 3+ > if group hexdigits tighter). Which is why the proposal doesn't fit well with pprint/pformat. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 14:16:53 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 May 2013 12:16:53 +0000 Subject: [issue16316] Support xz compression in mimetypes module In-Reply-To: <1351114845.07.0.378323444057.issue16316@psf.upfronthosting.co.za> Message-ID: <3b2q2X3HDNzNgv@mail.python.org> Roundup Robot added the comment: New changeset 26068bfec70e by Serhiy Storchaka in branch '2.7': Issue #16316: mimetypes now recognizes the .xz and .txz (.tar.xz) extensions. http://hg.python.org/cpython/rev/26068bfec70e New changeset d04259af01ff by Serhiy Storchaka in branch '3.3': Issue #16316: mimetypes now recognizes the .xz and .txz (.tar.xz) extensions. http://hg.python.org/cpython/rev/d04259af01ff ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 14:20:21 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 May 2013 12:20:21 +0000 Subject: [issue16316] Support xz compression in mimetypes module In-Reply-To: <1351114845.07.0.378323444057.issue16316@psf.upfronthosting.co.za> Message-ID: <1367670021.78.0.0477209347468.issue16316@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Have backported. ---------- resolution: -> fixed status: open -> closed versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 14:36:20 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 May 2013 12:36:20 +0000 Subject: [issue15809] IDLE console uses incorrect encoding. In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za> Message-ID: <1367670980.46.0.663699083247.issue15809@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If there are no objections I will commit the patch soon. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 14:44:17 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 04 May 2013 12:44:17 +0000 Subject: [issue16945] rewrite CGIHTTPRequestHandler to always use subprocess In-Reply-To: <1358000083.64.0.0773347996342.issue16945@psf.upfronthosting.co.za> Message-ID: <1367671457.8.0.606935302697.issue16945@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: The latest version of the patch passes on Linux, OpenIndiana and Windows. Note that I did apply the select()-hack on all platforms (not only Windows), because if I understood #427345 correctly, it's really there to bypass a non-standard IE behavior (which appends trailing '\r\n'), and doesn't depend on the platform. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 14:46:43 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 04 May 2013 12:46:43 +0000 Subject: [issue17868] pprint long non-printable bytes as hexdump In-Reply-To: <1367259569.59.0.63399196745.issue17868@psf.upfronthosting.co.za> Message-ID: <1367671603.66.0.859403380611.issue17868@psf.upfronthosting.co.za> Ezio Melotti added the comment: The idea is that the output of pprint should be something like (once #17530 is applied): >>> pprint.pprint(b'\x7fELF\x01\x01\x01\x00\x00\n\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00\x01') (b'\x7fELF\x01\x01\x01\x00\x00\n\x00\x00' b'\x00\x00\x00\x00\x02\x00\x03\x00\x01') whereas the output of hexdump can be something like: pprint.hexdump(b'\x7fELF\x01\x01\x01\x00\x00\n\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00\x01') 7F 45 4C 46 01 01 01 00 00 0A 00 00 00 00 00 00 | .ELF............ 02 00 03 00 01 | ..... hexdump() could accept some additional args too if required, but otherwise I don't think the details are so important as long as it produces something readable for a human. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 16:00:06 2013 From: report at bugs.python.org (Antonio Cavallo) Date: Sat, 04 May 2013 14:00:06 +0000 Subject: [issue17819] removes need for CONFIG_SITE external configuration In-Reply-To: <1366676555.13.0.0940928027778.issue17819@psf.upfronthosting.co.za> Message-ID: <1367676006.84.0.0581186462063.issue17819@psf.upfronthosting.co.za> Antonio Cavallo added the comment: So far it seems the special handling in config.site is restricted to these two bits ptc/ptmx (I'm targeting android in cross compiling at the moment). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 16:09:13 2013 From: report at bugs.python.org (Antonio Cavallo) Date: Sat, 04 May 2013 14:09:13 +0000 Subject: [issue17905] Add check for locale.h Message-ID: <1367676553.24.0.0475219885835.issue17905@psf.upfronthosting.co.za> New submission from Antonio Cavallo: This patch adds autoconf.ac check for the locale.h file in addition to langinfo.h. The patch contains also a fix to Python/fileutils.c file. The android ndk provides locale.h but no langinfo.h: this fixes the issue. BTW bionic doesn't have any runtime support for locale at the moment in the standard build at least. ---------- components: Build, Cross-Build files: locale_h_configure.ac.patch keywords: patch messages: 188362 nosy: benjamin.peterson, cavallo71, doko, haypo priority: normal severity: normal status: open title: Add check for locale.h type: enhancement versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file30123/locale_h_configure.ac.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 16:34:14 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 14:34:14 +0000 Subject: [issue17810] Implement PEP 3154 (pickle protocol 4) In-Reply-To: <1366526938.19.0.00976593994103.issue17810@psf.upfronthosting.co.za> Message-ID: <1367678054.64.0.669085985384.issue17810@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here are some numbers: # Without the patch $ ./python -m timeit -s "import pickle, io; d=pickle.dumps(list(range(1000)), 4); b=io.BytesIO(d)" "b.seek(0); pickle.load(b)" 10000 loops, best of 3: 180 usec per loop $ ./python -m timeit -s "import pickle, _pyio as io; d=pickle.dumps(list(range(1000)), 4); b=io.BytesIO(d)" "b.seek(0); pickle.load(b)" 100 loops, best of 3: 4.52 msec per loop # With the patch $ ./python -m timeit -s "import pickle, io; d=pickle.dumps(list(range(1000)), 4); b=io.BytesIO(d)" "b.seek(0); pickle.load(b)" 10000 loops, best of 3: 42.8 usec per loop $ ./python -m timeit -s "import pickle, _pyio as io; d=pickle.dumps(list(range(1000)), 4); b=io.BytesIO(d)" "b.seek(0); pickle.load(b)" 10000 loops, best of 3: 47.3 usec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 16:38:28 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 May 2013 14:38:28 +0000 Subject: [issue17906] Add a string error handler to JSON encoder/decoder Message-ID: <1367678308.48.0.934181281887.issue17906@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Inspired by simplejson issue [1] which is related to standard json module too. JSON parser 3.3+ and wide builds of 3.2- raise an error on invalid strings (i.e. with unpaired surrogate), while narrow builds and some third-party parsers. Wide builds are right, such JSON data is invalid. However it will be good to be optionally more permissive to input data. Otherwise it is not easy process such invalid data. I propose to add an "error" parameter to JSON decoder and encoder with the same meaning as in string decoding/encoding. "strict" is default and "surrogatepass" corresponds to narrow builds (and non-strict third-party parsers). [1] https://github.com/simplejson/simplejson/issues/62 ---------- assignee: serhiy.storchaka components: Extension Modules, Library (Lib), Unicode messages: 188364 nosy: bob.ippolito, ezio.melotti, pitrou, rhettinger, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Add a string error handler to JSON encoder/decoder type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 16:48:05 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 May 2013 14:48:05 +0000 Subject: [issue7855] Add test cases for ctypes/winreg for issues found in IronPython In-Reply-To: <1265311030.9.0.277359551887.issue7855@psf.upfronthosting.co.za> Message-ID: <3b2tP11fmJzR0x@mail.python.org> Roundup Robot added the comment: New changeset 5f82b68c1f28 by Ezio Melotti in branch '3.3': #7855: Add tests for ctypes/winreg for issues found in IronPython. Initial patch by Dino Viehland. http://hg.python.org/cpython/rev/5f82b68c1f28 New changeset df655ebf74d7 by Ezio Melotti in branch 'default': #7855: merge with 3.3. http://hg.python.org/cpython/rev/df655ebf74d7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 16:59:14 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 May 2013 14:59:14 +0000 Subject: [issue7855] Add test cases for ctypes/winreg for issues found in IronPython In-Reply-To: <1265311030.9.0.277359551887.issue7855@psf.upfronthosting.co.za> Message-ID: <3b2tds6T4kz7LjR@mail.python.org> Roundup Robot added the comment: New changeset e71406d8ed5d by Ezio Melotti in branch '2.7': #7855: Add tests for ctypes/winreg for issues found in IronPython. Initial patch by Dino Viehland. http://hg.python.org/cpython/rev/e71406d8ed5d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 17:00:43 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 04 May 2013 15:00:43 +0000 Subject: [issue7855] Add test cases for ctypes/winreg for issues found in IronPython In-Reply-To: <1265311030.9.0.277359551887.issue7855@psf.upfronthosting.co.za> Message-ID: <1367679643.09.0.889681295046.issue7855@psf.upfronthosting.co.za> Ezio Melotti added the comment: This should be fixed now. Thanks for the report and the patch (and thanks Zach for confirming that it works on Windows and for the review)! ---------- assignee: dino.viehland -> ezio.melotti resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 17:07:30 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 May 2013 15:07:30 +0000 Subject: [issue16518] add "buffer protocol" to glossary In-Reply-To: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za> Message-ID: <3b2tqQ1J92z7LjR@mail.python.org> Roundup Robot added the comment: New changeset 003e4eb92683 by Ezio Melotti in branch '3.3': #16518: use "bytes-like object" throughout the docs. http://hg.python.org/cpython/rev/003e4eb92683 New changeset d4912244cce6 by Ezio Melotti in branch 'default': #16518: merge with 3.3. http://hg.python.org/cpython/rev/d4912244cce6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 17:27:32 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 04 May 2013 15:27:32 +0000 Subject: [issue16518] add "buffer protocol" to glossary In-Reply-To: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za> Message-ID: <1367681252.43.0.686278131794.issue16518@psf.upfronthosting.co.za> Ezio Melotti added the comment: The attached patch uses "bytes-like objects" in the error messages. ---------- Added file: http://bugs.python.org/file30124/issue16518-3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 17:31:02 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 15:31:02 +0000 Subject: [issue17904] bytes should be listed as built-in function for 2.7 In-Reply-To: <1367663679.93.0.0164308850832.issue17904@psf.upfronthosting.co.za> Message-ID: <1367681462.23.0.252526807.issue17904@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 17:32:37 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 04 May 2013 15:32:37 +0000 Subject: [issue17859] improve error message for saving ints to file In-Reply-To: <1367134676.21.0.161863892006.issue17859@psf.upfronthosting.co.za> Message-ID: <1367681557.33.0.62090884273.issue17859@psf.upfronthosting.co.za> Ezio Melotti added the comment: > binary-mode write requires bytes-like object, not 'int' Looks like the function that raises the error (Objects/abstract.c:352) doesn't have enough information to produce a message like that. I attached a patch to #16518 that improves this and other error messages (this particular error is replaced by "a bytes-like object is required, not 'int'"). ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 17:40:08 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 15:40:08 +0000 Subject: [issue17901] _elementtree.TreeBuilder raises IndexError on end if constructed with element_factory=None In-Reply-To: <1367611016.77.0.197383711231.issue17901@psf.upfronthosting.co.za> Message-ID: <1367682008.65.0.479857679007.issue17901@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +eli.bendersky stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 17:41:30 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 May 2013 15:41:30 +0000 Subject: [issue17868] pprint long non-printable bytes as hexdump In-Reply-To: <1367259569.59.0.63399196745.issue17868@psf.upfronthosting.co.za> Message-ID: <1367682090.3.0.887583855769.issue17868@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > I don't understand your question. Do you never print some data at the > command-line prompt? Or even as part of small test programs? To be honest, I very rarely even use pprint. I'm too lazy to import it. If I want to quickly get a hexdump, I use something like `' '.join('%02X'%i for i in data)`. It is shorter than `import pprint; pprint.hexdump(data)`. For a small program most likely the standard hexdump() will not be enough. > Passing type-specific parameters to pprint/pformat sounds like a bad > idea to me. Agree. Of course it would be better to automatically determine a "nice" display (use hexdump only for large non-printable bytes). > And I don't think you'd want to print *all* integers as hex. If you want to print bytes in hex, why not ints and floats? ;) In fact I don't want to print data as hex, so shut up. > Which is why the proposal doesn't fit well with pprint/pformat. Perhaps I misunderstood your wish. I'm not against consider pprint as a black box, which does all good magic inside by default. The use of this feature does not require anything from the users and does not impose obligations on the maintainers. But I'm not interested in a separate function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 17:46:40 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 15:46:40 +0000 Subject: [issue17868] pprint long non-printable bytes as hexdump In-Reply-To: <1367682090.3.0.887583855769.issue17868@psf.upfronthosting.co.za> Message-ID: <1367682397.2570.7.camel@fsol> Antoine Pitrou added the comment: Le samedi 04 mai 2013 ? 15:41 +0000, Serhiy Storchaka a ?crit : > > Which is why the proposal doesn't fit well with pprint/pformat. > > Perhaps I misunderstood your wish. I'm not against consider pprint as > a black box, which does all good magic inside by default. The use of > this feature does not require anything from the users and does not > impose obligations on the maintainers. But I'm not interested in a > separate function. The problem is the "good magic" will depend on the situation. Really, I don't want a hexdump of a HTTP message :-) Which is why there should be a separate function for those *wishing* a hexdump. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 17:51:33 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 04 May 2013 15:51:33 +0000 Subject: [issue1298835] Add a vendor-packages directory for system-supplied modules Message-ID: <1367682693.78.0.715530087155.issue1298835@psf.upfronthosting.co.za> ?ric Araujo added the comment: Adding Nick to this discussion, since distutils-sig is talking about these issues right now. Previous discussions: http://mail.python.org/pipermail/python-list/2005-September/345116.html http://mail.python.org/pipermail/python-dev/2005-September/056682.html http://mail.python.org/pipermail/python-dev/2003-August/037487.html Barry: if you could summarize how and why doko introduced dist-packages in Debian, or let me copy parts of email we exchanged a couple years ago, I think it could help. Nick seems inclined to standardize doko?s solution, but IIRC it was an imperfect but working compromise, so we might want to rethink it. ---------- assignee: tarek -> nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 17:51:57 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sat, 04 May 2013 15:51:57 +0000 Subject: [issue1298835] Add a vendor-packages directory for system-supplied modules Message-ID: <1367682717.61.0.283652552157.issue1298835@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- components: +Interpreter Core -Distutils2, Library (Lib) versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 17:59:32 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 15:59:32 +0000 Subject: [issue17906] Add a string error handler to JSON encoder/decoder In-Reply-To: <1367678308.48.0.934181281887.issue17906@psf.upfronthosting.co.za> Message-ID: <1367683172.02.0.258713299528.issue17906@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I wonder if json should simply be less strict by default. If you pass the raw unescaped character, the json module accepts it: >>> json.loads('{"a": "\ud8e9"}') {'a': '\ud8e9'} It's only if you pass the escaped representation that json rejects it: >>> json.loads('{"a": "\\ud8e9"}') Traceback (most recent call last): File "", line 1, in File "/home/antoine/cpython/default/Lib/json/__init__.py", line 316, in loads return _default_decoder.decode(s) File "/home/antoine/cpython/default/Lib/json/decoder.py", line 344, in decode obj, end = self.raw_decode(s, idx=_w(s, 0).end()) File "/home/antoine/cpython/default/Lib/json/decoder.py", line 360, in raw_decode obj, end = self.scan_once(s, idx) ValueError: Unpaired high surrogate: line 1 column 9 (char 8) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 18:01:18 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 04 May 2013 16:01:18 +0000 Subject: [issue17906] Add a string error handler to JSON encoder/decoder In-Reply-To: <1367678308.48.0.934181281887.issue17906@psf.upfronthosting.co.za> Message-ID: <1367683278.29.0.307688949168.issue17906@psf.upfronthosting.co.za> Ezio Melotti added the comment: See also #11489. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 18:44:11 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 04 May 2013 16:44:11 +0000 Subject: [issue17854] symmetric difference operation applicable to more than two sets In-Reply-To: <1367063240.22.0.643670001227.issue17854@psf.upfronthosting.co.za> Message-ID: <1367685851.48.0.485740949465.issue17854@psf.upfronthosting.co.za> Ezio Melotti added the comment: > Return a new set with elements in an odd number of the sets. This wording is not really clear to me. IMHO the documentation is fine as is. The evaluation order works as usual, and, since the symmetric difference is an associative (and commutative) operation, the order doesn't even matter. ---------- nosy: +ezio.melotti type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 18:52:52 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 04 May 2013 16:52:52 +0000 Subject: [issue1298835] Add a vendor-packages directory for system-supplied modules Message-ID: <1367686372.96.0.851956304612.issue1298835@psf.upfronthosting.co.za> Nick Coghlan added the comment: The discussion on distutils-sig that ?ric is referring to is one were I ended up pointing out that PEP 439 (bootstrapping pip in 3.4) needs to address this in some manner, so that pip (which installs to site-packages) doesn't end up fighting with system package managers that are also installing to site-packages in many cases. Since the distro vendors are in a better situation to change their target installation directory, the consensus on the list was that something *like* the current Debian solution is most appropriate (I wasn't aware this issue existed at the time). The current situation is annoying-but-tolerable with pip as a third party solution, but unacceptable once the command is being provided by Python itself. As with virtual environments, something with upstream support may be able to be cleaner than a third party workaround. Relevant distutils-sig post:http://mail.python.org/pipermail/distutils-sig/2013-May/020673.html (ignore the initial quoted part - I was just flat out wrong earlier in that thread) ---------- nosy: +richard _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 19:15:40 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 04 May 2013 17:15:40 +0000 Subject: [issue17862] itertools.chunks(iterable, size, fill=None) In-Reply-To: <1367165590.04.0.46648726654.issue17862@psf.upfronthosting.co.za> Message-ID: <1367687740.68.0.302432676092.issue17862@psf.upfronthosting.co.za> Ezio Melotti added the comment: FWIW I'm +1 about adding grouper(), since it happened to me to use it and suggest more often than any other recipe (I think it's the only recipe I used/know), and even more often than some of the current itertools. The fact that has been requested several times already it's a good indication that it's something useful, and not a feature creep (I don't think any other recipe received nearly as many requests). Regarding use cases, a few days ago I needed it while shuffling a sequence of 20 chars and then split it in four 5-chars long groups. I also remember writing code like this more than once: >>> s = 'aaaaabbbbbcccccddddd' >>> n = 5 >>> [s[x:x+n] for x in range(0,len(s),n)] ['aaaaa', 'bbbbb', 'ccccc', 'ddddd'] (As a side note, I find the grouper(iterable, n, fill) signature more intuitive than grouper(n, iterable, fill) (the recipe uses the latter).) ---------- assignee: rhettinger -> nosy: +ezio.melotti stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 19:16:06 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 04 May 2013 17:16:06 +0000 Subject: [issue17862] itertools.chunks(iterable, size, fill=None) In-Reply-To: <1367165590.04.0.46648726654.issue17862@psf.upfronthosting.co.za> Message-ID: <1367687766.43.0.462392073447.issue17862@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 19:16:50 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 04 May 2013 17:16:50 +0000 Subject: [issue17877] Skip test_variable_tzname when the zoneinfo database is missing In-Reply-To: <1367312853.26.0.203809750785.issue17877@psf.upfronthosting.co.za> Message-ID: <1367687810.81.0.242028132047.issue17877@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- assignee: -> ezio.melotti stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 19:19:48 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 04 May 2013 17:19:48 +0000 Subject: [issue17887] docs: summary page - generator vs iterator vs iterable In-Reply-To: <1367390087.97.0.0883934646573.issue17887@psf.upfronthosting.co.za> Message-ID: <1367687988.89.0.262620941533.issue17887@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti type: -> enhancement versions: +Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 19:44:44 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sat, 04 May 2013 17:44:44 +0000 Subject: [issue17890] argparse: mutually exclusive groups full of suppressed args can cause AssertionErrors In-Reply-To: <1367455382.45.0.0611766927148.issue17890@psf.upfronthosting.co.za> Message-ID: <1367689484.8.0.615240465975.issue17890@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: I am not sure if I am missing something. I had filled out the form at http://www.python.org/psf/contrib/contrib-form/ on the day I submitted the patch and even got back an email from Ewa Jodlowska. However, I don't see any "*" after my name. I submitted the same form to contributors at python.org and shot a mail to python-dev mailing list but there is no change. Any suggestions? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 19:53:11 2013 From: report at bugs.python.org (Matthias Klose) Date: Sat, 04 May 2013 17:53:11 +0000 Subject: [issue1298835] Add a vendor-packages directory for system-supplied modules Message-ID: <1367689991.4.0.723945511343.issue1298835@psf.upfronthosting.co.za> Matthias Klose added the comment: there is more than one thing addressed with the 'dist-packages' choice of name. The primary reason is to have a directory where you only find python packages as distributed by the linux distribution, and where installers do not install to by default. Even if this directory is non-writable, people did call 'sudo python setup.py install', and then did report issues on the Ubuntu tracker caused by these installs. Such a vendor place should never be the default to be installed to by default. There is a Debian policy to support /usr/local, and that's the reason you find a second directory /usr/local/lib/pythonx.y/dist-packages. A 'sudo python setup.py install' installs into this location, distribution maintainers providing Debian packages are supposed to call setup.py install --install-layout=deb to install into the debian system installation. At this time Barry still new to distro policies, was surprised to find /usr/local/lib/pythonx.y/site-packages being used by the system python, which is also used by a local python build which is configured without any --prefix parameters. So the system python now uses dist-packages in both /usr and /usr/local to not interfere with a local python installation. Note that for python3, Debian and Ubuntu are trying to share dist-packages across python3 versions to ease upgrades from one version to the other, and trying to support more than one version during the upgrade (calling that /usr/lib/python3/dist-packages). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 19:57:09 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 May 2013 17:57:09 +0000 Subject: [issue17115] __loader__ = None should be fine In-Reply-To: <1359910046.95.0.667824237181.issue17115@psf.upfronthosting.co.za> Message-ID: <3b2yb83yT6z7LjR@mail.python.org> Roundup Robot added the comment: New changeset e39a8f8ceb9f by Brett Cannon in branch 'default': #17115,17116: Have modules initialize the __package__ and __loader__ http://hg.python.org/cpython/rev/e39a8f8ceb9f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 19:58:11 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 04 May 2013 17:58:11 +0000 Subject: [issue17115] __loader__ = None should be fine In-Reply-To: <1359910046.95.0.667824237181.issue17115@psf.upfronthosting.co.za> Message-ID: <1367690291.99.0.368360614386.issue17115@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 19:58:17 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 04 May 2013 17:58:17 +0000 Subject: [issue17116] xml.parsers.expat.(errors|model) don't set the __loader__ attribute In-Reply-To: <1359910057.05.0.356511738926.issue17116@psf.upfronthosting.co.za> Message-ID: <1367690297.3.0.0796020519369.issue17116@psf.upfronthosting.co.za> Brett Cannon added the comment: New changeset e39a8f8ceb9f by Brett Cannon in branch 'default': #17115,17116: Have modules initialize the __package__ and __loader__ http://hg.python.org/cpython/rev/e39a8f8ceb9f ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 20:05:17 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 04 May 2013 18:05:17 +0000 Subject: [issue17894] Edits to descriptor howto In-Reply-To: <1367547112.04.0.920947702161.issue17894@psf.upfronthosting.co.za> Message-ID: <1367690717.21.0.735055542985.issue17894@psf.upfronthosting.co.za> Ezio Melotti added the comment: Attached a patch that rephrases part of the suggestions made by Ned. ---------- nosy: +ezio.melotti Added file: http://bugs.python.org/file30125/issue17894.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 20:08:43 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 May 2013 18:08:43 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <3b2yrV6pK7zRlj@mail.python.org> Roundup Robot added the comment: New changeset d5ef330bac50 by Antoine Pitrou in branch 'default': Issue #5845: Enable tab-completion in the interactive interpreter by default, thanks to a new sys.__interactivehook__. http://hg.python.org/cpython/rev/d5ef330bac50 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 20:11:40 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 18:11:40 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1367691100.5.0.0629992617795.issue5845@psf.upfronthosting.co.za> Antoine Pitrou added the comment: End-users will hopefully rejoice :) ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 20:23:44 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 04 May 2013 18:23:44 +0000 Subject: [issue17177] Document/deprecate imp In-Reply-To: <1360526911.57.0.856873084515.issue17177@psf.upfronthosting.co.za> Message-ID: <1367691824.88.0.473156195266.issue17177@psf.upfronthosting.co.za> Brett Cannon added the comment: Just to keep on top of what is left to do for this to happen: * get_magic(): expose in importlib * find_module()/load_module(): eliminate all uses in the stdlib and fully deprecate * new_module(): use types.ModuleType() instead * reload(): relocate * cache_from_source(): relocate * source_from_cache(): relocate * get_tag(): deprecate * lock_held()/acquire_lock()/release_lock(): deprecate * NullImporter: deprecate Everything else can stay undocumented as-is (deprecated or simply exposed through _imp which can stay undocumented). I plan to make individual issues for these things as I solidify the decision of how to handle them. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 20:25:08 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 04 May 2013 18:25:08 +0000 Subject: [issue17907] Deprecate imp.new_module() in favour of types.ModuleType Message-ID: <1367691908.58.0.339991159831.issue17907@psf.upfronthosting.co.za> New submission from Brett Cannon: imp.new_module() does not need to exist since code can use types.ModuleType's constructor. ---------- components: Library (Lib) keywords: easy messages: 188388 nosy: brett.cannon priority: low severity: normal stage: test needed status: open title: Deprecate imp.new_module() in favour of types.ModuleType versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 20:25:28 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 04 May 2013 18:25:28 +0000 Subject: [issue17177] Document/deprecate imp In-Reply-To: <1360526911.57.0.856873084515.issue17177@psf.upfronthosting.co.za> Message-ID: <1367691928.45.0.145014655392.issue17177@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- dependencies: +Deprecate imp.new_module() in favour of types.ModuleType _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 20:37:36 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 04 May 2013 18:37:36 +0000 Subject: [issue17115] __loader__ = None should be fine In-Reply-To: <1359910046.95.0.667824237181.issue17115@psf.upfronthosting.co.za> Message-ID: <1367692656.99.0.399378661104.issue17115@psf.upfronthosting.co.za> Ezio Melotti added the comment: Some buildbots are failing after this: http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.x/builds/7840 http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.0%203.x/builds/4536 FAIL: test_everyone_has___loader__ (test.test_importlib.test_api.StartupTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/srv/buildbot/buildarea/3.x.bolen-ubuntu/build/Lib/test/test_importlib/test_api.py", line 201, in test_everyone_has___loader__ '{!r} lacks a __loader__ attribute'.format(name)) AssertionError: False is not true : 'test.pydoc_mod' lacks a __loader__ attribute ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 20:38:33 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 04 May 2013 18:38:33 +0000 Subject: [issue17177] Document/deprecate imp In-Reply-To: <1360526911.57.0.856873084515.issue17177@psf.upfronthosting.co.za> Message-ID: <1367692713.21.0.483447162921.issue17177@psf.upfronthosting.co.za> Brett Cannon added the comment: While thinking about asking on G+ for feedback, I realized that if I get this to the point of a module-level warning, it won't be a big deal. It would be just like warnings you deal with when supporting old versions of Python along with newer versions where things are now deprecated. That way users of imp could just do:: with warnings.catch_warnings(): warnings.simplefilter("ignore") import imp and be done with it. This means still striving to deprecate every function in imp so that it can all be replaced with a single module-level deprecation is a reasonable goal to have. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 20:43:34 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 04 May 2013 18:43:34 +0000 Subject: [issue17177] Document/deprecate imp In-Reply-To: <1360526911.57.0.856873084515.issue17177@psf.upfronthosting.co.za> Message-ID: <1367693014.4.0.0728849471604.issue17177@psf.upfronthosting.co.za> Ezio Melotti added the comment: This might be OK, however you won't be able to point to the alternatives in the deprecation message (e.g. "new_module() is deprecated, use types.ModuleType() instead"). This can still be done in the docs though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 20:46:23 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 04 May 2013 18:46:23 +0000 Subject: [issue17177] Document/deprecate imp In-Reply-To: <1360526911.57.0.856873084515.issue17177@psf.upfronthosting.co.za> Message-ID: <1367693183.47.0.768019828729.issue17177@psf.upfronthosting.co.za> Brett Cannon added the comment: Right, the docs would say "the imp modules is deprecated; please see the module documentation for alternatives" or something. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 20:46:34 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 May 2013 18:46:34 +0000 Subject: [issue17408] second python execution fails when embedding In-Reply-To: <1363183794.27.0.643296851621.issue17408@psf.upfronthosting.co.za> Message-ID: <3b2zh92m2pz7Lk8@mail.python.org> Roundup Robot added the comment: New changeset 8c1385205a35 by Antoine Pitrou in branch '3.3': Issue #17408: Avoid using an obsolete instance of the copyreg module when the interpreter is shutdown and then started again. http://hg.python.org/cpython/rev/8c1385205a35 New changeset 0b34fd75b937 by Antoine Pitrou in branch 'default': Issue #17408: Avoid using an obsolete instance of the copyreg module when the interpreter is shutdown and then started again. http://hg.python.org/cpython/rev/0b34fd75b937 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 20:46:51 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 04 May 2013 18:46:51 +0000 Subject: [issue17882] test_objecttypes fails for 3.2.4 on CentOS 6 In-Reply-To: <1367340943.59.0.839415774822.issue17882@psf.upfronthosting.co.za> Message-ID: <1367693211.34.0.220780950022.issue17882@psf.upfronthosting.co.za> Ezio Melotti added the comment: 3.2 only gets security fixes, can you try with 3.3/default and see if it fails there? (The devguide has instructions about getting an updated clone and testing on 3.3/default if you need them.) ---------- nosy: +benjamin.peterson, ezio.melotti, loewis type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 20:47:28 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 18:47:28 +0000 Subject: [issue17408] second python execution fails when embedding In-Reply-To: <1363183794.27.0.643296851621.issue17408@psf.upfronthosting.co.za> Message-ID: <1367693248.45.0.911986689544.issue17408@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thank you for reporting! This should be fixed now. ---------- components: +Interpreter Core -None nosy: +pitrou resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 20:48:21 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 04 May 2013 18:48:21 +0000 Subject: [issue17115] __loader__ = None should be fine In-Reply-To: <1359910046.95.0.667824237181.issue17115@psf.upfronthosting.co.za> Message-ID: <1367693301.84.0.616365663058.issue17115@psf.upfronthosting.co.za> Brett Cannon added the comment: It's because test_pydoc is actively deleting the __loader__ of a test module. I'll have a look to figure out why it's doing that. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 20:51:49 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 18:51:49 +0000 Subject: [issue16742] PyOS_Readline drops GIL and calls PyOS_StdioReadline, which isn't thread safe In-Reply-To: <1356086390.48.0.327620937355.issue16742@psf.upfronthosting.co.za> Message-ID: <1367693509.52.0.504269266066.issue16742@psf.upfronthosting.co.za> Antoine Pitrou added the comment: So, could you propose a patch? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 20:54:44 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 18:54:44 +0000 Subject: [issue10363] Embedded python, handle (memory) leak In-Reply-To: <1289237931.86.0.626938349639.issue10363@psf.upfronthosting.co.za> Message-ID: <1367693684.08.0.596044319278.issue10363@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Closing as the original issue is fixed. Other leaks should be reported as separate issues. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 21:25:41 2013 From: report at bugs.python.org (Roger Serwy) Date: Sat, 04 May 2013 19:25:41 +0000 Subject: [issue15809] IDLE console uses incorrect encoding. In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za> Message-ID: <1367695541.9.0.794659452266.issue15809@psf.upfronthosting.co.za> Roger Serwy added the comment: There is a problem. Adding the encoding comment to the top of the source causes off-by-one line errors in the traceback. Take as an example: >>> 1/0 Traceback (most recent call last): File "", line 2, in ZeroDivisionError: integer division or modulo by zero >>> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 21:45:33 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 19:45:33 +0000 Subject: [issue1545463] New-style classes fail to cleanup attributes Message-ID: <1367696733.94.0.809403225597.issue1545463@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch adding a call to gc.collect() after cleaning up most modules, with tests. ---------- keywords: +patch nosy: +ncoghlan stage: commit review -> patch review type: resource usage -> enhancement versions: +Python 3.4 -Python 3.2 Added file: http://bugs.python.org/file30126/gcshutdown.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 21:58:19 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 19:58:19 +0000 Subject: [issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx In-Reply-To: <1205084332.03.0.568369699233.issue2262@psf.upfronthosting.co.za> Message-ID: <1367697499.56.0.123246907734.issue2262@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This avenue doesn't look promising at all. Closing. ---------- resolution: -> works for me stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 22:03:05 2013 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 04 May 2013 20:03:05 +0000 Subject: [issue17806] Add keyword args support to str/bytes.expandtabs() In-Reply-To: <1366507154.61.0.217389659931.issue17806@psf.upfronthosting.co.za> Message-ID: <1367697785.42.0.0595308299537.issue17806@psf.upfronthosting.co.za> Mark Dickinson added the comment: > For me s.expandtabs(3) looks more readable than s.expandtabs(tabsize=3). I disagree: I think the second is more readable, and I think it's especially helpful to those not intimately familiar with the language (which probably accounts for the vast majority of Python users) to see code like "s.expandtabs(tabsize=3)", or "int(43, base=8)", or "s.splitlines(keepends=True)": such code is instantly understandable, whereas someone seeing "s.splitlines(True)" likely has to stop and wonder what the "True" is doing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 22:05:04 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 20:05:04 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1299320278.86.0.403600489598.issue11406@psf.upfronthosting.co.za> Message-ID: <1367697904.17.0.109599713543.issue11406@psf.upfronthosting.co.za> Antoine Pitrou added the comment: +1 for iterdir. However, if we get a separate scandir() returning entries with attributes, is iterdir() still useful? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 22:23:50 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 20:23:50 +0000 Subject: [issue16518] add "buffer protocol" to glossary In-Reply-To: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za> Message-ID: <1367699030.69.0.204632742027.issue16518@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > The attached patch uses "bytes-like objects" in the error messages. I'm surprised your patch doesn't touch Python/getargs.c. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 22:26:47 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 20:26:47 +0000 Subject: [issue16445] SEGFAULT when deleting Exception.message In-Reply-To: <1352415910.77.0.640632287013.issue16445@psf.upfronthosting.co.za> Message-ID: <1367699207.32.0.470222618479.issue16445@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This looks like it is fixed by Mark's commit. Other proposals should go into separate issues. ---------- nosy: +pitrou resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 22:31:38 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 20:31:38 +0000 Subject: [issue17705] Fill Character cannot be \0 In-Reply-To: <1365785695.21.0.22745237494.issue17705@psf.upfronthosting.co.za> Message-ID: <1367699498.16.0.87876447893.issue17705@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 22:48:23 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 04 May 2013 20:48:23 +0000 Subject: [issue16518] add "buffer protocol" to glossary In-Reply-To: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za> Message-ID: <1367700503.42.0.139025601562.issue16518@psf.upfronthosting.co.za> Ezio Melotti added the comment: FWIW I was grepping for buffer protocol/interface/api, and then double-checking for "buffer" in the resulting files. Python/getargs.c doesn't seem to mention the buffer protocol/interface/api at all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 23:21:20 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 May 2013 21:21:20 +0000 Subject: [issue14173] PyOS_FiniInterupts leaves signal.getsignal segfaulty In-Reply-To: <1330684893.81.0.620988158976.issue14173@psf.upfronthosting.co.za> Message-ID: <3b336m1yY2zP7r@mail.python.org> Roundup Robot added the comment: New changeset 0201d8fa8bd0 by Antoine Pitrou in branch '2.7': Issue #14173: Avoid crashing when reading a signal handler during interpreter shutdown. http://hg.python.org/cpython/rev/0201d8fa8bd0 New changeset 0dfd5c7d953d by Antoine Pitrou in branch '3.3': Issue #14173: Avoid crashing when reading a signal handler during interpreter shutdown. http://hg.python.org/cpython/rev/0dfd5c7d953d New changeset 753bcce45854 by Antoine Pitrou in branch 'default': Issue #14173: Avoid crashing when reading a signal handler during interpreter shutdown. http://hg.python.org/cpython/rev/753bcce45854 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 23:22:15 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 21:22:15 +0000 Subject: [issue14173] PyOS_FiniInterupts leaves signal.getsignal segfaulty In-Reply-To: <1330684893.81.0.620988158976.issue14173@psf.upfronthosting.co.za> Message-ID: <1367702535.1.0.786117884865.issue14173@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This should be fixed now. Thank you for diagnosing this bug! ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 23:26:00 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 21:26:00 +0000 Subject: [issue6178] Core error in Py_EvalFrameEx 2.6.2 In-Reply-To: <1243956972.97.0.133216910206.issue6178@psf.upfronthosting.co.za> Message-ID: <1367702760.3.0.274121677329.issue6178@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > As an update (since someone else has this problem) this issue stopped > once we converted from centos to archlinux (www.archlinux.org). May be > an underlying issue with something in the centos environment. We used > the same modules same configuration basically same compilation for > python. Ok, let's close this issue then. ---------- resolution: -> works for me stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 23:29:43 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 May 2013 21:29:43 +0000 Subject: [issue17115] __loader__ = None should be fine In-Reply-To: <1359910046.95.0.667824237181.issue17115@psf.upfronthosting.co.za> Message-ID: <3b33JR06knzPVK@mail.python.org> Roundup Robot added the comment: New changeset bb023c3426bc by Brett Cannon in branch 'default': #17115: Remove what appears to be a useless chunk of code which broke http://hg.python.org/cpython/rev/bb023c3426bc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 23:30:05 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 04 May 2013 21:30:05 +0000 Subject: [issue17115] __loader__ = None should be fine In-Reply-To: <1359910046.95.0.667824237181.issue17115@psf.upfronthosting.co.za> Message-ID: <1367703005.62.0.807316851006.issue17115@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 23:37:17 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 May 2013 21:37:17 +0000 Subject: [issue17115] __loader__ = None should be fine In-Reply-To: <1359910046.95.0.667824237181.issue17115@psf.upfronthosting.co.za> Message-ID: <3b33T84MQVzPln@mail.python.org> Roundup Robot added the comment: New changeset 97b7bd87c44c by Brett Cannon in branch 'default': #17115: I hate you MS for not supporting C99. http://hg.python.org/cpython/rev/97b7bd87c44c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 4 23:52:51 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 21:52:51 +0000 Subject: [issue17289] readline.set_completer_delims() doesn't play well with others In-Reply-To: <1361727162.6.0.330340271384.issue17289@psf.upfronthosting.co.za> Message-ID: <1367704371.15.0.629432459177.issue17289@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for reporting this. Do you want to contribute a proper patch? You'll find instructions at http://docs.python.org/devguide/ ---------- nosy: +pitrou stage: -> needs patch versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 00:00:48 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 04 May 2013 22:00:48 +0000 Subject: [issue17890] argparse: mutually exclusive groups full of suppressed args can cause AssertionErrors In-Reply-To: <1367455382.45.0.0611766927148.issue17890@psf.upfronthosting.co.za> Message-ID: <1367704848.25.0.236925677218.issue17890@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Wait a week and see what happens. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 00:12:38 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 22:12:38 +0000 Subject: [issue17855] Implement introspection of logger hierarchy In-Reply-To: <1367066938.7.0.169657399656.issue17855@psf.upfronthosting.co.za> Message-ID: <1367705557.99.0.891455395203.issue17855@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Perhaps you should explain what the point of this is. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 00:12:48 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 04 May 2013 22:12:48 +0000 Subject: [issue17854] symmetric difference operation applicable to more than two sets In-Reply-To: <1367063240.22.0.643670001227.issue17854@psf.upfronthosting.co.za> Message-ID: <1367705568.49.0.496832692578.issue17854@psf.upfronthosting.co.za> Terry J. Reedy added the comment: If you take the union/intersection/symmetric difference of n sets, the result is a set with all items that appears in one/all/an odd number of the n sets. The union and intersection methods actually accept n inputs, because the result is obvious, useful, and can be obtained faster that with n-1 binary operations. The symmetric_difference method does not, I presume because the result in not obvious (but that cuts both ways), not known to be useful, and perhaps would not be much faster than than n-1 binary operations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 00:20:29 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 May 2013 22:20:29 +0000 Subject: [issue11698] Improve repr for structseq objects to show named, but unindexed fields In-Reply-To: <1301264097.04.0.982421975108.issue11698@psf.upfronthosting.co.za> Message-ID: <1367706029.33.0.0924425855807.issue11698@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the patch. (Yes, I'm looking at this a bit late :-)) First, there seems to be a problem with the repr() of of.stat() results: ./python -c "import os; print(os.stat('LICENSE'))" posix.stat_result(st_mode=33204, st_ino=6553619, st_dev=2053, st_nlink=1, st_uid=1000, st_gid=1000, st_size=15089, st_atime=1367693898, st_mtime=1365264866, st_ctime=1366481591, st_atime=1367693898.528636, st_mtime=1365264866.4163036, st_ctime=1366481591.9862735, st_atime_ns=1367693898528635928, st_mtime_ns=1365264866416303676, st_ctime_ns=1366481591986273627, st_blksize=4096, st_blocks=32, st_rdev=0) As you see, fields such as "st_atime" are duplicated. There are other issues with the patch: * C variable declarations should always be at the beginning of blocks (otherwise it's not C89-compliant) * C++-style comments (//) are forbidden * I don't understand in which circumstances `Py_TYPE(obj)->tp_members[i-n_unnamed_fields].name` can be NULL ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 00:49:25 2013 From: report at bugs.python.org (Phillip J. Eby) Date: Sat, 04 May 2013 22:49:25 +0000 Subject: [issue17636] Modify IMPORT_FROM to fallback on sys.modules In-Reply-To: <1367605445.89.0.775517272704.issue17636@psf.upfronthosting.co.za> Message-ID: Phillip J. Eby added the comment: It looks like maybe basic2 should be importing basic, not basic2. Otherwise, you might as well just import basic2 directly and be done with it. ;-) Likewise, I think indirect should be importing from indirect2, not from itself? i.e., I'd expect that test to fail even with the change. In addition, even if that is fixed, it's still not testing a cycle involving util; it's really just testing the same thing as "basic" is supposed to be testing. It also looks as though like the rebinding test doesn't actually test any rebinding, since nobody ever imports the thing that's rebound. It's failing for the same reason as the subpackage test. The subpackage test looks like a valid test, though - i.e., it's the "basic" case correctly implemented as a parent-child cycle. It's actually the only one of the tests that tests what it says it does. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 01:33:23 2013 From: report at bugs.python.org (Ned Batchelder) Date: Sat, 04 May 2013 23:33:23 +0000 Subject: [issue17894] Edits to descriptor howto In-Reply-To: <1367547112.04.0.920947702161.issue17894@psf.upfronthosting.co.za> Message-ID: <1367710403.72.0.666342475334.issue17894@psf.upfronthosting.co.za> Ned Batchelder added the comment: I worked with Ezio to make a new patch with the full edits. I have other ideas for edits to the rest of the document, but we can discuss those if you like these... ---------- Added file: http://bugs.python.org/file30127/descriptor_howto_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 01:49:16 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 04 May 2013 23:49:16 +0000 Subject: [issue17907] Deprecate imp.new_module() in favour of types.ModuleType In-Reply-To: <1367691908.58.0.339991159831.issue17907@psf.upfronthosting.co.za> Message-ID: <1367711356.79.0.300884752583.issue17907@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 01:49:29 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 04 May 2013 23:49:29 +0000 Subject: [issue17177] Document/deprecate imp In-Reply-To: <1360526911.57.0.856873084515.issue17177@psf.upfronthosting.co.za> Message-ID: <1367711369.04.0.867373306947.issue17177@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 03:20:25 2013 From: report at bugs.python.org (R. David Murray) Date: Sun, 05 May 2013 01:20:25 +0000 Subject: [issue17855] Implement introspection of logger hierarchy In-Reply-To: <1367066938.7.0.169657399656.issue17855@psf.upfronthosting.co.za> Message-ID: <1367716825.28.0.296998485934.issue17855@psf.upfronthosting.co.za> R. David Murray added the comment: I think that's what the link in the first message does. However, as I remember Bradon's talk, the short answer is: make it easy to discover (and therefore reason about) the hierarchy of logging objects that results from all the logging setup calls in an application. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 04:20:44 2013 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 05 May 2013 02:20:44 +0000 Subject: [issue17908] Unittest runner needs an option to call gc.collect() after each test Message-ID: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za> New submission from Guido van Rossum: It would be nice if there was a command-line option to tell the test runner to call gc.collect() after each test. See https://groups.google.com/d/msg/python-tulip/tstjvOQowIU/IRihc8NCHZUJ -- Glyph points out that always doing this is problematic because it slows down tests too much; OTOH it's a useful option to have in case you're tracking down something that happens (or doesn't happen) when an object is collected (e.g. in __del__). ---------- components: Library (Lib) keywords: easy messages: 188420 nosy: gvanrossum priority: normal severity: normal status: open title: Unittest runner needs an option to call gc.collect() after each test type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 04:25:29 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 05 May 2013 02:25:29 +0000 Subject: [issue17894] Edits to descriptor howto In-Reply-To: <1367547112.04.0.920947702161.issue17894@psf.upfronthosting.co.za> Message-ID: <1367720729.62.0.907608566142.issue17894@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Please don't go crazy with this. I will look at the suggestions and make some edits to improve its readability but am not going to change it into a breezy conversational style. Instead, I'll likely put together a separate descriptor tutorial that presents an easier on-ramp (in contrast to an authoritative document closely tied to the actually implementation details). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 04:30:16 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 05 May 2013 02:30:16 +0000 Subject: [issue17908] Unittest runner needs an option to call gc.collect() after each test In-Reply-To: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za> Message-ID: <1367721016.75.0.282940048004.issue17908@psf.upfronthosting.co.za> Ezio Melotti added the comment: See also #17534. ---------- nosy: +ezio.melotti, michael.foord stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 04:37:50 2013 From: report at bugs.python.org (Ned Batchelder) Date: Sun, 05 May 2013 02:37:50 +0000 Subject: [issue17894] Edits to descriptor howto In-Reply-To: <1367547112.04.0.920947702161.issue17894@psf.upfronthosting.co.za> Message-ID: <1367721470.76.0.811986817252.issue17894@psf.upfronthosting.co.za> Ned Batchelder added the comment: Raymond, I'm glad you're on top of this. I would have thought the howto should be the easy on-ramp, and deeper authoritative details should go in the reference section. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 05:24:55 2013 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 05 May 2013 03:24:55 +0000 Subject: [issue11798] Test cases not garbage collected after run In-Reply-To: <1302192957.51.0.450503345302.issue11798@psf.upfronthosting.co.za> Message-ID: <1367724295.96.0.147941338773.issue11798@psf.upfronthosting.co.za> Guido van Rossum added the comment: Just to be self-referential here's a link to #17908. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 05:50:42 2013 From: report at bugs.python.org (Ben Hoyt) Date: Sun, 05 May 2013 03:50:42 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1299320278.86.0.403600489598.issue11406@psf.upfronthosting.co.za> Message-ID: <1367725842.95.0.39899041935.issue11406@psf.upfronthosting.co.za> Ben Hoyt added the comment: That's right: if we have a separate scandir() that returns (name, stat) tuples, then a plain iterdir() is pretty much unnecessary -- callers just ignore the second stat value if they don't care about it. I'd slightly prefer the name iterdir_stat(), as that almost makes the (name, stat) return values explicit in the name. But that's kind of bikeshedding -- scandir() works too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 06:33:58 2013 From: report at bugs.python.org (koobs) Date: Sun, 05 May 2013 04:33:58 +0000 Subject: [issue17809] FAIL: test_expanduser when $HOME ends with / In-Reply-To: <1366522649.21.0.891133291523.issue17809@psf.upfronthosting.co.za> Message-ID: <1367728438.84.0.688785683763.issue17809@psf.upfronthosting.co.za> koobs added the comment: The attached patch strips the trailing slash from the home directory obtained from pw_dir in test_expanduser ./python -m test -j3 test_posixpath [1/1] test_posixpath 1 test OK. Can someone take care of the commit please, and thank you again Ezio for the assistance ---------- keywords: +patch Added file: http://bugs.python.org/file30128/test_posixpath.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 06:57:25 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 05 May 2013 04:57:25 +0000 Subject: [issue17408] second python execution fails when embedding In-Reply-To: <1363183794.27.0.643296851621.issue17408@psf.upfronthosting.co.za> Message-ID: <1367729845.72.0.43625077521.issue17408@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Commit 8c1385205a35 causes segmentation fault (in non-debug build) or abort (in debug build) during interpreter shutdown after copying of e.g. bytes or object(). $ python -c 'import copy; copy.copy(b""); print("text")' text Segmentation fault $ python -c 'import copy; copy.copy(object()); print("text")' text Segmentation fault ---------- nosy: +Arfrever resolution: fixed -> stage: committed/rejected -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 08:22:49 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 May 2013 06:22:49 +0000 Subject: [issue17408] second python execution fails when embedding In-Reply-To: <1363183794.27.0.643296851621.issue17408@psf.upfronthosting.co.za> Message-ID: <1367734969.94.0.336467082006.issue17408@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Should be fixed in 7de9852cdc0e, sorry. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 08:24:39 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 May 2013 06:24:39 +0000 Subject: [issue17809] FAIL: test_expanduser when $HOME ends with / In-Reply-To: <1366522649.21.0.891133291523.issue17809@psf.upfronthosting.co.za> Message-ID: <1367735079.16.0.751125658839.issue17809@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- assignee: -> ezio.melotti stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 08:27:42 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 May 2013 06:27:42 +0000 Subject: [issue17894] Edits to descriptor howto In-Reply-To: <1367547112.04.0.920947702161.issue17894@psf.upfronthosting.co.za> Message-ID: <1367735262.57.0.329008946351.issue17894@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > in contrast to an authoritative document closely tied to the actually > implementation details I fail to understand why a HOWTO should be an authoritative document closely tied to implementation details. If you don't want this document to be beginner-friendly, please move it into the language reference, not the HOWTO directory. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 08:37:11 2013 From: report at bugs.python.org (koobs) Date: Sun, 05 May 2013 06:37:11 +0000 Subject: [issue17809] FAIL: test_expanduser when $HOME ends with / In-Reply-To: <1366522649.21.0.891133291523.issue17809@psf.upfronthosting.co.za> Message-ID: <1367735831.69.0.057948394941.issue17809@psf.upfronthosting.co.za> koobs added the comment: Thanks Antoine, I'm removing the 'Library' component on this one given the proposed resolution. Additionally, given the trivial nature and isolation of the change strictly to the test, I'd like to request this go into 3.2 as well. For any future security fixes to 3.2 until its EoL, having our buildbots 'green' is imperative and a prerequisite for identifying regressions ---------- components: -Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 10:31:03 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 05 May 2013 08:31:03 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1367725842.95.0.39899041935.issue11406@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > I'd slightly prefer the name iterdir_stat(), as that almost makes the (name, stat) return values explicit in the name. But that's kind of bikeshedding -- scandir() works too. I find iterdir_stat() ugly :-) I like the scandir name, which has some precedent with POSIX. > That's right: if we have a separate scandir() that returns (name, stat) tuples, then a plain iterdir() is pretty much unnecessary -- callers just ignore the second stat value if they don't care about it. Hum, wait. scandir() cannot return (name, stat), because on POSIX, readdir() only returns d_name and d_type (the type of the entry): to return a stat, we would have to call stat() on each entry, which would defeat the performance gain. And that's the problem with scandir: it's not portable. Depending on the OS/file system, you could very well get DT_UNKNOWN (and on Linux, since it uses an adaptive heuristic for NFS filesystem, you could have some entries with a resolved d_type and some others with DT_UNKNOWN, on the same directory stream). That's why scandir would be a rather low-level call, whose main user would be walkdir, which only needs to know the entry time and not the whole stat result. Also, I don't know which information is returned by the readdir equivalent on Windows, but if we want a consistent API, we have to somehow map d_type and Windows's returned type to a common type, like DT_FILE, DT_DIRECTORY, etc (which could be an enum). The other approach would be to return a dummy stat object with only st_mode set, but that would be kind of a hack to return a dummy stat result with only part of the attributes set (some people will get bitten by this). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 10:53:16 2013 From: report at bugs.python.org (Ben Hoyt) Date: Sun, 05 May 2013 08:53:16 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1299320278.86.0.403600489598.issue11406@psf.upfronthosting.co.za> Message-ID: <1367743996.81.0.0633756411816.issue11406@psf.upfronthosting.co.za> Ben Hoyt added the comment: > I find iterdir_stat() ugly :-) I like the scandir name, which has some precedent with POSIX. Fair enough. I'm cool with scandir(). > scandir() cannot return (name, stat), because on POSIX, readdir() only returns d_name and d_type (the type of the entry): to return a stat, we would have to call stat() on each entry, which would defeat the performance gain. Yes, you're right. I "solved" this in BetterWalk with the solution you propose of returning a stat_result object with the fields it could get "for free" set, and the others set to None. So on Linux, you'd get a stat_result with only st_mode set (or None for DT_UNKNOWN), and all the other fields None. However -- st_mode is the one you're most likely to use, usually looking just for whether it's a file or directory. So calling code would look something like this: files = [] dirs = [] for name, st in scandir(path): if st.st_mode is None: st = os.stat(os.path.join(path, name)) if stat.S_ISDIR(st.st_mode): dirs.append(name) else: files.append(name) Meaning you'd get the speed improvements 99% of the time (when st_mode) was set, but if st_mode is None, you can call stat and handle errors and whatnot yourself. > That's why scandir would be a rather low-level call, whose main user would be walkdir, which only needs to know the entry time and not the whole stat result. Agreed. This is in the OS module after all, and there's tons of stuff that's OS-dependent in there. However, I think that doing something like the above, we can make it usable and performant on both Linux and Windows for use cases like walking directory trees. > Also, I don't know which information is returned by the readdir equivalent on Windows, but if we want a consistent API, we have to somehow map d_type and Windows's returned type to a common type, like DT_FILE, DT_DIRECTORY, etc (which could be an enum). The Windows scan directory functions (FindFirstFile/FindNextFile) return a *full* stat (or at least, as much info as you get from a stat in Windows). We *could* map them to a common type -- but I'm suggesting that common type might as well be "stat_result with None meaning not present". That way users don't have to learn a completely new type. > The other approach would be to return a dummy stat object with only st_mode set, but that would be kind of a hack to return a dummy stat result with only part of the attributes set (some people will get bitten by this). We could document any platform-specific stuff, and places you'd users could get bitten. But can you give me an example of where the stat_result-with-st_mode-or-None approach falls over completely? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 10:59:57 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 05 May 2013 08:59:57 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1299320278.86.0.403600489598.issue11406@psf.upfronthosting.co.za> Message-ID: <1367744397.48.0.03032220023.issue11406@psf.upfronthosting.co.za> Nick Coghlan added the comment: I think os.scandir is a case where we *want* a low level call that exposes everything we can retrieve efficiently about the directory entries given the underlying platform - not everything written in Python is written to be portable, especially when it comes to scripts rather than applications (e.g. given where I work, I write a fair bit of code that is Fedora/RHEL specific, and if that code happens to work anywhere else it's just a bonus rather than being of any specific value to me). This may mean that we just return an "info" object for each item, where the available info is explicitly platform specific. Agreed it can be an actual stat object, though. os.walk then become the cross-platform abstraction built on top of the low level scandir call (splitting files from directories is probably about all we can do consistently cross-platform without per-entry stat calls). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 11:18:06 2013 From: report at bugs.python.org (Armin Rigo) Date: Sun, 05 May 2013 09:18:06 +0000 Subject: [issue1545463] New-style classes fail to cleanup attributes Message-ID: <1367745486.93.0.188744915508.issue1545463@psf.upfronthosting.co.za> Changes by Armin Rigo : ---------- nosy: -arigo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 11:23:46 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 05 May 2013 09:23:46 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1367743996.81.0.0633756411816.issue11406@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > We could document any platform-specific stuff, and places you'd users could get bitten. But can you give me an example of where the stat_result-with-st_mode-or-None approach falls over completely? Well, that's easy: size = 0 for name, st in scandir(path): if stat.S_ISREG(st.st_mode): size += st.st_size > Agreed it can be an actual stat object, though. Well, the nice thing is that we don't have to create yet another info object, the downside is that it can be tricky, see above. We can probably use the DTTOIF macro to convert d_type to st_mode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 13:21:58 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Sun, 05 May 2013 11:21:58 +0000 Subject: [issue17908] Unittest runner needs an option to call gc.collect() after each test In-Reply-To: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za> Message-ID: <1367752918.75.0.141126192109.issue17908@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 13:23:17 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 May 2013 11:23:17 +0000 Subject: [issue1545463] New-style classes fail to cleanup attributes Message-ID: <1367752997.37.0.946623920195.issue1545463@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is an updated patch after the latest changes on default. ---------- Added file: http://bugs.python.org/file30129/gcshutdown2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 13:29:55 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 May 2013 11:29:55 +0000 Subject: [issue17908] Unittest runner needs an option to call gc.collect() after each test In-Reply-To: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za> Message-ID: <1367753395.25.0.838100069237.issue17908@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > OTOH it's a useful option to have in case you're tracking down > something that happens (or doesn't happen) when an object is collected IMO this is a good reason to implement your specific tearDown method (or call addCleanup if you prefer), possibly in a shared base class. I don't think this is a good candidate for a command-line option, it's too specialized and it's also not something which should be enabled blindly. In other words, each test case should know whether it needs a collection or not. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 13:45:06 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 May 2013 11:45:06 +0000 Subject: [issue17906] JSON should accept lone surrogates In-Reply-To: <1367678308.48.0.934181281887.issue17906@psf.upfronthosting.co.za> Message-ID: <1367754306.11.0.846039834679.issue17906@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: After investigating the problem deeper, I see that new parameter is not needed. RFC 4627 does not make exceptions for the range 0xD800-0xDFFF, and the decoder must accept lone surrogates, both escaped and unescaped. Non-BMP characters may be represented as escaped surrogate pair, so escaped surrogate pair may be decoded as non-BMP character, while unescaped surrogate pair shouldn't. Here is a patch, with which JSON decoder accepts encoded lone surrogates. Also fixed a bug when Python implementation decodes "\\ud834\\u0079x" as "\U0001d179". ---------- keywords: +patch stage: needs patch -> patch review title: Add a string error handler to JSON encoder/decoder -> JSON should accept lone surrogates type: enhancement -> behavior versions: +Python 2.7, Python 3.3 Added file: http://bugs.python.org/file30130/json_decode_lone_surrogates.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 13:45:58 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 May 2013 11:45:58 +0000 Subject: [issue17906] JSON should accept lone surrogates In-Reply-To: <1367678308.48.0.934181281887.issue17906@psf.upfronthosting.co.za> Message-ID: <1367754358.38.0.104134532071.issue17906@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file30131/json_decode_lone_surrogates-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 14:04:56 2013 From: report at bugs.python.org (Yael) Date: Sun, 05 May 2013 12:04:56 +0000 Subject: [issue995907] memory leak with threads and enhancement of the timer class Message-ID: <1367755496.75.0.849703507911.issue995907@psf.upfronthosting.co.za> Yael added the comment: Can you please review the patch? thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 14:05:38 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 May 2013 12:05:38 +0000 Subject: [issue17907] Deprecate imp.new_module() in favour of types.ModuleType In-Reply-To: <1367691908.58.0.339991159831.issue17907@psf.upfronthosting.co.za> Message-ID: <1367755538.28.0.612364478973.issue17907@psf.upfronthosting.co.za> Antoine Pitrou added the comment: If so, then at least the constructor should be documented. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 14:42:10 2013 From: report at bugs.python.org (Brett Cannon) Date: Sun, 05 May 2013 12:42:10 +0000 Subject: [issue15902] imp.load_module won't accept None for the file argument for a C extension In-Reply-To: <1347278689.78.0.295593798435.issue15902@psf.upfronthosting.co.za> Message-ID: <1367757730.42.0.448965623466.issue15902@psf.upfronthosting.co.za> Brett Cannon added the comment: http://hg.python.org/cpython/rev/996a937cdf81 also applies to this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 14:57:54 2013 From: report at bugs.python.org (Brett Cannon) Date: Sun, 05 May 2013 12:57:54 +0000 Subject: [issue17636] Modify IMPORT_FROM to fallback on sys.modules In-Reply-To: <1365124502.39.0.727243640375.issue17636@psf.upfronthosting.co.za> Message-ID: <1367758674.52.0.0254257096229.issue17636@psf.upfronthosting.co.za> Brett Cannon added the comment: Don't be distracted when trying to write tests is the lesson learned. Fixed basic and rebinding and just deleted indirect. ---------- Added file: http://bugs.python.org/file30132/import_from_tests.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 15:10:30 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 May 2013 13:10:30 +0000 Subject: [issue17909] Autodetecting JSON encoding Message-ID: <1367759430.76.0.988181674037.issue17909@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: RFC 4627 specifies a method to determine an encoding (one of UTF-8, UTF-16(BE|LE) or UTF-32(BE|LE)) of encoded JSON text. The proposed preliminary patch (it doesn't include the documentation yet) allows load() and loads() functions accept bytes data when it is encoded with standard Unicode encoding. Also accepted data with BOM (this doesn't specified in RFC 4627, but is widely used). There is only one case where the method can give a misfire. Serialized string "\x00..." encoded in UTF-16LE may be erroneously detected as encoded in UTF-32LE. This case violates the two rules of RFC 4627: the string was serialized instead of a an object or an array, and the control character U+0000 was not escaped. The standard encoded JSON always detected correctly. This patch requires "surrogatepass" error handler for utf-16/32 (see issue12892 and issue13916). ---------- assignee: serhiy.storchaka components: Library (Lib), Unicode files: json_detect_encoding.patch keywords: patch messages: 188442 nosy: ezio.melotti, pitrou, rhettinger, serhiy.storchaka priority: normal severity: normal status: open title: Autodetecting JSON encoding type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file30133/json_detect_encoding.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 15:11:10 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 May 2013 13:11:10 +0000 Subject: [issue17909] Autodetecting JSON encoding In-Reply-To: <1367759430.76.0.988181674037.issue17909@psf.upfronthosting.co.za> Message-ID: <1367759470.89.0.076654971711.issue17909@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +UTF-16 and UTF-32 codecs should reject (lone) surrogates, disallow the "surrogatepass" handler for non utf-* encodings _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 15:37:23 2013 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 May 2013 13:37:23 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: Message-ID: STINNER Victor added the comment: I really like scandir() -> (name: str, stat: stat structure using None for unknown fields). I expect that this API to optimize use cases like: - glob.glob("*.jpg") in a big directory with few JPEG picture - os.walk(".") in a directory with many files: should reduce the number of stat() to zero on most platforms But as usual, a benchmark on a real platform would be more convicing. Filtering entries in os.listdir() or os.scandir() would be faster (than filtering their output), but it hard to design an API to filter arbitrary fields (name, file type, size, ...) especially because the underlying C functions does not provide required information. A generator is closer to Python design and more natural. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 16:07:06 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sun, 05 May 2013 14:07:06 +0000 Subject: [issue12634] Random Remarks in class documentation In-Reply-To: <1311575810.71.0.0727071558423.issue12634@psf.upfronthosting.co.za> Message-ID: <1367762826.36.0.0591671215318.issue12634@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: Based on Teery's comments, this patch makes the changes to the random remarks section of the class documentation ---------- keywords: +patch nosy: +Yogesh.Chaudhari Added file: http://bugs.python.org/file30134/issue12634.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 16:08:28 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sun, 05 May 2013 14:08:28 +0000 Subject: [issue12634] Random Remarks in class documentation In-Reply-To: <1311575810.71.0.0727071558423.issue12634@psf.upfronthosting.co.za> Message-ID: <1367762908.21.0.556365241373.issue12634@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: Similar changes for 2.7 branch ---------- hgrepos: +188 Added file: http://bugs.python.org/file30135/issue12634-27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 17:51:55 2013 From: report at bugs.python.org (Nick Sloan) Date: Sun, 05 May 2013 15:51:55 +0000 Subject: [issue17732] distutils.cfg Can Break venv In-Reply-To: <1365963032.26.0.766714843383.issue17732@psf.upfronthosting.co.za> Message-ID: <1367769115.42.0.745307958305.issue17732@psf.upfronthosting.co.za> Nick Sloan added the comment: Just checking to see if anything else is needed from me on this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 18:36:32 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 May 2013 16:36:32 +0000 Subject: [issue17798] IDLE: can not edit new file names when using -e In-Reply-To: <1366425914.88.0.469107315169.issue17798@psf.upfronthosting.co.za> Message-ID: <3b3Xlh1QPzz7LjY@mail.python.org> Roundup Robot added the comment: New changeset c8cdc2400643 by Roger Serwy in branch '3.3': #17798: Allow IDLE to edit new files when specified on command line. http://hg.python.org/cpython/rev/c8cdc2400643 New changeset a64a3da996ed by Roger Serwy in branch 'default': #17798: merge with 3.3. http://hg.python.org/cpython/rev/a64a3da996ed ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 18:38:28 2013 From: report at bugs.python.org (Roger Serwy) Date: Sun, 05 May 2013 16:38:28 +0000 Subject: [issue17798] IDLE: can not edit new file names when using -e In-Reply-To: <1366425914.88.0.469107315169.issue17798@psf.upfronthosting.co.za> Message-ID: <1367771908.05.0.16133987118.issue17798@psf.upfronthosting.co.za> Roger Serwy added the comment: I'm closing this issue as fixed. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 19:06:32 2013 From: report at bugs.python.org (Paul Moore) Date: Sun, 05 May 2013 17:06:32 +0000 Subject: [issue17903] Python launcher for windows should search path for #!/usr/bin/env In-Reply-To: <1367662362.6.0.575670511803.issue17903@psf.upfronthosting.co.za> Message-ID: <1367773592.82.0.411429878743.issue17903@psf.upfronthosting.co.za> Paul Moore added the comment: There is a patch for this (against the standalone pylauncher project) at https://bitbucket.org/pmoore/pylauncher. ---------- keywords: +patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 19:10:04 2013 From: report at bugs.python.org (Andriy Mysyk) Date: Sun, 05 May 2013 17:10:04 +0000 Subject: [issue17858] Different documentation for identical methods In-Reply-To: <1367103485.02.0.041609834341.issue17858@psf.upfronthosting.co.za> Message-ID: <1367773804.82.0.141731265168.issue17858@psf.upfronthosting.co.za> Andriy Mysyk added the comment: Made changes suggested by Ezio Melotti in the attached patch. ---------- Added file: http://bugs.python.org/file30136/issue17858.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 19:23:55 2013 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 05 May 2013 17:23:55 +0000 Subject: [issue17908] Unittest runner needs an option to call gc.collect() after each test In-Reply-To: <1367753395.25.0.838100069237.issue17908@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: On Sun, May 5, 2013 at 4:29 AM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > >> OTOH it's a useful option to have in case you're tracking down >> something that happens (or doesn't happen) when an object is collected > > IMO this is a good reason to implement your specific tearDown method (or call addCleanup if you prefer), possibly in a shared base class. > > I don't think this is a good candidate for a command-line option, it's too specialized and it's also not something which should be enabled blindly. In other words, each test case should know whether it needs a collection or not. This is not for tests that know or expect they need a call to gc.collect(). This is for the case where you have 500 tests that weren't written with gc.collect() in mind, and suddenly you have a nondeterministic failure because something goes wrong during collection. The cause is probably many tests earlier -- and if you could just call gc.collect() in each tearDown() it would be a cinch to pinpoint the test that causes this. But (unless you had all that foresight) that's a massive undertaking. However turning on the command line option makes it trivial. It's rare that extra collections cause tests to fail (and if it does that's a flakey test anyway) so just turning this on for all tests shouldn't affect correct tests -- however it can slow down your test suite 3x or more so you don't want this to be unittest's default behavior. Hence the suggestion of a command line flag. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 20:43:32 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 May 2013 18:43:32 +0000 Subject: [issue17094] sys._current_frames() reports too many/wrong stack frames In-Reply-To: <1359668363.58.0.777154629349.issue17094@psf.upfronthosting.co.za> Message-ID: <1367779412.62.0.238820811559.issue17094@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is an updated patch which doesn't hold the lock while calling PyThreadState_Clear(). It looks like it should be ok. Also, I've added some comments. ---------- Added file: http://bugs.python.org/file30137/tstates-afterfork2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 21:23:38 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 05 May 2013 19:23:38 +0000 Subject: [issue16518] add "buffer protocol" to glossary In-Reply-To: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za> Message-ID: <1367781818.06.0.984235828078.issue16518@psf.upfronthosting.co.za> Ezio Melotti added the comment: Updated patch to include getargs.c too. ---------- stage: patch review -> commit review Added file: http://bugs.python.org/file30138/issue16518-4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 21:26:37 2013 From: report at bugs.python.org (Mike Milkin) Date: Sun, 05 May 2013 19:26:37 +0000 Subject: [issue9682] socket.create_connection error message for domain subpart with invalid length is very confusing In-Reply-To: <1282759693.65.0.0842882042261.issue9682@psf.upfronthosting.co.za> Message-ID: <1367781997.77.0.340540861014.issue9682@psf.upfronthosting.co.za> Mike Milkin added the comment: Moved the conditional logic out of the method. There are no tests for ToASCII function and I was not comfortable making changes to it without adding tests. ---------- Added file: http://bugs.python.org/file30139/Issue9682-5513.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 21:33:25 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 05 May 2013 19:33:25 +0000 Subject: [issue15528] Better support for finalization with weakrefs In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za> Message-ID: <1367782405.07.0.671030397291.issue15528@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Here is an updated patch. It is only really the example in the docs which is different, plus a note about daemon threads. Antoine, do think this is ready to be committed? ---------- Added file: http://bugs.python.org/file30140/finalize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 21:36:18 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 May 2013 19:36:18 +0000 Subject: [issue17883] Fix buildbot testing of Tkinter In-Reply-To: <1367355915.98.0.26398929673.issue17883@psf.upfronthosting.co.za> Message-ID: <3b3cl606SMz7Lkm@mail.python.org> Roundup Robot added the comment: New changeset 3c58fa7dc7f1 by Ezio Melotti in branch '2.7': #17883: Fix buildbot testing of Tkinter on Windows. Patch by Zachary Ware. http://hg.python.org/cpython/rev/3c58fa7dc7f1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 21:38:07 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 May 2013 19:38:07 +0000 Subject: [issue15528] Better support for finalization with weakrefs In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za> Message-ID: <1367782687.05.0.895306903895.issue15528@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, assuming there are no significant changes in the code (I haven't checked), +1 for committing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 21:40:45 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 May 2013 19:40:45 +0000 Subject: [issue16741] `int()`, `float()`, etc think python strings are null-terminated In-Reply-To: <1356046641.74.0.314140910069.issue16741@psf.upfronthosting.co.za> Message-ID: <1367782845.94.0.795725890781.issue16741@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch based on Matthew's patch. It is smaller (+35 lines vs +59) but fixes error messages for more cases: int(b'123\0') -- bytes string with null without base. int(b'123\xbd') -- non-utf-8 bytes string. int('123\ud800') -- lone surrogate in unicode string. Unfortunately it is not easy to backport it to 2.7. PyErr_Format() in 2.7 works only with null-terminated strings. I propose to fix this issue on 3.3+ and declare it as "won't fix" for 2.7. ---------- nosy: +chris.jerdonek versions: -Python 3.2 Added file: http://bugs.python.org/file30141/int_from_str.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 21:41:35 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 May 2013 19:41:35 +0000 Subject: [issue16741] `int()`, `float()`, etc think python strings are null-terminated In-Reply-To: <1356046641.74.0.314140910069.issue16741@psf.upfronthosting.co.za> Message-ID: <1367782895.81.0.191813309581.issue16741@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 21:43:02 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 05 May 2013 19:43:02 +0000 Subject: [issue15528] Better support for finalization with weakrefs In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za> Message-ID: <1367782982.73.0.24886147767.issue15528@psf.upfronthosting.co.za> Richard Oudkerk added the comment: The only (non-doc, non-comment) changes were the two one-liners you suggested in msg172077. So I will commit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 21:43:14 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 May 2013 19:43:14 +0000 Subject: [issue15809] IDLE console uses incorrect encoding. In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za> Message-ID: <1367782994.39.0.815130583805.issue15809@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Good catch. Thank you, Roger. ---------- stage: patch review -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 22:03:50 2013 From: report at bugs.python.org (Andriy Mysyk) Date: Sun, 05 May 2013 20:03:50 +0000 Subject: [issue17910] Usage error in multiprocessing documentation Message-ID: <1367784230.19.0.495557167576.issue17910@psf.upfronthosting.co.za> New submission from Andriy Mysyk: "As mentioned above, when doing concurrent programming it is usually best to avoid using shared state as far as possible" should say "as much as possible" in multiprocessing.rst. ---------- assignee: docs at python components: Documentation messages: 188461 nosy: amysyk, docs at python priority: normal severity: normal status: open title: Usage error in multiprocessing documentation type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 22:06:09 2013 From: report at bugs.python.org (Andriy Mysyk) Date: Sun, 05 May 2013 20:06:09 +0000 Subject: [issue17910] Usage error in multiprocessing documentation In-Reply-To: <1367784230.19.0.495557167576.issue17910@psf.upfronthosting.co.za> Message-ID: <1367784369.14.0.941927593586.issue17910@psf.upfronthosting.co.za> Andriy Mysyk added the comment: patch attached ---------- keywords: +patch Added file: http://bugs.python.org/file30142/issue17910.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 22:17:02 2013 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 May 2013 20:17:02 +0000 Subject: [issue16741] `int()`, `float()`, etc think python strings are null-terminated In-Reply-To: <1356046641.74.0.314140910069.issue16741@psf.upfronthosting.co.za> Message-ID: <1367785022.91.0.317607761859.issue16741@psf.upfronthosting.co.za> STINNER Victor added the comment: int_from_str.patch: + strobj = PySequence_GetSlice(u, 0, 200); + if (strobj != NULL) { + PyErr_Format(PyExc_ValueError, + "invalid literal for int() with base %d: %R", + base, strobj); + Py_DECREF(strobj); + } Oh, it remembers me that #7330 is still open. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 22:26:15 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 05 May 2013 20:26:15 +0000 Subject: [issue17883] Fix buildbot testing of Tkinter In-Reply-To: <1367355915.98.0.26398929673.issue17883@psf.upfronthosting.co.za> Message-ID: <1367785575.81.0.463446853756.issue17883@psf.upfronthosting.co.za> Ezio Melotti added the comment: The buildbots run the tests and seem happy. Thanks for the report and the patch! ---------- assignee: -> ezio.melotti resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 23:03:00 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 May 2013 21:03:00 +0000 Subject: [issue15528] Better support for finalization with weakrefs In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za> Message-ID: <3b3fg81rSQz7Ljq@mail.python.org> Roundup Robot added the comment: New changeset 2e446e87ac5b by Richard Oudkerk in branch 'default': Issue #15528: Add weakref.finalize to support finalization using http://hg.python.org/cpython/rev/2e446e87ac5b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 23:10:19 2013 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 May 2013 21:10:19 +0000 Subject: [issue15528] Better support for finalization with weakrefs In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za> Message-ID: <1367788219.5.0.993685596028.issue15528@psf.upfronthosting.co.za> STINNER Victor added the comment: The changeset 2e446e87ac5b broke some buildbots at compile step. ./python -E -S -m sysconfig --generate-posix-vars Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] Fatal Python error: Py_Initialize: can't initialize sys standard streams Traceback (most recent call last): File "/home/buildbot/buildarea/3.x.coghlan-redhat/build/Lib/locale.py", line 17, in import re File "/home/buildbot/buildarea/3.x.coghlan-redhat/build/Lib/re.py", line 124, in import functools File "/home/buildbot/buildarea/3.x.coghlan-redhat/build/Lib/functools.py", line 18, in from collections import namedtuple File "/home/buildbot/buildarea/3.x.coghlan-redhat/build/Lib/collections/__init__.py", line 8, in __all__ += collections.abc.__all__ AttributeError: 'module' object has no attribute 'abc' http://buildbot.python.org/all/builders/x86%20RHEL%206%203.x/builds/1963 ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 23:31:26 2013 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 05 May 2013 21:31:26 +0000 Subject: [issue17911] Extracting tracebacks does too much work Message-ID: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> New submission from Guido van Rossum: For Tulip I may have to extract tracebacks and store the extracted data, in order to avoid cycles created by the frames referenced in the traceback. I'll be extracting the traceback every time an exception is raised, and in most cases I won't be using the extracted info, because usually the exception is caught (or logged) by user code. But it's very important to ensure that if the user code doesn't catch or log it, I can log a traceback, and I won't know that this is the case until a destructor is called, which may be quite a bit later. (Reference: http://code.google.com/p/tulip/source/browse/tulip/futures.py#38) Unfortunately it looks like the public APIs do a lot more work than needed. Ideally, there'd be something similar to _extract_tb_or_stack_iter() that doesn't call linecache.getline() -- it should just return triples of (filename, lineno, functionname), and enough structure to tell apart the __cause__, __context__, and __traceback__ (the first two possibly repeated). Given this info it would be simple enough to format and log the actual traceback, and storing just this would take less space and time than computing the lines of the fully-formatted traceback. ---------- components: Library (Lib) messages: 188467 nosy: gvanrossum priority: normal severity: normal status: open title: Extracting tracebacks does too much work type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 23:43:22 2013 From: report at bugs.python.org (Ben Hoyt) Date: Sun, 05 May 2013 21:43:22 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1299320278.86.0.403600489598.issue11406@psf.upfronthosting.co.za> Message-ID: <1367790202.96.0.70313907442.issue11406@psf.upfronthosting.co.za> Ben Hoyt added the comment: Yeah, I very much agree with what Nick says -- we really want a way to expose what the platform provides. It's less important (though still the ideal), to expose that in a platform-independent way. Today the only way to get access to opendir/readdir on Linux and FindFirst/Next on Windows is by using a bunch of messy (and slowish) ctypes code. And yes, os.walk() would be the main cross-platform abstraction built on top of this. Charles gave this example of code that would fall over: size = 0 for name, st in scandir(path): if stat.S_ISREG(st.st_mode): size += st.st_size I don't see it, though. In this case you need both .st_mode and .st_size, so a caller would check that those are not None, like so: size = 0 for name, st in scandir(path): if st.st_mode is None or st.st_size is None: st = os.stat(os.path.join(path, name)) if stat.S_ISREG(st.st_mode): size += st.st_size One line of extra code for the caller, but a big performance gain in most cases. Stinner said, "But as usual, a benchmark on a real platform would be more convicing". Here's a start: https://github.com/benhoyt/betterwalk#benchmarks -- but it's not nearly as good as it gets yet, because those figures are still using the ctypes version. I've got a C version that's half-finished, and on Windows it makes os.walk() literally 10x the speed of the default version. Not sure about Linux/opendir/readdir yet, but I intend to do that too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 23:47:18 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 May 2013 21:47:18 +0000 Subject: [issue17094] sys._current_frames() reports too many/wrong stack frames In-Reply-To: <1359668363.58.0.777154629349.issue17094@psf.upfronthosting.co.za> Message-ID: <3b3gfF2ll3z7Lkg@mail.python.org> Roundup Robot added the comment: New changeset 847692b9902a by Antoine Pitrou in branch 'default': Issue #17094: Clear stale thread states after fork(). http://hg.python.org/cpython/rev/847692b9902a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 5 23:48:15 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 May 2013 21:48:15 +0000 Subject: [issue17094] sys._current_frames() reports too many/wrong stack frames In-Reply-To: <1359668363.58.0.777154629349.issue17094@psf.upfronthosting.co.za> Message-ID: <1367790495.8.0.0810781875355.issue17094@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I've committed after the small change suggested by Charles-Fran?ois. Hopefully there aren't any applications relying on the previous behaviour. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: -Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 00:02:39 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 May 2013 22:02:39 +0000 Subject: [issue17912] thread states should use a doubly-linked list Message-ID: <1367791359.52.0.60418083975.issue17912@psf.upfronthosting.co.za> New submission from Antoine Pitrou: Thread states are stored in a singly linked list, which makes some operations more cumbersome than they should be. Since memory consumption is far from critical here, it would be easier to handle them with a doubly linked list. ---------- components: Interpreter Core messages: 188471 nosy: pitrou priority: low severity: normal stage: needs patch status: open title: thread states should use a doubly-linked list type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 00:03:33 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 05 May 2013 22:03:33 +0000 Subject: [issue17910] Usage error in multiprocessing documentation In-Reply-To: <1367784230.19.0.495557167576.issue17910@psf.upfronthosting.co.za> Message-ID: <1367791413.23.0.222948272176.issue17910@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I don't see any difference in meaning: http://idioms.thefreedictionary.com/as+far+as+possible ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 00:06:39 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 05 May 2013 22:06:39 +0000 Subject: [issue17883] Fix buildbot testing of Tkinter In-Reply-To: <1367355915.98.0.26398929673.issue17883@psf.upfronthosting.co.za> Message-ID: <1367791599.27.0.979863355594.issue17883@psf.upfronthosting.co.za> Ezio Melotti added the comment: Actually one buildbot is failing: http://buildbot.python.org/all/builders/x86%20Windows%20Server%202003%20%5BSB%5D%202.7/builds/427/steps/test/logs/stdio ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 00:12:09 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 May 2013 22:12:09 +0000 Subject: [issue15528] Better support for finalization with weakrefs In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za> Message-ID: <3b3hBw4x58zQKd@mail.python.org> Roundup Robot added the comment: New changeset 186cf551dae5 by Richard Oudkerk in branch 'default': Issue #15528: Add weakref.finalize to support finalization using http://hg.python.org/cpython/rev/186cf551dae5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 00:47:37 2013 From: report at bugs.python.org (Bradley Froehle) Date: Sun, 05 May 2013 22:47:37 +0000 Subject: [issue17289] readline.set_completer_delims() doesn't play well with others In-Reply-To: <1361727162.6.0.330340271384.issue17289@psf.upfronthosting.co.za> Message-ID: <1367794057.77.0.718696764842.issue17289@psf.upfronthosting.co.za> Bradley Froehle added the comment: Patch attached. I implemented this by adding a 'static char *' which holds the memory we allocate. I did not use the PyState machinery. ---------- keywords: +patch Added file: http://bugs.python.org/file30143/readline_completer_state.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 01:03:09 2013 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 May 2013 23:03:09 +0000 Subject: [issue7330] PyUnicode_FromFormat: implement width and precision for %s, %S, %R, %V, %U, %A In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za> Message-ID: <1367794989.72.0.386630166038.issue7330@psf.upfronthosting.co.za> STINNER Victor added the comment: New version of my patch taking Serhiy's remarks into account: - add a check_format() function to cleanup unit tests - only call _PyUnicodeWriter_Prepare() once per formatted argument: compute the length and maximum character. Be more optimistic about sprintf() for integer and pointer: expect that the maximum character is 127 or less - uniformize code parsing width and precision - factorize code for '%s' and '%V' Note: remove also _PyUnicode_WriteSubstring() from the patch, it was already added. ---------- Added file: http://bugs.python.org/file30144/unicode_fromformat_precision-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 01:05:27 2013 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 May 2013 23:05:27 +0000 Subject: [issue7330] PyUnicode_FromFormat: implement width and precision for %s, %S, %R, %V, %U, %A In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za> Message-ID: <1367795127.19.0.432948564255.issue7330@psf.upfronthosting.co.za> STINNER Victor added the comment: I didn't add the following optimization (proposed by Serhiy in his review) because I'm not convinced that it's faster, and it's unrelated to this issue: if (width > (PY_SSIZE_T_MAX - 9) / 10 && width > (PY_SSIZE_T_MAX - ((int)*f - '0')) / 10) { ... } instead of if (width > (PY_SSIZE_T_MAX - ((int)*f - '0')) / 10) { ... } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 01:16:39 2013 From: report at bugs.python.org (STINNER Victor) Date: Sun, 05 May 2013 23:16:39 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1367790202.96.0.70313907442.issue11406@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: size = 0 for name, st in scandir(path): if st.st_mode is None or st.st_size is None: st = os.stat(os.path.join(path, name)) if stat.S_ISREG(st.st_mode): size += st.st_size It would be safer to use dir_fd parameter when supported, but I don't think that os.scandir() should care of this problem. An higher level API like pathlib, walkdir & cie which should be able to reuse *at() C functions using dir_fd parameter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 01:42:53 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sun, 05 May 2013 23:42:53 +0000 Subject: [issue15528] Better support for finalization with weakrefs In-Reply-To: <1343837927.06.0.561023898829.issue15528@psf.upfronthosting.co.za> Message-ID: <1367797373.84.0.994731845962.issue15528@psf.upfronthosting.co.za> Changes by Richard Oudkerk : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 02:38:30 2013 From: report at bugs.python.org (Andriy Mysyk) Date: Mon, 06 May 2013 00:38:30 +0000 Subject: [issue17910] Usage error in multiprocessing documentation In-Reply-To: <1367784230.19.0.495557167576.issue17910@psf.upfronthosting.co.za> Message-ID: <1367800710.07.0.1763937371.issue17910@psf.upfronthosting.co.za> Andriy Mysyk added the comment: I found the use of "as far" (as opposed to "as much") but Richard has a good point. Let's close the issue. ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 03:15:22 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 06 May 2013 01:15:22 +0000 Subject: [issue13503] improved efficiency of bytearray pickling by using bytes type instead of str In-Reply-To: <1322611756.83.0.989666994675.issue13503@psf.upfronthosting.co.za> Message-ID: <1367802922.23.0.218055772731.issue13503@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Reopening this one because there is a size issue, not just speed. My clients are bumping into this issue repeatedly. There is a reasonable expectation that pickling a bytearray will result in a pickle about the same size as the bytearray (not a 50% to 100% expansion depending on the content). Likewise, the size shouldn't double when switching from protocol 0 to the presumably more efficient protocol 2: >>> # Example using Python 2.7.4 on Mac OS X 10.8 >>> from pickle import dumps >>> print len(dumps(bytearray([200] * 10000), 0)) 10055 >>> print len(dumps(bytearray([200] * 10000), 2)) 20052 >>> print len(dumps(bytearray([100] * 10000), 2)) 10052 >>> print len(dumps(bytearray([100, 200] * 5000), 2)) 15052 An attractive feature of bytearrays are their compact representation of data. An attractive feature of the binary pickle protocol is improved compactness and speed. Currently, it isn't living up to expectations. ---------- assignee: -> rhettinger nosy: +rhettinger status: closed -> open type: performance -> behavior versions: +Python 2.7 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 04:45:45 2013 From: report at bugs.python.org (Todd Rovito) Date: Mon, 06 May 2013 02:45:45 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1367808345.77.0.637724833843.issue15392@psf.upfronthosting.co.za> Todd Rovito added the comment: This issue appears like it is making progress. For a very small contribution I tested JayKrish's patch and it seems to work on my Mac. The results are documented below. Any comment from Python Core Developers on what needs to happen to get it committed? It appears to work with -m test and -v test_idle. Thanks! /python.exe -m test -v test_idle == CPython 3.4.0a0 (default:186cf551dae5+, May 5 2013, 22:41:07) [GCC 4.2.1 Compatible Apple Clang 4.1 ((tags/Apple/clang-421.11.66))] == Darwin-12.3.0-x86_64-i386-64bit little-endian == /Volumes/SecurePython3/cpython/py34/build/test_python_15812 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1) [1/1] test_idle test_DirBrowserTreeItem (test.test_idle.test_PathBrowser.PathBrowserTest) ... ok ---------------------------------------------------------------------- Ran 1 test in 0.000s OK 1 test OK. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 04:45:55 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 May 2013 02:45:55 +0000 Subject: [issue17862] itertools.chunks(iterable, size, fill=None) In-Reply-To: <1367165590.04.0.46648726654.issue17862@psf.upfronthosting.co.za> Message-ID: <3b3pGp3SQVzQHD@mail.python.org> Roundup Robot added the comment: New changeset 763d260414d1 by Raymond Hettinger in branch '2.7': Issue 17862: Improve the signature of itertools grouper() recipe. http://hg.python.org/cpython/rev/763d260414d1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 04:54:33 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 May 2013 02:54:33 +0000 Subject: [issue17862] itertools.chunks(iterable, size, fill=None) In-Reply-To: <1367165590.04.0.46648726654.issue17862@psf.upfronthosting.co.za> Message-ID: <3b3pSm5pDjzNlw@mail.python.org> Roundup Robot added the comment: New changeset 6383d0c8140d by Raymond Hettinger in branch '3.3': Issue 17862: Improve the signature of itertools grouper() recipe. http://hg.python.org/cpython/rev/6383d0c8140d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 05:00:28 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 06 May 2013 03:00:28 +0000 Subject: [issue16518] add "buffer protocol" to glossary In-Reply-To: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za> Message-ID: <1367809228.92.0.684769181144.issue16518@psf.upfronthosting.co.za> Raymond Hettinger added the comment: At first-reading, it looks like matters were made more confusing with "bytes-like object" as a defined term. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 05:03:19 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 06 May 2013 03:03:19 +0000 Subject: [issue16518] add "buffer protocol" to glossary In-Reply-To: <1353477807.87.0.204584648831.issue16518@psf.upfronthosting.co.za> Message-ID: <1367809399.51.0.545691621034.issue16518@psf.upfronthosting.co.za> Ezio Melotti added the comment: Can you elaborate? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 05:15:34 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 May 2013 03:15:34 +0000 Subject: [issue13495] IDLE: Regressions - Two ColorDelegator instances loaded In-Reply-To: <1322510218.36.0.927250562508.issue13495@psf.upfronthosting.co.za> Message-ID: <3b3px15ZJmz7Lm6@mail.python.org> Roundup Robot added the comment: New changeset fef7f212fe76 by Roger Serwy in branch '3.3': #13495: Avoid loading the color delegator twice in IDLE. http://hg.python.org/cpython/rev/fef7f212fe76 New changeset 588fcf36c975 by Roger Serwy in branch 'default': #13495: merge with 3.3. http://hg.python.org/cpython/rev/588fcf36c975 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 05:16:25 2013 From: report at bugs.python.org (Roger Serwy) Date: Mon, 06 May 2013 03:16:25 +0000 Subject: [issue13495] IDLE: Regressions - Two ColorDelegator instances loaded In-Reply-To: <1322510218.36.0.927250562508.issue13495@psf.upfronthosting.co.za> Message-ID: <1367810185.32.0.455913703735.issue13495@psf.upfronthosting.co.za> Roger Serwy added the comment: I'm closing this issue as fixed. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 05:16:50 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 06 May 2013 03:16:50 +0000 Subject: [issue17883] Fix buildbot testing of Tkinter In-Reply-To: <1367355915.98.0.26398929673.issue17883@psf.upfronthosting.co.za> Message-ID: <1367810210.05.0.179261103784.issue17883@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I wonder if there is something special about the environment on that Snakebite machine. At the top, it says PATH=C:\Perl\site\bin;C:\Perl\bin;E:\apps\activestate-python-2.7.2.5-x86\;E:\apps\activestate-python-2.7.2.5-x86\Scripts;... Could the presence of activestate-python affect the build? Ignoring the 'no buffer in 3.0' warnings, there are a couple of warnings that suggest updates to test_tcl.py. Another issue though. The context for the failure is with test_support.EnvironmentVarGuard() as env: env.unset("TCL_LIBRARY") f = os.popen('%s -c "import Tkinter; print Tkinter"' % (unc_name,)) self.assertTrue('Tkinter.py' in f.read()) I do not know why test_tcl is testing the ability of python to be opened from a unc path (I am not familiar with them), but anyway... The assertion is testing the read of the printed Tkinter module representation. On my 2.7.4 install, the result is "". On my machine, the test reads that and passes. (On 3.x, the test is ('tkinter' in f.read()) as the file is tkinter/__init__.py instead of Tkinter.py.) To see what is going on with the failing machine, an update to self.assertIn('Tkinter.py', f.read()) will show the f.read() that does not contain 'Tkinter.py'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 05:22:39 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 May 2013 03:22:39 +0000 Subject: [issue17883] Fix buildbot testing of Tkinter In-Reply-To: <1367355915.98.0.26398929673.issue17883@psf.upfronthosting.co.za> Message-ID: <3b3q5C1hxbz7LkW@mail.python.org> Roundup Robot added the comment: New changeset b1abc5800e2b by Terry Jan Reedy in branch '2.7': Issue17883: Update to assertIn to see why test fails on one buildbot. http://hg.python.org/cpython/rev/b1abc5800e2b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 06:26:45 2013 From: report at bugs.python.org (Roger Serwy) Date: Mon, 06 May 2013 04:26:45 +0000 Subject: [issue5492] Error on leaving IDLE with quit() or exit() under Linux In-Reply-To: <1237121077.76.0.63532373748.issue5492@psf.upfronthosting.co.za> Message-ID: <1367814405.49.0.271254104275.issue5492@psf.upfronthosting.co.za> Roger Serwy added the comment: Terry, the SystemExit traceback from clicking cancel is expected given how Lib/site.py's Quitter first closes sys.stdin and then raises SystemExit. Closing sys.stdin causes the dialog, the raised exception just gets printed. We could change the behavior such that when IDLE's internals catch SystemExit, then the close dialog appears. This avoids having to rely on closing sys.stdin to signal IDLE to close. See issue17838 for the patch to do just that. (It looks like #17838, #17585, and this issue are converging.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 08:25:26 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 06:25:26 +0000 Subject: [issue13503] improved efficiency of bytearray pickling by using bytes type instead of str In-Reply-To: <1322611756.83.0.989666994675.issue13503@psf.upfronthosting.co.za> Message-ID: <1367821526.73.0.104151067551.issue13503@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Raymond, we can't just backport this without breaking compatibility with installed Python versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 08:51:57 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 06 May 2013 06:51:57 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1367790202.96.0.70313907442.issue11406@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Charles gave this example of code that would fall over: > > size = 0 > for name, st in scandir(path): > if stat.S_ISREG(st.st_mode): > size += st.st_size > > I don't see it, though. In this case you need both .st_mode and .st_size, so a caller would check that those are not None, like so: Well, that's precisely the point. A normal "caller" would never expect a stat object to be partially populated: if a function has a prototype returning a stat object, then I definitely expect it to be a regular stat object, with all the fields guaranteed by POSIX set (st_size, st_ino, st_dev...). By returning a dummy stat object, you break the stat interface, and I'm positive this *will* puzzle users and introduce errors. Now, if I'm the only one who finds this trick dangerous and ugly, you can go ahead, but I stand by my claim that it's definitely a bad idea (between this and the explicit Enum value assignent, I feel somewhat lost lately :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 08:54:43 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 06:54:43 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1299320278.86.0.403600489598.issue11406@psf.upfronthosting.co.za> Message-ID: <1367823283.66.0.679690277168.issue11406@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > (between this and the explicit Enum value assignent, I feel somewhat > lost lately :-) Don't worry, it sometimes happens :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 09:26:15 2013 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 06 May 2013 07:26:15 +0000 Subject: [issue13503] improved efficiency of bytearray pickling by using bytes type instead of str In-Reply-To: <1322611756.83.0.989666994675.issue13503@psf.upfronthosting.co.za> Message-ID: <1367825175.58.0.786648782155.issue13503@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Our hands are pretty much tied here. The pickle bytearray as unicode hack is likely the best we can do without pickling compatibility between Python 2 and 3. I can't think of a solution that could work here. For example. 1. Pickling bytearrays as a Python 2 str doesn't work because Python 2 strs are unpickled as unicode in Python 3. 2. Pickling bytearrays as an int lists makes the growth factor is much worst: 2x instead of the expected 1.5x. 3. Using a custom constructor breaks pickling compatibility with all the minor releases which doesn't implement the custom constructor. 4. Implementing special support in pickle for bytearrays requires a pickle protocol bump, which is disallowed for bugfixes releases. 5. Creating a special tag type to pickle Python 2 str as bytes in Python 3 has the same problem as #3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 11:08:56 2013 From: report at bugs.python.org (Ben Hoyt) Date: Mon, 06 May 2013 09:08:56 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1299320278.86.0.403600489598.issue11406@psf.upfronthosting.co.za> Message-ID: <1367831336.15.0.223604857326.issue11406@psf.upfronthosting.co.za> Ben Hoyt added the comment: > A normal "caller" would never expect a stat object to be partially populated: if a function has a prototype returning a stat object, then I definitely expect it to be a regular stat object, with all the fields guaranteed by POSIX set (st_size, st_ino, st_dev...). I don't think that's true in general, or true of how other Python APIs work. For instance, many APIs return a "file-like object", and you can only do certain things on that object, depending on what the documentation says, or what EAFP gets you. Some file-like object don't support seek/tell, some don't support close, etc. I've seen plenty of walk-like-a-duck checks like this: if hasattr(f, 'close'): f.close() Anyway, my point boils down to: * scandir() is a new function, so there aren't old trends or things that will break * we clearly document it as returning a tuple of (name, st), where st is a "stat-like object" whose invididual fields are None if they couldn't be determined for free with the directory scanning * in fact, that's kind of the point of the "st" object in this function, so the example could be the one I gave above where you call os.stat() if either of the fields you want is None * if that's clear in the documentation (of this new function) and the first example shows you exactly how it's meant to be used, I think that's pretty sane and sensible... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 11:11:20 2013 From: report at bugs.python.org (Christian Heimes) Date: Mon, 06 May 2013 09:11:20 +0000 Subject: [issue17913] stat.filemode returns "-" for sockets and unknown types Message-ID: <1367831480.84.0.461149512803.issue17913@psf.upfronthosting.co.za> New submission from Christian Heimes: The function stat.filemode() has a fallback to "-" for file type when it is unable to properly detect the type of a file. This gives wrong results for any file type that is not in the lookup table. For example it doesn't check for S_ISSOCK: >>> s = os.stat("/var/run/sdp") t >>> stat.filemode(s.st_mode) '-rw-rw-rw-' $ ls -la /var/run/sdp srw-rw-rw- 1 root root 0 Mai 2 16:08 /var/run/sdp Also see #11016 for more file types. I'm going to work on the matter soonish. ---------- messages: 188496 nosy: christian.heimes priority: normal severity: normal stage: needs patch status: open title: stat.filemode returns "-" for sockets and unknown types type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 11:13:30 2013 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 06 May 2013 09:13:30 +0000 Subject: [issue17884] Try to reuse stdint.h types like int32_t In-Reply-To: <1367362366.81.0.489465512002.issue17884@psf.upfronthosting.co.za> Message-ID: <1367831610.48.0.89026379115.issue17884@psf.upfronthosting.co.za> Mark Dickinson added the comment: [Victor] > Ok, I think I understood the issue :-) The problem is when the uint32_t > type is present but is not exactly 32-bit width. No, that's still not the issue :-). In any case, it would be a fairly serious violation of C99 to use uint32_t for something that *wasn't* exactly 32 bits in width. More generally, padding bits, trap representations, and non two's complement representations for signed integers seem to be a thing of the past; having integer types be exact width seems to be one of the few things that we *can* reasonably rely on. Concentrating on uint32_t for specificity, there are essentially three cases: (1) The platform (either in stdint.h or inttypes.h) #defines uint32_t. (2) The platform (either in stdint.h or inttypes.h) makes a typedef for uint32_t. (3) The platform doesn't do (1) *or* (2), but nevertheless, there's an unsigned integer type that has exact 32-bit width (and it's probably called "unsigned int"). [Oh, and (4) Windows. Let's leave that out of this discussion, since there don't seem to be any Windows-specific problems in practice here, and we don't use autoconf.] We've encountered all three of these cases, and as far as I know in recent history we haven't encountered a platform that doesn't match at least one of these three cases. With respect to the autoconf and pyport machinery: In case (1): AC_TYPE_UINT32_T does nothing, because uint32_t is already available, while the AC_CHECK_TYPE(uint32_t) #defines HAVE_UINT32_T. In case (2): AC_TYPE_UINT32_T still does nothing, and again AC_CHECK_TYPE(uint32_t) #defines HAVE_UINT32_T. In case (3): AC_TYPE_UINT32_T #defines uint32_t to be the appropriate type, and AC_CHECK_TYPE(uint32_t) will fail. So cases (1) and (3) lead to uint32_t being #defined, while cases (1) and (2) lead to HAVE_UINT32_T being defined. We want to catch all 3 cases, so we have to check for *both* uint32_t and HAVE_UINT32_T in pyport.h. Note that using AC_TYPE_UINT32_T and checking whether uint32_t is defined is not enough on platforms that do (2): because uint32_t is a typedef rather than a #define, there's no easy way for pyport.h to find it. Prior to the issue #10052 fix, we assumed that any platform doing (2) would, following C99, also define UINT32_MAX, but that turned out not to be true on some badly-behaved platforms. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 11:19:23 2013 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 06 May 2013 09:19:23 +0000 Subject: [issue17884] Try to reuse stdint.h types like int32_t In-Reply-To: <1367362366.81.0.489465512002.issue17884@psf.upfronthosting.co.za> Message-ID: <1367831963.74.0.948240614466.issue17884@psf.upfronthosting.co.za> Mark Dickinson added the comment: Stefan: sounds reasonable. I'd be happy to make availability of exact-width 32-bit and 64-bit, signed and unsigned integer types a requirement for building Python, provided that we run that by the python-dev mailing list first. I agree that this is what we seem to be doing in practice anyway, so we'd just be codifying existing practice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 11:35:21 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 06 May 2013 09:35:21 +0000 Subject: [issue16742] PyOS_Readline drops GIL and calls PyOS_StdioReadline, which isn't thread safe In-Reply-To: <1356086390.48.0.327620937355.issue16742@psf.upfronthosting.co.za> Message-ID: <1367832921.25.0.300064169781.issue16742@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: My quick and dirty fix is simple: _PyOS_ReadlineTState = PyThreadState_GET(); /* CCP change, cannot release the GIL here because PyOS_StdioReadline uses * the regular MALLOC */ /* Py_BEGIN_ALLOW_THREADS */ #ifdef WITH_THREAD PyThread_acquire_lock(_PyOS_ReadlineLock, 1); #endif /* This is needed to handle the unlikely case that the * interpreter is in interactive mode *and* stdin/out are not * a tty. This can happen, for example if python is run like * this: python -i < test1.py */ if (!isatty (fileno (sys_stdin)) || !isatty (fileno (sys_stdout))) rv = PyOS_StdioReadline (sys_stdin, sys_stdout, prompt); else rv = (*PyOS_ReadlineFunctionPointer)(sys_stdin, sys_stdout, prompt); /* Py_END_ALLOW_THREADS */ #ifdef WITH_THREAD PyThread_release_lock(_PyOS_ReadlineLock); #endif Basically, we just comment out the lock release since we don't need it. The reason we found this was that we were using GIL a custom mallocator which should have been run with the GIL but wasn?t. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 11:36:30 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 06 May 2013 09:36:30 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1367831336.15.0.223604857326.issue11406@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > I don't think that's true in general, or true of how other Python APIs work. For instance, many APIs return a "file-like object", and you can only do certain things on that object, depending on what the documentation says, or what EAFP gets you. Some file-like object don't support seek/tell, some don't support close, etc. I've seen plenty of walk-like-a-duck checks like this: Yes, I'm fully aware duck-typing ;-) But here, you're saying that "a duck has a beak, but it *may* have legs, a tail, etc". It's just looks wrong to me on so many levels. Please bring this up on python-dev. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 11:45:20 2013 From: report at bugs.python.org (Delhallt) Date: Mon, 06 May 2013 09:45:20 +0000 Subject: [issue8918] distutils test_config_cmd failure on Solaris In-Reply-To: <1275846660.59.0.731483262347.issue8918@psf.upfronthosting.co.za> Message-ID: <1367833520.84.0.540026396946.issue8918@psf.upfronthosting.co.za> Delhallt added the comment: For your information, with AIX 6.1, with both print line and preserve comment the output is not empty. Option -o, with i suffix always give error message /usr/vac/bin/xlc_r: 1501-218 (S) file _configline.i contains an incorrect file suffix #/usr/vac/bin/xlc_r -P _configtest.c -qppline -C #cat _configtest.i #line 1 "_configtest.c" /* xxx */ ---------- nosy: +delhallt versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 11:47:42 2013 From: report at bugs.python.org (Thomas Kluyver) Date: Mon, 06 May 2013 09:47:42 +0000 Subject: [issue11816] Refactor the dis module to provide better building blocks for bytecode analysis In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za> Message-ID: <1367833662.23.0.209837656863.issue11816@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Ping - the latest patches (dis_api3 & test_peepholer) are ready for review when someone's got a moment. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 12:46:50 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 May 2013 10:46:50 +0000 Subject: [issue13813] "sysconfig.py" and "distutils/util.py" redundancy In-Reply-To: <1326859118.01.0.584725172013.issue13813@psf.upfronthosting.co.za> Message-ID: <3b40xj6mnXz7LjW@mail.python.org> Roundup Robot added the comment: New changeset c4f92b597074 by Richard Oudkerk in branch 'default': Issue #13813: Embed stringification of remote traceback in local http://hg.python.org/cpython/rev/c4f92b597074 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 13:02:17 2013 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 06 May 2013 11:02:17 +0000 Subject: [issue11734] Add half-float (16-bit) support to struct module In-Reply-To: <1301619617.43.0.214438166588.issue11734@psf.upfronthosting.co.za> Message-ID: <1367838137.08.0.0981797743277.issue11734@psf.upfronthosting.co.za> Mark Dickinson added the comment: Refreshed patch, with a few minor updates: - Use copysign instead of signbit (we don't currently check for signbit in the configure scripts); only check for negative zero when we've already checked equality with 0.0. - Use Py_IS_NAN and Py_IS_INFINITY instead of isinf and isnan. - Add an extra check for really tiny numbers in _PyFloat_Pack2 to avoid binary64 subnormals in intermediate calculations. - Remove a duplicate check for the case x == 0.0 in _PyFloat_Pack2. - Make unpacking of ints and nans behave in the same way as float("inf") or float("nan"): use _Py_dg_infinity and _Py_dg_stdnan if available, else fall back to Py_HUGE_VAL and Py_NAN. - Minor style nits (braces; use floating-point constants when comparing with floats; consistent capitalization for hex literals, etc.) ---------- Added file: http://bugs.python.org/file30145/cpython-struct-float16-v6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 13:06:12 2013 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 06 May 2013 11:06:12 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1367838372.94.0.946402153809.issue5845@psf.upfronthosting.co.za> Mark Dickinson added the comment: On OS X 10.6, I now get the following message at interpreter startup: iwasawa:cpython mdickinson$ ./python.exe Python 3.4.0a0 (default:d5ef330bac50, May 6 2013, 13:05:57) [GCC 4.2.1 (Apple Inc. build 5664)] on darwin Type "help", "copyright", "credits" or "license" for more information. Failed calling sys.__interactivehook__ Traceback (most recent call last): File "/Users/mdickinson/Python/cpython/Lib/site.py", line 481, in register_readline readline.read_init_file() OSError: [Errno -1] Unknown error: -1 ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 13:06:47 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 06 May 2013 11:06:47 +0000 Subject: [issue17914] add os.cpu_count() Message-ID: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> New submission from Charles-Fran?ois Natali: multiprocessing.cpu_count() implementation should be made available in the os module, where it belongs. ---------- keywords: easy messages: 188506 nosy: neologix priority: normal severity: normal stage: needs patch status: open type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 13:11:52 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 06 May 2013 11:11:52 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1367838712.97.0.645905876761.issue17914@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Note that I think it might be interesting to return 1 if the actual value cannot be determined, since that's a sensible default, and likely what the caller will do anyway. This contrasts with the current multiprocessing's implementation which raised NotImplementedError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 13:14:06 2013 From: report at bugs.python.org (Simon Conseil) Date: Mon, 06 May 2013 11:14:06 +0000 Subject: [issue17915] Encoding error with sax and codecs Message-ID: <1367838846.54.0.113997926456.issue17915@psf.upfronthosting.co.za> New submission from Simon Conseil: There is an encoding issue between codecs.open and sax (see attached file). The issue is reproducible on Python 3.3.1, it is working fine on Python 3.3.0 ---------- components: Library (Lib) files: report.txt messages: 188508 nosy: sconseil priority: normal severity: normal status: open title: Encoding error with sax and codecs versions: Python 3.3 Added file: http://bugs.python.org/file30146/report.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 13:15:15 2013 From: report at bugs.python.org (Ned Batchelder) Date: Mon, 06 May 2013 11:15:15 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1367838915.93.0.857696464467.issue17914@psf.upfronthosting.co.za> Ned Batchelder added the comment: If you can't determine the number of CPUs, return a clear "can't determine" value, such as 0 or -1. Returning 1 will hide information, and it's an easy default for the caller to apply if they want to. ---------- nosy: +nedbat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 13:15:19 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 May 2013 11:15:19 +0000 Subject: [issue17805] No such class: multiprocessing.pool.AsyncResult In-Reply-To: <1366494249.42.0.0654021028594.issue17805@psf.upfronthosting.co.za> Message-ID: <3b41ZZ4DsZz7Ll2@mail.python.org> Roundup Robot added the comment: New changeset 2684176519ef by Richard Oudkerk in branch '2.7': Issue #17805: Add AsyncResult alias for ApplyResult http://hg.python.org/cpython/rev/2684176519ef New changeset bb4bb2db6106 by Richard Oudkerk in branch '3.3': Issue #17805: Add AsyncResult alias for ApplyResult http://hg.python.org/cpython/rev/bb4bb2db6106 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 13:21:21 2013 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 06 May 2013 11:21:21 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1367839281.09.0.821812310015.issue5845@psf.upfronthosting.co.za> Mark Dickinson added the comment: More information: readline.read_init_file() produced the same traceback before this commit, so all that's changed is that we're now calling this at interpreter startup. It looks like I'm using the system libedit: iwasawa:cpython mdickinson$ otool -L build/lib.macosx-10.6-x86_64-3.4-pydebug/readline.so build/lib.macosx-10.6-x86_64-3.4-pydebug/readline.so: /usr/lib/libedit.2.dylib (compatibility version 2.0.0, current version 2.11.0) /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11) iwasawa:cpython mdickinson$ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 13:25:57 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 May 2013 11:25:57 +0000 Subject: [issue13813] "sysconfig.py" and "distutils/util.py" redundancy In-Reply-To: <1326859118.01.0.584725172013.issue13813@psf.upfronthosting.co.za> Message-ID: <3b41pr69hpzPkT@mail.python.org> Roundup Robot added the comment: New changeset a2928dd2fde4 by Richard Oudkerk in branch 'default': Correct issue number for c4f92b597074 in Misc/NEWS from #13813 to #13831 http://hg.python.org/cpython/rev/a2928dd2fde4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 13:25:58 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 May 2013 11:25:58 +0000 Subject: [issue13831] get method of multiprocessing.pool.Async should return full traceback In-Reply-To: <1327006000.05.0.152231015377.issue13831@psf.upfronthosting.co.za> Message-ID: <3b41ps4dfwzPkT@mail.python.org> Roundup Robot added the comment: New changeset a2928dd2fde4 by Richard Oudkerk in branch 'default': Correct issue number for c4f92b597074 in Misc/NEWS from #13813 to #13831 http://hg.python.org/cpython/rev/a2928dd2fde4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 13:27:26 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 06 May 2013 11:27:26 +0000 Subject: [issue17805] No such class: multiprocessing.pool.AsyncResult In-Reply-To: <1366494249.42.0.0654021028594.issue17805@psf.upfronthosting.co.za> Message-ID: <1367839646.11.0.788919314122.issue17805@psf.upfronthosting.co.za> Changes by Richard Oudkerk : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 13:40:27 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 06 May 2013 11:40:27 +0000 Subject: [issue13831] get method of multiprocessing.pool.Async should return full traceback In-Reply-To: <1327006000.05.0.152231015377.issue13831@psf.upfronthosting.co.za> Message-ID: <1367840427.81.0.722960544332.issue13831@psf.upfronthosting.co.za> Changes by Richard Oudkerk : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 13:47:49 2013 From: report at bugs.python.org (Kushal Das) Date: Mon, 06 May 2013 11:47:49 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1367840869.76.0.518829081219.issue17914@psf.upfronthosting.co.za> Kushal Das added the comment: I am interested to submit a patch on this. Should I move the implementation to os module and made the multiprocessing one as an alias ? or keep it in both places ? I prefer the idea of returning -1 instead of the current way of raising NotImplementedError in case we can not determine the number of CPU(s). ---------- nosy: +kushaldas _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 13:52:15 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 06 May 2013 11:52:15 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367840869.76.0.518829081219.issue17914@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > I am interested to submit a patch on this. Should I move the implementation to os module and made the multiprocessing one as an alias ? or keep it in both places ? Yes, you should move it, add a corresponding documentation to Doc/modules/os.rst (you can probably reuse the multiprocessing doc), and add a test in Lib/test/test_os.py (you can also probably reuse the multiprocessing test). > I prefer the idea of returning -1 instead of the current way of raising NotImplementedError in case we can not determine the number of CPU(s). Seriously, I don't see what this brings. Since the user can't do anything except using 1 instead, why not do this in the library? I've searched a bit, and other platforms (.e.g Java, Ruby) don't raise an exception, and always return a positive value. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 14:00:06 2013 From: report at bugs.python.org (Ned Batchelder) Date: Mon, 06 May 2013 12:00:06 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1367841606.62.0.563438659204.issue17914@psf.upfronthosting.co.za> Ned Batchelder added the comment: Seriously, return zero, and I can use it as: cpu_count = os.cpu_count() or 1 Why throw away information? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 14:20:34 2013 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 06 May 2013 12:20:34 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1367842834.92.0.818033595352.issue5845@psf.upfronthosting.co.za> Mark Dickinson added the comment: So I'm failing to find any documentation for libedit, but it looks as though this error occurs if rl_read_init_file fails to find an .editrc file in the appropriate place. If I create an empty .editrc file in my home directory, the error disappears. (Having an .inputrc file doesn't seem to make a difference either way.) Perhaps the solution is to ignore an OSError from readline.read_init_file in register_readline---i.e., add a try / except OSError there. The other option would be to ignore a nonzero errno from rl_read_init_file, but that doesn't sound so good: I'd expect someone deliberately calling readline.read_init_file to get an exception if the initialization file isn't found. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 14:22:14 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 May 2013 12:22:14 +0000 Subject: [issue17884] Try to reuse stdint.h types like int32_t In-Reply-To: <1367831610.48.0.89026379115.issue17884@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: 2013/5/6 Mark Dickinson : > Concentrating on uint32_t for specificity, there are essentially three cases: > > (1) The platform (either in stdint.h or inttypes.h) #defines uint32_t. > > (2) The platform (either in stdint.h or inttypes.h) makes a typedef for uint32_t. > > (3) The platform doesn't do (1) *or* (2), but nevertheless, there's an unsigned integer type that has exact 32-bit width (and it's probably called "unsigned int"). So in all these 3 cases, it is possible to use "uint32_t" in the code. > [Oh, and (4) Windows. Let's leave that out of this discussion, since there don't seem to be any Windows-specific problems in practice here, and we don't use autoconf.] Windows issues can be fixed in PC/pyconfig.h. > So cases (1) and (3) lead to uint32_t being #defined, while cases (1) and (2) lead to HAVE_UINT32_T being defined. We want to catch all 3 cases, so we have to check for *both* uint32_t and HAVE_UINT32_T in pyport.h. Sorry I still don't understand why do you need HAVE_UINT32_T define. According to what you wrote above, uint32_t can always be used on any platform. > Note that using AC_TYPE_UINT32_T and checking whether uint32_t is defined is not enough on platforms that do (2): because uint32_t is a typedef rather than a #define, there's no easy way for pyport.h to find it. Prior to the issue #10052 fix, we assumed that any platform doing (2) would, following C99, also define UINT32_MAX, but that turned out not to be true on some badly-behaved platforms. Why should Python do extra checks in pyport.h (ex: check if UINT32_MAX is available)? Can't we rely on stdint.h? If stdint.h is not available, we can ask configure to build it for us using AX_CREATE_STDINT_H. Oh, it looks like this macro is not part of autotools directly. It's a third party module released under the GNU GPLv3+ license. Can we include a GPL script in our tool chain? I contacted the author by email to ask him if we can distribute it under a different license (compatible with the Python license). http://www.gnu.org/software/autoconf-archive/ax_create_stdint_h.html http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=history;f=m4/ax_create_stdint_h.m4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 14:26:19 2013 From: report at bugs.python.org (Christian Heimes) Date: Mon, 06 May 2013 12:26:19 +0000 Subject: [issue11016] Add S_ISDOOR to the stat module In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za> Message-ID: <1367843179.88.0.255238187345.issue11016@psf.upfronthosting.co.za> Christian Heimes added the comment: I have created a C implementation of the stat module for Python 3.4. It implements all current features, handling for DOOR, PORT, WHT and a fix for #17913. The first half of the file has lots of #ifndef checks. I'm not sure if they are really required. I guess they are required for the tarfile module on Windows. ---------- stage: -> patch review Added file: http://bugs.python.org/file30147/statmodule.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 14:27:12 2013 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 06 May 2013 12:27:12 +0000 Subject: [issue17884] Try to reuse stdint.h types like int32_t In-Reply-To: <1367362366.81.0.489465512002.issue17884@psf.upfronthosting.co.za> Message-ID: <1367843232.6.0.773252766013.issue17884@psf.upfronthosting.co.za> Mark Dickinson added the comment: > According to what you wrote above, uint32_t can always be used on any > platform. The issue is in *detecting* whether uint32_t exists or not. In cases (1) and (3), that can be done in the preprocessor with an "#ifdef uint32_t". In case (2), it can't: the check fails, because uint32_t isn't a preprocessor define---it's a typedef. *That's* why we need the HAVE_UINT32_T check. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 14:27:25 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 12:27:25 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1367842834.92.0.818033595352.issue5845@psf.upfronthosting.co.za> Message-ID: <1556055256.19527885.1367843239736.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > So I'm failing to find any documentation for libedit, but it looks as > though this error occurs if rl_read_init_file fails to find an > .editrc file in the appropriate place. If I create an empty .editrc > file in my home directory, the error disappears. (Having an > .inputrc file doesn't seem to make a difference either way.) > > Perhaps the solution is to ignore an OSError from > readline.read_init_file in register_readline---i.e., add a try / > except OSError there. This sounds fine to me. Can you propose a patch? I'm unlikely to ever have an OS X machine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 14:29:31 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 12:29:31 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1367843371.53.0.644382552926.issue17914@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Returning 0 or None sounds better to me than 1 or -1. (I have a preference for None) ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 14:34:14 2013 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 06 May 2013 12:34:14 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1367843654.87.0.33393482562.issue5845@psf.upfronthosting.co.za> Mark Dickinson added the comment: The attached fixes the issue for me. I'm not sure whether the try / except should only be done on Apple, though. What's the behaviour on Linux if there's no .inputrc file? ---------- Added file: http://bugs.python.org/file30148/issue5845_osx_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 14:42:32 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 12:42:32 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1367843654.87.0.33393482562.issue5845@psf.upfronthosting.co.za> Message-ID: <118043128.19565446.1367844146413.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > The attached fixes the issue for me. I'm not sure whether the try / > except should only be done on Apple, though. What's the behaviour > on Linux if there's no .inputrc file? Everything works fine under Linux (as usual :-)). There's no need to restrict the try / except to Apple platforms, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 14:46:53 2013 From: report at bugs.python.org (Steven D'Aprano) Date: Mon, 06 May 2013 12:46:53 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1367844413.46.0.88202212782.issue5845@psf.upfronthosting.co.za> Steven D'Aprano added the comment: I'm not able to test the patch at the moment, but since it essentially just uses the recipe in the docs, I expect it will have the same side-effect. Namely, it prevents you using the tab key to indent in the interactive interpreter. Now I don't know if I'm missing something painfully obvious, but having to bang out space-space-space-space for every indent is surely not going to be a win for usability ;-) Even if I am missing something, surely so will a lot of other users. I use a readline completer that (in my opinion) does the Right Thing: at the start of the line, hitting TAB inserts a tab, otherwise it does completion. It also sets a history file, adds a couple of key bindings that I sometimes find useful, and wraps it all up in a class. (Attached.) If you think there is any value in this, I'm happy to update it to Python 3.3 and polish it up as a patch to the readline module. Or someone can just mine it for ideas. ---------- Added file: http://bugs.python.org/file30149/completer.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 14:50:41 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 06 May 2013 12:50:41 +0000 Subject: [issue11016] Add S_ISDOOR to the stat module In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za> Message-ID: <1367844641.05.0.0479981748498.issue11016@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Christian, could you post it as a mercurial diff for review? Also, it would maybe be better to rename this issue to "rewrite stat module in C". Shouldn't we also remove the Python version? ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 14:53:19 2013 From: report at bugs.python.org (Guido Draheim 2011) Date: Mon, 06 May 2013 12:53:19 +0000 Subject: [issue17884] Try to reuse stdint.h types like int32_t In-Reply-To: <1367362366.81.0.489465512002.issue17884@psf.upfronthosting.co.za> Message-ID: <1367844799.31.0.83584090219.issue17884@psf.upfronthosting.co.za> Guido Draheim 2011 added the comment: Relicensing to Python core from my Opensource-licensed material is always permitted, including ax_create_stdint_h.m4 ---------- nosy: +guidod-2011 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 14:54:24 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 06 May 2013 12:54:24 +0000 Subject: [issue17916] Provide dis.Bytecode based equivalent of dis.distb Message-ID: <1367844864.14.0.49825143621.issue17916@psf.upfronthosting.co.za> New submission from Nick Coghlan: Issue 11816 adds a new dis.Bytecode API that replaces most of the dis functions, but doesn't cover dis.distb. A dis.Bytecode.from_tb class method, or a TracebackBytecode subclass to handle that use case may be desirable. ---------- messages: 188528 nosy: ncoghlan priority: normal severity: normal stage: needs patch status: open title: Provide dis.Bytecode based equivalent of dis.distb type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 14:54:32 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 06 May 2013 12:54:32 +0000 Subject: [issue17916] Provide dis.Bytecode based equivalent of dis.distb In-Reply-To: <1367844864.14.0.49825143621.issue17916@psf.upfronthosting.co.za> Message-ID: <1367844872.25.0.0299300234814.issue17916@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- dependencies: +Refactor the dis module to provide better building blocks for bytecode analysis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 15:02:42 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 06 May 2013 13:02:42 +0000 Subject: [issue11816] Refactor the dis module to provide better building blocks for bytecode analysis In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za> Message-ID: <1367845362.24.0.149983765338.issue11816@psf.upfronthosting.co.za> Nick Coghlan added the comment: I created issue 17916 after realising that the new OO API doesn't yet provide an equivalent to dis.distb that returns an appropriate Bytecode object. (I don't think it makes sense to hold up this patch for that change) ---------- assignee: -> ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 15:02:50 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 06 May 2013 13:02:50 +0000 Subject: [issue11816] Refactor the dis module to provide better building blocks for bytecode analysis In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za> Message-ID: <1367845370.42.0.257125797115.issue11816@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 15:06:02 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 13:06:02 +0000 Subject: [issue17911] Extracting tracebacks does too much work In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1367845562.6.0.684303204249.issue17911@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think instead we may want to add a finalize() or close() method on frame objects which would clear all local variables (as well as dereference the globals dict, perhaps), after having optionally run a generator's close() method (if the frame belongs to a generator). If I'm not mistaken, it should allow breaking reference cycles, and remove the need for complex traceback processing, which Twisted currently also does: http://twistedmatrix.com/trac/browser/trunk/twisted/python/failure.py#L89 Note that generator cleanup through the frame has a patch in issue17807. ---------- nosy: +ncoghlan, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 15:10:37 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 06 May 2013 13:10:37 +0000 Subject: [issue17917] use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() when applicable Message-ID: <1367845837.62.0.789153792923.issue17917@psf.upfronthosting.co.za> New submission from Charles-Fran?ois Natali: In many cases, PyModule_AddIntMacro() could be used instead of PyModule_AddIntConstant(), e.g. in socketmodule.c and posixmodule.c: PyModule_AddIntMacro(m, AF_INET6); vs (currently) PyModule_AddIntConstant(m, "AF_INET6", AF_INET6); It reduces the possibility of typo and is less verbose. ---------- keywords: easy messages: 188531 nosy: neologix priority: low severity: normal stage: needs patch status: open title: use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() when applicable type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 15:24:02 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 13:24:02 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1367844413.46.0.88202212782.issue5845@psf.upfronthosting.co.za> Message-ID: <1610220362.19668887.1367846636497.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > Now I don't know if I'm missing something painfully obvious, but > having to bang out space-space-space-space for every indent is > surely not going to be a win for usability ;-) Even if I am missing > something, surely so will a lot of other users. What *looks* painfully obvious to me is that Python doesn't force you to use 4 spaces (or tabs) for indents :-) > I use a readline completer that (in my opinion) does the Right Thing: > at the start of the line, hitting TAB inserts a tab, otherwise it > does completion. It also sets a history file, adds a couple of key > bindings that I sometimes find useful, and wraps it all up in a > class. The "indent at beginning of line" thing sounds useful. The rest seems to conflate the concept of a completer with the readline module itself. Even though it's called rlcompleter, the rlcompleter module is actually generic and could be used with other input schemes, so I don't think it's the right place to set history options or key bindings. In any case, you should post your patch as part of a separate issue, IMO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 15:39:47 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 May 2013 13:39:47 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <3b44nG5BH3zMp1@mail.python.org> Roundup Robot added the comment: New changeset 82e92da929eb by Mark Dickinson in branch 'default': Issue #5845: avoid an exception at startup on OS X if no .editrc file exists. http://hg.python.org/cpython/rev/82e92da929eb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 15:40:47 2013 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 06 May 2013 13:40:47 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1367847647.74.0.658172249648.issue5845@psf.upfronthosting.co.za> Mark Dickinson added the comment: Applied the OS X fix; reclosing. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 15:44:31 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 May 2013 13:44:31 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1367847871.67.0.362206729606.issue5845@psf.upfronthosting.co.za> R. David Murray added the comment: The tab-doesn't-indent still needs to be fixed before 3.4 is released. ---------- nosy: +larry priority: normal -> release blocker resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 15:53:16 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 06 May 2013 13:53:16 +0000 Subject: [issue11816] Refactor the dis module to provide better building blocks for bytecode analysis In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za> Message-ID: <1367848396.42.0.587661751064.issue11816@psf.upfronthosting.co.za> Nick Coghlan added the comment: Good thing test_peepholer was moved out to a separate patch - a failure of that picked up a bug in the new disassembly output (unifying the handling of name and constant dereferences had changed the way constant strings were reported in the disassembly, and the error was consistent in both the new implementation and in the new tests due to the way the expected test results had been generated) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 15:59:48 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 May 2013 13:59:48 +0000 Subject: [issue11816] Refactor the dis module to provide better building blocks for bytecode analysis In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za> Message-ID: <3b45DM2dBpzNHJ@mail.python.org> Roundup Robot added the comment: New changeset f65b867ce817 by Nick Coghlan in branch 'default': Issue #11816: multiple improvements to the dis module http://hg.python.org/cpython/rev/f65b867ce817 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 16:03:13 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 May 2013 14:03:13 +0000 Subject: [issue11816] Refactor the dis module to provide better building blocks for bytecode analysis In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za> Message-ID: <3b45JJ2whwzNHP@mail.python.org> Roundup Robot added the comment: New changeset d3fee4c64654 by Nick Coghlan in branch 'default': Issue #11816: switch test_peepholer to bytecode_helper http://hg.python.org/cpython/rev/d3fee4c64654 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 16:05:23 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 06 May 2013 14:05:23 +0000 Subject: [issue11816] Refactor the dis module to provide better building blocks for bytecode analysis In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za> Message-ID: <1367849123.12.0.0559039624988.issue11816@psf.upfronthosting.co.za> Nick Coghlan added the comment: And two-and-a-bit years later, we're done - thanks all, any further feedback or problems can be filed as a new issue :) ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 16:06:52 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 14:06:52 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1367847871.67.0.362206729606.issue5845@psf.upfronthosting.co.za> Message-ID: <672943187.19775865.1367849206265.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > The tab-doesn't-indent still needs to be fixed before 3.4 is > released. I don't really understand why this would be a release blocker? The interpreter prompt is a convenience, we don't guarantee compatibility like with stdlib APIs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 16:08:37 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 06 May 2013 14:08:37 +0000 Subject: [issue15494] Move test/support.py into a test.support subpackage In-Reply-To: <1343612231.54.0.0439576601623.issue15494@psf.upfronthosting.co.za> Message-ID: <1367849317.55.0.0130709110357.issue15494@psf.upfronthosting.co.za> Nick Coghlan added the comment: Ah, I *thought* there was another module that started me down this path. Issue 11816 (a dis module upgrade that I finally deemed ready enough to commit) added "test.bytecode_helper", so the new test.support package will consist of at least: support/__init__.py # Current test.support support/bytecode_helper.py # Current test.bytecode_helper support/pkg_helper.py # New for test_runpy & test_pkgutil support/script_helper.py # Current test.script_helper ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 16:14:42 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 May 2013 14:14:42 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1367849682.62.0.787634346153.issue5845@psf.upfronthosting.co.za> R. David Murray added the comment: It is a release blocker because it is a major usability regression. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 16:17:58 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 May 2013 14:17:58 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1367849878.13.0.713810247403.issue5845@psf.upfronthosting.co.za> R. David Murray added the comment: Just to be clear how important I consider this, I would advocate for backing out this patch rather than releasing 3.4 with a broken tab key at the interactive prompt. But I'd rather have the patch *and* a working tab key. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 16:27:32 2013 From: report at bugs.python.org (Peter Saveliev) Date: Mon, 06 May 2013 14:27:32 +0000 Subject: [issue17918] failed incoming SSL connection stays open forever Message-ID: <1367850452.92.0.464255806144.issue17918@psf.upfronthosting.co.za> New submission from Peter Saveliev: Important: only Python2 versions are affected. Python3 works OK. Possibly related issue: http://bugs.python.org/issue12378 (differs: see the line above) Having a server with SSLSocket waiting for connections, the incoming connection, failed on automatic do_handshake(), stays open forever ? accept() raises the SSLError and does not return client connection socket. Steps to reproduce ================== server side: 1. create a SOCK_STREAM socket 2. wrap it with wrap_socket() 3. listen() 4. accept() client side: 1. telnet to this port 2. enter any random text How reproducible ================ In all 146% Expected results ================ 1. Incoming connection is closed and client disconnected Actual results ============== 1. On the server side, due to exception, the reference to the incoming connection gets lost. 2. The client stays connected as long as the server operates. ---------- files: ssl_handshake_testcase.py messages: 188544 nosy: Peter.Saveliev priority: normal severity: normal status: open title: failed incoming SSL connection stays open forever type: resource usage versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file30150/ssl_handshake_testcase.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 16:36:56 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 06 May 2013 14:36:56 +0000 Subject: [issue16316] Support xz compression in mimetypes module In-Reply-To: <1351114845.07.0.378323444057.issue16316@psf.upfronthosting.co.za> Message-ID: <1367851016.95.0.441142523488.issue16316@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 16:39:26 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 May 2013 14:39:26 +0000 Subject: [issue11016] Add S_ISDOOR to the stat module In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za> Message-ID: <1367851166.35.0.724726952195.issue11016@psf.upfronthosting.co.za> R. David Murray added the comment: We've been *adding* python implementations for other modules, so I don't see why we would remove this one. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 16:39:37 2013 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 06 May 2013 14:39:37 +0000 Subject: [issue17911] Extracting tracebacks does too much work In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1367851177.58.0.908089384471.issue17911@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm not snubbing my nose at something that breaks these types of cycles more easily, but I still think that the abstractions offered by the traceback module could be improved. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 16:40:06 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 14:40:06 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1367849682.62.0.787634346153.issue5845@psf.upfronthosting.co.za> Message-ID: <1706586976.19848482.1367851200235.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > It is a release blocker because it is a major usability regression. Really? You can press the space key to indent, it works as well as the tab key... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 16:41:16 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 14:41:16 +0000 Subject: [issue11016] Add S_ISDOOR to the stat module In-Reply-To: <1367851166.35.0.724726952195.issue11016@psf.upfronthosting.co.za> Message-ID: <345571455.19851743.1367851270409.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > We've been *adding* python implementations for other modules, so I > don't see why we would remove this one. Well, the one reason is that the C constants aren't accessible from Python code. Once the constants are there, the rest is so trivial that it doesn't really deserve a pure Python alternative, IMHO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 16:44:00 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 06 May 2013 14:44:00 +0000 Subject: [issue11016] Add S_ISDOOR to the stat module In-Reply-To: <1367851166.35.0.724726952195.issue11016@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > We've been *adding* python implementations for other modules, so I don't see why we would remove this one. Because it's buggy, and cannot be implemented correctly in python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 16:44:02 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 May 2013 14:44:02 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1367851442.81.0.408784845916.issue5845@psf.upfronthosting.co.za> R. David Murray added the comment: Well, post it to python-dev and see what reaction you get :) I could be wrong, but I don't think I am (obviously). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 16:37:45 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 06 May 2013 14:37:45 +0000 Subject: [issue17732] distutils.cfg Can Break venv In-Reply-To: <1365963032.26.0.766714843383.issue17732@psf.upfronthosting.co.za> Message-ID: <1367851065.64.0.682268722773.issue17732@psf.upfronthosting.co.za> ?ric Araujo added the comment: No, patch is good to go, I just need to find some time to commit it. If another core dev wants to do it sooner, please feel free to do so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 16:45:27 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 06 May 2013 14:45:27 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1367851527.39.0.332439874688.issue5845@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I expect that a lot of users use the tab key to indent in the repl (as well as in editors, smart enough editors can convert the tab presses to spaces) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 16:46:52 2013 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 06 May 2013 14:46:52 +0000 Subject: [issue17911] Extracting tracebacks does too much work In-Reply-To: <1367845562.6.0.684303204249.issue17911@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: On Mon, May 6, 2013 at 6:06 AM, Antoine Pitrou wrote: > Note that generator cleanup through the frame has a patch in issue17807. Sadly that doesn't help with my issue. I applied path gen3.patch and ran various versions of the code I have. There's still something holding on to the Task or the exception. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 16:52:07 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 14:52:07 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1367851442.81.0.408784845916.issue5845@psf.upfronthosting.co.za> Message-ID: <1756035604.19879421.1367851921706.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > Well, post it to python-dev and see what reaction you get :) I'm not interested in python-dev reactions here. For this kind of issue, we'll have hundreds of messages for and against the change without any useful content. The commit adds an often-requested feature (to the point that many people were already taking the pain of activating it manually). But, yes, we could add Steven's refinement so that all bases are covered. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 16:53:05 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 14:53:05 +0000 Subject: [issue17911] Extracting tracebacks does too much work In-Reply-To: Message-ID: <723875373.19881474.1367851979609.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > On Mon, May 6, 2013 at 6:06 AM, Antoine Pitrou > wrote: > > Note that generator cleanup through the frame has a patch in > > issue17807. > > Sadly that doesn't help with my issue. It won't. It's just a building block for the change I've proposed here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 16:57:07 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 14:57:07 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1367851527.39.0.332439874688.issue5845@psf.upfronthosting.co.za> Message-ID: <265545000.19890952.1367852220721.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > I expect that a lot of users use the tab key to indent in the repl > (as well as in editors, smart enough editors can convert the tab > presses to spaces) The interpreter prompt is not a text editor at all. You can misuse it as one, but that's a loss of time and energy IMO. Really, everyone I've ever showed tab-completion to has always been enthusiastic about it ("why isn't this enabled by default?"). None has ever raised the concern of being able to use the tab key to indent code under the prompt. (probably because noone is crazy enough to type long chunks of code under the interactive prompt anyway) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 17:06:57 2013 From: report at bugs.python.org (Delhallt) Date: Mon, 06 May 2013 15:06:57 +0000 Subject: [issue17919] AIX POLLNVAL definition causes problems Message-ID: <1367852817.71.0.664729704726.issue17919@psf.upfronthosting.co.za> New submission from Delhallt: I encounted exactly the same issue http://bugs.python.org/issue923315 with test_asyncore, test_asynchat and test_poll. On AIX6.1, POLLNVAL=0x8000=SHRT_MIN=SHRT_MAX+1 (on 2 bytes) and parsing events with PyArg_ParseTuple as a signed short 'h' do not work, i.e "OverflowError: signed short integer is greater than maximum" occurs. I changed 'h' to 'H' in the attached patch, and delete associated Overflow test. Perhaps, they're a better way to handle that ? ---------- components: Extension Modules files: Python-2.7.4-pollnval.patch keywords: patch messages: 188558 nosy: delhallt priority: normal severity: normal status: open title: AIX POLLNVAL definition causes problems type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file30151/Python-2.7.4-pollnval.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 17:27:20 2013 From: report at bugs.python.org (Christian Heimes) Date: Mon, 06 May 2013 15:27:20 +0000 Subject: [issue17913] stat.filemode returns "-" for sockets and unknown types In-Reply-To: <1367831480.84.0.461149512803.issue17913@psf.upfronthosting.co.za> Message-ID: <1367854040.26.0.429366906703.issue17913@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- components: +Library (Lib) keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file30152/filemode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 17:30:01 2013 From: report at bugs.python.org (Peter Saveliev) Date: Mon, 06 May 2013 15:30:01 +0000 Subject: [issue17918] failed incoming SSL connection stays open forever In-Reply-To: <1367850452.92.0.464255806144.issue17918@psf.upfronthosting.co.za> Message-ID: <1367854201.5.0.944559371156.issue17918@psf.upfronthosting.co.za> Peter Saveliev added the comment: Possible solution would be something like that in SSLSocket.do_handshake(): try: self._sslobj.do_handshake() except SSLError as e: # or even any Exception? self._sock.close() raise e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 17:34:45 2013 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 06 May 2013 15:34:45 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1367854485.95.0.976148561509.issue5845@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I am in AP's camp on the tab issue, but I think we can preserve "tab inserts tab" behavior at the continuation prompt. I don't like "indent at beginning of line." I have rlcompleter enabled in Python 2.6 and i get the following when I press tab: Python 2.6.6 (r266:84292, Feb 22 2013, 00:00:18) [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> Display all 173 possibilities? (y or n) y ArithmeticError( abs( input( AssertionError( all( int( AttributeError( and intern( BaseException( any( is .. I find this rather useful. At the ... prompt, however, a tab (or better four spaces) is arguably the right completion at the beginning of the line. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 17:35:17 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 May 2013 15:35:17 +0000 Subject: [issue11016] Add S_ISDOOR to the stat module In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za> Message-ID: <1367854517.13.0.344334427715.issue11016@psf.upfronthosting.co.za> R. David Murray added the comment: "Cannot be implemented correctly in Python" is a darned good reason :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 17:40:26 2013 From: report at bugs.python.org (Christian Heimes) Date: Mon, 06 May 2013 15:40:26 +0000 Subject: [issue11016] Add S_ISDOOR to the stat module In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za> Message-ID: <1367854826.13.0.769908258509.issue11016@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- keywords: +patch Added file: http://bugs.python.org/file30153/statmodule.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 18:14:15 2013 From: report at bugs.python.org (Zachary Ware) Date: Mon, 06 May 2013 16:14:15 +0000 Subject: [issue17883] Fix buildbot testing of Tkinter In-Reply-To: <1367355915.98.0.26398929673.issue17883@psf.upfronthosting.co.za> Message-ID: <1367856855.33.0.884534306219.issue17883@psf.upfronthosting.co.za> Zachary Ware added the comment: Here's the relevant bit of the output from that buildbot after Terry's change: ====================================================================== FAIL: testLoadWithUNC (test.test_tcl.TclTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "E:\Data\buildslave\cpython\2.7.snakebite-win2k3r2sp2-x86\build\lib\test\test_tcl.py", line 151, in testLoadWithUNC self.assertIn('Tkinter.py', f.read()) AssertionError: 'Tkinter.py' not found in '' ---------------------------------------------------------------------- ...which doesn't say much. Here's a patch that updates the test to use subprocess.Popen instead of os.popen and add some useful debugging information. The test passes on my machine with and without the patch, so I can't do much more debugging until we get some useful output from the buildbot. ---------- Added file: http://bugs.python.org/file30154/issue17883.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 18:48:53 2013 From: report at bugs.python.org (Zachary Ware) Date: Mon, 06 May 2013 16:48:53 +0000 Subject: [issue14187] add "function annotation" entry to Glossary In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za> Message-ID: <1367858933.29.0.148308514628.issue14187@psf.upfronthosting.co.za> Zachary Ware added the comment: Would anyone mind committing this? It was approved by Raymond almost a year ago now, and is still accurate. The patch still applies cleanly to 3.3 and default, though with some fuzz. ---------- versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 18:59:26 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 May 2013 16:59:26 +0000 Subject: [issue14187] add "function annotation" entry to Glossary In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za> Message-ID: <3b49Cf0TlNzMp1@mail.python.org> Roundup Robot added the comment: New changeset e2a805281d26 by R David Murray in branch '3.3': #14187: Add glossary entry for 'function annotations'. http://hg.python.org/cpython/rev/e2a805281d26 New changeset 3e1c45f5c585 by R David Murray in branch 'default': Merge #14187: Add glossary entry for 'function annotations'. http://hg.python.org/cpython/rev/3e1c45f5c585 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 19:00:11 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 06 May 2013 17:00:11 +0000 Subject: [issue14187] add "function annotation" entry to Glossary In-Reply-To: <1330805957.18.0.748865462478.issue14187@psf.upfronthosting.co.za> Message-ID: <1367859611.9.0.0106732312501.issue14187@psf.upfronthosting.co.za> R. David Murray added the comment: Done. Thanks for the ping. And thanks for the suggestion and patch, Chris. ---------- nosy: +r.david.murray resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 20:07:11 2013 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 06 May 2013 18:07:11 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: Message-ID: Gregory P. Smith added the comment: Actually I'm thinking this duck may only have a beak. Instead of a bunch of fields of None I'd prefer just not having that attribute defined on the object. I consider the os specific "stat-like" info from reading a directory to be so os specific that i'd rather not let someone be confused by it if it were to be returned up to a higher level caller. It's not a stat. On May 6, 2013 2:36 AM, "Charles-Fran?ois Natali" wrote: > > Charles-Fran?ois Natali added the comment: > > > I don't think that's true in general, or true of how other Python APIs > work. For instance, many APIs return a "file-like object", and you can only > do certain things on that object, depending on what the documentation says, > or what EAFP gets you. Some file-like object don't support seek/tell, some > don't support close, etc. I've seen plenty of walk-like-a-duck checks like > this: > > Yes, I'm fully aware duck-typing ;-) > But here, you're saying that "a duck has a beak, but it *may* have > legs, a tail, etc". > It's just looks wrong to me on so many levels. > > Please bring this up on python-dev. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 20:16:59 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 06 May 2013 18:16:59 +0000 Subject: [issue13831] get method of multiprocessing.pool.Async should return full traceback In-Reply-To: <1327006000.05.0.152231015377.issue13831@psf.upfronthosting.co.za> Message-ID: <1367864219.9.0.0941288888552.issue13831@psf.upfronthosting.co.za> Richard Oudkerk added the comment: The relevant changeset was c4f92b597074, but I wrote the wrong issue number in the commit message and Misc/NEWS. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 20:42:29 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Mon, 06 May 2013 18:42:29 +0000 Subject: [issue11016] Add S_ISDOOR to the stat module In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za> Message-ID: <1367865749.76.0.375892925509.issue11016@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 20:46:27 2013 From: report at bugs.python.org (Ecir Hana) Date: Mon, 06 May 2013 18:46:27 +0000 Subject: [issue3982] support .format for bytes In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za> Message-ID: <1367865987.14.0.290953318645.issue3982@psf.upfronthosting.co.za> Changes by Ecir Hana : ---------- nosy: +ecir.hana _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 20:51:41 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 May 2013 18:51:41 +0000 Subject: [issue17833] test_gdb broken PPC64 Linux In-Reply-To: <1366828530.65.0.489906336326.issue17833@psf.upfronthosting.co.za> Message-ID: <3b4Cj848CQzPqc@mail.python.org> Roundup Robot added the comment: New changeset f4a6b731905a by David Malcolm in branch '3.3': #17833: fix test_gdb failures seen on PPC64 Linux in test_threads (test.test_gdb.PyBtTests) http://hg.python.org/cpython/rev/f4a6b731905a New changeset 6d971b172389 by David Malcolm in branch 'default': #17833: merge with 3.3 http://hg.python.org/cpython/rev/6d971b172389 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 20:56:15 2013 From: report at bugs.python.org (Dave Malcolm) Date: Mon, 06 May 2013 18:56:15 +0000 Subject: [issue17833] test_gdb broken PPC64 Linux In-Reply-To: <1366828530.65.0.489906336326.issue17833@psf.upfronthosting.co.za> Message-ID: <1367866575.57.0.279766728309.issue17833@psf.upfronthosting.co.za> Changes by Dave Malcolm : ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 21:17:20 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 May 2013 19:17:20 +0000 Subject: [issue1545463] New-style classes fail to cleanup attributes Message-ID: <3b4DGl5p3CzPbJ@mail.python.org> Roundup Robot added the comment: New changeset f0833e6ff2d2 by Antoine Pitrou in branch 'default': Issue #1545463: Global variables caught in reference cycles are now garbage-collected at shutdown. http://hg.python.org/cpython/rev/f0833e6ff2d2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 21:20:10 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 19:20:10 +0000 Subject: [issue1545463] New-style classes fail to cleanup attributes Message-ID: <1367868010.67.0.832972106978.issue1545463@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This issue is endly fixed in 3.4. Since changing the shutdown sequence is a delicate change, I won't backport to bugfix branches. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 21:26:50 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 May 2013 19:26:50 +0000 Subject: [issue12181] SIGBUS error on OpenBSD (sparc64) In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za> Message-ID: <3b4DTk12kxzPhP@mail.python.org> Roundup Robot added the comment: New changeset c6c2b216bd14 by Charles-Francois Natali in branch '2.7': Issue #12181: select module: Fix struct kevent definition on OpenBSD 64-bit http://hg.python.org/cpython/rev/c6c2b216bd14 New changeset f6c50b437de6 by Charles-Francois Natali in branch '3.3': Issue #12181: select module: Fix struct kevent definition on OpenBSD 64-bit http://hg.python.org/cpython/rev/f6c50b437de6 New changeset 557599a32821 by Charles-Francois Natali in branch 'default': Issue #12181: select module: Fix struct kevent definition on OpenBSD 64-bit http://hg.python.org/cpython/rev/557599a32821 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 21:26:51 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 06 May 2013 19:26:51 +0000 Subject: [issue15535] Fix pickling efficiency of named tuples in 2.7.3 In-Reply-To: <1343915086.31.0.252328658724.issue15535@psf.upfronthosting.co.za> Message-ID: <1367868411.4.0.9131465701.issue15535@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 21:34:45 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 06 May 2013 19:34:45 +0000 Subject: [issue11816] Refactor the dis module to provide better building blocks for bytecode analysis In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za> Message-ID: <1367868885.51.0.162870279131.issue11816@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: test_dis is failing on some buildbots: http://buildbot.python.org/all/builders/AMD64 Ubuntu LTS 3.x/builds/1674/steps/test/logs/stdio Re-running test 'test_dis' in verbose mode test test_dis crashed -- Traceback (most recent call last): File "/opt/python/3.x.langa-ubuntu/build/Lib/test/regrtest.py", line 1294, in runtest_inner the_module = importlib.import_module(abstest) File "/opt/python/3.x.langa-ubuntu/build/Lib/importlib/__init__.py", line 92, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 1603, in _gcd_import File "", line 1584, in _find_and_load File "", line 1551, in _find_and_load_unlocked File "", line 591, in _check_name_wrapper File "", line 1053, in load_module File "", line 1034, in load_module File "", line 567, in module_for_loader_wrapper File "", line 901, in _load_module File "", line 297, in _call_with_frames_removed File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_dis.py", line 4, in from test.bytecode_helper import BytecodeTestCase ImportError: No module named 'test.bytecode_helper' ---------- nosy: +neologix status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 21:37:11 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 19:37:11 +0000 Subject: [issue11816] Refactor the dis module to provide better building blocks for bytecode analysis In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za> Message-ID: <1367869031.24.0.519733712503.issue11816@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Yes, this is bytecode_helper hasn't been added to the repository. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 21:37:30 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 19:37:30 +0000 Subject: [issue11816] Refactor the dis module to provide better building blocks for bytecode analysis In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za> Message-ID: <1367869050.27.0.702391651797.issue11816@psf.upfronthosting.co.za> Antoine Pitrou added the comment: (this is *because*, sorry) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 21:37:40 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 19:37:40 +0000 Subject: [issue17912] thread states should use a doubly-linked list In-Reply-To: <1367791359.52.0.60418083975.issue17912@psf.upfronthosting.co.za> Message-ID: <1367869060.82.0.186794331702.issue17912@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 21:39:56 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 19:39:56 +0000 Subject: [issue17289] readline.set_completer_delims() doesn't play well with others In-Reply-To: <1361727162.6.0.330340271384.issue17289@psf.upfronthosting.co.za> Message-ID: <1367869196.03.0.123767518551.issue17289@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 21:48:06 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 06 May 2013 19:48:06 +0000 Subject: [issue12181] SIGBUS error on OpenBSD (sparc64) In-Reply-To: <1306354802.94.0.44002539476.issue12181@psf.upfronthosting.co.za> Message-ID: <1367869686.69.0.667619002758.issue12181@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Sorry for the delay, it should be fixed now. Federico, thanks for the patch! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 21:48:35 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 06 May 2013 19:48:35 +0000 Subject: [issue17917] use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() when applicable In-Reply-To: <1367845837.62.0.789153792923.issue17917@psf.upfronthosting.co.za> Message-ID: <1367869715.23.0.218250296678.issue17917@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Here's a (gigantic) patch. I used an ad-hoc script for the conversion (next time I might try with coccinelle). I tested it on Linux, FreeBSD, Openindiana, OS-X and Windows. ---------- keywords: +needs review, patch nosy: +pitrou stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 21:48:53 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 06 May 2013 19:48:53 +0000 Subject: [issue17917] use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() when applicable In-Reply-To: <1367845837.62.0.789153792923.issue17917@psf.upfronthosting.co.za> Message-ID: <1367869733.87.0.519135878766.issue17917@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Added file: http://bugs.python.org/file30155/ins_macro.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 21:49:44 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 19:49:44 +0000 Subject: [issue17917] use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() when applicable In-Reply-To: <1367845837.62.0.789153792923.issue17917@psf.upfronthosting.co.za> Message-ID: <1367869784.92.0.987308446949.issue17917@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 21:51:12 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 May 2013 19:51:12 +0000 Subject: [issue17289] readline.set_completer_delims() doesn't play well with others In-Reply-To: <1361727162.6.0.330340271384.issue17289@psf.upfronthosting.co.za> Message-ID: <3b4F1q6P3nzQ7F@mail.python.org> Roundup Robot added the comment: New changeset 55c7295aca6c by Antoine Pitrou in branch '2.7': Issue #17289: The readline module now plays nicer with external modules or applications changing the rl_completer_word_break_characters global variable. http://hg.python.org/cpython/rev/55c7295aca6c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 21:54:15 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 May 2013 19:54:15 +0000 Subject: [issue17289] readline.set_completer_delims() doesn't play well with others In-Reply-To: <1361727162.6.0.330340271384.issue17289@psf.upfronthosting.co.za> Message-ID: <3b4F5M08NbzQ8m@mail.python.org> Roundup Robot added the comment: New changeset df0afd3ebb70 by Antoine Pitrou in branch '3.3': Issue #17289: The readline module now plays nicer with external modules or applications changing the rl_completer_word_break_characters global variable. http://hg.python.org/cpython/rev/df0afd3ebb70 New changeset 0f65426009e2 by Antoine Pitrou in branch 'default': Issue #17289: The readline module now plays nicer with external modules or applications changing the rl_completer_word_break_characters global variable. http://hg.python.org/cpython/rev/0f65426009e2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 21:55:03 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 19:55:03 +0000 Subject: [issue17289] readline.set_completer_delims() doesn't play well with others In-Reply-To: <1361727162.6.0.330340271384.issue17289@psf.upfronthosting.co.za> Message-ID: <1367870103.74.0.95048035524.issue17289@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the patch! I made a variable name a bit shorter and also added some error checking on the strdup() result. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 21:57:33 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 19:57:33 +0000 Subject: [issue17917] use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() when applicable In-Reply-To: <1367845837.62.0.789153792923.issue17917@psf.upfronthosting.co.za> Message-ID: <1367870253.84.0.499169723747.issue17917@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This is a lot of code churn, but it touches code that is unlikely to be modified otherwise, so I guess it's ok. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 22:12:31 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 06 May 2013 20:12:31 +0000 Subject: [issue17912] thread states should use a doubly-linked list In-Reply-To: <1367869060.85.0.743038609985.issue17912@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: Are there other places in the code base using linked-list? If yes, I think it could be interesting to add a generic linked-list implementation, like the one used in the Linux kernel: http://kernelnewbies.org/FAQ/LinkedLists http://isis.poly.edu/kulesh/stuff/src/klist/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 22:14:38 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 20:14:38 +0000 Subject: [issue17918] failed incoming SSL connection stays open forever In-Reply-To: <1367850452.92.0.464255806144.issue17918@psf.upfronthosting.co.za> Message-ID: <1367871278.15.0.118209417541.issue17918@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for reporting. For maximum backwards compatibility, the safer fix is to close the socket only in SSLSocket.accept(). Unfortunately I can't think of a way to write a unittest for it, so I'll just commit the fix. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 22:19:40 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 06 May 2013 20:19:40 +0000 Subject: [issue17656] Python 2.7.4 breaks ZipFile extraction of zip files with unicode member paths In-Reply-To: <1365391259.55.0.44522935247.issue17656@psf.upfronthosting.co.za> Message-ID: <1367871580.61.0.0757774735262.issue17656@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: The test is still failling: http://buildbot.python.org/all/builders/AMD64 OpenIndiana 2.7/builds/1670/steps/test/logs/stdio """ ====================================================================== ERROR: test_extract_unicode_filenames (test.test_zipfile.TestsWithSourceFile) ---------------------------------------------------------------------- Traceback (most recent call last): File "/export/home/buildbot/64bits/2.7.cea-indiana-amd64/build/Lib/test/test_zipfile.py", line 436, in test_extract_unicode_filenames writtenfile = zipfp.extract(fname) File "/export/home/buildbot/64bits/2.7.cea-indiana-amd64/build/Lib/zipfile.py", line 1024, in extract return self._extract_member(member, path, pwd) File "/export/home/buildbot/64bits/2.7.cea-indiana-amd64/build/Lib/zipfile.py", line 1079, in _extract_member file(targetpath, "wb") as target: UnicodeEncodeError: 'ascii' codec can't encode characters in position 85-86: ordinal not in range(128) """ ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 22:19:57 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 May 2013 20:19:57 +0000 Subject: [issue17918] failed incoming SSL connection stays open forever In-Reply-To: <1367850452.92.0.464255806144.issue17918@psf.upfronthosting.co.za> Message-ID: <3b4Fg02tG8zMR5@mail.python.org> Roundup Robot added the comment: New changeset 85e5a93e534e by Antoine Pitrou in branch '2.7': Issue #17918: When using SSLSocket.accept(), if the SSL handshake failed on the new socket, the socket would linger indefinitely. http://hg.python.org/cpython/rev/85e5a93e534e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 22:20:30 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 20:20:30 +0000 Subject: [issue17918] failed incoming SSL connection stays open forever In-Reply-To: <1367850452.92.0.464255806144.issue17918@psf.upfronthosting.co.za> Message-ID: <1367871630.91.0.831089137815.issue17918@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 22:22:51 2013 From: report at bugs.python.org (abcdef) Date: Mon, 06 May 2013 20:22:51 +0000 Subject: [issue17920] Documentation: "complete ordering" should be "total ordering" Message-ID: <1367871771.49.0.425606433106.issue17920@psf.upfronthosting.co.za> New submission from abcdef: The set documentation [http://docs.python.org/3.4/library/stdtypes.html] states "The subset and equality comparisons do not generalize to a complete ordering function. For example, any two disjoint sets are not equal and are not subsets of each other..." Could "complete ordering" be changed to "total ordering"? This is the correct mathematical terminology. A total ordering is one where every pair is comparable. A complete ordering is one where each bounded subset has a supremum/infimum (for example, reals form a complete ordered field). This can be verified at Wikipedia [http://en.wikipedia.org/wiki/Total_order] and essentially every set theory book. ---------- assignee: docs at python components: Documentation messages: 188585 nosy: abcdef, docs at python priority: normal severity: normal status: open title: Documentation: "complete ordering" should be "total ordering" type: enhancement versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 22:22:56 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 20:22:56 +0000 Subject: [issue17912] thread states should use a doubly-linked list In-Reply-To: Message-ID: <1367871772.2564.1.camel@fsol> Antoine Pitrou added the comment: > Are there other places in the code base using linked-list? > If yes, I think it could be interesting to add a generic linked-list > implementation, like the one used in the Linux kernel: > http://kernelnewbies.org/FAQ/LinkedLists > http://isis.poly.edu/kulesh/stuff/src/klist/ There are a couple other places, IIRC. That said, I'm not sure what the point is, since a linked list is quite a simple structure anyway? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 22:26:13 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 20:26:13 +0000 Subject: [issue17919] AIX POLLNVAL definition causes problems In-Reply-To: <1367852817.71.0.664729704726.issue17919@psf.upfronthosting.co.za> Message-ID: <1367871973.2.0.858497430685.issue17919@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +David.Edelsohn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 22:30:39 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 20:30:39 +0000 Subject: [issue17915] Encoding error with sax and codecs In-Reply-To: <1367838846.54.0.113997926456.issue17915@psf.upfronthosting.co.za> Message-ID: <1367872239.57.0.698436516226.issue17915@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +haypo, serhiy.storchaka type: -> behavior versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 22:31:35 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 20:31:35 +0000 Subject: [issue17915] Encoding error with sax and codecs In-Reply-To: <1367838846.54.0.113997926456.issue17915@psf.upfronthosting.co.za> Message-ID: <1367872295.92.0.584473312845.issue17915@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Since this is a regression, setting (temporarily perhaps) as release blocker. ---------- nosy: +georg.brandl, larry, pitrou priority: normal -> release blocker stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 22:32:24 2013 From: report at bugs.python.org (abcdef) Date: Mon, 06 May 2013 20:32:24 +0000 Subject: [issue17920] Documentation: "complete ordering" should be "total ordering" In-Reply-To: <1367871771.49.0.425606433106.issue17920@psf.upfronthosting.co.za> Message-ID: <1367872344.64.0.0846869555779.issue17920@psf.upfronthosting.co.za> abcdef added the comment: Another small thing: "For example, any two disjoint sets are not equal and are not subsets of each other, so all of the following return False: ab." It should be "any two nonempty disjoint sets". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 22:36:36 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 20:36:36 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1367872596.62.0.0486670117738.issue5845@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Take it with a large grain of Internet salt, but Ezio pointed me to the following reactions: http://www.reddit.com/r/Python/comments/1dq7sh/python_repl_finally_gets_tab_completion_by_default/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 22:39:08 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 May 2013 20:39:08 +0000 Subject: [issue13503] improved efficiency of bytearray pickling by using bytes type instead of str In-Reply-To: <1322611756.83.0.989666994675.issue13503@psf.upfronthosting.co.za> Message-ID: <1367872748.71.0.181759796386.issue13503@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: How about base64? self.save_reduce(base64.b64decode, (str(base64.b64encode(obj), 'ascii'),), obj=obj) >>> len(dumps(bytes([200] * 10000), 2)) 13372 ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 22:45:17 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 May 2013 20:45:17 +0000 Subject: [issue13503] improved efficiency of bytearray pickling by using bytes type instead of str In-Reply-To: <1322611756.83.0.989666994675.issue13503@psf.upfronthosting.co.za> Message-ID: <1367873117.77.0.173299428244.issue13503@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Serhiy Storchaka added the comment: > > How about base64? > > self.save_reduce(base64.b64decode, > (str(base64.b64encode(obj), 'ascii'),), obj=obj) > > >>> len(dumps(bytes([200] * 10000), 2)) > 13372 It's statistically better (a fixed 1.33 expansion instead of 1.5 average), but ASCII bytearrays will pickle less efficiently than currently. There's something else: we had enough regressions in the latest 2.7.x release, and we shouldn't risk adding new ones in the next release. Really, let's close this issue. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 22:55:20 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Mon, 06 May 2013 20:55:20 +0000 Subject: [issue5845] rlcompleter should be enabled automatically In-Reply-To: <1240702039.68.0.55843541961.issue5845@psf.upfronthosting.co.za> Message-ID: <1367873720.79.0.171100665842.issue5845@psf.upfronthosting.co.za> Tshepang Lekhonkhobe added the comment: Also made it to the front-page of Hacker News[1], with better quality comments than the reddit thread. [1] https://news.ycombinator.com/item?id=5658062 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 23:07:01 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 May 2013 21:07:01 +0000 Subject: [issue17917] use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() when applicable In-Reply-To: <1367845837.62.0.789153792923.issue17917@psf.upfronthosting.co.za> Message-ID: <1367874421.1.0.696464389421.issue17917@psf.upfronthosting.co.za> STINNER Victor added the comment: Could you please generete the same patch without --git so it can be reviewed on Rietveld? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 23:10:42 2013 From: report at bugs.python.org (Zachary Ware) Date: Mon, 06 May 2013 21:10:42 +0000 Subject: [issue17883] Fix buildbot testing of Tkinter In-Reply-To: <1367355915.98.0.26398929673.issue17883@psf.upfronthosting.co.za> Message-ID: <1367874642.3.0.152245015891.issue17883@psf.upfronthosting.co.za> Zachary Ware added the comment: Here's a better patch after learning a bit better how subprocess.Popen works... ---------- Added file: http://bugs.python.org/file30156/issue17883.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 23:10:55 2013 From: report at bugs.python.org (Zachary Ware) Date: Mon, 06 May 2013 21:10:55 +0000 Subject: [issue17883] Fix buildbot testing of Tkinter In-Reply-To: <1367355915.98.0.26398929673.issue17883@psf.upfronthosting.co.za> Message-ID: <1367874655.52.0.957665737632.issue17883@psf.upfronthosting.co.za> Changes by Zachary Ware : Removed file: http://bugs.python.org/file30154/issue17883.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 23:14:39 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 06 May 2013 21:14:39 +0000 Subject: [issue17883] Fix buildbot testing of Tkinter In-Reply-To: <1367355915.98.0.26398929673.issue17883@psf.upfronthosting.co.za> Message-ID: <1367874879.71.0.381103949905.issue17883@psf.upfronthosting.co.za> Ezio Melotti added the comment: FTR there's also test.support.assert_python_ok and test.support.assert_python_failure (and a few convenience functions in subprocess too). I suspect that if the import fails, stdout is empty, and stderr will contain the error message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 23:20:22 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 06 May 2013 21:20:22 +0000 Subject: [issue17917] use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() when applicable In-Reply-To: <1367845837.62.0.789153792923.issue17917@psf.upfronthosting.co.za> Message-ID: <1367875222.66.0.555096237237.issue17917@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Removed file: http://bugs.python.org/file30155/ins_macro.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 23:20:57 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 06 May 2013 21:20:57 +0000 Subject: [issue17917] use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() when applicable In-Reply-To: <1367845837.62.0.789153792923.issue17917@psf.upfronthosting.co.za> Message-ID: <1367875257.3.0.451891719257.issue17917@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Added file: http://bugs.python.org/file30157/ins_macro-1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 23:23:34 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 May 2013 21:23:34 +0000 Subject: [issue7330] PyUnicode_FromFormat: implement width and precision for %s, %S, %R, %V, %U, %A In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za> Message-ID: <3b4H4P6PQ8zQxV@mail.python.org> Roundup Robot added the comment: New changeset 9e0f1c3bf9b6 by Victor Stinner in branch 'default': Issue #7330: Implement width and precision (ex: "%5.3s") for the format string http://hg.python.org/cpython/rev/9e0f1c3bf9b6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 23:36:01 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 May 2013 21:36:01 +0000 Subject: [issue7330] PyUnicode_FromFormat: implement width and precision for %s, %S, %R, %V, %U, %A In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za> Message-ID: <1367876161.29.0.502001418557.issue7330@psf.upfronthosting.co.za> STINNER Victor added the comment: Finally, I closed this issue. Sorry for the long delay, but many other PyUnicode_FromFormat() issues had to be discussed/fixed before this one can be fixed. It was also much easier to fix this issue since my refactoring of PyUnicode_FromFormat() to only parse the format string once (thanks to the _PyUnicodeWriter API) instead of having 4 steps. Thanks to Ysj Ray, thanks to reviewers. This is one of the oldest issue that I had to fix :-) ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 23:36:30 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 May 2013 21:36:30 +0000 Subject: [issue13349] Non-informative error message in index() and remove() functions In-Reply-To: <1320526177.89.0.678573577515.issue13349@psf.upfronthosting.co.za> Message-ID: <1367876190.46.0.469408887836.issue13349@psf.upfronthosting.co.za> STINNER Victor added the comment: > Confirmed with Ezio that issue #7330 will need to be fixed/approved before this issue can be closed. FYI I just fixed this issue. PyUnicode_FromFormat() now supports width and precision in the format string. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 23:48:19 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 May 2013 21:48:19 +0000 Subject: [issue17915] Encoding error with sax and codecs In-Reply-To: <1367838846.54.0.113997926456.issue17915@psf.upfronthosting.co.za> Message-ID: <1367876899.83.0.623761180144.issue17915@psf.upfronthosting.co.za> STINNER Victor added the comment: It looks like a regression of introduced by the fix of the issue #1470548, changeset 66f92f76b2ce. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 6 23:51:08 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 May 2013 21:51:08 +0000 Subject: [issue17915] Encoding error with sax and codecs In-Reply-To: <1367838846.54.0.113997926456.issue17915@psf.upfronthosting.co.za> Message-ID: <1367877068.89.0.651350235103.issue17915@psf.upfronthosting.co.za> STINNER Victor added the comment: Extracted test from report.txt. Test with Python 3.4: $ ./python test_codecs.py Traceback (most recent call last): File "test_codecs.py", line 7, in xml.startDocument() File "/home/haypo/prog/python/default/Lib/xml/sax/saxutils.py", line 148, in startDocument self._encoding) File "/home/haypo/prog/python/default/Lib/codecs.py", line 699, in write return self.writer.write(data) File "/home/haypo/prog/python/default/Lib/codecs.py", line 355, in write data, consumed = self.encode(object, self.errors) TypeError: Can't convert 'bytes' object to str implicitly _gettextwriter() of xml.sax.saxutils does not recognize codecs classes. (See also the PEP 400 :-)). ---------- Added file: http://bugs.python.org/file30158/test_codecs.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 00:14:56 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 May 2013 22:14:56 +0000 Subject: [issue11816] Refactor the dis module to provide better building blocks for bytecode analysis In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za> Message-ID: <1367878496.63.0.546108516498.issue11816@psf.upfronthosting.co.za> STINNER Victor added the comment: Ping! The test is still failing. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 00:21:39 2013 From: report at bugs.python.org (Thomas Kluyver) Date: Mon, 06 May 2013 22:21:39 +0000 Subject: [issue11816] Refactor the dis module to provide better building blocks for bytecode analysis In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za> Message-ID: <1367878899.48.0.235737301252.issue11816@psf.upfronthosting.co.za> Thomas Kluyver added the comment: bytecode_helper is there in dis_api3.diff - anyone with commit rights should be able to add it to the repository. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 00:22:43 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 May 2013 22:22:43 +0000 Subject: [issue17917] use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() when applicable In-Reply-To: <1367845837.62.0.789153792923.issue17917@psf.upfronthosting.co.za> Message-ID: <1367878963.98.0.0610936771008.issue17917@psf.upfronthosting.co.za> STINNER Victor added the comment: Modules/fcntlmodule.c and Modules/posixmodule.c are using explicit cast to long. I don't know if there is a good reason for such cast. PC/_msi.c: Oh, here you should remove cast to int. Example: PyModule_AddIntMacro(m, (int)MSIDBOPEN_CREATEDIRECT); I'm surprised that the does compile. You may have a "(int)MSIDBOPEN_CREATEDIRECT" variable :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 00:28:39 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 May 2013 22:28:39 +0000 Subject: [issue11816] Refactor the dis module to provide better building blocks for bytecode analysis In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za> Message-ID: <3b4JWV2b8qzRJ6@mail.python.org> Roundup Robot added the comment: New changeset 84d1a0e32d3b by Nick Coghlan in branch 'default': Issue #11816: Add missing test helper http://hg.python.org/cpython/rev/84d1a0e32d3b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 00:33:14 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 May 2013 22:33:14 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1367879594.22.0.946391491649.issue17914@psf.upfronthosting.co.za> STINNER Victor added the comment: I also vote +1 for returning None when the information is unknown. Just write "os.cpu_count() or 1" if you need 1 when the count is unknown ;-) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 00:35:48 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 May 2013 22:35:48 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1367879748.14.0.6802708697.issue17914@psf.upfronthosting.co.za> STINNER Victor added the comment: See also #17444, Trent Nelson wrote an implementation of os.cpu_count(). ---------- nosy: +trent _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 00:42:37 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 May 2013 22:42:37 +0000 Subject: [issue17913] stat.filemode returns "-" for sockets and unknown types In-Reply-To: <1367831480.84.0.461149512803.issue17913@psf.upfronthosting.co.za> Message-ID: <1367880157.53.0.741639656844.issue17913@psf.upfronthosting.co.za> STINNER Victor added the comment: Can you maybe add an unit test? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 00:45:45 2013 From: report at bugs.python.org (paul j3) Date: Mon, 06 May 2013 22:45:45 +0000 Subject: [issue14191] argparse doesn't allow optionals within positionals In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za> Message-ID: <1367880345.27.0.562116113891.issue14191@psf.upfronthosting.co.za> paul j3 added the comment: This is a revision of the test_intermixed.py that I submitted earlier. Now `parse_intermixed_args` acts like `parse_args', and calls `parse_known_intermixed_args`. Again it is form that can exercise the idea without modifying `argparse.py`. If the parser has incompatible features (REMAINDER, PARSER, or certain exclusive groups), it raises an error. However to facilitate testing I included a `_fallback` backdoor. If not default None it will be called instead of raising the error. While making documentation changes, I got to wondering whether 'interspersed' would be a better term than 'intermixed'. optparse has an 'interspersed' option and api. However the getopt documentation does use 'intermixed'. ---------- Added file: http://bugs.python.org/file30159/test_intermixed.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 00:51:32 2013 From: report at bugs.python.org (paul j3) Date: Mon, 06 May 2013 22:51:32 +0000 Subject: [issue14191] argparse doesn't allow optionals within positionals In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za> Message-ID: <1367880692.77.0.168236530924.issue14191@psf.upfronthosting.co.za> paul j3 added the comment: This is the formal patch corresponding to the `test_intermixed.py`. It includes changes to `argparse.rst`, plus tests in `test_argparse.py`. These tests are near the end, after those for `parse_known_args`. They are roughly equivalent to the examples in `test_intermixed.py`. ----------------- The new documentation section is: Some users expect to freely intermix optional and positional argument strings. For example, optparse, by default, allows interspersed argument strings. GNU getopt() permutes the argument strings so non-options are at the end. The parse_intermixed_args() method emulates this behavior by first calling parse_known_args() with just the optional arguments being active. It is then called a second time to parse the list of remaining argument strings using the positional arguments. parse_intermixed_args() raises an error if the parser uses features that are incompatible with this two step parsing. These include subparsers, argparse.REMAINDER, and mutually exclusive groups that include both optionals and positionals. In this example, parse_known_args() returns an unparsed list of arguments [?2?, ?3?], while parse_intermixed_args() returns rest=[1, 2, 3]. >>> parser = argparse.ArgumentParser() >>> parser.add_argument('--foo') >>> parser.add_argument('cmd') >>> parser.add_argument('rest', nargs='*', type=int) >>> parser.parse_known_args('cmd1 1 --foo bar 2 3'.split()) (Namespace(cmd='cmd1', foo='bar', rest=[1]), ['2', '3']) >>> parser.parse_intermixed_args('cmd1 1 --foo bar 2 3'.split()) Namespace(cmd='cmd1', foo='bar', rest=[1, 2, 3]) parse_known_intermixed_args() method, returns a two item tuple containing the populated namespace and the list of remaining argument strings. parse_intermixed_args() raises an error if there are any remaining unparsed argument strings. ---------- Added file: http://bugs.python.org/file30160/intermixed.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 00:52:16 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 May 2013 22:52:16 +0000 Subject: [issue11016] Add S_ISDOOR to the stat module In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za> Message-ID: <1367880736.84.0.0816642120521.issue11016@psf.upfronthosting.co.za> STINNER Victor added the comment: If we use the C language, I would prefer to only expose what does really exist, and not add "fake" functions like: +#ifndef S_ISDOOR +# define S_ISDOOR(mode) 0 +#endif So in: +static PyMethodDef stat_methods[] = { + {"S_ISDIR", stat_S_ISDIR, METH_O, stat_S_ISDIR_doc}, + {"S_ISCHR", stat_S_ISCHR, METH_O, stat_S_ISCHR_doc}, + {"S_ISBLK", stat_S_ISBLK, METH_O, stat_S_ISBLK_doc}, + {"S_ISREG", stat_S_ISREG, METH_O, stat_S_ISREG_doc}, + {"S_ISFIFO", stat_S_ISFIFO, METH_O, stat_S_ISFIFO_doc}, + {"S_ISLNK", stat_S_ISLNK, METH_O, stat_S_ISLNK_doc}, + {"S_ISSOCK", stat_S_ISSOCK, METH_O, stat_S_ISSOCK_doc}, + {"S_ISDOOR", stat_S_ISDOOR, METH_O, stat_S_ISDOOR_doc}, + {"S_ISPORT", stat_S_ISPORT, METH_O, stat_S_ISPORT_doc}, + {"S_ISWHT", stat_S_ISWHT, METH_O, stat_S_ISWHT_doc}, + {"S_IMODE", stat_S_IMODE, METH_O, stat_S_IMODE_doc}, + {"S_IFMT", stat_S_IFMT, METH_O, stat_S_IFMT_doc}, + {"filemode", stat_filemode, METH_O, stat_filemode_doc}, + {NULL, NULL} /* sentinel */ +}; I expect something similar to what is done in posixmodule.c: static PyMethodDef stat_methods[] = { {"S_ISDIR", stat_S_ISDIR, METH_O, stat_S_ISDIR_doc}, ... #ifdef S_ISDOOR {"S_ISDOOR", stat_S_ISDOOR, METH_O, stat_S_ISDOOR_doc}, #endif {"filemode", stat_filemode, METH_O, stat_filemode_doc}, {NULL, NULL} /* sentinel */ }; ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 00:57:40 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 May 2013 22:57:40 +0000 Subject: [issue11016] Add S_ISDOOR to the stat module In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za> Message-ID: <1367881060.83.0.236117155077.issue11016@psf.upfronthosting.co.za> STINNER Victor added the comment: > I have created a C implementation of the stat module for Python 3.4. Oh, your C module is called "stat", as the "stat" module implemented in Python (Lib/stat.py). What is your plan? Replace completly the Python module with the C module? It may be nice to keep the Python module for compatibility with other Python implementations, and test both implementations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 02:25:13 2013 From: report at bugs.python.org (David Edelsohn) Date: Tue, 07 May 2013 00:25:13 +0000 Subject: [issue17919] AIX POLLNVAL definition causes problems In-Reply-To: <1367852817.71.0.664729704726.issue17919@psf.upfronthosting.co.za> Message-ID: <1367886313.81.0.146140810111.issue17919@psf.upfronthosting.co.za> David Edelsohn added the comment: That's the way AIX allocated the bits. It's nice to check for overflow, but I think the test is imposing more semantics on the mask bits than POSIX requires. It just happens that the GLibc allocation of bits works out okay. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 02:33:17 2013 From: report at bugs.python.org (lesmana) Date: Tue, 07 May 2013 00:33:17 +0000 Subject: [issue519227] hook method for 'is' operator Message-ID: <1367886797.77.0.746169590767.issue519227@psf.upfronthosting.co.za> Changes by lesmana : ---------- nosy: +lesmana versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 03:18:35 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 07 May 2013 01:18:35 +0000 Subject: [issue17920] Documentation: "complete ordering" should be "total ordering" In-Reply-To: <1367871771.49.0.425606433106.issue17920@psf.upfronthosting.co.za> Message-ID: <1367889515.53.0.0869832684914.issue17920@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 03:21:18 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 May 2013 01:21:18 +0000 Subject: [issue17920] Documentation: "complete ordering" should be "total ordering" In-Reply-To: <1367871771.49.0.425606433106.issue17920@psf.upfronthosting.co.za> Message-ID: <3b4NLk0rKlzRpW@mail.python.org> Roundup Robot added the comment: New changeset a285ce18bd55 by Raymond Hettinger in branch '2.7': Issue 17920: Fix-up terminology in the set documentation http://hg.python.org/cpython/rev/a285ce18bd55 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 03:23:22 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 May 2013 01:23:22 +0000 Subject: [issue17920] Documentation: "complete ordering" should be "total ordering" In-Reply-To: <1367871771.49.0.425606433106.issue17920@psf.upfronthosting.co.za> Message-ID: <3b4NP52v37zSj9@mail.python.org> Roundup Robot added the comment: New changeset 6ec04c5dae6e by Raymond Hettinger in branch '3.3': Issue 17920: Fix-up terminology in the set documentation http://hg.python.org/cpython/rev/6ec04c5dae6e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 03:25:17 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 07 May 2013 01:25:17 +0000 Subject: [issue13503] improved efficiency of bytearray pickling by using bytes type instead of str In-Reply-To: <1322611756.83.0.989666994675.issue13503@psf.upfronthosting.co.za> Message-ID: <1367889917.39.0.709239910079.issue13503@psf.upfronthosting.co.za> Raymond Hettinger added the comment: It looks like this is an unfortunate dead-end. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 03:42:05 2013 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 07 May 2013 01:42:05 +0000 Subject: [issue17911] Extracting tracebacks does too much work In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1367890925.73.0.216938615603.issue17911@psf.upfronthosting.co.za> Nick Coghlan added the comment: Antoine - I like your idea, but I think it's a separate issue. I agree with Guido that exposing some lower level non-formatting APIs in the traceback module would be helpful. I see Guido's suggestion here as similar to the change we just made in the dis module to expose a dis.get_instructions iterator. That change makes it much easier to work with the disassembler output programmatically, whereas the module was previously too focused on displaying text with a specific format. My current thoughts: define a "TracebackSummary" with the following fields: exc_type exc_repr stack_summary cause context stack_summary would be a list of (filename, lineno, functionname) triples as Guido suggested (probably a named tuple) cause and context would be either None or a reference to an appropriate TracebackSummary object Basically, the summary should contain all of the information needed to create the formatted traceback output, without actually doing any formatting (aside from calling repr() on the exception) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 04:10:59 2013 From: report at bugs.python.org (Todd Rovito) Date: Tue, 07 May 2013 02:10:59 +0000 Subject: [issue17883] Fix buildbot testing of Tkinter In-Reply-To: <1367355915.98.0.26398929673.issue17883@psf.upfronthosting.co.za> Message-ID: <1367892659.79.0.0653738882943.issue17883@psf.upfronthosting.co.za> Changes by Todd Rovito : ---------- nosy: +Todd.Rovito _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 04:18:18 2013 From: report at bugs.python.org (lesmana) Date: Tue, 07 May 2013 02:18:18 +0000 Subject: [issue17921] explicit empty check instead of implicit booleaness Message-ID: <1367893097.98.0.624454967229.issue17921@psf.upfronthosting.co.za> New submission from lesmana: Python should have a builtin method `isempty()` which calls the special method name `__isempty__()` for explicit emptiness check. The special method `__isempty__()` should return `True` if the object is "empty" and `False` if the object is "not empty". Observe emptiness check using implicit booleaness: if not somecollection: foo() Note that this code also handles `None`, `0` and `False` silently. If those are possible values then I have to test explicitly: if somecollection is not None and not somecollection: foo() Also handling the `0` and `False` cases will make the code really really ugly. Usually the `None`, `0` or `False` cases only happen in case of a programming error. But if I do not test for them explicitly then they will be handled silently and the error will occur somewhere else in the code. Compare against explicit emptiness check: if not isempty(somecollection): foo() This code will break immediately if somecollection does not have `__isempty__()`. If `None`, `0` or `False` are possible values they will not be handled silently, instead an error will be reported at `isempty()`. Advantage of explicit emptiness check: * More explicit and fluently readable code * No silent implicit booleaness check when code should do emptiness check * Clearer separation of meaning for the special methods `__len__()` and `__empty__()` Possible use case for explicit emptiness check: a list with memory effect. >>> ml = MemoryEffectList() >>> ml.charge() >>> ml.discharge() >>> isempty(ml) True >>> len(ml) == 0 False ---------- components: Interpreter Core messages: 188617 nosy: lesmana priority: normal severity: normal status: open title: explicit empty check instead of implicit booleaness type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 04:23:32 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 May 2013 02:23:32 +0000 Subject: [issue17921] explicit empty check instead of implicit booleaness In-Reply-To: <1367893097.98.0.624454967229.issue17921@psf.upfronthosting.co.za> Message-ID: <1367893412.95.0.0636095560253.issue17921@psf.upfronthosting.co.za> R. David Murray added the comment: Just use len. ---------- nosy: +r.david.murray resolution: -> rejected stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 04:26:34 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 May 2013 02:26:34 +0000 Subject: [issue17921] explicit empty check instead of implicit booleaness In-Reply-To: <1367893097.98.0.624454967229.issue17921@psf.upfronthosting.co.za> Message-ID: <1367893594.67.0.546634686306.issue17921@psf.upfronthosting.co.za> R. David Murray added the comment: Or, to be more helpful than that short answer: if you think there is something that isempty can do that len can't that makes it worth adding complexity to the language, please discuss it on the python-ideas mailing list first. That's the best place to get feedback for ideas like this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 05:39:46 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 07 May 2013 03:39:46 +0000 Subject: [issue17911] Extracting tracebacks does too much work In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1367897986.94.0.722766927981.issue17911@psf.upfronthosting.co.za> Guido van Rossum added the comment: That sounds great, except I'd expect the exception type and str(), since a formatted traceback uses the str() of the exception, not its repr(). Personally I don't think the tuples need to be named, but I won't hold up progress either. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 05:40:03 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 07 May 2013 03:40:03 +0000 Subject: [issue17911] Extracting tracebacks does too much work In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1367898003.59.0.873518777317.issue17911@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 08:35:01 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 May 2013 06:35:01 +0000 Subject: [issue17833] test_gdb broken PPC64 Linux In-Reply-To: <1366828530.65.0.489906336326.issue17833@psf.upfronthosting.co.za> Message-ID: <3b4WJh33KMzRJ6@mail.python.org> Roundup Robot added the comment: New changeset 63f2941477d3 by Ezio Melotti in branch '2.7': #17833: add debug output to investigate buildbot failure. http://hg.python.org/cpython/rev/63f2941477d3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 08:35:48 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 07 May 2013 06:35:48 +0000 Subject: [issue17833] test_gdb broken PPC64 Linux In-Reply-To: <1366828530.65.0.489906336326.issue17833@psf.upfronthosting.co.za> Message-ID: <1367908548.51.0.434341328414.issue17833@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- Removed message: http://bugs.python.org/msg188621 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 08:37:30 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 07 May 2013 06:37:30 +0000 Subject: [issue17883] Fix buildbot testing of Tkinter In-Reply-To: <1367355915.98.0.26398929673.issue17883@psf.upfronthosting.co.za> Message-ID: <3b4WJh33KMzRJ6@mail.python.org> Ezio Melotti added the comment: New changeset 63f2941477d3 by Ezio Melotti in branch '2.7': #17833: add debug output to investigate buildbot failure. http://hg.python.org/cpython/rev/63f2941477d3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 08:47:18 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 May 2013 06:47:18 +0000 Subject: [issue17871] Wrong signature of TextTestRunner's init function In-Reply-To: <1367269592.44.0.115946830805.issue17871@psf.upfronthosting.co.za> Message-ID: <3b4WZs3MFrzNFJ@mail.python.org> Roundup Robot added the comment: New changeset 5dd076d441ec by Ezio Melotti in branch '3.3': #17871: fix unittest.TextTestRunner signature in the docs. Patch by Yogesh Chaudhari. http://hg.python.org/cpython/rev/5dd076d441ec New changeset 15ed67602ddf by Ezio Melotti in branch 'default': #17871: merge with 3.3. http://hg.python.org/cpython/rev/15ed67602ddf ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 08:47:54 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 07 May 2013 06:47:54 +0000 Subject: [issue17871] Wrong signature of TextTestRunner's init function In-Reply-To: <1367269592.44.0.115946830805.issue17871@psf.upfronthosting.co.za> Message-ID: <1367909274.6.0.0892955053973.issue17871@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- assignee: docs at python -> ezio.melotti resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 08:48:45 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 07 May 2013 06:48:45 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367879594.22.0.946391491649.issue17914@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > I also vote +1 for returning None when the information is unknown. I still don't like it. If a function returns a number of CPU, it should either return an integer >= 1, or raise an exception. None is *not* an integer. And returning an exception is IMO useles, since the user can't do anything with anyway, other than fallback to 1. > Just write "os.cpu_count() or 1" if you need 1 when the count is unknown ;-) os.cpu_count() or 1 is an ugly idiom. > See also #17444, Trent Nelson wrote an implementation of os.cpu_count(). I don't see exactly what this C implementation brings over the one in multiprocessing (which is written in Python)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 09:14:18 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 07 May 2013 07:14:18 +0000 Subject: [issue17917] use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() when applicable In-Reply-To: <1367878963.98.0.0610936771008.issue17917@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > PC/_msi.c: Oh, here you should remove cast to int. Example: > > PyModule_AddIntMacro(m, (int)MSIDBOPEN_CREATEDIRECT); > > I'm surprised that the does compile. You may have a "(int)MSIDBOPEN_CREATEDIRECT" variable :-) Probably, good catch ;-) I'll fix that. > Modules/fcntlmodule.c and Modules/posixmodule.c are using explicit cast to long. I don't know if there is a good reason for such cast. There's a prototype, so arguments are implicitly converted to long: PyAPI_FUNC(int) PyModule_AddIntConstant(PyObject *, const char *, long); #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 09:17:17 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 May 2013 07:17:17 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1367911037.56.0.199898332543.issue17914@psf.upfronthosting.co.za> STINNER Victor added the comment: > I don't see exactly what this C implementation brings over the one > in multiprocessing (which is written in Python)? multiprocessing.cpu_count() creates a subprocess on BSD and Darwin to get the number of CPU. Calling sysctl() or sysctlnametomib() should be faster and use less memory. On Windows, GetSystemInfo() is called instead of reading an environment variable. I suppose that this function is more reliable. Trent's os.cpu_count() returns -1 if the count cannot be read, multiprocessing.cpu_count() raises NotImplementedError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 09:22:12 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 07 May 2013 07:22:12 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367911037.56.0.199898332543.issue17914@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: Fair enough, I guess we should use it then. We just have to agree on the value to return when the number of CPUs can't be determined ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 09:28:13 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 07 May 2013 07:28:13 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1367911693.38.0.443206232715.issue17914@psf.upfronthosting.co.za> Ezio Melotti added the comment: Returning None sounds reasonable to me. Raising an exception pretty much means that the function should always be called in a try/except (unless you are sure that the code is running on an OS that knows the number of CPUs). Returning -1 is not very Pythonic, and between 0 and None I prefer the latter, since it's IMHO a clearer indication that the value couldn't be determined. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 09:38:01 2013 From: report at bugs.python.org (Jan Safranek) Date: Tue, 07 May 2013 07:38:01 +0000 Subject: [issue17922] Crash in clear_weakref Message-ID: <1367912280.08.0.116722269635.issue17922@psf.upfronthosting.co.za> New submission from Jan Safranek: I have Python 2.7.4 running on Fedora Rawhide and I get segmentation fault with following backtrace: #0 0x00007f73f69ca5f1 in clear_weakref (self=0x7f73ff515c00) at Objects/weakrefobject.c:56 #1 weakref_dealloc (self=0x7f73ff515c00) at Objects/weakrefobject.c:106 #2 0x00007f73f698ea27 in PyList_SetItem (op=, i=, newitem=) at Objects/listobject.c:218 #3 0x00007f73f69ba9db in add_subclass (type=type at entry=0x7f73e00456b0, base=) at Objects/typeobject.c:4155 #4 0x00007f73f69c440e in PyType_Ready (type=type at entry=0x7f73e00456b0) at Objects/typeobject.c:4120 #5 0x00007f73f69c6d4b in type_new (metatype=, args=, kwds=) at Objects/typeobject.c:2467 #6 0x00007f73f69be7d3 in type_call (type=0x7f73f6cdad00 , args=0x7f73f61e1550, kwds=0x0) at Objects/typeobject.c:725 #7 0x00007f73f6954833 in PyObject_Call (func=func at entry=0x7f73f6cdad00 , arg=arg at entry=0x7f73f61e1550, kw=kw at entry=0x0) at Objects/abstract.c:2529 #8 0x00007f73f69553c9 in PyObject_CallFunctionObjArgs (callable=callable at entry=0x7f73f6cdad00 ) at Objects/abstract.c:2760 #9 0x00007f73f6a06bf3 in build_class (name=, bases=0x7f73f61e3910, methods=0x7f73e0045590) at Python/ceval.c:4632 #10 PyEval_EvalFrameEx (f=f at entry=0x7f73e0043a40, throwflag=throwflag at entry=0) at Python/ceval.c:1928 #11 0x00007f73f6a0b46d in PyEval_EvalCodeEx (co=co at entry=0x7f73f61f50b0, globals=globals at entry=0x7f73e003bf00, locals=locals at entry=0x7f73e003bf00, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=kwcount at entry=0, defs=defs at entry=0x0, defcount=defcount at entry=0, closure=closure at entry=0x0) at Python/ceval.c:3253 #12 0x00007f73f6a0b5a2 in PyEval_EvalCode (co=co at entry=0x7f73f61f50b0, globals=globals at entry=0x7f73e003bf00, locals=locals at entry=0x7f73e003bf00) at Python/ceval.c:667 #13 0x00007f73f6a22cfc in PyImport_ExecCodeModuleEx (name=name at entry=0x7f73e003d760 "warnings", co=co at entry=0x7f73f61f50b0, pathname=pathname at entry=0x7f73e003ac90 "/usr/local/lib/python2.7/warnings.pyc") at Python/import.c:709 #14 0x00007f73f6a2305e in load_source_module (name=0x7f73e003d760 "warnings", pathname=0x7f73e003ac90 "/usr/local/lib/python2.7/warnings.pyc", fp=) at Python/import.c:1099 #15 0x00007f73f6a23f59 in import_submodule (mod=mod at entry=0x7f73f6cd2ec0 <_Py_NoneStruct>, subname=subname at entry=0x7f73e003d760 "warnings", fullname=fullname at entry=0x7f73e003d760 "warnings") at Python/import.c:2700 #16 0x00007f73f6a24b93 in load_next (p_buflen=, buf=0x7f73e003d760 "warnings", p_name=, altmod=0x7f73f6cd2ec0 <_Py_NoneStruct>, mod=0x7f73f6cd2ec0 <_Py_NoneStruct>) at Python/import.c:2515 #17 import_module_level (locals=, level=, fromlist=0x7f73f6cd2ec0 <_Py_NoneStruct>, globals=, name=0x0) at Python/import.c:2224 #18 PyImport_ImportModuleLevel (name=0x7f73ff54fbf4 "warnings", globals=, locals=, fromlist=0x7f73f6cd2ec0 <_Py_NoneStruct>, level=) at Python/import.c:2288 #19 0x00007f73f6a033af in builtin___import__ (self=, args=, kwds=) at Python/bltinmodule.c:49 ... #61 0x00007f73f6a37dbc in initsite () at Python/pythonrun.c:721 #62 Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:265 (full back trace is attached, it's quite long). (gdb) py-bt #10 Frame 0x7f4bf8043df0, for file /usr/lib64/python2.7/warnings.py, line 281, in () class WarningMessage(object): #23 Frame 0x7f4bf803d300, for file /usr/lib64/python2.7/posixpath.py, line 17, in () import warnings #36 Frame 0x7f4bf8024fc0, for file /usr/lib64/python2.7/os.py, line 49, in () import posixpath as path #49 Frame 0x7f4bf801c520, for file /usr/lib64/python2.7/site.py, line 62, in () import os I get the same crash with vanilla Python 2.7.4 without Fedora patches. Python 2.7.3 works well and doesn't crash. ---------- components: Interpreter Core files: full-bt.txt messages: 188629 nosy: jsafrane priority: normal severity: normal status: open title: Crash in clear_weakref type: crash versions: Python 2.7 Added file: http://bugs.python.org/file30161/full-bt.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 09:38:28 2013 From: report at bugs.python.org (Jan Safranek) Date: Tue, 07 May 2013 07:38:28 +0000 Subject: [issue17922] Crash in clear_weakref In-Reply-To: <1367912280.08.0.116722269635.issue17922@psf.upfronthosting.co.za> Message-ID: <1367912308.96.0.761734051037.issue17922@psf.upfronthosting.co.za> Jan Safranek added the comment: I can reproduce the crash in very unusual setup: 1. OpenPegasus (http://www.openpegasus.org/), for this bug we may consider it just a network daemon, listening on TCP port. When a request comes, it is eventually processed by a provider (= something like plugin). 2. cmpi-bindings ([1], [2]), which allows to write these plugins in Python + some other python modules, but IMHO not relevant (e.g. pywbem [3]) 1: https://github.com/kkaempf/cmpi-bindings 2: http://sourceforge.net/apps/mediawiki/pywbem/index.php?title=Provider_Home 3: http://sourceforge.net/apps/mediawiki/pywbem/index.php?title=Main_Page Now, if the Pegasus daemon gets a request, it calls cmpi-bindings, which creates embedded Python [4], loads the python "plugin", and processes the request. If the "plugin" is idle for 15 minutes, it is unloaded by Pegasus (= the embedded Python is destroyed). So far everything works like charm. But, when new request arrives *after* the unload, Pegaasus calls cmpi-bindings again, which tries to create the embedded Python for second time and here I get the crash. [4]: python initialization/shutdown: https://github.com/kkaempf/cmpi-bindings/blob/master/src/target_python.c, TargetInitialize() and TargetCleanup(), some marcos are generated by swig from https://github.com/kkaempf/cmpi-bindings/blob/master/swig/cmpi.i I haven't been able to reproduce the crash with simpler setup (and I have tried, believe me). It is also possible that the Python initialization/shutdown in cmpi-bindings is wrong, but I am not able to find any bug here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 09:38:41 2013 From: report at bugs.python.org (Jan Safranek) Date: Tue, 07 May 2013 07:38:41 +0000 Subject: [issue17922] Crash in clear_weakref In-Reply-To: <1367912280.08.0.116722269635.issue17922@psf.upfronthosting.co.za> Message-ID: <1367912321.44.0.0639738391846.issue17922@psf.upfronthosting.co.za> Jan Safranek added the comment: Bisecting Python mercurial repository, I found the patch which causes the crash: changeset: 80762:7e771f0363e2 branch: 2.7 parent: 80758:29627bd5b333 user: Antoine Pitrou date: Sat Dec 08 21:15:26 2012 +0100 summary: Issue #16602: When a weakref's target was part of a long deallocation chain, the object could remain reachable through its weakref even though its refcount had dropped to zero. If I revert the patch in Python 2.7.4, my setup works fine, without any crash. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 09:39:34 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 07 May 2013 07:39:34 +0000 Subject: [issue17922] Crash in clear_weakref In-Reply-To: <1367912280.08.0.116722269635.issue17922@psf.upfronthosting.co.za> Message-ID: <1367912374.99.0.178217575437.issue17922@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +benjamin.peterson, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 10:14:38 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 May 2013 08:14:38 +0000 Subject: [issue17714] str.encode('base64') add trailing new line character. It is not documented. In-Reply-To: <1365867569.46.0.547710519327.issue17714@psf.upfronthosting.co.za> Message-ID: <3b4YWd4twdzQ1v@mail.python.org> Roundup Robot added the comment: New changeset 8b764c3521fa by Ezio Melotti in branch '2.7': #17714: document that the base64 codec adds a trailing newline. http://hg.python.org/cpython/rev/8b764c3521fa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 10:16:56 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 07 May 2013 08:16:56 +0000 Subject: [issue17714] str.encode('base64') add trailing new line character. It is not documented. In-Reply-To: <1365867569.46.0.547710519327.issue17714@psf.upfronthosting.co.za> Message-ID: <1367914616.26.0.814681769103.issue17714@psf.upfronthosting.co.za> Ezio Melotti added the comment: The str.encode() doc is the wrong place where to document this, since the '\n' is added only for the base64 codec. I added a note about this in the codecs docs[0]. [0]: http://docs.python.org/2/library/codecs.html#standard-encodings ---------- assignee: docs at python -> ezio.melotti resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 10:21:33 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 May 2013 08:21:33 +0000 Subject: [issue17714] str.encode('base64') add trailing new line character. It is not documented. In-Reply-To: <1365867569.46.0.547710519327.issue17714@psf.upfronthosting.co.za> Message-ID: <3b4Ygc4dw1zR8T@mail.python.org> Roundup Robot added the comment: New changeset cbb23e40e0d7 by Ezio Melotti in branch '3.3': #17714: document that the base64 codec adds a trailing newline. http://hg.python.org/cpython/rev/cbb23e40e0d7 New changeset b3e1be1493a5 by Ezio Melotti in branch 'default': #17714: merge with 3.3. http://hg.python.org/cpython/rev/b3e1be1493a5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 10:26:30 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 07 May 2013 08:26:30 +0000 Subject: [issue13515] Consistent documentation practices for security concerns and considerations In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za> Message-ID: <1367915190.52.0.370187759053.issue13515@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 10:30:10 2013 From: report at bugs.python.org (Delhallt) Date: Tue, 07 May 2013 08:30:10 +0000 Subject: [issue17923] test glob with trailing slash fail Message-ID: <1367915410.77.0.862505044661.issue17923@psf.upfronthosting.co.za> New submission from Delhallt: test_glob's trailing_slash tests fails on AIX 6.1/Python 2.7.4: The code section for no_magic/slash case seems to be the issue. Attached patch resolves issue. FAIL: test_glob_directory_with_trailing_slash (test.test_glob.GlobTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/opt/freeware/lib/python2.7/test/test_glob.py", line 120, in test_glob_directory_with_trailing_slash self.assertEqual(res, []) AssertionError: Lists differ: ['@test_7602318_tmp_dir/ZZZ/'] != [] First list contains 1 additional elements. First extra element 0: @test_7602318_tmp_dir/ZZZ/ - ['@test_7602318_tmp_dir/ZZZ/'] + [] ====================================================================== FAIL: test_glob_unicode_directory_with_trailing_slash (test.test_glob.GlobTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/opt/freeware/lib/python2.7/test/test_glob.py", line 137, in test_glob_unicode_directory_with_trailing_slash self.assertEqual(res, []) AssertionError: Lists differ: [u'@test_7602318_tmp_dir/ZZZ/'... != [] First list contains 1 additional elements. First extra element 0: @test_7602318_tmp_dir/ZZZ/ - [u'@test_7602318_tmp_dir/ZZZ/'] + [] ---------- components: Tests files: Python-2.7.4-glob.patch keywords: patch messages: 188635 nosy: delhallt priority: normal severity: normal status: open title: test glob with trailing slash fail type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file30162/Python-2.7.4-glob.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 10:54:58 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 May 2013 08:54:58 +0000 Subject: [issue17922] Crash in clear_weakref In-Reply-To: <1367912280.08.0.116722269635.issue17922@psf.upfronthosting.co.za> Message-ID: <1367916898.11.0.291805020655.issue17922@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hi Jan, First, have you seen the following message on that bug report: http://bugs.python.org/issue16602#msg177180 Second, I would suggest you build a debug build of Python (./configure --with-pydebug), it should give you more information in the stack trace, and allow you to debug using gdb. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 11:55:08 2013 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 07 May 2013 09:55:08 +0000 Subject: [issue11816] Refactor the dis module to provide better building blocks for bytecode analysis In-Reply-To: <1302394810.0.0.38146154248.issue11816@psf.upfronthosting.co.za> Message-ID: <1367920508.3.0.728088130471.issue11816@psf.upfronthosting.co.za> Nick Coghlan added the comment: I checked in the missing file after I woke up this morning. Maybe I'll learn to use hg import instead of patch some day... Sorry for the noise. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 12:43:28 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 07 May 2013 10:43:28 +0000 Subject: [issue17912] thread states should use a doubly-linked list In-Reply-To: <1367871772.2564.1.camel@fsol> Message-ID: Charles-Fran?ois Natali added the comment: > There are a couple other places, IIRC. That said, I'm not sure what the > point is, since a linked list is quite a simple structure anyway? Well, it was just to avoid code duplication, and gain a nice iteration macro ;-) Anyway, I'll submit a patch later today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 12:50:35 2013 From: report at bugs.python.org (Jan Safranek) Date: Tue, 07 May 2013 10:50:35 +0000 Subject: [issue17922] Crash in clear_weakref In-Reply-To: <1367912280.08.0.116722269635.issue17922@psf.upfronthosting.co.za> Message-ID: <1367923835.33.0.365068001702.issue17922@psf.upfronthosting.co.za> Jan Safranek added the comment: > First, have you seen the following message on that bug report: > http://bugs.python.org/issue16602#msg177180 I'm reading it now... I searched for PyWeakref_GET_OBJECT in cmpi-bindings and both occurrences generated by SWIG and both look safe. Is it hidden/wrapped by any other macro? Sorry, I don't know much about python internals and extension development, I'm not author of cmpi-bindings. And I'm attaching stack trace with --with-pydebug. Debugging with gdb is quite a problem, I have gdb linked with distribution Python 2.7.4 and it doesn't cooperate with my custom built python, which I have in LD_LIBRARY_PATH (so Pegasus gets the right one when loading providers). ---------- Added file: http://bugs.python.org/file30163/full-bt.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 12:50:38 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 May 2013 10:50:38 +0000 Subject: [issue17915] Encoding error with sax and codecs In-Reply-To: <1367838846.54.0.113997926456.issue17915@psf.upfronthosting.co.za> Message-ID: <1367923838.67.0.961197676851.issue17915@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It is not working fine on Python 3.3.0. >>> with codecs.open('/tmp/test.txt', 'w', encoding='iso-8859-1') as f: ... xml = XMLGenerator(f, encoding='iso-8859-1') ... xml.startDocument() ... xml.startElement('root', {'attr': u'\u20ac'}) ... xml.endElement('root') ... xml.endDocument() ... Traceback (most recent call last): File "", line 4, in File "/home/serhiy/py/cpython-3.3.0/Lib/xml/sax/saxutils.py", line 141, in startElement self._write(' %s=%s' % (name, quoteattr(value))) File "/home/serhiy/py/cpython-3.3.0/Lib/xml/sax/saxutils.py", line 96, in _write self._out.write(text) File "/home/serhiy/py/cpython-3.3.0/Lib/codecs.py", line 699, in write return self.writer.write(data) File "/home/serhiy/py/cpython-3.3.0/Lib/codecs.py", line 355, in write data, consumed = self.encode(object, self.errors) UnicodeEncodeError: 'latin-1' codec can't encode character '\u20ac' in position 7: ordinal not in range(256) And shouldn't. On Python 2 XMLGenerator works only with binary files and "works" with text files only due implicit str->unicode converting. On Python 3 working with binary files was broken. Issue1470548 restores working with binary file (for which only XMLGenerator can work correctly), but for backward compatibility accepting of text files was left. The problem is that there no trustworthy method to determine whenever a file-like object is binary or text. Accepting of text streams in XMLGenerator should be deprecated in future versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 14:05:20 2013 From: report at bugs.python.org (Christian Heimes) Date: Tue, 07 May 2013 12:05:20 +0000 Subject: [issue17924] Deprecate stat.S_IF* integer constants Message-ID: <1367928320.73.0.37418131168.issue17924@psf.upfronthosting.co.za> New submission from Christian Heimes: Related to #11016 I like to deprecate the S_IF* constants in favor of the S_IS*() functions. rationals: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_stat.h.html No new S_IFMT symbolic names for the file type values of mode_t will be defined by POSIX.1-2008; if new file types are required, they will only be testable through S_ISxx() or S_TYPEISxxx() macros instead. ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 188641 nosy: christian.heimes, docs at python priority: normal severity: normal status: open title: Deprecate stat.S_IF* integer constants type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 14:06:06 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 May 2013 12:06:06 +0000 Subject: [issue17915] Encoding error with sax and codecs In-Reply-To: <1367923838.67.0.961197676851.issue17915@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Accepting of text streams in XMLGenerator should be deprecated in future versions. I agree that the following pattern is strange: with codecs.open('/tmp/test.txt', 'w', encoding='iso-8859-1') as f: xml = XMLGenerator(f, encoding='iso-8859-1') Why would I specify a codec twice? What happens if I specify two different codecs? with codecs.open('/tmp/test.txt', 'w', encoding='utf-8') as f: xml = XMLGenerator(f, encoding='iso-8859-1') It may be simpler (and safer?) to reject text files. If you cannot detect that f is a text file, just make it explicit in the documentation that f must be a binary file. 2013/5/7 Serhiy Storchaka : > > Serhiy Storchaka added the comment: > > It is not working fine on Python 3.3.0. > >>>> with codecs.open('/tmp/test.txt', 'w', encoding='iso-8859-1') as f: > ... xml = XMLGenerator(f, encoding='iso-8859-1') > ... xml.startDocument() > ... xml.startElement('root', {'attr': u'\u20ac'}) > ... xml.endElement('root') > ... xml.endDocument() > ... > Traceback (most recent call last): > File "", line 4, in > File "/home/serhiy/py/cpython-3.3.0/Lib/xml/sax/saxutils.py", line 141, in startElement > self._write(' %s=%s' % (name, quoteattr(value))) > File "/home/serhiy/py/cpython-3.3.0/Lib/xml/sax/saxutils.py", line 96, in _write > self._out.write(text) > File "/home/serhiy/py/cpython-3.3.0/Lib/codecs.py", line 699, in write > return self.writer.write(data) > File "/home/serhiy/py/cpython-3.3.0/Lib/codecs.py", line 355, in write > data, consumed = self.encode(object, self.errors) > UnicodeEncodeError: 'latin-1' codec can't encode character '\u20ac' in position 7: ordinal not in range(256) > > And shouldn't. On Python 2 XMLGenerator works only with binary files and "works" with text files only due implicit str->unicode converting. On Python 3 working with binary files was broken. Issue1470548 restores working with binary file (for which only XMLGenerator can work correctly), but for backward compatibility accepting of text files was left. The problem is that there no trustworthy method to determine whenever a file-like object is binary or text. > > Accepting of text streams in XMLGenerator should be deprecated in future versions. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 14:11:22 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 May 2013 12:11:22 +0000 Subject: [issue17922] Crash in clear_weakref In-Reply-To: <1367912280.08.0.116722269635.issue17922@psf.upfronthosting.co.za> Message-ID: <1367928682.87.0.895891736685.issue17922@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Debugging with gdb is quite a problem, I have gdb linked with distribution Python > 2.7.4 and it doesn't cooperate with my custom built python, which I have in > LD_LIBRARY_PATH Ok. Still, you should be able to inspect the variables at the crash point. Could you try to inspect the `self` variable inside weakref_dealloc, especially `self->wr_object` and its Py_TYPE() value? Also, what is the value of Py_REFCNT(self->wr_object)? AFAICT, the only reason GET_WEAKREFS_LISTPTR() may crash is because of an invalid Py_TYPE(). Which should never happen. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 14:34:39 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 May 2013 12:34:39 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1367930079.05.0.0490049748478.issue17914@psf.upfronthosting.co.za> R. David Murray added the comment: As for why to not return 1, I can imagine code that checks cpu_count, and only if it returns the "don't know" result would it invoke some more expensive method of determining the CPU count on platforms that cpu_count doesn't support. Since the os module is the home for "close to the metal" (well, OS) functions, I agree that it does not make sense to throw away the information that cpu_count can't actually determine the CPU count. Contrawise, I could see the multiprocessing version returning 1, since it is a higher level API and os.cpu_count would be available for those wanting the "don't know" info. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 14:36:49 2013 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 07 May 2013 12:36:49 +0000 Subject: [issue13515] Consistent documentation practices for security concerns and considerations In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za> Message-ID: <1367930209.22.0.363149354189.issue13515@psf.upfronthosting.co.za> Nick Coghlan added the comment: The new section looks good to me. Would it be appropriate to explicitly note that this is a relatively recent change of policy, so most of the stdlib docs don't actually follow it? (and patches to bring them into line would be reasonable) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 14:49:24 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 May 2013 12:49:24 +0000 Subject: [issue13515] Consistent documentation practices for security concerns and considerations In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za> Message-ID: <1367930964.45.0.0586056109665.issue13515@psf.upfronthosting.co.za> R. David Murray added the comment: Probably. Otherwise people are going to go look at the subprocess docs as an example...and they don't follow it. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 15:11:26 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 May 2013 13:11:26 +0000 Subject: [issue13515] Consistent documentation practices for security concerns and considerations In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za> Message-ID: <1367932286.1.0.0611549089544.issue13515@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Patch looks fine to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 15:13:44 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 May 2013 13:13:44 +0000 Subject: [issue17911] Extracting tracebacks does too much work In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1367932424.26.0.743191711545.issue17911@psf.upfronthosting.co.za> Antoine Pitrou added the comment: You may want two pieces of stack: the piece of stack that is above and including the catch point, and the piece of stack that is below it. The former is what gets traditionally printed in tracebacks, but the latter can be useful as well (see issue1553375 for a related feature request). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 15:34:23 2013 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 07 May 2013 13:34:23 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1367933663.43.0.326111132165.issue15392@psf.upfronthosting.co.za> Nick Coghlan added the comment: I've added 2.7 to the affected versions - the core unittest framework should be present in all 3 versions, so the choice of if/when to backport a fix and its test can be made on a case-by-case basis, rather than being a foregone conclusion due to the lack of IDLE test infrastructure in 2.7 If/when mock is used in any tests, then a compatibility module isn't actually needed, 3.3 and 3.4 can just use "from unittest import mock" while 2.7 can use "mock = support.import_module('mock')" (so those tests will run if you arrange to make the mock backport from PyPI available when running the tests, but will be skipped otherwise). Terry, are you happy with that plan? If so, over to you to get the ball rolling and commit this as a starting point :) ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 15:43:48 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 May 2013 13:43:48 +0000 Subject: [issue17915] Encoding error with sax and codecs In-Reply-To: <1367838846.54.0.113997926456.issue17915@psf.upfronthosting.co.za> Message-ID: <1367934228.94.0.820671045334.issue17915@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which adds explicit checks for codecs stream writers and adds tests for these cases. The tests are not entirely honest, they test only that XMLGenerator works with some specially prepared streams. XMLGenerator doesn't work with a stream with arbitrary encoding and errors handler. ---------- keywords: +patch Added file: http://bugs.python.org/file30164/XMLGenerator_codecs_stream.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 15:44:58 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 07 May 2013 13:44:58 +0000 Subject: [issue1545463] New-style classes fail to cleanup attributes Message-ID: <1367934298.15.0.964491187036.issue1545463@psf.upfronthosting.co.za> Richard Oudkerk added the comment: The test seems to be failing on Windows. ---------- nosy: +sbt status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 15:45:56 2013 From: report at bugs.python.org (Pierrick Koch) Date: Tue, 07 May 2013 13:45:56 +0000 Subject: [issue17925] asynchat.async_chat.initiate_send : del deque[0] is not safe Message-ID: <1367934356.3.0.498041746077.issue17925@psf.upfronthosting.co.za> New submission from Pierrick Koch: Dear, del deque[0] is not safe, see the attached patch for the asynchat.async_chat.initiate_send method. fix the "IndexError: deque index out of range" of "del self.producer_fifo[0]" Best, Pierrick Koch ---------- components: Library (Lib) files: asynchat.async_chat.initiate_send.deldeque.patch keywords: patch messages: 188652 nosy: Pierrick.Koch priority: normal severity: normal status: open title: asynchat.async_chat.initiate_send : del deque[0] is not safe type: crash versions: Python 3.3 Added file: http://bugs.python.org/file30165/asynchat.async_chat.initiate_send.deldeque.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 15:47:04 2013 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 07 May 2013 13:47:04 +0000 Subject: [issue12535] Chained tracebacks are confusing because the first traceback is minimal In-Reply-To: <1310405583.64.0.419150537523.issue12535@psf.upfronthosting.co.za> Message-ID: <1367934424.6.0.229151378108.issue12535@psf.upfronthosting.co.za> Nick Coghlan added the comment: Marking this as Library as well, since the traceback module should also be updated. ---------- components: +Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 15:48:21 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 May 2013 13:48:21 +0000 Subject: [issue17915] Encoding error with sax and codecs In-Reply-To: <1367838846.54.0.113997926456.issue17915@psf.upfronthosting.co.za> Message-ID: <1367934501.08.0.28298748936.issue17915@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Of course, if this patch will be committed, perhaps it will be worth to apply it also for 3.2 which has the same regression. ---------- components: +XML stage: needs patch -> patch review versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 15:56:25 2013 From: report at bugs.python.org (Roger Serwy) Date: Tue, 07 May 2013 13:56:25 +0000 Subject: [issue14146] IDLE: source line in editor doesn't highlight when debugging In-Reply-To: <1330401708.67.0.511106941359.issue14146@psf.upfronthosting.co.za> Message-ID: <1367934985.51.0.146722823418.issue14146@psf.upfronthosting.co.za> Roger Serwy added the comment: I'm pinging this issue to see if anyone has had any problems with the Windows-specific workaround for highlighting the selection tags. Issue17511 depends on this fix. ---------- assignee: -> roger.serwy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 15:56:39 2013 From: report at bugs.python.org (Kushal Das) Date: Tue, 07 May 2013 13:56:39 +0000 Subject: [issue12458] Tracebacks should contain the first line of continuation lines In-Reply-To: <1309499207.17.0.676241559437.issue12458@psf.upfronthosting.co.za> Message-ID: <1367934999.03.0.388313341737.issue12458@psf.upfronthosting.co.za> Kushal Das added the comment: I have been able to get the logical line details (start of it), now working on to print the required lines. The current way of showing source lines removes any indentation, but to show all the physical lines (related to the logical line) one should show the indentation to match the source. Is this the correct way I should go forward? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 15:57:03 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 May 2013 13:57:03 +0000 Subject: [issue17915] Encoding error with sax and codecs In-Reply-To: <1367838846.54.0.113997926456.issue17915@psf.upfronthosting.co.za> Message-ID: <1367935023.3.0.536856654471.issue17915@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Perhaps we should add a deprecation warning for codecs streams right in this patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 16:02:57 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 07 May 2013 14:02:57 +0000 Subject: [issue13515] Consistent documentation practices for security concerns and considerations In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za> Message-ID: <1367935377.87.0.423180274173.issue13515@psf.upfronthosting.co.za> Ezio Melotti added the comment: We could use the SSL docs[0] as example instead of subprocess. [0]: http://docs.python.org/3/library/ssl.html#security-considerations ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 16:09:05 2013 From: report at bugs.python.org (Jan Safranek) Date: Tue, 07 May 2013 14:09:05 +0000 Subject: [issue17922] Crash in clear_weakref In-Reply-To: <1367912280.08.0.116722269635.issue17922@psf.upfronthosting.co.za> Message-ID: <1367935744.99.0.720767274392.issue17922@psf.upfronthosting.co.za> Jan Safranek added the comment: > Could you try to inspect the `self` variable inside weakref_dealloc, > especially `self->wr_object` and its Py_TYPE() value? Also, what is the > value of Py_REFCNT(self->wr_object)? in weakref_dealloc at Objects/weakrefobject.c:106: (gdb) p *self $1 = {_ob_next = 0x0, _ob_prev = 0x0, ob_refcnt = 0, ob_type = 0x7fdb8ffc91a0 <_PyWeakref_RefType>} (gdb) p *((PyWeakReference*)self) $7 = {_ob_next = 0x0, _ob_prev = 0x0, ob_refcnt = 0, ob_type = 0x7fdb8ffc91a0 <_PyWeakref_RefType>, wr_object = 0x7fdb9c30bc00 , wr_callback = 0x0, hash = -1, wr_prev = 0x0, wr_next = 0x0} (gdb) p *((PyWeakReference*)self)->wr_object $9 = {_ob_next = 0x0, _ob_prev = 0x0, ob_refcnt = 0, ob_type = 0x0} If I am reading Py_TYPE right, Py_TYPE(self->wr_object) must be 0 (=NULL). seems to be PyTypeObject generated by SWIG in cmpi-bindings, I'll dig into it. Please let me know if there is anything suspicious or worth checking. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 16:31:30 2013 From: report at bugs.python.org (Florent Xicluna) Date: Tue, 07 May 2013 14:31:30 +0000 Subject: [issue4831] exec() behavior - revisited In-Reply-To: <1231080757.34.0.371299910719.issue4831@psf.upfronthosting.co.za> Message-ID: <1367937090.02.0.162294152504.issue4831@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 16:51:10 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 May 2013 14:51:10 +0000 Subject: [issue17922] Crash in clear_weakref In-Reply-To: <1367935744.99.0.720767274392.issue17922@psf.upfronthosting.co.za> Message-ID: <1115063899.22799378.1367938263675.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > (gdb) p *((PyWeakReference*)self)->wr_object > $9 = {_ob_next = 0x0, _ob_prev = 0x0, ob_refcnt = 0, ob_type = 0x0} > > If I am reading Py_TYPE right, Py_TYPE(self->wr_object) must be 0 > (=NULL). Well, no, it should *always* be non-NULL (and it's a strong reference, so it should be a pointer to a valid PyTypeObject). There's nothing in the CPython source code which sets Py_TYPE(something) (i.e. something->ob_type) to NULL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 16:52:51 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 07 May 2013 14:52:51 +0000 Subject: [issue17922] Crash in clear_weakref In-Reply-To: <1367912280.08.0.116722269635.issue17922@psf.upfronthosting.co.za> Message-ID: <1367938371.16.0.760712720468.issue17922@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: swigpyobject_type is a static PyTypeObject variable (similar to all static PyTypeObject structures we write in extension modules, but inside a function) It should never be deallocated... There may be a refcount issue with this object. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 16:58:50 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 May 2013 14:58:50 +0000 Subject: [issue12458] Tracebacks should contain the first line of continuation lines In-Reply-To: <1309499207.17.0.676241559437.issue12458@psf.upfronthosting.co.za> Message-ID: <1367938730.74.0.528125338071.issue12458@psf.upfronthosting.co.za> R. David Murray added the comment: Can you preserve just the *additional* indentation? That is, strip the excess leading whitespace, but preserve the logical indentation, like textwrap.dedent does? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 17:00:44 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 May 2013 15:00:44 +0000 Subject: [issue17925] asynchat.async_chat.initiate_send : del deque[0] is not safe In-Reply-To: <1367934356.3.0.498041746077.issue17925@psf.upfronthosting.co.za> Message-ID: <1367938844.79.0.634614073463.issue17925@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 17:06:49 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 May 2013 15:06:49 +0000 Subject: [issue17922] Crash in clear_weakref In-Reply-To: <1367938371.16.0.760712720468.issue17922@psf.upfronthosting.co.za> Message-ID: <1260652419.22843002.1367939203341.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > swigpyobject_type is a static PyTypeObject variable (similar to all > static PyTypeObject structures we write in extension modules, but > inside a function) > > It should never be deallocated... There may be a refcount issue with > this object. Even if it's deallocated, the Py_TYPE of an instance should never become NULL. At worse it may point to invalid memory. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 17:20:56 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 May 2013 15:20:56 +0000 Subject: [issue1545463] New-style classes fail to cleanup attributes In-Reply-To: <1367934298.15.0.964491187036.issue1545463@psf.upfronthosting.co.za> Message-ID: <1038859778.22881289.1367940050336.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > The test seems to be failing on Windows. Yes. I'll try to setup a new Windows dev environment and take a look :-/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 17:28:50 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 07 May 2013 15:28:50 +0000 Subject: [issue17922] Crash in clear_weakref In-Reply-To: <1367912280.08.0.116722269635.issue17922@psf.upfronthosting.co.za> Message-ID: <1367940530.27.0.430086592093.issue17922@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Right. But this is an embedded interpreter, and SWIG does not call PyType_Ready() again; the old type is returned instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 17:30:25 2013 From: report at bugs.python.org (David Edelsohn) Date: Tue, 07 May 2013 15:30:25 +0000 Subject: [issue17926] PowerLinux dbm failure in 2.7 Message-ID: <1367940625.16.0.48858198554.issue17926@psf.upfronthosting.co.za> New submission from David Edelsohn: The PowerLinux buildslave fails in test_dbm:test_keys() because of a problem with the "in" operator. >>> import dbm >>> d = dbm.open('t','c') >>> a = [('a', 'b'), ('12345678910', '019237410982340912840198242')] >>> for k,v in a: ... d[k] = v ... >>> print d >>> print d.keys() ['a', '12345678910'] >>> print 'a' in d False <--- This apparently should be True >>> print 'a' in d.keys() True ---------- components: Interpreter Core messages: 188666 nosy: David.Edelsohn priority: normal severity: normal status: open title: PowerLinux dbm failure in 2.7 versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 17:31:28 2013 From: report at bugs.python.org (David Edelsohn) Date: Tue, 07 May 2013 15:31:28 +0000 Subject: [issue17926] PowerLinux dbm failure in 2.7 In-Reply-To: <1367940625.16.0.48858198554.issue17926@psf.upfronthosting.co.za> Message-ID: <1367940688.21.0.534446590031.issue17926@psf.upfronthosting.co.za> Changes by David Edelsohn : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 17:31:55 2013 From: report at bugs.python.org (David Edelsohn) Date: Tue, 07 May 2013 15:31:55 +0000 Subject: [issue17926] PowerLinux dbm failure in 2.7 In-Reply-To: <1367940625.16.0.48858198554.issue17926@psf.upfronthosting.co.za> Message-ID: <1367940715.14.0.294527900795.issue17926@psf.upfronthosting.co.za> Changes by David Edelsohn : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 17:32:01 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 May 2013 15:32:01 +0000 Subject: [issue17922] Crash in clear_weakref In-Reply-To: <1367912280.08.0.116722269635.issue17922@psf.upfronthosting.co.za> Message-ID: <1367940721.47.0.846910634765.issue17922@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > But this is an embedded interpreter, and SWIG does not call > PyType_Ready() again; the old type is returned instead. Yuk. Perhaps Dave Beazley can give us some insights here? Jan, one possibility would be for Pegasus to stop "unloading" Python, it seems. ---------- nosy: +dabeaz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 17:38:15 2013 From: report at bugs.python.org (Jan Safranek) Date: Tue, 07 May 2013 15:38:15 +0000 Subject: [issue17922] Crash in clear_weakref In-Reply-To: <1367940530.27.0.430086592093.issue17922@psf.upfronthosting.co.za> Message-ID: <51891FE4.9040104@redhat.com> Jan Safranek added the comment: > Right. But this is an embedded interpreter, and SWIG does not call > PyType_Ready() again; the old type is returned instead. Python crashes in Py_Initialize(). SWIG_init() is called right after it. So even if SWIG calls PyType_Ready, it would be too late. Why python remembers SWIG types after Py_Finalize() in the first place? I want to destroy it and start with fresh instance. Jan ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 17:51:26 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 May 2013 15:51:26 +0000 Subject: [issue17926] PowerLinux dbm failure in 2.7 In-Reply-To: <1367940625.16.0.48858198554.issue17926@psf.upfronthosting.co.za> Message-ID: <1367941886.01.0.817849538848.issue17926@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Can you try the other dbm methods? e.g. has_key(), get()... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 17:54:16 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 07 May 2013 15:54:16 +0000 Subject: [issue17922] Crash in clear_weakref In-Reply-To: <1367912280.08.0.116722269635.issue17922@psf.upfronthosting.co.za> Message-ID: <1367942056.28.0.645884795017.issue17922@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Python remembers SWIG types because SWIG generates code like this: PyTypeObject * SwigPyObject_TypeOnce(void) { static PyTypeObject swigpyobject_type; static int type_init = 0; if (!type_init) { // ... initialization code ... swigpyobject_type = tmp; type_init = 1; if (PyType_Ready(&swigpyobject_type) < 0) return NULL; } } SWIG should reset "type_init" on a fresh interpreter. The initXxx() function should do this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 17:59:57 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 May 2013 15:59:57 +0000 Subject: [issue17926] PowerLinux dbm failure in 2.7 In-Reply-To: <1367940625.16.0.48858198554.issue17926@psf.upfronthosting.co.za> Message-ID: <1367942397.53.0.54308242862.issue17926@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Forget it, can you just try the following patch? diff --git a/Modules/dbmmodule.c b/Modules/dbmmodule.c --- a/Modules/dbmmodule.c +++ b/Modules/dbmmodule.c @@ -168,11 +168,13 @@ dbm_contains(register dbmobject *dp, PyObject *v) { datum key, val; + char *ptr; + Py_ssize_t size; - if (PyString_AsStringAndSize(v, (char **)&key.dptr, - (Py_ssize_t *)&key.dsize)) { + if (PyString_AsStringAndSize(v, &ptr, &size)) return -1; - } + key.dptr = ptr; + key.dsize = size; /* Expand check_dbmobject_open to return -1 */ if (dp->di_dbm == NULL) { ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 18:02:23 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 07 May 2013 16:02:23 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame Message-ID: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> New submission from Guido van Rossum: This came out of some investigations into Tulip reference cycles. I've only confirmed this with 3.3 and 3.4, but I suspect it's a problem in earlier versions too. The scenario is as follows. Consider a object with a method that ends up catching an exception and storing the exception on the object. We know that the __traceback__ attribute of the exception references the stack frame where the exception was caught, so there is a cycle: self -> exception -> traceback -> frame -> self. To break this cycle without disturbing the __traceback__ on the exception, the method sets "self = None" before it returns. (The point of breaking the cycle is that at some later point when the object is deleted the traceback can be printed by the __del__ method.) This works beautifully... Except if the function happens to contain a nested function or a lambda that references 'self'. *Even if the function is never created* (e.g. "if 0: lambda: self"). Then setting "self = None" does not break the cycle. It's not a real leak, because gc.collect() will collect the cycle. But it's still annoying that I can't break the cycle (I don't want to break it at any other point because it would reduce the usefulness of the exception stored on the object). After two days of investigations and thinking about it I found the cause: the presence of the lambda cause a cell to be created into which self is copied, but the original self argument is still referenced by the frame. Setting "self = None" clears the cell but doesn't affect the original self argument. (FWIW, this indicates it's not specifically about self, it's about any argument that gets copied into a cell.) I thought I had a one-line fix (see cellfree.diff attached) but it breaks argument-less super(), which looks at the original first argument. I think I can fix super() (it must introspect the code object to find out into which cell self has been copied, if it finds it NULL), but I have to think about that more. If anyone wants to jump in and suggest an approach to that I'd appreciate it. ---------- assignee: gvanrossum components: Interpreter Core files: cellfree.diff keywords: patch messages: 188672 nosy: gvanrossum priority: normal severity: normal stage: needs patch status: open title: Argument copied into cell still referenced by frame type: resource usage versions: Python 3.3 Added file: http://bugs.python.org/file30166/cellfree.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 18:06:10 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 May 2013 16:06:10 +0000 Subject: [issue17922] Crash in clear_weakref In-Reply-To: <51891FE4.9040104@redhat.com> Message-ID: <37504889.22998280.1367942763564.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > Why python remembers SWIG types after Py_Finalize() in the first > place? > I want to destroy it and start with fresh instance. Because a significant amount of static data inside CPython actually survives Py_Finalize :-/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 18:14:38 2013 From: report at bugs.python.org (David Edelsohn) Date: Tue, 07 May 2013 16:14:38 +0000 Subject: [issue17926] PowerLinux dbm failure in 2.7 In-Reply-To: <1367940625.16.0.48858198554.issue17926@psf.upfronthosting.co.za> Message-ID: <1367943278.63.0.575047607539.issue17926@psf.upfronthosting.co.za> David Edelsohn added the comment: My example and test_dbm succeeds on Python2.7 with your patch applied. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 18:20:22 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 May 2013 16:20:22 +0000 Subject: [issue17926] PowerLinux dbm failure in 2.7 In-Reply-To: <1367940625.16.0.48858198554.issue17926@psf.upfronthosting.co.za> Message-ID: <1367943622.36.0.665954132783.issue17926@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok. This is a classic example of why a big-endian buildbot is useful :) ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 18:48:27 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 07 May 2013 16:48:27 +0000 Subject: [issue17917] use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() when applicable In-Reply-To: <1367845837.62.0.789153792923.issue17917@psf.upfronthosting.co.za> Message-ID: <1367945307.29.0.355781632161.issue17917@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Added file: http://bugs.python.org/file30167/ins_macro-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 19:31:12 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 07 May 2013 17:31:12 +0000 Subject: [issue17912] thread states should use a doubly-linked list In-Reply-To: <1367791359.52.0.60418083975.issue17912@psf.upfronthosting.co.za> Message-ID: <1367947872.51.0.452515931445.issue17912@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- keywords: +needs review, patch stage: needs patch -> patch review Added file: http://bugs.python.org/file30168/pystate.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 19:33:28 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 May 2013 17:33:28 +0000 Subject: [issue16569] Preventing errors of simultaneous access in zipfile In-Reply-To: <1354112511.94.0.436567820333.issue16569@psf.upfronthosting.co.za> Message-ID: <1367948008.96.0.983437155601.issue16569@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- Removed message: http://bugs.python.org/msg176850 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 19:34:00 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 May 2013 17:34:00 +0000 Subject: [issue16569] Preventing errors of simultaneous access in zipfile In-Reply-To: <1354112511.94.0.436567820333.issue16569@psf.upfronthosting.co.za> Message-ID: <1367948040.77.0.894854695253.issue16569@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- Removed message: http://bugs.python.org/msg176851 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 19:57:26 2013 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 07 May 2013 17:57:26 +0000 Subject: [issue17883] Fix buildbot testing of Tkinter In-Reply-To: <1367355915.98.0.26398929673.issue17883@psf.upfronthosting.co.za> Message-ID: <1367949446.06.0.50886177147.issue17883@psf.upfronthosting.co.za> Ezio Melotti added the comment: Here's the traceback: http://buildbot.python.org/all/builders/x86%20Windows%20Server%202003%20%5BSB%5D%202.7/builds/435/steps/test/logs/stdio ====================================================================== ERROR: testLoadWithUNC (test.test_tcl.TclTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "E:\Data\buildslave\cpython\2.7.snakebite-win2k3r2sp2-x86\build\lib\test\test_tcl.py", line 152, in testLoadWithUNC p = Popen(cmd, stdout=PIPE, stderr=PIPE) File "E:\Data\buildslave\cpython\2.7.snakebite-win2k3r2sp2-x86\build\lib\subprocess.py", line 711, in __init__ errread, errwrite) File "E:\Data\buildslave\cpython\2.7.snakebite-win2k3r2sp2-x86\build\lib\subprocess.py", line 948, in _execute_child startupinfo) WindowsError: [Error 5] Access is denied ---------------------------------------------------------------------- Ran 21 tests in 0.578s The buildbot also hangs on test_ttk_guionly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 20:29:22 2013 From: report at bugs.python.org (David Edelsohn) Date: Tue, 07 May 2013 18:29:22 +0000 Subject: [issue17928] PowerLinux getargs.c FETCH_SIZE endianness bug Message-ID: <1367951362.08.0.951682363124.issue17928@psf.upfronthosting.co.za> New submission from David Edelsohn: Another endianness bug that causes a failure in test_structmembers.py. _testcapi reports "string too long" because getargs.c:PyArg_ParseTupleAndKeywords() incorrectly returns a huge value for string_len. The problem is FETCH_ARGS is passing the wrong type to va_arg. It grabs an "int" for the size arg, but that is the not the argument type on 64 bit platforms. This happens to work for little endian because the low part of the 64 bit argument overlaps correctly. Big endian is not as fortuitous. If I change "int" to "long", the testcase succeeds. diff -r a285ce18bd55 Python/getargs.c --- a/Python/getargs.c Mon May 06 18:21:10 2013 -0700 +++ b/Python/getargs.c Tue May 07 11:26:21 2013 -0700 @@ -582,9 +582,9 @@ char *msgbuf, size_t bufsize, PyObject **freelist) { /* For # codes */ -#define FETCH_SIZE int *q=NULL;Py_ssize_t *q2=NULL;\ +#define FETCH_SIZE long *q=NULL;Py_ssize_t *q2=NULL;\ if (flags & FLAG_SIZE_T) q2=va_arg(*p_va, Py_ssize_t*); \ - else q=va_arg(*p_va, int*); + else q=va_arg(*p_va, long*); #define STORE_SIZE(s) \ if (flags & FLAG_SIZE_T) \ *q2=s; \ I am not certain exactly what type it should be, but it definitely needs to be a matching 64 bit type of 64 bit platforms. I believe that this bug exists in all versions. ---------- components: Interpreter Core messages: 188677 nosy: David.Edelsohn, pitrou priority: normal severity: normal status: open title: PowerLinux getargs.c FETCH_SIZE endianness bug type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 20:42:57 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 07 May 2013 18:42:57 +0000 Subject: [issue1545463] New-style classes fail to cleanup attributes Message-ID: <1367952177.62.0.696196841087.issue1545463@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I think the problem is that the __del__ method fails on Windows, maybe because sys.stdout and sys.__stderr__ have been replaced by None. Consider the following program: import os class C: def __del__(self, write=os.write): write(1, b"BEFORE\n") print("__del__ called") write(1, b"AFTER\n") l = [C()] l.append(l) On Unix I get BEFORE __del__ called AFTER but on Windows I only get BEFORE I would suggest using os.write() instead of print() in the tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 20:45:46 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 07 May 2013 18:45:46 +0000 Subject: [issue1545463] New-style classes fail to cleanup attributes Message-ID: <1367952346.74.0.0989980306262.issue1545463@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I will try a fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 20:50:13 2013 From: report at bugs.python.org (Glenn Linderman) Date: Tue, 07 May 2013 18:50:13 +0000 Subject: [issue14191] argparse doesn't allow optionals within positionals In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za> Message-ID: <1367952613.26.0.671753949626.issue14191@psf.upfronthosting.co.za> Glenn Linderman added the comment: Paul, thanks for your continued work. I had reworked your prior patch into a subclass of Argument Parser, and tweaking the code to get parse_intermixed_args to adjust the behaviors I had reported. Now substituting exactly your more flexible new code into my subclass from your latest test_intermixed.py (you should delete your old patches), I can quickly confirm that it works with my applications that used to use my wrapper class, and expect and use intermixed functionality. I also read through all your code and comments and it looks good to me. Regarding parse_fallback_args, I do not see documentation for it. If that is intentional, you might want to add comments in the code regarding its use for testing only... and might want to rename it to _parse_fallback_args. I personally don't see a lot of value to the function, or the new parameter; tests for parse_intermixed_args and parse_known_intermixed_args should be (and have been, thanks) added to the tests for argparse, and should suffice for testing. In non-test code, I see no benefit: either the user uses features that are incompatible with parse_intermixed_args, and thus uses the other features of argparse, or the user, for compatibility reasons, needs to use parse_intermixed_args, and thus is prevented from successfully using the incompatible features. If I'm missing some benefit of parse_fallback_args, it should be explained in either the documentation or the comments. Regarding the terminology: both intermixed and interspersed would be correct English words to describe the use case. So would intermingled :) Because Stephen "blessed" intermixed, and because it is used by getopt documentation (getopt has not been deprecated, optparse has), it seems to be the best term to use. Should optparse someday be removed, along with its documentation, the use of the term interspersed would also disappear, leaving more consistency in terminology. Alternative: Because optparse uses "interspersed" in an API, we cannot fix it to use "intermixed". However, we could fix the uses of "intermixed" to be "interspersed" prior to or at the time of accepting your patch to argparse... afterwards, it would be too late. Personally, I see no problem with the use of both terms in the documentation, and "intermixed" is the shortest, so I have a slight preference for that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 20:55:59 2013 From: report at bugs.python.org (Yuval Greenfield) Date: Tue, 07 May 2013 18:55:59 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1367952959.72.0.281211510505.issue17927@psf.upfronthosting.co.za> Changes by Yuval Greenfield : ---------- nosy: +ubershmekel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 21:14:46 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 07 May 2013 19:14:46 +0000 Subject: [issue1545463] New-style classes fail to cleanup attributes Message-ID: <1367954086.37.0.54840840003.issue1545463@psf.upfronthosting.co.za> Richard Oudkerk added the comment: On Windows my encoding for stdout, stderr is "cp1252" which is implemented in pure python. By the time that _PyGC_DumpShutdownStats() runs the encoding.cp1252 module has been purged so stdout and stderr are broken. I am afraid I will have to leave this to you Antoine... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 21:18:21 2013 From: report at bugs.python.org (Firstname Lastname) Date: Tue, 07 May 2013 19:18:21 +0000 Subject: [issue17929] TypeError using tarfile.addfile() with io.StringIO replacing StringIO.StringIO() Message-ID: <1367954301.44.0.758275221698.issue17929@psf.upfronthosting.co.za> New submission from Firstname Lastname: Trying to work with tarfile library and python 3.3 (Ubuntu 13.04 64-bit) While everything works quite well using StringIO.StringIO() and python 2.7.4, the equivalent code with io.StringIO() and python 3.3.1 doesn't. Is that a bug or am I doing something wrong ? ---------- components: Library (Lib) files: showbug.py messages: 188682 nosy: Firstname.Lastname priority: normal severity: normal status: open title: TypeError using tarfile.addfile() with io.StringIO replacing StringIO.StringIO() type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file30169/showbug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 21:45:10 2013 From: report at bugs.python.org (Till Maas) Date: Tue, 07 May 2013 19:45:10 +0000 Subject: [issue16584] unhandled IOError filecmp.cmpfiles() if file not readable In-Reply-To: <1354300040.38.0.588944499058.issue16584@psf.upfronthosting.co.za> Message-ID: <1367955910.93.0.964605892625.issue16584@psf.upfronthosting.co.za> Till Maas added the comment: When might this be patched in Python 2.X? This Exception makes the function pretty useless for me, since it makes by custom compare script crash. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 22:07:35 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 May 2013 20:07:35 +0000 Subject: [issue17929] TypeError using tarfile.addfile() with io.StringIO replacing StringIO.StringIO() In-Reply-To: <1367954301.44.0.758275221698.issue17929@psf.upfronthosting.co.za> Message-ID: <1367957255.07.0.0934897069289.issue17929@psf.upfronthosting.co.za> R. David Murray added the comment: Basic questions like this aren't really suitable for the tracker, you should use other forums such as the python-list mailing list or the #python irc channel. In Python3, bytes and strings are different classes, but in Python2 they are not. You need to be working with BytesIO. ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 22:11:15 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 May 2013 20:11:15 +0000 Subject: [issue17929] TypeError using tarfile.addfile() with io.StringIO replacing StringIO.StringIO() In-Reply-To: <1367954301.44.0.758275221698.issue17929@psf.upfronthosting.co.za> Message-ID: <1367957475.72.0.937970951316.issue17929@psf.upfronthosting.co.za> R. David Murray added the comment: Bah, I should reread my messages *before* I hit submit. A better phrasing would be "questions like this aren't what the tracker is intended to answer, you will get more and better help from..." :) (The bytes/string split is the most important thing to understand about python3 vs python2.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 23:38:43 2013 From: report at bugs.python.org (Tim Peters) Date: Tue, 07 May 2013 21:38:43 +0000 Subject: [issue17930] Search not needed in combinations_with_replacement Message-ID: <1367962723.84.0.508821715816.issue17930@psf.upfronthosting.co.za> New submission from Tim Peters: Each time thru, CWR searches for the rightmost position not containing the maximum index. But this is wholly determined by what happened the last time thru - search isn't really needed. Here's Python code: def cwr2(iterable, r): pool = tuple(iterable) n = len(pool) if not n and r: return indices = [0] * r yield tuple(pool[i] for i in indices) j = r-1 if n > 1 else -1 while j >= 0: newval = indices[j] + 1 indices[j:] = [newval] * (r - j) yield tuple(pool[i] for i in indices) j = r-1 if newval < n-1 else j-1 There `j` is the rightmost position not containing the maximum index. A little thought suffices to see that the next j is either r-1 (if newval is not the maximum index) or j-1 (if newval is the maximum index: since the indices vector is non-decreasing, if indices[j] was r-2 then indices[j-1] is also at most r-2). I don't much care if this goes in, but Raymond should find it amusing so assigning it to him ;-) ---------- assignee: rhettinger components: Extension Modules keywords: easy messages: 188686 nosy: rhettinger, tim_one priority: low severity: normal stage: needs patch status: open title: Search not needed in combinations_with_replacement type: performance versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 7 23:41:49 2013 From: report at bugs.python.org (Tim Peters) Date: Tue, 07 May 2013 21:41:49 +0000 Subject: [issue17930] Search not needed in combinations_with_replacement In-Reply-To: <1367962723.84.0.508821715816.issue17930@psf.upfronthosting.co.za> Message-ID: <1367962909.14.0.120704416313.issue17930@psf.upfronthosting.co.za> Tim Peters added the comment: Oops! Last part should read "since the indices vector is non-decreasing, if indices[j] was n-2 then indices[j-1] is also at most n-2" That is, the instances of "r-2" in the original should have been "n-2". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 00:11:49 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 May 2013 22:11:49 +0000 Subject: [issue17931] PyLong_FromPid() is not correctly defined on Windows 64-bit Message-ID: <1367964709.89.0.899001899577.issue17931@psf.upfronthosting.co.za> New submission from STINNER Victor: The issue #1983 was not fixed on Windows: pid_t is HANDLE on Windows, which is a pointer. SIZEOF_PID_T is not defined in PC/pyconfig.h and so longobject.h takes the default implementation (use C long type): /* Issue #1983: pid_t can be longer than a C long on some systems */ #if !defined(SIZEOF_PID_T) || SIZEOF_PID_T == SIZEOF_INT #define _Py_PARSE_PID "i" #define PyLong_FromPid PyLong_FromLong #define PyLong_AsPid PyLong_AsLong #elif SIZEOF_PID_T == SIZEOF_LONG ... The consequence is a compiler warning: ..\Modules\posixmodule.c(6603): warning C4244: 'function' : conversion from 'Py_intptr_t' to 'long', possible loss of data [C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\pythoncore.vcxproj] It would be safer to define SIZEOF_PID_T on Windows: #define SIZEOF_PID_T SIZEOF_VOID_P I didn't test attached patch on Windows. Python 3.2 is affected, but I don't think that the issue is important enough to touch this branch (which now only accept security fixes). See also issue #17870. ---------- components: Windows files: win_sizeof_pid_t.patch keywords: patch messages: 188688 nosy: haypo, serhiy.storchaka, tim.golden priority: normal severity: normal status: open title: PyLong_FromPid() is not correctly defined on Windows 64-bit versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30170/win_sizeof_pid_t.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 00:13:30 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 May 2013 22:13:30 +0000 Subject: [issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function In-Reply-To: <1367269025.02.0.400879045482.issue17870@psf.upfronthosting.co.za> Message-ID: <1367964810.01.0.137694930511.issue17870@psf.upfronthosting.co.za> STINNER Victor added the comment: @Mark: any opinion on my patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 00:29:11 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 May 2013 22:29:11 +0000 Subject: [issue1545463] New-style classes fail to cleanup attributes Message-ID: <1367965751.33.0.268662398999.issue1545463@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Your diagnosis seems right about test_garbage_at_shudown (I can reproduce under Linux using `PYTHONIOENCODING=iso8859-15 ./python -m test -v test_gc`). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 00:36:52 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 May 2013 22:36:52 +0000 Subject: [issue1545463] New-style classes fail to cleanup attributes Message-ID: <1367966212.38.0.0875745172958.issue1545463@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 00:38:35 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 May 2013 22:38:35 +0000 Subject: [issue17932] Win64: possible integer overflow in iterobject.c Message-ID: <1367966315.05.0.262623510238.issue17932@psf.upfronthosting.co.za> New submission from STINNER Victor: seqiterobject.it_index type is long, whereas iter_setstate() uses a Py_ssize_t. It would be safer to use Py_ssize_t type for seqiterobject.it_index. The issue emits a compiler warning on Windows 64-bit. iterator.__getstate__() was introduced in Python 3.3, so older versions are not affected. ---------- files: iter_ssize_t.patch keywords: patch messages: 188691 nosy: haypo priority: normal severity: normal status: open title: Win64: possible integer overflow in iterobject.c versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30171/iter_ssize_t.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 00:39:11 2013 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 May 2013 22:39:11 +0000 Subject: [issue17932] Win64: possible integer overflow in iterobject.c In-Reply-To: <1367966315.05.0.262623510238.issue17932@psf.upfronthosting.co.za> Message-ID: <1367966351.1.0.903262384878.issue17932@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't know how to create an "iterator" object. How can I do that? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 01:51:46 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 May 2013 23:51:46 +0000 Subject: [issue17926] PowerLinux dbm failure in 2.7 In-Reply-To: <1367940625.16.0.48858198554.issue17926@psf.upfronthosting.co.za> Message-ID: <3b4yJx2KSpz7Ljj@mail.python.org> Roundup Robot added the comment: New changeset 53da3bad8554 by Antoine Pitrou in branch '2.7': Issue #17926: Fix dbm.__contains__ on 64-bit big-endian machines. http://hg.python.org/cpython/rev/53da3bad8554 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 01:52:12 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 May 2013 23:52:12 +0000 Subject: [issue17926] PowerLinux dbm failure in 2.7 In-Reply-To: <1367940625.16.0.48858198554.issue17926@psf.upfronthosting.co.za> Message-ID: <1367970732.97.0.534521888958.issue17926@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Committed, thank you. ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 01:57:29 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 May 2013 23:57:29 +0000 Subject: [issue17928] PowerLinux getargs.c FETCH_SIZE endianness bug In-Reply-To: <1367951362.08.0.951682363124.issue17928@psf.upfronthosting.co.za> Message-ID: <1367971049.79.0.888979416563.issue17928@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Is it 2.7-only? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 02:07:22 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 May 2013 00:07:22 +0000 Subject: [issue17928] PowerLinux getargs.c FETCH_SIZE endianness bug In-Reply-To: <1367951362.08.0.951682363124.issue17928@psf.upfronthosting.co.za> Message-ID: <3b4yfx2t9nzQxL@mail.python.org> Roundup Robot added the comment: New changeset a199ec80c679 by Antoine Pitrou in branch '2.7': Issue #17928: Fix test_structmembers on 64-bit big-endian machines. http://hg.python.org/cpython/rev/a199ec80c679 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 02:31:06 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 08 May 2013 00:31:06 +0000 Subject: [issue1545463] New-style classes fail to cleanup attributes Message-ID: <1367973066.44.0.428832792731.issue1545463@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch, it seems to work on the custom buildbots. The problem was two-fold: - PyErr_Warn() is too high-level, it will invoke linecache and others - encodings and codecs shouldn't be cleared before the final shutdown ---------- Added file: http://bugs.python.org/file30172/better_shutdown.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 02:32:38 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 08 May 2013 00:32:38 +0000 Subject: [issue17928] PowerLinux getargs.c FETCH_SIZE endianness bug In-Reply-To: <1367951362.08.0.951682363124.issue17928@psf.upfronthosting.co.za> Message-ID: <1367973158.65.0.521236106756.issue17928@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Fixed. _testcapi was actually the culprit. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 02:50:24 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 08 May 2013 00:50:24 +0000 Subject: [issue17933] test_ftp failure / ftplib error formatting issue Message-ID: <1367974224.67.0.224732033427.issue17933@psf.upfronthosting.co.za> New submission from Antoine Pitrou: The following error appeared on some buildbots: http://buildbot.python.org/all/builders/x86%20Gentoo%203.x/builds/4195/steps/test/logs/stdio ====================================================================== ERROR: test_ftp (test.test_urllib2net.OtherNetworkTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/urllib/request.py", line 2337, in retrfile self.ftp.cwd(file) File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/ftplib.py", line 622, in cwd return self.voidcmd(cmd) File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/ftplib.py", line 272, in voidcmd return self.voidresp() File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/ftplib.py", line 245, in voidresp resp = self.getresp() File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/ftplib.py", line 240, in getresp raise error_perm(resp) ftplib.error_perm: 550 Failed to change directory. During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_urllib2net.py", line 112, in test_ftp self._test_urls(urls, self._extra_handlers()) File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_urllib2net.py", line 218, in _test_urls f = urlopen(url, req, TIMEOUT) File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_urllib2net.py", line 33, in wrapped return _retry_thrice(func, exc, *args, **kwargs) File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_urllib2net.py", line 23, in _retry_thrice return func(*args, **kwargs) File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/urllib/request.py", line 462, in open response = self._open(req, data) File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/urllib/request.py", line 480, in _open '_open', req) File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/urllib/request.py", line 440, in _call_chain result = func(*args) File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/urllib/request.py", line 1464, in ftp_open fp, retrlen = fw.retrfile(file, type) File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/urllib/request.py", line 2339, in retrfile raise URLError('ftp error: %d' % reason) from reason TypeError: %d format: a number is required, not error_perm ---------- components: Library (Lib), Tests messages: 188699 nosy: giampaolo.rodola, pitrou, r.david.murray priority: high severity: normal stage: needs patch status: open title: test_ftp failure / ftplib error formatting issue type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 02:58:27 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 08 May 2013 00:58:27 +0000 Subject: [issue17931] PyLong_FromPid() is not correctly defined on Windows 64-bit In-Reply-To: <1367964709.89.0.899001899577.issue17931@psf.upfronthosting.co.za> Message-ID: <1367974707.8.0.0980517424742.issue17931@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 03:51:26 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 May 2013 01:51:26 +0000 Subject: [issue995907] memory leak with threads and enhancement of the timer class Message-ID: <1367977886.45.0.166892096026.issue995907@psf.upfronthosting.co.za> R. David Murray added the comment: Review comments added. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 04:25:49 2013 From: report at bugs.python.org (Rajanikanth Jammalamadaka) Date: Wed, 08 May 2013 02:25:49 +0000 Subject: [issue5492] Error on leaving IDLE with quit() or exit() under Linux In-Reply-To: <1237121077.76.0.63532373748.issue5492@psf.upfronthosting.co.za> Message-ID: <1367979949.47.0.770269167264.issue5492@psf.upfronthosting.co.za> Changes by Rajanikanth Jammalamadaka : ---------- nosy: +Raj _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 04:49:45 2013 From: report at bugs.python.org (wim glenn) Date: Wed, 08 May 2013 02:49:45 +0000 Subject: [issue1551113] random.choice(setinstance) fails Message-ID: <1367981385.3.0.225492265244.issue1551113@psf.upfronthosting.co.za> wim glenn added the comment: The implementation suggested by the OP def choice(self, seq): """Choose a random element from a non-empty sequence.""" idx = int(self.random() * len(seq)) try: result = seq[idx] # raises IndexError if seq is empty except TypeError: result = list(seq)[idx] return result Is broken because input may be a dict with, for example, keys 0 1 and 7 - potentially causing the line result = seq[idx] to pass when logically it should raise. Rather it would be needed to determine from the input whether it was a non-sequence type collection, which sounds pretty hairy... ---------- nosy: +wim.glenn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 04:57:19 2013 From: report at bugs.python.org (wim glenn) Date: Wed, 08 May 2013 02:57:19 +0000 Subject: [issue1551113] random.choice(setinstance) fails Message-ID: <1367981839.25.0.36687012601.issue1551113@psf.upfronthosting.co.za> wim glenn added the comment: How about if isinstance(seq, collections.Sequence): # do it the usual way .. else: return choice(list(seq)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 08:38:29 2013 From: report at bugs.python.org (Phil Webster) Date: Wed, 08 May 2013 06:38:29 +0000 Subject: [issue2704] IDLE: Patch to make PyShell behave more like a Terminal interface In-Reply-To: <1209319360.66.0.583090952017.issue2704@psf.upfronthosting.co.za> Message-ID: <1367995109.76.0.309438121987.issue2704@psf.upfronthosting.co.za> Phil Webster added the comment: After reading about beginners having difficulty with IDLE's terminal behavior, I wrote a (very) simple patch to disable left clicking in the text area. I realize that this doesn't solve the problem completely (and the fact that there is already a patch here), but I wanted to become familiar with the contribution process. Thanks for your patience with me! ---------- nosy: +philwebster Added file: http://bugs.python.org/file30173/Issue2704.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 09:04:54 2013 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 08 May 2013 07:04:54 +0000 Subject: [issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function In-Reply-To: <1367269025.02.0.400879045482.issue17870@psf.upfronthosting.co.za> Message-ID: <1367996694.19.0.899502222371.issue17870@psf.upfronthosting.co.za> Mark Dickinson added the comment: I'll take a look. ---------- assignee: -> mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 09:37:36 2013 From: report at bugs.python.org (Phil Connell) Date: Wed, 08 May 2013 07:37:36 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1367998656.11.0.502607808802.issue17927@psf.upfronthosting.co.za> Changes by Phil Connell : ---------- nosy: +pconnell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 09:37:57 2013 From: report at bugs.python.org (Phil Connell) Date: Wed, 08 May 2013 07:37:57 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1367998677.54.0.89615958794.issue17927@psf.upfronthosting.co.za> Changes by Phil Connell : ---------- nosy: +isoschiz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 09:57:05 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 May 2013 07:57:05 +0000 Subject: [issue16523] attrgetter and itemgetter signatures in docs need cleanup In-Reply-To: <1353510966.46.0.566270540705.issue16523@psf.upfronthosting.co.za> Message-ID: <3b594w3rCmz7LjM@mail.python.org> Roundup Robot added the comment: New changeset 6f2412f12bfd by Ezio Melotti in branch '3.3': #16523: improve attrgetter/itemgetter/methodcaller documentation. http://hg.python.org/cpython/rev/6f2412f12bfd New changeset c2000ce25fe8 by Ezio Melotti in branch 'default': #16523: merge with 3.3. http://hg.python.org/cpython/rev/c2000ce25fe8 New changeset 5885c02120f0 by Ezio Melotti in branch '2.7': #16523: improve attrgetter/itemgetter/methodcaller documentation. http://hg.python.org/cpython/rev/5885c02120f0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 09:57:36 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 08 May 2013 07:57:36 +0000 Subject: [issue16523] attrgetter and itemgetter signatures in docs need cleanup In-Reply-To: <1353510966.46.0.566270540705.issue16523@psf.upfronthosting.co.za> Message-ID: <1367999856.17.0.594422818873.issue16523@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the review! ---------- assignee: docs at python -> ezio.melotti resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 10:05:48 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 08 May 2013 08:05:48 +0000 Subject: [issue16396] Importing ctypes.wintypes on Linux gives a traceback In-Reply-To: <1351956172.0.0.64927799046.issue16396@psf.upfronthosting.co.za> Message-ID: <1368000348.61.0.649879351611.issue16396@psf.upfronthosting.co.za> Ezio Melotti added the comment: That patch is more a workaround than an actual fix. Lib/ctypes/wintypes.py should either fail with an ImportError or be importable. For the former it's possible to catch the ValueError and turn it into an ImportError, or perhaps raise it if some precondition is missing; for the latter, either the creation of that signle class is skipped if _type_ 'v' is not supported, or a way to define it that works on other platforms too should be found instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 10:15:03 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 08 May 2013 08:15:03 +0000 Subject: [issue17877] Skip test_variable_tzname when the zoneinfo database is missing In-Reply-To: <1367312853.26.0.203809750785.issue17877@psf.upfronthosting.co.za> Message-ID: <1368000903.8.0.220164087071.issue17877@psf.upfronthosting.co.za> Ezio Melotti added the comment: > The attached patch checks if /usr/share/zoneinfo or /usr/lib/zoneinfo exist FTR these two locations are described by `man tzfile`: """ This page describes the structure of the timezone files used by tzset(3). These files are typically found under one of the directories /usr/lib/zoneinfo or /usr/share/zoneinfo. """ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 10:16:54 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 May 2013 08:16:54 +0000 Subject: [issue17877] Skip test_variable_tzname when the zoneinfo database is missing In-Reply-To: <1367312853.26.0.203809750785.issue17877@psf.upfronthosting.co.za> Message-ID: <3b59Wp2pVfz7Ljf@mail.python.org> Roundup Robot added the comment: New changeset f7b552020d44 by Ezio Melotti in branch '3.3': #17877: skip test if the Olson's TZ database is missing. http://hg.python.org/cpython/rev/f7b552020d44 New changeset 492eba054e59 by Ezio Melotti in branch 'default': #17877: merge with 3.3. http://hg.python.org/cpython/rev/492eba054e59 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 10:17:24 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 08 May 2013 08:17:24 +0000 Subject: [issue17877] Skip test_variable_tzname when the zoneinfo database is missing In-Reply-To: <1367312853.26.0.203809750785.issue17877@psf.upfronthosting.co.za> Message-ID: <1368001044.13.0.890833645556.issue17877@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 10:22:39 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 08 May 2013 08:22:39 +0000 Subject: [issue995907] memory leak with threads and enhancement of the timer class Message-ID: <1368001359.96.0.679722084848.issue995907@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: IMO, this shouldn't be implemented atop thread, but ought to be a regular thread pool: this way, you won't get behind if some task takes too long to execute, the thread pool can start new threads as needed, and we get the general work submit/cancel (through future) for free. Also, it would probably deserve a new interface in concurrent.futures, as ScheduledExecutor, with new schedule(delay, fn, *args, **kwargs) and schedule_periodic(delay, fn, *args, **kwargs) for one-shot and periodic calls. It would be much more consistant than an ad-hoc implementation in the threading module. ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 10:39:11 2013 From: report at bugs.python.org (koobs) Date: Wed, 08 May 2013 08:39:11 +0000 Subject: [issue17809] FAIL: test_expanduser when $HOME ends with / In-Reply-To: <1366522649.21.0.891133291523.issue17809@psf.upfronthosting.co.za> Message-ID: <1368002351.41.0.761404156738.issue17809@psf.upfronthosting.co.za> koobs added the comment: Spoil Ezio and learn me some python dev guide conventions, with an updated patch generated via hg diff, containing a comment, and including a bug #ID reference ---------- Added file: http://bugs.python.org/file30174/test_posixpath_v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 12:29:33 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 May 2013 10:29:33 +0000 Subject: [issue995907] memory leak with threads and enhancement of the timer class Message-ID: <1368008973.87.0.516213837591.issue995907@psf.upfronthosting.co.za> R. David Murray added the comment: I take your point; I knew there was something bothering me about how the tasks were handled but I didn't consciously see the bug. I like the idea of a ScheduledExecutor. Yael, thanks a lot for working through this, but I think we should probably close this issue and open a new one for adding a ScheduledExecutor to concurrent.futures, and make see-also link from the Timer class to it. Would you be interested in working on it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 13:05:43 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 08 May 2013 11:05:43 +0000 Subject: [issue17932] Win64: possible integer overflow in iterobject.c In-Reply-To: <1367966315.05.0.262623510238.issue17932@psf.upfronthosting.co.za> Message-ID: <1368011143.2.0.441243237171.issue17932@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Create a class with a __getitem__ method but no __iter__: class Seq (object): def __len__(self): return 5 def __getitem__(self, idx): if idx > len(self): raise IndexError(idx) return idx * 2 i = iter(Seq()) ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 13:23:34 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 May 2013 11:23:34 +0000 Subject: [issue1545463] New-style classes fail to cleanup attributes Message-ID: <3b5Fg94zcNz7Ljk@mail.python.org> Roundup Robot added the comment: New changeset 8a5bebea9fec by Antoine Pitrou in branch 'default': Issue #1545463: At shutdown, defer finalization of codec modules so that stderr remains usable. http://hg.python.org/cpython/rev/8a5bebea9fec ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 13:31:26 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 08 May 2013 11:31:26 +0000 Subject: [issue17912] thread states should use a doubly-linked list In-Reply-To: <1367791359.52.0.60418083975.issue17912@psf.upfronthosting.co.za> Message-ID: <1368012686.22.0.514641139782.issue17912@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Your patch looks fine to me, thank you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 13:31:59 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 08 May 2013 11:31:59 +0000 Subject: [issue17809] FAIL: test_expanduser when $HOME ends with / In-Reply-To: <1366522649.21.0.891133291523.issue17809@psf.upfronthosting.co.za> Message-ID: <1368012719.72.0.172357030187.issue17809@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Looks good to me. ---------- nosy: +pitrou stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 13:39:04 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 May 2013 11:39:04 +0000 Subject: [issue17858] Different documentation for identical methods In-Reply-To: <1367103485.02.0.041609834341.issue17858@psf.upfronthosting.co.za> Message-ID: <1368013144.64.0.545436459083.issue17858@psf.upfronthosting.co.za> R. David Murray added the comment: Added review comments with suggestions on improving the wording further. Once we agree on wording we could apply this to the _thread docs as well, I suppose. Ah, I see that one of the changes I found problematic was suggested by Ezio :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 13:54:02 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 08 May 2013 11:54:02 +0000 Subject: [issue17934] Add a frame method to clear expensive details Message-ID: <1368014042.2.0.41504275061.issue17934@psf.upfronthosting.co.za> New submission from Antoine Pitrou: I think we may want to add a finalize() or close() method on frame objects which would clear all local variables (as well as dereference the globals dict, perhaps), after having optionally run a generator's close() method (if the frame belongs to a generator). If I'm not mistaken, it should allow breaking reference cycles, and remove the need for complex traceback processing, which Twisted currently also does: http://twistedmatrix.com/trac/browser/trunk/twisted/python/failure.py#L89 Note that generator cleanup through the frame has a patch in issue17807. (spinned off from issue17911) ---------- components: Interpreter Core messages: 188718 nosy: ncoghlan, pitrou priority: normal severity: normal stage: needs patch status: open title: Add a frame method to clear expensive details type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 13:54:18 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 08 May 2013 11:54:18 +0000 Subject: [issue17934] Add a frame method to clear expensive details In-Reply-To: <1368014042.2.0.41504275061.issue17934@psf.upfronthosting.co.za> Message-ID: <1368014058.35.0.803656303374.issue17934@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- dependencies: +Generator cleanup without tp_del _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 13:55:47 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 08 May 2013 11:55:47 +0000 Subject: [issue17911] Extracting tracebacks does too much work In-Reply-To: <1367789486.16.0.484658151136.issue17911@psf.upfronthosting.co.za> Message-ID: <1368014147.9.0.72679835358.issue17911@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, I've spinned off the frame clearing suggestion to issue17934. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 14:03:24 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 08 May 2013 12:03:24 +0000 Subject: [issue17935] Failed compile on XP buildbot Message-ID: <1368014604.67.0.545390884341.issue17935@psf.upfronthosting.co.za> New submission from Antoine Pitrou: OpenSSL fails compiling on the XP-4 buildbot. Judging by the errors below (snipped), the nasm version may be too old (?) to understand some of the assembler instructions used in the source. David, could you perhaps take a look? http://buildbot.python.org/all/buildslaves/bolen-windows Build: cd "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\" "d:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\PCbuild\python_d.exe" build_ssl.py Release Win32 -a Found a working perl at 'c:\Perl\bin\perl.exe' Executing ssl makefiles: nmake /nologo -f "ms\nt.mak" Building OpenSSL nasm -f win32 -o tmp32\sha1-586.obj tmp32\sha1-586.asm tmp32\sha1-586.asm:2646: warning: label alone on a line without a colon might be in error tmp32\sha1-586.asm:2647: error: parser: instruction expected tmp32\sha1-586.asm:2648: error: symbol `vmovdqa' redefined tmp32\sha1-586.asm:2648: error: parser: instruction expected tmp32\sha1-586.asm:2649: error: symbol `vmovdqa' redefined tmp32\sha1-586.asm:2649: error: parser: instruction expected tmp32\sha1-586.asm:2650: error: symbol `vmovdqa' redefined tmp32\sha1-586.asm:2650: error: parser: instruction expected tmp32\sha1-586.asm:2651: error: symbol `vmovdqa' redefined tmp32\sha1-586.asm:2651: error: parser: instruction expected tmp32\sha1-586.asm:2658: error: symbol `vmovdqa' redefined tmp32\sha1-586.asm:2658: error: parser: instruction expected tmp32\sha1-586.asm:2659: error: symbol `vmovdqa' redefined tmp32\sha1-586.asm:2659: error: parser: instruction expected tmp32\sha1-586.asm:2660: error: symbol `vmovdqa' redefined tmp32\sha1-586.asm:2660: error: parser: instruction expected tmp32\sha1-586.asm:2662: error: symbol `vmovdqa' redefined ---------- components: Build keywords: buildbot messages: 188720 nosy: db3l, loewis, pitrou priority: high severity: normal status: open title: Failed compile on XP buildbot type: compile error versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 15:30:42 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 08 May 2013 13:30:42 +0000 Subject: [issue17807] Generator cleanup without tp_del In-Reply-To: <1366508251.45.0.78173664702.issue17807@psf.upfronthosting.co.za> Message-ID: <1368019842.42.0.121048487165.issue17807@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Updated patch keeping PyGen_NeedsFinalizing() for backwards compatibility (always returning 0). ---------- Added file: http://bugs.python.org/file30175/gen4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 17:35:14 2013 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 08 May 2013 15:35:14 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1368027314.24.0.695444671647.issue17927@psf.upfronthosting.co.za> Guido van Rossum added the comment: Here's a new version that copies the cell into the arg slot instead of just clearing it, with matching code in super() that looks in the cell. I'd appreciate a review from another senior core dev. ---------- keywords: +needs review -patch Added file: http://bugs.python.org/file30176/cellfree2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 17:35:29 2013 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 08 May 2013 15:35:29 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1368027329.9.0.588851262487.issue17927@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 17:44:52 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 May 2013 15:44:52 +0000 Subject: [issue17862] itertools.chunks(iterable, size, fill=None) In-Reply-To: <1367165590.04.0.46648726654.issue17862@psf.upfronthosting.co.za> Message-ID: <1368027892.44.0.548965125863.issue17862@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: A week ago I implemented chunks() on C for issue17804. This is an equivalent of such Python code for unlimited sequences: def chunks(seq, size, start=0): for i in itertools.count(start, size): yield seq[i: i + size] or simpler for limited sequences: def chunks(seq, size, start=0): for i in range(start, len(seq), size): yield seq[i: i + size] Later I gave up the idea when I saw the insignificance of the benefits. Personally I have such arguments against including it in stdlib: 1. While C implemented chunks() is faster than manual iteration, speed up of real loops is not worth the use of special function. 2. This idiom is used less than I expected (about two dozen times in stdlib, not counting tests and tools) and use chunks() saves too little number of lines. In any case Python implementation is only 2-3 lines. 3. This function is not very well suited for the itertools module, because it works with sequences and not with iterators. ---------- keywords: +patch nosy: +serhiy.storchaka Added file: http://bugs.python.org/file30177/iter_chunks.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 17:46:25 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 08 May 2013 15:46:25 +0000 Subject: [issue17921] explicit empty check instead of implicit booleaness In-Reply-To: <1367893097.98.0.624454967229.issue17921@psf.upfronthosting.co.za> Message-ID: <1368027985.19.0.95124436839.issue17921@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 17:58:46 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 08 May 2013 15:58:46 +0000 Subject: [issue17936] O(2) behaviour when adding/removing classes Message-ID: <1368028726.5.0.833825784859.issue17936@psf.upfronthosting.co.za> New submission from Kristj?n Valur J?nsson: We came across this curious phenomenon, when our progam was leaking dynamically created classes. It started spending CPU, to be fixed when gc was increased. The attached .py file demonstrates the problem. The problem is due to how child classes are added to the parent class, in this case, "object". Obsolete code tries to look for a NULL pointer in the entire list of children. In addition, removing child classes is unnecessarily slow. the attached patch fixes these performance issues. ---------- components: Interpreter Core files: slowness.py keywords: patch messages: 188724 nosy: kristjan.jonsson priority: normal severity: normal status: open title: O(2) behaviour when adding/removing classes type: performance versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30178/slowness.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 17:59:59 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Wed, 08 May 2013 15:59:59 +0000 Subject: [issue17936] O(2) behaviour when adding/removing classes In-Reply-To: <1368028726.5.0.833825784859.issue17936@psf.upfronthosting.co.za> Message-ID: <1368028799.15.0.599071920404.issue17936@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Adding the code change patch ---------- Added file: http://bugs.python.org/file30179/subtype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 18:07:32 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 08 May 2013 16:07:32 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368028726.5.0.833825784859.issue17936@psf.upfronthosting.co.za> Message-ID: <1368029252.71.0.974886275319.issue17936@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Funny, I had once noticed this theoretical problem, but it didn't seem to matter concretely, so I hadn't posted about it :) ---------- nosy: +pitrou stage: -> patch review title: O(2) behaviour when adding/removing classes -> O(n**2) behaviour when adding/removing classes versions: -Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 18:12:46 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 May 2013 16:12:46 +0000 Subject: [issue17807] Generator cleanup without tp_del In-Reply-To: <1366508251.45.0.78173664702.issue17807@psf.upfronthosting.co.za> Message-ID: <3b5N4s3tCRzMs9@mail.python.org> Roundup Robot added the comment: New changeset c89febab4648 by Antoine Pitrou in branch 'default': Issue #17807: Generators can now be finalized even when they are part of a reference cycle. http://hg.python.org/cpython/rev/c89febab4648 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 18:13:23 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 08 May 2013 16:13:23 +0000 Subject: [issue17807] Generator cleanup without tp_del In-Reply-To: <1366508251.45.0.78173664702.issue17807@psf.upfronthosting.co.za> Message-ID: <1368029603.6.0.288392672777.issue17807@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Committing for now, we'll see what people say. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 18:50:00 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 08 May 2013 16:50:00 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1368031800.89.0.605396229553.issue17927@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +benjamin.peterson, brett.cannon, georg.brandl, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 18:51:12 2013 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 08 May 2013 16:51:12 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1368031872.32.0.705980560899.issue17927@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 19:44:39 2013 From: report at bugs.python.org (Jesse Ogle) Date: Wed, 08 May 2013 17:44:39 +0000 Subject: [issue11587] METH_KEYWORDS alone gives "METH_OLDARGS is no longer supported!" In-Reply-To: <1300371450.74.0.196347407425.issue11587@psf.upfronthosting.co.za> Message-ID: <1368035079.77.0.538471151737.issue11587@psf.upfronthosting.co.za> Jesse Ogle added the comment: Same error with Python 3.3.1 Objects/methodobject.c: PyCFunction_Call() Switch contains case for "METH_VARARGS | METH_KEYWORDS" but not "METH_KEYWORDS". I assume this is on purpose? ---------- nosy: +jogle versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 20:53:24 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 May 2013 18:53:24 +0000 Subject: [issue17656] Python 2.7.4 breaks ZipFile extraction of zip files with unicode member paths In-Reply-To: <1365391259.55.0.44522935247.issue17656@psf.upfronthosting.co.za> Message-ID: <3b5RfC4szTzR6H@mail.python.org> Roundup Robot added the comment: New changeset 8952fa2c475f by Serhiy Storchaka in branch '2.7': Issue #17656: Skip test_extract_unicode_filenames if the FS encoding http://hg.python.org/cpython/rev/8952fa2c475f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 20:54:39 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 May 2013 18:54:39 +0000 Subject: [issue17656] Python 2.7.4 breaks ZipFile extraction of zip files with unicode member paths In-Reply-To: <1365391259.55.0.44522935247.issue17656@psf.upfronthosting.co.za> Message-ID: <1368039279.31.0.866891843504.issue17656@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry, I thought I had corrected this test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 20:59:51 2013 From: report at bugs.python.org (David Bolen) Date: Wed, 08 May 2013 18:59:51 +0000 Subject: [issue17935] Failed compile on XP buildbot In-Reply-To: <1368014604.67.0.545390884341.issue17935@psf.upfronthosting.co.za> Message-ID: <1368039591.8.0.755097579837.issue17935@psf.upfronthosting.co.za> David Bolen added the comment: Yeah, the XP buildbot was pretty old, at nasm 2.02, so I updated to the same 2.09 as the Win7 buildbot, restarted the last build and it went through compilation fine. However, then it failed in test_ssl, and in checking, it looks like my Win7 buildbot is failing the same way. I thought it might just be an independent problem, but then found issue 15172 from last June (like Jeremy I have 2.09.02) which seems to say OpenSSL 1.0.1+ needs nasm 2.10. In Jeremy's case it only affected his 64-bit build, so maybe that's why I haven't seen it yet, but perhaps with the recent move to 1.0.1d it can affect 32-bit as well? Ah, or wait, there's also issue 17425 that seems to indicate 1.0.1d may be at fault for that test failure. Anyway, I installed the latest nasm 2.10.07 both both XP and Win7, and flushed the openssl tree in the 3.3 and 3.x build branches. In retrying the XP 3.x build it still fails test_ssl, so I don't think there's anything else I can change on the buildbot side as it looks like fixing that needs us to switch to 1.0.1e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 21:10:30 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 May 2013 19:10:30 +0000 Subject: [issue17912] thread states should use a doubly-linked list In-Reply-To: <1367791359.52.0.60418083975.issue17912@psf.upfronthosting.co.za> Message-ID: <3b5S1y0SC1z7LjM@mail.python.org> Roundup Robot added the comment: New changeset 375d4fed4cf2 by Charles-Francois Natali in branch 'default': Issue #17912: Use a doubly linked-list for thread states. http://hg.python.org/cpython/rev/375d4fed4cf2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 21:11:40 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 08 May 2013 19:11:40 +0000 Subject: [issue17935] Failed compile on XP buildbot In-Reply-To: <1368014604.67.0.545390884341.issue17935@psf.upfronthosting.co.za> Message-ID: <1368040300.22.0.302484462484.issue17935@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Yes, the test_ssl failure is orthogonal. Thanks for fixing the compile issue! ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 22:40:20 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 May 2013 20:40:20 +0000 Subject: [issue17656] Python 2.7.4 breaks ZipFile extraction of zip files with unicode member paths In-Reply-To: <1365391259.55.0.44522935247.issue17656@psf.upfronthosting.co.za> Message-ID: <1368045620.62.0.0749540853692.issue17656@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 22:48:20 2013 From: report at bugs.python.org (Tim Peters) Date: Wed, 08 May 2013 20:48:20 +0000 Subject: [issue17930] Search not needed in combinations_with_replacement In-Reply-To: <1367962723.84.0.508821715816.issue17930@psf.upfronthosting.co.za> Message-ID: <1368046100.27.0.459086257324.issue17930@psf.upfronthosting.co.za> Tim Peters added the comment: There's another savings to be had when an index becomes the maximum: in that case, all the indices to its right are already at the maximum, so no need to overwrite them. This isn't as big a savings as skipping the search, but still buys about 10% more in the Python code. Like so: def cwr3(iterable, r): pool = tuple(iterable) n = len(pool) if n == 0 and r: return indices = [0] * r yield tuple(pool[i] for i in indices) rmax, nmax = r-1, n-1 j = rmax if n > 1 else -1 while j >= 0: newval = indices[j] + 1 if newval < nmax: indices[j:] = [newval] * (r - j) j = rmax else: assert newval == nmax indices[j] = newval j -= 1 yield tuple(pool[i] for i in indices) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 22:53:00 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 08 May 2013 20:53:00 +0000 Subject: [issue17912] thread states should use a doubly-linked list In-Reply-To: <1367791359.52.0.60418083975.issue17912@psf.upfronthosting.co.za> Message-ID: <1368046380.77.0.60318621884.issue17912@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 23:14:26 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 08 May 2013 21:14:26 +0000 Subject: [issue17937] Collect garbage harder at shutdown Message-ID: <1368047666.23.0.340381721586.issue17937@psf.upfronthosting.co.za> New submission from Antoine Pitrou: This is a patch to collect cyclic garbage one more time when all modules have been cleared. ---------- components: Interpreter Core files: gc_hard.patch keywords: patch messages: 188736 nosy: pitrou priority: low severity: normal stage: patch review status: open title: Collect garbage harder at shutdown type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file30180/gc_hard.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 23:27:11 2013 From: report at bugs.python.org (Stefan Chrobot) Date: Wed, 08 May 2013 21:27:11 +0000 Subject: [issue17938] Duplicate text in docs/reference/import statement Message-ID: <1368048430.97.0.564979420355.issue17938@psf.upfronthosting.co.za> New submission from Stefan Chrobot: http://docs.python.org/3/reference/simple_stmts.html#the-import-statement After the "Examples", there's a duplicated paragraph: The public names defined by a module are determined by checking the module?s namespace for a variable named __all__; if defined, it must be a sequence of strings which are names defined or imported by that module. The names given in __all__ are all considered public and are required to exist. If __all__ is not defined, the set of public names includes all names found in the module?s namespace which do not begin with an underscore character ('_'). __all__ should contain the entire public API. It is intended to avoid accidentally exporting items that are not part of the API (such as library modules which were imported and used within the module). The from form with * may only occur in a module scope. Attempting to use it in class or function definitions will raise a SyntaxError. The public names defined by a module are determined by checking the module?s namespace for a variable named __all__; if defined, it must be a sequence of strings which are names defined or imported by that module. The names given in __all__ are all considered public and are required to exist. If __all__ is not defined, the set of public names includes all names found in the module?s namespace which do not begin with an underscore character ('_'). __all__ should contain the entire public API. It is intended to avoid accidentally exporting items that are not part of the API (such as library modules which were imported and used within the module). The from form with * may only occur in a module scope. The wild card form of import ? import * ? is only allowed at the module level. Attempting to use it in class or function definitions will raise a SyntaxError. ---------- assignee: docs at python components: Documentation messages: 188737 nosy: docs at python, stefanchrobot priority: normal severity: normal status: open title: Duplicate text in docs/reference/import statement type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 23:31:40 2013 From: report at bugs.python.org (Stefan Chrobot) Date: Wed, 08 May 2013 21:31:40 +0000 Subject: [issue17939] Misleading information about slice assignment in docs Message-ID: <1368048699.98.0.203661524608.issue17939@psf.upfronthosting.co.za> New submission from Stefan Chrobot: http://docs.python.org/3/reference/simple_stmts.html#assignment-statements The docs says: "If the target is a slicing: The primary expression in the reference is evaluated. It should yield a mutable sequence object (such as a list). The assigned object should be a sequence object of the same type." This seems wrong, because the assigned object can be any iterable: a = [4, 5, 6] a[0:0] = range(1, 4) # a is now [1, 2, 3, 4, 5, 6] ---------- assignee: docs at python components: Documentation messages: 188738 nosy: docs at python, stefanchrobot priority: normal severity: normal status: open title: Misleading information about slice assignment in docs type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 23:47:44 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 08 May 2013 21:47:44 +0000 Subject: [issue17938] Duplicate text in docs/reference/import statement In-Reply-To: <1368048430.97.0.564979420355.issue17938@psf.upfronthosting.co.za> Message-ID: <1368049664.52.0.429449486272.issue17938@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 8 23:48:01 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 08 May 2013 21:48:01 +0000 Subject: [issue17939] Misleading information about slice assignment in docs In-Reply-To: <1368048699.98.0.203661524608.issue17939@psf.upfronthosting.co.za> Message-ID: <1368049681.02.0.474182828337.issue17939@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 00:02:55 2013 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 08 May 2013 22:02:55 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1368050575.22.0.724327270052.issue17927@psf.upfronthosting.co.za> Guido van Rossum added the comment: Ok, if I don't hear from anyone soon I'm going to commit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 00:20:31 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 08 May 2013 22:20:31 +0000 Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or operator.index() docos lie) In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za> Message-ID: <1368051631.5.0.415491679603.issue17576@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 00:27:10 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 08 May 2013 22:27:10 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1368052030.75.0.442356284446.issue17927@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: with a unit test maybe? ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 00:28:43 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 08 May 2013 22:28:43 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1368052123.85.0.678505918929.issue17927@psf.upfronthosting.co.za> Antoine Pitrou added the comment: +1 for a unit test! ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 00:32:30 2013 From: report at bugs.python.org (Alex) Date: Wed, 08 May 2013 22:32:30 +0000 Subject: [issue17940] extra code in argparse.py Message-ID: <1368052350.83.0.843381398629.issue17940@psf.upfronthosting.co.za> New submission from Alex: In class HelpFormatter, class _Section, format_help(self) (lines 199 & 200), the two lines for func, args in self.items: func(*args) aren't necessary; the results of func are ignored. "func" is applied (again) on the next line when the output is joined into item_help. Cheers .a ---------- components: Library (Lib) messages: 188742 nosy: aho priority: normal severity: normal status: open title: extra code in argparse.py type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 00:32:57 2013 From: report at bugs.python.org (paul j3) Date: Wed, 08 May 2013 22:32:57 +0000 Subject: [issue11354] argparse: nargs could accept range of options count In-Reply-To: <1298911895.1.0.590272861033.issue11354@psf.upfronthosting.co.za> Message-ID: <1368052377.47.0.750391302772.issue11354@psf.upfronthosting.co.za> paul j3 added the comment: Wouldn't it be simpler to use the re {m,n} notation to grab the appropriate number of arguments? In ArgumentParser _get_nargs_pattern we could add: + # n to m arguments, nargs is re like {n,m} + elif is_mnrep(nargs): + nargs_pattern = '([-A]%s)'%nargs # all others should be integers where is_mnrep() tests that the nargs string looks like '{m,n}' (or '{,n}' or '{m,}'). The resulting nargs_pattern will look like '([-A]{m,n})' In _format_args() a similar addition would be: + elif is_mnrep(action.nargs): + result = '%s%s' % (get_metavar(1)[0], action.nargs) 'FOO{2,5}' It would take more code to generate FOO FOO [FOO [FOO [FOO]]] A matching programmer input would be: parser.add_argument('Foo', nargs='{2,5}') though it wouldn't be much work to also translate a tuple. parser.add_argument('Foo', nargs=(2,5)) I'll try to test this implementation against wm's tests. ---------- nosy: +paul.j3 Added file: http://bugs.python.org/file30181/prelimary.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 00:45:51 2013 From: report at bugs.python.org (Michael Foord) Date: Wed, 08 May 2013 22:45:51 +0000 Subject: [issue17908] Unittest runner needs an option to call gc.collect() after each test In-Reply-To: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za> Message-ID: <1368053151.9.0.783838507861.issue17908@psf.upfronthosting.co.za> Michael Foord added the comment: I'm afraid I'm inclined to agree with Antoine. This seems a relatively specialised problem and I'd expect to see it solved in the test system rather than in unittest itself. One solution, and something I'd like to see, is a way for test systems to extend the unittest command line handling so that they can add extra options. At the moment it's very painful to do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 00:53:02 2013 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 08 May 2013 22:53:02 +0000 Subject: [issue17908] Unittest runner needs an option to call gc.collect() after each test In-Reply-To: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za> Message-ID: <1368053582.88.0.82608757457.issue17908@psf.upfronthosting.co.za> Guido van Rossum added the comment: TBH I would *love* for there to be a standardized way to extend the command line options! If it existed I would help myself. As it is, that's way to complicated. (Then again, most customizations to the default test runner are too complicated IMO. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 02:34:05 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 May 2013 00:34:05 +0000 Subject: [issue17656] Python 2.7.4 breaks ZipFile extraction of zip files with unicode member paths In-Reply-To: <1365391259.55.0.44522935247.issue17656@psf.upfronthosting.co.za> Message-ID: <1368059645.63.0.371088517956.issue17656@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 05:19:03 2013 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 May 2013 03:19:03 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1368069543.54.0.816321792328.issue17927@psf.upfronthosting.co.za> Nick Coghlan added the comment: Guido, did you try combining your first patch (clearing the local var when populating the cell) with your second patch (by only checking for a cell when the local var is cleared rather than when it is populated)? It seems slightly more logical to me to have a cell fallback for the "local ref is NULL" case than it does to special case "local ref is not NULL". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 05:28:09 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 09 May 2013 03:28:09 +0000 Subject: [issue16584] unhandled IOError filecmp.cmpfiles() if file not readable In-Reply-To: <1354300040.38.0.588944499058.issue16584@psf.upfronthosting.co.za> Message-ID: <1368070089.18.0.264631305897.issue16584@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: -> terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 05:43:04 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 May 2013 03:43:04 +0000 Subject: [issue16584] unhandled IOError filecmp.cmpfiles() if file not readable In-Reply-To: <1354300040.38.0.588944499058.issue16584@psf.upfronthosting.co.za> Message-ID: <3b5gPM1Bh2z7LlD@mail.python.org> Roundup Robot added the comment: New changeset 1823cf6e1084 by Terry Jan Reedy in branch '2.7': Issue 16584: in filecomp._cmp, catch IOError as well as os.error. http://hg.python.org/cpython/rev/1823cf6e1084 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 05:46:56 2013 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 09 May 2013 03:46:56 +0000 Subject: [issue17941] namedtuple should support fully qualified name for more portable pickling Message-ID: <1368071216.78.0.0822877752405.issue17941@psf.upfronthosting.co.za> New submission from Eli Bendersky: [this came up as part of the Enum discussions. Full details in this thread: http://mail.python.org/pipermail/python-dev/2013-May/126076.html] namedtuple currently uses this code to obtain the __module__ for the class it creates dynamically so that pickling works: result.__module__ = _sys._getframe(1).f_globals.get('__name__', '__main__') This may not work correctly on all Python implementations, for example IronPython. To support some way to pickle on all implementations, namedtuple should support a fully qualified name for the class: Point = namedtuple('mymodule.Point', ['x', 'y']) If the name is a qualified dotted name, it will be split and the first part becomes the __module__. ---------- components: Library (Lib) messages: 188748 nosy: eli.bendersky, ncoghlan priority: normal severity: normal stage: needs patch status: open title: namedtuple should support fully qualified name for more portable pickling type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 05:53:34 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 09 May 2013 03:53:34 +0000 Subject: [issue16584] unhandled IOError filecmp.cmpfiles() if file not readable In-Reply-To: <1354300040.38.0.588944499058.issue16584@psf.upfronthosting.co.za> Message-ID: <1368071614.86.0.438240152643.issue16584@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I don't use filecmp and cannot reproduce problem on Windows, for reason stated, but this looks correct, so I am taking Till's word that this fixes the problem, at least for him. Intentionally applied to 2.7 only for reason stated by Andrew. Till, if you submit more patches, especially any that are not so trivial, please sign PSF Contributor Licence Agreement. http://www.python.org/psf/contrib/ ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 07:05:28 2013 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 09 May 2013 05:05:28 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1368069543.54.0.816321792328.issue17927@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I thought about that but I like this version better because the super() code does not have to know the details of how to find the cell. On Wednesday, May 8, 2013, Nick Coghlan wrote: > > Nick Coghlan added the comment: > > Guido, did you try combining your first patch (clearing the local var when > populating the cell) with your second patch (by only checking for a cell > when the local var is cleared rather than when it is populated)? > > It seems slightly more logical to me to have a cell fallback for the > "local ref is NULL" case than it does to special case "local ref is not > NULL". > > ---------- > > _______________________________________ > Python tracker > > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 07:09:33 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 09 May 2013 05:09:33 +0000 Subject: [issue14146] IDLE: source line in editor doesn't highlight when debugging In-Reply-To: <1330401708.67.0.511106941359.issue14146@psf.upfronthosting.co.za> Message-ID: <1368076173.23.0.844694023058.issue14146@psf.upfronthosting.co.za> Terry J. Reedy added the comment: 64 bit Win 7 with 32 bit debug build. Patch imported cleanly with all 3 branches. I cannot currently test 2.7. On 3.3 and 3.4, debugger worked fine relative to this issue: editor window highlight tracked line displayed in debugger as far as I checked. Normal selection and Shell Go to file/line highlight seem to work normally. Normal color marking seems not affected. I cannot think of any more manual tests. So if someone else checks 2.7 and it is also ok, I think you should apply this, so if there is any problem, it can show up in other usage. We can deal with a patched tk if and when it happens. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 07:20:18 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 09 May 2013 05:20:18 +0000 Subject: [issue17942] IDLE Debugger: names, values misaligned Message-ID: <1368076818.55.0.00268388045116.issue17942@psf.upfronthosting.co.za> New submission from Terry J. Reedy: The IDLE debugger has subwindows to display name-object bindings for locals and (optionally) globals. They have a gray background. Text is black, object strings get a white background box. The issue is that the white box and text for each name is slightly raised relative to the name. This is somehow especially noticeable to me for something like 'd = 3', resulting in d3 with 3 boxed and raised a bit so it almost looks like a superscript. This is a fairly minor issue, so low priority now unless trivially fixed. But it should be part of polishing IDLE. I am hoping that this is not a tk bug that is terrible to work around. ---------- components: IDLE messages: 188752 nosy: roger.serwy, terry.reedy priority: normal severity: normal stage: needs patch status: open title: IDLE Debugger: names, values misaligned type: enhancement versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 08:13:39 2013 From: report at bugs.python.org (Georg Brandl) Date: Thu, 09 May 2013 06:13:39 +0000 Subject: [issue17943] AttributeError: 'long' object has no attribute 'release' in Queue.put() Message-ID: <1368080019.56.0.453263213436.issue17943@psf.upfronthosting.co.za> New submission from Georg Brandl: I'm a bit puzzled by this exception in a long-running process (running on Python 2.7.3): ... File "/usr/lib/python2.7/Queue.py", line 138, in put self.not_empty.notify() item = ('message', '\x80\x02]q\x01(U\x05nicosq\x02GA\xd4b\xccu\xb0\xc0\xcaK\x15U\x01\nNU\x00e.') self = block = False timeout = None File "/usr/lib/python2.7/threading.py", line 288, in notify waiter.release() waiter = 7128680L self = , 1)> _Condition__waiters = [7128680L] waiters = [7128680L] n = 1 AttributeError: 'long' object has no attribute 'release' As far as I can see, there should only ever be lock objects in the self.__waiters list. Does anyone see a possible reason for the long object to end up there? (Sadly I can't debug the process anymore.) ---------- messages: 188753 nosy: georg.brandl, pitrou priority: normal severity: normal status: open title: AttributeError: 'long' object has no attribute 'release' in Queue.put() type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 08:28:29 2013 From: report at bugs.python.org (Roger Serwy) Date: Thu, 09 May 2013 06:28:29 +0000 Subject: [issue2704] IDLE: Patch to make PyShell behave more like a Terminal interface In-Reply-To: <1209319360.66.0.583090952017.issue2704@psf.upfronthosting.co.za> Message-ID: <1368080909.5.0.564915282075.issue2704@psf.upfronthosting.co.za> Roger Serwy added the comment: Welcome Phil! Your patch looks good and applied cleanly to the default branch and behaves as you specified. Your submission mechanics are good! You might want to look into signing a contributor's agreement: http://docs.python.org/devguide/coredev.html#sign-a-contributor-agreement ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 08:55:42 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 09 May 2013 06:55:42 +0000 Subject: [issue6699] IDLE: Warn user about overwriting a file that has a newer version on filesystem In-Reply-To: <1250207930.18.0.223468874802.issue6699@psf.upfronthosting.co.za> Message-ID: <1368082542.35.0.384273280832.issue6699@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: +Python 2.7, Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 08:58:22 2013 From: report at bugs.python.org (Jan Safranek) Date: Thu, 09 May 2013 06:58:22 +0000 Subject: [issue17922] Crash in clear_weakref In-Reply-To: <37504889.22998280.1367942763564.JavaMail.root@zimbra10-e2.priv.proxad.net> Message-ID: <518B490B.70502@redhat.com> Jan Safranek added the comment: On 05/07/2013 06:06 PM, Antoine Pitrou wrote: > a significant amount of static data inside CPython actually survives > Py_Finalize :-/ As a solution, would it be possible to wipe all registered types in Py_Finalize? Jan ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 09:07:57 2013 From: report at bugs.python.org (Jan Safranek) Date: Thu, 09 May 2013 07:07:57 +0000 Subject: [issue17922] Crash in clear_weakref In-Reply-To: <1367940721.47.0.846910634765.issue17922@psf.upfronthosting.co.za> Message-ID: <518B4B4A.5000109@redhat.com> Jan Safranek added the comment: On 05/07/2013 05:32 PM, Antoine Pitrou wrote: > Jan, one possibility would be for Pegasus to stop "unloading" Python, > it seems. It is always possibility. Actually, Pegasus "plugin" is just a shared object (.so) and the .so is linked with Python. Pegasus calls dlopen() and dlclose() on it. After dlclose(), the "plugin" is removed from memory. Unfortunately, libpython2.7.so stays loaded, at least /proc/XXX/mems says so. If there was a way to unload libpython2.7.so from memory too... Jan ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 10:01:33 2013 From: report at bugs.python.org (paul j3) Date: Thu, 09 May 2013 08:01:33 +0000 Subject: [issue11354] argparse: nargs could accept range of options count In-Reply-To: <1298911895.1.0.590272861033.issue11354@psf.upfronthosting.co.za> Message-ID: <1368086493.28.0.530351863485.issue11354@psf.upfronthosting.co.za> paul j3 added the comment: I think this patch should build on http://bugs.python.org/issue9849, which seeks to improve the error checking for nargs. There, add_argument returns an ArgumentError if the nargs value is not a valid string, interger, or it there is mismatch between a tuple metavar and nargs. This range nargs should be tested at the same time, and return a ArgumentError if possible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 11:39:42 2013 From: report at bugs.python.org (Till Maas) Date: Thu, 09 May 2013 09:39:42 +0000 Subject: [issue16584] unhandled IOError filecmp.cmpfiles() if file not readable In-Reply-To: <1354300040.38.0.588944499058.issue16584@psf.upfronthosting.co.za> Message-ID: <1368092382.2.0.184952621522.issue16584@psf.upfronthosting.co.za> Till Maas added the comment: I just tried on a Windows 8 system with python from GIMP. The error occurs there as well if I compare two empty files after I removed permissions for one of the files. I do not know how to manage Windows' file ACLs in python, therefore I created the test case using the Explorer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 11:47:18 2013 From: report at bugs.python.org (Amit Saha) Date: Thu, 09 May 2013 09:47:18 +0000 Subject: [issue17583] IDLE HOWTO In-Reply-To: <1364685156.29.0.769214841654.issue17583@psf.upfronthosting.co.za> Message-ID: <1368092838.41.0.63936035321.issue17583@psf.upfronthosting.co.za> Amit Saha added the comment: Hello, I just wanted to check if I should attach the image files separately and submit the text as a diff? Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 11:57:51 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 May 2013 09:57:51 +0000 Subject: [issue17944] Refactor test_zipfile Message-ID: <1368093470.65.0.477520947191.issue17944@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Here is a patch which refactors test_zipfile, decreases it's size by 269 lines, makes adding tests for new compression types and new tests for all compression types simpler, and makes test_zipfile discoverable. ---------- components: Tests files: test_zipfile.patch keywords: patch messages: 188760 nosy: alanmcintyre, ezio.melotti, serhiy.storchaka, zach.ware priority: normal severity: normal stage: patch review status: open title: Refactor test_zipfile type: enhancement versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30182/test_zipfile.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 11:58:38 2013 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 May 2013 09:58:38 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: Message-ID: Nick Coghlan added the comment: Ah, I misread the second patch, I think due to the "copy the cell into" in the comment. I believe I would have grasped it immediately if it said something like "reference the cell from". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 12:33:59 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 09 May 2013 10:33:59 +0000 Subject: [issue17941] namedtuple should support fully qualified name for more portable pickling In-Reply-To: <1368071216.78.0.0822877752405.issue17941@psf.upfronthosting.co.za> Message-ID: <1368095639.67.0.257080923102.issue17941@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > If the name is a qualified dotted name, it will be split and the first > part becomes the __module__. That will not work correctly if the module name has a dot in it. ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 13:39:31 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 May 2013 11:39:31 +0000 Subject: [issue16601] Restarting iteration over tarfile continues from where it left off. In-Reply-To: <1354564872.87.0.0661195327337.issue16601@psf.upfronthosting.co.za> Message-ID: <3b5sz65PYhzLq6@mail.python.org> Roundup Robot added the comment: New changeset 9b86fb6f5bc9 by Serhiy Storchaka in branch '2.7': Issue #16601: Restarting iteration over tarfile no more continues from where http://hg.python.org/cpython/rev/9b86fb6f5bc9 New changeset 9ed127d8ad61 by Serhiy Storchaka in branch '3.3': Issue #16601: Restarting iteration over tarfile no more continues from where http://hg.python.org/cpython/rev/9ed127d8ad61 New changeset 1c6a1427353b by Serhiy Storchaka in branch 'default': Issue #16601: Restarting iteration over tarfile no more continues from where http://hg.python.org/cpython/rev/1c6a1427353b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 14:01:14 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 May 2013 12:01:14 +0000 Subject: [issue16601] Restarting iteration over tarfile continues from where it left off. In-Reply-To: <1354564872.87.0.0661195327337.issue16601@psf.upfronthosting.co.za> Message-ID: <1368100874.27.0.219310788859.issue16601@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for contribution. I have committed simpler test. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 14:13:09 2013 From: report at bugs.python.org (Michael Birtwell) Date: Thu, 09 May 2013 12:13:09 +0000 Subject: [issue16601] Restarting iteration over tarfile continues from where it left off. In-Reply-To: <1354564872.87.0.0661195327337.issue16601@psf.upfronthosting.co.za> Message-ID: <1368101589.34.0.0800197801653.issue16601@psf.upfronthosting.co.za> Michael Birtwell added the comment: Sorry about the delay in the contributor form. Things got in the way then I completely forgot about it. It's done now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 14:14:35 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 May 2013 12:14:35 +0000 Subject: [issue16631] tarfile.extractall() doesn't extract everything if .next() was used In-Reply-To: <1354855276.1.0.878015275431.issue16631@psf.upfronthosting.co.za> Message-ID: <1368101675.38.0.180952374377.issue16631@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patch for issue16601 has fixed this issue too. ---------- resolution: -> duplicate stage: patch review -> committed/rejected status: open -> closed superseder: -> Restarting iteration over tarfile continues from where it left off. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 14:18:31 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 May 2013 12:18:31 +0000 Subject: [issue17656] Python 2.7.4 breaks ZipFile extraction of zip files with unicode member paths In-Reply-To: <1365391259.55.0.44522935247.issue17656@psf.upfronthosting.co.za> Message-ID: <1368101911.06.0.84906216675.issue17656@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Shouldn't it left opened until regression fix release has released. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 14:25:24 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 May 2013 12:25:24 +0000 Subject: [issue17809] FAIL: test_expanduser when $HOME ends with / In-Reply-To: <1366522649.21.0.891133291523.issue17809@psf.upfronthosting.co.za> Message-ID: <3b5v034K4zz7LjW@mail.python.org> Roundup Robot added the comment: New changeset dee0a2dea11e by Ezio Melotti in branch '3.3': #17809: fix a test failure in test_expanduser when $HOME has a trailing /. Patch by Kubilay Kocak. http://hg.python.org/cpython/rev/dee0a2dea11e New changeset 489f075430de by Ezio Melotti in branch 'default': #17809: merge with 3.3. http://hg.python.org/cpython/rev/489f075430de ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 14:25:52 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 May 2013 12:25:52 +0000 Subject: [issue17656] Python 2.7.4 breaks ZipFile extraction of zip files with unicode member paths In-Reply-To: <1365391259.55.0.44522935247.issue17656@psf.upfronthosting.co.za> Message-ID: <1368102352.8.0.39628292082.issue17656@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't think so. The bug is fixed, and the fix will be in the release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 14:27:28 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 May 2013 12:27:28 +0000 Subject: [issue17943] AttributeError: 'long' object has no attribute 'release' in Queue.put() In-Reply-To: <1368080019.56.0.453263213436.issue17943@psf.upfronthosting.co.za> Message-ID: <1368102448.48.0.550817845583.issue17943@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Waiters are created through _allocate_lock(), so you should look there. But, unless you have further info, I don't think keeping this open as a bug is useful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 14:27:37 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 09 May 2013 12:27:37 +0000 Subject: [issue17809] FAIL: test_expanduser when $HOME ends with / In-Reply-To: <1366522649.21.0.891133291523.issue17809@psf.upfronthosting.co.za> Message-ID: <1368102457.05.0.563701998803.issue17809@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 14:34:23 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 May 2013 12:34:23 +0000 Subject: [issue17938] Duplicate text in docs/reference/import statement In-Reply-To: <1368048430.97.0.564979420355.issue17938@psf.upfronthosting.co.za> Message-ID: <3b5vBM3wbWzRKZ@mail.python.org> Roundup Robot added the comment: New changeset 844c6442a39e by Ezio Melotti in branch '3.3': #17938: remove duplicate paragraphs. http://hg.python.org/cpython/rev/844c6442a39e New changeset ebc296bf23d1 by Ezio Melotti in branch 'default': #17938: merge with 3.3. http://hg.python.org/cpython/rev/ebc296bf23d1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 14:34:55 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 09 May 2013 12:34:55 +0000 Subject: [issue17938] Duplicate text in docs/reference/import statement In-Reply-To: <1368048430.97.0.564979420355.issue17938@psf.upfronthosting.co.za> Message-ID: <1368102895.86.0.707405891141.issue17938@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the report! ---------- assignee: docs at python -> ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 14:37:50 2013 From: report at bugs.python.org (A.M. Kuchling) Date: Thu, 09 May 2013 12:37:50 +0000 Subject: [issue17700] Update Curses HOWTO for 3.4 In-Reply-To: <1365719687.97.0.644773548697.issue17700@psf.upfronthosting.co.za> Message-ID: <1368103070.48.0.478893200069.issue17700@psf.upfronthosting.co.za> A.M. Kuchling added the comment: I've just verified that I still have commit access to the repo, so unless someone has any further suggested changes to the patch, I'll go ahead and commit it to trunk. Should I also commit it to the 3.3 branch? Victor: I'm willing to improve the HOWTO's discussion of Unicode/wide characters if you can point me at some references. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 14:38:03 2013 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 09 May 2013 12:38:03 +0000 Subject: [issue17941] namedtuple should support fully qualified name for more portable pickling In-Reply-To: <1368071216.78.0.0822877752405.issue17941@psf.upfronthosting.co.za> Message-ID: <1368103083.3.0.498852098404.issue17941@psf.upfronthosting.co.za> Eric V. Smith added the comment: I agree it should work the same as Enum, and I agree it should be possible to supply the module name. But wouldn't it be cleaner as: Point = namedtuple('Point', 'x y z', module=__name__) rather than: Point = namedtuple(__name__ + '.Point', 'x y z') ? ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 14:45:52 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 09 May 2013 12:45:52 +0000 Subject: [issue17700] Update Curses HOWTO for 3.4 In-Reply-To: <1365719687.97.0.644773548697.issue17700@psf.upfronthosting.co.za> Message-ID: <1368103552.39.0.631903465981.issue17700@psf.upfronthosting.co.za> Ezio Melotti added the comment: Patch LGTM. You should commit it to 3.3 and then merge it with default (unless the patch contains parts that are specific to 3.4). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 15:31:11 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 May 2013 13:31:11 +0000 Subject: [issue16741] `int()`, `float()`, etc think python strings are null-terminated In-Reply-To: <1356046641.74.0.314140910069.issue16741@psf.upfronthosting.co.za> Message-ID: <1368106271.04.0.338305190796.issue16741@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks, for 3.4 I will use new formatting feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 15:36:44 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 09 May 2013 13:36:44 +0000 Subject: [issue17941] namedtuple should support fully qualified name for more portable pickling In-Reply-To: <1368071216.78.0.0822877752405.issue17941@psf.upfronthosting.co.za> Message-ID: <1368106604.65.0.0665932363924.issue17941@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 16:36:22 2013 From: report at bugs.python.org (Gregory HOULDSWORTH) Date: Thu, 09 May 2013 14:36:22 +0000 Subject: [issue17945] tkinter/Python 3.3.0: peer_create doesn't instantiate Text Message-ID: <1368110182.39.0.238603513669.issue17945@psf.upfronthosting.co.za> New submission from Gregory HOULDSWORTH: Python version: 3.3.0 32bit OS: Windows 7 Service Pack 1 64bit The peer_create method of the Text class, introduced in changeset <71041c0dedd5> in response to issue <2843> creates a tk text widget but does not instantiate Text. Because they don't exist as Python objects, we have to use tk.call() to manipulate them. This also breaks the nametowidget method used with Text's peer_names, again because these widgets don't exist in Python. Following the inheritance of Text in /Lib/tkinter/__init__.py:2039 Text > Widget > BaseWidget, where the actual widget creation occurs with a call to self.tk.call: self.tk.call( (widgetName, self._w) + extra + self._options(cnf)) We cannot smuggle in the tk command '.myoriginaltext peer create' as a tuple in place of the widgetName ('text') because we end up with the malformed argument: ((.myoriginaltext, 'peer', 'create'), .peer.path ...) The attached file is my second attempt, using subclassing. Lot of code duplication, ugly and not thoroughly tested: I'm hoping a more elegant solution can be found. ---------- components: Tkinter files: pythonlevelpeers.py messages: 188778 nosy: ghoul, gpolo priority: normal severity: normal status: open title: tkinter/Python 3.3.0: peer_create doesn't instantiate Text type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file30183/pythonlevelpeers.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 16:38:35 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 09 May 2013 14:38:35 +0000 Subject: [issue17656] Python 2.7.4 breaks ZipFile extraction of zip files with unicode member paths In-Reply-To: <1365391259.55.0.44522935247.issue17656@psf.upfronthosting.co.za> Message-ID: <1368110315.28.0.648960492338.issue17656@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: http://mail.python.org/pipermail/python-dev/2013-April/125761.html asked to leave bugs open. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 17:10:01 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 May 2013 15:10:01 +0000 Subject: [issue17656] Python 2.7.4 breaks ZipFile extraction of zip files with unicode member paths In-Reply-To: <1365391259.55.0.44522935247.issue17656@psf.upfronthosting.co.za> Message-ID: <1368112201.06.0.918145946703.issue17656@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ah, fair enough. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 17:19:20 2013 From: report at bugs.python.org (Andriy Mysyk) Date: Thu, 09 May 2013 15:19:20 +0000 Subject: [issue17858] Different documentation for identical methods In-Reply-To: <1367103485.02.0.041609834341.issue17858@psf.upfronthosting.co.za> Message-ID: <1368112760.69.0.421852947371.issue17858@psf.upfronthosting.co.za> Andriy Mysyk added the comment: Incorporated R. David Murray's feedback... .. method:: acquire(blocking=True, timeout=-1) Without any optional argument, this method acquires the lock unconditionally, if necessary waiting until it is released by another thread (only one thread at a time can acquire a lock). If *blocking* is ``False``, the call returns immediately. If *blocking* is ``True``, the lock is acquired unconditionally. In both cases the return value indicates whether or not the lock was acquired. If the floating-point *timeout* argument is present and positive, it specifies the maximum wait time in seconds before returning; the return value indicates whether or not the lock was acquired. A negative *timeout* argument specifies an unbounded wait and is the same as not specifying a *timeout* and also setting *blocking* to ``True``. A zero *timeout* is the same as not specifying a *timeout* and setting *blocking* to ``False``. You cannot specify a *timeout* if *blocking* is ``False``. The return value is ``True`` if the lock is acquired successfully, ``False`` if not. ---------- Added file: http://bugs.python.org/file30184/issue17858.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 18:02:49 2013 From: report at bugs.python.org (Guilherme Polo) Date: Thu, 09 May 2013 16:02:49 +0000 Subject: [issue17945] tkinter/Python 3.3.0: peer_create doesn't instantiate Text In-Reply-To: <1368110182.39.0.238603513669.issue17945@psf.upfronthosting.co.za> Message-ID: Guilherme Polo added the comment: Uh.. well observed. It sounds like you are the first actual user of peer_create. Now I wish Tk had done this in a different way: when creating a text widget, specificy that it is a peer of some other text widget via an option ("-peer w" for example). If possible I would like to keep the functionality through the method "peer_create" (and as a minor detail, newPathName should be None by default -- it is easy to pick some name for the peer). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 18:12:42 2013 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 09 May 2013 16:12:42 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1368115962.03.0.0317175199532.issue17927@psf.upfronthosting.co.za> Guido van Rossum added the comment: Ok, here's a version with a unittest. I've also improved the comment that set Nick off the track. ---------- keywords: +patch Added file: http://bugs.python.org/file30185/cellfree3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 18:43:53 2013 From: report at bugs.python.org (Guilherme Polo) Date: Thu, 09 May 2013 16:43:53 +0000 Subject: [issue17945] tkinter/Python 3.3.0: peer_create doesn't instantiate Text In-Reply-To: <1368110182.39.0.238603513669.issue17945@psf.upfronthosting.co.za> Message-ID: Guilherme Polo added the comment: Here is a quick patch for it: http://pastebin.com/m1XQBGqU (I forgot my password for the tracker, and leaving home right now). Does it work for you ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 19:50:31 2013 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 09 May 2013 17:50:31 +0000 Subject: [issue17941] namedtuple should support fully qualified name for more portable pickling In-Reply-To: <1368071216.78.0.0822877752405.issue17941@psf.upfronthosting.co.za> Message-ID: <1368121831.18.0.112737475147.issue17941@psf.upfronthosting.co.za> Guido van Rossum added the comment: Agreed with Eric. We're already modifying PEP 435 to do it that way. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 20:05:16 2013 From: report at bugs.python.org (Lucas Clemente Vella) Date: Thu, 09 May 2013 18:05:16 +0000 Subject: [issue17946] base64 encoding result should be str, not bytes Message-ID: <1368122716.0.0.40098064467.issue17946@psf.upfronthosting.co.za> New submission from Lucas Clemente Vella: As stated in RFC 3548: Base encoding of data is used in many situations to store or transfer data in environments that, perhaps for legacy reasons, are restricted to only US-ASCII [9] data. thus, I was surprised to see, when I used base64 for the first time in python 3, that the encodig result was bytes, not str. Well, if I am encoding something to base64, I am most certainly needing it as a printable ASCII string, not as an binary byte array. Thus, I suggest that the output of: base64.b64encode(data) to be, instead, the output of: base64.b64encode(data).decode('ascii') ---------- components: Library (Lib) messages: 188786 nosy: Lucas.Vella priority: normal severity: normal status: open title: base64 encoding result should be str, not bytes type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 20:20:16 2013 From: report at bugs.python.org (Gregory HOULDSWORTH) Date: Thu, 09 May 2013 18:20:16 +0000 Subject: [issue17945] tkinter/Python 3.3.0: peer_create doesn't instantiate Text In-Reply-To: <1368110182.39.0.238603513669.issue17945@psf.upfronthosting.co.za> Message-ID: <1368123616.84.0.756178815423.issue17945@psf.upfronthosting.co.za> Gregory HOULDSWORTH added the comment: Splendid, it works and is indeed far more elegant. Well done there, thanks. ---------- resolution: -> works for me _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 21:14:12 2013 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 May 2013 19:14:12 +0000 Subject: [issue17946] base64 encoding result should be str, not bytes In-Reply-To: <1368122716.0.0.40098064467.issue17946@psf.upfronthosting.co.za> Message-ID: <1368126852.59.0.305615223436.issue17946@psf.upfronthosting.co.za> R. David Murray added the comment: This has been discussed numerous times. There are just as many times when you want the output to be binary (because you are about to send it on the wire). However, the deciding factor is that the API is now what it is, and changing it at this point would be backward incompatible, so we won't do that. ---------- nosy: +r.david.murray resolution: -> rejected stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 21:19:55 2013 From: report at bugs.python.org (Xavier de Gaye) Date: Thu, 09 May 2013 19:19:55 +0000 Subject: [issue17925] asynchat.async_chat.initiate_send : del deque[0] is not safe In-Reply-To: <1367934356.3.0.498041746077.issue17925@psf.upfronthosting.co.za> Message-ID: <1368127195.3.0.062600621041.issue17925@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The attached script, test_initiate_send.py, tests initiate_send with threads, causing duplicate writes and an IndexError. This is the script output using python on the default branch: $ python test_initiate_send.py --- Test: duplicate data sent --- chat.send('thread data') chat.send('thread data') --- Test: IndexError --- chat.send('thread data') chat.send('thread data') Exception in thread Thread-2: Traceback (most recent call last): File "Lib/threading.py", line 644, in _bootstrap_inner self.run() File "Lib/threading.py", line 601, in run self._target(*self._args, **self._kwargs) File "test_initiate_send.py", line 25, in thread = threading.Thread(target=lambda : chat.push('thread data')) File "Lib/asynchat.py", line 194, in push self.initiate_send() File "Lib/asynchat.py", line 254, in initiate_send del self.producer_fifo[0] IndexError: deque index out of range The script does not fail with Pierrick patch: $ python test_initiate_send.py --- Test: duplicate data sent --- chat.send('main data') chat.send('thread data') --- Test: IndexError --- chat.send('thread data') The patch misses to also appendleft() 'first' when 'num_sent' is zero, which may happen on getting EWOULDBLOCK on send(). ---------- nosy: +xdegaye Added file: http://bugs.python.org/file30186/test_initiate_send.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 9 22:28:26 2013 From: report at bugs.python.org (Zachary Ware) Date: Thu, 09 May 2013 20:28:26 +0000 Subject: [issue17883] Fix buildbot testing of Tkinter In-Reply-To: <1367355915.98.0.26398929673.issue17883@psf.upfronthosting.co.za> Message-ID: <1368131306.7.0.740640279256.issue17883@psf.upfronthosting.co.za> Zachary Ware added the comment: I'm not sure where to go with this from here, without knowing more about what's going wrong. Just to make sure there wasn't anything wrong with the Tcl/Tk build or some manner of issue with things not being properly cleaned up or something, I set the 'custom' builder on that buildbot to build cpython#2.7 and got the same result: http://buildbot.python.org/all/builders/x86%20Windows%20Server%202003%20%5BSB%5D%20custom/builds/9 I've got a few changes lined up to try to get some more output (namely, add a 'print cmd' to the test_tcl test, and hack up Tools/buildbot/test.bat to just run the Tcl/Tk tests in verbose mode to try and get something from test_ttk_guionly), but I don't think we want to pollute the main repository with them. Which direction should we go from here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 00:09:29 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 May 2013 22:09:29 +0000 Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or operator.index() docos lie) In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za> Message-ID: <1368137369.75.0.921014905671.issue17576@psf.upfronthosting.co.za> STINNER Victor added the comment: Alex> In my opinion that should use PyLong_CheckExact +1 ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 00:11:14 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 May 2013 22:11:14 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368028726.5.0.833825784859.issue17936@psf.upfronthosting.co.za> Message-ID: <1368137474.38.0.807252330628.issue17936@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 00:24:14 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 09 May 2013 22:24:14 +0000 Subject: [issue17883] Fix buildbot testing of Tkinter In-Reply-To: <1367355915.98.0.26398929673.issue17883@psf.upfronthosting.co.za> Message-ID: <1368138254.43.0.771936285506.issue17883@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Amaury and Martin: there is a problem on one machine with test.test_tcl.TclTest.testLoadWithUNC that you two jointly wrote, reviewed, and applied in #6470. This issue (17883) is above getting the tcl/tk/tkinter tests to actually be run on 2.7, which they were not before. Zack's patch succeeded in doing that, and the tests all pass on all buildbots except (if I understand correctly) on one Snakebite machine "x86 Windows Server 2003 [SB] 2.7". (According to http://buildbot.python.org/all/builders/, the only other Server-2.7 bot is x86 Windows Server 2008 [SB] 2.7, and that seems not to have run these tests: the most recent(?) log says "test_tk skipped -- DLL load failed: The specified module could not be found.". But if I understand, this was back in January.) With the original f = os.popen('%s -c "import Tkinter; print Tkinter"' % (unc_name,)) f.read() returns '', so 'Tkinter' is not found in the null string and the assertion that it is fails. To get more info -- from an error traceback presumed to be on stderr -- we tried using subprocess.POpen instead and the child process startup fails with "WindowsError: [Error 5] Access is denied", so the Python import is never tried. Unless there is an error in the subprocess call or if Win Servers require a different version of UNC, it would seem that the test is not at fault. a) Is Windows Server 2003 is really meant to be spported? b) Are UNCs expected to behave differently on Server 2003? c) Can UNCs be disabled on a particular machine? In other words, should we just ignore this error, and possibly catch it with 'except WinError"? ---------- nosy: +amaury.forgeotdarc, loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 00:37:42 2013 From: report at bugs.python.org (Michael Foord) Date: Thu, 09 May 2013 22:37:42 +0000 Subject: [issue17908] Unittest runner needs an option to call gc.collect() after each test In-Reply-To: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za> Message-ID: <1368139062.93.0.581466063456.issue17908@psf.upfronthosting.co.za> Michael Foord added the comment: The default test runner is quite horrible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 01:22:41 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 09 May 2013 23:22:41 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1368141761.96.0.698986474442.issue17927@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Consider the following testcase class X: def meth(self): print(self) super() def f(): k = X() def g(): return k return g c = f().__closure__[0] X.meth(c) With patch $ ./python unboxing.py Without patch $ ./python unboxing.py Traceback (most recent call last): File "x.py", line 12, in X.meth(c) File "x.py", line 4, in meth super() TypeError: super(type, obj): obj must be an instance or subtype of type Maybe you don't care. OTOH, perhaps it could be fixed by checking if the first argument is in fact a closure in super(). In the best world, super() would be syntax instead of a call, and we would just push the __class__ the closure and first argument in the interpreter loop. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 01:29:08 2013 From: report at bugs.python.org (paul j3) Date: Thu, 09 May 2013 23:29:08 +0000 Subject: [issue11354] argparse: nargs could accept range of options count In-Reply-To: <1298911895.1.0.590272861033.issue11354@psf.upfronthosting.co.za> Message-ID: <1368142148.98.0.805912612398.issue11354@psf.upfronthosting.co.za> paul j3 added the comment: This patch adds this `nargs='{m,n}'` or `nargs=(m,n)` feature. It builds on the `better nargs error message` patch in http://bugs.python.org/msg187754 It includes an argparse.rst paragraph, changes to argparse.py, and additions to test_argparse.py. The tests include those proposed by wm, rewritten to use the ParserTestCase framework where possible. I did not give a lot of thought to test names. The coverage could also use further thought. As WM noted some range cases are the equivalent to existing nargs options ('{1,}'=='+'). I did not attempt to code or test such equivalences. Since the '{0,}' form uses regex matching just like '*', I don't think there is any advantage to making such a translation. I convert the tuple version (m,n) to the re string '{m,n}' during the add_argument() testing. So it is the string form that is added to the parser action. This is also the format that appears in usage. The documentation paragraph is: '{m,n}'. m to n command-line arguments are gathered into a list. This is modeled on the Regular Expression use. '{,n}' gathers up to n arguments. '{m,}' gathers m or more. Thus '{1,}' is the equivalent to '+', and '{,1}' to '?'. A tuple notation is also accepted, '(m,n)', '(None,n)', '(m,None)'. For example: >>> parser = argparse.ArgumentParser(prog='PROG') >>> parser.add_argument('--foo', nargs='{2,4}') >>> parser.parse_args('--foo a b c'.split()) Namespace(foo=['a', 'b', 'c']) >>> parser.parse_args('--foo a'.split()) usage: PROG [-h] [--foo FOO{2,4}] PROG: error: argument --foo: expected {2,4} arguments ---------- Added file: http://bugs.python.org/file30187/nargsrange.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 01:36:30 2013 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 09 May 2013 23:36:30 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1368142590.82.0.108600329943.issue17927@psf.upfronthosting.co.za> Guido van Rossum added the comment: I see. I really don't care, it's extremely rare to see a closure object. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 02:14:50 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 May 2013 00:14:50 +0000 Subject: [issue17700] Update Curses HOWTO for 3.4 In-Reply-To: <1365719687.97.0.644773548697.issue17700@psf.upfronthosting.co.za> Message-ID: <3b6Bkc2b3vz7Llj@mail.python.org> Roundup Robot added the comment: New changeset 1fa70b797973 by Andrew Kuchling in branch '3.3': #17700: update the curses HOWTO for 3.x http://hg.python.org/cpython/rev/1fa70b797973 New changeset 70f530161b9b by Andrew Kuchling in branch 'default': #17700: merge with 3.3 http://hg.python.org/cpython/rev/70f530161b9b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 02:16:54 2013 From: report at bugs.python.org (A.M. Kuchling) Date: Fri, 10 May 2013 00:16:54 +0000 Subject: [issue17700] Update Curses HOWTO for 3.4 In-Reply-To: <1365719687.97.0.644773548697.issue17700@psf.upfronthosting.co.za> Message-ID: <1368145014.9.0.666161614149.issue17700@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Applied to 3.3 and 3.4. I'll leave this issue open for a week so that Victor can comment on Unicode/wide-characters. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 02:22:44 2013 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 10 May 2013 00:22:44 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1368145364.45.0.366936504493.issue17927@psf.upfronthosting.co.za> Guido van Rossum added the comment: cellfree4.diff. Addressed review: - Moved test to test_scope.py - Added @cpython_only - Fixed comment indent (and removed tabs :-) - Fixed missing NULL test I decided to keep the super() call; it's likely that it's tested elsewhere but I don't want to verify that there really is a test that puts self into a cell *and* uses super(). I also decided not to bother rewriting the test using weakrefs. Let me know if you really want me to do that. ---------- Added file: http://bugs.python.org/file30188/cellfree4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 02:55:46 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 May 2013 00:55:46 +0000 Subject: [issue14878] Improve documentation for generator.send method In-Reply-To: <1337662493.01.0.380911981252.issue14878@psf.upfronthosting.co.za> Message-ID: <3b6Cds2vxzz7LjP@mail.python.org> Roundup Robot added the comment: New changeset 7b8c0bf8fcb8 by Andrew Kuchling in branch '2.7': #14878: add cross-reference to the yield statement. http://hg.python.org/cpython/rev/7b8c0bf8fcb8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 02:56:12 2013 From: report at bugs.python.org (A.M. Kuchling) Date: Fri, 10 May 2013 00:56:12 +0000 Subject: [issue14878] Improve documentation for generator.send method In-Reply-To: <1337662493.01.0.380911981252.issue14878@psf.upfronthosting.co.za> Message-ID: <1368147372.87.0.801652147466.issue14878@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Thanks for the patch! ---------- nosy: +akuchling resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 03:19:45 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 10 May 2013 01:19:45 +0000 Subject: [issue14878] Improve documentation for generator.send method In-Reply-To: <1337662493.01.0.380911981252.issue14878@psf.upfronthosting.co.za> Message-ID: <1368148785.92.0.750465948582.issue14878@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: needs patch -> committed/rejected type: -> enhancement versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 04:22:27 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 May 2013 02:22:27 +0000 Subject: [issue17841] Remove missing aliases from codecs documentation In-Reply-To: <1366878629.86.0.715834730144.issue17841@psf.upfronthosting.co.za> Message-ID: <3b6FYv1F8bzR2w@mail.python.org> Roundup Robot added the comment: New changeset ead47bc3a763 by Ezio Melotti in branch '3.3': #17841: remove missing codecs aliases from the documentation. Patch by Thomas Fenzl. http://hg.python.org/cpython/rev/ead47bc3a763 New changeset eafff38a56cc by Ezio Melotti in branch 'default': #17841: merge with 3.3. http://hg.python.org/cpython/rev/eafff38a56cc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 04:29:06 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 10 May 2013 02:29:06 +0000 Subject: [issue17841] Remove missing aliases from codecs documentation In-Reply-To: <1366878629.86.0.715834730144.issue17841@psf.upfronthosting.co.za> Message-ID: <1368152946.2.0.898167439877.issue17841@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the patch! @Nick While this works as a short-term solution, I think it would be good to 1) reintroduce the aliases in 3.4 (so that codecs.encode(b'foo', 'base64') works without spelling out the full codec name); 2) either separate these codecs from the others, or tweak the error message of str.encode/bytes.decode to point to codecs.encode/decode. Should I create a new issue and/or ask python-dev about this? ---------- assignee: docs at python -> ezio.melotti resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed type: behavior -> enhancement versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 04:42:35 2013 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 10 May 2013 02:42:35 +0000 Subject: [issue17828] More informative error handling when encoding and decoding In-Reply-To: <1366812598.92.0.4116744942.issue17828@psf.upfronthosting.co.za> Message-ID: <1368153755.14.0.145166690264.issue17828@psf.upfronthosting.co.za> Nick Coghlan added the comment: Ezio pointed out on IRC that the extra type checks in str.encode, bytes.decode and bytearray.decode should reference the appopriate codecs module function in addition to the codec in use. So if str.encode produces something other than bytes, it should reference codecs.encode, while the binary decoding methods should mention codecs.decode if they produce something other than str. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 04:52:17 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 10 May 2013 02:52:17 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1368154337.35.0.746068692828.issue17927@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I think it looks good now. I'll probably just rewrite the test once you commit it. ---------- keywords: -needs review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 04:54:22 2013 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 10 May 2013 02:54:22 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1368154462.07.0.286276446384.issue17927@psf.upfronthosting.co.za> Nick Coghlan added the comment: Looks good to me, too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 05:22:37 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 10 May 2013 03:22:37 +0000 Subject: [issue17828] More informative error handling when encoding and decoding In-Reply-To: <1366812598.92.0.4116744942.issue17828@psf.upfronthosting.co.za> Message-ID: <1368156157.04.0.266620918345.issue17828@psf.upfronthosting.co.za> Ezio Melotti added the comment: The attached patch changes the error message of str.encode/bytes.decode when the codec returns the wrong type: >>> import codecs >>> 'example'.encode('rot_13') TypeError: encoder returned 'str' instead of 'bytes', use codecs.decode for str->str conversions >>> codecs.encode('example', 'rot_13') 'rknzcyr' >>> >>> b'000102'.decode('hex_codec') TypeError: decoder returned 'bytes' instead of 'str', use codecs.encode for bytes->bytes conversions >>> codecs.decode(b'000102', 'hex_codec') b'\x00\x01\x02' This only solves part of the problem though, because individual codecs might raise other errors if the input type is wrong: >>> 'example'.encode('hex_codec') Traceback (most recent call last): File "/home/wolf/dev/py/py3k/Lib/encodings/hex_codec.py", line 16, in hex_encode return (binascii.b2a_hex(input), len(input)) TypeError: 'str' does not support the buffer interface ---------- keywords: +patch Added file: http://bugs.python.org/file30189/issue17828-1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 05:52:40 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 10 May 2013 03:52:40 +0000 Subject: [issue17828] More informative error handling when encoding and decoding In-Reply-To: <1366812598.92.0.4116744942.issue17828@psf.upfronthosting.co.za> Message-ID: <1368157960.54.0.28244812057.issue17828@psf.upfronthosting.co.za> Ezio Melotti added the comment: To summarize: * str.encode does only str->bytes; * bytes.decode does only bytes-> str; * codecs.encode/decode do obj->obj; The things that could go wrong are: 1) the input type is wrong (i.e. the codec doesn't accept the type of the input); 2) the input value is invalid; 3) for str.encode/bytes.decode only, the output type is wrong (i.e. the codec returned a non-bytes/non-str object); My patch only covers 3. The four new exceptions suggested by Nick in msg187704 would cover the first 2 cases. For str.encode/bytes.decode, if we knew the input type accepted by the codec we could also provide a better error message (e.g. "codecs accepts '...', not '...'; use ... instead"), but we don't. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 06:36:13 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 10 May 2013 04:36:13 +0000 Subject: [issue17828] More informative error handling when encoding and decoding In-Reply-To: <1366812598.92.0.4116744942.issue17828@psf.upfronthosting.co.za> Message-ID: <1368160573.65.0.704549183111.issue17828@psf.upfronthosting.co.za> Ezio Melotti added the comment: The attached proof of concept catches Type/ValueError in str.encode and raises another exception with a better message: >>> 'example'.encode('hex_codec') Traceback (most recent call last): File "", line 1, in TypeError: invalid input type for hex_codec codec ('str' does not support the buffer interface) (note: the patch doesn't handle the exception chaining yet and probably leaks.) If Nick proposal in msg187704 is accepted, this should become a codecs.EncodeTypeError. The same should then be done for bytes.decode and for codecs.encode/decode. ---------- Added file: http://bugs.python.org/file30190/issue17828-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 06:45:14 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 10 May 2013 04:45:14 +0000 Subject: [issue17282] document the defaultTest parameter to unittest.main() In-Reply-To: <1361664894.83.0.085559336561.issue17282@psf.upfronthosting.co.za> Message-ID: <1368161114.71.0.298975183935.issue17282@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: needs patch -> patch review versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 08:03:37 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 May 2013 06:03:37 +0000 Subject: [issue17576] PyNumber_Index() is not int-subclass friendly (or operator.index() docos lie) In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za> Message-ID: <1368165817.7.0.49653127526.issue17576@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: if (PyLong_CheckExact(item) || (PyLong_Check(item) && item->ob_type->tp_as_number->nb_index == PyLong_Type.tp_as_number->nb_index)) ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 08:39:07 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 10 May 2013 06:39:07 +0000 Subject: [issue17883] Fix buildbot testing of Tkinter In-Reply-To: <1367355915.98.0.26398929673.issue17883@psf.upfronthosting.co.za> Message-ID: <1368167946.98.0.147619613176.issue17883@psf.upfronthosting.co.za> Martin v. L?wis added the comment: > a) Is Windows Server 2003 is really meant to be spported? Yes > b) Are UNCs expected to behave differently on Server 2003? No. > c) Can UNCs be disabled on a particular machine? I may misunderstand "can": yes, it is possible, but no, it is not desirable. Zach: Temporarily committing changes to test specific buildbot issues is fine; asking the slave operator for direct access to the machine may also work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 08:50:01 2013 From: report at bugs.python.org (Ethan Furman) Date: Fri, 10 May 2013 06:50:01 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum Message-ID: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> New submission from Ethan Furman: PEP-0435 has been approved! Now for lots of code review. ---------- assignee: docs at python components: Documentation, Library (Lib), Tests files: ref435.py hgrepos: 189 messages: 188812 nosy: barry, docs at python, eli.bendersky, stoneleaf priority: normal severity: normal status: open title: Code, test, and doc review for PEP-0435 Enum versions: Python 3.4 Added file: http://bugs.python.org/file30191/ref435.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 08:55:46 2013 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 10 May 2013 06:55:46 +0000 Subject: [issue17841] Remove missing aliases from codecs documentation In-Reply-To: <1366878629.86.0.715834730144.issue17841@psf.upfronthosting.co.za> Message-ID: <1368168946.39.0.214714675619.issue17841@psf.upfronthosting.co.za> Nick Coghlan added the comment: For anyone else reading the issue and wondering about Ezio's question above - this issue was actually spun out from issue 7475, which covers the long saga of getting these codecs fully restored in the new world order of Python 3 :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 08:58:11 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 10 May 2013 06:58:11 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368169091.9.0.066335906963.issue17947@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 09:01:10 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 10 May 2013 07:01:10 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368169270.2.0.463214846124.issue17947@psf.upfronthosting.co.za> Ezio Melotti added the comment: Can you upload the patch as a diff against the CPython repo? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 09:09:03 2013 From: report at bugs.python.org (Ethan Furman) Date: Fri, 10 May 2013 07:09:03 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368169743.23.0.07951913795.issue17947@psf.upfronthosting.co.za> Ethan Furman added the comment: Here it is (I hope ;) . ---------- keywords: +patch Added file: http://bugs.python.org/file30192/pep-435.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 09:43:49 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIFZpZGFsIFBhbmFsw6lz?=) Date: Fri, 10 May 2013 07:43:49 +0000 Subject: [issue17948] HTTPS and sending a big file size hangs. Message-ID: <1368171829.05.0.903022030282.issue17948@psf.upfronthosting.co.za> New submission from Jes?s Vidal Panal?s: This bug was found using Mercurial. All the information it's on this bug link http://bz.selenic.com/show_bug.cgi?id=3905 The bug was introduced on 2.7.3, previous versions works fine. ---------- components: Windows messages: 188816 nosy: jesusvpct priority: normal severity: normal status: open title: HTTPS and sending a big file size hangs. type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 10:35:28 2013 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 10 May 2013 08:35:28 +0000 Subject: [issue16133] asyncore.dispatcher.recv doesn't handle EAGAIN / EWOULDBLOCK In-Reply-To: <1349366792.42.0.417654527681.issue16133@psf.upfronthosting.co.za> Message-ID: <1368174928.38.0.027262086241.issue16133@psf.upfronthosting.co.za> Xavier de Gaye added the comment: For the reson why read() must still check for EWOULDBLOCK even though after select() has reported a file descriptor ready for reading, see the BUGS section of select linux man page, which says: Under Linux, select() may report a socket file descriptor as "ready for reading", while nevertheless a subsequent read blocks. This could for example happen when data has arrived but upon examination has wrong checksum and is discarded. There may be other circumstances in which a file descriptor is spuriously reported as ready. Thus it may be safer to use O_NONBLOCK on sockets that should not block. ---------- nosy: +xdegaye _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 10:41:42 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 10 May 2013 08:41:42 +0000 Subject: [issue17908] Unittest runner needs an option to call gc.collect() after each test In-Reply-To: <1368053582.88.0.82608757457.issue17908@psf.upfronthosting.co.za> Message-ID: <198367512.28990841.1368175295122.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > TBH I would *love* for there to be a standardized way to extend the > command line options! If it existed I would help myself. As it is, > that's way to complicated. (Then again, most customizations to the > default test runner are too complicated IMO. :-) +1. I found myself wanting to add a "-F" option ? la regrtest, and I ended up processing sys.argv manually :-/ ---------- title: Unittest runner needs an option to call gc.collect() after each test -> Unittest runner needs an option to call gc.collect() after each test _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 11:07:43 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 10 May 2013 09:07:43 +0000 Subject: [issue17948] HTTPS and sending a big file size hangs. In-Reply-To: <1368171829.05.0.903022030282.issue17948@psf.upfronthosting.co.za> Message-ID: <1368176863.25.0.229836252565.issue17948@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hello Jesus, this report is far too vague to make anything about it. You should try to diagnose the issue further, here are some ideas: - check whether it happens with another server than IIS - try if you can reproduce without Mercurial being involved (simply write a script using httplib or urllib2 to push a file to the server) - try to see what happens over the wire using e.g. Wireshark Bonus points if you can find an easy way to reproduce, short of hosting a large Mercurial repo on a Windows server :-) ---------- components: +Library (Lib) nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 11:14:11 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 10 May 2013 09:14:11 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368028726.5.0.833825784859.issue17936@psf.upfronthosting.co.za> Message-ID: <1368177251.8.0.5096389234.issue17936@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: So, any objections? It is pretty straighforward. Btw, the searching for Py_NONE seems to be a rudiment of some older version, there is no place where a Py_NONE is put in there. Also, what is the policy for 2.7? Are performance bugs proper bugs? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 11:22:14 2013 From: report at bugs.python.org (Xavier de Gaye) Date: Fri, 10 May 2013 09:22:14 +0000 Subject: [issue16133] asyncore.dispatcher.recv doesn't handle EAGAIN / EWOULDBLOCK In-Reply-To: <1349366792.42.0.417654527681.issue16133@psf.upfronthosting.co.za> Message-ID: <1368177734.7.0.814879432573.issue16133@psf.upfronthosting.co.za> Xavier de Gaye added the comment: > Deciding what's best to do at this point without breaking existent > code is not easy, that is why I think that on python <= 3.3 we > should fix *asynchat* in order to take EAGAIN/EWOULDBLOCK into > account and leave asyncore's recv() alone. IMHO for all python versions, asynchat should be fixed and recv() left unchanged raising OSError with EAGAIN/EWOULDBLOCK. With the proposed change on recv(), asyncore users would need to handle this new None returned value anyway, instead of handling the exception which is much more explicit. The attached patch does this on the default branch. ---------- Added file: http://bugs.python.org/file30193/EWOULDBLOCK.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 11:35:00 2013 From: report at bugs.python.org (mirabilos) Date: Fri, 10 May 2013 09:35:00 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za> Message-ID: <1368178500.76.0.115755504903.issue17237@psf.upfronthosting.co.za> mirabilos added the comment: Hi again, sorry for being a bit late in following up to this. Here are the results for the two runs you requested; these were done on the same machine, intermixed (the first one cache-clean, the second and third run subsequently (so that the third run is cache-filled)). I used static builds. For the ?without assert?, I get approximately 570 usec per loop consistently: (590,580), (570,570), (560,580), (570,560) Interestingly enough, there seems to be no preference either way (ASCII or UTF-8). For the ?without the whole if?endif block?, I get mixed results: (650,540), (690,530), (520,530), (650,540) Interesting here is that the third run of them both has a lower ASCII than UTF-8 time, the others don?t ? but the UTF-8 run is the second in a row, so cache might be of an issue. Repeating the runs, I get (560,590), (540,530) for the second case, and (760,570), (590,660) for the first case breaking its ?consistently 570 usec? streak. Error of measurement may be large, thus. Which supports your suspicion that the optimised case may not be needed at all. Matthias asked me to provide links how to set up an Atari VM with Debian unstable and a clean/minimal unstable chroot, since there?s much use of Ubuntu here who ship ARAnyM (I even filed a Sync Request so that the latest release got a fixed version ?). https://wiki.debian.org/Aranym/Quick#download has got pointers for the first part (setting up an ARAnyM VM), and https://wiki.debian.org/M68k/Installing contains the whole documentation (we cannot currently use d-i but people are working on it). http://people.debian.org/~tg/f/20121227/m68k-buildd.tgz is the output of ?debootstrap --variant=buildd? and as such should be usable in either cowbuilder or sbuild. Considering that we *only* have unstable available, you may want to be careful when upgrading ;) but an apt-get update should work out of the box (takes a few minutes). The VMs have 768+14 MiB RAM each in the sample configuration (maxed out), which makes them use a bit less than 1 GiB on the host side. A 3 GHz host CPU is of benefit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 11:35:32 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 10 May 2013 09:35:32 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368028726.5.0.833825784859.issue17936@psf.upfronthosting.co.za> Message-ID: <1368178532.78.0.0383619546149.issue17936@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Py_None is what PyWeakref_GET_OBJECT() returns when the object is dead. (same as calling () on a weakref, really) The patch looks straightforward to me. 2.7 doesn't receive performance fixes, though, except for large regressions. Also, we've had enough regressions in the last 2.7 bugfix release, IMHO. (I had worked on a patch which replaced the list with a dict, but I had refcounting issues with it, and I'm not interested enough in the issue to push any further) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 11:42:21 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 May 2013 09:42:21 +0000 Subject: [issue9687] dbmmodule.c:dbm_contains fails on 64bit big-endian (test_dbm.py fails) when built against gdbm (int vs Py_ssize_t) In-Reply-To: <1282766699.94.0.103473116752.issue9687@psf.upfronthosting.co.za> Message-ID: <1368178941.74.0.0811661191547.issue9687@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 11:44:46 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 May 2013 09:44:46 +0000 Subject: [issue17926] PowerLinux dbm failure in 2.7 In-Reply-To: <1367940625.16.0.48858198554.issue17926@psf.upfronthosting.co.za> Message-ID: <1368179086.34.0.432266493267.issue17926@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue9687. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 11:53:58 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 10 May 2013 09:53:58 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368028726.5.0.833825784859.issue17936@psf.upfronthosting.co.za> Message-ID: <1368179638.65.0.840869470942.issue17936@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Right, I misread the code. Since the remove_subclass() function is called when a subclass dies, I don't think it is necessary to clear out weak references in add_subclass(). They are there merely to break the reference cycle. Btw, the 'patch diff' stuff seems to be broken in the tracker .... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 12:09:13 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 10 May 2013 10:09:13 +0000 Subject: [issue9687] dbmmodule.c:dbm_contains fails on 64bit big-endian (test_dbm.py fails) when built against gdbm (int vs Py_ssize_t) In-Reply-To: <1282766699.94.0.103473116752.issue9687@psf.upfronthosting.co.za> Message-ID: <1368180553.46.0.0890317085543.issue9687@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Should be fixed in issue17926. AFAICT the issue doesn't exist on 3.x. ---------- resolution: -> duplicate stage: patch review -> committed/rejected status: open -> closed superseder: -> PowerLinux dbm failure in 2.7 versions: -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 12:10:31 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 10 May 2013 10:10:31 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368179638.65.0.840869470942.issue17936@psf.upfronthosting.co.za> Message-ID: <785723795.29210752.1368180625990.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > Right, I misread the code. > Since the remove_subclass() function is called when a subclass dies, > I don't think it is necessary to clear out weak references in > add_subclass(). They are there merely to break the reference cycle. Agreed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 14:05:50 2013 From: report at bugs.python.org (Anselm Kruis) Date: Fri, 10 May 2013 12:05:50 +0000 Subject: [issue5773] Crash on shutdown after os.fdopen(2) in debug builds In-Reply-To: <1239885549.06.0.444041706295.issue5773@psf.upfronthosting.co.za> Message-ID: <1368187550.13.0.696422235587.issue5773@psf.upfronthosting.co.za> Anselm Kruis added the comment: Hi, I was faced with a very similar problem also caused by an invalid file descriptor. My solution is to set an invalid parameter handler, that does nothing. This effectively disables Dr. Watson. Perhaps this is a suitable solution for other users too. And it does not require a patch. def set_invalid_parameter_handler(flag): """ Set the MSVCRT invalid parameter handler. If flag is True, this function sets an invalid parameter handler, that does nothing. This effectively disables Dr. Watson. If flag is an integer number, it must be the address of an invalid parameter handler function. If flag is None, this function removes the invalid parameter handler. This effectively enables Dr. Watson. The return value is the address of the current handler or None, if no handler is installed. Example:: old = set_invalid_parameter_handler(True) try: do_something_nasty finally: set_invalid_parameter_handler(old) """ try: # get the msvcrt library import ctypes.util libc = ctypes.util.find_msvcrt() if not libc: # probably not windows return None libc = getattr(ctypes.cdll, libc) siph = libc._set_invalid_parameter_handler siph.restype = ctypes.c_void_p siph.argtypes = [ ctypes.c_void_p ] # now we need a suitable handler. # The handler must simply return without performing any actions. # Of course there is none. # But if we look at the calling convention (cdecl), and # at the fact, that we don't need the argument values # we find, that we can call any function, as long as the function # does not harm. A suitable function is "int abs(abs)". null_handler = libc.abs except Exception: # probably not the correct windows version return None if flag is True: flag = null_handler return siph(flag) ---------- nosy: +anselm.kruis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 14:18:37 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 10 May 2013 12:18:37 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za> Message-ID: <1368188317.05.0.207459272677.issue17237@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Which supports your suspicion that the optimised case may not be needed > at all. So we can just skip the assert when __m68k__ is defined? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 14:26:20 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 May 2013 12:26:20 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za> Message-ID: <1368188780.81.0.927241893572.issue17237@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please repeat the tests with a larger data (1MB or more)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 15:04:40 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 May 2013 13:04:40 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1368191080.68.0.782921961612.issue14596@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: So what about more compact Struct object? This is not only memory issue (a Struct object can require several times larger memory than size of processed data), but performance issue (time of creating such object is proportional to it's size). Here is a patch with updated __sizeof__ method and tests. ---------- Added file: http://bugs.python.org/file30194/struct_repeat_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 15:19:21 2013 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 10 May 2013 13:19:21 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368191961.45.0.922188978038.issue17947@psf.upfronthosting.co.za> Changes by Eli Bendersky : Removed file: http://bugs.python.org/file30191/ref435.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 15:21:01 2013 From: report at bugs.python.org (Christian Heimes) Date: Fri, 10 May 2013 13:21:01 +0000 Subject: [issue11016] stat module in C In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za> Message-ID: <1368192061.25.0.432401118051.issue11016@psf.upfronthosting.co.za> Christian Heimes added the comment: AP has started to review my patch. I'm not yet sure how we should handle constants and functions when the platform doesn't provide them. For example Windows doesn't have any S_IS*() function like macros and doesn't provide a S_IFBLK constant. We have three possibilities here: 1) omit the constant / function (breaks b/w compatibility) 2) add constant with a value of 0 / function that returns false (may break b/w compatibility) 3) default to current value from Lib/stat.py I'm against 1) because it breaks backwards compatibility and makes the module harder to use. I like to follow 3) for all S_I*, SF_* and UF_* macros and functions that are currently provided by the stat module and 2) for new constants and functions such as S_ISDOOR(). ---------- title: Add S_ISDOOR to the stat module -> stat module in C _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 15:21:38 2013 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 10 May 2013 13:21:38 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368192098.91.0.138348876038.issue17947@psf.upfronthosting.co.za> Eli Bendersky added the comment: I don't see docs in the patch, but perhaps that should be a separate patch to keep reviewing easier. Also, Ethan, number the patch files in some way (like pep-435.1.patch, pep-435.N.patch) as they go through rounds of reviews. ---------- assignee: docs at python -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 16:01:01 2013 From: report at bugs.python.org (A.M. Kuchling) Date: Fri, 10 May 2013 14:01:01 +0000 Subject: [issue5901] missing meta-info in documentation pdf In-Reply-To: <1241246578.79.0.771794251259.issue5901@psf.upfronthosting.co.za> Message-ID: <1368194461.48.0.850274393487.issue5901@psf.upfronthosting.co.za> A.M. Kuchling added the comment: This seems to be fixed now. I downloaded python-3.3.1-docs-pdf-letter.tar.bz2 and ran pdfinfo on using.pdf: Title: Python Setup and Usage Subject: Keywords: Author: Guido van Rossum, Fred L. Drake, Jr., editor Creator: LaTeX with hyperref package Producer: pdfTeX-1.40.10 CreationDate: Fri May 10 09:42:17 2013 ModDate: Fri May 10 09:42:17 2013 Tagged: no Pages: 65 Encrypted: no Page size: 612 x 792 pts (letter) File size: 432316 bytes Optimized: no PDF version: 1.4 We could fill in Subject and Keywords, but the basic fields of Title and Author seem to be present. (Do we need to change author to 'Python Development Group' or 'PSF'?) ---------- nosy: +akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 16:01:12 2013 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 10 May 2013 14:01:12 +0000 Subject: [issue17941] namedtuple should support fully qualified name for more portable pickling In-Reply-To: <1368071216.78.0.0822877752405.issue17941@psf.upfronthosting.co.za> Message-ID: <1368194472.74.0.122152650724.issue17941@psf.upfronthosting.co.za> Eli Bendersky added the comment: A question that came up while reviewing the new enum code: "module" or "module_name" for this extra argument? The former is shorter, but the latter is more correct in a way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 16:02:56 2013 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 10 May 2013 14:02:56 +0000 Subject: [issue17941] namedtuple should support fully qualified name for more portable pickling In-Reply-To: <1368194472.74.0.122152650724.issue17941@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Module, please. The class attribute is also called __module__ after all. On Friday, May 10, 2013, Eli Bendersky wrote: > > Eli Bendersky added the comment: > > A question that came up while reviewing the new enum code: "module" or > "module_name" for this extra argument? The former is shorter, but the > latter is more correct in a way. > > ---------- > > _______________________________________ > Python tracker > > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 16:03:17 2013 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 10 May 2013 14:03:17 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368194597.22.0.625248946443.issue17947@psf.upfronthosting.co.za> Eli Bendersky added the comment: OK, I sent another batch of reviews through the code review system - Ethan you should've gotten an email about it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 16:04:31 2013 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 10 May 2013 14:04:31 +0000 Subject: [issue17941] namedtuple should support fully qualified name for more portable pickling In-Reply-To: Message-ID: Eli Bendersky added the comment: On Fri, May 10, 2013 at 7:02 AM, Guido van Rossum wrote: > > Guido van Rossum added the comment: > > Module, please. The class attribute is also called __module__ after all. > Makes sense. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 16:05:21 2013 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 10 May 2013 14:05:21 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368194721.2.0.250087702798.issue17947@psf.upfronthosting.co.za> Eli Bendersky added the comment: Regarding module vs. module_name for the extra param in the functional API, Guido rightly points out in issue 17941 that __module__ is the class attribute, so "module" is a consistent choice. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 16:28:44 2013 From: report at bugs.python.org (Meador Inge) Date: Fri, 10 May 2013 14:28:44 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1368191080.68.0.782921961612.issue14596@psf.upfronthosting.co.za> Message-ID: Meador Inge added the comment: > > Serhiy Storchaka added the comment: > > So what about more compact Struct object? I already implemented the count optimization as a part of my patch for implementing PEP 3188 in issue3132. I need to rebaseline the patch. It has gotten stale. Hopefully there is still interest in the PEP 3188 work and I can get that patch pushed through. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 16:42:08 2013 From: report at bugs.python.org (Alex Gaynor) Date: Fri, 10 May 2013 14:42:08 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368196928.04.0.652107495237.issue17947@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 17:21:23 2013 From: report at bugs.python.org (Ethan Furman) Date: Fri, 10 May 2013 15:21:23 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368199283.22.0.141003833512.issue17947@psf.upfronthosting.co.za> Ethan Furman added the comment: Incorporated comments. ---------- Added file: http://bugs.python.org/file30195/pep-0435_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 17:24:58 2013 From: report at bugs.python.org (Ethan Furman) Date: Fri, 10 May 2013 15:24:58 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368199498.1.0.518469104802.issue17947@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- hgrepos: -189 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 17:33:11 2013 From: report at bugs.python.org (Zachary Ware) Date: Fri, 10 May 2013 15:33:11 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368199991.15.0.94975357035.issue17947@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 17:37:26 2013 From: report at bugs.python.org (Jonathan Wakely) Date: Fri, 10 May 2013 15:37:26 +0000 Subject: [issue1045893] warning '"_POSIX_C_SOURCE" redefined' when include Python.h Message-ID: <1368200246.24.0.651875616034.issue1045893@psf.upfronthosting.co.za> Jonathan Wakely added the comment: Insisting on including Python.h first is just broken. GNU libc's /usr/include/features.h will override it anyway when _GNU_SOURCE is defined: # undef _POSIX_C_SOURCE # define _POSIX_C_SOURCE 200809L # undef _XOPEN_SOURCE # define _XOPEN_SOURCE 700 So if you define _GNU_SOURCE ( which happens automatically when using G++) the annoying defines in pyconfig.h are overridden anyway, so why not just only define them if not already defined? Either you include Python.h first and its settings get ignored by glibc, or you don't include it first and you get annoying warnings. ---------- nosy: +Jonathan.Wakely _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 17:48:03 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 May 2013 15:48:03 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <3b6bRQ6G05zST4@mail.python.org> Roundup Robot added the comment: New changeset d331e14cae42 by Guido van Rossum in branch 'default': #17927: Keep frame from referencing cell-ified arguments. http://hg.python.org/cpython/rev/d331e14cae42 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 17:50:15 2013 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 10 May 2013 15:50:15 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1368201015.28.0.999718610194.issue17927@psf.upfronthosting.co.za> Guido van Rossum added the comment: Ok, the deed is done. Thanks for your review, Benjamin! I've reassigned it to you so you can fix up the test if you want to. What would you think of a backport to 3.3? ---------- assignee: gvanrossum -> benjamin.peterson resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 18:00:43 2013 From: report at bugs.python.org (Zachary Ware) Date: Fri, 10 May 2013 16:00:43 +0000 Subject: [issue17883] Fix buildbot testing of Tkinter In-Reply-To: <1367355915.98.0.26398929673.issue17883@psf.upfronthosting.co.za> Message-ID: <1368201643.64.0.626678372455.issue17883@psf.upfronthosting.co.za> Zachary Ware added the comment: Thanks for your response, Martin. Martin v. L?wis wrote: > Zach: Temporarily committing changes to test specific buildbot issues > is fine I suppose it would also be beneficial to get some output from the other bots which are *not* failing, to have something to compare with. In that case, here's a (very) temporary patch we can try for a round of builds. > asking the slave operator for direct access to the machine > may also work. Trent, what's your policy on letting non-committers play around in your machines? :) Alternately, do you know of anything about that machine that could be causing the failures? ---------- nosy: +trent Added file: http://bugs.python.org/file30196/issue17883-tmp-test.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 18:06:16 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 May 2013 16:06:16 +0000 Subject: [issue17944] Refactor test_zipfile In-Reply-To: <1368093470.65.0.477520947191.issue17944@psf.upfronthosting.co.za> Message-ID: <1368201976.6.0.9449788973.issue17944@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file30197/test_zipfile_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 18:26:22 2013 From: report at bugs.python.org (Martijn Pieters) Date: Fri, 10 May 2013 16:26:22 +0000 Subject: [issue17949] operator documentation mixup Message-ID: <1368203182.3.0.318883699217.issue17949@psf.upfronthosting.co.za> New submission from Martijn Pieters: Rev 83684 (http://hg.python.org/cpython/rev/5885c02120f0) managed to move the `attrgetter()` `versionadded` and `versionchanged` notes down to the `itemgetter()` documentation instead, by moving the `itemgetter()` signature *up* above these lines. Now the docs claim `itemgetter()` gained support for dotted attributes in version 2.6, which makes no sense, and there is another set of added and changed notes lower down in the same section. This patch puts the `itemgetter()` signature back in the correct location. ---------- assignee: docs at python components: Documentation files: operator_documentation_fix.patch keywords: patch messages: 188846 nosy: docs at python, mjpieters priority: normal severity: normal status: open title: operator documentation mixup versions: Python 2.7 Added file: http://bugs.python.org/file30198/operator_documentation_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 18:28:57 2013 From: report at bugs.python.org (mirabilos) Date: Fri, 10 May 2013 16:28:57 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za> Message-ID: <1368203337.08.0.569020853788.issue17237@psf.upfronthosting.co.za> mirabilos added the comment: Antoine: precisely. Serhiy: sure. The times are now in msec per loop. I did three subsequent runs, so the second and third tuple are cache-warm. Without assert: (89,88), (87,87), (89,86) Without block : (79,78), (78,78), (79,78) And in a second run: Without assert: (87,88), (87,88), (92,87) Without block : (111,91), (78,85), (79,79) This means that, again, removing the ?optimised? code speeds up operations (on this particular slow architecture. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 18:31:59 2013 From: report at bugs.python.org (Martijn Pieters) Date: Fri, 10 May 2013 16:31:59 +0000 Subject: [issue16523] attrgetter and itemgetter signatures in docs need cleanup In-Reply-To: <1353510966.46.0.566270540705.issue16523@psf.upfronthosting.co.za> Message-ID: <1368203519.9.0.15883661165.issue16523@psf.upfronthosting.co.za> Martijn Pieters added the comment: The 2.7 patch shifted the `itemgetter()` signature to above the `attrgetter()` change and new notes. New patch to fix that in issue #17949: http://bugs.python.org/issue17949 ---------- nosy: +mjpieters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 18:57:16 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 May 2013 16:57:16 +0000 Subject: [issue17949] operator documentation mixup In-Reply-To: <1368203182.3.0.318883699217.issue17949@psf.upfronthosting.co.za> Message-ID: <3b6czH3b6vzQTH@mail.python.org> Roundup Robot added the comment: New changeset 9c93a631e95a by Ezio Melotti in branch '2.7': #17949: fix merge glitch in itemgetter signature. Patch by Martijn Pieters. http://hg.python.org/cpython/rev/9c93a631e95a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 18:57:50 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 10 May 2013 16:57:50 +0000 Subject: [issue17949] operator documentation mixup In-Reply-To: <1368203182.3.0.318883699217.issue17949@psf.upfronthosting.co.za> Message-ID: <1368205070.41.0.110354567946.issue17949@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the report and the patch! ---------- assignee: docs at python -> ezio.melotti nosy: +ezio.melotti resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 19:08:21 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 10 May 2013 17:08:21 +0000 Subject: [issue995907] memory leak with threads and enhancement of the timer class In-Reply-To: <1368008973.87.0.516213837591.issue995907@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: I'm attaching a proof of concept code for a ScheduledExecutor interface, and a ScheduledThreadPoolExecutor implementation (unfortunately I can't upload it as a mercurial diff for now). Here's what the API looks like: """ from concurrent.futures import ScheduledThreadPoolExecutor import time def say(text): print("{}: {}".format(time.ctime(), text)) with ScheduledThreadPoolExecutor(5) as p: p.schedule(1, say, 'hello 1') f = p.schedule_fixed_rate(0, 2, say, 'hello 2') p.schedule_fixed_delay(0, 3, say, 'hello 3') time.sleep(6) say("cancelling: %s" % f) f.cancel() time.sleep(10) say("shutting down") """ schedule() is for one-shot, schedule_fixed_rate() for fixed rate scheduling (i.e. there will be no drift due to the task execution time), and schedule_fixed_delay() is for fixed delay (i.e. there will always be a fixed amount of time between two invokations). Random notes: - the scheduling is handled by a new SchedQueue in the queue module: sched would have been useful, but actually it can't be used here: it stops as soon as the queue is empty, when it calls the wait function it won't wake up if a new task is enqueued, etc. Also, I guess such a queue could be useful in general. - I had to create a DelayedFuture subclass, which is returned by schedule_XXX methods. The main differences with raw Future are that it has a scheduled time and period attributes, and supports reinitialization (a future can only be run once). It can be cancelled, and also supports result/exception retrieval. - I don't know if a process-based counterpart (ScheduledProcessPoolExecutor) is really useful. I didn't look at it for now. ---------- Added file: http://bugs.python.org/file30199/scheduled.diff Added file: http://bugs.python.org/file30200/test.py _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -ur cpython.orig/Lib/concurrent/futures/_base.py cpython-b3e1be1493a5/Lib/concurrent/futures/_base.py --- cpython.orig/Lib/concurrent/futures/_base.py 2013-05-07 08:21:21.000000000 +0000 +++ cpython-b3e1be1493a5/Lib/concurrent/futures/_base.py 2013-05-10 16:35:16.000000000 +0000 @@ -6,7 +6,10 @@ import collections import logging import threading -import time +try: + from time import monotonic as time +except ImportError: + from time import time FIRST_COMPLETED = 'FIRST_COMPLETED' FIRST_EXCEPTION = 'FIRST_EXCEPTION' @@ -188,7 +191,7 @@ before the given timeout. """ if timeout is not None: - end_time = timeout + time.time() + end_time = timeout + time() with _AcquireFutures(fs): finished = set( @@ -204,7 +207,7 @@ if timeout is None: wait_timeout = None else: - wait_timeout = end_time - time.time() + wait_timeout = end_time - time() if wait_timeout < 0: raise TimeoutError( '%d (of %d) futures unfinished' % ( @@ -390,11 +393,11 @@ elif self._state == FINISHED: return self.__get_result() - self._condition.wait(timeout) + gotit = self._condition.wait(timeout) if self._state in [CANCELLED, CANCELLED_AND_NOTIFIED]: raise CancelledError() - elif self._state == FINISHED: + elif gotit: return self.__get_result() else: raise TimeoutError() @@ -423,11 +426,11 @@ elif self._state == FINISHED: return self._exception - self._condition.wait(timeout) + gotit = self._condition.wait(timeout) if self._state in [CANCELLED, CANCELLED_AND_NOTIFIED]: raise CancelledError() - elif self._state == FINISHED: + elif gotit: return self._exception else: raise TimeoutError() @@ -499,6 +502,39 @@ self._condition.notify_all() self._invoke_callbacks() + +class DelayedFuture(Future): + """A future whose execution can be delayed, and periodic.""" + + def __init__(self, sched_time, period=0, delay=0): + super().__init__() + self._sched_time = sched_time + if period > 0: + # step > 0 => fixed rate + self._step = period + elif delay > 0: + # step < 0 => fixed delay + self._step = -delay + else: + # step == 0 => one-shot + self._step = 0 + + def is_periodic(self): + return self._step != 0 + + def get_sched_time(self): + return self._sched_time + + def rearm(self): + """Re-arm the future, and update its scheduled execution time.""" + with self._condition: + if self._step > 0: + self._sched_time += self._step + else: + self._sched_time = time() - self._step + self._state = PENDING + + class Executor(object): """This is an abstract base class for concrete asynchronous executors.""" @@ -532,7 +568,7 @@ Exception: If fn(*args) raises for any values. """ if timeout is not None: - end_time = timeout + time.time() + end_time = timeout + time() fs = [self.submit(fn, *args) for args in zip(*iterables)] @@ -544,7 +580,7 @@ if timeout is None: yield future.result() else: - yield future.result(end_time - time.time()) + yield future.result(end_time - time()) finally: for future in fs: future.cancel() @@ -569,3 +605,15 @@ def __exit__(self, exc_type, exc_val, exc_tb): self.shutdown(wait=True) return False + + +class ScheduledExecutor(Executor): + + def schedule(self, delay, fn, *args, **kwargs): + raise NotImplementedError() + + def schedule_fixed_rate(self, init_delay, period, fn, *args, **kwargs): + raise NotImplementedError() + + def schedule_fixed_delay(self, init_delay, delay, fn, *args, **kwargs): + raise NotImplementedError() diff -ur cpython.orig/Lib/concurrent/futures/__init__.py cpython-b3e1be1493a5/Lib/concurrent/futures/__init__.py --- cpython.orig/Lib/concurrent/futures/__init__.py 2013-05-07 08:21:21.000000000 +0000 +++ cpython-b3e1be1493a5/Lib/concurrent/futures/__init__.py 2013-05-10 15:29:04.000000000 +0000 @@ -15,4 +15,4 @@ wait, as_completed) from concurrent.futures.process import ProcessPoolExecutor -from concurrent.futures.thread import ThreadPoolExecutor +from concurrent.futures.thread import ScheduledThreadPoolExecutor, ThreadPoolExecutor diff -ur cpython.orig/Lib/concurrent/futures/thread.py cpython-b3e1be1493a5/Lib/concurrent/futures/thread.py --- cpython.orig/Lib/concurrent/futures/thread.py 2013-05-07 08:21:21.000000000 +0000 +++ cpython-b3e1be1493a5/Lib/concurrent/futures/thread.py 2013-05-10 16:37:16.000000000 +0000 @@ -9,6 +9,10 @@ from concurrent.futures import _base import queue import threading +try: + from time import monotonic as time +except ImportError: + from time import time import weakref # Workers are created as daemon threads. This is done to allow the interpreter @@ -57,6 +61,39 @@ else: self.future.set_result(result) +class _DelayedWorkItem(_WorkItem): + + def __init__(self, queue, future, fn, args, kwargs): + super().__init__(future, fn, args, kwargs) + self.queue = queue + + def run(self): + if not self.future.set_running_or_notify_cancel(): + return + + try: + result = self.fn(*self.args, **self.kwargs) + except BaseException as e: + self.future.set_exception(e) + else: + self.future.set_result(result) + if self.future.is_periodic(): + # rearm the future - it also updates it scheduled time + self.future.rearm() + # and re-schedule ourselves - XXX don't reschedule if the pool + # is shut down + self.queue.put(self) + + +class _DelayedWorkItemQueue(queue.SchedQueue): + + def put(self, w, block=True, timeout=None): + if w is not None: + super().put_abs(w.future.get_sched_time(), w, block, timeout) + else: + super().put_abs(0, None, block, timeout) + + def _worker(executor_reference, work_queue): try: while True: @@ -130,3 +167,31 @@ for t in self._threads: t.join() shutdown.__doc__ = _base.Executor.shutdown.__doc__ + +class ScheduledThreadPoolExecutor(ThreadPoolExecutor): + def __init__(self, max_workers): + super().__init__(max_workers) + self._work_queue = _DelayedWorkItemQueue() + + def schedule(self, init_delay, fn, *args, **kwargs): + f = _base.DelayedFuture(time() + init_delay) + return self._schedule(f, fn, *args, **kwargs) + + def schedule_fixed_rate(self, init_delay, period, fn, *args, **kwargs): + f = _base.DelayedFuture(time() + init_delay, period=period) + return self._schedule(f, fn, *args, **kwargs) + + def schedule_fixed_delay(self, init_delay, delay, fn, *args, **kwargs): + f = _base.DelayedFuture(time() + init_delay, delay=delay) + return self._schedule(f, fn, *args, **kwargs) + + def _schedule(self, f, fn, *args, **kwargs): + with self._shutdown_lock: + if self._shutdown: + raise RuntimeError('cannot schedule new futures after shutdown') + + w = _DelayedWorkItem(self._work_queue, f, fn, args, kwargs) + + self._work_queue.put(w) + self._adjust_thread_count() + return f --- cpython.orig/Lib/queue.py 2013-05-07 08:21:21.000000000 +0000 +++ cpython-b3e1be1493a5/Lib/queue.py 2013-05-10 16:32:50.000000000 +0000 @@ -247,3 +247,71 @@ def _get(self): return self.queue.pop() + + +class SchedQueue(PriorityQueue): + '''Variant of Queue that retrieves open entries as their deadline expire. + ''' + + def put(self, delay, item, block=True, timeout=None): + self.put_abs(time() + delay, item, block, timeout) + + def put_abs(self, deadline, item, block=True, timeout=None): + super().put((deadline, item), block, timeout) + + def _put(self, data): + deadline, item = data + + do_notify = False + if self.queue: + earliest_deadline, _ = self.queue[0] + if deadline < earliest_deadline: + do_notify = True + else: + do_notify = True + + heappush(self.queue, (deadline, item)) + + if do_notify: + self.not_empty.notify_all() + + def get(self, block=True, timeout=None): + with self.not_empty: + if not self.queue and not block: + raise Empty + if timeout is not None: + if timeout < 0: + raise ValueError("'timeout' must be a positive number") + else: + timeout_deadline = time() + timeout + + while True: + if not self.queue: + if timeout is None: + self.not_empty.wait() + else: + delay = timeout_deadline - time() + if delay > 0: + self.not_empty.wait(delay) + else: + raise Empty + else: + deadline, item = self.queue[0] + now = time() + + if now >= deadline: + heappop(self.queue) + if self.queue: + self.not_empty.notify_all() + return item + elif not block: + raise Empty + elif timeout is None: + self.not_empty.wait(deadline - now) + else: + deadline = min(deadline, timeout_deadline) + delay = deadline - now + if delay > 0: + self.not_empty.wait(delay) + else: + raise Empty -------------- next part -------------- from concurrent.futures import ScheduledThreadPoolExecutor import time def say(text): print("{}: {}".format(time.ctime(), text)) with ScheduledThreadPoolExecutor(5) as p: p.schedule(1, say, 'hello 1') f = p.schedule_fixed_rate(0, 2, say, 'hello 2') p.schedule_fixed_delay(0, 3, say, 'hello 3') time.sleep(6) say("cancelling: %s" % f) f.cancel() time.sleep(10) say("shutting down") From report at bugs.python.org Fri May 10 19:33:48 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 10 May 2013 17:33:48 +0000 Subject: [issue17904] bytes should be listed as built-in function for 2.7 In-Reply-To: <1367663679.93.0.0164308850832.issue17904@psf.upfronthosting.co.za> Message-ID: <1368207228.14.0.176335305113.issue17904@psf.upfronthosting.co.za> Ezio Melotti added the comment: Here's a patch. Do you think it should be added under the string signature too? It will make linking easier, but it might be more confusing for users. ---------- keywords: +patch nosy: +chris.jerdonek, ezio.melotti stage: needs patch -> patch review type: behavior -> enhancement Added file: http://bugs.python.org/file30201/issue17904.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 19:35:28 2013 From: report at bugs.python.org (Martin Morrison) Date: Fri, 10 May 2013 17:35:28 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1368207328.5.0.982908798324.issue17927@psf.upfronthosting.co.za> Martin Morrison added the comment: Our usage of Python would certainly benefit from the backport. We are embedding Python 3.3 in a system with requirements that lead us to disable the gc in most cases, so cycles are an obvious problem for us. Cycles created inadvertently, such as this, are the biggest problem. We would probably backport the fix anyway, but would prefer not to carry patches and instead pick up fixes via 3.3.x releases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 19:39:50 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 10 May 2013 17:39:50 +0000 Subject: [issue17468] Generator memory leak In-Reply-To: <1363638865.27.0.0312549957802.issue17468@psf.upfronthosting.co.za> Message-ID: <1368207590.89.0.742405301639.issue17468@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The issue17807 patch has now been committed and should solve this issue. I would like to encourage anyone to test this change, as it is quite a significant departure from the previous semantics: http://mail.python.org/pipermail/python-dev/2013-May/126102.html ---------- assignee: docs at python -> components: +Interpreter Core -Documentation resolution: -> duplicate status: open -> closed superseder: -> Generator cleanup without tp_del _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 19:47:16 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 10 May 2013 17:47:16 +0000 Subject: [issue17907] Deprecate imp.new_module() in favour of types.ModuleType In-Reply-To: <1367691908.58.0.339991159831.issue17907@psf.upfronthosting.co.za> Message-ID: <1368208036.45.0.784920088898.issue17907@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 19:50:36 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 10 May 2013 17:50:36 +0000 Subject: [issue17920] Documentation: "complete ordering" should be "total ordering" In-Reply-To: <1367871771.49.0.425606433106.issue17920@psf.upfronthosting.co.za> Message-ID: <1368208236.66.0.887481938312.issue17920@psf.upfronthosting.co.za> Ezio Melotti added the comment: Raymond, since this has been merged to default too in e163c13b941c, can the issue be closed or is there something else left to do? ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 19:53:17 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 10 May 2013 17:53:17 +0000 Subject: [issue17923] test glob with trailing slash fail In-Reply-To: <1367915410.77.0.862505044661.issue17923@psf.upfronthosting.co.za> Message-ID: <1368208397.53.0.784808560534.issue17923@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Library (Lib) nosy: +ezio.melotti stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 19:54:59 2013 From: report at bugs.python.org (Ethan Furman) Date: Fri, 10 May 2013 17:54:59 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368208499.92.0.321999639783.issue17947@psf.upfronthosting.co.za> Ethan Furman added the comment: More adjustments due to review. ---------- Added file: http://bugs.python.org/file30202/pep-0435_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 19:59:47 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 10 May 2013 17:59:47 +0000 Subject: [issue17940] extra code in argparse.py In-Reply-To: <1368052350.83.0.843381398629.issue17940@psf.upfronthosting.co.za> Message-ID: <1368208787.99.0.45728457839.issue17940@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +bethard stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 20:08:10 2013 From: report at bugs.python.org (Bob Ippolito) Date: Fri, 10 May 2013 18:08:10 +0000 Subject: [issue17906] JSON should accept lone surrogates In-Reply-To: <1367678308.48.0.934181281887.issue17906@psf.upfronthosting.co.za> Message-ID: <1368209290.44.0.393067752829.issue17906@psf.upfronthosting.co.za> Bob Ippolito added the comment: The patch that I wrote for simplejson is here (it differs a bit from serhiy's patch): https://github.com/simplejson/simplejson/commit/35816bfe2d0ddeb5ddcc68239683cbb35b7e3ff2 I discovered another bug along the way in the pure-Python scanstring, int(s, 16) will parse '0xNN' when json expects only strings of the form 'NNNN' to work. I fixed that along with this issue by explicitly checking for x or X. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 20:11:21 2013 From: report at bugs.python.org (James O'Cull) Date: Fri, 10 May 2013 18:11:21 +0000 Subject: [issue17948] HTTPS and sending a big file size hangs. In-Reply-To: <1368171829.05.0.903022030282.issue17948@psf.upfronthosting.co.za> Message-ID: <1368209481.44.0.661638652308.issue17948@psf.upfronthosting.co.za> James O'Cull added the comment: We have more information on this bug here. It's SSL v2 related when pushing to IIS. http://stackoverflow.com/a/16486104/97964 Here's a paste from the StackOverflow answer: I found a few ways of dealing with this issue: To fix this server-side in IIS, download and install https://www.nartac.com/Products/IISCrypto/Default.aspx and click the BEAST button, or force SSL3.0 by disabling other protocols. If you don't have access to the IIS server, you can fix it by rolling back Python to version 2.7.2 or earlier. If you are adventurous, you can modify the mercurial source in sslutil.py, near the top, change the line sslsocket = ssl.wrap_socket(sock, keyfile, certfile, cert_reqs=cert_reqs, ca_certs=ca_certs) to from _ssl import PROTOCOL_SSLv3 sslsocket = ssl.wrap_socket(sock, keyfile, certfile, cert_reqs=cert_reqs, ca_certs=ca_certs, ssl_version=PROTOCOL_SSLv3) This will work around the problem and fix the push limit to mercurial behind IIS. If you are interested in why Python 2.7.3 broke this, look at http://bugs.python.org/issue13885 for the explanation (it is security-related). If you want to modify Python itself, in Modules/_ssl.c change the line SSL_CTX_set_options(self->ctx, SSL_OP_ALL & ~SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS); back to how it was prior to 2.7.3: SSL_CTX_set_options(self->ctx, SSL_OP_ALL); Compile and reinstall python, etc. This adds more SSL compatibility at the expense of potential security risks, if I understand the OpenSSL docs correctly. ---------- nosy: +James.O'Cull _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 20:15:12 2013 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 10 May 2013 18:15:12 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1368209712.57.0.311043845344.issue17927@psf.upfronthosting.co.za> Guido van Rossum added the comment: Martin Morrison, can you check if my fix (cellfree4.diff) applies cleanly to 3.3? Or if nearly so, could you upload a fixed version here? (Or create a new issue and assign it to me if you can't upload to this issue.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 20:19:03 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Fri, 10 May 2013 18:19:03 +0000 Subject: [issue17940] extra code in argparse.py In-Reply-To: <1368052350.83.0.843381398629.issue17940@psf.upfronthosting.co.za> Message-ID: <1368209943.15.0.293174743337.issue17940@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 20:19:44 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 10 May 2013 18:19:44 +0000 Subject: [issue17948] HTTPS and sending a big file size hangs. In-Reply-To: <1368171829.05.0.903022030282.issue17948@psf.upfronthosting.co.za> Message-ID: <1368209984.56.0.108494236963.issue17948@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thank you for pointing this out. I am frankly shocked that IIS would defaut to SSLv2 (an obsolete and insecure version of the protocol), while Python's (and certainly Mercurial's) default settings allow for higher protocol versions. > If you are interested in why Python 2.7.3 broke this, look at > http://bugs.python.org/issue13885 for the explanation (it is > security-related). Indeed, it is a security fix. I have no desire to undo this change, which means things may get a bit painful with IIS apparently. One way to deal with it may be to detect IIS after the first wrap_socket() (through an HTTP header in the response?) and then re-issue a wrap_socket() with IIS-specific parameters. (forcing SSLv3 as the client protocol isn't terrific, since TLSv1 is AFAIR supposed to have improved security) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 20:20:22 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 10 May 2013 18:20:22 +0000 Subject: [issue17948] HTTPS and sending a big file size hangs. In-Reply-To: <1368171829.05.0.903022030282.issue17948@psf.upfronthosting.co.za> Message-ID: <1368210022.22.0.933683057987.issue17948@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Closing as won't fix. I hope you'll find a reasonable to deal with this, sorry :-/ ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 20:28:19 2013 From: report at bugs.python.org (James O'Cull) Date: Fri, 10 May 2013 18:28:19 +0000 Subject: [issue17948] HTTPS and sending a big file size hangs. In-Reply-To: <1368171829.05.0.903022030282.issue17948@psf.upfronthosting.co.za> Message-ID: <1368210499.82.0.874877781497.issue17948@psf.upfronthosting.co.za> James O'Cull added the comment: I appreciate the response all the same. Thanks for taking the time to look at it, Antoine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 20:34:44 2013 From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIFZpZGFsIFBhbmFsw6lz?=) Date: Fri, 10 May 2013 18:34:44 +0000 Subject: [issue17948] HTTPS and sending a big file size hangs. In-Reply-To: <1368171829.05.0.903022030282.issue17948@psf.upfronthosting.co.za> Message-ID: <1368210884.86.0.455363703752.issue17948@psf.upfronthosting.co.za> Jes?s Vidal Panal?s added the comment: Thank you. I will modify IIS security to disable SSL older verions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 20:41:12 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 May 2013 18:41:12 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za> Message-ID: <1368211272.88.0.783572538893.issue17237@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Well, it will be safer to skip this block on such platforms. ---------- keywords: +patch Added file: http://bugs.python.org/file30203/ascii_decode_nonaligned.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 21:01:23 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 May 2013 19:01:23 +0000 Subject: [issue17895] TemporaryFile name returns an integer in python3 In-Reply-To: <1367600057.19.0.0234960166216.issue17895@psf.upfronthosting.co.za> Message-ID: <1368212483.36.0.310690923199.issue17895@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Given that the changed behavior is documented and pretty obviously intentional, it is not a bug. The proposal would have to be that we 'enhance' 3.4 *or later* by reverting back to the 2.x -- and possibly break 3.0 to 3.3 code. We are not going to do that without extremely good reason. For a nameless file, using the integer fd as a 'name' seems more truthful than ''. I believe the latter can be a actual filename on *nix. On Windows, while Explorer rejects it, there may be ways to bypass the check. The integer fd is also more useful than None and 'isintance(x.name, int)' is as easy to check as 'x.name is None'. ---------- nosy: +terry.reedy status: open -> closed type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 21:07:43 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 May 2013 19:07:43 +0000 Subject: [issue1475523] gettext breaks on plural-forms header Message-ID: <1368212863.25.0.439746795432.issue1475523@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 21:07:51 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 May 2013 19:07:51 +0000 Subject: [issue12425] gettext breaks on empty plural-forms value In-Reply-To: <1309246707.61.0.397995745183.issue12425@psf.upfronthosting.co.za> Message-ID: <1368212871.2.0.118651282808.issue12425@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 21:13:01 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 May 2013 19:13:01 +0000 Subject: [issue17898] gettext bug while parsing plural-forms metadata In-Reply-To: <1367605186.32.0.57972582146.issue17898@psf.upfronthosting.co.za> Message-ID: <1368213180.99.0.636069166129.issue17898@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Since the other two listed inner-loop issues apply to 3.x, I would guess that this does also. Steve, can you test with 3.3? And provide a *minimal* test case? ---------- nosy: +terry.reedy stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 21:15:40 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 May 2013 19:15:40 +0000 Subject: [issue17905] Add check for locale.h In-Reply-To: <1367676553.24.0.0475219885835.issue17905@psf.upfronthosting.co.za> Message-ID: <1368213340.23.0.0938827114886.issue17905@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 21:25:21 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 May 2013 19:25:21 +0000 Subject: [issue11489] json.dumps not parsable by json.loads (on Linux only) In-Reply-To: <1300058240.59.0.513243746739.issue11489@psf.upfronthosting.co.za> Message-ID: <1368213921.29.0.0810587276552.issue11489@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I forgot about this issue and open a new issue17906. There is a patch for it. Simplejson has accepted it in https://github.com/simplejson/simplejson/issues/62. RFC 4627 does not make exceptions for the range 0xD800-0xDFFF (unescaped = %x20-21 / %x23-5B / %x5D-10FFFF), and the decoder must accept lone surrogates, both escaped and unescaped. Non-BMP characters may be represented as escaped surrogate pair, so escaped surrogate pair may be decoded as non-BMP character, while unescaped surrogate pair shouldn't. ---------- nosy: +bob.ippolito versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 21:25:35 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 May 2013 19:25:35 +0000 Subject: [issue17906] JSON should accept lone surrogates In-Reply-To: <1367678308.48.0.934181281887.issue17906@psf.upfronthosting.co.za> Message-ID: <1368213935.55.0.715399299227.issue17906@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I forgot about issue11489. After reclassification this issue is it's duplicate. ---------- resolution: -> duplicate superseder: -> json.dumps not parsable by json.loads (on Linux only) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 21:29:25 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 May 2013 19:29:25 +0000 Subject: [issue17930] Search not needed in combinations_with_replacement In-Reply-To: <1367962723.84.0.508821715816.issue17930@psf.upfronthosting.co.za> Message-ID: <1368214165.67.0.0470072199294.issue17930@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 21:38:01 2013 From: report at bugs.python.org (paul j3) Date: Fri, 10 May 2013 19:38:01 +0000 Subject: [issue14191] argparse doesn't allow optionals within positionals In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za> Message-ID: <1368214681.22.0.10713055322.issue14191@psf.upfronthosting.co.za> paul j3 added the comment: 'parse_fallback_args()' function is only in the 'test_intermixed.py' file, not the patch. It should be in the 'if __name__' section of that file, along with the modified 'exit()' method, since it is part of these testing suit, not meant to be imported. 'test_intermixed.py' is more of an example and discussion tool, not a formal test. I added the '_fallback' optional argument because the normal exit from 'parse_args' using SystemExit is remarkably uninformative. It's hard to distinguish between the 'fallback' errors, and the ones generated by 'parse_known_args' (that have more to do with the argument strings). One is a programming error, the other a user generated error. It is possible to redefine ArgumentParser.error() so it gives more information, for example by raising an Exception(message). I have added to test_intermixed.py an alternative 'parse_fallback_args' that uses such a modified error rather than the _fallback option. But that ends up modifying the normal parsing error generation as well. I used the 'fallback' idea to test 'parse_intermixed_args' against the whole set 'test_argparse.py' tests. It would nice to have a way of doing that automatically anytime other features are added to 'parse_args'. But I can't think of a clean way of doing that. Regarding earlier versions of these files - I do not see a way of deleting them. I have attached a modified test_intermixed.py that has these changes. I also modified how 'parse_known_intermixed_args' restores the original value of self.usage, using an outer 'try:finally:' block. I need to make a note to myself to put that in the patch. ---------- Added file: http://bugs.python.org/file30204/test_intermixed.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 21:45:39 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 May 2013 19:45:39 +0000 Subject: [issue17939] Misleading information about slice assignment in docs In-Reply-To: <1368048699.98.0.203661524608.issue17939@psf.upfronthosting.co.za> Message-ID: <1368215139.65.0.111265653015.issue17939@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Since range objects have a known length, that example is not enough to show 'any iterable'. However, generators do not even have a __length_hint__ and they work too. a = [1,2,3] a[0:1] = (i for i in range(4)) print(a) >>> [0, 1, 2, 3, 2, 3] ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 21:50:20 2013 From: report at bugs.python.org (Glenn Linderman) Date: Fri, 10 May 2013 19:50:20 +0000 Subject: [issue14191] argparse doesn't allow optionals within positionals In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za> Message-ID: <1368215420.0.0.305894140227.issue14191@psf.upfronthosting.co.za> Glenn Linderman added the comment: paul j3: Regarding earlier versions of these files - I do not see a way of deleting them. Click on edit, then there is an option to unlink. I don't know if they ever actually get deleted, but it clears out the clutter when looking for the latest version. Will check out the newest code shortly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 22:06:49 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 May 2013 20:06:49 +0000 Subject: [issue17945] tkinter/Python 3.3.0: peer_create doesn't instantiate Text In-Reply-To: <1368110182.39.0.238603513669.issue17945@psf.upfronthosting.co.za> Message-ID: <1368216409.47.0.467234925548.issue17945@psf.upfronthosting.co.za> Terry J. Reedy added the comment: (This issue only applies to 3.3+ because the method is new in 3.3.) Gregory: 'works for me' means that the issue can be closed without a patch because Python actually 'works' for the example presented. I presume you mean that the tkinter works *after* you apply the patch and therefore consider it a possible fix to be applied. On that assumption, I downloaded it and will upload it here. Also, if you specifically write issue2843 or #2843, the tracker makes a link to the issue. ---------- keywords: +patch nosy: +terry.reedy resolution: works for me -> stage: -> patch review versions: +Python 3.4 Added file: http://bugs.python.org/file30205/issue17945.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 22:07:10 2013 From: report at bugs.python.org (Steve Strassmann) Date: Fri, 10 May 2013 20:07:10 +0000 Subject: [issue17898] gettext bug while parsing plural-forms metadata In-Reply-To: <1367605186.32.0.57972582146.issue17898@psf.upfronthosting.co.za> Message-ID: <1368216430.34.0.652142025432.issue17898@psf.upfronthosting.co.za> Steve Strassmann added the comment: Sorry, I haven't installed python 3.*, I just have default Mac OS python 2.7. Here's a minimal test case. Tar expands to file structure: ./test.py ./en/LC_MESSAGES/messages.po $ ./test.py Traceback (most recent call last): File "./test.py", line 28, in test() File "./test.py", line 23, in test gettext.install('messages', localedir=LOCALEDIR) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/gettext.py", line 494, in install t = translation(domain, localedir, fallback=True, codeset=codeset) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/gettext.py", line 479, in translat\ ion t = _translations.setdefault(key, class_(fp)) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/gettext.py", line 180, in __init__ self._parse(fp) File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/gettext.py", line 314, in _parse v = v.split(';') AttributeError: 'list' object has no attribute 'split' ---------- Added file: http://bugs.python.org/file30206/pybug.tar.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 22:21:42 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 May 2013 20:21:42 +0000 Subject: [issue17944] Refactor test_zipfile In-Reply-To: <1368093470.65.0.477520947191.issue17944@psf.upfronthosting.co.za> Message-ID: <1368217302.12.0.590365620303.issue17944@psf.upfronthosting.co.za> Terry J. Reedy added the comment: As I understand this, the main refactoring is to put the tests duplicated for zlib, bz2, and lzma into a master class that is then subclasses=d for each of the compressors. This looks like a great idea. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 22:22:24 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 10 May 2013 20:22:24 +0000 Subject: [issue17950] Dynamic classes contain non-breakable reference cycles Message-ID: <1368217344.29.0.260515184231.issue17950@psf.upfronthosting.co.za> New submission from Kristj?n Valur J?nsson: Classes contain two kinds of cycles back to themselves: 1) in their __mro_ list, the class itself is typically the first member. 2) in the descriptors for various fields such as __dict__. The problem here is that there is no way to break the cycle. A class that is dynamically created (e.g. in a function) and then not needed, will stick around until garbage collection is performed. This happens in spite of attempts within the core to avoid such cycles. For instance, the type's tp_subclasses list contains to avoid a cycle between a baseclass and its parent. A .py file demonstrating the problem is attached. A patch is attached that resolves the issue: 1) the mro tuple in the type object is "nerfed" to contain a Py_None reference in its first place, where it previously held the cyclic reference to the type object itself. This is then "fixed" in place where required. the __mro__ attribute becomes a getter that duplicates the tuple. 2) the descriptors are modified to hold a weak-reference to the target type, rather than a strong reference. 3) Fix process cleanup. The thread state cannot be released until after the cleanup of e.g. PySet_Fini() because the freeing of objects in there requires the DUSTBIN_SAFE macros that require the thread state. Cleanup behaviour probably changed since objects go away on their own now. 4) changes to test_gc.py in the testsuite reflecting the changed behaviour The patched code passes all the testsuite. ---------- components: Interpreter Core files: classleak.patch keywords: patch messages: 188875 nosy: kristjan.jonsson priority: normal severity: normal status: open title: Dynamic classes contain non-breakable reference cycles type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file30207/classleak.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 22:22:51 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 10 May 2013 20:22:51 +0000 Subject: [issue17950] Dynamic classes contain non-breakable reference cycles In-Reply-To: <1368217344.29.0.260515184231.issue17950@psf.upfronthosting.co.za> Message-ID: <1368217371.56.0.47968253976.issue17950@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Adding file demonstraing the problem. ---------- Added file: http://bugs.python.org/file30208/classleak.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 22:26:04 2013 From: report at bugs.python.org (mirabilos) Date: Fri, 10 May 2013 20:26:04 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za> Message-ID: <1368217564.95.0.518720820533.issue17237@psf.upfronthosting.co.za> mirabilos added the comment: file30203/ascii_decode_nonaligned.patch is potentially a nop (the struct being a multiple of, in the m68k case 4, bytes is not an indicator of whether to skip it). I think we can be bold and put #if !defined(__m68k__) and #endif around the entire block and, should there ever be another architecture with similar issues, whitelist them there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 22:35:25 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 10 May 2013 20:35:25 +0000 Subject: [issue1545463] New-style classes fail to cleanup attributes Message-ID: <1368218125.4.0.798872370848.issue1545463@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- assignee: belopolsky -> status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 22:36:29 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 10 May 2013 20:36:29 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: <1368217564.95.0.518720820533.issue17237@psf.upfronthosting.co.za> Message-ID: <1368218187.2562.5.camel@fsol> Antoine Pitrou added the comment: > I think we can be bold and put #if !defined(__m68k__) and #endif > around the entire block and, should there ever be another architecture > with similar issues, whitelist them there. Agreed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 22:42:44 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 May 2013 20:42:44 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za> Message-ID: <1368218564.87.0.6047857096.issue17237@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What is sizeof(PyASCIIObject) on m68k? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 22:46:29 2013 From: report at bugs.python.org (Stefan Mihaila) Date: Fri, 10 May 2013 20:46:29 +0000 Subject: [issue17810] Implement PEP 3154 (pickle protocol 4) In-Reply-To: <1366526938.19.0.00976593994103.issue17810@psf.upfronthosting.co.za> Message-ID: <1368218789.98.0.463429802029.issue17810@psf.upfronthosting.co.za> Changes by Stefan Mihaila : ---------- nosy: +mstefanro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 22:54:52 2013 From: report at bugs.python.org (mirabilos) Date: Fri, 10 May 2013 20:54:52 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za> Message-ID: <1368219292.4.0.405154560687.issue17237@psf.upfronthosting.co.za> mirabilos added the comment: Currently 22; it will increase to 24 if a few more bits are added. That?s why I said it?s ?fragile? magic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 23:04:08 2013 From: report at bugs.python.org (Ethan Furman) Date: Fri, 10 May 2013 21:04:08 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368219848.3.0.732047528729.issue17947@psf.upfronthosting.co.za> Ethan Furman added the comment: Round 4. I wonder if I should have used two digits to number the patches. ;) ---------- Added file: http://bugs.python.org/file30209/pep-0435_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 23:05:16 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 10 May 2013 21:05:16 +0000 Subject: [issue17950] Dynamic classes contain non-breakable reference cycles In-Reply-To: <1368217344.29.0.260515184231.issue17950@psf.upfronthosting.co.za> Message-ID: <1368219916.35.0.887226535786.issue17950@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > 1) the mro tuple in the type object is "nerfed" to contain a > Py_None reference in its first place I like the idea, but I find the implementation (the new macros) quite convoluted. I think special-casing the first tuple element where necessary would be cleaner. > 2) the descriptors are modified to hold a weak-reference to the target > type, rather than a strong reference. What would happen if someone keeps a reference to the descriptor and not to the class object? Is it a possible use case? > 3) Fix process cleanup. This was already done in changeset 6f4627a65c0a. You might want to update your working copy. Does your patch cater to all possible implicit cycles, or only a subset of them? ---------- nosy: +amaury.forgeotdarc, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 23:06:23 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 May 2013 21:06:23 +0000 Subject: [issue17944] Refactor test_zipfile In-Reply-To: <1368093470.65.0.477520947191.issue17944@psf.upfronthosting.co.za> Message-ID: <1368219983.89.0.66189549326.issue17944@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, the first patch includes only this change (plus some needed regrouping and renaming). The second patch in additional wraps long lines, uses asserts with better error reporting, has better resource management ("with" operator and addCleanup), and contains other minor changes (see a difference between two patches). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 10 23:46:54 2013 From: report at bugs.python.org (mirabilos) Date: Fri, 10 May 2013 21:46:54 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: <1368178500.76.0.115755504903.issue17237@psf.upfronthosting.co.za> Message-ID: mirabilos added the comment: I?m currently thinking this patch. (Will need another day or so for compiles to finish, though.) ---------- Added file: http://bugs.python.org/file30210/python3.3_3.3.1-1+m68k.1.debdiff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -u python3.3-3.3.1/debian/changelog python3.3-3.3.1/debian/changelog --- python3.3-3.3.1/debian/changelog +++ python3.3-3.3.1/debian/changelog @@ -1,3 +1,9 @@ +python3.3 (3.3.1-1+m68k.1) unreleased; urgency=low + + * Employ m68k build fix (see issue17237) + + -- Thorsten Glaser Fri, 10 May 2013 23:39:11 +0200 + python3.3 (3.3.1-1) unstable; urgency=low * Python 3.3.1 release. diff -u python3.3-3.3.1/debian/patches/series.in python3.3-3.3.1/debian/patches/series.in --- python3.3-3.3.1/debian/patches/series.in +++ python3.3-3.3.1/debian/patches/series.in @@ -55,0 +56 @@ +m68k-buildfix.diff only in patch2: unchanged: --- python3.3-3.3.1.orig/debian/patches/m68k-buildfix.diff +++ python3.3-3.3.1/debian/patches/m68k-buildfix.diff @@ -0,0 +1,18 @@ +--- a/Objects/unicodeobject.c ++++ b/Objects/unicodeobject.c +@@ -4661,6 +4661,7 @@ ascii_decode(const char *start, const ch + const char *p = start; + const char *aligned_end = (const char *) _Py_ALIGN_DOWN(end, SIZEOF_LONG); + ++#if !defined(__m68k__) + #if SIZEOF_LONG <= SIZEOF_VOID_P + assert(_Py_IS_ALIGNED(dest, SIZEOF_LONG)); + if (_Py_IS_ALIGNED(p, SIZEOF_LONG)) { +@@ -4686,6 +4687,7 @@ ascii_decode(const char *start, const ch + return p - start; + } + #endif ++#endif + while (p < end) { + /* Fast path, see in STRINGLIB(utf8_decode) in stringlib/codecs.h + for an explanation. */ From report at bugs.python.org Fri May 10 23:55:41 2013 From: report at bugs.python.org (mirabilos) Date: Fri, 10 May 2013 21:55:41 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za> Message-ID: <1368222941.23.0.669868899203.issue17237@psf.upfronthosting.co.za> mirabilos added the comment: + dest is always aligned on common platforms + (if sizeof(PyASCIIObject) is divisible by SIZEOF_LONG). Actually, that?s the part that is not true. On m68k, and perfectly permitted by the C standard, even a 24-byte object has only a guaranteed alignment of 2 bytes (or one, if it?s a char array) in the normal case (contains integers and pointers, nothing special). We patched out this bogus assumption from things like glib already ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 00:00:37 2013 From: report at bugs.python.org (Stefan Mihaila) Date: Fri, 10 May 2013 22:00:37 +0000 Subject: [issue17810] Implement PEP 3154 (pickle protocol 4) In-Reply-To: <1366526938.19.0.00976593994103.issue17810@psf.upfronthosting.co.za> Message-ID: <1368223237.16.0.648732699378.issue17810@psf.upfronthosting.co.za> Changes by Stefan Mihaila : Added file: http://bugs.python.org/file30211/780722877a3e.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 00:02:05 2013 From: report at bugs.python.org (Stefan Mihaila) Date: Fri, 10 May 2013 22:02:05 +0000 Subject: [issue17810] Implement PEP 3154 (pickle protocol 4) In-Reply-To: <1366526938.19.0.00976593994103.issue17810@psf.upfronthosting.co.za> Message-ID: <1368223325.54.0.153550965125.issue17810@psf.upfronthosting.co.za> Changes by Stefan Mihaila : Removed file: http://bugs.python.org/file30211/780722877a3e.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 00:20:49 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Fri, 10 May 2013 22:20:49 +0000 Subject: [issue17950] Dynamic classes contain non-breakable reference cycles In-Reply-To: <1368217344.29.0.260515184231.issue17950@psf.upfronthosting.co.za> Message-ID: <1368224449.4.0.434835734687.issue17950@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Hello Antoine. 1) Yes, I am not completely happy with the approach myself, but I'd like to get the ball rolling. One particular nuance is that there appears to be a way to provide a custom MRO, one which does not enforce the rule that the self type come first. (although, in the code there is a place that iterates over the mro tuple starting from index 1... the code isn't completely consistent.) An alternative approach, that would replace 'self' in the mro with Py_None, and then special casing this when doing lookup, might that be ok? 2) I was a bit worried about it, but running the test suite showed no problems. The only time this weak reference gets dropped is when the class is garbage collected, hence the need to add special code to repr the descriptor. The descriptors are normally part of the class, and then de-referenced at runtime into concrete things, such as bound methods, and the like. I suppose we could float this on python-dev, to see what people think. 3) thanks for the heads up. it looked a bit weird to me. But python 3 code is still getting the shakedown, and touching these parts of the code can illustrate unknown bugs. There are some other assumptions I came across in the code that are weird, but don't appear to be relevant. In one place, it is presumed that tp_mro could be NULL, but later, it is INCREFd. And in another place, (descriptors) the type is XINCREFd, but then in other places, assumed to be true.... Anyway, I'd like us to find a way to do this in a clean way. I'll revisit the macro scheme, and see if I can do it more nicely and explicitly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 00:39:01 2013 From: report at bugs.python.org (paul j3) Date: Fri, 10 May 2013 22:39:01 +0000 Subject: [issue14191] argparse doesn't allow optionals within positionals In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za> Message-ID: <1368225541.72.0.704146742925.issue14191@psf.upfronthosting.co.za> paul j3 added the comment: I should note one caveat: As a consequence of setting nargs to 0 for the first 'parse_know_args' step, all positional entries in the namespace get an empty list value ([]). This is produced by 'ArgumentParser._get_values'. With the builtin action classes this does not cause any problems. However a custom action class might have problems with this [] value. For example in 'test_argparse.py', TestActionUserDefined the PositionalAction class does check the values and throws an error with this [] value. The positional arguments are removed from the namespace before it is passed on to the 2nd 'parse_known_args', so these [] in the first don't affect the final namespace. I don't think anything about this should be added to main documentation, since it could confuse most readers. I might add a note of warning to the code itself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 01:23:24 2013 From: report at bugs.python.org (Catalin Patulea) Date: Fri, 10 May 2013 23:23:24 +0000 Subject: [issue17951] TypeError during gdb backtracing Message-ID: <1368228204.29.0.543705311064.issue17951@psf.upfronthosting.co.za> New submission from Catalin Patulea: With libpython.py loaded in gdb, when backtracing and trying to pretty-print frame objects along the way, this error is sometimes raised: Python Exception object of type 'FakeRepr' has no len() See attached patch against tip. ---------- components: Demos and Tools files: libpython-typeerror-str.patch keywords: patch messages: 188888 nosy: Catalin.Patulea, dmalcolm priority: normal severity: normal status: open title: TypeError during gdb backtracing type: behavior Added file: http://bugs.python.org/file30212/libpython-typeerror-str.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 02:09:06 2013 From: report at bugs.python.org (Stefan Mihaila) Date: Sat, 11 May 2013 00:09:06 +0000 Subject: [issue17810] Implement PEP 3154 (pickle protocol 4) In-Reply-To: <1368218790.01.0.562055588211.issue17810@psf.upfronthosting.co.za> Message-ID: <518D8C1C.5080209@gmail.com> Stefan Mihaila added the comment: On 5/10/2013 11:46 PM, Stefan Mihaila wrote: > Changes by Stefan Mihaila : > > > ---------- > nosy: +mstefanro > > _______________________________________ > Python tracker > > _______________________________________ > Hello. I've worked on implementing PEP3154 as part of GSoC2012. My work is available in a repo at [1]. The blog I've used to report my work is at [2] and contains some useful information. Here is a list of features that were implemented as part of GSoC: * Pickling of very large bytes and strings * Better pickling of small string and bytes (+ tests) * Native pickling of sets and frozensets (+ tests) * Self-referential sets and frozensets (+ tests) * Implicit memoization (BINPUT is implicit for certain opcodes) - The argument against this was that pickletools.optimize would not be able to prevent memoization of objects that are not referred later. For such situations, a special flag at beginning could be added, which indicates whether implicit BINPUT is enabled. This flag could be added as one of the higher-order bits of the protocol version. For instance: PROTO \x04 + BINUNICODE ".." and PROTO \x84 + BINUNICODE ".." + BINPUT 1 would be equivalent. Then pickletools.optimize could choose whether it wants implicit BINPUT or not. Sure, this would complicate matters and it's not for me to decide whether it's worth it. In my midterm report at [3] there are some examples of what a pickled string looks in v4 without implicit memoization, and some size comparisons to v3. * Pickling of nested globals, methods etc. (+ tests) * Pickling calls to __new__ with keyword args (+ tests) * A BAIL_OUT opcode was always outputted when pickling failed, so that the Pickler and Unpickler can be both run at once on different ends of a stream. The Pickler could guarantee to always send a correct pickle on the stream. The Unpickler would never end up hanging when Pickling failed mid-work. - At the time, Alexandre suggested this would probably not be a great idea because it should be the responsibility of the protocol used to assure some consistency. However, this does not appear to be a trivial task to achieve. The size of the pickle is not known in advance, and waiting for the Pickler to complete before sending the data via stream is not as efficient, because the Unpickler would not be able to run at the same time. write and read methods of the stream would have to be wrapped and some escape sequence used. This would increase the size of the pickled string for some sort of worst-case of the escape sequence, probably. My thought was that it would be beneficial for the average user to have the guarantee that the Pickler always outputs a correct pickle to a stream, even if it raises an exception. * Other minor changes that I can't really remember. Although I'm sure Alexandre had his good reasons to start the work from scratch, it would be a shame to waste all this work. The features mentioned above are working and although the implementation may not be ideal (I don't have the cpython experience of a regular dev), I'm sure useful bits can be extracted from it. Alexandre suggested that I extract bits and post patches, so I have attached, for now, support for pickling methods and nested globals (+tests). I'm willing to do so for some or the rest of the features, should this be requested and should I have the necessary time to do so. [1] https://bitbucket.org/mstefanro/pickle4/ [2] https://pypickle4.wordpress.com/ [3] https://gist.github.com/mstefanro/3086647 ---------- Added file: http://bugs.python.org/file30213/methods.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 780722877a3e Lib/pickle.py --- a/Lib/pickle.py Wed May 01 13:16:11 2013 -0700 +++ b/Lib/pickle.py Sat May 11 03:06:28 2013 +0300 @@ -23,7 +23,7 @@ """ -from types import FunctionType, BuiltinFunctionType +from types import FunctionType, BuiltinFunctionType, MethodType, ModuleType from copyreg import dispatch_table from copyreg import _extension_registry, _inverted_registry, _extension_cache from itertools import islice @@ -34,10 +34,44 @@ import io import codecs import _compat_pickle +import builtins +from inspect import ismodule, isclass __all__ = ["PickleError", "PicklingError", "UnpicklingError", "Pickler", "Unpickler", "dump", "dumps", "load", "loads"] +# Issue 15397: Unbinding of methods +# Adds the possibility to unbind methods as well as a few definitions missing +# from the types module. + +_MethodDescriptorType = type(list.append) +_WrapperDescriptorType = type(list.__add__) +_MethodWrapperType = type([].__add__) + +def _unbind(f): + """Unbinds a bound method.""" + self = getattr(f, '__self__', None) + if self is not None and not isinstance(self, ModuleType) \ + and not isinstance(self, type): + if hasattr(f, '__func__'): + return f.__func__ + return getattr(type(f.__self__), f.__name__) + raise TypeError('not a bound method') + + +def _bind_method(self, func): + """This method is used internally to pickle bound methods using the REDUCE + opcode.""" + return func.__get__(self) + +def _isclassmethod(func): + """Tests if a given function is a classmethod.""" + if type(func) not in [MethodType, BuiltinFunctionType]: + return False + if hasattr(func, '__self__') and type(func.__self__) is type: + return True + return False + # Shortcut for use in isinstance testing bytes_types = (bytes, bytearray) @@ -173,6 +207,8 @@ ADDITEMS = b'\x90' # modify set by adding topmost stack items EMPTY_FROZENSET = b'\x91' # push empty frozenset on the stack FROZENSET = b'\x92' # build frozenset from topmost stack items +BINGLOBAL = b'\x93' # push a global (like GLOBAL) +BINGLOBAL_BIG = b'\x94' # push an unusually large global name __all__.extend([x for x in dir() if re.match("[A-Z][A-Z0-9_]+$", x)]) @@ -726,23 +762,34 @@ write = self.write memo = self.memo + getattr_func = getattr_recurse if self.proto >= 4 else getattr + if name is None: - name = obj.__name__ + if self.proto >= 4: + name = obj.__qualname__ + else: + name = obj.__name__ module = getattr(obj, "__module__", None) if module is None: - module = whichmodule(obj, name) + module = whichmodule(obj, name, getattr_func) try: __import__(module, level=0) mod = sys.modules[module] - klass = getattr(mod, name) - except (ImportError, KeyError, AttributeError): + klass = getattr_func(mod, name) + except (ImportError, KeyError, AttributeError) as e: raise PicklingError( "Can't pickle %r: it's not found as %s.%s" % - (obj, module, name)) + (obj, module, name)) from e else: - if klass is not obj: + # Note: The 'is' operator does not currently work as expected when + # applied on functions which are classmethods ("dict.fromkeys is + # dict.fromkeys" is False). Therefore, we only perform the check + # below if the object we are dealing with ("obj") is not a + # classmethod. + # XXX remove the additional check when this is fixed + if klass is not obj and not _isclassmethod(obj): raise PicklingError( "Can't pickle %r: it's not the same object as %s.%s" % (obj, module, name)) @@ -758,10 +805,31 @@ else: write(EXT4 + pack("= 4 and module == '__builtins__': + module = 'builtins' # Non-ASCII identifiers are supported only with protocols >= 3. if self.proto >= 3: - write(GLOBAL + bytes(module, "utf-8") + b'\n' + - bytes(name, "utf-8") + b'\n') + module_bin = bytes(module, 'utf-8') + name_bin = bytes(name, 'utf-8') + if self.proto >= 4 and len(module_bin) <= 255 and \ + len(name_bin) <= 255: + write(BINGLOBAL + bytes([len(module_bin)]) + + module_bin + bytes([len(name_bin)]) + name_bin) + # use BINGLOBAL_BIG for representing unusually large globals in + # pickle >= 4 + elif self.proto >= 4: + assert len(module_bin) <= 65535 + assert len(name_bin) <= 65535 + write(BINGLOBAL_BIG + pack('>> getattr(sys.modules['os'], 'path.isdir') + Traceback (most recent call last): + ... + AttributeError: 'module' object has no attribute 'path.isdir' + >>> getattr_recurse(sys.modules['os'], 'path.isdir')('.') + True + >>> getattr_recurse(sys.modules['os'], 'path.foo') + Traceback (most recent call last): + ... + AttributeError: 'module' object has no attribute 'foo' + """ + ret = module + for attr in name.split('.'): + if attr == '': + raise TypeError('Cannot work with the locals of '+ + ret.__qualname__) + + if default is _None: + ret = getattr(ret, attr) + """ + raise AttributeError('\'%s\' object has no attribute \'%s\'' % + (type(ret), n)) + ret = ret_ + """ + else: + try: + ret = getattr(ret, attr) + except AttributeError: + return default + return ret + + +def whichmodule(func, funcname, getattr_func=getattr): """Figure out the module in which a function occurs. Search sys.modules for the module. @@ -799,13 +926,20 @@ mod = getattr(func, "__module__", None) if mod is not None: return mod + # XXX this is for classmethods. since whichmodule() uses `is' to compare + # for equality of functions and "dict.fromkeys is dict.fromkeys" evaluates + # to False, whichmodule(dict.fromkeys, 'dict.fromkeys') would incorrectly + # return '__main__' + elif hasattr(func, "__self__") and hasattr(func.__self__, "__module__") \ + and func.__self__.__module__ is not None: + return func.__self__.__module__ if func in classmap: return classmap[func] for name, module in list(sys.modules.items()): if module is None: continue # skip dummy package entries - if name != '__main__' and getattr(module, funcname, None) is func: + if name != '__main__' and getattr_func(module, funcname, None) is func: break else: name = '__main__' @@ -1180,10 +1314,20 @@ module, name = _compat_pickle.NAME_MAPPING[(module, name)] if module in _compat_pickle.IMPORT_MAPPING: module = _compat_pickle.IMPORT_MAPPING[module] - __import__(module, level=0) - mod = sys.modules[module] - klass = getattr(mod, name) - return klass + + try: + __import__(module, level=0) + + mod = sys.modules[module] + + if self.proto >= 4: + klass = getattr_recurse(mod, name) + else: + klass = getattr(mod, name) + return klass + except Exception as e: + raise UnpicklingError("Couldn't find class %s.%s" % + (module,name)) from e def load_reduce(self): stack = self.stack @@ -1333,6 +1477,24 @@ raise _Stop(value) dispatch[STOP[0]] = load_stop + def load_binglobal(self): + module_size = self.read(1)[0] + module = self.read(module_size).decode('utf-8') + name_size = self.read(1)[0] + name = self.read(name_size).decode('utf-8') + klass = self.find_class(module, name) + self.append(klass) + dispatch[BINGLOBAL[0]] = load_binglobal + + def load_binglobal_big(self): + module_size = unpack('>> import io + >>> read_unicodestringu2(io.BytesIO(b'\x00\x00abc')) + '' + >>> read_unicodestringu2(io.BytesIO(b'\x03\x00abc')) + 'abc' + >>> read_unicodestringu2(io.BytesIO(b'\x04\x00' + ('\U0001D223'.encode('utf-8')))) + '\U0001d223' + >>> read_unicodestringu2(io.BytesIO(b'\x0d\x00' + ('\ufb93' * 4).encode('utf-8'))) + Traceback (most recent call last): + ... + ValueError: expected 13 bytes in a unicodestringu2, but only 12 remain + """ + n = read_uint2(f) + assert n >= 0 + + data = f.read(n) + if len(data) == n: + return str(data, 'utf-8', 'surrogatepass') + raise ValueError("expected %d bytes in a unicodestringu2, but only %d " + "remain" % (n, len(data))) + +unicodestringu2 = ArgumentDescriptor( + name='unicodestringu2', + n=TAKEN_FROM_ARGUMENT2U, + reader=read_unicodestringu2, + doc="""A counted semi-short Unicode string. + + The first argument is a 2-byte little-endian unsigned short, giving + the number of bytes in the string, and the second argument is + the UTF-8 encoding of the Unicode string + """) +def read_unicodestring1_pair(f): + r""" + >>> import io + >>> read_unicodestring1_pair(io.BytesIO(b"\x00\x00whatever")) + ' ' + >>> read_unicodestring1_pair(io.BytesIO(b"\x05hello\x06world!blabla")) + 'hello world!' + """ + return "%s %s" % (read_unicodestring1(f), read_unicodestring1(f)) + +unicodestring1_pair = ArgumentDescriptor( + name='unicodestring1_pair', + n=TAKEN_FROM_ARGUMENT1, + reader=read_unicodestring1_pair, + doc="""Read a pair of small unicode strings. + + Both of the strings are preceded by an uint1 + indicating the length of the utf-8 encoded + string to follow""") + +def read_unicodestringu2_pair(f): + r""" + >>> import io + >>> read_unicodestringu2_pair(io.BytesIO(b"\x00\x00\x00\x00whatever")) + ' ' + >>> read_unicodestringu2_pair(io.BytesIO( + ... b"\x05\x00hello\x06\x00world!blabla")) + 'hello world!' + """ + return "%s %s" % (read_unicodestringu2(f), read_unicodestringu2(f)) + +unicodestringu2_pair = ArgumentDescriptor( + name='unicodestringu2_pair', + n=TAKEN_FROM_ARGUMENT2U, + reader=read_unicodestringu2_pair, + doc="""Read a pair of semi-small unicode strings. + + Both of the strings are preceded by a + little-endian uint2 indicating the length + of the utf-8 encoded string to follow""") def read_string1(f): r""" @@ -2107,6 +2182,35 @@ ID is passed to self.persistent_load(), and whatever object that returns is pushed on the stack. See PERSID for more detail. """), + I(name='BINGLOBAL', + code='\x93', + arg=unicodestring1_pair, + stack_before=[], + stack_after=[anyobject], + proto=4, + doc="""Push a global object (module.obj) on the stack. + + This works in a similar way to GLOBAL, but instead of taking a pair of + newline-terminated strings as parameters (representing the module name + and the attribute respectively), it takes a pair of two small utf-8 + encoded strings, with their 8bit size prepended to them (the + equivalent of two consecutive SHORT_BINUNICODE opcodes). + + On versions 4 and above, this object is automatically memoized by the + unpickler (there's no need for BINPUT after this opcode). + """), + + I(name='BINGLOBAL_BIG', + code='\x94', + arg=unicodestringu2_pair, + stack_before=[], + stack_after=[anyobject], + proto=4, + doc="""Push a global object (module.obj) on the stack. + + This is used instead of BINGLOBAL for unusually large global names (i.e. + >255 bytes). + """), ] del I @@ -2414,6 +2518,20 @@ if stack: raise ValueError("stack not empty after STOP: %r" % stack) +def maxversion(pickled_data): + """Find the maximum version amongst the used opcodes in the given pickled + data. + + Like in `dis', pickle is a file-like object, or string, containing at least + one pickle. The pickle is disassembled from the current position until the + first STOP opcode is encountered, and the maximum version of the + encountered opcodes is returned. + """ + ret = -1 + for opcode, arg, pos in genops(pickled_data): + ret = max(ret, opcode.proto) + return ret + # For use in the doctest, simply as an example of a class to pickle. class _Example: def __init__(self, value): diff -r 780722877a3e Lib/test/pickletester.py --- a/Lib/test/pickletester.py Wed May 01 13:16:11 2013 -0700 +++ b/Lib/test/pickletester.py Sat May 11 03:06:28 2013 +0300 @@ -433,6 +433,43 @@ x.append(5) return x +class Nested: + n = 'Nested' + + class B: + n = 'Nested.B' + + def f(): + return 'Nested.B.f' + def ff(self): + return 'Nested.B.ff' + + @classmethod + def cm(klass): + return klass.n + + @staticmethod + def sm(): + return 'sm' + + class C: + n = 'Nested.B.C' + + def __init__(self): + self.a = 123 + + def f(): + return 'Nested.B.C.f' + def ff(self): + return 'Nested.B.C.ff' + + def get_a(self): + return self.a + +# used to test pickling of unusually large names +class _aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa: + pass + class AbstractPickleTests(unittest.TestCase): # Subclass must define self.dumps, self.loads. @@ -1291,6 +1328,105 @@ self._check_pickling_with_opcode(obj, pickle.SETITEM, proto) else: self._check_pickling_with_opcode(obj, pickle.SETITEMS, proto) + + def _loads(self, data, version=pickle.HIGHEST_PROTOCOL, minversion=-1, + *kargs, **kwargs): + """Uses loads, but first makes sure there aren't any opcodes of too + high or too low of a version number. + + Usecase: + data = self.dumps([1, 2, 3], proto) + undata = self._loads(data, proto) + + v3_feature = .. + data = self.dumps(v3_feature, 4) + undata = self._loads(v3_feature, 4, 3) + """ + maxv = pickletools.maxversion(data) + self.assertLessEqual(maxv, version) + self.assertLessEqual(minversion, maxv) + return self.loads(data, *kargs, **kwargs) + + def _used_opcodes(self, data): + opcodes=set() + for opcode, arg, pos in pickletools.genops(data): + opcodes.add(opcode.name) + return opcodes + + def test_v4_binglobal_big(self): + klass=_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa + for proto in protocols: + data=self.dumps(klass, proto) + klass_=self._loads(data, proto) + self.assertEqual(klass_, klass) + opcodes=self._used_opcodes(data) + if proto < 4: + self.assertNotIn('BINGLOBAL', opcodes) + self.assertNotIn('BINGLOBAL_BIG', opcodes) + self.assertIn('GLOBAL', opcodes) + else: + self.assertNotIn('GLOBAL', opcodes) + self.assertNotIn('BINGLOBAL', opcodes) + self.assertIn('BINGLOBAL_BIG', opcodes) + + def test_v4_nested_classes(self): + """test pickling nested classes""" + for proto in range(4, 1+pickle.HIGHEST_PROTOCOL): + for klass in (Nested, Nested.B, Nested.B.C): + data = self.dumps(klass, proto) + undata = self._loads(data, proto, 4) + + self.assertEqual(klass.n, undata.n) + self.assertEqual(klass.n, undata.__qualname__) + self.assertEqual(klass.__qualname__, undata.__qualname__) + + for func in (Nested.B.f, Nested.B.C.f): + data = self.dumps(func, proto) + undata = self._loads(data, proto, 4) + + self.assertEqual(func.__qualname__, undata.__qualname__) + self.assertEqual(func(), undata()) + self.assertLessEqual(4, pickletools.maxversion(data)) + + inst = Nested.B.C() + inst.a = 42 + + data = self.dumps(inst, proto) + undata = self._loads(data, proto, 4) + + self.assertEqual(inst.a, undata.get_a()) + + data = self.dumps( [(inst, Nested.B), (Nested.B.C.f, Nested.B.f, + Nested.B.C.f), + Nested, Nested.B.C, inst, Nested.B.f], proto) + inst.a = -42 + undata = self._loads(data, proto, 4) + + self.assertEqual(42, undata[0][0].a) + self.assertEqual('Nested.B.f', undata[0][1].f()) + self.assertEqual('Nested.B.C.f', undata[1][0]()) + self.assertEqual('Nested.B.f', undata[1][1]()) + self.assertEqual('Nested.B.C.f', undata[1][2]()) + self.assertEqual('Nested', undata[2].n) + self.assertEqual('Nested.B.C', undata[3].n) + self.assertEqual(42, undata[4].get_a()) + self.assertEqual('Nested.B.f', undata[5]()) + + def test_v4_weird_funcs(self): + funcs = [list.append, list.__add__, dict.fromkeys, len, Nested.B.cm, + Nested.B.sm] + for proto in range(4, 1+pickle.HIGHEST_PROTOCOL): + data=self.dumps(funcs, proto) + funcs_=self._loads(data, proto) + l=[] + funcs_[0](l, 1) # l.append(1) + l=funcs_[1](l, [2,3]) # l += [2,3] + self.assertEqual([1,2,3], l) + self.assertEqual(3, funcs_[3](l)) # len(l) + # dict.fromkeys([1,2]) = {1: None, 2: None} + self.assertEqual({1 : None, 2 : None}, funcs_[2]([1,2])) + self.assertEqual('Nested.B', funcs_[4]()) # Nested.B.cm() + self.assertEqual('sm', funcs_[5]()) # Nested.B.sm() class BigmemPickleTests(unittest.TestCase): diff -r 780722877a3e Modules/_pickle.c --- a/Modules/_pickle.c Wed May 01 13:16:11 2013 -0700 +++ b/Modules/_pickle.c Sat May 11 03:06:28 2013 +0300 @@ -80,7 +80,9 @@ EMPTY_SET = '\x8f', ADDITEMS = '\x90', EMPTY_FROZENSET = '\x91', - FROZENSET = '\x92' + FROZENSET = '\x92', + BINGLOBAL = '\x93', + BINGLOBAL_BIG = '\x94' }; /* These aren't opcodes -- they're ways to pickle bools before protocol 2 @@ -145,6 +147,161 @@ /* For looking up name pairs in copyreg._extension_registry. */ static PyObject *two_tuple = NULL; +static PyObject *v4_common_modules = NULL; + +static PyObject * +unbind (PyObject *func) +{ + PyObject *self = NULL, *unbound = NULL, *name; + static PyObject *self_str = NULL, *func_str = NULL, *name_str = NULL; + + if (!self_str) { + self_str = PyUnicode_InternFromString("__self__"); + if (!self_str) return NULL; + } + + self = PyObject_GetAttr(func, self_str); + PyErr_Clear(); + if (!self || PyModule_Check(self) || PyType_Check(self)) { + PyErr_SetString(PyExc_TypeError, "not a bound method"); + Py_XDECREF(self); + return NULL; + } + else { + if (!func_str) { + func_str = PyUnicode_InternFromString("__func__"); + if (!func_str) goto done; + } + unbound = PyObject_GetAttr(func, func_str); + if (unbound) goto done; + else { + if (PyErr_ExceptionMatches(PyExc_AttributeError)) + PyErr_Clear(); + else return NULL; + if (!name_str) { + name_str = PyUnicode_InternFromString("__name__"); + if (!name_str) goto done; + } + name = PyObject_GetAttr(func, name_str); + if (!name) goto done; + unbound = PyObject_GetAttr((PyObject*)Py_TYPE(self), name); + Py_DECREF(name); + } + } + +done: + Py_DECREF(self); + return unbound; +} + +static int isclassmethod (PyObject *func) +{ + PyObject *self; + static PyObject *self_str = NULL; + + if (Py_TYPE(func) != &PyMethod_Type && + Py_TYPE(func) != &PyCFunction_Type && + Py_TYPE(func) != &PyClassMethod_Type && + Py_TYPE(func) != &PyClassMethodDescr_Type) return 0; + + if (!self_str) { + self_str = PyUnicode_InternFromString("__self__"); + if (!self_str) return 0; + } + + self = PyObject_GetAttr(func, self_str); + if (self && PyType_Check(self)) { Py_DECREF(self); return 1; } + Py_XDECREF(self); + return 0; +} + +static PyObject * +getattr_recurse (PyObject *obj, PyObject *attr) +{ + static PyObject *locals_str = NULL, *qualname_str = NULL, *dot = NULL; + PyObject *attr_parts, *iter, *item, *crt = obj, *prev; + + assert(PyUnicode_Check(attr)); + + if (locals_str == NULL) { + /* + appears as a token in __qualname__. E.g.: + >>> def f(): + ... def g(): + ... pass + ... return g.__qualname__ + ... + >>> f() + 'f..g' + */ + locals_str = PyUnicode_InternFromString(""); + if (locals_str == NULL) return NULL; + } + if (qualname_str == NULL) { + qualname_str = PyUnicode_InternFromString("__qualname__"); + if (qualname_str == NULL) return NULL; + } + if (dot == NULL) { + dot = PyUnicode_InternFromString("."); + if (dot == NULL) return NULL; + } + + attr_parts = PyUnicode_Split(attr, dot, 128); + if (!attr_parts) + return NULL; + + iter = PyObject_GetIter(attr_parts); + + // Making sure that the first call to Py_DECREF(prev) below won't decrement + // obj's refcount + Py_INCREF(obj); + + while ( (item = PyIter_Next(iter)) ) { + //check item=="" + PyObject *is_locals = PyUnicode_RichCompare(item, locals_str, Py_EQ); + + if (is_locals == Py_True) { + PyObject *qualname = PyObject_GetAttr(crt, qualname_str); + if (qualname == NULL) { crt = NULL; goto error; } + PyErr_Format(PyExc_TypeError, + "Cannot work with the locals of %U", qualname); + Py_DECREF(item); + Py_DECREF(qualname); + Py_DECREF(is_locals); + crt = NULL; + goto error; + } + else if (is_locals == Py_NotImplemented) { + PyErr_BadInternalCall(); + crt = NULL; + Py_DECREF(item); + Py_DECREF(is_locals); + goto error; + } + else if (is_locals == NULL) { + crt = NULL; + Py_DECREF(item); + goto error; + } + + prev = crt; + crt = PyObject_GetAttr(crt, item); + Py_DECREF(prev); + Py_DECREF(is_locals); + if (crt == NULL) { Py_DECREF(item); goto error; } + + Py_DECREF(item); + } + + //iteration failed + if (PyErr_Occurred()) crt = NULL; + +error: + Py_DECREF(iter); + Py_DECREF(attr_parts); + return crt; +} + static int stack_underflow(void) { @@ -1339,9 +1496,11 @@ Py_ssize_t i, j; static PyObject *module_str = NULL; static PyObject *main_str = NULL; + static PyObject *self_str = NULL; PyObject *module_name; PyObject *modules_dict; PyObject *module; + PyObject *self; PyObject *obj; if (module_str == NULL) { @@ -1351,27 +1510,47 @@ main_str = PyUnicode_InternFromString("__main__"); if (main_str == NULL) return NULL; + self_str = PyUnicode_InternFromString("__self__"); + if (self_str == NULL) + return NULL; } module_name = PyObject_GetAttr(global, module_str); /* In some rare cases (e.g., bound methods of extension types), - __module__ can be None. If it is so, then search sys.modules - for the module of global. */ - if (module_name == Py_None) { + __module__ can be None. If it is so, then search sys.modules for the + module of global. Before doing so, check if the global has a __self__ + attribute which in turn has a __module__. */ + if (!module_name) { + if (PyErr_ExceptionMatches(PyExc_AttributeError)) + PyErr_Clear(); + else + return NULL; + } + else if (module_name == Py_None) { Py_DECREF(module_name); - goto search; - } - - if (module_name) { - return module_name; - } - if (PyErr_ExceptionMatches(PyExc_AttributeError)) - PyErr_Clear(); - else - return NULL; - - search: + } + else return module_name; + + self = PyObject_GetAttr(global, self_str); + if (!self) { + if (PyErr_ExceptionMatches(PyExc_AttributeError)) + PyErr_Clear(); + else + return NULL; + } + else { + module_name = PyObject_GetAttr(self, module_str); + Py_DECREF(self); + if (!module_name) { + if (PyErr_ExceptionMatches(PyExc_AttributeError)) + PyErr_Clear(); + else + return NULL; + } + else return module_name; + } + modules_dict = PySys_GetObject("modules"); if (modules_dict == NULL) return NULL; @@ -1382,7 +1561,7 @@ if (PyObject_RichCompareBool(module_name, main_str, Py_EQ) == 1) continue; - obj = PyObject_GetAttr(module, global_name); + obj = getattr_recurse(module, global_name); if (obj == NULL) { if (PyErr_ExceptionMatches(PyExc_AttributeError)) PyErr_Clear(); @@ -2620,6 +2799,69 @@ return status; } +static int save_global_nonbinary( + PicklerObject *self, + PyObject *module_name, + PyObject *global_name) +{ + static char global_op = GLOBAL; + PyObject *encoded; + PyObject *(*unicode_encoder)(PyObject *); + + /* Since Python 3.0 now supports non-ASCII identifiers, we encode both + the module name and the global name using UTF-8. We do so only when + we are using the pickle protocol newer than version 3. This is to + ensure compatibility with older Unpickler running on Python 2.x. */ + if (self->proto >= 3) { + unicode_encoder = PyUnicode_AsUTF8String; + } + else { + unicode_encoder = PyUnicode_AsASCIIString; + } + + if ( _Pickler_Write(self, &global_op, 1) < 0) + return -1; + + /* Save the name of the module. */ + encoded = unicode_encoder(module_name); + if (encoded == NULL) { + if (PyErr_ExceptionMatches(PyExc_UnicodeEncodeError)) + PyErr_Format(PicklingError, + "can't pickle module identifier '%S' using " + "pickle protocol %i", module_name, self->proto); + return -1; + } + if (_Pickler_Write(self, PyBytes_AS_STRING(encoded), + PyBytes_GET_SIZE(encoded)) < 0) { + Py_DECREF(encoded); + return -1; + } + Py_DECREF(encoded); + if(_Pickler_Write(self, "\n", 1) < 0) + return -1; + + /* Save the name of the global. */ + encoded = unicode_encoder(global_name); + if (encoded == NULL) { + if (PyErr_ExceptionMatches(PyExc_UnicodeEncodeError)) + PyErr_Format(PicklingError, + "can't pickle global identifier '%S' using " + "pickle protocol %i", global_name, self->proto); + return -1; + } + if (_Pickler_Write(self, PyBytes_AS_STRING(encoded), + PyBytes_GET_SIZE(encoded)) < 0) { + Py_DECREF(encoded); + return -1; + } + Py_DECREF(encoded); + if(_Pickler_Write(self, "\n", 1) < 0) + return -1; + + return 0; +} + + static int save_set(PicklerObject *self, PyObject *obj) { @@ -2772,30 +3014,159 @@ return 0; } +/* + * Only for pickle >= 4. + * Uses opcodes BINGLOBAL, BINGLOBAL_BIG + */ +static int save_global_binary( + PicklerObject *self, + PyObject *module_name, + PyObject *global_name) +{ + char global_op; + int return_code = 0; + PyObject *encoded_module_name, *encoded_global_name; + Py_ssize_t encoded_module_size, encoded_global_size; + + assert(module_name != NULL && global_name != NULL); + + encoded_module_name = PyUnicode_AsUTF8String(module_name); + if (encoded_module_name == NULL) { + if (PyErr_ExceptionMatches(PyExc_UnicodeEncodeError)) + PyErr_Format(PicklingError, + "can't pickle module identifier '%S' using " + "pickle protocol %i", encoded_module_name, + self->proto); + return -1; + } + encoded_module_size = PyBytes_GET_SIZE(encoded_module_name); + if (encoded_module_size < 0) { + Py_DECREF(encoded_module_name); + return -1; + } + + encoded_global_name = PyUnicode_AsUTF8String(global_name); + if (encoded_global_name == NULL) { + if (PyErr_ExceptionMatches(PyExc_UnicodeEncodeError)) + PyErr_Format(PicklingError, + "can't pickle global identifier '%S' using " + "pickle protocol %i", global_name, self->proto); + Py_DECREF(encoded_module_name); + return -1; + } + encoded_global_size = PyBytes_GET_SIZE(encoded_global_name); + if (encoded_global_size < 0) goto error; + + /* BINGLOBAL */ + if (encoded_module_size <= 0xff && encoded_global_size <= 0xff) { + char module_size_byte = encoded_module_size, + global_size_byte = encoded_global_size; + + /* write the opcode */ + global_op = BINGLOBAL; + if (_Pickler_Write(self, &global_op, 1) < 0) + goto error; + + /* write the size of the module (1 byte) */ + if (_Pickler_Write(self, &module_size_byte, 1) < 0) + goto error; + + /* write the module name */ + if (_Pickler_Write(self, PyBytes_AS_STRING(encoded_module_name), + encoded_module_size) < 0) + goto error; + + /* write the size of the global (1 byte) */ + if (_Pickler_Write(self, &global_size_byte, 1) < 0) + goto error; + + /* write the global name */ + if (_Pickler_Write(self, PyBytes_AS_STRING(encoded_global_name), + encoded_global_size) < 0) + goto error; + + } + /* BINGLOBAL_BIG */ + else { + char data[2]; + /* nearly useless checks */ + if (encoded_module_size > 0xffff) { + PyErr_Format(PyExc_OverflowError, "Unusually large module name."); + goto error; + } + else if (encoded_global_size > 0xffff) { + PyErr_Format(PyExc_OverflowError, "Unusually large global name."); + goto error; + } + + /* write the opcode */ + global_op = BINGLOBAL_BIG; + if (_Pickler_Write(self, &global_op, 1) < 0) + goto error; + + /* write the size of the module (2 bytes) */ + data[0] = (unsigned char)(encoded_module_size & 0xff); + data[1] = (unsigned char)((encoded_module_size >> 8) & 0xff); + if (_Pickler_Write(self, data, 2) < 0) + goto error; + + /* write the module name */ + if (_Pickler_Write(self, PyBytes_AS_STRING(encoded_module_name), + encoded_module_size) < 0) + goto error; + + /* write the size of the global (2 bytes) */ + data[0] = (unsigned char)(encoded_global_size & 0xff); + data[1] = (unsigned char)((encoded_global_size >> 8) & 0xff); + if (_Pickler_Write(self, data, 2) < 0) + goto error; + + /* write the global name */ + if (_Pickler_Write(self, PyBytes_AS_STRING(encoded_global_name), + encoded_global_size) < 0) + goto error; + } + + if (0) { + // only goto error after both encoded_global_name + // and encoded_module_name have been initialized +error: + return_code = -1; + } + Py_DECREF(encoded_module_name); + Py_DECREF(encoded_global_name); + return return_code; +} + static int save_global(PicklerObject *self, PyObject *obj, PyObject *name) { - static PyObject *name_str = NULL; + static PyObject *name_str = NULL, + *qualname_str = NULL; PyObject *global_name = NULL; PyObject *module_name = NULL; PyObject *module = NULL; PyObject *cls; int status = 0; - const char global_op = GLOBAL; - - if (name_str == NULL) { + if (self->proto < 4 && name_str == NULL) { name_str = PyUnicode_InternFromString("__name__"); if (name_str == NULL) goto error; } + else if (self->proto >= 4 && qualname_str == NULL) { + qualname_str = PyUnicode_InternFromString("__qualname__"); + if (qualname_str == NULL) + goto error; + } if (name) { global_name = name; Py_INCREF(global_name); } else { - global_name = PyObject_GetAttr(obj, name_str); + global_name = PyObject_GetAttr(obj, + self->proto >= 4 ? qualname_str : name_str); if (global_name == NULL) goto error; } @@ -2819,14 +3190,21 @@ obj, module_name); goto error; } - cls = PyObject_GetAttr(module, global_name); + if (self->proto < 4) { + cls = PyObject_GetAttr(module, global_name); + } + else { + cls = getattr_recurse(module, global_name); + } if (cls == NULL) { PyErr_Format(PicklingError, "Can't pickle %R: attribute lookup %S.%S failed", obj, module_name, global_name); goto error; } - if (cls != obj) { + // we ignore this step for classmethods because + // "dict.fromkeys is dict.fromkeys" evaluates to false + if (cls != obj && !isclassmethod(obj)) { Py_DECREF(cls); PyErr_Format(PicklingError, "Can't pickle %R: it's not the same object as %S.%S", @@ -2867,8 +3245,8 @@ if (code <= 0 || code > 0x7fffffffL) { if (!PyErr_Occurred()) PyErr_Format(PicklingError, - "Can't pickle %R: extension code %ld is out of range", - obj, code); + "Can't pickle %R: extension code %ld is out of range", + obj, code); goto error; } @@ -2900,23 +3278,9 @@ /* Generate a normal global opcode if we are using a pickle protocol <= 2, or if the object is not registered in the extension registry. */ - PyObject *encoded; - PyObject *(*unicode_encoder)(PyObject *); gen_global: - if (_Pickler_Write(self, &global_op, 1) < 0) - goto error; - - /* Since Python 3.0 now supports non-ASCII identifiers, we encode both - the module name and the global name using UTF-8. We do so only when - we are using the pickle protocol newer than version 3. This is to - ensure compatibility with older Unpickler running on Python 2.x. */ - if (self->proto >= 3) { - unicode_encoder = PyUnicode_AsUTF8String; - } - else { - unicode_encoder = PyUnicode_AsASCIIString; - } + /* For protocol < 3 and if the user didn't request against doing so, we convert module names to the old 2.x module names. */ @@ -2974,42 +3338,17 @@ goto error; } } - - /* Save the name of the module. */ - encoded = unicode_encoder(module_name); - if (encoded == NULL) { - if (PyErr_ExceptionMatches(PyExc_UnicodeEncodeError)) - PyErr_Format(PicklingError, - "can't pickle module identifier '%S' using " - "pickle protocol %i", module_name, self->proto); - goto error; + + if (self->proto < 4) { + //uses opcode GLOBAL + if (save_global_nonbinary(self, module_name, global_name) < 0) + goto error; } - if (_Pickler_Write(self, PyBytes_AS_STRING(encoded), - PyBytes_GET_SIZE(encoded)) < 0) { - Py_DECREF(encoded); - goto error; + else if (self->proto >= 4) { + //uses one of the opcodes: BINGLOBAL or BINGLOBAL_BIG + if (save_global_binary(self, module_name, global_name) < 0) + goto error; } - Py_DECREF(encoded); - if(_Pickler_Write(self, "\n", 1) < 0) - goto error; - - /* Save the name of the module. */ - encoded = unicode_encoder(global_name); - if (encoded == NULL) { - if (PyErr_ExceptionMatches(PyExc_UnicodeEncodeError)) - PyErr_Format(PicklingError, - "can't pickle global identifier '%S' using " - "pickle protocol %i", global_name, self->proto); - goto error; - } - if (_Pickler_Write(self, PyBytes_AS_STRING(encoded), - PyBytes_GET_SIZE(encoded)) < 0) { - Py_DECREF(encoded); - goto error; - } - Py_DECREF(encoded); - if(_Pickler_Write(self, "\n", 1) < 0) - goto error; /* Memoize the object. */ if (memo_put(self, obj) < 0) @@ -3028,6 +3367,77 @@ } static int +save_global_or_method(PicklerObject *self, PyObject *obj) +{ + PyObject *unbound, *obj_self = NULL, *tuple, *inner_tuple; + static PyObject *str_self = NULL, *binding_function = NULL, + *pickle_str = NULL; + int ret = -1; + + unbound = unbind(obj); + if (unbound == NULL) { + if (PyErr_ExceptionMatches(PyExc_TypeError)) { + PyErr_Clear(); + return save_global(self, obj, NULL); + } + return -1; + } + else if (self->proto < 4) { + PyErr_SetString(PicklingError, + "Can't pickle bound methods in pickle<4"); + Py_DECREF(unbound); + return -1; + } + else { + if (pickle_str == NULL) { + pickle_str = PyUnicode_InternFromString("pickle"); + if (pickle_str == NULL) { + Py_DECREF(unbound); + return -1; + } + } + if (binding_function == NULL) { + PyObject *pickle_module = PyImport_Import(pickle_str); + if (pickle_module == NULL) { + Py_DECREF(unbound); + return -1; + } + binding_function = PyObject_GetAttrString(pickle_module, + "_bind_method"); + if (binding_function == NULL) { + Py_DECREF(unbound); + return -1; + } + } + if (str_self == NULL) { + str_self = PyUnicode_InternFromString("__self__"); + if (str_self == NULL) { + Py_DECREF(unbound); + return -1; + } + } + + obj_self = PyObject_GetAttr(obj, str_self); + if (obj_self == NULL) { + Py_DECREF(unbound); + return -1; + } + + inner_tuple = PyTuple_Pack(2, obj_self, unbound); + if (!inner_tuple) goto done; + + tuple = PyTuple_Pack(2, binding_function, inner_tuple); + if (!tuple) goto done; + + ret = save_reduce(self, tuple, obj); + Py_DECREF(tuple); +done: + Py_DECREF(obj_self); + Py_DECREF(unbound); + return ret; + } +} +static int save_ellipsis(PicklerObject *self, PyObject *obj) { PyObject *str = PyUnicode_FromString("Ellipsis"); @@ -3441,7 +3851,13 @@ goto done; } } - else if (type == &PyCFunction_Type) { + else if (type == &PyCFunction_Type || type == &PyMethod_Type || + type == &_PyMethodWrapper_Type) { + status = save_global_or_method(self, obj); + goto done; + } + else if (type == &PyWrapperDescr_Type || type == &PyMethodDescr_Type || + type == &PyClassMethodDescr_Type) { status = save_global(self, obj, NULL); goto done; } @@ -4840,6 +5256,97 @@ } static int +load_binglobal(UnpicklerObject *self) +{ + PyObject *module_name, *global_name, *global = NULL; + char *s; + Py_ssize_t encoded_size; + + /* read module's size (1 byte) */ + if (_Unpickler_Read(self, &s, 1) < 1) + return -1; + encoded_size = (unsigned char)s[0]; + + /* read module name */ + if (_Unpickler_Read(self, &s, encoded_size) < encoded_size) + return -1; + module_name = PyUnicode_DecodeUTF8(s, encoded_size, "strict"); + if (!module_name) + return -1; + + /* read global's size */ + if (_Unpickler_Read(self, &s, 1) < 1) + return -1; + encoded_size = (unsigned char)s[0]; + + /* read global name */ + if (_Unpickler_Read(self, &s, encoded_size) < encoded_size) { + Py_DECREF(module_name); + return -1; + } + global_name = PyUnicode_DecodeUTF8(s, encoded_size, "strict"); + + if (global_name) { + global = find_class(self, module_name, global_name); + Py_DECREF(global_name); + } + + Py_DECREF(module_name); + + if (global) { + PDATA_PUSH(self->stack, global, -1); + return 0; + } + return -1; +} + +static int +load_binglobal_big(UnpicklerObject *self) +{ + /* like load_binglobal, s/1/2/g */ + PyObject *module_name, *global_name, *global = NULL; + char *s; + Py_ssize_t encoded_size; + + /* read module's size (2 bytes) */ + if (_Unpickler_Read(self, &s, 2) < 2) + return -1; + encoded_size = (Py_ssize_t)(s[0]) | ((Py_ssize_t)(s[1])<<8); + + /* read module name */ + if (_Unpickler_Read(self, &s, encoded_size) < encoded_size) + return -1; + module_name = PyUnicode_DecodeUTF8(s, encoded_size, "strict"); + if (!module_name) + return -1; + + /* read global's size */ + if (_Unpickler_Read(self, &s, 2) < 2) + return -1; + encoded_size = (Py_ssize_t)(s[0]) | ((Py_ssize_t)(s[1])<<8); + + /* read global name */ + if (_Unpickler_Read(self, &s, encoded_size) < encoded_size) { + Py_DECREF(module_name); + return -1; + } + global_name = PyUnicode_DecodeUTF8(s, encoded_size, "strict"); + + if (global_name) { + global = find_class(self, module_name, global_name); + Py_DECREF(global_name); + } + + Py_DECREF(module_name); + + if (global) { + PDATA_PUSH(self->stack, global, -1); + return 0; + } + return -1; +} + +static int load_global(UnpicklerObject *self) { PyObject *global = NULL; @@ -5645,6 +6152,8 @@ OP(INST, load_inst) OP(NEWOBJ, load_newobj) OP(GLOBAL, load_global) + OP(BINGLOBAL, load_binglobal) + OP(BINGLOBAL_BIG, load_binglobal_big) OP(APPEND, load_append) OP(APPENDS, load_appends) OP(BUILD, load_build) @@ -5814,11 +6323,15 @@ module = PyImport_Import(module_name); if (module == NULL) return NULL; + if (self->proto < 4) global = PyObject_GetAttr(module, global_name); + else global = getattr_recurse(module, global_name); + Py_DECREF(module); + } + else if (self->proto < 4) { global = PyObject_GetAttr(module, global_name); - Py_DECREF(module); } else { - global = PyObject_GetAttr(module, global_name); + global = getattr_recurse(module, global_name); } return global; } From report at bugs.python.org Sat May 11 04:57:58 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 May 2013 02:57:58 +0000 Subject: [issue16694] Add pure Python operator module In-Reply-To: <1355642681.84.0.519392654153.issue16694@psf.upfronthosting.co.za> Message-ID: <3b6tJP67gVzRGm@mail.python.org> Roundup Robot added the comment: New changeset 4b3238923b01 by Raymond Hettinger in branch 'default': Issue #16694: Add source code link for operator.py http://hg.python.org/cpython/rev/4b3238923b01 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 04:59:26 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 11 May 2013 02:59:26 +0000 Subject: [issue17941] namedtuple should support fully qualified name for more portable pickling In-Reply-To: <1368071216.78.0.0822877752405.issue17941@psf.upfronthosting.co.za> Message-ID: <1368241166.91.0.472996066141.issue17941@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 05:03:35 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 11 May 2013 03:03:35 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368241415.14.0.341369098099.issue17947@psf.upfronthosting.co.za> Eli Bendersky added the comment: By the way, if anyone is willing to take on the documentation, that could be of great help. It shouldn't be very hard since PEP 435 is extremely detailed. The stdlib .rst doc would be the descriptions from PEP 435 plus a reference of the exposed classes which is pretty minimal. We'll need the documentation patch available by the time the code is done reviewing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 05:08:25 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 11 May 2013 03:08:25 +0000 Subject: [issue1551113] random.choice(setinstance) fails Message-ID: <1368241705.79.0.152431925488.issue1551113@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Sorry, this is still rejected for the reasons that Tim mentioned. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 05:09:06 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 11 May 2013 03:09:06 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368241746.54.0.0191259394505.issue17947@psf.upfronthosting.co.za> Nick Coghlan added the comment: Two requests: 1. Lose the frame hack. With the explicit "module=__name__" API available, the implicit fragile magic isn't necessary and leads to Enum instances that may or may not support pickling depending on the implementation. Better to say "if you use the functional API without passing the module name, your Enum instances won't support pickling". 2. Mike Bayer (SQL Alchemy author) has requested the ability to derive a custom metaclass that turns off the Enums-with-members-are-final subclassing restriction (relaxing the rule that members of an enum are instances of that enum to "members of an enum are instances of that enum, or one of its parent enums", but otherwise keeping the same behaviour as the standard enums). Barry would probably appreciate this capability, too ;) We don't need to explicitly support this for the initial patch (besides, as I read the current code, you can get something like this already just by overriding EnumMeta._get_mixins), but we may want to revisit it as a supported subclassing API at some point in the future. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 05:10:51 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 11 May 2013 03:10:51 +0000 Subject: [issue12535] Chained tracebacks are confusing because the first traceback is minimal In-Reply-To: <1310405583.64.0.419150537523.issue12535@psf.upfronthosting.co.za> Message-ID: <1368241851.24.0.196036101066.issue12535@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 05:26:11 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 11 May 2013 03:26:11 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368241746.54.0.0191259394505.issue17947@psf.upfronthosting.co.za> Message-ID: Eli Bendersky added the comment: On Fri, May 10, 2013 at 8:09 PM, Nick Coghlan wrote: > > Nick Coghlan added the comment: > > Two requests: > > 1. Lose the frame hack. With the explicit "module=__name__" API available, > the implicit fragile magic isn't necessary and leads to Enum instances that > may or may not support pickling depending on the implementation. Better to > say "if you use the functional API without passing the module name, your > Enum instances won't support pickling". > > Strong -1 from me on this. The PEP has been accepted. Feel free to raise this for discussion if you want to change the decision. With all due respect to IronPython, most users can write simpler code and have pickling work just fine. _______ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 05:28:32 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 11 May 2013 03:28:32 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368241746.54.0.0191259394505.issue17947@psf.upfronthosting.co.za> Message-ID: Eli Bendersky added the comment: > 2. Mike Bayer (SQL Alchemy author) has requested the ability to derive a > custom metaclass that turns off the Enums-with-members-are-final > subclassing restriction (relaxing the rule that members of an enum are > instances of that enum to "members of an enum are instances of that enum, > or one of its parent enums", but otherwise keeping the same behaviour as > the standard enums). > Nick, after you read the whole code, please consider whether it's not already complex enough even without catering to every other need out there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 06:25:39 2013 From: report at bugs.python.org (Ben Hoyt) Date: Sat, 11 May 2013 04:25:39 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1299320278.86.0.403600489598.issue11406@psf.upfronthosting.co.za> Message-ID: <1368246339.82.0.0265290417638.issue11406@psf.upfronthosting.co.za> Ben Hoyt added the comment: > Please bring this up on python-dev. Good idea. Thread started: http://mail.python.org/pipermail/python-dev/2013-May/126119.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 08:38:18 2013 From: report at bugs.python.org (Phil Connell) Date: Sat, 11 May 2013 06:38:18 +0000 Subject: [issue17908] Unittest runner needs an option to call gc.collect() after each test In-Reply-To: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za> Message-ID: <1368254298.5.0.259849168879.issue17908@psf.upfronthosting.co.za> Changes by Phil Connell : ---------- nosy: +pconnell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 08:51:28 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 11 May 2013 06:51:28 +0000 Subject: [issue17930] Search not needed in combinations_with_replacement In-Reply-To: <1367962723.84.0.508821715816.issue17930@psf.upfronthosting.co.za> Message-ID: <1368255088.52.0.361691361921.issue17930@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks Tim :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 08:52:40 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 11 May 2013 06:52:40 +0000 Subject: [issue17920] Documentation: "complete ordering" should be "total ordering" In-Reply-To: <1367871771.49.0.425606433106.issue17920@psf.upfronthosting.co.za> Message-ID: <1368255160.89.0.815126503908.issue17920@psf.upfronthosting.co.za> Raymond Hettinger added the comment: It can be closed now. Thanks for the reminder. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 09:23:44 2013 From: report at bugs.python.org (Glenn Linderman) Date: Sat, 11 May 2013 07:23:44 +0000 Subject: [issue14191] argparse doesn't allow optionals within positionals In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za> Message-ID: <1368257024.35.0.829212688566.issue14191@psf.upfronthosting.co.za> Glenn Linderman added the comment: OK, I've been running with the new code most the day, and it seems functional in my testing. I only "sort of" follow your discussion about the "custom action class" caveat, probably because I haven't used "custom action classes"... I tried once, but failed to achieve my goal, as it was more ambitious than they presently support. If the [] value is significantly problematical in some manner, could positional nargs be set to a sentinal value that would avoid the assignment of the [] value? I realize that would require code changes in some other function or functions, in addition to the added new functions, so that would make the patch a bit more intrusive. If _fallback helps some folks with understanding errors clearly, I won't object to it. I guess it would only be programmers that would be confused, because they would be the ones interpreting the errors... and with adequate testing, should fix the programming errors before the users get a chance to be confused. So maybe your next .patch will be ready to ship! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 09:45:52 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sat, 11 May 2013 07:45:52 +0000 Subject: [issue17952] setup#editors-and-tools Message-ID: <1368258352.41.0.175036203954.issue17952@psf.upfronthosting.co.za> New submission from Tshepang Lekhonkhobe: 2nd paragraph of http://docs.python.org/devguide/setup#editors-and-tools does not look accurate. It implies that there would be some mention of text editor in the given link, but I could not find it. ---------- components: Devguide messages: 188900 nosy: ezio.melotti, tshepang priority: normal severity: normal status: open title: setup#editors-and-tools _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 09:46:30 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sat, 11 May 2013 07:46:30 +0000 Subject: [issue17952] editors-and-tools section of devguide does not appear to be ccurate In-Reply-To: <1368258352.41.0.175036203954.issue17952@psf.upfronthosting.co.za> Message-ID: <1368258390.09.0.404660478749.issue17952@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- title: setup#editors-and-tools -> editors-and-tools section of devguide does not appear to be ccurate _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 10:23:33 2013 From: report at bugs.python.org (ProgVal) Date: Sat, 11 May 2013 08:23:33 +0000 Subject: [issue17953] sys.modules cannot be reassigned Message-ID: <1368260613.85.0.746522318662.issue17953@psf.upfronthosting.co.za> New submission from ProgVal: In Python 3.3 (I did not test with 3.4), sys.modules cannot be reassigned without breaking the import mechanism; while it works with Python <= 3.2. Here is how to reproduce the bug: progval at Andromede:/tmp$ mkdir test_imports progval at Andromede:/tmp$ echo "from . import module" > test_imports/__init__.py progval at Andromede:/tmp$ echo "print('foo')" > test_imports/module.py progval at Andromede:/tmp$ python3.3 Python 3.3.1 (default, Apr 6 2013, 13:58:40) [GCC 4.7.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.modules = dict(sys.modules) >>> import test_imports Traceback (most recent call last): File "", line 1, in File "./test_imports/__init__.py", line 1, in from . import module SystemError: Parent module 'test_imports' not loaded, cannot perform relative import >>> progval at Andromede:/tmp$ python3.2 Python 3.2.3 (default, May 6 2013, 01:46:35) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.modules = dict(sys.modules) >>> import test_imports foo >>> ---------- components: Interpreter Core messages: 188901 nosy: Valentin.Lorentz priority: normal severity: normal status: open title: sys.modules cannot be reassigned type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 12:20:37 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sat, 11 May 2013 10:20:37 +0000 Subject: [issue17940] extra code in argparse.py In-Reply-To: <1368052350.83.0.843381398629.issue17940@psf.upfronthosting.co.za> Message-ID: <1368267637.55.0.150629392119.issue17940@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: Removed the duplicated code from argparse.py ---------- keywords: +patch nosy: +Yogesh.Chaudhari Added file: http://bugs.python.org/file30214/issue17940.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 12:26:23 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sat, 11 May 2013 10:26:23 +0000 Subject: [issue17940] extra code in argparse.py In-Reply-To: <1368052350.83.0.843381398629.issue17940@psf.upfronthosting.co.za> Message-ID: <1368267983.64.0.479729223971.issue17940@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: Remove extra code in argparse.py for 2.7 branch ---------- hgrepos: +190 Added file: http://bugs.python.org/file30215/issue17940-27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 12:27:54 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sat, 11 May 2013 10:27:54 +0000 Subject: [issue17940] extra code in argparse.py In-Reply-To: <1368052350.83.0.843381398629.issue17940@psf.upfronthosting.co.za> Message-ID: <1368268074.02.0.427707747823.issue17940@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: I have added a patch for default branch as well, because IMO the same issue exists in all branches ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 13:12:04 2013 From: report at bugs.python.org (Stefan Mihaila) Date: Sat, 11 May 2013 11:12:04 +0000 Subject: [issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila In-Reply-To: <1344890920.23.0.695633734046.issue15642@psf.upfronthosting.co.za> Message-ID: <1368270724.03.0.590367898348.issue15642@psf.upfronthosting.co.za> Changes by Stefan Mihaila : Added file: http://bugs.python.org/file30216/d0c3a8d4947a.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 13:34:24 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sat, 11 May 2013 11:34:24 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368272064.98.0.898946722771.issue17914@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: Based on the conversation and the particular inputs to the thread form neologix and ezio, I would like to submit this patch. It probably needs modification(s) as I am not sure what to do with the implementation that is already present in multiprocessing. This patch simply calls the os.cpu_count() from multiprocessing now and behaves as it would have previously. The test cases are also added to test_os similar to ones from multiprocessing. ---------- components: +2to3 (2.x to 3.x conversion tool) keywords: +patch nosy: +Yogesh.Chaudhari Added file: http://bugs.python.org/file30217/issue17914.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 13:50:08 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 11 May 2013 11:50:08 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1368272064.98.0.898946722771.issue17914@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Based on the conversation and the particular inputs to the thread form neologix and ezio, I would like to submit this patch. > > It probably needs modification(s) as I am not sure what to do with the implementation that is already present in multiprocessing. This patch simply calls the os.cpu_count() from multiprocessing now and behaves as it would have previously. Thanks, but it would be better to reuse Trent's C implementation instead of multiprocessing's: http://hg.python.org/sandbox/trent/file/dd1c2fd3aa31/Modules/posixmodule.c#l10213 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 13:51:08 2013 From: report at bugs.python.org (Ned Batchelder) Date: Sat, 11 May 2013 11:51:08 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368273068.56.0.258290775858.issue17914@psf.upfronthosting.co.za> Ned Batchelder added the comment: A few small points: Use `num is None` instead of `num == None`. Use `isinstance(cpus, int)` rather than `type(cpus) is int`. And this I think will throw an exception in Python 3: `cpus >= 1 or cpus == None`, because you can't compare None to 1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 14:00:19 2013 From: report at bugs.python.org (Gregory HOULDSWORTH) Date: Sat, 11 May 2013 12:00:19 +0000 Subject: [issue17945] tkinter/Python 3.3.0: peer_create doesn't instantiate Text In-Reply-To: <1368110182.39.0.238603513669.issue17945@psf.upfronthosting.co.za> Message-ID: <1368273619.59.0.043028469061.issue17945@psf.upfronthosting.co.za> Gregory HOULDSWORTH added the comment: Noted: I assumed 'works for me' meant user approval of proposed fix, pending 'official' sanction. Didn't catch the BNF-like syntax for issue linking, hence the literal <>'s in my original post. Thank you for clarifying those. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 14:13:54 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 May 2013 12:13:54 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368274434.78.0.652963479501.issue17914@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think the idiom `os.cpu_count() or 1` should be mentioned in the documentation an officially recommended. Otherwise people will produce a non-portable code which works on their developer's computers but not on exotic platforms. I have added some other comments on Rietveld. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 14:17:18 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 May 2013 12:17:18 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368274638.09.0.6423683049.issue17914@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I agree with Charles-Fran?ois. An approach using C library functions is far superior to launching external commands. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 14:17:49 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 May 2013 12:17:49 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1299320278.86.0.403600489598.issue11406@psf.upfronthosting.co.za> Message-ID: <1368274669.93.0.367649084032.issue11406@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: -serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 14:24:49 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 11 May 2013 12:24:49 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1368274434.78.0.652963479501.issue17914@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > I think the idiom `os.cpu_count() or 1` should be mentioned in the documentation an officially recommended. Otherwise people will produce a non-portable code which works on their developer's computers but not on exotic platforms. And I maintain it's an ugly idiom ;-) Since the user can't do anything except falling back to 1, os.cpu_count() should always return a positive number (1 by default). That's AFAICT what all other platforms (Java, Ruby, etc) do, because it makes sense. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 14:26:33 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 May 2013 12:26:33 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: Message-ID: <1368275190.2537.1.camel@fsol> Antoine Pitrou added the comment: > And I maintain it's an ugly idiom ;-) > Since the user can't do anything except falling back to 1, > os.cpu_count() should always return a positive number (1 by default). The user can also raise an error. For example, if I'm writing a benchmark to measure per-core scaling performance, I would like to bail out if I can't calculate the number of cores (rather than report incorrect results). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 14:30:14 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 May 2013 12:30:14 +0000 Subject: [issue17905] Add check for locale.h In-Reply-To: <1367676553.24.0.0475219885835.issue17905@psf.upfronthosting.co.za> Message-ID: <1368275414.33.0.151204947994.issue17905@psf.upfronthosting.co.za> Antoine Pitrou added the comment: There are more places where including locale.h is guarded by HAVE_LANGINFO_H. Also, there are places where including locale.h isn't guarded by anything (such as Python/formatter_unicode.c), so I don't think we need the new configure check. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 14:32:05 2013 From: report at bugs.python.org (Christian Heimes) Date: Sat, 11 May 2013 12:32:05 +0000 Subject: [issue17953] sys.modules cannot be reassigned In-Reply-To: <1368260613.85.0.746522318662.issue17953@psf.upfronthosting.co.za> Message-ID: <1368275525.24.0.839380542269.issue17953@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- assignee: -> brett.cannon keywords: +3.3regression nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 14:34:34 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 May 2013 12:34:34 +0000 Subject: [issue17953] sys.modules cannot be reassigned In-Reply-To: <1368260613.85.0.746522318662.issue17953@psf.upfronthosting.co.za> Message-ID: <1368275674.89.0.236352470025.issue17953@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I wouldn't call it a bug personally. The modules dictionary is used in all kinds of places in the interpreter; you can change the dictionary's contents, but not swap it with another one. It's just a pity that we can't forbid reassignment altogether. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 14:55:21 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 May 2013 12:55:21 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za> Message-ID: <1368276921.12.0.580547586562.issue17237@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: PyASCIIObject is allocated on heap and should have a maximal alignment enough for every type. If sizeof(PyASCIIObject) % SIZEOF_LONG == 0 then dest is at least long-aligned. Currently sizeof(PyASCIIObject) is 22 on m68k and the optimization is switched off at compile time. When PyASCIIObject will grow to 24 bytes the optimization will switched on and perhaps will have some effect. I prefer checks for features instead of concrete names. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 14:58:28 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 May 2013 12:58:28 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: <1368276921.12.0.580547586562.issue17237@psf.upfronthosting.co.za> Message-ID: <1368277106.2537.4.camel@fsol> Antoine Pitrou added the comment: > PyASCIIObject is allocated on heap and should have a maximal alignment > enough for every type. If sizeof(PyASCIIObject) % SIZEOF_LONG == 0 > then dest is at least long-aligned. Currently sizeof(PyASCIIObject) is > 22 on m68k and the optimization is switched off at compile time. When > PyASCIIObject will grow to 24 bytes the optimization will switched on > and perhaps will have some effect. I prefer checks for features > instead of concrete names. This is a bugfix, please let's keep it simple. Checking for __m68k__ ensures that other architectures aren't affected by mistake. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 15:08:16 2013 From: report at bugs.python.org (mirabilos) Date: Sat, 11 May 2013 13:08:16 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za> Message-ID: <1368277696.13.0.730956817685.issue17237@psf.upfronthosting.co.za> mirabilos added the comment: Right, keeping it simple helps in preventing accidents, and the code block looks full of magic enough as-is. Maybe add a comment block that says: /* * m68k is a bit different from most architectures in that objects * do not use "natural alignment" - for example, int and long are * only aligned at 2-byte boundaries. Tests have shown that skipping * the "optimised version" will even speed up m68k, so we #ifdef * for "the odd duck out" here. */ Then we have an in-situ documentation point for why that ifdef is there and why m68k is ?the odd duck? and this whitelist method is used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 15:10:34 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 May 2013 13:10:34 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368277834.27.0.160923591645.issue17914@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Since the user can't do anything except falling back to 1, > os.cpu_count() should always return a positive number (1 by default). In general I agree with you. Actually the os module should contains two functions: cpu_count() which fallbacks to 1 and is_cpu_counting_supported() for rare need. But this looks even more ugly and I choose single function even if in most cases I need use strange idiom. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 15:23:23 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 May 2013 13:23:23 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za> Message-ID: <1368278603.85.0.955962201707.issue17237@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Well, then already too much bikeshedding for such simple fix. Antoine, do you want to commit a fix? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 15:55:34 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 11 May 2013 13:55:34 +0000 Subject: [issue17954] Support creation of extensible enums through metaclass subclassing Message-ID: <1368280534.51.0.41696456409.issue17954@psf.upfronthosting.co.za> New submission from Nick Coghlan: Guido chose to follow Java in enforcing the invariant "Enum members are instances of that Enum" for PEP 435 (i.e. "assert (all(isinstance(x, SomeEnum) for x in SomeEnum)"). As a consequence, the Enum metaclass prevents subclassing of Enums with defined members. This is a reasonable design choice, but one that limits the applicability of the standard library enum solution for use cases that currently rely on this feature of a custom enum implementation (including flufl.enum, the original inspiration for this feature). An alternative reasonable design choice is to allow extension of enumerations (similar to flufl.enum) and relax the invariant to "Enum members are an instance of that Enum or an Enum-derived parent class of that Enum" (i.e. "assert (all(issubclass(type(x), Enum) and type(x) in SomeEnum.mro() for x in SomeEnum)") There is no need to support this directly in the standard library, but it would be valuable to make it straightforward to support in an Enum variant by subclassing the standard metaclass (similar to the customisation mechanisms provided to support things like autonumbered enums through a derived metaclass). Currently, implementing this behaviour involves overriding a private method of the metaclass (EnumMetaclass._get_mixins) ---------- messages: 188920 nosy: ncoghlan priority: low severity: normal stage: needs patch status: open title: Support creation of extensible enums through metaclass subclassing type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 15:55:45 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 11 May 2013 13:55:45 +0000 Subject: [issue17954] Support creation of extensible enums through metaclass subclassing In-Reply-To: <1368280534.51.0.41696456409.issue17954@psf.upfronthosting.co.za> Message-ID: <1368280545.46.0.604895012539.issue17954@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- dependencies: +Code, test, and doc review for PEP-0435 Enum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 15:58:44 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 11 May 2013 13:58:44 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368280724.65.0.936927151551.issue17947@psf.upfronthosting.co.za> Nick Coghlan added the comment: The accepted PEP states that the frame hack should be removed: "To support pickling of these enums, the module name can be specified using the module keyword-only argument." Ergo, if you don't specify it, they cannot be pickled. Explicit is better than implicit, and this hack should not propagate beyond namedtuple (it should actually be deprecated in namedtuple as well). As far as the second point goes, I had already reviewed the PEP implementation before making the comment (that's why I am reasonably sure you can already do it just by overriding _get_mixins). I see it as similar to the changes that were already made to support autonumbered subtypes. However, also note that I said we should wait before doing anything about providing a supported mechanism for that customisation. I've now created issue 17954 to cover a possible refactoring and documentation of that part of the implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 15:59:51 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 May 2013 13:59:51 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za> Message-ID: <3b79064wPbzSsc@mail.python.org> Roundup Robot added the comment: New changeset 0f8022ac88ad by Antoine Pitrou in branch '3.3': Issue #17237: Fix crash in the ASCII decoder on m68k. http://hg.python.org/cpython/rev/0f8022ac88ad New changeset 201ae2d02328 by Antoine Pitrou in branch 'default': Issue #17237: Fix crash in the ASCII decoder on m68k. http://hg.python.org/cpython/rev/201ae2d02328 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 16:19:13 2013 From: report at bugs.python.org (Ramchandra Apte) Date: Sat, 11 May 2013 14:19:13 +0000 Subject: [issue17952] editors-and-tools section of devguide does not appear to be accurate In-Reply-To: <1368258352.41.0.175036203954.issue17952@psf.upfronthosting.co.za> Message-ID: <1368281953.88.0.0665145315315.issue17952@psf.upfronthosting.co.za> Changes by Ramchandra Apte : ---------- title: editors-and-tools section of devguide does not appear to be ccurate -> editors-and-tools section of devguide does not appear to be accurate _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 16:19:13 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 May 2013 14:19:13 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za> Message-ID: <1368281953.93.0.650365428879.issue17237@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, I hope I got the fix right :) Thanks mirabilos for the comment suggestion, I used a modified version. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 16:32:32 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sat, 11 May 2013 14:32:32 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368028726.5.0.833825784859.issue17936@psf.upfronthosting.co.za> Message-ID: <1368282752.2.0.965787769989.issue17936@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: It turned out to be slightly more compilcated. Two additions make this complete: 1) check for the subtype OR the Py_None when removing subclass. This removes any dependency on the order in which weakrefs are cleared. 2) When the type is cleared, manually remove ourselves from all the base classes. It is because of the lack of 2) that the original version was always clearing out all stale weakrefs when new subclasses were added. ---------- Added file: http://bugs.python.org/file30218/subtype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 16:32:47 2013 From: report at bugs.python.org (mirabilos) Date: Sat, 11 May 2013 14:32:47 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: <1361284308.62.0.1198849813.issue17237@psf.upfronthosting.co.za> Message-ID: <1368282767.76.0.265780716877.issue17237@psf.upfronthosting.co.za> mirabilos added the comment: Thanks Antoine! Now, for ?finishing up? this? to follow up on Stefan?s comment? is there any way I can run the testsuite from an installed Python (from the Debian packages)? (I build the packages with disabled testsuite, to get the rest of the system running again, since python3.3 was recently made required and we had never built it before.) Otherwise I guess I could run ?make test? on one of the earlier trees I used for the timing? but that machine is currently building six Linux kernel flavours from the src:linux package and thus will not be available for the next one and a half week or so? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 16:38:48 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 May 2013 14:38:48 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: <1368282767.76.0.265780716877.issue17237@psf.upfronthosting.co.za> Message-ID: <1368283122.2537.6.camel@fsol> Antoine Pitrou added the comment: > Now, for ?finishing up? this? to follow up on Stefan?s comment? is > there any way I can run the testsuite from an installed Python (from > the Debian packages)? "python -m test" (with any options you might like), but we don't guarantee that all tests pass on an installed Python. But at least you will be able to spot any hard crashes :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 16:57:31 2013 From: report at bugs.python.org (mirabilos) Date: Sat, 11 May 2013 14:57:31 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: <1368283122.2537.6.camel@fsol> Message-ID: mirabilos added the comment: Antoine Pitrou dixit: >"python -m test" (with any options you might like), but we don't No, I tried that (as it was the only thing I could find on the ?net as well) on an i386 system and only get: tglase at tglase:~ $ python2.7 -m test /usr/bin/python2.7: No module named test.__main__; 'test' is a package and cannot be directly executed 1|tglase at tglase:~ $ python3.2 -m test /usr/bin/python3.2: No module named test.__main__; 'test' is a package and cannot be directly executed Same when adding ?-h?. bye, //mirabilos -- Gast: ?Ein Bier, bitte!? Wirt: ?Geht auch alkoholfrei?? Gast: ?Geht auch Spielgeld?? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 17:00:41 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 May 2013 15:00:41 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: Message-ID: <1368284439.2537.7.camel@fsol> Antoine Pitrou added the comment: > >"python -m test" (with any options you might like), but we don't > > No, I tried that (as it was the only thing I could find on the > ?net as well) on an i386 system and only get: Ah, that's because the system Python install doesn't include the test suite. Perhaps you have to install an additional package, python-dev perhaps? (note, on 2.7, it's "python -m test.regrtest") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 17:06:42 2013 From: report at bugs.python.org (Brian Curtin) Date: Sat, 11 May 2013 15:06:42 +0000 Subject: [issue11406] There is no os.listdir() equivalent returning generator instead of list In-Reply-To: <1299320278.86.0.403600489598.issue11406@psf.upfronthosting.co.za> Message-ID: <1368284802.85.0.90220364516.issue11406@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- nosy: -brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 17:13:52 2013 From: report at bugs.python.org (mirabilos) Date: Sat, 11 May 2013 15:13:52 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: <1368284439.2537.7.camel@fsol> Message-ID: mirabilos added the comment: Antoine Pitrou dixit: >(note, on 2.7, it's "python -m test.regrtest") That indeed does things. So I had mistaken them for the same problem. >Ah, that's because the system Python install doesn't include the test >suite. Perhaps you have to install an additional package, python-dev >perhaps? tglase at tglase:~ $ l /usr/lib/python2.7/test/ __init__.py pystone.py* regrtest.py* test_support.py __init__.pyc pystone.pyc regrtest.pyc test_support.pyc tglase at tglase:~ $ l /usr/lib/python3.2/test/ __init__.py __pycache__/ pystone.py* regrtest.py* support.py Maybe it?s just not packaged? these are all I can find, and installing python3.2-dev doesn?t fix it. Oh well, then it?ll just have to wait. Do you have a preferred place where I can submit the test results, as it?s getting very off-topic here? bye, //mirabilos -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 17:16:06 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 May 2013 15:16:06 +0000 Subject: [issue17237] m68k aligns on 16bit boundaries. In-Reply-To: Message-ID: <1368285362.2537.8.camel@fsol> Antoine Pitrou added the comment: > Oh well, then it?ll just have to wait. Do you have a preferred > place where I can submit the test results, as it?s getting > very off-topic here? Well, if everything works fine, you don't have to submit them! If you get test failures, you can open issues for the individual test failures. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 17:59:22 2013 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 11 May 2013 15:59:22 +0000 Subject: [issue17955] Minor updates to Functional HOWTO Message-ID: <1368287962.52.0.951274382256.issue17955@psf.upfronthosting.co.za> New submission from A.M. Kuchling: I read through the 3.x Functional HOWTO, and it only seems to require a few minor updates. The attached patch: * adds a forward link to skip the theoretical discussion in the first section. * remove stray extra comma * clarify what filterfalse() is the opposite of. * (more significant) Describe compress(), the combinatoric functions in their own section, and accumulate(). ---------- assignee: docs at python components: Documentation files: functional.txt messages: 188931 nosy: akuchling, docs at python priority: low severity: normal stage: patch review status: open title: Minor updates to Functional HOWTO type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file30219/functional.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 18:34:23 2013 From: report at bugs.python.org (Guilherme Polo) Date: Sat, 11 May 2013 16:34:23 +0000 Subject: [issue17945] tkinter/Python 3.3.0: peer_create doesn't instantiate Text In-Reply-To: <1368273619.59.0.043028469061.issue17945@psf.upfronthosting.co.za> Message-ID: Guilherme Polo added the comment: If someone decides to commit this, please check that the name of the widget in Tcl is always adequate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 19:10:42 2013 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 11 May 2013 17:10:42 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368292242.21.0.755004457231.issue17947@psf.upfronthosting.co.za> Guido van Rossum added the comment: Sorry everyone, the frame hack needs to stay. This is not negotiable. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 19:30:08 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sat, 11 May 2013 17:30:08 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368293408.93.0.00106378365132.issue17914@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: Appreciate everyone's feedback. I have modified the patch based on further messages in the thread. @Neologix modified posixmodule according to one in Trent's branch and used that for cpu_count(). Kindly suggest improvements/changes if any. @Ned: Thanks for the suggestions. I have applied them wherever applicable. However regarding "And this I think will throw an exception in Python 3: `cpus >= 1 or cpus == None`, because you can't compare None to 1." It does not throw any exceptions as of now. ---------- Added file: http://bugs.python.org/file30220/issue17914-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 19:45:43 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 11 May 2013 17:45:43 +0000 Subject: [issue17956] add ScheduledExecutor Message-ID: <1368294342.98.0.976753460934.issue17956@psf.upfronthosting.co.za> New submission from Charles-Fran?ois Natali: Here's an implementation of a new ScheduledExecutor abstract class, with a concrete ScheduledThreadPoolExecutor implementation (see #995907). The aim is to provide a flexible, efficient and consistent framework for delayed and periodic tasks, leveraging on futures. Incidentally, this supersedes threading.Timer, which is quite fragile and inefficient. Here's a patch with test (I didn't write the documentation, I prefer to have some feedback first :-), the API is complete. There's one thing that bothers me with the current implementation: when a future is cancelled, like for regular ThreadPoolExecutor, it doesn't get removed from the work queue right away, but only when it gets dequeued. For a delayed future, this means that one has to wait for the next scheduled execution (i.e. worst case + future.period) for it to be effectively cancelled and removed from the queue, and for the executor to be shutdown. I'm considering using a callback (Future.add_done_callback()), that's kind of hackish but I don't see any other way. ---------- components: Library (Lib) files: scheduled-1.diff keywords: needs review, patch messages: 188935 nosy: neologix, pitrou, r.david.murray priority: normal severity: normal stage: patch review status: open title: add ScheduledExecutor type: enhancement Added file: http://bugs.python.org/file30221/scheduled-1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 19:46:49 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 11 May 2013 17:46:49 +0000 Subject: [issue995907] memory leak with threads and enhancement of the timer class Message-ID: <1368294409.77.0.201930889966.issue995907@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: OK, I just created #17956 for ScheduledExecutor, closing this one. ---------- resolution: -> duplicate stage: test needed -> committed/rejected status: open -> closed superseder: -> add ScheduledExecutor _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 20:03:14 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 May 2013 18:03:14 +0000 Subject: [issue17547] "checking whether gcc supports ParseTuple __format__... " erroneously returns yes with gcc 4.8 In-Reply-To: <1364240036.0.0.495843553762.issue17547@psf.upfronthosting.co.za> Message-ID: <3b7GNx1d94zRvB@mail.python.org> Roundup Robot added the comment: New changeset 9d50af4c482f by Benjamin Peterson in branch '2.7': -Wformat is needed by gcc 4.8 (closes #17547) http://hg.python.org/cpython/rev/9d50af4c482f New changeset 94a7475d3a5f by Benjamin Peterson in branch '3.3': -Wformat is needed by gcc 4.8 (closes #17547) http://hg.python.org/cpython/rev/94a7475d3a5f New changeset f12e3ce66ae6 by Benjamin Peterson in branch 'default': merge 3.3 (#17547) http://hg.python.org/cpython/rev/f12e3ce66ae6 ---------- nosy: +python-dev resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 20:04:28 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 May 2013 18:04:28 +0000 Subject: [issue17956] add ScheduledExecutor In-Reply-To: <1368294342.98.0.976753460934.issue17956@psf.upfronthosting.co.za> Message-ID: <1368295468.81.0.631322243813.issue17956@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +bquinlan, gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 20:05:08 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 11 May 2013 18:05:08 +0000 Subject: [issue17547] "checking whether gcc supports ParseTuple __format__... " erroneously returns yes with gcc 4.8 In-Reply-To: <1364240036.0.0.495843553762.issue17547@psf.upfronthosting.co.za> Message-ID: <1368295508.29.0.11710712777.issue17547@psf.upfronthosting.co.za> Benjamin Peterson added the comment: We really ought to just scrap that configure test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 20:12:08 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 11 May 2013 18:12:08 +0000 Subject: [issue17955] Minor updates to Functional HOWTO In-Reply-To: <1368287962.52.0.951274382256.issue17955@psf.upfronthosting.co.za> Message-ID: <1368295928.09.0.00367938903712.issue17955@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 20:23:33 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 May 2013 18:23:33 +0000 Subject: [issue17937] Collect garbage harder at shutdown In-Reply-To: <1368047666.23.0.340381721586.issue17937@psf.upfronthosting.co.za> Message-ID: <1368296612.99.0.73141949459.issue17937@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I was asked what this patch did exactly: it simply calls the garbage collector one last time after sys.modules has been cleared. I don't know it it makes much of a difference, but it may limit the amount of leaking when doing successive Py_Initialize/Py_Finalize calls. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 20:34:36 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 11 May 2013 18:34:36 +0000 Subject: [issue17956] add ScheduledExecutor In-Reply-To: <1368294342.98.0.976753460934.issue17956@psf.upfronthosting.co.za> Message-ID: <1368297276.91.0.599773855007.issue17956@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Added file: http://bugs.python.org/file30222/scheduled-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 20:36:26 2013 From: report at bugs.python.org (Antonio Cavallo) Date: Sat, 11 May 2013 18:36:26 +0000 Subject: [issue17905] Add check for locale.h In-Reply-To: <1367676553.24.0.0475219885835.issue17905@psf.upfronthosting.co.za> Message-ID: <1368297386.1.0.860936722762.issue17905@psf.upfronthosting.co.za> Antonio Cavallo added the comment: I see, in that case wouldn't make more sense completely remove the check for the langinfo.h either? I think is better to close the issue to keep the noise low. Thanks ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 20:38:20 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 11 May 2013 18:38:20 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368297500.93.0.937180949293.issue17947@psf.upfronthosting.co.za> Nick Coghlan added the comment: Why we need two ways to do it? If "module=__name__" is available, what's the rationale for providing the option of leaving it out when pickling support is required? (The only times the frame hack will work to enable pickling, the explicit fix will also work). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 20:38:25 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 May 2013 18:38:25 +0000 Subject: [issue17905] Add check for locale.h In-Reply-To: <1367676553.24.0.0475219885835.issue17905@psf.upfronthosting.co.za> Message-ID: <1368297505.28.0.113435078987.issue17905@psf.upfronthosting.co.za> Antoine Pitrou added the comment: You might have misunderstood me. Since locale.h appears to exist on all systems (including Android) there's no need to add a check for it in configure. On the other hand, it is correct to fix the existing guards like your patch proposes to do, except that there appears to be more places to fix. I'm reopening the issue. ---------- resolution: works for me -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 20:38:51 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 May 2013 18:38:51 +0000 Subject: [issue17956] add ScheduledExecutor In-Reply-To: <1368294342.98.0.976753460934.issue17956@psf.upfronthosting.co.za> Message-ID: <1368297531.09.0.324887674376.issue17956@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It will be good to be compatible with sched.scheduler. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 20:44:37 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 May 2013 18:44:37 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368297877.44.0.905036420383.issue17914@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yogesh, didn't you notice comments on Rietveld? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 20:53:41 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 11 May 2013 18:53:41 +0000 Subject: [issue17953] sys.modules cannot be reassigned In-Reply-To: <1368260613.85.0.746522318662.issue17953@psf.upfronthosting.co.za> Message-ID: <1368298421.94.0.993447512503.issue17953@psf.upfronthosting.co.za> Brett Cannon added the comment: There is no good way to solve this. At the C level there interpreter struct has two key fields, sysdict and modules. The former is sys.__dict__ and the latter is sys.modules. But when you re-assign sys.modules you then break the assumption that sys.modules is the same dict as that contained in interp->modules. And this all goes out the window as the C code is expected to use interp->modules while the Python code in importlib only has access to sys.modules. The reason this used to "work" is your new dictionary was completely ignored and so we basically a no-op from the perspective of import (done in Python 2.7 but same result in any version up to Python 3.3):: >>> import sys >>> original_modules = sys.modules >>> new_modules = sys.modules.copy() >>> sys.modules = new_modules >>> import pkg >>> 'pkg' in original_modules True >>> 'pkg' in new_modules False What really needs to happen is that sys.modules needs to be documented as something that cannot be replaced. If you really want to update it cleanly then do ``sys.modules.clear(); sys.modules.update(new_modules)``, but even that is tricky because removing certain modules will flat-out break Python. I have updated the issue to be a documentation one and added Python 3.4 to the affected versions. ---------- components: +Documentation -Interpreter Core keywords: +easy stage: -> test needed type: behavior -> versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 21:08:39 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 May 2013 19:08:39 +0000 Subject: [issue1159051] Handle corrupted gzip files with unexpected EOF Message-ID: <3b7HrQ3Hlqz7Ljp@mail.python.org> Roundup Robot added the comment: New changeset abc780332b60 by Benjamin Peterson in branch '2.7': backout 214d8909513d for regressions (#1159051) http://hg.python.org/cpython/rev/abc780332b60 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 21:10:46 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 11 May 2013 19:10:46 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368299446.38.0.717430522814.issue17947@psf.upfronthosting.co.za> Eli Bendersky added the comment: Ethan, something is wrong with _StealthProperty. Well, two things. First, it's way too general and can be cut to just what Enum needs. Second, this is enough to make the tests pass: class _StealthProperty(): """ Returns the value in the instance, or the virtual attribute on the class. A virtual attribute is one that is looked up by __getattr__, as opposed to one that lives in __class__.__dict__ """ def __init__(self, fget): self.fget = fget def __get__(self, obj, objtype=None): return self.fget(obj) def __set__(self, obj, value): raise AttributeError("can't set attribute") def __delete__(self, obj): raise AttributeError("can't delete attribute") Now this is fishy because __get__ gets obj=None when called on a class and therefore self.fget(obj) raises an exception. But this gets caught somewhere in your code or tests and ignored. However, the right thing is still returned. I didn't have more time to investigate, but this must be cleaned out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 21:11:30 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 11 May 2013 19:11:30 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368299490.03.0.339200892123.issue17947@psf.upfronthosting.co.za> Eli Bendersky added the comment: Also, your test must run within the regrtest framework. Currently I get: ./python -mtest.regrtest test_enum [1/1] test_enum test test_enum failed -- Traceback (most recent call last): File "/home/eliben/python-src/default/Lib/test/test_enum.py", line 245, in test_pickle_enum_function_with_module self.assertIs(Question.who, loads(dumps(Question.who))) _pickle.PicklingError: Can't pickle : attribute lookup __main__.Question failed 1 test failed: test_enum ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 21:18:45 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sat, 11 May 2013 19:18:45 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368299925.67.0.847583002172.issue17914@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: @Serhiy Sorry, I missed your comments in the thread. I have made 2 changes and ignored the cpu_count() returning 0, because it returns -1 on failure, else give the number of CPUs. Also the test_os, checks for 0 return if that was to e the case. ---------- Added file: http://bugs.python.org/file30223/issue17914-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 21:20:54 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 May 2013 19:20:54 +0000 Subject: [issue17934] Add a frame method to clear expensive details In-Reply-To: <1368014042.2.0.41504275061.issue17934@psf.upfronthosting.co.za> Message-ID: <1368300054.98.0.698146297049.issue17934@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch. Guido, I would hope this may be useful to you. ---------- keywords: +patch nosy: +gvanrossum stage: needs patch -> patch review Added file: http://bugs.python.org/file30224/frame_clear.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 22:03:12 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 May 2013 20:03:12 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368302592.37.0.211445518076.issue17914@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Now we have three cpu_count() functions: multiprocessing.cpu_count() raises an exception on failure, posix.cpu_count() returns -1, and os.cpu_count() returns None. It will be easy to get rid of Python wrapper in the os module and return None directly from C code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 22:04:20 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 May 2013 20:04:20 +0000 Subject: [issue17934] Add a frame method to clear expensive details In-Reply-To: <1368014042.2.0.41504275061.issue17934@psf.upfronthosting.co.za> Message-ID: <1368302660.7.0.543366807551.issue17934@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Updated patch to avoid clearing executing frames. Note that the new f_executing member should be re-usable to compute gi_running without storing it. ---------- Added file: http://bugs.python.org/file30225/frame_clear2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 22:06:53 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 11 May 2013 20:06:53 +0000 Subject: [issue14097] Improve the "introduction" page of the tutorial In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za> Message-ID: <1368302813.38.0.627686094873.issue14097@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 22:08:30 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sat, 11 May 2013 20:08:30 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368302910.13.0.701677493962.issue17914@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: Returning None from C code sounds reasonable to me. Anyone else wants to pitch in with suggestions for/against this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 23:11:04 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 May 2013 21:11:04 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <3b7LYg3wYVz7Ljc@mail.python.org> Roundup Robot added the comment: New changeset 1b595399e070 by Benjamin Peterson in branch 'default': simplify #17947 test with weakrefs http://hg.python.org/cpython/rev/1b595399e070 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 23:24:25 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 11 May 2013 21:24:25 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368307465.83.0.944660643548.issue17947@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I copied the wrong bug number. should have been #17927. sorry ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 23:38:04 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 11 May 2013 21:38:04 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368308284.22.0.923443552262.issue17947@psf.upfronthosting.co.za> Eli Bendersky added the comment: Benjamin, I guess you can just unlink the message from the issue? [and then your clarification, and when again this message from me ;-)] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 23:38:39 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 11 May 2013 21:38:39 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1368302910.13.0.701677493962.issue17914@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Returning None from C code sounds reasonable to me. Anyone else wants to pitch in with suggestions for/against this? Go for it ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 23:41:08 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 11 May 2013 21:41:08 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368308468.82.0.127409355717.issue17947@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- Removed message: http://bugs.python.org/msg188954 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 23:41:25 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 11 May 2013 21:41:25 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368308485.29.0.309360278231.issue17947@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- Removed message: http://bugs.python.org/msg188955 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 23:41:32 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 11 May 2013 21:41:32 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368308492.27.0.543520686831.issue17947@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- Removed message: http://bugs.python.org/msg188956 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 11 23:42:16 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 11 May 2013 21:42:16 +0000 Subject: [issue17956] add ScheduledExecutor In-Reply-To: <1368297531.09.0.324887674376.issue17956@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > It will be good to be compatible with sched.scheduler. What do you mean? Actually, this would kind of supersede the sched module (except that the sched module supports custom time and delay functions). By the way, for those that didn't realize it, it's heavily inspired by Java ScheduledExecutorService interface (pretty much like Python's Executor mirrors Java's ExecutorService). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 00:02:12 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sat, 11 May 2013 22:02:12 +0000 Subject: [issue16805] when building docs on Debian 7 --> ERROR: Error in "note" directive In-Reply-To: <1356739435.76.0.304211925624.issue16805@psf.upfronthosting.co.za> Message-ID: <1368309732.89.0.161501092783.issue16805@psf.upfronthosting.co.za> Tshepang Lekhonkhobe added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 00:03:03 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 11 May 2013 22:03:03 +0000 Subject: [issue16805] when building docs on Debian 7 --> ERROR: Error in "note" directive In-Reply-To: <1356739435.76.0.304211925624.issue16805@psf.upfronthosting.co.za> Message-ID: <1368309783.5.0.917961398315.issue16805@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> patch review type: -> behavior versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 00:09:15 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sat, 11 May 2013 22:09:15 +0000 Subject: [issue15130] remove redundant paragraph in socket howto In-Reply-To: <1340311752.3.0.940656841103.issue15130@psf.upfronthosting.co.za> Message-ID: <1368310155.06.0.45166204239.issue15130@psf.upfronthosting.co.za> Tshepang Lekhonkhobe added the comment: ping ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 00:19:08 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sat, 11 May 2013 22:19:08 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368310748.47.0.928271955628.issue17914@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: Modified patch to return None from C code ---------- Added file: http://bugs.python.org/file30226/issue17914-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 00:20:43 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sat, 11 May 2013 22:20:43 +0000 Subject: [issue17957] remove outdated (and unexcellent) paragraph in whatsnew Message-ID: <1368310843.47.0.442601461472.issue17957@psf.upfronthosting.co.za> New submission from Tshepang Lekhonkhobe: The first part looks incomplete, and the second part is outdated. The whole paragraph doesn't add much value I believe, so should just go. ---------- assignee: docs at python components: Documentation files: diff messages: 188962 nosy: docs at python, tshepang priority: normal severity: normal status: open title: remove outdated (and unexcellent) paragraph in whatsnew versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30227/diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 00:24:20 2013 From: report at bugs.python.org (Ned Batchelder) Date: Sat, 11 May 2013 22:24:20 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368311060.28.0.966296654451.issue17914@psf.upfronthosting.co.za> Ned Batchelder added the comment: @Yogesh: if cpus is None, then this will raise an exception in Python 3: `cpus >= 1 or cpus == None` Perhaps you don't have enough test cases yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 00:27:28 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sat, 11 May 2013 22:27:28 +0000 Subject: [issue16805] when building docs on Debian 7 --> ERROR: Error in "note" directive In-Reply-To: <1356739435.76.0.304211925624.issue16805@psf.upfronthosting.co.za> Message-ID: <1368311248.04.0.835550366937.issue16805@psf.upfronthosting.co.za> Tshepang Lekhonkhobe added the comment: @ezio why remove 3.2 from applicable versions ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 00:29:53 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 11 May 2013 22:29:53 +0000 Subject: [issue16805] when building docs on Debian 7 --> ERROR: Error in "note" directive In-Reply-To: <1356739435.76.0.304211925624.issue16805@psf.upfronthosting.co.za> Message-ID: <1368311393.55.0.33055921146.issue16805@psf.upfronthosting.co.za> Ezio Melotti added the comment: 3.2 only gets security fixes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 00:31:57 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 11 May 2013 22:31:57 +0000 Subject: [issue17957] remove outdated (and unexcellent) paragraph in whatsnew In-Reply-To: <1368310843.47.0.442601461472.issue17957@psf.upfronthosting.co.za> Message-ID: <1368311517.49.0.796426705453.issue17957@psf.upfronthosting.co.za> Ezio Melotti added the comment: The patch you uploaded is wrong. ---------- nosy: +ezio.melotti stage: -> needs patch type: -> enhancement versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 00:46:06 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sat, 11 May 2013 22:46:06 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368312366.6.0.333391901785.issue17914@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: @Ned: if cpus is None, then this will raise an exception in Python 3: `cpus >= 1 or cpus == None` I understand that cpus >= INTEGER will raise an exception and have already modified the condition to remove that kind of check. I was merely stating that equality checks do not raise exception. eg: >>> cpus = None >>> cpus == 1 False >>> cpus == None True >>> Thanks for pointing me out in the right direction to remove those invalid checks and showing the use of proper alternatives at other places in the patch ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 01:09:53 2013 From: report at bugs.python.org (STINNER Victor) Date: Sat, 11 May 2013 23:09:53 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1368312366.6.0.333391901785.issue17914@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Not being able to decide for the default value is not a problem: just an optional "default" argument, which is 1 by default (most convinient value), return default on error. os.get_terminal_size() has a similar API for example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 01:10:46 2013 From: report at bugs.python.org (Antonio Cavallo) Date: Sat, 11 May 2013 23:10:46 +0000 Subject: [issue17905] Add check for locale.h In-Reply-To: <1367676553.24.0.0475219885835.issue17905@psf.upfronthosting.co.za> Message-ID: <1368313846.69.0.902891898769.issue17905@psf.upfronthosting.co.za> Antonio Cavallo added the comment: ok I see it, thanks. I've attached a new patch fixing the files with the locale's guards. Modules/readline.c might have the SAVE_LOCALE renamed into HAVE_SETLOCALE but the patch doesn't address that bit. Android has definitively locale.h but it is a dummy implementation at the moment. I'm trying with http://www.crystax.net/en/android/ndk instead but still no luck. ---------- Added file: http://bugs.python.org/file30228/locale_h_configure.ac.patch2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 01:41:51 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 11 May 2013 23:41:51 +0000 Subject: [issue8876] distutils should not assume that hardlinks will work In-Reply-To: <1275485916.86.0.44676570948.issue8876@psf.upfronthosting.co.za> Message-ID: <1368315711.47.0.475225029963.issue8876@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Not blocking on this old bug. ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 02:51:20 2013 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 12 May 2013 00:51:20 +0000 Subject: [issue17810] Implement PEP 3154 (pickle protocol 4) In-Reply-To: <1366526938.19.0.00976593994103.issue17810@psf.upfronthosting.co.za> Message-ID: <1368319880.77.0.0759989594967.issue17810@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Thanks Stefan for the patch. It's very much appreciated. I will try to review it soon. Of the features you proposed, the twos I would like to take a look again is implicit memoization and the BAIL_OUT opcode. For the implicit memoization feature, we will need to have some performance results in hand to justify the major changes it needs. If you can you work out a quick patch, I can run it through the benchmarks suite for pickle and measure the impact. Hopefully, we will see a good improvement though we can't be sure until we measure. And as for the BAIL_OUT opcode, it would be interesting to revisit its use now that we support binary framing. It could be helpful to add it to prevent the Unpickler from hanging if the other end forgot to close the stream. I am still not totally convinced. However if you make a good case for it, I would support to see it included. ---------- Added file: http://bugs.python.org/file30229/pickle4+methods.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 02:53:05 2013 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 12 May 2013 00:53:05 +0000 Subject: [issue17810] Implement PEP 3154 (pickle protocol 4) In-Reply-To: <1366526938.19.0.00976593994103.issue17810@psf.upfronthosting.co.za> Message-ID: <1368319985.92.0.673252119528.issue17810@psf.upfronthosting.co.za> Changes by Alexandre Vassalotti : Removed file: http://bugs.python.org/file30229/pickle4+methods.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 05:24:51 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 May 2013 03:24:51 +0000 Subject: [issue17838] Can't assign a different value for sys.stdin in IDLE In-Reply-To: <1366872984.94.0.234893757031.issue17838@psf.upfronthosting.co.za> Message-ID: <3b7Vrz0Mlpz7LjP@mail.python.org> Roundup Robot added the comment: New changeset 4b3d18117813 by Benjamin Peterson in branch '2.7': prevent IDLE from trying to close when sys.stdin is reassigned (#17838) http://hg.python.org/cpython/rev/4b3d18117813 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 05:25:58 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 12 May 2013 03:25:58 +0000 Subject: [issue17838] Can't assign a different value for sys.stdin in IDLE In-Reply-To: <1366872984.94.0.234893757031.issue17838@psf.upfronthosting.co.za> Message-ID: <1368329158.35.0.313958346788.issue17838@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I applied the least controversial patch, which fixes the regression, so 2.7.5 can be released. Feel free to tweak as needed. ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 06:31:50 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 04:31:50 +0000 Subject: [issue17934] Add a frame method to clear expensive details In-Reply-To: <1368014042.2.0.41504275061.issue17934@psf.upfronthosting.co.za> Message-ID: <1368333110.23.0.889135313213.issue17934@psf.upfronthosting.co.za> Nick Coghlan added the comment: Mostly looks good to me, but I think I'd prefer that attempts to clear a running frame raise RuntimeError with an appropriate message. I also wonder how this might relate to Eric Snow's proposal to reference the currently executing function from the frame object (see issue 12857). It seems to me that the "f_func" pointer in that patch could serve the same purpose as the "f_executing" boolean flag in this patch, while providing additional information about the execution context. Some other possibly relevant traceback related resource management issues: issue 6116, issue 1565525, issue 9815 (picked up while searching for Eric's RFE above) (We may want to add a "clear_frames" convenience method to tracebacks as well) ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 07:25:20 2013 From: report at bugs.python.org (Ethan Furman) Date: Sun, 12 May 2013 05:25:20 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368336320.95.0.52763307146.issue17947@psf.upfronthosting.co.za> Ethan Furman added the comment: Eli, The original _StealthProperty checked to see if it was being called on instance or class, and if it was the class it invoked __getattr__ to attempt a lookup for an enum member. Your version does not check, but, ironically, the exception raised is AttributeError, and so Python is calling __getattr__ anyway and so finds the virtual enum member. While this is cool, and it works, I think it's much less mysterious, magical, and downright confusing to keep the original behavior and call __getattr__ from _StealthProperty. On the other hand, it might make somebody think, and that's always good, so I'm happy to leave it your way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 07:36:48 2013 From: report at bugs.python.org (Alex Rhatushnyak) Date: Sun, 12 May 2013 05:36:48 +0000 Subject: [issue17958] int(math.log(2**i, 2)) Message-ID: <1368337008.23.0.437998264924.issue17958@psf.upfronthosting.co.za> New submission from Alex Rhatushnyak: In Python 2.7.4: import math for i in range(40, 55): print int(math.log(2**i, 2)), output: 40 41 42 43 44 45 46 46 48 49 49 50 52 53 53 ---------- messages: 188976 nosy: Alex.Rhatushnyak priority: normal severity: normal status: open title: int(math.log(2**i, 2)) type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 07:39:20 2013 From: report at bugs.python.org (Ethan Furman) Date: Sun, 12 May 2013 05:39:20 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368337160.55.0.895944472021.issue17947@psf.upfronthosting.co.za> Ethan Furman added the comment: regrtest framework now supported (had to change the module name I was passing in from '__main__' to __name__). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 07:42:15 2013 From: report at bugs.python.org (Ethan Furman) Date: Sun, 12 May 2013 05:42:15 +0000 Subject: [issue17954] Support creation of extensible enums through metaclass subclassing In-Reply-To: <1368280534.51.0.41696456409.issue17954@psf.upfronthosting.co.za> Message-ID: <1368337335.71.0.156410603077.issue17954@psf.upfronthosting.co.za> Ethan Furman added the comment: I'm sure this is a dumb question, but I have lots of them so thought I'd share. Can this issue be resolved simply by making the `_get_mixins` method `get_mixins`? ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 08:25:55 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 06:25:55 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368339955.73.0.263511969426.issue17947@psf.upfronthosting.co.za> Nick Coghlan added the comment: Guido has promised an explanation for why he wants to keep the frame hack once he is back at work next week. To help him target that reply appropriately for my concrete objections to retaining it, I'd like to explain a bit more about why I think it's fundamentally impossible to create a robust stack inspection mechanism for implicit pickling support. Even if a dedicated mechanism for it is added, the information the interpreter needs to make a sensible reliable decision simply isn't there. Consider the following: # In utils.py def enum_helper(name, prefix, fields): if isinstance(fields, str): fields = fields.split() e = Enum(name, (prefix + field for field in fields)) return e # In some other module from utils import enum_helper MyEnum = enum_helper(MyEnum, "st_", "mtime atime ctime") This breaks the frame hack, but would work correctly if enum_helper was redesigned to accept an explicit module name, or if we adopted something like the "name binding protocol" discussed on Python ideas. If we adopted a simplistic rule of ignoring function scopes and only look at module and class scopes, then we break the semantics of the global keyword. I consider the frame hack fundamentally broken, since there's currently no way the interpreter can distinguish between an incidental assignment (like the "e = Enum..." call in util.py) and a destination assignment (like the "MyEnum = enum_helper..." call), and if we *do* add a different syntax for "this supports pickling" assignments (like the def name = expr syntax on Python ideas), then a name binding protocol makes more sense than implicit contextual magic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 08:30:06 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 06:30:06 +0000 Subject: [issue17954] Support creation of extensible enums through metaclass subclassing In-Reply-To: <1368280534.51.0.41696456409.issue17954@psf.upfronthosting.co.za> Message-ID: <1368340206.09.0.309770042573.issue17954@psf.upfronthosting.co.za> Nick Coghlan added the comment: I don't think that would be wise - there's currently other logic in _get_mixins that subclasses would then have to duplicate. I was thinking more of an allow_subclass() API that subtypes could override to always return True. EnumMeta would then just factor the relevant piece of _get_mixins out into the default allow_subclass implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 08:51:37 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 06:51:37 +0000 Subject: [issue17959] Alternate approach to aliasing for PEP 435 Message-ID: <1368341497.6.0.896861896968.issue17959@psf.upfronthosting.co.za> New submission from Nick Coghlan: Creating this as a separate issue so as not to delay incorporation of the accepted PEP. One legitimate criticism of the accepted PEP 435 is that the combination of requiring explicit assignment of values *and* allowing aliasing by default is that aliases may be created inadvertently. I believe we can actually do better than the initial implementation by making the following work: >>> class Shape(Enum): ... square = 2 ... diamond = 1 ... circle = 3 ... alias_for_square = square ... >>> Shape.square >>> Shape.alias_for_square >>> Shape(2) While *disallowing* the following: >>> class Shape(Enum): ... square = 2 ... diamond = 1 ... circle = 3 ... alias_for_square = 2 ... How, do you ask? By wrapping non-descriptors on assignment in a placeholder type, and keeping track of which values we have already seen. If a new attribute is mapped to a placeholder, then that's fine, we accept it as an explicit declaration of an alias. However, if it's mapped directly to a repeat value, then that would be disallowed (as it was in earlier versions of the PEP). ---------- messages: 188981 nosy: ncoghlan priority: normal severity: normal stage: needs patch status: open title: Alternate approach to aliasing for PEP 435 type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 08:51:58 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 06:51:58 +0000 Subject: [issue17959] Alternate approach to aliasing for PEP 435 In-Reply-To: <1368341497.6.0.896861896968.issue17959@psf.upfronthosting.co.za> Message-ID: <1368341518.05.0.899606875723.issue17959@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- dependencies: +Code, test, and doc review for PEP-0435 Enum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 08:52:47 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 06:52:47 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368341567.62.0.492464716804.issue17947@psf.upfronthosting.co.za> Nick Coghlan added the comment: I also created issue 17959 to track a legitimate concern with the current aliasing design, without impacting incorporation of the accepted PEP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 08:54:08 2013 From: report at bugs.python.org (Alex Gaynor) Date: Sun, 12 May 2013 06:54:08 +0000 Subject: [issue17959] Alternate approach to aliasing for PEP 435 In-Reply-To: <1368341497.6.0.896861896968.issue17959@psf.upfronthosting.co.za> Message-ID: <1368341648.18.0.0258286116935.issue17959@psf.upfronthosting.co.za> Alex Gaynor added the comment: This would preclude code like: class Shape(Enum): rectangle = shape = 2 which seems (to me) to be the most reasonable way to express aliasing. ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 08:56:34 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sun, 12 May 2013 06:56:34 +0000 Subject: [issue17890] argparse: mutually exclusive groups full of suppressed args can cause AssertionErrors In-Reply-To: <1367455382.45.0.0611766927148.issue17890@psf.upfronthosting.co.za> Message-ID: <1368341794.03.0.278700213118.issue17890@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: @Terry: Thanks for the info. I seem to have the elusive "*" after my username now. I am not sure how this works, but can you review/test/apply the patch now? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 08:59:36 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sun, 12 May 2013 06:59:36 +0000 Subject: [issue17940] extra code in argparse.py In-Reply-To: <1368052350.83.0.843381398629.issue17940@psf.upfronthosting.co.za> Message-ID: <1368341976.22.0.881250450633.issue17940@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: I guess that was simple enough. I am new to this issue tracker for Cpython. How will the patch review/commit proceed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 09:46:47 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 07:46:47 +0000 Subject: [issue17960] Clarify the required behaviour of locals() Message-ID: <1368344807.52.0.116896667629.issue17960@psf.upfronthosting.co.za> New submission from Nick Coghlan: As proposed at [1], I would like to tighten up the definition of locals so that defining enum members programmatically is officially supported behaviour. I'll come up with a patch soonish. [1] http://mail.python.org/pipermail/python-dev/2013-May/125917.html ---------- assignee: ncoghlan components: Documentation messages: 188986 nosy: benjamin.peterson, gvanrossum, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Clarify the required behaviour of locals() type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 09:51:25 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 12 May 2013 07:51:25 +0000 Subject: [issue17960] Clarify the required behaviour of locals() In-Reply-To: <1368344807.52.0.116896667629.issue17960@psf.upfronthosting.co.za> Message-ID: <1368345085.85.0.0059003505737.issue17960@psf.upfronthosting.co.za> Ezio Melotti added the comment: See also #17546 and #7083. ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 09:56:05 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 07:56:05 +0000 Subject: [issue17959] Alternate approach to aliasing for PEP 435 In-Reply-To: <1368341497.6.0.896861896968.issue17959@psf.upfronthosting.co.za> Message-ID: <1368345365.87.0.924725079352.issue17959@psf.upfronthosting.co.za> Nick Coghlan added the comment: That's a terrible way to express aliasing, because it's really unclear that "rectangle" is the canonical name. By contrast: class Shape(Enum): rectangle = 2 oblong = rectangle leaves no doubt as to which is canonical and which is the alias. You never need to go beyond two assignments, as you can still use multiple target assignment for the aliases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 09:59:34 2013 From: report at bugs.python.org (=?utf-8?q?Antonio_P=C3=A9rez?=) Date: Sun, 12 May 2013 07:59:34 +0000 Subject: [issue17606] xml.sax.saxutils.XMLGenerator cannot output with the correct encoding In-Reply-To: <1364767390.87.0.956919246275.issue17606@psf.upfronthosting.co.za> Message-ID: <1368345574.53.0.0761369765532.issue17606@psf.upfronthosting.co.za> Changes by Antonio P?rez : ---------- nosy: +skarcha _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 10:12:05 2013 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 12 May 2013 08:12:05 +0000 Subject: [issue17960] Clarify the required behaviour of locals() In-Reply-To: <1368344807.52.0.116896667629.issue17960@psf.upfronthosting.co.za> Message-ID: <1368346325.3.0.264973385707.issue17960@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 10:14:45 2013 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 12 May 2013 08:14:45 +0000 Subject: [issue17934] Add a frame method to clear expensive details In-Reply-To: <1368014042.2.0.41504275061.issue17934@psf.upfronthosting.co.za> Message-ID: <1368346485.06.0.714877888237.issue17934@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 10:53:45 2013 From: report at bugs.python.org (Alexandre Vassalotti) Date: Sun, 12 May 2013 08:53:45 +0000 Subject: [issue17810] Implement PEP 3154 (pickle protocol 4) In-Reply-To: <1366526938.19.0.00976593994103.issue17810@psf.upfronthosting.co.za> Message-ID: <1368348825.3.0.96007337272.issue17810@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: Stefan, I took a quick look at your patch. There is a couple things that stands out. First, I think the implementation of BINGLOBAL and BINGLOBAL_BIG should be moved to another patch. Adding a binary version opcode for GLOBAL is a separate feature and it should be reviewed independently. Personally, I prefer the STACK_GLOBAL opcode I proposed as it much simpler to implement, but I am biased. Next, the patch's formatting should be fixed to conform to PEP 7 and PEP 8. Make sure the formatting is consistent with the surrounding code. In particular, comments should be full sentences that explains why we need this code. Avoid adding comments that merely say what the code does, unless the code is complex. In addition, please replace the uses of PyUnicode_InternFromString with the _Py_IDENTIFIER as needed. The latter allow the static strings to be garbage collected when the module is deleted, which is friendlier to embedded interpreters. It is also lead to cleaner code. Finally, the class method check hack looks like a bug to me. There are multiple solutions here. For example, we could fix class methods to be cached so they always have the same ID once they are created. Or, we could remove the 'is' check completely if it is unnecessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 11:00:19 2013 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 May 2013 09:00:19 +0000 Subject: [issue17666] Extra gzip headers breaks _read_gzip_header In-Reply-To: <1365443712.06.0.547975068624.issue17666@psf.upfronthosting.co.za> Message-ID: <1368349219.46.0.344737637649.issue17666@psf.upfronthosting.co.za> Georg Brandl added the comment: Cherry-picked to 3.2 branch as c31ff361cde3. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 11:11:18 2013 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 May 2013 09:11:18 +0000 Subject: [issue17843] Lib/test/testbz2_bigmem.bz2 trigger virus warnings In-Reply-To: <1366887968.16.0.8223632695.issue17843@psf.upfronthosting.co.za> Message-ID: <1368349878.79.0.343216467437.issue17843@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks, applied to 3.2 branch. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 11:14:39 2013 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 May 2013 09:14:39 +0000 Subject: [issue17857] sqlite modules doesn't build with 2.7.4 on Mac OS X 10.4 In-Reply-To: <1367088365.18.0.161187485212.issue17857@psf.upfronthosting.co.za> Message-ID: <1368350079.68.0.216024106149.issue17857@psf.upfronthosting.co.za> Georg Brandl added the comment: Cherry-picked to 3.2 branch. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 11:24:27 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 May 2013 09:24:27 +0000 Subject: [issue17838] Can't assign a different value for sys.stdin in IDLE In-Reply-To: <1366872984.94.0.234893757031.issue17838@psf.upfronthosting.co.za> Message-ID: <3b7fqj4bDrz7LjP@mail.python.org> Roundup Robot added the comment: New changeset 5f62c848f713 by Benjamin Peterson in branch '3.3': prevent IDLE from trying to close when sys.stdin is reassigned (#17838) http://hg.python.org/cpython/rev/5f62c848f713 New changeset bc322854c336 by Georg Brandl in branch 'default': Issue #17838: merge with 3.3 http://hg.python.org/cpython/rev/bc322854c336 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 11:40:51 2013 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 May 2013 09:40:51 +0000 Subject: [issue17585] IDLE - regression with exit() and quit() In-Reply-To: <1364715900.07.0.37447718586.issue17585@psf.upfronthosting.co.za> Message-ID: <1368351651.73.0.792786243333.issue17585@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 11:41:23 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sun, 12 May 2013 09:41:23 +0000 Subject: [issue16805] when building docs on Debian 7 --> ERROR: Error in "note" directive In-Reply-To: <1368311393.55.0.33055921146.issue16805@psf.upfronthosting.co.za> Message-ID: Tshepang Lekhonkhobe added the comment: Ok. I thought doc fixes were exempt. Strange policy there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 11:41:35 2013 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 May 2013 09:41:35 +0000 Subject: [issue15902] imp.load_module won't accept None for the file argument for a C extension In-Reply-To: <1347278689.78.0.295593798435.issue15902@psf.upfronthosting.co.za> Message-ID: <1368351695.48.0.721440871035.issue15902@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 11:42:13 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sun, 12 May 2013 09:42:13 +0000 Subject: [issue17957] remove outdated (and unexcellent) paragraph in whatsnew In-Reply-To: <1368310843.47.0.442601461472.issue17957@psf.upfronthosting.co.za> Message-ID: <1368351733.75.0.778112310501.issue17957@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : Removed file: http://bugs.python.org/file30227/diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 11:42:29 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sun, 12 May 2013 09:42:29 +0000 Subject: [issue17957] remove outdated (and unexcellent) paragraph in whatsnew In-Reply-To: <1368310843.47.0.442601461472.issue17957@psf.upfronthosting.co.za> Message-ID: <1368351749.28.0.0963906329063.issue17957@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : Added file: http://bugs.python.org/file30230/diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 11:42:35 2013 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 May 2013 09:42:35 +0000 Subject: [issue17585] IDLE - regression with exit() and quit() In-Reply-To: <1364715900.07.0.37447718586.issue17585@psf.upfronthosting.co.za> Message-ID: <1368351755.3.0.204293530094.issue17585@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 11:43:17 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sun, 12 May 2013 09:43:17 +0000 Subject: [issue17957] remove outdated (and unexcellent) paragraph in whatsnew In-Reply-To: <1368310843.47.0.442601461472.issue17957@psf.upfronthosting.co.za> Message-ID: <1368351797.91.0.179436202496.issue17957@psf.upfronthosting.co.za> Tshepang Lekhonkhobe added the comment: uploaded the correct one; sori ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:02:02 2013 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 May 2013 10:02:02 +0000 Subject: [issue16805] when building docs on Debian 7 --> ERROR: Error in "note" directive In-Reply-To: <1356739435.76.0.304211925624.issue16805@psf.upfronthosting.co.za> Message-ID: <1368352922.96.0.652109722524.issue16805@psf.upfronthosting.co.za> Georg Brandl added the comment: Please do not comment on policies if you don't understand our release system. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:11:30 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 10:11:30 +0000 Subject: [issue17959] Alternate approach to aliasing for PEP 435 In-Reply-To: <1368341497.6.0.896861896968.issue17959@psf.upfronthosting.co.za> Message-ID: <1368353490.02.0.161727508864.issue17959@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:28:42 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 May 2013 10:28:42 +0000 Subject: [issue17838] Can't assign a different value for sys.stdin in IDLE In-Reply-To: <1366872984.94.0.234893757031.issue17838@psf.upfronthosting.co.za> Message-ID: <1368354522.79.0.0419176743896.issue17838@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: 3.2? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:31:23 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 10:31:23 +0000 Subject: [issue17954] Support creation of extensible enums through metaclass subclassing In-Reply-To: <1368280534.51.0.41696456409.issue17954@psf.upfronthosting.co.za> Message-ID: <1368354683.69.0.863278067388.issue17954@psf.upfronthosting.co.za> Nick Coghlan added the comment: I elaborated on this point in http://python-notes.boredomandlaziness.org/en/latest/python3/enum_creation.html#support-for-alternate-declaration-syntaxes However, I'm now wondering if the problem is simply that the "no extension of enums" rule is more restrictive than it needs to be. If you *don't define any new methods*, then there's no problem with extending an enumeration - it's only the combination of extension and adding extra behaviour which is incoherent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:31:49 2013 From: report at bugs.python.org (Eric V. Smith) Date: Sun, 12 May 2013 10:31:49 +0000 Subject: [issue17959] Alternate approach to aliasing for PEP 435 In-Reply-To: <1368341497.6.0.896861896968.issue17959@psf.upfronthosting.co.za> Message-ID: <1368354709.04.0.200590086006.issue17959@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:32:39 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 May 2013 10:32:39 +0000 Subject: [issue15535] Fix pickling efficiency of named tuples in 2.7.3 In-Reply-To: <1343915086.31.0.252328658724.issue15535@psf.upfronthosting.co.za> Message-ID: <3b7hLZ6Fssz7LjP@mail.python.org> Roundup Robot added the comment: New changeset 31eaf8a137ea by Georg Brandl in branch '3.2': Issue #15535: Fix pickling of named tuples. http://hg.python.org/cpython/rev/31eaf8a137ea ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:32:40 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 May 2013 10:32:40 +0000 Subject: [issue17857] sqlite modules doesn't build with 2.7.4 on Mac OS X 10.4 In-Reply-To: <1367088365.18.0.161187485212.issue17857@psf.upfronthosting.co.za> Message-ID: <3b7hLb4j52z7LjP@mail.python.org> Roundup Robot added the comment: New changeset d5b5116bf953 by Serhiy Storchaka in branch '3.2': Issue #17857: Prevent build failures with pre-3.5.0 versions of sqlite3, http://hg.python.org/cpython/rev/d5b5116bf953 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:32:41 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 May 2013 10:32:41 +0000 Subject: [issue17843] Lib/test/testbz2_bigmem.bz2 trigger virus warnings In-Reply-To: <1366887968.16.0.8223632695.issue17843@psf.upfronthosting.co.za> Message-ID: <3b7hLc367Mz7LkB@mail.python.org> Roundup Robot added the comment: New changeset 9da98ab823c9 by Georg Brandl in branch '3.2': Issue #17843: Remove bz2 test data that triggers antivirus warnings. http://hg.python.org/cpython/rev/9da98ab823c9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:32:41 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 May 2013 10:32:41 +0000 Subject: [issue1159051] Handle corrupted gzip files with unexpected EOF Message-ID: <3b7hLd1RBhz7LkK@mail.python.org> Roundup Robot added the comment: New changeset 854ba6f414a8 by Georg Brandl in branch '3.2': Issue #1159051: Back out a fix for handling corrupted gzip files that http://hg.python.org/cpython/rev/854ba6f414a8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:32:42 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 May 2013 10:32:42 +0000 Subject: [issue17915] Encoding error with sax and codecs In-Reply-To: <1367838846.54.0.113997926456.issue17915@psf.upfronthosting.co.za> Message-ID: <3b7hLd72FCz7Lkc@mail.python.org> Roundup Robot added the comment: New changeset 1c01571ce0f4 by Georg Brandl in branch '3.2': Issue #17915: Fix interoperability of xml.sax with file objects returned by http://hg.python.org/cpython/rev/1c01571ce0f4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:32:43 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 May 2013 10:32:43 +0000 Subject: [issue17666] Extra gzip headers breaks _read_gzip_header In-Reply-To: <1365443712.06.0.547975068624.issue17666@psf.upfronthosting.co.za> Message-ID: <3b7hLf5YVjz7LkY@mail.python.org> Roundup Robot added the comment: New changeset c31ff361cde3 by Serhiy Storchaka in branch '3.2': Close #17666: Fix reading gzip files with an extra field. http://hg.python.org/cpython/rev/c31ff361cde3 ---------- stage: commit review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:33:04 2013 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 12 May 2013 10:33:04 +0000 Subject: [issue17958] int(math.log(2**i, 2)) In-Reply-To: <1368337008.23.0.437998264924.issue17958@psf.upfronthosting.co.za> Message-ID: <1368354784.01.0.346172609972.issue17958@psf.upfronthosting.co.za> Mark Dickinson added the comment: Sorry: this is not a bug, but a difficult-to-avoid consequence of floating-point imprecision: math.log(n, 2) is computed as log(n) / log(2), and each of the log computations and the division can introduce small errors. For what it's worth, Python 3.3 has a `log2` function, which has accuracy that's a little bit better than math.log(n, 2), and gives the 'correct' answer exact powers of 2. Closing as invalid. ---------- nosy: +mark.dickinson resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:34:07 2013 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 12 May 2013 10:34:07 +0000 Subject: [issue17958] int(math.log(2**i, 2)) In-Reply-To: <1368337008.23.0.437998264924.issue17958@psf.upfronthosting.co.za> Message-ID: <1368354847.79.0.675717905383.issue17958@psf.upfronthosting.co.za> Mark Dickinson added the comment: Postscript: depending on what you're doing, you might also find the int.bit_length method helpful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:41:32 2013 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 May 2013 10:41:32 +0000 Subject: [issue17838] Can't assign a different value for sys.stdin in IDLE In-Reply-To: <1366872984.94.0.234893757031.issue17838@psf.upfronthosting.co.za> Message-ID: <1368355292.39.0.83260419711.issue17838@psf.upfronthosting.co.za> Georg Brandl added the comment: Not necessary as per msg188301. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:44:26 2013 From: report at bugs.python.org (Ethan Furman) Date: Sun, 12 May 2013 10:44:26 +0000 Subject: [issue17959] Alternate approach to aliasing for PEP 435 In-Reply-To: <1368341497.6.0.896861896968.issue17959@psf.upfronthosting.co.za> Message-ID: <1368355466.2.0.338915809536.issue17959@psf.upfronthosting.co.za> Ethan Furman added the comment: Another approach to handling this, and other, issues is to allow options to EnumMeta. My original aenum code had the default Enum class as unordered, no duplicates allowed, non-indexable, etc., but then allowed options to be passed in such as DUPLICATES to allow duplicates, ORDERED to add the ge-gt-le-lt methods, INDEXED to add __index__, etc. For the aliasing issue this method is more robust as placeholders are not required, and code like this will work: class Physics(Enum): e = 2.81847 pi = 3.141596 tau = 2 * pi To make that code work with placeholders is possible (I have it in aenum) but a major pain (I was about to remove it before my offer to help with ref435 was accepted). ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:45:59 2013 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 May 2013 10:45:59 +0000 Subject: [issue17915] Encoding error with sax and codecs In-Reply-To: <1367838846.54.0.113997926456.issue17915@psf.upfronthosting.co.za> Message-ID: <1368355559.9.0.551474295042.issue17915@psf.upfronthosting.co.za> Georg Brandl added the comment: Fixed in 3.2, 3.3 and default. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:46:19 2013 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 May 2013 10:46:19 +0000 Subject: [issue1159051] Handle corrupted gzip files with unexpected EOF Message-ID: <1368355579.55.0.230054136629.issue1159051@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:46:25 2013 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 May 2013 10:46:25 +0000 Subject: [issue1159051] Handle corrupted gzip files with unexpected EOF Message-ID: <1368355585.79.0.506528108459.issue1159051@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- versions: -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:47:24 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 May 2013 10:47:24 +0000 Subject: [issue1159051] Handle corrupted gzip files with unexpected EOF Message-ID: <3b7hgb3X01zR0l@mail.python.org> Roundup Robot added the comment: New changeset 9c2831fe84e9 by Georg Brandl in branch '3.3': Back out patch for #1159051, which caused backwards compatibility problems. http://hg.python.org/cpython/rev/9c2831fe84e9 New changeset 5400e8fbc1de by Georg Brandl in branch 'default': null-merge reversion of #1159051 patch from 3.3 http://hg.python.org/cpython/rev/5400e8fbc1de ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:47:24 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 May 2013 10:47:24 +0000 Subject: [issue17732] distutils.cfg Can Break venv In-Reply-To: <1365963032.26.0.766714843383.issue17732@psf.upfronthosting.co.za> Message-ID: <3b7hgc1x7gzR0l@mail.python.org> Roundup Robot added the comment: New changeset 6c5a3d194a10 by Georg Brandl in branch '3.3': Closes issue #17732: ignore install-directory specific options in http://hg.python.org/cpython/rev/6c5a3d194a10 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:56:55 2013 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 12 May 2013 10:56:55 +0000 Subject: [issue17958] int(math.log(2**i, 2)) In-Reply-To: <1368337008.23.0.437998264924.issue17958@psf.upfronthosting.co.za> Message-ID: <1368356215.4.0.399237917845.issue17958@psf.upfronthosting.co.za> Mark Dickinson added the comment: For tracker archaeologists: see also issue #11888, issue #9959. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:57:02 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 10:57:02 +0000 Subject: [issue17961] Use enum names as values in enum.Enum convenience API Message-ID: <1368356222.14.0.0972295622627.issue17961@psf.upfronthosting.co.za> New submission from Nick Coghlan: I encountered an interesting suggestion [1] regarding the enum.Enum convenience API: use the member names as their values, rather than the current integers starting from one. Since we're now using definition order rather than value order for iteration, this suggestion makes a lot of sense to me. (again, posting this as something to consider after the accepted PEP is incorporated) [1] http://www.acooke.org/cute/Pythonssad0.html ---------- messages: 189013 nosy: ncoghlan priority: normal severity: normal stage: needs patch status: open title: Use enum names as values in enum.Enum convenience API type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:57:35 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 10:57:35 +0000 Subject: [issue17961] Use enum names as values in enum.Enum convenience API In-Reply-To: <1368356222.14.0.0972295622627.issue17961@psf.upfronthosting.co.za> Message-ID: <1368356255.34.0.400193764805.issue17961@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- dependencies: +Code, test, and doc review for PEP-0435 Enum versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 12:59:53 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 10:59:53 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368356393.3.0.125711914449.issue17947@psf.upfronthosting.co.za> Nick Coghlan added the comment: Another post-incorporation proposal (issue 17961) relating to the values used for the functional API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 13:02:27 2013 From: report at bugs.python.org (Ethan Furman) Date: Sun, 12 May 2013 11:02:27 +0000 Subject: [issue17954] Support creation of extensible enums through metaclass subclassing In-Reply-To: <1368280534.51.0.41696456409.issue17954@psf.upfronthosting.co.za> Message-ID: <1368356547.4.0.00447441835583.issue17954@psf.upfronthosting.co.za> Ethan Furman added the comment: Make it simpler: class EnumMeta(): allow_subclass = False class MyEnumMeta(EnumMeta): allow_subclass = True ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 13:11:20 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 12 May 2013 11:11:20 +0000 Subject: [issue17934] Add a frame method to clear expensive details In-Reply-To: <1368333110.23.0.889135313213.issue17934@psf.upfronthosting.co.za> Message-ID: <1368357075.2535.1.camel@fsol> Antoine Pitrou added the comment: > Mostly looks good to me, but I think I'd prefer that attempts to clear > a running frame raise RuntimeError with an appropriate message. Hmm, why not. My intuition was to make frame.clear() a best-effort method, but this sounds ok too. > I also wonder how this might relate to Eric Snow's proposal to > reference the currently executing function from the frame object (see > issue 12857). It seems to me that the "f_func" pointer in that patch > could serve the same purpose as the "f_executing" boolean flag in this > patch, while providing additional information about the execution > context. Yes, perhaps. Then Eric's patch can incorporate that change once the frame.clear() patch is committed. > (We may want to add a "clear_frames" convenience method to tracebacks > as well) That, or in the traceback module. The reason I'm proposing this one as a frame method is that it can't be done in pure Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 13:12:31 2013 From: report at bugs.python.org (Ethan Furman) Date: Sun, 12 May 2013 11:12:31 +0000 Subject: [issue17961] Use enum names as values in enum.Enum convenience API In-Reply-To: <1368356222.14.0.0972295622627.issue17961@psf.upfronthosting.co.za> Message-ID: <1368357151.88.0.885981468814.issue17961@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 13:14:46 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 12 May 2013 11:14:46 +0000 Subject: [issue17810] Implement PEP 3154 (pickle protocol 4) In-Reply-To: <1368348825.3.0.96007337272.issue17810@psf.upfronthosting.co.za> Message-ID: <1368357284.2535.4.camel@fsol> Antoine Pitrou added the comment: > Stefan, I took a quick look at your patch. There is a couple things > that stands out. It would be nice if you could reconcile each other's work. Especially so I don't re-implement framing on top of something else :-) > Adding a binary version opcode for GLOBAL is a separate feature and it > should be reviewed independently. Well, it's part of the PEP. > Personally, I prefer the STACK_GLOBAL opcode I proposed as it much > simpler to implement, but I am biased. I agree it sounds simpler. I hadn't thought about it when first writing the PEP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 13:23:17 2013 From: report at bugs.python.org (Georg Brandl) Date: Sun, 12 May 2013 11:23:17 +0000 Subject: [issue17732] distutils.cfg Can Break venv In-Reply-To: <1365963032.26.0.766714843383.issue17732@psf.upfronthosting.co.za> Message-ID: <1368357797.04.0.981555846997.issue17732@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 13:24:05 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 12 May 2013 11:24:05 +0000 Subject: [issue17962] Broken OpenSSL version in Windows builds Message-ID: <1368357845.04.0.941311125595.issue17962@psf.upfronthosting.co.za> New submission from Antoine Pitrou: 3.3 and default are currently fetching OpenSSL 1.0.1d for the Windows builds. It seems OpenSSL 1.0.1d was a kind of "brown paper bag" release, they've released 1.0.1e since (some of test_ssl can fail on 1.0.1d and succeed on 1.0.1e, as experienced on my Linux setup; the Windows buildbots also exhibit similar failures). Following is their description of the fix: ?Changes between 1.0.1d and 1.0.1e [11 Feb 2013] *) Correct fix for CVE-2013-0169. The original didn't work on AES-NI supporting platforms or when small records were transferred. [Andy Polyakov, Steve Henson]? ---------- components: Build, Windows messages: 189018 nosy: georg.brandl, larry, loewis, pitrou priority: release blocker severity: normal status: open title: Broken OpenSSL version in Windows builds type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 13:24:40 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 12 May 2013 11:24:40 +0000 Subject: [issue17425] Update OpenSSL versions in Windows builds In-Reply-To: <1363299017.8.0.243503203176.issue17425@psf.upfronthosting.co.za> Message-ID: <1368357880.18.0.115045547702.issue17425@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Opened #17962 to tackle the broken OpenSSL issue. ---------- stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 13:24:44 2013 From: report at bugs.python.org (Ethan Furman) Date: Sun, 12 May 2013 11:24:44 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368357884.5.0.421027540351.issue17947@psf.upfronthosting.co.za> Ethan Furman added the comment: After more thought, I think we should leave the shortened version of _StealthProperty as is. The reasoning being that if _StealthProperty does the __getattr__ lookup itself, and fails, it will return an AttributeError... and then Python will use __getattr__ again to try and find the attribute. So I'll add a comment into the shortened version and leave it at that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 14:17:47 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 12 May 2013 12:17:47 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368361067.01.0.42031520252.issue17947@psf.upfronthosting.co.za> Eli Bendersky added the comment: Nick, could you open a separate issue for the frame hack discussion, like you did for the other things? You can make this one depend on it, if you feel it's a "blocker", but let's please not intermix more discussion here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 14:28:56 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 12:28:56 +0000 Subject: [issue17961] Use enum names as values in enum.Enum convenience API In-Reply-To: <1368356222.14.0.0972295622627.issue17961@psf.upfronthosting.co.za> Message-ID: <1368361736.34.0.770655422948.issue17961@psf.upfronthosting.co.za> Nick Coghlan added the comment: Specifically, my suggestion is that for auto-created enum members, the invariant "asset x.value == str(x)" should hold. In flufl.enum, using integers made sense because it relies on sorting of values to determine the iteration order. That's no longer a concern for the standard library version, as iteration has been changed to use definition order. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 14:34:06 2013 From: report at bugs.python.org (Ethan Furman) Date: Sun, 12 May 2013 12:34:06 +0000 Subject: [issue17961] Use enum names as values in enum.Enum convenience API In-Reply-To: <1368356222.14.0.0972295622627.issue17961@psf.upfronthosting.co.za> Message-ID: <1368362046.38.0.857456457914.issue17961@psf.upfronthosting.co.za> Ethan Furman added the comment: In flufl.enum integers also made since as that was the default back-end data type. Currently, the functional method allows a type declaration. The behavior there could be tweaked such that no specification meant no value (a truly valueless enum!), type=int means ints starting from 1, type=str meant str values of names, any other value and you better had made your own enum derived class to support it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 14:44:41 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 12:44:41 +0000 Subject: [issue17959] Alternate approach to aliasing for PEP 435 In-Reply-To: <1368341497.6.0.896861896968.issue17959@psf.upfronthosting.co.za> Message-ID: <1368362681.81.0.301391018701.issue17959@psf.upfronthosting.co.za> Nick Coghlan added the comment: Hmm, that's an interesting point about allowing operations on the already defined values. You could get around that by requiring that the wrapper be explicit when definined the alias: >>> class Shape(enum.Enum): ... rectangle = 1 ... oblong = enum.alias(rectangle) Or, equivalently: >>> class Shape(enum.Enum): ... rectangle = 1 ... oblong = enum.alias(1) So simple typos would trigger an error by default, and the enum.alias wrapper would tell the namespace (or the metaclass) "hey, this should be an alias for another value already defined here". I definitely don't want us to turn the metaclass into a swiss army knife of behavioural options - I'm happy with customisation hooks in the metaclass on that front, as I believe it is an effective way to discourage excessive use of metaclass magic without preventing it when it is necessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 14:52:34 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 12:52:34 +0000 Subject: [issue17954] Support creation of extensible enums through metaclass subclassing In-Reply-To: <1368280534.51.0.41696456409.issue17954@psf.upfronthosting.co.za> Message-ID: <1368363154.63.0.116278955804.issue17954@psf.upfronthosting.co.za> Nick Coghlan added the comment: Simply removing the restriction isn't actually appropriate, as the variants that allow addition of new members should *not* allow addition of new descriptors. That's why I'm wondering if the current subclassing restriction is wrong: if you subclass an Enum derivative that already has defined members, then adding new members is OK, but adding new behaviour is not. If you subclass an Enum derivative with no members, then adding either members or behaviours is fine. If we relaxed the "no subclassing" rule to "no new non-members", then this Enums would be natively extensible and this customisation hack wouldn't be necessary at all. We have plenty of time before 3.4 - let's get the existing implementation in before worrying further about this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 14:54:03 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 12:54:03 +0000 Subject: [issue17934] Add a frame method to clear expensive details In-Reply-To: <1368014042.2.0.41504275061.issue17934@psf.upfronthosting.co.za> Message-ID: <1368363243.61.0.444138842319.issue17934@psf.upfronthosting.co.za> Nick Coghlan added the comment: +1 to all Antoine's replies :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 14:54:50 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 12 May 2013 12:54:50 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368363290.7.0.625084021145.issue17947@psf.upfronthosting.co.za> Eli Bendersky added the comment: Ethan, I pasted the minimized version to point out the problem; I fully agree it should do the getattr lookup because otherwise it's very difficult to understand what's going on. Let's keep exceptions for actual exceptional situations and explicitly code the normal path. Also, _MemberOrProperty is probably a more descriptive name. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 15:09:13 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 13:09:13 +0000 Subject: [issue17963] Deprecate the frame hack for implicitly getting module details Message-ID: <1368364153.58.0.131087315276.issue17963@psf.upfronthosting.co.za> New submission from Nick Coghlan: (Split off from issue 17947) collections.namedtuple includes a frame hack that attempts to make the functional API work for ordinary module level assignments: try: result.__module__ = _sys._getframe(1).f_globals.get('__name__', '__main__') except (AttributeError, ValueError): pass I *really* don't like the fact that this hack is being incorporated into the PEP 435 implementation as well, when that API has been designed to include an explicit cross-implementation workaround for this case. Eli asked me to move the discussion over to a new issue to allow the implementation issue to focus on incorporating the PEP as is. Issue 17941 (the explicit module keyword-only argument) suggest incorporating PEP 435's robust, cross-implementation way to support pickling in the functional API into collection namedtuple as well, suggesting to me that the frame hack should be deprecated, not propagated further. The main reason I don't like it is not the fact it doesn't work reliably on other implementations, but the fact it doesn't work reliably in CPython either - if you create a helper function, then the frame hack will pick up the module where the helper function lives rather than where you ultimately store the created object. Without some explicit way of telling the created object the final destination (whether through an argument or through new syntax and a name binding protocol), I don't see a way to resolve this dilemna in a robust way. However, Guido tells me that he really wants to keep the frame hack (and include it for PEP 435 as well), so this issue is basically about documenting that rationale somewhere. ---------- assignee: gvanrossum messages: 189028 nosy: eli.bendersky, gvanrossum, ncoghlan priority: normal severity: normal status: open title: Deprecate the frame hack for implicitly getting module details type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 15:09:36 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 13:09:36 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368364176.41.0.861689473179.issue17947@psf.upfronthosting.co.za> Nick Coghlan added the comment: Eli: done, created as #17963 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 15:12:24 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 13:12:24 +0000 Subject: [issue17963] Deprecate the frame hack for implicitly getting module details In-Reply-To: <1368364153.58.0.131087315276.issue17963@psf.upfronthosting.co.za> Message-ID: <1368364344.01.0.551597829073.issue17963@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- dependencies: +namedtuple should support fully qualified name for more portable pickling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 15:17:31 2013 From: report at bugs.python.org (Ethan Furman) Date: Sun, 12 May 2013 13:17:31 +0000 Subject: [issue17954] Support creation of extensible enums through metaclass subclassing In-Reply-To: <1368280534.51.0.41696456409.issue17954@psf.upfronthosting.co.za> Message-ID: <1368364651.97.0.183628325463.issue17954@psf.upfronthosting.co.za> Ethan Furman added the comment: Not trying to push, but if I don't write it down now, I'll forget later. ;) What does adding new members gain us? If I have a func xyz() that's expecting a Color, a MoreColor will work sometimes and blow up other times. Or are you saying that we may have a function mno() that takes a Color or a MoreColor? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 15:18:01 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 12 May 2013 13:18:01 +0000 Subject: [issue17963] Deprecate the frame hack for implicitly getting module details In-Reply-To: <1368364153.58.0.131087315276.issue17963@psf.upfronthosting.co.za> Message-ID: <1368364681.55.0.475607893529.issue17963@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 15:32:06 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 13:32:06 +0000 Subject: [issue17954] Support creation of extensible enums through metaclass subclassing In-Reply-To: <1368280534.51.0.41696456409.issue17954@psf.upfronthosting.co.za> Message-ID: <1368365526.11.0.0851374849295.issue17954@psf.upfronthosting.co.za> Nick Coghlan added the comment: Ah, you're right, I forgot that was the other reason for disallowing extensions through subclassing. To get extensions to work right, you need to flip it around so that isinstance(Color.red, MoreColor) is True, while isinstance(MoreColor.magenta, Color) is False. ---------- dependencies: -Code, test, and doc review for PEP-0435 Enum resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 15:52:13 2013 From: report at bugs.python.org (Ethan Furman) Date: Sun, 12 May 2013 13:52:13 +0000 Subject: [issue17963] Deprecate the frame hack for implicitly getting module details In-Reply-To: <1368364153.58.0.131087315276.issue17963@psf.upfronthosting.co.za> Message-ID: <1368366733.75.0.21787499672.issue17963@psf.upfronthosting.co.za> Ethan Furman added the comment: I believe Guido will be happy to replace the frame hack once we have something better, such as a way to implicitly (or explicitly in the case of helper functions) pass the calling module's name. Maybe a global __calling_module__ that a function can look at... or something similar, anyway. ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 16:06:28 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 14:06:28 +0000 Subject: [issue17963] Deprecate the frame hack for implicitly getting module details In-Reply-To: <1368364153.58.0.131087315276.issue17963@psf.upfronthosting.co.za> Message-ID: <1368367588.8.0.525537010988.issue17963@psf.upfronthosting.co.za> Nick Coghlan added the comment: Right, but I think it's categorically impossible to make that work reliably without new syntax and a name binding protocol (or something equivalent). Due to the existence of the global keyword, the frame stack and normal assignment syntax simply don't provide adequate information for us to tell the difference between "incidental" assignments in a helper function and "definite assignments" that represent the ultimate destination. And if the solution involves new syntax, then the frame hack will have to be deprecated at some point anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 16:07:13 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 14:07:13 +0000 Subject: [issue17963] Deprecate the frame hack for implicitly getting module details In-Reply-To: <1368364153.58.0.131087315276.issue17963@psf.upfronthosting.co.za> Message-ID: <1368367633.06.0.713849139953.issue17963@psf.upfronthosting.co.za> Nick Coghlan added the comment: Oops, that was supposed to be "definitive assignments" in my previous comment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 16:14:54 2013 From: report at bugs.python.org (Stefan Drees) Date: Sun, 12 May 2013 14:14:54 +0000 Subject: [issue17962] Broken OpenSSL version in Windows builds In-Reply-To: <1368357845.04.0.941311125595.issue17962@psf.upfronthosting.co.za> Message-ID: <1368368094.04.0.481257391495.issue17962@psf.upfronthosting.co.za> Changes by Stefan Drees : ---------- nosy: +sdrees _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 16:24:59 2013 From: report at bugs.python.org (Ethan Furman) Date: Sun, 12 May 2013 14:24:59 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368368699.61.0.987758075805.issue17947@psf.upfronthosting.co.za> Ethan Furman added the comment: Here's the latest patch. Note that the functional API portion is broken, and I'll get back to that this evening. Please only comment on the working code. ;) I'll make that _MemborOrProperty name change then as well. ---------- Added file: http://bugs.python.org/file30231/pep-0435.05.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 16:32:49 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 May 2013 14:32:49 +0000 Subject: [issue17606] xml.sax.saxutils.XMLGenerator cannot output with the correct encoding In-Reply-To: <1364767390.87.0.956919246275.issue17606@psf.upfronthosting.co.za> Message-ID: <3b7ngh2gZHz7Lk5@mail.python.org> Roundup Robot added the comment: New changeset a32a3b79f5e8 by Serhiy Storchaka in branch '2.7': Issue #17606: Fixed support of encoded byte strings in the XMLGenerator http://hg.python.org/cpython/rev/a32a3b79f5e8 New changeset e730447caf20 by Serhiy Storchaka in branch '3.3': Issue #17606: Fixed support of encoded byte strings in the XMLGenerator http://hg.python.org/cpython/rev/e730447caf20 New changeset 00afa5350f6a by Serhiy Storchaka in branch 'default': Issue #17606: Fixed support of encoded byte strings in the XMLGenerator http://hg.python.org/cpython/rev/00afa5350f6a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 16:41:42 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 May 2013 14:41:42 +0000 Subject: [issue17606] xml.sax.saxutils.XMLGenerator doesn't support byte strings In-Reply-To: <1364767390.87.0.956919246275.issue17606@psf.upfronthosting.co.za> Message-ID: <1368369702.1.0.0129469767047.issue17606@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Sebastian for your report and patch. ---------- assignee: -> serhiy.storchaka components: +Library (Lib) resolution: -> fixed stage: -> committed/rejected status: open -> closed title: xml.sax.saxutils.XMLGenerator cannot output with the correct encoding -> xml.sax.saxutils.XMLGenerator doesn't support byte strings type: crash -> behavior versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 16:44:58 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sun, 12 May 2013 14:44:58 +0000 Subject: [issue17962] Broken OpenSSL version in Windows builds In-Reply-To: <1368357845.04.0.941311125595.issue17962@psf.upfronthosting.co.za> Message-ID: <1368369898.0.0.769481668973.issue17962@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: The following patch will make use of 1.0.1e version of OpenSSL ---------- keywords: +patch nosy: +Yogesh.Chaudhari Added file: http://bugs.python.org/file30232/issue17962.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 16:52:01 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 May 2013 14:52:01 +0000 Subject: [issue17838] Can't assign a different value for sys.stdin in IDLE In-Reply-To: <1366872984.94.0.234893757031.issue17838@psf.upfronthosting.co.za> Message-ID: <1368370321.48.0.850445393682.issue17838@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I mean applying both issue17585 and issue17838 patches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 17:07:24 2013 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 12 May 2013 15:07:24 +0000 Subject: [issue17959] Alternate approach to aliasing for PEP 435 In-Reply-To: <1368341497.6.0.896861896968.issue17959@psf.upfronthosting.co.za> Message-ID: <1368371244.08.0.608179008027.issue17959@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 17:42:49 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 May 2013 15:42:49 +0000 Subject: [issue17956] add ScheduledExecutor In-Reply-To: <1368294342.98.0.976753460934.issue17956@psf.upfronthosting.co.za> Message-ID: <1368373369.28.0.0665858917326.issue17956@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: 1. Extends an abstract interface to support of a priority and absolute time. 2. Subclass sched.scheduler from this interface and implement missing methods. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 17:53:16 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 12 May 2013 15:53:16 +0000 Subject: [issue17956] add ScheduledExecutor In-Reply-To: <1368294342.98.0.976753460934.issue17956@psf.upfronthosting.co.za> Message-ID: <1368373996.25.0.469266485145.issue17956@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 18:06:06 2013 From: report at bugs.python.org (Stefan Drees) Date: Sun, 12 May 2013 16:06:06 +0000 Subject: [issue17128] OS X system openssl deprecated - installer should build local libssl In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za> Message-ID: <1368374766.0.0.781465051579.issue17128@psf.upfronthosting.co.za> Changes by Stefan Drees : ---------- nosy: +dilettant _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 18:07:01 2013 From: report at bugs.python.org (Stefan Drees) Date: Sun, 12 May 2013 16:07:01 +0000 Subject: [issue17959] Alternate approach to aliasing for PEP 435 In-Reply-To: <1368341497.6.0.896861896968.issue17959@psf.upfronthosting.co.za> Message-ID: <1368374821.56.0.694801872412.issue17959@psf.upfronthosting.co.za> Changes by Stefan Drees : ---------- nosy: +dilettant _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 18:12:43 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 12 May 2013 16:12:43 +0000 Subject: [issue17959] Alternate approach to aliasing for PEP 435 In-Reply-To: <1368341497.6.0.896861896968.issue17959@psf.upfronthosting.co.za> Message-ID: <1368375163.0.0.604304300088.issue17959@psf.upfronthosting.co.za> Antoine Pitrou added the comment: That's way too much magic for my taste. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 18:13:06 2013 From: report at bugs.python.org (Stefan Drees) Date: Sun, 12 May 2013 16:13:06 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368375186.47.0.469830250421.issue17914@psf.upfronthosting.co.za> Changes by Stefan Drees : ---------- nosy: +dilettant _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 18:14:01 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 12 May 2013 16:14:01 +0000 Subject: [issue17959] Alternate approach to aliasing for PEP 435 In-Reply-To: <1368341497.6.0.896861896968.issue17959@psf.upfronthosting.co.za> Message-ID: <1368375241.33.0.544824948289.issue17959@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Also, since we currently don't forbid the following: >>> {'a': 1, 'a': 2} {'a': 2} I don't see why enums should be any different. Recommend closing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 18:15:07 2013 From: report at bugs.python.org (Stefan Drees) Date: Sun, 12 May 2013 16:15:07 +0000 Subject: [issue11016] stat module in C In-Reply-To: <1296039446.69.0.66523737586.issue11016@psf.upfronthosting.co.za> Message-ID: <1368375307.84.0.318617703841.issue11016@psf.upfronthosting.co.za> Changes by Stefan Drees : ---------- nosy: +dilettant _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 18:32:49 2013 From: report at bugs.python.org (Brett Cannon) Date: Sun, 12 May 2013 16:32:49 +0000 Subject: [issue17963] Deprecate the frame hack for implicitly getting module details In-Reply-To: <1368364153.58.0.131087315276.issue17963@psf.upfronthosting.co.za> Message-ID: <1368376369.6.0.450829809769.issue17963@psf.upfronthosting.co.za> Brett Cannon added the comment: If you read the docs for sys._getframe() (http://docs.python.org/3/library/sys.html#sys._getframe) we explicitly state that the function should be considered an implementation detail for CPython. While Nick doesn't want to argue from the VM angle, I will. I would prefer to not rely on this hack in the stdlib to not put the other VMs at a disadvantage. Nick also has a good point that it is at best a heuristic as you can fool it into using the wrong result. At minimum I think the keyword argument for the module being used should be provided and documented that if it isn't provided then pickling is wishy-washy based on how you call the function and that it is not cross-VM compatible. But knowing that users won't clearly read the docs if it just happens to work in the interpreter and that is partial luck because of the possible indirection issue Nick pointed out, I think it would be better to not rely upon sys._getframe() and just ask people to explicitly specify the module if they happen to care about pickling *and* are using the functional API for enums. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 18:36:37 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 12 May 2013 16:36:37 +0000 Subject: [issue10766] optparse uses %s in gettext calls In-Reply-To: <1293148753.14.0.11198082887.issue10766@psf.upfronthosting.co.za> Message-ID: <1368376597.15.0.716555992857.issue10766@psf.upfronthosting.co.za> Mark Lawrence added the comment: I don't understand this. Fixes have already been committed via #4391 but this fix couldn't go ahead. Can somebody please clarify the situation. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 18:49:16 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 12 May 2013 16:49:16 +0000 Subject: [issue11011] More functools functions In-Reply-To: <1295994742.19.0.341586360497.issue11011@psf.upfronthosting.co.za> Message-ID: <1368377356.75.0.526432766062.issue11011@psf.upfronthosting.co.za> Mark Lawrence added the comment: To summarize flip, const and identity won't happen, trampoline needs an external recipe or blog post and compose is the only one that's likely to happen. Opinions please gentlemen. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 18:58:34 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 12 May 2013 16:58:34 +0000 Subject: [issue8841] getopt errors should be specialized In-Reply-To: <1275007450.32.0.944656023036.issue8841@psf.upfronthosting.co.za> Message-ID: <1368377914.91.0.132250012175.issue8841@psf.upfronthosting.co.za> Mark Lawrence added the comment: #11371 was closed on 2011-03-21 so what if anything needs doing here? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 19:06:33 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sun, 12 May 2013 17:06:33 +0000 Subject: [issue9856] Change object.__format__(s) where s is non-empty to a TypeError In-Reply-To: <1284485218.75.0.159147258754.issue9856@psf.upfronthosting.co.za> Message-ID: <1368378393.7.0.988730083405.issue9856@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: @Eric: when you say: "If the type of the object really is "object", then it can use string formatting. It's only for non-objects that I want to add the error.". I am confused. Let me demonstrate what I'm thinking according to the statement above. First let us take a 'non-object': >>> integer=1 >>> type(integer) != object True As of now it returns the following: >>> integer.__format__(s) '1' Which seems natural. But after this patch should it return an error Also now consider an object: >>> f = object() >>> type(f) This will return the following after the patch as it does now which is: >>> f.__format__('') '' Does this mean that 'integer' should give an error, however, 'f' should give something that appears messy? I may be mistaken in my interpretation of the statement, so kindly let me know if there is something else that I am not clearly understanding. ---------- nosy: +Yogesh.Chaudhari _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 19:07:39 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sun, 12 May 2013 17:07:39 +0000 Subject: [issue9856] Change object.__format__(s) where s is non-empty to a TypeError In-Reply-To: <1284485218.75.0.159147258754.issue9856@psf.upfronthosting.co.za> Message-ID: <1368378459.97.0.0662670161551.issue9856@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: Please replace integer.__format__(s) with integer.__format__('') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 19:07:59 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 12 May 2013 17:07:59 +0000 Subject: [issue17956] add ScheduledExecutor In-Reply-To: <1368373369.28.0.0665858917326.issue17956@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > 1. Extends an abstract interface to support of a priority I'm not sure I see the use case for priority support, do you have a sample use case? Furthermore, the executor is backed by a thread pool, so tasks can be run concurrently. Finally, the ordering is based on real-clock time - not user-provided timefunc and delayfunc: so the probability of having identical scheduled time (priority is only used for ties) is virtually 0. > and absolute time. If you want and absolute time, you can simply do: p.schedule(abstime - time(), fn, args) I don't see the need to complicate the API. > 2. Subclass sched.scheduler from this interface and implement missing methods. There again, I don't see the need. The goal of ScheduledExecutor is to be consistent with the Executor interface and futures, not being backward-compatible with the sched module. Also, the sched module simply can't support some operations: for example, it's impossible to have the schedule.run() method wake up when a new event with a deadline easiest than the current one is inserted. Really, there is now reason to make it compatible or similar to the sched module: this will - it it gets accepted - effectively deprecate threading.Timer and the sched module (except that the later supports user-provided time and delay functions, I don't know how often those are used). ---------- Added file: http://bugs.python.org/file30233/scheduled-3.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 4b3238923b01 Lib/concurrent/futures/__init__.py --- a/Lib/concurrent/futures/__init__.py Fri May 10 19:57:44 2013 -0700 +++ b/Lib/concurrent/futures/__init__.py Sun May 12 18:49:56 2013 +0200 @@ -15,4 +15,5 @@ wait, as_completed) from concurrent.futures.process import ProcessPoolExecutor -from concurrent.futures.thread import ThreadPoolExecutor +from concurrent.futures.thread import (ScheduledThreadPoolExecutor, + ThreadPoolExecutor) diff -r 4b3238923b01 Lib/concurrent/futures/_base.py --- a/Lib/concurrent/futures/_base.py Fri May 10 19:57:44 2013 -0700 +++ b/Lib/concurrent/futures/_base.py Sun May 12 18:49:56 2013 +0200 @@ -4,6 +4,7 @@ __author__ = 'Brian Quinlan (brian at sweetapp.com)' import collections +import functools import logging import threading import time @@ -499,6 +500,87 @@ self._condition.notify_all() self._invoke_callbacks() + + at functools.total_ordering +class ScheduledFuture(Future): + """A future whose execution can be delayed, one-shot or periodic. + + ScheduledFutures support mutual ordering based on their scheduled execution + time, which makes them easy to use in e.g. priority queues. + """ + + def __init__(self, init_time, period=0, delay=0): + """Initializes the future. Should not be called by clients. + + Args: + init_time: The initial absolute execution time, in seconds since + epoch. + period: The execution period, in seconds. + delay: The execution delay, in seconds. + + If a period is given, then the task will be scheduled every `period` + seconds: each execution will start `period` seconds after the starting + time of the previous execution: there will be no drift incurred by the + amount of time the task takes to execute. + Conversely, if a delay is given, then there will always be `delay` + seconds between sequential executions: each execution will start + `delay` seconds after the ending time of the previous execution: there + will be a drift incurred by the amount of time the task takes to + execute. + If neither a period nor a delay are specified, then the execution will + occur exactly once (one-shot). + + The future's result can only be retrieved for one-shot execution, + since there's no meaningful result for periodic execution (for those, + calling result()/exception() will block until the future is cancelled). + """ + super().__init__() + self._sched_time = init_time + if period > 0: + # step > 0 => fixed rate + self._step = period + elif delay > 0: + # step < 0 => fixed delay + self._step = -delay + else: + # step == 0 => one-shot + self._step = 0 + + def is_periodic(self): + """Return True if the future execution is periodic.""" + return self._step != 0 + + def get_delay(self): + """Return the delay until the next scheduled execution, in seconds.""" + with self._condition: + return self._sched_time - time.time() + + def _get_sched_time(self): + with self._condition: + return self._sched_time + + def rearm(self): + """Re-arm a periodic future, preparing it for its next execution. + + Should only be used by Executor implementations and unit tests. + """ + with self._condition: + self._state = PENDING + if self._step > 0: + self._sched_time += self._step + else: + self._sched_time = time.time() - self._step + + def __eq__(self, other): + return self is other + + def __lt__(self, other): + return self._get_sched_time() < other._get_sched_time() + + def __hash__(self): + return id(self) + + class Executor(object): """This is an abstract base class for concrete asynchronous executors.""" @@ -569,3 +651,48 @@ def __exit__(self, exc_type, exc_val, exc_tb): self.shutdown(wait=True) return False + + +class ScheduledExecutor(Executor): + """This is an abstract base class for concrete asynchronous scheduled + executors.""" + + def schedule(self, delay, fn, *args, **kwargs): + """Submits a callable to be executed with the given arguments after the + given delay. + + Schedules the callable to be executed as fn(*args, **kwargs) and returns + a ScheduledFuture instance representing the execution of the callable. + + Returns: + A ScheduledFuture representing the given call. + """ + raise NotImplementedError() + + def schedule_fixed_rate(self, init_delay, period, fn, *args, **kwargs): + """Submits a callable to be executed with the given arguments after the + given delay, and then repeatedly at the given period. In other words, + each execution will start `period` seconds after the starting time of + the previous execution. + + Schedules the callable to be executed as fn(*args, **kwargs) and returns + a ScheduledFuture instance representing the execution of the callable. + + Returns: + A ScheduledFuture representing the given call. + """ + raise NotImplementedError() + + def schedule_fixed_delay(self, init_delay, delay, fn, *args, **kwargs): + """Submits a callable to be executed with the given arguments after the + given delay, and then repeatedly with the given delay between two + consecutive executions. In other words, each execution will start + `delay` seconds after the ending time of the previous execution. + + Schedules the callable to be executed as fn(*args, **kwargs) and returns + a ScheduledFuture instance representing the execution of the callable. + + Returns: + A ScheduledFuture representing the given call. + """ + raise NotImplementedError() diff -r 4b3238923b01 Lib/concurrent/futures/thread.py --- a/Lib/concurrent/futures/thread.py Fri May 10 19:57:44 2013 -0700 +++ b/Lib/concurrent/futures/thread.py Sun May 12 18:49:56 2013 +0200 @@ -7,8 +7,12 @@ import atexit from concurrent.futures import _base +import functools +import heapq import queue +import sys import threading +import time import weakref # Workers are created as daemon threads. This is done to allow the interpreter @@ -33,35 +37,120 @@ _shutdown = True items = list(_threads_queues.items()) for t, q in items: - q.put(None) + q.put(q.sentinel) for t, q in items: t.join() atexit.register(_python_exit) -class _WorkItem(object): - def __init__(self, future, fn, args, kwargs): - self.future = future - self.fn = fn - self.args = args - self.kwargs = kwargs +class _WorkItem(_base.Future): + + def __init__(self, fn, args, kwargs): + super().__init__() + self._fn = fn + self._args = args + self._kwargs = kwargs def run(self): - if not self.future.set_running_or_notify_cancel(): + if not self.set_running_or_notify_cancel(): return try: - result = self.fn(*self.args, **self.kwargs) + result = self._fn(*self._args, **self._kwargs) except BaseException as e: - self.future.set_exception(e) + self.set_exception(e) else: - self.future.set_result(result) + self.set_result(result) + + +class _WorkItemQueue(queue.Queue): + + sentinel = None + + +class _ScheduledWorkItem(_base.ScheduledFuture): + + def __init__(self, pool, fn, args, kwargs, init_time, period=0, delay=0): + super().__init__(init_time, period, delay) + self._fn = fn + self._args = args + self._kwargs = kwargs + self._pool = pool + + def run(self): + if not self.set_running_or_notify_cancel(): + return + + try: + result = self._fn(*self._args, **self._kwargs) + except BaseException as e: + self.set_exception(e) + else: + if self.is_periodic(): + # rearm and reschedule ourselves + self.rearm() + try: + self._pool._schedule(self) + except RuntimeError: + # pool shut down + pass + else: + # we only set the result in case of one-shot + self.set_result(result) + + +class _ScheduledWorkItemQueue: + """A wrapper around a priority queue, holding _ScheduledWorkItem ordered by + their scheduled execution time. + """ + + # the sentinel deadline must appear later than any other work deadline to + # let pending work finish (hence the sys.maxsize execution time), but it + # must be returned immediately when it's the head of the queue, see the + # get() method below + sentinel = _ScheduledWorkItem(None, None, None, None, sys.maxsize) + + def __init__(self): + self._queue = [] + self._available = threading.Condition() + + def put(self, work): + with self._available: + if self._queue: + first = self._queue[0] + else: + first = None + + heapq.heappush(self._queue, work) + + if first is None or work < first or first.cancelled(): + self._available.notify_all() + + def get(self, block=True): + with self._available: + while True: + if not self._queue: + self._available.wait() + else: + first = self._queue[0] + + delay = first.get_delay() + + if (delay <= 0 or first is self.sentinel or + first.cancelled()): + heapq.heappop(self._queue) + if self._queue: + self._available.notify_all() + return first + else: + self._available.wait(delay) + def _worker(executor_reference, work_queue): try: while True: work_item = work_queue.get(block=True) - if work_item is not None: + if work_item is not work_queue.sentinel: work_item.run() # Delete references to object. See issue16284 del work_item @@ -73,7 +162,7 @@ # - The executor that owns the worker has been shutdown. if _shutdown or executor is None or executor._shutdown: # Notice other workers - work_queue.put(None) + work_queue.put(work_queue.sentinel) return del executor except BaseException: @@ -88,7 +177,7 @@ execute the given calls. """ self._max_workers = max_workers - self._work_queue = queue.Queue() + self._work_queue = _WorkItemQueue() self._threads = set() self._shutdown = False self._shutdown_lock = threading.Lock() @@ -98,19 +187,18 @@ if self._shutdown: raise RuntimeError('cannot schedule new futures after shutdown') - f = _base.Future() - w = _WorkItem(f, fn, args, kwargs) + w = _WorkItem(fn, args, kwargs) self._work_queue.put(w) self._adjust_thread_count() - return f + return w submit.__doc__ = _base.Executor.submit.__doc__ def _adjust_thread_count(self): # When the executor gets lost, the weakref callback will wake up # the worker threads. def weakref_cb(_, q=self._work_queue): - q.put(None) + q.put(q.sentinel) # TODO(bquinlan): Should avoid creating new threads if there are more # idle threads than items in the work queue. if len(self._threads) < self._max_workers: @@ -125,8 +213,49 @@ def shutdown(self, wait=True): with self._shutdown_lock: self._shutdown = True - self._work_queue.put(None) + self._work_queue.put(self._work_queue.sentinel) if wait: for t in self._threads: t.join() shutdown.__doc__ = _base.Executor.shutdown.__doc__ + + +class ScheduledThreadPoolExecutor(ThreadPoolExecutor): + + def __init__(self, max_workers): + """Initializes a new ScheduledThreadPoolExecutor instance. + + Args: + max_workers: The maximum number of threads that can be used to + execute the given calls. + """ + super().__init__(max_workers) + self._work_queue = _ScheduledWorkItemQueue() + + def submit(self, fn, *args, **kwargs): + return self.schedule(0, fn, *args, **kwargs) + + def schedule(self, init_delay, fn, *args, **kwargs): + w = _ScheduledWorkItem(self, fn, args, kwargs, time.time() + init_delay) + self._schedule(w) + return w + + def schedule_fixed_rate(self, init_delay, period, fn, *args, **kwargs): + w = _ScheduledWorkItem(self, fn, args, kwargs, time.time() + init_delay, + period=period) + self._schedule(w) + return w + + def schedule_fixed_delay(self, init_delay, delay, fn, *args, **kwargs): + w = _ScheduledWorkItem(self, fn, args, kwargs, time.time() + init_delay, + delay=delay) + self._schedule(w) + return w + + def _schedule(self, w): + with self._shutdown_lock: + if self._shutdown: + raise RuntimeError('cannot schedule new futures after shutdown') + + self._work_queue.put(w) + self._adjust_thread_count() diff -r 4b3238923b01 Lib/test/test_concurrent_futures.py --- a/Lib/test/test_concurrent_futures.py Fri May 10 19:57:44 2013 -0700 +++ b/Lib/test/test_concurrent_futures.py Sun May 12 18:49:56 2013 +0200 @@ -11,6 +11,7 @@ from test.script_helper import assert_python_ok +from collections import defaultdict import sys import threading import time @@ -58,6 +59,34 @@ pass +class RefAccumulator: + + """An helper class to record events.""" + + def __init__(self): + self._result = defaultdict(list) + self._lock = threading.Lock() + + def add(self, key, delay): + with self._lock: + self._result[key].append(delay) + + def result(self): + with self._lock: + return self._result + + +class TimedAccumulator(RefAccumulator): + + def __init__(self): + super().__init__() + self._init_time = time.time() + + def add(self, key): + with self._lock: + self._result[key].append(time.time() - self._init_time) + + class ExecutorMixin: worker_count = 5 @@ -85,11 +114,26 @@ for f in futures: f.result() + def assertDelay(self, actual, expected): + # The waiting and/or time.time() can be imprecise, which + # is why comparing to the expected value would sometimes fail + # (especially under Windows). + # account for 0 timeout + expected = max(expected, 0.01) + actual = max(actual, 0.01) + self.assertGreaterEqual(actual, expected * 0.6) + # Test nothing insane happened + self.assertLess(actual, expected * 10.0) + class ThreadPoolMixin(ExecutorMixin): executor_type = futures.ThreadPoolExecutor +class ScheduledThreadPoolMixin(ExecutorMixin): + executor_type = futures.ScheduledThreadPoolExecutor + + class ProcessPoolMixin(ExecutorMixin): executor_type = futures.ProcessPoolExecutor @@ -122,10 +166,7 @@ f.result() -class ThreadPoolShutdownTest(ThreadPoolMixin, ExecutorShutdownTest): - def _prime_executor(self): - pass - +class BaseThreadPoolShutdownTest(ExecutorShutdownTest): def test_threads_terminate(self): self.executor.submit(mul, 21, 2) self.executor.submit(mul, 6, 7) @@ -153,6 +194,17 @@ for t in threads: t.join() +class ThreadPoolShutdownTest(ThreadPoolMixin, BaseThreadPoolShutdownTest): + def _prime_executor(self): + pass + + +class ScheduledThreadPoolShutdownTest(ScheduledThreadPoolMixin, + BaseThreadPoolShutdownTest): + def _prime_executor(self): + pass + + class ProcessPoolShutdownTest(ProcessPoolMixin, ExecutorShutdownTest): def _prime_executor(self): @@ -291,7 +343,7 @@ self.assertEqual(set([future2]), pending) -class ThreadPoolWaitTests(ThreadPoolMixin, WaitTests): +class BaseThreadPoolWaitTests(WaitTests): def test_pending_calls_race(self): # Issue #14406: multi-threaded race condition when waiting on all @@ -309,6 +361,12 @@ sys.setswitchinterval(oldswitchinterval) +class ThreadPoolWaitTests(ThreadPoolMixin, BaseThreadPoolWaitTests): + pass + +class ScheduledThreadPoolWaitTests(ScheduledThreadPoolMixin, BaseThreadPoolWaitTests): + pass + class ProcessPoolWaitTests(ProcessPoolMixin, WaitTests): pass @@ -355,6 +413,10 @@ pass +class ScheduledThreadPoolAsCompletedTests(ScheduledThreadPoolMixin, + AsCompletedTests): + pass + class ProcessPoolAsCompletedTests(ProcessPoolMixin, AsCompletedTests): pass @@ -445,6 +507,143 @@ self.assertRaises(BrokenProcessPool, self.executor.submit, pow, 2, 8) +class ScheduledThreadPoolExecutorTest(ScheduledThreadPoolMixin, + unittest.TestCase): + + # some of the tests below create many events, bump the number of workers to + # keep up + worker_count = 10 + + def compare_accumulators(self, actual, expected, strict=True): + expected = expected.result() + actual = actual.result() + + self.assertEqual(actual.keys(), expected.keys()) + for key in actual: + expected_delays = sorted(expected[key]) + actual_delays = sorted(actual[key]) + if strict: + # in strict mode, the number of events must match exactly for + # each key + tolerance = 0 + else: + # otherwise, we tolerate an offset, due to timing and rounding + # errors: this is useful for timing-dependent tests + tolerance = 1 + + self.assertLessEqual(abs(len(actual_delays) - len(expected_delays)), + tolerance) + for actual_delay, expected_delay in zip(actual_delays, + expected_delays): + self.assertDelay(actual_delay, expected_delay) + + def test_schedule(self): + acc = TimedAccumulator() + expected = RefAccumulator() + NB = 100 + + for i in range(NB): + self.executor.schedule(i/NB, acc.add, i) + expected.add(i, i/NB) + + self.executor.shutdown(wait=True) + self.compare_accumulators(acc, expected) + + def test_schedule_result(self): + expected = {} + NB = 100 + + for i in range(NB): + f = self.executor.schedule(i/NB, lambda i: i, i) + expected[f] = i + + self.executor.shutdown(wait=True) + self.assertEqual(expected, dict((f, f.result()) for f in expected)) + + def test_schedule_fixed_rate(self): + acc = TimedAccumulator() + expected = RefAccumulator() + NB = 10 + RUN_TIME = 2 + + for i in range(1, NB+1): + self.executor.schedule_fixed_rate(0, RUN_TIME * i/NB, acc.add, i) + # let's compute future dealines during the RUN_TIME period + for n in range(int(NB/i) + 2): + expected.add(i, n*RUN_TIME*i/NB) + + time.sleep(RUN_TIME) + + self.executor.shutdown(wait=True) + self.compare_accumulators(acc, expected, False) + + def test_schedule_fixed_delay(self): + acc = TimedAccumulator() + expected = RefAccumulator() + NB = 10 + RUN_TIME = 2 + + for i in range(1, NB+1): + self.executor.schedule_fixed_delay(0, RUN_TIME*i/NB, acc.add, i) + # let's compute future dealines during the RUN_TIME period + for n in range(int(NB/i)+2): + expected.add(i, n*RUN_TIME*i/NB) + + time.sleep(RUN_TIME) + + self.executor.shutdown(wait=True) + self.compare_accumulators(acc, expected, False) + + def test_schedule_fixed_delay_drift(self): + acc = TimedAccumulator() + expected = RefAccumulator() + NB = 10 + RUN_TIME = 2 + DRIFT = 0.1 + + def delayed_add(i): + time.sleep(DRIFT) + acc.add(i) + + for i in range(1, NB+1): + self.executor.schedule_fixed_delay(0, RUN_TIME*i/NB, delayed_add, i) + # let's compute future dealines during the RUN_TIME period, taking + # DRIFT drit into account + for nb in range(int(RUN_TIME/(RUN_TIME*i/NB + DRIFT))+2): + expected.add(i, nb*(RUN_TIME*i/NB+DRIFT)+DRIFT) + + time.sleep(RUN_TIME) + + self.executor.shutdown(wait=True) + self.compare_accumulators(acc, expected, False) + + def test_cancel(self): + acc = TimedAccumulator() + expected = RefAccumulator() + NB = 100 + futures = [] + RUN_TIME = 5 + + for _ in range(0, NB, 3): + f = self.executor.schedule(0.1, acc.add, 1) + futures.append(f) + expected.add(1, 0.1) + f = self.executor.schedule_fixed_rate(0.2, 1000, acc.add, 2) + futures.append(f) + expected.add(2, 0.2) + f = self.executor.schedule_fixed_delay(0.3, 1000, acc.add, 3) + futures.append(f) + expected.add(3, 0.3) + + time.sleep(RUN_TIME) + + for f in futures: + f.cancel() + + self.executor.shutdown(wait=True) + self.compare_accumulators(acc, expected, False) + + class FutureTests(unittest.TestCase): def test_done_callback_with_result(self): callback_result = None @@ -674,11 +873,15 @@ ThreadPoolExecutorTest, ProcessPoolWaitTests, ThreadPoolWaitTests, + ScheduledThreadPoolWaitTests, ProcessPoolAsCompletedTests, ThreadPoolAsCompletedTests, + ScheduledThreadPoolAsCompletedTests, FutureTests, ProcessPoolShutdownTest, ThreadPoolShutdownTest, + ScheduledThreadPoolShutdownTest, + ScheduledThreadPoolExecutorTest, ) finally: test.support.reap_children() From report at bugs.python.org Sun May 12 19:48:48 2013 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 12 May 2013 17:48:48 +0000 Subject: [issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function In-Reply-To: <1367269025.02.0.400879045482.issue17870@psf.upfronthosting.co.za> Message-ID: <1368380928.98.0.504161803677.issue17870@psf.upfronthosting.co.za> Mark Dickinson added the comment: Some comments for the first patch (I haven't really looked at the second): - I would much prefer PyLong_AsIntMax_t not to use nb_int; it should work only for instances of 'int' (just as PyLong_AsSsize_t and PyLong_AsSize_t currently do). - There's a missing 'versionadded' for PyLong_AsIntMax_t in the docs. - Will AC_CHECK_SIZEOF(intmax_t) work on platforms that don't define intmax_t? I don't know whether the #define created by the earlier AC_TYPE_INTMAX_T is available at that point. We'll probably find out from the buildbots. - Do we also need an addition to PC/pyconfig.h to define (u)intmax_t and SIZEOF_(U)INTMAX_T on Windows? - For the PyLong_As* functions, it may be more efficient to code the conversion directly instead of using _PyLong_AsByteArray. - The PyLong_As* functions assume that intmax_t and uintmax_t have no padding bits, no trap representation, and (in the case of intmax_t) use two's complement. I think it's fine to assume all these things, but we should also either document or test those assumptions. - The patch lacks tests. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 19:55:18 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 May 2013 17:55:18 +0000 Subject: [issue17962] Broken OpenSSL version in Windows builds In-Reply-To: <1368357845.04.0.941311125595.issue17962@psf.upfronthosting.co.za> Message-ID: <3b7t9L13skz7Lkc@mail.python.org> Roundup Robot added the comment: New changeset d047928ae3f6 by Georg Brandl in branch '3.3': Closes #17962: Build with OpenSSL 1.0.1e on Windows. http://hg.python.org/cpython/rev/d047928ae3f6 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 20:53:30 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sun, 12 May 2013 18:53:30 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368384810.6.0.616437435565.issue17914@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: @STINNER: I don't understand. Where exactly should the patch handle this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 21:22:24 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 12 May 2013 19:22:24 +0000 Subject: [issue17890] argparse: mutually exclusive groups full of suppressed args can cause AssertionErrors In-Reply-To: <1367455382.45.0.0611766927148.issue17890@psf.upfronthosting.co.za> Message-ID: <1368386544.07.0.717200044395.issue17890@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Argparse is out of my area of competence/experience. I have added a couple of people who have worked on argparse in the past and should be better able to review or suggest another reviewer. ---------- nosy: +bethard, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 21:25:42 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 May 2013 19:25:42 +0000 Subject: [issue11489] json.dumps not parsable by json.loads (on Linux only) In-Reply-To: <1300058240.59.0.513243746739.issue11489@psf.upfronthosting.co.za> Message-ID: <1368386742.01.0.608850282456.issue11489@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here are updated patches from issue17906. Updated tests, fixed a bug reported by Bob Ippolito in msg188857 and fixed inconsistency noted by Ezio Melotti on Rietveld (Python implementation now raises same exception as C implementation on illegal hexadecimal escape). ---------- Added file: http://bugs.python.org/file30234/json_decode_lone_surrogates_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 21:26:33 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 May 2013 19:26:33 +0000 Subject: [issue11489] json.dumps not parsable by json.loads (on Linux only) In-Reply-To: <1300058240.59.0.513243746739.issue11489@psf.upfronthosting.co.za> Message-ID: <1368386793.95.0.749444169708.issue11489@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file30235/json_decode_lone_surrogates_2-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 21:27:13 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 May 2013 19:27:13 +0000 Subject: [issue11489] json.dumps not parsable by json.loads (on Linux only) In-Reply-To: <1300058240.59.0.513243746739.issue11489@psf.upfronthosting.co.za> Message-ID: <1368386833.3.0.424281103588.issue11489@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Extension Modules stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 21:28:20 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 12 May 2013 19:28:20 +0000 Subject: [issue17906] JSON should accept lone surrogates In-Reply-To: <1367678308.48.0.934181281887.issue17906@psf.upfronthosting.co.za> Message-ID: <1368386900.59.0.682496531647.issue17906@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch submitted in issue11489. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 21:31:20 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 12 May 2013 19:31:20 +0000 Subject: [issue17956] add ScheduledExecutor In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: I'd like to have your opinion regarding some implementation choices I made. 1) There's a new ScheduledFuture deriving from Future, which adds methods to check if the task is periodic, to get the delay until the next scheduled execution, support re-arming (for periodic tasks), and finally is orderable with respect to the scheduled time. ScheduledExecutor methods (submit(), schedule(), schedule_fixed_rate() and schedule_fixed_delay()) return a ScheduledFuture instance. That's an addition to the API. Is that acceptable? If not, one solution would be make _ScheduledFuture private, and document those methods as returning a base Future (but then the client can't query periodicity, next scheduled time, etc). 2) In the latest version of the patch, I changed _WorkerItem and _ScheduledWorkerItem to subclass Future and ScheduledFuture. The reason is that when you look at the code, those wrapper just add a run method to the future, but otherwise just delegate to the wrapped future. In fact, a work item is just a runnable future, so why not subclass it? Also, for example for the scheduled executor, you want to maintain work items in wrapped-future scheduled time order (i.e. the soonest expiring future at the head of the queue), and easily if the wrapped future is cancelled, or get its delay: So you have to do something like: """ @functools.total_ordering class _ScheduledWorkItem(_WorkItem): [...] def run(self): if not self.future.set_running_or_notify_cancel(): return try: result = self.fn(*self.args, **self.kwargs) except BaseException as e: self.future.set_exception(e) else: if self.future.is_periodic(): # rearm the future self.future.rearm() # and re-schedule ourselves try: self._pool._schedule(self) except RuntimeError: # pool shut down pass else: # we only set the result in case of one-shot self.future.set_result(result) def __eq__(self, other): return self is other def __lt__(self, other): return self.future < other.future def get_delay(self): return self.future.get_delay() def cancelled(self): return self.future.cancelled() """ Basically, this object merely delegate to the wrapped future. Instead, if the work item is a subclass of Future, it looks like: """ class _ScheduledWorkItem(_base.ScheduledFuture): [...] def run(self): if not self.set_running_or_notify_cancel(): return try: result = self._fn(*self._args, **self._kwargs) except BaseException as e: self.set_exception(e) else: if self.is_periodic(): # rearm and reschedule ourselves self.rearm() try: self._pool._schedule(self) except RuntimeError: # pool shut down pass else: # we only set the result in case of one-shot self.set_result(result) """ And to return a future from submit(), instead of: """ f = _base.Future() w = _WorkItem(f, fn, args, kwargs) self._work_queue.put(w) self._adjust_thread_count() return f """ You just do: """ w = _WorkItem(fn, args, kwargs) self._work_queue.put(w) self._adjust_thread_count() return w """ The work item inherits all the necessary methods and behavior (like order) from the future. It looks much more natural to me. Also, you don't have to create two objects (the future and the wrapper work item) per submitted task, so you save some memory, and maybe some CPU cycles too. I see the following downsides: - you don't return a base Future, but a subclass. But to me, Future is more of an interface than an implementation, see e.g. Tulip's futures - since the function and arguments are stored in the work item, this keeps references to them as long as the returned future is alive. That could be a problem for code expecting the passed fn/args/kwargs to be collected in a timely manner (see e.g. #16284 for a database collection), but it could be solved easily by having the worker's run method explicitly clear those references after execution (except for periodic execution of course). What do you think (sorry for the long message ;-) ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 22:01:53 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sun, 12 May 2013 20:01:53 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368388913.12.0.942513511205.issue17914@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: Modified patch based on review by neologix ---------- Added file: http://bugs.python.org/file30236/issue17914-4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 22:18:17 2013 From: report at bugs.python.org (Jan Gosmann) Date: Sun, 12 May 2013 20:18:17 +0000 Subject: [issue17396] modulefinder fails if module contains syntax error In-Reply-To: <1363003425.82.0.865184669213.issue17396@psf.upfronthosting.co.za> Message-ID: <1368389897.18.0.656566294619.issue17396@psf.upfronthosting.co.za> Jan Gosmann added the comment: Here is an updated patch, also containing a test. ---------- Added file: http://bugs.python.org/file30237/fix-handling-of-syntax-errors.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 22:19:21 2013 From: report at bugs.python.org (Jan Gosmann) Date: Sun, 12 May 2013 20:19:21 +0000 Subject: [issue17396] modulefinder fails if module contains syntax error In-Reply-To: <1363003425.82.0.865184669213.issue17396@psf.upfronthosting.co.za> Message-ID: <1368389961.16.0.254776353216.issue17396@psf.upfronthosting.co.za> Jan Gosmann added the comment: It's based on the default branch becoming 3.4. ---------- versions: +Python 3.4 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 22:29:34 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sun, 12 May 2013 20:29:34 +0000 Subject: [issue13461] Error on test_issue_1395_5 with Python 2.7 and VS2010 In-Reply-To: <1322056958.99.0.498945300571.issue13461@psf.upfronthosting.co.za> Message-ID: <1368390574.89.0.578971121719.issue13461@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: This patch should work for 2.7 branch ---------- hgrepos: +191 keywords: +patch nosy: +Yogesh.Chaudhari Added file: http://bugs.python.org/file30238/issue13461-27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 22:41:22 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sun, 12 May 2013 20:41:22 +0000 Subject: [issue13461] Error on test_issue_1395_5 with Python 2.7 and VS2010 In-Reply-To: <1322056958.99.0.498945300571.issue13461@psf.upfronthosting.co.za> Message-ID: <1368391282.45.0.490517513446.issue13461@psf.upfronthosting.co.za> Changes by Yogesh Chaudhari : ---------- hgrepos: -191 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 22:43:15 2013 From: report at bugs.python.org (Eric V. Smith) Date: Sun, 12 May 2013 20:43:15 +0000 Subject: [issue9856] Change object.__format__(s) where s is non-empty to a TypeError In-Reply-To: <1284485218.75.0.159147258754.issue9856@psf.upfronthosting.co.za> Message-ID: <1368391395.87.0.483451609335.issue9856@psf.upfronthosting.co.za> Eric V. Smith added the comment: But int has its own __format__ method, so this does not apply. Per the title of this issue, this only refers to object.__format__. For example: This works now, and will continue working: >>> format(2, '1') '2' This is currently an error, and will remain an error: >>> class C: pass ... >>> format(C(), '1') Traceback (most recent call last): File "", line 1, in TypeError: non-empty format string passed to object.__format__ It's this case that is currently an error, but it need not be: >>> format(object(), '1') Traceback (most recent call last): File "", line 1, in TypeError: non-empty format string passed to object.__format__ The more I think about it, the more I think it would be too confusing to make object.__format__ behave differently if self is of type object, versus another type. So I'll probably just close this as fixed unless someone feels strongly about it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 22:57:23 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sun, 12 May 2013 20:57:23 +0000 Subject: [issue13461] Error on test_issue_1395_5 with Python 2.7 and VS2010 In-Reply-To: <1322056958.99.0.498945300571.issue13461@psf.upfronthosting.co.za> Message-ID: <1368392243.29.0.0109464950438.issue13461@psf.upfronthosting.co.za> Changes by Yogesh Chaudhari : Added file: http://bugs.python.org/file30239/issue13461-3x.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 23:19:48 2013 From: report at bugs.python.org (Simon Conseil) Date: Sun, 12 May 2013 21:19:48 +0000 Subject: [issue17915] Encoding error with sax and codecs In-Reply-To: <1367838846.54.0.113997926456.issue17915@psf.upfronthosting.co.za> Message-ID: <1368393588.94.0.850641114953.issue17915@psf.upfronthosting.co.za> Simon Conseil added the comment: thanks everybody ! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 23:25:37 2013 From: report at bugs.python.org (paul j3) Date: Sun, 12 May 2013 21:25:37 +0000 Subject: [issue17890] argparse: mutually exclusive groups full of suppressed args can cause AssertionErrors In-Reply-To: <1367455382.45.0.0611766927148.issue17890@psf.upfronthosting.co.za> Message-ID: <1368393937.34.0.696196004359.issue17890@psf.upfronthosting.co.za> paul j3 added the comment: I'm following a dozen argparse issues with patches. I haven't seen much posting by argparse experts (like bethard, david.murry) since last December. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 23:35:24 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sun, 12 May 2013 21:35:24 +0000 Subject: [issue17940] extra code in argparse.py In-Reply-To: <1368052350.83.0.843381398629.issue17940@psf.upfronthosting.co.za> Message-ID: <1368394524.47.0.525750604685.issue17940@psf.upfronthosting.co.za> Changes by Yogesh Chaudhari : ---------- hgrepos: -190 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 23:41:23 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sun, 12 May 2013 21:41:23 +0000 Subject: [issue17890] argparse: mutually exclusive groups full of suppressed args can cause AssertionErrors In-Reply-To: <1367455382.45.0.0611766927148.issue17890@psf.upfronthosting.co.za> Message-ID: <1368394883.86.0.0479134637365.issue17890@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: @terry and @paul: I have 2 argparse related patches, sitting idle for quiet sometime now. Can you suggest any more names who can take this forward? (I could not find anyone else related to argparse in http://docs.python.org/devguide/experts.html) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 23:57:15 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Sun, 12 May 2013 21:57:15 +0000 Subject: [issue17961] Use enum names as values in enum.Enum convenience API In-Reply-To: <1368356222.14.0.0972295622627.issue17961@psf.upfronthosting.co.za> Message-ID: <1368395835.84.0.512782221901.issue17961@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 12 23:59:10 2013 From: report at bugs.python.org (STINNER Victor) Date: Sun, 12 May 2013 21:59:10 +0000 Subject: [issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function In-Reply-To: <1367269025.02.0.400879045482.issue17870@psf.upfronthosting.co.za> Message-ID: <1368395950.56.0.61190878368.issue17870@psf.upfronthosting.co.za> STINNER Victor added the comment: Version 2 of my patch: Mark> - I would much prefer PyLong_AsIntMax_t not to use nb_int; Mark> it should work only for instances of 'int' (just as Mark> PyLong_AsSsize_t and PyLong_AsSize_t currently do)." I copied code from PyLong_AsLongLong(), but doc from PyLong_AsLong() :-/ Some PyLong_As*() functions call __int__(), but not all? It is a little bit surprising to have a different behaviour, but Mark has a longer experience in these APIs and so I trust him :-) I changed my code to only accept PyLongObject. Mark> There's a missing 'versionadded' for PyLong_AsIntMax_t in the docs. fixed Mark> Will AC_CHECK_SIZEOF(intmax_t) work on platforms that Mark> don't define intmax_t? I don't know whether the #define Mark> created by the earlier AC_TYPE_INTMAX_T is available at Mark> that point. We'll probably find out from the buildbots. I tested with a typo in configure.ac: AC_CHECK_SIZEOF(uintmax32_t) configure result: checking size of uintmax32_t... 0 pyconfig.h: #define SIZEOF_UINTMAX32_T 0 Should we undefine SIZEOF_UINTMAX32_T (in pyport.h) if its value is zero? Mark> Do we also need an addition to PC/pyconfig.h to define (u)intmax_t Mark> and SIZEOF_(U)INTMAX_T on Windows? Ah yes, I forgot Windows, but I don't have access to a Windows box right now. I modified PC/pyconfig.h, but I cannot test my patch. I suppose that intmax_t and uintmax_t don't need to be defined (using typedef) with Visual Studio 2010 or later, since stdint.h is available. For the SIZEOF, I chose 64 bits and added a new test in _testcapi (for all platforms). It looks like there is no platform with (hardware) 128 bits integer, and 64-bit on Windows should be correct. On Linux 64-bit, __int128 is available, but the size of intmax_t is 64 bits. Mark> For the PyLong_As* functions, it may be more efficient to code the conversion directly instead of using _PyLong_AsByteArray. I copied code from PyLong_AsLongLong and PyLong_AsUnsignedLongLong. If the code is changed, I would prefer to change the 4 PyLong_As*() functions at the same time. Don't you think so? > The PyLong_As* functions assume that intmax_t and uintmax_t have no padding bits, no trap representation, and (in the case of intmax_t) use two's complement. I think it's fine to assume all these things, but we should also either document or test those assumptions. What is a "trap representation"? I only know "two's complement". What are the other kinds? How should we test those assumptions? > The patch lacks tests. Which kind of test do you see? Would you like to help me to implement this new feature? ---------- Added file: http://bugs.python.org/file30240/intmax_t-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 00:00:29 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Sun, 12 May 2013 22:00:29 +0000 Subject: [issue17961] Use enum names as values in enum.Enum convenience API In-Reply-To: <1368356222.14.0.0972295622627.issue17961@psf.upfronthosting.co.za> Message-ID: <20130512180026.60377cd4@limelight.wooz.org> Barry A. Warsaw added the comment: On May 12, 2013, at 10:57 AM, Nick Coghlan wrote: >I encountered an interesting suggestion [1] regarding the enum.Enum >convenience API: use the member names as their values, rather than the >current integers starting from one. > >Since we're now using definition order rather than value order for iteration, >this suggestion makes a lot of sense to me. Cute, but I want the functional API to be equivalent to the class syntax. Besides: X = Enum('X', ((name, name) for name in 'ant bee cat dog elk'.split())) is not so much typing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 00:06:22 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sun, 12 May 2013 22:06:22 +0000 Subject: [issue9856] Change object.__format__(s) where s is non-empty to a TypeError In-Reply-To: <1284485218.75.0.159147258754.issue9856@psf.upfronthosting.co.za> Message-ID: <1368396382.88.0.0798872466725.issue9856@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: >It's this case that is currently an error, but it need not be: >>>> format(object(), '1') >Traceback (most recent call last): > File "", line 1, in >TypeError: non-empty format string passed to object.__format__ I believe that should continue to remain an error. Please note that this works >>> format(object(), '') '' >From what I can tell, specifying '1' or '2' or '100' makes no sense because unlike string or int (and like list or tuple ) this 'number' does not represent anything sensible. This works fine as it should: >>> format('q', '5') 'q ' >>> format(1, '5') ' 1' >>> format(1, '05') '00001' >>> But this does not and IMHO *should* not 'work' >>> format([1,2,3], '5') Traceback (most recent call last): File "", line 1, in TypeError: non-empty format string passed to object.__format__ >>> format((1,2,3), '5') Traceback (most recent call last): File "", line 1, in TypeError: non-empty format string passed to object.__format__ an object() CANNOT have specific behavior like str or int. You can of-course argue as to what kind of error/exception/warning this may raise, but it does not make any sense (AFAIK) to 'fix' this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 01:14:59 2013 From: report at bugs.python.org (Martin Morrison) Date: Sun, 12 May 2013 23:14:59 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1368400499.67.0.702214456415.issue17927@psf.upfronthosting.co.za> Martin Morrison added the comment: The latest diff (cellfree4.diff) applies correctly to 3.3 (one hunk fails, but it's just the one where you've removed a blank line). The tests also pass successfully with the diff applied. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 01:18:16 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 12 May 2013 23:18:16 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <3b81Kz40C6z7LlY@mail.python.org> Roundup Robot added the comment: New changeset f6223bab5657 by Benjamin Peterson in branch 'default': when an argument is a cell, set the local copy to NULL (see #17927) http://hg.python.org/cpython/rev/f6223bab5657 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 01:21:49 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 23:21:49 +0000 Subject: [issue17959] Alternate approach to aliasing for PEP 435 In-Reply-To: <1368375241.33.0.544824948289.issue17959@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: The difference is the use case: dicts are a general purpose data store, enums are typically for defining mutually exclusive named values, with aliasing as a concession to practical reality. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 01:24:21 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 12 May 2013 23:24:21 +0000 Subject: [issue17961] Use enum names as values in enum.Enum convenience API In-Reply-To: <20130512180026.60377cd4@limelight.wooz.org> Message-ID: Nick Coghlan added the comment: That gives the unqualified names, and I don't understand your other objection. The class syntax doesn't support implicit values at all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 01:24:59 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sun, 12 May 2013 23:24:59 +0000 Subject: [issue12634] Random Remarks in class documentation In-Reply-To: <1311575810.71.0.0727071558423.issue12634@psf.upfronthosting.co.za> Message-ID: <1368401099.67.0.983173794836.issue12634@psf.upfronthosting.co.za> Changes by Yogesh Chaudhari : ---------- hgrepos: -188 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 01:25:35 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 12 May 2013 23:25:35 +0000 Subject: [issue17962] Broken OpenSSL version in Windows builds In-Reply-To: <1368357845.04.0.941311125595.issue17962@psf.upfronthosting.co.za> Message-ID: <1368401135.52.0.22647148776.issue17962@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Apparently it lacks the required SVN addition: The system cannot find the file specified. svn: E170000: URL 'http://svn.python.org/projects/external/openssl-1.0.1e' doesn't exist ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 01:41:46 2013 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 12 May 2013 23:41:46 +0000 Subject: [issue17959] Alternate approach to aliasing for PEP 435 In-Reply-To: Message-ID: Guido van Rossum added the comment: I'm with Antoine. Trying to prevent accidental redefinition behavior like Nick proposes feels like un-Pythonic coddling to me, and I expect we'd be closing off some occasionally useful patterns. Please leave well enough alone. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 01:45:02 2013 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 12 May 2013 23:45:02 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1368400499.67.0.702214456415.issue17927@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Benjamin, what do you think of backporting this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 01:56:12 2013 From: report at bugs.python.org (STINNER Victor) Date: Sun, 12 May 2013 23:56:12 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368402972.0.0.444255584628.issue17914@psf.upfronthosting.co.za> STINNER Victor added the comment: Here is a new patch (cpu_count.patch) with a different approach: * add a os.cpu_count() which returns the raw value (may be zero or negative if the OS returns a dummy value) and raise an OSError on error * os.cpu_count() is not available on all platforms * shutil.cpu_count() is the high level API using 1 as a fallback. The fallback value (which is 1 by default) is configurable, ex: shutil.cpu_count(fallback=None) returns None on os.cpu_count() error. * multiprocessing.cpu_count() simply reuses shutil.cpu_count() So os.cpu_count() as a well defined behaviour, and shutil.cpu_count() is the convinient API. My patch is based on issue17914-4.patch and so also on Trent Nelson's code. I only tested my patch on Linux. It must be tested on other platforms. If nobody tests the patch on HPUX, it would be safer to remove HPUX support. It looks like Trent's code was not tested, I don't think that his code works on platforms other than Windows. test_os will fail if os.cpu_count() fails. The test should be fixed to handle failures, but I prefer to start with a failing test to check if the error case occurs on a buildbot. ---------- Added file: http://bugs.python.org/file30241/cpu_count.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 01:56:51 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sun, 12 May 2013 23:56:51 +0000 Subject: [issue17962] Broken OpenSSL version in Windows builds In-Reply-To: <1368357845.04.0.941311125595.issue17962@psf.upfronthosting.co.za> Message-ID: <1368403011.23.0.867874216363.issue17962@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: I am not sure how http://www.openssl.org/source/openssl-1.0.1e.tar.gz can be provided to python svn. Doesn't that require svn credentials to check-out/add/check-in? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 01:58:36 2013 From: report at bugs.python.org (STINNER Victor) Date: Sun, 12 May 2013 23:58:36 +0000 Subject: [issue17964] os.sysconf(): return type of the C function sysconf() is long, not int Message-ID: <1368403116.83.0.700816018997.issue17964@psf.upfronthosting.co.za> New submission from STINNER Victor: According to POSIX and my manual page on Linux, sysconf() return type is long (and not int). http://pubs.opengroup.org/onlinepubs/009695399/functions/sysconf.html It may not mater in practice because most sysconf() results are smaller than 1000, and I failed to find a value bigger than 2 millions. ---------- files: sysconf_long.patch keywords: patch messages: 189078 nosy: haypo priority: normal severity: normal status: open title: os.sysconf(): return type of the C function sysconf() is long, not int versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30242/sysconf_long.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 02:00:03 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 13 May 2013 00:00:03 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368403203.06.0.60428541104.issue17914@psf.upfronthosting.co.za> STINNER Victor added the comment: The return type of the C function sysconf() is long, but Python uses int: I opened the issue #17964 to track this bug. (os.cpu_count() uses sysconf()). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 02:05:46 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 13 May 2013 00:05:46 +0000 Subject: [issue17964] os.sysconf(): return type of the C function sysconf() is long, not int In-Reply-To: <1368403116.83.0.700816018997.issue17964@psf.upfronthosting.co.za> Message-ID: <1368403546.32.0.00384946899823.issue17964@psf.upfronthosting.co.za> Benjamin Peterson added the comment: That looks reasonable to me. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 02:05:54 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 13 May 2013 00:05:54 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1368403554.36.0.215049709021.issue17927@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I think with the way I rewrote it, it would be okay. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 02:06:17 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 13 May 2013 00:06:17 +0000 Subject: [issue17959] Alternate approach to aliasing for PEP 435 In-Reply-To: <1368341497.6.0.896861896968.issue17959@psf.upfronthosting.co.za> Message-ID: <1368403577.46.0.379629185981.issue17959@psf.upfronthosting.co.za> Nick Coghlan added the comment: OK, I mainly wanted to make sure this alternative was at least considered, as I didn't see it come up during the PEP discussions. ---------- dependencies: -Code, test, and doc review for PEP-0435 Enum resolution: -> rejected stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 02:06:27 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 13 May 2013 00:06:27 +0000 Subject: [issue17656] Python 2.7.4 breaks ZipFile extraction of zip files with unicode member paths In-Reply-To: <1365391259.55.0.44522935247.issue17656@psf.upfronthosting.co.za> Message-ID: <1368403587.17.0.496332367789.issue17656@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 02:24:51 2013 From: report at bugs.python.org (paul j3) Date: Mon, 13 May 2013 00:24:51 +0000 Subject: [issue17940] extra code in argparse.py In-Reply-To: <1368052350.83.0.843381398629.issue17940@psf.upfronthosting.co.za> Message-ID: <1368404691.79.0.0229617369467.issue17940@psf.upfronthosting.co.za> paul j3 added the comment: I was wondering about that block of code earlier. It would be a good idea to look at what func() does, just to make sure there aren't any side effects - e.g. set maximum line length, required indention, etc. ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 02:35:53 2013 From: report at bugs.python.org (Ethan Furman) Date: Mon, 13 May 2013 00:35:53 +0000 Subject: [issue17961] Use enum names as values in enum.Enum convenience API In-Reply-To: <1368356222.14.0.0972295622627.issue17961@psf.upfronthosting.co.za> Message-ID: <1368405353.16.0.149348878037.issue17961@psf.upfronthosting.co.za> Ethan Furman added the comment: The class syntax (and default Enum) no longer have preferential treatment for integers (even __int__ is gone); so it is completely up to us as what should happen for the functional syntax. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 03:29:18 2013 From: report at bugs.python.org (Ethan Furman) Date: Mon, 13 May 2013 01:29:18 +0000 Subject: [issue17960] Clarify the required behaviour of locals() In-Reply-To: <1368344807.52.0.116896667629.issue17960@psf.upfronthosting.co.za> Message-ID: <1368408558.68.0.251119661575.issue17960@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 03:49:24 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 13 May 2013 01:49:24 +0000 Subject: [issue17941] namedtuple should support fully qualified name for more portable pickling In-Reply-To: <1368071216.78.0.0822877752405.issue17941@psf.upfronthosting.co.za> Message-ID: <1368409764.34.0.268622357464.issue17941@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Marking this a low priority. I want to see how it pans out for Enums before adding a new parameter to the namedtuple API. Also, I would like to look at the test cases for Enum so I can see how you're writing tests that would fail without this parameter. ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 03:57:08 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 13 May 2013 01:57:08 +0000 Subject: [issue17961] Use enum names as values in enum.Enum convenience API In-Reply-To: <1368405353.16.0.149348878037.issue17961@psf.upfronthosting.co.za> Message-ID: <54F3BF79-A1F0-4BA8-84E2-A49BD306922E@python.org> Barry A. Warsaw added the comment: On May 12, 2013, at 8:35 PM, Ethan Furman wrote: > Ethan Furman added the comment: > > The class syntax (and default Enum) no longer have preferential treatment for integers (even __int__ is gone); so it is completely up to us as what should happen for the functional syntax. Do you really think the enum discussion on python-dev was too short and could use another few thousand messages? ;) Or IOW, hasn't this already been decided by virtue of PEP acceptance? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 04:06:04 2013 From: report at bugs.python.org (Ethan Furman) Date: Mon, 13 May 2013 02:06:04 +0000 Subject: [issue17961] Use enum names as values in enum.Enum convenience API In-Reply-To: <54F3BF79-A1F0-4BA8-84E2-A49BD306922E@python.org> Message-ID: <51904A8A.3080604@stoneleaf.us> Ethan Furman added the comment: On 05/12/2013 06:57 PM, Barry A. Warsaw wrote: > > Do you really think the enum discussion on python-dev was too short and could use another few thousand messages? ;) No! > Or IOW, hasn't this already been decided by virtue of PEP acceptance? Indeed it has. I was merely replying to your comment about keeping class and function syntax in sync, when in fact there is no longer any direct correlation between the two other than the names used and the type created. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 04:07:09 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 13 May 2013 02:07:09 +0000 Subject: [issue9856] Change object.__format__(s) where s is non-empty to a TypeError In-Reply-To: <1284485218.75.0.159147258754.issue9856@psf.upfronthosting.co.za> Message-ID: <1368410829.92.0.780446996548.issue9856@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Everying is an instance of object. If its class does not override .__format__, then it seems that it should act the same as a direct object instance. If this a the current plan (or patch already committed, I think I would stay with that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 04:23:29 2013 From: report at bugs.python.org (paul j3) Date: Mon, 13 May 2013 02:23:29 +0000 Subject: [issue17965] argparse does not dest.replace('-', '_') for postionals Message-ID: <1368411809.58.0.522670485437.issue17965@psf.upfronthosting.co.za> New submission from paul j3: "16.4.3.11. dest For optional argument actions,... Any internal - characters will be converted to _ characters to make sure the string is a valid attribute name." In _get_optional_kwargs(), dest = dest.replace('-', '_'); but there is nothing like this in _get_positional_kwargs() Thus if parser.add_argument('foo-bar',...) this attribute can only be accessed with getattr(namespace, 'foo-bar'). Alternatives: - ignore this since no one has complained about it - stress in the documentation that the positionals name should be a valid python attribute name - test the name during add_argument - add the dest.replace('-','_') to positionals But as things stand, even an optional can be given a weird dest - a=p.add_argument('--foo*[]-bar') requiring getattr(args,'foo*[]_bar') I assume that optionals have this dash replacement because historically some unix (or other) programs have accepted options like '--foo-bar' (though off hand I can't think of any). ---------- components: Library (Lib) messages: 189090 nosy: paul.j3 priority: normal severity: normal status: open title: argparse does not dest.replace('-', '_') for postionals type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 04:29:06 2013 From: report at bugs.python.org (paul j3) Date: Mon, 13 May 2013 02:29:06 +0000 Subject: [issue14046] argparse: assertion failure if optional argument has square/round brackets in metavar In-Reply-To: <1329542509.5.0.84021889574.issue14046@psf.upfronthosting.co.za> Message-ID: <1368412146.81.0.252967440915.issue14046@psf.upfronthosting.co.za> Changes by paul j3 : ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 04:29:52 2013 From: report at bugs.python.org (paul j3) Date: Mon, 13 May 2013 02:29:52 +0000 Subject: [issue9338] argparse optionals with nargs='?', '*' or '+' can't be followed by positionals In-Reply-To: <1279881989.28.0.725806934086.issue9338@psf.upfronthosting.co.za> Message-ID: <1368412192.7.0.7584925106.issue9338@psf.upfronthosting.co.za> Changes by paul j3 : ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 05:50:42 2013 From: report at bugs.python.org (Roger Serwy) Date: Mon, 13 May 2013 03:50:42 +0000 Subject: [issue17838] Can't assign a different value for sys.stdin in IDLE In-Reply-To: <1366872984.94.0.234893757031.issue17838@psf.upfronthosting.co.za> Message-ID: <1368417042.61.0.411979044234.issue17838@psf.upfronthosting.co.za> Roger Serwy added the comment: Georg, I need to clarify what I meant in msg188301. Issue9290 was applied to 3.2 which introduced the bug addressed in issue17585, whose fix then introduced issue17838. IDLE on the 3.2 branch doesn't handle exit() or quit() correctly. It needs both #17585 and #17838 to be applied, as Serhiy said. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 06:02:39 2013 From: report at bugs.python.org (Roger Serwy) Date: Mon, 13 May 2013 04:02:39 +0000 Subject: [issue14146] IDLE: source line in editor doesn't highlight when debugging In-Reply-To: <1330401708.67.0.511106941359.issue14146@psf.upfronthosting.co.za> Message-ID: <1368417759.14.0.844664950114.issue14146@psf.upfronthosting.co.za> Roger Serwy added the comment: I'm waiting until after the next wave of maitenance releases before I apply this patch. If anyone feels strongly that it should be applied now, let me know. I applied the patch to the latest 2.7.4 64-bit release version of Python and it worked. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 06:08:36 2013 From: report at bugs.python.org (Paul Jurczak) Date: Mon, 13 May 2013 04:08:36 +0000 Subject: [issue17966] Lack of consistency in PEP 8 -- Style Guide for Python Code Message-ID: <1368418116.32.0.199767602115.issue17966@psf.upfronthosting.co.za> New submission from Paul Jurczak: This may be too subjective, but here it goes: PEP 8 discourages vertical alignment: "More than one space around an assignment (or other) operator to align it with another", but contrary to this rule, vertical alignment is used many times in the same paragraph, e.g.: Yes: spam(1) No: spam (1) If vertical alignment is so evil, the above should be changed to: Yes: spam(1) No: spam (1) Disclosure: I use vertical alignment in my code quite often. http://www.python.org/dev/peps/pep-0008/ ---------- assignee: docs at python components: Documentation messages: 189093 nosy: docs at python, pauljurczak priority: normal severity: normal status: open title: Lack of consistency in PEP 8 -- Style Guide for Python Code type: enhancement versions: Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 06:09:05 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 13 May 2013 04:09:05 +0000 Subject: [issue17961] Use enum names as values in enum.Enum convenience API In-Reply-To: <51904A8A.3080604@stoneleaf.us> Message-ID: Nick Coghlan added the comment: Accepting awkward implementation details when their rationale no longer applies doesn't make sense to me, no. The functional API originally used integers for good reasons. Over the course of the enum discussions, those reasons evaporated, but this wasn't noticed until after the PEP was accepted. However, the acceptance of the PEP is why I have proposed this as a post-incorporation change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 06:09:09 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 13 May 2013 04:09:09 +0000 Subject: [issue17547] "checking whether gcc supports ParseTuple __format__... " erroneously returns yes with gcc 4.8 In-Reply-To: <1364240036.0.0.495843553762.issue17547@psf.upfronthosting.co.za> Message-ID: <1368418149.06.0.322037471414.issue17547@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I've now scrapped that test completely for 3.4. 6eab274d3e34 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 06:32:51 2013 From: report at bugs.python.org (Todd Rovito) Date: Mon, 13 May 2013 04:32:51 +0000 Subject: [issue14146] IDLE: source line in editor doesn't highlight when debugging In-Reply-To: <1330401708.67.0.511106941359.issue14146@psf.upfronthosting.co.za> Message-ID: <1368419571.51.0.525038369009.issue14146@psf.upfronthosting.co.za> Todd Rovito added the comment: Roger, If you and Terry tested I would apply now so it makes it into 2.7.5. Why not? Right now the debugger in Windows doesn't highlight and I am sure that has to drive people crazy. But if you feel it needs more testing maybe you should let it bake some more? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 07:50:10 2013 From: report at bugs.python.org (zhaoqifa) Date: Mon, 13 May 2013 05:50:10 +0000 Subject: [issue17967] urllib2.open failed to access a url when a perent directory of the url is permission denied Message-ID: <1368424209.99.0.52540499369.issue17967@psf.upfronthosting.co.za> New submission from zhaoqifa: urllib2.open failed to access a url when a perent directory of the url is permission denied. I had a file in a ftp, the address is like ftp://host/home/work/123.txt which can be access by wget. When I urllib2.open to access the file, it always tell me that: urllib2.URLError: I found that the path /home is denied for anonymouse access but the path /home/work is not. urllib2.open try to call ftp.cwd("home") and then ftp.cwd("work") which failed when ftp.cwd("home"). I tried to fix this by changing "for dir in self.dirs: self.ftp.cwd(dir)" to "self.ftp.cwd(os.path.join(*self.dirs)" in urllib.py. And it works fine for this situation. ---------- messages: 189097 nosy: foxkiller priority: normal severity: normal status: open title: urllib2.open failed to access a url when a perent directory of the url is permission denied type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 07:50:22 2013 From: report at bugs.python.org (zhaoqifa) Date: Mon, 13 May 2013 05:50:22 +0000 Subject: [issue17967] urllib2.open failed to access a url when a perent directory of the url is permission denied In-Reply-To: <1368424209.99.0.52540499369.issue17967@psf.upfronthosting.co.za> Message-ID: <1368424222.83.0.240268386362.issue17967@psf.upfronthosting.co.za> Changes by zhaoqifa : ---------- components: +Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 07:52:06 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 13 May 2013 05:52:06 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1368402972.0.0.444255584628.issue17914@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Here is a new patch (cpu_count.patch) with a different approach: > > * add a os.cpu_count() which returns the raw value (may be zero or negative if the OS returns a dummy value) and raise an OSError on error > * os.cpu_count() is not available on all platforms > * shutil.cpu_count() is the high level API using 1 as a fallback. The fallback value (which is 1 by default) is configurable, ex: shutil.cpu_count(fallback=None) returns None on os.cpu_count() error. > * multiprocessing.cpu_count() simply reuses shutil.cpu_count() Do we really need cpu_count() in three places with different semantics? Also, it doesn't belong to shutil(), which stands for shell utilities IIRC. IMO just one version in Modules/posixmodule.c is enough (with multiprocessing's version as an alias), there's no need to over-engineer this. It can return None, that's fine with me now at this point. > I only tested my patch on Linux. It must be tested on other platforms. If nobody tests the patch on HPUX, it would be safer to remove HPUX support. Well, HP-UX isn't officially supported, so that's reasonable. > test_os will fail if os.cpu_count() fails. The test should be fixed to handle failures, but I prefer to start with a failing test to check if the error case occurs on a buildbot. That's reasonable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 07:57:19 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 05:57:19 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1368402972.0.0.444255584628.issue17914@psf.upfronthosting.co.za> Message-ID: <1368424636.2557.0.camel@fsol> Antoine Pitrou added the comment: > * add a os.cpu_count() which returns the raw value (may be zero or > negative if the OS returns a dummy value) and raise an OSError on > error > * os.cpu_count() is not available on all platforms > * shutil.cpu_count() is the high level API using 1 as a fallback. The > fallback value (which is 1 by default) is configurable, ex: > shutil.cpu_count(fallback=None) returns None on os.cpu_count() error. -1. This is simply too complicated for a simple API. Just let os.cpu_count() return None. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 07:58:08 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 05:58:08 +0000 Subject: [issue17962] Broken OpenSSL version in Windows builds In-Reply-To: <1368357845.04.0.941311125595.issue17962@psf.upfronthosting.co.za> Message-ID: <1368424688.23.0.096802452585.issue17962@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Yes, someone with SVN write access (Georg?) will have to do it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 08:12:10 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 13 May 2013 06:12:10 +0000 Subject: [issue10652] test___all_ + test_tcl fails (Windows installed binary) In-Reply-To: <1291819198.8.0.493152862608.issue10652@psf.upfronthosting.co.za> Message-ID: <1368425530.09.0.693120786441.issue10652@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 08:13:14 2013 From: report at bugs.python.org (Georg Brandl) Date: Mon, 13 May 2013 06:13:14 +0000 Subject: [issue17962] Broken OpenSSL version in Windows builds In-Reply-To: <1368357845.04.0.941311125595.issue17962@psf.upfronthosting.co.za> Message-ID: <1368425594.94.0.436336017735.issue17962@psf.upfronthosting.co.za> Georg Brandl added the comment: I could, but the checked-in 1.0.1d is different from the tarball in some respects, so it's better for Martin to do this. ---------- assignee: -> loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 08:15:05 2013 From: report at bugs.python.org (Georg Brandl) Date: Mon, 13 May 2013 06:15:05 +0000 Subject: [issue17838] Can't assign a different value for sys.stdin in IDLE In-Reply-To: <1366872984.94.0.234893757031.issue17838@psf.upfronthosting.co.za> Message-ID: <1368425705.85.0.223027645398.issue17838@psf.upfronthosting.co.za> Georg Brandl added the comment: Sorry, this was not clear to me. 3.2 users will have to live with the bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 08:18:47 2013 From: report at bugs.python.org (Georg Brandl) Date: Mon, 13 May 2013 06:18:47 +0000 Subject: [issue17966] Lack of consistency in PEP 8 -- Style Guide for Python Code In-Reply-To: <1368418116.32.0.199767602115.issue17966@psf.upfronthosting.co.za> Message-ID: <1368425927.46.0.130402916621.issue17966@psf.upfronthosting.co.za> Georg Brandl added the comment: Interesting observation :) However, the alignment in the PEP is in prose, not code. ---------- assignee: docs at python -> nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 08:45:16 2013 From: report at bugs.python.org (paul j3) Date: Mon, 13 May 2013 06:45:16 +0000 Subject: [issue17965] argparse does not dest.replace('-', '_') for positionals In-Reply-To: <1368411809.58.0.522670485437.issue17965@psf.upfronthosting.co.za> Message-ID: <1368427516.25.0.725493458073.issue17965@psf.upfronthosting.co.za> Changes by paul j3 : ---------- title: argparse does not dest.replace('-', '_') for postionals -> argparse does not dest.replace('-', '_') for positionals _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 08:47:27 2013 From: report at bugs.python.org (paul j3) Date: Mon, 13 May 2013 06:47:27 +0000 Subject: [issue14191] argparse doesn't allow optionals within positionals In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za> Message-ID: <1368427647.26.0.124783595826.issue14191@psf.upfronthosting.co.za> Changes by paul j3 : Removed file: http://bugs.python.org/file29880/mixed.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 10:15:46 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Mon, 13 May 2013 08:15:46 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368432946.86.0.00667887882645.issue17914@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: @Stinner: 1. While I agree with your idea of what you have done in test_os, (particularly, for determining if platform is supported or not) there seems to be no reason(AFAIK) to have a shutil for cpu_count. I agree with neologox there. 2. Also I am not comfortable with the idea of having multiple 'implementations' of cpu_count. "There should be one-- and preferably only one --obvious way to do it." 3. The idea of returning 1 by default does not seem to serve a useful purpose. It should be left to the end-user to decide what needs to be done based on error/actual_value received from system. (+1 to Antoine and nedbat) For eg, a. Let's say someone works on scheduling and power managment modules. It is important to know that the platform does not support providing cpu_count() instead of giving 1. This will ensure that they don't go about erroneously setting wrong options for scheduler and/or overclocking the CPU too much(or too little). b. On the other hand if another user just wants to use a cpu_count number from a his application to determine the number of threads to spawn he can set th = cpu_count() or 1 (on a side note: *usually* for programs that are non IO intensive and require no/little synchronization it is best to spawn cpu_count() number of threads) These are just 2 examples to demonstrate that it must be the end-user who decides what to do with the proper_value or reasonable_error_value given by cpu_count() 4. +1 to Antoine on last comment ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 10:24:58 2013 From: report at bugs.python.org (Paul Jurczak) Date: Mon, 13 May 2013 08:24:58 +0000 Subject: [issue17966] Lack of consistency in PEP 8 -- Style Guide for Python Code In-Reply-To: <1368418116.32.0.199767602115.issue17966@psf.upfronthosting.co.za> Message-ID: <1368433498.77.0.443045911581.issue17966@psf.upfronthosting.co.za> Paul Jurczak added the comment: Correct, it is in mixed prose and code. However, the underlying principle in this PEP is: "guidelines provided here are intended to improve the readability of code". The author used vertical alignment (for mixed prose and code), because of its superior readability. Many others had found that aligning long columns of data improves readability, from newsprint and spreadsheets to multiple assignment statements. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 10:25:23 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Mon, 13 May 2013 08:25:23 +0000 Subject: [issue17962] Broken OpenSSL version in Windows builds In-Reply-To: <1368357845.04.0.941311125595.issue17962@psf.upfronthosting.co.za> Message-ID: <1368433523.71.0.0877205279922.issue17962@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: I would like to take a crack at it. Would it be possible(I mean permission wise)? How can I proceed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 10:29:35 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 13 May 2013 08:29:35 +0000 Subject: [issue17941] namedtuple should support fully qualified name for more portable pickling In-Reply-To: <1368071216.78.0.0822877752405.issue17941@psf.upfronthosting.co.za> Message-ID: <1368433775.06.0.256710602788.issue17941@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- keywords: +patch Added file: http://bugs.python.org/file30243/nt_module.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 10:32:41 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Mon, 13 May 2013 08:32:41 +0000 Subject: [issue9856] Change object.__format__(s) where s is non-empty to a TypeError In-Reply-To: <1284485218.75.0.159147258754.issue9856@psf.upfronthosting.co.za> Message-ID: <1368433961.15.0.705431250956.issue9856@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: +1 to Terry for "If its class does not override .__format__, then it seems that it should act the same as a direct object instance" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 10:49:36 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 08:49:36 +0000 Subject: [issue17962] Broken OpenSSL version in Windows builds In-Reply-To: <1368357845.04.0.941311125595.issue17962@psf.upfronthosting.co.za> Message-ID: <1368434976.19.0.798907795642.issue17962@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't know how much work there is. Perhaps you want to produce a diff between the current "external" 1.0.1d and the upstream version. Otherwise just let Georg or Martin handle it ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 10:57:07 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 08:57:07 +0000 Subject: [issue17934] Add a frame method to clear expensive details In-Reply-To: <1368014042.2.0.41504275061.issue17934@psf.upfronthosting.co.za> Message-ID: <1368435427.92.0.169352400171.issue17934@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is an alternative patch raising RuntimeError on executing frames. Please tell which one you prefer :) ---------- Added file: http://bugs.python.org/file30244/frame_clear_alt.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 10:57:09 2013 From: report at bugs.python.org (Claudiu.Popa) Date: Mon, 13 May 2013 08:57:09 +0000 Subject: [issue17487] wave.Wave_read.getparams should be more user friendly In-Reply-To: <1363726749.83.0.981836859976.issue17487@psf.upfronthosting.co.za> Message-ID: <1368435429.5.0.905639630258.issue17487@psf.upfronthosting.co.za> Claudiu.Popa added the comment: There is a regression with the latest patch, `getparams` output is no longer picklable. The attached patch fixes this issue. Also, I renamed the internal namedtuple to something more meaningful. ---------- Added file: http://bugs.python.org/file30245/wave_picklable.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 10:57:44 2013 From: report at bugs.python.org (Claudiu.Popa) Date: Mon, 13 May 2013 08:57:44 +0000 Subject: [issue17487] wave.Wave_read.getparams should be more user friendly In-Reply-To: <1363726749.83.0.981836859976.issue17487@psf.upfronthosting.co.za> Message-ID: <1368435464.19.0.890312643018.issue17487@psf.upfronthosting.co.za> Changes by Claudiu.Popa : ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 11:19:07 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 09:19:07 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368028726.5.0.833825784859.issue17936@psf.upfronthosting.co.za> Message-ID: <1368436747.31.0.631468543656.issue17936@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think the logic is slightly wrong in remove_subclass. When you encounter Py_None, you can't be sure it's the weakref for the current type; theoretically, it could be any other one (depending on oddities in cleanup order, cycle collection, etc.). So you have to continue walking the list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 11:26:00 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Mon, 13 May 2013 09:26:00 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368437160.42.0.0105279775356.issue17914@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: Modified patch based on further comments and review. 1. Removed *everything* from os.py 2. removed typecasting for ncpu where not required. 3. removed redundant comments ---------- Added file: http://bugs.python.org/file30246/issue17914-5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 11:39:50 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 09:39:50 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368028726.5.0.833825784859.issue17936@psf.upfronthosting.co.za> Message-ID: <1368437990.5.0.544753735825.issue17936@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Attaching an alternative implementation for remove_subclass(). ---------- Added file: http://bugs.python.org/file30247/subtype2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 11:48:46 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 09:48:46 +0000 Subject: [issue17968] memory leak in listxattr() Message-ID: <1368438526.63.0.243173178736.issue17968@psf.upfronthosting.co.za> New submission from Antoine Pitrou: os.listxattr() leaks its internal buffer when the first call to C listxattr() fails with ERANGE. This wasn't caught by the refleak bot, probably because xattrs are not enabled on it. ---------- files: listxattr_leak.patch keywords: patch messages: 189114 nosy: benjamin.peterson, pitrou priority: normal severity: normal stage: patch review status: open title: memory leak in listxattr() type: resource usage versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30248/listxattr_leak.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 12:09:13 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 10:09:13 +0000 Subject: [issue17966] Lack of consistency in PEP 8 -- Style Guide for Python Code In-Reply-To: <1368418116.32.0.199767602115.issue17966@psf.upfronthosting.co.za> Message-ID: <1368439753.85.0.702025331628.issue17966@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 12:10:58 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 10:10:58 +0000 Subject: [issue17961] Use enum names as values in enum.Enum convenience API In-Reply-To: <1368356222.14.0.0972295622627.issue17961@psf.upfronthosting.co.za> Message-ID: <1368439858.29.0.556189352394.issue17961@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I agree with Nick here, there's no reason to auto-number constants in Python. This is not C :-) ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 12:14:10 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 10:14:10 +0000 Subject: [issue17956] add ScheduledExecutor In-Reply-To: <1368294342.98.0.976753460934.issue17956@psf.upfronthosting.co.za> Message-ID: <1368440050.88.0.831328058615.issue17956@psf.upfronthosting.co.za> Antoine Pitrou added the comment: To be honest I can't find much to say about this proposal, but I think it would be good if the time function were configurable (both for test purposes, and to allow passing e.g. time.monotonic). I suppose this could be an executor option. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 12:15:29 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 13 May 2013 10:15:29 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368028726.5.0.833825784859.issue17936@psf.upfronthosting.co.za> Message-ID: <1368440129.21.0.9865725643.issue17936@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Basically the logic is this: When the class goes away, it _always_ calls remove_subclass(). Now, this may be before or after the weakref has been clear so that it will either find itself in a weakref, or a clear weakref. In case this logic is flawed, we know that when remove_subclass() is called, exactly one child is removed. Whether it is us, or some previous class, is irrelevant. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 12:21:18 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 10:21:18 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368440129.21.0.9865725643.issue17936@psf.upfronthosting.co.za> Message-ID: <1258170106.35637465.1368440471433.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > In case this logic is flawed, we know that when remove_subclass() is > called, exactly one child is removed. Whether it is us, or some > previous class, is irrelevant. remove_subclass() is called when __bases__ is assigned to, so it is not irrelevant: >>> class A: pass ... >>> class B(A): pass ... >>> class C: pass ... >>> A.__subclasses__() [] >>> B.__bases__ = C, >>> A.__subclasses__() [] >>> C.__subclasses__() [] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 12:21:23 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 13 May 2013 10:21:23 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368028726.5.0.833825784859.issue17936@psf.upfronthosting.co.za> Message-ID: <1368440483.31.0.308483973083.issue17936@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: There are two cases when remove_subclass is called: One when we are changing base classes(the original use of this function), and in this case we must find the correct one. The second one is when the class is being deleted, for housekeeping of the weakrefs. I worry that your alternative will cause us to walk the entire list in the second case because it will be called when the weakref has been cleared, so it will never find itself in the list, only None. I'll make some tests to verify. I think perhaps a small adjustment, an "exact" flag or something, can be added to differentiate between the two cases.... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 12:26:31 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 10:26:31 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368440483.31.0.308483973083.issue17936@psf.upfronthosting.co.za> Message-ID: <776350391.35651192.1368440785246.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > The second one is when the class is being deleted, for housekeeping > of the weakrefs. > I worry that your alternative will cause us to walk the entire list > in the second case because it will be called when the weakref has > been cleared, so it will never find itself in the list, only None. I don't think that matters much. In both cases the expected complexity is O(n). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 12:33:19 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 13 May 2013 10:33:19 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368028726.5.0.833825784859.issue17936@psf.upfronthosting.co.za> Message-ID: <1368441199.48.0.668113987475.issue17936@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Actually, in a program that dynamically creates a class, and then deletes it, you would expect a O(1) complexity. adding children at the end, and searching from the end, is a way to achieve this. While I admit that I oversaw the exact requirement for __bases__, I think that allowing for a "None" to be sufficient when the class is being deleted is an important improvement. I realize that the therotetical worst case is O(n), but the practical common case is still O(1) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 13:06:45 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 11:06:45 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368028726.5.0.833825784859.issue17936@psf.upfronthosting.co.za> Message-ID: <1368443205.89.0.85124009405.issue17936@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > While I admit that I oversaw the exact requirement for __bases__, I think > that allowing for a "None" to be sufficient when the class is being deleted > is an important improvement. You can't be sure the "None" corresponds to the type being deleted and not another one. If you want guaranteed (almost :-)) O(1) behaviour, you must switch to a dict. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 13:31:34 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 13 May 2013 11:31:34 +0000 Subject: [issue17969] multiprocessing crash on exit Message-ID: <1368444694.56.0.376585959821.issue17969@psf.upfronthosting.co.za> New submission from Kristj?n Valur J?nsson: We have observed this crash with some frequency when running our compilation scripts using multiprocessing.Pool() By analysing the crashes, this is what is happening: 1) The Pool has a "daemon" thread managing the pool. 2) the worker is asleep, waiting for the GIL 3) The main thread exits. The system starts its shutdown. During PyInterpreterState_Clear, it has cleared among other things the sys dict. During this, it clears an old traceback. The traceback contains a multiprocessing.connection object. 4) The connection object is cleared. It it contains this code: Py_BEGIN_ALLOW_THREADS CLOSE(self->handle); Py_END_ALLOW_THREADS 5) The sleeping daemon thread is woken up and starts prancing around. Upon calling sys.exc_clear() it crashes, since the tstate->interp->sysdict == NULL. I have a workaround in place in our codebase: static void connection_dealloc(ConnectionObject* self) { if (self->weakreflist != NULL) PyObject_ClearWeakRefs((PyObject*)self); if (self->handle != INVALID_HANDLE_VALUE) { /* CCP Change. Cannot release threads here, because this * deallocation may be running during process shutdown, and * releaseing a daemon thread will cause a crash Py_BEGIN_ALLOW_THREADS CLOSE(self->handle); Py_END_ALLOW_THREADS */ CLOSE(self->handle); } PyObject_Del(self); } In general, deallocators should have no side effects, I think. Releaseing the GIL is certainly a side effect. I realize that process shutdown is a delicate matter. One delicate thing is that we cannot allow worker threads to run anymore. I see no general mechanism for ensuring this, but surely at least not releasing the GIL for deallocators is a first step? ---------- messages: 189123 nosy: kristjan.jonsson priority: normal severity: normal status: open title: multiprocessing crash on exit type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 13:38:06 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 13 May 2013 11:38:06 +0000 Subject: [issue17969] multiprocessing crash on exit In-Reply-To: <1368444694.56.0.376585959821.issue17969@psf.upfronthosting.co.za> Message-ID: <1368445086.38.0.46324021195.issue17969@psf.upfronthosting.co.za> Changes by Richard Oudkerk : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 13:40:09 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 13 May 2013 11:40:09 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368028726.5.0.833825784859.issue17936@psf.upfronthosting.co.za> Message-ID: <1368445209.67.0.271613335351.issue17936@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Yes I am sure. Please see the previous reasoning. Igoring assigning to __bases__ for the moment... Every class deletion will try to remove itself from the list. Either it will a) find an existing reference in the weakref and remove it b) find a None in the weakref and remove it. b) is guaranteed to be the old weakref, because every previous class removal has also succeeded. At any time, there is at most a single stale weakref in the list. And _even_if_ there is a flaw in the argument, every call will remove _one_ stale (or just about to become stale) weakref from the list. Whether it is its own weakref or that of a previous deletion is immaterial. The removal of _one_ entry for each class deletion keeps the list at its optimal size. For the case of assigning to __bases__, of course, the weakrefs are not stale and we must find the correct class to remove for correctness. I don't want guaranteed O(1) behaviour, just O(1) for the common case of creating a class, or a few classes, and then removing them. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 14:01:08 2013 From: report at bugs.python.org (Martin Morrison) Date: Mon, 13 May 2013 12:01:08 +0000 Subject: [issue17950] Dynamic classes contain non-breakable reference cycles In-Reply-To: <1368217344.29.0.260515184231.issue17950@psf.upfronthosting.co.za> Message-ID: <1368446468.79.0.484846605833.issue17950@psf.upfronthosting.co.za> Changes by Martin Morrison : ---------- nosy: +isoschiz, pconnell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 14:02:42 2013 From: report at bugs.python.org (Georg Brandl) Date: Mon, 13 May 2013 12:02:42 +0000 Subject: [issue17962] Broken OpenSSL version in Windows builds In-Reply-To: <1368357845.04.0.941311125595.issue17962@psf.upfronthosting.co.za> Message-ID: <1368446562.71.0.58443078367.issue17962@psf.upfronthosting.co.za> Georg Brandl added the comment: I don't know what there is to do, so I can give no instructions. It's best to let Martin handle it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 14:49:35 2013 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Mon, 13 May 2013 12:49:35 +0000 Subject: [issue17950] Dynamic classes contain non-breakable reference cycles In-Reply-To: <1368217344.29.0.260515184231.issue17950@psf.upfronthosting.co.za> Message-ID: <1368449375.63.0.253430184253.issue17950@psf.upfronthosting.co.za> Changes by Fred L. Drake, Jr. : ---------- nosy: +fdrake _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 15:06:41 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 13 May 2013 13:06:41 +0000 Subject: [issue5803] email/quoprimime: encode and decode are very slow on large messages In-Reply-To: <1240254091.33.0.632025917195.issue5803@psf.upfronthosting.co.za> Message-ID: <1368450401.98.0.77122764886.issue5803@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch for 3.4 based on Matt's patch with additional optimizations. It speeds up body_encode() and header_encode(). $ ./python -m timeit -s "from email.quoprimime import body_encode as encode; x = open('Lib/decimal.py').read()[:100000]" "encode(x)" Before patch: 1.12 sec per loop After patch: 26.3 msec per loop $ ./python -m timeit -s "from email.quoprimime import header_encode as encode; x = b'A'*100" "encode(x)" Before patch: 97.9 usec per loop After patch: 23.7 usec per loop For non-ascii data difference is even larger. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file30249/email_quoprimime_fast_encode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 15:19:44 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 13 May 2013 13:19:44 +0000 Subject: [issue17968] memory leak in listxattr() In-Reply-To: <1368438526.63.0.243173178736.issue17968@psf.upfronthosting.co.za> Message-ID: <1368451184.85.0.421944947419.issue17968@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 15:24:04 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Mon, 13 May 2013 13:24:04 +0000 Subject: [issue17962] Broken OpenSSL version in Windows builds In-Reply-To: <1368357845.04.0.941311125595.issue17962@psf.upfronthosting.co.za> Message-ID: <1368451444.53.0.330372755739.issue17962@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: @Antoine and @Georg: You are right. There is nothing much to be done. The only difference is those of auto-generated files like Makefile and other config files created after running ./config script. This just needs a simple add/commit from the openssl site. It seems there is nothing else AFAICS ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 15:25:56 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 13 May 2013 13:25:56 +0000 Subject: [issue17950] Dynamic classes contain non-breakable reference cycles In-Reply-To: <1368217344.29.0.260515184231.issue17950@psf.upfronthosting.co.za> Message-ID: <1368451556.07.0.0637140778307.issue17950@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 15:26:40 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 13 May 2013 13:26:40 +0000 Subject: [issue17963] Deprecate the frame hack for implicitly getting module details In-Reply-To: <1368364153.58.0.131087315276.issue17963@psf.upfronthosting.co.za> Message-ID: <1368451600.09.0.0220552233377.issue17963@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 15:29:39 2013 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 13 May 2013 13:29:39 +0000 Subject: [issue17966] Lack of consistency in PEP 8 -- Style Guide for Python Code In-Reply-To: <1368418116.32.0.199767602115.issue17966@psf.upfronthosting.co.za> Message-ID: <1368451779.74.0.148925028479.issue17966@psf.upfronthosting.co.za> Guido van Rossum added the comment: This is a silly argument. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 15:39:18 2013 From: report at bugs.python.org (Eli Bendersky) Date: Mon, 13 May 2013 13:39:18 +0000 Subject: [issue1772673] Replacing char* with const char* Message-ID: <1368452358.92.0.988940188986.issue1772673@psf.upfronthosting.co.za> Eli Bendersky added the comment: For external APIs visible to user code, this can cause some compatibility problems and users may need to at the very least re-compile this code. So -1 here. For new external APIs, having const wherever appropriate should be considered on a case by case basis. For internal code this is a good idea, but I wouldn't go mass-slashing all the code base now replacing char* by const char*. Presenting some examples where this makes sense in particular would be interesting though. +0 ---------- nosy: +eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 15:52:38 2013 From: report at bugs.python.org (mrDoctorWho0 .) Date: Mon, 13 May 2013 13:52:38 +0000 Subject: [issue17970] Mutlithread XML parsing cause segfault Message-ID: <1368453158.92.0.142296100122.issue17970@psf.upfronthosting.co.za> New submission from mrDoctorWho0 .: Linux i386, Python 2.7.4. Multithread xml parsing via pyexpat cause segmentation fault ---------- components: XML files: pyexpat_crash_multithread.py messages: 189131 nosy: mrDoctorWho0.. priority: normal severity: normal status: open title: Mutlithread XML parsing cause segfault versions: Python 2.7 Added file: http://bugs.python.org/file30250/pyexpat_crash_multithread.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 16:01:24 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 13 May 2013 14:01:24 +0000 Subject: [issue17961] Use enum names as values in enum.Enum convenience API In-Reply-To: <1368439858.29.0.556189352394.issue17961@psf.upfronthosting.co.za> Message-ID: <20130513100122.62b73d53@limelight.wooz.org> Barry A. Warsaw added the comment: On May 13, 2013, at 10:10 AM, Antoine Pitrou wrote: >I agree with Nick here, there's no reason to auto-number constants in >Python. This is not C :-) Why should they be strings? Why not object()? Why is `x.value == str(x)` a useful invariant to hold? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 16:05:08 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 14:05:08 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368445209.67.0.271613335351.issue17936@psf.upfronthosting.co.za> Message-ID: <412497329.36172431.1368453901775.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > I don't want guaranteed O(1) behaviour, just O(1) for the common case > of creating a class, or a few classes, and then removing them. Then just make sure you call remove_subclass() before PyObject_ClearWeakRefs() in type_dealloc(). Really, this thing should be demonstrably correct. Performance of dynamic class creation is not critical enough to take shortcuts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 16:05:11 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 13 May 2013 14:05:11 +0000 Subject: [issue17968] memory leak in listxattr() In-Reply-To: <1368438526.63.0.243173178736.issue17968@psf.upfronthosting.co.za> Message-ID: <1368453911.91.0.203789395026.issue17968@psf.upfronthosting.co.za> Benjamin Peterson added the comment: LGTM ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 16:06:28 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 14:06:28 +0000 Subject: [issue17961] Use enum names as values in enum.Enum convenience API In-Reply-To: <20130513100122.62b73d53@limelight.wooz.org> Message-ID: <1172298768.36174760.1368453982354.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > >I agree with Nick here, there's no reason to auto-number constants > >in > >Python. This is not C :-) > > Why should they be strings? Why not object()? Because strings are readable, I'd say. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 16:08:16 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 13 May 2013 14:08:16 +0000 Subject: [issue17966] Lack of consistency in PEP 8 -- Style Guide for Python Code In-Reply-To: <1368418116.32.0.199767602115.issue17966@psf.upfronthosting.co.za> Message-ID: <1368454096.51.0.413297867521.issue17966@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 16:13:30 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 13 May 2013 14:13:30 +0000 Subject: [issue17966] Lack of consistency in PEP 8 -- Style Guide for Python Code In-Reply-To: <1368418116.32.0.199767602115.issue17966@psf.upfronthosting.co.za> Message-ID: <1368454410.44.0.463670627278.issue17966@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: It's not *particularly* silly[1], but I think that with Government backing, he could make it very silly. [1] I mean, the right hand side isn't silly at all and the left hand side merely does a forward aerial half turn every alternative assignment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 16:21:44 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 13 May 2013 14:21:44 +0000 Subject: [issue17959] Alternate approach to aliasing for PEP 435 In-Reply-To: <1368341497.6.0.896861896968.issue17959@psf.upfronthosting.co.za> Message-ID: <1368454904.95.0.867725767659.issue17959@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 16:24:41 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 13 May 2013 14:24:41 +0000 Subject: [issue17961] Use enum names as values in enum.Enum convenience API In-Reply-To: <1172298768.36174760.1368453982354.JavaMail.root@zimbra10-e2.priv.proxad.net> Message-ID: Nick Coghlan added the comment: On 14 May 2013 00:06, "Antoine Pitrou" wrote: > > > Antoine Pitrou added the comment: > > > >I agree with Nick here, there's no reason to auto-number constants > > >in > > >Python. This is not C :-) > > > > Why should they be strings? Why not object()? > > Because strings are readable, I'd say. Yep. Since we no longer have a compelling reason for it to be anything else, it may as well be the human readable string. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 16:26:48 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 13 May 2013 14:26:48 +0000 Subject: [issue17959] Alternate approach to aliasing for PEP 435 In-Reply-To: <1368341497.6.0.896861896968.issue17959@psf.upfronthosting.co.za> Message-ID: <20130513102647.298d1124@limelight.wooz.org> Barry A. Warsaw added the comment: On May 12, 2013, at 06:51 AM, Nick Coghlan wrote: >>>> class Shape(Enum): >... square = 2 >... diamond = 1 >... circle = 3 >... alias_for_square = square I see Guido pronounced against it, but I'm just registering that I kind of like this. You could probably have guess that since flufl.enum doesn't allow aliases at all mostly because of the potential for accidental duplicate values, which this would avoid. Hmm. LP: #1179529 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 16:41:11 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 13 May 2013 14:41:11 +0000 Subject: [issue17969] multiprocessing crash on exit In-Reply-To: <1368444694.56.0.376585959821.issue17969@psf.upfronthosting.co.za> Message-ID: <1368456071.6.0.815109099247.issue17969@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > In general, deallocators should have no side effects, I think. > Releaseing the GIL is certainly a side effect. Notice that socket and file objects also release the GIL when being deallocated. At least for sockets close() can block (e.g. if you you use the SO_LINGER option). I am not sure whether we can ignore the possibility for connection objects. > I realize that process shutdown is a delicate matter. One delicate > thing is that we cannot allow worker threads to run anymore. I see no > general mechanism for ensuring this, but surely at least not releasing > the GIL for deallocators is a first step? I agree that shutdown matters are delicate, particularly when daemon threads are involved. In fact I'm starting to agree with Antoine that daemon threads are evil and should be avoided wherever possible. P.S. I think in Python 3.x this thread switching is stopped (by setting _Py_Finalizing to something non-NULL) before PyInterpreterState_Clear() is run. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 16:44:28 2013 From: report at bugs.python.org (Ethan Furman) Date: Mon, 13 May 2013 14:44:28 +0000 Subject: [issue17961] Use enum names as values in enum.Enum convenience API In-Reply-To: <1368356222.14.0.0972295622627.issue17961@psf.upfronthosting.co.za> Message-ID: <1368456268.85.0.601860845209.issue17961@psf.upfronthosting.co.za> Ethan Furman added the comment: So the repr will look like: ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 16:45:15 2013 From: report at bugs.python.org (Alejandro Rodas) Date: Mon, 13 May 2013 14:45:15 +0000 Subject: [issue17642] IDLE add font resizing hot keys In-Reply-To: <1365228385.87.0.236246362772.issue17642@psf.upfronthosting.co.za> Message-ID: <1368456315.33.0.871035006112.issue17642@psf.upfronthosting.co.za> Alejandro Rodas added the comment: I have merged the two patches: Now it queries the font size as I did in the original patch, and it also stores the position of the cursor based on Abhishek Kumar's modification of ZoomFont.py. ---------- Added file: http://bugs.python.org/file30251/ZoomInOut.patch2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 17:09:31 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 13 May 2013 15:09:31 +0000 Subject: [issue17961] Use enum names as values in enum.Enum convenience API In-Reply-To: <1172298768.36174760.1368453982354.JavaMail.root@zimbra10-e2.priv.proxad.net> Message-ID: <20130513110927.20cbead5@anarchist> Barry A. Warsaw added the comment: On May 13, 2013, at 02:06 PM, Antoine Pitrou wrote: >Antoine Pitrou added the comment: > >> >I agree with Nick here, there's no reason to auto-number constants >> >in >> >Python. This is not C :-) >> >> Why should they be strings? Why not object()? > >Because strings are readable, I'd say. The repr would then be Yuck. Also, you would have to allow for subclasses (e.g. IntEnum) to override auto-assignment. Clearly, you can't use strings for X = IntEnum('X', 'start middle end') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 17:10:20 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 13 May 2013 15:10:20 +0000 Subject: [issue17961] Use enum names as values in enum.Enum convenience API In-Reply-To: Message-ID: <20130513111018.72a02b21@anarchist> Barry A. Warsaw added the comment: On May 13, 2013, at 02:24 PM, Nick Coghlan wrote: >Yep. Since we no longer have a compelling reason for it to be anything >else, it may as well be the human readable string. Again, why does it matter? That's the whole point of having a human readable str() and repr(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 17:24:50 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 13 May 2013 15:24:50 +0000 Subject: [issue17956] add ScheduledExecutor In-Reply-To: <1368440050.88.0.831328058615.issue17956@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > To be honest I can't find much to say about this proposal, Hum, OK, I thought it would be a useful addition :-) > but I think it would be good if the time function were configurable (both for test purposes, and to allow passing e.g. time.monotonic). I suppose this could be an executor option. Note that the time function must be "real" time, since the sleep are based on condition.wait() (otherwise if you just call an arbitrary sleep() function you can't be woken up when a new task with an earlier deadline is submitted). So it's different from the sched module, we can't really support arbitrary time functions. Note that I do think it would be a good idea to use time.monotonic() when available (almost all modules have been updated, except the future one). That's probably another issue, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 17:28:12 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 13 May 2013 15:28:12 +0000 Subject: [issue17969] multiprocessing crash on exit In-Reply-To: <1368444694.56.0.376585959821.issue17969@psf.upfronthosting.co.za> Message-ID: <1368458892.2.0.450730633923.issue17969@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: I think that socket.close() is the exception rather than the rule here. What kind of handle is this? It can't be a socket, since that would require closesocket. Also, even though an IO call _can_ block, that doesn't mean that we _must_ release the gil for the duration. I?m not very familiar with multiprocessing, I'm mainly trying to enhance robustness with our build tools here. Would an alternative fix, making the worker thread a non-daemon, be hard to do? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 17:36:54 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 13 May 2013 15:36:54 +0000 Subject: [issue17969] multiprocessing crash on exit In-Reply-To: <1368444694.56.0.376585959821.issue17969@psf.upfronthosting.co.za> Message-ID: <1368459414.77.0.378502041293.issue17969@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: > Also, even though an IO call _can_ block, that doesn't mean that > we _must_ release the gil for the duration. Yes, otherwise some people will complain when the whole interpreter is stuck while a socket/NFS file handle/whatever is shutdown. This problem isn't specific to multiprocessing: for example, if a daemon thread's thread state is cleared as part of the shutdown procedure, and one of the TLS object releases the GIL (e.g. a database connection), you'll have the same kind of problem. AFAICT, it's "solved" in Python 3 because, as Richard said, you can't acquire the GIL once the interpreter is shutting down. Daemon threads are *really* tricky, since they can wake-up while the interpreter is shutting down. So they should be avoided as much as possible. We can also try to think some more about a way to avoid/limit this type of issue, but it's not trivial... ---------- nosy: +neologix, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 17:44:40 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 15:44:40 +0000 Subject: [issue17956] add ScheduledExecutor In-Reply-To: Message-ID: <1889772132.36458275.1368459873497.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > > To be honest I can't find much to say about this proposal, > > Hum, OK, I thought it would be a useful addition :-) It's probably useful, but I'd have to take a closer look. It's been a long time I haven't used separate threads for timers... > Note that the time function must be "real" time, since the sleep are > based on condition.wait() (otherwise if you just call an arbitrary > sleep() function you can't be woken up when a new task with an > earlier > deadline is submitted). Agreed, but at least tornado supports a custom time function, even though their event loop is based on epoll() (under Linux): http://www.tornadoweb.org/en/stable/ioloop.html#tornado.ioloop.IOLoop.time This means: 1) the custom time function is used to adjust the epoll() timeout according to pending timed calls 2) the epoll() call times out based on the system time function I suppose it works well enough when the divergence is not too large, and/or the wakeups are frequent enough that there are no glaring defects. "Practicality beats purity", I guess :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 17:46:24 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 15:46:24 +0000 Subject: [issue17969] multiprocessing crash on exit In-Reply-To: <1368444694.56.0.376585959821.issue17969@psf.upfronthosting.co.za> Message-ID: <1368459984.92.0.0993714942057.issue17969@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Yes, I think it's too delicate to change in 2.7 right now. As Charles-Fran?ois said, daemon threads should be much less crashy in 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 17:48:59 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 15:48:59 +0000 Subject: [issue17934] Add a frame method to clear expensive details In-Reply-To: <1368014042.2.0.41504275061.issue17934@psf.upfronthosting.co.za> Message-ID: <1368460139.59.0.93105307646.issue17934@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Updated patch addressing some of Nick's comments. ---------- Added file: http://bugs.python.org/file30252/frame_clear_alt2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 17:53:29 2013 From: report at bugs.python.org (Daniel Urban) Date: Mon, 13 May 2013 15:53:29 +0000 Subject: [issue17950] Dynamic classes contain non-breakable reference cycles In-Reply-To: <1368217344.29.0.260515184231.issue17950@psf.upfronthosting.co.za> Message-ID: <1368460409.14.0.616349183932.issue17950@psf.upfronthosting.co.za> Changes by Daniel Urban : ---------- nosy: +daniel.urban _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 18:14:04 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 13 May 2013 16:14:04 +0000 Subject: [issue17969] multiprocessing crash on exit In-Reply-To: <1368444694.56.0.376585959821.issue17969@psf.upfronthosting.co.za> Message-ID: <1368461644.96.0.252040085832.issue17969@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Well, knowing that they crash less in 3.3 doesn't really fix the problem now, does it? We can consider two options then: 1) A multiprocessing specific fix. Removing this handle close gil release (which is superfluous, since these calls aren't blocking in any real sense) will certainly remove _this_ instance of the crash. An alternative is to make this worker thread non-daemon. That shouldn't be too hard and shouldn't have any other side effects. 2) A general daemon thread fix. For example, removing the GIL at the start of the shutdown process will make it impossible to release it. We can do this by setting interpreter_lock to NULL. I don't see the point of having 2.7 in bug fix mode if we can't fix bugs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 19:05:36 2013 From: report at bugs.python.org (Phil Connell) Date: Mon, 13 May 2013 17:05:36 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368464736.71.0.987146605143.issue17947@psf.upfronthosting.co.za> Changes by Phil Connell : ---------- nosy: +isoschiz, pconnell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 19:07:35 2013 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 13 May 2013 17:07:35 +0000 Subject: [issue17934] Add a frame method to clear expensive details In-Reply-To: <1368014042.2.0.41504275061.issue17934@psf.upfronthosting.co.za> Message-ID: <1368464855.97.0.970733445403.issue17934@psf.upfronthosting.co.za> Guido van Rossum added the comment: A downside of using this is that some extended traceback printers (such as cgitb.py in the stdlib, or and some things I've seen in web frameworks) won't be able to print the locals. And pdb's pm() function would lose its value too. So it'll remain a judgment call whether to use this. As for Tulip, I think I've broken the cycle I was most concerned about, and I've also gotten rid of the lambda that cost me so much time debugging. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 19:27:39 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 17:27:39 +0000 Subject: [issue17969] multiprocessing crash on exit In-Reply-To: <1368461644.96.0.252040085832.issue17969@psf.upfronthosting.co.za> Message-ID: <1368466057.2545.1.camel@fsol> Antoine Pitrou added the comment: Le lundi 13 mai 2013 ? 16:14 +0000, Kristj?n Valur J?nsson a ?crit : > I don't see the point of having 2.7 in bug fix mode if we can't fix > bugs. Delicate bug fixes may entail regressions, and we've had enough of them in 2.7.4. You've already patched your own Python anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 19:29:59 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Mon, 13 May 2013 17:29:59 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368028726.5.0.833825784859.issue17936@psf.upfronthosting.co.za> Message-ID: <1368466199.86.0.987728143845.issue17936@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: That is not sufficient. The weakrefs may have been cleared already if the deletion comes as a result of garbage collection (which is currently the only way classes get deleted.) It is still easily demonstratably correct: The previous version _only_ removed subclasses on setting __bases__. Housekeeping of stale weakrefs was done when new classes were created. This proposed version still properly removes subclasses when setting __bases__, but housekeeping of dead weakrefs is now moved to the point when a class is deleted. To do housekeeping of stale weakrefs, it is sufficient to remove _one_ stale weakref for each class that is deleted. It is not important that this is the correct stale weakref, all stale weakrefs are the same. I've uploaded an updated patch with added in-line comments explaining the case. ---------- Added file: http://bugs.python.org/file30253/subtype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 19:32:35 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 13 May 2013 17:32:35 +0000 Subject: [issue17969] multiprocessing crash on exit In-Reply-To: <1368444694.56.0.376585959821.issue17969@psf.upfronthosting.co.za> Message-ID: <1368466355.2.0.615091104071.issue17969@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > We can consider two options then: > 1) A multiprocessing specific fix. Removing this handle close gil > release (which is superfluous, since these calls aren't blocking in any > real sense) will certainly remove _this_ instance of the crash. An > alternative is to make this worker thread non-daemon. That shouldn't > be too hard and shouldn't have any other side effects. Have you tried doing p = Pool() try: ... finally: p.close() # or perhaps p.terminate() p.join() Actually, making the worker thread non-daemonic is not so simple. This is because there is no way to interrupt a background thread which is blocked doing IO (unless you use multiplexing which is not possible with non-overlapped pipes). One can try to unblock such background threads by reading/writing messages from/to the result/task pipe, but it not straightforward. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 19:42:23 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 17:42:23 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368028726.5.0.833825784859.issue17936@psf.upfronthosting.co.za> Message-ID: <1368466943.94.0.548821853346.issue17936@psf.upfronthosting.co.za> Antoine Pitrou added the comment: One thing: "int i" should be "Py_ssize_t i". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 19:48:57 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 13 May 2013 17:48:57 +0000 Subject: [issue17968] memory leak in listxattr() In-Reply-To: <1368438526.63.0.243173178736.issue17968@psf.upfronthosting.co.za> Message-ID: <3b8TzX6lG3z7Ljc@mail.python.org> Roundup Robot added the comment: New changeset 2187cf880e5b by Antoine Pitrou in branch '3.3': Issue #17968: Fix memory leak in os.listxattr(). http://hg.python.org/cpython/rev/2187cf880e5b New changeset 1fa1a021ed23 by Antoine Pitrou in branch 'default': Issue #17968: Fix memory leak in os.listxattr(). http://hg.python.org/cpython/rev/1fa1a021ed23 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 19:49:21 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 17:49:21 +0000 Subject: [issue17968] memory leak in listxattr() In-Reply-To: <1368438526.63.0.243173178736.issue17968@psf.upfronthosting.co.za> Message-ID: <1368467361.7.0.523872991261.issue17968@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Should be fixed now. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 20:03:09 2013 From: report at bugs.python.org (Paul Jurczak) Date: Mon, 13 May 2013 18:03:09 +0000 Subject: [issue17966] Lack of consistency in PEP 8 -- Style Guide for Python Code In-Reply-To: <1368418116.32.0.199767602115.issue17966@psf.upfronthosting.co.za> Message-ID: <1368468189.87.0.276372816665.issue17966@psf.upfronthosting.co.za> Paul Jurczak added the comment: I admit, it is somewhat silly, but not entirely silly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 20:28:02 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 13 May 2013 18:28:02 +0000 Subject: [issue17970] Mutlithread XML parsing cause segfault In-Reply-To: <1368453158.92.0.142296100122.issue17970@psf.upfronthosting.co.za> Message-ID: <1368469682.78.0.0272765109936.issue17970@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Expat is not thread-safe at the object level, a single Parser cannot be used from multiple threads. Pyexpat could add locks to Parser objects. ---------- nosy: +amaury.forgeotdarc stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 20:32:50 2013 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 13 May 2013 18:32:50 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368469970.49.0.194089170746.issue17947@psf.upfronthosting.co.za> Guido van Rossum added the comment: Here's the promised explanation why I want to keep the getframe hack. I'm sure it won't satisfy everyone, but this will have to do. There are two parts to my argument. TL;DR: (a) by implementing this hack, we will maximize user happiness; (b) I expect that all Python implementations can provide the functionality needed. So why does this maximize user happiness? First of all, enums are such simple objects that it's a disgrace to have an enum that isn't picklable. But most users are lazy and lack imagination, so if they find they have to do extra work to ensure that something is picklable, they will make a judgement call -- is the extra work to make it picklable worth it? Unfortunately they will try to make this judgment call in a fraction of a second, and they limited imagination they may well say "I can't imagine ever pickling this", save themselves the work, and move on. If you think more than a second about the decision, you've wasted more time than it takes to type "module=__name__", so it's going to be a split-second decision. But nevertheless, having to think about it and typing it is a distraction, and when you're "in the zone" you may prefer to spend your time thinking about the perfect names for your enum class and values rather than the red tape of making in picklable. So, in my mind, it's a given that there will be many enums that are missing the module=__name__ keyword argument. Moreover, it's likely that most of the time this will be fine -- you can get through most days just fine without ever reading or writing a pickle. (For example, I very much doubt that I've ever pickled one of the flag values used by the socket module to define e.g. the address family, socket type, or protocol.) But now you enter a different phase of your project, or one of your collaborators does, or perhaps you've released your code on PyPI and one of your users does. So someone tries to pickle some class instance that happens to contain an unpicklable enum. That's not a great experience. Pickling and unpickling errors are often remarkably hard to debug. (Especially the latter, so I have privately admonished Ethan to ensure that if the getframe hack doesn't work, the pickle failure should happen at pickling time, not at unpickle time.) Once you've tracked down the source, you have to figure out the fix -- hopefully just typing the error message into Google will link back to a StackOverflow answer explaining the need to say "module=__name__". But the damage is done, especially if the person encountering the pickling error is not the original author of the code defining the enum. (Often the person downloading and using a package from PyPI has less advanced Python knowledge than the package author, so they may have a hard time debugging the situation.) You can see how having the getframe hack in place makes life more pleasant for many people -- the package user won't have to debug the pickling problem, and the package author won't have to deal with the bug report and fix. But what about other Python implementations? Well, TBH, they have plenty of other issues. The reality is that you can't take a large package that hasn't been tested on Jython, or IronPython, or PyPy, and expect it to just work on any of those. Sure, things are getting better. But there are still tons of differences between the various Python implementations (as there are between different versions of CPython), and whether you like it or not, CPython is still the Python version of choice for most people. The long and short of it is that porting any significant package to another implementation is a bit of work, and keeping the port working probably requires adding some set of additional line items to the style guide used by its developers -- don't use feature X, don't depend on behavior Y, always use pattern Z... However, I don't expect that "always pass module=__name__ when using the enum convenience API" won't have to be added to that list. sys._getframe() is way more powerful than what's needed. Even on platforms where sys._getframe() is unimplementable (or disabled by default in favor of a 10% speedup), it should still be possible to provide an API that *just* gets the module name of the caller, at least in case the call site is top-level module code (and for anything else, the getframe hack doesn't work anyway). After all, we're talking about a full Python implementation, right? That's a dynamic language with lots of introspection APIs, and any implementation worth its salt will have to deal with that, even if full-fledged sys._getframe() is explicitly excluded. So I propose that we use sys._getframe() for the time being, and the authors of Jython, IronPython and PyPy can get together and figure out how to implement something like sys.get_calling_module_name(). They have plenty of time -- at least until they pledge support for Python 3.4. To make it easy for them we should probably add that API to CPython 3.4. And it's fine with me if the function only works if the caller is top-level code in a module. Which reminds me. Nick offered another use case where using sys._getframe() breaks down: a wrapper function that constructs an enum for its caller. First of all, I think this is a pretty rare use case. But additionally, that wrapper could just use sys.get_calling_module_name(), and everything would be fine. PS. Whoever adds sys.get_calling_module_name() to CPython, please pick a shorter name. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 20:32:54 2013 From: report at bugs.python.org (Alex Gaynor) Date: Mon, 13 May 2013 18:32:54 +0000 Subject: [issue17970] Mutlithread XML parsing cause segfault In-Reply-To: <1368453158.92.0.142296100122.issue17970@psf.upfronthosting.co.za> Message-ID: <1368469974.24.0.961697007406.issue17970@psf.upfronthosting.co.za> Alex Gaynor added the comment: It could also track tids and raise an error if you attempt to use it from multiple threads. ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 20:35:58 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 13 May 2013 18:35:58 +0000 Subject: [issue17970] Mutlithread XML parsing cause segfault In-Reply-To: <1368453158.92.0.142296100122.issue17970@psf.upfronthosting.co.za> Message-ID: <1368470158.34.0.902304073602.issue17970@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: But this would break working code which already uses locks correctly (or some kind of pool of cached parsers) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 20:37:03 2013 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 13 May 2013 18:37:03 +0000 Subject: [issue17963] Deprecate the frame hack for implicitly getting module details In-Reply-To: <1368364153.58.0.131087315276.issue17963@psf.upfronthosting.co.za> Message-ID: <1368470223.77.0.892473170027.issue17963@psf.upfronthosting.co.za> Guido van Rossum added the comment: As I explained in issue 17947, I think that any Python implementation worth its salt should be able to implement sys.get_calling_module_name() (*), at least for the case where the caller is top-level code in a module body. That is a much weaker requirement than being able to implement sys._getframe(). We should just add this to CPython 3.4 and require that conforming implementations support it, at least in the stated context (top-level caller). (*) Please pick a somewhat shorter name for it. ---------- assignee: gvanrossum -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 20:40:23 2013 From: report at bugs.python.org (Alex Gaynor) Date: Mon, 13 May 2013 18:40:23 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368470423.07.0.858190323531.issue17947@psf.upfronthosting.co.za> Alex Gaynor added the comment: >From PyPy's perspective we don't really care what you name this particular bikeshed, and it's probably not that important to us (in this particular case). As far as I know IronPython is the only Python VM that doesn't have _getframe() support by default (you need a CLI flag at startup, IIRC). In PyPy calling _getframe (right now) has a negative performance impact, but it's local to wherever you're calling it, so unless you create Enum in frequent loops (as opposed to just once at module level), this doesn't really matter to us. If someone wants to invent a more narrow, tailored API for stack introspection, logging is a much better target (right now each call to logging.{info,error,etc.} calls _getframe(), which does have a real performance impact. (We'll eventually invent enough engineering to fix this ourselves, but in the meantime if somewhere were to pain this bikeshed, we certainly wouldn't object ;)). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 20:45:51 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 18:45:51 +0000 Subject: [issue17970] Mutlithread XML parsing cause segfault In-Reply-To: <1368453158.92.0.142296100122.issue17970@psf.upfronthosting.co.za> Message-ID: <1368470751.01.0.647480883188.issue17970@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 20:47:13 2013 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 13 May 2013 18:47:13 +0000 Subject: [issue17950] Dynamic classes contain non-breakable reference cycles In-Reply-To: <1368217344.29.0.260515184231.issue17950@psf.upfronthosting.co.za> Message-ID: <1368470833.86.0.778335897202.issue17950@psf.upfronthosting.co.za> Guido van Rossum added the comment: I think turning the __mro__ tuple into a getter is fine. As long as this works I'm okay: class C: ... mro = C.__mro__ del C assert mro[0].__name__ == 'C' (The last assert stands in for asserting that the class object must stay alive as long as the tuple returned by __mro__ is alive.) I think it's also fine if the descriptors contain weak references. Its hard to get a "raw" descriptor anyways -- you can't say C.desc, you'd have to say C.__dict__['desc']. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 20:53:13 2013 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 13 May 2013 18:53:13 +0000 Subject: [issue6208] path separator output ignores shell's path separator: / instead of \ In-Reply-To: <1244226110.31.0.876689452852.issue6208@psf.upfronthosting.co.za> Message-ID: <1368471193.07.0.808912186537.issue6208@psf.upfronthosting.co.za> Mark Lawrence added the comment: Can this issue to confined to the small round filing cabinet, mainly on the grounds that I find some of the wording undecipherable? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 21:03:13 2013 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 13 May 2013 19:03:13 +0000 Subject: [issue17941] namedtuple should support fully qualified name for more portable pickling In-Reply-To: <1368071216.78.0.0822877752405.issue17941@psf.upfronthosting.co.za> Message-ID: <1368471793.97.0.603295844297.issue17941@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'd like to propose one slight tweak to the patch. (Also to enum.py.) If no module name was passed and _getframe() fails, can you set the __module__ attribute to something that will cause pickling the object to fail? That would be much better than letting it pickle but then being unable to unpickle it. (TBH I'm not sure how this should be accomplished, and if it can't, forget that I said it. But it would be nice.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 21:41:31 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Mon, 13 May 2013 19:41:31 +0000 Subject: [issue17941] namedtuple should support fully qualified name for more portable pickling In-Reply-To: <1368471793.97.0.603295844297.issue17941@psf.upfronthosting.co.za> Message-ID: <519141E7.4020100@gmail.com> Richard Oudkerk added the comment: When pickling a class (or instance of a class) there is already a check that the invariant getattr(sys.modules[cls.__module__], cls.__name__) == cls holds. >>> import pickle >>> class A: pass ... >>> A.__module__ = 'nonexistent' >>> pickle.dumps(A()) Traceback (most recent call last): File "", line 1, in _pickle.PicklingError: Can't pickle : import of module 'nonexistent' failed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 21:50:28 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 13 May 2013 19:50:28 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1368437160.42.0.0105279775356.issue17914@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: Just for giggles, here's the glibc default implementation on non Linux platforms: http://sourceware.org/git/?p=glibc.git;a=blob;f=misc/getsysstats.c;hb=HEAD """ int __get_nprocs () { /* We don't know how to determine the number. Simply return always 1. */ return 1; } """ And on Linux, 1 is returned as a fallback when you don't have the right /sys or /proc entry: http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/getsysstats.c (The enum discussion enlighted me, endless discussions are so fun!) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 21:57:04 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 19:57:04 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: Message-ID: <1368475021.4048.2.camel@fsol> Antoine Pitrou added the comment: > And on Linux, 1 is returned as a fallback when you don't have the > right /sys or /proc entry: > http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/getsysstats.c > > (The enum discussion enlighted me, endless discussions are so fun!) Do you want cpu_count() to return an enum? >>> os.cpu_count() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 22:02:02 2013 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 13 May 2013 20:02:02 +0000 Subject: [issue17941] namedtuple should support fully qualified name for more portable pickling In-Reply-To: <1368071216.78.0.0822877752405.issue17941@psf.upfronthosting.co.za> Message-ID: <1368475322.34.0.427610572625.issue17941@psf.upfronthosting.co.za> Guido van Rossum added the comment: Great, forget I said anything then. LGTM to the patch, feel free to commit (with update to Misc/NEWS please). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 22:05:00 2013 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 13 May 2013 20:05:00 +0000 Subject: [issue6208] path separator output ignores shell's path separator: / instead of \ In-Reply-To: <1244226110.31.0.876689452852.issue6208@psf.upfronthosting.co.za> Message-ID: <1368475500.29.0.602314343389.issue6208@psf.upfronthosting.co.za> Eric V. Smith added the comment: I say close it. Any "shell detection" is likely to be fragile, and any changes are likely to break something. It's not worth the risk. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 22:05:29 2013 From: report at bugs.python.org (Ned Batchelder) Date: Mon, 13 May 2013 20:05:29 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368475529.19.0.545562465188.issue17914@psf.upfronthosting.co.za> Ned Batchelder added the comment: Python's goal is not to emulate the suboptimal parts of other languages. We have dynamic typing, and so can return None from the same function that returns 1. And we have compact expressions like `cpu_count() or 1`, so we don't have to make unfortunate compromises. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 22:06:08 2013 From: report at bugs.python.org (Gregory HOULDSWORTH) Date: Mon, 13 May 2013 20:06:08 +0000 Subject: [issue17945] tkinter/Python 3.3.0: peer_create doesn't instantiate Text In-Reply-To: <1368110182.39.0.238603513669.issue17945@psf.upfronthosting.co.za> Message-ID: <1368475568.17.0.699554075273.issue17945@psf.upfronthosting.co.za> Gregory HOULDSWORTH added the comment: The Text instance created by the last patch has the same parent -in the Python w hierarchy- as the "model" widget regardless of the actual parent implied by the given pathname. Further, pathname is really a tk level construct: in Python this hierarchy is expressed the w's master and name. Attached is a proposed fix; peer_create now has the signature (self, master=None, cnf={}, **kw) The optional name of the peer is passed as an item in cnf. (note that the behaviour of peers is actually correct in the previous incarnation, only the children property is faulty and you have to go down to tk names to attach the text to an arbitrary parent) There is also an issue with subclassing of Text, to override the standard event handling for example. Should the peer be an instance of that subclass, or should this be a 'default' that may be overriden? ---------- Added file: http://bugs.python.org/file30254/peerfix.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 22:17:26 2013 From: report at bugs.python.org (Zachary Ware) Date: Mon, 13 May 2013 20:17:26 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368476246.75.0.836362831038.issue17947@psf.upfronthosting.co.za> Zachary Ware added the comment: I've come across something in the implementation here that I'd like some clarification on. What is the purpose of overriding __dir__ in Enum and EnumMeta? It doesn't change any behavior that I'm aware of, just makes things look a little nicer when someone calls dir() on their Enum. And, in fact, it can make things a little confusing. For example: >>> class Test(enum.Enum): ... foo = 1 ... bar = 2 ... baz = 3 ... >>> dir(Test) ['__class__', '__doc__', '__members__', 'bar', 'baz', 'foo'] >>> Test.mro This brings up another interesting case: >>> class Test2(enum.Enum): ... mro = 1 ... _create = 2 ... >>> dir(Test2) ['__class__', '__doc__', '__members__', '_create', 'mro'] >>> Test2.__members__ mappingproxy(OrderedDict([('mro', ), ('_create', )])) >>> Test2['mro'] >>> Test2.mro >>> Test2._create > >>> >From using "mro" or "_create", I would have expected either ValueError or for them to work properly. I don't know whether this should be fixed (one way or the other), documented, or just left alone; those kind of names really shouldn't ever be used anyway. It's something I stumbled across, though, and I just wanted to make sure that those who do have opinions that matter are aware of it :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 22:44:20 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 13 May 2013 20:44:20 +0000 Subject: [issue6208] path separator output ignores shell's path separator: / instead of \ In-Reply-To: <1244226110.31.0.876689452852.issue6208@psf.upfronthosting.co.za> Message-ID: <1368477860.14.0.850192420764.issue6208@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The resolution should be 'This is a gawd-awful mess created by Microsoft 30 years ago and we already do the best we sensibly can to deal with it' ;-) (and sensible people know it would be a mess from the first day). To put is another way, the answer to the original question 'can this be configured somehow' seems to be 'not obviously'. ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 22:56:54 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 13 May 2013 20:56:54 +0000 Subject: [issue17941] namedtuple should support fully qualified name for more portable pickling In-Reply-To: <1368071216.78.0.0822877752405.issue17941@psf.upfronthosting.co.za> Message-ID: <1368478614.16.0.0341430285281.issue17941@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: LGTM too. Needs test and docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 23:11:53 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 21:11:53 +0000 Subject: [issue1772673] Replacing char* with const char* Message-ID: <1368479513.78.0.339879030029.issue1772673@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > For external APIs visible to user code, this can cause some > compatibility problems and users may need to at the very least > re-compile this code. Can you explain exactly which compatibility problems this would cause? Actually, the point is precisely to make life easier for third-party code, since "const char *" is more accepting than "char *". ---------- nosy: +pitrou stage: -> needs patch versions: +Python 3.4 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 23:15:53 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 13 May 2013 21:15:53 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1368475529.19.0.545562465188.issue17914@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Python's goal is not to emulate the suboptimal parts of other languages. Well, I'm sure they could have returned -1 or 0, which are valid C long distinct from any valid integer representing a number of CPUs. If the libc guys (and many other APIs out there ), chose to return 1 as default, there's a reason. Furthermore, you're missing the point: since the underlying libraries os.cpu_count() rely on return 1 when they can't determine the number of CPUs, why complicate the API by pretending to return None in that case, since you can't detect it in the first place? > We have dynamic typing, and so can return None from the same function that returns 1. And we have compact expressions like `cpu_count() or 1`, so we don't have to make unfortunate compromises. That's not because it's feasible that it's a good idea. Dynamic typing is different from no typing: the return type of a function is part of its API. You can't return None when you're supposed to return an int. If I go to a coffee machine to get some chocolate and there's no chocolate left, I don't want it to return me a coffee instead. What's looks more natural if os.cpu_count() is None or if os.cpu_count() >= 1 Even in dynamic typing, it's always a good thing to be consistent in parameter and return value type. Why? For example, PEP 362 formalizes function signatures. With a os.cpu_count() returning a number (or eventually raising an exception), the signature is: def cpu_count() -> int [...] What does it become if you can return None instead? For example, there's some discussion to use such signatures or other DSL to automatically generate the glue code needed to parse arguments and return values from C extension modules (PEP 436 and 437). Basically, you just implement: /* ** [annotation] ** @return int */ long cpu_count_impl(void) { long result = 1; #ifdef _SC_NPROCESSORS_CONF long = sysconf(_SC_NPROCESSORS_ONL); [...] #fi return result; } And the DSL processor takes care of the rest. What does this become if your return object isn't typed? Really, typing is of paramount importance, even in a dynamically typed language. And pretending to return a distinct value is pretty much useless, since the underlying platform will always return a default value of 1. Plus `cpu_count() or 1` is really ugly. Now I hope I made my point, but honestly at this point I don't care anymore, since in practice it should never return None. Documenting the None return value is just noise in the API... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 23:21:23 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 21:21:23 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: Message-ID: <1368480080.4048.8.camel@fsol> Antoine Pitrou added the comment: > > Python's goal is not to emulate the suboptimal parts of other languages. > > Well, I'm sure they could have returned -1 or 0, which are valid C > long distinct from any valid integer representing a number of CPUs. If > the libc guys (and many other APIs out there ), chose to return 1 as > default, there's a reason. Well, they can be wrong sometimes, too :-) > Furthermore, you're missing the point: since the underlying libraries > os.cpu_count() rely on return 1 when they can't determine the number > of CPUs, why complicate the API by pretending to return None in that > case, since you can't detect it in the first place? The patch doesn't seem to rely on the glibc, so we are fine here. Or do the other libs work likewise? > And the DSL processor takes care of the rest. > > What does this become if your return object isn't typed? It's typed, just the type is "int or None". I'm sure some statically-typed languages are able to express this (OCaml? Haskell?). Anyway, I don't mind whether it's None or 0 or -42. But let's not hide the information. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 23:27:58 2013 From: report at bugs.python.org (Eli Bendersky) Date: Mon, 13 May 2013 21:27:58 +0000 Subject: [issue1772673] Replacing char* with const char* Message-ID: <1368480478.57.0.928335325039.issue1772673@psf.upfronthosting.co.za> Eli Bendersky added the comment: Antoine, I was referring to the discussion linked earlier (http://mail.python.org/pipermail/python-dev/2006-February/060689.html). Users of the C API needed to recompile their code and also add preprocessor hacks to make things compatible with C and C++, AFAIU. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 23:41:43 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 21:41:43 +0000 Subject: [issue1772673] Replacing char* with const char* In-Reply-To: <1368480478.57.0.928335325039.issue1772673@psf.upfronthosting.co.za> Message-ID: <1368481300.4048.13.camel@fsol> Antoine Pitrou added the comment: > Antoine, I was referring to the discussion linked earlier > (http://mail.python.org/pipermail/python-dev/2006-February/060689.html). Ok, I've read it through. The problem is specifically with pointers-to-pointers: http://mail.python.org/pipermail/python-dev/2006-February/060849.html And indeed, PyArg_ParseTupleAndKeywords() got its "const char **" argument changed back to "char **". But the other consts have stayed (such as the "const char *" argument to the same PyArg_ParseTupleAndKeywords()). So it looks like the patch, in essence, is legit. (of course, in practice, it probably won't apply cleanly, since it's very old; and perhaps it's incomplete too) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 13 23:54:13 2013 From: report at bugs.python.org (Eric Promislow) Date: Mon, 13 May 2013 21:54:13 +0000 Subject: [issue17971] Weird interaction between Komodo Python debugger C module & Python 3 Message-ID: <1368482053.55.0.661749882724.issue17971@psf.upfronthosting.co.za> New submission from Eric Promislow: While much of Komodo's source code has been released under MIT/GPL/LGPL, the Python debugger hasn't, so I can't post it here. We can work out an arrangement later, although it might not be necessary once I describe the problem: Komodo's Python debugger was a pure-Python debugger, based on pdb. To make it possible to debug the Chandler app, one of the components was written in C against the CPython API, for performance, and all was good. With Python 3, breakpoints no longer work after an exec with an explicit globals arg, where globals is a user-supplied dict, not "globals()" or "locals()". For example, in this code: print("I'm line 1") namespace = {} exec("a = 42", namespace) print("I'm line 4") print("Done") Set breakpoints at lines 1 and 4. Start the debugger in "Run" mode (stops at first breakpoint). The debugger stops at line 1. Press continue. The debugger runs to end, without stopping. If the namespace arg to exec is deleted, or replaced with "globals()" or "locals()", (quotes are typographic, not literal), the breakpoint at line 4 is honored. It only fails when globals is set to a new dict. Additionally, if the namespace is defined like so: namespace = {"DBGPHide": 1}, the breakpoint is honored. The debugger marks its internal frames with directives like "DBGPHide" to avoid stepping into them. Yes, it's a hack. Adding more diagnostics to the C file shows that the first time the debugger finds a frame with a global named DBGPHide, __name__ is "dbgp.common". This makes sense, because that module sets DBGPHide to 1, but after every other time, __name__ is "__main__" , and DBGPHide isn't set on it. I had a look at the implementation of exec in Python 3.3 in bltinmodule.c and ceval.c, but don't see anything obvious. Ref Komodo bug http://bugs.activestate.com/show_bug.cgi?id=98951 ---------- components: Interpreter Core messages: 189183 nosy: ericp priority: normal severity: normal status: open title: Weird interaction between Komodo Python debugger C module & Python 3 type: behavior versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 00:01:42 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Mon, 13 May 2013 22:01:42 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368482502.15.0.477364469217.issue17914@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: Based on the last 3 messages by Ned, Charles and Antoine, I keep thinking that arguments made by Charles are very valid ones and that it would be better to return 1. I say this (partly from the 'type' argument, but), mainly, *if* its known that the underlying libraries are returning 1 on failure. *If* that is the case I see no reason try to return None (which, btw, will never happen if none of the calls return non-positive values ever). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 00:08:14 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 13 May 2013 22:08:14 +0000 Subject: [issue17971] Weird interaction between Komodo Python debugger C module & Python 3 In-Reply-To: <1368482053.55.0.661749882724.issue17971@psf.upfronthosting.co.za> Message-ID: <1368482894.26.0.484864154606.issue17971@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +georg.brandl, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 00:32:54 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 13 May 2013 22:32:54 +0000 Subject: [issue17971] Weird interaction between Komodo Python debugger C module & Python 3 In-Reply-To: <1368482053.55.0.661749882724.issue17971@psf.upfronthosting.co.za> Message-ID: <1368484374.0.0.657922687723.issue17971@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Since this seems to be some sort of interaction between Komodo's code and Python (it works for me with vanilla Python 3), it's going to be hard to debug without seeing what this other thing is doing. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 00:33:46 2013 From: report at bugs.python.org (Kaleb Robertson) Date: Mon, 13 May 2013 22:33:46 +0000 Subject: [issue16024] Doc cleanup regarding path=fd, dir_fd, follow_symlinks, etc In-Reply-To: <1348500599.22.0.118178834994.issue16024@psf.upfronthosting.co.za> Message-ID: <1368484426.76.0.776521605694.issue16024@psf.upfronthosting.co.za> Kaleb Robertson added the comment: Adding a revision of the .diff file according to akuchling's comment. ---------- nosy: +kkvr05 Added file: http://bugs.python.org/file30255/lch.supports_set.doc.cleanup.1-revised.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 01:09:17 2013 From: report at bugs.python.org (Eric Promislow) Date: Mon, 13 May 2013 23:09:17 +0000 Subject: [issue17971] Weird interaction between Komodo Python debugger C module & Python 3 In-Reply-To: <1368482053.55.0.661749882724.issue17971@psf.upfronthosting.co.za> Message-ID: <1368486557.3.0.859137236539.issue17971@psf.upfronthosting.co.za> Eric Promislow added the comment: I'm running it inside gdb to see if I can figure it out. I don't see a way of isolating this from the whole product. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 01:21:25 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 13 May 2013 23:21:25 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368469970.49.0.194089170746.issue17947@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Thanks Guido, now that I fully understand your reasoning, I can accept that this is a valid "practicality beats purity" situation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 02:53:34 2013 From: report at bugs.python.org (Christian Heimes) Date: Tue, 14 May 2013 00:53:34 +0000 Subject: [issue17968] memory leak in listxattr() In-Reply-To: <1368438526.63.0.243173178736.issue17968@psf.upfronthosting.co.za> Message-ID: <1368492814.93.0.559339099675.issue17968@psf.upfronthosting.co.za> Christian Heimes added the comment: Coverity complains that your patch has introduced a double free bug. Can you have a look, please? ** CID 1021198: Double free (USE_AFTER_FREE) /Modules/posixmodule.c: 10161 http://scan5.coverity.com:8080//sourcebrowser.htm?projectId=10226#mergedDefectId=1021198 ________________________________________________________________________ CID 1021198: Double free (USE_AFTER_FREE) /Modules/posixmodule.c: 10123 ( freed_arg) 10120 10121 if (length < 0) { 10122 if (errno == ERANGE) { >>> "free(void *)" frees "buffer". 10123 PyMem_FREE(buffer); 10124 continue; 10125 } 10126 path_error(&path); 10127 break; /Modules/posixmodule.c: 10161 ( double_free) 10158 exit: 10159 path_cleanup(&path); 10160 if (buffer) >>> CID 1021198: Double free (USE_AFTER_FREE) >>> Calling "free(void *)" frees pointer "buffer" which has already been freed. 10161 PyMem_FREE(buffer); 10162 return result; 10163 } 10164 10165 #endif /* USE_XATTRS */ ---------- nosy: +christian.heimes status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 02:56:47 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 May 2013 00:56:47 +0000 Subject: [issue17968] memory leak in listxattr() In-Reply-To: <1368438526.63.0.243173178736.issue17968@psf.upfronthosting.co.za> Message-ID: <3b8gTB6ZD6z7LkW@mail.python.org> Roundup Robot added the comment: New changeset 7aa157971810 by Benjamin Peterson in branch '3.3': prevent double free in cleanup code (#17968) http://hg.python.org/cpython/rev/7aa157971810 New changeset 617cb2f978b0 by Benjamin Peterson in branch 'default': merge 3.3 (#17968) http://hg.python.org/cpython/rev/617cb2f978b0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 02:57:22 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 14 May 2013 00:57:22 +0000 Subject: [issue17968] memory leak in listxattr() In-Reply-To: <1368438526.63.0.243173178736.issue17968@psf.upfronthosting.co.za> Message-ID: <1368493042.67.0.122831389695.issue17968@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Technically a false alarm but it is a danger in the future. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 04:30:29 2013 From: report at bugs.python.org (Roger Serwy) Date: Tue, 14 May 2013 02:30:29 +0000 Subject: [issue14146] IDLE: source line in editor doesn't highlight when debugging In-Reply-To: <1330401708.67.0.511106941359.issue14146@psf.upfronthosting.co.za> Message-ID: <1368498629.43.0.608704253302.issue14146@psf.upfronthosting.co.za> Roger Serwy added the comment: It won't make it in 2.7.5. Benjamin tagged the 2.7.5 release a couple of days ago. I'll apply this later tonight. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 05:11:08 2013 From: report at bugs.python.org (xiaobing jiang) Date: Tue, 14 May 2013 03:11:08 +0000 Subject: [issue17972] inspect module leak docs Message-ID: <1368501068.91.0.677640111487.issue17972@psf.upfronthosting.co.za> New submission from xiaobing jiang: the inspect module leak docs. all these functions have no doc. getlineno getabsfile getblock formatannotation walktree findsource indentsize getargs formatannotationrelativeto classify_class_attrs ---------- assignee: docs at python components: Documentation messages: 189193 nosy: docs at python, s7v7nislands at gmail.com priority: normal severity: normal status: open title: inspect module leak docs type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 05:14:34 2013 From: report at bugs.python.org (Roger Serwy) Date: Tue, 14 May 2013 03:14:34 +0000 Subject: [issue14146] IDLE: source line in editor doesn't highlight when debugging In-Reply-To: <1330401708.67.0.511106941359.issue14146@psf.upfronthosting.co.za> Message-ID: <1368501274.44.0.300442116121.issue14146@psf.upfronthosting.co.za> Roger Serwy added the comment: On second thought, I'll wait until after the releases so that Misc/NEWS gets populated properly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 05:38:24 2013 From: report at bugs.python.org (Roger Serwy) Date: Tue, 14 May 2013 03:38:24 +0000 Subject: [issue17642] IDLE add font resizing hot keys In-Reply-To: <1365228385.87.0.236246362772.issue17642@psf.upfronthosting.co.za> Message-ID: <1368502704.04.0.510233029308.issue17642@psf.upfronthosting.co.za> Roger Serwy added the comment: @Abhishek: I'd rather not require extensions to have a new method for resetting font sizes. Instead, a virtual event can be bound to a callback by the extension if it needs to know about a font change. @Alejandro: It looks like there's a bug in ZoomFont.py where the cursor can go off screen which has propagated into these patches. That's my fault. I'll take a look at these points later this week. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 05:42:55 2013 From: report at bugs.python.org (Roger Serwy) Date: Tue, 14 May 2013 03:42:55 +0000 Subject: [issue13657] IDLE doesn't support sys.ps1 and sys.ps2. In-Reply-To: <1324640742.58.0.860347532783.issue13657@psf.upfronthosting.co.za> Message-ID: <1368502975.87.0.805097639901.issue13657@psf.upfronthosting.co.za> Roger Serwy added the comment: Adding 16123 as a dependency. Resolving sys.ps1 and sys.ps2 will likely be simpler when only considering one execution mode. ---------- dependencies: +IDLE - deprecate running without a subprocess nosy: +roger.serwy versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 05:56:24 2013 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 14 May 2013 03:56:24 +0000 Subject: [issue17959] Alternate approach to aliasing for PEP 435 In-Reply-To: <1368341497.6.0.896861896968.issue17959@psf.upfronthosting.co.za> Message-ID: <1368503784.13.0.20696665754.issue17959@psf.upfronthosting.co.za> Nick Coghlan added the comment: I just wanted to note that there's a trivial way to prevent accidental aliases inline or in your test suite if you don't intend them: class MyEnum(Enum): .... assert len(MyEnum) == len(MyEnum.__members__) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 05:56:30 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 14 May 2013 03:56:30 +0000 Subject: [issue17954] Support creation of extensible enums through metaclass subclassing In-Reply-To: <1368280534.51.0.41696456409.issue17954@psf.upfronthosting.co.za> Message-ID: <1368503790.92.0.186668353413.issue17954@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 06:29:00 2013 From: report at bugs.python.org (paul j3) Date: Tue, 14 May 2013 04:29:00 +0000 Subject: [issue9338] argparse optionals with nargs='?', '*' or '+' can't be followed by positionals In-Reply-To: <1279881989.28.0.725806934086.issue9338@psf.upfronthosting.co.za> Message-ID: <1368505740.14.0.249835681897.issue9338@psf.upfronthosting.co.za> paul j3 added the comment: I've played a bit the idea that barthard sketched. I don't have all the details worked out, but I believe this is what will happen: With parser = argparse.ArgumentParser() parser.add_argument('-w') parser.add_argument('-x', nargs='+') parser.add_argument('y') parser.add_argument('z', nargs='*') some possible parses are '-w 1 -x 2 3 4 5', # w:1, x:[2,3,4], y:5, z:[] - # fail + '-w 1 2 -x 3 4 5', # w:1, y:2, x:[3 4 5], z:[] + '-w 1 -x 2 3', # w:1, x:[2], y:3, z:[] - # fail + '-x 1 2 -w 3 4 5 6', # w:3, x:[1,2], y:4, z:[5,6] + # w:3, x:[1], y:2, z:[4,5,6] - '-x 1 2 3 4 -w 5 6 7', # w:5, x:[1,2,3,4], y:5, z:[7] + # w:5, x:[1,2,3], y:4, z:[6,7] - '1 2 3 -x 4 5 -w 6', # w:6, x:[4,5], y:1, z:[2,3] + '+' lines are those currently produced '-' lines are ones that would be produced by these ideas '-w 1 -x 2 3 4 5' is the protypical problem case. The current parser allocates all [2,3,4,5] to -x, leaving none for y, thus failing. So desired solution is to give 5 to y, leaving -x with the rest. '-x 1 2 -w 3 4 5 6' is a potentially ambiguous case. The current parser lets -x grab [1,2]; y then gets 4, and z the remainder. But the alternative is to give 2 to y, leaving -x with just [1]. In this case arg_strings_pattern = 'OAAOAAAA' replacing the Os with the option flags: '-xAA-wAAAA' I match this with a refined version of bethard's regex: pat1='((?:-wA)|(?:-xA+)|(?:-wA-xA+)|(?:-xA+-wA))' pat = _re.compile('%s?(?PA)%s?(?PA*)%s?'%(pat1,pat1,pat1)) groups (without the Nones) and groupdict are ['-xA', 'A', '-wA', 'AAA'] {'z': 'AAA', 'y': 'A'} So this does effectively give y the 2nd argument, leaving -x with just the 1st. The current parser effectively groups the arguments as ['-xAA, '-wA', 'A', 'AA'] In the real world, generating and apply a global pattern like this could get complicated. For example there are long option names ('--water'), and combined argument strings ('-x1', '-x=1'). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 07:36:54 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 14 May 2013 05:36:54 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1368480080.4048.8.camel@fsol> Message-ID: Charles-Fran?ois Natali added the comment: > Well, they can be wrong sometimes, too :-) Indeed, as can I ;-) > The patch doesn't seem to rely on the glibc, so we are fine here. > Or do the other libs work likewise? sysconf(_SC_NPROCESSORS_CONF) is implemented with the above function in the glibc. For other Unix systems apparently they use the sysctl() syscall, and I don't *think* it can fail to return the number of CPUs. So the only platforms where it could in theory fail are things like Cygwin, etc. > >> And the DSL processor takes care of the rest. >> >> What does this become if your return object isn't typed? > > It's typed, just the type is "int or None". I'm sure some > statically-typed languages are able to express this (OCaml? Haskell?). I recently started learning Haskell. You have Either and Maybe that could fall into that category. > Anyway, I don't mind whether it's None or 0 or -42. But let's not hide > the information. I liked your suggestion of making it an enum: >>> os.cpu_count() Nah, None is fine to me! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 09:45:16 2013 From: report at bugs.python.org (paul j3) Date: Tue, 14 May 2013 07:45:16 +0000 Subject: [issue9338] argparse optionals with nargs='?', '*' or '+' can't be followed by positionals In-Reply-To: <1279881989.28.0.725806934086.issue9338@psf.upfronthosting.co.za> Message-ID: <1368517516.6.0.799210315439.issue9338@psf.upfronthosting.co.za> paul j3 added the comment: I need to make one correction to my last post: '-x 1 2 -w 3 4 5 6', # w:3, x:[1,2], y:4, z:[5,6] + # w:3, x:[1], y:2, z:[4,5,6] - The second solution is only possible if 'z' is not consumed when 'y' is being processed. In current version, if consume_positionals() is called with a 'AOAAAA' pattern, 'y' will match the first 'A', and 'z' will match ''. That means '4 5 6' will be left over. It's only when I use the patch in http://bugs.python.org/issue14191#msg187051 (argparse doesn't allow optionals within positionals) that the processing 'z' is delayed, so it can get [4,5,6]. So at least with the 4 arguments in this example, bethard's idea only seems to make a difference in the case of '-w 1 -x 2 3 4 5', where 'y' lays claim to the last string, and '-x' gets the rest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 10:19:37 2013 From: report at bugs.python.org (Andy Chugunov) Date: Tue, 14 May 2013 08:19:37 +0000 Subject: [issue17973] '+=' on a list inside tuple both succeeds and raises an exception Message-ID: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> New submission from Andy Chugunov: At the same time append() succeeds silently, while simple '+' fails. Here's an example: >>> a = ([1],) >>> a[0].append(2) >>> a ([1, 2],) >>> a[0] += [3] Traceback (most recent call last): File "", line 1, in a[0] += [3] TypeError: 'tuple' object does not support item assignment >>> a ([1, 2, 3],) >>> a[0] = a[0] + [4] Traceback (most recent call last): File "", line 1, in a[0] = a[0] + [4] TypeError: 'tuple' object does not support item assignment >>> a ([1, 2, 3],) >>> Looks like a self-contradictory behavior. Unfortunately, I'm not yet advanced enough to figure out where the problem might be and submit a fix. Tested with v3.3.1 on Windows 7 (64-bit), and v3.2.3 and v2.7.3 on Debian 7 (also 64-bit). ---------- messages: 189201 nosy: andy.chugunov priority: normal severity: normal status: open title: '+=' on a list inside tuple both succeeds and raises an exception type: behavior versions: Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 10:52:10 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 14 May 2013 08:52:10 +0000 Subject: [issue17973] '+=' on a list inside tuple both succeeds and raises an exception In-Reply-To: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> Message-ID: <1368521530.55.0.293664245101.issue17973@psf.upfronthosting.co.za> Ronald Oussoren added the comment: This is a side effect to the way the in place operators work. Basically "a[0] += [3]" is evaluated as: a[0] = a[0].__iadd__([3]) The call to __iadd__ succeeds, which is why the list is updated, but you get an exception when the interpreter tries to update item 0 of the tuple. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 10:53:13 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 14 May 2013 08:53:13 +0000 Subject: [issue17973] '+=' on a list inside tuple both succeeds and raises an exception In-Reply-To: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> Message-ID: <1368521593.92.0.0471698847874.issue17973@psf.upfronthosting.co.za> Changes by Ronald Oussoren : ---------- assignee: -> ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 10:59:07 2013 From: report at bugs.python.org (Florent Xicluna) Date: Tue, 14 May 2013 08:59:07 +0000 Subject: [issue17973] '+=' on a list inside tuple both succeeds and raises an exception In-Reply-To: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> Message-ID: <1368521947.56.0.251386607447.issue17973@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 11:02:09 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 14 May 2013 09:02:09 +0000 Subject: [issue17973] '+=' on a list inside tuple both succeeds and raises an exception In-Reply-To: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> Message-ID: <1368522129.82.0.358403886191.issue17973@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I'm closing this issue as rejected because the current behavior is intentional, although it is confusing (IMO). ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 11:16:24 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 14 May 2013 09:16:24 +0000 Subject: [issue17128] OS X system openssl deprecated - installer should build local libssl In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za> Message-ID: <1368522984.33.0.305196510035.issue17128@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The RVM issue is wrong, ML still includes OpenSSL. Apple has deprecated the use of the system install of OpenSSL, but the library and include files are still there. There are two paths for avoiding the deprecated library: either ship your own build of OpenSSL, or (and that's probably what Apple would prefer) use the Apple specific frameworks (common crypto and/or security transforms). The latter has the advantage of using the security infrastructure, such as the CA chain, as provided by Apple, but would require significant code changes in Python, might take even more work to get to work properly on OSX 10.6 or earlier (and cannot work on 10.4), and might cause problems with scripts that use os.fork() because a number of core Apple frameworks won't work properly in the child process and cause a hard crash when they were initialized in the parent and then used in a child. All in all it would be better to ship a recent version of OpenSSL with the binary installers on OSX. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 11:48:04 2013 From: report at bugs.python.org (Kiyoshi Aman) Date: Tue, 14 May 2013 09:48:04 +0000 Subject: [issue16531] Allow IPNetwork to take a tuple In-Reply-To: <1353621566.3.0.0992835206333.issue16531@psf.upfronthosting.co.za> Message-ID: <1368524884.06.0.375576042279.issue16531@psf.upfronthosting.co.za> Kiyoshi Aman added the comment: I would instead suggest a cidr or netmask kwarg, rather than accepting a tuple as first argument. ---------- nosy: +Kiyoshi.Aman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 13:31:30 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 14 May 2013 11:31:30 +0000 Subject: [issue17969] multiprocessing crash on exit In-Reply-To: <1368444694.56.0.376585959821.issue17969@psf.upfronthosting.co.za> Message-ID: <1368531090.53.0.514279613673.issue17969@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Catching regressions is what we have the regression tests for. If it is not in caught by the regression tests, then it is not a regression, by definition. Bug fix mode is for fixing bugs, IMHO. Yes, I have patched my local version. The reason I am here having this discussion is that I want to contribute to help others that are using 2.7 for multiprocessing. Others will have the same problem, and probably have, already. Anyway, I cannot easily reproduce the problem, it happens regularly in a live production environment. My patch is a conjecture based patch. But I actually had a different thought about how to handle this. The particular manifestation of this error occurs because an exception state is being cleared from the system dict. The dict contains a frame and there is where the connection object is being held. The problem can be avoided, by clearing the exception right at the start of the PyInterpreterState_Clear(), thus flushing out most side effects right at the start. I'll prepare a patch for you to review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 13:41:17 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 14 May 2013 11:41:17 +0000 Subject: [issue17950] Dynamic classes contain non-breakable reference cycles In-Reply-To: <1368217344.29.0.260515184231.issue17950@psf.upfronthosting.co.za> Message-ID: <1368531677.88.0.962646088346.issue17950@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Thanks Guido. The current patch provides the property you ask for. I will see if I can make the "fiddling" of the internal tuple less magical. I have one other question for you: The standard "mro" puts the class in the 0th position. But apparently, there is a mechanism for a "custom" mro, by calling an mro() function on the type (as far as I understand). However, the order of objects in the returned tuple is not verified, only the types of the objects therein (this is in mro_internal()) Yet there is code that manually skips the 0th element, e.g. this code /* Initialize tp_dict properly */ bases = type->tp_mro; assert(bases != NULL); assert(PyTuple_Check(bases)); n = PyTuple_GET_SIZE(bases); for (i = 1; i < n; i++) { PyObject *b = PyTuple_GET_ITEM(bases, i); if (PyType_Check(b)) inherit_slots(type, (PyTypeObject *)b); } (from PyType_Ready()) I'm not familiar with the mro() function. What kind of black magic is it supposed to provide? And how can we make sure that its free-form return value is reconciled with the 1-based loop above? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 13:46:06 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 14 May 2013 11:46:06 +0000 Subject: [issue17969] multiprocessing crash on exit In-Reply-To: <1368444694.56.0.376585959821.issue17969@psf.upfronthosting.co.za> Message-ID: <1368531966.2.0.954835976632.issue17969@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Kristjan, could you confirm whether joining the pool explicitly before shutdown (in the way I suggested earlier) fixes the problem. I think it should -- at shutdown you won't switch to a thread if it has already been joined. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 13:49:41 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 14 May 2013 11:49:41 +0000 Subject: [issue17969] multiprocessing crash on exit In-Reply-To: <1368531090.53.0.514279613673.issue17969@psf.upfronthosting.co.za> Message-ID: <533693086.38791427.1368532175185.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > Catching regressions is what we have the regression tests for. If it > is not in caught by the regression tests, then it is not a > regression, by definition. Call it what you want :-) The bottom line is that we'll release a 2.7.5 soon because of breakage introduced in 2.7.4. Whether or not it's a "regression" according to some platonic definition isn't very important here. > The problem can be avoided, by clearing the exception right at the > start of the PyInterpreterState_Clear(), thus flushing out most side > effects right at the start. > > I'll prepare a patch for you to review. I think this kind of stuff is too tricky to risk breaking 2.7 once again with it. If 3.x has the same issue, then a patch is helpful, otherwise not IMHO. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 13:57:11 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 May 2013 11:57:11 +0000 Subject: [issue1772673] Replacing char* with const char* Message-ID: <1368532631.42.0.810625836433.issue1772673@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In C++ we may overload functions for backward compatibility: PyAPI_FUNC(int) PyArg_ParseTupleAndKeywords(PyObject *, PyObject *, const char *, const char * const *, ...); PyAPI_FUNC(int) PyArg_VaParseTupleAndKeywords(PyObject *, PyObject *, const char *, const char * const *, va_list va); ... #ifdef __cplusplus inline int PyArg_ParseTupleAndKeywords(PyObject *args, PyObject *keywords, const char *format, char * const *kwlist, ...) { int retval; va_list va; va_start(va, kwlist); retval = PyArg_ParseTupleAndKeywords(args, keywords, format, (const char * const *)kwlist, va_start); va_end(va); return retval; } #endif ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 14:04:21 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 14 May 2013 12:04:21 +0000 Subject: [issue17969] multiprocessing crash on exit In-Reply-To: <1368531090.53.0.514279613673.issue17969@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Catching regressions is what we have the regression tests for. If it is not in caught by the regression tests, then it is not a regression, by definition. You do realize this sentence doesn't make sense, do you? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 14:34:45 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 14 May 2013 12:34:45 +0000 Subject: [issue17974] Migrate unittest to argparse Message-ID: <1368534885.41.0.702465315617.issue17974@psf.upfronthosting.co.za> New submission from Antoine Pitrou: Attached patch migrates unittest to argparse. This doesn't make discover handling much saner, given the awful way it's originally implemented. ---------- components: Library (Lib) files: unittest_argparse.patch keywords: patch messages: 189212 nosy: ezio.melotti, michael.foord, pitrou priority: normal severity: normal stage: patch review status: open title: Migrate unittest to argparse type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file30256/unittest_argparse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 14:36:44 2013 From: report at bugs.python.org (Michael Foord) Date: Tue, 14 May 2013 12:36:44 +0000 Subject: [issue17974] Migrate unittest to argparse In-Reply-To: <1368534885.41.0.702465315617.issue17974@psf.upfronthosting.co.za> Message-ID: <1368535004.99.0.12835683424.issue17974@psf.upfronthosting.co.za> Michael Foord added the comment: What's the benefit of this change? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 14:41:24 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 14 May 2013 12:41:24 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1368535284.36.0.13545762455.issue14596@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't think Serhiy's patch should be blocked by a larger issue. I suppose you could rebase easily over his changes. ---------- versions: +Python 3.4 -Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 14:45:01 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 14 May 2013 12:45:01 +0000 Subject: [issue17974] Migrate unittest to argparse In-Reply-To: <1368534885.41.0.702465315617.issue17974@psf.upfronthosting.co.za> Message-ID: <1368535501.28.0.147935550729.issue17974@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I was considering making it possible to customize command-line options, as requested by Guido, and it's better to expose the modern API rather than the more obsolete one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 15:06:36 2013 From: report at bugs.python.org (A.M. Kuchling) Date: Tue, 14 May 2013 13:06:36 +0000 Subject: [issue16024] Doc cleanup regarding path=fd, dir_fd, follow_symlinks, etc In-Reply-To: <1348500599.22.0.118178834994.issue16024@psf.upfronthosting.co.za> Message-ID: <1368536796.49.0.445290265151.issue16024@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Kaleb Robertson's changes look good. Larry, do you want to go ahead and commit this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 15:13:58 2013 From: report at bugs.python.org (Michael Foord) Date: Tue, 14 May 2013 13:13:58 +0000 Subject: [issue17974] Migrate unittest to argparse In-Reply-To: <1368534885.41.0.702465315617.issue17974@psf.upfronthosting.co.za> Message-ID: <1368537238.38.0.27394154704.issue17974@psf.upfronthosting.co.za> Michael Foord added the comment: Ok, feel free to reimplement discovery command line handling if it can be done in a compatible-but-less-horrible way. Anyway, the patch looks fine and a couple of minor cleanups in there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 15:43:35 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 May 2013 13:43:35 +0000 Subject: [issue17974] Migrate unittest to argparse In-Reply-To: <1368534885.41.0.702465315617.issue17974@psf.upfronthosting.co.za> Message-ID: <1368539015.52.0.0120850911076.issue17974@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't see much sense in this modernization, while the code does not use the capabilities of argparse (and even optparse). Why USAGE_AS_MAIN/USAGE_FROM_MODULE/etc exist, why help is not generated automatically? Why -v/-q store boolean flags instead of changing the numerical level of verbosity? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 15:56:06 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 14 May 2013 13:56:06 +0000 Subject: [issue17969] multiprocessing crash on exit In-Reply-To: <1368444694.56.0.376585959821.issue17969@psf.upfronthosting.co.za> Message-ID: <1368539766.57.0.621250782483.issue17969@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Richard, I'll review implement your change. It is a bit tricky to test this, since I can only tell after a few days if the particular (rare) problem has been fixed. The crash is a rare one but consistently happens with some probability we use multiprocessing to perform certain batch processing. About regressions: The term means that problems, previously fixed, become broken again. All fixes should reasonably have appropriate tests in the regression test suite. I don't know what particular "regressions" you have been battling since 2.7.4. I hope they are all testable by now. I only know that there is a exit problem with multiprocessing that statistically happens and is problemematic. It caused use to stop using multiprocessing and parallel jobs until I could diagnose the problem. I have suggested several fixes to this particular problem. I have two favorites, which would also help in the general case: 1) calling sys.exc_clear() at the beginning of the python finalize part, to throw out any lingering traceback and frame objects. This will cause side effects such as gil-twiddling to happen early, and without consequence. sys.exc_clear() is a safe api and used throughout the code, an extra call just prior to exit should be a very safe operation. 2) Turn off multi-threading at the start of python exit, by setting interpreter_lock to NULL. Again, this is a no-brainer, since the NULL value is already well defined and works well. It will cause all subsequent GIL releases to be no-ops. I personally favor the second one. It makes no sense to allow other threads to run after finalization has started and forcing them to stay dead is only prudent. 2.7 is not frozen, and it is in bug fix mode. If a solid bug fix to an actual problem is proposed, we should embrace it, and deal with any eventual fallout appropriate as the price of doing business. 2.7 is a product that is alive and well, used by millions of people and thousands of businesses and will remain so for quite some time. I know that most of the core devs have moved on to greener pastures, but I for one would like to stay loyal to this workhorse of a product and continue to make necessary improvements to it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 15:58:35 2013 From: report at bugs.python.org (Michael Foord) Date: Tue, 14 May 2013 13:58:35 +0000 Subject: [issue17974] Migrate unittest to argparse In-Reply-To: <1368534885.41.0.702465315617.issue17974@psf.upfronthosting.co.za> Message-ID: <1368539915.62.0.536656026736.issue17974@psf.upfronthosting.co.za> Michael Foord added the comment: Test discovery and new options (buffer, failfast etc) were bolted onto an old and ugly design. Yes the code could use an overhaul and rebuilding from scratch - but doing that whilst remaining fully compatible with all the existing usage patterns is "difficult". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 16:01:04 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 14 May 2013 14:01:04 +0000 Subject: [issue17974] Migrate unittest to argparse In-Reply-To: <1368534885.41.0.702465315617.issue17974@psf.upfronthosting.co.za> Message-ID: <1368540064.74.0.857464095954.issue17974@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 16:03:53 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 14 May 2013 14:03:53 +0000 Subject: [issue17969] multiprocessing crash on exit In-Reply-To: <1368444694.56.0.376585959821.issue17969@psf.upfronthosting.co.za> Message-ID: <1368540233.82.0.487788566674.issue17969@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Richard, reading the multiprocessing.py code, it appears that your suggestion of closign and joining the Pool() object should also do the trick. Doing that will certainly also fix this particular case. I'll implement that in our local application code. I'm still not happy that 2.7 has a potential exit crash if a daemon thread is left hanging :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 16:14:28 2013 From: report at bugs.python.org (A.M. Kuchling) Date: Tue, 14 May 2013 14:14:28 +0000 Subject: [issue17955] Minor updates to Functional HOWTO In-Reply-To: <1368287962.52.0.951274382256.issue17955@psf.upfronthosting.co.za> Message-ID: <1368540868.86.0.359112531446.issue17955@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Updated version of the patch: * uses 'r' instead of 'N'. * removes the old outline and some notes at the end. * minor rewriting. ---------- Added file: http://bugs.python.org/file30257/functional.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 16:36:37 2013 From: report at bugs.python.org (Dmitry Shachnev) Date: Tue, 14 May 2013 14:36:37 +0000 Subject: [issue11245] Implementation of IMAP IDLE in imaplib? In-Reply-To: <1298061371.03.0.0638918089315.issue11245@psf.upfronthosting.co.za> Message-ID: <1368542197.7.0.168034728192.issue11245@psf.upfronthosting.co.za> Changes by Dmitry Shachnev : ---------- nosy: +mitya57 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 16:43:59 2013 From: report at bugs.python.org (Patrick Welche) Date: Tue, 14 May 2013 14:43:59 +0000 Subject: [issue17975] libpython3.so conflicts between $VERSIONs Message-ID: <1368542639.2.0.817126483539.issue17975@psf.upfronthosting.co.za> New submission from Patrick Welche: I currently have python 2.7 and 3.2 installed concurrently. I just tried to install 3.3 as well, but a file conflicts between 3.2 and 3.3. It is libpython3.so. Given that we go out of our way e.g. with $(INSTALL_DATA) Misc/python.pc $(DESTDIR)$(LIBPC)/python-$(VERSION).pc to avoid clashes, what should be done about PY3LIBRARY? ---------- components: Build messages: 189223 nosy: prlw1 priority: normal severity: normal status: open title: libpython3.so conflicts between $VERSIONs type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 16:44:36 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 14 May 2013 14:44:36 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1368542676.47.0.427905360444.issue17927@psf.upfronthosting.co.za> Guido van Rossum added the comment: Would you mind doing the backport then? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 16:58:13 2013 From: report at bugs.python.org (Christian Heimes) Date: Tue, 14 May 2013 14:58:13 +0000 Subject: [issue17970] Mutlithread XML parsing cause segfault In-Reply-To: <1368453158.92.0.142296100122.issue17970@psf.upfronthosting.co.za> Message-ID: <1368543493.61.0.929780977615.issue17970@psf.upfronthosting.co.za> Christian Heimes added the comment: In my opinion it's fine to document Python's XML parser as not thread-safe and leave locking to the user. Any fancy locking or tracking is going to make it slower for users. Any it takes a lot of effort to implement the feature, too. lxml offers a faster XML parser with multi-threading support. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 17:10:27 2013 From: report at bugs.python.org (Jaakko Moisio) Date: Tue, 14 May 2013 15:10:27 +0000 Subject: [issue17976] file.write doesn't raise IOError when it should Message-ID: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za> New submission from Jaakko Moisio: file.write doesn't sometimes raise IOError when it should, e.g. writing to /dev/full in line buffered mode: jaakko at jm-laptop:~$ python Python 2.7.5+ (2.7:a32a3b79f5e8, May 14 2013, 14:20:11) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> f=open('/dev/full','w',1) >>> f.write('hello\n') Traceback (most recent call last): File "", line 1, in IOError: [Errno 28] No space left on device >>> f.close() >>> f=open('/dev/full','w',1) >>> f.write('hello') >>> f.write('\n') >>> f.close() >>> # No IOError! ... >>> The current implementation of file.write relies on comparing the return value of fwrite to the expected number of bytes written to detect errors. I haven't dug deep enough into the C standard to know for sure if fwrite return value == expected should always imply no error, but in my example it clearly doesn't (I assume my glibc and fwrite aren't broken though). However using ferror to detect the error works fine and IOError was raised as expected. Python3 and io module use different implementation where this is no longer an issue. For us still using Python 2.7 I suggest the attached simple patch to fix the issue. ---------- components: Interpreter Core files: fileobject-fix.patch keywords: patch messages: 189226 nosy: jasujm priority: normal severity: normal status: open title: file.write doesn't raise IOError when it should type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file30258/fileobject-fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 17:28:11 2013 From: report at bugs.python.org (Jan Safranek) Date: Tue, 14 May 2013 15:28:11 +0000 Subject: [issue17922] Crash in clear_weakref In-Reply-To: <518B4B4A.5000109@redhat.com> Message-ID: <51925809.2020104@redhat.com> Jan Safranek added the comment: On 05/09/2013 09:07 AM, Jan Safranek wrote: > > Jan Safranek added the comment: > > On 05/07/2013 05:32 PM, Antoine Pitrou wrote: >> Jan, one possibility would be for Pegasus to stop "unloading" Python, >> it seems. > > It is always possibility. Actually, Pegasus "plugin" is just a shared > object (.so) and the .so is linked with Python. Pegasus calls dlopen() > and dlclose() on it. After dlclose(), the "plugin" is removed from > memory. Unfortunately, libpython2.7.so stays loaded, at least > /proc/XXX/mems says so. If there was a way to unload libpython2.7.so > from memory too... libpython2.7.so is not unloaded because python extensions, e.g. /usr/lib64/python2.7/lib-dynload/_heapq.so depend on it. And _heapq.so was dlopenened by Python and it was not dlclosed -> glibc does not unload it. It seems that Py_Finalize() does not even close opened shared objects. Isn't it a bug? Jan ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 17:31:19 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 14 May 2013 15:31:19 +0000 Subject: [issue17977] urllib.request.urlopen() cadefault argument is documented with wrong default value Message-ID: <1368545479.83.0.400534978811.issue17977@psf.upfronthosting.co.za> New submission from Barry A. Warsaw: The docs[1] say: .. function:: urlopen(url, data=None[, timeout], *, cafile=None, capath=None, cadefault=True) The code[2] says: def urlopen(url, data=None, timeout=socket._GLOBAL_DEFAULT_TIMEOUT, *, cafile=None, capath=None, cadefault=False): Obviously, the code cannot be changed in a stable release, and whether the default should be changed for 3.4 is a separate discussion. For now, the docs should be fixed to reflect the code. [1] Doc/library/urllib.request.rst [2] Lib/urllib/request.py ---------- assignee: barry components: Documentation messages: 189228 nosy: barry priority: normal severity: normal status: open title: urllib.request.urlopen() cadefault argument is documented with wrong default value type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 17:38:50 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 May 2013 15:38:50 +0000 Subject: [issue17977] urllib.request.urlopen() cadefault argument is documented with wrong default value In-Reply-To: <1368545479.83.0.400534978811.issue17977@psf.upfronthosting.co.za> Message-ID: <3b932x4VNKz7Ljb@mail.python.org> Roundup Robot added the comment: New changeset e2288953e9f1 by Barry Warsaw in branch '3.3': - Issue #17977: The documentation for the cadefault argument's default value http://hg.python.org/cpython/rev/e2288953e9f1 New changeset 85ecc4761a6c by Barry Warsaw in branch 'default': - Issue #17977: The documentation for the cadefault argument's default value http://hg.python.org/cpython/rev/85ecc4761a6c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 17:39:46 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 14 May 2013 15:39:46 +0000 Subject: [issue17977] urllib.request.urlopen() cadefault argument is documented with wrong default value In-Reply-To: <1368545479.83.0.400534978811.issue17977@psf.upfronthosting.co.za> Message-ID: <1368545986.91.0.552718100873.issue17977@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 17:43:43 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 14 May 2013 15:43:43 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368028726.5.0.833825784859.issue17936@psf.upfronthosting.co.za> Message-ID: <1368546223.83.0.826326089574.issue17936@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Yes, thanks for pointing that out, Antoine, I have made the change locally. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 18:10:02 2013 From: report at bugs.python.org (Armin Rigo) Date: Tue, 14 May 2013 16:10:02 +0000 Subject: [issue17950] Dynamic classes contain non-breakable reference cycles In-Reply-To: <1368217344.29.0.260515184231.issue17950@psf.upfronthosting.co.za> Message-ID: <1368547802.63.0.27865581962.issue17950@psf.upfronthosting.co.za> Armin Rigo added the comment: Well, adding weak references left and right to break cycles is going to subtly change or break people's code and hasn't been done so far, but that's only my opinion. Anyway, I want to correct what you say about tp_subclasses: yes, tp_subclasses is a list of weakrefs, but the reason is not (as I think you mean) to avoid cycles. The reason is simply that if it were strong references, then all classes ever created would stay alive. ---------- nosy: +arigo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 18:22:17 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 14 May 2013 16:22:17 +0000 Subject: [issue17970] Mutlithread XML parsing cause segfault In-Reply-To: <1368453158.92.0.142296100122.issue17970@psf.upfronthosting.co.za> Message-ID: <1368548537.88.0.763369442773.issue17970@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: In my opinion it's not fine to let Python crash. The implementation could be similar to the one in bufferedio.c, it's quite lightweight. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 18:26:07 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 14 May 2013 16:26:07 +0000 Subject: [issue17976] file.write doesn't raise IOError when it should In-Reply-To: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za> Message-ID: <1368548767.55.0.919021731763.issue17976@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: > I assume my glibc and fwrite aren't broken though Actually, it's a glibc bug when the last character is a '\n': $ python -c "f = open('/dev/full', 'w', 1); f.write('hello'); f.close()" Traceback (most recent call last): File "", line 1, in IOError: [Errno 28] No space left on device Normal. Now, you add a trailing newline: $ strace -e write python -c "f = open('/dev/full', 'w', 1); f.write('hello'); f.write('\n'); f.close()" write(3, "hello\n", 6) = -1 ENOSPC (No space left on device) write() still returns ENOSPC, but it gets ignored by fwrite(). I've had a quick look at the source, and I think the culprit is here: http://sourceware.org/git/?p=glibc.git;a=blob;f=libio/fileops.c#l1270 1336 if (do_write) 1337 { 1338 count = new_do_write (f, s, do_write); 1339 to_do -= count; 1340 if (count < do_write) 1341 return n - to_do; 1342 } It looks like there's a check missing here for count < 0. ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 18:37:54 2013 From: report at bugs.python.org (Meador Inge) Date: Tue, 14 May 2013 16:37:54 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1368549474.61.0.0332511924747.issue14596@psf.upfronthosting.co.za> Meador Inge added the comment: > I don't think Serhiy's patch should be blocked by a larger issue. > I suppose you could rebase easily over his changes. Where rebase=undo, sure. The changes for issue3132 are pretty extensive (the basic data structures are changed). And as mentioned in msg165892, msg188840, and msg125617 I have already proposed and implemented this optimization many months back. If we feel that this optimization is really critical, then I agree let's not hold it up and I will just work around it with my patch for issue3132. I don't see it as that critical, but I understand that the PEP 3118 changes are dragging on and this optimization might be important for some now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 18:39:02 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 May 2013 16:39:02 +0000 Subject: [issue17976] file.write doesn't raise IOError when it should In-Reply-To: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za> Message-ID: <1368549542.01.0.649751121557.issue17976@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Indeed, fwrite() can return expected number of items and set errno. Here is a simple example on C. An output is: setvbuf 0 0 fwrite 5 0 fwrite 1 28 fwrite 1 28 On writing "\n" fwrite returns 1 and set errno to ENOSPC. ---------- nosy: +serhiy.storchaka Added file: http://bugs.python.org/file30259/fullwrite.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 18:44:00 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 14 May 2013 16:44:00 +0000 Subject: [issue17974] Migrate unittest to argparse In-Reply-To: <1368537238.38.0.27394154704.issue17974@psf.upfronthosting.co.za> Message-ID: <1368549837.2562.2.camel@fsol> Antoine Pitrou added the comment: > Ok, feel free to reimplement discovery command line handling if it can > be done in a compatible-but-less-horrible way. I don't think it's possible. Best way forward would be to provide a pytest utility that does discovery automatically, and leave "python -m unittest" as the lesser, undocumented option. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 18:52:35 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 14 May 2013 16:52:35 +0000 Subject: [issue17976] file.write doesn't raise IOError when it should In-Reply-To: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za> Message-ID: <1368550355.86.0.479601952968.issue17976@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: > Indeed, fwrite() can return expected number of items and set errno. Here is a simple example on C. An output is: Yeah, who's volunteering to report it to the glibc? That's not a python bug, but I feel bad ignoring it. Note that ferror() isn't reliable (not on my box at least), so we have to use errno directly. And of course keep the check that the value returned by fwrite matches. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 19:03:25 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 14 May 2013 17:03:25 +0000 Subject: [issue17950] Dynamic classes contain non-breakable reference cycles In-Reply-To: <1368217344.29.0.260515184231.issue17950@psf.upfronthosting.co.za> Message-ID: <1368551005.49.0.596525207455.issue17950@psf.upfronthosting.co.za> Guido van Rossum added the comment: Kristjan, it seems you're in over your head. :-) The mro() function is documented here: http://docs.python.org/3/library/stdtypes.html?highlight=mro#class.mro It exists to be called instead of using __mro__ directly; a metaclass can then override what it returns. (Though I don't know if anyone has ever done this.) The code you quote is in PyType_Ready() and skips bases[0] because bases[0] has already been used as the basic "template" for the C-level layout of the instances. This particular loop adds additional slots to the layout and (most importantly) verifies that no bases are in conflict with the layout enforced by bases[0]. (This is required because we don't actually implement "virtual slots" at this level -- the C-level layout can only extend the first base class's layout.) BTW, Armin is also right about the reason for using weak references in the __subclasses__ list. As for replacing references with weak references, I would be much more concerned if you were proposing this for e.g. bound methods or instances, but that doesn't mean I'm completely unconcerned... In addition to worrying about breaking (obscure) code that might depend on those references, I worry that it is trying to optimize for an unusual case (dynamically created classes in a world where you don't want to call gc.collect()) but slowing down the common case (access of the class from the descriptor every time a descriptor is used). Specifically about your patch, I'm pretty sure there are some calls in there that don't expect a NULL pointer, as d_type is never NULL; but adding the weak reference makes it possible that your macro will return a NULL pointer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 19:07:45 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 14 May 2013 17:07:45 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1368549474.61.0.0332511924747.issue14596@psf.upfronthosting.co.za> Message-ID: <1368551263.2562.5.camel@fsol> Antoine Pitrou added the comment: Le mardi 14 mai 2013 ? 16:37 +0000, Meador Inge a ?crit : > If we feel that this optimization is really critical, then I agree > let's not hold it up and I will just work around it with my patch for > issue3132. I don't see it as that critical, but I understand that the > PEP 3118 changes are dragging on and this optimization might be important > for some now. Are you sure the PEP 3118 changes will land in 3.4? It would be a pity to lose a simple improvement because it was deferred to a bigger change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 19:11:20 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 14 May 2013 17:11:20 +0000 Subject: [issue17976] file.write doesn't raise IOError when it should In-Reply-To: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za> Message-ID: <1368551480.63.0.597355934988.issue17976@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Yuck. We can of course workaround this (the glibc is commonly used :-)). Why is ferror() not reliable? ---------- priority: normal -> low stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 19:59:56 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 14 May 2013 17:59:56 +0000 Subject: [issue17976] file.write doesn't raise IOError when it should In-Reply-To: <1368551480.63.0.597355934988.issue17976@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Why is ferror() not reliable? Because the glibc doesn't check the errno return code after the write() syscall, and thus doesn't set the file's stream error flag (ferror() just checks this flag). That's what I saw from the code. I was a little surprised when Jaako says that ferror() is enough to detect this, so I modified Serhiy code to print ferror(), and actually ferror() reports an error for subsequent writes, not for the first one (probably because the error goes unnoticed only when the buffer is in a particular state). So in short, errno is the only reliable way to check for errors :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 20:38:03 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 14 May 2013 18:38:03 +0000 Subject: [issue17807] Generator cleanup without tp_del In-Reply-To: <1366508251.45.0.78173664702.issue17807@psf.upfronthosting.co.za> Message-ID: <3b971k2SPbz7Ljb@mail.python.org> Roundup Robot added the comment: New changeset edefd3450834 by Antoine Pitrou in branch 'default': Backout c89febab4648 following private feedback by Guido. http://hg.python.org/cpython/rev/edefd3450834 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 20:40:58 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 14 May 2013 18:40:58 +0000 Subject: [issue17807] Generator cleanup without tp_del In-Reply-To: <1366508251.45.0.78173664702.issue17807@psf.upfronthosting.co.za> Message-ID: <1368556858.93.0.845559481073.issue17807@psf.upfronthosting.co.za> Antoine Pitrou added the comment: After getting some private feedback from Guido, I'm convinced this patch isn't ready for consumption. Objects visible from the frame when it is finalized can be in a weird, incomplete state (Guido reports failing to get the __class__ of an object, for instance). I'm keeping the issue open for now and will try to find further ways to solve the underlying problem. ---------- resolution: fixed -> stage: committed/rejected -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 20:41:05 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 14 May 2013 18:41:05 +0000 Subject: [issue17128] OS X system openssl deprecated - installer should build local libssl In-Reply-To: <1360002680.77.0.851671416179.issue17128@psf.upfronthosting.co.za> Message-ID: <1368556865.7.0.793697477242.issue17128@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The one difference between the system openssl and a separately compiled one is that the former can use the CA root from the KeyChain (and uses a private API to do that, as noted earlier). I just stumbled across a utility that can sync the KeyChain to an OpenSSL CA file: , and a blog message at ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 20:45:14 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 14 May 2013 18:45:14 +0000 Subject: [issue17922] Crash in clear_weakref In-Reply-To: <51925809.2020104@redhat.com> Message-ID: <1368557111.2562.11.camel@fsol> Antoine Pitrou added the comment: Le mardi 14 mai 2013 ? 15:28 +0000, Jan Safranek a ?crit : > libpython2.7.so is not unloaded because python extensions, e.g. > /usr/lib64/python2.7/lib-dynload/_heapq.so depend on it. And _heapq.so > was dlopenened by Python and it was not dlclosed -> glibc does not > unload it. > > It seems that Py_Finalize() does not even close opened shared objects. > Isn't it a bug? What do you call shared objects in this context? .so files? Indeed they are not closed, because usually extension modules are not reload-safe: therefore, their basic structures are kept eternally once initialized. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 21:04:38 2013 From: report at bugs.python.org (Jaakko Moisio) Date: Tue, 14 May 2013 19:04:38 +0000 Subject: [issue17976] file.write doesn't raise IOError when it should In-Reply-To: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za> Message-ID: <1368558278.4.0.26845791202.issue17976@psf.upfronthosting.co.za> Jaakko Moisio added the comment: Thank you for your comments. > I was a little surprised when Jaako says that ferror() is enough to > detect this, so I modified Serhiy code to print ferror(), and actually > ferror() reports an error for subsequent writes, not for the first one > (probably because the error goes unnoticed only when the buffer is in > a particular state). Strange. I too modified Serchiy's code and my version of glibc (2.15) set the error flag at the same fwrite call as errno was set: setvbuf 0 0 0 fwrite 5 0 0 fwrite 1 28 1 fwrite 1 28 1 (the last column being the return value of ferror after each fwrite call) I've trusted ferror until now but I'm not an expert on the subject. It's a good point that errno is set by the underlying system call and is thus more reliable. So would checking errno be sufficient (in addition to checking that the lengths agree)? It can only serve to make file_write more robust. ---------- Added file: http://bugs.python.org/file30260/fileobject-fix2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 21:55:43 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 14 May 2013 19:55:43 +0000 Subject: [issue17950] Dynamic classes contain non-breakable reference cycles In-Reply-To: <1368217344.29.0.260515184231.issue17950@psf.upfronthosting.co.za> Message-ID: <1368561343.68.0.588747953729.issue17950@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Armin: Of course you are right. This is what weak references are for, in a gc world, although their convenience to avoid cycles and enable reference counting to work always makes me forget. I have another ongoing issue regarding tp_subclasses, btw, in issue #17936. Guido: Yes, it is complicated. The reason I am doing this is because I'm working to incorporate these changes in our stackless 2.7 branch. I figured this might be useful to Python at large, hence this submission. relying on gc is not an option when using python in a performance sensitive environment. there are a few places in the core that cause cycles and I'm always keen to try to remove those. Of course we can avoid the dynamic creation of classes, which is perhaps somewhat exotic. But it is a simpler problem than the reference cylcle inherent in recursive closures. I had a crack at that a week ago and ran in to a wall, so I thought I'd set myself an easier target :) Thanks for clarifying mro(). What I was driving at was that without mro(), then type == type->tp_mro[0]. and knowing this, it is easy to put a None in tp_mro[0]. With a custom mro(), this restriction is no longer valid. But my patch deals with this by verifying the assumption. So, there is no big problem there. I hear you worry a bit about performance for descriptors. Performance is indeed a valid concern, but I"m not sure that an extra C indirection will show up on any readings, given that the next thing that happens is typically the creation of a bound method or the like, with all the stuff that entails. I am not too worried about possibly returning NULL. That's a technical detail that is fixable. A much better question is whether this is worth doing at all because the practice I'm trying to optimize is probably a rare practice as you point out. When do you truly need to create throwaway classes? Most places that do are simply defining classes in a function scope as a means of name scoping, not realizing that each function invocation will create a unique metaclass instance and cost a non-trivial amount of cpu. So, after this interesting sojourn into the bowels of typeobject.c, and these most enlightening discussions with you (Armin, Guido, Antoine) I don't think I'll pursue this any further. Cheers! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 22:10:14 2013 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 14 May 2013 20:10:14 +0000 Subject: [issue17950] Dynamic classes contain non-breakable reference cycles In-Reply-To: <1368217344.29.0.260515184231.issue17950@psf.upfronthosting.co.za> Message-ID: <1368562214.59.0.721347265179.issue17950@psf.upfronthosting.co.za> Guido van Rossum added the comment: Good call. I think it's perfectly fine for you to do this in your custom 2.7 branch. It feels too fragile to adopt the same approach for Python 3.4 though. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 22:35:19 2013 From: report at bugs.python.org (Meador Inge) Date: Tue, 14 May 2013 20:35:19 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1368563719.92.0.141992716312.issue14596@psf.upfronthosting.co.za> Meador Inge added the comment: > Are you sure the PEP 3118 changes will land in 3.4? It would be a pity > to lose a simple improvement because it was deferred to a bigger > change. No, I am not sure. That is why I said that I understand if others felt this bug was critical to fix now since the PEP 3118 changes were dragging on. In that case I will just rework my patch. I am not trying to stand in the way of this patch. I just wanted folks to be aware that this approach was implemented in the PEP 3118 work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 14 23:04:28 2013 From: report at bugs.python.org (Romulo A. Ceccon) Date: Tue, 14 May 2013 21:04:28 +0000 Subject: [issue17978] Python crashes if Py_Initialize/Py_Finalize are called multiple times Message-ID: <1368565468.18.0.0802244129119.issue17978@psf.upfronthosting.co.za> New submission from Romulo A. Ceccon: I have patched (see attachment) Python 2.7.4 (as available for download at python.org/download) to disable initialization of Unicode (an embeded system requirement) and now it segfaults with the following program: #include int main(int argc, char** argv) { int i; Py_NoSiteFlag = 1; Py_SetProgramName(argv[0]); for (i = 0; i < 3; i++) { printf("run no. %d\n", i); Py_Initialize(); Py_Finalize(); } return 0; } The problem appears to be related with the reference count of the empty tuple. I've also applied the following patch in Objects/tupleobject.c to help diagnose the problem: @@ -928,6 +928,8 @@ PyTuple_Fini(void) #if PyTuple_MAXSAVESIZE > 0 /* empty tuples are used all over the place and applications may * rely on the fact that an empty tuple is a singleton. */ + printf("free_list[0]->ob_refcnt before XDECREF: %d\n", + free_list[0]->ob_refcnt); Py_XDECREF(free_list[0]); free_list[0] = NULL; *Without* the patch for Python/pythonrun.c the program produces the following results under Ubuntu 13.04 x64: run no. 0 free_list[0]->ob_refcnt before XDECREF: 58 run no. 1 free_list[0]->ob_refcnt before XDECREF: 57 run no. 2 free_list[0]->ob_refcnt before XDECREF: 57 Note the strange ref count of the empty tuple (free_list[0]). Now, *with* the patch, the application will not hold so many references to the empty tuple and the finalization code ends up trying to deallocate it (what, from my limited understading of the code, is not supposed to happen): run no. 0 free_list[0]->ob_refcnt before XDECREF: 2 run no. 1 free_list[0]->ob_refcnt before XDECREF: 1 Segmentation fault (core dumped) The actual patch I'm using is much more complicated. This is just the minimal patch able to reproduce the problem. I tried undefining Py_USING_UNICODE but then the build doesn't succeed. ---------- components: Interpreter Core files: pythonrun.c.patch keywords: patch messages: 189250 nosy: Romulo A. Ceccon priority: normal severity: normal status: open title: Python crashes if Py_Initialize/Py_Finalize are called multiple times type: crash versions: Python 2.7 Added file: http://bugs.python.org/file30261/pythonrun.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 00:09:27 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 14 May 2013 22:09:27 +0000 Subject: [issue17976] file.write doesn't raise IOError when it should In-Reply-To: <1368558278.4.0.26845791202.issue17976@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Strange. I too modified Serchiy's code and my version of glibc (2.15) set the error flag at the same fwrite call as errno was set: > > setvbuf 0 0 0 > fwrite 5 0 0 > fwrite 1 28 1 > fwrite 1 28 1 > > (the last column being the return value of ferror after each fwrite call) Hum, you're right, I just re-ran the test, and I'm finding the same thing as you (I must have been dreaming). I just re-checked the glibc code, and indeed the write() error is checked, and the error flag is set: http://sourceware.org/git/?p=glibc.git;a=blob;f=libio/fileops.c#l1255 1241 _IO_ssize_t 1242 _IO_new_file_write (f, data, n) [...] 1251 count = (__builtin_expect (f->_flags2 1252 & _IO_FLAGS2_NOTCANCEL, 0) 1253 ? write_not_cancel (f->_fileno, data, to_do) 1254 : write (f->_fileno, data, to_do)); 1255 if (count < 0) 1256 { 1257 f->_flags |= _IO_ERR_SEEN; 1258 break; 1259 } But then this value is returned, and depending on the position in the buffer, this -1 ends up being incremented to what's left to write, and can result in returning exactly the same size that was requested. That's definitely a bug, and a bad one since you can get silent corruption (fclose() won't even return an error in most cases). Anyway, this means that ferror() should be enough - in addition to checking that the returned value matches. > I've trusted ferror until now but I'm not an expert on the subject. It's a good point that errno is set by the underlying system call and is thus more reliable. So would checking errno be sufficient (in addition to checking that the lengths agree)? It can only serve to make file_write more robust. Yeah, would you like to write a patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 00:10:00 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 14 May 2013 22:10:00 +0000 Subject: [issue16611] multiple problems with Cookie.py In-Reply-To: <1354654224.49.0.677339520856.issue16611@psf.upfronthosting.co.za> Message-ID: <1368569400.23.0.663127540559.issue16611@psf.upfronthosting.co.za> ?ric Araujo added the comment: I have just been bitten by a bug (haven?t checked if it?s covered by the added tests) where Cookies uses string.translate incorrectly: File "/usr/lib/python2.7/Cookie.py", line 323, in _quote if "" == translate(str, idmap, LegalChars): File "/usr/lib/python2.7/string.py", line 493, in translate return s.translate(table, deletions) TypeError: translate() takes exactly one argument (2 given) The state of the Cookie module is quite embarrassing. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 00:50:34 2013 From: report at bugs.python.org (Jaakko Moisio) Date: Tue, 14 May 2013 22:50:34 +0000 Subject: [issue17976] file.write doesn't raise IOError when it should In-Reply-To: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za> Message-ID: <1368571834.28.0.403765949075.issue17976@psf.upfronthosting.co.za> Jaakko Moisio added the comment: > Yeah, would you like to write a patch? Yes. It's fileobject-fix3.patch attached to this issue record. ---------- Added file: http://bugs.python.org/file30262/fileobject-fix3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 01:04:24 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 14 May 2013 23:04:24 +0000 Subject: [issue17974] Migrate unittest to argparse In-Reply-To: <1368534885.41.0.702465315617.issue17974@psf.upfronthosting.co.za> Message-ID: <1368572664.89.0.748859783081.issue17974@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which reimplement discovery command line handling in a i-hope-in-compatible-but-less-horrible way (and fixes some bugs). It is horrible still, but I doubt how many changes can I do without breaking compatibility. If _do_discovery() used only in tests, I can clean the code more. I suppose discovery mode doesn't make sense when unittest.main() is called from a test module (i.e. "./python Lib/test/test_bisect.py discover"). At least USAGE_FROM_MODULE did not mention this mode. ---------- Added file: http://bugs.python.org/file30263/unittest_argparse_less_horrible.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 01:27:01 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 14 May 2013 23:27:01 +0000 Subject: [issue17979] Cannot build 2.7 with --enable-unicode=no Message-ID: <1368574020.99.0.834797445108.issue17979@psf.upfronthosting.co.za> New submission from Amaury Forgeot d'Arc: python2.7 can't be compiled with --enable-unicode=no Because of a crash in the re module. It's a regression from 2.7.3. $ ./python -c 'import re; re.compile("([a-zA-Z][a-zA-Z0-9_]+)\s*=\s*(.*)")' Traceback (most recent call last): File "", line 1, in File "/home/amauryfa/python/cpython2.7/Lib/re.py", line 190, in compile return _compile(pattern, flags) File "/home/amauryfa/python/cpython2.7/Lib/re.py", line 240, in _compile p = sre_compile.compile(pattern, flags) File "/home/amauryfa/python/cpython2.7/Lib/sre_compile.py", line 533, in compile groupindex, indexgroup RuntimeError: invalid SRE code The cause is in sre.h: when Py_USING_UNICODE is false, SRE_CODE is defined as "unsigned long" instead of "unsigned short"! When this is fixed, the following modules did not compile: _io _json _sqlite3 _ssl _testcapi Which modules are supposed to work without unicode? ---------- assignee: serhiy.storchaka messages: 189255 nosy: amaury.forgeotdarc, serhiy.storchaka priority: normal severity: normal status: open title: Cannot build 2.7 with --enable-unicode=no versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 01:28:29 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 14 May 2013 23:28:29 +0000 Subject: [issue17978] Python crashes if Py_Initialize/Py_Finalize are called multiple times In-Reply-To: <1368565468.18.0.0802244129119.issue17978@psf.upfronthosting.co.za> Message-ID: <1368574109.48.0.780824591597.issue17978@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The official way to build without unicode is ./configure --enable-unicode=no But see issue17979. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 01:43:44 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 14 May 2013 23:43:44 +0000 Subject: [issue17977] urllib.request.urlopen() cadefault argument is documented with wrong default value In-Reply-To: <1368545479.83.0.400534978811.issue17977@psf.upfronthosting.co.za> Message-ID: <1368575024.89.0.370002748103.issue17977@psf.upfronthosting.co.za> Senthil Kumaran added the comment: OMG. That's a glaring mistake. Thanks for fixing it. ---------- nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 02:11:36 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 15 May 2013 00:11:36 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1368576696.89.0.970421345099.issue15392@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Attached is a 3.3 patch that I *believe* is ready to commit and push. With my Win7 repository build, I tested running one test from a file (after "if __name__ == '__main__':") or command line ('python_d -m idlelib.PathBrowser'); all idle tests with an interactive interpreter (console or idle shell, see @template.txt for input); all idle tests from the command line ('python_d -m test.test_idle'); and idle tests as part of the CPython suite (python_d -m test). I also tested versions of all but the two batch-mode tests in my 3.3.1 installation. >From what i know, I do not believe there should be much issue with the framework working on non-Windows systems. But I would not mind verification. I presume this patch will work as is with 3.4, but ditto. 2.7 may need one tweak noted below. (Testing with 2.7 is difficult for me at the moment.) Nick: yes to your 2.7 plan. PEP 343 changes things. Once applied to all three branches I think this patch is enough to close this issue and 'get the ball rolling'. Mock, gui testing, and any other big problems should be separate issues. The patch adds Itest/__init__.py (merges doc example, part of previous __init__.py) Itest/@template (for both test_x.py and startup from x.py) Itest/test_calltips.py (with first 2 of many tests) Itest/test_pathbrowser.py (revised, with 1 test, see note below) test/test_idle.py (revised skeleton of previous __init__.py) and revises CallTips.py PathBrowser.py to run the corresponding tests when run as '__main__'. Question: "Unittest supports skipping individual test methods and even whole classes of tests" How about skipping (possibly conditionally) an entire file -- especially test_idle, which has no classes, or and test_xxx with multiple classes? For multiple reasons related to the fact that Idle and idlelib *are* special, as recognized by PEP 343, I want to keep the individual test files in an idlelib subdirectory. as with tkinter tests. (I changed the name from 'test', so that 'import test' will a always import Lib/test.) * Once in idlelib, changing to Itest is easier than to ../test/test_idle. With 62 .py files in idlelib, we will be opening pairs of files a lot. * Copying code and test files to another directory, such as an installation idlelib/, will be easier. I will be doing that to run with new features and test things in the installation environment. * PEP343 makes most of idlelib/* a private arena. Test/* is a public tree mainly for the buildbots. Tests put there are supposed to pass. In brief, I personally feel much more comfortable mucking around in a private arena with a small public window that can selectively open and closed as needed. * We need an Itest directory anyway for things that do not belong in test/*. @template is an example, and I have in mind a couple of non-buildbot test scripts. We may also want an idle-specific support module, as tkinter has. * Once people install Python so it runs, some still have problems running Idle. They ask a class instructor or someone else; post here, python-list, stackoverflow, or elsewhere; or give up. Sometimes the problem is with tkinter, sometimes with idle, sometimes with their knowledge. A good diagnosis script should save support time and user frustration. Both tkinter and idle tests should be available for this. The Windows installer makes the 17 mb of test/* optional. Other changes from the previous patch: * Use unittest.main to run tests. * Guard test_idle execution with tkinter import, as it is _tkinter, not idlelib that might not be built. I left the guard for idlelib since someone who deletes idlelib/* might forget to delete test/test_idle. * Exceptions raised outside of self.assertXyz (and self.fail) calls are regarded as an error in the test code rather than a failure of the code tested (26.3.4. Organizing test code). So, there being no 'assertNotRaises' context manager, I added "try:...except ...: self.fail()" to test_pathbrowser.py so a failure will be reported as such and not as an error. If there is a better way to do this, let me know. Since 3.x chains exceptions and prints the original traceback, no message argument is needed with self.fail to explain the failure. For 2.7, I believe one should be added. Note: to empirically test that a test fails properly, it must be run with code that does not work properly. This is a problem with writing tests after the fact for code that works properly. I checked all 62 idlelib/*.py files for a test to see what we have to work with: the answer is 'not much'. Less than half the files have a test. All but 2 that do bring up a window and require a human to key, click, and look according to a script that is not provided. (This is not to say that the existing code will not be helpful for some gui tests.) One of the 2 remaining text tests prints multiple pages (a config file) for a person to check. By coincidence, the only automated tests are the ones in CallTips.py, the first file I looked at, last summer. ---------- stage: test needed -> patch review Added file: http://bugs.python.org/file30264/idletests.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 02:49:09 2013 From: report at bugs.python.org (Christopher Bare) Date: Wed, 15 May 2013 00:49:09 +0000 Subject: [issue7965] Problem with urlparse in Windows XP after a drag and drop In-Reply-To: <1266589212.06.0.504228462246.issue7965@psf.upfronthosting.co.za> Message-ID: <1368578949.76.0.915214125212.issue7965@psf.upfronthosting.co.za> Christopher Bare added the comment: I see Senthil's point, but this tripped me up. ---------- nosy: +Christopher.Bare _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 04:00:34 2013 From: report at bugs.python.org (Romulo A. Ceccon) Date: Wed, 15 May 2013 02:00:34 +0000 Subject: [issue17978] Python crashes if Py_Initialize/Py_Finalize are called multiple times In-Reply-To: <1368565468.18.0.0802244129119.issue17978@psf.upfronthosting.co.za> Message-ID: <1368583234.25.0.385219083637.issue17978@psf.upfronthosting.co.za> Romulo A. Ceccon added the comment: I've made some further investigation on this issue. Here's the output and the stack trace using --with-pydebug (and the attached patch applied): run no. 0 [8766 refs] free_list[0]->ob_refcnt before XDECREF: 2 run no. 1 [8844 refs] free_list[0]->ob_refcnt before XDECREF: 1 Fatal Python error: PyThreadState_Get: no current thread Aborted (core dumped) Thread 1 (Thread 0x7ffff7fed700 (LWP 32572)): #0 0x00007ffff7131425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff7134b8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00000000004086f4 in Py_FatalError ( msg=0x5a0378 "PyThreadState_Get: no current thread") at Python/pythonrun.c:1631 #3 0x000000000054120c in PyThreadState_Get () at Python/pystate.c:330 #4 0x000000000049a13b in tupledealloc (op=0x84e3a0) at Objects/tupleobject.c:218 #5 0x000000000047adf1 in _Py_Dealloc (op=0x84e3a0) at Objects/object.c:2262 #6 0x000000000049bba9 in PyTuple_Fini () at Objects/tupleobject.c:933 #7 0x000000000040519b in Py_Finalize () at Python/pythonrun.c:466 #8 0x00000000004047b6 in main () A build of Python 2.7.3 using the same steps *does not* crash, although it shows the same curious behavior for free_list[0]->ob_refcnt: [8676 refs] free_list[0]->ob_refcnt before XDECREF: 2 run no. 1 [8754 refs] free_list[0]->ob_refcnt before XDECREF: 1 run no. 2 [8832 refs] free_list[0]->ob_refcnt before XDECREF: 1 I have no idea why it behaves like that, but it seems that the default configuration with Unicode enabled is covering some bug (because of the additional references held). Regarding the official way to disable Unicode, I cannot build Python using --enable-unicode=no on Ubuntu 13.04. In 2.7.4, 2.7.3, 2.7.2 and 2.6.8 ./configure aborts with: checking what type to use for unicode... configure: error: invalid value for --enable-unicode. Use either ucs2 or ucs4 (lowercase). I'm afraid I'm missing something really obvious. With 2.5.6 I'm able to get past the configure part but then it fails when building the modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 04:09:31 2013 From: report at bugs.python.org (Todd Rovito) Date: Wed, 15 May 2013 02:09:31 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1368583771.77.0.394581207306.issue15392@psf.upfronthosting.co.za> Todd Rovito added the comment: Terry I think you have a typo you mean PEP434 (http://www.python.org/dev/peps/pep-0434/) where PEP343 exists. Can you please confirm? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 04:10:20 2013 From: report at bugs.python.org (Berker Peksag) Date: Wed, 15 May 2013 02:10:20 +0000 Subject: [issue17974] Migrate unittest to argparse In-Reply-To: <1368534885.41.0.702465315617.issue17974@psf.upfronthosting.co.za> Message-ID: <1368583820.86.0.954286518176.issue17974@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 04:11:50 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 15 May 2013 02:11:50 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1368583910.32.0.267608168854.issue15392@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Yes, of course. Thanks for correcting. 434, 434, 434,... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 04:28:27 2013 From: report at bugs.python.org (Ethan Furman) Date: Wed, 15 May 2013 02:28:27 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368584907.94.0.365614056161.issue17947@psf.upfronthosting.co.za> Ethan Furman added the comment: Got the pickle issues worked out. Added super to the metaclass' __new__. Checking for illegal names of members and raising ValueError if any are found (I know, I know, safety checks! But such an enum is broken from the getgo so I see no reason to allow those names through). Thanks everyone for the excellent feed back. I really appreciate it. Hopefully we're almost done! :) ---------- assignee: -> ethan.furman Added file: http://bugs.python.org/file30265/pep-0435.06.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 05:05:30 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 15 May 2013 03:05:30 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1368587130.83.0.536853435031.issue15392@psf.upfronthosting.co.za> Ezio Melotti added the comment: A few comments about the patch: 1) I would prefer a more explicit idle_test instead of Itest (assuming "I" means idle); 2) having idle_test in Lib/test would be better if possible (see #10572); 3) the tests should only be in idle_test, and not in the "if __name__ == '__main__':" of the files; 4) I'm not sure the @template file is necessary. It could be documented somewhere else though (see e.g. http://docs.python.org/3/library/test.html#writing-unit-tests-for-the-test-package). IOW putting all tests in a separate dir is a good thing, and the dir could either be in Lib/test or in Lib/idlelib. All the tests should be inside this dir, except for Lib/test/test_idle.py that should be the entry point used to run all the tests in idle_test (see e.g. the tests for ctypes, email, and json). Individual tests in idle_test can be run on their own, and they should use the "if __name__ == '__main__': unittest.main()" idiom. > Question: "Unittest supports skipping individual test > methods and even whole classes of tests" How about skipping > (possibly conditionally) an entire file -- especially test_idle, > which has no classes, or and test_xxx with multiple classes? You can raise unittest.SkipTest or use support.import_module(). This works fine if you run the tests through regrtest, but be aware that unittest itself only sees this as a skip from 3.4 (see #16935). > * Exceptions raised outside of self.assertXyz (and self.fail) > calls are regarded as an error in the test code rather than a > failure of the code tested (26.3.4. Organizing test code). > So, there being no 'assertNotRaises' context manager, I added > "try:...except ...: self.fail()" to test_pathbrowser.py so a > failure will be reported as such and not as an error. If > there is a better way to do this, let me know. If it's supposed to work the try/except is not necessary IMHO. By this logic every line of code should be wrapped in a try/except :) > Since 3.x chains exceptions and prints the original traceback, > no message argument is needed with self.fail to explain the > failure. For 2.7, I believe one should be added. If you still want to keep the try/except, I would provide a meaningful failure message in any case. > Note: to empirically test that a test fails properly, it must > be run with code that does not work properly. This is a > problem with writing tests after the fact for code that works > properly. It's not difficult to break the code to test that test works though :) > I checked all 62 idlelib/*.py files for a test to see what we > have to work with: the answer is 'not much'. Less than half > the files have a test. If possible I think these should all be moved to idle_test. You can also add an additional resource to regrtest to skip the ones that require manual intervention. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 05:08:25 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 15 May 2013 03:08:25 +0000 Subject: [issue17955] Minor updates to Functional HOWTO In-Reply-To: <1368287962.52.0.951274382256.issue17955@psf.upfronthosting.co.za> Message-ID: <1368587305.64.0.879042689259.issue17955@psf.upfronthosting.co.za> Ezio Melotti added the comment: LGTM. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 05:32:49 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 15 May 2013 03:32:49 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <3b9Ltm5b8yzT1t@mail.python.org> Roundup Robot added the comment: New changeset 2b4b289c1abb by Benjamin Peterson in branch '3.3': when arguments are cells clear the locals slot (backport of #17927) http://hg.python.org/cpython/rev/2b4b289c1abb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 05:33:07 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 15 May 2013 03:33:07 +0000 Subject: [issue17927] Argument copied into cell still referenced by frame In-Reply-To: <1367942543.4.0.296722706025.issue17927@psf.upfronthosting.co.za> Message-ID: <1368588787.24.0.876556533412.issue17927@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 05:38:05 2013 From: report at bugs.python.org (Todd Rovito) Date: Wed, 15 May 2013 03:38:05 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1368589085.29.0.676109780866.issue15392@psf.upfronthosting.co.za> Todd Rovito added the comment: Terry, On my Mac with "hg revert -a" and "hg pull -u" the patch fails to apply on CallTips.py and PathBrowser.py under the latest version of Python 3.4. Here is the output when I try to apply the patch: rovitotv-pc:py34 rovitotv$ hg import --no-commit /Volumes/SecurePython3/source/15392idletests.diff applying /Volumes/SecurePython3/source/15392idletests.diff patching file Lib/idlelib/CallTips.py Hunk #1 FAILED at 263 1 out of 1 hunks FAILED -- saving rejects to file Lib/idlelib/CallTips.py.rej patching file Lib/idlelib/Itest/@template.txt patching file Lib/idlelib/Itest/__init__.py patching file Lib/idlelib/Itest/test_calltips.py patching file Lib/idlelib/Itest/test_pathbrowser.py patching file Lib/idlelib/PathBrowser.py Hunk #1 FAILED at 94 1 out of 1 hunks FAILED -- saving rejects to file Lib/idlelib/PathBrowser.py.rej patching file Lib/test/test_idle.py adding Lib/idlelib/Itest/@template.txt adding Lib/idlelib/Itest/__init__.py adding Lib/idlelib/Itest/test_calltips.py adding Lib/idlelib/Itest/test_pathbrowser.py adding Lib/test/test_idle.py abort: patch failed to apply I even tried using the tr command to remove the ^M characters from the .diff file and that still didn't allow me to apply the patch. Maybe it is my setup??? It is late here so I am going to bed but will play with it some more tomorrow. Thanks for your hard work, the patch looks like a good start. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 06:55:36 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 15 May 2013 04:55:36 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1368593736.96.0.233688491113.issue15392@psf.upfronthosting.co.za> Ezio Melotti added the comment: Have you tried applying it to 3.3? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 07:54:32 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 15 May 2013 05:54:32 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1368597272.94.0.79616774362.issue15392@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Todd, the last two commits, both rather trivial, I merged from 3.3 to 3.4 would not apply for no reason I could see. I wonder is there is something wrong with the repository. I wrote about the problem on the committer's list a few days ago, but got no response yet. It probably fell thru the cracks. I will try applying to 3.4 on windows tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 08:05:35 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 15 May 2013 06:05:35 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1368597935.44.0.898929707421.issue15392@psf.upfronthosting.co.za> Ezio Melotti added the comment: > I wonder is there is something wrong with the repository. The repo looks ok to me. You could try to run "hg verify" on your machine id you want to make sure your clone is ok. > I wrote about the problem on the committer's list a few days ago, > but got no response yet. It probably fell thru the cracks. I've seen the mail but it's hard to tell what the problem was after the fact. Next time it happens I suggest you to come on #python-dev and ask there before continuing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 09:11:01 2013 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 15 May 2013 07:11:01 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1368601861.51.0.967615798706.issue15392@psf.upfronthosting.co.za> Nick Coghlan added the comment: Just a quick note on the directory naming: idlelib/idle_test sounds like a good option to me. Putting it under idlelib makes it easy for distros to carve it out along with the rest of Idle, as well as making it clear that it falls under the purview of PEP 434 Expanding Itest -> idle_test is a combination of "Itest" being somewhat cryptic in the first place, and then the potential for 1/I/l/i glyph confusion (depending on font) making it worse. Other than that, +1 to what Ezio said (I wouldn't worry about moving any more existing tests for this patch though - starting to move self-tests out of the individual IDLE files to the new test suite can be a good next step) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 09:26:31 2013 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 15 May 2013 07:26:31 +0000 Subject: [issue17978] Python crashes if Py_Initialize/Py_Finalize are called multiple times In-Reply-To: <1368574109.48.0.780824591597.issue17978@psf.upfronthosting.co.za> Message-ID: <519338A2.9040402@egenix.com> Marc-Andre Lemburg added the comment: On 15.05.2013 01:28, Amaury Forgeot d'Arc wrote: > > Amaury Forgeot d'Arc added the comment: > > The official way to build without unicode is > ./configure --enable-unicode=no > But see issue17979. The official way to build without Unicode is: ./configure --disable-unicode See http://bugs.python.org/issue8767 for the most recent set of fixes that were supplied to make it work again in Python 2.7.4. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 09:34:28 2013 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 15 May 2013 07:34:28 +0000 Subject: [issue17979] Cannot build 2.7 with --enable-unicode=no In-Reply-To: <1368574020.99.0.834797445108.issue17979@psf.upfronthosting.co.za> Message-ID: <1368603268.32.0.160337067017.issue17979@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Please note that the official way to build Python without Unicode support is (see http://bugs.python.org/issue445762): ./configure --disable-unicode See http://bugs.python.org/issue8767 for the most recent set of fixes that were supplied to make it work again in Python 2.7.4. If the above doesn't work, it's a bug (as well) - and has been for quite a few releases. Technically, --disable-unicode is mapped to --enable-unicode=no by configure. I guess we'd need a buildbot to check whether --disable-unicode still works, i.e. produces a Python version that compiles and passes the basic tests. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 09:48:54 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 15 May 2013 07:48:54 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1368604134.02.0.434696358084.issue15392@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Ezio, thank you for the response. 1. I care more about where the directory of tests is than what it is called. 'idle_test' or 'idletest' or whatever would be fine. Lets make that the last bikeshed item ;-). 2. I looked as #10572. It was originally about moving unittest tests from unittest/xx to test/yy, and then broadened to other packages. Michael F. gave two reasons for the move. 2A. Easier to grep without recursing into the test directory. Barry already refuted this, pointing out that grep/find have options to not recurse. The Idle equivalent, Find in Files, has a little checkbox [] Recurse down subdirectories. I think Michael had this point backwards. The advantage of having tests with the code is to make grepping both at once possible. I am sure I will want to do this while developing the tests. So add this to my list of reasons to put the directory under idlelib. 2B. Would honor the Windows Install without Tests option. This is strictly a matter of saving space by disabling function. I agree that this is appropriate for nearly all packages, but I already explained why I want to evade that option: tkinter and idle are exceptional in that they are the only two packages that people regularly have problems running. So I think people should have those tests available, even if none of the others. 2 (again). Other people opined that package maintainers should have some say in the matter and that there might be exceptions. 3. Many modules have more or useless 'sanity-check' tests run with the 'if __name__' mechanism. I think *all* of these should be replaced with unittest.main(xxx, verbosity=2, exit=False) to run the full test module. If the code module test has anything valuable that is not in the test module, it should be moved there; the rest should be deleted. I plan to eventually do this with all such 'tests' in idlelib/*.py. However, this needs to be done one by one. Some current tests have program errors; my 'file' to 'open' patch last week was the first fix. Some put up a blank window, with no indication of what a person is expected to do to perform the test. Some put up a window that will not close by normal means. All except the two in idletasks.diff require human intervention, which is not acceptible for buildbots. Question: is there a way for a test to detect being run by a buildbot? 4. I already used @template.txt to alter CallTips.py and start test_calltips.py and I want to use it for all the other 60 (or whatever) test files. I will (re)read the test-writing section and possibly suggest a patch. But Idle-specific info and code does not belong there. (5.) unittest.SkipTest is what I was looking for. I do not believe that support.import_module() will allow skipping if, or unless, the test is running on a specific platform. I need to look at #16935. Is Idle CPython only? If so, that should be a condition of test/test_idle.py running. Ah, testing the imports of tkinter and idlelib already takes care of that. (6.) My concern and possible confusion about raising exceptions came from Jayakrishnan's patch + def test_DirBrowserTreeItem(self): + # Issue16226 - make sure that getting a sublist works + d = PathBrowser.DirBrowserTreeItem('') + d.GetSubList() in relation to the doc saying "Note that in order to test something, we use one of the assert*() methods provided by the TestCase base class." There is no such method. The doc follows with "If the test fails, an exception will be raised, and unittest will identify the test case as a failure. Any other exceptions will be treated as errors." The 'test above is to raise, or not, an 'other exception' and I took 'treated as errors' to mean that raising an 'other exception' is an error. It certainly makes test failure counted as an error rather than an error and indistinguishable from test code errors. I guess when the test is fleshed out, there should and will be some assert about the result of d.getsublist(). So I could delete the try-except. (7.) A human-intervention resource. I will leave that for later. My next step after this one is moving tests from CallTips.py to the new test_calltips.py (3. above). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 10:10:30 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 15 May 2013 08:10:30 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1368605430.04.0.303776876065.issue15392@psf.upfronthosting.co.za> Terry J. Reedy added the comment: For future reference, there is an idle specific issue that I do not think has been mentioned yet. Idle can run in one process, but the default mode now, and perhaps only mode sometime in the future, is two processes communicating through a socket. Testing two process communication requires two test processes, not just one. Tests will pass in one process without testing the full normal process. For instance: def fetch_tip(self, expression): try: rpcclt = self.editwin.flist.pyshell.interp.rpcclt except AttributeError: rpcclt = None if rpcclt: return rpcclt.remotecall("exec", "get_the_calltip", (expression,), {}) else: return get_argspec(get_entity(expression)) I believe this works because fetch_tip executed in the idle process makes a remote call that results in fetch_tip being executed in the remote process, where self has no editwin and hence control falls through to the last line. A normal, naive test of fetch_tip will 'work' because it will simply fall through to the last line, which in this case is mostly redundant with separate tests of get_entity and get_argspec. It seems to me that a full test suite must at some point test that the actual communication works, and that this cannot all be done with mocks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 10:16:06 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 15 May 2013 08:16:06 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1368605766.26.0.0510184495549.issue15392@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thanks Nick. Tomorrow I should change the directory name, delete try-except, commit, and move onward on the path laid out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 10:49:22 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 May 2013 08:49:22 +0000 Subject: [issue17979] Cannot build 2.7 with --enable-unicode=no In-Reply-To: <1368574020.99.0.834797445108.issue17979@psf.upfronthosting.co.za> Message-ID: <1368607762.56.0.813711818513.issue17979@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I can't reproduce this when build with --disable-unicode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 10:53:30 2013 From: report at bugs.python.org (Jaakko Moisio) Date: Wed, 15 May 2013 08:53:30 +0000 Subject: [issue17976] file.write doesn't raise IOError when it should In-Reply-To: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za> Message-ID: <1368608010.95.0.296396275443.issue17976@psf.upfronthosting.co.za> Changes by Jaakko Moisio : Added file: http://bugs.python.org/file30266/fileobject-fix4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 11:04:58 2013 From: report at bugs.python.org (Jaakko Moisio) Date: Wed, 15 May 2013 09:04:58 +0000 Subject: [issue17976] file.write doesn't raise IOError when it should In-Reply-To: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za> Message-ID: <1368608698.04.0.886585927492.issue17976@psf.upfronthosting.co.za> Jaakko Moisio added the comment: I tried to reply to the review of my last patch but this tracker software itself crashed. Is there anyone who would be interested in the traceback? Anyway, I'll reply here. On 2013/05/15 08:37:29, Charles-Fran?ois Natali wrote: > http://bugs.python.org/review/17976/diff/8158/Objects/fileobject.c > File Objects/fileobject.c (right): > > http://bugs.python.org/review/17976/diff/8158/Objects/fileobject.c#newcode1856 > Objects/fileobject.c:1856: if (n2 != n || errno != 0) { > Hum, we saw that ferror() could be used to detect the error, so it should be > used instead. > > Also, there's a problem with this patch: it's checking errno too late: for > example, it could have been cleared by FILE_END_ALLOW_THREADS or Py_XDECREF in > the meantime. Ok. However I must point out that if errno is cleared in the meantime, that also affects PyErr_SetFromErrno. I've submitted another patch where I'm extra careful with errno. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 11:23:33 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 15 May 2013 09:23:33 +0000 Subject: [issue17979] Cannot build 2.7 with --enable-unicode=no In-Reply-To: <1368574020.99.0.834797445108.issue17979@psf.upfronthosting.co.za> Message-ID: <1368609813.22.0.216607844386.issue17979@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 11:36:27 2013 From: report at bugs.python.org (Michael Foord) Date: Wed, 15 May 2013 09:36:27 +0000 Subject: [issue17974] Migrate unittest to argparse In-Reply-To: <1368534885.41.0.702465315617.issue17974@psf.upfronthosting.co.za> Message-ID: <1368610587.08.0.548257304266.issue17974@psf.upfronthosting.co.za> Michael Foord added the comment: Discovery from a module importing main doesn't make sense (although from a *script* importing main it does). So long as "python -m unittest -v" continues to launch discovery, and the "positional argument" form of discovery still works, then the new patch looks good. I'll try it out and confirm. In general I agree with Antoine, the best way to improve the implementation of unittest.main is to provide a new discovery script (with supporting code that is then much easier to extend). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 12:25:06 2013 From: report at bugs.python.org (Florian Weimer) Date: Wed, 15 May 2013 10:25:06 +0000 Subject: [issue17980] ssl.match_hostname() trips over crafted wildcard names Message-ID: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> New submission from Florian Weimer: If the name in the certificate contains many "*" characters, matching the compiled regular expression against the host name can take a very long time. Certificate validation happens before host name checking, so I think this is a minor issue only because it can only be triggered in cooperation with a CA (which seems unlikely). The fix is to limit the number of "*" wildcards to a reasonable maximum (perhaps even 1). ---------- components: Library (Lib) messages: 189280 nosy: fweimer priority: normal severity: normal status: open title: ssl.match_hostname() trips over crafted wildcard names versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 12:45:01 2013 From: report at bugs.python.org (Jaakko Moisio) Date: Wed, 15 May 2013 10:45:01 +0000 Subject: [issue17976] file.write doesn't raise IOError when it should In-Reply-To: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za> Message-ID: <1368614701.93.0.254607946863.issue17976@psf.upfronthosting.co.za> Jaakko Moisio added the comment: > I tried to reply to the review of my last patch but this tracker > software itself crashed. Is there anyone who would be interested in > the traceback? Never mind. I found the meta tracker and posted my traceback there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 15:48:05 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 15 May 2013 13:48:05 +0000 Subject: [issue17754] test_ctypes assumes LANG=C LC_ALL=C In-Reply-To: <1366110871.25.0.649633802528.issue17754@psf.upfronthosting.co.za> Message-ID: <3b9cXh4NKJz7Ljs@mail.python.org> Roundup Robot added the comment: New changeset 4f594f9b296a by doko in branch '2.7': - Issue #17754: Make ctypes.util.find_library() independent of the locale. http://hg.python.org/cpython/rev/4f594f9b296a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 15:49:55 2013 From: report at bugs.python.org (Julien Palard) Date: Wed, 15 May 2013 13:49:55 +0000 Subject: [issue17981] SysLogHandler closes connection before using it Message-ID: <1368625795.57.0.786028186823.issue17981@psf.upfronthosting.co.za> New submission from Julien Palard: I have a script that close its socket to /dev/log immediatly before using it, causing it to fail, here is the code : {{{ #!/usr/bin/env python # -*- coding: utf-8 -*- import logging import logging.handlers import daemon from daemon.pidlockfile import PIDLockFile logger = logging.getLogger('twitterCounter') logger.addHandler(logging.handlers.SysLogHandler(address='/dev/log')) logger.setLevel(logging.DEBUG) logger.info("Hello") with daemon.DaemonContext(): logger.info("World !") }}} and here is an strace : {{{ strace -s999 -f /tmp/test.py 2>&1 | grep -C2 ^connect // Outside daemonContext, all is OK // Note that inside daemonContext, all is OK if we do not log outside daemonContext. close(3) = 0 socket(PF_FILE, SOCK_DGRAM, 0) = 3 connect(3, {sa_family=AF_FILE, path="/dev/log"}, 10) = 0 sendto(3, "<14>Hello\0", 10, 0, NULL, 0) = 10 getuid() = 1001 -- // Second log, inside daemonContext, with the erroneous "socket(); close()" : socket(PF_FILE, SOCK_DGRAM, 0) = 3 close(3) = 0 connect(3, {sa_family=AF_FILE, path="/dev/log"}, 10) = -1 EBADF (Bad file descriptor) close(3) = -1 EBADF (Bad file descriptor) // As the previous try has failed, SysLogHandler seems to give another try with different parameters, failing too as expected socket type is DGRAM : socket(PF_FILE, SOCK_STREAM, 0) = 3 connect(3, {sa_family=AF_FILE, path="/dev/log"}, 10) = -1 EPROTOTYPE (Protocol wrong type for socket) }}} ---------- components: Library (Lib) messages: 189283 nosy: Julien.Palard priority: normal severity: normal status: open title: SysLogHandler closes connection before using it type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 16:16:54 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 15 May 2013 14:16:54 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1368627414.51.0.431639964608.issue15392@psf.upfronthosting.co.za> Ezio Melotti added the comment: Having idle_test under idlelib is fine with me if it makes your life easier. > 3. Many modules have more or useless 'sanity-check' tests run > with the 'if __name__' mechanism. I think *all* of these should > be replaced with unittest.main(xxx, verbosity=2, exit=False) > to run the full test module. If the code module test has > anything valuable that is not in the test module, > it should be moved there; the rest should be deleted. All the sanity checks (at least the reasonably sane) should be converted to unittest and moved from the modules to the respective test_* modules. The others should be removed, and I don't think we have to keep the "if __name__" in the modules (the test modules should have it though). Specifying the verbosity=2 in all the test modules might not be a good idea. If you are running all the tests at once, that level of verbosity will just get in the way (and I'm not sure you can change it easily). If you are running individual tests modules you should be able to change the verbosity from the command line. > Question: is there a way for a test to detect being run by a buildbot? You can handle this by adding a new resource to test.support. The tests will normally be skipped unless you explicitly run them using "./python -m test -uhumanneeded" or you run the test file directly (you can enable the resource in the "if __name__"). > 4. I already used @template.txt to alter CallTips.py and start > test_calltips.py and I want to use it for all the other 60 (or > whatever) test files. I will (re)read the test-writing section > and possibly suggest a patch. As I suggested earlier, I think the "main" function in Lib/idlelib/CallTips.py should be converted to unittest and moved to test_calltips. CallTips.py should not include any test-related code and no "if __name__" IMHO. > But Idle-specific info and code does not belong there. Agreed. Actually once the initial conversion is done I don't think documenting it so important, since it will be easier to look at all the others tests and see what they do than finding the documentation that explain how things should be done. > (5.) unittest.SkipTest is what I was looking for. I do not believe > that support.import_module() will allow skipping if, or unless, > the test is running on a specific platform. I need to look at #16935. Nope, but you can do "if sys.platform() == '...': raise unittest.SkipTest(...)". The TL;DR version of #16935 is that it will break test discovery on 3.3, but that's not a big problem. > (6.) My concern and possible confusion about raising > exceptions came from Jayakrishnan's patch Either if you get a failure or an error, it still means there's something wrong :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 17:12:24 2013 From: report at bugs.python.org (=?utf-8?b?0JPQtdC90L3QsNC00LjQuSDQldCz0L7RgNC+0LI=?=) Date: Wed, 15 May 2013 15:12:24 +0000 Subject: [issue15267] tempfile.TemporaryFile and httplib incompatibility In-Reply-To: <1341620675.47.0.0551988049302.issue15267@psf.upfronthosting.co.za> Message-ID: <1368630744.58.0.659972746412.issue15267@psf.upfronthosting.co.za> ???????? ?????? added the comment: i think it is not good, len(fd) must raise AttributeError, not TypeError ---------- nosy: +????????.?????? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 18:05:03 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 15 May 2013 16:05:03 +0000 Subject: [issue17754] test_ctypes assumes LANG=C LC_ALL=C In-Reply-To: <1366110871.25.0.649633802528.issue17754@psf.upfronthosting.co.za> Message-ID: <3b9gZk44BCz7LlW@mail.python.org> Roundup Robot added the comment: New changeset d6a43a99aea3 by doko in branch '3.3': - Issue #17754: Make ctypes.util.find_library() independent of the locale. http://hg.python.org/cpython/rev/d6a43a99aea3 New changeset 9a44f12df844 by doko in branch 'default': - Issue #17754: Make ctypes.util.find_library() independent of the locale. http://hg.python.org/cpython/rev/9a44f12df844 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 18:09:17 2013 From: report at bugs.python.org (Matthias Klose) Date: Wed, 15 May 2013 16:09:17 +0000 Subject: [issue17754] test_ctypes assumes LANG=C LC_ALL=C In-Reply-To: <1366110871.25.0.649633802528.issue17754@psf.upfronthosting.co.za> Message-ID: <1368634157.36.0.82645802233.issue17754@psf.upfronthosting.co.za> Matthias Klose added the comment: fixed in 2.7, 3.3 and trunk ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 18:20:36 2013 From: report at bugs.python.org (Hugh Littlejohn) Date: Wed, 15 May 2013 16:20:36 +0000 Subject: [issue17982] Syntax Error in IDLE3 not in IDLE Message-ID: <1368634836.7.0.999902243519.issue17982@psf.upfronthosting.co.za> New submission from Hugh Littlejohn: New to Python, acquired Raspberry PI. Upgraded and now have IDLE and IDLE3. Python 3.2.3 (default, Mar 1 2013, 11:53:50) (GNU 4.6.3] on Linux2 First task, New Window to create "Hello, World!" Using IDLE3, created file helloworld.py Using Run/ Check Module - failed with syntax error on the closing double-quote Tried space before ending double-quote - failed Tried reducing string to "Hello" - failed Removed training end-of-line - failed Closed IDLE3 and started IDLE Loaded file as before - worked as expected Restarted IDLE3 - still failed Tried command-line "python helloworld.py" - worked as expected Any ideas ? ---------- components: IDLE files: helloworld.py messages: 189288 nosy: Littlejohn priority: normal severity: normal status: open title: Syntax Error in IDLE3 not in IDLE type: crash versions: Python 3.2 Added file: http://bugs.python.org/file30267/helloworld.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 18:36:46 2013 From: report at bugs.python.org (Ned Batchelder) Date: Wed, 15 May 2013 16:36:46 +0000 Subject: [issue17982] Syntax Error in IDLE3 not in IDLE In-Reply-To: <1368634836.7.0.999902243519.issue17982@psf.upfronthosting.co.za> Message-ID: <1368635806.2.0.973070546811.issue17982@psf.upfronthosting.co.za> Ned Batchelder added the comment: Python 3 has no print statement, it has a print function, so you need: print("Hello, world!") ---------- nosy: +nedbat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 20:06:57 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 15 May 2013 18:06:57 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1368641217.02.0.828186620622.issue15392@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Tests have at least two very different purposes. One is test-driven development of code (and tests) by developers. The other is regression detection by buildbots. "if __name__" in code modules, in addition to test modules, makes the first much easier. First, the unittest.main call in the test module must be appropriate for the buildbots. Since buildbots do not execute the corresponding call in the code module, it can and and should tuned for development, which I have done. The 'if' block is also a place for any other code specific to developer tests, such as enabling a 'humanneeded' resource. Second, when editing with Idle, F5 in an editor window runs the test in the Idle shell, where right-click, click on a traceback line takes one back to the corresponding file and line. At least on Windows, using the console and console interpreter is painful by comparison. All this is true when editing any Python file, not just Idle files, so I would be disappointed if someone went through the stdlib deleting, rather than revising the 'if __name__' blocks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 20:22:58 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 15 May 2013 18:22:58 +0000 Subject: [issue17980] ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368642178.85.0.714186315529.issue17980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Does the RFC say anything about this? How much wildcards are necessary to take up a significant amount of CPU time? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 20:43:16 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 15 May 2013 18:43:16 +0000 Subject: [issue16748] Make CPython test package discoverable In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za> Message-ID: <1368643396.21.0.814863283006.issue16748@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Chris: >>> import unittest as u; u.main("test.test_xxx") Ezio: I think that's the last nail in the coffin of test_main. Terry, do you agree? Belated answer: now that I use and understand the idiom, yes. Chris: The load_tests protocol (2.7, 3.2+) seems like the right approach for [tests in directories outside of /test]. I am using that in the new idlelib/idle_test/__init__.py. But perhaps the load_tests() example in the doc, which I copied, should be changed from 'do nothing' to 'discover all tests in the directory' as a more useful default. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 21:00:10 2013 From: report at bugs.python.org (Dwight Guth) Date: Wed, 15 May 2013 19:00:10 +0000 Subject: [issue17983] global __class__ statement in class declaration Message-ID: <1368644410.25.0.871302075026.issue17983@psf.upfronthosting.co.za> New submission from Dwight Guth: The following python program causes cpython to crash: class A: global __class__ def a(self): super() I get the following output on the console: bug.py:2: SyntaxWarning: name '__class__' is assigned to before global declaration global __class__ lookup '__class__' in ? a sequ 2 -1 freevars of A: ('__class__',) Fatal Python error: compiler_make_closure() Current thread 0x00007fc712192700: Aborted (core dumped) This probably happens because __class__ is handled specially by the scoping rules and isn't expected to be anything other than a member of co_cellvars. It should probably throw an exception instead (SystemError?) ---------- messages: 189293 nosy: dwight.guth priority: normal severity: normal status: open title: global __class__ statement in class declaration type: crash versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 21:02:54 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 15 May 2013 19:02:54 +0000 Subject: [issue17983] global __class__ statement in class declaration In-Reply-To: <1368644410.25.0.871302075026.issue17983@psf.upfronthosting.co.za> Message-ID: <1368644574.96.0.933611588297.issue17983@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- assignee: -> benjamin.peterson nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From mal at egenix.com Wed May 15 09:26:26 2013 From: mal at egenix.com (M.-A. Lemburg) Date: Wed, 15 May 2013 09:26:26 +0200 Subject: [issue17978] Python crashes if Py_Initialize/Py_Finalize are called multiple times In-Reply-To: <1368574109.48.0.780824591597.issue17978@psf.upfronthosting.co.za> References: <1368574109.48.0.780824591597.issue17978@psf.upfronthosting.co.za> Message-ID: <519338A2.9040402@egenix.com> On 15.05.2013 01:28, Amaury Forgeot d'Arc wrote: > > Amaury Forgeot d'Arc added the comment: > > The official way to build without unicode is > ./configure --enable-unicode=no > But see issue17979. The official way to build without Unicode is: ./configure --disable-unicode See http://bugs.python.org/issue8767 for the most recent set of fixes that were supplied to make it work again in Python 2.7.4. -- Marc-Andre Lemburg eGenix.com From report at bugs.python.org Wed May 15 21:30:23 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 15 May 2013 19:30:23 +0000 Subject: [issue13146] Writing a pyc file is not atomic In-Reply-To: <1318275475.02.0.82335017062.issue13146@psf.upfronthosting.co.za> Message-ID: <1368646223.77.0.154578766907.issue13146@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 21:32:47 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 May 2013 19:32:47 +0000 Subject: [issue17974] Migrate unittest to argparse In-Reply-To: <1368534885.41.0.702465315617.issue17974@psf.upfronthosting.co.za> Message-ID: <1368646367.0.0.847084566042.issue17974@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is other variant of patch, even less horrible. However it introduces some incompatibility: 1. Discovery mode now works only when module==None (i.e. from "-m unittest"). It is only case for which it was documented. 2. Previously unittest.main(failfast=False, argv=['prog', '-f']) caused an error, while unittest.main(failfast=True, argv=['prog', '-f']) and unittest.main(failfast=[], argv=['prog', '-f']) just had no any effect. Now all non-None casse cause an error. The same for catchbreak and buffer. ---------- Added file: http://bugs.python.org/file30268/unittest_argparse_less_horrible_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 21:39:47 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 15 May 2013 19:39:47 +0000 Subject: [issue8604] Adding an atomic FS write API In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za> Message-ID: <1368646787.54.0.284202429592.issue8604@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 21:49:27 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 15 May 2013 19:49:27 +0000 Subject: [issue17984] io and _pyio modules require the _io module Message-ID: <1368647367.8.0.180383025422.issue17984@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: io and _pyio modules don't usable without the _io module. In particular when 2.7 build without unicode. Why we have a Python implementation if it can't be used as a fallback when a C implementation is not available? ---------- components: IO messages: 189295 nosy: benjamin.peterson, hynek, pitrou, serhiy.storchaka, stutzbach priority: normal severity: normal status: open title: io and _pyio modules require the _io module type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 21:50:44 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 15 May 2013 19:50:44 +0000 Subject: [issue17984] io and _pyio modules require the _io module In-Reply-To: <1368647367.8.0.180383025422.issue17984@psf.upfronthosting.co.za> Message-ID: <1368647444.76.0.584853194179.issue17984@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Well, we at least need some C level _fileio. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 22:15:29 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 15 May 2013 20:15:29 +0000 Subject: [issue17984] io and _pyio modules require the _io module In-Reply-To: <1368647367.8.0.180383025422.issue17984@psf.upfronthosting.co.za> Message-ID: <1368648929.83.0.42621552633.issue17984@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Patches welcome, of course! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 22:09:39 2013 From: report at bugs.python.org (Alex Gaynor) Date: Wed, 15 May 2013 20:09:39 +0000 Subject: [issue17984] io and _pyio modules require the _io module In-Reply-To: <1368647367.8.0.180383025422.issue17984@psf.upfronthosting.co.za> Message-ID: <1368648579.22.0.818049815934.issue17984@psf.upfronthosting.co.za> Alex Gaynor added the comment: I don't see why we need some C level _fileio, the os module has everythign we need. ---------- nosy: +alex _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 22:27:39 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 15 May 2013 20:27:39 +0000 Subject: [issue12370] Use of super overwrites use of __class__ in class namespace In-Reply-To: <1308522510.81.0.637011547356.issue12370@psf.upfronthosting.co.za> Message-ID: <3b9nPk2CsDz7LlF@mail.python.org> Roundup Robot added the comment: New changeset 3d858f1eef54 by Benjamin Peterson in branch 'default': hide the __class__ closure from the class body (#12370) http://hg.python.org/cpython/rev/3d858f1eef54 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 22:28:08 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 15 May 2013 20:28:08 +0000 Subject: [issue12370] Use of super overwrites use of __class__ in class namespace In-Reply-To: <1308522510.81.0.637011547356.issue12370@psf.upfronthosting.co.za> Message-ID: <1368649688.37.0.0699898591896.issue12370@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Finally killed this one properly. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 22:32:31 2013 From: report at bugs.python.org (Eric Promislow) Date: Wed, 15 May 2013 20:32:31 +0000 Subject: [issue17971] Weird interaction between Komodo Python debugger C module & Python 3 In-Reply-To: <1368482053.55.0.661749882724.issue17971@psf.upfronthosting.co.za> Message-ID: <1368649951.77.0.961146083925.issue17971@psf.upfronthosting.co.za> Eric Promislow added the comment: I found a workaround in our debugger code, so you can lower the priority on this, or even mark it "Wontfix", although I still think the frame stack is getting messed up. One thing about our debugger, it essentially runs all the Python code in a big exec statement, and this particular code contains its own exec stmt. The stack looks wrong after we finish the inner exec statement. So if you're looking for a repro, that might be the way to go. However I can break at line 10 in the following code with no problem using pdb (Py 3): 1 #!/usr/bin/env python3 2 3 def inner_f(a, b): 4 ns2 = {"c": 7, "a":a, "b":b, "tot":None } 5 exec("tot = a + b + 1 + 100 * c", ns2) 6 return ns2['tot'] 7 8 ns1 = {"c": 5, "inner_f": inner_f, "res":None } 9 exec("res = inner_f(3, 4) + 10 * c", ns1) 10 print("After all that, res: %d" % (ns1['res'],)) 11 print("Stop here") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 22:41:12 2013 From: report at bugs.python.org (Andre Dias) Date: Wed, 15 May 2013 20:41:12 +0000 Subject: [issue17985] multiprocessing Queue.qsize() and Queue.empty() with different results Message-ID: <1368650472.41.0.00471316865127.issue17985@psf.upfronthosting.co.za> New submission from Andre Dias: The problem is that Queue.empty() is True even if Queue.qsize()>0! #!/usr/bin/python from multiprocessing import Queue numbers=Queue() for i in range (0,10): numbers.put(i) if numbers.qsize()>0 and numbers.empty(): print "BUG?!" ---------- components: Extension Modules messages: 189302 nosy: aod priority: normal severity: normal status: open title: multiprocessing Queue.qsize() and Queue.empty() with different results versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 22:55:29 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 15 May 2013 20:55:29 +0000 Subject: [issue17982] Syntax Error in IDLE3 not in IDLE In-Reply-To: <1368634836.7.0.999902243519.issue17982@psf.upfronthosting.co.za> Message-ID: <1368651329.81.0.236002957213.issue17982@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Please ask questions like this on python-list, mirrored as newsgroup gmane.comp.python.general or on other forums. This tracker is for patching Python itself, not usage questions. ---------- nosy: +terry.reedy resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 23:04:14 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 15 May 2013 21:04:14 +0000 Subject: [issue17981] SysLogHandler closes connection before using it In-Reply-To: <1368625795.57.0.786028186823.issue17981@psf.upfronthosting.co.za> Message-ID: <1368651854.1.0.858141070385.issue17981@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 23:09:59 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 15 May 2013 21:09:59 +0000 Subject: [issue17986] Alternative async subprocesses (pep 3145) Message-ID: <1368652199.21.0.577907802925.issue17986@psf.upfronthosting.co.za> New submission from Richard Oudkerk: In the attached file is an experimental implementation of an AsyncPopen class. It should work for Python 3.3, 3.4 on Unix and Windows. Unlike http://code.google.com/p/subprocdev (see #1191964) this does not depend on using time.sleep() and polling. It also uses the stdlib's _winapi instead of ctypes. It lets one do Unix-style multiplexing of stdin, stdout, stderr on Windows (by using overlapped IO). Differences from normal Popen: * File objects created for stdin/stdout/stderr using "...=PIPE" are non-blocking. * There are no options for buffering or for universal line endings (or unicode). * There is an extra method select(file_list, timeout=None) -> ready_file_list which can be used to wait for stdin, stdout, stderr to be ready. file_list should be a sublist of [self.stdin, self.stdout, self.stderr] with no None elements. Note that there is no separation between "readers" and "writers" the way there is for the normal select() function. On Unix this is implemented using select() or poll(). * On Windows close() can fail with BlockingIOError. To prevent this one must use select() to wait for self.stdin to be ready. As an example, communicate() can be reimplemented using select() as follows: def communicate(p, input): buf = memoryview(input) collected = collections.defaultdict(list) registered = [f for f in (p.stdin, p.stdout, p.stderr) if f is not None] while registered: for f in p.select(registered): if f is p.stdin: if not buf: f.close() registered.remove(f) else: n = f.write(buf) if n is not None: buf = buf[n:] elif f in (p.stdout, p.stderr): s = f.read(8192) if s == b'': f.close() registered.remove(f) elif s is not None: collected[f].append(s) else: raise RuntimeError('should not get here') return (b''.join(collected[p.stdout]) if p.stdout else None, b''.join(collected[p.stderr]) if p.stderr else None) ---------- files: asyncsubprocess.py messages: 189304 nosy: sbt priority: normal severity: normal status: open title: Alternative async subprocesses (pep 3145) versions: Python 3.4 Added file: http://bugs.python.org/file30269/asyncsubprocess.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 23:19:00 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 15 May 2013 21:19:00 +0000 Subject: [issue17985] multiprocessing Queue.qsize() and Queue.empty() with different results In-Reply-To: <1368650472.41.0.00471316865127.issue17985@psf.upfronthosting.co.za> Message-ID: <1368652740.56.0.406673401326.issue17985@psf.upfronthosting.co.za> Richard Oudkerk added the comment: >From the docs: qsize() Return the approximate size of the queue. Because of multithreading/multiprocessing semantics, this number is not reliable. Adding a short sleep before calling qsize() and empty() should make things appear to work. But really, there are no good reasons for using qsize() except for debugging. The same applies to queue.Queue. ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 23:19:04 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 15 May 2013 21:19:04 +0000 Subject: [issue17983] global __class__ statement in class declaration In-Reply-To: <1368644410.25.0.871302075026.issue17983@psf.upfronthosting.co.za> Message-ID: <3b9pY35vDCz7Lmf@mail.python.org> Roundup Robot added the comment: New changeset cd9141a4f999 by Benjamin Peterson in branch '3.3': complain about "global __class__" in a class body (closes #17983) http://hg.python.org/cpython/rev/cd9141a4f999 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 23:19:41 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 15 May 2013 21:19:41 +0000 Subject: [issue17971] Weird interaction between Komodo Python debugger C module & Python 3 In-Reply-To: <1368482053.55.0.661749882724.issue17971@psf.upfronthosting.co.za> Message-ID: <1368652781.72.0.686657987073.issue17971@psf.upfronthosting.co.za> Benjamin Peterson added the comment: If you ever find a Python bug, feel free to reopen. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 23:23:42 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 15 May 2013 21:23:42 +0000 Subject: [issue17972] inspect module docs omits many functions In-Reply-To: <1368501068.91.0.677640111487.issue17972@psf.upfronthosting.co.za> Message-ID: <1368653022.43.0.98174614549.issue17972@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I do not know what you mean by 'leak docs' so I changed the title to something that makes more sense. It is possible that these functions are considered private to the module, but then their names should be preceded by '_', or else there should be an '__all__' list that omits them. So the omission may be a mistake. I do not know. ---------- nosy: +terry.reedy stage: -> needs patch title: inspect module leak docs -> inspect module docs omits many functions _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 23:25:36 2013 From: report at bugs.python.org (Andre Dias) Date: Wed, 15 May 2013 21:25:36 +0000 Subject: [issue17985] multiprocessing Queue.qsize() and Queue.empty() with different results In-Reply-To: <1368652740.56.0.406673401326.issue17985@psf.upfronthosting.co.za> Message-ID: Andre Dias added the comment: But qsize() is working. what is not working is empty() 2013/5/15 Richard Oudkerk > > Richard Oudkerk added the comment: > > >From the docs: > > qsize() > Return the approximate size of the queue. Because of > multithreading/multiprocessing semantics, this number > is not reliable. > > Adding a short sleep before calling qsize() and empty() should make things > appear to work. > > But really, there are no good reasons for using qsize() except for > debugging. The same applies to queue.Queue. > > ---------- > nosy: +sbt > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 23:28:10 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 15 May 2013 21:28:10 +0000 Subject: [issue17967] urllib2.open failed to access a url when a perent directory of the url is permission denied In-Reply-To: <1368424209.99.0.52540499369.issue17967@psf.upfronthosting.co.za> Message-ID: <1368653290.41.0.679607168637.issue17967@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Did you run the urllib test module after your code change? Have you tried 3.3? ---------- nosy: +orsenthil, terry.reedy stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 23:29:40 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 15 May 2013 21:29:40 +0000 Subject: [issue17965] argparse does not dest.replace('-', '_') for positionals In-Reply-To: <1368411809.58.0.522670485437.issue17965@psf.upfronthosting.co.za> Message-ID: <1368653380.83.0.572340207948.issue17965@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +bethard _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 23:30:23 2013 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Wed, 15 May 2013 21:30:23 +0000 Subject: [issue17987] test.support.captured_stderr, captured_stdin not documented Message-ID: <1368653423.88.0.898801742943.issue17987@psf.upfronthosting.co.za> New submission from Fred L. Drake, Jr.: The captured_stderr and captured_stdin context managers aren't documented, and should be. ---------- assignee: docs at python components: Documentation keywords: easy messages: 189311 nosy: docs at python, fdrake priority: normal severity: normal stage: needs patch status: open title: test.support.captured_stderr, captured_stdin not documented type: enhancement versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 23:41:02 2013 From: report at bugs.python.org (Josh Purvis) Date: Wed, 15 May 2013 21:41:02 +0000 Subject: [issue17981] SysLogHandler closes connection before using it In-Reply-To: <1368625795.57.0.786028186823.issue17981@psf.upfronthosting.co.za> Message-ID: <1368654062.29.0.0964532162995.issue17981@psf.upfronthosting.co.za> Changes by Josh Purvis : ---------- nosy: +Josh.Purvis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 15 23:51:59 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 15 May 2013 21:51:59 +0000 Subject: [issue17953] sys.modules cannot be reassigned In-Reply-To: <1368260613.85.0.746522318662.issue17953@psf.upfronthosting.co.za> Message-ID: <1368654719.69.0.323445276702.issue17953@psf.upfronthosting.co.za> Terry J. Reedy added the comment: "sys.modules This is a dictionary that maps module names to modules which have already been loaded. This can be manipulated to force reloading of modules and other tricks." How about adding at the end "However, replacing or clearing it may cause Python to fail." or to be slightly more explicit "However, replacing it or deleting critical entries may cause Python to fail." ---------- nosy: +terry.reedy stage: test needed -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 00:01:43 2013 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 15 May 2013 22:01:43 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1368641217.02.0.828186620622.issue15392@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Terry, the unittest and regrtest command lines are *built* for TDD - you rely on test discovery and selection to run the appropriate tests for what you're working on. However, the point about F5 in IDLE is well made, and a reasonable rationale for ensuring at least the IDLE implementation files support running their tests that way. While it doesn't need to be extensive, it would be good to capture some of these points in a Idle/idle_tests/README file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 00:05:40 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 15 May 2013 22:05:40 +0000 Subject: [issue17979] Cannot build 2.7 with --enable-unicode=no In-Reply-To: <1368574020.99.0.834797445108.issue17979@psf.upfronthosting.co.za> Message-ID: <1368655540.0.0.408385645102.issue17979@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Can't build here with after "./configure --disable-unicode". Serhiy, which OS did you try? I'm running Debian 64bit, with gcc 4.6.3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 00:24:06 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 15 May 2013 22:24:06 +0000 Subject: [issue17985] multiprocessing Queue.qsize() and Queue.empty() with different results In-Reply-To: Message-ID: <51940AFF.5080808@gmail.com> Richard Oudkerk added the comment: On 15/05/2013 10:25pm, Andre Dias wrote: > But qsize() is working. what is not working is empty() empty() returns False when there is data in the underlying pipe. But the data does not enter the pipe until a background thread has written it to the pipe. This should not cause any problems. Using Queue.empty() is always subject to races. It is just that the multiprocessing version has an additional type of race compared to the normal one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 00:27:05 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 15 May 2013 22:27:05 +0000 Subject: [issue17962] Broken OpenSSL version in Windows builds In-Reply-To: <1368357845.04.0.941311125595.issue17962@psf.upfronthosting.co.za> Message-ID: <1368656825.88.0.475879418207.issue17962@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I have now updated the code. Yogesh: It is somewhat more that just committing the source; the assembler files need to be generated. The objective is to not require Perl on the build machines. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 00:30:57 2013 From: report at bugs.python.org (Brett Cannon) Date: Wed, 15 May 2013 22:30:57 +0000 Subject: [issue17953] sys.modules cannot be reassigned In-Reply-To: <1368260613.85.0.746522318662.issue17953@psf.upfronthosting.co.za> Message-ID: <1368657057.66.0.503869314431.issue17953@psf.upfronthosting.co.za> Brett Cannon added the comment: Sounds good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 00:33:12 2013 From: report at bugs.python.org (Andre Dias) Date: Wed, 15 May 2013 22:33:12 +0000 Subject: [issue17985] multiprocessing Queue.qsize() and Queue.empty() with different results In-Reply-To: <51940AFF.5080808@gmail.com> Message-ID: Andre Dias added the comment: RIchard, But the example program has no races, no threads, nothing. empty() is returning TRUE even though qsize() is >0 (which actually is) And it happens almost every time I run that small example. I had read the module doc, and I know its an unreliable method, but man, the example program is too simple to fail Truth is I decided qsize() is more reliable and im using it in my programs, but man empty() problem is so ridiculous that I decided to submit here 2013/5/15 Richard Oudkerk > > Richard Oudkerk added the comment: > > On 15/05/2013 10:25pm, Andre Dias wrote: > > But qsize() is working. what is not working is empty() > > empty() returns False when there is data in the underlying pipe. But > the data does not enter the pipe until a background thread has written > it to the pipe. This should not cause any problems. > > Using Queue.empty() is always subject to races. It is just that the > multiprocessing version has an additional type of race compared to the > normal one. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 00:39:05 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 15 May 2013 22:39:05 +0000 Subject: [issue17986] Alternative async subprocesses (pep 3145) In-Reply-To: <1368652199.21.0.577907802925.issue17986@psf.upfronthosting.co.za> Message-ID: <1368657545.14.0.845192235864.issue17986@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 00:39:43 2013 From: report at bugs.python.org (Jakub Wilk) Date: Wed, 15 May 2013 22:39:43 +0000 Subject: [issue17988] ElementTree.Element != ElementTree._ElementInterface Message-ID: <1368657583.19.0.922119818205.issue17988@psf.upfronthosting.co.za> New submission from Jakub Wilk: The xml.etree.ElementTree module provides _Element and _ElementInterface as compatibility aliases for Element. However, in Python 3.3 if the _elementtree module is importable, these classes are not identical: Element is a C implementation, and _Element/_ElementInterface is a Python implementation. $ python3.2 test-elementinterface.py 141477524 141477524 141477524 $ python3.3 test-elementinterface.py 137248544 4144597188 4144597188 ---------- components: Library (Lib) files: test-elementinterface.py messages: 189319 nosy: jwilk priority: normal severity: normal status: open title: ElementTree.Element != ElementTree._ElementInterface versions: Python 3.3 Added file: http://bugs.python.org/file30270/test-elementinterface.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 00:41:27 2013 From: report at bugs.python.org (Jakub Wilk) Date: Wed, 15 May 2013 22:41:27 +0000 Subject: [issue17988] ElementTree.Element != ElementTree._ElementInterface In-Reply-To: <1368657583.19.0.922119818205.issue17988@psf.upfronthosting.co.za> Message-ID: <1368657687.34.0.0749014582939.issue17988@psf.upfronthosting.co.za> Jakub Wilk added the comment: The attached (untested) patch should fix the bug. ---------- keywords: +patch Added file: http://bugs.python.org/file30271/elementinterface.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 00:45:05 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 15 May 2013 22:45:05 +0000 Subject: [issue17988] ElementTree.Element != ElementTree._ElementInterface In-Reply-To: <1368657583.19.0.922119818205.issue17988@psf.upfronthosting.co.za> Message-ID: <1368657905.67.0.720460689717.issue17988@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +eli.bendersky stage: -> patch review type: -> behavior versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 00:46:51 2013 From: report at bugs.python.org (Jakub Wilk) Date: Wed, 15 May 2013 22:46:51 +0000 Subject: [issue17989] ElementTree.Element broken attribute setting Message-ID: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za> New submission from Jakub Wilk: Setting attributes on ElementTree.Element objects is broken: it succeeds without exception, but then the following statement fails with AttributeError (unless that statement sets an Element's attribute too): $ python3.3 test-element-setattr.py Hello world!Traceback (most recent call last): File "test-element-setattr.py", line 6, in print('Hello world!') AttributeError: ham2 ---------- components: Library (Lib) files: test-element-setattr.py messages: 189321 nosy: jwilk priority: normal severity: normal status: open title: ElementTree.Element broken attribute setting versions: Python 3.3 Added file: http://bugs.python.org/file30272/test-element-setattr.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 00:46:52 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 15 May 2013 22:46:52 +0000 Subject: [issue17985] multiprocessing Queue.qsize() and Queue.empty() with different results In-Reply-To: Message-ID: <51941054.2040904@gmail.com> Richard Oudkerk added the comment: On 15/05/2013 11:33pm, Andre Dias wrote: > But the example program has no races, no threads, nothing. > empty() is returning TRUE even though qsize() is >0 (which actually is) > And it happens almost every time I run that small example. > I had read the module doc, and I know its an unreliable method, but man, > the example program is too simple to fail > Truth is I decided qsize() is more reliable and im using it in my programs, > but man empty() problem is so ridiculous that I decided to submit here If you assume everything is single-threaded then you would assume that this is too simple to fail. But there *is* more than thread involved. empty() and qsize() are basically redundant. You would almost certainly be better off using get_noblock()/put_noblock() and catching Empty/Full. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 01:13:49 2013 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 15 May 2013 23:13:49 +0000 Subject: [issue17981] SysLogHandler closes connection before using it In-Reply-To: <1368625795.57.0.786028186823.issue17981@psf.upfronthosting.co.za> Message-ID: <1368659629.55.0.425339923435.issue17981@psf.upfronthosting.co.za> Vinay Sajip added the comment: Isn't this a case of handles being closed in the child after a fork, by the daemon module? Have you investigated the files_preserve option in DaemonContext? ---------- resolution: -> invalid status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 01:24:57 2013 From: report at bugs.python.org (Christian Heimes) Date: Wed, 15 May 2013 23:24:57 +0000 Subject: [issue13146] Writing a pyc file is not atomic In-Reply-To: <1318275475.02.0.82335017062.issue13146@psf.upfronthosting.co.za> Message-ID: <1368660297.26.0.916349382033.issue13146@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 01:31:38 2013 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 May 2013 23:31:38 +0000 Subject: [issue8604] Adding an atomic FS write API In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za> Message-ID: <1368660698.32.0.721196970698.issue8604@psf.upfronthosting.co.za> STINNER Victor added the comment: Here is a patch based on the new os.replace() function. I only tested the patch on Linux. My patch must be tested on Windows, I don't know what happens when the file object is closed when the NamedTemporaryFile.delete attribute is set to False. Does close() raise an exception? I hesitate between prefix and dir parameters for NamedTemporaryFile. If prefix is equal to filename, is it possible for NamedTemporaryFile to create a file called filename? Or does it always add a suffix? If the program crashs before rename, I prefer to leave "file.XXX" temporary files (ex: "file.tmp", "file.tmp.2", ...) instead of random names like "tmpXXX". It is important to create the temporary file in the same directory to not create a file on a different file system. os.replace() fails on POSIX if the source and the destination are on two different file systems. If importing tempfile in shutil is a problem, it may be done in atomic_write() (maybe using a global variable to ensure that the module is only imported once). -- First, I tried to handle the temporary file manually (without the tempfile module) with a constant suffix. I only created a temporary file if the creation of the file (in exclusive mode, using "x" mode") failed. But Antoine pointed me on IRC that the function is not atomic because the file may be invalid before the file content is completly written and flushed. If two threads try to create the same file, the second thread gets a FileExistsError. In this case, the caller has to handle FileExistsError. The caller may remove the temporary file of the first thread, which may make the situation even worse. I prefer to use tempfile.NamedTemporaryFile because it is portable and well tested. It also uses a random suffix. On Windows, the O_TEMPORARY flag is passed to os.open(), so the file is removed by the OS when the file is closed, or when the program does crash. ---------- keywords: +patch Added file: http://bugs.python.org/file30273/atomic_write.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 01:35:11 2013 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 May 2013 23:35:11 +0000 Subject: [issue8604] Adding an atomic FS write API In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za> Message-ID: <1368660911.98.0.41820968276.issue8604@psf.upfronthosting.co.za> STINNER Victor added the comment: + # Flush Python buffers to system buffers + fileobj.flush() + + if hasattr(os, 'fsync'): + # Flush system buffers to disk + fd = fileobj.fileno() + os.fsync(fd) A fsync=True paramater may be added if calling os.fsync() is an issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 01:37:26 2013 From: report at bugs.python.org (Josh Purvis) Date: Wed, 15 May 2013 23:37:26 +0000 Subject: [issue17981] SysLogHandler closes connection before using it In-Reply-To: <1368625795.57.0.786028186823.issue17981@psf.upfronthosting.co.za> Message-ID: <1368661046.28.0.0153156142734.issue17981@psf.upfronthosting.co.za> Josh Purvis added the comment: Ironically, I ran into this same exact issue today, and I have investigated the `files_preserve` param, with no luck. I'm not too familiar with the internals here, but from what I can tell it works with FileHandler, but not the SysLogHandler. If you try to add the syslog handler to the files_preserve list it has no effect. It seems to need a stream, and SysLogHandler doesn't have the stream attribute. # This works for FileHandler's log = logging.getLogger('MyLog') fh = logging.FileHandler('/some/file') with daemon.DaemonContext(files_preserve=[fh.stream, ]): log.warn("In the belly of the beast.") ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 01:37:43 2013 From: report at bugs.python.org (Ned Deily) Date: Wed, 15 May 2013 23:37:43 +0000 Subject: [issue17990] 2.7 builds can fail due to unconditional inclusion of include paths Message-ID: <1368661063.81.0.616710425049.issue17990@psf.upfronthosting.co.za> New submission from Ned Deily: For Issue17086, 8ee6d96a1019 backported some cross-build patches to the 2.7 branch. The changes to setup.py detect_modules differ in the backport from those in default. In particular, in default, changes to the library and include directory lists used to build extensions modules are only made conditionally when cross-compiling. But the 2.7 backport makes these changes unconditionally. default: def detect_modules(self): # Ensure that /usr/local is always used, but the local build # directories (i.e. '.' and 'Include') must be first. See issue # 10520. if not cross_compiling: add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib') add_dir_to_list(self.compiler.include_dirs, '/usr/local/include') # only change this for cross builds for 3.3, issues on Mageia if cross_compiling: self.add_gcc_paths() self.add_multiarch_paths() 2.7: def detect_modules(self): # Ensure that /usr/local is always used add_dir_to_list(self.compiler.library_dirs, '/usr/local/lib') add_dir_to_list(self.compiler.include_dirs, '/usr/local/include') self.add_gcc_paths() self.add_multiarch_paths() This breaks certain universal build combinations on OS X when using SDKs and it is possible it could break builds on other platforms as well. Substituting the default branch code on 2.7 appears to solve the OS X build problem. Whether it has any negative impact on other builds, in particular cross-compilations is untested. ---------- components: Build messages: 189327 nosy: benjamin.peterson, doko, ned.deily priority: release blocker severity: normal stage: patch review status: open title: 2.7 builds can fail due to unconditional inclusion of include paths versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 01:39:59 2013 From: report at bugs.python.org (Ned Deily) Date: Wed, 15 May 2013 23:39:59 +0000 Subject: [issue17990] 2.7 builds can fail due to unconditional inclusion of include paths In-Reply-To: <1368661063.81.0.616710425049.issue17990@psf.upfronthosting.co.za> Message-ID: <1368661199.62.0.269946632208.issue17990@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- keywords: +patch Added file: http://bugs.python.org/file30274/issue17990.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 01:41:44 2013 From: report at bugs.python.org (Matthias Klose) Date: Wed, 15 May 2013 23:41:44 +0000 Subject: [issue17990] 2.7 builds can fail due to unconditional inclusion of include paths In-Reply-To: <1368661063.81.0.616710425049.issue17990@psf.upfronthosting.co.za> Message-ID: <1368661304.24.0.565742161597.issue17990@psf.upfronthosting.co.za> Matthias Klose added the comment: I don't see how this would break the cross builds, so please go ahead with this change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 01:45:48 2013 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 May 2013 23:45:48 +0000 Subject: [issue8604] Adding an atomic FS write API In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za> Message-ID: <1368661548.32.0.944485298992.issue8604@psf.upfronthosting.co.za> STINNER Victor added the comment: "I prefer to use tempfile.NamedTemporaryFile because it is portable and well tested. It also uses a random suffix. On Windows, the O_TEMPORARY flag is passed to os.open(), ..." Oh, and it sets also the close-on-exec safe, which is also more secure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 01:50:03 2013 From: report at bugs.python.org (STINNER Victor) Date: Wed, 15 May 2013 23:50:03 +0000 Subject: [issue8604] Adding an atomic FS write API In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za> Message-ID: <1368661803.13.0.790441539008.issue8604@psf.upfronthosting.co.za> STINNER Victor added the comment: atomic_write.patch calls os.replace(src, dst) whereas the src file is open. It works on Linux, but it sounds a little bit strange to me and may fail on other platforms. Here is another patch (atomic_write_mkstemp.patch) using tempfile.mkstemp() instead of tempfile.NamedTemporaryFile(delete=True) to control when the file is closed and removed. ---------- Added file: http://bugs.python.org/file30275/atomic_write_mkstemp.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 02:04:55 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 May 2013 00:04:55 +0000 Subject: [issue11877] Change os.fsync() to support physical backing store syncs In-Reply-To: <1303212938.57.0.821096700769.issue11877@psf.upfronthosting.co.za> Message-ID: <1368662695.81.0.816439418715.issue11877@psf.upfronthosting.co.za> STINNER Victor added the comment: What is the status of this issue? This issue is interesting in the implementation of #8604 (add shutil.atomic_write()). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 02:12:13 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 May 2013 00:12:13 +0000 Subject: [issue8604] Adding an atomic FS write API In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za> Message-ID: <1368663133.36.0.360138058169.issue8604@psf.upfronthosting.co.za> STINNER Victor added the comment: > Here's the part of the code that does the open/close part: > http://bazaar.launchpad.net/~exabyte/blackherd/async-refactor/view/61/blackherd/misc.py#L498 This code contains a bug: hasattr('os', 'fsync') is never True :-) This part is interesting: # fsync on Mac OS X doesn't work, it requires using the # F_FULLSYNC fcntl if hasattr(fcntl, 'F_FULLFSYNC'): fcntl.fcntl(self._fd, fcntl.F_FULLFSYNC) => see also #11877 > http://trac.edgewall.org/browser/trunk/trac/util/__init__.py?#L145 This class copies file owner, permissions, flags, etc. atomic_write() should probably also call copystat() on the temporary file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 02:51:39 2013 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 16 May 2013 00:51:39 +0000 Subject: [issue8604] Adding an atomic FS write API In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za> Message-ID: <1368665499.5.0.696273697345.issue8604@psf.upfronthosting.co.za> Nick Coghlan added the comment: We have one of these in Beaker (we didn't need to wait for os.replace, since Beaker only runs on Linux): http://git.beaker-project.org/cgit/beaker/tree/Common/bkr/common/helpers.py?h=develop#n90 It turns out to be beneficial to separate the three operations in order to cooperate more cleanly with other operations on the same file system (in our case, we needed to be able to write data uploaded over a network connection to the temporary file *before* acquiring an flock when we did the rename). We also create the file adjacent to the destination, as creating it under the /tmp heirarchy and then renaming it is invalid under SELinux (since the security context ends up being incorrect). While Beaker is GPLv2, I'd easily be able to get permission to extract this and contribute it to the PSF. Incidentally, I'm thinking tempfile might actually be a more sensible home for this than shutil. ---------- assignee: tarek -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 02:54:58 2013 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 16 May 2013 00:54:58 +0000 Subject: [issue8604] Adding an atomic FS write API In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za> Message-ID: <1368665698.01.0.829110519369.issue8604@psf.upfronthosting.co.za> Nick Coghlan added the comment: (Note that the Beaker version would need to be enhanced with the extra API parameters from Victor's version, as well as updated to use the exclusive open and close-on-exec flags) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 03:02:48 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 May 2013 01:02:48 +0000 Subject: [issue17990] 2.7 builds can fail due to unconditional inclusion of include paths In-Reply-To: <1368661063.81.0.616710425049.issue17990@psf.upfronthosting.co.za> Message-ID: <3b9vWC4ywrz7Lnl@mail.python.org> Roundup Robot added the comment: New changeset cd577c328886 by Ned Deily in branch '2.7': Issue #17990: Only modify include and library search paths when cross-compiling. http://hg.python.org/cpython/rev/cd577c328886 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 03:05:35 2013 From: report at bugs.python.org (Ned Deily) Date: Thu, 16 May 2013 01:05:35 +0000 Subject: [issue17990] 2.7 builds can fail due to unconditional inclusion of include paths In-Reply-To: <1368661063.81.0.616710425049.issue17990@psf.upfronthosting.co.za> Message-ID: <1368666335.54.0.876659930132.issue17990@psf.upfronthosting.co.za> Ned Deily added the comment: Applied to 2.7 branch. Leaving the issue open for release manager action for 2.7.5. ---------- components: +Cross-Build resolution: -> fixed stage: patch review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 04:33:23 2013 From: report at bugs.python.org (xiaobing jiang) Date: Thu, 16 May 2013 02:33:23 +0000 Subject: [issue17972] inspect module docs omits many functions In-Reply-To: <1368501068.91.0.677640111487.issue17972@psf.upfronthosting.co.za> Message-ID: <1368671603.92.0.263604877295.issue17972@psf.upfronthosting.co.za> xiaobing jiang added the comment: when I read the memory_profiler source code, I find it using inspect.getblock(). so I check the doc, but can't find the function's doc. these functions are found not in doc. I want to known which function should in doc or not? in inspect module has no __all__ variable. sorry for poor english! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 05:21:57 2013 From: report at bugs.python.org (Steven Barker) Date: Thu, 16 May 2013 03:21:57 +0000 Subject: [issue17991] ctypes.c_char gives a misleading error when passed a one-character unicode string Message-ID: <1368674517.59.0.230555789399.issue17991@psf.upfronthosting.co.za> New submission from Steven Barker: While investigating a Stack Overflow question (http://stackoverflow.com/questions/16484764/multiprocessing-value-clear-syntax) I came across a misleading error message from the multiprocessing.Value constructor: >>> import multiprocessing >>> my_char = "x" >>> v = multiprocessing.Value("c", my_char) Traceback (most recent call last): File "", line 1, in v = multiprocessing.Value("c", my_char) File "S:\Python33\lib\multiprocessing\__init__.py", line 243, in Value return Value(typecode_or_type, *args, lock=lock) File "S:\Python33\lib\multiprocessing\sharedctypes.py", line 70, in Value obj = RawValue(typecode_or_type, *args) File "S:\Python33\lib\multiprocessing\sharedctypes.py", line 47, in RawValue obj.__init__(*args) TypeError: one character string expected The "one character string expected" message was rather unhelpful, since that seemed to be what I gave it. After being stumped by this for a bit, I realized that it might be having an issue with Unicode and giving an error message more appropriate to Python 2 than Python 3. Sure enough, passing a one-character bytes instance works just fine. So, at a minimum I think the error message should be updated to say it wants a one-character bytes instance rather than a "string" (which to my mind means a "str" instance). A further enhancement might be to accept unicode strings that contain just a single ASCII character too, but I realize that may be more messy and error prone. The error message comes from the ctypes module, and can be reproduced easily: >>> ctypes.c_char("x") Traceback (most recent call last): File "", line 1, in ctypes.c_char("x") TypeError: one character string expected The exception text comes from Modules/_ctypes/cfield.c:1151 ---------- components: Library (Lib) messages: 189338 nosy: Steven.Barker priority: normal severity: normal status: open title: ctypes.c_char gives a misleading error when passed a one-character unicode string type: enhancement versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 05:26:01 2013 From: report at bugs.python.org (Steven Barker) Date: Thu, 16 May 2013 03:26:01 +0000 Subject: [issue17991] ctypes.c_char gives a misleading error when passed a one-character unicode string In-Reply-To: <1368674517.59.0.230555789399.issue17991@psf.upfronthosting.co.za> Message-ID: <1368674761.38.0.791031491338.issue17991@psf.upfronthosting.co.za> Changes by Steven Barker : ---------- components: +ctypes -Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 05:30:35 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 16 May 2013 03:30:35 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1368675035.96.0.957844528715.issue15392@psf.upfronthosting.co.za> Terry J. Reedy added the comment: New patch: I renamed Itest to idle_test everywhere and re-ran tests; removed try-except from test_pathbrowser.py; and renamed @template to @README and rewrote. It applies cleanly to 3.4 on my system. The only problem applying to 2.7 is CallTips.py, which has different test code at the end. That will be easily fixed. ---------- Added file: http://bugs.python.org/file30276/idletest2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 06:54:43 2013 From: report at bugs.python.org (Carlos Nepomuceno) Date: Thu, 16 May 2013 04:54:43 +0000 Subject: [issue17992] test_asynchat hangs Message-ID: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> New submission from Carlos Nepomuceno: after running 'make' i entered 'make test' and it hanged on test_asynchat. stayed there for more than 1 hour. --- Python build finished, but the necessary bits to build these modules were not found: _bsddb _tkinter bsddb185 bz2 dbm dl gdbm imageop readline sunaudiodev To find the necessary bits, look in setup.py in detect_modules() for the module's name. running build_scripts ./python -E -c 'import sys ; from sysconfig import get_platform ; print get_platform()+"-"+sys.version[0:3]' >platform find ./Lib -name '*.py[co]' -print | xargs rm -f ./python -Wd -3 -E -tt ./Lib/test/regrtest.py -l == CPython 2.7.5 (default, May 16 2013, 00:43:33) [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] == Linux-2.6.32-279.19.1.el6.x86_64-x86_64-with-centos-6.4-Final little-endian == /usr/src/Python-2.7.5/build/test_python_26106 Testing with flags: sys.flags(debug=0, py3k_warning=1, division_warning=1, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, tabcheck=2, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0) test_grammar test_opcodes test_dict test_builtin test_exceptions test_types test_unittest /usr/src/Python-2.7.5/Lib/unittest/runner.py:39: DeprecationWarning: comparing unequal types not supported in 3.x self.showAll = verbosity > 1 test_doctest test_doctest2 test_MimeWriter test_SimpleHTTPServer test_StringIO test___all__ test___future__ test__locale test__osx_support test_abc test_abstract_numbers test_aepack test_aepack skipped -- No module named aetypes test_aifc test_al test_al skipped -- No module named al test_anydbm test_applesingle test_applesingle skipped -- No module named MacOS test_argparse test_array test_ascii_formatd test_ast test_asynchat ---------- components: Tests files: test_asynchat.txt messages: 189340 nosy: Carlos.Nepomuceno priority: normal severity: normal status: open title: test_asynchat hangs type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file30277/test_asynchat.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 06:57:27 2013 From: report at bugs.python.org (Brian Curtin) Date: Thu, 16 May 2013 04:57:27 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368680247.53.0.829107338574.issue17992@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 06:58:01 2013 From: report at bugs.python.org (Carlos Nepomuceno) Date: Thu, 16 May 2013 04:58:01 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368680281.42.0.147622659221.issue17992@psf.upfronthosting.co.za> Changes by Carlos Nepomuceno : Removed file: http://bugs.python.org/file30277/test_asynchat.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 06:58:24 2013 From: report at bugs.python.org (Carlos Nepomuceno) Date: Thu, 16 May 2013 04:58:24 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368680304.72.0.353081386882.issue17992@psf.upfronthosting.co.za> Changes by Carlos Nepomuceno : Added file: http://bugs.python.org/file30278/test_asynchat.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 07:00:13 2013 From: report at bugs.python.org (Carlos Nepomuceno) Date: Thu, 16 May 2013 05:00:13 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368680413.46.0.899321341079.issue17992@psf.upfronthosting.co.za> Changes by Carlos Nepomuceno : Removed file: http://bugs.python.org/file30278/test_asynchat.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 07:00:26 2013 From: report at bugs.python.org (Carlos Nepomuceno) Date: Thu, 16 May 2013 05:00:26 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368680426.07.0.52555953906.issue17992@psf.upfronthosting.co.za> Changes by Carlos Nepomuceno : Added file: http://bugs.python.org/file30279/test_asynchat.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 07:04:52 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 16 May 2013 05:04:52 +0000 Subject: [issue17990] 2.7 builds can fail due to unconditional inclusion of include paths In-Reply-To: <1368661063.81.0.616710425049.issue17990@psf.upfronthosting.co.za> Message-ID: <1368680692.96.0.995825290918.issue17990@psf.upfronthosting.co.za> Benjamin Peterson added the comment: The 32-bit OSX binary was patched manually. ---------- components: -Cross-Build stage: committed/rejected -> patch review status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 07:05:27 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 16 May 2013 05:05:27 +0000 Subject: [issue17990] 2.7 builds can fail due to unconditional inclusion of include paths In-Reply-To: <1368661063.81.0.616710425049.issue17990@psf.upfronthosting.co.za> Message-ID: <1368680727.08.0.805331067721.issue17990@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- components: +Cross-Build _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 08:28:16 2013 From: report at bugs.python.org (Ned Deily) Date: Thu, 16 May 2013 06:28:16 +0000 Subject: [issue17990] 2.7 builds can fail due to unconditional inclusion of include paths In-Reply-To: <1368661063.81.0.616710425049.issue17990@psf.upfronthosting.co.za> Message-ID: <1368685696.19.0.279690358979.issue17990@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- stage: patch review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 08:32:14 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Thu, 16 May 2013 06:32:14 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368685934.63.0.762289250629.issue17992@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +giampaolo.rodola, josiahcarlson, stutzbach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 08:33:03 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Thu, 16 May 2013 06:33:03 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368685983.2.0.0464830504095.issue17992@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 08:44:31 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 16 May 2013 06:44:31 +0000 Subject: [issue8604] Adding an atomic FS write API In-Reply-To: <1368665698.01.0.829110519369.issue8604@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > (Note that the Beaker version would need to be enhanced with the extra API parameters from Victor's version, as well as updated to use the exclusive open and close-on-exec flags) I think the API would be nicer if it was just a wrapper around the underlying temporary file object, delegating all methods except close() (sort of like the _TemporaryFileWrapper in tempfile). Something like (untested, not even foolproof-read) : class AtomicFile: def __init__(self, path): self.dest_path = path dirname, basename = os.path.split(self.dest_path) fd, temp_path = tempfile.mkstemp(prefix='.' + basename, dir=dirname) try: self.f = os.fdopen(fd, 'w') except: os.unlink(temp_path) raise self.temp_path = temp_path def close(self): self.f.close() os.rename(self.temp_path, self.dest_path) # copied from tempfile def __getattr__(self, name): # Attribute lookups are delegated to the underlying file # and cached for non-numeric results # (i.e. methods are cached, closed and friends are not) file = self.__dict__['file'] a = getattr(file, name) if not issubclass(type(a), type(0)): setattr(self, name, a) return a def __enter__self(): self.file.__enter__() return f def __exit__(self, exc, value, tb): if exc is None: self.close() else: self.file.close() os.remove(self.temp_path) This way, one just has to do: f = AtomicFile(path) and then use it as a normal file; it will automatically be committed (or rollback) when the file is closed, either because you're leaving the context manager, or because an explicit() close is called. It also makes it easier to use with legacy code/libraries accepting an open file (since no modification is needed), is less error-prone (since you don't have to remember to call special methods like destroy_temp/replace_dest), and leads to a more compact API (exactly the same as regular files). Otherwise, I think the calls to fsync() should be optional (maybe an option passed to the constructor): most of the time, you want atomicity but not durability (i.e. you don't really care if data is committed to disk), and you don't want to pay for the performance hit incurred by fsync(). Also, fsync() should also be done on the containing directory (which is not the case in Victor's version). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 09:18:52 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 16 May 2013 07:18:52 +0000 Subject: [issue17993] Missed comma causes unintentional implicit string literal concatenation Message-ID: <1368688732.05.0.0592357298734.issue17993@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: I just found a bug in Tools/scripts/abitype.py: typeslots = [ 'tp_name', 'tp_basicsize', ... 'tp_subclasses', 'tp_weaklist', 'tp_del' 'tp_version_tag' ] There is a missed comma after 'tp_del'. Perhaps there are other similar bugs in Python sources. ---------- components: Demos and Tools files: missed_comma.patch keywords: patch messages: 189343 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Missed comma causes unintentional implicit string literal concatenation type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30280/missed_comma.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 09:39:22 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 16 May 2013 07:39:22 +0000 Subject: [issue17993] Missed comma causes unintentional implicit string literal concatenation In-Reply-To: <1368688732.05.0.0592357298734.issue17993@psf.upfronthosting.co.za> Message-ID: <1368689962.55.0.973614855307.issue17993@psf.upfronthosting.co.za> Ezio Melotti added the comment: Patch LGTM. Are you planning to look for similar bugs before fixing this? ---------- nosy: +ezio.melotti stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 11:52:27 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 16 May 2013 09:52:27 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368697947.26.0.591635115898.issue17992@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Can you try to figure out where it hangs exactly? I can't reproduce the issue on Ubuntu and FreeBSD and don't have a Red Hat to test against. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 11:59:42 2013 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 16 May 2013 09:59:42 +0000 Subject: [issue17981] SysLogHandler closes connection before using it In-Reply-To: <1368625795.57.0.786028186823.issue17981@psf.upfronthosting.co.za> Message-ID: <1368698382.27.0.729614629625.issue17981@psf.upfronthosting.co.za> Vinay Sajip added the comment: The python-daemon documentation states, about files_preserve: "Elements of the list are file descriptors (as returned by a file object's `fileno()` method) or Python `file` objects. Each specifies a file that is not to be closed during daemon start." Notice that file objects are just a convenience - filenos() can be passed. The following, slightly modified script works as expected: import logging import logging.handlers import daemon logger = logging.getLogger('twitterCounter') handler = logging.handlers.SysLogHandler(address='/dev/log') logger.addHandler(handler) logger.setLevel(logging.DEBUG) logger.info("Hello, ") with daemon.DaemonContext(files_preserve=[handler.socket.fileno()]): logger.info("world!") Output in syslog after running the above: May 16 10:58:42 eta-oneiric64 Hello, May 16 10:58:42 eta-oneiric64 world! ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 12:09:46 2013 From: report at bugs.python.org (Carlos Nepomuceno) Date: Thu, 16 May 2013 10:09:46 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368698986.6.0.88738868215.issue17992@psf.upfronthosting.co.za> Carlos Nepomuceno added the comment: I don't know what to do. I tried CTRL+C but it didn't stop. Then I pressed CTRL+Z and kill the python process and when i got back with 'fg' the make process had been terminated. No messages were printed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 12:16:41 2013 From: report at bugs.python.org (Jan Lieskovsky) Date: Thu, 16 May 2013 10:16:41 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368699401.58.0.282267929169.issue17980@psf.upfronthosting.co.za> Jan Lieskovsky added the comment: The CVE identifier of CVE-2013-2099 has been assigned: http://www.openwall.com/lists/oss-security/2013/05/16/6 to this issue. ---------- nosy: +iankko title: ssl.match_hostname() trips over crafted wildcard names -> CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 12:27:07 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 16 May 2013 10:27:07 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368700027.08.0.882550860441.issue17992@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Does it hang also if you run it directly as in "./python Lib/test/test_asynchat.py". Perhaps you ca try "./python -m trace -t Lib/test/test_asynchat.py"? Figuring this out should be relatively easy: you can also just put prints into test_asynchat.py yourself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 12:31:52 2013 From: report at bugs.python.org (Carlos Nepomuceno) Date: Thu, 16 May 2013 10:31:52 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368700312.86.0.367706998443.issue17992@psf.upfronthosting.co.za> Carlos Nepomuceno added the comment: ./python -m trace -t Lib/test/test_asynchat.py [...] --- modulename: asyncore, funcname: poll asyncore.py(126): if map is None: asyncore.py(128): if map: asyncore.py(129): r = []; w = []; e = [] asyncore.py(130): for fd, obj in map.items(): asyncore.py(131): is_r = obj.readable() --- modulename: asynchat, funcname: readable asynchat.py(198): return 1 asyncore.py(132): is_w = obj.writable() --- modulename: asynchat, funcname: writable asynchat.py(202): return self.producer_fifo or (not self.connected) asyncore.py(133): if is_r: asyncore.py(134): r.append(fd) asyncore.py(136): if is_w and not obj.accepting: asyncore.py(137): w.append(fd) asyncore.py(138): if is_r or is_w: asyncore.py(139): e.append(fd) asyncore.py(130): for fd, obj in map.items(): asyncore.py(140): if [] == r == w == e: asyncore.py(144): try: asyncore.py(145): r, w, e = select.select(r, w, e, timeout) asyncore.py(152): for fd in r: asyncore.py(158): for fd in w: asyncore.py(164): for fd in e: asyncore.py(221): count = count - 1 asyncore.py(219): while map and count > 0: test_asynchat.py(225): s.start_resend_event.set() --- modulename: threading, funcname: set threading.py(580): self.__cond.acquire() threading.py(581): try: threading.py(582): self.__flag = True threading.py(583): self.__cond.notify_all() --- modulename: threading, funcname: notifyAll threading.py(406): self.notify(len(self.__waiters)) --- modulename: threading, funcname: notify threading.py(382): if not self._is_owned(): --- modulename: threading, funcname: _is_owned threading.py(302): if self.__lock.acquire(0): threading.py(306): return True threading.py(384): __waiters = self.__waiters threading.py(385): waiters = __waiters[:n] threading.py(386): if not waiters: threading.py(388): self._note("%s.notify(): no waiters", self) --- modulename: threading, funcname: _note threading.py(64): if self.__verbose: threading.py(389): return threading.py(585): self.__cond.release() test_asynchat.py(226): s.join() --- modulename: threading, funcname: join threading.py(933): if not self.__initialized: threading.py(935): if not self.__started.is_set(): --- modulename: threading, funcname: isSet threading.py(569): return self.__flag threading.py(937): if self is current_thread(): --- modulename: threading, funcname: currentThread threading.py(1157): try: threading.py(1158): return _active[_get_ident()] threading.py(941): if not self.__stopped: threading.py(942): self._note("%s.join(): waiting until thread stops", self) --- modulename: threading, funcname: _note threading.py(64): if self.__verbose: threading.py(943): self.__block.acquire() threading.py(944): try: threading.py(945): if timeout is None: threading.py(946): while not self.__stopped: threading.py(947): self.__block.wait() --- modulename: threading, funcname: wait threading.py(331): if not self._is_owned(): --- modulename: threading, funcname: _is_owned threading.py(302): if self.__lock.acquire(0): threading.py(306): return True threading.py(333): waiter = _allocate_lock() threading.py(334): waiter.acquire() threading.py(335): self.__waiters.append(waiter) threading.py(336): saved_state = self._release_save() --- modulename: threading, funcname: _release_save threading.py(294): self.__lock.release() # No state to save threading.py(337): try: # restore state no matter what (e.g., KeyboardInterrupt) threading.py(338): if timeout is None: threading.py(339): waiter.acquire() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 12:34:23 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 16 May 2013 10:34:23 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368700463.85.0.324636022719.issue17980@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> needs patch type: -> security versions: +Python 3.2, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 12:47:19 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 16 May 2013 10:47:19 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368701239.3.0.458147465696.issue17992@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Nosying Collin Winter as per rev 531d3023b48b. In the meantime you can try to specify a timeout for join() as in: diff --git a/Lib/test/test_asynchat.py b/Lib/test/test_asynchat.py --- a/Lib/test/test_asynchat.py +++ b/Lib/test/test_asynchat.py @@ -223,7 +223,7 @@ # where the server echoes all of its data before we can check that it # got any down below. s.start_resend_event.set() - s.join() + s.join(timeout=2.0) That should at least fix the hanging, but I guess it will produce another error later on. ---------- nosy: +collinwinter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 12:49:32 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 16 May 2013 10:49:32 +0000 Subject: [issue1662581] the re module can perform poorly: O(2**n) versus O(n**2) Message-ID: <1368701372.26.0.762886343723.issue1662581@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Note this can be used for denials of service: see http://bugs.python.org/issue17980 ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 12:51:47 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 16 May 2013 10:51:47 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368701507.21.0.251887750397.issue17980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This is caused by the regex engine's performance behaviour: http://bugs.python.org/issue1662581 http://bugs.python.org/issue1515829 http://bugs.python.org/issue212521 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 12:56:39 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 16 May 2013 10:56:39 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368701799.41.0.969214493064.issue17980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I would like to know what is the expected scenario: - does the attacker only control the certificate? - or does the attacker control both the certificate and the hostname being validated? The reason is that the matching cost for a domain name fragment seems to be O(n**k), where n is the fragment length and k is the number of wildcards. Therefore, if the attacker controls both n and k, even limiting k to 2 already allows a quadratic complexity attack. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 12:56:43 2013 From: report at bugs.python.org (R. David Murray) Date: Thu, 16 May 2013 10:56:43 +0000 Subject: [issue17890] argparse: mutually exclusive groups full of suppressed args can cause AssertionErrors In-Reply-To: <1367455382.45.0.0611766927148.issue17890@psf.upfronthosting.co.za> Message-ID: <1368701803.75.0.993359728242.issue17890@psf.upfronthosting.co.za> R. David Murray added the comment: I've been observing the activity on the argparse issues and am appreciating the work, but I don't have time right now to review the patches. I should have more time next month, and expect to get to them then, if no one else gets to them before I do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 12:56:44 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 16 May 2013 10:56:44 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368701804.06.0.92996935866.issue17980@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 12:59:50 2013 From: report at bugs.python.org (Carlos Nepomuceno) Date: Thu, 16 May 2013 10:59:50 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368701990.05.0.90690166244.issue17992@psf.upfronthosting.co.za> Carlos Nepomuceno added the comment: Thank you! But what's going on? Do my system have any limitation that is causing such hang? Here goes it's ulimit output just in case: [root at localhost Python-2.7.5]# ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 31259 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 31259 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited [root at localhost Python-2.7.5]# ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 13:15:56 2013 From: report at bugs.python.org (Christian Heimes) Date: Thu, 16 May 2013 11:15:56 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368702956.57.0.212197982899.issue17980@psf.upfronthosting.co.za> Christian Heimes added the comment: RFC 2818 doesn't say anything about the maximum amount of wildcards. I'm going to check OpenSSL's implementation now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 13:57:44 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 16 May 2013 11:57:44 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368705464.66.0.194976093554.issue17992@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Could you provide the output of: strace -ttT -f ./python Lib/test/test_asynchat.py ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 14:05:54 2013 From: report at bugs.python.org (Carlos Nepomuceno) Date: Thu, 16 May 2013 12:05:54 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368705954.55.0.554442360966.issue17992@psf.upfronthosting.co.za> Carlos Nepomuceno added the comment: Full output in the attached file. [root at localhost Python-2.7.5]# strace -ttT -f ./python Lib/test/test_asynchat.py [...] [pid 1697] 08:01:27.815179 select(6, [5], [5], [5], {0, 10000}) = 0 (Timeout) <0.010095> [pid 1697] 08:01:27.825348 select(6, [5], [5], [5], {0, 10000}) = 0 (Timeout) <0.010096> [pid 1697] 08:01:27.835509 select(6, [5], [5], [5], {0, 10000}) = 0 (Timeout) <0.010097> [pid 1697] 08:01:27.845669 select(6, [5], [5], [5], {0, 10000}) = 0 (Timeout) <0.010096> [pid 1697] 08:01:27.855830 select(6, [5], [5], [5], {0, 10000}) = 0 (Timeout) <0.010095> [pid 1697] 08:01:27.866028 select(6, [5], [5], [5], {0, 10000}) = 0 (Timeout) <0.010096> [pid 1697] 08:01:27.876188 select(6, [5], [5], [5], {0, 10000}) = 0 (Timeout) <0.010096> [pid 1697] 08:01:27.886388 futex(0x1bb8280, FUTEX_WAIT_PRIVATE, 0, NULL ---------- Added file: http://bugs.python.org/file30281/test_asynchat_strace.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 14:06:19 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Thu, 16 May 2013 12:06:19 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368705979.63.0.651181086358.issue17914@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: Minor modifications based on review comments. 1. Change mib array size to 2, 2. return value set to 0 consistently (in C code), and 3. removed IRIX #defines ---------- Added file: http://bugs.python.org/file30282/issue17914-6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 14:10:18 2013 From: report at bugs.python.org (Florian Weimer) Date: Thu, 16 May 2013 12:10:18 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368706218.05.0.480199923411.issue17980@psf.upfronthosting.co.za> Florian Weimer added the comment: OpenSSL supports only a single wildcard character. In my tests, I used a host name like aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.example.org, and a dNSName like a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*.example.org. Quadratic behavior wouldn't be too bad because the host name is necessarily rather short (more than 255 characters will not pass through DNS). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 14:14:51 2013 From: report at bugs.python.org (Illia Polosukhin) Date: Thu, 16 May 2013 12:14:51 +0000 Subject: [issue17206] Py_XDECREF() expands its argument multiple times In-Reply-To: <1360858057.09.0.617835061471.issue17206@psf.upfronthosting.co.za> Message-ID: <1368706491.46.0.694897382593.issue17206@psf.upfronthosting.co.za> Illia Polosukhin added the comment: Amaury, I didn't update Py_INCREF macro in this patch (because it doesn't expand it's argument multiple times) - so the examples you are showing will be working fine. I've updated Py_XINCREF, but it can't be used as an expression anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 14:15:06 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 16 May 2013 12:15:06 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368706506.14.0.667647886828.issue17992@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: That's what I thought: 08:01:24.824406 bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 <0.000024> [pid 1698] 08:01:24.825502 listen(3, 1) = 0 <0.000035> [pid 1698] 08:01:24.825786 accept(3, [pid 1697] 08:01:24.837622 connect(5, {sa_family=AF_INET, sin_port=htons(43785), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress) <0.000074> [pid 1697] 08:01:24.837811 select(6, [5], [5], [5], {0, 10000}) = 0 (Timeout) <0.010095> [pid 1697] 08:01:27.876188 select(6, [5], [5], [5], {0, 10000}) = 0 (Timeout) <0.010096> [pid 1697] 08:01:27.886388 futex(0x1bb8280, FUTEX_WAIT_PRIVATE, 0, NULL See the EINPROGRESS? The connect() doesn't return within 3 seconds. You probably have a firewall on your machine. What does: # iptables -L return ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 14:23:33 2013 From: report at bugs.python.org (Carlos Nepomuceno) Date: Thu, 16 May 2013 12:23:33 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368707013.27.0.436947393116.issue17992@psf.upfronthosting.co.za> Carlos Nepomuceno added the comment: What ports are needed? [root at localhost Python-2.7.5]# iptables -L Chain INPUT (policy DROP) target prot opt source destination ACCEPT udp -- anywhere anywhere udp dpt:domain ACCEPT tcp -- anywhere anywhere tcp dpt:http ACCEPT tcp -- anywhere anywhere tcp dpt:https ACCEPT icmp -- anywhere anywhere icmp echo-request ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED Chain FORWARD (policy DROP) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere state NEW [root at localhost Python-2.7.5]# ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 14:28:11 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 16 May 2013 12:28:11 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368707291.22.0.369331348345.issue17992@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: > What ports are needed? Many tests use random ephemeral ports on the loopback interface (e.g. 43785 above). You should update your rules to apply to external NIC, not on the loopback. ---------- resolution: -> invalid stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 14:30:54 2013 From: report at bugs.python.org (Apostolis Bessas) Date: Thu, 16 May 2013 12:30:54 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368707454.67.0.820831282784.issue17980@psf.upfronthosting.co.za> Changes by Apostolis Bessas : ---------- nosy: +mpessas _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 14:33:31 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 16 May 2013 12:33:31 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368707611.71.0.761734577529.issue17980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Indeed, two wildcards seem to be ok with a 255-character domain name: $ ./python -m timeit -s "import ssl; cert = {'subject': ((('commonName', '*a*a.com'),),)}" "try: ssl.match_hostname(cert, 'a' * 250 +'z.com')" "except ssl.CertificateError: pass" 1000 loops, best of 3: 797 usec per loop Three wildcards already start producing some load: $ ./python -m timeit -s "import ssl; cert = {'subject': ((('commonName', '*a*a*a.com'),),)}" "try: ssl.match_hostname(cert, 'a' * 250 +'z.com')" "except ssl.CertificateError: pass" 10 loops, best of 3: 66.2 msec per loop Four wildcards are more than enough for a DoS: $ ./python -m timeit -s "import ssl; cert = {'subject': ((('commonName', '*a*a*a*a.com'),),)}" "try: ssl.match_hostname(cert, 'a' * 250 +'z.com')" "except ssl.CertificateError: pass" 10 loops, best of 3: 4.12 sec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 14:40:24 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 16 May 2013 12:40:24 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368708024.3.0.928909039022.issue17992@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Good catch! I think we better set a general timeout so that the tests fail instead of hanging though. Carlos can you try the patch in attachment and confirm you see failures instead of hangings? ---------- keywords: +patch Added file: http://bugs.python.org/file30283/asyncore-timeout.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 14:43:57 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 16 May 2013 12:43:57 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368706218.05.0.480199923411.issue17980@psf.upfronthosting.co.za> Message-ID: <1905282002.4507864.1368708231321.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > In my tests, I used a host name like > aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.example.org, and a dNSName > like a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*a*.example.org. > Quadratic behavior wouldn't be too bad because the host name is > necessarily rather short (more than 255 characters will not pass > through DNS). Hmm, but the host name doesn't necessarily come from DNS, does it? ---------- title: CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names -> CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 14:45:00 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 16 May 2013 12:45:00 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368708300.04.0.217025874373.issue17980@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 14:50:10 2013 From: report at bugs.python.org (Florian Weimer) Date: Thu, 16 May 2013 12:50:10 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368708610.69.0.227631887513.issue17980@psf.upfronthosting.co.za> Florian Weimer added the comment: The host name is looked up to get the IP address to connect to. The lookup will fail if the host name is longer than 255 characters, and the crafted certificate is never retrieved. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 14:54:21 2013 From: report at bugs.python.org (Carlos Nepomuceno) Date: Thu, 16 May 2013 12:54:21 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368708861.07.0.345914194735.issue17992@psf.upfronthosting.co.za> Carlos Nepomuceno added the comment: Yes, but I don't have the git clone. Can you send the complete file instead of the patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 14:54:27 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 16 May 2013 12:54:27 +0000 Subject: [issue17206] Py_XDECREF() expands its argument multiple times In-Reply-To: <1360858057.09.0.617835061471.issue17206@psf.upfronthosting.co.za> Message-ID: <1368708867.53.0.205987901097.issue17206@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 14:54:40 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 16 May 2013 12:54:40 +0000 Subject: [issue17589] Make documentation about macros in C API explicit about rvalue vs statement In-Reply-To: <1364758755.79.0.998719447408.issue17589@psf.upfronthosting.co.za> Message-ID: <1368708880.68.0.599917879212.issue17589@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 14:54:54 2013 From: report at bugs.python.org (Carlos Nepomuceno) Date: Thu, 16 May 2013 12:54:54 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368708894.42.0.736186580643.issue17992@psf.upfronthosting.co.za> Carlos Nepomuceno added the comment: BTW, problem solved with: iptables -A INPUT -d 127.0.0.1 -j ACCEPT iptables -A INPUT -s 127.0.0.1 -j ACCEPT Thanks a lot! \o ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 14:56:53 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Thu, 16 May 2013 12:56:53 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368709013.46.0.656557688993.issue17914@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: Typo fix ---------- Added file: http://bugs.python.org/file30284/issue17914-7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 14:58:18 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 16 May 2013 12:58:18 +0000 Subject: [issue8604] Adding an atomic FS write API In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za> Message-ID: <1368709098.39.0.550164602935.issue8604@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 15:01:08 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 16 May 2013 13:01:08 +0000 Subject: [issue8604] Adding an atomic FS write API In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za> Message-ID: <1368709268.13.0.585744551387.issue8604@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 15:01:29 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 16 May 2013 13:01:29 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368709289.79.0.588555320565.issue17992@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : Added file: http://bugs.python.org/file30285/test_asynchat.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 15:01:37 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 16 May 2013 13:01:37 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368709297.87.0.401595837061.issue17992@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : Added file: http://bugs.python.org/file30286/test_asyncore.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 15:04:44 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 16 May 2013 13:04:44 +0000 Subject: [issue17989] ElementTree.Element broken attribute setting In-Reply-To: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za> Message-ID: <1368709484.21.0.0624740182592.issue17989@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 15:08:04 2013 From: report at bugs.python.org (Christian Heimes) Date: Thu, 16 May 2013 13:08:04 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368709684.44.0.411079454883.issue17980@psf.upfronthosting.co.za> Christian Heimes added the comment: I think a malicious user could abuse SNI to craft a longer host name and trigger the pathological case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 15:16:06 2013 From: report at bugs.python.org (Carlos Nepomuceno) Date: Thu, 16 May 2013 13:16:06 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368710166.82.0.69219062639.issue17992@psf.upfronthosting.co.za> Carlos Nepomuceno added the comment: Tried to use the new files[1] but they use 'support' instead of 'test_support' from 'test' module. [1] test_asynchat.py, test_asyncore.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 15:19:22 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 16 May 2013 13:19:22 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368710362.13.0.250229810879.issue17992@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Nevermind. It's an easy patch so I'm going to commit it anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 15:20:03 2013 From: report at bugs.python.org (Julien Palard) Date: Thu, 16 May 2013 13:20:03 +0000 Subject: [issue17981] SysLogHandler closes connection before using it In-Reply-To: <1368625795.57.0.786028186823.issue17981@psf.upfronthosting.co.za> Message-ID: <1368710403.37.0.0136703660887.issue17981@psf.upfronthosting.co.za> Julien Palard added the comment: I understand the files_preserve parameter, the bug I'm filling is the innability of SysLogHandler to reopen the socket, although it tries : // DaemonContext closing all FDs: close(3) = 0 close(2) = 0 close(1) = 0 close(0) = 0 [...] // Trying to send "World !" to the closed socket (developper missusing files_preserve sendto(3, "<14>World !\0", 12, 0, NULL, 0) = -1 EBADF (Bad file descriptor) // Reopening socket, with good parameters socket(PF_FILE, SOCK_DGRAM, 0) = 3 // WTF ? For me, the bug is here, why do we close it ? // That's not the DaemonContext that closes the file here, as we already are in daemonContext, all files were closed before by the DaemonContext, so for me it's SysLogHandler who's closing here and it's a bug : close(3) = 0 // Trying to connect to a closed socket ... will fail )o: connect(3, {sa_family=AF_FILE, path="/dev/log"}, 10) = -1 EBADF (Bad file descriptor) // Reclosing it ? ok ... why not as we don't know that it were closed. close(3) = -1 EBADF (Bad file descriptor) // Trying another socket type, cause first try failed, but failed cause the close(), it may have not been closed and have succeed. So this try may no apprear normally : socket(PF_FILE, SOCK_STREAM, 0) = 3 connect(3, {sa_family=AF_FILE, path="/dev/log"}, 10) = -1 EPROTOTYPE (Protocol wrong type for socket) ---------- resolution: invalid -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 15:21:14 2013 From: report at bugs.python.org (Carlos Nepomuceno) Date: Thu, 16 May 2013 13:21:14 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <1368710474.35.0.396381685646.issue17992@psf.upfronthosting.co.za> Carlos Nepomuceno added the comment: Ok! Thanks a lot! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 15:22:06 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 May 2013 13:22:06 +0000 Subject: [issue17992] test_asynchat hangs In-Reply-To: <1368680083.51.0.0433699528341.issue17992@psf.upfronthosting.co.za> Message-ID: <3bBCwF2X70z7LkY@mail.python.org> Roundup Robot added the comment: New changeset 3ee61b048173 by Giampaolo Rodola' in branch 'default': Issue #17992: Add timeouts to asyncore and asynchat tests so that they won't accidentally hang. http://hg.python.org/cpython/rev/3ee61b048173 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 15:27:01 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 16 May 2013 13:27:01 +0000 Subject: [issue17206] Py_XDECREF() expands its argument multiple times In-Reply-To: <1360858057.09.0.617835061471.issue17206@psf.upfronthosting.co.za> Message-ID: <1368710821.95.0.582885969469.issue17206@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The last patch (17206-3.diff) has tests for the 4 macros, and looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 15:34:22 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 16 May 2013 13:34:22 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368711262.64.0.251659257711.issue17980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: In GnuTLS, _gnutls_hostname_compare() (lib/gnutls_str.c) uses a trivial recursive approach with a maximum number of 5 wildcards. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 15:39:20 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Thu, 16 May 2013 13:39:20 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1368711560.81.0.439143522196.issue17914@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: +1 for returning None. I haven't looked into patches but if needed feel free to borrow some code from psutil: Linux: https://code.google.com/p/psutil/source/browse/psutil/_pslinux.py?spec=svn30f3c67322f99ab30ed87205245dc8394f89f0ac&r=c970f35bc9640ac32eb9f09de8c230e7f86a2466#44 BSD / OSX: https://code.google.com/p/psutil/source/browse/psutil/_psutil_bsd.c?spec=svn30f3c67322f99ab30ed87205245dc8394f89f0ac&r=9b6e780ea6b598a785670c2626c7557f9fef9238#486 Windows: https://code.google.com/p/psutil/source/browse/psutil/_psutil_mswindows.c?spec=svn30f3c67322f99ab30ed87205245dc8394f89f0ac&r=4d5b0de27024e9d3cd6a3573a493290498afa9c2#426 SunOS: https://code.google.com/p/psutil/source/browse/psutil/_pssunos.py?spec=svnff76a4e33da359162c28f8c7478f9e6c6dff347b&name=sunos&r=d53e11edfbe18d22f4e08168f72b1952cfaef373#27 ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 15:55:35 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 16 May 2013 13:55:35 +0000 Subject: [issue17988] ElementTree.Element != ElementTree._ElementInterface In-Reply-To: <1368657583.19.0.922119818205.issue17988@psf.upfronthosting.co.za> Message-ID: <1368712535.0.0.894348405313.issue17988@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 15:57:57 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 16 May 2013 13:57:57 +0000 Subject: [issue17989] ElementTree.Element broken attribute setting In-Reply-To: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za> Message-ID: <1368712677.43.0.529138786512.issue17989@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 16:11:36 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 16 May 2013 14:11:36 +0000 Subject: [issue8604] Adding an atomic FS write API In-Reply-To: <1272890639.26.0.821067455807.issue8604@psf.upfronthosting.co.za> Message-ID: <1368713496.73.0.835428039378.issue8604@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Of course, I have my own atomic-rename thing, but I'm not going to post the code here. It's fairly limited to my own use case and I have no interest in making it cross platform. That being said, I personally found that a context manager with a signature identical to built-in open() was the most convenient API. It looks natural: with atomic(filename, 'w', encoding='utf-8') as fp: data = do_a_bunch_of_things_that_might_fail() fp.write(data) If any of that fails, the temporary file is guaranteed to be cleaned up, otherwise, filename (which is the ultimate destination) will be guaranteed to exist. Another reason why context managers are useful is with ExitStack(), where you might have a bunch of conditions that you want to guarantee get cleaned up properly if any of them fail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 16:24:45 2013 From: report at bugs.python.org (Ian Cordasco) Date: Thu, 16 May 2013 14:24:45 +0000 Subject: [issue17994] Change necessary in platform.py to support IronPython Message-ID: <1368714285.1.0.952125974829.issue17994@psf.upfronthosting.co.za> New submission from Ian Cordasco: Stemming from a StackOverflow question[1] and a conversation with Marc-Andre Lemburg via email, I'm filing this issue without any easy way of confirming it myself. It seems that the logic in platform.python_implementation() has been obsoleted by a change made in IronPython. As it is now, it checks that the slice, sys.version[:10], is "IronPython". Seemingly due to a change in IronPython, this no longer is a correct condition for checking that the implementation is IronPython. I'm trying to work with the question author on StackOverflow to provide the relevant debugging information to fix this, but it is taking a while to get responses. Without his repr(sys.version) I can't submit a patch with this issue. I've also only tagged Python 2.7 since I have no way of knowing if this occurs with Python 3.x or anything earlier. [1]: http://stackoverflow.com/questions/16545027/ironpython-error-in-url-request?noredirect=1#comment23828551_16545027 ---------- components: Library (Lib), Windows messages: 189383 nosy: icordasc, lemburg priority: normal severity: normal status: open title: Change necessary in platform.py to support IronPython versions: 3rd party, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 16:41:35 2013 From: report at bugs.python.org (Brian Curtin) Date: Thu, 16 May 2013 14:41:35 +0000 Subject: [issue17994] Change necessary in platform.py to support IronPython In-Reply-To: <1368714285.1.0.952125974829.issue17994@psf.upfronthosting.co.za> Message-ID: <1368715295.54.0.431009354639.issue17994@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- nosy: +brian.curtin stage: -> test needed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 16:52:55 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 16 May 2013 14:52:55 +0000 Subject: [issue17994] Change necessary in platform.py to support IronPython In-Reply-To: <1368714285.1.0.952125974829.issue17994@psf.upfronthosting.co.za> Message-ID: <1368715975.48.0.470638613125.issue17994@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +dino.viehland _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 17:21:03 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 16 May 2013 15:21:03 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1368717663.34.0.311761456371.issue15758@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I have done an updated patch. It no longer special cases Windows, so realloc() is always used for enlarging the buffer (except when fstat() is missing). Antoine, do you think this is ready to commit? ---------- Added file: http://bugs.python.org/file30287/readall.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 17:21:16 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 16 May 2013 15:21:16 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1368717676.98.0.167718921198.issue15758@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Removed file: http://bugs.python.org/file26986/readall-benchmark.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 17:21:50 2013 From: report at bugs.python.org (Jeffrey C. Jacobs) Date: Thu, 16 May 2013 15:21:50 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368717710.23.0.880293566085.issue17980@psf.upfronthosting.co.za> Changes by Jeffrey C. Jacobs : ---------- nosy: +timehorse _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 17:42:51 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 16 May 2013 15:42:51 +0000 Subject: [issue17222] py_compile.compile() explicitly sets st_mode for written files In-Reply-To: <1361136224.16.0.490340842207.issue17222@psf.upfronthosting.co.za> Message-ID: <1368718971.11.0.923032855294.issue17222@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 17:57:16 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 16 May 2013 15:57:16 +0000 Subject: [issue17222] py_compile.compile() explicitly sets st_mode for written files In-Reply-To: <1361136224.16.0.490340842207.issue17222@psf.upfronthosting.co.za> Message-ID: <1368719836.69.0.808830831928.issue17222@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Antoine says: > Ah, right. Well, there would be an argument not to use os.replace() in > py_compile, since it's an offline processing step which generally > shouldn't race with another (online) processing step. But I think that's not necessarily true. http://mail.python.org/pipermail/python-dev/2013-May/126241.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 18:56:22 2013 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 16 May 2013 16:56:22 +0000 Subject: [issue17981] SysLogHandler closes connection before using it In-Reply-To: <1368625795.57.0.786028186823.issue17981@psf.upfronthosting.co.za> Message-ID: <1368723382.33.0.362296905233.issue17981@psf.upfronthosting.co.za> Vinay Sajip added the comment: I see what you're saying now, but there's no explicit close in logging, so it's coming from somewhere lower down. Let's examine what happens when we try to emit the record: -> def emit(self, record): (Pdb) > /usr/lib/python2.7/logging/handlers.py(791)emit() -> msg = self.format(record) + '\000' (Pdb) n > /usr/lib/python2.7/logging/handlers.py(796)emit() -> prio = '<%d>' % self.encodePriority(self.facility, (Pdb) n > /usr/lib/python2.7/logging/handlers.py(797)emit() -> self.mapPriority(record.levelname)) (Pdb) n > /usr/lib/python2.7/logging/handlers.py(799)emit() -> if type(msg) is unicode: (Pdb) n > /usr/lib/python2.7/logging/handlers.py(803)emit() -> msg = prio + msg (Pdb) n > /usr/lib/python2.7/logging/handlers.py(804)emit() -> try: (Pdb) p msg '<14>world!\x00' (Pdb) n > /usr/lib/python2.7/logging/handlers.py(805)emit() -> if self.unixsocket: (Pdb) n > /usr/lib/python2.7/logging/handlers.py(806)emit() -> try: (Pdb) n > /usr/lib/python2.7/logging/handlers.py(807)emit() ============================================================== Here is where we try to send the message ============================================================== -> self.socket.send(msg) (Pdb) n error: (9, 'Bad file descriptor') > /usr/lib/python2.7/logging/handlers.py(807)emit() -> self.socket.send(msg) (Pdb) s > /usr/lib/python2.7/logging/handlers.py(808)emit() ============================================================== It failed, as expected, so we go to the exception handler. ============================================================== -> except socket.error: (Pdb) > /usr/lib/python2.7/logging/handlers.py(809)emit() ============================================================== We are going to try and connect again. ============================================================== -> self._connect_unixsocket(self.address) (Pdb) s --Call-- > /usr/lib/python2.7/logging/handlers.py(737)_connect_unixsocket() -> def _connect_unixsocket(self, address): (Pdb) > /usr/lib/python2.7/logging/handlers.py(738)_connect_unixsocket() -> self.socket = socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM) ============================================================== Created the socket at line 738. Line 739 is a comment. ============================================================== (Pdb) n > /usr/lib/python2.7/logging/handlers.py(740)_connect_unixsocket() -> try: (Pdb) n > /usr/lib/python2.7/logging/handlers.py(741)_connect_unixsocket() -> self.socket.connect(address) (Pdb) n error: (9, 'Bad file descriptor') ============================================================== Line 740 is a try: statement. At line 741, called connect, got an EBADF, and there's no intervening call to close(). ============================================================== > /usr/lib/python2.7/logging/handlers.py(741)_connect_unixsocket() -> self.socket.connect(address) (Pdb) n > /usr/lib/python2.7/logging/handlers.py(742)_connect_unixsocket() -> except socket.error: (Pdb) n > /usr/lib/python2.7/logging/handlers.py(743)_connect_unixsocket() -> self.socket.close() ============================================================== This close is just trying to tidy up in the exception handler. ============================================================== (Pdb) n > /usr/lib/python2.7/logging/handlers.py(744)_connect_unixsocket() -> self.socket = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) ============================================================== We'll try to open using TCP, which will fail. ============================================================== To summarise: line 738 is a call to socket.socket(AF_UNIX, SOCK_DGRAM) line 739 is a comment "# syslog may require either ..." line 740 is a try: line 741 is a call to socket.connect(address) There is no close() called by logging between socket.socket() and socket.connect(), so the close seems to be coming from inside one of those two calls to the socket module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 19:03:53 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 May 2013 17:03:53 +0000 Subject: [issue17732] distutils.cfg Can Break venv In-Reply-To: <1365963032.26.0.766714843383.issue17732@psf.upfronthosting.co.za> Message-ID: <3bBJr8526Jz7LrQ@mail.python.org> Roundup Robot added the comment: New changeset d62f71bd2192 by Brian Curtin in branch '3.3': Add Nick Sloan for his contribution to #17732 http://hg.python.org/cpython/rev/d62f71bd2192 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 19:06:25 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 16 May 2013 17:06:25 +0000 Subject: [issue17222] py_compile.compile() explicitly sets st_mode for written files In-Reply-To: <1368719836.69.0.808830831928.issue17222@psf.upfronthosting.co.za> Message-ID: <1368723982.2625.0.camel@fsol> Antoine Pitrou added the comment: > > Ah, right. Well, there would be an argument not to use os.replace() in > > py_compile, since it's an offline processing step which generally > > shouldn't race with another (online) processing step. > > But I think that's not necessarily true. > > http://mail.python.org/pipermail/python-dev/2013-May/126241.html Ha :) Then you know which kind of patch you have to try. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 19:14:57 2013 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 16 May 2013 17:14:57 +0000 Subject: [issue17981] SysLogHandler closes connection before using it In-Reply-To: <1368625795.57.0.786028186823.issue17981@psf.upfronthosting.co.za> Message-ID: <1368724497.64.0.5140872838.issue17981@psf.upfronthosting.co.za> Vinay Sajip added the comment: We'll try this with a simple script which doesn't use logging at all: import os import socket MSG1 = '<14>Hi, \x00' MSG2 = '<14>there!\x00' sock = socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM) sock.connect('/dev/log') sock.send(MSG1) os.close(sock.fileno()) # what daemonizing does try: sock.send(MSG2) except socket.error as e: print(e) print('Trying to reconnect:') sock = socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM) try: sock.connect('/dev/log') except socket.error as e: print('Oh look, reconnecting failed: %s' % e) When we run this, we get: [Errno 9] Bad file descriptor Trying to reconnect: Oh look, reconnecting failed: [Errno 9] Bad file descriptor And the strace output looks like this: socket(PF_FILE, SOCK_DGRAM, 0) = 3 connect(3, {sa_family=AF_FILE, path="/dev/log"}, 10) = 0 sendto(3, "<14>Hi, \0", 9, 0, NULL, 0) = 9 =================================================== The next close() is the os.close(sock.fileno()) =================================================== close(3) = 0 sendto(3, "<14>there!\0", 11, 0, NULL, 0) = -1 EBADF (Bad file descriptor) fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0), ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc4a90e5000 write(1, "[Errno 9] Bad file descriptor\n", 30) = 30 write(1, "Trying to reconnect:\n", 21) = 21 socket(PF_FILE, SOCK_DGRAM, 0) = 3 =================================================== Created the socket via a call to socket.socket(). =================================================== close(3) = 0 =================================================== No idea where this close() comes from, but it's the same as in the logging case. =================================================== connect(3, {sa_family=AF_FILE, path="/dev/log"}, 10) = -1 EBADF (Bad file descriptor) =================================================== connect() fails, just as in the logging case. =================================================== write(1, "Oh look, reconnecting failed: [E"..., 60) = 60 So, while it seems to be a bug, it's not a logging bug. It seems to be connected to the fact that os.close() closes the socket fd out from under the socket object, which somehow then causes a close() to be called... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 19:29:40 2013 From: report at bugs.python.org (Nobody/Anonymous) Date: Thu, 16 May 2013 17:29:40 +0000 Subject: =?utf-8?b?W2lzc3VlMTc5OTVdIHJlcG9ydO+8jOS4reOAgOmrmOOAgOWxguOAgOeuoQ==?= =?utf-8?b?44CA55CG44CA5oqA44CA6IO9MTU4NzY2?= Message-ID: <1368725380.5.0.946016872176.issueNone@psf.upfronthosting.co.za> New submission from Nobody/Anonymous: report???? $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 158766? ? ? ? 6 ? ?158766 5?18-19? ? ? 05?25-26? ? ? 6?08-09? ? ? ?????????????????????????????????? $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ 2013-05-1701:29:41 ---------- messages: 189390 nosy: nobody priority: normal severity: normal status: open title: report??????????????158766 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 19:39:47 2013 From: report at bugs.python.org (Tim Peters) Date: Thu, 16 May 2013 17:39:47 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368725987.68.0.61040130883.issue17980@psf.upfronthosting.co.za> Tim Peters added the comment: Wildcard matching can easily be done in worst-case linear time, but not with regexps. doctest.py's internal _ellipsis_match() shows one way to do it (doctest can use "..." as a wildcard marker). ---------- nosy: +tim_one _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 19:45:10 2013 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Thu, 16 May 2013 17:45:10 +0000 Subject: =?utf-8?b?W2lzc3VlMTc5OTVdIHJlcG9ydO+8jOS4reOAgOmrmOOAgOWxguOAgOeuoQ==?= =?utf-8?b?44CA55CG44CA5oqA44CA6IO9MTU4NzY2?= In-Reply-To: <1368725380.5.0.946016872176.issueNone@psf.upfronthosting.co.za> Message-ID: <1368726310.29.0.488670661477.issue17995@psf.upfronthosting.co.za> Changes by Fred L. Drake, Jr. : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 19:55:31 2013 From: report at bugs.python.org (jan matejek) Date: Thu, 16 May 2013 17:55:31 +0000 Subject: [issue17928] PowerLinux getargs.c FETCH_SIZE endianness bug In-Reply-To: <1367951362.08.0.951682363124.issue17928@psf.upfronthosting.co.za> Message-ID: <1368726931.02.0.553963772033.issue17928@psf.upfronthosting.co.za> jan matejek added the comment: The fix causes regression on my 64bit little-endian machine. It seems that while parsing the arguments, the length value overwrites part of the string pointer. ---------- nosy: +matejcik _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 19:57:20 2013 From: report at bugs.python.org (Georg Brandl) Date: Thu, 16 May 2013 17:57:20 +0000 Subject: [issue17732] distutils.cfg Can Break venv In-Reply-To: <1365963032.26.0.766714843383.issue17732@psf.upfronthosting.co.za> Message-ID: <1368727040.17.0.832013411962.issue17732@psf.upfronthosting.co.za> Georg Brandl added the comment: Thanks for the attribution, that was definitely an oversight on my part. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 20:00:09 2013 From: report at bugs.python.org (Georg Brandl) Date: Thu, 16 May 2013 18:00:09 +0000 Subject: [issue17943] AttributeError: 'long' object has no attribute 'release' in Queue.put() In-Reply-To: <1368080019.56.0.453263213436.issue17943@psf.upfronthosting.co.za> Message-ID: <1368727209.56.0.190687674696.issue17943@psf.upfronthosting.co.za> Georg Brandl added the comment: We've now found a wrongful section in C code releasing the GIL in spite of calling Python malloc functions, and I'm going to blame this failure on that. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 20:05:04 2013 From: report at bugs.python.org (jan matejek) Date: Thu, 16 May 2013 18:05:04 +0000 Subject: [issue17928] PowerLinux getargs.c FETCH_SIZE endianness bug In-Reply-To: <1367951362.08.0.951682363124.issue17928@psf.upfronthosting.co.za> Message-ID: <1368727504.25.0.467057575568.issue17928@psf.upfronthosting.co.za> jan matejek added the comment: hmm, but it's caused by a private patch claiming that _testcapimodule.c is PY_SSIZE_T_CLEAN. sorry for the noise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 20:10:43 2013 From: report at bugs.python.org (Christian Heimes) Date: Thu, 16 May 2013 18:10:43 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368727843.45.0.423431320341.issue17980@psf.upfronthosting.co.za> Christian Heimes added the comment: We could use an algorithm that doesn't need regexp for most cases. pseudo code: value = value.lower() hostname = hostname.lower() if '*' not in value: return value == hostname vparts = valuesplit(".") hparts = hostname.split(".") if len(vparts) != len(hparts): # * doesn't match a dot return False for v, h in zip(vparts, hparts): if v == "*": # match any host part continue asterisk = v.count("*") if asterisk == 0: if v != h: return False elif asterisk == 1: # match with simple re else: # don't support more than one * in a FQDN part raise TooManyAsterisk ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 20:12:10 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 16 May 2013 18:12:10 +0000 Subject: [issue17981] SysLogHandler closes connection before using it In-Reply-To: <1368625795.57.0.786028186823.issue17981@psf.upfronthosting.co.za> Message-ID: <1368727930.16.0.596759921322.issue17981@psf.upfronthosting.co.za> Richard Oudkerk added the comment: The line sock = socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM) overwrites the old broken socket with a new one with the same fd. The old socket's destructor closes the fd of the new socket. ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 20:13:19 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 16 May 2013 18:13:19 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368725987.68.0.61040130883.issue17980@psf.upfronthosting.co.za> Message-ID: <1368727996.2527.0.camel@fsol> Antoine Pitrou added the comment: > Wildcard matching can easily be done in worst-case linear time, but > not with regexps. doctest.py's internal _ellipsis_match() shows one > way to do it (doctest can use "..." as a wildcard marker). Thanks, this may be a nice enhancement for 3.4. For 3.2 and 3.3, I'd prefer to go the safe way of simply limiting the number of wildcards. If OpenSSL only accepts one per fragment, accepting one or two is certainly fine for Python as well :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 20:34:26 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 16 May 2013 18:34:26 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368729266.16.0.523820896617.issue17980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch allowing at most 2 wildcards per domain fragment. Georg, do you think this should go into 3.2? ---------- keywords: +patch nosy: +georg.brandl Added file: http://bugs.python.org/file30288/ssl_wildcard_dos.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 20:35:49 2013 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 16 May 2013 18:35:49 +0000 Subject: [issue17981] SysLogHandler closes connection before using it In-Reply-To: <1368625795.57.0.786028186823.issue17981@psf.upfronthosting.co.za> Message-ID: <1368729349.95.0.66851530572.issue17981@psf.upfronthosting.co.za> Vinay Sajip added the comment: > The old socket's destructor closes the fd of the new socket. Aha! Nice one. But what's the correct fix? I suppose a self.sock = None before every self.sock = socket.socket call would fix seem this, and while I can certainly make this change in SysLogHandler, isn't this a more general problem? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 20:43:27 2013 From: report at bugs.python.org (W. Owen Parry) Date: Thu, 16 May 2013 18:43:27 +0000 Subject: [issue17545] os.listdir and os.path.join inconsistent on empty path In-Reply-To: <1364228813.43.0.916487849633.issue17545@psf.upfronthosting.co.za> Message-ID: <1368729807.41.0.22163186635.issue17545@psf.upfronthosting.co.za> W. Owen Parry added the comment: I started working on a patch for this, but the more I think about it the less I am convinced it is wanted. The issue requests that os.listdir('') be equal to os.listdir('.') The given example of os.path.join doesn't follow this: >>> os.path.join('','aaa') 'aaa' >>> os.path.join('.','aaa') '.\\aaa' This makes sense: prepending an empty path should be a no-op, while prepending the current directory has a different meaning. It seems consistent in this case that listing an empty path and listing the current directory should have different meanings. Is there any other traction/use case for this change? ---------- nosy: +woparry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 20:45:01 2013 From: report at bugs.python.org (Georg Brandl) Date: Thu, 16 May 2013 18:45:01 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368729901.17.0.329433384559.issue17980@psf.upfronthosting.co.za> Georg Brandl added the comment: It's certainly a security fix, but probably not one that warrants an immediate release. If you commit it to the 3.2 branch, that's fine, it will get picked up by coming releases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 21:17:31 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 16 May 2013 19:17:31 +0000 Subject: [issue17981] SysLogHandler closes connection before using it In-Reply-To: <1368625795.57.0.786028186823.issue17981@psf.upfronthosting.co.za> Message-ID: <1368731851.26.0.104781188296.issue17981@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Rather than self.sock = None I would do self.sock.close() which should work better for non-refcounted Pythons. Of course it would be better to do this immediately after forking (i.e. before any more fds are created), otherwise you could still accidentally zap the fd of some other object. If you can't do this immediately after forking then maybe it is better to move inherited potentially broken objects to a garbage list to prevent garbage collection. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 22:20:45 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 May 2013 20:20:45 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368735645.39.0.974630524243.issue17980@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 22:27:00 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 May 2013 20:27:00 +0000 Subject: [issue17964] os.sysconf(): return type of the C function sysconf() is long, not int In-Reply-To: <1368403116.83.0.700816018997.issue17964@psf.upfronthosting.co.za> Message-ID: <3bBPLW5bwLz7LjW@mail.python.org> Roundup Robot added the comment: New changeset 7c60cf756097 by Victor Stinner in branch 'default': Issue #17964: Fix os.sysconf(): the return type of the C sysconf() function http://hg.python.org/cpython/rev/7c60cf756097 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 22:27:53 2013 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 16 May 2013 20:27:53 +0000 Subject: [issue1662581] the re module can perform poorly: O(2**n) versus O(n**2) Message-ID: <1368736073.89.0.757133461743.issue1662581@psf.upfronthosting.co.za> Gregory P. Smith added the comment: The recommendation for anyone using regular expressions on hostile input is to (a) don't do that. (b) use a better regexp without this possible behavior and (c) use something like re2 (there's a Python binding at https://github.com/axiak/pyre2) which is a regular expression engine that this cannot happen to. fixing this within python requires a complete rewrite and replacement of the re module with one that uses a different approach. see the other work on the MRAB regex module and discussion surrounding that. that is a non trivial task and it is fixing other more important things (unicode correctness!) than this... Given that, I don't actually expect this issue to ever be fixed. IMNSHO: People shouldn't abuse regexes and get themselves into this situation in the first place. ;) discussion should really happen on python-ideas. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 22:28:42 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 May 2013 20:28:42 +0000 Subject: [issue17964] os.sysconf(): return type of the C function sysconf() is long, not int In-Reply-To: <1368403116.83.0.700816018997.issue17964@psf.upfronthosting.co.za> Message-ID: <1368736122.15.0.458102299386.issue17964@psf.upfronthosting.co.za> STINNER Victor added the comment: The bug does also exist in Python 2.7, 3.2 and 3.3, but I prefer to not fix it in these versions because I'm not 100% sure that the return type is long on all platforms and because nobody noticed the issue since years. So if I broke something, I prefer to only break the development branch ;-) I applied the fix to Python 3.4 and so I'm closing the issue. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 22:29:17 2013 From: report at bugs.python.org (Gregory P. Smith) Date: Thu, 16 May 2013 20:29:17 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368736157.74.0.382111620791.issue17980@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Indeed, doing this _without a regexp_ is preferred. :) ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 22:31:00 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 16 May 2013 20:31:00 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1368736260.3.0.508972262756.issue15758@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I posted a couple of review comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 22:36:42 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 May 2013 20:36:42 +0000 Subject: [issue17700] Update Curses HOWTO for 3.4 In-Reply-To: <1365719687.97.0.644773548697.issue17700@psf.upfronthosting.co.za> Message-ID: <1368736602.07.0.802271897182.issue17700@psf.upfronthosting.co.za> STINNER Victor added the comment: > Applied to 3.3 and 3.4. I'll leave this issue open > for a week so that Victor can comment on Unicode/wide-characters. I don't know (n)curses, but I tried to improve the curses module of Python. I added an encoding attribute which is the locale encoding by default, so it should work without special configuration. But it's good to know what the default encoding is. (It was UTF-8 on older Python 3 release, maybe in Python < 3.3.) I also added functions like unget_wch() and get_wch(). The problem is that unget_wch() and get_wch() are not always available, it depends on the platform. If I remember correctly, it depends if libreadline is linked to libncursesw (and not libncurses). Ah yes, and the Python curses modules uses Unicode versions of C curses functions if available. It is still possible to use thes bytes versions if you pass bytes strings. For example: * window.addstr("abc"): use *add_wstr() functions if available, *addstr() otherwise * window.addstr(b"abc"): always use *addstr() functions I don't know enough the C libncursesw library to write an HOWTO or something like that. I just would like to say that you should prefer get_wch() over getch() if get_wch() is available. But I don't understand exactly how curses behave with control characters ("keys"?) like "up" or "left". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 22:53:50 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 May 2013 20:53:50 +0000 Subject: [issue17931] PyLong_FromPid() is not correctly defined on Windows 64-bit In-Reply-To: <1367964709.89.0.899001899577.issue17931@psf.upfronthosting.co.za> Message-ID: <1368737630.41.0.150414173372.issue17931@psf.upfronthosting.co.za> STINNER Victor added the comment: @Antoine (author of the commit fixing #1983): any opinion? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 22:56:07 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 16 May 2013 20:56:07 +0000 Subject: [issue17931] PyLong_FromPid() is not correctly defined on Windows 64-bit In-Reply-To: <1367964709.89.0.899001899577.issue17931@psf.upfronthosting.co.za> Message-ID: <1368737767.36.0.418047634195.issue17931@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Sounds fine to me, but perhaps better test the patch before committing? (or wait for the buildbots to crash) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 22:58:10 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 May 2013 20:58:10 +0000 Subject: [issue17917] use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() when applicable In-Reply-To: <1367845837.62.0.789153792923.issue17917@psf.upfronthosting.co.za> Message-ID: <1368737890.73.0.259227268373.issue17917@psf.upfronthosting.co.za> STINNER Victor added the comment: ins_macro-2.diff looks good to me, go ahead! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 23:23:55 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 May 2013 21:23:55 +0000 Subject: [issue17952] editors-and-tools section of devguide does not appear to be accurate In-Reply-To: <1368258352.41.0.175036203954.issue17952@psf.upfronthosting.co.za> Message-ID: <3bBQcB4g4qz7LjS@mail.python.org> Roundup Robot added the comment: New changeset 3d523f0c0a9d by Ned Deily in branch 'default': Add comment about avoiding --enable-shared for uninstalled builds. This should also cause the resources ref link in the Editors and Tools section to be updated (Issue17952). http://hg.python.org/devguide/rev/3d523f0c0a9d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 23:23:58 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 May 2013 21:23:58 +0000 Subject: [issue17931] PyLong_FromPid() is not correctly defined on Windows 64-bit In-Reply-To: <1367964709.89.0.899001899577.issue17931@psf.upfronthosting.co.za> Message-ID: <1368739438.87.0.628380015514.issue17931@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, I just noticed the following check in pyport.h: #if SIZEOF_PID_T > SIZEOF_LONG # error "Python doesn't support sizeof(pid_t) > sizeof(long)" #endif I don't understand this test, longobject.h contains: #elif defined(SIZEOF_LONG_LONG) && SIZEOF_PID_T == SIZEOF_LONG_LONG #define _Py_PARSE_PID "L" #define PyLong_FromPid PyLong_FromLongLong #define PyLong_AsPid PyLong_AsLongLong I suppose that this path was never tested before. Here is a new patch removing the check from pyport.h, longobject.h already fails if SIZEOF_PID_T value is not supported: #else #error "sizeof(pid_t) is neither sizeof(int), sizeof(long) or sizeof(long long)" #endif /* SIZEOF_PID_T */ ---------- Added file: http://bugs.python.org/file30289/win_sizeof_pid_t-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 23:26:58 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 May 2013 21:26:58 +0000 Subject: [issue17742] Add _PyBytesWriter API In-Reply-To: <1366063415.31.0.505871872027.issue17742@psf.upfronthosting.co.za> Message-ID: <1368739618.91.0.166598377999.issue17742@psf.upfronthosting.co.za> STINNER Victor added the comment: _PyBytesWriter API makes the code slower and does not really reduce the number of lines, so I'm closing this issue as invalid. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 16 23:34:09 2013 From: report at bugs.python.org (Ned Deily) Date: Thu, 16 May 2013 21:34:09 +0000 Subject: [issue17952] editors-and-tools section of devguide does not appear to be accurate In-Reply-To: <1368258352.41.0.175036203954.issue17952@psf.upfronthosting.co.za> Message-ID: <1368740049.56.0.86009923499.issue17952@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the report. To resolve Issue17820, the target of the link in setup#editors-and-tools was changed from the "Key Resources" section to the "Additional Resources" section. However, because the "setup" page itself was not modified, it was not automatically rebuilt and the old section name remained. I added an unrelated change to the setup page to cause the page to be regenerated; it now shows the correct section name in the link. ---------- nosy: +ned.deily resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 00:03:12 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 16 May 2013 22:03:12 +0000 Subject: [issue17981] SysLogHandler closes connection before using it In-Reply-To: <1368625795.57.0.786028186823.issue17981@psf.upfronthosting.co.za> Message-ID: <3bBRTW6bjnz7LjM@mail.python.org> Roundup Robot added the comment: New changeset d91da96a55bf by Vinay Sajip in branch '2.7': Issue #17981: Closed socket on error in SysLogHandler. http://hg.python.org/cpython/rev/d91da96a55bf New changeset 590b865aa73c by Vinay Sajip in branch '3.3': Issue #17981: Closed socket on error in SysLogHandler. http://hg.python.org/cpython/rev/590b865aa73c New changeset f2809c7a7c3c by Vinay Sajip in branch 'default': Closes #17981: Merged fix from 3.3. http://hg.python.org/cpython/rev/f2809c7a7c3c ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 00:15:31 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 16 May 2013 22:15:31 +0000 Subject: [issue17870] Python does not provide PyLong_FromIntMax_t() or PyLong_FromUintMax_t() function In-Reply-To: <1367269025.02.0.400879045482.issue17870@psf.upfronthosting.co.za> Message-ID: <1368742531.14.0.705777053152.issue17870@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, the sqlite3 module has an interesting function: PyObject * _pysqlite_long_from_int64(sqlite_int64 value) { #ifdef HAVE_LONG_LONG # if SIZEOF_LONG_LONG < 8 if (value > PY_LLONG_MAX || value < PY_LLONG_MIN) { return _PyLong_FromByteArray(&value, sizeof(value), IS_LITTLE_ENDIAN, 1 /* signed */); } # endif # if SIZEOF_LONG < SIZEOF_LONG_LONG if (value > LONG_MAX || value < LONG_MIN) return PyLong_FromLongLong(value); # endif #else # if SIZEOF_LONG < 8 if (value > LONG_MAX || value < LONG_MIN) { return _PyLong_FromByteArray(&value, sizeof(value), IS_LITTLE_ENDIAN, 1 /* signed */); } # endif #endif return PyLong_FromLong(value); } If PyLong_FromIntMax_t() is implemented, this function may be simply removed (and replaced with PyLong_FromIntMax_t). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 03:02:20 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 17 May 2013 01:02:20 +0000 Subject: [issue9566] Compilation warnings under x64 Windows In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za> Message-ID: <1368752539.99.0.465436306403.issue9566@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +terry.reedy priority: low -> normal stage: -> patch review versions: +Python 3.3, Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 03:09:43 2013 From: report at bugs.python.org (Christian Heimes) Date: Fri, 17 May 2013 01:09:43 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368752983.7.0.787778109525.issue17980@psf.upfronthosting.co.za> Christian Heimes added the comment: Are multiple wildcards per fragment even specified? I'm unable to find information if the wildcard is supposed to be a greedy or a non-greedy match. By the way Chromium does more fancy checks. For example it requires * to match at least on character and it does special handling of IDN. X509Certificate::VerifyHostname() around line 500. http://src.chromium.org/viewvc/chrome/trunk/src/net/cert/x509_certificate.cc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 04:20:43 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 17 May 2013 02:20:43 +0000 Subject: [issue17996] socket module should expose AF_LINK Message-ID: <1368757243.4.0.421622185164.issue17996@psf.upfronthosting.co.za> New submission from Giampaolo Rodola': I bumped into this while exposing getifaddrs() [1] in psutil: https://code.google.com/p/psutil/issues/detail?id=376 In that case AF_LINK would be useful to distinguish MAC addresses (see also: http://carnivore.it/2010/07/22/python_-_getifaddrs). [1] http://man7.org/linux/man-pages/man3/getifaddrs.3.html ---------- messages: 189420 nosy: giampaolo.rodola, pitrou priority: normal severity: normal status: open title: socket module should expose AF_LINK versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 07:22:22 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 May 2013 05:22:22 +0000 Subject: [issue9566] Compilation warnings under x64 Windows In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za> Message-ID: <1368768142.35.0.40042412982.issue9566@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Just a note: Today I got warnings for 4 or 5 files when compiling with VC express (32 bit) on 64-bit Win 7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 07:53:22 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 17 May 2013 05:53:22 +0000 Subject: [issue17996] socket module should expose AF_LINK In-Reply-To: <1368757243.4.0.421622185164.issue17996@psf.upfronthosting.co.za> Message-ID: <1368770002.94.0.319523373432.issue17996@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 08:39:53 2013 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Fri, 17 May 2013 06:39:53 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368772793.21.0.929794888371.issue17980@psf.upfronthosting.co.za> Changes by Bohuslav "Slavek" Kabrda : ---------- nosy: +bkabrda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 09:12:36 2013 From: report at bugs.python.org (Armin Rigo) Date: Fri, 17 May 2013 07:12:36 +0000 Subject: [issue17222] py_compile.compile() explicitly sets st_mode for written files In-Reply-To: <1361136224.16.0.490340842207.issue17222@psf.upfronthosting.co.za> Message-ID: <1368774756.04.0.880255797818.issue17222@psf.upfronthosting.co.za> Armin Rigo added the comment: Can someone confirm the answer to Arfrever's original question: a seemingly innocent use case of py_compile.compile(), which works fine until Python 3.3, when executed as root, can in Python 3.4 fundamentally break down a complete Posix system in a non-obvious way? ---------- nosy: +arigo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 09:15:05 2013 From: report at bugs.python.org (zhaoqifa) Date: Fri, 17 May 2013 07:15:05 +0000 Subject: [issue17967] urllib2.open failed to access a url when a perent directory of the url is permission denied In-Reply-To: <1368424209.99.0.52540499369.issue17967@psf.upfronthosting.co.za> Message-ID: <1368774905.51.0.257254486843.issue17967@psf.upfronthosting.co.za> zhaoqifa added the comment: I had run test by python ./urllib.py -t, test steps for accessing /etc/passwd, file:/etc/passwd, file://localhost/etc/passwd passed, steps for ftp://ftp.gnu.org/pub/README not tested because my work env is not free for internet accessing. And, I have not tried version 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 09:19:36 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 May 2013 07:19:36 +0000 Subject: [issue17993] Missed comma causes unintentional implicit string literal concatenation In-Reply-To: <1368688732.05.0.0592357298734.issue17993@psf.upfronthosting.co.za> Message-ID: <1368775176.96.0.0586649737651.issue17993@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I haven't found any similar bugs, but I have found other bug in Tools/scripts/abitype.py. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 09:21:30 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 May 2013 07:21:30 +0000 Subject: [issue17993] Missed comma causes unintentional implicit string literal concatenation In-Reply-To: <1368688732.05.0.0592357298734.issue17993@psf.upfronthosting.co.za> Message-ID: <1368775290.86.0.97236056758.issue17993@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, committed in changesets 26531f21bc4c and 27cc0e0b7637. ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 09:22:41 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 17 May 2013 07:22:41 +0000 Subject: [issue17222] py_compile.compile() explicitly sets st_mode for written files In-Reply-To: <1361136224.16.0.490340842207.issue17222@psf.upfronthosting.co.za> Message-ID: <1368775361.82.0.244361254106.issue17222@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Yes, the switch to renaming can change behaviour in some corner cases (I say "corner cases" because the expected situation is to have your pyc files be regular files, not symlinks or character devices). Python is certainly not the only application where you can bust /dev/null by specifying it as target location. Mutating a file in place is a source of unpredictable issues with concurrent access of the file being written to, which is why it was changed to renaming. I think the class of issues which was solved (presumably) is much more important than the use case of compiling to /dev/null. As for symlinks, I'd naively expect breaking symlinks to be a feature, but YMMV. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 09:30:32 2013 From: report at bugs.python.org (STINNER Victor) Date: Fri, 17 May 2013 07:30:32 +0000 Subject: [issue9566] Compilation warnings under x64 Windows In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za> Message-ID: <1368775832.79.0.569377301608.issue9566@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, I fixed some warnings yesterday, but I forgot this issue. changeset: 83802:ef5dd5bda323 user: Victor Stinner date: Fri May 17 00:12:04 2013 +0200 files: Python/getargs.c Python/traceback.c description: Fix compilater warnings on Windows 64-bit changeset: 83801:16a00dd78cd0 user: Victor Stinner date: Fri May 17 00:04:56 2013 +0200 files: Python/formatter_unicode.c description: Fix a compilater warning on Windows 64-bit changeset: 83800:e5dc97fb304d user: Victor Stinner date: Thu May 16 23:48:01 2013 +0200 files: Python/ceval.c description: Fix a compilater warning on Windows 64-bit idx variable is used for a tuple indexn so use Py_ssize_t (not int). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 09:48:29 2013 From: report at bugs.python.org (Armin Rigo) Date: Fri, 17 May 2013 07:48:29 +0000 Subject: [issue17222] py_compile.compile() explicitly sets st_mode for written files In-Reply-To: <1361136224.16.0.490340842207.issue17222@psf.upfronthosting.co.za> Message-ID: <1368776909.51.0.310526955875.issue17222@psf.upfronthosting.co.za> Armin Rigo added the comment: My point is that in five years' time some existing well-tested sysadmin-like program will be run with Python 3.4 for the first time, and suddenly whole systems will break. I don't want to sound negative but this is the worst behavior ever (with the possible exception of programs that do bad things beyond your own system, like viruses). Please at least crash with an exception instead: add one easy check to py_compile.compile() and complain if cfile points to an existing non-regular file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 09:50:21 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 May 2013 07:50:21 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <3bBhW02flVz7Lmk@mail.python.org> Roundup Robot added the comment: New changeset 6707637f68ca by Serhiy Storchaka in branch 'default': Issue #14596: The struct.Struct() objects now use more compact implementation. http://hg.python.org/cpython/rev/6707637f68ca ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 09:51:18 2013 From: report at bugs.python.org (STINNER Victor) Date: Fri, 17 May 2013 07:51:18 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368777078.96.0.603443202196.issue17980@psf.upfronthosting.co.za> STINNER Victor added the comment: > Are multiple wildcards per fragment even specified? I don't know the standard, but it sounds strange to have more than one wildcard per part of an URL. "*.*.*.google.com" looks valid to me, whereas "*a*a*a*.google.com" looks very suspicious. Said differently, I expect: assert max(part.count("*") for part in url.split(".")) <= 1 "*" pattern is replace with '[^.]+' regex, so I may not cause the exponential complexity issue. (I didn't check.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 10:07:36 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 May 2013 08:07:36 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1368778056.47.0.211007321782.issue14596@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: We already lost this improvement for 3.3. :( Could we now close the issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 10:20:28 2013 From: report at bugs.python.org (Florian Weimer) Date: Fri, 17 May 2013 08:20:28 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368778828.83.0.836464500084.issue17980@psf.upfronthosting.co.za> Florian Weimer added the comment: > "*" pattern is replace with '[^.]+' regex, so I may not cause the exponential complexity issue. (I didn't check.) A possessive quantifier might also help, that is [^.]+?. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 11:21:27 2013 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 17 May 2013 09:21:27 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368782487.24.0.556986441816.issue17980@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: SSL certificate hostname matching is defined in RFC 2818: * http://www.ietf.org/rfc/rfc2818.txt It's not very verbose on how exactly matching should be done: """ Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com. """ Given that it's underspecified, I doubt that anyone using wildcards in certificates for valid purposes would risk using anything but very simply prefix/suffix matching - most certainly not any matching that would require backtracking to succeed. There are several variants out there of how the matching is done. See e.g. http://search-hadoop.com/c/Hadoop:hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/security/ssl/SSLHostnameVerifier.java||dns ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 11:23:16 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 17 May 2013 09:23:16 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368782596.37.0.813766361391.issue17980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Non-greedy matching actually makes things worse :-) $ ./python -m timeit -s "import re; pat = re.compile('\A*a*a*a\Z'.replace('*', '[^.]+'), re.IGNORECASE)" "pat.match('a' * 100 +'z')" 100 loops, best of 3: 3.31 msec per loop $ ./python -m timeit -s "import re; pat = re.compile('\A*a*a*a\Z'.replace('*', '[^.]+?'), re.IGNORECASE)" "pat.match('a' * 100 +'z')" 100 loops, best of 3: 6.91 msec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 11:32:55 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 17 May 2013 09:32:55 +0000 Subject: [issue17222] py_compile.compile() explicitly sets st_mode for written files In-Reply-To: <1361136224.16.0.490340842207.issue17222@psf.upfronthosting.co.za> Message-ID: <1368783175.22.0.0272976298936.issue17222@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: I fixed syntax sanity check in Portage (package manager in Gentoo) to avoid breaking system. This sanity check is always run during upgrade of Portage itself. http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commitdiff;h=e8d1337b5936ee058872d25f21b914e96bcbf677 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 11:34:22 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 17 May 2013 09:34:22 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368783262.92.0.365764905939.issue17980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Florian, I'm actually surprised by your assertion that OpenSSL supports a single wildcard character. Last I looked, I couldn't find any hostname matching function in OpenSSL (which is why I had to write our own). Could you point me to the relevant piece of code? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 11:40:18 2013 From: report at bugs.python.org (Florian Weimer) Date: Fri, 17 May 2013 09:40:18 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368783617.99.0.155882706474.issue17980@psf.upfronthosting.co.za> Florian Weimer added the comment: Antoine, support for OpenSSL host name matching is quite new: ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 11:43:05 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 17 May 2013 09:43:05 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368783785.86.0.697829695672.issue17980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: libcurl supports a single wildcard for the whole domain name pattern (not even one per fragment), as per lib/hostcheck.c (this is when linked against OpenSSL; when linked against GnuTLS, curl will use the GnuTLS-provided matching function) Based on all the evidence, I think allowing one wildcard per fragment is sufficient. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 11:44:36 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 17 May 2013 09:44:36 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368783876.32.0.374088907973.issue17980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Antoine, support for OpenSSL host name matching is quite new Ah, thanks. I was looking in 1.0.1e. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 11:48:47 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 17 May 2013 09:48:47 +0000 Subject: [issue14596] struct.unpack memory leak In-Reply-To: <1334578212.47.0.0704752159065.issue14596@psf.upfronthosting.co.za> Message-ID: <1368784127.02.0.057637630524.issue14596@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Closing indeed! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 11:50:45 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 17 May 2013 09:50:45 +0000 Subject: [issue17222] py_compile.compile() explicitly sets st_mode for written files In-Reply-To: <1368783175.22.0.0272976298936.issue17222@psf.upfronthosting.co.za> Message-ID: <170426978.7171364.1368784239395.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > I fixed syntax sanity check in Portage (package manager in Gentoo) to > avoid breaking system. This sanity check is always run during > upgrade of Portage itself. Well, we could add a dedicated function for sanity checking, then. ---------- title: py_compile.compile() explicitly sets st_mode for written files -> py_compile.compile() explicitly sets st_mode for written files _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 11:51:50 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 17 May 2013 09:51:50 +0000 Subject: [issue17222] py_compile.compile() explicitly sets st_mode for written files In-Reply-To: <1368776909.51.0.310526955875.issue17222@psf.upfronthosting.co.za> Message-ID: <61689337.7174072.1368784303961.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > Please at least crash with an exception instead: add > one easy check to py_compile.compile() and complain if cfile points > to an existing non-regular file. That's a good point (except that symlinks should probably be allowed too). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 11:58:19 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 17 May 2013 09:58:19 +0000 Subject: [issue17222] py_compile.compile() replaces target files, breaking special files and symlinks In-Reply-To: <1361136224.16.0.490340842207.issue17222@psf.upfronthosting.co.za> Message-ID: <1368784699.09.0.559913684548.issue17222@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- title: py_compile.compile() explicitly sets st_mode for written files -> py_compile.compile() replaces target files, breaking special files and symlinks _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 12:25:17 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 May 2013 10:25:17 +0000 Subject: [issue17563] Excessive resizing of dicts when used as a cache In-Reply-To: <1364420039.63.0.203772094216.issue17563@psf.upfronthosting.co.za> Message-ID: <3bBlxn07tfz7LjM@mail.python.org> Roundup Robot added the comment: New changeset cd2457463eeb by Raymond Hettinger in branch '3.3': Issue #17563: Fix dict resize performance regression. http://hg.python.org/cpython/rev/cd2457463eeb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 12:29:11 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 17 May 2013 10:29:11 +0000 Subject: [issue17563] Excessive resizing of dicts when used as a cache In-Reply-To: <1364420039.63.0.203772094216.issue17563@psf.upfronthosting.co.za> Message-ID: <1368786551.1.0.400032875035.issue17563@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 12:49:03 2013 From: report at bugs.python.org (Donald Stufft) Date: Fri, 17 May 2013 10:49:03 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368787743.95.0.169868802751.issue17947@psf.upfronthosting.co.za> Changes by Donald Stufft : ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 12:52:43 2013 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 17 May 2013 10:52:43 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368787963.76.0.320253281654.issue17980@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Here's another long discussions about SSL hostname matching that may provide some useful insights: * https://bugzilla.mozilla.org/show_bug.cgi?id=159483 Note how RFC 2595 doesn't even allow sub-string matching. It only allows '*' to be used as component. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 13:11:31 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 May 2013 11:11:31 +0000 Subject: [issue17979] Cannot build 2.7 with --enable-unicode=no In-Reply-To: <1368574020.99.0.834797445108.issue17979@psf.upfronthosting.co.za> Message-ID: <1368789091.92.0.492335098826.issue17979@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ubuntu 32-bit, gcc 4.6.3. The bug requires 64 bit. This patch should fix it. ---------- components: +Build, Extension Modules, Regular Expressions, Unicode keywords: +patch nosy: +mrabarnett stage: -> patch review Added file: http://bugs.python.org/file30290/re_nounicode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 13:19:39 2013 From: report at bugs.python.org (Donald Stufft) Date: Fri, 17 May 2013 11:19:39 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1368789579.9.0.458423505099.issue17947@psf.upfronthosting.co.za> Donald Stufft added the comment: Small nitpick, weakref is imported but not used in the latest patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 13:42:25 2013 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 17 May 2013 11:42:25 +0000 Subject: [issue17979] Cannot build 2.7 with --enable-unicode=no In-Reply-To: <1368789091.92.0.492335098826.issue17979@psf.upfronthosting.co.za> Message-ID: <5196179A.5050002@egenix.com> Marc-Andre Lemburg added the comment: On 17.05.2013 13:11, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > Ubuntu 32-bit, gcc 4.6.3. The bug requires 64 bit. > > This patch should fix it. int and long are the same size on Linux 64-bit platforms. You probably want to use "short" instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 13:47:26 2013 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 17 May 2013 11:47:26 +0000 Subject: [issue17979] Cannot build 2.7 with --enable-unicode=no In-Reply-To: <5196179A.5050002@egenix.com> Message-ID: <519618C4.7000006@egenix.com> Marc-Andre Lemburg added the comment: On 17.05.2013 13:42, Marc-Andre Lemburg wrote: > > Marc-Andre Lemburg added the comment: > > On 17.05.2013 13:11, Serhiy Storchaka wrote: >> >> Serhiy Storchaka added the comment: >> >> Ubuntu 32-bit, gcc 4.6.3. The bug requires 64 bit. >> >> This patch should fix it. > > int and long are the same size on Linux 64-bit platforms. Sorry, scratch that. It's the same on Windows x64, not Linux x64. > You probably want to use "short" instead. This should still be safer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 14:19:16 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 May 2013 12:19:16 +0000 Subject: [issue17979] Cannot build 2.7 with --enable-unicode=no In-Reply-To: <1368574020.99.0.834797445108.issue17979@psf.upfronthosting.co.za> Message-ID: <1368793156.56.0.500650950933.issue17979@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: SRE_CODE should be at least 32-bit for support of long regexpes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 14:34:12 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 17 May 2013 12:34:12 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1368794052.92.0.929929749703.issue15758@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Updated patch adressing Antoine's comments. ---------- Added file: http://bugs.python.org/file30291/readall.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 14:34:18 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 17 May 2013 12:34:18 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1368794058.67.0.461256974015.issue15758@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Removed file: http://bugs.python.org/file30287/readall.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 14:34:24 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 17 May 2013 12:34:24 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1368794064.48.0.876336864746.issue15758@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Removed file: http://bugs.python.org/file26985/readall-combined.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 14:34:32 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 17 May 2013 12:34:32 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1368794072.33.0.336423046607.issue15758@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Added file: http://bugs.python.org/file26986/readall-benchmark.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 15:13:30 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 17 May 2013 13:13:30 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368796410.86.0.51617157243.issue17980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Attached patch forbidding more than one wildcard per fragment. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file30292/ssl_wildcard_dos2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 15:23:42 2013 From: report at bugs.python.org (Christian Heimes) Date: Fri, 17 May 2013 13:23:42 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368797022.27.0.578268936376.issue17980@psf.upfronthosting.co.za> Christian Heimes added the comment: I still think that sub string wildcard should not match the IDN "xn--" prefix. With current code the rules "x*.example.de" gives a positive match for "g?tter.example.de". >>> u"g?tter.example.de".encode("idna") 'xn--gtter-jua.example.de' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 15:36:56 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 17 May 2013 13:36:56 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368797022.27.0.578268936376.issue17980@psf.upfronthosting.co.za> Message-ID: <1493007068.7839264.1368797809224.JavaMail.root@zimbra10-e2.priv.proxad.net> Antoine Pitrou added the comment: > I still think that sub string wildcard should not match the IDN > "xn--" prefix. With current code the rules "x*.example.de" gives a > positive match for "g?tter.example.de". You should open a separate issue for this (possibly with a patch). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 16:04:53 2013 From: report at bugs.python.org (Christian Heimes) Date: Fri, 17 May 2013 14:04:53 +0000 Subject: [issue17997] ssl.match_hostname(): sub string wildcard should not match IDNA prefix Message-ID: <1368799493.86.0.504478450601.issue17997@psf.upfronthosting.co.za> New submission from Christian Heimes: Python's ssl.match_hostname() does sub string matching as specified in RFC 2818: Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com. The RFC doesn't specify how internationalized domain names shoould be handled because it predates RFC 5890 for IDNA by many year. IDNA are prefixed with "xn--", e.g. u"g?tter.example.de".encode("idna") == "xn--gtter-jua.example.de". This can result into false positive matches for a rule like "x*.example.de". Chrome has special handling for IDN prefix in X509Certificate::VerifyHostname() http://src.chromium.org/viewvc/chrome/trunk/src/net/cert/x509_certificate.cc Also see #17980 ---------- messages: 189454 nosy: christian.heimes, pitrou priority: critical severity: normal stage: needs patch status: open title: ssl.match_hostname(): sub string wildcard should not match IDNA prefix type: security versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 16:05:17 2013 From: report at bugs.python.org (Christian Heimes) Date: Fri, 17 May 2013 14:05:17 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368799517.85.0.859685615536.issue17980@psf.upfronthosting.co.za> Christian Heimes added the comment: #17997 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 16:09:26 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 17 May 2013 14:09:26 +0000 Subject: [issue17951] TypeError during gdb backtracing In-Reply-To: <1368228204.29.0.543705311064.issue17951@psf.upfronthosting.co.za> Message-ID: <1368799766.44.0.699173747904.issue17951@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for the report and patch. The next step required for this issue is for someone to write a unit test. ---------- keywords: +easy nosy: +r.david.murray stage: -> test needed versions: +Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 16:27:19 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 17 May 2013 14:27:19 +0000 Subject: [issue17965] argparse does not dest.replace('-', '_') for positionals In-Reply-To: <1368411809.58.0.522670485437.issue17965@psf.upfronthosting.co.za> Message-ID: <1368800839.62.0.223005690738.issue17965@psf.upfronthosting.co.za> R. David Murray added the comment: This is a duplicate of issue 15125. (FYI there are many many unix commands that use options of the form -XXX-YYYY. This is the standard for the gnu 'long option' format.) ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> argparse: positional arguments containing - in name not handled well _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 16:31:08 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 17 May 2013 14:31:08 +0000 Subject: [issue15125] argparse: positional arguments containing - in name not handled well In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za> Message-ID: <1368801068.62.0.44812260307.issue15125@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 16:42:34 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 17 May 2013 14:42:34 +0000 Subject: [issue17973] '+=' on a list inside tuple both succeeds and raises an exception In-Reply-To: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> Message-ID: <1368801754.54.0.444170440489.issue17973@psf.upfronthosting.co.za> R. David Murray added the comment: This gets reported periodically. I wonder if it is time for a FAQ entry. There doesn't seem to be one yet. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 16:48:40 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 17 May 2013 14:48:40 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1368802120.13.0.484006672354.issue15758@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Added file: http://bugs.python.org/file30293/readall.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 16:48:46 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 17 May 2013 14:48:46 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1368802126.54.0.502501817155.issue15758@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Removed file: http://bugs.python.org/file30291/readall.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 16:55:07 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 17 May 2013 14:55:07 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1368802507.55.0.642862225834.issue15758@psf.upfronthosting.co.za> Richard Oudkerk added the comment: New patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 17:07:03 2013 From: report at bugs.python.org (Alejandro Rodas) Date: Fri, 17 May 2013 15:07:03 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1368803223.22.0.39149992283.issue15392@psf.upfronthosting.co.za> Changes by Alejandro Rodas : ---------- nosy: +alex.rodas _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 17:07:14 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 17 May 2013 15:07:14 +0000 Subject: [issue17973] '+=' on a list inside tuple both succeeds and raises an exception In-Reply-To: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> Message-ID: <1368803234.1.0.19175144957.issue17973@psf.upfronthosting.co.za> Ronald Oussoren added the comment: You've got a point there. What about this patch (but then with proper english grammer)? BTW. Actually fixing this wart would be possible, but at a significant cost: you'd have to change the implementation of LHS += RHS from: tmp = LHS tmp = tmp.__iadd__(RHS) LHS = tmp to: tmp = LHS LHS = tmp tmp = tmp.__iadd__(RHS) LHS = tmp The odd assignment on the second line would detect that the LHS is immutable in 99+% of use cases before updating the RHS. My gut feeling is that an implementation of this would have too high a cost (both in runtime performance and in a more complicated compiler), although it would be interesting to actually see a patch. ---------- keywords: +patch Added file: http://bugs.python.org/file30294/faq-update.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 17:09:14 2013 From: report at bugs.python.org (Jeroen Demeyer) Date: Fri, 17 May 2013 15:09:14 +0000 Subject: [issue17998] internal error in regular expression engine Message-ID: <1368803354.84.0.768428094886.issue17998@psf.upfronthosting.co.za> New submission from Jeroen Demeyer: On Linux Ubuntu 13.04, i686: $ uname -a Linux arando 3.5.0-26-generic #42-Ubuntu SMP Fri Mar 8 23:20:06 UTC 2013 i686 i686 i686 GNU/Linux $ python Python 2.7.5 (default, May 17 2013, 18:43:24) [GCC 4.7.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> re.compile('(.*)\.[0-9]*\.[0-9]*$', re.I|re.S).findall('3.0.0') Traceback (most recent call last): File "", line 1, in RuntimeError: internal error in regular expression engine This is a 2.7.5 regression, 2.7.4 worked fine. ---------- components: Library (Lib) messages: 189461 nosy: jdemeyer priority: normal severity: normal status: open title: internal error in regular expression engine versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 17:10:09 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 17 May 2013 15:10:09 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1368803409.34.0.114260887794.issue15758@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Added file: http://bugs.python.org/file30295/readall.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 17:10:15 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Fri, 17 May 2013 15:10:15 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1368803415.68.0.658321702282.issue15758@psf.upfronthosting.co.za> Changes by Richard Oudkerk : Removed file: http://bugs.python.org/file30293/readall.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 17:15:11 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 17 May 2013 15:15:11 +0000 Subject: [issue17998] internal error in regular expression engine In-Reply-To: <1368803354.84.0.768428094886.issue17998@psf.upfronthosting.co.za> Message-ID: <1368803711.2.0.894310762097.issue17998@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Regular Expressions nosy: +benjamin.peterson, ezio.melotti, mrabarnett type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 17:30:40 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 17 May 2013 15:30:40 +0000 Subject: [issue17965] argparse does not dest.replace('-', '_') for positionals In-Reply-To: <1368411809.58.0.522670485437.issue17965@psf.upfronthosting.co.za> Message-ID: <1368804640.05.0.711439879605.issue17965@psf.upfronthosting.co.za> R. David Murray added the comment: That should have been --XXX-YYY, of course. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 17:55:53 2013 From: report at bugs.python.org (Joe Stuart) Date: Fri, 17 May 2013 15:55:53 +0000 Subject: [issue17989] ElementTree.Element broken attribute setting In-Reply-To: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za> Message-ID: <1368806153.97.0.548758981848.issue17989@psf.upfronthosting.co.za> Joe Stuart added the comment: It looks like it's being called from the c extension. I would think it should still throw an exception though? >>> e = etree.Element >>> e.ham = 1 Traceback (most recent call last): File "", line 1, in TypeError: can't set attributes of built-in/extension type 'xml.etree.ElementTree.Element' ---------- nosy: +jjstuart _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 18:15:33 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 17 May 2013 16:15:33 +0000 Subject: [issue17999] test_super fails in refleak runs Message-ID: <1368807333.21.0.801142067432.issue17999@psf.upfronthosting.co.za> New submission from Antoine Pitrou: $ ./python -m test -R 3:3 test_super [1/1] test_super beginning 6 repetitions 123456 test test_super failed -- Traceback (most recent call last): File "/home/antoine/cpython/default/Lib/test/test_super.py", line 97, in test_various___class___pathologies self.assertIs(X.x, type(self)) AssertionError: 42 is not ---------- components: Tests messages: 189464 nosy: benjamin.peterson, pitrou priority: normal severity: normal stage: needs patch status: open title: test_super fails in refleak runs type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 18:23:46 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 17 May 2013 16:23:46 +0000 Subject: [issue17957] remove outdated (and unexcellent) paragraph in whatsnew In-Reply-To: <1368310843.47.0.442601461472.issue17957@psf.upfronthosting.co.za> Message-ID: <1368807826.39.0.647380752.issue17957@psf.upfronthosting.co.za> ?ric Araujo added the comment: I don?t see any benefit at all in changing this paragraph of a whatsnew document. It was useful and accurate for the 2.6 release, it?s still accessible for the record, let?s keep it. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 18:25:54 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 17 May 2013 16:25:54 +0000 Subject: [issue17998] internal error in regular expression engine In-Reply-To: <1368803354.84.0.768428094886.issue17998@psf.upfronthosting.co.za> Message-ID: <1368807954.84.0.873149118746.issue17998@psf.upfronthosting.co.za> Benjamin Peterson added the comment: 27162465316f ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 18:28:35 2013 From: report at bugs.python.org (Christian Heimes) Date: Fri, 17 May 2013 16:28:35 +0000 Subject: [issue17998] internal error in regular expression engine In-Reply-To: <1368803354.84.0.768428094886.issue17998@psf.upfronthosting.co.za> Message-ID: <1368808115.36.0.288231572814.issue17998@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 18:29:13 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Fri, 17 May 2013 16:29:13 +0000 Subject: [issue17998] internal error in regular expression engine In-Reply-To: <1368803354.84.0.768428094886.issue17998@psf.upfronthosting.co.za> Message-ID: <1368808153.82.0.751410738626.issue17998@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Also, note this particular case only reproduces on 32 bit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 18:33:38 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 May 2013 16:33:38 +0000 Subject: [issue17999] test_super fails in refleak runs In-Reply-To: <1368807333.21.0.801142067432.issue17999@psf.upfronthosting.co.za> Message-ID: <3bBw6p1RWGz7LlM@mail.python.org> Roundup Robot added the comment: New changeset b4553d22c163 by Benjamin Peterson in branch 'default': reset __class__, so multiple runs don't fail (closes #17999) http://hg.python.org/cpython/rev/b4553d22c163 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 18:33:49 2013 From: report at bugs.python.org (Christian Heimes) Date: Fri, 17 May 2013 16:33:49 +0000 Subject: [issue17998] internal error in regular expression engine In-Reply-To: <1368803354.84.0.768428094886.issue17998@psf.upfronthosting.co.za> Message-ID: <1368808429.73.0.962605752741.issue17998@psf.upfronthosting.co.za> Christian Heimes added the comment: I'm able to confirm Benjamin's notes. The regexp works on 64bit Linux but fails with a 32bit build: $ CFLAGS="-m32" LDFLAGS="-m32" ./configure $ make -j10 $ ./python -c "import re; print(re.compile('(.*)\.[0-9]*\.[0-9]*$', re.I|re.S).findall('3.0.0'))" Traceback (most recent call last): File "", line 1, in RuntimeError: internal error in regular expression engine ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 18:48:16 2013 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 17 May 2013 16:48:16 +0000 Subject: =?utf-8?b?W2lzc3VlMTc5OTVdIHJlcG9ydO+8jOS4reOAgOmrmOOAgOWxguOAgOeuoQ==?= =?utf-8?b?44CA55CG44CA5oqA44CA6IO9MTU4NzY2?= Message-ID: <1368809296.18.0.0984409716066.issue17995@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- Removed message: http://bugs.python.org/msg189390 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 19:02:40 2013 From: report at bugs.python.org (paul j3) Date: Fri, 17 May 2013 17:02:40 +0000 Subject: [issue9338] argparse optionals with nargs='?', '*' or '+' can't be followed by positionals In-Reply-To: <1279881989.28.0.725806934086.issue9338@psf.upfronthosting.co.za> Message-ID: <1368810160.78.0.701988461206.issue9338@psf.upfronthosting.co.za> paul j3 added the comment: This patch implements, I think, the ideas bethard proposed. It is test patch, not intended for production. Most of work is in ArgumentParser._get_alt_length() which - generates a pattern along the lines bethard proposed - generates a string like arg_strings_pattern, but with optionals strings ('-x') instead of 'O'. - runs a match - from groups like '-xAAA', creates dict entries like: alt_opt_length['x'] = 3 Later, in consume_optionals(), this alternative count replaces arg_count if it is lower. The next consume_positionals() then takes care of consuming the unconsumed arguments. If _get_alt_length() has any problems, it logs an error, and returns an otherwise empty dict. So it 'fails' quietly without affecting regular parsing. Reasons for failing include (for now) the use of subparsers, optionals with explicit args, and special prefix_chars. With exclusions like this, test_argparse.py runs without errors or failures. Since this is still a testing vehicle, it writes an issue9338.log file with debugging entries. This version works, but is both not sufficiently general and too general. As bethard notes, the testing pattern could get very large if there are many optionals. Ideally the pattern will allow the optionals in any order and combination between positionals. The ambiguities that I discussed in the previous 2 posts disappear if the patching pattern is sufficiently general. But I also suspect it is too general. It does not need to match every case, just those where an optional is consuming arguments that should go to a positional. But if we come up with something more specific, this could still be a useful testing tool. ---------- Added file: http://bugs.python.org/file30296/issue9338_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 19:07:11 2013 From: report at bugs.python.org (Andy Chugunov) Date: Fri, 17 May 2013 17:07:11 +0000 Subject: [issue17973] '+=' on a list inside tuple both succeeds and raises an exception In-Reply-To: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> Message-ID: <1368810431.79.0.927194040861.issue17973@psf.upfronthosting.co.za> Andy Chugunov added the comment: Thank you for the clarification! The exception is appropriate as tuples have to stay immutable. Got it. Could you please also explain a bit about the append() call? Should it in theory raise an exception as well or is such clean behavior intended? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 19:10:16 2013 From: report at bugs.python.org (paul j3) Date: Fri, 17 May 2013 17:10:16 +0000 Subject: [issue9338] argparse optionals with nargs='?', '*' or '+' can't be followed by positionals In-Reply-To: <1279881989.28.0.725806934086.issue9338@psf.upfronthosting.co.za> Message-ID: <1368810616.38.0.759584371025.issue9338@psf.upfronthosting.co.za> paul j3 added the comment: This is a test file for the patch I just submitted. It is not a formal unitttest, but uses print output as much as assert. Cases include the example bethard used, as well as ones from test_argparse.py that initially caused problems. ---------- Added file: http://bugs.python.org/file30297/test_9338.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 19:14:11 2013 From: report at bugs.python.org (Matthew Barnett) Date: Fri, 17 May 2013 17:14:11 +0000 Subject: [issue17998] internal error in regular expression engine In-Reply-To: <1368803354.84.0.768428094886.issue17998@psf.upfronthosting.co.za> Message-ID: <1368810851.28.0.285067419472.issue17998@psf.upfronthosting.co.za> Matthew Barnett added the comment: Here are some simpler examples of the bug: re.compile('.*yz', re.S).findall('xyz') re.compile('.?yz', re.S).findall('xyz') re.compile('.+yz', re.S).findall('xyz') Unfortunately I find it difficult to see what's happening when single-stepping through the code because of the macros. :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 20:04:28 2013 From: report at bugs.python.org (Joe Stuart) Date: Fri, 17 May 2013 18:04:28 +0000 Subject: [issue17989] ElementTree.Element broken attribute setting In-Reply-To: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za> Message-ID: <1368813868.37.0.585630325214.issue17989@psf.upfronthosting.co.za> Joe Stuart added the comment: At the end of ElementTree all of the c accelerators are being imported and it looks like only XMLParser is being used. Here is a patch that only imports XMLParser. ---------- keywords: +patch Added file: http://bugs.python.org/file30298/ElementTree.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 20:07:29 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 May 2013 18:07:29 +0000 Subject: [issue17998] internal error in regular expression engine In-Reply-To: <1368803354.84.0.768428094886.issue17998@psf.upfronthosting.co.za> Message-ID: <1368814049.66.0.186487446492.issue17998@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which should fix this bug. I still have to look for similar bugs and write tests. ---------- keywords: +patch stage: -> patch review versions: +Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30299/re_unsigned_ptrdiff.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 20:10:42 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 17 May 2013 18:10:42 +0000 Subject: [issue17998] internal error in regular expression engine In-Reply-To: <1368803354.84.0.768428094886.issue17998@psf.upfronthosting.co.za> Message-ID: <1368814242.6.0.843776517158.issue17998@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Matthew for simpler examples. They helped and I'll use them in the tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 20:17:16 2013 From: report at bugs.python.org (Joe Stuart) Date: Fri, 17 May 2013 18:17:16 +0000 Subject: [issue17989] ElementTree.Element broken attribute setting In-Reply-To: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za> Message-ID: <1368814636.03.0.884799231285.issue17989@psf.upfronthosting.co.za> Changes by Joe Stuart : Removed file: http://bugs.python.org/file30298/ElementTree.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 20:19:31 2013 From: report at bugs.python.org (Joe Stuart) Date: Fri, 17 May 2013 18:19:31 +0000 Subject: [issue17989] ElementTree.Element broken attribute setting In-Reply-To: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za> Message-ID: <1368814771.41.0.679462395568.issue17989@psf.upfronthosting.co.za> Joe Stuart added the comment: This patch should fix the issue of the classes being overwritten by the c accelerated ones. ---------- Added file: http://bugs.python.org/file30300/ElementTree.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 21:02:32 2013 From: report at bugs.python.org (Joe Stuart) Date: Fri, 17 May 2013 19:02:32 +0000 Subject: [issue17989] ElementTree.Element broken attribute setting In-Reply-To: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za> Message-ID: <1368817352.02.0.908465355433.issue17989@psf.upfronthosting.co.za> Changes by Joe Stuart : Removed file: http://bugs.python.org/file30300/ElementTree.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 21:11:02 2013 From: report at bugs.python.org (Joe Stuart) Date: Fri, 17 May 2013 19:11:02 +0000 Subject: [issue17989] ElementTree.Element broken attribute setting In-Reply-To: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za> Message-ID: <1368817862.41.0.217926767408.issue17989@psf.upfronthosting.co.za> Joe Stuart added the comment: Forgot to update the XMLParser() assignment. ---------- Added file: http://bugs.python.org/file30301/ElementTree.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 21:12:17 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 17 May 2013 19:12:17 +0000 Subject: [issue17991] ctypes.c_char gives a misleading error when passed a one-character unicode string In-Reply-To: <1368674517.59.0.230555789399.issue17991@psf.upfronthosting.co.za> Message-ID: <1368817937.57.0.215936230877.issue17991@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +amaury.forgeotdarc, meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 21:23:12 2013 From: report at bugs.python.org (Jeroen Demeyer) Date: Fri, 17 May 2013 19:23:12 +0000 Subject: [issue18000] _md5 should be built if _ssl cannot be built Message-ID: <1368818592.85.0.0295311805267.issue18000@psf.upfronthosting.co.za> New submission from Jeroen Demeyer: I have an Itanium Linux system where compiling Python's _ssl module fails for some reason, with the consequence that there is no md5 support at all in the resulting Python 2.7.5 installation. With Python 2.7.4, setup.py didn't even try to compile _ssl, instead it compiled the _sha, _md5, _sha256, _sha512 modules and it worked. With Python 2.7.5, setup.py somehow thinks that _ssl should work, tries to compile _ssl, which fails and (this is the real failure): it doesn't try anymore to compile the _sha, _md5, _sha256, _sha512 modules. ---------- components: Build messages: 189479 nosy: jdemeyer priority: normal severity: normal status: open title: _md5 should be built if _ssl cannot be built versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 21:49:55 2013 From: report at bugs.python.org (Charles Henry) Date: Fri, 17 May 2013 19:49:55 +0000 Subject: [issue18001] TypeError: dict is not callable in ConfigParser.py Message-ID: <1368820195.26.0.0396003591011.issue18001@psf.upfronthosting.co.za> New submission from Charles Henry: Python 2.6 and 2.7 each have a bad definition of the class RawConfigParser It is immediately apparent in the __init__ function which begins with: class RawConfigParser: def __init__(self, defaults=None, dict_type=dict): self._dict = dict_type self._sections = self._dict() self._defaults = self._dict() Clearly, _dict() is not a function. _dict is not even properly defined as a public or private member of the RawConfigParser class. The fix is to add a private variable to the class and a function for retrieving the value. ---------- components: Library (Lib) messages: 189480 nosy: czhenry priority: normal severity: normal status: open title: TypeError: dict is not callable in ConfigParser.py versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 21:57:47 2013 From: report at bugs.python.org (Christian Heimes) Date: Fri, 17 May 2013 19:57:47 +0000 Subject: [issue18000] _md5 should be built if _ssl cannot be built In-Reply-To: <1368818592.85.0.0295311805267.issue18000@psf.upfronthosting.co.za> Message-ID: <1368820667.0.0.58016257235.issue18000@psf.upfronthosting.co.za> Christian Heimes added the comment: setup.py doesn't compile _md5 and the other C extension if it thinks that _ssl is available. Can you post the build error of the _ssl module here, too? ---------- nosy: +christian.heimes stage: -> needs patch type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 21:59:52 2013 From: report at bugs.python.org (Jeroen Demeyer) Date: Fri, 17 May 2013 19:59:52 +0000 Subject: [issue18000] _md5 should be built if _ssl cannot be built In-Reply-To: <1368818592.85.0.0295311805267.issue18000@psf.upfronthosting.co.za> Message-ID: <1368820792.41.0.821959714997.issue18000@psf.upfronthosting.co.za> Jeroen Demeyer added the comment: Sure, building _ssl fails with: building '_ssl' extension gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -I. -IInclude -I./Include -I/usr/include -I/home/buildbot/build/sage/iras-1/iras_full/build /sage-5.10.beta4/local/include -I/home/buildbot/local/iras/include -I/home/buildbot/build/sage/iras-1/iras_full/build/sage-5.10.beta4/spkg/build/python-2.7.5.p0/src/Inc lude -I/home/buildbot/build/sage/iras-1/iras_full/build/sage-5.10.beta4/spkg/build/python-2.7.5.p0/src -c /home/buildbot/build/sage/iras-1/iras_full/build/sage-5.10.bet a4/spkg/build/python-2.7.5.p0/src/Modules/_ssl.c -o build/temp.linux-ia64-2.7/home/buildbot/build/sage/iras-1/iras_full/build/sage-5.10.beta4/spkg/build/python-2.7.5.p0 /src/Modules/_ssl.o gcc -pthread -shared -L/home/buildbot/build/sage/iras-1/iras_full/build/sage-5.10.beta4/local/lib -L/home/buildbot/build/sage/iras-1/iras_full/build/sage-5.10.beta4/loc al/lib build/temp.linux-ia64-2.7/home/buildbot/build/sage/iras-1/iras_full/build/sage-5.10.beta4/spkg/build/python-2.7.5.p0/src/Modules/_ssl.o -L/usr/lib -L/lib -L/home /buildbot/build/sage/iras-1/iras_full/build/sage-5.10.beta4/local/lib -L/home/buildbot/local/iras/lib -L. -lssl -lcrypto -lpython2.7 -o build/lib.linux-ia64-2.7/_ssl.so /usr/bin/ld: /home/buildbot/local/iras/lib/libcrypto.a(obj_dat.o): @gprel relocation against dynamic symbol obj_cleanup_defer /usr/bin/ld: /home/buildbot/local/iras/lib/libcrypto.a(obj_dat.o): @gprel relocation against dynamic symbol obj_cleanup_defer /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status But really: I think the main problem here is that _md5 isn't even attempted to build. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 22:23:18 2013 From: report at bugs.python.org (Christian Heimes) Date: Fri, 17 May 2013 20:23:18 +0000 Subject: [issue18000] _md5 should be built if _ssl cannot be built In-Reply-To: <1368818592.85.0.0295311805267.issue18000@psf.upfronthosting.co.za> Message-ID: <1368822198.59.0.533624032786.issue18000@psf.upfronthosting.co.za> Christian Heimes added the comment: Yes, that's the main culprit. At first setup.py checks if all necessary bits and pieces for _ssl are available. If setup.py doesn't find the shared libraries and header files it adds _md5 to the list of extensions. Compilation and linking happens *after* the list of extension modules has been created. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 22:38:30 2013 From: report at bugs.python.org (Ethan Furman) Date: Fri, 17 May 2013 20:38:30 +0000 Subject: [issue18001] TypeError: dict is not callable in ConfigParser.py In-Reply-To: <1368820195.26.0.0396003591011.issue18001@psf.upfronthosting.co.za> Message-ID: <1368823110.59.0.482840515968.issue18001@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 22:42:59 2013 From: report at bugs.python.org (STINNER Victor) Date: Fri, 17 May 2013 20:42:59 +0000 Subject: [issue17976] file.write doesn't raise IOError when it should In-Reply-To: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za> Message-ID: <1368823379.66.0.491214912792.issue17976@psf.upfronthosting.co.za> STINNER Victor added the comment: Attached: Test expressed as an unit test, test_dev_null.py. The test pass with Python 3 which does not use the "FILE*" API anymore. So you should maybe migrate to Python 3 :-) $ python3.4 test_dev_null.py .. ---------------------------------------------------------------------- Ran 2 tests in 0.005s OK $ python2.7 test_dev_null.py .F ====================================================================== FAIL: test_write2 (__main__.TestFull) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_dev_null.py", line 13, in test_write2 self.assertRaises(IOError, self.check_write, 'hello', '\n') AssertionError: IOError not raised ---------------------------------------------------------------------- Ran 2 tests in 0.002s FAILED (failures=1) ---------- nosy: +haypo Added file: http://bugs.python.org/file30302/test_dev_null.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 22:55:55 2013 From: report at bugs.python.org (STINNER Victor) Date: Fri, 17 May 2013 20:55:55 +0000 Subject: [issue18002] AMD64 Windows7 SP1 3.x buildbot: compilation of _ssl module fails, the build fails Message-ID: <1368824155.21.0.900173074466.issue18002@psf.upfronthosting.co.za> New submission from STINNER Victor: Example of failure: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/1956/ -- Compilation log: Project "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\pcbuild.sln" (1) is building "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\_ssl.vcxproj" (17) on node 1 (default targets). Project "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\_ssl.vcxproj" (17) is building "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\ssl.vcxproj" (18) on node 1 (default targets). Build: cd "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\" "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\amd64\python_d.exe" build_ssl.py Release x64 -a Can not find a suitable PERL: NO perl interpreters were found on this machine at all! Please install ActivePerl and ensure it appears on your path No Perl installation was found. Existing Makefiles are used. Perl is required to build the makefiles! C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: The command "cd "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\" [C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\ssl.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\amd64\python_d.exe" build_ssl.py Release x64 -a [C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\ssl.vcxproj] C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(38,5): error MSB3073: " exited with code 1. [C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\ssl.vcxproj] Done Building Project "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\ssl.vcxproj" (default targets) -- FAILED. Done Building Project "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\_ssl.vcxproj" (default targets) -- FAILED. ---------- components: Tests, Windows messages: 189485 nosy: haypo, loewis, pitrou priority: normal severity: normal status: open title: AMD64 Windows7 SP1 3.x buildbot: compilation of _ssl module fails, the build fails versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 23:10:22 2013 From: report at bugs.python.org (Ethan Furman) Date: Fri, 17 May 2013 21:10:22 +0000 Subject: [issue18001] TypeError: dict is not callable in ConfigParser.py In-Reply-To: <1368820195.26.0.0396003591011.issue18001@psf.upfronthosting.co.za> Message-ID: <1368825022.98.0.478679940574.issue18001@psf.upfronthosting.co.za> Ethan Furman added the comment: Your interest if fixing Python is appreciated, but you need to verify that a bug actually exists first: Python 2.7.3 (default, Sep 26 2012, 21:51:14) [GCC 4.7.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. --> class RawConfigParser: ... def __init__(self, defaults=None, dict_type=dict): ... self._dict = dict_type ... self._sections = self._dict() ... self._defaults = self._dict() ... --> rcp = RawConfigParser() --> rcp._sections {} --> type(rcp._sections) --> rcp._sections['test'] = 'hello, world!' --> rcp._sections {'test': 'hello, world!'} As you can see, it is indeed callable and does result in a dictionary. ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 23:44:54 2013 From: report at bugs.python.org (STINNER Victor) Date: Fri, 17 May 2013 21:44:54 +0000 Subject: [issue17986] Alternative async subprocesses (pep 3145) In-Reply-To: <1368652199.21.0.577907802925.issue17986@psf.upfronthosting.co.za> Message-ID: <1368827094.48.0.346578247736.issue17986@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 17 23:54:29 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 17 May 2013 21:54:29 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1368827669.7.0.51012786112.issue15758@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Looks fine to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 00:27:24 2013 From: report at bugs.python.org (Michael Fox) Date: Fri, 17 May 2013 22:27:24 +0000 Subject: [issue18003] New lzma crazy slow with line-oriented reading. Message-ID: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> New submission from Michael Fox: import lzma count = 0 f = lzma.LZMAFile('bigfile.xz' ,'r') for line in f: count += 1 print(count) Comparing python2 with pyliblzma to python3.3.1 with the new lzma: m at air:~/q/topaz/parse_datalog$ time python lzmaperf.py 102368 real 0m0.062s user 0m0.056s sys 0m0.004s m at air:~/q/topaz/parse_datalog$ time python3 lzmaperf.py 102368 real 0m7.506s user 0m7.484s sys 0m0.012s Profiling shows most of the time is spent here: 102371 6.881 0.000 6.972 0.000 lzma.py:247(_read_block) I also notice that reading the entire file into memory with f.read() is perfectly fast. I think it has something to do with lack of buffering. ---------- components: Library (Lib) messages: 189488 nosy: Michael.Fox, nadeem.vawda priority: normal severity: normal status: open title: New lzma crazy slow with line-oriented reading. type: performance versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 00:36:43 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 May 2013 22:36:43 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <3bC49l0zZlz7Ljv@mail.python.org> Roundup Robot added the comment: New changeset e4c303d23d01 by Richard Oudkerk in branch 'default': Issue #15758: Fix FileIO.readall() so it no longer has O(n**2) complexity. http://hg.python.org/cpython/rev/e4c303d23d01 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 00:52:34 2013 From: report at bugs.python.org (STINNER Victor) Date: Fri, 17 May 2013 22:52:34 +0000 Subject: [issue18003] New lzma crazy slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1368831154.62.0.0818144532208.issue18003@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 01:23:06 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 17 May 2013 23:23:06 +0000 Subject: [issue17644] str.format() crashes In-Reply-To: <1365259586.34.0.498934812452.issue17644@psf.upfronthosting.co.za> Message-ID: <3bC5CG0bXXz7Ljv@mail.python.org> Roundup Robot added the comment: New changeset 6786e681ed58 by Benjamin Peterson in branch '3.3': only recursively expand in the format spec (closes #17644) http://hg.python.org/cpython/rev/6786e681ed58 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 01:46:49 2013 From: report at bugs.python.org (Anselm Kruis) Date: Fri, 17 May 2013 23:46:49 +0000 Subject: [issue18004] test_list.test_overflow crashes Win64 Message-ID: <1368834409.49.0.790067586607.issue18004@psf.upfronthosting.co.za> New submission from Anselm Kruis: I installed Python 2.7.5 including tests using the MSI installer from http://www.python.org/ftp/python/2.7.5/python-2.7.5.amd64.msi Running python.exe -m test.regrtest -v test_list consumes all available memory and renders the my system completely unusable. I had to reboot. The problem is caused by the test case "test_overflow". If you run the test with an imposed memory limit, e.g. by using ulimitnt (http://code.google.com/p/ulimitnt/) , test_overflow passes. I propose to skip this test on Win64. ---------- components: Tests messages: 189491 nosy: anselm.kruis priority: normal severity: normal status: open title: test_list.test_overflow crashes Win64 type: resource usage versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 04:12:56 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sat, 18 May 2013 02:12:56 +0000 Subject: [issue17957] remove outdated (and unexcellent) paragraph in whatsnew In-Reply-To: <1368310843.47.0.442601461472.issue17957@psf.upfronthosting.co.za> Message-ID: <1368843176.53.0.438106590081.issue17957@psf.upfronthosting.co.za> Ezio Melotti added the comment: Agreed. ---------- resolution: -> rejected stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 05:40:07 2013 From: report at bugs.python.org (Phil Webster) Date: Sat, 18 May 2013 03:40:07 +0000 Subject: [issue13657] IDLE doesn't support sys.ps1 and sys.ps2. In-Reply-To: <1324640742.58.0.860347532783.issue13657@psf.upfronthosting.co.za> Message-ID: <1368848406.98.0.0840530276865.issue13657@psf.upfronthosting.co.za> Phil Webster added the comment: I've attached a patch that attempts to get sys.ps1 for the prompt. Unfortunately it prints out blue because it is treated as output from running print(sys.ps1) as if the user had typed it in. Now that I have a better understanding of the issue, I may be able to work on the subprocess handling that Roger suggested. ---------- keywords: +patch nosy: +philwebster Added file: http://bugs.python.org/file30303/issue13657.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 05:46:37 2013 From: report at bugs.python.org (Ethan Furman) Date: Sat, 18 May 2013 03:46:37 +0000 Subject: [issue3489] add rotate{left,right} methods to bytearray In-Reply-To: <1217613478.49.0.00141126667538.issue3489@psf.upfronthosting.co.za> Message-ID: <1368848797.94.0.198997550604.issue3489@psf.upfronthosting.co.za> Ethan Furman added the comment: Antoine, do you want to pursue, or can we close this? ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 05:54:44 2013 From: report at bugs.python.org (Ethan Furman) Date: Sat, 18 May 2013 03:54:44 +0000 Subject: [issue515074] Extended storage in new-style classes Message-ID: <1368849284.78.0.460572175388.issue515074@psf.upfronthosting.co.za> Ethan Furman added the comment: David, is this still a need? Or, put another way, has Python change enough in the last 11 years that you can now do what you wanted? ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 06:34:58 2013 From: report at bugs.python.org (Dave Abrahams) Date: Sat, 18 May 2013 04:34:58 +0000 Subject: [issue515074] Extended storage in new-style classes In-Reply-To: <1368849284.78.0.460572175388.issue515074@psf.upfronthosting.co.za> Message-ID: <8D6C5435-926D-4DCD-8E74-70934BBED973@boostpro.com> Dave Abrahams added the comment: I have no idea. I don't work with low-level python much anymore. Sorry Sent from my moss-covered three-handled family gradunza On May 17, 2013, at 8:54 PM, Ethan Furman wrote: > > Ethan Furman added the comment: > > David, is this still a need? Or, put another way, has Python change enough in the last 11 years that you can now do what you wanted? > > ---------- > nosy: +ethan.furman > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 06:44:40 2013 From: report at bugs.python.org (Ethan Furman) Date: Sat, 18 May 2013 04:44:40 +0000 Subject: [issue8297] AttributeError message text should include module name In-Reply-To: <1270272607.93.0.943961280816.issue8297@psf.upfronthosting.co.za> Message-ID: <1368852280.0.0.337321553561.issue8297@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 09:12:30 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 18 May 2013 07:12:30 +0000 Subject: [issue17997] ssl.match_hostname(): sub string wildcard should not match IDNA prefix In-Reply-To: <1368799493.86.0.504478450601.issue17997@psf.upfronthosting.co.za> Message-ID: <1368861150.71.0.988194423454.issue17997@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 09:15:53 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 18 May 2013 07:15:53 +0000 Subject: [issue17989] ElementTree.Element broken attribute setting In-Reply-To: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za> Message-ID: <1368861353.68.0.858929483342.issue17989@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Replacement of pure-Python classes by C-accelerated classes is intentional. http://docs.python.org/3.3/library/xml.etree.elementtree.html "Changed in version 3.3: This module will use a fast implementation whenever available. The xml.etree.cElementTree module is deprecated." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 09:17:42 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 18 May 2013 07:17:42 +0000 Subject: [issue17989] ElementTree.Element broken attribute setting In-Reply-To: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za> Message-ID: <1368861462.56.0.863251118948.issue17989@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : Removed file: http://bugs.python.org/file30301/ElementTree.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 09:23:10 2013 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 18 May 2013 07:23:10 +0000 Subject: [issue17973] '+=' on a list inside tuple both succeeds and raises an exception In-Reply-To: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> Message-ID: <1368861790.52.0.746424089687.issue17973@psf.upfronthosting.co.za> Mark Dickinson added the comment: Another 'fix' would be to allow assignment to a tuple item in the case that the item being assigned is the same (in the sense of 'is') as the item already in the tuple. Then the '+=' operation would succeed, but the tuple would remain immutable. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 09:25:07 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 18 May 2013 07:25:07 +0000 Subject: [issue17998] internal error in regular expression engine In-Reply-To: <1368803354.84.0.768428094886.issue17998@psf.upfronthosting.co.za> Message-ID: <1368861907.04.0.855123211908.issue17998@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 09:25:33 2013 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 18 May 2013 07:25:33 +0000 Subject: [issue17973] '+=' on a list inside tuple both succeeds and raises an exception In-Reply-To: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> Message-ID: <1368861933.63.0.432415911062.issue17973@psf.upfronthosting.co.za> Mark Dickinson added the comment: @andy.chugunov: tuples are immutable in the sense that you can't put a new object into a tuple or remove objects from a tuple. That doesn't mean that tuples can't contain mutable objects, or prevent you from mutating the objects inside a tuple. So the append method call is fine: it's not modifying the tuple itself (the tuple still has references to exactly the same objects both before and after the append call); it's merely mutating one the objects inside the tuple. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 10:48:27 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 08:48:27 +0000 Subject: [issue3489] add rotate{left,right} methods to bytearray In-Reply-To: <1217613478.49.0.00141126667538.issue3489@psf.upfronthosting.co.za> Message-ID: <1368866907.63.0.804588301523.issue3489@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think we can close. issue17100 would have been more useful actually. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 11:33:37 2013 From: report at bugs.python.org (Patrick Welche) Date: Sat, 18 May 2013 09:33:37 +0000 Subject: [issue17975] libpython3.so conflicts between $VERSIONs In-Reply-To: <1368542639.2.0.817126483539.issue17975@psf.upfronthosting.co.za> Message-ID: <1368869617.24.0.00838818809458.issue17975@psf.upfronthosting.co.za> Patrick Welche added the comment: I see that this was introduced in http://www.python.org/dev/peps/pep-0384/ Would a configure option to make it easy not to install the conflicting file be acceptable? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 11:34:07 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 May 2013 09:34:07 +0000 Subject: [issue3489] add rotate{left,right} methods to bytearray In-Reply-To: <1217613478.49.0.00141126667538.issue3489@psf.upfronthosting.co.za> Message-ID: <1368869647.0.0.439219544887.issue3489@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think you rather need the inplace shift operation. Or even the move the tail of buffer to the start without filling the remaining. I.e. something like buffer[:size] = buffer[-size:] but without creating immediate bytes object. Now it may be written as: buffer[:size] = memoryview(buffer)[-size:] ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 11:49:59 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 18 May 2013 09:49:59 +0000 Subject: [issue17975] libpython3.so conflicts between $VERSIONs In-Reply-To: <1368542639.2.0.817126483539.issue17975@psf.upfronthosting.co.za> Message-ID: <1368870599.05.0.943883356122.issue17975@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: See issue #11347. (Python ebuilds in Gentoo manually delete libpython3.so.) ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 12:07:19 2013 From: report at bugs.python.org (Pernici Mario) Date: Sat, 18 May 2013 10:07:19 +0000 Subject: [issue18005] faster modular exponentiation in some cases Message-ID: <1368871639.93.0.89718215484.issue18005@psf.upfronthosting.co.za> New submission from Pernici Mario: A trivial optimization can be made in ``pow(a, b, c)`` if ``b`` is even and ``c - a < a`` ``` In [1]: c = (1 << 1000000) + 1 In [2]: a = c - 1234567 In [3]: b = 2 In [4]: %timeit pow(a, b, c) 1 loops, best of 3: 3.03 s per loop In [5]: %timeit pow(c - a if c - a < (a >> 10) else a, b, c) 1000 loops, best of 3: 287 us per loop ``` This optimization is probably done in GMP, since using gmpy.mpz [5] is a bit slower than [4]. ---------- messages: 189504 nosy: pernici priority: normal severity: normal status: open title: faster modular exponentiation in some cases type: performance versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 12:36:49 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 May 2013 10:36:49 +0000 Subject: [issue18005] faster modular exponentiation in some cases In-Reply-To: <1368871639.93.0.89718215484.issue18005@psf.upfronthosting.co.za> Message-ID: <1368873409.89.0.60327986547.issue18005@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +eric.smith, lemburg, mark.dickinson, rhettinger, serhiy.storchaka, stutzbach versions: +Python 3.4 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 13:13:15 2013 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 18 May 2013 11:13:15 +0000 Subject: [issue18005] faster modular exponentiation in some cases In-Reply-To: <1368871639.93.0.89718215484.issue18005@psf.upfronthosting.co.za> Message-ID: <1368875595.71.0.657200172472.issue18005@psf.upfronthosting.co.za> Mark Dickinson added the comment: Sorry, I'm rejecting this. This sort of micro-optimization for a little-used operation doesn't belong in Python. For applications that need it, use gmpy2. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 13:35:20 2013 From: report at bugs.python.org (Volker Braun) Date: Sat, 18 May 2013 11:35:20 +0000 Subject: [issue18000] _md5 should be built if _ssl cannot be built In-Reply-To: <1368818592.85.0.0295311805267.issue18000@psf.upfronthosting.co.za> Message-ID: <1368876920.35.0.508708742391.issue18000@psf.upfronthosting.co.za> Volker Braun added the comment: This has been fixed for Python-3.3 in #14693. Attached is a straightforward Python-2.7.5 backport of the patch. ---------- keywords: +patch nosy: +vbraun Added file: http://bugs.python.org/file30304/hashlibfallbacks.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 13:44:07 2013 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sat, 18 May 2013 11:44:07 +0000 Subject: [issue18006] Set thread nema in linux kernel Message-ID: <1368877447.89.0.564489245045.issue18006@psf.upfronthosting.co.za> New submission from ???? ?????????: In linux (Since 2.6.9) we can use syscall prctl(PR_SET_NAME, "Some thread name") to set thread name to the kernel. This thread is seen under this name in some process tool (like top, ps, pstree (have bug reported connected with this) and others). It will be nice if this syscall will be called (from correspoding thread=TID) when changing (setting) thread name. Note, that in current implementation name will be truncated to 15 bytes in kernel. This work very well using ctypes or python-prctl module. Also there is error in manpage about prctl saying that name is set to process (already sent to maintainer). Really, name is set to each thread. ---------- components: Library (Lib) messages: 189507 nosy: mmarkk priority: normal severity: normal status: open title: Set thread nema in linux kernel type: enhancement versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 13:44:20 2013 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 18 May 2013 11:44:20 +0000 Subject: [issue17931] PyLong_FromPid() is not correctly defined on Windows 64-bit In-Reply-To: <1367964709.89.0.899001899577.issue17931@psf.upfronthosting.co.za> Message-ID: <1368877459.99.0.486639386776.issue17931@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 13:44:26 2013 From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=) Date: Sat, 18 May 2013 11:44:26 +0000 Subject: [issue18006] Set thread name in linux kernel In-Reply-To: <1368877447.89.0.564489245045.issue18006@psf.upfronthosting.co.za> Message-ID: <1368877466.25.0.333443778031.issue18006@psf.upfronthosting.co.za> Changes by ???? ????????? : ---------- title: Set thread nema in linux kernel -> Set thread name in linux kernel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 14:15:22 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 12:15:22 +0000 Subject: [issue17975] libpython3.so conflicts between $VERSIONs In-Reply-To: <1368542639.2.0.817126483539.issue17975@psf.upfronthosting.co.za> Message-ID: <1368879322.9.0.447848544967.issue17975@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Did you use "make altinstall"? ---------- nosy: +barry, dmalcolm, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 14:24:45 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 12:24:45 +0000 Subject: [issue18004] test_list.test_overflow crashes Win64 In-Reply-To: <1368834409.49.0.790067586607.issue18004@psf.upfronthosting.co.za> Message-ID: <1368879885.44.0.743954206007.issue18004@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I take it you have more than 16GB of RAM? What happens if you replace "sys.maxint" with "sys.maxsize" in test_overflow? ---------- nosy: +arigo, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 14:25:48 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 12:25:48 +0000 Subject: [issue18004] test_list.test_overflow crashes Win64 In-Reply-To: <1368834409.49.0.790067586607.issue18004@psf.upfronthosting.co.za> Message-ID: <1368879948.59.0.149422290237.issue18004@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Note: "test_overflow" can be found in Python2.7/Lib/test/test_list.py ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 14:35:40 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 12:35:40 +0000 Subject: [issue17807] Generator cleanup without tp_del In-Reply-To: <1366508251.45.0.78173664702.issue17807@psf.upfronthosting.co.za> Message-ID: <1368880540.82.0.755230520914.issue17807@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Obsoleted by PEP 442. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 15:17:05 2013 From: report at bugs.python.org (R. David Murray) Date: Sat, 18 May 2013 13:17:05 +0000 Subject: [issue18006] Set thread name in linux kernel In-Reply-To: <1368877447.89.0.564489245045.issue18006@psf.upfronthosting.co.za> Message-ID: <1368883025.21.0.456595521363.issue18006@psf.upfronthosting.co.za> R. David Murray added the comment: This is effectively a duplicate of issue 5672. Are you interested in carrying through the process outlined there by Martin? Otherwise we should close this issue as well until someone does propose to do so. ---------- nosy: +r.david.murray versions: -Python 3.3, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 15:28:46 2013 From: report at bugs.python.org (Armin Rigo) Date: Sat, 18 May 2013 13:28:46 +0000 Subject: [issue18004] test_list.test_overflow crashes Win64 In-Reply-To: <1368834409.49.0.790067586607.issue18004@psf.upfronthosting.co.za> Message-ID: <1368883726.72.0.180753490944.issue18004@psf.upfronthosting.co.za> Changes by Armin Rigo : ---------- nosy: -arigo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 15:57:34 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 13:57:34 +0000 Subject: [issue18006] Set thread name in linux kernel In-Reply-To: <1368877447.89.0.564489245045.issue18006@psf.upfronthosting.co.za> Message-ID: <1368885454.53.0.954690423287.issue18006@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'd also point out that changing the kernel thread name *by default* would be pretty much a large regression. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 16:06:54 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 18 May 2013 14:06:54 +0000 Subject: [issue17989] ElementTree.Element broken attribute setting In-Reply-To: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za> Message-ID: <1368886014.2.0.858585040543.issue17989@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- assignee: -> eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 16:10:30 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 14:10:30 +0000 Subject: [issue17997] ssl.match_hostname(): sub string wildcard should not match IDNA prefix In-Reply-To: <1368799493.86.0.504478450601.issue17997@psf.upfronthosting.co.za> Message-ID: <1368886230.16.0.416855841781.issue17997@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Actually, I don't this is a bug: match_hostname() expects str data, and therefore IDNA-decoded domain names: >>> b"xn--gtter-jua.example.de".decode("idna") 'g?tter.example.de' Doing the matching on the decoded domain name should be safe. Then it very much depends on whether the data you've got was IDNA-decoded, or na?vely ASCII-decoded, and I don't think the Python stdlib is very consistent here. Looking at the socket module, gethostbyaddr and getnameinfo seem to use ASCII decoding... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 16:14:19 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 18 May 2013 14:14:19 +0000 Subject: [issue17989] ElementTree.Element broken attribute setting In-Reply-To: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za> Message-ID: <1368886459.58.0.0749222359768.issue17989@psf.upfronthosting.co.za> Eli Bendersky added the comment: Yes, overwriting the Python classes with C classes is not an error, but the original issue is legit. The error should be more immediately reported. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 16:19:37 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sat, 18 May 2013 14:19:37 +0000 Subject: [issue15758] FileIO.readall() has worst case O(n^2) complexity In-Reply-To: <1345587910.43.0.919180045188.issue15758@psf.upfronthosting.co.za> Message-ID: <1368886777.31.0.950821335865.issue15758@psf.upfronthosting.co.za> Changes by Richard Oudkerk : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 16:35:44 2013 From: report at bugs.python.org (Christian Heimes) Date: Sat, 18 May 2013 14:35:44 +0000 Subject: [issue17997] ssl.match_hostname(): sub string wildcard should not match IDNA prefix In-Reply-To: <1368799493.86.0.504478450601.issue17997@psf.upfronthosting.co.za> Message-ID: <1368887744.13.0.9916310497.issue17997@psf.upfronthosting.co.za> Christian Heimes added the comment: It's called "internationalized domain name for APPLICATIONS". ;) It's up to the application to interpret the ASCII text as IDNA encoded FQDNs. As far as I know DNS, SSL's CNAME and OS interfaces etc. always use ASCII labels. It's an elegant solution. Just the UI part of an application needs to understand IDNA. http://tools.ietf.org/html/rfc6125#section-6.4.2 If the DNS domain name portion of a reference identifier is an internationalized domain name, then an implementation MUST convert any U-labels [IDNA-DEFS] in the domain name to A-labels before checking the domain name. In accordance with [IDNA-PROTO], A-labels MUST be compared as case-insensitive ASCII. Each label MUST match in order for the domain names to be considered to match, except as supplemented by the rule about checking of wildcard labels (Section 6.4.3; but see also Section 7.2 regarding wildcards in internationalized domain names). Coincidentally the same RFC contains matching rules for wild card certs http://tools.ietf.org/html/rfc6125#section-6.4.3 If a client matches the reference identifier against a presented identifier whose DNS domain name portion contains the wildcard character '*', the following rules apply: 1. The client SHOULD NOT attempt to match a presented identifier in which the wildcard character comprises a label other than the left-most label (e.g., do not match bar.*.example.net). 2. If the wildcard character is the only character of the left-most label in the presented identifier, the client SHOULD NOT compare against anything but the left-most label of the reference identifier (e.g., *.example.com would match foo.example.com but not bar.foo.example.com or example.com). 3. The client MAY match a presented identifier in which the wildcard character is not the only character of the label (e.g., baz*.example.net and *baz.example.net and b*z.example.net would be taken to match baz1.example.net and foobaz.example.net and buzz.example.net, respectively). However, the client SHOULD NOT attempt to match a presented identifier where the wildcard character is embedded within an A-label or U-label [IDNA-DEFS] of an internationalized domain name [IDNA-PROTO]. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 16:37:31 2013 From: report at bugs.python.org (Christian Heimes) Date: Sat, 18 May 2013 14:37:31 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368887851.7.0.574611732474.issue17980@psf.upfronthosting.co.za> Christian Heimes added the comment: The IDNA RFC contains additional rules for wildcard matching ... very well hidden indead! http://tools.ietf.org/html/rfc6125#section-6.4.3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 16:41:56 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 18 May 2013 14:41:56 +0000 Subject: [issue17989] ElementTree.Element broken attribute setting In-Reply-To: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za> Message-ID: <1368888116.64.0.306092925164.issue17989@psf.upfronthosting.co.za> Eli Bendersky added the comment: The problem is that element_setattro is returning a wrong value for error - NULL instead of -1. So the exception is set and is triggered on the next line instead. Will fix for 3.3 and default branches ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 16:42:22 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 18 May 2013 14:42:22 +0000 Subject: [issue17989] ElementTree.Element broken attribute setting In-Reply-To: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za> Message-ID: <1368888142.04.0.681509038718.issue17989@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- stage: -> needs patch type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 16:49:11 2013 From: report at bugs.python.org (Jeremy Kloth) Date: Sat, 18 May 2013 14:49:11 +0000 Subject: [issue18002] AMD64 Windows7 SP1 3.x buildbot: compilation of _ssl module fails, the build fails In-Reply-To: <1368824155.21.0.900173074466.issue18002@psf.upfronthosting.co.za> Message-ID: <1368888551.54.0.304672058284.issue18002@psf.upfronthosting.co.za> Jeremy Kloth added the comment: The build of OpenSSL was failing due to an incomplete external check-in of OpenSSL (missing the cached assembler files). Martin has since updated the external and I have refreshed the OpenSSL exports on the buildbot. It is no longer failing to compile, but other errors still remain. This issue can be closed. ---------- nosy: +jkloth type: -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 16:53:52 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 May 2013 14:53:52 +0000 Subject: [issue17989] ElementTree.Element broken attribute setting In-Reply-To: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za> Message-ID: <3bCTsD05VxzSdZ@mail.python.org> Roundup Robot added the comment: New changeset 9682241dc8fc by Eli Bendersky in branch '3.3': Issue #17989: element_setattro returned incorrect error value. http://hg.python.org/cpython/rev/9682241dc8fc New changeset b111ae4f83ef by Eli Bendersky in branch 'default': Issue #17989: element_setattro returned incorrect error value. http://hg.python.org/cpython/rev/b111ae4f83ef ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 16:54:41 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 18 May 2013 14:54:41 +0000 Subject: [issue17989] ElementTree.Element broken attribute setting In-Reply-To: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za> Message-ID: <1368888881.74.0.717735452336.issue17989@psf.upfronthosting.co.za> Eli Bendersky added the comment: Fixed. Thanks for the report! Python 3.4.0a0 (default:1b760f926846+9682241dc8fc+, May 18 2013, 07:52:49) [GCC 4.6.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import xml.etree.ElementTree as ET; j = ET.Element('j') >>> j.ham = 2 Traceback (most recent call last): File "", line 1, in AttributeError: Can't set arbitraty attributes on Element >>> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 16:54:53 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 18 May 2013 14:54:53 +0000 Subject: [issue17989] ElementTree.Element broken attribute setting In-Reply-To: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za> Message-ID: <1368888893.3.0.923516315983.issue17989@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 17:03:22 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 18 May 2013 15:03:22 +0000 Subject: [issue17988] ElementTree.Element != ElementTree._ElementInterface In-Reply-To: <1368657583.19.0.922119818205.issue17988@psf.upfronthosting.co.za> Message-ID: <1368889402.28.0.510156980729.issue17988@psf.upfronthosting.co.za> Eli Bendersky added the comment: These "compatibility" names are likely to be remnants from the out-of-tree xml etree implementation before it made it into the stdlib. I think they can simply be removed in 3.4, as they're not documented anywhere. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 17:45:02 2013 From: report at bugs.python.org (Simon Nicolussi) Date: Sat, 18 May 2013 15:45:02 +0000 Subject: [issue18007] CookieJar expects request objects with origin_req_host attribute instead of method Message-ID: <1368891902.97.0.967044954731.issue18007@psf.upfronthosting.co.za> New submission from Simon Nicolussi: A fix for a DeprecationWarning (#17678) had the unfortunate side effect of changing the expected interface of the request object higher up in the call stack. For example, the documentation for CookieJar.add_cookie_header(request) states that the request object must support the methods get_full_url(), get_host(), get_type(), unverifiable(), get_origin_req_host(), has_header(), get_header(), header_items(), and add_unredirected_header(). The patch for #17678, however, changes the requirement for a get_origin_req_host() method to an origin_req_host attribute. This breaks at least one notable third-party library (Kenneth Reitz' Requests). ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 189523 nosy: docs at python, orsenthil, sinic priority: normal severity: normal status: open title: CookieJar expects request objects with origin_req_host attribute instead of method type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 17:45:06 2013 From: report at bugs.python.org (William Moreno) Date: Sat, 18 May 2013 15:45:06 +0000 Subject: [issue18008] python33-3.3.2 Parser/pgen: Permission denied Message-ID: <1368891906.35.0.458659072685.issue18008@psf.upfronthosting.co.za> New submission from William Moreno: cc -DNDEBUG -O2 -pipe -fno-strict-aliasing -pthread -pthread Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/dynamic_annotations.o Python/mysnprintf.o Python/pyctype.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/parsetok_pgen.o Parser/pgenmain.o -lutil -o Parser/pgen `Parser/pgen' is up to date. Parser/pgen ./../Grammar/Grammar Include/graminit.h Python/graminit.c Parser/pgen: Permission denied *** [Include/graminit.h] Error code 126 cc -c -DNDEBUG -O2 -pipe -fno-strict-aliasing -O2 -pipe -fno-strict-aliasing -O2 -pipe -fno-strict-aliasing -I. -IInclude -I./../Include -DPy_BUILD_CORE -o Objects/typeobject.o ./../Objects/typeobject.c /usr/lib/crt1.o: In function `_start': crt1.c:(.text+0x8a): undefined reference to `main' Parser/bitset.o: In function `_Py_newbitset': bitset.c:(.text+0xfa): undefined reference to `Py_FatalError' Parser/firstsets.o: In function `calcfirstset': firstsets.c:(.text+0x15): undefined reference to `Py_DebugFlag' firstsets.c:(.text+0x1d9): undefined reference to `Py_DebugFlag' firstsets.c:(.text+0x20f): undefined reference to `Py_FatalError' firstsets.c:(.text+0x329): undefined reference to `Py_FatalError' Parser/firstsets.o: In function `_Py_addfirstsets': firstsets.c:(.text+0x345): undefined reference to `Py_DebugFlag' Parser/grammar.o: In function `_Py_translatelabels': grammar.c:(.text+0x87): undefined reference to `Py_DebugFlag' grammar.c:(.text+0x10d): undefined reference to `Py_DebugFlag' grammar.c:(.text+0x205): undefined reference to `Py_DebugFlag' grammar.c:(.text+0x234): undefined reference to `Py_DebugFlag' Parser/grammar.o: In function `_Py_findlabel': grammar.c:(.text+0x452): undefined reference to `Py_FatalError' Parser/grammar.o: In function `_Py_addarc': grammar.c:(.text+0x4ec): undefined reference to `Py_FatalError' Parser/grammar.o: In function `_Py_addstate': grammar.c:(.text+0x588): undefined reference to `Py_FatalError' Parser/grammar.o: In function `_Py_addlabel': grammar.c:(.text+0x63b): undefined reference to `Py_DebugFlag' grammar.c:(.text+0x675): undefined reference to `Py_FatalError' Parser/grammar.o: In function `_Py_adddfa': grammar.c:(.text+0x72e): undefined reference to `Py_FatalError' Parser/grammar.o: In function `_Py_newgrammar': grammar.c:(.text+0x7a6): undefined reference to `Py_FatalError' Parser/pgen.o: In function `addnfaarc': pgen.c:(.text+0x76): undefined reference to `Py_FatalError' Parser/pgen.o: In function `addnfastate': pgen.c:(.text+0xd6): undefined reference to `Py_FatalError' Parser/pgen.o: In function `_Py_pgen': pgen.c:(.text+0x5f4): undefined reference to `Py_DebugFlag' pgen.c:(.text+0x744): undefined reference to `Py_FatalError' pgen.c:(.text+0x799): undefined reference to `Py_FatalError' pgen.c:(.text+0x7ee): undefined reference to `Py_DebugFlag' pgen.c:(.text+0xaa3): undefined reference to `Py_DebugFlag' pgen.c:(.text+0xb86): undefined reference to `Py_DebugFlag' pgen.c:(.text+0xc96): undefined reference to `Py_FatalError' pgen.c:(.text+0xca5): undefined reference to `Py_FatalError' pgen.c:(.text+0xcb1): undefined reference to `Py_DebugFlag' pgen.c:(.text+0xeed): undefined reference to `Py_FatalError' pgen.c:(.text+0xefc): undefined reference to `Py_FatalError' Parser/tokenizer_pgen.o: In function `indenterror': tokenizer_pgen.c:(.text+0x3a6): undefined reference to `PySys_WriteStderr' Parser/tokenizer_pgen.o: In function `tok_nextc': tokenizer_pgen.c:(.text+0x605): undefined reference to `PyOS_Readline' tokenizer_pgen.c:(.text+0x6ef): undefined reference to `PySys_WriteStderr' Parser/tokenizer_pgen.o: In function `tok_backup': tokenizer_pgen.c:(.text+0xa98): undefined reference to `Py_FatalError' Parser/parsetok_pgen.o: In function `PyParser_ParseStringFlagsFilenameEx': parsetok_pgen.c:(.text+0x5e3): undefined reference to `PyErr_Occurred' *** [Parser/pgen] Error code 1 1 error *** [Include/graminit.h] Error code 2 1 error *** [Python/importlib.h] Error code 2 2 errors *** [do-build] Error code 1 Stop in /usr/ports/lang/python33. *** [install] Error code 1 Stop in /usr/ports/lang/python33. root at server:/usr/ports/lang/python33 # make clean ===> Cleaning for python33-3.3.2 ---------- components: Build messages: 189524 nosy: wmoreno3 priority: normal severity: normal status: open title: python33-3.3.2 Parser/pgen: Permission denied type: compile error versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 17:59:23 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 May 2013 15:59:23 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <3bCWJp3YN0zRvP@mail.python.org> Roundup Robot added the comment: New changeset b9b521efeba3 by Antoine Pitrou in branch '3.2': Issue #17980: Fix possible abuse of ssl.match_hostname() for denial of service using certificates with many wildcards (CVE-2013-2099). http://hg.python.org/cpython/rev/b9b521efeba3 New changeset c627638753e2 by Antoine Pitrou in branch '3.3': Issue #17980: Fix possible abuse of ssl.match_hostname() for denial of service using certificates with many wildcards (CVE-2013-2099). http://hg.python.org/cpython/rev/c627638753e2 New changeset fafd33db6ff6 by Antoine Pitrou in branch 'default': Issue #17980: Fix possible abuse of ssl.match_hostname() for denial of service using certificates with many wildcards (CVE-2013-2099). http://hg.python.org/cpython/rev/fafd33db6ff6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 18:00:16 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 16:00:16 +0000 Subject: [issue17980] CVE-2013-2099 ssl.match_hostname() trips over crafted wildcard names In-Reply-To: <1368613506.72.0.090501566592.issue17980@psf.upfronthosting.co.za> Message-ID: <1368892816.5.0.378318394296.issue17980@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, this should be fixed now. Thanks a lot for reporting! ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 18:02:30 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 16:02:30 +0000 Subject: [issue17997] ssl.match_hostname(): sub string wildcard should not match IDNA prefix In-Reply-To: <1368799493.86.0.504478450601.issue17997@psf.upfronthosting.co.za> Message-ID: <1368892950.42.0.133906564681.issue17997@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > It's called "internationalized domain name for APPLICATIONS". ;) It's > up to the application to interpret the ASCII text as IDNA encoded > FQDNs. As far as I know DNS, SSL's CNAME and OS interfaces etc. always > use ASCII labels. It's an elegant solution. Just the UI part of an > application needs to understand IDNA. The socket module already decodes to/encodes from IDNA in places (e.g. gethostname()). We need a consistent policy in the stdlib; I would like Martin's advice on this. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 18:03:23 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 16:03:23 +0000 Subject: [issue18002] AMD64 Windows7 SP1 3.x buildbot: compilation of _ssl module fails, the build fails In-Reply-To: <1368824155.21.0.900173074466.issue18002@psf.upfronthosting.co.za> Message-ID: <1368893003.06.0.111492472516.issue18002@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the heads-up. Closing. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 18:04:53 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 18 May 2013 16:04:53 +0000 Subject: [issue3489] add rotate{left,right} methods to bytearray In-Reply-To: <1217613478.49.0.00141126667538.issue3489@psf.upfronthosting.co.za> Message-ID: <1368893093.65.0.619617384954.issue3489@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 18:06:35 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sat, 18 May 2013 16:06:35 +0000 Subject: [issue17953] sys.modules cannot be reassigned In-Reply-To: <1368260613.85.0.746522318662.issue17953@psf.upfronthosting.co.za> Message-ID: <1368893195.18.0.690499460052.issue17953@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: Documentation added for sys.modules ---------- keywords: +patch nosy: +Yogesh.Chaudhari Added file: http://bugs.python.org/file30305/issue17953.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 18:08:49 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 16:08:49 +0000 Subject: [issue17998] internal error in regular expression engine In-Reply-To: <1368803354.84.0.768428094886.issue17998@psf.upfronthosting.co.za> Message-ID: <1368893329.36.0.70902366171.issue17998@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Perhaps it would be safer to revert the original commit in bugfix branches, and just commit the better patch in default? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 18:15:53 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 16:15:53 +0000 Subject: [issue17975] libpython3.so conflicts between $VERSIONs In-Reply-To: <1368542639.2.0.817126483539.issue17975@psf.upfronthosting.co.za> Message-ID: <1368893753.64.0.697520593863.issue17975@psf.upfronthosting.co.za> Antoine Pitrou added the comment: According to Martin on the bug linked to: ? Having the soname be libpython3 is the whole point of the library, it serves no other reason. It is intentional that there are file collisions with that file, and either the local admin or the distributor must make an explicit choice which libpython3 should be installed; it should be the one that corresponds to /usr/bin/python (if you install it into /usr/lib). ? Should we close this issue as won't fix? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 18:16:16 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 16:16:16 +0000 Subject: [issue17975] libpython3.so conflicts between $VERSIONs In-Reply-To: <1368542639.2.0.817126483539.issue17975@psf.upfronthosting.co.za> Message-ID: <1368893776.05.0.235375666256.issue17975@psf.upfronthosting.co.za> Antoine Pitrou added the comment: (on the bug Arfrever linked to, sorry) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 18:19:12 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 16:19:12 +0000 Subject: [issue17984] io and _pyio modules require the _io module In-Reply-To: <1368647367.8.0.180383025422.issue17984@psf.upfronthosting.co.za> Message-ID: <1368893952.23.0.946961932756.issue17984@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- stage: -> needs patch type: behavior -> enhancement versions: -Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 18:20:47 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 16:20:47 +0000 Subject: [issue17970] Mutlithread XML parsing cause segfault In-Reply-To: <1368453158.92.0.142296100122.issue17970@psf.upfronthosting.co.za> Message-ID: <1368894047.34.0.466849104657.issue17970@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I agree with Amaury, multi-threaded parsing should definitely not crash. Adding a lock should be quite easy. I wonder what would be the effect on performance, if there are lots of backs and forths between expat and Python. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 18:28:26 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sat, 18 May 2013 16:28:26 +0000 Subject: [issue17988] ElementTree.Element != ElementTree._ElementInterface In-Reply-To: <1368657583.19.0.922119818205.issue17988@psf.upfronthosting.co.za> Message-ID: <1368894506.62.0.504408805187.issue17988@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: +1 for deletion of them (even in 3.3.3). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 18:44:29 2013 From: report at bugs.python.org (Shai Berger) Date: Sat, 18 May 2013 16:44:29 +0000 Subject: [issue18009] os.write.__doc__ is misleading Message-ID: <1368895469.2.0.802658153503.issue18009@psf.upfronthosting.co.za> New submission from Shai Berger: At least on posix systems, os.write says it takes a string, but in fact it barfs on strings -- it needs bytes. $ python Python 3.3.1 (default, May 6 2013, 16:18:33) [GCC 4.7.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> print(os.write.__doc__) write(fd, string) -> byteswritten Write a string to a file descriptor. >>> os.write(1, "hello") Traceback (most recent call last): File "", line 1, in TypeError: 'str' does not support the buffer interface >>> os.write(1, b"hello") hello5 >>> ---------- messages: 189535 nosy: shai priority: normal severity: normal status: open title: os.write.__doc__ is misleading type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 19:05:19 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 17:05:19 +0000 Subject: [issue18010] pydoc search chokes on import errors Message-ID: <1368896719.35.0.915741072389.issue18010@psf.upfronthosting.co.za> New submission from Antoine Pitrou: After installing Django, I get the following error in test_pydoc: ====================================================================== FAIL: test_url_requests (test.test_pydoc.PydocUrlHandlerTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/antoine/cpython/finalize/Lib/test/test_pydoc.py", line 581, in test_url_requests self.assertEqual(result, title, text) AssertionError: 'Pydoc: Error - search?key=pydoc' != 'Pydoc: Search Results' - Pydoc: Error - search?key=pydoc + Pydoc: Search Results The reason is attempting to import a django.something module raises the following error: django.core.exceptions.ImproperlyConfigured: Requested setting DATABASES, but settings are not configured. You must either define the environment variable DJANGO_SETTINGS_MODULE or call settings.configure() before accessing settings ... which isn't silenced by pydoc. Now I agree this is fundamentally obnoxious on Django's part, but unfortunately it isn't the only package (IIRC) to behave in this way, meaning it would be nice from pydoc to silence all such errors when an import is attempted. ---------- components: Library (Lib) messages: 189536 nosy: pitrou priority: normal severity: normal stage: needs patch status: open title: pydoc search chokes on import errors type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 19:09:08 2013 From: report at bugs.python.org (Ethan Furman) Date: Sat, 18 May 2013 17:09:08 +0000 Subject: [issue18009] os.write.__doc__ is misleading In-Reply-To: <1368895469.2.0.802658153503.issue18009@psf.upfronthosting.co.za> Message-ID: <1368896948.25.0.86441226419.issue18009@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 20:16:23 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 May 2013 18:16:23 +0000 Subject: [issue17839] base64 module should use memoryview In-Reply-To: <1366875154.79.0.0782227735295.issue17839@psf.upfronthosting.co.za> Message-ID: <1368900982.99.0.198346214747.issue17839@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Nick, what you say about the patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 20:45:24 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 May 2013 18:45:24 +0000 Subject: [issue17812] Quadratic complexity in b32encode In-Reply-To: <1366580059.45.0.527459222954.issue17812@psf.upfronthosting.co.za> Message-ID: <1368902724.04.0.508392411322.issue17812@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Note that without patches both tests run many minutes. base32_fix.patch causes little (5%) performance degradation for small data (< KB), this is perhaps the cause for the use of string concatenation. However base32_optimize.patch speeds up about 3x for such data. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 20:46:00 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 May 2013 18:46:00 +0000 Subject: [issue17812] Quadratic complexity in b32encode In-Reply-To: <1366580059.45.0.527459222954.issue17812@psf.upfronthosting.co.za> Message-ID: <1368902760.13.0.100337192384.issue17812@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Note that without patches both tests run many minutes. base32_fix.patch causes little (5%) performance degradation for small data (< KB), this is perhaps the cause for the use of string concatenation. However base32_optimize.patch speeds up about 3x for such data. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 20:47:28 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 May 2013 18:47:28 +0000 Subject: [issue17844] Add link to alternatives for bytes-to-bytes codecs In-Reply-To: <1366889842.88.0.0886939266057.issue17844@psf.upfronthosting.co.za> Message-ID: <1368902848.34.0.835276540282.issue17844@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Any opinions? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 20:53:12 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 May 2013 18:53:12 +0000 Subject: [issue18010] pydoc search chokes on import errors In-Reply-To: <1368896719.35.0.915741072389.issue18010@psf.upfronthosting.co.za> Message-ID: <1368903192.67.0.483484020817.issue18010@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Isn't issue10060 related? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 20:57:14 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 May 2013 18:57:14 +0000 Subject: [issue16995] Add Base32 support for RFC4648 "Extended Hex" alphabet (patch attached) In-Reply-To: <1358533279.94.0.666576182033.issue16995@psf.upfronthosting.co.za> Message-ID: <1368903434.8.0.024008238863.issue16995@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 21:27:18 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 May 2013 19:27:18 +0000 Subject: [issue5557] Byte-code compilation uses excessive memory In-Reply-To: <1237924124.82.0.478709056921.issue5557@psf.upfronthosting.co.za> Message-ID: <1368905238.84.0.0611361675431.issue5557@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 21:46:33 2013 From: report at bugs.python.org (Nadeem Vawda) Date: Sat, 18 May 2013 19:46:33 +0000 Subject: [issue18003] New lzma crazy slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1368906393.5.0.772712845262.issue18003@psf.upfronthosting.co.za> Nadeem Vawda added the comment: Have you tried running the benchmark against the default (3.4) branch? There was some significant optimization work done in issue 16034, but the changes were not backported to 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 21:47:42 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 19:47:42 +0000 Subject: [issue18010] pydoc search chokes on import errors In-Reply-To: <1368896719.35.0.915741072389.issue18010@psf.upfronthosting.co.za> Message-ID: <1368906462.11.0.68605524935.issue18010@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Not exactly. issue10060 is about a crash when loading an extension module, not an exception being raised and propagated through pydoc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 21:53:19 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 19:53:19 +0000 Subject: [issue17812] Quadratic complexity in b32encode In-Reply-To: <1366580059.45.0.527459222954.issue17812@psf.upfronthosting.co.za> Message-ID: <1368906799.34.0.0773436705228.issue17812@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Using a bytearray, rather than accumulating into a list, may reduce memory consumption. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 22:03:03 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 20:03:03 +0000 Subject: [issue18010] pydoc search chokes on import errors In-Reply-To: <1368896719.35.0.915741072389.issue18010@psf.upfronthosting.co.za> Message-ID: <1368907383.95.0.112669828888.issue18010@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Patch attached. ---------- keywords: +patch Added file: http://bugs.python.org/file30306/pydoc_search_onerror.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 22:34:07 2013 From: report at bugs.python.org (Patrick Welche) Date: Sat, 18 May 2013 20:34:07 +0000 Subject: [issue17975] libpython3.so conflicts between $VERSIONs In-Reply-To: <1368542639.2.0.817126483539.issue17975@psf.upfronthosting.co.za> Message-ID: <1368909247.18.0.3947171462.issue17975@psf.upfronthosting.co.za> Patrick Welche added the comment: No, I don't think you should close this, as you haven't explained what it is that you won't do. I think that a sensible plan is to introduce a configure flag whose effect is to not install the files which cause the conflict. You set the default to always install the conflicting files, so the standard install of python gets to be the PY3LIBRARY. What this buys you, is that then you can also install another version of python 3 concurrently and easily. I just need to find a round tuit to write it... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 22:35:52 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 20:35:52 +0000 Subject: [issue11995] test_pydoc loads all Python modules In-Reply-To: <1304497766.98.0.489430644994.issue11995@psf.upfronthosting.co.za> Message-ID: <1368909352.67.0.527457047547.issue11995@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is a patch. ---------- nosy: +pitrou versions: +Python 3.4 Added file: http://bugs.python.org/file30307/test_pydoc_imports.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 22:45:03 2013 From: report at bugs.python.org (Patrick Welche) Date: Sat, 18 May 2013 20:45:03 +0000 Subject: [issue17975] libpython3.so conflicts between $VERSIONs In-Reply-To: <1368542639.2.0.817126483539.issue17975@psf.upfronthosting.co.za> Message-ID: <1368909903.03.0.611323989514.issue17975@psf.upfronthosting.co.za> Patrick Welche added the comment: To quote the README: Installing multiple versions ---------------------------- ... For example, if you want to install Python 2.6, 2.7 and 3.4 with 2.7 being the primary version, you would execute "make install" in your 2.7 build directory and "make altinstall" in the others. This makes perfect sense, but now it is impossible to make 3.2 and 3.3 python packages which can be installed simultaneously. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 22:58:04 2013 From: report at bugs.python.org (Ned Deily) Date: Sat, 18 May 2013 20:58:04 +0000 Subject: [issue18008] python33-3.3.2 Parser/pgen: Permission denied In-Reply-To: <1368891906.35.0.458659072685.issue18008@psf.upfronthosting.co.za> Message-ID: <1368910684.45.0.838203180843.issue18008@psf.upfronthosting.co.za> Ned Deily added the comment: You did not provide enough information to determine exactly what went wrong in your build but you are likely running in an environment with non-standard permissions (umask, root, ACLs, etc.). Note that the failure occurs when the main Makefile rule to build Include/graminit.h ($(GRAMMAR_H): around Makefile.pre.in:669) gets a permission denied error trying to execute the pgen executable (Parser/pgen) created in the previously executed rule ($(PGEN): Makefile.pre.in:677). Most likely the executable lacks executable permission. Check the permissions on Parser/pgen to determine if that was so and determine why the cc -o build recipe was unable to set the normal executable permissions on it or why it was subsequently unable to be executed by make. ---------- nosy: +ned.deily resolution: -> works for me stage: -> committed/rejected status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 23:12:40 2013 From: report at bugs.python.org (Michael Fox) Date: Sat, 18 May 2013 21:12:40 +0000 Subject: [issue18003] New lzma crazy slow with line-oriented reading. In-Reply-To: <1368906393.5.0.772712845262.issue18003@psf.upfronthosting.co.za> Message-ID: Michael Fox added the comment: 3.4 is much better but still 4x slower than 2.7 m at air:~/q/topaz/parse_datalog$ time python2.7 lzmaperf.py 102368 real 0m0.053s user 0m0.052s sys 0m0.000s m at air:~/q/topaz/parse_datalog$ time ~/tmp/cpython-23836f17e4a2/bin/python3.4 lzmaperf.py 102368 real 0m0.229s user 0m0.212s sys 0m0.012s The bottleneck has moved here: 102369 0.151 0.000 0.226 0.000 lzma.py:333(readline) I don't know if this is a strictly fair comparison. The lzma module and pyliblzma may not be of the same quality. I've just come across a real bug in pyliblzma. It doesn't apply to this test, but who knows what shortcuts it's taking. Finally, here's a baseline: m at air:~/q/topaz/parse_datalog$ time xzcat bigfile.xz | wc -l 102368 real 0m0.034s user 0m0.024s sys 0m0.016s On Sat, May 18, 2013 at 12:46 PM, Nadeem Vawda wrote: > > Nadeem Vawda added the comment: > > Have you tried running the benchmark against the default (3.4) branch? > There was some significant optimization work done in issue 16034, but > the changes were not backported to 3.3. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ -- - Michael ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 23:12:57 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 May 2013 21:12:57 +0000 Subject: [issue17812] Quadratic complexity in b32encode In-Reply-To: <1366580059.45.0.527459222954.issue17812@psf.upfronthosting.co.za> Message-ID: <1368911577.1.0.347021311634.issue17812@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Antoine. Here are updated patches. ---------- Added file: http://bugs.python.org/file30308/base32_fix_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 23:13:24 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 May 2013 21:13:24 +0000 Subject: [issue17812] Quadratic complexity in b32encode In-Reply-To: <1366580059.45.0.527459222954.issue17812@psf.upfronthosting.co.za> Message-ID: <1368911604.85.0.173125523865.issue17812@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file30309/base32_optimize_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 23:14:06 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 May 2013 21:14:06 +0000 Subject: [issue17812] Quadratic complexity in b32encode In-Reply-To: <1366580059.45.0.527459222954.issue17812@psf.upfronthosting.co.za> Message-ID: <1368911646.16.0.772129485278.issue17812@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file29971/base32_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 23:14:17 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 May 2013 21:14:17 +0000 Subject: [issue17812] Quadratic complexity in b32encode In-Reply-To: <1366580059.45.0.527459222954.issue17812@psf.upfronthosting.co.za> Message-ID: <1368911657.17.0.375813256221.issue17812@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file29972/base32_optimize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 18 23:48:22 2013 From: report at bugs.python.org (Michael Fox) Date: Sat, 18 May 2013 21:48:22 +0000 Subject: [issue18003] New lzma crazy slow with line-oriented reading. In-Reply-To: Message-ID: Michael Fox added the comment: I looked into it a little and it looks like pyliblzma is a pure C extension whereas new lzma library wraps liblzma but the rest is python. In particular this happens for every line: if size < 0: end = self._buffer.find(b"\n", self._buffer_offset) + 1 if end > 0: line = self._buffer[self._buffer_offset : end] self._buffer_offset = end self._pos += len(line) return line And while that doesn't look like a lot of overhead, it's definitely something. So, unless someone thinks that a pure C extension is the right technical direction, lzma in 3.4 is probably as fast as it's ever going to be. I will just use the workaround of piping in unxz regardless. On Sat, May 18, 2013 at 2:12 PM, Michael Fox <415fox at gmail.com> wrote: > 3.4 is much better but still 4x slower than 2.7 > > m at air:~/q/topaz/parse_datalog$ time python2.7 lzmaperf.py > 102368 > > real 0m0.053s > user 0m0.052s > sys 0m0.000s > m at air:~/q/topaz/parse_datalog$ time > ~/tmp/cpython-23836f17e4a2/bin/python3.4 lzmaperf.py > 102368 > > real 0m0.229s > user 0m0.212s > sys 0m0.012s > > The bottleneck has moved here: > 102369 0.151 0.000 0.226 0.000 lzma.py:333(readline) > > I don't know if this is a strictly fair comparison. The lzma module > and pyliblzma may not be of the same quality. I've just come across a > real bug in pyliblzma. It doesn't apply to this test, but who knows > what shortcuts it's taking. > > Finally, here's a baseline: > > m at air:~/q/topaz/parse_datalog$ time xzcat bigfile.xz | wc -l > 102368 > > real 0m0.034s > user 0m0.024s > sys 0m0.016s > > On Sat, May 18, 2013 at 12:46 PM, Nadeem Vawda wrote: >> >> Nadeem Vawda added the comment: >> >> Have you tried running the benchmark against the default (3.4) branch? >> There was some significant optimization work done in issue 16034, but >> the changes were not backported to 3.3. >> >> ---------- >> >> _______________________________________ >> Python tracker >> >> _______________________________________ > > > > -- > > - > Michael -- - Michael ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 00:00:10 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 22:00:10 +0000 Subject: [issue17812] Quadratic complexity in b32encode In-Reply-To: <1366580059.45.0.527459222954.issue17812@psf.upfronthosting.co.za> Message-ID: <1368914410.49.0.451555330396.issue17812@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 00:11:54 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 May 2013 22:11:54 +0000 Subject: [issue18003] New lzma crazy slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1368915114.01.0.786975041336.issue18003@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Try `f = io.BufferedReader(f)`. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 00:14:27 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 May 2013 22:14:27 +0000 Subject: [issue17812] Quadratic complexity in b32encode In-Reply-To: <1366580059.45.0.527459222954.issue17812@psf.upfronthosting.co.za> Message-ID: <1368915267.1.0.164235206724.issue17812@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think 3.3 needs a fix. The quadratic complexity is a bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 00:15:41 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 22:15:41 +0000 Subject: [issue17812] Quadratic complexity in b32encode In-Reply-To: <1366580059.45.0.527459222954.issue17812@psf.upfronthosting.co.za> Message-ID: <1368915341.25.0.918106332629.issue17812@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Then I would recommend committing the simple patch in 3.3 and the more optimized one in 3.4. Both look fine to me, althgugh I haven't really examined the padding stuff. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 00:44:19 2013 From: report at bugs.python.org (Marcus von Appen) Date: Sat, 18 May 2013 22:44:19 +0000 Subject: [issue18008] python33-3.3.2 Parser/pgen: Permission denied In-Reply-To: <1368891906.35.0.458659072685.issue18008@psf.upfronthosting.co.za> Message-ID: <1368917059.93.0.0534109154912.issue18008@psf.upfronthosting.co.za> Marcus von Appen added the comment: This is a FreeBSD-specific problem with the Python 3.3 port. Using pmake (BSD's make implementation) leads to random errors on either generating pgen or executing pgen. This seems to happen since Python 3.3.1 randomly and is quite hard to reproduce. Switching to GNU make seems to solve the issue, but makes me wonder, if Python (from now on) relies on GNU make. ---------- nosy: +marcusva status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 00:48:04 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 May 2013 22:48:04 +0000 Subject: [issue17901] _elementtree.TreeBuilder raises IndexError on end if constructed with element_factory=None In-Reply-To: <1367611016.77.0.197383711231.issue17901@psf.upfronthosting.co.za> Message-ID: <3bChNN1d6SzRmp@mail.python.org> Roundup Robot added the comment: New changeset c430bea30457 by Eli Bendersky in branch '3.3': Issue #17901: fix TreeBuilder construction for an explicit element_factory=None http://hg.python.org/cpython/rev/c430bea30457 New changeset e79df5d1f680 by Eli Bendersky in branch 'default': Issue #17901: fix TreeBuilder construction for an explicit element_factory=None http://hg.python.org/cpython/rev/e79df5d1f680 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 00:49:10 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 18 May 2013 22:49:10 +0000 Subject: [issue17901] _elementtree.TreeBuilder raises IndexError on end if constructed with element_factory=None In-Reply-To: <1367611016.77.0.197383711231.issue17901@psf.upfronthosting.co.za> Message-ID: <1368917350.2.0.786582804347.issue17901@psf.upfronthosting.co.za> Eli Bendersky added the comment: I committed a fix with a simplified test. Thanks for the contribution, Aaron. Also, to get your patches committed directly you need to sign the Python contributor agreement. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 00:49:26 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 18 May 2013 22:49:26 +0000 Subject: [issue17901] _elementtree.TreeBuilder raises IndexError on end if constructed with element_factory=None In-Reply-To: <1367611016.77.0.197383711231.issue17901@psf.upfronthosting.co.za> Message-ID: <1368917366.08.0.148397102181.issue17901@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 00:51:26 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 18 May 2013 22:51:26 +0000 Subject: [issue17988] ElementTree.Element != ElementTree._ElementInterface In-Reply-To: <1368657583.19.0.922119818205.issue17988@psf.upfronthosting.co.za> Message-ID: <1368917486.55.0.620676445269.issue17988@psf.upfronthosting.co.za> Eli Bendersky added the comment: > +1 for deletion of them (even in 3.3.3). Hmm, I don't think I agree. If someone relies on this thing for some obscure reason, breaking when the switch to 3.4 is made is still less abrasive than a break in a maintenance version. Since this isn't strictly a bug fix, I'm reluctant touching 3.3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 00:54:03 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 22:54:03 +0000 Subject: [issue17988] ElementTree.Element != ElementTree._ElementInterface In-Reply-To: <1368657583.19.0.922119818205.issue17988@psf.upfronthosting.co.za> Message-ID: <1368917643.64.0.870668792171.issue17988@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Agreed with Eli. We shouldn't remove names in bugfix versions. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 01:12:20 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 May 2013 23:12:20 +0000 Subject: [issue17937] Collect garbage harder at shutdown In-Reply-To: <1368047666.23.0.340381721586.issue17937@psf.upfronthosting.co.za> Message-ID: <3bChwM34z5zSGt@mail.python.org> Roundup Robot added the comment: New changeset 5abe85aefe29 by Antoine Pitrou in branch 'default': Issue #17937: Try harder to collect cyclic garbage at shutdown. http://hg.python.org/cpython/rev/5abe85aefe29 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 01:14:15 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 18 May 2013 23:14:15 +0000 Subject: [issue17937] Collect garbage harder at shutdown In-Reply-To: <1368047666.23.0.340381721586.issue17937@psf.upfronthosting.co.za> Message-ID: <1368918855.25.0.668142776276.issue17937@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 01:18:18 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 18 May 2013 23:18:18 +0000 Subject: [issue17902] Document that _elementtree C API cannot use custom TreeBuilder for iterparse or IncrementalParser In-Reply-To: <1367614578.64.0.34953241054.issue17902@psf.upfronthosting.co.za> Message-ID: <1368919098.59.0.977991821926.issue17902@psf.upfronthosting.co.za> Eli Bendersky added the comment: Aaron, could you please sign the PSF CLA (http://www.python.org/psf/contrib/contrib-form/) - this will make it accepting patches from you easier. Other than that, I agree it's a legit patch. The alternative would be to fix _elementtree to actually allow arbitrary TreeBuilders there, although I'm not sure it's worth the effort. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 01:22:16 2013 From: report at bugs.python.org (Ned Deily) Date: Sat, 18 May 2013 23:22:16 +0000 Subject: [issue18008] python33-3.3.2 Parser/pgen: Permission denied In-Reply-To: <1368891906.35.0.458659072685.issue18008@psf.upfronthosting.co.za> Message-ID: <1368919336.64.0.74855704244.issue18008@psf.upfronthosting.co.za> Ned Deily added the comment: I don't know of an intention to break use of other makes but I don't know of any specific effort to test with various makes. As you may have noticed, there were some significant changes to the Makefile rules for pgen-related targets by changeset 52597f888e7a which was released with 3.3.0. I would start by looking there. If someone can identify a problem, patches are welcome. The thing is pgen shouldn't need to be run at all when using a release tarball (assuming you are doing that) as long as the preserved timestamps are correct (see http://bugs.python.org/issue14321#msg155910). Perhaps there is a step missing in the creation of the release tarballs. Georg? ---------- nosy: +georg.brandl stage: committed/rejected -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 04:10:18 2013 From: report at bugs.python.org (Todd Rovito) Date: Sun, 19 May 2013 02:10:18 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1368929418.89.0.0477048354215.issue15392@psf.upfronthosting.co.za> Todd Rovito added the comment: I still have the same problem with the patch it will not apply for me on Python 3.4. Based on Ezio's suggestion I used hg verify where I got three warnings unrelated to IDLE, but just to make sure I did a brand new checkout. Even after a new checkout the patch failed to apply. Then I tried on my CentOS 6.4 box and the patch would not apply. I am wondering has anybody else tried to apply this patch on a Mac OS X or Linux machine and had it work? I still admit I could be doing something stupid..... No idea where to go from here...I might try this on Windows which I think is the system Terry is using because I noticed the file has Ctrl M at the end of the lines. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 04:22:19 2013 From: report at bugs.python.org (R. David Murray) Date: Sun, 19 May 2013 02:22:19 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1368930139.42.0.716899457452.issue15392@psf.upfronthosting.co.za> R. David Murray added the comment: I just did an hg pull/hg up in my 3.4 (default) checkout on linux: rdmurray at hey:~/python/p34>patch -p1 _______________________________________ From report at bugs.python.org Sun May 19 04:49:56 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 19 May 2013 02:49:56 +0000 Subject: [issue734176] Make Tkinter.py's nametowidget work with cloned menu widgets Message-ID: <1368931796.92.0.836829707521.issue734176@psf.upfronthosting.co.za> Mark Lawrence added the comment: Ten years on does anybody actually care about this? If you do the patch will need reworking as in Python 3 the code exists in lib/tkinter/__init__.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 05:38:49 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 19 May 2013 03:38:49 +0000 Subject: [issue18003] New lzma crazy slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1368934729.64.0.881355349673.issue18003@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > So, unless someone thinks that a pure C extension is the > right technical direction, lzma in 3.4 is probably as fast > as it's ever going to be. I would support the inclusion of a C extension. Reasonable performance is a prerequisite for broader adoption. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 05:47:34 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 19 May 2013 03:47:34 +0000 Subject: [issue18003] New lzma crazy slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1368935254.46.0.31150385151.issue18003@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Serhiy, would you like to take this one? ---------- assignee: -> serhiy.storchaka stage: -> needs patch versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 07:20:01 2013 From: report at bugs.python.org (Georg Brandl) Date: Sun, 19 May 2013 05:20:01 +0000 Subject: [issue18008] python33-3.3.2 Parser/pgen: Permission denied In-Reply-To: <1368891906.35.0.458659072685.issue18008@psf.upfronthosting.co.za> Message-ID: <1368940801.06.0.899658219095.issue18008@psf.upfronthosting.co.za> Georg Brandl added the comment: Indeed, the new "hg touch" facility should have been integrated in the release script. I've done that now, in the future all necessary files should have the correct timestamps in the release tarballs. ---------- resolution: works for me -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 10:01:04 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 19 May 2013 08:01:04 +0000 Subject: [issue18006] Set thread name in linux kernel In-Reply-To: <1368877447.89.0.564489245045.issue18006@psf.upfronthosting.co.za> Message-ID: <1368950464.36.0.413609695649.issue18006@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: It's a dupe of #15500. ---------- nosy: +neologix resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> Python should support naming threads _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 10:19:09 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 May 2013 08:19:09 +0000 Subject: [issue18011] Inconsistency between b32decode() documentation, docstring and code Message-ID: <1368951549.72.0.00589705304437.issue18011@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: b32decode() documentation says: "A TypeError is raised if s were incorrectly padded or if there are non-alphabet characters present in the string." b32decode() docstring says: "binascii.Error is raised if the input is incorrectly padded or if there are non-alphabet characters present in the input." Actually binascii.Error (which is a ValueError subtype) is raised if the input is incorrectly padded and TypeError is raised if there are non-alphabet characters present in the input. At least 2 of 3 (documentation, docstring and implementation) should be corrected. Base32 support was originally added in 3cc0d8fd4e2b (TypeError was used everywhere) and then modified in eb45f85c4c79 (TypeError was partially changed to binascii.Error). ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 189571 nosy: barry, docs at python, gvanrossum, serhiy.storchaka priority: normal severity: normal status: open title: Inconsistency between b32decode() documentation, docstring and code type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 10:20:05 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sun, 19 May 2013 08:20:05 +0000 Subject: [issue17996] socket module should expose AF_LINK In-Reply-To: <1368757243.4.0.421622185164.issue17996@psf.upfronthosting.co.za> Message-ID: <1368951605.13.0.252099506638.issue17996@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Well, this just needs a patch :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 10:50:01 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 19 May 2013 08:50:01 +0000 Subject: [issue17812] Quadratic complexity in b32encode In-Reply-To: <1366580059.45.0.527459222954.issue17812@psf.upfronthosting.co.za> Message-ID: <3bCxkw4rr3z7LjY@mail.python.org> Roundup Robot added the comment: New changeset 4b5467d997f1 by Serhiy Storchaka in branch '3.3': Issue #17812: Fixed quadratic complexity of base64.b32encode(). http://hg.python.org/cpython/rev/4b5467d997f1 New changeset 1b5ef05d6ced by Serhiy Storchaka in branch 'default': Issue #17812: Fixed quadratic complexity of base64.b32encode(). http://hg.python.org/cpython/rev/1b5ef05d6ced ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 10:51:48 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 May 2013 08:51:48 +0000 Subject: [issue17812] Quadratic complexity in b32encode In-Reply-To: <1366580059.45.0.527459222954.issue17812@psf.upfronthosting.co.za> Message-ID: <1368953508.72.0.926743919995.issue17812@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: That is why I proposed two patches. ---------- versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 10:52:26 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 May 2013 08:52:26 +0000 Subject: [issue17812] Quadratic complexity in b32encode In-Reply-To: <1366580059.45.0.527459222954.issue17812@psf.upfronthosting.co.za> Message-ID: <1368953546.24.0.233645438969.issue17812@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 11:02:53 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 May 2013 09:02:53 +0000 Subject: [issue18003] New lzma crazy slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1368954173.34.0.59980652546.issue18003@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm against implementing LZMAFile in a pure C. It was a great win that LZMAFile had implemented in a pure Python. However may be we could reuse the existing accelerated implementation of io.BufferedReader. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 12:11:22 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 May 2013 10:11:22 +0000 Subject: [issue18011] Inconsistency between b32decode() documentation, docstring and code In-Reply-To: <1368951549.72.0.00589705304437.issue18011@psf.upfronthosting.co.za> Message-ID: <1368958282.85.0.792373415567.issue18011@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which changes TypeError to binascii.Error in b32decode() and fixes the documentation and tests. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file30310/b32decode_exception.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 12:14:26 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 May 2013 10:14:26 +0000 Subject: [issue18011] Inconsistency between b32decode() documentation, docstring and code In-Reply-To: <1368951549.72.0.00589705304437.issue18011@psf.upfronthosting.co.za> Message-ID: <1368958466.65.0.562178951303.issue18011@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which changes TypeError to binascii.Error in b32decode() and fixes the documentation and tests. ---------- Added file: http://bugs.python.org/file30311/b32decode_exception.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 12:15:54 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 May 2013 10:15:54 +0000 Subject: [issue18011] Inconsistency between b32decode() documentation, docstring and code In-Reply-To: <1368951549.72.0.00589705304437.issue18011@psf.upfronthosting.co.za> Message-ID: <1368958554.86.0.475737983743.issue18011@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- Removed message: http://bugs.python.org/msg189577 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 12:16:05 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 May 2013 10:16:05 +0000 Subject: [issue18011] Inconsistency between b32decode() documentation, docstring and code In-Reply-To: <1368951549.72.0.00589705304437.issue18011@psf.upfronthosting.co.za> Message-ID: <1368958565.69.0.461078746879.issue18011@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file30311/b32decode_exception.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 13:09:13 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 May 2013 11:09:13 +0000 Subject: [issue17844] Add link to alternatives for bytes-to-bytes codecs In-Reply-To: <1366889842.88.0.0886939266057.issue17844@psf.upfronthosting.co.za> Message-ID: <1368961753.01.0.721870020987.issue17844@psf.upfronthosting.co.za> Nick Coghlan added the comment: I like this, both because it quite clearly defines the encode and decode directions, and allows notes the more direct entry points if the codec isn't being specified as an input string. So +1 from me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 13:31:36 2013 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sun, 19 May 2013 11:31:36 +0000 Subject: [issue17844] Add link to alternatives for bytes-to-bytes codecs In-Reply-To: <1368961753.01.0.721870020987.issue17844@psf.upfronthosting.co.za> Message-ID: <5198B80F.4090705@egenix.com> Marc-Andre Lemburg added the comment: Not a bad idea. More information is always better when it comes to documentation :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 13:39:03 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 May 2013 11:39:03 +0000 Subject: [issue17839] base64 module should use memoryview In-Reply-To: <1366875154.79.0.0782227735295.issue17839@psf.upfronthosting.co.za> Message-ID: <1368963543.39.0.147334449636.issue17839@psf.upfronthosting.co.za> Nick Coghlan added the comment: Oops, my review comments don't actually make sense because I looked at the patch in isolation, rather than checking the full context in the module. Sorry about that. We have 2 different cases to deal with, only one of which currently has a helper function. I suggest renaming _bytes_from_decode_data to "_bytes_for_decoding" and adding "_bytes_for_encoding". The difference between them is the implicit encoding of pure ASCII strings to bytes in the decoding case and the details of the error message thrown. The encoding and decoding functions should then use the appropriate coercion helper for both the input data and for altchars. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 13:52:08 2013 From: report at bugs.python.org (Etienne Robillard) Date: Sun, 19 May 2013 11:52:08 +0000 Subject: [issue17085] test_socket crashes the whole test suite In-Reply-To: <1359580628.83.0.173179383331.issue17085@psf.upfronthosting.co.za> Message-ID: <1368964328.71.0.663852370747.issue17085@psf.upfronthosting.co.za> Etienne Robillard added the comment: since TIPC is silently included in python 2.7.3 and recents kernel memory leaks were found in the linux TIPC kernel code, could this result in info disclosure in python when compiled with TIPC ? does the kernel module needs to be loaded to exploit the memleaks from within python ? http://www.openwall.com/lists/oss-security/2013/04/14/3 ---------- nosy: +erob _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 14:21:34 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 19 May 2013 12:21:34 +0000 Subject: [issue12082] Python/import.c still references fstat even with DONT_HAVE_FSTAT/!HAVE_FSTAT In-Reply-To: <1305503118.99.0.0671211382341.issue12082@psf.upfronthosting.co.za> Message-ID: <1368966094.28.0.0656360189268.issue12082@psf.upfronthosting.co.za> Antoine Pitrou added the comment: For those of you who are concerned with this issue, could you explain your use case on the following discussion thread: http://mail.python.org/pipermail/python-dev/2013-May/126285.html ? I would personally like to remove HAVE_FSTAT and make Python unconditionally use fstat(). It will make the code quite simpler in some places. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 14:21:38 2013 From: report at bugs.python.org (R. David Murray) Date: Sun, 19 May 2013 12:21:38 +0000 Subject: [issue16805] when building docs on Debian 7 --> ERROR: Error in "note" directive In-Reply-To: <1356739435.76.0.304211925624.issue16805@psf.upfronthosting.co.za> Message-ID: <1368966098.96.0.577684692629.issue16805@psf.upfronthosting.co.za> R. David Murray added the comment: Tshepang: see the 'Development Cycle' section of the devguide. Only security related commits are allowed to security branches, and since the docs are part of the source tree, that means no doc commits. One reason for this is the same reason we only have one maintenance release (ignoring 2.7, it is an exception), and is a matter of practicality: reducing the load on developers. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 14:51:31 2013 From: report at bugs.python.org (R. David Murray) Date: Sun, 19 May 2013 12:51:31 +0000 Subject: [issue10766] optparse uses %s in gettext calls In-Reply-To: <1293148753.14.0.11198082887.issue10766@psf.upfronthosting.co.za> Message-ID: <1368967891.37.0.420603379076.issue10766@psf.upfronthosting.co.za> R. David Murray added the comment: The #4391 fixes were only applied to the development branch. So these could be applied to 3.4 at this point, but not 3.3. ---------- nosy: +r.david.murray status: -> open versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 15:01:43 2013 From: report at bugs.python.org (R. David Murray) Date: Sun, 19 May 2013 13:01:43 +0000 Subject: [issue11011] More functools functions In-Reply-To: <1295994742.19.0.341586360497.issue11011@psf.upfronthosting.co.za> Message-ID: <1368968503.06.0.350139488745.issue11011@psf.upfronthosting.co.za> R. David Murray added the comment: By my reading compose was also rejected, so I'm going to close this. (See issue 1506122 for one previous rejection of compose.) ---------- nosy: +r.david.murray resolution: -> rejected stage: -> committed/rejected status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 15:11:53 2013 From: report at bugs.python.org (R. David Murray) Date: Sun, 19 May 2013 13:11:53 +0000 Subject: [issue9856] Change object.__format__(s) where s is non-empty to a TypeError In-Reply-To: <1284485218.75.0.159147258754.issue9856@psf.upfronthosting.co.za> Message-ID: <1368969113.92.0.480618160866.issue9856@psf.upfronthosting.co.za> R. David Murray added the comment: Since Eric indicated he'd close this unless someone felt strongly that the status quo should be changed, and the arguments are in favor of *maintaining* the status quo, I'm going to close this for him :) ---------- nosy: +r.david.murray resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 15:28:24 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sun, 19 May 2013 13:28:24 +0000 Subject: [issue16805] when building docs on Debian 7 --> ERROR: Error in "note" directive In-Reply-To: <1356739435.76.0.304211925624.issue16805@psf.upfronthosting.co.za> Message-ID: <1368970104.06.0.901635239436.issue16805@psf.upfronthosting.co.za> Tshepang Lekhonkhobe added the comment: @murray thanks for the clarification; I saw that part of the devguide, but wasn't sure if doc fixes/improvements were exempt (even if not mentioned) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 15:33:15 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 19 May 2013 13:33:15 +0000 Subject: [issue17085] test_socket crashes the whole test suite In-Reply-To: <1359580628.83.0.173179383331.issue17085@psf.upfronthosting.co.za> Message-ID: <1368970395.11.0.481398717555.issue17085@psf.upfronthosting.co.za> Antoine Pitrou added the comment: ddvento, I'm afraid you'll have to diagnose a bit more by tracing what happens during test_sendall_interrupted and test_sendall_interrupted_with_timeout. These test cases have a legitimate use for arming an alarm signal, but for some reason it seems the signal is triggered after those tests finish. Try printing exactly what happens at each step in those tests. Etienne, I'm not sure what the issue specifically is. Is Linux TIPC has a memory leak issue, it isn't really Python's problem. If any case, it is a separate issue and therefore should be discussed on a separate bug entry. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 15:46:46 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 19 May 2013 13:46:46 +0000 Subject: [issue11995] test_pydoc loads all Python modules In-Reply-To: <1304497766.98.0.489430644994.issue11995@psf.upfronthosting.co.za> Message-ID: <3bD4KK2P2YzSlk@mail.python.org> Roundup Robot added the comment: New changeset 58ace614df6b by Antoine Pitrou in branch '3.3': Issue #11995: test_pydoc doesn't import all sys.path modules anymore. http://hg.python.org/cpython/rev/58ace614df6b New changeset 13d817cb72e7 by Antoine Pitrou in branch 'default': Issue #11995: test_pydoc doesn't import all sys.path modules anymore. http://hg.python.org/cpython/rev/13d817cb72e7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 15:51:21 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 19 May 2013 13:51:21 +0000 Subject: [issue11995] test_pydoc loads all Python modules In-Reply-To: <1304497766.98.0.489430644994.issue11995@psf.upfronthosting.co.za> Message-ID: <3bD4Qc52H6zSSQ@mail.python.org> Roundup Robot added the comment: New changeset 68d2337688c1 by Antoine Pitrou in branch '2.7': Issue #11995: test_pydoc doesn't import all sys.path modules anymore. http://hg.python.org/cpython/rev/68d2337688c1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 15:52:12 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 19 May 2013 13:52:12 +0000 Subject: [issue11995] test_pydoc loads all Python modules In-Reply-To: <1304497766.98.0.489430644994.issue11995@psf.upfronthosting.co.za> Message-ID: <1368971532.51.0.9958967078.issue11995@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 16:04:28 2013 From: report at bugs.python.org (Torsten Bronger) Date: Sun, 19 May 2013 14:04:28 +0000 Subject: [issue4470] smtplib SMTP_SSL not working. In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za> Message-ID: <1368972268.31.0.298954718102.issue4470@psf.upfronthosting.co.za> Torsten Bronger added the comment: For five Ubuntu releases now, I apply this patch. In contrast to Catalin's statement, it is not solved for me unless the upstream changes of two years ago haven't yet found their way into Ubuntu. I'm currently using Python 2.7.4 on Ubuntu 13.04. That said, the patch solves my issue every time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 16:07:00 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 19 May 2013 14:07:00 +0000 Subject: [issue18003] New lzma crazy slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1368972420.6.0.139242466915.issue18003@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I second Serhiy here. Wrapping the LZMAFile in a BufferedReader is the simple solution to the performance problem: ./python -m timeit -s "import lzma, io" "f=lzma.LZMAFile('words.xz', 'r')" "for line in f: pass" 10 loops, best of 3: 148 msec per loop $ ./python -m timeit -s "import lzma, io" "f=io.BufferedReader(lzma.LZMAFile('words.xz', 'r'))" "for line in f: pass" 10 loops, best of 3: 44.3 msec per loop $ time xzcat words.xz | wc -l 99156 real 0m0.021s user 0m0.016s sys 0m0.004s Perhaps the top-level lzma.open() should do the wrapping for you, though. Interestingly, opening in text (i.e. unicode) mode is almost as fast as with a BufferedReader: $ ./python -m timeit -s "import lzma, io" "f=lzma.open('words.xz', 'rt')" "for line in f: pass" 10 loops, best of 3: 51.1 msec per loop ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 16:11:21 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 19 May 2013 14:11:21 +0000 Subject: [issue4470] smtplib SMTP_SSL not working. In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za> Message-ID: <1368972681.29.0.469928367797.issue4470@psf.upfronthosting.co.za> Antoine Pitrou added the comment: When you say "I apply this patch", you mean smtplib_05_shutdown_socket_v2.patch, right? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 16:12:19 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 19 May 2013 14:12:19 +0000 Subject: [issue4470] smtplib SMTP_SSL not working. In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za> Message-ID: <1368972739.87.0.673190100284.issue4470@psf.upfronthosting.co.za> Antoine Pitrou added the comment: In any case, I'm growing wary of bugfix regressions right now, so I would only apply the patch on the default branch. ---------- versions: +Python 3.4 -Python 2.6, Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 16:17:57 2013 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 19 May 2013 14:17:57 +0000 Subject: [issue18012] cannot assign unicode keys to SimpleCookie Message-ID: <1368973077.46.0.479375460496.issue18012@psf.upfronthosting.co.za> New submission from Florent Xicluna: from Cookie import SimpleCookie cookie = SimpleCookie() cookie[u'apple'] = u'green' Traceback (most recent call last): File "", line 1, in File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/Cookie.py", line 592, in __setitem__ self.__set(key, rval, cval) File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/Cookie.py", line 585, in __set M.set(key, real_value, coded_value) File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/Cookie.py", line 459, in set if "" != translate(key, idmap, LegalChars): File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/string.py", line 493, in translate return s.translate(table, deletions) TypeError: translate() takes exactly one argument (2 given) The documentation don't say it's not supported. And the error TypeError seems not appropriate. ---------- components: Library (Lib) messages: 189595 nosy: flox priority: normal severity: normal status: open title: cannot assign unicode keys to SimpleCookie type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 16:25:58 2013 From: report at bugs.python.org (R. David Murray) Date: Sun, 19 May 2013 14:25:58 +0000 Subject: [issue18012] cannot assign unicode keys to SimpleCookie In-Reply-To: <1368973077.46.0.479375460496.issue18012@psf.upfronthosting.co.za> Message-ID: <1368973558.56.0.855504114696.issue18012@psf.upfronthosting.co.za> R. David Murray added the comment: Python2 tends to document where unicode *is* supported, rather than where it is not. And why would a TypeError be incorrect if the unicode type is not supported? I do not think it likely that this falls into the 'bug' category at this point in the Python2 lifecycle. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 16:49:26 2013 From: report at bugs.python.org (Torsten Bronger) Date: Sun, 19 May 2013 14:49:26 +0000 Subject: [issue4470] smtplib SMTP_SSL not working. In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za> Message-ID: <1368974966.61.0.962129294358.issue4470@psf.upfronthosting.co.za> Torsten Bronger added the comment: Sorry, after having had another look at it, I realised that I have a different SSMTP issue now, non-Python-related. So for me, Ubuntu 13.04 indeed solves my old issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 16:49:51 2013 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 19 May 2013 14:49:51 +0000 Subject: [issue18012] cannot assign unicode keys to SimpleCookie In-Reply-To: <1368973077.46.0.479375460496.issue18012@psf.upfronthosting.co.za> Message-ID: <1368974991.31.0.0695025152428.issue18012@psf.upfronthosting.co.za> Florent Xicluna added the comment: you're right, this behavior is documented. >>> u'read this short text'.translate(None, 'aeiou') Traceback (most recent call last): File "", line 1, in TypeError: translate() takes exactly one argument (2 given) >>> http://docs.python.org/2/library/stdtypes.html#str.translate ---------- resolution: -> invalid status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 17:19:52 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 19 May 2013 15:19:52 +0000 Subject: [issue5811] io.BufferedReader.peek(): Documentation differs from Implementation In-Reply-To: <1240380953.7.0.732520909261.issue5811@psf.upfronthosting.co.za> Message-ID: <1368976792.83.0.337546798183.issue5811@psf.upfronthosting.co.za> Mark Lawrence added the comment: Looks like this has slipped under the radar. I'll leave working on it to the experts :) ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 17:23:24 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 19 May 2013 15:23:24 +0000 Subject: [issue6237] Build errors when using LDFLAGS="-Wl,--no-undefined" In-Reply-To: <1244428013.0.0.0482442850802.issue6237@psf.upfronthosting.co.za> Message-ID: <1368977004.57.0.845349789946.issue6237@psf.upfronthosting.co.za> Mark Lawrence added the comment: Is this build issue still a problem some four years on? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 17:29:42 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 19 May 2013 15:29:42 +0000 Subject: [issue3559] Pasted \n not same as typed \n In-Reply-To: <1218778489.95.0.525643042727.issue3559@psf.upfronthosting.co.za> Message-ID: <1368977382.59.0.169145437406.issue3559@psf.upfronthosting.co.za> Mark Lawrence added the comment: Could we borrow code from the ipython %paste command? This issue is also referenced from #5124. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 17:34:11 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 19 May 2013 15:34:11 +0000 Subject: [issue2276] distutils out-of-date for runtime_library_dirs flag on OS X In-Reply-To: <1205290203.53.0.517851484238.issue2276@psf.upfronthosting.co.za> Message-ID: <1368977651.11.0.257354780431.issue2276@psf.upfronthosting.co.za> Mark Lawrence added the comment: Is this still a problem or not? If yes what can be done about it? If no can we close it? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 17:51:23 2013 From: report at bugs.python.org (Roger Serwy) Date: Sun, 19 May 2013 15:51:23 +0000 Subject: [issue3559] Pasted \n not same as typed \n In-Reply-To: <1218778489.95.0.525643042727.issue3559@psf.upfronthosting.co.za> Message-ID: <1368978683.56.0.590435999894.issue3559@psf.upfronthosting.co.za> Roger Serwy added the comment: The core problem is that IDLE only executes the shell buffer when the <> virtual event gets sent by physically pressing the Enter key. Pasting the clipboard contents with \n will not trigger the enter_callback function in Lib/idlelib/PyShell.py. The MultiLineRun.py extension as part of IdleX intercepts the pasted text and splits the buffer on '\n' and then runs each line. Mark, what you are suggesting is adding something like a "Paste and Execute" option for the shell and its right-click menu which mimics the %paste magic from IPython. That's doable. ---------- nosy: +roger.serwy versions: +Python 2.7, Python 3.3, Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 18:20:45 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 19 May 2013 16:20:45 +0000 Subject: [issue17988] ElementTree.Element != ElementTree._ElementInterface In-Reply-To: <1368657583.19.0.922119818205.issue17988@psf.upfronthosting.co.za> Message-ID: <1368980445.77.0.0676708610836.issue17988@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 18:21:01 2013 From: report at bugs.python.org (Roundup Robot) Date: Sun, 19 May 2013 16:21:01 +0000 Subject: [issue17988] ElementTree.Element != ElementTree._ElementInterface In-Reply-To: <1368657583.19.0.922119818205.issue17988@psf.upfronthosting.co.za> Message-ID: <3bD7lJ3CZzz7Lkj@mail.python.org> Roundup Robot added the comment: New changeset 16a03959819a by Eli Bendersky in branch 'default': Issue #17988: remove unused alias for Element and rename the used one http://hg.python.org/cpython/rev/16a03959819a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 18:21:48 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 19 May 2013 16:21:48 +0000 Subject: [issue17988] ElementTree.Element != ElementTree._ElementInterface In-Reply-To: <1368657583.19.0.922119818205.issue17988@psf.upfronthosting.co.za> Message-ID: <1368980508.41.0.60149519366.issue17988@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 18:49:14 2013 From: report at bugs.python.org (Michael Fox) Date: Sun, 19 May 2013 16:49:14 +0000 Subject: [issue18003] New lzma crazy slow with line-oriented reading. In-Reply-To: <1368972420.6.0.139242466915.issue18003@psf.upfronthosting.co.za> Message-ID: Michael Fox added the comment: io.BufferedReader works well for me. Thanks for the good suggestion. Now python 3.3 and 3.4 have similar performance to each other and they are only 2x slower than pyliblzma. >From my perspective default wrapping with io.BufferedReader is a great idea. I can't think of who would suffer. Maybe someone who wants to open thousands of simultaneous streams wouldn't appreciate the memory overhead. If that person exists then he would want an option to turn it off. m at air:~/q/topaz/parse_datalog$ time python2 lzmaperf.py 102368 real 0m0.049s user 0m0.040s sys 0m0.008s m at air:~/q/topaz/parse_datalog$ time python3 lzmaperf.py 102368 real 0m0.109s user 0m0.092s sys 0m0.020s m at air:~/q/topaz/parse_datalog$ time ~/tmp/cpython-23836f17e4a2/bin/python3 lzmaperf.py 102368 real 0m0.101s user 0m0.084s sys 0m0.012s On Sun, May 19, 2013 at 7:07 AM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > I second Serhiy here. Wrapping the LZMAFile in a BufferedReader is the simple solution to the performance problem: > > ./python -m timeit -s "import lzma, io" "f=lzma.LZMAFile('words.xz', 'r')" "for line in f: pass" > 10 loops, best of 3: 148 msec per loop > > $ ./python -m timeit -s "import lzma, io" "f=io.BufferedReader(lzma.LZMAFile('words.xz', 'r'))" "for line in f: pass" > 10 loops, best of 3: 44.3 msec per loop > > $ time xzcat words.xz | wc -l > 99156 > > real 0m0.021s > user 0m0.016s > sys 0m0.004s > > > Perhaps the top-level lzma.open() should do the wrapping for you, though. > Interestingly, opening in text (i.e. unicode) mode is almost as fast as with a BufferedReader: > > $ ./python -m timeit -s "import lzma, io" "f=lzma.open('words.xz', 'rt')" "for line in f: pass" > 10 loops, best of 3: 51.1 msec per loop > > ---------- > nosy: +pitrou > > _______________________________________ > Python tracker > > _______________________________________ -- - Michael ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 19:00:32 2013 From: report at bugs.python.org (Shriramana Sharma) Date: Sun, 19 May 2013 17:00:32 +0000 Subject: [issue6294] Improve shutdown exception ignored message In-Reply-To: <1245196911.61.0.437199244327.issue6294@psf.upfronthosting.co.za> Message-ID: <1368982832.45.0.250002629153.issue6294@psf.upfronthosting.co.za> Changes by Shriramana Sharma : ---------- nosy: +jamadagni _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 19:08:37 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 19 May 2013 17:08:37 +0000 Subject: [issue14097] Improve the "introduction" page of the tutorial In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za> Message-ID: <1368983317.6.0.419322951055.issue14097@psf.upfronthosting.co.za> Ezio Melotti added the comment: Here is an updated patch. ---------- Added file: http://bugs.python.org/file30312/issue14097-3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 19:24:09 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 19 May 2013 17:24:09 +0000 Subject: [issue14097] Improve the "introduction" page of the tutorial In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za> Message-ID: <1368984249.42.0.594318690019.issue14097@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Please restore the section "A value can be assigned to several variables simultaneously". This is easy to teach in this context and there's no other good place to put it. Also, I'm unclear why you took out the Mark Lemburg's section on Unicode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 19:44:26 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 19 May 2013 17:44:26 +0000 Subject: [issue14097] Improve the "introduction" page of the tutorial In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za> Message-ID: <1368985466.18.0.546302957148.issue14097@psf.upfronthosting.co.za> Ezio Melotti added the comment: > Please restore the section "A value can be assigned to several > variables simultaneously". The reason for removing it are: * generally it's not really useful/used IMHO; * it has potentially confusing side effects (e.g. x = y = 0 is the same as x = 0; y = 0, but a = b = [] is not the same as a = []; b = []); * and more confusing side effects (http://mail.python.org/pipermail/python-dev/2012-November/122552.html ;); IOW I think that teaching this (especially at this point of the tutorial where you can't/shouldn't yet explain the side effects) does more harm than good. It could be mentioned later in the tutorial when object identity is explained in more detail (I'm planning to work on this next), and should be also covered in the language reference (if it's not there already). > Also, I'm unclear why you took out the Mark Lemburg's section > on Unicode. I'm planning to write something about Unicode when bytes are introduced. That section has been written with Python 2 in mind, where byte strings are the default but "there are also Unicode strings". For Python 3, users already naturally associate strings with text and explaining the text/bytes dichotomy and Unicode can be postponed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 19:45:09 2013 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 19 May 2013 17:45:09 +0000 Subject: [issue18013] cgi.FieldStorage does not parse W3C sample Message-ID: <1368985509.82.0.0767956747913.issue18013@psf.upfronthosting.co.za> New submission from Florent Xicluna: Trying to parse the W3C sample, it fails in 3.3 (while it passes on 2.7). http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4 (last example) Content-Type: multipart/form-data; boundary=AaB03x --AaB03x Content-Disposition: form-data; name="submit-name" Larry --AaB03x Content-Disposition: form-data; name="files" Content-Type: multipart/mixed; boundary=BbC04y --BbC04y Content-Disposition: file; filename="file1.txt" Content-Type: text/plain ... contents of file1.txt ... --BbC04y Content-Disposition: file; filename="file2.gif" Content-Type: image/gif Content-Transfer-Encoding: binary ...contents of file2.gif... --BbC04y-- --AaB03x-- (broken) test attached. ---------- components: Library (Lib) files: test_multipart_w3.diff keywords: patch messages: 189609 nosy: flox, orsenthil priority: normal severity: normal status: open title: cgi.FieldStorage does not parse W3C sample type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file30313/test_multipart_w3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 19:45:49 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 19 May 2013 17:45:49 +0000 Subject: [issue18013] cgi.FieldStorage does not parse W3C sample In-Reply-To: <1368985509.82.0.0767956747913.issue18013@psf.upfronthosting.co.za> Message-ID: <1368985549.24.0.960860866236.issue18013@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 19:51:40 2013 From: report at bugs.python.org (Anselm Kruis) Date: Sun, 19 May 2013 17:51:40 +0000 Subject: [issue15535] Fix pickling efficiency of named tuples in 2.7.3 In-Reply-To: <1343915086.31.0.252328658724.issue15535@psf.upfronthosting.co.za> Message-ID: <1368985900.66.0.63944596455.issue15535@psf.upfronthosting.co.za> Anselm Kruis added the comment: >> why the different fix for 3.3 > > I reverted the 2.7.4 addition of __dict__ rather than introduce more > differences between point releases with possible unintended effects. __dict__ was a 2.7.3 addition (changeset 26d5f022eb1a). Now unpickling of named tuples created by 2.7.3 and 2.7.4 fails. ---------- nosy: +anselm.kruis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 19:52:20 2013 From: report at bugs.python.org (Nadeem Vawda) Date: Sun, 19 May 2013 17:52:20 +0000 Subject: [issue18003] New lzma crazy slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1368985940.65.0.0946283632411.issue18003@psf.upfronthosting.co.za> Nadeem Vawda added the comment: I agree that making lzma.open() wrap its return value in a BufferedReader (or BufferedWriter, as appropriate) is the way to go. I'm currently travelling and don't have my SSH key with me - Serhiy, can you make the change? I'll put together a documentation patch that recommends using lzma.open() rather than LZMAFile directly, and mentions the performance implications. > Interestingly, opening in text (i.e. unicode) mode is almost as fast as with a BufferedReader: This is because opening in text mode returns a TextIOWrapper, which is written in C, and presumably does its own buffering on top of LZMAFile.read1() instead of calling LZMAFile.readline(). > From my perspective default wrapping with io.BufferedReader is a great > idea. I can't think of who would suffer. Maybe someone who wants to > open thousands of simultaneous streams wouldn't appreciate the memory > overhead. If that person exists then he would want an option to turn > it off. If someone doesn't want the BufferedReader/BufferedWriter, they can create an LZMAFile directly; we don't plan to remove that possibility. So I don't think that should be a problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 19:53:15 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 19 May 2013 17:53:15 +0000 Subject: [issue18014] Problem compiling on Windows, VC++Express 2010 Message-ID: <1368985995.62.0.842732310972.issue18014@psf.upfronthosting.co.za> New submission from Terry J. Reedy: 64-bit Win 7 Professional, using default F7 debug build -- F7 Running as normal user, not admin. 3.4: built Thursday, Saturday; failed Wednesday, Friday, today Sunday. 7> cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL -D_DEBUG -MDd -DHGBRANCH=\"default\" -DHGTAG=\"tip\" -DHGVERSION=\"79bf4e7e4004\" ..\Modules\getbuildinfo.c -Fo"D:\Python\dev\cpython\PCbuild\Win32-temp-Debug\pythoncore\getbuildinfo.o" -I..\Include -I..\PC 7> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 7> Copyright (C) Microsoft Corporation. All rights reserved. 7> 7> getbuildinfo.c 7>LINK : fatal error LNK1104: cannot open file 'D:\Python\dev\cpython\PCbuild\python34_d.dll' I 'updated' back about 24 hours to rev 83828: worked. Forward to rev 83829: failed. This made no sense so back to '28: failed. Delete python34_d.dll: works. Update to tip: works. Try again: fails. What I believe to be the case: if python34_d.dll is rebuilt, python_d.exe is built. If not, it 'cannot be opened' even though it is sitting there. I cannot be sure if this was always the case as I did not try to rebuild very ofter. -- 3.3 I have not been able to rebuild python_d.exe since May 7. I currently get 7>..\PC\pylauncher.rc(16): error RC2104: undefined keyword or key name: FIELD3 (for pywlauncher project) 10>..\PC\pylauncher.rc(16): error RC2104: undefined keyword or key name: FIELD3 9>..\PC\python_nt.rc(35): error RC2104: undefined keyword or key name: MS_DLL_ID (for pythoncore project) Failure of pythoncore stops the dependent projects. I have no idea how I might work around this. ---------- components: Build, Windows messages: 189612 nosy: brian.curtin, steve.dower, terry.reedy, tim.golden priority: normal severity: normal status: open title: Problem compiling on Windows, VC++Express 2010 type: compile error versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 20:29:23 2013 From: report at bugs.python.org (R. David Murray) Date: Sun, 19 May 2013 18:29:23 +0000 Subject: [issue18013] cgi.FieldStorage does not parse W3C sample In-Reply-To: <1368985509.82.0.0767956747913.issue18013@psf.upfronthosting.co.za> Message-ID: <1368988163.61.0.690147026982.issue18013@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 20:33:29 2013 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 19 May 2013 18:33:29 +0000 Subject: [issue18013] cgi.FieldStorage does not parse W3C sample In-Reply-To: <1368985509.82.0.0767956747913.issue18013@psf.upfronthosting.co.za> Message-ID: <1368988409.75.0.334856422273.issue18013@psf.upfronthosting.co.za> Florent Xicluna added the comment: At first glance it seems related to rev d864328a74e4 , issue 4953 The check on self.bytes_read >= self.length returns True because length == -1. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 20:39:41 2013 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 19 May 2013 18:39:41 +0000 Subject: [issue18013] cgi.FieldStorage does not parse W3C sample In-Reply-To: <1368985509.82.0.0767956747913.issue18013@psf.upfronthosting.co.za> Message-ID: <1368988781.0.0.61382933743.issue18013@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- versions: +Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 20:41:59 2013 From: report at bugs.python.org (Anselm Kruis) Date: Sun, 19 May 2013 18:41:59 +0000 Subject: [issue18015] python 2.7.5 fails to unpickle namedtuple pickled by 2.7.3 or 2.7.4 Message-ID: <1368988919.46.0.250713350438.issue18015@psf.upfronthosting.co.za> New submission from Anselm Kruis: Change 18303391b981 breaks unpickling named tuples pickled by 2.7.3 and 2.7.4. See closed issue #15535 for the full story. Unfortunately Raymond was wrong, when he wrote that the addition of __dict__ was a 2.7.4 change. It was added by changeset 26d5f022eb1a in 2.7.3. Now 2.7.5 can't unpickle any named tuples pickled by 2.7.3, which is probably one of the most widely used python versions. Example: Pickle a namd tuple using 2.7.3 and unpickle it using 2.7.5. anselm at Emmy:~$ python2.7 Python 2.7.3 (default, Sep 16 2012, 21:46:37) [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import collections >>> import pickletools >>> import pickle >>> N=collections.namedtuple("N","a") >>> n=N(1) >>> p=pickle.dumps(n, 2) >>> p2=pickletools.optimize(p) >>> pickletools.dis(p2) 0: \x80 PROTO 2 2: c GLOBAL '__main__ N' 14: K BININT1 1 16: \x85 TUPLE1 17: \x81 NEWOBJ 18: c GLOBAL 'collections OrderedDict' 43: ] EMPTY_LIST 44: ] EMPTY_LIST 45: ( MARK 46: U SHORT_BINSTRING 'a' 49: K BININT1 1 51: e APPENDS (MARK at 45) 52: a APPEND 53: \x85 TUPLE1 54: R REDUCE 55: b BUILD 56: . STOP highest protocol among opcodes = 2 >>> print repr(p2) '\x80\x02c__main__\nN\nK\x01\x85\x81ccollections\nOrderedDict\n]](U\x01aK\x01ea\x85Rb.' anselm at Emmy:~/sc/eclipsews/fg2py$ fg2python Python 2.7.5 (default, May 18 2013, 17:02:17) [GCC 4.1.2 20080704 (Red Hat 4.1.2-44)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle >>> import collections >>> N=collections.namedtuple("N","a") >>> pickle.loads('\x80\x02c__main__\nN\nK\x01\x85\x81ccollections\nOrderedDict\n]](U\x01aK\x01ea\x85Rb.') Traceback (most recent call last): File "", line 1, in File "/home/anselm/sc/eclipsews/fg2py/arch/rhel4u4-x86_64/lib/python2.7/pickle.py", line 1419, in loads return Unpickler(file).load() File "/home/anselm/sc/eclipsews/fg2py/arch/rhel4u4-x86_64/lib/python2.7/pickle.py", line 895, in load dispatch[key](self) File "/home/anselm/sc/eclipsews/fg2py/arch/rhel4u4-x86_64/lib/python2.7/pickle.py", line 1261, in load_build d = inst.__dict__ AttributeError: 'N' object has no attribute '__dict__' As we can see from the trace back, the problem arises from the pickle op-code 'BUILD'. BUILD requires that the object to be build either has a method __setstate__ or has an attribute __dict__. Therefore I propose: - Revert change 18303391b981 and add a __getstate__ method This is the Python 3 fix for the problem. or - Add a method __setstate__: def __setstate__(self, state): """For compatibility with Python 2.7.3 and 2.7.4""" pass ---------- components: Library (Lib) messages: 189614 nosy: anselm.kruis, rhettinger priority: normal severity: normal status: open title: python 2.7.5 fails to unpickle namedtuple pickled by 2.7.3 or 2.7.4 type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 20:49:18 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 19 May 2013 18:49:18 +0000 Subject: [issue16805] when building docs on Debian 7 --> ERROR: Error in "note" directive In-Reply-To: <1356739435.76.0.304211925624.issue16805@psf.upfronthosting.co.za> Message-ID: <1368989358.47.0.389587565814.issue16805@psf.upfronthosting.co.za> ?ric Araujo added the comment: An additional reason is that docs of branches in security mode are not rebuilt and published, so changes would be useless. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 20:50:56 2013 From: report at bugs.python.org (Nadeem Vawda) Date: Sun, 19 May 2013 18:50:56 +0000 Subject: [issue18003] New lzma crazy slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1368989456.71.0.0894411600818.issue18003@psf.upfronthosting.co.za> Nadeem Vawda added the comment: > I agree that making lzma.open() wrap its return value in a BufferedReader > (or BufferedWriter, as appropriate) is the way to go. On second thoughts, there's no need to change the behavior for mode='wb'. We can just return a BufferedReader for mode='rb', and leave the current behavior (returning a raw LZMAFile) in place for mode='wb'. I also ran some additional benchmarks for the bz2 and gzip modules. It looks like those two modules would also benefit from having their open() functions use io.BufferedReader: [lzma] $ time xzcat src.xz | wc -l 1057980 real 0m0.543s user 0m0.556s sys 0m0.024s $ ../cpython/python -m timeit -s 'import lzma, io' 'f = lzma.open("src.xz", "r")' 'for line in f: pass' 10 loops, best of 3: 2.01 sec per loop $ ../cpython/python -m timeit -s 'import lzma, io' 'f = io.BufferedReader(lzma.open("src.xz", "r"))' 'for line in f: pass' 10 loops, best of 3: 795 msec per loop [bz2] $ time bzcat src.bz2 | wc -l 1057980 real 0m1.322s user 0m1.324s sys 0m0.044s $ ../cpython/python -m timeit -s 'import bz2, io' 'f = bz2.open("src.bz2", "r")' 'for line in f: pass' 10 loops, best of 3: 3.71 sec per loop $ ../cpython/python -m timeit -s 'import bz2, io' 'f = io.BufferedReader(bz2.open("src.bz2", "r"))' 'for line in f: pass' 10 loops, best of 3: 2.04 sec per loop [gzip] $ time zcat src.gz | wc -l 1057980 real 0m0.310s user 0m0.296s sys 0m0.028s $ ../cpython/python -m timeit -s 'import gzip, io' 'f = gzip.open("src.gz", "r")' 'for line in f: pass' 10 loops, best of 3: 1.94 sec per loop $ ../cpython/python -m timeit -s 'import gzip, io' 'f = io.BufferedReader(gzip.open("src.gz", "r"))' 'for line in f: pass' 10 loops, best of 3: 556 msec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 20:52:24 2013 From: report at bugs.python.org (R. David Murray) Date: Sun, 19 May 2013 18:52:24 +0000 Subject: [issue4470] smtplib SMTP_SSL not working. In-Reply-To: <1228062214.03.0.955455415588.issue4470@psf.upfronthosting.co.za> Message-ID: <1368989544.21.0.263081981529.issue4470@psf.upfronthosting.co.za> R. David Murray added the comment: Lorenzo, any chance you could supply a unit test that fails without smtplib_05_shutdown_socket.diff applied? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 21:01:56 2013 From: report at bugs.python.org (Florent Xicluna) Date: Sun, 19 May 2013 19:01:56 +0000 Subject: [issue18013] cgi.FieldStorage does not parse W3C sample In-Reply-To: <1368985509.82.0.0767956747913.issue18013@psf.upfronthosting.co.za> Message-ID: <1368990116.75.0.292395877678.issue18013@psf.upfronthosting.co.za> Florent Xicluna added the comment: This seems to fix it. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file30314/patch_multipart_w3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 21:07:39 2013 From: report at bugs.python.org (Lorenzo M. Catucci) Date: Sun, 19 May 2013 19:07:39 +0000 Subject: [issue4470] smtplib SMTP_SSL not working. In-Reply-To: <1368989544.21.0.263081981529.issue4470@psf.upfronthosting.co.za> Message-ID: Lorenzo M. Catucci added the comment: On Sun, 19 May 2013, R. David Murray wrote: RDM> RDM> R. David Murray added the comment: RDM> RDM> Lorenzo, any chance you could supply a unit test that fails without RDM> smtplib_05_shutdown_socket.diff applied? RDM> It would really be a functional test, since the problem with half-open connection pile-up stems from smtp server's access control rules. To test we should setup a fake smtp server, which forbids having multiple connections from the same IP address, and connect twice in a row to the fake server. I'm not sure I'm able to implement both an smtpd.py server serving more than one connection and the client code in a race-free way in the same "unit" test. Will try in the next week. Thank you very much, lorenzo ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 21:46:21 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 19 May 2013 19:46:21 +0000 Subject: [issue7146] [PATCH] platform.uname()[4] returns 'amd64' on Windows and 'x86-64' on Linux In-Reply-To: <1255650052.62.0.822964382584.issue7146@psf.upfronthosting.co.za> Message-ID: <1368992781.81.0.969230320354.issue7146@psf.upfronthosting.co.za> Mark Lawrence added the comment: It appears from previous comments that this is not needed so can be closed. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 21:56:34 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 19 May 2013 19:56:34 +0000 Subject: [issue7262] codecs.open() + eol (windows) In-Reply-To: <1257344010.52.0.739143662559.issue7262@psf.upfronthosting.co.za> Message-ID: <1368993394.04.0.107759443092.issue7262@psf.upfronthosting.co.za> Mark Lawrence added the comment: The docs still read the same. Would someone in the know like to propose a doc patch please. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 22:03:09 2013 From: report at bugs.python.org (R. David Murray) Date: Sun, 19 May 2013 20:03:09 +0000 Subject: [issue17973] FAQ entry for: '+=' on a list inside tuple both succeeds and raises an exception In-Reply-To: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> Message-ID: <1368993789.33.0.231272669062.issue17973@psf.upfronthosting.co.za> R. David Murray added the comment: Mark, I rather like your suggestion. Do you think Guido will go for it? :) In the meantime, I've attached a rewritten version of Ronald's FAQ entry. I think the FAQ is why it fails when the extend succeeds, not why assigning to a tuple raises an error, so I revised the question and answer accordingly. ---------- components: +Documentation resolution: rejected -> stage: -> patch review status: closed -> open title: '+=' on a list inside tuple both succeeds and raises an exception -> FAQ entry for: '+=' on a list inside tuple both succeeds and raises an exception versions: +Python 3.4 Added file: http://bugs.python.org/file30315/augmented_tuple_assignment_faq.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 22:17:18 2013 From: report at bugs.python.org (R. David Murray) Date: Sun, 19 May 2013 20:17:18 +0000 Subject: [issue7146] platform.uname()[4] returns 'amd64' on Windows and 'x86-64' on Linux In-Reply-To: <1255650052.62.0.822964382584.issue7146@psf.upfronthosting.co.za> Message-ID: <1368994638.78.0.865086058317.issue7146@psf.upfronthosting.co.za> R. David Murray added the comment: Right, Marc-Andre indicates that cross-platform consistency is not a goal of the platform uname. If someone wants to propose a patch for the possible enhancement to platform that Marc-Andre talked about, they can open a new issue. ---------- nosy: +r.david.murray resolution: -> invalid stage: -> committed/rejected status: open -> closed title: [PATCH] platform.uname()[4] returns 'amd64' on Windows and 'x86-64' on Linux -> platform.uname()[4] returns 'amd64' on Windows and 'x86-64' on Linux type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 22:29:13 2013 From: report at bugs.python.org (Jason Gross) Date: Sun, 19 May 2013 20:29:13 +0000 Subject: [issue18016] subprocess should open stdin in mode w+b on windows Message-ID: <1368995353.89.0.988630901542.issue18016@psf.upfronthosting.co.za> New submission from Jason Gross: Files opened on Windows in mode 'wb' have a limit on the number of characters that can be written to them (at once?); attempting to write too many bytes gives the confusing error ?IOError: [Errno 22] Invalid argument?. See http://support.microsoft.com/default.aspx?scid=kb;en-us;899149 and http://stackoverflow.com/questions/4226941/python-ioerror-errno-22-invalid-argument-when-using-cpickle-to-write-large. I have gotten this error when using subprocess.communicate(input=). Please fix the subprocess library (and any other library that uses mode 'wb') to use mode 'w+b', at least on Windows. ---------- components: Library (Lib) messages: 189624 nosy: Jason.Gross priority: normal severity: normal status: open title: subprocess should open stdin in mode w+b on windows versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 22:56:19 2013 From: report at bugs.python.org (=?utf-8?q?Guilherme_Sim=C3=B5es?=) Date: Sun, 19 May 2013 20:56:19 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1368996979.22.0.783147004389.issue15392@psf.upfronthosting.co.za> Changes by Guilherme Sim?es : ---------- nosy: +Guilherme.Sim?es _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 19 23:39:02 2013 From: report at bugs.python.org (Joe Stuart) Date: Sun, 19 May 2013 21:39:02 +0000 Subject: [issue17989] ElementTree.Element broken attribute setting In-Reply-To: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za> Message-ID: <1368999542.13.0.27116229926.issue17989@psf.upfronthosting.co.za> Joe Stuart added the comment: Looks like a typo in arbitrary. AttributeError: Can't set arbitraty attributes on Element ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 00:05:19 2013 From: report at bugs.python.org (Alejandro Rodas) Date: Sun, 19 May 2013 22:05:19 +0000 Subject: [issue13657] IDLE doesn't support sys.ps1 and sys.ps2. In-Reply-To: <1324640742.58.0.860347532783.issue13657@psf.upfronthosting.co.za> Message-ID: <1369001119.41.0.55033312351.issue13657@psf.upfronthosting.co.za> Alejandro Rodas added the comment: I have reviewed the patch, and apart from setting the promt, I think it would be possible to set it at the beginning with the same approach: def getprompt(self): self.interp.runcommand(textwrap.dedent("""\ try: print(sys.ps1, end="") except: import sys sys.ps1, sys.ps2 = ">>> ", "... " print(sys.ps1, end="")""")) What I don't know is why ps1 and ps2 are the only attributes that are missing in the sys module within the ModifiedInterpreter. When I try InteractiveInterpreter in the original interpreter, it shows the 79 attributes that sys has originally. ---------- nosy: +alex.rodas _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 00:07:10 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 19 May 2013 22:07:10 +0000 Subject: [issue17989] ElementTree.Element broken attribute setting In-Reply-To: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za> Message-ID: <1369001230.79.0.592829550554.issue17989@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- resolution: fixed -> stage: committed/rejected -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 00:22:03 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 19 May 2013 22:22:03 +0000 Subject: [issue15535] Fix pickling efficiency of named tuples in 2.7.3 In-Reply-To: <1343915086.31.0.252328658724.issue15535@psf.upfronthosting.co.za> Message-ID: <1369002123.46.0.465355546011.issue15535@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- priority: release blocker -> normal resolution: fixed -> status: closed -> open versions: -Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 00:28:20 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 19 May 2013 22:28:20 +0000 Subject: [issue18003] New lzma crazy slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1369002500.01.0.501619969157.issue18003@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 00:33:51 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 19 May 2013 22:33:51 +0000 Subject: [issue18015] python 2.7.5 fails to unpickle namedtuple pickled by 2.7.3 or 2.7.4 In-Reply-To: <1368988919.46.0.250713350438.issue18015@psf.upfronthosting.co.za> Message-ID: <1369002831.84.0.889152609024.issue18015@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 00:57:40 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 19 May 2013 22:57:40 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1369004260.03.0.39053392204.issue15392@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I was really sure that 'python_d -m test' worked a week ago, in the sense that test_idle was run without incident in its proper alphabetical sequence, before I said so and uploaded the patch. Now, there are (different) error messages with both 'python_d -m test' and 'python_d -m test test_idle'. (I did not try the latter before, only 'python_d -m test.test_idle', with the added '.' whose importance I now understand.) One of the two error messages includes what David reported. When I can, will report the other, and also will try to 'hg update' to a week ago to reproduce the remembered success. If I cannot, I will try options to determine the boundaries of the bug in the interacton between unittest and regrtest and a decent workaround that avoids duplicating code while running under both unittest and regrtest. I sent Todd the Windows files to examine, modify, and test. (Nick: neither unittest nor regrtest can run tests hidden within patches on the tracker. However, the point is currently moot for this issue. It might someday be a python-dev or python-ideas post.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 01:04:56 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 19 May 2013 23:04:56 +0000 Subject: [issue18015] python 2.7.5 fails to unpickle namedtuple pickled by 2.7.3 or 2.7.4 In-Reply-To: <1368988919.46.0.250713350438.issue18015@psf.upfronthosting.co.za> Message-ID: <1369004696.69.0.38892461957.issue18015@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 02:00:40 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 May 2013 00:00:40 +0000 Subject: [issue17989] ElementTree.Element broken attribute setting In-Reply-To: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za> Message-ID: <3bDKxd53ldz7Lm8@mail.python.org> Roundup Robot added the comment: New changeset 65680e3a7f07 by Eli Bendersky in branch '3.3': Issue #17989: fix typo in error message http://hg.python.org/cpython/rev/65680e3a7f07 New changeset 19767536ce84 by Eli Bendersky in branch 'default': Issue #17989: fix typo in error message http://hg.python.org/cpython/rev/19767536ce84 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 02:01:03 2013 From: report at bugs.python.org (Eli Bendersky) Date: Mon, 20 May 2013 00:01:03 +0000 Subject: [issue17989] ElementTree.Element broken attribute setting In-Reply-To: <1368658011.78.0.414145744808.issue17989@psf.upfronthosting.co.za> Message-ID: <1369008063.76.0.320496995465.issue17989@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 02:38:39 2013 From: report at bugs.python.org (=?utf-8?q?Marc_Br=C3=BCnink?=) Date: Mon, 20 May 2013 00:38:39 +0000 Subject: [issue18017] ctypes.PyDLL documentation Message-ID: <1369010319.69.0.913023030404.issue18017@psf.upfronthosting.co.za> New submission from Marc Br?nink: The documentation for is not very clear regarding the usage of CDLL and PyDLL. Especially it is not obvious that you should use PyDLL whenever you call any function of the Python/C API. Since calling a Python/C API function without owning the GIL will most likely cause latent segfaults, I think it warrants a warning box in section 16.17.2.2 and maybe also somewhere prominent in http://docs.python.org/dev/c-api/intro.html. For section 16.17.2.2 I would put a box next the decription of CDLL saying something like: "The Python GIL is released before a function call. It is not safe to call any Pyhon/C API function within the loaded library without acquiring the GIL first. Thus, if the loaded library calls functions of the Python/C API, for example in case it creates and returns a new Python object, and does not manually acquire and release the GIL, use PyDLL instead." ---------- assignee: docs at python components: Documentation messages: 189629 nosy: Marc.Br?nink, docs at python priority: normal severity: normal status: open title: ctypes.PyDLL documentation versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 03:01:48 2013 From: report at bugs.python.org (Florent Xicluna) Date: Mon, 20 May 2013 01:01:48 +0000 Subject: [issue18018] SystemError: Parent module '' not loaded, cannot perform relative import Message-ID: <1369011708.43.0.213176616662.issue18018@psf.upfronthosting.co.za> New submission from Florent Xicluna: When executing a submodule, there's a SystemError in 3.3 where we used to receive a ValueError. mkdir marsu touch marsu/__init__.py echo "from .houba import bi" >> marsu/pilami.py ./python marsu/pilami.py Traceback (most recent call last): File "marsu/pilami.py", line 2, in from .houba import bi SystemError: Parent module '' not loaded, cannot perform relative import In Python 3.2 (or Python 2.7): ./python3.2 marsu/pilami.py Traceback (most recent call last): File "marsu/pilami.py", line 2, in from .houba import bi ValueError: Attempted relative import in non-package ---------- components: Interpreter Core keywords: 3.3regression messages: 189630 nosy: brett.cannon, eric.snow, flox, ncoghlan priority: normal severity: normal status: open title: SystemError: Parent module '' not loaded, cannot perform relative import type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 04:15:31 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 20 May 2013 02:15:31 +0000 Subject: [issue14097] Improve the "introduction" page of the tutorial In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za> Message-ID: <1369016131.18.0.555810416194.issue14097@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Please add the "x = y = z = 0" example back. It doesn't improve the tutorial to dumb it down or to leave out basic knowledge. You may not like the feature but it is a long standing part of the core language. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 04:18:42 2013 From: report at bugs.python.org (Marcin Szamotulski) Date: Mon, 20 May 2013 02:18:42 +0000 Subject: [issue18019] dictionary views lead to segmentation fault Message-ID: <1369016322.42.0.272832887604.issue18019@psf.upfronthosting.co.za> New submission from Marcin Szamotulski: This simple snipet will crash python: >>> d={} >>> v=d.viewvalues() >>> k=d.viewkeys() >>> d[v]=k >>> k Segmentation fault I am using python2.7. Python3.2 does not have views while .keys() and .values() methods raise RuntimeError: maximum recursion depth exceeded, which is expected. ---------- messages: 189632 nosy: Marcin.Szamotulski priority: normal severity: normal status: open title: dictionary views lead to segmentation fault type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 04:27:23 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 20 May 2013 02:27:23 +0000 Subject: [issue14097] Improve the "introduction" page of the tutorial In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za> Message-ID: <1369016843.94.0.248259972953.issue14097@psf.upfronthosting.co.za> Ezio Melotti added the comment: Is it OK if I add it back to the next page, when I explain object identity? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 04:28:35 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 20 May 2013 02:28:35 +0000 Subject: [issue18015] python 2.7.5 fails to unpickle namedtuple pickled by 2.7.3 or 2.7.4 In-Reply-To: <1368988919.46.0.250713350438.issue18015@psf.upfronthosting.co.za> Message-ID: <1369016915.6.0.0878367076013.issue18015@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- keywords: +patch Added file: http://bugs.python.org/file30316/nt_pickle_fix.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 04:30:48 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 20 May 2013 02:30:48 +0000 Subject: [issue14097] Improve the "introduction" page of the tutorial In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za> Message-ID: <1369017048.74.0.537128796073.issue14097@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Is it OK if I add it back to the next page, > when I explain object identity? Yes. That would work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 04:39:53 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 May 2013 02:39:53 +0000 Subject: [issue18019] dictionary views lead to segmentation fault In-Reply-To: <1369016322.42.0.272832887604.issue18019@psf.upfronthosting.co.za> Message-ID: <3bDPTP0MWkzSGt@mail.python.org> Roundup Robot added the comment: New changeset 3568f8f1ccac by Benjamin Peterson in branch '2.7': add missing NULL check (closes #18019) http://hg.python.org/cpython/rev/3568f8f1ccac ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 05:29:02 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 20 May 2013 03:29:02 +0000 Subject: [issue18018] SystemError: Parent module '' not loaded, cannot perform relative import In-Reply-To: <1369011708.43.0.213176616662.issue18018@psf.upfronthosting.co.za> Message-ID: <1369020542.76.0.307573278964.issue18018@psf.upfronthosting.co.za> Nick Coghlan added the comment: For the specific case given, both error messages are misleading anyway - the problem is attempting to directly execute a module inside a package instead of using "-m". However, for the case of attempting a relative import from a top level module, the old message is indeed preferable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 05:34:02 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 20 May 2013 03:34:02 +0000 Subject: [issue18018] SystemError: Parent module '' not loaded, cannot perform relative import In-Reply-To: <1369011708.43.0.213176616662.issue18018@psf.upfronthosting.co.za> Message-ID: <1369020842.38.0.978778151626.issue18018@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 06:49:33 2013 From: report at bugs.python.org (Greg Couch) Date: Mon, 20 May 2013 04:49:33 +0000 Subject: [issue734176] Make Tkinter.py's nametowidget work with cloned menu widgets In-Reply-To: <1368931796.92.0.836829707521.issue734176@psf.upfronthosting.co.za> Message-ID: <5199AB58.7040607@cgl.ucsf.edu> Greg Couch added the comment: We still apply that patch to the Python that we embed in our application and have for the last 10 years :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 07:14:26 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 May 2013 05:14:26 +0000 Subject: [issue14097] Improve the "introduction" page of the tutorial In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za> Message-ID: <3bDSvk0MCKzRwP@mail.python.org> Roundup Robot added the comment: New changeset 796d1371605d by Ezio Melotti in branch '3.3': #14097: improve the "introduction" page of the tutorial. http://hg.python.org/cpython/rev/796d1371605d New changeset 42dda22a6f8c by Ezio Melotti in branch 'default': #14097: merge with 3.3. http://hg.python.org/cpython/rev/42dda22a6f8c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 07:40:59 2013 From: report at bugs.python.org (Martin Panter) Date: Mon, 20 May 2013 05:40:59 +0000 Subject: [issue9951] introduce bytes.hex method In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1369028459.62.0.432012939135.issue9951@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 08:59:19 2013 From: report at bugs.python.org (Larry Hastings) Date: Mon, 20 May 2013 06:59:19 +0000 Subject: [issue16024] Doc cleanup regarding path=fd, dir_fd, follow_symlinks, etc In-Reply-To: <1348500599.22.0.118178834994.issue16024@psf.upfronthosting.co.za> Message-ID: <1369033159.17.0.246563669912.issue16024@psf.upfronthosting.co.za> Larry Hastings added the comment: I would, but I can't get it to apply cleanly, either to tip or to historical revisions back in Sepember. Kaleb, what revision is the branch that you generated the diff from? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 10:18:30 2013 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 May 2013 08:18:30 +0000 Subject: [issue17973] FAQ entry for: '+=' on a list inside tuple both succeeds and raises an exception In-Reply-To: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> Message-ID: <1369037910.52.0.83623858539.issue17973@psf.upfronthosting.co.za> Mark Dickinson added the comment: David: not sure. I don't think I'd go for it---I think the cure is worse than the disease. > I think the FAQ is why it fails when the extend succeeds Agreed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 10:21:38 2013 From: report at bugs.python.org (Florent Xicluna) Date: Mon, 20 May 2013 08:21:38 +0000 Subject: [issue18020] html.escape 10x slower than cgi.escape Message-ID: <1369038098.34.0.795942514317.issue18020@psf.upfronthosting.co.za> New submission from Florent Xicluna: I noticed the convenient ``html.escape`` in Python 3.2 and ``cgi.escape`` is marked as deprecated. However, the former is an order of magnitude slower than the latter. $ python3 --version Python 3.3.2 With html.escape: $ python3 -m timeit -s "from html import escape as html; from cgi import escape; s = repr(copyright)" "h = html(s)" 10000 loops, best of 3: 48.7 usec per loop $ python3 -m timeit -s "from html import escape as html; from cgi import escape; s = repr(copyright) * 19" "h = html(s)" 1000 loops, best of 3: 898 usec per loop With cgi.escape: $ python3 -m timeit -s "from html import escape as html; from cgi import escape; s = repr(copyright)" "h = escape(s)" 100000 loops, best of 3: 7.42 usec per loop $ python3 -m timeit -s "from html import escape as html; from cgi import escape; s = repr(copyright) * 19" "h = escape(s)" 10000 loops, best of 3: 21.5 usec per loop Since this kind of function is called frequently in template engines, it makes a difference. Of course C replacements are available on PyPI: MarkupSafe or Webext But it would be nice to restore the performance of cgi.escape with a pragmatic `.replace(` approach. ---------- components: Library (Lib) messages: 189641 nosy: ezio.melotti, flox, orsenthil priority: normal severity: normal status: open title: html.escape 10x slower than cgi.escape type: performance versions: Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 10:47:50 2013 From: report at bugs.python.org (Florent Xicluna) Date: Mon, 20 May 2013 08:47:50 +0000 Subject: [issue16611] multiple problems with Cookie.py In-Reply-To: <1354654224.49.0.677339520856.issue16611@psf.upfronthosting.co.za> Message-ID: <1369039670.12.0.275216406313.issue16611@psf.upfronthosting.co.za> Florent Xicluna added the comment: Eric, this last one is not a bug in Cookie. This is a limitation with Python 2. See #18012. ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 10:53:52 2013 From: report at bugs.python.org (Graham Dumpleton) Date: Mon, 20 May 2013 08:53:52 +0000 Subject: [issue18020] html.escape 10x slower than cgi.escape In-Reply-To: <1369038098.34.0.795942514317.issue18020@psf.upfronthosting.co.za> Message-ID: <1369040032.47.0.962201379829.issue18020@psf.upfronthosting.co.za> Graham Dumpleton added the comment: Importing the cgi module the first time even in Python 2.X was always very expensive. I would suggest you redo the test using timing done inside of the script after modules have been imported so as to properly separate module import time in both cases from execution time of the specific function. ---------- nosy: +grahamd _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 11:06:38 2013 From: report at bugs.python.org (Florent Xicluna) Date: Mon, 20 May 2013 09:06:38 +0000 Subject: [issue18020] html.escape 10x slower than cgi.escape In-Reply-To: <1369038098.34.0.795942514317.issue18020@psf.upfronthosting.co.za> Message-ID: <1369040798.27.0.751638466953.issue18020@psf.upfronthosting.co.za> Florent Xicluna added the comment: > I would suggest you redo the test using timing done inside of the script after modules have been imported. The -s switch takes care of this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 11:09:02 2013 From: report at bugs.python.org (Jaakko Moisio) Date: Mon, 20 May 2013 09:09:02 +0000 Subject: [issue17976] file.write doesn't raise IOError when it should In-Reply-To: <1368544227.15.0.288519217445.issue17976@psf.upfronthosting.co.za> Message-ID: <1369040942.65.0.324606253278.issue17976@psf.upfronthosting.co.za> Jaakko Moisio added the comment: > The test pass with Python 3 which does not use the "FILE*" API > anymore. So you should maybe migrate to Python 3 :-) Yes. I will eventually. But not all the libraries I'm using are migrated yet. ---------- Added file: http://bugs.python.org/file30317/fileobject-fix5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 11:09:32 2013 From: report at bugs.python.org (Larry Hastings) Date: Mon, 20 May 2013 09:09:32 +0000 Subject: [issue16024] Doc cleanup regarding path=fd, dir_fd, follow_symlinks, etc In-Reply-To: <1348500599.22.0.118178834994.issue16024@psf.upfronthosting.co.za> Message-ID: <1369040972.17.0.43579695388.issue16024@psf.upfronthosting.co.za> Larry Hastings added the comment: p.s. Thanks for reviving the patch. I forgot about this one! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 12:14:05 2013 From: report at bugs.python.org (Graham Dumpleton) Date: Mon, 20 May 2013 10:14:05 +0000 Subject: [issue18020] html.escape 10x slower than cgi.escape In-Reply-To: <1369038098.34.0.795942514317.issue18020@psf.upfronthosting.co.za> Message-ID: <1369044845.85.0.339889175785.issue18020@psf.upfronthosting.co.za> Graham Dumpleton added the comment: Whoops. Missed the quoting. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 12:41:01 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 20 May 2013 10:41:01 +0000 Subject: [issue17973] FAQ entry for: '+=' on a list inside tuple both succeeds and raises an exception In-Reply-To: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> Message-ID: <1369046461.59.0.775749650549.issue17973@psf.upfronthosting.co.za> Ronald Oussoren added the comment: David: your update to the FAQ looks ok to me. I don't like updating the __setitem__ of tuple to allow setting an identical value (that is 'a[0] = a[0]'), it is a bit too magic to my taste and hides the real problem. I'd slightly prefer my idea: update the code generated for += to try performing the assignment before calling __iadd__. I hadn't looked at the AST compiler before, but at first glance implementing my idea seems easier than I had expected and I'm working on an experimental patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 13:27:11 2013 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 May 2013 11:27:11 +0000 Subject: [issue17973] FAQ entry for: '+=' on a list inside tuple both succeeds and raises an exception In-Reply-To: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> Message-ID: <1369049231.1.0.158139839532.issue17973@psf.upfronthosting.co.za> Mark Dickinson added the comment: > it is a bit too magic to my taste and hides the real problem. Agreed. I do wonder whether there's a solution that allows the operation to succeed, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 13:39:46 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 20 May 2013 11:39:46 +0000 Subject: [issue17973] FAQ entry for: '+=' on a list inside tuple both succeeds and raises an exception In-Reply-To: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> Message-ID: <1369049986.78.0.398842684049.issue17973@psf.upfronthosting.co.za> Ronald Oussoren added the comment: issue-17973-experimental.txt is a very crude first attempt at catching augment assignment to an immutable LHS. On first glance the code works, but it causes problems in the test suite and hence isn't correct yet. The generated code also isn't optimal, the LHS is evaluated too many times. With the patch ``([],)[0] += ['a']`` raises an exception, and doesn't update the list. I also haven't done benchmarking of the code, I'd expect a slowdown in micro benchmarks for augmented assignment when the LHS isn't a simple name because there is more byte code (``a[0] += b`` disassembly expands from 8 to 14 lines). ---------- Added file: http://bugs.python.org/file30318/issue-17973-experimental.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 13:42:43 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 20 May 2013 11:42:43 +0000 Subject: [issue17973] FAQ entry for: '+=' on a list inside tuple both succeeds and raises an exception In-Reply-To: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> Message-ID: <1369050163.4.0.0978360341274.issue17973@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Allowing the operation to succeed wouldn't be right, you are assigning to an immutable location after all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 13:44:46 2013 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 May 2013 11:44:46 +0000 Subject: [issue17973] FAQ entry for: '+=' on a list inside tuple both succeeds and raises an exception In-Reply-To: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> Message-ID: <1369050286.37.0.348080209862.issue17973@psf.upfronthosting.co.za> Mark Dickinson added the comment: Unfortunately, I don't think the checking first approach can work either: in the case where the object *does* accept assignments, it will now be assigned to twice. If there are side-effects from those assignments, then that will change behaviour. An example is the Enthought traits library, where assignment to a list item causes a notification to be fired; with this change, listeners would now receive two events instead of one. I suspect there just isn't a good solution here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 13:47:51 2013 From: report at bugs.python.org (Ethan Furman) Date: Mon, 20 May 2013 11:47:51 +0000 Subject: [issue18011] Inconsistency between b32decode() documentation, docstring and code In-Reply-To: <1368951549.72.0.00589705304437.issue18011@psf.upfronthosting.co.za> Message-ID: <1369050471.64.0.418989462713.issue18011@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 14:35:44 2013 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 20 May 2013 12:35:44 +0000 Subject: [issue17973] FAQ entry for: '+=' on a list inside tuple both succeeds and raises an exception In-Reply-To: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> Message-ID: <1369053344.37.0.0476321849742.issue17973@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 14:38:06 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 20 May 2013 12:38:06 +0000 Subject: [issue17973] FAQ entry for: '+=' on a list inside tuple both succeeds and raises an exception In-Reply-To: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> Message-ID: <1369053486.78.0.694575675805.issue17973@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: what if we try the assignment, and catch TypeError only if __iadd__ returned self? ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 14:41:53 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 May 2013 12:41:53 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <3bDfr059NWz7LkD@mail.python.org> Roundup Robot added the comment: New changeset 5e0c56557390 by Charles-Francois Natali in branch 'default': Issue #17914: Add os.cpu_count(). Patch by Yogesh Chaudhari, based on an http://hg.python.org/cpython/rev/5e0c56557390 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 14:56:25 2013 From: report at bugs.python.org (Eli Bendersky) Date: Mon, 20 May 2013 12:56:25 +0000 Subject: [issue17024] cElementTree calls end() on parser taget even if start() fails In-Reply-To: <1359040208.76.0.707549580683.issue17024@psf.upfronthosting.co.za> Message-ID: <1369054585.78.0.555020223803.issue17024@psf.upfronthosting.co.za> Eli Bendersky added the comment: Yes, it doesn't seem that expat cares too much about propagating errors from every single handler. Digging in its code comments, it says that even when XML_StopParser is called, some event handlers (like the one for "end element") may still be called since otherwise they will be lost. I don't know if this is important enough to muck with the way expat does things internally - I would expect this problem to exist in all Python XML modules that use expat. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 14:57:01 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 20 May 2013 12:57:01 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <3bDfr059NWz7LkD@mail.python.org> Message-ID: Charles-Fran?ois Natali added the comment: Alright, committed. Yogesh, thanks for the patch! I'm attaching a patch to replace several occurrences of multiprocessing.cpu_count() by os.cpu_count() in the stdlib/test suite. ---------- Added file: http://bugs.python.org/file30319/use_cpu_count.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 5e0c56557390 Doc/library/multiprocessing.rst --- a/Doc/library/multiprocessing.rst Mon May 20 14:40:46 2013 +0200 +++ b/Doc/library/multiprocessing.rst Mon May 20 14:52:18 2013 +0200 @@ -1646,9 +1646,9 @@ callbacks and has a parallel map implementation. *processes* is the number of worker processes to use. If *processes* is - ``None`` then the number returned by :func:`cpu_count` is used. If - *initializer* is not ``None`` then each worker process will call - ``initializer(*initargs)`` when it starts. + ``None`` then the number returned by :func:`os.cpu_count` is used, with a + fallback value of 1. If *initializer* is not ``None`` then each worker + process will call ``initializer(*initargs)`` when it starts. .. versionadded:: 3.2 *maxtasksperchild* is the number of tasks a worker process can complete diff -r 5e0c56557390 Lib/concurrent/futures/process.py --- a/Lib/concurrent/futures/process.py Mon May 20 14:40:46 2013 +0200 +++ b/Lib/concurrent/futures/process.py Mon May 20 14:52:18 2013 +0200 @@ -331,7 +331,7 @@ _check_system_limits() if max_workers is None: - self._max_workers = multiprocessing.cpu_count() + self._max_workers = os.cpu_count() or 1 else: self._max_workers = max_workers diff -r 5e0c56557390 Lib/multiprocessing/pool.py --- a/Lib/multiprocessing/pool.py Mon May 20 14:40:46 2013 +0200 +++ b/Lib/multiprocessing/pool.py Mon May 20 14:52:18 2013 +0200 @@ -17,10 +17,11 @@ import queue import itertools import collections +import os import time import traceback -from multiprocessing import Process, cpu_count, TimeoutError +from multiprocessing import Process, TimeoutError from multiprocessing.util import Finalize, debug # @@ -147,10 +148,7 @@ self._initargs = initargs if processes is None: - try: - processes = cpu_count() - except NotImplementedError: - processes = 1 + processes = os.cpu_count() or 1 if processes < 1: raise ValueError("Number of processes must be at least 1") diff -r 5e0c56557390 Lib/test/regrtest.py --- a/Lib/test/regrtest.py Mon May 20 14:40:46 2013 +0200 +++ b/Lib/test/regrtest.py Mon May 20 14:52:18 2013 +0200 @@ -508,12 +508,9 @@ elif o in ('-j', '--multiprocess'): use_mp = int(a) if use_mp <= 0: - try: - import multiprocessing - # Use all cores + extras for tests that like to sleep - use_mp = 2 + multiprocessing.cpu_count() - except (ImportError, NotImplementedError): - use_mp = 3 + # Use all cores + extras for tests that like to sleep + ncpu = os.cpu_count() or 1 + use_mp = 2 + ncpu if use_mp == 1: use_mp = None elif o == '--header': From report at bugs.python.org Mon May 20 15:07:20 2013 From: report at bugs.python.org (Eli Bendersky) Date: Mon, 20 May 2013 13:07:20 +0000 Subject: [issue7214] TreeBuilder.end(tag) differs between cElementTree and ElementTree In-Reply-To: <1256599950.66.0.903450683949.issue7214@psf.upfronthosting.co.za> Message-ID: <1369055240.17.0.281614774145.issue7214@psf.upfronthosting.co.za> Eli Bendersky added the comment: TreeBuilder is an interface users can implement. As such, 'tag' is a convenience the user-defined tree builder can use, as in: class Target(object): def start(self, tag, attrib): print('i see start', tag) def end(self, tag): print('i see end', tag) def close(self): return "DONE" parser = ET.XMLParser(target=Target()) parser.feed("sd") The default TreeBuilder simply needs to build the tree, and it doesn't actually use the tag argument (except for some sanity checking in the Python version). But user code is free to use it. ---------- resolution: -> wont fix stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 15:08:15 2013 From: report at bugs.python.org (STINNER Victor) Date: Mon, 20 May 2013 13:08:15 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1369055295.02.0.285535187339.issue17914@psf.upfronthosting.co.za> STINNER Victor added the comment: In my patch cpu_count.patch, I changed posix_cpu_count(): * rewrite Mac OS X implementation: code in 5e0c56557390 looks wrong. It gets a MIB but then don't use it when calling _bsd_cpu_count(). But I didn't check my patch nor the commit version on Mac OS X. * use "int ncpu;" instead of "long ncpu;" when calling mpctl() and sysctl(). For mpctl(), ncpu is used to store the result, so a wide type is ok. But for sysctl(), we pass a pointer. What happens if sysctl() expects int whereas we pass a pointer to a long? We announce sizeof(int)!? * inline _bsd_cpu_count() Sorry for this late review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 15:12:18 2013 From: report at bugs.python.org (Madison May) Date: Mon, 20 May 2013 13:12:18 +0000 Subject: [issue18021] Update broken link to Apple Publication Style Guide Message-ID: <1369055538.2.0.556134337366.issue18021@psf.upfronthosting.co.za> New submission from Madison May: The links at http://docs.python.org/devguide/documenting.html#building-doc and http://docs.python.org/devguide/docquality.html to http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/APStyleGuide/APSG_2009.pdf lead to a "Page Not Found" message and a redirect to http://developer.apple.com/library/mac/navigation/. This url should be updated to point to another copy of the 2009 style guide or https://help.apple.com/asg/mac/2013/ASG_2013.pdf, the 2013 version of Apple's Style Guide. ---------- components: Devguide messages: 189659 nosy: Madison.May, ezio.melotti priority: normal severity: normal status: open title: Update broken link to Apple Publication Style Guide type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 15:17:22 2013 From: report at bugs.python.org (Eli Bendersky) Date: Mon, 20 May 2013 13:17:22 +0000 Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular encoding In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za> Message-ID: <1369055842.81.0.623038266733.issue13612@psf.upfronthosting.co.za> Eli Bendersky added the comment: In 3.3+ there's no distinction between wide and narrow builds. Does anyone know how this should be affected? [I don't know much about unicode and encodings, unfortunately] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 15:21:26 2013 From: report at bugs.python.org (Eli Bendersky) Date: Mon, 20 May 2013 13:21:26 +0000 Subject: [issue14009] Clearer documentation for cElementTree In-Reply-To: <1329233203.38.0.944311933185.issue14009@psf.upfronthosting.co.za> Message-ID: <1369056086.11.0.246558896945.issue14009@psf.upfronthosting.co.za> Eli Bendersky added the comment: The ET docs have been significantly revamped in 3.3 I don't think cET needs to be documented. It's just confusing. ---------- resolution: -> wont fix stage: commit review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 15:37:47 2013 From: report at bugs.python.org (Madison May) Date: Mon, 20 May 2013 13:37:47 +0000 Subject: [issue18021] Update broken link to Apple Publication Style Guide In-Reply-To: <1369055538.2.0.556134337366.issue18021@psf.upfronthosting.co.za> Message-ID: <1369057067.57.0.30156422457.issue18021@psf.upfronthosting.co.za> Changes by Madison May : ---------- type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 15:50:55 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 May 2013 13:50:55 +0000 Subject: [issue17900] Recursive OrderedDict pickling In-Reply-To: <1367610016.74.0.566900545996.issue17900@psf.upfronthosting.co.za> Message-ID: <1369057855.43.0.403941465608.issue17900@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 16:13:28 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 May 2013 14:13:28 +0000 Subject: [issue18022] Inconsistency between quopri.decodestring() and email.quoprimime.decode() Message-ID: <1369059208.07.0.0770184639372.issue18022@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: >>> import quopri, email.quoprimime >>> quopri.decodestring(b'==41') b'=41' >>> email.quoprimime.decode('==41') '=A' I don't see a rule about double '=' in RFC 1521-1522 or RFCs 2045-2047 and I think quopri is wrong. Other half of this bug (encoding '=' as '==') was fixed in 9bc52706d283. ---------- components: Library (Lib), email messages: 189663 nosy: Jeremy.Hylton, barry, gvanrossum, r.david.murray, serhiy.storchaka priority: normal severity: normal status: open title: Inconsistency between quopri.decodestring() and email.quoprimime.decode() type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 16:15:21 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 May 2013 14:15:21 +0000 Subject: [issue17955] Minor updates to Functional HOWTO In-Reply-To: <1368287962.52.0.951274382256.issue17955@psf.upfronthosting.co.za> Message-ID: <3bDhvr4GPWz7Lm2@mail.python.org> Roundup Robot added the comment: New changeset 20409786cf8e by Andrew Kuchling in branch 'default': #17955: minor updates to Functional howto http://hg.python.org/cpython/rev/20409786cf8e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 16:15:43 2013 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 20 May 2013 14:15:43 +0000 Subject: [issue17955] Minor updates to Functional HOWTO In-Reply-To: <1368287962.52.0.951274382256.issue17955@psf.upfronthosting.co.za> Message-ID: <1369059343.36.0.629994948678.issue17955@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 16:16:03 2013 From: report at bugs.python.org (A.M. Kuchling) Date: Mon, 20 May 2013 14:16:03 +0000 Subject: [issue17955] Minor updates to Functional HOWTO In-Reply-To: <1368287962.52.0.951274382256.issue17955@psf.upfronthosting.co.za> Message-ID: <1369059363.88.0.748338734209.issue17955@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- stage: commit review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 16:28:26 2013 From: report at bugs.python.org (Michael Fox) Date: Mon, 20 May 2013 14:28:26 +0000 Subject: [issue18003] New lzma crazy slow with line-oriented reading. In-Reply-To: <1369002500.05.0.671120945894.issue18003@psf.upfronthosting.co.za> Message-ID: Michael Fox added the comment: I was thinking about this line: end = self._buffer.find(b"\n", self._buffer_offset) + 1 Might be a bug? For example, is there a unicode where one of several bytes is '\n'? In this case it splits the line in the middle of a character, right? On Sun, May 19, 2013 at 3:28 PM, Arfrever Frehtes Taifersar Arahesis wrote: > > Changes by Arfrever Frehtes Taifersar Arahesis : > > > ---------- > nosy: +Arfrever > > _______________________________________ > Python tracker > > _______________________________________ -- - Michael ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 16:28:43 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 20 May 2013 14:28:43 +0000 Subject: [issue8743] set() operators don't work with collections.Set instances In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za> Message-ID: <1369060123.97.0.199601911096.issue8743@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 16:29:21 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 20 May 2013 14:29:21 +0000 Subject: [issue2226] Small _abcoll Bugs / Oddities In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za> Message-ID: <1369060161.59.0.297056362528.issue2226@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 16:35:16 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 May 2013 14:35:16 +0000 Subject: [issue17973] FAQ entry for: '+=' on a list inside tuple both succeeds and raises an exception In-Reply-To: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> Message-ID: <3bDjLr1KbRz7Lkh@mail.python.org> Roundup Robot added the comment: New changeset b363473cfe9c by R David Murray in branch '3.3': #17973: Add FAQ entry for ([],)[0] += [1] both extending and raising. http://hg.python.org/cpython/rev/b363473cfe9c New changeset 6d2f0edb0758 by R David Murray in branch 'default': Merge #17973: Add FAQ entry for ([],)[0] += [1] both extending and raising. http://hg.python.org/cpython/rev/6d2f0edb0758 New changeset 8edfe539d4c6 by R David Murray in branch '2.7': #17973: Add FAQ entry for ([],)[0] += [1] both extending and raising. http://hg.python.org/cpython/rev/8edfe539d4c6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 16:38:25 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 20 May 2013 14:38:25 +0000 Subject: [issue17973] FAQ entry for: '+=' on a list inside tuple both succeeds and raises an exception In-Reply-To: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> Message-ID: <1369060705.21.0.603542998301.issue17973@psf.upfronthosting.co.za> R. David Murray added the comment: You still have the side effect problem, as far as I can see. I'm going to close this doc issue, if you guys do come up with some clever fix, you can reopen it again :) ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 16:42:43 2013 From: report at bugs.python.org (Nadeem Vawda) Date: Mon, 20 May 2013 14:42:43 +0000 Subject: [issue18003] New lzma crazy slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1369060963.08.0.432691945326.issue18003@psf.upfronthosting.co.za> Nadeem Vawda added the comment: No, that is the intended behavior for binary streams - they operate at the level of individual byes. If you want to treat your input file as Unicode-encoded text, you should open it in text mode. This will return a TextIOWrapper which handles the decoding and line splitting properly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 17:04:19 2013 From: report at bugs.python.org (Jed Brown) Date: Mon, 20 May 2013 15:04:19 +0000 Subject: [issue9189] Improve CFLAGS handling In-Reply-To: <1278517873.84.0.191654592449.issue9189@psf.upfronthosting.co.za> Message-ID: <1369062259.2.0.834228669082.issue9189@psf.upfronthosting.co.za> Jed Brown added the comment: Undefined variables are still a problem: $ echo 'FROTZ = ${CFLAGS}' > make.py3 $ python3 Python 3.3.1 (default, Apr 6 2013, 19:03:55) [GCC 4.8.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import distutils.sysconfig >>> distutils.sysconfig.parse_makefile('make.py3') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.3/distutils/sysconfig.py", line 367, in parse_makefile item = str(done['PY_' + n]) KeyError: 'PY_CFLAGS' Proposed fix: --- i/Lib/distutils/sysconfig.py +++ w/Lib/distutils/sysconfig.py @@ -357,7 +357,7 @@ def parse_makefile(fn, g=None): found = False else: - item = str(done['PY_' + n]) + item = str(done.get('PY_' + n, '')) else: done[n] = item = "" if found: ---------- nosy: +jedbrown _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 17:10:04 2013 From: report at bugs.python.org (Florent Xicluna) Date: Mon, 20 May 2013 15:10:04 +0000 Subject: [issue2226] Small _abcoll Bugs / Oddities In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za> Message-ID: <1369062604.55.0.291778064075.issue2226@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 17:31:29 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 May 2013 15:31:29 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <3bDkbj1KWdzRlW@mail.python.org> Roundup Robot added the comment: New changeset a85ac58e9eaf by Charles-Francois Natali in branch 'default': Issue #17914: Remove OS-X special-case, and use the correct int type. http://hg.python.org/cpython/rev/a85ac58e9eaf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 17:35:55 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Mon, 20 May 2013 15:35:55 +0000 Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular encoding In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za> Message-ID: <1369064155.9.0.605483004601.issue13612@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: encoding="GBK" causes a buffer overflow in PyUnknownEncodingHandler, because the result of PyUnicode_Decode() is only 192 characters long. Exact behavior is not defined... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 17:41:22 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 May 2013 15:41:22 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <3bDkq604jyzRn1@mail.python.org> Roundup Robot added the comment: New changeset f9d815522cdb by Charles-Francois Natali in branch 'default': Issue #17914: We can now inline _bsd_cpu_count(). http://hg.python.org/cpython/rev/f9d815522cdb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 17:43:00 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 20 May 2013 15:43:00 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1369055295.02.0.285535187339.issue17914@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > * rewrite Mac OS X implementation: code in 5e0c56557390 looks wrong. It > gets a MIB but then don't use it when calling _bsd_cpu_count(). But I didn't > check my patch nor the commit version on Mac OS X. Indeed. I just removed the OS-X special case altogether. Apparently, the standard sysctl is supposed to work os OS-X. We'll see what happens. > * use "int ncpu;" instead of "long ncpu;" when calling mpctl() and > sysctl(). For mpctl(), ncpu is used to store the result, so a wide type is > ok. But for sysctl(), we pass a pointer. What happens if sysctl() expects > int whereas we pass a pointer to a long? We announce sizeof(int)!? Ouch. This was overlooked when the type was changed to long. I fixed this. > * inline _bsd_cpu_count() Done in a subsequent commit (especially since the OS-X special case has been removed). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 18:40:07 2013 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 20 May 2013 16:40:07 +0000 Subject: [issue734176] Make Tkinter.py's nametowidget work with cloned menu widgets Message-ID: <1369068007.7.0.326848071487.issue734176@psf.upfronthosting.co.za> Mark Lawrence added the comment: I've attached a patch for Python 3 which I hope is okay as it's my first attempt using TortoiseHg on Windows. ---------- Added file: http://bugs.python.org/file30320/issue734176_py3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 18:41:58 2013 From: report at bugs.python.org (Michael Fox) Date: Mon, 20 May 2013 16:41:58 +0000 Subject: [issue18003] New lzma crazy slow with line-oriented reading. In-Reply-To: <1369060963.08.0.432691945326.issue18003@psf.upfronthosting.co.za> Message-ID: Michael Fox added the comment: You're right. In fact, what doesn't make sense is to be doing line-oriented reads on a binary file. Why was I doing that? I do have another quibble though. The open() function is like this: open(file, mode='r', buffering=-1, encoding=None, errors=None, newline=None, closefd=True, opener=None) -> file object The lzma.open() function is like this: lzma.open = open(filename, mode='rb', *, format=None, check=-1, preset=None, filters=None, encoding=None, errors=None, newline=None) It seems to me that it would be best for them to be as congruent as possible. Because people will try to do this (I did): if filename.endswith('.xz'): f = lzma.open(filename) else: f = open(filename) for line in f: ... And then they will be in for a surprise. Would you consider changing the default mode of lzma.open() to 'rt' and implement the 'buffering' parameter as it is implemented in open()? And further, can we discuss whether "duck typing" is becoming generally problematic in an expanding standard library and whether there should be some process, language, testing or something to ensure the ducks really quack the same? For example, there could be a standard testsuite which everything purporting to implement an open() function should be subject to. On Mon, May 20, 2013 at 7:42 AM, Nadeem Vawda wrote: > > Nadeem Vawda added the comment: > > No, that is the intended behavior for binary streams - they operate at > the level of individual byes. If you want to treat your input file as > Unicode-encoded text, you should open it in text mode. This will return a > TextIOWrapper which handles the decoding and line splitting properly. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ -- - Michael ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 18:50:52 2013 From: report at bugs.python.org (Michael Fox) Date: Mon, 20 May 2013 16:50:52 +0000 Subject: [issue18003] New lzma crazy slow with line-oriented reading. In-Reply-To: Message-ID: Michael Fox added the comment: I thought of an even more hazardous case: if compression == 'gz': import gzip open = gzip.open elif compression == 'xz': import lzma open = lzma.open else: pass On Mon, May 20, 2013 at 9:41 AM, Michael Fox wrote: > > Michael Fox added the comment: > > You're right. In fact, what doesn't make sense is to be doing > line-oriented reads on a binary file. Why was I doing that? > > I do have another quibble though. The open() function is like this: > > open(file, mode='r', buffering=-1, encoding=None, > errors=None, newline=None, closefd=True, opener=None) -> file object > > The lzma.open() function is like this: > > lzma.open = open(filename, mode='rb', *, format=None, check=-1, > preset=None, filters=None, encoding=None, errors=None, newline=None) > > It seems to me that it would be best for them to be as congruent as > possible. Because people will try to do this (I did): > > if filename.endswith('.xz'): > f = lzma.open(filename) > else: > f = open(filename) > for line in f: ... > > And then they will be in for a surprise. Would you consider changing > the default mode of lzma.open() to 'rt' and implement the 'buffering' > parameter as it is implemented in open()? And further, can we discuss > whether "duck typing" is becoming generally problematic in an > expanding standard library and whether there should be some process, > language, testing or something to ensure the ducks really quack the > same? > > For example, there could be a standard testsuite which everything > purporting to implement an open() function should be subject to. > > On Mon, May 20, 2013 at 7:42 AM, Nadeem Vawda wrote: >> >> Nadeem Vawda added the comment: >> >> No, that is the intended behavior for binary streams - they operate at >> the level of individual byes. If you want to treat your input file as >> Unicode-encoded text, you should open it in text mode. This will return a >> TextIOWrapper which handles the decoding and line splitting properly. >> >> ---------- >> >> _______________________________________ >> Python tracker >> >> _______________________________________ > > -- > > - > Michael > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ -- - Michael ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 19:14:04 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 May 2013 17:14:04 +0000 Subject: [issue17917] use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() when applicable In-Reply-To: <1367845837.62.0.789153792923.issue17917@psf.upfronthosting.co.za> Message-ID: <3bDmt41nT8z7LnG@mail.python.org> Roundup Robot added the comment: New changeset 12cbb5183d98 by Charles-Francois Natali in branch 'default': Issue #17917: Use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() http://hg.python.org/cpython/rev/12cbb5183d98 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 19:14:05 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 May 2013 17:14:05 +0000 Subject: [issue17684] Skip tests in test_socket like testFDPassSeparate on OS X In-Reply-To: <1365563429.51.0.176752850468.issue17684@psf.upfronthosting.co.za> Message-ID: <3bDmt509Ztz7Lmk@mail.python.org> Roundup Robot added the comment: New changeset 9cfaefa58bdc by Charles-Francois Natali in branch 'default': Issue #17684: Fix some test_socket failures due to limited FD passing support http://hg.python.org/cpython/rev/9cfaefa58bdc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 19:32:39 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 May 2013 17:32:39 +0000 Subject: [issue18003] New lzma crazy slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1369071159.69.0.784405062464.issue18003@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Wrapping a raw LZMAFile in a BufferedReader is a simple solution. But I think about extending BufferedReader so that LZMAFile and BufferedReader could use a common buffer. Perhaps add a new method to BufferedIOBase which will be called when a buffer is underflowed. In BufferedIOBase it should call raw.read(), in LZMAFile it should call _fill_buffer(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 19:34:46 2013 From: report at bugs.python.org (Michael Fox) Date: Mon, 20 May 2013 17:34:46 +0000 Subject: [issue18003] New lzma crazy slow with line-oriented reading. In-Reply-To: Message-ID: Michael Fox added the comment: I thought about it some more and the only bug here is mine, failing to explicitly set mode='rt'. Maybe back when someone invented text and binary modes they should have been clear which was to be the default for all things. Maybe when someone made the base class, io.IOBase they should have defined an .open() with a mode that matched open(). Maybe when someone first implemented gzip.open() they should have matched open(). But that's not what happened and there's going to be lots of code out there relying on the default 'rt' for open() and 'rb' for gzip/bz2/lzma.open(). There's going to be lots of bugs in the future as people familiar with one thing assume the default is the same for the other. But oh well. It's too late change. On Mon, May 20, 2013 at 9:50 AM, Michael Fox wrote: > > Michael Fox added the comment: > > I thought of an even more hazardous case: > > if compression == 'gz': > import gzip > open = gzip.open > elif compression == 'xz': > import lzma > open = lzma.open > else: > pass > > On Mon, May 20, 2013 at 9:41 AM, Michael Fox wrote: >> >> Michael Fox added the comment: >> >> You're right. In fact, what doesn't make sense is to be doing >> line-oriented reads on a binary file. Why was I doing that? >> >> I do have another quibble though. The open() function is like this: >> >> open(file, mode='r', buffering=-1, encoding=None, >> errors=None, newline=None, closefd=True, opener=None) -> file object >> >> The lzma.open() function is like this: >> >> lzma.open = open(filename, mode='rb', *, format=None, check=-1, >> preset=None, filters=None, encoding=None, errors=None, newline=None) >> >> It seems to me that it would be best for them to be as congruent as >> possible. Because people will try to do this (I did): >> >> if filename.endswith('.xz'): >> f = lzma.open(filename) >> else: >> f = open(filename) >> for line in f: ... >> >> And then they will be in for a surprise. Would you consider changing >> the default mode of lzma.open() to 'rt' and implement the 'buffering' >> parameter as it is implemented in open()? And further, can we discuss >> whether "duck typing" is becoming generally problematic in an >> expanding standard library and whether there should be some process, >> language, testing or something to ensure the ducks really quack the >> same? >> >> For example, there could be a standard testsuite which everything >> purporting to implement an open() function should be subject to. >> >> On Mon, May 20, 2013 at 7:42 AM, Nadeem Vawda wrote: >>> >>> Nadeem Vawda added the comment: >>> >>> No, that is the intended behavior for binary streams - they operate at >>> the level of individual byes. If you want to treat your input file as >>> Unicode-encoded text, you should open it in text mode. This will return a >>> TextIOWrapper which handles the decoding and line splitting properly. >>> >>> ---------- >>> >>> _______________________________________ >>> Python tracker >>> >>> _______________________________________ >> >> -- >> >> - >> Michael >> >> ---------- >> >> _______________________________________ >> Python tracker >> >> _______________________________________ > > -- > > - > Michael > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ -- - Michael ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 19:38:23 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 20 May 2013 17:38:23 +0000 Subject: [issue17684] Skip tests in test_socket like testFDPassSeparate on OS X In-Reply-To: <1365563429.51.0.176752850468.issue17684@psf.upfronthosting.co.za> Message-ID: <1369071503.88.0.986220495753.issue17684@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Committed, thanks! ---------- resolution: -> fixed stage: -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 19:39:00 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 20 May 2013 17:39:00 +0000 Subject: [issue17684] Skip tests in test_socket like testFDPassSeparate on OS X In-Reply-To: <1365563429.51.0.176752850468.issue17684@psf.upfronthosting.co.za> Message-ID: <1369071540.87.0.320882615224.issue17684@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 19:59:14 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 20 May 2013 17:59:14 +0000 Subject: [issue17683] socket.getsockname() inconsistent return type with AF_UNIX In-Reply-To: <1365555770.86.0.711874075927.issue17683@psf.upfronthosting.co.za> Message-ID: <1369072754.54.0.916503958931.issue17683@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Here's a patch. Note that I had to adapt test_socket (which was passing bytes). ---------- components: +Library (Lib) keywords: +needs review stage: -> patch review type: -> behavior Added file: http://bugs.python.org/file30321/af_unix_str.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 20:11:13 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 20 May 2013 18:11:13 +0000 Subject: [issue13146] Writing a pyc file is not atomic In-Reply-To: <1318275475.02.0.82335017062.issue13146@psf.upfronthosting.co.za> Message-ID: <1369073473.45.0.589168073473.issue13146@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 20:20:04 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 May 2013 18:20:04 +0000 Subject: [issue17868] pprint long non-printable bytes as hexdump In-Reply-To: <1367259569.59.0.63399196745.issue17868@psf.upfronthosting.co.za> Message-ID: <1369074004.2.0.627623194901.issue17868@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, I forgot about bytes.fromhex(). This of course looks better than base64.b16decode((...).replace(' ', '')). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 20:31:22 2013 From: report at bugs.python.org (Jeff Hardy) Date: Mon, 20 May 2013 18:31:22 +0000 Subject: [issue17994] Change necessary in platform.py to support IronPython In-Reply-To: <1368714285.1.0.952125974829.issue17994@psf.upfronthosting.co.za> Message-ID: <1369074682.21.0.553454974017.issue17994@psf.upfronthosting.co.za> Changes by Jeff Hardy : ---------- nosy: +jeff.hardy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 20:53:22 2013 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 20 May 2013 18:53:22 +0000 Subject: [issue17683] socket.getsockname() inconsistent return type with AF_UNIX In-Reply-To: <1365555770.86.0.711874075927.issue17683@psf.upfronthosting.co.za> Message-ID: <1369076002.87.0.192301066113.issue17683@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 21:05:16 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 20 May 2013 19:05:16 +0000 Subject: [issue17683] socket.getsockname() inconsistent return type with AF_UNIX In-Reply-To: <1365555770.86.0.711874075927.issue17683@psf.upfronthosting.co.za> Message-ID: <1369076716.04.0.185753225501.issue17683@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Looks fine to me :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 21:53:03 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 20 May 2013 19:53:03 +0000 Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular encoding In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za> Message-ID: <1369079583.21.0.416688402904.issue13612@psf.upfronthosting.co.za> Terry J. Reedy added the comment: 3.3 shifted the wide-build problem to all builds ;-). I now get File "C:\Python\mypy\tem.py", line 4, in xmlet.fromstring(s) File "C:...33\lib\xml\etree\ElementTree.py", line 1356, in XML parser.feed(text) File "", line None xml.etree.ElementTree.ParseError: unknown encoding: line 1, column 30 I do not understand the 'unknown encoding' bit. Replacing 'GBK' with a truly unknown encoding changes the last line to LookupError: unknown encoding: xyz, so the lookup of 'GBK' succeeded. I get the same two messages if I add a 'b' prefix to make s be bytes, which it logically should be (and was in 2.7). (I presume .fromstring 'encodes' unicode input to bytes with the ascii or latin-1 encoder and then decodes back to unicode according to the announced encoding.) With s so prefixed, s.decode(encoding="GBK") works and returns the original unicode version of s, so Python does know "GBK". And it indeed is in the list of official IANA charset names. I don't know unicode internals to understand Amaury's comment. However, it almost reads to me as if this is a unicode bug, not ET bug. ---------- versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 21:56:02 2013 From: report at bugs.python.org (Anselm Kruis) Date: Mon, 20 May 2013 19:56:02 +0000 Subject: [issue18023] msi product code for 2.7.5150 not in Tools/msi/uuids.py Message-ID: <1369079762.11.0.597354582837.issue18023@psf.upfronthosting.co.za> New submission from Anselm Kruis: The file Tools/msi/uuids.py contains the product codes for all recently released Python 2.x versions except 2.7.5. Without this code it is not possible to recreate the MSI installer using Tools\msi\msi.py. The product code of http://www.python.org/ftp/python/2.7.5/python-2.7.5.msi is '{DBDD570E-0952-475F-9453-AB88F3DD5659}'. ---------- components: Build, Windows messages: 189686 nosy: anselm.kruis priority: normal severity: normal status: open title: msi product code for 2.7.5150 not in Tools/msi/uuids.py type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 22:08:53 2013 From: report at bugs.python.org (Brian Curtin) Date: Mon, 20 May 2013 20:08:53 +0000 Subject: [issue18023] msi product code for 2.7.5150 not in Tools/msi/uuids.py In-Reply-To: <1369079762.11.0.597354582837.issue18023@psf.upfronthosting.co.za> Message-ID: <1369080533.08.0.770398866989.issue18023@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- assignee: -> loewis components: -Build nosy: +loewis type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 22:11:50 2013 From: report at bugs.python.org (Kristofer Wempa) Date: Mon, 20 May 2013 20:11:50 +0000 Subject: [issue18024] dbm module fails to build on SLES11SP1 using 2.7.5 source Message-ID: <1369080710.44.0.400005629221.issue18024@psf.upfronthosting.co.za> New submission from Kristofer Wempa: I recently built a new version of our Linux tools using Python 2.7.5 on our SLES11SP2 server. Afterwards, I noticed that the dbm module was not built successfully. The Python build did not fail and the failed module build summary at the end of the build did not list "dbm", which surprised me. I rebuilt Python and captured the actual error when attempting to build the dbm module. Below is the error. I managed to get it to build by replacing "-lndbm" with "-lgdbm". This is the first time dbm has failed to build on this platform. I've built several versions of Python 2.7.2, 2.7.3 and 2.7.4 and this module built every single time. Something that has changed in the build process is causing this problem. Link Error: gcc -pthread -shared build/temp.linux-x86_64-2.7/nfs/statbuild/ci1admin/ci1_toolchain_src/KRIS/Python-2.7.5/Modules/dbmmodule.o -L/usr/lib -L/lib -L/usr/x86_64-suse-linux/lib -L/lib64 -L/usr/lib64 -L/usr/local/lib -lndbm -o build/lib.linux-x86_64-2.7/dbm.so /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: skipping incompatible /usr/lib/libgdbm.so when searching for /usr/lib/libgdbm.so /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: cannot find /usr/lib/libgdbm.so collect2: ld returned 1 exit status ---------- components: Build messages: 189687 nosy: wempa priority: normal severity: normal status: open title: dbm module fails to build on SLES11SP1 using 2.7.5 source type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 22:22:34 2013 From: report at bugs.python.org (Alexandre Vassalotti) Date: Mon, 20 May 2013 20:22:34 +0000 Subject: [issue17900] Recursive OrderedDict pickling In-Reply-To: <1367610016.74.0.566900545996.issue17900@psf.upfronthosting.co.za> Message-ID: <1369081354.84.0.00475898135138.issue17900@psf.upfronthosting.co.za> Alexandre Vassalotti added the comment: The patch looks good to me. So go ahead and submit it. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 22:28:02 2013 From: report at bugs.python.org (Thomas Fenzl) Date: Mon, 20 May 2013 20:28:02 +0000 Subject: [issue17545] os.listdir and os.path.join inconsistent on empty path In-Reply-To: <1364228813.43.0.916487849633.issue17545@psf.upfronthosting.co.za> Message-ID: <1369081682.31.0.604139903751.issue17545@psf.upfronthosting.co.za> Thomas Fenzl added the comment: I also looked into creating a patch and now I'm not convinced about the solution. While os.path.join accepts an empty string, the functions is os (e.g. stat and friends, utime, chown don't. os.walk doesn't throw an Exception, but generates an empty iterator on ''. So from a module perspective, things wouldn't get more consistent, but less. Any thoughts about how to proceed? ---------- nosy: +Thomas Fenzl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 22:33:30 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 May 2013 20:33:30 +0000 Subject: [issue17872] Crash in marshal.load() with bad reader In-Reply-To: <1367270952.48.0.351702678796.issue17872@psf.upfronthosting.co.za> Message-ID: <1369082010.54.0.453836071289.issue17872@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And here is a fix. ---------- assignee: -> serhiy.storchaka keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file30322/marshal_bad_reader.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 22:34:38 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 May 2013 20:34:38 +0000 Subject: [issue18025] Buffer overflow in BufferedIOBase.readinto() Message-ID: <1369082078.59.0.190906066186.issue18025@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: BufferedIOBase.readinto() overflows output buffer if read() returns more data than requested. Here is a patch. See also related issue17872. ---------- assignee: serhiy.storchaka components: Extension Modules, IO files: bufferedio_buffer_overflow.patch keywords: patch messages: 189691 nosy: benjamin.peterson, pitrou, serhiy.storchaka, stutzbach priority: normal severity: normal stage: patch review status: open title: Buffer overflow in BufferedIOBase.readinto() type: crash versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30323/bufferedio_buffer_overflow.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 22:35:59 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 May 2013 20:35:59 +0000 Subject: [issue17900] Recursive OrderedDict pickling In-Reply-To: <1367610016.74.0.566900545996.issue17900@psf.upfronthosting.co.za> Message-ID: <1369082159.51.0.705016614724.issue17900@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 22:47:05 2013 From: report at bugs.python.org (Kristofer Wempa) Date: Mon, 20 May 2013 20:47:05 +0000 Subject: [issue18024] dbm module fails to build on SLES11SP1 using 2.7.5 source In-Reply-To: <1369080710.44.0.400005629221.issue18024@psf.upfronthosting.co.za> Message-ID: <1369082825.9.0.666665500723.issue18024@psf.upfronthosting.co.za> Kristofer Wempa added the comment: Some more information: The libndbm.so is not a library but some sort of ld script. It has the following content: /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ GROUP ( /usr/lib/libgdbm.so /usr/lib/libgdbm_compat.so ) What I think is happening is that the build is finding the one in /usr/lib instead of /usr/lib64 and then it's trying to load the incomptaible /usr/lib/libgdbm.so. I was also able to circumvent the problem by setting LDFLAGS to "-L/usr/lib64 -L/lib64". This put the 64-bit library directories earlier on the link line. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 23:06:37 2013 From: report at bugs.python.org (Jakub Wilk) Date: Mon, 20 May 2013 21:06:37 +0000 Subject: [issue18026] Typo in ctypes documentation Message-ID: <1369083997.94.0.835709293593.issue18026@psf.upfronthosting.co.za> New submission from Jakub Wilk: http://docs.python.org/3/library/ctypes.html#finding-shared-libraries reads: "If wrapping a shared library with ctypes, it may be better to determine the shared library name at development type, and hardcode ..." Shouldn't that be "... at development time, ..."? ---------- assignee: docs at python components: Documentation messages: 189693 nosy: docs at python, jwilk priority: normal severity: normal status: open title: Typo in ctypes documentation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 23:18:51 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 May 2013 21:18:51 +0000 Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular encoding In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za> Message-ID: <1369084731.41.0.919161405221.issue13612@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: PyUnknownEncodingHandler gets an encoding name and fills a special XML_Encoding structure which expat parser uses for decoding. Currently PyUnknownEncodingHandler works only with 8-bit encodings and I don't see an efficient method how extent it to handle general multibyte encoding. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 23:27:22 2013 From: report at bugs.python.org (Jakub Wilk) Date: Mon, 20 May 2013 21:27:22 +0000 Subject: [issue18027] distutils should access stat_result timestamps via .st_*time attributes Message-ID: <1369085242.54.0.746637584547.issue18027@psf.upfronthosting.co.za> New submission from Jakub Wilk: Currently distutils accesses stat_result timestamps like this: os.stat(source)[ST_MTIME] But, for compatibility with older Python versions, the above method gives you at most 1-second resolution. It should do it like this instead: os.stat(source).st_mtime ---------- assignee: eric.araujo components: Distutils messages: 189695 nosy: eric.araujo, jwilk, tarek priority: normal severity: normal status: open title: distutils should access stat_result timestamps via .st_*time attributes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 23:31:59 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 20 May 2013 21:31:59 +0000 Subject: [issue16603] Sporadic test_socket failures: testFDPassCMSG_SPACE on Mac OS X In-Reply-To: <1354610154.86.0.887949323401.issue16603@psf.upfronthosting.co.za> Message-ID: <1369085519.39.0.637254181563.issue16603@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: This has been fixed some time ago (I don't remember the commit though). ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 23:33:45 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 May 2013 21:33:45 +0000 Subject: [issue18026] Typo in ctypes documentation In-Reply-To: <1369083997.94.0.835709293593.issue18026@psf.upfronthosting.co.za> Message-ID: <3bDtdh2cpmz7Llc@mail.python.org> Roundup Robot added the comment: New changeset 7937f5c56924 by Ned Deily in branch '2.7': Issue #18026: fix ctypes doc typo http://hg.python.org/cpython/rev/7937f5c56924 New changeset cac83b62b0de by Ned Deily in branch '3.3': Issue #18026: fix ctypes doc typo http://hg.python.org/cpython/rev/cac83b62b0de New changeset 1f388bbc8917 by Ned Deily in branch 'default': Issue #18026: merge http://hg.python.org/cpython/rev/1f388bbc8917 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 23:34:49 2013 From: report at bugs.python.org (Ned Deily) Date: Mon, 20 May 2013 21:34:49 +0000 Subject: [issue18026] Typo in ctypes documentation In-Reply-To: <1369083997.94.0.835709293593.issue18026@psf.upfronthosting.co.za> Message-ID: <1369085689.41.0.268223325888.issue18026@psf.upfronthosting.co.za> Ned Deily added the comment: It should. Thanks! ---------- nosy: +ned.deily resolution: -> fixed stage: -> committed/rejected status: open -> closed versions: +Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 23:37:40 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 20 May 2013 21:37:40 +0000 Subject: [issue15523] Block on close TCP socket in SocketServer.py In-Reply-To: <1343815668.28.0.0910478510187.issue15523@psf.upfronthosting.co.za> Message-ID: <1369085860.21.0.478538640753.issue15523@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- resolution: -> invalid stage: -> committed/rejected status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 23:38:06 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 20 May 2013 21:38:06 +0000 Subject: [issue17525] os.getcwd() fails on cifs share In-Reply-To: <1363990327.07.0.260090776617.issue17525@psf.upfronthosting.co.za> Message-ID: <1369085886.15.0.125172719479.issue17525@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- resolution: -> invalid stage: -> committed/rejected status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 23:41:17 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 20 May 2013 21:41:17 +0000 Subject: [issue3006] subprocess.Popen causes socket to remain open after close In-Reply-To: <1212094958.77.0.0391223554576.issue3006@psf.upfronthosting.co.za> Message-ID: <1369086077.36.0.0565225098567.issue3006@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: It's fixed now that subprocess defaults to close_fds=True. ---------- resolution: -> out of date stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 23:47:17 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 20 May 2013 21:47:17 +0000 Subject: [issue13146] Writing a pyc file is not atomic In-Reply-To: <1318275475.02.0.82335017062.issue13146@psf.upfronthosting.co.za> Message-ID: <1369086437.71.0.862009463637.issue13146@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Proposed patch for 2.7 ---------- Added file: http://bugs.python.org/file30324/13146-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 23:48:30 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 20 May 2013 21:48:30 +0000 Subject: [issue13146] Writing a pyc file is not atomic In-Reply-To: <1318275475.02.0.82335017062.issue13146@psf.upfronthosting.co.za> Message-ID: <1369086510.48.0.733988198338.issue13146@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I'm re-opening this because I'd like to get RM pronouncement on applying a patch to 2.7, 3.2, and 3.3 to make py_compile.py atomically rename its pyc/pyo file. Attached is a patch for 2.7 based on importlib's approach in 3.4. It should be easy enough to port to Python 3. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 23:50:00 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 20 May 2013 21:50:00 +0000 Subject: [issue13146] Writing a pyc file is not atomic In-Reply-To: <1318275475.02.0.82335017062.issue13146@psf.upfronthosting.co.za> Message-ID: <1369086600.15.0.351507940468.issue13146@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Oh btw, if Georg and Benjamin deny this for the stable releases, I'll very likely patch the Ubuntu versions anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 23:52:43 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 20 May 2013 21:52:43 +0000 Subject: [issue13146] Writing a pyc file is not atomic In-Reply-To: <1369086510.48.0.733988198338.issue13146@psf.upfronthosting.co.za> Message-ID: <1369086753.2536.3.camel@fsol> Antoine Pitrou added the comment: > I'm re-opening this because I'd like to get RM pronouncement on > applying a patch to 2.7, 3.2, and 3.3 to make py_compile.py atomically > rename its pyc/pyo file. Some people already complained about this change. I'm not sure it's fit for a bugfix release. http://bugs.python.org/issue17222 Besides, you can just also make py_compile write to a temporary file, then do the rename yourself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 23:55:15 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 20 May 2013 21:55:15 +0000 Subject: [issue13146] Writing a pyc file is not atomic In-Reply-To: <1369086753.2536.3.camel@fsol> Message-ID: <20130520175512.6af08f99@anarchist> Barry A. Warsaw added the comment: On May 20, 2013, at 09:52 PM, Antoine Pitrou wrote: >Some people already complained about this change. I'm not sure it's fit for a >bugfix release. http://bugs.python.org/issue17222 Yeah, but that's a crazy use case. :) >Besides, you can just also make py_compile write to a temporary file, >then do the rename yourself. That actually doesn't work as well for us, since we feed .py file names to py_compile via stdin. I'd rather rename them atomically on a per-file basis rather than at the end of all the byte compilations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 23:57:07 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 20 May 2013 21:57:07 +0000 Subject: [issue13146] Writing a pyc file is not atomic In-Reply-To: <1318275475.02.0.82335017062.issue13146@psf.upfronthosting.co.za> Message-ID: <1369087027.27.0.153844699744.issue13146@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: IIRC, os.rename() will fail on Windows if the target file already exists. That's why os.replace() was added. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 20 23:57:56 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 20 May 2013 21:57:56 +0000 Subject: [issue13146] Writing a pyc file is not atomic In-Reply-To: <1369087027.27.0.153844699744.issue13146@psf.upfronthosting.co.za> Message-ID: <1369087069.2536.4.camel@fsol> Antoine Pitrou added the comment: > IIRC, os.rename() will fail on Windows if the target file already > exists. Good point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 00:00:02 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 20 May 2013 22:00:02 +0000 Subject: [issue13146] Writing a pyc file is not atomic In-Reply-To: <1369087027.27.0.153844699744.issue13146@psf.upfronthosting.co.za> Message-ID: <20130520180000.302d24f6@anarchist> Barry A. Warsaw added the comment: On May 20, 2013, at 09:57 PM, Charles-Fran?ois Natali wrote: >IIRC, os.rename() will fail on Windows if the target file already exists. >That's why os.replace() was added. Ah, that's probably a more serious blocker for adding it to upstream Python. Not so for fixing it in Debian/Ubuntu though! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 00:10:27 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 20 May 2013 22:10:27 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1369087827.14.0.755614657993.issue15392@psf.upfronthosting.co.za> Changes by Terry J. Reedy : Removed file: http://bugs.python.org/file30264/idletests.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 00:14:26 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Mon, 20 May 2013 22:14:26 +0000 Subject: [issue13146] Writing a pyc file is not atomic In-Reply-To: <20130520180000.302d24f6@anarchist> Message-ID: Charles-Fran?ois Natali added the comment: The workaround would be to unlink the file first, and then try to create it with O_EXCL. You have a short window where there's no file, but that shouldn't be a problem in this specific case, and it would work on Windows. As for issue #17222, well, many applications use temporary files and rename (e.g. most web browsers), so I'd be tempted to say "don't do it". Of course, I would feel kinda bad if Python broke Debian's builders (I don't care about Gentoo though ;-) Its funny how an seemingly harmless change can introduce nasty regressions... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 00:30:21 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 May 2013 22:30:21 +0000 Subject: [issue17744] Unset VIRTUAL_ENV environment variable in deactivate.bat In-Reply-To: <1366064071.06.0.700925428013.issue17744@psf.upfronthosting.co.za> Message-ID: <3bDvv10qR9z7Ll0@mail.python.org> Roundup Robot added the comment: New changeset 9a2eea6fffee by Vinay Sajip in branch '3.3': Issue #17744: Now unset VIRTUAL_ENV environment variable when deactivating. http://hg.python.org/cpython/rev/9a2eea6fffee New changeset e29533c8ec66 by Vinay Sajip in branch 'default': Closes #17744: Merged fix from 3.3. http://hg.python.org/cpython/rev/e29533c8ec66 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 00:39:25 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 May 2013 22:39:25 +0000 Subject: [issue17743] Use extended syntax of `set` command in activate.bat/deactivate.bat batch files. In-Reply-To: <1366063963.5.0.506967251468.issue17743@psf.upfronthosting.co.za> Message-ID: <3bDw5S2l7KzRwQ@mail.python.org> Roundup Robot added the comment: New changeset 66c87d2b3435 by Vinay Sajip in branch '3.3': Issue #17743: Now use extended syntax of set command in .bat files. http://hg.python.org/cpython/rev/66c87d2b3435 New changeset 96c842873c30 by Vinay Sajip in branch 'default': Closes #17743: Merged fix from 3.3. http://hg.python.org/cpython/rev/96c842873c30 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 01:05:30 2013 From: report at bugs.python.org (Matt Bryant) Date: Mon, 20 May 2013 23:05:30 +0000 Subject: [issue18020] html.escape 10x slower than cgi.escape In-Reply-To: <1369038098.34.0.795942514317.issue18020@psf.upfronthosting.co.za> Message-ID: <1369091130.31.0.652601595461.issue18020@psf.upfronthosting.co.za> Matt Bryant added the comment: I did a few more tests and am seeing the same speed differences Florent noticed. It seems reasonable to use .replace() instead, as it does the same thing significantly faster. I've attached a patch doing just this. ---------- keywords: +patch nosy: +Teh Matt Added file: http://bugs.python.org/file30325/htmlescape.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 01:13:59 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 20 May 2013 23:13:59 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1369091639.97.0.367945740139.issue15392@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Problem solved at least for me with a new patch: D:\Python\dev\py33\PCbuild> python_d -m test test_idle [1/1] test_idle Warning -- os.environ was modified by test_idle 1 test altered the execution environment: test_idle ...> python_d -m test ... [154/373/2] test_httpservers [155/373/2] test_idle [156/373/2] test_imaplib ... The new patch has two simple changes to test_idle. 1. The traceback David and I saw started in regrtest.runtest_inner: the_package = __import__(abstest, globals(), locals(), []) The rest of the calls were in unittest. This line runs fine in isolation, but it does not matter; regrtest does not want the test to run when it imports the file. Add 'if name ...' to guard main(...). 2. With no test_main present, the key line of runtest_inner is tests = unittest.TestLoader().loadTestsFromModule(the_module) Unittest.main makes the same call to look for, among other things, a load_tests function. Import load_tests from idlelib.idle_test. ---------- Added file: http://bugs.python.org/file30326/idletest3.diff.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 01:44:26 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 20 May 2013 23:44:26 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1369093466.0.0.572658347554.issue15392@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I will delete 'sim' as an abbreviation for 'support import module'. Does this otherwise seem ready to apply? This time I am really sure it works here, because I ran the 2 tests twice each and cut and pasted the evidence. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 02:12:03 2013 From: report at bugs.python.org (William Moreno) Date: Tue, 21 May 2013 00:12:03 +0000 Subject: [issue18008] python33-3.3.2 Parser/pgen: Permission denied In-Reply-To: <1368891906.35.0.458659072685.issue18008@psf.upfronthosting.co.za> Message-ID: <1369095123.63.0.962755321805.issue18008@psf.upfronthosting.co.za> William Moreno added the comment: Thank's a lot by answered me, I am now at FreeBSD team in order to fix this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 02:27:39 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 21 May 2013 00:27:39 +0000 Subject: [issue17996] socket module should expose AF_LINK In-Reply-To: <1368757243.4.0.421622185164.issue17996@psf.upfronthosting.co.za> Message-ID: <1369096059.61.0.472216348317.issue17996@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Mmm I'm not sure how to do this properly. Apparently it seems I can: --- a/Lib/plat-freebsd8/regen +++ b/Lib/plat-freebsd8/regen @@ -1,3 +1,3 @@ #! /bin/sh set -v -python ../../Tools/scripts/h2py.py -i '(u_long)' /usr/include/netinet/in.h +python ../../Tools/scripts/h2py.py -i '(u_long)' /usr/include/netinet/in.h /usr/include/sys/socket.h ...and then rerun Tools/scripts/h2py.py in order to "#ifdef AF_LINK" from within socketmodule.c but what about other FreeBSD versions? Why there's no Lib/plat-freebsd9 directory? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 03:14:28 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 21 May 2013 01:14:28 +0000 Subject: [issue17996] socket module should expose AF_LINK In-Reply-To: <1368757243.4.0.421622185164.issue17996@psf.upfronthosting.co.za> Message-ID: <1369098868.4.0.472300861424.issue17996@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Nevermind, it seems changing regen is not necessary. Patch is in attachment. ---------- keywords: +patch Added file: http://bugs.python.org/file30327/AF_LINK.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 04:08:40 2013 From: report at bugs.python.org (=?utf-8?q?Guilherme_Sim=C3=B5es?=) Date: Tue, 21 May 2013 02:08:40 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1369102120.84.0.238626465026.issue15392@psf.upfronthosting.co.za> Guilherme Sim?es added the comment: I'm having the same problem as Todd when I apply the patch in my Mac... I have no idea why though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 05:18:02 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 May 2013 03:18:02 +0000 Subject: [issue14146] IDLE: source line in editor doesn't highlight when debugging In-Reply-To: <1330401708.67.0.511106941359.issue14146@psf.upfronthosting.co.za> Message-ID: <3bF2Gx0Xh4zSjM@mail.python.org> Roundup Robot added the comment: New changeset 5ae830ff6d64 by Roger Serwy in branch '2.7': #14146: Highlight source line while debugging on Windows. http://hg.python.org/cpython/rev/5ae830ff6d64 New changeset 3735b4e0fc7c by Roger Serwy in branch '3.3': #14146: Highlight source line while debugging on Windows. http://hg.python.org/cpython/rev/3735b4e0fc7c New changeset b56ae3f878cb by Roger Serwy in branch 'default': #14146: merge with 3.3. http://hg.python.org/cpython/rev/b56ae3f878cb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 05:21:03 2013 From: report at bugs.python.org (Roger Serwy) Date: Tue, 21 May 2013 03:21:03 +0000 Subject: [issue14146] IDLE: source line in editor doesn't highlight when debugging In-Reply-To: <1330401708.67.0.511106941359.issue14146@psf.upfronthosting.co.za> Message-ID: <1369106463.95.0.817191675171.issue14146@psf.upfronthosting.co.za> Roger Serwy added the comment: I committed the Tk workaround for the Windows platform. I'm leaving this issue as pending with a resolution of later in case Tk developers address the bug report mentioned in msg185632. If anyone else wishes to close it, feel free. ---------- resolution: -> later stage: commit review -> committed/rejected status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 05:31:10 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 May 2013 03:31:10 +0000 Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular encoding In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za> Message-ID: <1369107070.93.0.420793805784.issue13612@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I can propose only raise a specialized exception instead of general xml.etree.ElementTree.ParseError. Here is a patch. It also fixes a buffer overread bug mentioned by Amaury. ---------- components: +Extension Modules, Unicode, XML -Library (Lib) keywords: +patch nosy: +ezio.melotti stage: -> patch review versions: +Python 3.4 Added file: http://bugs.python.org/file30328/expat_unknown_encoding_handler.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 05:33:27 2013 From: report at bugs.python.org (Roger Serwy) Date: Tue, 21 May 2013 03:33:27 +0000 Subject: [issue17511] Idle find function closes after each find operation In-Reply-To: <1363902452.43.0.911749750934.issue17511@psf.upfronthosting.co.za> Message-ID: <1369107207.36.0.771071403521.issue17511@psf.upfronthosting.co.za> Roger Serwy added the comment: issue_17511_FindNext_rev1.patch keeps the find dialog open and changes the button from "Find" to "Find Next". The applied patch from #14146 corrects the selection tag highlighting issue. ---------- Added file: http://bugs.python.org/file30329/issue_17511_FindNext_rev1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 05:42:15 2013 From: report at bugs.python.org (Roger Serwy) Date: Tue, 21 May 2013 03:42:15 +0000 Subject: [issue17658] pythonw.exe crashes on opening IDLE In-Reply-To: <1365393115.5.0.931092283515.issue17658@psf.upfronthosting.co.za> Message-ID: <1369107735.06.0.567106532096.issue17658@psf.upfronthosting.co.za> Roger Serwy added the comment: Patrick, does removing PYTHONPATH from your environment variables fix this problem? ---------- nosy: +roger.serwy status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 06:03:46 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 21 May 2013 04:03:46 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1369109026.43.0.212708467458.issue15392@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The change to the two idlelib/*.py files enables those files to run their corresponding idle_test/test_*.py file when run as a main script. They have nothing to do with running test/test_idle.py. So please try running the latter. python -m test.test_idle # direct, without regrtest python -m test test_idle # indirect, with regrtest I upgraded(?) TortoiseHG (2.8, with hg 2.6) and found the setting for Notepad++ to create new files in 'unix/osx' format, which I presume refers to line endings. Does the new file apply better for you? If so, I will try to always use this for uploaded patches. --- Question: when I import this patch (either format) to 3.4, it applies the chunks and makes the changes with no apparent problem, but then 'aborts' -- but not really, because it leaves the changes: abort: edit failed: vi exited with status 1 [command returned code 255 Mon May 20 23:08:16 2013] The appear to be a failure of the commit message editor? If so, it is tolerable, but it worked a week ago (regression in upgrade?), though i have seen it before. Manual says "If the patch you are importing does not have a commit message, Mercurial will try to launch your editor, just as if you had tried to import the patch from the command line. Your ui.editor needs to be a GUI app to make this work correctly." I get same message after setting editor to notepad or notepad++, so 'vi' mystifies me. Anyone have any idea? ---- ---------- Added file: http://bugs.python.org/file30330/idletest3u.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 07:34:33 2013 From: report at bugs.python.org (William Moreno) Date: Tue, 21 May 2013 05:34:33 +0000 Subject: [issue18008] python33-3.3.2 Parser/pgen: Permission denied In-Reply-To: <1368891906.35.0.458659072685.issue18008@psf.upfronthosting.co.za> Message-ID: <1369114473.54.0.107912835915.issue18008@psf.upfronthosting.co.za> William Moreno added the comment: [SOLVED on FreeBSD 9.1] if anyone need to see http://www.freshports.org/lang/python33/ thank's again to alls specyally to Marcus von Appen (marcusva) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 07:36:50 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 21 May 2013 05:36:50 +0000 Subject: [issue11489] json.dumps not parsable by json.loads (on Linux only) In-Reply-To: <1300058240.59.0.513243746739.issue11489@psf.upfronthosting.co.za> Message-ID: <1369114610.9.0.844480038047.issue11489@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 08:21:09 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 21 May 2013 06:21:09 +0000 Subject: [issue17973] FAQ entry for: '+=' on a list inside tuple both succeeds and raises an exception In-Reply-To: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> Message-ID: <1369117269.45.0.749716619154.issue17973@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I agree that there's probably no good solution here. Catching TypeError would require emitting a lot more byte code, and would change the semantics of augmented assignment, in particular it wouldn't really be an assignment statement anymore (and hides some flow control). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 09:43:07 2013 From: report at bugs.python.org (Tillmann Karras) Date: Tue, 21 May 2013 07:43:07 +0000 Subject: [issue17140] Provide a more obvious public ThreadPool API In-Reply-To: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za> Message-ID: <1369122187.14.0.837912826057.issue17140@psf.upfronthosting.co.za> Changes by Tillmann Karras : ---------- nosy: +Tilka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 09:49:45 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 May 2013 07:49:45 +0000 Subject: [issue17683] socket.getsockname() inconsistent return type with AF_UNIX In-Reply-To: <1365555770.86.0.711874075927.issue17683@psf.upfronthosting.co.za> Message-ID: <3bF8JS6p6RzPns@mail.python.org> Roundup Robot added the comment: New changeset c0f2b038fc12 by Charles-Fran?ois Natali in branch 'default': Issue #17683: socket module: return AF_UNIX addresses in Linux abstract http://hg.python.org/cpython/rev/c0f2b038fc12 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 10:24:38 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 21 May 2013 08:24:38 +0000 Subject: [issue17683] socket.getsockname() inconsistent return type with AF_UNIX In-Reply-To: <3bF8JS6p6RzPns@mail.python.org> Message-ID: Charles-Fran?ois Natali added the comment: Antoine, I need your help :-) http://buildbot.python.org/all/builders/x86 Gentoo Non-Debug 3.x/builds/4311/steps/test/logs/stdio """ ====================================================================== ERROR: testLinuxAbstractNamespace (test.test_socket.TestLinuxAbstractNamespace) ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/lib/buildslave/3.x.murray-gentoo-wide/build/Lib/test/test_socket.py", line 4456, in testLinuxAbstractNamespace s1.bind(address) UnicodeEncodeError: 'ascii' codec can't encode character '\xff' in position 19: ordinal not in range(128) """ I don't know jack s*** about encoding, but from what I understand, the problem is that the test is passing an invalid ordinal, now that test is passing a string. Should I revert this part of the test (i.e. make the passed address a bytes again)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 10:28:08 2013 From: report at bugs.python.org (Anselm Kruis) Date: Tue, 21 May 2013 08:28:08 +0000 Subject: [issue18004] test_list.test_overflow crashes Win64 In-Reply-To: <1368834409.49.0.790067586607.issue18004@psf.upfronthosting.co.za> Message-ID: <1369124888.77.0.852190024448.issue18004@psf.upfronthosting.co.za> Anselm Kruis added the comment: > I take it you have more than 16GB of RAM? I used a system with 16GB Ram. > What happens if you replace "sys.maxint" with "sys.maxsize" in test_overflow? The test passes. Both mul and imul raise MemoryError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 10:32:22 2013 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Tue, 21 May 2013 08:32:22 +0000 Subject: [issue18028] Warnings with -fstrict-aliasing Message-ID: <1369125142.14.0.432992440388.issue18028@psf.upfronthosting.co.za> New submission from Bohuslav "Slavek" Kabrda: Hi, I'm getting these warnings with -fstrict-aliasing, compiling Python 3.3.2 (compiling with gcc 4.4.7): /builddir/build/BUILD/Python-3.3.2/Python/ceval.c: In function 'PyEval_EvalFrameEx': /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:1006: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:1007: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:1008: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:1009: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:1249: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:1258: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:1372: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2358: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2362: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2377: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2379: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2388: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2390: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2743: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2745: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2896: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:2909: warning: dereferencing type-punned pointer will break strict-aliasing rules /builddir/build/BUILD/Python-3.3.2/Python/ceval.c:3035: warning: dereferencing type-punned pointer will break strict-aliasing rules This seems to be quite serious, but I'm not a C expert, so I'd like to know whether this is a false positive or this is actually a dangerous bug. Thanks. ---------- components: Build messages: 189729 nosy: bkabrda priority: normal severity: normal status: open title: Warnings with -fstrict-aliasing versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 10:37:40 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 21 May 2013 08:37:40 +0000 Subject: [issue17683] socket.getsockname() inconsistent return type with AF_UNIX In-Reply-To: Message-ID: Charles-Fran?ois Natali added the comment: Hum, IIUC, basically what happens is that the user could - and still can - pass arbitrary bytes as address (which is legtit), but depending on the encoding, getsockaddr() and friends might blow up when decoding it. If that's correct, that's bad, and that would be a good reason to keep bytes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 10:39:26 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 21 May 2013 08:39:26 +0000 Subject: [issue13146] Writing a pyc file is not atomic In-Reply-To: <1318275475.02.0.82335017062.issue13146@psf.upfronthosting.co.za> Message-ID: <1369125566.41.0.450149114108.issue13146@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 10:51:25 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 21 May 2013 08:51:25 +0000 Subject: [issue18028] Warnings with -fstrict-aliasing In-Reply-To: <1369125142.14.0.432992440388.issue18028@psf.upfronthosting.co.za> Message-ID: <1369126285.45.0.790126900272.issue18028@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Your Python/ceval.c has custom patches applied. Line 1006 is a comment in unmodified Python/ceval.c in Python 3.3.2. This bug might be caused by your patches. Alternatively it is a bug in GCC 4.4.7. I get 0 warnings for unmodified Python/ceval.c with GCC 4.7.3. ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 10:54:48 2013 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 21 May 2013 08:54:48 +0000 Subject: [issue6299] pyexpat build failure on Solaris 10 for 2.6.1/2.6.2 In-Reply-To: <1245269274.21.0.966496864817.issue6299@psf.upfronthosting.co.za> Message-ID: <1369126488.31.0.36229477523.issue6299@psf.upfronthosting.co.za> Mark Lawrence added the comment: Is this still a problem given that both Python and Solaris have moved on? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 10:56:13 2013 From: report at bugs.python.org (=?utf-8?q?Guilherme_Sim=C3=B5es?=) Date: Tue, 21 May 2013 08:56:13 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1369126573.54.0.596607622583.issue15392@psf.upfronthosting.co.za> Guilherme Sim?es added the comment: Now I can apply the patch successfully and everything seems to be working. Thanks, Terry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 11:07:55 2013 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Tue, 21 May 2013 09:07:55 +0000 Subject: [issue18028] Warnings with -fstrict-aliasing In-Reply-To: <1369125142.14.0.432992440388.issue18028@psf.upfronthosting.co.za> Message-ID: <1369127275.85.0.968300097102.issue18028@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda added the comment: Hmm, you're probably right. The problem seems to be in downstream redefinition of READ_TIMESTAMP. Sorry for the fuzz, closing. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 11:07:58 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 21 May 2013 09:07:58 +0000 Subject: [issue17917] use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() when applicable In-Reply-To: <1367845837.62.0.789153792923.issue17917@psf.upfronthosting.co.za> Message-ID: <1369127278.03.0.557179013148.issue17917@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 11:16:27 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 21 May 2013 09:16:27 +0000 Subject: [issue17914] add os.cpu_count() In-Reply-To: <1367838407.82.0.153634220851.issue17914@psf.upfronthosting.co.za> Message-ID: <1369127787.7.0.642653161692.issue17914@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 11:29:00 2013 From: report at bugs.python.org (Anselm Kruis) Date: Tue, 21 May 2013 09:29:00 +0000 Subject: [issue18015] python 2.7.5 fails to unpickle namedtuple pickled by 2.7.3 or 2.7.4 In-Reply-To: <1368988919.46.0.250713350438.issue18015@psf.upfronthosting.co.za> Message-ID: <1369128540.79.0.101308300173.issue18015@psf.upfronthosting.co.za> Anselm Kruis added the comment: Just for the records: the patch works as expected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 11:32:35 2013 From: report at bugs.python.org (Ralf Schmitt) Date: Tue, 21 May 2013 09:32:35 +0000 Subject: [issue18015] python 2.7.5 fails to unpickle namedtuple pickled by 2.7.3 or 2.7.4 In-Reply-To: <1368988919.46.0.250713350438.issue18015@psf.upfronthosting.co.za> Message-ID: <1369128755.21.0.289618553065.issue18015@psf.upfronthosting.co.za> Changes by Ralf Schmitt : ---------- nosy: +schmir _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 11:46:45 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Tue, 21 May 2013 09:46:45 +0000 Subject: [issue17917] use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() when applicable In-Reply-To: <1367845837.62.0.789153792923.issue17917@psf.upfronthosting.co.za> Message-ID: <1369129605.29.0.548686720549.issue17917@psf.upfronthosting.co.za> Tshepang Lekhonkhobe added the comment: @antoine I don't understand "This is a lot of code churn, but it touches code that is unlikely to be modified otherwise, so I guess it's ok.". What does it mean it's okay when it touches on code that's unlikely to be modified? ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 11:49:23 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 May 2013 09:49:23 +0000 Subject: [issue17900] Recursive OrderedDict pickling In-Reply-To: <1367610016.74.0.566900545996.issue17900@psf.upfronthosting.co.za> Message-ID: <3bFByV3yblzSyb@mail.python.org> Roundup Robot added the comment: New changeset 56f25569ba86 by Serhiy Storchaka in branch 'default': Issue #17900: Allowed pickling of recursive OrderedDicts. Decreased pickled http://hg.python.org/cpython/rev/56f25569ba86 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 11:53:19 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 21 May 2013 09:53:19 +0000 Subject: [issue17917] use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() when applicable In-Reply-To: <1369129605.29.0.548686720549.issue17917@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > I don't understand "This is a lot of code churn, but it touches code that is unlikely to be modified otherwise, so I guess it's ok.". What does it mean it's okay when it touches on code that's unlikely to be modified? The problem with refactoring is that it can complicate further merges between branches. In this case, the code is nearly never touched, so it's unlikely to be an issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 11:57:33 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 May 2013 09:57:33 +0000 Subject: [issue17900] Recursive OrderedDict pickling In-Reply-To: <1367610016.74.0.566900545996.issue17900@psf.upfronthosting.co.za> Message-ID: <1369130253.38.0.707105287315.issue17900@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 11:59:36 2013 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Tue, 21 May 2013 09:59:36 +0000 Subject: [issue18028] Warnings with -fstrict-aliasing In-Reply-To: <1369125142.14.0.432992440388.issue18028@psf.upfronthosting.co.za> Message-ID: <1369130376.03.0.256804549216.issue18028@psf.upfronthosting.co.za> Bohuslav "Slavek" Kabrda added the comment: Actually, this appears on vanilla Python 3.3 with -DWITH_TSC: Python/ceval.c: In function ?PyEval_EvalFrameEx?: Python/ceval.c:986:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(inst0); ^ Python/ceval.c:987:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(inst1); ^ Python/ceval.c:988:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(loop0); ^ Python/ceval.c:989:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(loop1); ^ Python/ceval.c:1225:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(inst1); ^ Python/ceval.c:1234:9: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(loop0); ^ Python/ceval.c:1348:9: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(inst0); ^ Python/ceval.c:2334:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(intr0); ^ Python/ceval.c:2338:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(intr1); ^ Python/ceval.c:2353:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(intr0); ^ Python/ceval.c:2355:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(intr1); ^ Python/ceval.c:2364:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(intr0); ^ Python/ceval.c:2366:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(intr1); ^ Python/ceval.c:2719:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(intr0); ^ Python/ceval.c:2721:13: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(intr1); ^ Python/ceval.c:2872:9: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(inst1); ^ Python/ceval.c:2885:21: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(loop1); ^ Python/ceval.c:3011:9: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] READ_TIMESTAMP(loop1); ^ ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 12:20:00 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 May 2013 10:20:00 +0000 Subject: [issue17844] Add link to alternatives for bytes-to-bytes codecs In-Reply-To: <1366889842.88.0.0886939266057.issue17844@psf.upfronthosting.co.za> Message-ID: <1369131600.76.0.237810331745.issue17844@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Not a bad idea. How about implementation? Here is updated patches for 3.x and 2.7. Note that in 2.7 I split codecs table as in 3.x. ---------- Added file: http://bugs.python.org/file30331/doc_codecs_impl.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 12:20:49 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 May 2013 10:20:49 +0000 Subject: [issue17844] Add link to alternatives for bytes-to-bytes codecs In-Reply-To: <1366889842.88.0.0886939266057.issue17844@psf.upfronthosting.co.za> Message-ID: <1369131649.43.0.187705160518.issue17844@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file30332/doc_codecs_impl-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 12:21:20 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 May 2013 10:21:20 +0000 Subject: [issue17844] Add link to alternatives for bytes-to-bytes codecs In-Reply-To: <1366889842.88.0.0886939266057.issue17844@psf.upfronthosting.co.za> Message-ID: <1369131680.21.0.900462729226.issue17844@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file30013/doc_codecs_impl.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 12:41:28 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 May 2013 10:41:28 +0000 Subject: [issue17683] socket.getsockname() inconsistent return type with AF_UNIX In-Reply-To: Message-ID: <1369132880.2545.0.camel@fsol> Antoine Pitrou added the comment: > Hum, IIUC, basically what happens is that the user could - and still > can - pass arbitrary bytes as address (which is legtit), but depending > on the encoding, getsockaddr() and friends might blow up when decoding > it. Shouldn't the surrogateescape error handler (PEP 383) prevent this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 12:50:57 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 21 May 2013 10:50:57 +0000 Subject: [issue17140] Provide a more obvious public ThreadPool API In-Reply-To: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za> Message-ID: <1369133457.36.0.19008025383.issue17140@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Given that the change could only be made to 3.4, and we already have concurrent.futures.ThreadPoolExecutor, I am not sure there is much point to such a change now. ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 13:14:27 2013 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 21 May 2013 11:14:27 +0000 Subject: [issue17844] Add link to alternatives for bytes-to-bytes codecs In-Reply-To: <1366889842.88.0.0886939266057.issue17844@psf.upfronthosting.co.za> Message-ID: <1369134867.38.0.625712907705.issue17844@psf.upfronthosting.co.za> Nick Coghlan added the comment: I like the idea of splitting the table in 2.7 rather than using a result type column. However, the two intro paragraphs need a bit of work. How does the following sound: 1. Create a new subheading at the same level as the current "Standard Encodings" heading: "Python Specific Encodings" 2. Split out rot-13 to its own table in Python 2.7 as well 3. Under the new subheading, have the following text introducing the tables: ---- A number of predefined codecs are specific to Python, so their codec names have no meaning outside Python. These are listed in the tables below based on the expected input and output types (note that while text encodings are the most common use case for codecs, the underlying codec infrastructure supports arbitrary data transforms rather than just text encodings). For asymmetric codecs, the stated purpose describes the encoding direction. The following codecs provide text-to-binary encoding and binary-to-text decoding, similar to the Unicode text encodings. ---- The following codecs provide binary-to-binary encoding and decoding. ---- The following codecs provide text-to-text encoding and decoding. ---- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 13:16:06 2013 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 21 May 2013 11:16:06 +0000 Subject: [issue17140] Provide a more obvious public ThreadPool API In-Reply-To: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za> Message-ID: <1369134966.72.0.644667410332.issue17140@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thread Pools can be handy when you want to do explicit message passing, rather than the call-and-response model favoured by the futures module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 13:41:41 2013 From: report at bugs.python.org (Paul Moore) Date: Tue, 21 May 2013 11:41:41 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za> Message-ID: <1369136501.33.0.859826764196.issue12641@psf.upfronthosting.co.za> Changes by Paul Moore : ---------- nosy: +pmoore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 13:56:39 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 21 May 2013 11:56:39 +0000 Subject: [issue17140] Provide a more obvious public ThreadPool API In-Reply-To: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za> Message-ID: <1369137399.55.0.0465819737701.issue17140@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I don't understand what you mean by "explicit message passing" and "call-and-response model". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 14:21:37 2013 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 21 May 2013 12:21:37 +0000 Subject: [issue17140] Provide a more obvious public ThreadPool API In-Reply-To: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za> Message-ID: <1369138897.88.0.169281099863.issue17140@psf.upfronthosting.co.za> Nick Coghlan added the comment: Future are explicitly about kicking off a concurrent call and waiting for a reply. They're great for master/slave and client/server models, but not particularly good for actors and other forms of peer-to-peer message passing. For the latter, explicit pools and message queues are still the way to go, and that's why I think a concurrent.pool module may still be useful as a more obvious entry point for the thread pool implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 14:34:50 2013 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Tue, 21 May 2013 12:34:50 +0000 Subject: [issue17453] logging.config.fileConfig error In-Reply-To: <1363592089.61.0.213350705624.issue17453@psf.upfronthosting.co.za> Message-ID: <1369139690.07.0.221089764351.issue17453@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- resolution: -> works for me stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 14:39:04 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 May 2013 12:39:04 +0000 Subject: [issue17844] Add link to alternatives for bytes-to-bytes codecs In-Reply-To: <1366889842.88.0.0886939266057.issue17844@psf.upfronthosting.co.za> Message-ID: <1369139944.85.0.436449420415.issue17844@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > However, the two intro paragraphs need a bit of work. Yes, it's a help which I needed. Thank you. However your wording is not entirely correct. In 2.7 binary-to-binary codecs and rot-13 works with Unicode strings (only ascii-compatible) as with bytes strings. >>> u'Python'.encode('base64') 'UHl0aG9u\n' >>> u'UHl0aG9u'.decode('base64') 'Python' >>> u'Python\u20ac'.encode('base64') Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython-2.7/Lib/encodings/base64_codec.py", line 24, in base64_encode output = base64.encodestring(input) File "/home/serhiy/py/cpython-2.7/Lib/base64.py", line 315, in encodestring pieces.append(binascii.b2a_base64(chunk)) UnicodeEncodeError: 'ascii' codec can't encode character u'\u20ac' in position 6: ordinal not in range(128) Rot-13 works as common text-to-binary encoding (encode returns str, decode returns unicode). >>> u'Python'.encode('rot13') 'Clguba' >>> u'Python'.decode('rot13') u'Clguba' >>> 'Python'.encode('rot13') 'Clguba' >>> 'Python'.decode('rot13') u'Clguba' >>> u'Python\u20ac'.encode('rot13') Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython-2.7/Lib/encodings/rot_13.py", line 17, in encode return codecs.charmap_encode(input,errors,encoding_map) UnicodeEncodeError: 'charmap' codec can't encode character u'\u20ac' in position 6: character maps to >>> u'Python\u20ac'.decode('rot13') Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython-2.7/Lib/encodings/rot_13.py", line 20, in decode return codecs.charmap_decode(input,errors,decoding_map) UnicodeEncodeError: 'ascii' codec can't encode character u'\u20ac' in position 6: ordinal not in range(128) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 15:00:07 2013 From: report at bugs.python.org (Ken Giusti) Date: Tue, 21 May 2013 13:00:07 +0000 Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za> Message-ID: <1369141207.53.0.751789003819.issue8240@psf.upfronthosting.co.za> Changes by Ken Giusti : ---------- nosy: +Ken.Giusti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 15:08:45 2013 From: report at bugs.python.org (Oscar Benjamin) Date: Tue, 21 May 2013 13:08:45 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za> Message-ID: <1369141725.02.0.445189613045.issue12641@psf.upfronthosting.co.za> Oscar Benjamin added the comment: I'd really like to get a resolution on this issue so I've tried to gather some more information about this problem by asking some questions in the mingw-users mailing list. The resulting thread can be found here: http://comments.gmane.org/gmane.comp.gnu.mingw.user/42092 This issue concerns users of distutils --compiler=mingw32 mode. Normally this is used to build with mingw gcc in which case it is currently broken because of -mno-cygwin. It has been suggested above that some may be using it to build with cygwin's gcc. The -mno-cygwin option is there for those using cygwin's gcc. To summarise the points (see the thread on mingw-users for more info): 1) -mno-cygwin has never had a meaningful effect in mingw. 2) -mno-cygwin produces an error in recent (~2011 onwards) mingw releases and will do for all future releases. This prevents distutils from building extensions with mingw. 3) -mno-cygwin only ever had a meaningful effect for cygwin's gcc 3.x where it could be used to build binaries that did not depend in cygwin.dll. 4) -mno-cygwin was always considered an experimental feature and its use is discouraged. 5) -mno-cygwin was removed from cygwin's gcc in the transition from 3.x to 4.x without any deprecation period (as it was an experimental feature). In gcc 4.x it produces an error preventing build. 6) The recommended way to replace the -mno-cygwin option is either to use mingw or to use cygwin's cross-compilers. So there are two types of breakage affected by -mno-cygwin: A: Anyone trying to use recent and future mingw versions to build extensions with distutils in the way that is described in the distutils docs. For this group distutils has been broken for 2 years and will continue to be until the -mno-cygwin option is removed. B: Anyone who is using distutils with --compiler=mingw32 but using cygwin's gcc 3.x instead of mingw's gcc to build an extension for a non-cygwin Python. For this group removing the -mno-cygwin option would result in unusable extension modules. (the resulting .pyd requires cygwin.dll but is to be used in a non-cygwin Python). Firstly, note that users in group B must surely be a group that diminishes with time since they are using the legacy gcc 3.x cygwin compiler. Similarly, since neither of mingw or cygwin will ever bring back -mno-cygwin users in group A will only increase with time. (I am such a user and have been manually removing all reference to -mno-cygwin from distutils for 2 years now.) This means that the balance of breakage will only move towards group A over time. Secondly, any users in group B will suffer the same problem as users in group A if they try to use gcc 4.x. However this has not been reported on the tracker (I read through all matches in a search for '-mno-cygwin'). I think this serves as an indication of how many people are actually using this setup. Thirdly, the -mno-cygwin option is a now-abandoned, experimental feature of a legacy compiler. Its creators did not feel the need to give it a deprecation period and its use is discouraged by both mingw and cygwin. Bringing these points together: not removing -mno-cygwin from distutils trades the possible breakage for possibly non-existent users of the obscure, legacy, and generally considered broken setup B against the definite, known breakage for users of the appropriate documented setup A. I think this should be enough to say that the fix for the next Python version should simply remove all reference to '-mno-cygwin' as I have been doing for 2 years now without problem. The only users who can be adversely affected by this are those in group B who decide to upgrade to non-cygwin Python 3.4 (while still using an ancient cygwin gcc to build extensions). The suggested fix can be either to use mingw or to setup the cross-compilers in their cygwin installation. For Python 2.7, 3.2 and 3.3 I think that this should be considered a bug that can be fixed in a bugfix release. However in that case it may be considered inappropriate to risk the small possibility of users in group B experiencing breakage. Since such users must be using cygwin's gcc 3.x, I propose that distutils check the gcc version and only add '-mno-cygwin' if the major version is 3. This will not adversely affect users in group B and will fix the problem for users in group A. Users in group B who attempt to use gcc 4.x will find that they get a different error message (at import time instead of build time) but that their setup will still be just as broken as it was before this change. Thanks, Oscar ---------- nosy: +oscarbenjamin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 15:12:11 2013 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 21 May 2013 13:12:11 +0000 Subject: [issue17844] Add link to alternatives for bytes-to-bytes codecs In-Reply-To: <1366889842.88.0.0886939266057.issue17844@psf.upfronthosting.co.za> Message-ID: <1369141931.45.0.202348318231.issue17844@psf.upfronthosting.co.za> Nick Coghlan added the comment: While the Python 2 text model was almost certainly a necessary transition step to full unicode support, it is things like this that highlight how fundamentally broken implicit conversion turned out to be at a conceptual level :P Perhaps the following would work for 2.7 then (with rot-13 in the first table), with footnotes added to cover the quirks of the implicit type conversions between str and unicode: ---- A number of predefined codecs are specific to Python, so their codec names have no meaning outside Python. These are listed in the tables below based on the expected input and output types (note that while text encodings are the most common use case for codecs, the underlying codec infrastructure supports arbitrary data transforms rather than just text encodings). For asymmetric codecs, the stated purpose describes the encoding direction. The following codecs provide unicode-to-str encoding [#1] and str-to-unicode decoding [#2], similar to the Unicode text encodings. ---- The following codecs provide str-to-str encoding and decoding [#2]. ---- .. [#1] str objects are also accepted as input in place of unicode objects. They are implicitly converted to unicode by decoding them using the default encoding. If this conversion fails, it may lead to encoding operations raising :exc:`UnicodeDecodeError`. .. [#2] unicode objects are also accepted as input in place of str objects. They are implicitly converted to str by encoding them using the default encoding. If this conversion fails, it may lead to decoding operations raising :exc:`UnicodeEncodeError`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 15:17:11 2013 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Tue, 21 May 2013 13:17:11 +0000 Subject: [issue7434] general pprint rewrite In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za> Message-ID: <1369142231.17.0.136903949189.issue7434@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- Removed message: http://bugs.python.org/msg138819 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 15:18:33 2013 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Tue, 21 May 2013 13:18:33 +0000 Subject: [issue7434] general pprint rewrite In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za> Message-ID: <1369142313.1.0.121598065373.issue7434@psf.upfronthosting.co.za> ?ukasz Langa added the comment: For the record, my class-based approach from 2010 still available here: https://bitbucket.org/ambv/nattyprint ---------- versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 15:23:48 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 21 May 2013 13:23:48 +0000 Subject: [issue7434] general pprint rewrite In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za> Message-ID: <1369142628.35.0.0921829965097.issue7434@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 15:26:48 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 21 May 2013 13:26:48 +0000 Subject: [issue17140] Provide a more obvious public ThreadPool API In-Reply-To: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za> Message-ID: <1369142808.23.0.182247445771.issue17140@psf.upfronthosting.co.za> Richard Oudkerk added the comment: As far as I can see they are mostly equivalent. For instance, ApplyResult (the type returned by Pool.apply_async()) is virtually the same as a Future. When you say "explicit message passing", do you mean creating a queue and making the worker tasks put results on that queue? Why can't you do the same with ThreadPoolExecutor? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 15:34:56 2013 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 21 May 2013 13:34:56 +0000 Subject: [issue2226] Small _abcoll Bugs / Oddities In-Reply-To: <1204579501.7.0.0188509512316.issue2226@psf.upfronthosting.co.za> Message-ID: <1369143296.41.0.0199663076852.issue2226@psf.upfronthosting.co.za> Nick Coghlan added the comment: Armin pointed out in http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/ that one nasty consequence of the remaining part of this bug and issue 8743 is making it much harder than it should be to use the ItemsView, KeysView and ValuesView from collections.abc to implement third party mappings that behave like the builtin dict. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 15:35:47 2013 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 21 May 2013 13:35:47 +0000 Subject: [issue8743] set() operators don't work with collections.Set instances In-Reply-To: <1274122246.37.0.692277131409.issue8743@psf.upfronthosting.co.za> Message-ID: <1369143347.27.0.246340683894.issue8743@psf.upfronthosting.co.za> Nick Coghlan added the comment: Armin pointed out in http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/ that one nasty consequence of the remaining part of issue 2226 and this bug is making it much harder than it should be to use the ItemsView, KeysView and ValuesView from collections.abc to implement third party mappings that behave like the builtin dict. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 15:38:27 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 21 May 2013 13:38:27 +0000 Subject: [issue17967] urllib2.open failed to access a url when a perent directory of the url is permission denied In-Reply-To: <1368424209.99.0.52540499369.issue17967@psf.upfronthosting.co.za> Message-ID: <1369143507.3.0.445178027538.issue17967@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Hello zhaoqifa, Your suggestion for the solution looks good to me. Instead of cd-ing to each dir, you cd to target dir when ftp url is accessed. Two things to consider. 1) Will the above change have any security implications. It does not seem to me. But I did not write that code originally that way either. 2) On Ubuntu, I am unable to setup a directory based (ACL'ed) anonymous ftp server. The option is either anonymous from ftp root (/) which will map to my operating system folder (/srv/ftp) or non-anonymous. I wonder how your server is configured to allow anonymous from a particular point onwards. ---------- assignee: -> orsenthil versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 15:43:28 2013 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 21 May 2013 13:43:28 +0000 Subject: [issue17140] Provide a more obvious public ThreadPool API In-Reply-To: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za> Message-ID: <1369143808.32.0.181040486938.issue17140@psf.upfronthosting.co.za> Nick Coghlan added the comment: No, I mean implementing communicating sequential processes with independent state machines passing messages to each other. There aren't necessarily any fixed request/reply pairs. Each actor has a "mailbox", which is a queue that you dump its messages into. If you want a reply, you'll include some kind of addressing info to get the answer back rather than receiving it back on the channel you used to send the message. For threads, the addressing info can just be a queue.Queue reference for your own mailbox, for multiple processes it can either be multiprocessing queue, or any other form of IPC. It's a very different architecture from that assumed by futures, so you need to drop down to the pool layer rather than using the executor model. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 16:04:00 2013 From: report at bugs.python.org (Paul Moore) Date: Tue, 21 May 2013 14:04:00 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za> Message-ID: <1369145040.72.0.731990443487.issue12641@psf.upfronthosting.co.za> Paul Moore added the comment: +1 for Oscar's proposed fix. It sounds like a sensible approach. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 16:09:17 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 21 May 2013 14:09:17 +0000 Subject: [issue17996] socket module should expose AF_LINK In-Reply-To: <1369098868.4.0.472300861424.issue17996@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: > Nevermind, it seems changing regen is not necessary. Patch is in attachment. Go ahead! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 16:13:28 2013 From: report at bugs.python.org (David Cuddihy) Date: Tue, 21 May 2013 14:13:28 +0000 Subject: [issue17525] os.getcwd() fails on cifs share In-Reply-To: <1363990327.07.0.260090776617.issue17525@psf.upfronthosting.co.za> Message-ID: <1369145608.81.0.919123595367.issue17525@psf.upfronthosting.co.za> David Cuddihy added the comment: I apologize for not posting the strace output - I didn't see the request until today. Libc getcwd() is indeed failing - when I run a c program which calls getcwd() and prints the output, the call to getcwd() fails - errno is ENOENT and the buffer is null. I will look elsewhere. Thanks for getting me on the right track. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 16:16:28 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 21 May 2013 14:16:28 +0000 Subject: [issue17140] Provide a more obvious public ThreadPool API In-Reply-To: <1369143808.32.0.181040486938.issue17140@psf.upfronthosting.co.za> Message-ID: <519B81B5.4040809@gmail.com> Richard Oudkerk added the comment: > It's a very different architecture from that assumed by futures, > so you need to drop down to the pool layer rather than using the > executor model. AIUI an ThreadPoolExecutor object (which must be explicitly created) represents a thread/process pool, and it is used to send tasks to the workers in the pool. And if you want to ignore the future object returned by submit(), then you can. How is that any different from a ThreadPool object? And if you are impementing actors on top of a thread pool then isn't there a limit on the number "active" actors there can be at any one time, potentially creating deadlocks because all workers are waiting for messages from an actor which cannot run yet. (I am probably misunderstanding what you mean.) To me, the obvious way to implement actors would be to create one thread/process for each actor. In Python 3.4 one could use the tulip equivalents instead for better scalability. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 16:21:57 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Tue, 21 May 2013 14:21:57 +0000 Subject: [issue13483] Use VirtualAlloc to allocate memory arenas In-Reply-To: <1322313162.87.0.914810161445.issue13483@psf.upfronthosting.co.za> Message-ID: <1369146117.55.0.390510953896.issue13483@psf.upfronthosting.co.za> Charles-Fran?ois Natali added the comment: Martin, do you think your latest patch can be committed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 16:28:18 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 May 2013 14:28:18 +0000 Subject: [issue17844] Add link to alternatives for bytes-to-bytes codecs In-Reply-To: <1366889842.88.0.0886939266057.issue17844@psf.upfronthosting.co.za> Message-ID: <1369146498.57.0.886563224728.issue17844@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Nick. Here is an updated patch for 2.7. ---------- Added file: http://bugs.python.org/file30333/doc_codecs_impl-2.7_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 16:30:16 2013 From: report at bugs.python.org (Florent Xicluna) Date: Tue, 21 May 2013 14:30:16 +0000 Subject: [issue17844] Add link to alternatives for bytes-to-bytes codecs In-Reply-To: <1366889842.88.0.0886939266057.issue17844@psf.upfronthosting.co.za> Message-ID: <1369146616.43.0.202417469712.issue17844@psf.upfronthosting.co.za> Changes by Florent Xicluna : ---------- nosy: +flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 16:32:19 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 May 2013 14:32:19 +0000 Subject: [issue17844] Add link to alternatives for bytes-to-bytes codecs In-Reply-To: <1366889842.88.0.0886939266057.issue17844@psf.upfronthosting.co.za> Message-ID: <1369146739.48.0.344216727084.issue17844@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file30332/doc_codecs_impl-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 17:00:11 2013 From: report at bugs.python.org (Donal Duane) Date: Tue, 21 May 2013 15:00:11 +0000 Subject: [issue18029] Python SSL support is missing from SPARC build Message-ID: <1369148411.16.0.857951754305.issue18029@psf.upfronthosting.co.za> New submission from Donal Duane: Hi, We have 2 Python 3.2 builds - one on x86 (Solaris 10), and one on SPARC (Solaris 10). The x86 build works fine for SSL, but the SPARC build was either built without SSL support pecified, or, there was an issue with the build. $ bash $ . /etc/opt/ericsson/system.env $ export PYTHONPATH PYTHONHOME PYTHON_HOME_3PP $ /opt/python/python/python3.2 Python 3.2.2 (default, Nov 16 2011, 05:23:55) [GCC 3.4.6] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import _ssl Traceback (most recent call last): File "", line 1, in ImportError: No module named _ssl >>> $ ls -l /opt/python/python/lib-dynload/ | grep ssl -r-xr-xr-x 1 root other 110604 Nov 21 2011 _ssl_failed.so are there any know issues with building in SSL support to Python 3.2 on Solaris SPARC 10? If not - is there anyway to include it POST-compile? Any support much appreciated. Regards, D?nal ---------- components: Extension Modules messages: 189762 nosy: eeiddne priority: normal severity: normal status: open title: Python SSL support is missing from SPARC build type: security versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 17:08:15 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 May 2013 15:08:15 +0000 Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za> Message-ID: <1369148895.94.0.813072340796.issue8240@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm thinking that perhaps we should simply enable SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER by default. Ben, what do you think? Does the current behaviour allow to catch bugs? ---------- type: behavior -> enhancement versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 17:48:00 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 May 2013 15:48:00 +0000 Subject: [issue17973] FAQ entry for: '+=' on a list inside tuple both succeeds and raises an exception In-Reply-To: <1368519577.93.0.961015588209.issue17973@psf.upfronthosting.co.za> Message-ID: <3bFLwH26R9z7Lkg@mail.python.org> Roundup Robot added the comment: New changeset 6ab88d6527f1 by R David Murray in branch '3.3': #17973: fix technical inaccuracy in faq entry (it now passes doctest). http://hg.python.org/cpython/rev/6ab88d6527f1 New changeset 26588b6a39d9 by R David Murray in branch 'default': merge #17973: fix technical inaccuracy in faq entry (it now passes doctest). http://hg.python.org/cpython/rev/26588b6a39d9 New changeset 7fce9186accb by R David Murray in branch '2.7': #17973: fix technical inaccuracy in faq entry (it now passes doctest). http://hg.python.org/cpython/rev/7fce9186accb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 18:01:03 2013 From: report at bugs.python.org (Pascal Chambon) Date: Tue, 21 May 2013 16:01:03 +0000 Subject: [issue17716] From ... import fails when parent package failed but child module succeeded, yet works in std import case In-Reply-To: <1365869097.02.0.582677403017.issue17716@psf.upfronthosting.co.za> Message-ID: <1369152063.34.0.15383249007.issue17716@psf.upfronthosting.co.za> Pascal Chambon added the comment: Well, since it's a tough decision to make (erasing all children modules when rolling back parent, or instead reconnecting with children on 2nd import of parent), I guess it should be discussed on python-dev first, shouldn't it ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 18:04:18 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 May 2013 16:04:18 +0000 Subject: [issue18029] Python SSL support is missing from SPARC build In-Reply-To: <1369148411.16.0.857951754305.issue18029@psf.upfronthosting.co.za> Message-ID: <1369152258.09.0.832086424488.issue18029@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Do you build Python yourself? If so, check for any errors pertaining to the ssl module in the "make" output. "_ssl_failed.so" implies the module was built, but the resulting file failed to be imported dynamically by the interpreter, and thus was renamed to "XXX_failed.so". ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 18:06:38 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 21 May 2013 16:06:38 +0000 Subject: [issue18029] Python SSL support is missing from SPARC build In-Reply-To: <1369148411.16.0.857951754305.issue18029@psf.upfronthosting.co.za> Message-ID: <1369152398.2.0.718910508804.issue18029@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Donal, please understand that this tracker is primarily to report bugs, not to get support, so help on possible work-arounds is out of scope. That said, if you want to investigate further, please rename _ssl_failed.so back to _ssl.so, and then re-perform the import; then report any messages you get. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 18:17:00 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 May 2013 16:17:00 +0000 Subject: [issue17934] Add a frame method to clear expensive details In-Reply-To: <1368014042.2.0.41504275061.issue17934@psf.upfronthosting.co.za> Message-ID: <1369153020.68.0.645764322297.issue17934@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I will probably wait for PEP 442 adoption before finalizing this issue. ---------- dependencies: -Generator cleanup without tp_del _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 18:18:53 2013 From: report at bugs.python.org (Pete Forman) Date: Tue, 21 May 2013 16:18:53 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za> Message-ID: <1369153133.72.0.472413974828.issue12641@psf.upfronthosting.co.za> Pete Forman added the comment: Another +1 for Oscar. I've just done an install of Python 2.7.5 and had to hack cygwinccompiler.py again. I'm using mingw with gcc 4.6.2 on Windows 7. ---------- nosy: +Pete.Forman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 18:21:41 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 21 May 2013 16:21:41 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za> Message-ID: <1369153301.13.0.00251046961752.issue12641@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Oscar: I agree with your analysis, but it is incomplete. There is a group C: Users who have only cygwin gcc 4.x installed For those, the current setup will produce an error message, essentially telling them that the need to fix something (specifically: edit distutils, install mingw). With the proposed change, --compiler=mingw32 will produce a binary, but the binary will incorrectly depend on cygwin. They may not notice on their local system (since cygwin.dll is available), but only on customer systems. That said: which of Roumen's patches (if any) would you recommend for inclusion? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 18:24:28 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 21 May 2013 16:24:28 +0000 Subject: [issue13483] Use VirtualAlloc to allocate memory arenas In-Reply-To: <1322313162.87.0.914810161445.issue13483@psf.upfronthosting.co.za> Message-ID: <1369153468.24.0.776915762136.issue13483@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Antoine's request for benchmarks still stands. I continue to think that it should be applied even in absence of benchmarks. In the absence of third opinions on this specific aspect, I don't think it can be applied. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 18:45:42 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Tue, 21 May 2013 16:45:42 +0000 Subject: [issue17917] use PyModule_AddIntMacro() instead of PyModule_AddIntConstant() when applicable In-Reply-To: Message-ID: Tshepang Lekhonkhobe added the comment: Ok, I thought so. Just wanted to make sure. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 19:13:33 2013 From: report at bugs.python.org (W. Owen Parry) Date: Tue, 21 May 2013 17:13:33 +0000 Subject: [issue17545] os.listdir and os.path.join inconsistent on empty path In-Reply-To: <1364228813.43.0.916487849633.issue17545@psf.upfronthosting.co.za> Message-ID: <1369156413.22.0.357792195074.issue17545@psf.upfronthosting.co.za> W. Owen Parry added the comment: I suggest that this is a documentation issue. I have seen three classes of functions is os and os.path i - those which operate on path names only (os.path.join, os.path.dirname, etc) and do not depend on the state of the file system. Since these are string manipulation functions, they treat '' as the empty string. ii - those which turn path names into valid paths via knowledge of the state of the file system (os.path.abspath, os.path.normpath, etc). These treat '' as an empty relative path and thus equivalent to the current directory. iii - those which operate on valid paths only and thus depend on the state of the file system (os.listdir, os.stat, os.path.relpath, os.path.exists, etc). '' is not a valid path so these functions throw an exception. The documentation should clearly state which class a function belongs to. I will provide a patch sometime this week. os.walk is an odd duck - it has class iii behaviour except that it returns an empty iterator instead of raising an exception. Note that it still distinguishes between '' (invalid path) and '.' (current directory) and so is not a good reason to change os.listdir: >>> [x for x in os.walk('')] [] >>> [x for x in os.walk('.')] [('.', [], [])] in an empty directory. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 19:48:48 2013 From: report at bugs.python.org (Simon Nicolussi) Date: Tue, 21 May 2013 17:48:48 +0000 Subject: [issue18007] CookieJar expects request objects with origin_req_host attribute instead of method In-Reply-To: <1368891902.97.0.967044954731.issue18007@psf.upfronthosting.co.za> Message-ID: <1369158528.77.0.699793996341.issue18007@psf.upfronthosting.co.za> Simon Nicolussi added the comment: Requests 1.2.1 has been released to address this issue. An origin_req_host property has been added to the request object as a workaround. The original problem of mismatched documentation and behaviour still persists. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 19:57:27 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 21 May 2013 17:57:27 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1369159047.92.0.373066903096.issue15392@psf.upfronthosting.co.za> R. David Murray added the comment: regrtest now works for me, as does running test_idle.py directly and the simple minded unittest call: ./python -m unittest test.test_idle However, running an individual test doesn't. I don't see this as a show-stopper for committing this, but rather something we should figure out how to fix later. rdmurray at hey:~/python/p34>./python -m unittest test.test_idle ... ---------------------------------------------------------------------- Ran 3 tests in 0.003s OK rdmurray at hey:~/python/p34>./python -m unittest -v test.test_idle test_bad_entity (idlelib.idle_test.test_calltips.Test_get_entity) ... ok test_good_entity (idlelib.idle_test.test_calltips.Test_get_entity) ... ok test_DirBrowserTreeItem (idlelib.idle_test.test_pathbrowser.PathBrowserTest) ... ok ---------------------------------------------------------------------- Ran 3 tests in 0.004s OK rdmurray at hey:~/python/p34>./python -m unittest -v test.test_idle.idlelib.idle_test.test_calltips.Test_get_entity.test_bad_entity Traceback (most recent call last): File "/home/rdmurray/python/p34/Lib/runpy.py", line 160, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/home/rdmurray/python/p34/Lib/runpy.py", line 73, in _run_code exec(code, run_globals) File "/home/rdmurray/python/p34/Lib/unittest/__main__.py", line 19, in main(module=None) File "/home/rdmurray/python/p34/Lib/unittest/main.py", line 124, in __init__ self.parseArgs(argv) File "/home/rdmurray/python/p34/Lib/unittest/main.py", line 171, in parseArgs self.createTests() File "/home/rdmurray/python/p34/Lib/unittest/main.py", line 178, in createTests self.module) File "/home/rdmurray/python/p34/Lib/unittest/loader.py", line 145, in loadTestsFromNames suites = [self.loadTestsFromName(name, module) for name in names] File "/home/rdmurray/python/p34/Lib/unittest/loader.py", line 145, in suites = [self.loadTestsFromName(name, module) for name in names] File "/home/rdmurray/python/p34/Lib/unittest/loader.py", line 113, in loadTestsFromName parent, obj = obj, getattr(obj, part) AttributeError: 'module' object has no attribute 'idlelib' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 20:03:31 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 21 May 2013 18:03:31 +0000 Subject: [issue11959] smtpd cannot be used without affecting global state In-Reply-To: <1304111550.3.0.684224980767.issue11959@psf.upfronthosting.co.za> Message-ID: <1369159411.08.0.468151916865.issue11959@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 20:27:47 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 21 May 2013 18:27:47 +0000 Subject: [issue11959] smtpd cannot be used without affecting global state In-Reply-To: <1304111550.3.0.684224980767.issue11959@psf.upfronthosting.co.za> Message-ID: <1369160867.66.0.872349645576.issue11959@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: Looking back at this I think that allowing a map argument to be passed to SMTPChannel in order to allow running handlers in separate threads can be reasonable after all. I don't understand why create_socket() signature needs to be changed though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 21:02:15 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 May 2013 19:02:15 +0000 Subject: [issue17996] socket module should expose AF_LINK In-Reply-To: <1368757243.4.0.421622185164.issue17996@psf.upfronthosting.co.za> Message-ID: <3bFRDR0PtnzSWL@mail.python.org> Roundup Robot added the comment: New changeset 155e6fb309f5 by Giampaolo Rodola' in branch 'default': Fix issue #17996: expose socket.AF_LINK constant on BSD and OSX. http://hg.python.org/cpython/rev/155e6fb309f5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 21:03:12 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 21 May 2013 19:03:12 +0000 Subject: [issue17996] socket module should expose AF_LINK In-Reply-To: <1368757243.4.0.421622185164.issue17996@psf.upfronthosting.co.za> Message-ID: <1369162992.18.0.0281301729382.issue17996@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- assignee: -> giampaolo.rodola resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 21:07:24 2013 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 21 May 2013 19:07:24 +0000 Subject: [issue11959] smtpd cannot be used without affecting global state In-Reply-To: <1304111550.3.0.684224980767.issue11959@psf.upfronthosting.co.za> Message-ID: <1369163244.65.0.723699465396.issue11959@psf.upfronthosting.co.za> Vinay Sajip added the comment: I wasn't suggesting changing the signature of create_socket, I just thought that it needed to be reimplemented because it didn't pass a map to set_socket. I've had a look at it again, and a reimplementation of create_socket doesn't seem to be needed, after all, because: SMTPServer.__init__ can pass the map it received to dispatcher.__init__, which will cause it to be set in self._map. Then, when create_socket calls set_socket with no map, that will call add_channel with map=None, which will then cause self._map to be used. I'll update the patch as soon as I get a chance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 21:48:27 2013 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 21 May 2013 19:48:27 +0000 Subject: [issue2449] Improved serialization error logging in xmlrpclib In-Reply-To: <1206131988.04.0.901893858067.issue2449@psf.upfronthosting.co.za> Message-ID: <1369165707.7.0.57527279557.issue2449@psf.upfronthosting.co.za> Mark Lawrence added the comment: Slipped under the radar? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 21:54:41 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 May 2013 19:54:41 +0000 Subject: [issue17979] Cannot build 2.7 with --enable-unicode=no In-Reply-To: <1368574020.99.0.834797445108.issue17979@psf.upfronthosting.co.za> Message-ID: <3bFSNw2r3szSHm@mail.python.org> Roundup Robot added the comment: New changeset 8408eed151eb by Serhiy Storchaka in branch '2.7': Issue #17979: Fixed the re module in build with --disable-unicode. http://hg.python.org/cpython/rev/8408eed151eb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 21:59:39 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 May 2013 19:59:39 +0000 Subject: [issue17979] Cannot build 2.7 with --enable-unicode=no In-Reply-To: <1368574020.99.0.834797445108.issue17979@psf.upfronthosting.co.za> Message-ID: <1369166379.47.0.822322631867.issue17979@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The re module with --disable-unicode is still broken on platform with sizeof(int) > 4, but totally portable fix requires more code. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 22:32:53 2013 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 21 May 2013 20:32:53 +0000 Subject: [issue7727] xmlrpc library returns string which contain null ( \x00 ) In-Reply-To: <1263758368.94.0.169057465263.issue7727@psf.upfronthosting.co.za> Message-ID: <1369168372.99.0.724209716456.issue7727@psf.upfronthosting.co.za> Mark Lawrence added the comment: Even if the original patch is valid it will need reworking as xmlrpclib isn't in Python 3, the code is now in xmlrpc/client. It also looks as if dump_string has been renamed dump_unicode. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 22:40:00 2013 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 21 May 2013 20:40:00 +0000 Subject: [issue6461] multiprocessing: freezing apps on Windows In-Reply-To: <1247292508.31.0.803162103646.issue6461@psf.upfronthosting.co.za> Message-ID: <1369168800.75.0.0620925541541.issue6461@psf.upfronthosting.co.za> Mark Lawrence added the comment: Could someone answer the question posed in msg98154 please. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 22:52:15 2013 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 21 May 2013 20:52:15 +0000 Subject: [issue7760] use_errno=True does not work In-Reply-To: <1264205937.75.0.643663912285.issue7760@psf.upfronthosting.co.za> Message-ID: <1369169535.55.0.0783206992165.issue7760@psf.upfronthosting.co.za> Mark Lawrence added the comment: Would someone like to propose a documentation patch that clarifies this situation. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 22:59:41 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 21 May 2013 20:59:41 +0000 Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular encoding In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za> Message-ID: <1369169981.17.0.399010172165.issue13612@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The patch goes in the right direction: consistently reject non-8bit encodings which the current implementation does not support. - please add a unit test - remove usage of PyUnicodeObject and the "Stupid to access directly" comment, they are outdated. Real support for GBK is more work, http://wang.yuxuan.org/blog/?itemid=63 shows how to set a conversion callback. It will difficult to implement in the general case, see my older comment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 21 23:14:09 2013 From: report at bugs.python.org (Oscar Benjamin) Date: Tue, 21 May 2013 21:14:09 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: <1369153301.13.0.00251046961752.issue12641@psf.upfronthosting.co.za> Message-ID: Oscar Benjamin added the comment: On 21 May 2013 17:21, Martin v. L?wis wrote: > > C: Users who have only cygwin gcc 4.x installed > > For those, the current setup will produce an error message, essentially telling them that the need to fix something (specifically: edit distutils, install mingw). With the proposed change, --compiler=mingw32 will produce a binary, but the binary will incorrectly depend on cygwin. They may not notice on their local system (since cygwin.dll is available), but only on customer systems. Well there cannot be anyone in group C who currently has a functioning setup. But I agree that it's better to have a good error message. It may be possible to check in some way that the gcc used is from cygwin and add an error message specifically for this case. I'll have a look at this when I'm next on Windows. More generally I think that compiling non-cygwin extensions with cygwin gcc should be altogether deprecated (for Python 3.4 at least). It should be discouraged in the docs and unsupported in the future. It can only work with -mno-cygwin which in turn only works with gcc 3.x, has never documented as being a stable gcc feature, is now abandoned and is referred to disparagingly on both the mingw and cygwin mailing lists: To quote Dave Korn from cygwin http://cygwin.com/ml/cygwin/2009-03/msg00802.html ''' gcc-3 -mno-cygwin still works just as well (or badly!) as it ever has done, and will be retained for ever. gcc-4 series releases will not support it at all. As the whole thing is (still) experimental and explicitly warned to be unstable I don't see the need to go for a deprecation period. ''' Or Earnie Boyd from mingw-users http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42111 ''' On Mon, May 20, 2013 at 9:13 AM, Paul Moore wrote: > So building an extension using --compiler=mingw in Python could pick up a > cygwin gcc if that was on PATH, and this will work as long as -mno-cygwin is > passed on the command line. But it won't work (it will build a DLL with a > dependency on the cygwin DLL) if -mno-cygwin is omitted. I'd argue that > people should just install and use mingw rather than cygwin, but that may > not be what everyone does in practice. No!!! The -mno-cygwin abomination is dead. If you want to build a native Python using Cygwin you would do it the cross compiler way and state the --host you're configuring for. Python's distutil needs to remove the -mno-cygwin option. ''' However no-cygwin mode is currently a documented feature: http://docs.python.org/3.4/install/index.html#gnu-c-cygwin-mingw So it can't simply be deprecated in already released Pythons but I do want to fix the mingw bug there if possible. The suggestion to make -mno-cygwin conditional on gcc major version may lead to some users who attempt to use a setup that did not previously work not seeing the appropriate error message. However it does, I believe, come with the following two guarantees: 1) Mingw setups that are used, wanted and currently broken will be fixed. 2) No currently functional setups will be broken. That may be the best that is possible given the tight constraints on changes to distutils. > That said: which of Roumen's patches (if any) would you recommend for inclusion? None. I may have misread them but my impression is that they are not particularly intended to be used as individual patches. I can't see one that just makes the relevant changes and collectively they make up a more pervasive change than I was proposing. The patch that I was proposing for 3.4 would simply remove -mno-cygwin on these 5 lines: http://hg.python.org/cpython/file/7fce9186accb/Lib/distutils/cygwinccompiler.py#l322 For 2.7, 3.2 and 3.3 I would do the same but conditional on self.gcc_version. I think Roumen has identified many different issues but I would try and keep it focussed on the one -mno-cygwin issue. Oscar ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 00:22:33 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 21 May 2013 22:22:33 +0000 Subject: [issue6461] multiprocessing: freezing apps on Windows In-Reply-To: <1247292508.31.0.803162103646.issue6461@psf.upfronthosting.co.za> Message-ID: <1369174953.81.0.228605700947.issue6461@psf.upfronthosting.co.za> Changes by Richard Oudkerk : ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 02:21:18 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 May 2013 00:21:18 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1369182078.11.0.104730683832.issue15392@psf.upfronthosting.co.za> Terry J. Reedy added the comment: It works when one uses the right dotted name ;-) D:\Python\dev\py33\PCbuild>python_d -m unittest -v idlelib.idle_test.test_calltips.Test_get_entity.test_bad_entity test_bad_entity (idlelib.idle_test.test_calltips.Test_get_entity) ... ok ---------------------------------------------------------------------- Ran 1 test in 0.000s OK idlelib.idle_test.test_calltips.Test_get_entity works too. I did not know about these options; I added them to @README as part of revising it. I also added verbosity and exit args to all if-name unittest.main calls, which are ignored anyway when either unittest or regrtest import the modules. New patch uploaded. With this additional confirmation, I am about ready to commit -- when I feel fresh and ready to monitor the buildbots. But I notice that the non-executable @README has 7 ways to run all or part of the suite, most of which have appeared in this issue. Even with history retrieval, I am tired of retyping to test changes. I should have started with an executable test suite test (.bat or .py using subproccess for the command lines). Then I could have just added the two cases above and re-run after today's edit. I may do this first. ---------- Added file: http://bugs.python.org/file30334/idletest4u.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 04:58:13 2013 From: report at bugs.python.org (Marc) Date: Wed, 22 May 2013 02:58:13 +0000 Subject: [issue18030] IDLE shell crashes when reporting errors in Windows 7 Message-ID: <1369191492.92.0.0405253536514.issue18030@psf.upfronthosting.co.za> New submission from Marc: Using TkInter as gui, running a module that worked in 3.0 (I believe). It is trying to print a warning message about RuntimeWarning: overflow encountered in double_scalars and stops my process (running eval) returning this error File "C:\Python32\lib\idlelib\PyShell.py", line 59, in idle_showwarning file.write(warnings.formatwarning(message, category, filename, AttributeError: 'NoneType' object has no attribute 'write' If I use python -m idlelib.idle it doesn't happen; it just prints the error. Previously this worked fine using the shell as stdout. This is similar to a bug about symbols' errors however it has been closed and this one is not about symbols. http://bugs.python.org/issue14200 I don't really know a lot about programming and don't often submit bugs so sorry if I've missed any major details here. Marc ---------- components: IDLE messages: 189788 nosy: marcopolo priority: normal severity: normal status: open title: IDLE shell crashes when reporting errors in Windows 7 type: crash versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 05:32:11 2013 From: report at bugs.python.org (Ben Darnell) Date: Wed, 22 May 2013 03:32:11 +0000 Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za> Message-ID: <1369193531.91.0.863827488033.issue8240@psf.upfronthosting.co.za> Ben Darnell added the comment: I vote for enabling SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER by default. It can catch mistakes (i.e. failure to check the return value of send) in Python just as easily as in C, but I don't think those mistakes are common enough to be worth the headache of this error. The false positive rate of this error is higher in Python than in C because we don't have direct control over memory and pointers. As for partial writes, I'm not sure if it's backwards compatible to turn them on by default, but it might be nice if the option were exposed. Partial writes may have less benefit in Python than in C since we'd have to reallocate and copy a string instead of just moving a pointer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 07:23:44 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 May 2013 05:23:44 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1369200224.02.0.463224891113.issue15392@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Attached file tests framework by running idle_tests 6 different ways. Run with the executable that you want to run the tests with as is uses sys.executable. I plan to move it into idle_tests. ---------- Added file: http://bugs.python.org/file30335/frametest.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 07:58:22 2013 From: report at bugs.python.org (Carlos Nepomuceno) Date: Wed, 22 May 2013 05:58:22 +0000 Subject: [issue18031] The Python Tutorial says % string formatting will be removed Message-ID: <1369202302.43.0.537534312315.issue18031@psf.upfronthosting.co.za> New submission from Carlos Nepomuceno: It[1] says: "Since str.format() is quite new, a lot of Python code still uses the % operator. However, because this old style of formatting will eventually be removed from the language, str.format() should generally be used." [1] http://docs.python.org/2/tutorial/inputoutput.html#old-string-formatting ---------- assignee: docs at python components: Documentation messages: 189791 nosy: Carlos.Nepomuceno, docs at python priority: normal severity: normal status: open title: The Python Tutorial says % string formatting will be removed versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 08:09:53 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 22 May 2013 06:09:53 +0000 Subject: [issue18007] CookieJar expects request objects with origin_req_host attribute instead of method In-Reply-To: <1368891902.97.0.967044954731.issue18007@psf.upfronthosting.co.za> Message-ID: <1369202993.19.0.942147082331.issue18007@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Hello Simon, Thanks for bringing this to attention. Since get_origin_req_host has been under deprecation was a release, I thought it was safe to remove that. Agree that documentation of "cookiejar" methods, which had a dependency on the change should have been fixed. Here is patch attempting to do that. If this is okay, I shall go with committing this change in 3.3 and 3.4. ---------- assignee: docs at python -> orsenthil keywords: +patch stage: -> patch review versions: +Python 3.4 Added file: http://bugs.python.org/file30336/18007.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 08:32:10 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 22 May 2013 06:32:10 +0000 Subject: [issue18031] The Python Tutorial says % string formatting will be removed In-Reply-To: <1369202302.43.0.537534312315.issue18031@psf.upfronthosting.co.za> Message-ID: <1369204330.09.0.0323797847289.issue18031@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti type: -> enhancement versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 08:53:48 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 May 2013 06:53:48 +0000 Subject: [issue17839] base64 module should use memoryview In-Reply-To: <1366875154.79.0.0782227735295.issue17839@psf.upfronthosting.co.za> Message-ID: <1369205628.67.0.00277909219273.issue17839@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Ezio and Nick for your comments. > I suggest renaming _bytes_from_decode_data to "_bytes_for_decoding" and adding "_bytes_for_encoding". I rather think a TypeError exception raised by `memoryview(s).tobytes()` is good enough and we don't need a special wrapper. ---------- Added file: http://bugs.python.org/file30337/base64_buffer_input_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 09:00:54 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 May 2013 07:00:54 +0000 Subject: [issue18030] IDLE shell crashes when reporting errors in Windows 7 In-Reply-To: <1369191492.92.0.0405253536514.issue18030@psf.upfronthosting.co.za> Message-ID: <1369206054.04.0.599985543604.issue18030@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Windows nosy: +brian.curtin, kbk, roger.serwy, terry.reedy, tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 09:05:55 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 May 2013 07:05:55 +0000 Subject: [issue18030] IDLE shell crashes when reporting errors in Windows 7 In-Reply-To: <1369191492.92.0.0405253536514.issue18030@psf.upfronthosting.co.za> Message-ID: <1369206355.41.0.925237776179.issue18030@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is a duplicate of issue13582. ---------- nosy: +serhiy.storchaka resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> IDLE and pythonw.exe stderr problem _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 09:42:44 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 22 May 2013 07:42:44 +0000 Subject: [issue18031] The Python Tutorial says % string formatting will be removed In-Reply-To: <1369202302.43.0.537534312315.issue18031@psf.upfronthosting.co.za> Message-ID: <1369208564.17.0.815422936464.issue18031@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Can you please provide some context for this report? On the abstract, I agree that there is an error in the tutorial: it is not decided whether the % formatting will be eventually removed, and I would also personally disagree with the recommendation to prefer .format. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 09:59:11 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 May 2013 07:59:11 +0000 Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular encoding In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za> Message-ID: <1369209551.22.0.504450418655.issue13612@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +ElementTree incorrectly parses strings with declared encoding not UTF-8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 10:01:25 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 May 2013 08:01:25 +0000 Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular encoding In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za> Message-ID: <1369209685.02.0.0902112579225.issue13612@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For unit tests we first should fix issue16986. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 10:11:34 2013 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 22 May 2013 08:11:34 +0000 Subject: [issue17844] Add link to alternatives for bytes-to-bytes codecs In-Reply-To: <1366889842.88.0.0886939266057.issue17844@psf.upfronthosting.co.za> Message-ID: <1369210294.09.0.797021409126.issue17844@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thanks Serhiy, that version looks great. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 10:15:10 2013 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 22 May 2013 08:15:10 +0000 Subject: [issue17140] Provide a more obvious public ThreadPool API In-Reply-To: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za> Message-ID: <1369210510.63.0.708201599696.issue17140@psf.upfronthosting.co.za> Nick Coghlan added the comment: Actors are just as vulnerable to the "new threads/processes are expensive" issue as anything else, and by using a dynamic pool appropriately you can amortise those costs across multiple instances. The point is to expose a less opinionated threading model in a more readily accessible way. Executors and futures are *very* opinionated about the communication channels you're expected to use (the ones the executor provides), while pools are just a resource management tool. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 10:17:21 2013 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 22 May 2013 08:17:21 +0000 Subject: [issue17716] From ... import fails when parent package failed but child module succeeded, yet works in std import case In-Reply-To: <1365869097.02.0.582677403017.issue17716@psf.upfronthosting.co.za> Message-ID: <1369210641.44.0.642088093369.issue17716@psf.upfronthosting.co.za> Nick Coghlan added the comment: import-sig is probably a better place to start ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 11:23:10 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Wed, 22 May 2013 09:23:10 +0000 Subject: [issue17140] Provide a more obvious public ThreadPool API In-Reply-To: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za> Message-ID: <1369214590.87.0.0702345355912.issue17140@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I understand that a thread pool (in the general sense) might be used to amortise the cost. But I think you would probably have to write this from scratch rather than use the ThreadPool API. The ThreadPool API does not really expose anything that the ThreadPoolExceutor API does not -- the differences are just a matter of taste. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 11:29:48 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 22 May 2013 09:29:48 +0000 Subject: [issue7727] xmlrpc library returns string which contain null ( \x00 ) In-Reply-To: <1263758368.94.0.169057465263.issue7727@psf.upfronthosting.co.za> Message-ID: <1369214988.12.0.705658535721.issue7727@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't really understand the issue. If you want to pass binary data (rather than unicode text), you should use a Binary object as explained in the docs: http://docs.python.org/2/library/xmlrpclib.html#binary-objects ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 12:01:01 2013 From: report at bugs.python.org (Carlos Nepomuceno) Date: Wed, 22 May 2013 10:01:01 +0000 Subject: [issue18031] The Python Tutorial says % string formatting will be removed In-Reply-To: <1369202302.43.0.537534312315.issue18031@psf.upfronthosting.co.za> Message-ID: <1369216861.06.0.0543861815413.issue18031@psf.upfronthosting.co.za> Carlos Nepomuceno added the comment: According to what I have been told at python-list at python.org str.__mod__() is not going to be deprecated and that seems to be a myth created by Python's own documentation. I do remember to have read previously in another page that it would be deprecated but that seems to be already corrected. Today I just found it in the tutorial. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 13:16:56 2013 From: report at bugs.python.org (Ned Batchelder) Date: Wed, 22 May 2013 11:16:56 +0000 Subject: [issue18031] The Python Tutorial says % string formatting will be removed In-Reply-To: <1369202302.43.0.537534312315.issue18031@psf.upfronthosting.co.za> Message-ID: <1369221416.68.0.580491010264.issue18031@psf.upfronthosting.co.za> Changes by Ned Batchelder : ---------- nosy: +nedbat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 13:28:09 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 22 May 2013 11:28:09 +0000 Subject: [issue7727] xmlrpc library returns string which contain null ( \x00 ) In-Reply-To: <1263758368.94.0.169057465263.issue7727@psf.upfronthosting.co.za> Message-ID: <1369222089.63.0.164779274756.issue7727@psf.upfronthosting.co.za> Martin v. L?wis added the comment: The original report really includes two parts: a) when a string containing \0 is marshalled, ill-formed XML is produced b) the expected behavior is that base64 is used IMO: While a) is correct, b) is not. Antoine is correct that xmlrpclib.Binary should be used if you want to transmit binary data. Consequently, an Error should be reported if an attempt is made to produce ill-formed XML. OTOH, ill-formed XML can also be produced when sending a byte string that does not match the encoding declaration. Because of that, I propose to close this by documentating the limitations, rather than changing the code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 13:36:49 2013 From: report at bugs.python.org (Anselm Kruis) Date: Wed, 22 May 2013 11:36:49 +0000 Subject: [issue18015] python 2.7.5 fails to unpickle namedtuple pickled by 2.7.3 or 2.7.4 In-Reply-To: <1368988919.46.0.250713350438.issue18015@psf.upfronthosting.co.za> Message-ID: <1369222609.14.0.0438555613185.issue18015@psf.upfronthosting.co.za> Anselm Kruis added the comment: I created a small *.pth to monkey patch collections.py until 2.7.6 gets released. Maybe this is useful for someone else. Therefore I attach it here. The pth file runs the following code during Python startup: import collections def _fix_issue_18015(collections): try: template = collections._class_template except AttributeError: # prior to 2.7.4 _class_template didn't exists return if not isinstance(template, basestring): return # strange if "__dict__" in template or "__getstate__" in template: return # already patched lines = template.splitlines() indent = -1 for i,l in enumerate(lines): if indent < 0: indent = l.find('def _asdict') continue if l.startswith(' '*indent + 'def '): lines.insert(i, ' '*indent + 'def __getstate__(self): pass') lines.insert(i, ' '*indent + '__dict__ = _property(_asdict)') break collections._class_template = '''\n'''.join(lines) _fix_issue_18015(collections) ---------- Added file: http://bugs.python.org/file30338/fix_python_275_issue18015.pth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 13:43:37 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 22 May 2013 11:43:37 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: Message-ID: <519CAF67.2090506@v.loewis.de> Martin v. L?wis added the comment: Am 21.05.13 23:14, schrieb Oscar Benjamin: > More generally I think that compiling non-cygwin extensions with > cygwin gcc should be altogether deprecated (for Python 3.4 at least). > It should be discouraged in the docs and unsupported in the future. I agree with that, although I find it sad that the Cygwin project apparently abandoned support for building Mingw binaries. > It can only work with -mno-cygwin This is factually incorrect. It also works with the i686-pc-mingw32-gcc executable, which (IIUC) is still available for Cygwin. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 13:58:43 2013 From: report at bugs.python.org (Abafei) Date: Wed, 22 May 2013 11:58:43 +0000 Subject: [issue18032] set methods should specify whether they consume iterators "lazily" Message-ID: <1369223923.83.0.620034016791.issue18032@psf.upfronthosting.co.za> New submission from Abafei: It says here (http://docs.python.org/2/library/stdtypes.html#set-types-set-frozenset) that some of the set methods take iterables as a parameter. Usually, the expected behavior is for a iterator consumer to consume only as much data as it needs. For example, for the code `any(itertools.repeat(True))`, the code will complete speedily, in contrast to when all() is used instead of any(), in which case the code will go forever. A least some of the set methods have semantics such that they can consume only some of the input; for example, "issubset" only needs to make sure that all of the items in the set are in the iterable, and once this is the case, it can return "True". However in such a case, the methods will *still* go forever. The docs should specify that this is the case, to disambiguate the semantics. (Tested on Python 3.2.3 and 2.7.3). ---------- assignee: docs at python components: Documentation messages: 189806 nosy: Abafei, docs at python priority: normal severity: normal status: open title: set methods should specify whether they consume iterators "lazily" type: behavior versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 14:03:31 2013 From: report at bugs.python.org (Matt Jones) Date: Wed, 22 May 2013 12:03:31 +0000 Subject: [issue7760] use_errno=True does not work In-Reply-To: <1264205937.75.0.643663912285.issue7760@psf.upfronthosting.co.za> Message-ID: <1369224211.92.0.739092281779.issue7760@psf.upfronthosting.co.za> Matt Jones added the comment: Is this really a documentation issue? Is it not generally understood that using absolute paths to libraries is a bad idea due to the amount of PATH/symlink spaghetti that the average file system contains? ---------- nosy: +Matt.Jones _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 14:11:04 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 May 2013 12:11:04 +0000 Subject: [issue7727] xmlrpc library returns string which contain null ( \x00 ) In-Reply-To: <1263758368.94.0.169057465263.issue7727@psf.upfronthosting.co.za> Message-ID: <1369224664.36.0.443117789963.issue7727@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The limitations is already documented: """However, it?s the caller?s responsibility to ensure that the string is free of characters that aren?t allowed in XML, such as the control characters with ASCII values between 0 and 31 (except, of course, tab, newline and carriage return); failing to do this will result in an XML-RPC request that isn?t well-formed XML. If you have to pass arbitrary bytes via XML-RPC, use the bytes class or the class:Binary wrapper class described below.""" Here is a patch which forbids creating ill-formed XML. ---------- nosy: +serhiy.storchaka stage: test needed -> patch review versions: +Python 2.7, Python 3.3, Python 3.4 -Python 2.6 Added file: http://bugs.python.org/file30339/xmlrpc_dump_invalid_string.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 14:27:27 2013 From: report at bugs.python.org (Eli Bendersky) Date: Wed, 22 May 2013 12:27:27 +0000 Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular encoding In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za> Message-ID: <1369225647.56.0.264746896201.issue13612@psf.upfronthosting.co.za> Eli Bendersky added the comment: > For unit tests we first should fix issue16986. I did another round of code review on issue 16986 now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 14:29:22 2013 From: report at bugs.python.org (Eli Bendersky) Date: Wed, 22 May 2013 12:29:22 +0000 Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular encoding In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za> Message-ID: <1369225762.51.0.980602588232.issue13612@psf.upfronthosting.co.za> Eli Bendersky added the comment: Looked at Serhiy's patch here too: LGTM with a unit test :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 14:36:17 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 May 2013 12:36:17 +0000 Subject: [issue17844] Add link to alternatives for bytes-to-bytes codecs In-Reply-To: <1366889842.88.0.0886939266057.issue17844@psf.upfronthosting.co.za> Message-ID: <3bFtcc2RZ3z7Ljr@mail.python.org> Roundup Robot added the comment: New changeset 85c04fdaa404 by Serhiy Storchaka in branch '2.7': Issue #17844: Refactor a documentation of Python specific encodings. http://hg.python.org/cpython/rev/85c04fdaa404 New changeset 039dc6dd2bc0 by Serhiy Storchaka in branch '3.3': Issue #17844: Add links to encoders and decoders for bytes-to-bytes codecs. http://hg.python.org/cpython/rev/039dc6dd2bc0 New changeset 9afdd88fe33a by Serhiy Storchaka in branch 'default': Issue #17844: Add links to encoders and decoders for bytes-to-bytes codecs. http://hg.python.org/cpython/rev/9afdd88fe33a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 14:40:01 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 May 2013 12:40:01 +0000 Subject: [issue17844] Add link to alternatives for bytes-to-bytes codecs In-Reply-To: <1366889842.88.0.0886939266057.issue17844@psf.upfronthosting.co.za> Message-ID: <1369226401.55.0.470968332929.issue17844@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Nick. It's mainly your patch. Do you want to foreport your changes (a "Python Specific Encodings" subheading and followed paragraph) to 3.x? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 14:40:58 2013 From: report at bugs.python.org (Oscar Benjamin) Date: Wed, 22 May 2013 12:40:58 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: <519CAF67.2090506@v.loewis.de> Message-ID: Oscar Benjamin added the comment: On 22 May 2013 12:43, Martin v. L?wis wrote: > Am 21.05.13 23:14, schrieb Oscar Benjamin: >> More generally I think that compiling non-cygwin extensions with >> cygwin gcc should be altogether deprecated (for Python 3.4 at least). >> It should be discouraged in the docs and unsupported in the future. > > I agree with that, Excellent. > although I find it sad that the Cygwin project > apparently abandoned support for building Mingw binaries. I don't understand their reasoning but given the scorn poured on to -mno-cygwin from at least some people I trust that they had some good reason :) Also they have replaced it with something that they consider more appropriate (the cross-compilers). >> It can only work with -mno-cygwin > > This is factually incorrect. It also works with the i686-pc-mingw32-gcc > executable, which (IIUC) is still available for Cygwin. I should have been slightly clearer. It can only currently work in distutils with -mno-cygwin. The executable you refer to is part of cygwin gcc's cross-compiler toolchain. This is their recommended replacement for -mno-cygwin (if not mingw) but is AFAICT unsupported by distutils. I think there's a case for saying that distutils should support these but it should only be done with a new UnixCCompiler subclass and a new --compiler entry point. It should also perhaps provide a way to specify the --host since I think that facility is part of the purpose of the new toolchain. In any case cygwin cross-compiler support should not be conflated in the codebase with distutils' mingw support and if it is to be added that should be discussed in a separate issue. I personally don't think I would use it and would not push for the support to be added. Going back to the group C users: I think that it should be possible to create an is_cygwingcc() function that would parse the output of 'gcc --version'. Then Mingw32CCompiler.__init__ could do: if is_cygwingcc() and self.gcc_version >= '4': raise RuntimeError('No cygwin mode only works with gcc-3. Use gcc-3 or mingw') The is_cygwingcc() function can be conservative since false positives or more of a problem than false negatives. I think this should address your concern. However on further reflection I'm a little reluctant to force an error if I can't *prove* that the setup is broken. I'm no stranger to monkey-patching distutils and it's possible that someone has already monkey-patched it to make some bizarre setup just about work. I would be a little peeved if my setup broke in a bugfix release simply because someone else who didn't understand it decided that it wasn't viable. (The same monkey-patching concerns apply to the other changes but I think that fixing the non-monkey-patched setup for mingw trumps in that case.) So perhaps the best place to deal with the gcc-4/no-cygwin issue is in the distutils docs. My updated proposal is (I'll write patches if this is acceptable): Python 3.4: Remove '-mno-cygwin'. This breaks the no-cygwin mode and fixes the mingw mode. The distutils docs are updated with something like: ''' Note: Previous Python versions supported another 'no-cygwin' mode that could use cygwin gcc to build extensions without a dependency on cygwin.dll. This is no longer supported. New in Python 3.4: No-cygwin mode is no longer supported. ''' Python 2.7, 3.2 and 3.3: Only use '-mno-cygwin' if self.gcc_version < '4'. This should not break any currently functioning setups (barring serious monkey-patching). The distutils docs are updated with something like: ''' Note: The no-cygwin mode only works with cygwin's gcc-3. For gcc-4 it may produce .pyd files with dependencies on cygwin.dll that are not fully redistributable. The use of no-cygwin mode is deprecated by cygwin and support for it is removed in Python 3.4. ''' If you would rather have the is_cygwingcc() check I'm happy to put that in also if it gets this issue moving but I'm personally cautious about it. Thanks, Oscar ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 15:23:08 2013 From: report at bugs.python.org (Oscar Benjamin) Date: Wed, 22 May 2013 13:23:08 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: Message-ID: Oscar Benjamin added the comment: On 22 May 2013 13:40, Oscar Benjamin wrote: > > However on further reflection I'm a little reluctant to force an error > if I can't *prove* that the setup is broken. After a little more reflection I realise that we could just do: if self.gcc_version < '4' or is_cygwingcc(): # use -mno-cygwin This way the cygwin/gcc-4 error is still emitted only if gcc emits it. If the is_cygwingcc() function is conservative then there could be cases where it mistakenly does not use -mno-cygwin but that would have to be a broken cygwin/gcc-4 setup anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 15:32:21 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 22 May 2013 13:32:21 +0000 Subject: [issue17272] request.full_url: unexpected results on assignment In-Reply-To: <1361512602.9.0.97298415685.issue17272@psf.upfronthosting.co.za> Message-ID: <1369229541.09.0.126426225793.issue17272@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Here is patch with tests and docs. I see no changes to opener is required and the selector which is sent to HTTP request is the correct one. I have added tests for redirect url with #fragment too (For testing scenario reported in Issue 8280). I shall close this issue once I commit this patch. In a separate report/ commit, get_full_url should be deprecated. Also, I like to see splittag being replaced with urlparse itself, so that our test and expectation with fragment will be consistent. ---------- Added file: http://bugs.python.org/file30340/17272-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 15:42:12 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 May 2013 13:42:12 +0000 Subject: [issue16986] ElementTree incorrectly parses strings with declared encoding not UTF-8 In-Reply-To: <1358441659.05.0.359191214505.issue16986@psf.upfronthosting.co.za> Message-ID: <1369230132.49.0.17288292246.issue16986@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is an updated patch. ---------- Added file: http://bugs.python.org/file30341/etree_parse_str_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 15:48:07 2013 From: report at bugs.python.org (Eli Bendersky) Date: Wed, 22 May 2013 13:48:07 +0000 Subject: [issue16986] ElementTree incorrectly parses strings with declared encoding not UTF-8 In-Reply-To: <1358441659.05.0.359191214505.issue16986@psf.upfronthosting.co.za> Message-ID: <1369230487.98.0.909553011813.issue16986@psf.upfronthosting.co.za> Eli Bendersky added the comment: LGTM ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 15:52:31 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 May 2013 13:52:31 +0000 Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular encoding In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za> Message-ID: <1369230751.07.0.239213177413.issue13612@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is an updated patch. PyUnknownEncodingHandler() and expat_unknown_encoding_handler() are synchronized. Added tests. ---------- Added file: http://bugs.python.org/file30342/expat_unknown_encoding_handler_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 15:57:33 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 May 2013 13:57:33 +0000 Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular encoding In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za> Message-ID: <1369231053.94.0.537038455912.issue13612@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: -ElementTree incorrectly parses strings with declared encoding not UTF-8 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 16:21:35 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 May 2013 14:21:35 +0000 Subject: [issue16986] ElementTree incorrectly parses strings with declared encoding not UTF-8 In-Reply-To: <1358441659.05.0.359191214505.issue16986@psf.upfronthosting.co.za> Message-ID: <3bFwy664Q1z7LkS@mail.python.org> Roundup Robot added the comment: New changeset 7781ccae7b9a by Serhiy Storchaka in branch '3.3': Issue #16986: ElementTree now correctly parses a string input not only when http://hg.python.org/cpython/rev/7781ccae7b9a New changeset 659c1ce8ed2f by Serhiy Storchaka in branch 'default': Issue #16986: ElementTree now correctly parses a string input not only when http://hg.python.org/cpython/rev/659c1ce8ed2f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 16:44:30 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 May 2013 14:44:30 +0000 Subject: [issue16986] ElementTree incorrectly parses strings with declared encoding not UTF-8 In-Reply-To: <1358441659.05.0.359191214505.issue16986@psf.upfronthosting.co.za> Message-ID: <1369233870.94.0.186003578312.issue16986@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, 2.7 still uses old doctests. It's a challenge to backport tests for this issue. ---------- versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 16:50:57 2013 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 22 May 2013 14:50:57 +0000 Subject: [issue17844] Add link to alternatives for bytes-to-bytes codecs In-Reply-To: <1366889842.88.0.0886939266057.issue17844@psf.upfronthosting.co.za> Message-ID: <1369234257.91.0.14776864806.issue17844@psf.upfronthosting.co.za> Nick Coghlan added the comment: That sounds like a good idea. Yay for not needing those arcane footnotes, though :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 17:01:26 2013 From: report at bugs.python.org (Ezio Melotti) Date: Wed, 22 May 2013 15:01:26 +0000 Subject: [issue17844] Add link to alternatives for bytes-to-bytes codecs In-Reply-To: <1366889842.88.0.0886939266057.issue17844@psf.upfronthosting.co.za> Message-ID: <1369234886.28.0.696677742998.issue17844@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 17:02:59 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 22 May 2013 15:02:59 +0000 Subject: [issue7727] xmlrpc library returns string which contain null ( \x00 ) In-Reply-To: <1263758368.94.0.169057465263.issue7727@psf.upfronthosting.co.za> Message-ID: <1369234979.38.0.959255092757.issue7727@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Serhiy: The patch fixes the OP's concern, but not the extended concern about producing ill-formed XML (at least not for 2.7). If the string contains non-UTF-8 data, yet the XML declaration says UTF-8, it's still ill-formed, and not caught by your patch. I wonder whether xmlrpclib.Error would be a better exception than ValueError (although ValueError is also plausible); either way, the case should be documented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 17:12:38 2013 From: report at bugs.python.org (Jough Dempsey) Date: Wed, 22 May 2013 15:12:38 +0000 Subject: [issue18033] Example for Profile Module shows incorrect method Message-ID: <1369235558.14.0.532987051887.issue18033@psf.upfronthosting.co.za> New submission from Jough Dempsey: The example on this page: http://docs.python.org/2/library/profile.html?highlight=pstats#profile.Profile Shows: import cProfile, pstats, io pr = cProfile.Profile() pr.enable() ... do something ... pr.disable() s = io.StringIO() ps = pstats.Stats(pr, stream=s) ps.print_results() Where "ps.print_results()" should be "ps.print_stats()" ---------- assignee: docs at python components: Documentation messages: 189823 nosy: docs at python, jough priority: normal severity: normal status: open title: Example for Profile Module shows incorrect method type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 19:03:57 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 22 May 2013 17:03:57 +0000 Subject: [issue13483] Use VirtualAlloc to allocate memory arenas In-Reply-To: <1369153468.24.0.776915762136.issue13483@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: I can't speak for Antoine, but I guess that the result of pybench would be enough to make sure it doesn't introduce any regression (which would be *really* suprising). As for the memory savings, the benchmark you posted earlier is conclusive enough IMO (especially since the it can be difficult to come up with a scheme leading to heap fragmentation). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 19:24:57 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 22 May 2013 17:24:57 +0000 Subject: [issue13483] Use VirtualAlloc to allocate memory arenas In-Reply-To: <1322313162.87.0.914810161445.issue13483@psf.upfronthosting.co.za> Message-ID: <1369243497.87.0.0717446390235.issue13483@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I asked for benchmarks because I don't know anything about Windows virtual memory management, but if other people think this patch should go in then it's fine. The main point of using VirtualAlloc/VirtualFree was, in my mind, to allow *releasing* memory in more cases than when relying on free() (assuming Windows uses some sbrk() equivalent). But perhaps Windows is already tuned to release memory on most free() calls. ---------- stage: -> commit review versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 19:26:55 2013 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 22 May 2013 17:26:55 +0000 Subject: [issue18031] The Python Tutorial says % string formatting will be removed In-Reply-To: <1369202302.43.0.537534312315.issue18031@psf.upfronthosting.co.za> Message-ID: <1369243615.62.0.0078260829326.issue18031@psf.upfronthosting.co.za> Eric V. Smith added the comment: I agree that we should not say that %-formatting will be removed from the language. Not until Python 5000, anyway. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 19:35:15 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 May 2013 17:35:15 +0000 Subject: [issue18034] Last two entries in the programming FAQ are out of date (import related) Message-ID: <1369244115.61.0.298181094271.issue18034@psf.upfronthosting.co.za> New submission from R. David Murray: The second to last talks about the __import__ quirk with out calling __import__ out as deprecated. The last uses the imp module for reload. ---------- assignee: docs at python components: Documentation messages: 189827 nosy: brett.cannon, docs at python, eric.snow, r.david.murray priority: normal severity: normal stage: needs patch status: open title: Last two entries in the programming FAQ are out of date (import related) type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 19:36:57 2013 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 22 May 2013 17:36:57 +0000 Subject: [issue18035] telnetlib incorrectly assumes that select.error has an errno attribute Message-ID: <1369244217.55.0.122247989262.issue18035@psf.upfronthosting.co.za> New submission from Gregory P. Smith: In Python 2.7.3 through 2.7.5 the telnetlib select.poll based implementation assumes that select.error has an errno attribute when handling errors. it does not. select.error is not an EnvironmentError derived exception. http://hg.python.org/cpython/file/85c04fdaa404/Lib/telnetlib.py#l317 i haven't check 3.x yet. ---------- messages: 189828 nosy: gregory.p.smith priority: normal severity: normal status: open title: telnetlib incorrectly assumes that select.error has an errno attribute versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 19:37:51 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 May 2013 17:37:51 +0000 Subject: [issue18036] "How do I create a .pyc file?" FAQ entry is out of date Message-ID: <1369244271.04.0.495588356743.issue18036@psf.upfronthosting.co.za> New submission from R. David Murray: It doesn't talk about __pycache__. ---------- messages: 189829 nosy: barry, r.david.murray priority: normal severity: normal stage: needs patch status: open title: "How do I create a .pyc file?" FAQ entry is out of date type: behavior versions: Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 19:40:49 2013 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 22 May 2013 17:40:49 +0000 Subject: [issue18035] telnetlib incorrectly assumes that select.error has an errno attribute In-Reply-To: <1369244217.55.0.122247989262.issue18035@psf.upfronthosting.co.za> Message-ID: <1369244449.82.0.457481418211.issue18035@psf.upfronthosting.co.za> Gregory P. Smith added the comment: As this is only on the select.poll code path, a workaround for code that isn't going to hit select.select file descriptor limits is to set their telnetlib.Telnet instance _has_poll attribute to False before using it. my_telnet = telnetlib.Telnet(...) my_telnet._has_poll = False ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 20:07:29 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 May 2013 18:07:29 +0000 Subject: [issue7727] xmlrpc library returns string which contain null ( \x00 ) In-Reply-To: <1263758368.94.0.169057465263.issue7727@psf.upfronthosting.co.za> Message-ID: <1369246049.79.0.997265579956.issue7727@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Indeed, 2.7 needs more work. Here is a patch for 2.7. UnicodeError (which subclasses ValueError) can be raised implicitly here, that is why I think ValueError is a good exception. I'll be very grateful to you for your help with a documentation. ---------- Added file: http://bugs.python.org/file30343/xmlrpc_dump_invalid_string-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 20:17:25 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 May 2013 18:17:25 +0000 Subject: [issue17089] Expat parser parses strings only when XML encoding is UTF-8 In-Reply-To: <1359626479.25.0.87229024986.issue17089@psf.upfronthosting.co.za> Message-ID: <1369246645.4.0.411738740555.issue17089@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 20:17:43 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 May 2013 18:17:43 +0000 Subject: [issue16986] ElementTree incorrectly parses strings with declared encoding not UTF-8 In-Reply-To: <1358441659.05.0.359191214505.issue16986@psf.upfronthosting.co.za> Message-ID: <1369246663.31.0.286566742555.issue16986@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Due to the fact that ElementTree's documentation doesn't promise parsing Unicode string perhaps it shouldn't be backported to 2.7. At least I hadn't backported corresponded pyexpat changes (which affects pure Python ElementTree) to 2.7. ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 20:29:51 2013 From: report at bugs.python.org (Eli Bendersky) Date: Wed, 22 May 2013 18:29:51 +0000 Subject: [issue16986] ElementTree incorrectly parses strings with declared encoding not UTF-8 In-Reply-To: <1358441659.05.0.359191214505.issue16986@psf.upfronthosting.co.za> Message-ID: <1369247391.74.0.35583371389.issue16986@psf.upfronthosting.co.za> Eli Bendersky added the comment: Agreed re 2.7; the problem is not important enough to warrant such a backport, due to the state of maintenance of 2.7 at this point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 21:27:47 2013 From: report at bugs.python.org (Claudiu.Popa) Date: Wed, 22 May 2013 19:27:47 +0000 Subject: [issue17818] aifc.Aifc_read/Aifc_write.getparams can return a namedtuple In-Reply-To: <1366659454.45.0.422161537493.issue17818@psf.upfronthosting.co.za> Message-ID: <1369250867.8.0.457385338091.issue17818@psf.upfronthosting.co.za> Claudiu.Popa added the comment: Can anyone review the latest patch, please? Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 21:51:24 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 May 2013 19:51:24 +0000 Subject: [issue17818] aifc.Aifc_read/Aifc_write.getparams can return a namedtuple In-Reply-To: <1366659454.45.0.422161537493.issue17818@psf.upfronthosting.co.za> Message-ID: <1369252284.75.0.784572004589.issue17818@psf.upfronthosting.co.za> R. David Murray added the comment: I've got it on my list, but I'm very busy for the next couple weeks. If someone else gets to it first that's good too :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 22:29:47 2013 From: report at bugs.python.org (Ned Deily) Date: Wed, 22 May 2013 20:29:47 +0000 Subject: [issue17649] Python/Python-ast.c: No such file or directory In-Reply-To: <1365299208.3.0.0356664357916.issue17649@psf.upfronthosting.co.za> Message-ID: <1369254587.88.0.000121727679243.issue17649@psf.upfronthosting.co.za> Ned Deily added the comment: I believe there are two different issues here. One: since the python-dev switch to hg, Python source release tarballs no longer have had consistent file time stamps which result in unnecessary generation steps being run in a build. Python 2.7 and 3.3 now include the "make touch" target to manually fix the timestamps for generated files and, in Issue18008, changes were made to the release process scripts so that future source tarballs will be produced with consistent timestamps and these spurious generation steps should no longer run. The second issue is making sure that, if you are building from a repo or possibly with separate, out-of-tree build directory, generated files are built correctly and are used as expected in the build. There are a number of subtle points involved in getting this right for all cases; Issue15819 has been tracking these points. I'm going to close this issue as a duplicate of it and suggest any further discussion take place there. ---------- resolution: out of date -> duplicate status: open -> closed superseder: -> Unable to build Python out-of-tree when source tree is readonly. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 22 23:46:44 2013 From: report at bugs.python.org (Vinay Sajip) Date: Wed, 22 May 2013 21:46:44 +0000 Subject: [issue18037] 2to3 passes through string literal which causes SyntaxError in 3.x Message-ID: <1369259204.14.0.48841389768.issue18037@psf.upfronthosting.co.za> New submission from Vinay Sajip: """ This string contains DOMAIN\username, which is talking about Windows and is a valid string in Python 2.x but not in 3.x. However, 2to3 passes this string through unchanged, and it causes a SyntaxError when interpreted by Python 3.x, because it contains what looks like a truncated Unicode escape. """ ---------- components: 2to3 (2.x to 3.x conversion tool) messages: 189837 nosy: benjamin.peterson, vinay.sajip priority: normal severity: normal status: open title: 2to3 passes through string literal which causes SyntaxError in 3.x type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 00:25:17 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 May 2013 22:25:17 +0000 Subject: [issue17532] IDLE: Always include "Options" menu on MacOSX In-Reply-To: <1364074890.28.0.799485456817.issue17532@psf.upfronthosting.co.za> Message-ID: <3bG7hF0vgHz7Ll1@mail.python.org> Roundup Robot added the comment: New changeset e134714e3b30 by Ned Deily in branch '2.7': Issue #17532: Always include Options menu for IDLE on OS X. http://hg.python.org/cpython/rev/e134714e3b30 New changeset 75c3e9a659bc by Ned Deily in branch '3.3': Issue #17532: Always include Options menu for IDLE on OS X. http://hg.python.org/cpython/rev/75c3e9a659bc New changeset d0a093f40801 by Ned Deily in branch 'default': Issue #17532: merge http://hg.python.org/cpython/rev/d0a093f40801 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 00:28:16 2013 From: report at bugs.python.org (Ned Deily) Date: Wed, 22 May 2013 22:28:16 +0000 Subject: [issue17532] IDLE: Always include "Options" menu on MacOSX In-Reply-To: <1364074890.28.0.799485456817.issue17532@psf.upfronthosting.co.za> Message-ID: <1369261696.14.0.780257834055.issue17532@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks again for the patch. Committed for release in 2.7.6, 3.3.3, and 3.4.0. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 00:43:16 2013 From: report at bugs.python.org (Max Cantor) Date: Wed, 22 May 2013 22:43:16 +0000 Subject: [issue18038] Unhelpful error message on invalid encoding specification Message-ID: <1369262596.73.0.912726466313.issue18038@psf.upfronthosting.co.za> New submission from Max Cantor: When you specify a nonexistent encoding at the top of a file, like so for example: # -*- coding: fakefakefoobar -*- The following exception occurs: SyntaxError: encoding problem: with BOM This is very unhelpful, especially in cases where you might have made a typo in the encoding. ---------- components: Library (Lib) messages: 189840 nosy: Max.Cantor priority: normal severity: normal status: open title: Unhelpful error message on invalid encoding specification type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 02:39:58 2013 From: report at bugs.python.org (Sashko Kopyl) Date: Thu, 23 May 2013 00:39:58 +0000 Subject: [issue18039] dbm.open(..., flag="n") does not work and does not give a warning Message-ID: <1369269598.14.0.669972141851.issue18039@psf.upfronthosting.co.za> New submission from Sashko Kopyl: I use Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit (Intel)] on win32. dbm.open(..., flag="n") is supposed to "Always create a new, empty database, open for reading and writing". In Windows case it does not. So I cannot empty a dbm database when I need it. http://docs.python.org/3/library/dbm.html#module-dbm.dumb Here it is written: "The optional flag argument is currently ignored; the database is always opened for update, and will be created if it does not exist." If it is ignored, there should be at least a warning. How am I supposed to now that this is a known bug? ---------- components: Library (Lib) messages: 189841 nosy: sonyachiko priority: normal severity: normal status: open title: dbm.open(..., flag="n") does not work and does not give a warning type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 04:56:41 2013 From: report at bugs.python.org (James Saryerwinnie) Date: Thu, 23 May 2013 02:56:41 +0000 Subject: [issue6700] inspect.getsource() returns incorrect source lines In-Reply-To: <1250223562.74.0.274098839265.issue6700@psf.upfronthosting.co.za> Message-ID: <1369277801.02.0.619167439188.issue6700@psf.upfronthosting.co.za> James Saryerwinnie added the comment: I confirmed the issue in tip. One of the issues with the original patch is that it modifies the tokeneater method used by getblock which won't work if the first token is any of the special cased tokens in the original patch ('@', 'def', 'class'). I've added additional tests that show where the original patch fails. An alternative approach is to check in getsourcelines whether or not we're dealing with a traceback or frame object in the module scope, and if so, return the lines of the entire module. I've attached an updated patch that implements this along with additional tests. ---------- nosy: +James.Saryerwinnie Added file: http://bugs.python.org/file30344/issue6700.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 05:01:07 2013 From: report at bugs.python.org (David Gilman) Date: Thu, 23 May 2013 03:01:07 +0000 Subject: [issue18040] SIGINT catching regression on windows in 2.7 Message-ID: <1369278066.93.0.310534523814.issue18040@psf.upfronthosting.co.za> New submission from David Gilman: I opened this StackOverflow bug with an example simplified testcase. As you can see in the first comment a user added that this code worked under Python 2.6 on Windows and no longer works on 2.7. http://stackoverflow.com/questions/16686510/how-do-i-capture-sigint-in-python-on-windows?noredirect=1#comment24013681_16686510 Here's a patch that went into the 2.7 release that maybe is related? http://bugs.python.org/issue1677 ---------- messages: 189843 nosy: David.Gilman priority: normal severity: normal status: open title: SIGINT catching regression on windows in 2.7 versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 05:37:31 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Thu, 23 May 2013 03:37:31 +0000 Subject: [issue18041] mention issues with code churn in the devguide Message-ID: <1369280251.47.0.219323501066.issue18041@psf.upfronthosting.co.za> New submission from Tshepang Lekhonkhobe: I've seen complaints about code churn a few times, example: http://bugs.python.org/issue16510#msg175956. Would be nice if this was documented in the devguide. ---------- components: Devguide messages: 189844 nosy: ezio.melotti, tshepang priority: normal severity: normal status: open title: mention issues with code churn in the devguide _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 06:02:53 2013 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 23 May 2013 04:02:53 +0000 Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular encoding In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za> Message-ID: <1369281773.98.0.865473865272.issue13612@psf.upfronthosting.co.za> Eli Bendersky added the comment: Serhiy, would it make sense to share the code somewhere instead of duplicating it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 06:31:27 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 May 2013 04:31:27 +0000 Subject: [issue18038] Unhelpful error message on invalid encoding specification In-Reply-To: <1369262596.73.0.912726466313.issue18038@psf.upfronthosting.co.za> Message-ID: <1369283487.57.0.30607127083.issue18038@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch. ---------- components: +Interpreter Core, Unicode -Library (Lib) keywords: +patch nosy: +ezio.melotti, serhiy.storchaka stage: -> patch review versions: +Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30345/tokenizer_encoding_problem_msg.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 06:48:59 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 May 2013 04:48:59 +0000 Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular encoding In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za> Message-ID: <1369284539.44.0.982167018043.issue13612@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be. But it needs more work for building. It is simpler just duplicate a code (the function is small enough) and add comments: /* The code is duplicated as xx() in xxx.c. Keep both functions synchronized. */ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 07:00:25 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 May 2013 05:00:25 +0000 Subject: [issue18037] 2to3 passes through string literal which causes SyntaxError in 3.x In-Reply-To: <1369259204.14.0.48841389768.issue18037@psf.upfronthosting.co.za> Message-ID: <1369285225.76.0.983706842073.issue18037@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: However r'DOMAIN\username' is valid in 3.x (if this is not a regular expression in 3.3+). It would be good to emit a warning in Python 2 with -3 option. Or perhaps even emit a warning about any non-known escape in non-raw strings. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 07:18:09 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 23 May 2013 05:18:09 +0000 Subject: [issue18037] 2to3 passes through string literal which causes SyntaxError in 3.x In-Reply-To: <1369259204.14.0.48841389768.issue18037@psf.upfronthosting.co.za> Message-ID: <1369286289.2.0.617691141285.issue18037@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 07:50:23 2013 From: report at bugs.python.org (Thayu R) Date: Thu, 23 May 2013 05:50:23 +0000 Subject: [issue18035] telnetlib incorrectly assumes that select.error has an errno attribute In-Reply-To: <1369244217.55.0.122247989262.issue18035@psf.upfronthosting.co.za> Message-ID: <1369288223.56.0.538194969888.issue18035@psf.upfronthosting.co.za> Thayu R added the comment: Just to add: select.error was made an alias of OSError following PEP 3151 from 3.3 onwards. Up to 3.2, it was a pair containing the error code and the error string. http://docs.python.org/3.3/library/select.html?highlight=select.error#select.error ---------- nosy: +Thayu.R _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 08:34:07 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 23 May 2013 06:34:07 +0000 Subject: [issue13483] Use VirtualAlloc to allocate memory arenas In-Reply-To: <1322313162.87.0.914810161445.issue13483@psf.upfronthosting.co.za> Message-ID: <1369290847.63.0.126906566687.issue13483@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Ah ok. I guess tuples.py then indeed demonstrates a saving. I'll apply the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 09:02:48 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 23 May 2013 07:02:48 +0000 Subject: [issue7727] xmlrpc library returns string which contain null ( \x00 ) In-Reply-To: <1263758368.94.0.169057465263.issue7727@psf.upfronthosting.co.za> Message-ID: <1369292568.2.0.936777887436.issue7727@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I'm still skeptical that a new exception should be introduced in 2.7.x, or 3.3 (might this break existing setups?). I suggest to ask the release manager for a decision. But if this is done, then I propose to add the following text to ServerProxy: versionchanged (2.7.6): Sending strings with characters that are ill-formed in XML (e.g. \x00) now raises ValueError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 09:12:45 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 May 2013 07:12:45 +0000 Subject: [issue18031] The Python Tutorial says % string formatting will be removed In-Reply-To: <1369202302.43.0.537534312315.issue18031@psf.upfronthosting.co.za> Message-ID: <3bGMNr2Q62zSQ6@mail.python.org> Roundup Robot added the comment: New changeset ef037ad304c1 by Raymond Hettinger in branch '2.7': Issue #18031: %-formatting isn't dead yet and might pull through. http://hg.python.org/cpython/rev/ef037ad304c1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 09:15:48 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 May 2013 07:15:48 +0000 Subject: [issue18031] The Python Tutorial says % string formatting will be removed In-Reply-To: <1369202302.43.0.537534312315.issue18031@psf.upfronthosting.co.za> Message-ID: <3bGMSM2Rlxz7Ljg@mail.python.org> Roundup Robot added the comment: New changeset e1d6140b02f0 by Raymond Hettinger in branch '3.3': Issue #18031: %-formatting isn't dead yet and might pull through. http://hg.python.org/cpython/rev/e1d6140b02f0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 09:16:04 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 23 May 2013 07:16:04 +0000 Subject: [issue18031] The Python Tutorial says % string formatting will be removed In-Reply-To: <1369202302.43.0.537534312315.issue18031@psf.upfronthosting.co.za> Message-ID: <1369293364.4.0.0784776201091.issue18031@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 10:56:18 2013 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 23 May 2013 08:56:18 +0000 Subject: [issue18042] Provide enum.unique class decorator Message-ID: <1369299378.37.0.789518154232.issue18042@psf.upfronthosting.co.za> New submission from Nick Coghlan: Another attempt at tackling the "but I want to ensure my enum values are unique" problem that PEP 435 deliberately chose not to handle. My previous suggestion (in issue 17959) was rightly rejected due to the other problems it caused, but this idea is much cleaner and simpler. All we would need to do is provide the following class decorator in the enum module: def unique(new_enum): for name, member in new_enum.__members__.items(): if name != member.name: msg = "Alias {!r} for {!r} not permitted in unique Enum" raise TypeError(msg.format(name, member)) return new_enum Used as so: >>> @enum.unique ... class MyEnum(enum.Enum): ... a = 1 ... b = 2 ... c = 1 ... Traceback (most recent call last): File "", line 2, in File "", line 6, in unique TypeError: Alias 'c' for not permitted in unique Enum ---------- components: Library (Lib) messages: 189854 nosy: ncoghlan priority: normal severity: normal status: open title: Provide enum.unique class decorator type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 10:56:55 2013 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 23 May 2013 08:56:55 +0000 Subject: [issue18042] Provide enum.unique class decorator In-Reply-To: <1369299378.37.0.789518154232.issue18042@psf.upfronthosting.co.za> Message-ID: <1369299415.75.0.869445959076.issue18042@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- dependencies: +Code, test, and doc review for PEP-0435 Enum nosy: +eli.bendersky, ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 11:28:33 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 23 May 2013 09:28:33 +0000 Subject: [issue17986] Alternative async subprocesses (pep 3145) In-Reply-To: <1368657545.17.0.168122835218.issue17986@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: I'm not familiar with windows, but if I understand the patch correctly, you can only select from a single subprocess at a time, which is IMO an important limitation. Also, the fact that close() can fail with BlockingIOError is really a pain, and makes writing portable code complicated, but I know you can't do anything about it ;-) In short, that would be nice, but Windows seems to make it so limited/complicated that I'm not sure that would be really useful, but once again I don't use Windows, so I can't make a call. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 12:25:22 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 May 2013 10:25:22 +0000 Subject: [issue17844] Add link to alternatives for bytes-to-bytes codecs In-Reply-To: <1366889842.88.0.0886939266057.issue17844@psf.upfronthosting.co.za> Message-ID: <3bGRg562MfzNKZ@mail.python.org> Roundup Robot added the comment: New changeset 85e8414060b4 by Nick Coghlan in branch '3.3': Issue 17844: Clarify meaning of different codec tables http://hg.python.org/cpython/rev/85e8414060b4 New changeset 801567d6302c by Nick Coghlan in branch 'default': Merge issue 17844 from 3.3 http://hg.python.org/cpython/rev/801567d6302c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 12:26:34 2013 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 23 May 2013 10:26:34 +0000 Subject: [issue17844] Add link to alternatives for bytes-to-bytes codecs In-Reply-To: <1366889842.88.0.0886939266057.issue17844@psf.upfronthosting.co.za> Message-ID: <1369304794.15.0.900788458396.issue17844@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thanks for initiating this Serhiy :) ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 12:28:34 2013 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 23 May 2013 10:28:34 +0000 Subject: [issue17839] base64 module should use memoryview In-Reply-To: <1366875154.79.0.0782227735295.issue17839@psf.upfronthosting.co.za> Message-ID: <1369304914.86.0.527815311883.issue17839@psf.upfronthosting.co.za> Nick Coghlan added the comment: We now also need to update the new footnote that I added for issue 17844 in http://hg.python.org/cpython/rev/801567d6302c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 13:28:57 2013 From: report at bugs.python.org (Ram Rachum) Date: Thu, 23 May 2013 11:28:57 +0000 Subject: [issue18043] No mention of `match.regs` in `re` documentation Message-ID: <1369308537.81.0.515783227267.issue18043@psf.upfronthosting.co.za> New submission from Ram Rachum: There's no mention of `match.regs` in the documentation of the `re` module. ---------- assignee: docs at python components: Documentation messages: 189859 nosy: cool-RR, docs at python priority: normal severity: normal status: open title: No mention of `match.regs` in `re` documentation type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 13:33:40 2013 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 23 May 2013 11:33:40 +0000 Subject: [issue17839] base64 module should use memoryview In-Reply-To: <1366875154.79.0.0782227735295.issue17839@psf.upfronthosting.co.za> Message-ID: <1369308820.27.0.807308116889.issue17839@psf.upfronthosting.co.za> Nick Coghlan added the comment: The codec uses the old API that breaks the encoded output up into multiple lines. The new patch: 1. Also changes the behaviour of the older de/encodebytes API 2. Checks that all the defined binary transform codecs actually support memoryview as input for both encoding and decoding (and that the data roundtrips correctly) ---------- Added file: http://bugs.python.org/file30346/issue17839_base64_buffer_input_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 13:36:55 2013 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 23 May 2013 11:36:55 +0000 Subject: [issue17839] base64 module should use memoryview In-Reply-To: <1366875154.79.0.0782227735295.issue17839@psf.upfronthosting.co.za> Message-ID: <1369309015.92.0.52855919473.issue17839@psf.upfronthosting.co.za> Nick Coghlan added the comment: Just adding a note for easier cross-referencing: the old behaviour of these functions was one of the culprits that led to the removal of the codec aliases as discussed in issue 7475 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 13:57:36 2013 From: report at bugs.python.org (Tim Rawlinson) Date: Thu, 23 May 2013 11:57:36 +0000 Subject: [issue18044] Email headers do not properly decode to unicode. Message-ID: <1369310256.22.0.862828757307.issue18044@psf.upfronthosting.co.za> New submission from Tim Rawlinson: In Python 3.3 decoding of headers to unicode is supposed to be automatic but fails in several cases, including one shown as successful in the documentation: >>> msg = message_from_string('Subject: =?utf-8?q?=C3=89ric?=\n\n', policy=default) >>> msg['Subject'] '=?utf-8?q?=C3=89ric?=' >>> msg = message_from_string('To: =?utf-8?q?=C3=89ric \n\n', policy=default) >>> msg['To'] '=?utf-8?q?=C3=89ric?= ' Although the following works: >>> msg = message_from_string('Subject: =?utf-8?q?Eric?=\n\n', policy=default) >>> msg['Subject'] 'Eric' Though this does not: >>> msg = message_from_string('To: =?utf-8?q?Eric?= \n\n', policy=default) >>> msg['To'] '=?utf-8?q?Eric?= ' And just to prove some things are working as they should: >>> msg = message_from_string("Subject: =?gb2312?b?1eLKx9bQzsSy4srUo6E=?=\n\n", policy=default) >>> msg['Subject'] '???????' ---------- assignee: docs at python components: Documentation, email messages: 189862 nosy: Tim.Rawlinson, barry, docs at python, r.david.murray priority: normal severity: normal status: open title: Email headers do not properly decode to unicode. type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 14:28:39 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 May 2013 12:28:39 +0000 Subject: [issue18007] CookieJar expects request objects with origin_req_host attribute instead of method In-Reply-To: <1368891902.97.0.967044954731.issue18007@psf.upfronthosting.co.za> Message-ID: <3bGVPL3XcMz7Ljb@mail.python.org> Roundup Robot added the comment: New changeset 26ac5b9cffda by Senthil Kumaran in branch '3.3': Fix #18007 : Document CookieJar.add_cookie_header request parameter changes in 3.3 http://hg.python.org/cpython/rev/26ac5b9cffda New changeset f7992397e98d by Senthil Kumaran in branch 'default': merge from 3.3 http://hg.python.org/cpython/rev/f7992397e98d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 14:29:15 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Thu, 23 May 2013 12:29:15 +0000 Subject: [issue18007] CookieJar expects request objects with origin_req_host attribute instead of method In-Reply-To: <1368891902.97.0.967044954731.issue18007@psf.upfronthosting.co.za> Message-ID: <1369312155.63.0.177444696386.issue18007@psf.upfronthosting.co.za> Senthil Kumaran added the comment: This change is documented. Thanks for the report. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 14:48:20 2013 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 23 May 2013 12:48:20 +0000 Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular encoding In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za> Message-ID: <1369313300.75.0.018359121.issue13612@psf.upfronthosting.co.za> Eli Bendersky added the comment: How about this patch (not tested it too much - just as a proof of concept). We're pretty free in the C API exported by pyexpat through a capsule to _elementtree, so we can also add a default handler there. This API already has some general utilities like ErrorString. ET can then simply call the handler from pyexpat. ---------- Added file: http://bugs.python.org/file30347/expat_et_share_unknown_handler.1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 14:52:06 2013 From: report at bugs.python.org (Delhallt) Date: Thu, 23 May 2013 12:52:06 +0000 Subject: [issue17454] ld_so_aix not used when linking c++ (scipy) In-Reply-To: <1363595248.19.0.716647347764.issue17454@psf.upfronthosting.co.za> Message-ID: <1369313526.82.0.580536680663.issue17454@psf.upfronthosting.co.za> Delhallt added the comment: proposed patch ---------- keywords: +patch nosy: +delhallt Added file: http://bugs.python.org/file30348/Python-2.7.5-linkso.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 18:20:42 2013 From: report at bugs.python.org (paul j3) Date: Thu, 23 May 2013 16:20:42 +0000 Subject: [issue9338] argparse optionals with nargs='?', '*' or '+' can't be followed by positionals In-Reply-To: <1279881989.28.0.725806934086.issue9338@psf.upfronthosting.co.za> Message-ID: <1369326042.2.0.778468251586.issue9338@psf.upfronthosting.co.za> paul j3 added the comment: Here's another approach to the problem, using an iterative localized search. For simple cases it produces the same thing, but in complex cases it is more robust. It is based on two ideas: - if the action in consume_optional() is being 'greedy', use slots = self._match_arguments_partial([action]+positionals, selected_patterns) to determine if this action can share arguments with any of the remaining positionals. This is similar to how consume_positionals() allocates arguments to the set of positionals. - try this 'sharing' with the last optional. If that is not enough, try the penultimate optional as well, and continue working toward the start as needed. Since the normal parsing is from left to right, figuring out when to start 'sharing' requires some sort of search strategy. I have moved the start_index loop into a consume_loop() function, and added a switch so it can parse the arguments without invoking take_action() (so arguments are not evaluated, and namespace is not changed). If there is a suspected 'greed' problem, consume_loop() is called (in test mode) one or more times to determine the right-most optionals to use, and once more (with take_action) to parse and evaluate the arguments. As in the previous patch this writes a log file for debugging purposes. test_argparse.py now has a number of tests for this issue. It is more robust than the previous patch, and does not need special handling for things like subparsers and explicit arguments. ---------- Added file: http://bugs.python.org/file30349/argparse_7.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 18:22:48 2013 From: report at bugs.python.org (paul j3) Date: Thu, 23 May 2013 16:22:48 +0000 Subject: [issue9338] argparse optionals with nargs='?', '*' or '+' can't be followed by positionals In-Reply-To: <1279881989.28.0.725806934086.issue9338@psf.upfronthosting.co.za> Message-ID: <1369326168.54.0.244590124441.issue9338@psf.upfronthosting.co.za> Changes by paul j3 : Removed file: http://bugs.python.org/file30349/argparse_7.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 18:23:52 2013 From: report at bugs.python.org (paul j3) Date: Thu, 23 May 2013 16:23:52 +0000 Subject: [issue9338] argparse optionals with nargs='?', '*' or '+' can't be followed by positionals In-Reply-To: <1279881989.28.0.725806934086.issue9338@psf.upfronthosting.co.za> Message-ID: <1369326232.57.0.721948663148.issue9338@psf.upfronthosting.co.za> paul j3 added the comment: Oops, I attached the wrong file. Here's the correct one. ---------- Added file: http://bugs.python.org/file30350/issue9338_7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 19:02:00 2013 From: report at bugs.python.org (James Socol) Date: Thu, 23 May 2013 17:02:00 +0000 Subject: [issue9883] minidom: AttributeError: DocumentFragment instance has no attribute 'writexml' In-Reply-To: <1284694245.92.0.410723728376.issue9883@psf.upfronthosting.co.za> Message-ID: <1369328520.04.0.869963555452.issue9883@psf.upfronthosting.co.za> Changes by James Socol : ---------- nosy: +jamessocol _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 19:05:11 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Thu, 23 May 2013 17:05:11 +0000 Subject: [issue17683] socket.getsockname() inconsistent return type with AF_UNIX In-Reply-To: <1369132880.2545.0.camel@fsol> Message-ID: Charles-Fran?ois Natali added the comment: > Shouldn't the surrogateescape error handler (PEP 383) prevent this? Yes, it shoud (I just read PEP 383, I told you I didn't know anything about encoding :-). So basically, for the test failure, the issue is simply that the platform's default encoding can't encode character '\xff'. Should I simply remove the offending character from this test address? Also, let's say I wanted to test that it can be passed and returned properly, so I add '\0xff' to the adress passed to testBytesName: s.bind(b"\x00python\x00test\xff") How should I check the string returned by getsockname()? self.assertEquals(s.getsockname(), ???) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 19:56:27 2013 From: report at bugs.python.org (Brett Cannon) Date: Thu, 23 May 2013 17:56:27 +0000 Subject: [issue17222] py_compile.compile() replaces target files, breaking special files and symlinks In-Reply-To: <1361136224.16.0.490340842207.issue17222@psf.upfronthosting.co.za> Message-ID: <1369331787.13.0.870353146469.issue17222@psf.upfronthosting.co.za> Brett Cannon added the comment: If someone wants to submit a patch to make the change that's fine, but they are going to have the same issue when they simply execute an import that byte-compiles as a side-effect so you will have to decide if you are only worried about py_compile. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 19:57:54 2013 From: report at bugs.python.org (Oscar Benjamin) Date: Thu, 23 May 2013 17:57:54 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: Message-ID: Oscar Benjamin added the comment: I have written a function that can be used to determine if the gcc that distutils will use is from Cygwin or MinGW: def is_cygwingcc(): '''Try to determine if the gcc that would be used is from cygwin.''' out = Popen(['gcc', '-dumpmachine'], shell=True, stdout=PIPE).stdout try: out_string = out.read() finally: out.close() # out_string is the target triplet cpu-vendor-os # Cygwin's gcc sets the os to 'cygwin' return out_string.strip().endswith('cygwin') The idea is that 'gcc -dumpmachine' emits a string that always ends in 'cygwin' for the Cygwin gcc (please let me know if I'm wrong about that). Earnie Boyd at mingw-users described this method for distinguishing MinGW and Cygwin gcc as not being a bad idea: http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42137 With this the Mingw32CCompiler.__init__ method can be modified to do: if self.gcc_version < '4' or is_cygwingcc(): no_cygwin = ' -mno-cygwin' else: no_cygwin = '' self.set_executables(compiler='gcc%s -O -Wall' % no_cygwin, compiler_so='gcc%s -mdll -O -Wall' % no_cygwin, compiler_cxx='g++%s -O -Wall' % no_cygwin, linker_exe='gcc%s' % no_cygwin, linker_so='%s%s %s %s' % (self.linker_dll, no_cygwin, shared_option, entry_point)) This will fix the problem for MinGW, should not break existing no-cygwin/gcc 3.x setups and preserves the error message currently seen for no-cygwin with gcc 4.x. In other words it should satisfy users in all three groups A, B and C referred to above. In particular the is_cygwingcc() function hopefully addresses Martin's concern for users in group C. Is this approach acceptable? Thanks, Oscar ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 20:00:14 2013 From: report at bugs.python.org (Brett Cannon) Date: Thu, 23 May 2013 18:00:14 +0000 Subject: [issue18018] SystemError: Parent module '' not loaded, cannot perform relative import In-Reply-To: <1369011708.43.0.213176616662.issue18018@psf.upfronthosting.co.za> Message-ID: <1369332014.42.0.508642133652.issue18018@psf.upfronthosting.co.za> Brett Cannon added the comment: The line raising the exception is http://hg.python.org/cpython/file/f7992397e98d/Lib/importlib/_bootstrap.py#l1518 . If you're sure it's a regression feel free to change what exception is raised. ---------- assignee: -> flox _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 20:48:38 2013 From: report at bugs.python.org (Thom Nichols) Date: Thu, 23 May 2013 18:48:38 +0000 Subject: [issue16692] Support TLS 1.1 and TLS 1.2 In-Reply-To: <1355592665.89.0.539973629387.issue16692@psf.upfronthosting.co.za> Message-ID: <1369334918.86.0.705847459733.issue16692@psf.upfronthosting.co.za> Thom Nichols added the comment: Is there any chance of this being backported to Python 2.7? Given NIST's complete deprecation of SHA1 and TLS 1.0 by end of 2013, I imagine there are at least a few folks who can't upgrade to Python 3.x, but need TLS 1.2 support. I think Ruby just recently implemented TLS 1.2 in 2.0, and backported it to the 1.9.3 tree. Thanks. ---------- nosy: +Thom.Nichols _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 21:11:39 2013 From: report at bugs.python.org (Roumen Petrov) Date: Thu, 23 May 2013 19:11:39 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: Message-ID: <519E69EA.1010301@roumenpetrov.info> Roumen Petrov added the comment: Oscar Benjamin wrote: > Oscar Benjamin added the comment: > > I have written a function that can be used to determine if the gcc > that distutils will use is from Cygwin or MinGW: > > def is_cygwingcc(): > '''Try to determine if the gcc that would be used is from cygwin.''' > out = Popen(['gcc', '-dumpmachine'], shell=True, stdout=PIPE).stdout > try: > out_string = out.read() > finally: > out.close() > # out_string is the target triplet cpu-vendor-os > # Cygwin's gcc sets the os to 'cygwin' > return out_string.strip().endswith('cygwin') > > The idea is that 'gcc -dumpmachine' emits a string that always ends in > 'cygwin' for the Cygwin gcc (please let me know if I'm wrong about > that). Earnie Boyd at mingw-users described this method for > distinguishing MinGW and Cygwin gcc as not being a bad idea: > http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42137 > > With this the Mingw32CCompiler.__init__ method can be modified to do: > > if self.gcc_version < '4' or is_cygwingcc(): It seems to me you try to find another method to detect support of some options. Where is written that compiler is gcc ? Yes this is current distutils code but please review my set of patches > no_cygwin = ' -mno-cygwin' > else: > no_cygwin = '' > > self.set_executables(compiler='gcc%s -O -Wall' % no_cygwin, > compiler_so='gcc%s -mdll -O -Wall' % no_cygwin, > compiler_cxx='g++%s -O -Wall' % no_cygwin, > linker_exe='gcc%s' % no_cygwin, > linker_so='%s%s %s %s' > % (self.linker_dll, no_cygwin, > shared_option, entry_point)) This will not work in new cygwin (1.7) environment with true cross-compilers. Reason is simple - executable is not gcc. > This will fix the problem for MinGW, should not break existing > no-cygwin/gcc 3.x setups and preserves the error message currently > seen for no-cygwin with gcc 4.x. In other words it should satisfy > users in all three groups A, B and C referred to above. In particular > the is_cygwingcc() function hopefully addresses Martin's concern for > users in group C. > > Is this approach acceptable? It is not enough. > Thanks, > Oscar > > ---------- > Roumen ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 21:58:30 2013 From: report at bugs.python.org (Zachary Ware) Date: Thu, 23 May 2013 19:58:30 +0000 Subject: [issue16895] Batch file to mimic 'make' on Windows In-Reply-To: <1357677821.21.0.151237367429.issue16895@psf.upfronthosting.co.za> Message-ID: <1369339110.78.0.049388078146.issue16895@psf.upfronthosting.co.za> Zachary Ware added the comment: Here's a new version of the patch, which is a major rewrite. Among the changes: - Switch from using 'goto' to execute the right subroutine to 'call' and end every subroutine with 'exit /B' (thank you Richard for making me aware of that possibility). This makes the :end label useless, so it's removed. Every subroutine now expects to start in the root of the source tree, and is expected to return there before exiting. - Changed the argument parsing magic to a different flavor of magic. Setting variables on the command line is now much more like it is using Unix make, no more required double quotes around the whole assignment, and you can now specify multiple targets in a single command. This method can be quite a bit slower if you give a huge command, as it steps through the command line a character at a time (on the order of several seconds if you're appending something to PATH, for instance. The delay is not noticeable if you're just giving targets), but at least all the magic is self-contained. - Add '--no-externals' and '--interactive' options to configure.bat to ignore the presence or absence of the external libs and to allow questions to be asked of the user, respectively. I've waffled back and forth on whether it is better for the '--interactive' option to be on or off by default, currently it is off. - On 64 bit machines, default to Win32 platform if vcvarsx86_amd64.bat can't be found. - Give some nicer output just about everywhere. This includes making configure.bat die early in case %VS100COMNTOOLS% is not defined with a message to install MSVC++ 2010 Express, a warning if NASM is not available, and tagging all output with the name of the script. Also, add a message at the end of building Python giving the best estimate of the outcome. - Another part of giving a nice message at the end of building Python: if the expected executable file exists at the end, exit code 0 is returned. This is for the buildbots, so that even if the build had errors, the tests are still run so we can see what is actually broken. This ties in with the new '--no-externals' option on configure.bat, which would allow a buildbot to build with '--no-externals' and still be able to test everything else. - List and use specific exit codes. If anyone has advice on better numbers to use (more standard numbers, perhaps), please let me know :). - Use "absolute relative" paths (paths that always start with %~dp0, but may include '..') to avoid some directory changing magic just to make a relative path point to the right place. - 'clobber' target builds the clean target of Win32 configuration, then x64 config if the environment can be set up to do so. - 'importlib' will clean up after itself if there wasn't a build already done. - Some refactoring and cleanup to put things in places that make more sense and look better. This includes major changes to :external and :tcltk to use a couple of loops to be more DRY. - Change Tools/scripts/run_tests.py (used by the test targets in make.bat and Makefile) to use subprocess.call instead of os.execv on win32. Since execv creates a new process on Windows, control was handed back to the console as soon as the execv call was made, but the test output still came to the terminal so the prompt was lost in the test output and did not automatically come up at the end of the test. Using subprocess.call keeps control in the parent python(_d) process and doesn't release back to the console until the test is done. - Added better documentation of make.bat usage to PCbuild\readme.txt, and took out unrelated changes to that file (which will be posted to another issue). Everything works as expected for me, but I do only have a 32bit machine available to me currently. I hope to be able to test on a 64bit machine soon, but have no guarantees. For anyone testing this, I would suggest to run the command "prompt $+%PROMPT%" before testing; this will add a "+" to the beginning of your prompt for every dir on the pushd/popd stack. Neither configure.bat nor make.bat should ever remove dirs from that stack, and should not leave any extras when they're done (unless forcibly killed in the middle of running). ---------- Added file: http://bugs.python.org/file30351/win_configure-make.v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 22:07:33 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 May 2013 20:07:33 +0000 Subject: [issue13483] Use VirtualAlloc to allocate memory arenas In-Reply-To: <1322313162.87.0.914810161445.issue13483@psf.upfronthosting.co.za> Message-ID: <1369339653.93.0.118260011064.issue13483@psf.upfronthosting.co.za> STINNER Victor added the comment: Set also issue #3329 which proposes an API to define memory allocators. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 22:14:18 2013 From: report at bugs.python.org (Zachary Ware) Date: Thu, 23 May 2013 20:14:18 +0000 Subject: [issue17326] Windows build docs still referring to VS 2008 in 3.3 In-Reply-To: <1362142705.89.0.367756520949.issue17326@psf.upfronthosting.co.za> Message-ID: <1369340058.82.0.365385509304.issue17326@psf.upfronthosting.co.za> Zachary Ware added the comment: Here's a simple patch to clear up the first paragraph of PCbuild/readme.txt, applicable to 3.3 and default. ---------- keywords: +patch nosy: +zach.ware Added file: http://bugs.python.org/file30352/issue17326.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 23:06:04 2013 From: report at bugs.python.org (Paul Moore) Date: Thu, 23 May 2013 21:06:04 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: <519E69EA.1010301@roumenpetrov.info> Message-ID: Paul Moore added the comment: On 23 May 2013 20:11, Roumen Petrov wrote: > > Is this approach acceptable? > It is not enough. > Support for compilers other than gcc (including cross-compilers) is a separate issue, and one which is much less likely to get accepted. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 23:24:24 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 23 May 2013 21:24:24 +0000 Subject: [issue16692] Support TLS 1.1 and TLS 1.2 In-Reply-To: <1369334918.86.0.705847459733.issue16692@psf.upfronthosting.co.za> Message-ID: <1369344255.2622.0.camel@fsol> Antoine Pitrou added the comment: > Is there any chance of this being backported to Python 2.7? Given > NIST's complete deprecation of SHA1 and TLS 1.0 by end of 2013, I > imagine there are at least a few folks who can't upgrade to Python > 3.x, but need TLS 1.2 support. I think Ruby just recently implemented > TLS 1.2 in 2.0, and backported it to the 1.9.3 tree. Thanks. No, sorry. 2.7 only gets bug fixes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 23:33:37 2013 From: report at bugs.python.org (Zachary Ware) Date: Thu, 23 May 2013 21:33:37 +0000 Subject: [issue10652] test___all_ + test_tcl fails (Windows installed binary) In-Reply-To: <1291819198.8.0.493152862608.issue10652@psf.upfronthosting.co.za> Message-ID: <1369344817.39.0.979700241711.issue10652@psf.upfronthosting.co.za> Zachary Ware added the comment: Terry, I just tested your 2.7 patch, and it does work, but the workaround that (I think) we have both been using on 3.x to find the Tcl/Tk .dlls (copying them into PCbuild) doesn't work on 2.7 for some reason. However, if you add ..\tcltk\bin to PATH, which the PCbuild\rt.bat script (called by Tools\buildbot\test(-amd64).bat) does, your patch allows all of the test modules to run properly. I wonder if this has anything to do with issue17883's buildbot problems? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 23:45:19 2013 From: report at bugs.python.org (David Wolever) Date: Thu, 23 May 2013 21:45:19 +0000 Subject: [issue17701] Improving strftime documentation In-Reply-To: <1365725163.24.0.249924950016.issue17701@psf.upfronthosting.co.za> Message-ID: <1369345519.59.0.927695157759.issue17701@psf.upfronthosting.co.za> Changes by David Wolever : Added file: http://bugs.python.org/file30353/102b3e257dca.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 23 23:53:28 2013 From: report at bugs.python.org (David Wolever) Date: Thu, 23 May 2013 21:53:28 +0000 Subject: [issue17701] Improving strftime documentation In-Reply-To: <1365725163.24.0.249924950016.issue17701@psf.upfronthosting.co.za> Message-ID: <1369346008.3.0.177300302733.issue17701@psf.upfronthosting.co.za> Changes by David Wolever : Removed file: http://bugs.python.org/file30353/102b3e257dca.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 00:01:20 2013 From: report at bugs.python.org (David Wolever) Date: Thu, 23 May 2013 22:01:20 +0000 Subject: [issue17701] Improving strftime documentation In-Reply-To: <1365725163.24.0.249924950016.issue17701@psf.upfronthosting.co.za> Message-ID: <1369346480.79.0.0912790504503.issue17701@psf.upfronthosting.co.za> Changes by David Wolever : Added file: http://bugs.python.org/file30354/0f4d971b0cee.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 00:23:35 2013 From: report at bugs.python.org (Ethan Furman) Date: Thu, 23 May 2013 22:23:35 +0000 Subject: [issue18042] Provide enum.unique class decorator In-Reply-To: <1369299378.37.0.789518154232.issue18042@psf.upfronthosting.co.za> Message-ID: <1369347815.85.0.931599912228.issue18042@psf.upfronthosting.co.za> Ethan Furman added the comment: This is certainly an effective method, but it places safety off by default. I would rather have a system that was from duplicates by default but had an easy override. The method I had in place in my original code was something like: class Color(Enum, options=DUPLICATES): red = 1 green = 2 blue = 3 grene = 2 Without the DUPLICATES option, the above class would raise an error. Safe(r) by default, easy override. If my suggestion doesn't fly, we should definitely put Nick's in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 00:28:53 2013 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 23 May 2013 22:28:53 +0000 Subject: [issue7940] re.finditer and re.findall should support negative end positions In-Reply-To: <1266329075.25.0.639780854585.issue7940@psf.upfronthosting.co.za> Message-ID: <1369348133.11.0.887943202956.issue7940@psf.upfronthosting.co.za> Mark Lawrence added the comment: Has this been fixed in the regex module? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 00:38:31 2013 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 23 May 2013 22:38:31 +0000 Subject: [issue18042] Provide enum.unique class decorator In-Reply-To: <1369347815.85.0.931599912228.issue18042@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: I take Guido's acceptance of the PEP (and the discussion in the previous issue) as meaning the default behaviour (allowing aliases) is no longer up for debate. Hence this suggestion to offer a self-documenting way to opt in to the more restrictive variant. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 00:43:41 2013 From: report at bugs.python.org (Ethan Furman) Date: Thu, 23 May 2013 22:43:41 +0000 Subject: [issue18042] Provide enum.unique class decorator In-Reply-To: <1369299378.37.0.789518154232.issue18042@psf.upfronthosting.co.za> Message-ID: <1369349021.43.0.0230650952519.issue18042@psf.upfronthosting.co.za> Ethan Furman added the comment: I'm not giving up hope yet. Plenty of Python features no longer work the way they did when their PEP was accepted. ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 00:44:02 2013 From: report at bugs.python.org (Matthew Barnett) Date: Thu, 23 May 2013 22:44:02 +0000 Subject: [issue7940] re.finditer and re.findall should support negative end positions In-Reply-To: <1266329075.25.0.639780854585.issue7940@psf.upfronthosting.co.za> Message-ID: <1369349042.37.0.320957394843.issue7940@psf.upfronthosting.co.za> Matthew Barnett added the comment: Yes. As msg99456 suggests, I fixed it the my source code before posting. Compare re in Python 3.3.2: >>> re.compile('x').findall('xxxx', 1, 3) ['x', 'x'] >>> re.compile('x').findall('xxxx', 1, -1) [] with regex: >>> regex.compile('x').findall('xxxx', 1, 3) ['x', 'x'] >>> regex.compile('x').findall('xxxx', 1, -1) ['x', 'x'] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 02:05:22 2013 From: report at bugs.python.org (Nikolaus Rath) Date: Fri, 24 May 2013 00:05:22 +0000 Subject: [issue7760] use_errno=True does not work In-Reply-To: <1264205937.75.0.643663912285.issue7760@psf.upfronthosting.co.za> Message-ID: <1369353922.79.0.459929993536.issue7760@psf.upfronthosting.co.za> Nikolaus Rath added the comment: Matt, I believe in that case it's still a documentation issue, because then the documentation probably should say that using absolute paths to libraries is a bad idea in general. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 02:27:36 2013 From: report at bugs.python.org (Renato Silva) Date: Fri, 24 May 2013 00:27:36 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za> Message-ID: <1369355256.31.0.666634749447.issue12641@psf.upfronthosting.co.za> Renato Silva added the comment: I must note that GCC 4.x *does* support -mno-cygwin, at least until 4.4, and at least the MinGW version. I have used it myself for building Pidgin under Windows, which requires that option. See [1] where a Pidgin developer confirms that. [1] http://pidgin.im/pipermail/support/2011-December/011159.html ---------- nosy: +renatosilva _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 02:37:22 2013 From: report at bugs.python.org (Matt Mao) Date: Fri, 24 May 2013 00:37:22 +0000 Subject: [issue18045] get_python_version is not import in bdist_rpm.py Message-ID: <1369355842.75.0.290813933305.issue18045@psf.upfronthosting.co.za> New submission from Matt Mao: Python version : 2.7.5 OS : CentOS 6.3 When I tried to build a rpm with "python ./setup.py bdist_rpm", I get the following error : Traceback (most recent call last): File "setup.py", line 221, in ... and much more ;)""" File "/usr/local/python2.7/lib/python2.7/distutils/core.py", line 152, in setup dist.run_commands() File "/usr/local/python2.7/lib/python2.7/distutils/dist.py", line 953, in run_commands self.run_command(cmd) File "/usr/local/python2.7/lib/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/usr/local/python2.7/lib/python2.7/python2.7/distutils/command/bdist_rpm.py", line 383, in run pyversion = get_python_version() NameError: global name 'get_python_version' is not defined I find that we do not import function get_python_version in python2.7/distutils/command/bdist_rpm.py. I think we need to add ?from distutils.sysconfig import get_python_version? in this file. ---------- assignee: eric.araujo components: Distutils messages: 189888 nosy: eric.araujo, maoliping455, tarek priority: normal severity: normal status: open title: get_python_version is not import in bdist_rpm.py versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 02:54:35 2013 From: report at bugs.python.org (Alex Gaynor) Date: Fri, 24 May 2013 00:54:35 +0000 Subject: [issue18046] Simplify and clarify logging internals Message-ID: <1369356875.31.0.0932169954685.issue18046@psf.upfronthosting.co.za> New submission from Alex Gaynor: This patch splits a dictionary that maps integer and string representations of levels to each other out into two dictionaries, one which goes int -> string, and the other which is string -> int. This makes it easier to reason about what a variable contains. ---------- components: Library (Lib) files: log-simple.diff keywords: needs review, patch messages: 189889 nosy: alex priority: normal severity: normal stage: patch review status: open title: Simplify and clarify logging internals versions: Python 3.4 Added file: http://bugs.python.org/file30355/log-simple.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 03:59:52 2013 From: report at bugs.python.org (Alex Gaynor) Date: Fri, 24 May 2013 01:59:52 +0000 Subject: [issue18046] Simplify and clarify logging internals In-Reply-To: <1369356875.31.0.0932169954685.issue18046@psf.upfronthosting.co.za> Message-ID: <1369360792.06.0.887310470121.issue18046@psf.upfronthosting.co.za> Changes by Alex Gaynor : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 04:53:23 2013 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 May 2013 02:53:23 +0000 Subject: [issue18042] Provide enum.unique class decorator In-Reply-To: <1369299378.37.0.789518154232.issue18042@psf.upfronthosting.co.za> Message-ID: <1369364003.18.0.445813327827.issue18042@psf.upfronthosting.co.za> Nick Coghlan added the comment: You don't generally see reversals of decisions where Guido has made an explicit choice based on consistency with the rest of the language. The fact that aliases are permitted in enumerations by default is consistent with the normal behaviour of namespaces and dictionaries in general, so providing a way to opt in to the stricter checks is a better solution. The idea of passing flags or other configuration options to the metaclass is also rather ugly. Offering permissive behaviour by default with an easy way to opt in to additional restrictions is far more in keeping with the general "consenting adults" ethos of the language. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 06:04:09 2013 From: report at bugs.python.org (Eric Snow) Date: Fri, 24 May 2013 04:04:09 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1369368249.06.0.351464370256.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: It's worth noting that issue10977 is pretty closely related to this isssue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 06:18:12 2013 From: report at bugs.python.org (Ethan Furman) Date: Fri, 24 May 2013 04:18:12 +0000 Subject: [issue18042] Provide enum.unique class decorator In-Reply-To: <1369299378.37.0.789518154232.issue18042@psf.upfronthosting.co.za> Message-ID: <1369369092.72.0.700489923188.issue18042@psf.upfronthosting.co.za> Ethan Furman added the comment: Oh. Well, I like your decorator. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 06:38:31 2013 From: report at bugs.python.org (Eric Snow) Date: Fri, 24 May 2013 04:38:31 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1369370311.54.0.0731928078113.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: > I just looked at the test-collections patch and don't want it > committed. It is full of trivial edits that make it hard to > review and doesn't make the test suite better. Thanks for the feedback, Raymond. I agree that there are a number of trivial edits there that shouldn't be there. I'll fix those. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 07:07:30 2013 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 May 2013 05:07:30 +0000 Subject: [issue18042] Provide enum.unique class decorator In-Reply-To: <1369299378.37.0.789518154232.issue18042@psf.upfronthosting.co.za> Message-ID: <1369372050.65.0.52720390387.issue18042@psf.upfronthosting.co.za> Nick Coghlan added the comment: Don't worry, compared to some of the ideas I've had (and rightfully had shot down) over the years, that one was positively sensible :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 07:10:54 2013 From: report at bugs.python.org (Eric Snow) Date: Fri, 24 May 2013 05:10:54 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1369372254.09.0.465803208718.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: Raymond, do you have any objections to splitting the OrderedDict-related tests into their own module. Doing so allows for testing all the those test classes at once, which is handy when working on OrderedDict. This is more relevant now with the extra PEP-399-motivated tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 07:39:43 2013 From: report at bugs.python.org (Arnaud Porterie) Date: Fri, 24 May 2013 05:39:43 +0000 Subject: [issue18047] Descriptors get invoked in old-style objects and classes Message-ID: <1369373983.58.0.00587959802813.issue18047@psf.upfronthosting.co.za> New submission from Arnaud Porterie: In the Data Model section of the documentation regarding descriptors invokations (http://docs.python.org/2/reference/datamodel.html#invoking-descriptors), it is said: Note that descriptors are only invoked for new style objects or classes (ones that subclass object() or type()). However, it seems this restriction isn't enforced in practice: Python 2.7.4 (default, May 16 2013, 13:28:03) [GCC 4.2.1 Compatible Apple Clang 4.0 ((tags/Apple/clang-421.0.60))] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> class Desc(object): ... def __get__(self, obj, cls): ... return 'test' ... >>> class A: # Not inheriting object here ... desc = Desc() ... >>> A().desc 'test' I dived into CPython's code and saw no trace of a test for new-style classes in the descriptor invokation code path (down in classobject.c / instance_getattr2). Unfortunately, fixing this behavior doesn't seem trivial as class methods appear to be implemented as descriptor themselves. In other words, and from my understanding, restricting descriptor invokation to new-style objects and classes would prevent method calls on old-style classes. ---------- components: Interpreter Core files: desc.py messages: 189896 nosy: icecrime priority: normal severity: normal status: open title: Descriptors get invoked in old-style objects and classes type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file30356/desc.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 07:57:00 2013 From: report at bugs.python.org (Eric Snow) Date: Fri, 24 May 2013 05:57:00 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1369375020.46.0.125444740886.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: I finally had some time so here's an updated patch (including O(1) deletions). I've also added a bunch of notes at the top of odictobject.c. Some notable things left to do: * address two recently failing tests due to r83881 (issue 17900) * check for any reference cycles (should be fine) * validate reentrancy (make sure everything is thread-safe around calls into Python) * make sure subclassing is okay * compare performance to dict, pure Python OrderedDict My goal here is to get an effective OrderedDict that we are happy with, while recognizing that there is room for optimization. However, I won't be okay with faultiness, so the implementation must be complete. This has been my mindset throughout. ---------- Added file: http://bugs.python.org/file30357/cOrderedDict.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 07:57:15 2013 From: report at bugs.python.org (Eric Snow) Date: Fri, 24 May 2013 05:57:15 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1369375035.76.0.300596643421.issue16991@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file29077/cleanup-test-collections.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 07:57:22 2013 From: report at bugs.python.org (Eric Snow) Date: Fri, 24 May 2013 05:57:22 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1369375042.61.0.514349079431.issue16991@psf.upfronthosting.co.za> Changes by Eric Snow : Removed file: http://bugs.python.org/file29078/odict.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 08:19:08 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 May 2013 06:19:08 +0000 Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular encoding In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za> Message-ID: <1369376348.58.0.353046319997.issue13612@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM. But why not just inline expat_unknown_encoding_handler()? For 2.7 we perhaps should add SetStartDoctypeDeclHandler and SetEncoding in the exported C API. Shouldn't we update the C API version (for this issue and for issue16986)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 08:37:58 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 24 May 2013 06:37:58 +0000 Subject: [issue18018] SystemError: Parent module '' not loaded, cannot perform relative import In-Reply-To: <1369011708.43.0.213176616662.issue18018@psf.upfronthosting.co.za> Message-ID: <1369377478.28.0.8718207597.issue18018@psf.upfronthosting.co.za> Antoine Pitrou added the comment: User code should generally not see any SystemErrors (even when choosing wacky module names :-)), so IMHO this is a regression. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 09:01:59 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 May 2013 07:01:59 +0000 Subject: [issue17839] base64 module should use memoryview In-Reply-To: <1366875154.79.0.0782227735295.issue17839@psf.upfronthosting.co.za> Message-ID: <1369378919.79.0.0373937710917.issue17839@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It works only if input also supports slicing and this slicing is corresponded to bytes-slicing. It perhaps doesn't catch a non C-continuous buffers. Actually we need something like (unlikely cast() doesn't work with empty buffers): s = memoryview(s) if not s: return b'' s = s.cast('B') ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 09:35:28 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 May 2013 07:35:28 +0000 Subject: [issue18011] Inconsistency between b32decode() documentation, docstring and code In-Reply-To: <1368951549.72.0.00589705304437.issue18011@psf.upfronthosting.co.za> Message-ID: <1369380928.24.0.75788318451.issue18011@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Are there any objections? ---------- assignee: docs at python -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 11:30:13 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 May 2013 09:30:13 +0000 Subject: [issue18048] Merging test_pep263.py and test_coding.py Message-ID: <1369387812.98.0.236232283698.issue18048@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: There are two test files for the same feature -- defining Python source code encodings (PEP 263). It is not clear where new tests should be added. Perhaps two files should be merged into the one file. test_pep263.py was added in 2002, test_coding.py was added in 2005. ---------- components: Tests, Unicode messages: 189902 nosy: ezio.melotti, lemburg, loewis, nnorwitz, serhiy.storchaka priority: normal severity: normal status: open title: Merging test_pep263.py and test_coding.py type: enhancement versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 11:53:58 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 24 May 2013 09:53:58 +0000 Subject: [issue18038] Unhelpful error message on invalid encoding specification In-Reply-To: <1369262596.73.0.912726466313.issue18038@psf.upfronthosting.co.za> Message-ID: <1369389238.57.0.502904303805.issue18038@psf.upfronthosting.co.za> Martin v. L?wis added the comment: LGTM. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 11:55:34 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 24 May 2013 09:55:34 +0000 Subject: [issue18040] SIGINT catching regression on windows in 2.7 In-Reply-To: <1369278066.93.0.310534523814.issue18040@psf.upfronthosting.co.za> Message-ID: <1369389334.62.0.390537114479.issue18040@psf.upfronthosting.co.za> Changes by Martin v. L?wis : ---------- nosy: +loewis, tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 11:57:04 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 24 May 2013 09:57:04 +0000 Subject: [issue18041] mention issues with code churn in the devguide In-Reply-To: <1369280251.47.0.219323501066.issue18041@psf.upfronthosting.co.za> Message-ID: <1369389424.97.0.285443378216.issue18041@psf.upfronthosting.co.za> Martin v. L?wis added the comment: What does "churn" mean? ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 12:09:30 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 May 2013 10:09:30 +0000 Subject: [issue18038] Unhelpful error message on invalid encoding specification In-Reply-To: <1369262596.73.0.912726466313.issue18038@psf.upfronthosting.co.za> Message-ID: <1369390170.38.0.299920670697.issue18038@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a better patch with tests (see also issue18048). ---------- Added file: http://bugs.python.org/file30358/tokenizer_encoding_problem_msg.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 12:52:19 2013 From: report at bugs.python.org (Oscar Benjamin) Date: Fri, 24 May 2013 10:52:19 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: <1369355256.31.0.666634749447.issue12641@psf.upfronthosting.co.za> Message-ID: Oscar Benjamin added the comment: > Renato Silva added the comment: > > I must note that GCC 4.x *does* support -mno-cygwin, at least until 4.4, and at least the MinGW version. MinGW has never "supported" the -mno-cygwin option. It has simply tolerated it. The option never did anything useful and at some point it became an error to even supply it. I'm not sure exactly when but some time after 4.4 sounds reasonable to me. The option was only ever meaningful in cygwin's gcc 3.x and was always an error in 4.x. > I have used it myself for building Pidgin under Windows, which requires that option. See [1] where a Pidgin developer confirms that. > No the developer does not confirm that the -mno-cygin option is required for MinGW. Also from what I've seen I would say that the error message that the OP shows there comes from Cygwin's gcc not MinGW. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 13:51:37 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 May 2013 11:51:37 +0000 Subject: [issue17269] getaddrinfo segfaults on OS X when provided with invalid arguments combinations In-Reply-To: <1361489513.5.0.894275569557.issue17269@psf.upfronthosting.co.za> Message-ID: <3bH5X81R5HzR4Y@mail.python.org> Roundup Robot added the comment: New changeset f4981d8eb401 by Ronald Oussoren in branch '2.7': Issue #17269: Workaround for a platform bug in getaddrinfo on OSX http://hg.python.org/cpython/rev/f4981d8eb401 New changeset 3c4a5dc29417 by Ronald Oussoren in branch '3.3': Issue #17269: Workaround for a platform bug in getaddrinfo on OSX http://hg.python.org/cpython/rev/3c4a5dc29417 New changeset 24ffb0148729 by Ronald Oussoren in branch 'default': (3.3->default) Issue #17269: Workaround for a platform bug in getaddrinfo on OSX http://hg.python.org/cpython/rev/24ffb0148729 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 13:54:36 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 May 2013 11:54:36 +0000 Subject: [issue18038] Unhelpful error message on invalid encoding specification In-Reply-To: <1369262596.73.0.912726466313.issue18038@psf.upfronthosting.co.za> Message-ID: <1369396476.65.0.928895476071.issue18038@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file30345/tokenizer_encoding_problem_msg.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 14:19:11 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 24 May 2013 12:19:11 +0000 Subject: [issue18048] Merging test_pep263.py and test_coding.py In-Reply-To: <1369387812.98.0.236232283698.issue18048@psf.upfronthosting.co.za> Message-ID: <1369397951.07.0.267436940782.issue18048@psf.upfronthosting.co.za> Martin v. L?wis added the comment: For a bug fix release, I consider refactoring of test cases inappropriate. If they really ought to be merged, I consider neither file name particularly descriptive, so perhaps a new file name should be used altogether (e.g. test_source_encoding). ---------- versions: -Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 15:09:31 2013 From: report at bugs.python.org (Christian Heimes) Date: Fri, 24 May 2013 13:09:31 +0000 Subject: [issue17997] ssl.match_hostname(): sub string wildcard should not match IDNA prefix In-Reply-To: <1368799493.86.0.504478450601.issue17997@psf.upfronthosting.co.za> Message-ID: <1369400971.97.0.272791728783.issue17997@psf.upfronthosting.co.za> Christian Heimes added the comment: I finally found the correct RFC for wildcard matching. I think our implementation violates some recommendations. http://tools.ietf.org/html/rfc6125#section-6.4.2 http://tools.ietf.org/html/rfc6125#section-6.4.3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 15:26:59 2013 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 May 2013 13:26:59 +0000 Subject: [issue13266] Add inspect.unwrap(f) to easily unravel "__wrapped__" chains In-Reply-To: <1319611391.89.0.610441716125.issue13266@psf.upfronthosting.co.za> Message-ID: <1369402019.79.0.833205449868.issue13266@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: -> ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 15:27:13 2013 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 May 2013 13:27:13 +0000 Subject: [issue17482] functools.update_wrapper mishandles __wrapped__ In-Reply-To: <1363714542.8.0.838364934538.issue17482@psf.upfronthosting.co.za> Message-ID: <1369402033.36.0.73249442673.issue17482@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: -> ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 15:33:13 2013 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 24 May 2013 13:33:13 +0000 Subject: [issue17482] functools.update_wrapper mishandles __wrapped__ In-Reply-To: <1363714542.8.0.838364934538.issue17482@psf.upfronthosting.co.za> Message-ID: <1369402393.96.0.987372585345.issue17482@psf.upfronthosting.co.za> Nick Coghlan added the comment: Georg, just a heads up that I was informed of a fairly significant bug in the __wrapped__ handling which some folks doing function introspection had been assuming was a feature. I'd like to fix it for 3.3.3, but need your +1 as RM since it *will* break introspection code which assumes the current behaviour was intentional. ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 15:42:48 2013 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 24 May 2013 13:42:48 +0000 Subject: [issue17482] functools.update_wrapper mishandles __wrapped__ In-Reply-To: <1363714542.8.0.838364934538.issue17482@psf.upfronthosting.co.za> Message-ID: <1369402968.65.0.84656534454.issue17482@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 15:58:22 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 24 May 2013 13:58:22 +0000 Subject: [issue17269] getaddrinfo segfaults on OS X when provided with invalid arguments combinations In-Reply-To: <1361489513.5.0.894275569557.issue17269@psf.upfronthosting.co.za> Message-ID: <1369403902.91.0.978623473042.issue17269@psf.upfronthosting.co.za> Changes by Ronald Oussoren : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 16:07:39 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 24 May 2013 14:07:39 +0000 Subject: [issue11101] plistlib has no graceful way of handing None values In-Reply-To: <1296673853.21.0.702351569168.issue11101@psf.upfronthosting.co.za> Message-ID: <1369404459.94.0.254593128169.issue11101@psf.upfronthosting.co.za> Ronald Oussoren added the comment: At first I didn't like the proposal, but when I looked at the JSON module I noticed it has similar functionality for ignoring keys that cannot be represented in a JSON file. I'll look into this after merging #14455. The JSON library has two other options that might be useful for the plistlib library: sort_keys (sort the keys in the serialization of of dicts) and default(obj), which is a function for transforming values that cannot be represented natively. ---------- assignee: -> ronaldoussoren nosy: +ned.deily versions: +Python 3.4 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 16:27:46 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 24 May 2013 14:27:46 +0000 Subject: [issue18049] Re-enable threading test on OSX Message-ID: <1369405666.05.0.54874731136.issue18049@psf.upfronthosting.co.za> New submission from Ronald Oussoren: I recently notied that test.test_threading.ThreadingExceptionTests.test_recursion_limit is disabled for debug builds. The attached patch re-enables this test case and fixes the crash be increasing the stack size for new threads. The disadvantage of the patch is that is increases the default stack size for all new threads on OSX from 5 to 8 megabytes (for threads created by Python) and that could affect program behavior as fewer threads can be created before running out of memory. The patch could be updated to check for Py_DEBUG and only increase the stack size for --with-pydebug builds (which are the ones using -O0), as those builds need the increased stack size and debug builds already consume more memory that normal builds. That's not 100% reliable though, as users could also build the with CFLAGS set to -O0 without using --with-pydebug. I haven't found a way to detect the optimization level with clang or gcc using the preprocessor. ---------- assignee: ronaldoussoren components: Macintosh files: reenable-threading-test.txt messages: 189912 nosy: ned.deily, ronaldoussoren priority: normal severity: normal stage: patch review status: open title: Re-enable threading test on OSX type: behavior Added file: http://bugs.python.org/file30359/reenable-threading-test.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 18:04:49 2013 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 24 May 2013 16:04:49 +0000 Subject: [issue2053] IDLE - standardize dialogs In-Reply-To: <1202515821.86.0.159216664847.issue2053@psf.upfronthosting.co.za> Message-ID: <1369411489.96.0.584313536906.issue2053@psf.upfronthosting.co.za> Mark Lawrence added the comment: Bump as IDLE is now being actively developed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 18:11:28 2013 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 24 May 2013 16:11:28 +0000 Subject: [issue4304] build mode which fails for build failures in extensions In-Reply-To: <1226482481.6.0.943122034161.issue4304@psf.upfronthosting.co.za> Message-ID: <1369411888.34.0.846052429472.issue4304@psf.upfronthosting.co.za> Mark Lawrence added the comment: Can someone answer the question pointed to by msg109816 i.e. can all of the buildbots build all of the expected extensions? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 18:14:34 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 May 2013 16:14:34 +0000 Subject: [issue17272] request.full_url: unexpected results on assignment In-Reply-To: <1361512602.9.0.97298415685.issue17272@psf.upfronthosting.co.za> Message-ID: <3bHCMY3Vq3z7LnC@mail.python.org> Roundup Robot added the comment: New changeset 51c5870144e7 by Senthil Kumaran in branch 'default': Fix #17272 - Make Request.full_url and Request.get_full_url return same result under all circumstances. http://hg.python.org/cpython/rev/51c5870144e7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 18:16:33 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 24 May 2013 16:16:33 +0000 Subject: [issue17701] Improving strftime documentation In-Reply-To: <1365725163.24.0.249924950016.issue17701@psf.upfronthosting.co.za> Message-ID: <1369412193.02.0.199025679527.issue17701@psf.upfronthosting.co.za> ?ric Araujo added the comment: Looks good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 18:17:57 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 24 May 2013 16:17:57 +0000 Subject: [issue14455] plistlib unable to read json and binary plist files In-Reply-To: <1333144578.81.0.343123708942.issue14455@psf.upfronthosting.co.za> Message-ID: <1369412277.92.0.136766838536.issue14455@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I've started work on integrating the latest patch. Some notes (primarily for my own use): * I'll drop support for the JSON format, that format is not used by Apple's libraries (although the plutil tool can convert plists to JSON) * The patch (plistlib_with_tests.diff) no longer applies cleanly, there are two rejected hunks in test_plist.py. * There is no documentation update in the patch, I'm working on that * There is also an NextStep format (see . That format is not supported by plutil, but is supported by Apple's libraries. Support for this can be added later. * plistlib needs futher work as well, it would be nice to move closer to the PEP8 coding style (although this should be done carefully to maintain compatibility with existing code. * plistlib.Data should be deprecated. The class was needed in python 2.7, but python 3 already has a unambiguous representation for binary data: the bytes type. * It might be nice to add some options from the json library to the serialization function: * skipkeys=True/False: skip keys that aren't strings and cannot be represented in a plist file, instead of raising TypeError * check_circular=True/False: explicitly check for circular recursion and raise an exception instead of hoping that some other exception occurs * default=function(obj): a function that is called on values that cannot be represented, should either return a value that can be encoded or raise TypeError * Issue #11101 mentions that it would be nice to have an option to ignore keys whose value is None. I'm not sure if this is really useful, and if it is it might be better to add a "skip values" option that ignores items where the value cannot be encoded. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 18:19:04 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Fri, 24 May 2013 16:19:04 +0000 Subject: [issue17272] request.full_url: unexpected results on assignment In-Reply-To: <1361512602.9.0.97298415685.issue17272@psf.upfronthosting.co.za> Message-ID: <1369412344.61.0.767477877523.issue17272@psf.upfronthosting.co.za> Senthil Kumaran added the comment: This is fixed in 3.4. I dont think backporting is a good idea just to support assignment to .full_url. Thinking of this further, the idea of reusing request by assigning to .full_url may not be a good idea, because if you set .full_url to a completely different URL from different host, the request becomes meaningless. Closing this issue as the enhancement is done. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 18:36:45 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 May 2013 16:36:45 +0000 Subject: [issue7727] xmlrpc library returns string which contain null ( \x00 ) In-Reply-To: <1263758368.94.0.169057465263.issue7727@psf.upfronthosting.co.za> Message-ID: <1369413405.51.0.524979486676.issue7727@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updating tests I found some related errors. XML-RPC doesn't work in general case for non UTF-8 encoding: >>> import xmlrpclib >>> xmlrpclib.dumps(('\u20ac',), encoding='iso-8859-1') '\n\n\\u20ac\n\n\n' >>> xmlrpclib.dumps((u'\u20ac',), encoding='iso-8859-1') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/xmlrpclib.py", line 1085, in dumps data = m.dumps(params) File "/usr/lib/python2.7/xmlrpclib.py", line 632, in dumps dump(v, write) File "/usr/lib/python2.7/xmlrpclib.py", line 654, in __dump f(self, value, write) File "/usr/lib/python2.7/xmlrpclib.py", line 700, in dump_unicode value = value.encode(self.encoding) UnicodeEncodeError: 'latin-1' codec can't encode character u'\u20ac' in position 0: ordinal not in range(256) We should use 'xmlcharrefreplace' error handler. Non-ASCII strings is passed as Unicode strings (this should be documented). >>> xmlrpclib.loads(xmlrpclib.dumps(('\xe2\x82\xac',))) ((u'\u20ac',), None) '\r' and '\r\n' are deserialized as '\n'. >>> xmlrpclib.loads(xmlrpclib.dumps(('\r',))) (('\n',), None) >>> xmlrpclib.loads(xmlrpclib.dumps(('\r\n',))) (('\n',), None) ---------- Added file: http://bugs.python.org/file30360/xmlrpc_dump_invalid_string-2.7_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 18:43:17 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 May 2013 16:43:17 +0000 Subject: [issue7727] xmlrpc library returns string which contain null ( \x00 ) In-Reply-To: <1263758368.94.0.169057465263.issue7727@psf.upfronthosting.co.za> Message-ID: <1369413797.67.0.0579661383384.issue7727@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file30339/xmlrpc_dump_invalid_string.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 18:43:58 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 24 May 2013 16:43:58 +0000 Subject: [issue18041] mention issues with code churn in the devguide In-Reply-To: <1369280251.47.0.219323501066.issue18041@psf.upfronthosting.co.za> Message-ID: <1369413838.33.0.0117815574931.issue18041@psf.upfronthosting.co.za> ?ric Araujo added the comment: Moving things around. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 18:44:00 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 May 2013 16:44:00 +0000 Subject: [issue7727] xmlrpc library returns string which contain null ( \x00 ) In-Reply-To: <1263758368.94.0.169057465263.issue7727@psf.upfronthosting.co.za> Message-ID: <1369413840.31.0.0359211592835.issue7727@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file30343/xmlrpc_dump_invalid_string-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 18:46:20 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 24 May 2013 16:46:20 +0000 Subject: [issue18041] mention issues with code churn in the devguide In-Reply-To: <1369280251.47.0.219323501066.issue18041@psf.upfronthosting.co.za> Message-ID: <1369413980.0.0.0487386201501.issue18041@psf.upfronthosting.co.za> ?ric Araujo added the comment: Tshepang is referring to cases where a patch changes one line but affects ten other lines because a paragraph was rewrapped, modernizing code, updating tests to use latest helpers, etc. I?ve actually seen two contrary kinds of advice: do cleanups when you touch the code for a bug fix or new feature (the holistic approach / anti-code churn) vs. separate concerns with separate commits. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 18:57:47 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 24 May 2013 16:57:47 +0000 Subject: [issue18003] lzma module very slow with line-oriented reading. In-Reply-To: <1368829644.15.0.251410244875.issue18003@psf.upfronthosting.co.za> Message-ID: <1369414667.6.0.429152262929.issue18003@psf.upfronthosting.co.za> ?ric Araujo added the comment: A higher-level interface to abstract differences between gzip, xz and others is actually provided in the tarfile module. (zipfile is left out and its file objects have different methods, but that?s another issue. shutil provides even higher-level functions to work on top of tarfile or zipfile.) ---------- nosy: +eric.araujo title: New lzma crazy slow with line-oriented reading. -> lzma module very slow with line-oriented reading. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 18:59:28 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 24 May 2013 16:59:28 +0000 Subject: [issue18000] _md5 should be built if _ssl cannot be built In-Reply-To: <1368818592.85.0.0295311805267.issue18000@psf.upfronthosting.co.za> Message-ID: <1369414768.6.0.012396246434.issue18000@psf.upfronthosting.co.za> ?ric Araujo added the comment: The other bug report classifies the request behavior as a new feature, so it could not go into 2.7. ---------- nosy: +eric.araujo, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 19:40:43 2013 From: report at bugs.python.org (Samuel John) Date: Fri, 24 May 2013 17:40:43 +0000 Subject: [issue18050] _sre.MAXREPEAT not defined in 2.7.3 Message-ID: <1369417243.06.0.993082490408.issue18050@psf.upfronthosting.co.za> New submission from Samuel John: As also discussed at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704084 and https://github.com/mxcl/homebrew/pull/19300, Python 2.7.4 and 2.7.5 seem to have added an `from _sre import MAXREPEAT` to the sre_compile.py, sre_parse.py and sre_constants.py modules. But python 2.7.3 (and older?) don't have the built in MAXREPEAT in _sre. Some virtualenvs have to be updated (which is easy) but some Software (such as vim, shipped with OS X 10.8.3) is statically linked to an older python 2.7.2 (I guess) but somehow picks up my newly built python 2.7.5 and attempts to load it's site.py. (Weechat also reported to being affected) I think this is more a bug of vim/weechat etc. but we at homebrew have to do some "hacky" fix, because Apple is not going to update vim very soon, and so having a newer python in path breaks system stuff. So I am fine if you close this here again. But at least we have a reference or perhaps you guys have a better idea how to work-around. For homebrew, I propose a monkey-patch in re.py to the _sre module if it does not have a MAXREPEAT. try: from _sre import MAXREPEAT except ImportError: import _sre _sre.MAXREPEAT = 65535 # this monkey-patches all other places of "from _sre import MAXREPEAT" ---------- components: Extension Modules, Regular Expressions messages: 189924 nosy: ezio.melotti, mrabarnett, samueljohn priority: normal severity: normal status: open title: _sre.MAXREPEAT not defined in 2.7.3 type: crash versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 21:18:41 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 24 May 2013 19:18:41 +0000 Subject: [issue2053] IDLE - standardize dialogs In-Reply-To: <1202515821.86.0.159216664847.issue2053@psf.upfronthosting.co.za> Message-ID: <1369423121.84.0.834005702429.issue2053@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I have not looked at the details, so cannot currently comment as to whether the idea should be pursued or dropped. Perhaps when Roger is done with overt bugs he will take a look and offer an opinion. ---------- assignee: kbk -> nosy: +roger.serwy versions: +Python 2.7, Python 3.3, Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 21:56:52 2013 From: report at bugs.python.org (Craig McDaniel) Date: Fri, 24 May 2013 19:56:52 +0000 Subject: [issue18051] get_python_version undefined in bdist_rpm.py Message-ID: <1369425412.53.0.375050257963.issue18051@psf.upfronthosting.co.za> New submission from Craig McDaniel: Running "setup.py bdist_rpm" throws an exception on some libraries (e.g. - simplejson) since 2.7.4 due to introduction of get_python_version(): Traceback (most recent call last): File "setup.py", line 103, in run_setup(True) File "setup.py", line 99, in run_setup cmdclass={'build_ext': ve_build_ext}, File "/home/cmcdaniel/src/cpython/Lib/distutils/core.py", line 152, in setup dist.run_commands() File "/home/cmcdaniel/src/cpython/Lib/distutils/dist.py", line 953, in run_commands self.run_command(cmd) File "/home/cmcdaniel/src/cpython/Lib/distutils/dist.py", line 972, in run_command cmd_obj.run() File "build/bdist.linux-i686/egg/setuptools/command/bdist_rpm.py", line 28, in run File "/home/cmcdaniel/src/cpython/Lib/distutils/command/bdist_rpm.py", line 383, in run pyversion = get_python_version() NameError: global name 'get_python_version' is not defined ---------- assignee: eric.araujo components: Distutils files: mywork.patch keywords: patch messages: 189926 nosy: Craig.McDaniel, eric.araujo, tarek priority: normal severity: normal status: open title: get_python_version undefined in bdist_rpm.py versions: Python 2.7 Added file: http://bugs.python.org/file30361/mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 22:04:37 2013 From: report at bugs.python.org (Craig McDaniel) Date: Fri, 24 May 2013 20:04:37 +0000 Subject: [issue18051] get_python_version undefined in bdist_rpm.py In-Reply-To: <1369425412.53.0.375050257963.issue18051@psf.upfronthosting.co.za> Message-ID: <1369425877.61.0.102055254939.issue18051@psf.upfronthosting.co.za> Craig McDaniel added the comment: Closing; duplicate of 18045 ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 22:18:39 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 24 May 2013 20:18:39 +0000 Subject: [issue18009] os.write.__doc__ is misleading In-Reply-To: <1368895469.2.0.802658153503.issue18009@psf.upfronthosting.co.za> Message-ID: <1369426719.66.0.536625588307.issue18009@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 22:23:20 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 24 May 2013 20:23:20 +0000 Subject: [issue17997] ssl.match_hostname(): sub string wildcard should not match IDNA prefix In-Reply-To: <1368799493.86.0.504478450601.issue17997@psf.upfronthosting.co.za> Message-ID: <1369427000.59.0.626985373989.issue17997@psf.upfronthosting.co.za> Martin v. L?wis added the comment: As a policy, the standard library should accept non-ASCII host names ("U-labels") wherever possible. I.e the hostname parameter of match_hostname should allow for U-labels (as well as A-labels). When returning names, it should always return the data "as-is", which typically means A-labels. Anybody wanting to display U-labels will need to decode them explicitly. I believe that the matching of IDNA names doesn't currently happen according to 6.4.2 of RFC 6125, however, this is not actually the issue that Christian reported (which was only about wildcard matching). I suggest to create a separate issue for that. As for 6.4.3: I find the text to be quite ill-formulated. Specifically, I'm referring to the sentence However, the client SHOULD NOT attempt to match a presented identifier where the wildcard character is embedded within an A-label or U-label [IDNA-DEFS] of an internationalized domain name [IDNA-PROTO]. First, in the context of X.509, a wildcard *cannot* be embedded "with an ... U-label"; the certificate can only possibly contain A-labels (because the datatype of dNSName is IA5String). Second, as written, it *does* allow to match 'g?tter.example.de' against "x*.example.de", since "x*.example.de" is not an A-label. An A-label is defined as An "A-label" is the ASCII-Compatible Encoding (ACE, see Section 2.3.2.5) form of an IDNA-valid string. It must be a complete label: IDNA is defined for labels, not for parts of them and not for complete domain names. This means, by definition, that every A-label will begin with the IDNA ACE prefix, "xn--" (see Section 2.3.2.5), followed by a string that is a valid output of the Punycode algorithm [RFC3492] and hence a maximum of 59 ASCII characters in length. The prefix and string together must conform to all requirements for a label that can be stored in the DNS including conformance to the rules for LDH labels (Section 2.3.1). If and only if a string meeting the above requirements can be decoded into a U-label is it an A-label. Since an A-label is required to conform to the LDH label syntax, it cannot possibly contain the asterisk (LDH labels can only contain letters, digits, and the hyphen. Hence, the entire requirement is irrelevant (as literally written). They might mean something else, but I cannot guess what it is that they mean. I disagree with the classification of this issue as critical. It does not involve a crash, a serious regression, or a breakage of a very important API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 22:35:39 2013 From: report at bugs.python.org (A.M. Kuchling) Date: Fri, 24 May 2013 20:35:39 +0000 Subject: [issue1554133] PyOS_InputHook() and related API funcs. not documented Message-ID: <1369427739.26.0.218963704767.issue1554133@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Here's a proposed patch to the c-api manual that describes these two pointers. I put them in the 'very high-level API' section. Maybe they belong in the Operating System Utilities section instead, but I think they're intertwined with the interpreter loop and therefore belong in the 'very high-level' section. ---------- Added file: http://bugs.python.org/file30362/inputhook.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 22:46:40 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 24 May 2013 20:46:40 +0000 Subject: [issue1554133] PyOS_InputHook() and related API funcs. not documented Message-ID: <1369428400.36.0.19195166407.issue1554133@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I am not a C-api user, but the entries are pretty clear to me and seem ready to apply. The usage examples are a nice touch. OS Utilites is not where I would expect interpreter loop hooks, so I think the current location is better. ---------- stage: -> commit review versions: +Python 3.4 -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 23:00:25 2013 From: report at bugs.python.org (Ned Deily) Date: Fri, 24 May 2013 21:00:25 +0000 Subject: [issue2053] IDLE - standardize dialogs In-Reply-To: <1202515821.86.0.159216664847.issue2053@psf.upfronthosting.co.za> Message-ID: <1369429225.44.0.313955329157.issue2053@psf.upfronthosting.co.za> Ned Deily added the comment: Attached is a refreshed version of the patch against current 2.7 tip. I did a quick visual comparison with the original but make no guarantees that it is totally accurate. I have no plans to work on it further myself. ---------- nosy: +ned.deily Added file: http://bugs.python.org/file30363/IDLE_standardize_dialogs_2.7_2013-05-24.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 23:10:14 2013 From: report at bugs.python.org (Alex Burka) Date: Fri, 24 May 2013 21:10:14 +0000 Subject: [issue18050] _sre.MAXREPEAT not defined in 2.7.3 In-Reply-To: <1369417243.06.0.993082490408.issue18050@psf.upfronthosting.co.za> Message-ID: <1369429814.11.0.986401210666.issue18050@psf.upfronthosting.co.za> Changes by Alex Burka : ---------- nosy: +Alex.Burka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 23:20:22 2013 From: report at bugs.python.org (A.M. Kuchling) Date: Fri, 24 May 2013 21:20:22 +0000 Subject: [issue1554133] PyOS_InputHook() and related API funcs. not documented Message-ID: <1369430422.56.0.868632603267.issue1554133@psf.upfronthosting.co.za> A.M. Kuchling added the comment: One question about the patch: how to give the prototype expected for the function? I currently have it as: char *(*PyOS_ReadlineFunctionPointer)(FILE *stdin, FILE *stdout, char *prompt) Would it be better with a trivial function name, as in: char *func(FILE *stdin, FILE *stdout, char *prompt) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 23:31:47 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 May 2013 21:31:47 +0000 Subject: [issue17953] sys.modules cannot be reassigned In-Reply-To: <1368260613.85.0.746522318662.issue17953@psf.upfronthosting.co.za> Message-ID: <3bHLPZ2QbbzQk3@mail.python.org> Roundup Robot added the comment: New changeset 4f8160e45cb7 by Brett Cannon in branch '3.3': Issue #17953: document that sys.modules shouldn't be replaced (thanks http://hg.python.org/cpython/rev/4f8160e45cb7 New changeset b60ae4ebf981 by Brett Cannon in branch 'default': merge fix for issue #17953 http://hg.python.org/cpython/rev/b60ae4ebf981 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 23:33:08 2013 From: report at bugs.python.org (Brett Cannon) Date: Fri, 24 May 2013 21:33:08 +0000 Subject: [issue17953] sys.modules cannot be reassigned In-Reply-To: <1368260613.85.0.746522318662.issue17953@psf.upfronthosting.co.za> Message-ID: <1369431188.28.0.950708494299.issue17953@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks for the patch, Yogesh, but I went with different wording that I came up with on the train the other day while offline. But you did remind me to update Misc/NEWS (which led to a discussion on python-committers), so thanks for that. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 24 23:36:19 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 May 2013 21:36:19 +0000 Subject: [issue18009] os.write.__doc__ is misleading In-Reply-To: <1368895469.2.0.802658153503.issue18009@psf.upfronthosting.co.za> Message-ID: <3bHLVq1sMtz7Lk2@mail.python.org> Roundup Robot added the comment: New changeset 7935844c6737 by Benjamin Peterson in branch '3.3': indicate that read/write work with bytes (closes #18009) http://hg.python.org/cpython/rev/7935844c6737 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 00:08:38 2013 From: report at bugs.python.org (Ned Deily) Date: Fri, 24 May 2013 22:08:38 +0000 Subject: [issue18050] _sre.MAXREPEAT not defined in 2.7.3 In-Reply-To: <1369417243.06.0.993082490408.issue18050@psf.upfronthosting.co.za> Message-ID: <1369433318.89.0.387625561707.issue18050@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 00:27:32 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 24 May 2013 22:27:32 +0000 Subject: [issue1554133] PyOS_InputHook() and related API funcs. not documented Message-ID: <1369434452.51.0.831788782743.issue1554133@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Can one of you three answer Kuchling's question about formatting a data entry that consists of a function pointer with function signature? ---------- nosy: +eric.araujo, ezio.melotti, georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 01:21:33 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 24 May 2013 23:21:33 +0000 Subject: [issue18052] IDLE 3.3.2 Windows taskbar icon regression Message-ID: <1369437693.91.0.216380064498.issue18052@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Windows 7 (32 bit?), 32 bit IDLE 3.3.2: When I start from the start menu, the taskbar icon is the red Tk icon instead of the IDLE icon. If I try to pin the Tk icon to the task bar, a useless pythonw icon is pinned instead. The Tk icon goes when the program is closed. After multiple open and frequent program deletions, Idle shows up on the Start/frequent programs list with it normal Idle icon (White page + snake). (I had 3.3.1 before working fine. The 3.3.2 upgrade did not work (tkinter would not import, so I redownloaded, deleted Python 3.3.2, and reinstalled, getting the behavior above.) I have seen the Tk icon before after fresh installs, but on other machines, and it was replaced after the first open with the correct icon. ---------- components: IDLE, Installation, Windows messages: 189937 nosy: loewis, roger.serwy, terry.reedy priority: normal severity: normal stage: needs patch status: open title: IDLE 3.3.2 Windows taskbar icon regression versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 03:13:08 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sat, 25 May 2013 01:13:08 +0000 Subject: [issue17953] sys.modules cannot be reassigned In-Reply-To: <1368260613.85.0.746522318662.issue17953@psf.upfronthosting.co.za> Message-ID: <1369444388.26.0.789853034483.issue17953@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: You are most welcome Brett. I am just starting to contribute with this doc fix. Didn't think a small detail in it will generate such a long debate in the python-committers mailing list. Is there a plan in action for 'fixing' Misc/NEWS. I now realize that this change is too small to warrant an entry there, however, as someone new to the list, I simply followed http://docs.python.org/devguide/patch.html. Doing a make patchcheck warns about no changes to Misc/NEWS. IMHO it would be great if this tool can look at the files changed (or maybe at-least just the directory, or even, simply number of lines modified) and decide if an entry is required in Misc/News. Of-course this is from my perspective. I would like to get your view on this and help about the solution if possible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 05:07:55 2013 From: report at bugs.python.org (R. David Murray) Date: Sat, 25 May 2013 03:07:55 +0000 Subject: [issue17953] sys.modules cannot be reassigned In-Reply-To: <1368260613.85.0.746522318662.issue17953@psf.upfronthosting.co.za> Message-ID: <1369451275.32.0.779140817632.issue17953@psf.upfronthosting.co.za> R. David Murray added the comment: I think that is a reasonable suggestion for an enhancement to patchcheck (though I think Brett had a good reason to add a news entry in this particular case). You could open a new issue with that suggestion. On the other hand, patchcheck always warns about other stuff that it can't so easily realize aren't really needed, so it may not be considered a worthwhile enhancement. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 05:32:18 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sat, 25 May 2013 03:32:18 +0000 Subject: [issue17953] sys.modules cannot be reassigned In-Reply-To: <1368260613.85.0.746522318662.issue17953@psf.upfronthosting.co.za> Message-ID: <1369452738.28.0.399078808428.issue17953@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: That sounds good. I will open up an issue (if not for anything else other than to get more eyes on this issue) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 05:43:37 2013 From: report at bugs.python.org (Renato Silva) Date: Sat, 25 May 2013 03:43:37 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za> Message-ID: <1369453417.74.0.560003324497.issue12641@psf.upfronthosting.co.za> Renato Silva added the comment: > MinGW has never "supported" the -mno-cygwin option. It has simply > tolerated it. The option never did anything useful and at some point > it became an error to even supply it. I'm not sure exactly when but > some time after 4.4 sounds reasonable to me. Hi Oscar! Sorry, I just meant to correct this information: "in gcc 4.x it produces an error preventing build". Even if it doesn't do anything useful, still GCC 4.4 does accept that option normally. If MinGW didn't touch anything relevant, then what Cygwin folks said about 4.x [1] clearly did not come to reality. > No the developer does not confirm that the -mno-cygin option is > required for MinGW. Not for MinGW, but for building Pidgin. I have just checked it, and -mno-cygwin actually is no longer necessary since 2.10.7 [1], but it was at the time of that message. Even though it didn't do anything meaningful, a GCC like 4.6 would cause build to fail. > Also from what I've seen I would say that the error message that > the OP shows there comes from Cygwin's gcc not MinGW. No, you can use either Cygwin or MinGW MSYS as environment, but the compiler must be MinGW [2]. [1] https://hg.pidgin.im/pidgin/main/rev/c959cde2a7bd [2] https://developer.pidgin.im/wiki/BuildingWinPidgin#Setupyourbuildenvironment ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 05:46:40 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sat, 25 May 2013 03:46:40 +0000 Subject: [issue18053] Add checks for Misc/NEWS in make patchcheck Message-ID: <1369453600.75.0.470507945427.issue18053@psf.upfronthosting.co.za> New submission from Yogesh Chaudhari: Based on the threads about http://mail.python.org/pipermail/python-committers/2013-May/002529.html and discussion on http://bugs.python.org/issue17953; It would be good to add some (very high level)checks inside patchcheck that will tell the user if Misc/NEWS needs to be updated for the patch created. As of now the patchcheck utility adds a notice to modify Misc/NEWS for every patch. IMO this notice should be based on some simple checks. eg: number of lines modified and/or directories changed (that might give a clue about ignoring minor changes in documentation and considering changes in Python core or major changes in Libs etc) based on which make patchcheck should generate warnings for changing Misc/NEWS. ---------- messages: 189942 nosy: Yogesh.Chaudhari priority: normal severity: normal status: open title: Add checks for Misc/NEWS in make patchcheck _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 05:50:06 2013 From: report at bugs.python.org (Renato Silva) Date: Sat, 25 May 2013 03:50:06 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za> Message-ID: <1369453806.89.0.841306916531.issue12641@psf.upfronthosting.co.za> Renato Silva added the comment: ERRATA. Where you see: "[1] clearly did not come to reality." Please read: "[0] clearly did not come to reality." [0] http://cygwin.com/ml/cygwin/2009-03/msg00802.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 05:58:14 2013 From: report at bugs.python.org (Yogesh Chaudhari) Date: Sat, 25 May 2013 03:58:14 +0000 Subject: [issue18053] Add checks for Misc/NEWS in make patchcheck In-Reply-To: <1369453600.75.0.470507945427.issue18053@psf.upfronthosting.co.za> Message-ID: <1369454294.49.0.210528202066.issue18053@psf.upfronthosting.co.za> Yogesh Chaudhari added the comment: I am not sure which component patchcheck corresponds to, so I have left that out and added people on nosy list in http://bugs.python.org/issue17953. If I have missed the concerned maintainer, kindly let me know. ---------- nosy: +brett.cannon, pitrou, r.david.murray, terry.reedy versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 08:55:59 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 May 2013 06:55:59 +0000 Subject: [issue18054] Add more exception related assertions to unittest Message-ID: <1369464959.25.0.285327189549.issue18054@psf.upfronthosting.co.za> New submission from Nick Coghlan: When creating the error handling tests for the new ipaddress module, one of the things I added was an "assertCleanError" method on the test cases [1]. This is a wrapper around assertRaisesRegex which ensures that either no exception context is set, or if there is one set, ensures that the display is suppressed by default. While I don't think assertCleanError itself is suitable for adoption (there are two many use case specific details), I think it *would* be useful to provide two related helper assertions along the lines of the following (the failure message in the first case could likely be improved). Firstly, ensuring that the context has been *suppressed* when it should have been: def assertCleanTraceback(self, exc, msg=None): exc_context = exc.__context__ if exc_context is not None and not exc.__suppress_context__: if msg is None: fmt = "{} has context set: {}" msg = fmt.format(type(exc), type(exc_context)) self.fail(msg) return exc_context and secondly ensuring that the cause has been *set* when it should have been: def assertRaisedFrom(self, exc, expected_cause, expected_regex, msg=None): exc_cause = exc.__cause__ # Use the guts of assertRaises to compare the actual cause # and the expected cause and raise an appropriate failure # if they don't match return exc_cause Both proposed helpers return the actual context/cause so they can be used to test longer deliberate exception chaings. [1] http://hg.python.org/cpython/file/04ca3f1515cf/Lib/test/test_ipaddress.py#l37 ---------- messages: 189945 nosy: michael.foord, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Add more exception related assertions to unittest type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 10:53:36 2013 From: report at bugs.python.org (Roumen Petrov) Date: Sat, 25 May 2013 08:53:36 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: Message-ID: <51A07C0E.8080808@roumenpetrov.info> Roumen Petrov added the comment: Oscar Benjamin wrote: > [SNIP]The option was only ever meaningful in cygwin's gcc 3.x and was > always an error in 4.x. May be . It seems to me flag was removed in GCC 4.5 . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 10:59:52 2013 From: report at bugs.python.org (Seppo Yli-Olli) Date: Sat, 25 May 2013 08:59:52 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za> Message-ID: <1369472392.67.0.438657598545.issue12641@psf.upfronthosting.co.za> Seppo Yli-Olli added the comment: Since Renata's ERRATA was unclear to whether or not this was *actually* removed (please point to a changeset if the option was removed): If the option is no longer required by Pidgin and that was the original reason to have it in the first, there's really no reason *not* to remove this, no? Eg this code > int main() { return 0; } Fails to compile on MingW gcc 4.6 and 4.7 when passing -mno-cygwin to gcc. The solution that distutils does not work with current versions of MingW (and GCC) for good is unacceptable so the only working solution is removal of no-cygwin. Just that GCC 4.4 would support the flag does not change this bug one way or the other. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 11:09:12 2013 From: report at bugs.python.org (Phil Connell) Date: Sat, 25 May 2013 09:09:12 +0000 Subject: [issue18032] set methods should specify whether they consume iterators "lazily" In-Reply-To: <1369223923.83.0.620034016791.issue18032@psf.upfronthosting.co.za> Message-ID: <1369472952.2.0.67027898668.issue18032@psf.upfronthosting.co.za> Changes by Phil Connell : ---------- nosy: +pconnell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 11:10:12 2013 From: report at bugs.python.org (Phil Connell) Date: Sat, 25 May 2013 09:10:12 +0000 Subject: [issue18033] Example for Profile Module shows incorrect method In-Reply-To: <1369235558.14.0.532987051887.issue18033@psf.upfronthosting.co.za> Message-ID: <1369473012.01.0.731070218697.issue18033@psf.upfronthosting.co.za> Changes by Phil Connell : ---------- nosy: +pconnell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 11:27:36 2013 From: report at bugs.python.org (Phil Connell) Date: Sat, 25 May 2013 09:27:36 +0000 Subject: [issue18035] telnetlib incorrectly assumes that select.error has an errno attribute In-Reply-To: <1369244217.55.0.122247989262.issue18035@psf.upfronthosting.co.za> Message-ID: <1369474056.43.0.629486316664.issue18035@psf.upfronthosting.co.za> Changes by Phil Connell : ---------- nosy: +pconnell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 11:28:08 2013 From: report at bugs.python.org (Phil Connell) Date: Sat, 25 May 2013 09:28:08 +0000 Subject: [issue18036] "How do I create a .pyc file?" FAQ entry is out of date In-Reply-To: <1369244271.04.0.495588356743.issue18036@psf.upfronthosting.co.za> Message-ID: <1369474088.83.0.228066356765.issue18036@psf.upfronthosting.co.za> Changes by Phil Connell : ---------- nosy: +pconnell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 11:31:07 2013 From: report at bugs.python.org (Phil Connell) Date: Sat, 25 May 2013 09:31:07 +0000 Subject: [issue18042] Provide enum.unique class decorator In-Reply-To: <1369299378.37.0.789518154232.issue18042@psf.upfronthosting.co.za> Message-ID: <1369474267.53.0.40354555755.issue18042@psf.upfronthosting.co.za> Changes by Phil Connell : ---------- nosy: +pconnell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 11:31:38 2013 From: report at bugs.python.org (Phil Connell) Date: Sat, 25 May 2013 09:31:38 +0000 Subject: [issue18043] No mention of `match.regs` in `re` documentation In-Reply-To: <1369308537.81.0.515783227267.issue18043@psf.upfronthosting.co.za> Message-ID: <1369474298.54.0.552579596847.issue18043@psf.upfronthosting.co.za> Changes by Phil Connell : ---------- nosy: +pconnell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 11:33:46 2013 From: report at bugs.python.org (Phil Connell) Date: Sat, 25 May 2013 09:33:46 +0000 Subject: [issue18047] Descriptors get invoked in old-style objects and classes In-Reply-To: <1369373983.58.0.00587959802813.issue18047@psf.upfronthosting.co.za> Message-ID: <1369474426.92.0.98907521486.issue18047@psf.upfronthosting.co.za> Changes by Phil Connell : ---------- nosy: +pconnell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 12:20:41 2013 From: report at bugs.python.org (Seppo Yli-Olli) Date: Sat, 25 May 2013 10:20:41 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za> Message-ID: <1369477241.49.0.22142244429.issue12641@psf.upfronthosting.co.za> Seppo Yli-Olli added the comment: ERRATA Misunderstood the meaning of ERRATA, please ignore my last post. Roumen Petrov wrote: > Where is written that compiler is gcc ? Yes this is current distutils > code but please review my set of patches I kinda like the using --target-help for finding out if -mno-cygwin is supported assuming --target-help is supported by all GCC's. I disliked the version-based approach since back from 2011 since it seems fragile to me. I'm noo sure if it falls into the category of lightweight checks Eric asked for in #msg146499 but at least more lightweight than my proposal of trying to compile a sample program with the compiler. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 12:20:50 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 May 2013 10:20:50 +0000 Subject: [issue18046] Simplify and clarify logging internals In-Reply-To: <1369356875.31.0.0932169954685.issue18046@psf.upfronthosting.co.za> Message-ID: <3bHgSx4w1Mz7LkM@mail.python.org> Roundup Robot added the comment: New changeset 5629bf4c6bba by Vinay Sajip in branch 'default': Closes #18046: Simplified logging internals relating to levels and their names. Thanks to Alex Gaynor for the patch. http://hg.python.org/cpython/rev/5629bf4c6bba ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 12:42:29 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 25 May 2013 10:42:29 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368028726.5.0.833825784859.issue17936@psf.upfronthosting.co.za> Message-ID: <1369478549.68.0.159737594061.issue17936@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Here is another approach to make tp_subclasses a dict, rather than a list. I'll let you benchmark and choose whichever you prefer :) ---------- nosy: +gvanrossum, rhettinger Added file: http://bugs.python.org/file30364/subclasses_dict.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 12:50:29 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 25 May 2013 10:50:29 +0000 Subject: [issue17997] ssl.match_hostname(): sub string wildcard should not match IDNA prefix In-Reply-To: <1368799493.86.0.504478450601.issue17997@psf.upfronthosting.co.za> Message-ID: <1369479029.29.0.41729745207.issue17997@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- priority: critical -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 12:56:11 2013 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sat, 25 May 2013 10:56:11 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368028726.5.0.833825784859.issue17936@psf.upfronthosting.co.za> Message-ID: <1369479371.53.0.531800415852.issue17936@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Looks good, I'll give it a spin. This is probably smarter then trying to do tricks with lists. One question: I saw you clearing exceptions in the tp_clear() function, isn't it better to use PyErr_PrintUnraisable()? Is there a guideline to when to use that one in internal code? When is it safe to just shrug and ignore? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 12:57:18 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 25 May 2013 10:57:18 +0000 Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za> Message-ID: <1369479438.38.0.668022017361.issue8240@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > As for partial writes, I'm not sure if it's backwards compatible to > turn them on by default, but it might be nice if the option were > exposed. Partial writes may have less benefit in Python than in C > since we'd have to reallocate and copy a string instead of just moving > a pointer. You can slice a memoryview() to avoid a copy. But I'm not sure of the point of partial writes here: can't you just send slices that are small enough (e.g. 4KB each)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 12:58:04 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 25 May 2013 10:58:04 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1369479371.53.0.531800415852.issue17936@psf.upfronthosting.co.za> Message-ID: <1369479476.2562.0.camel@fsol> Antoine Pitrou added the comment: > One question: I saw you clearing exceptions in the tp_clear() > function, isn't it better to use PyErr_PrintUnraisable()? You're right, that would be better. I was just being lazy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 13:02:41 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 May 2013 11:02:41 +0000 Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za> Message-ID: <3bHhPD1kLQz7LkY@mail.python.org> Roundup Robot added the comment: New changeset 60310223d075 by Antoine Pitrou in branch 'default': Issue #8240: Set the SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER flag on SSL sockets. http://hg.python.org/cpython/rev/60310223d075 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 13:09:59 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 25 May 2013 11:09:59 +0000 Subject: [issue8240] ssl.SSLSocket.write may fail on non-blocking sockets In-Reply-To: <1269617434.76.0.650979265578.issue8240@psf.upfronthosting.co.za> Message-ID: <1369480199.73.0.362051435111.issue8240@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, I should have fixed the original issue. If you want to see an option to enable partial writes, please open a separate issue. ---------- resolution: -> fixed stage: needs patch -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 13:43:05 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 25 May 2013 11:43:05 +0000 Subject: [issue7940] re.finditer and re.findall should support negative end positions In-Reply-To: <1266329075.25.0.639780854585.issue7940@psf.upfronthosting.co.za> Message-ID: <1369482185.1.0.475140128473.issue7940@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- components: +Library (Lib) stage: test needed -> needs patch versions: +Python 3.4 -Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 14:27:32 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 May 2013 12:27:32 +0000 Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular encoding In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za> Message-ID: <3bHkH80Yx1z7Ljq@mail.python.org> Roundup Robot added the comment: New changeset f7b47fb30169 by Eli Bendersky in branch '3.3': Issue #13612: handle unknown encodings without a buffer overflow. http://hg.python.org/cpython/rev/f7b47fb30169 New changeset 47e719b11c46 by Eli Bendersky in branch 'default': Issue #13612: handle unknown encodings without a buffer overflow. http://hg.python.org/cpython/rev/47e719b11c46 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 14:32:56 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 25 May 2013 12:32:56 +0000 Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular encoding In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za> Message-ID: <1369485176.59.0.851797433132.issue13612@psf.upfronthosting.co.za> Eli Bendersky added the comment: A few notes: 1. If by C API version you mean PyExpat_CAPI_MAGIC, I'm not sure what difference that makes. It has never been updated and it's also being used only in _elementtree. Since the latter is statically compiled against pyexpat, I don't see a reason to touch it. 2. I wouldn't backport it to 2.7; again, not critical enough. 3. Should we open a separate issue for adding support to GBK and similar encodings "sometime in the future"? This issue kind-of got derailed to fix the bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 14:54:48 2013 From: report at bugs.python.org (Oscar Benjamin) Date: Sat, 25 May 2013 12:54:48 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: <1369453417.74.0.560003324497.issue12641@psf.upfronthosting.co.za> Message-ID: Oscar Benjamin added the comment: On 25 May 2013 04:43, Renato Silva wrote: > > Renato Silva added the comment: > > Hi Oscar! Sorry, I just meant to correct this information: "in gcc 4.x it produces an error preventing build". Even if it doesn't do anything useful, still GCC 4.4 does accept that option normally. If MinGW didn't touch anything relevant, then what Cygwin folks said about 4.x [1] clearly did not come to reality. In context it should be clear that the statement "in gcc 4.x it produces an error preventing build" refers to Cygwin's gcc and not MinGW's. Which gcc are you referring to? >> No the developer does not confirm that the -mno-cygin option is >> required for MinGW. > > Not for MinGW, but for building Pidgin. I have just checked it, and -mno-cygwin actually is no longer necessary since 2.10.7 [1], but it was at the time of that message. Even though it didn't do anything meaningful, a GCC like 4.6 would cause build to fail. Yes gcc 4.6 would fail because it won't accept the -mno-cygwin option. That does not mean that any other MinGW gcc ever *required* the -mno-cygwin option for anything. The MinGW devs have repeatedly and explicitly stated that the -mno-cygwin option never did anything useful when used with MinGW: http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42097 http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42101 http://permalink.gmane.org/gmane.comp.gnu.mingw.user/42104 >> Also from what I've seen I would say that the error message that >> the OP shows there comes from Cygwin's gcc not MinGW. > > No, you can use either Cygwin or MinGW MSYS as environment, but the compiler must be MinGW [2]. Yes but that particular error message is coming from Cygwin's gcc not MinGW. As stated by the Pidgin dev in that message the OP does not know which compiler they are using: http://pidgin.im/pipermail/support/2011-December/011159.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 15:16:23 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 25 May 2013 13:16:23 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1368028726.5.0.833825784859.issue17936@psf.upfronthosting.co.za> Message-ID: <1369487783.17.0.431818653534.issue17936@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Note that making tp_subclasses a dict makes the __subclasses__ return order undefined. I don't think I've ever seen __subclasses__ actually used, so I'm not convinced it's a problem, but perhaps it's worth floating the idea on python-dev. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 15:44:25 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 May 2013 13:44:25 +0000 Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular encoding In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za> Message-ID: <1369489465.55.0.674920695677.issue13612@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Tests were duplicated. There is no Misc/NEWS entry. I think a buffer overflow is critical enough for backporting. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 16:18:49 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 25 May 2013 14:18:49 +0000 Subject: [issue13612] xml.etree.ElementTree says unknown encoding of a regular encoding In-Reply-To: <1324026251.51.0.0968835446575.issue13612@psf.upfronthosting.co.za> Message-ID: <1369491529.91.0.938462361366.issue13612@psf.upfronthosting.co.za> Eli Bendersky added the comment: Oh, I didn't notice that your patches had duplication in the tests. Fixed now. I'll wait to see what unfolds for the Misc/NEWS discussion on python-committers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 16:30:42 2013 From: report at bugs.python.org (Roumen Petrov) Date: Sat, 25 May 2013 14:30:42 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: Message-ID: <51A0CB11.3060301@roumenpetrov.info> Roumen Petrov added the comment: Oscar, 10x for info I know how to find information for this particular case . So you last post just confrim what I wrote before two years ( 2011-08-03 http://bugs.python.org/issue12641#msg141614 ) Go ahead and just remove flag. Roumen ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 16:43:04 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 May 2013 14:43:04 +0000 Subject: [issue1747670] Limiting data copy in xmlrpclib Message-ID: <1369492984.91.0.332323351073.issue1747670@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Do you have any benchmarks? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 16:51:11 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 May 2013 14:51:11 +0000 Subject: [issue11084] Serialization of decimal.Decimal to XML-RPC In-Reply-To: <1296502651.44.0.847909816314.issue11084@psf.upfronthosting.co.za> Message-ID: <1369493471.98.0.335127228468.issue11084@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 17:08:14 2013 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Sat, 25 May 2013 15:08:14 +0000 Subject: [issue16832] Expose cache validity checking support in ABCMeta In-Reply-To: <1357011504.56.0.782130595735.issue16832@psf.upfronthosting.co.za> Message-ID: <1369494494.15.0.954003417306.issue16832@psf.upfronthosting.co.za> ?ukasz Langa added the comment: This will be useful for PEP 443. >From Nick's comment on python-dev (http://mail.python.org/pipermail/python-dev/2013-May/126535.html): "Given the global nature of the cache invalidation, it may be better as a module level abc.get_cache_token() function." ---------- assignee: -> lukasz.langa nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 17:16:12 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 25 May 2013 15:16:12 +0000 Subject: [issue18053] Add checks for Misc/NEWS in make patchcheck In-Reply-To: <1369453600.75.0.470507945427.issue18053@psf.upfronthosting.co.za> Message-ID: <1369494972.31.0.0482228855494.issue18053@psf.upfronthosting.co.za> Brett Cannon added the comment: There isn't really a maintainer. I originally wrote it to help out new developers, but no one owns it. We just let people submit fixes they find useful and add them. ---------- components: +Demos and Tools versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 17:27:04 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 25 May 2013 15:27:04 +0000 Subject: [issue16832] Expose cache validity checking support in ABCMeta In-Reply-To: <1357011504.56.0.782130595735.issue16832@psf.upfronthosting.co.za> Message-ID: <1369495624.48.0.95182797253.issue16832@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Rather than exposing the "cache token" (which looks like an implementation detail), you may allow third-party code to register a handler which will be called when an ABC's registrations are modified: def abc_handler(abc): """ Called when the concrete class registrations for ABC `abc` are updated. """ or even: def abc_handler(abc, added, removed): """ Called when the concrete class registrations for ABC `abc` are updated. `added` is an iterable of concrete classes which have been registered on the ABC, `removed` is an iterable of concrete classes which have been unregistered. """ ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 17:36:10 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 25 May 2013 15:36:10 +0000 Subject: [issue17314] Stop using imp.find_module() in multiprocessing In-Reply-To: <1361994994.99.0.625564916049.issue17314@psf.upfronthosting.co.za> Message-ID: <1369496170.6.0.434489745172.issue17314@psf.upfronthosting.co.za> Brett Cannon added the comment: So I think I have come up with a way to expose a new method that makes this use-case doable and in a sane manner. Richard, let me know what you think so that I know that this makes sense before I commit myself to the new method (init_module_attrs()):: --- a/Lib/multiprocessing/forking.py Fri May 24 13:51:21 2013 +0200 +++ b/Lib/multiprocessing/forking.py Fri May 24 08:06:17 2013 -0400 @@ -449,7 +449,7 @@ elif main_name != 'ipython': # Main modules not actually called __main__.py may # contain additional code that should still be executed - import imp + import importlib if main_path is None: dirs = None @@ -460,16 +460,17 @@ assert main_name not in sys.modules, main_name sys.modules.pop('__mp_main__', None) - file, path_name, etc = imp.find_module(main_name, dirs) + # We should not try to load __main__ + # since that would execute 'if __name__ == "__main__"' + # clauses, potentially causing a psuedo fork bomb. + loader = importlib.find_loader(main_name, path=dirs) + main_module = imp.new_module(main_name) try: - # We should not do 'imp.load_module("__main__", ...)' - # since that would execute 'if __name__ == "__main__"' - # clauses, potentially causing a psuedo fork bomb. - main_module = imp.load_module( - '__mp_main__', file, path_name, etc - ) - finally: - if file: - file.close() + loader.init_module_attrs(main_module) + except AttributeError: + pass + main_module.__name__ = '__mp_main__' + code = loader.get_code(main_name) + exec(code, main_module.__dict__) sys.modules['__main__'] = sys.modules['__mp_main__'] = main_module ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 17:39:08 2013 From: report at bugs.python.org (Jakub Wilk) Date: Sat, 25 May 2013 15:39:08 +0000 Subject: [issue1054041] Python doesn't exit with proper resultcode on SIGINT Message-ID: <1369496348.85.0.830781842795.issue1054041@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 17:40:14 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 25 May 2013 15:40:14 +0000 Subject: [issue18055] Stop using imp in IDLE Message-ID: <1369496414.51.0.562875229152.issue18055@psf.upfronthosting.co.za> New submission from Brett Cannon: As part of issue #14797 I'm trying to remove all uses of imp.find_module/load_module since the API is so bad in the face of importers. See the attached patch to replace the one use in IDLE. It should actually be more accepting of alternative importers than the original code. Since I'm not an IDLE user I'm not comfortable with committing w/o an IDLE dev signing off on it, so please let me know if I can commit it (I would only bother in 3.4 unless you really want it in the 3.3 branch). ---------- components: IDLE files: imp_removed_from_idle.diff keywords: patch messages: 189968 nosy: brett.cannon priority: normal severity: normal stage: commit review status: open title: Stop using imp in IDLE type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file30365/imp_removed_from_idle.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 17:40:26 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 25 May 2013 15:40:26 +0000 Subject: [issue14797] Deprecate imp.find_module()/load_module() In-Reply-To: <1336926729.01.0.715234386918.issue14797@psf.upfronthosting.co.za> Message-ID: <1369496426.55.0.761127867152.issue14797@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- dependencies: +Stop using imp in IDLE _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 17:42:51 2013 From: report at bugs.python.org (Jakub Wilk) Date: Sat, 25 May 2013 15:42:51 +0000 Subject: [issue18020] html.escape 10x slower than cgi.escape In-Reply-To: <1369038098.34.0.795942514317.issue18020@psf.upfronthosting.co.za> Message-ID: <1369496571.06.0.381082858715.issue18020@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 17:45:51 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 25 May 2013 15:45:51 +0000 Subject: [issue18056] Document importlib._bootstrap.NamespaceLoader Message-ID: <1369496751.81.0.344197180241.issue18056@psf.upfronthosting.co.za> New submission from Brett Cannon: Is there a reason NamespaceLoader is undocumented? ---------- assignee: barry components: Documentation keywords: 3.3regression messages: 189969 nosy: barry, brett.cannon, eric.smith priority: normal severity: normal stage: needs patch status: open title: Document importlib._bootstrap.NamespaceLoader versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 17:46:50 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 25 May 2013 15:46:50 +0000 Subject: [issue18057] Register NamespaceLoader with importlib.abc.Loader Message-ID: <1369496810.62.0.455394595935.issue18057@psf.upfronthosting.co.za> New submission from Brett Cannon: ---------- assignee: brett.cannon components: Library (Lib) messages: 189970 nosy: barry, brett.cannon, eric.smith priority: normal severity: normal stage: needs patch status: open title: Register NamespaceLoader with importlib.abc.Loader type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 17:48:15 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 May 2013 15:48:15 +0000 Subject: [issue7727] xmlrpc library returns string which contain null ( \x00 ) In-Reply-To: <1263758368.94.0.169057465263.issue7727@psf.upfronthosting.co.za> Message-ID: <1369496895.8.0.983049506229.issue7727@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +effbot _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 17:48:32 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 May 2013 15:48:32 +0000 Subject: [issue16832] Expose cache validity checking support in ABCMeta In-Reply-To: <1357011504.56.0.782130595735.issue16832@psf.upfronthosting.co.za> Message-ID: <1369496912.02.0.854233733047.issue16832@psf.upfronthosting.co.za> Nick Coghlan added the comment: I thought about that originally, but there's only ever one object graph for the process, and as soon as you break any one edge in that graph you pretty much invalidate anything based on caching traversal results. (More accurately: it's almost always going to be cheaper to blow away and rebuild your cache than it is to determine whether or not your cache was actually affected by the graph change, particularly given the fact that object graph changes will almost always happen while the caches are still cold during application startup). So it's not really an implementation detail, it's a promise to provide a unique token for the current state of the object graph that can be used reliably for cache invalidation. Thus, I favour exposing a cache token as the simplest thing that could possibly work - building a mechanism for "tell me when the object graph changes" is a complex solution when the only question we need to answer is "is my cache still valid?". So the recommended idiom with this design would be: new_token = abc.get_cache_token() if new_token != cached_token: cache.clear() cached_token = new_token else: # Do something with the cache # Handle a cache miss A callback based system is actually *harder* to use, because you can't simply ask the question "Is my cache still valid?" - you have to register a callback that sets a flag, or something similar. Your lookup code ends up being: if cache_invalidated: cache.clear() cache_invalidated = False else: # Do something with the cache # Handle a cache miss However, now you have a potential problem, because your state update (setting the flag) is decoupled from checking the flag. That makes it harder to ensure correct sequencing than is the case with a simple inline check of a cache validity token. Choosing a solution that is harder to implement and harder to use is definitely not a good idea :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 17:48:43 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 25 May 2013 15:48:43 +0000 Subject: [issue18058] Define is_package for NamespaceLoader Message-ID: <1369496923.18.0.904476367209.issue18058@psf.upfronthosting.co.za> New submission from Brett Cannon: Is there a reason that is_package() is not defined for NamespaceLoader? If it's just an oversight then adding it would let -m would work with namespace packages. The other abstract methods on InspectLoader can also be implemented or raise ImportError as appropriate. Just assign to me if you are okay with seeing this happen. ---------- assignee: barry components: Library (Lib) messages: 189972 nosy: barry, brett.cannon, eric.smith priority: normal severity: normal stage: test needed status: open title: Define is_package for NamespaceLoader type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 17:49:35 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 May 2013 15:49:35 +0000 Subject: [issue16832] Expose cache validity checking support in ABCMeta In-Reply-To: <1357011504.56.0.782130595735.issue16832@psf.upfronthosting.co.za> Message-ID: <1369496975.51.0.226789093335.issue16832@psf.upfronthosting.co.za> Nick Coghlan added the comment: And when I say "originally" I mean "after I saw how ABCs already implemented this capability" :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 17:50:49 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 May 2013 15:50:49 +0000 Subject: [issue18055] Stop using imp in IDLE In-Reply-To: <1369496414.51.0.562875229152.issue18055@psf.upfronthosting.co.za> Message-ID: <1369497049.53.0.832308622196.issue18055@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +kbk, roger.serwy, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 17:53:27 2013 From: report at bugs.python.org (STINNER Victor) Date: Sat, 25 May 2013 15:53:27 +0000 Subject: [issue7760] ctypes: use_errno=True does not work In-Reply-To: <1264205937.75.0.643663912285.issue7760@psf.upfronthosting.co.za> Message-ID: <1369497207.1.0.395264697885.issue7760@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: use_errno=True does not work -> ctypes: use_errno=True does not work _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 17:57:48 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 25 May 2013 15:57:48 +0000 Subject: [issue16832] Expose cache validity checking support in ABCMeta In-Reply-To: <1369496912.02.0.854233733047.issue16832@psf.upfronthosting.co.za> Message-ID: <1369497460.2562.9.camel@fsol> Antoine Pitrou added the comment: > I thought about that originally, but there's only ever one object > graph for the process, and as soon as you break any one edge in that > graph you pretty much invalidate anything based on caching traversal > results. Ah, I was forgetting that a ABC registration also affects the subclasses of the registered class, and the abstract parents of the ABC class. So it's a bit more annoying than it looked like. > So it's not really an implementation detail, it's a promise to provide > a unique token for the current state of the object graph that can be > used reliably for cache invalidation. Sounds fair. > A callback based system is actually *harder* to use, because you can't > simply ask the question "Is my cache still valid?" - you have to > register a callback that sets a flag, or something similar. Your > lookup code ends up being: Well, the point of a callback based system is for the callback to invalidate or recompute the cache *right now*, so you don't have to "check a flag" each time you do a lookup. It's a basic cost/benefit compromise: the callback system makes invalidations more expensive, but lookups cheapers. Besides, a callback-based system can be more future-proof than exposing the raw cache tags or tokens. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 18:00:54 2013 From: report at bugs.python.org (STINNER Victor) Date: Sat, 25 May 2013 16:00:54 +0000 Subject: [issue17934] Add a frame method to clear expensive details In-Reply-To: <1368014042.2.0.41504275061.issue17934@psf.upfronthosting.co.za> Message-ID: <1369497654.41.0.241397506834.issue17934@psf.upfronthosting.co.za> STINNER Victor added the comment: I may be safer to initialize f->f_executing to 1 at the creation of the frame, and only change its value to 0 when the execution is done. (The name of the attribute may also be changed.) I don't know if it is possible, but a frame should not be cleared just before it is used to execute code. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 18:20:41 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 May 2013 16:20:41 +0000 Subject: [issue16832] Expose cache validity checking support in ABCMeta In-Reply-To: <1357011504.56.0.782130595735.issue16832@psf.upfronthosting.co.za> Message-ID: <1369498841.87.0.12713884423.issue16832@psf.upfronthosting.co.za> Nick Coghlan added the comment: Ah, but that's the other trick: we *don't know* if we need to recalculate our whole cache when the object graph changes. 1. Some of the cached entries may never be accessed again, so recalculating them will be a waste 2. The object graph may change again before they're next accessed, so recalculating any entries at all will be waste The cache invalidation design in the ABCs is a smart compromise, since it leaves recreating the cache entries to the last possible moment: the next time a type is looked up after the object graph has changed. It doesn't matter if there is one graph change or a thousand in that time, we only do the fresh lookup once. And if the type is never looked up again, we don't even need to do that much. In a typical application, the expected usage model for both ABCs and generic functions is the same: 1. During startup, the object graph and dispatch resolution results are changing rapidly as concrete classes and implementations get registered with ABCs and generic functions. Actual instance checks and generic function dispatch operations are rare, so the caches mostly remain cold. 2. Once the application is up and running, the object graph stabilises, and the caches of significance to the application start to become populated through actual use. Absent live code reloading, the caches then remain valid for the lifetime of the application. The ABC design takes the view that the extra runtime check for cache validity in the absence of direct inheritance or registration is worth it to avoid repeated cache clearing during application startup for ABCs that may never even be used by the application. I believe exactly the same reasoning holds true for generic functions: triggering callbacks when the object graph changes means we may end up doing a lot of work clearing caches that the application isn't even using. Delaying the check to call time means that only the caches that matter will ever be touched. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 18:24:03 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 25 May 2013 16:24:03 +0000 Subject: [issue16832] Expose cache validity checking support in ABCMeta In-Reply-To: <1369498841.87.0.12713884423.issue16832@psf.upfronthosting.co.za> Message-ID: <1369499035.2562.10.camel@fsol> Antoine Pitrou added the comment: > 1. Some of the cached entries may never be accessed again, so > recalculating them will be a waste > 2. The object graph may change again before they're next accessed, so > recalculating any entries at all will be waste Yup, hence the "cost/benefit compromise" ;-) My assumption here was that ABC registrations change quite infrequently compared to the invocations of generic functions, so transferring most of the cost to registration-time (rather than invocation-time) would be a benefit. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 18:27:15 2013 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Sat, 25 May 2013 16:27:15 +0000 Subject: [issue16832] Expose cache validity checking support in ABCMeta In-Reply-To: <1357011504.56.0.782130595735.issue16832@psf.upfronthosting.co.za> Message-ID: <1369499235.49.0.980867233179.issue16832@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- keywords: +patch Added file: http://bugs.python.org/file30366/issue16832.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 18:28:18 2013 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Sat, 25 May 2013 16:28:18 +0000 Subject: [issue16832] Expose cache validity checking support in ABCMeta In-Reply-To: <1357011504.56.0.782130595735.issue16832@psf.upfronthosting.co.za> Message-ID: <1369499298.31.0.429780855148.issue16832@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Review the patch, please. Committing in 10... 9... 8... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 18:33:41 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 25 May 2013 16:33:41 +0000 Subject: [issue7757] sys.path is incorrect when prefix is "" In-Reply-To: <1264178776.01.0.552667161926.issue7757@psf.upfronthosting.co.za> Message-ID: <1369499621.01.0.696899130596.issue7757@psf.upfronthosting.co.za> Mark Lawrence added the comment: There's so much detail provided that I think this should be easy for someone who understands C code. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 18:42:14 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 May 2013 16:42:14 +0000 Subject: [issue16832] Expose cache validity checking support in ABCMeta In-Reply-To: <1357011504.56.0.782130595735.issue16832@psf.upfronthosting.co.za> Message-ID: <3bHqx20tfFzPYf@mail.python.org> Roundup Robot added the comment: New changeset 5b17d5ca2ff1 by ?ukasz Langa in branch 'default': Fix #16832 - expose cache validity checking support in ABCMeta http://hg.python.org/cpython/rev/5b17d5ca2ff1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 18:48:36 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 May 2013 16:48:36 +0000 Subject: [issue16832] Expose cache validity checking support in ABCMeta In-Reply-To: <1357011504.56.0.782130595735.issue16832@psf.upfronthosting.co.za> Message-ID: <3bHr4M2vCfzPYf@mail.python.org> Roundup Robot added the comment: New changeset d9828c438889 by ?ukasz Langa in branch 'default': Mention issue #16832 in Misc/NEWS http://hg.python.org/cpython/rev/d9828c438889 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 18:54:28 2013 From: report at bugs.python.org (Phillip J. Eby) Date: Sat, 25 May 2013 16:54:28 +0000 Subject: [issue16832] Expose cache validity checking support in ABCMeta In-Reply-To: <1357011504.56.0.782130595735.issue16832@psf.upfronthosting.co.za> Message-ID: <1369500868.65.0.599552839538.issue16832@psf.upfronthosting.co.za> Phillip J. Eby added the comment: Please expose this as an attribute of the class or module, not as a function. A function is orders of magnitude slower than attribute access, and the entire point of exposing this is to allow caches to be invalidated. In order to be useful for cache invalidation, the token has to be read on *every* access to a cache, thus adding unnecessary overhead to every cache access. ---------- nosy: +pje _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 18:56:13 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 25 May 2013 16:56:13 +0000 Subject: [issue16832] Expose cache validity checking support in ABCMeta In-Reply-To: <1369500868.65.0.599552839538.issue16832@psf.upfronthosting.co.za> Message-ID: <1369500966.2562.11.camel@fsol> Antoine Pitrou added the comment: > Please expose this as an attribute of the class or module, not as a > function. A function is orders of magnitude slower than attribute > access, and the entire point of exposing this is to allow caches to be > invalidated. -1. Exposing a function allows to modify the underlying implementation without breaking any API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 19:06:03 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 25 May 2013 17:06:03 +0000 Subject: [issue648658] xmlrpc can't do proxied HTTP Message-ID: <1369501563.59.0.276381698163.issue648658@psf.upfronthosting.co.za> Mark Lawrence added the comment: Could someone take a look at this while investigating other xmlrpc issues e.g. #7727. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 19:11:53 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 25 May 2013 17:11:53 +0000 Subject: [issue639266] Tkinter sliently discards all backgrond Tcl errors Message-ID: <1369501913.85.0.0836760624103.issue639266@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- title: Tkinter sliently discards all Tcl errors -> Tkinter sliently discards all backgrond Tcl errors _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 19:13:29 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 May 2013 17:13:29 +0000 Subject: [issue16832] Expose cache validity checking support in ABCMeta In-Reply-To: <1357011504.56.0.782130595735.issue16832@psf.upfronthosting.co.za> Message-ID: <1369502009.2.0.156769822517.issue16832@psf.upfronthosting.co.za> Nick Coghlan added the comment: Trading correctness for speed is almost never a good idea. If people are worried about speed to that level, they can either bypass the public API and access the private attribute directly (after profiling their application to ensure the cache validity checks are the bottleneck), or else migrate to PyPy to eliminate the function call overhead (amongst many other speed improvements). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 19:46:24 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 25 May 2013 17:46:24 +0000 Subject: [issue592703] HTTPS does not handle pipelined requests Message-ID: <1369503984.97.0.0504125748002.issue592703@psf.upfronthosting.co.za> Mark Lawrence added the comment: Bump. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 19:52:05 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 25 May 2013 17:52:05 +0000 Subject: [issue672115] Assignment to __bases__ of direct object subclasses Message-ID: <1369504325.76.0.940187339224.issue672115@psf.upfronthosting.co.za> Mark Lawrence added the comment: Has any work been done on typeobject.c to render this obsolete? Failing that are there any souls brave enough to take on typeobject.c? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 20:11:25 2013 From: report at bugs.python.org (W. Owen Parry) Date: Sat, 25 May 2013 18:11:25 +0000 Subject: [issue17545] os.listdir and os.path.join inconsistent on empty path In-Reply-To: <1364228813.43.0.916487849633.issue17545@psf.upfronthosting.co.za> Message-ID: <1369505485.49.0.503644661633.issue17545@psf.upfronthosting.co.za> W. Owen Parry added the comment: Patch as described above. Comments appreciated. ---------- keywords: +patch Added file: http://bugs.python.org/file30367/issue17545.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 20:41:28 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 May 2013 18:41:28 +0000 Subject: [issue18059] Add multibyte encoding support to pyexpat Message-ID: <1369507288.26.0.471852341095.issue18059@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: It is possible to add the support of most multibyte encodings to pyexpat. There are several ways to do this: 1. Generate maps with a special script and add generated file to repository. After adding or updating a multibyte encoding this file should be regenerated. 2. Generate maps on fly. It requires more time for first use of the encoding, but allows support of arbitrary encoding which compatible with expat. ---------- components: Extension Modules, XML files: expat_encodings.py messages: 189989 nosy: doerwalter, eli.bendersky, lemburg, serhiy.storchaka priority: normal severity: normal status: open title: Add multibyte encoding support to pyexpat type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file30368/expat_encodings.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 21:02:55 2013 From: report at bugs.python.org (Phillip J. Eby) Date: Sat, 25 May 2013 19:02:55 +0000 Subject: [issue16832] Expose cache validity checking support in ABCMeta In-Reply-To: <1369502009.2.0.156769822517.issue16832@psf.upfronthosting.co.za> Message-ID: Phillip J. Eby added the comment: Antoine Pitrou added the comment: > -1. Exposing a function allows to modify the underlying implementation > without breaking any API. This doesn't make any sense. Once you've exposed an API that gives out a value for this, you can't change the implementation in a way that doesn't involve handing out a value... in which case you can just as easily set it as an attribute. So there is actually zero improvement in encapsulation: it's purely a ritualistic wrapping, like Java programmers insisting on having getFoo() methods in Python when an attribute would suffice. If there must be a way to change it later to be dynamic, it can always be exposed as an attribute of an object that could grow a property later, e.g. from abc import object_graph if object_graph.version != old_version: ... Nick Coghlan added the comment: > Trading correctness for speed is almost never a good idea. How is "correctness" relevant to the question of whether a readable value is exposed as an attribute or a method? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 21:07:05 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sat, 25 May 2013 19:07:05 +0000 Subject: [issue17314] Stop using imp.find_module() in multiprocessing In-Reply-To: <1361994994.99.0.625564916049.issue17314@psf.upfronthosting.co.za> Message-ID: <1369508825.61.0.945096376761.issue17314@psf.upfronthosting.co.za> Richard Oudkerk added the comment: Looks good to me. (Any particular reason for ignoring AttributeError?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 21:07:26 2013 From: report at bugs.python.org (Lauri Alanko) Date: Sat, 25 May 2013 19:07:26 +0000 Subject: [issue18060] Updating _fields_ of a derived struct type yields a bad cif Message-ID: <1369508846.31.0.680698237225.issue18060@psf.upfronthosting.co.za> New submission from Lauri Alanko: In Modules/_ctypes/stgdict.c:567 there is a suspicious line: stgdict->length = len; /* ADD ffi_ofs? */ That is, the length field of the stgdict is set to the number of fields in the immediate Structure class, and the number of fields in the parent class (ffi_ofs) is questionably left out. This is wrong. The length field is used in PyCStgDict_clone to copy the ffi_type descriptors for struct elements to a derived struct type. If length is short, not all element types are copied, and the resulting array is not NULL-terminated. So the problem manifests when you inherit from a structure type, update the _fields_ of the inherited type, and then inherit again from the updated type. Even then everything might seem normal, since the elements array is actually not used very much. However, attached is a test case that segfaults at least with debug builds on ARM with the VFP ABI. The non-null-terminated element type array is traversed to find if the structure can be passed in floating point registers, eventually resulting in dereferencing 0xfbfbfbfb. The test program should print out pi. To avoid the hassle of a separate C component, the program abuses the standard atan2 function by pretending it takes a struct of two doubles instead of two separate double parameters. This does not make a difference to the ABI. Fixing the bug is trivial. Just change the line to: stgdict->length = ffi_ofs + len; ---------- components: ctypes files: t1.py messages: 189992 nosy: lauri.alanko priority: normal severity: normal status: open title: Updating _fields_ of a derived struct type yields a bad cif type: crash versions: Python 3.3 Added file: http://bugs.python.org/file30369/t1.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 21:16:27 2013 From: report at bugs.python.org (Phillip J. Eby) Date: Sat, 25 May 2013 19:16:27 +0000 Subject: [issue16832] Expose cache validity checking support in ABCMeta In-Reply-To: Message-ID: Phillip J. Eby added the comment: All that being said, I took out some time to get actual numbers, and found my original guesstimate of overhead was incorrect; it's only 3 times slower, not "orders of magnitude". ;-) And even on a relatively old machine, that 3 times slower amounts to an extra tenth of a microsecond, at least in a hot loop with timeit. So I'll stop being a pain about this now, even though I still think getters are a stinky Java code smell and don't belong in Python anyways. ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 21:18:12 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 25 May 2013 19:18:12 +0000 Subject: [issue16832] Expose cache validity checking support in ABCMeta In-Reply-To: Message-ID: <1369509484.2562.14.camel@fsol> Antoine Pitrou added the comment: > This doesn't make any sense. Once you've exposed an API that gives > out a value for this, you can't change the implementation in a way > that doesn't involve handing out a value... in which case you can just > as easily set it as an attribute. Because it may be computed whenever the function call is done, rather than stored statically somewhere. The caching scheme will not necessarily remain forever identical. > If there > must be a way to change it later to be dynamic, it can always be > exposed as an attribute of an object that could grow a property later, > e.g. That's a possibility indeed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 21:53:05 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sat, 25 May 2013 19:53:05 +0000 Subject: [issue18059] Add multibyte encoding support to pyexpat In-Reply-To: <1369507288.26.0.471852341095.issue18059@psf.upfronthosting.co.za> Message-ID: <1369511585.29.0.949483723753.issue18059@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: I guess GB18030 can't be supported at all? ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 22:30:38 2013 From: report at bugs.python.org (Tim Golden) Date: Sat, 25 May 2013 20:30:38 +0000 Subject: [issue18040] SIGINT catching regression on windows in 2.7 In-Reply-To: <1369278066.93.0.310534523814.issue18040@psf.upfronthosting.co.za> Message-ID: <1369513838.33.0.115378342996.issue18040@psf.upfronthosting.co.za> Tim Golden added the comment: My initial reaction is that, whether the 2.7 behaviour is faulty or not, I can't reproduce the "correct" behaviour on any version of Windows going back to 2.4. Take the attached Python file issue18040.py and run "c:\pythonxx\python.exe -i issue18040.py" for any version of Python from 2.4 to 3.4. At the interpreter prompt, pressing Ctrl-C produces "Keyboard Interrupt" consistently (except for the few times it exits the interpreter which is the problem fixed in issue1677). Note that this applies to pressing Ctrl-C *at the interpreter prompt* (while the running code is the function my_fgets in parser/myreadline.c). Pressing Ctrl-C in other circumstances, eg in the middle of a long-running os.walk or a time.sleep, invokes the signal handler as expected. I don't know if the handler *should* be invoked at the interpreter prompt. I recognise that it does so under Linux, but are there any circumstances where that would actually be useful? ---------- assignee: -> tim.golden Added file: http://bugs.python.org/file30370/issue18040.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 22:55:06 2013 From: report at bugs.python.org (mirabilos) Date: Sat, 25 May 2013 20:55:06 +0000 Subject: [issue18061] m68k Python 3.3 test results Message-ID: <1369515304.6.0.15163680976.issue18061@psf.upfronthosting.co.za> New submission from mirabilos: Hi! As a followup to http://bugs.python.org/issue17237 I took the tree of Python 3.3.1 I had compiled already, with the patch that was eventually committed for issue17237, and ran the testsuite. Since I used configure flags to get it compiled quickly, it probably lacks functionality that?s normally there, so some tests got omitted. The result of normally running the testsuite is attached as file; I can re-run any test verbosely, just ask ;-) I can immediately say something to some failures: ? On m68k, the 68881 FPU, similar to the i8087 FPU, internally operates on 80-bit precision, which means that the ?old? dtoa code is used. Contrarily to i8087, we do not want to disable that mode because that is not fully supported in some environments; especially, at least the most wide-spread emulator had bugs wrt. that. (Do note that, when you disable 80-bit precision on i8087, you get double-rounding as the only the mantisse, not the exponent, is bit-reduced, anyway. So I believe that you should not restrict the i8087 to 64-bit precision either.) That?s responsible for test_optparse, test_difflib, maybe test_cmath, definitely test_format, test_types, test_math? ouch, quite some. It would be interesting to see what happens when you take a normal i386 (not amd64 or x32) Linux host and compile py3k with SSE disabled (to force it to use the normal i80387 FPU), and disable HAVE_GCC_ASM_FOR_X87 so that X87_DOUBLE_ROUNDING is defined, because that?s what we have on m68k, and see whether the failure mode is the same. If so, you can then probably relatively easily fix those. root at ara3:~/P-without-block # fgrep X87 pyconfig.h /* #undef HAVE_GCC_ASM_FOR_X87 */ #define X87_DOUBLE_ROUNDING 1 ? This one is pretty severe: AssertionError: 42 != 44 : wrong size for : got 42, expected 44 On m68k, ?natural? alignment is *not* used: instead of aligning 4-byte quantities on 4-byte boundaries, for almost all types, only a minimum alignment of 2 bytes is used; this also has effect on struct padding, array padding, and things like that. As shown in https://mail.gnome.org/archives/commits-list/2012-February/msg02332.html fixing this is a ?simple? matter of making these invalid assumptions explicit. To that effect, take Include/pyerrors.h and change #define PyException_HEAD PyObject_HEAD PyObject *dict;\ PyObject *args; PyObject *traceback;\ PyObject *context; PyObject *cause;\ char suppress_context; to #define PyException_HEAD PyObject_HEAD PyObject *dict;\ PyObject *args; PyObject *traceback;\ PyObject *context; PyObject *cause;\ char suppress_context; char padding1[3]; i.e. add the padding that?s implicit on ?natural alignment? platforms (a padding1[1] is implicit on m68k). Do *not* use -malign-int because that changes the ABI, and you probably won?t be able to make libc or syscalls any more? However, this brings us to a problem with that solution (which I?d still prefer over everything else) in Debian (hence, putting doko on Cc), which I?ll demonstrate on the shortest struct I could find in that file, but applies to e.g. PyImportErrorObject too: typedef struct { PyException_HEAD PyObject *code; } PySystemExitObject; The ?code? member of this struct is aligned with only *one* byte of padding, instead of three. This means that, when we apply this bugfix, that the published ABI changes: currently, sizeof(PySystemExitObject) is (8 (PyObject_HEAD) + 4 (dict) + 4 (args) + 4 (traceback) + 4 (context) + 4 (cause) + 1 (suppress_context) + 1 padding + 4 (code)) = 34; after the fact, it will be 36, and the offsetof(code) will have changed. I?ll leave the understanding of these implications, and how they can best be handled in the distribution, to doko, because he?s probably the man who understands it best. I guess we need versioned dependencies or ABI virtual dependencies, since python3.3 is already uploaded, but some packages have already been built against it (probably not too difficult to identify them). Or we can only get this fixed in python3.4 ? no idea when that will land in Debian, or whether it?ll become the default python3 provider shortly. ? As for any other failures, I don?t directly have an idea, but I guess we can work on them. I?d somewhat prefer to do that *after* the FPU precision-related bugs have been fixed, though, as it?ll reduce the noise, and possibly followup-errors. (Maybe I should even, for running the tests, fix the alignment issue locally in the tree.) ---------- components: Interpreter Core files: results.txt messages: 189997 nosy: doko, mirabilos, pitrou, skrah priority: normal severity: normal status: open title: m68k Python 3.3 test results versions: Python 3.3 Added file: http://bugs.python.org/file30371/results.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 22:57:33 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 25 May 2013 20:57:33 +0000 Subject: [issue18061] m68k Python 3.3 test results In-Reply-To: <1369515304.6.0.15163680976.issue18061@psf.upfronthosting.co.za> Message-ID: <1369515453.3.0.443903624746.issue18061@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Could you a separate bug entry for each class of issues? It will make things more manageable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:00:51 2013 From: report at bugs.python.org (mirabilos) Date: Sat, 25 May 2013 21:00:51 +0000 Subject: [issue18062] m68k FPU precision issue Message-ID: <1369515651.34.0.291697920686.issue18062@psf.upfronthosting.co.za> New submission from mirabilos: Hi, splitting off issue18061 by request of pitrou: FPU precision issue: MC68881 FPU, similar to Intel 80387, uses 80-bit precision internally. We do not want to change it to 64-bit because it?s not supported in all environments. Can probably be reproduced on i386 (with disabled SSE); fixing this in general would allow keeping the FPUCW on i387 unchanged too. See issue18061 for details. ---------- components: Interpreter Core messages: 189999 nosy: mirabilos priority: normal severity: normal status: open title: m68k FPU precision issue versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:01:55 2013 From: report at bugs.python.org (mirabilos) Date: Sat, 25 May 2013 21:01:55 +0000 Subject: [issue18063] m68k struct alignment issue vs. PyException_HEAD Message-ID: <1369515715.51.0.704105315626.issue18063@psf.upfronthosting.co.za> New submission from mirabilos: Hi, splitting off issue18061 by request of pitrou: struct alignment issue: PyException_HEAD misses explicit alignment instruction; uses invalid (non-portable) alignment assumptions. ABI change on m68k. See issue18061 for details. ---------- components: Interpreter Core messages: 190000 nosy: mirabilos priority: normal severity: normal status: open title: m68k struct alignment issue vs. PyException_HEAD versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:02:48 2013 From: report at bugs.python.org (mirabilos) Date: Sat, 25 May 2013 21:02:48 +0000 Subject: [issue18061] m68k Python 3.3 test results In-Reply-To: <1369515304.6.0.15163680976.issue18061@psf.upfronthosting.co.za> Message-ID: <1369515768.87.0.860133937156.issue18061@psf.upfronthosting.co.za> mirabilos added the comment: OK sure; I put the two I identified already into issue18062 and issue18063; we can then retry here after those get fixed (I?ll just resend results from a patched tree then). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:02:54 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 25 May 2013 21:02:54 +0000 Subject: [issue18063] m68k struct alignment issue vs. PyException_HEAD In-Reply-To: <1369515715.51.0.704105315626.issue18063@psf.upfronthosting.co.za> Message-ID: <1369515774.67.0.797110758673.issue18063@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > ? This one is pretty severe: AssertionError: 42 != 44 : wrong size for > : got 42, expected 44 What is the context? test_sys? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:03:30 2013 From: report at bugs.python.org (mirabilos) Date: Sat, 25 May 2013 21:03:30 +0000 Subject: [issue18063] m68k struct alignment issue vs. PyException_HEAD In-Reply-To: <1369515715.51.0.704105315626.issue18063@psf.upfronthosting.co.za> Message-ID: <1369515810.32.0.160642046644.issue18063@psf.upfronthosting.co.za> mirabilos added the comment: Yes, that's in test_sys. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:05:07 2013 From: report at bugs.python.org (W. Owen Parry) Date: Sat, 25 May 2013 21:05:07 +0000 Subject: [issue16580] Add examples to int.to_bytes and int.from_bytes In-Reply-To: <1354217109.61.0.534443148437.issue16580@psf.upfronthosting.co.za> Message-ID: <1369515907.34.0.379857181404.issue16580@psf.upfronthosting.co.za> W. Owen Parry added the comment: Patch adding examples + tests for equivalence. Comments appreciated. In particular, I'm not sure that the from_bytes example is simple enough to be useful: def from_bytes(bytes, byteorder, signed=False): if byteorder == 'little': little_ordered = list(bytes) elif byteorder == 'big': little_ordered = list(reversed(bytes)) n = sum(little_ordered[i] << i*8 for i in range(len(little_ordered))) if signed and little_ordered and (little_ordered[-1] & 0x80): n -= 1 << 8*len(little_ordered) return n ---------- keywords: +patch nosy: +woparry Added file: http://bugs.python.org/file30372/issue16580.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:10:53 2013 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 25 May 2013 21:10:53 +0000 Subject: [issue17936] O(n**2) behaviour when adding/removing classes In-Reply-To: <1369487783.17.0.431818653534.issue17936@psf.upfronthosting.co.za> Message-ID: <1369516250388.93c19d27@Nodemailer> Guido van Rossum added the comment: I can't think of a use for the order of __subclasses__ so no objection here. ? Sent from Mailbox for iPad On Sat, May 25, 2013 at 6:16 AM, Antoine Pitrou wrote: > Antoine Pitrou added the comment: > Note that making tp_subclasses a dict makes the __subclasses__ return order undefined. I don't think I've ever seen __subclasses__ actually used, so I'm not convinced it's a problem, but perhaps it's worth floating the idea on python-dev. > ---------- > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:12:58 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 25 May 2013 21:12:58 +0000 Subject: [issue18063] m68k struct alignment issue vs. PyException_HEAD In-Reply-To: <1369515715.51.0.704105315626.issue18063@psf.upfronthosting.co.za> Message-ID: <1369516378.86.0.912989801229.issue18063@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I suppose it's in SizeofTest specifically (in the future, please quote more detailed test information; you can get it by replaying a test in verbose mode, e.g. "./python -m test -v test_sys"). Can you post the output of: >>> struct.calcsize("PPnP5Pb") >>> struct.calcsize("PPnP5Pi") >>> struct.calcsize("PPnP5Pb0P") >>> struct.calcsize("PPnP5Pi0P") ---------- components: +Tests versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:17:56 2013 From: report at bugs.python.org (Stefan Krah) Date: Sat, 25 May 2013 21:17:56 +0000 Subject: [issue18062] m68k FPU precision issue In-Reply-To: <1369515651.34.0.291697920686.issue18062@psf.upfronthosting.co.za> Message-ID: <1369516676.2.0.0569822220152.issue18062@psf.upfronthosting.co.za> Stefan Krah added the comment: > We do not want to change it to 64-bit because it?s not supported in all environments. Does this also apply to changing the precision temporarily? Because that is what happens for other platforms, see Include/pyport.h: HAVE_PY_SET_53BIT_PRECISION _PY_SET_53BIT_PRECISION_START _PY_SET_53BIT_PRECISION_END ... To me it sounds that you'd basically have to provide these macros for the platform. ---------- nosy: +mark.dickinson, skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:18:47 2013 From: report at bugs.python.org (mirabilos) Date: Sat, 25 May 2013 21:18:47 +0000 Subject: [issue18063] m68k struct alignment issue vs. PyException_HEAD In-Reply-To: <1369515715.51.0.704105315626.issue18063@psf.upfronthosting.co.za> Message-ID: <1369516727.96.0.897971717753.issue18063@psf.upfronthosting.co.za> mirabilos added the comment: >>> struct.calcsize("PPnP5Pb") 37 >>> struct.calcsize("PPnP5Pi") 40 >>> struct.calcsize("PPnP5Pb0P") 38 >>> struct.calcsize("PPnP5Pi0P") 40 I already offered to re-run tests in verbose mode ?on request? if needed, but the results.txt I attached to issue18061 contains them for test_sys (it apparently got re-run verbosely automatically). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:20:29 2013 From: report at bugs.python.org (mirabilos) Date: Sat, 25 May 2013 21:20:29 +0000 Subject: [issue18062] m68k FPU precision issue In-Reply-To: <1369515651.34.0.291697920686.issue18062@psf.upfronthosting.co.za> Message-ID: <1369516829.93.0.967399013079.issue18062@psf.upfronthosting.co.za> mirabilos added the comment: > > We do not want to change it to 64-bit because it?s not supported > > in all environments. > Does this also apply to changing the precision temporarily? Yes, that?s precisely what?s not working on the most widespread emulator, at the very least. (I have working code for that, in three(!) variants, but it just ignores those requests to change precision.) I think FPU is the one thing current m68k emulators do the worst? the responses I got from the mailing list back then said so, anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:23:52 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 25 May 2013 21:23:52 +0000 Subject: [issue18063] m68k struct alignment issue vs. PyException_HEAD In-Reply-To: <1369515715.51.0.704105315626.issue18063@psf.upfronthosting.co.za> Message-ID: <1369517032.25.0.0600263024744.issue18063@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, can you try applying the following patch: diff --git a/Lib/test/test_sys.py b/Lib/test/test_sys.py --- a/Lib/test/test_sys.py +++ b/Lib/test/test_sys.py @@ -703,13 +703,13 @@ class SizeofTest(unittest.TestCase): class C(object): pass check(C.__dict__, size('P')) # BaseException - check(BaseException(), size('5Pi')) + check(BaseException(), size('5Pb')) # UnicodeEncodeError - check(UnicodeEncodeError("", "", 0, 0, ""), size('5Pi 2P2nP')) + check(UnicodeEncodeError("", "", 0, 0, ""), size('5Pb 2P2nP')) # UnicodeDecodeError - check(UnicodeDecodeError("", b"", 0, 0, ""), size('5Pi 2P2nP')) + check(UnicodeDecodeError("", b"", 0, 0, ""), size('5Pb 2P2nP')) # UnicodeTranslateError - check(UnicodeTranslateError("", 0, 1, ""), size('5Pi 2P2nP')) + check(UnicodeTranslateError("", 0, 1, ""), size('5Pb 2P2nP')) # ellipses check(Ellipsis, size('')) # EncodingMap ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:24:42 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 May 2013 21:24:42 +0000 Subject: [issue18059] Add multibyte encoding support to pyexpat In-Reply-To: <1369507288.26.0.471852341095.issue18059@psf.upfronthosting.co.za> Message-ID: <1369517082.46.0.854074472004.issue18059@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which implements first way. Yes, looks as followed encodings could not be supported at all: euc-kr, gb18030, iso2022-kr, utf-7, cp037, cp424, cp500, cp864, cp875, cp1026, cp1140, utf_32, utf_32_be, utf_32_le. ---------- keywords: +patch Added file: http://bugs.python.org/file30373/pyexpat_multibyte_encodings.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:36:20 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 25 May 2013 21:36:20 +0000 Subject: [issue18064] IDLE: add current directory to open_module Message-ID: <1369517780.56.0.941397989466.issue18064@psf.upfronthosting.co.za> New submission from Terry J. Reedy: The point of File / Open Module is to look at the source for a module that has been, could be, or will be imported. The problem is that open_module is executed in the idle process while imports are executed in the user process, with the current directory prepended to sys.module. The problem was already noted in the source, line 675. # XXX Ought to insert current file's directory in front of path The augmentation of sys.path and subsequent restoration of the original could be done in a context manager that might be useful elsewhere. For 3.3,3.4, I think the change should be done after the patch in #18055, to not invalidate that patch. It would need to located in a slightly different place in 2.7, which will not be changed by that issue. ---------- messages: 190012 nosy: roger.serwy, terry.reedy priority: normal severity: normal stage: test needed status: open title: IDLE: add current directory to open_module type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:36:38 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 25 May 2013 21:36:38 +0000 Subject: [issue18064] IDLE: add current directory to open_module In-Reply-To: <1369517780.56.0.941397989466.issue18064@psf.upfronthosting.co.za> Message-ID: <1369517798.39.0.555826799208.issue18064@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- dependencies: +Stop using imp in IDLE _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:39:18 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 May 2013 21:39:18 +0000 Subject: [issue16580] Add examples to int.to_bytes and int.from_bytes In-Reply-To: <1354217109.61.0.534443148437.issue16580@psf.upfronthosting.co.za> Message-ID: <1369517958.79.0.514940765486.issue16580@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't call it the examples. Here is the examples: >>> (1234).to_bytes(2, 'big') b'\x04\xd2' >>> (1234).to_bytes(2, 'little') b'\xd2\x04' >>> (-1234).to_bytes(2, 'big', signed=True) b'\xfb.' >>> int.from_bytes(b'\xde\xad\xbe\xef', 'big') 3735928559 >>> int.from_bytes(b'\xde\xad\xbe\xef', 'little') 4022250974 >>> int.from_bytes(b'\xde\xad\xbe\xef', 'big', signed=True) -559038737 ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:40:01 2013 From: report at bugs.python.org (mirabilos) Date: Sat, 25 May 2013 21:40:01 +0000 Subject: [issue18063] m68k struct alignment issue vs. PyException_HEAD In-Reply-To: <1369515715.51.0.704105315626.issue18063@psf.upfronthosting.co.za> Message-ID: <1369518001.14.0.84633167702.issue18063@psf.upfronthosting.co.za> mirabilos added the comment: Sure (attached). ---------- Added file: http://bugs.python.org/file30374/after-patch-1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:40:10 2013 From: report at bugs.python.org (mirabilos) Date: Sat, 25 May 2013 21:40:10 +0000 Subject: [issue18063] m68k struct alignment issue vs. PyException_HEAD In-Reply-To: <1369515715.51.0.704105315626.issue18063@psf.upfronthosting.co.za> Message-ID: <1369518010.93.0.502192860722.issue18063@psf.upfronthosting.co.za> mirabilos added the comment: Include/unicodeobject.h has the same problem; its ?state? member currently allocates 8 bit, which is only padded up to 16 bit. asciifields = "nnbP" makes that work too; result attached as after-patch-2.txt Will just changing the testsuite to match reality be enough, or are there any other internal assumptions about this type of thing, like we had with issue17237 earlier? Thanks for your quick responses! ---------- Added file: http://bugs.python.org/file30375/after-patch-2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:46:21 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 25 May 2013 21:46:21 +0000 Subject: [issue18063] m68k struct alignment issue vs. PyException_HEAD In-Reply-To: <1369515715.51.0.704105315626.issue18063@psf.upfronthosting.co.za> Message-ID: <1369518381.92.0.868173987079.issue18063@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thank you. This is just a bug in the test suite, so it's fine to fix it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:48:08 2013 From: report at bugs.python.org (mirabilos) Date: Sat, 25 May 2013 21:48:08 +0000 Subject: [issue18063] m68k struct alignment issue vs. PyException_HEAD In-Reply-To: <1369515715.51.0.704105315626.issue18063@psf.upfronthosting.co.za> Message-ID: <1369518488.12.0.514617977551.issue18063@psf.upfronthosting.co.za> mirabilos added the comment: Okay, then I?ll ignore those for now. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:48:23 2013 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 May 2013 21:48:23 +0000 Subject: [issue18063] m68k struct alignment issue vs. PyException_HEAD In-Reply-To: <1369515715.51.0.704105315626.issue18063@psf.upfronthosting.co.za> Message-ID: <3bHykG65DXzPtX@mail.python.org> Roundup Robot added the comment: New changeset c20b701c66fc by Antoine Pitrou in branch '3.3': Issue #18063: fix some struct specifications in the tests for sys.getsizeof(). http://hg.python.org/cpython/rev/c20b701c66fc New changeset 5c4ca109af1c by Antoine Pitrou in branch 'default': Issue #18063: fix some struct specifications in the tests for sys.getsizeof(). http://hg.python.org/cpython/rev/5c4ca109af1c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:52:26 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 25 May 2013 21:52:26 +0000 Subject: [issue18063] m68k struct alignment issue vs. PyException_HEAD In-Reply-To: <1369515715.51.0.704105315626.issue18063@psf.upfronthosting.co.za> Message-ID: <1369518746.2.0.418815740086.issue18063@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Should be done now :) ---------- components: -Interpreter Core resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> behavior versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:58:01 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 May 2013 21:58:01 +0000 Subject: [issue18061] m68k Python 3.3 test results In-Reply-To: <1369515304.6.0.15163680976.issue18061@psf.upfronthosting.co.za> Message-ID: <1369519081.63.0.390136196662.issue18061@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: About test_shutil failure. What filesystem are used? Do you run tests as root? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:58:07 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 25 May 2013 21:58:07 +0000 Subject: [issue18055] Stop using imp in IDLE In-Reply-To: <1369496414.51.0.562875229152.issue18055@psf.upfronthosting.co.za> Message-ID: <1369519087.94.0.0998980125266.issue18055@psf.upfronthosting.co.za> Terry J. Reedy added the comment: (Roger, please see Bretts opening message.) Brett, thanks for asking. We prefer to keep active codebases in sync as much as possible. Since new import stuff is not in 2.7, we will have to skip that. In EditorWindow.py, the patch deletes the _find_module function that wraps imp.find_module and edits the EditorWindows class open_module method that used that method. I presume that the new code somewhere duplicates the extra work done in _find_module beyond that done by imp.find_module. I verified that these are the only idlelib/*.py occurrences of 'find_module' and '_find_module'. It applies to 3.3 with chunk 3 offset a line. The only use of open_module is its binding to File / Open Module (Alt-M). This opens a module, given by its dotted import name, in the editor, instead of importing it. This works for stdlib modules before and after the patch. I tried both text selection and keyboard entry. As noted in the code, and explained in #18064, open_module does not work for 'current directory' modules. (A fix for that issue should wait for this one.) I did not try anything exotic like a relative path (never used one, not sure of syntax), .pth (not used on current machine), or package directories. But I expect the new import code is more reliable for these. If there is a problem, people can always use the open dialog. So unless Roger sees something I missed, you have my green light to apply. ---------- keywords: +needs review, pep3121 versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat May 25 23:58:57 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sat, 25 May 2013 21:58:57 +0000 Subject: [issue18059] Add multibyte encoding support to pyexpat In-Reply-To: <1369507288.26.0.471852341095.issue18059@psf.upfronthosting.co.za> Message-ID: <1369519137.64.0.234875880849.issue18059@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Then you should also remove the "Make it as simple as possible" comment :-/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 00:01:48 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 May 2013 22:01:48 +0000 Subject: [issue18063] m68k struct alignment issue vs. PyException_HEAD In-Reply-To: <1369515715.51.0.704105315626.issue18063@psf.upfronthosting.co.za> Message-ID: <1369519308.15.0.268246420012.issue18063@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: 2.7? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 00:03:22 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 May 2013 22:03:22 +0000 Subject: [issue18059] Add multibyte encoding support to pyexpat In-Reply-To: <1369507288.26.0.471852341095.issue18059@psf.upfronthosting.co.za> Message-ID: <1369519402.08.0.123823777569.issue18059@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It is still simple enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 00:03:53 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 25 May 2013 22:03:53 +0000 Subject: [issue18063] m68k struct alignment issue vs. PyException_HEAD In-Reply-To: <1369515715.51.0.704105315626.issue18063@psf.upfronthosting.co.za> Message-ID: <1369519433.53.0.340679620058.issue18063@psf.upfronthosting.co.za> Antoine Pitrou added the comment: 2.7 doesn't have the C struct fields which were mistakingly sized in test_sys. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 00:10:40 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 May 2013 22:10:40 +0000 Subject: [issue18061] m68k Python 3.3 test results In-Reply-To: <1369515304.6.0.15163680976.issue18061@psf.upfronthosting.co.za> Message-ID: <1369519840.59.0.563460945028.issue18061@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Is m68k big-endian? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 00:18:07 2013 From: report at bugs.python.org (Stefan Krah) Date: Sat, 25 May 2013 22:18:07 +0000 Subject: [issue18062] m68k FPU precision issue In-Reply-To: <1369515651.34.0.291697920686.issue18062@psf.upfronthosting.co.za> Message-ID: <1369520287.82.0.902183008239.issue18062@psf.upfronthosting.co.za> Stefan Krah added the comment: I forgot to comment on this: > fixing this in general would allow keeping the FPUCW on i387 unchanged too. Actually dtoa.c (which is used on i387) explicitly requires to change the control word. Looking at the test results, it seems to me that a couple of tests could be skipped if PY_NO_SHORT_FLOAT_REPR is defined, i.e.the failures are fully expected. Not sure about the lgamma etc. failures though, perhaps that's an emulator bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 00:19:27 2013 From: report at bugs.python.org (mirabilos) Date: Sat, 25 May 2013 22:19:27 +0000 Subject: [issue18061] m68k Python 3.3 test results In-Reply-To: <1369519840.59.0.563460945028.issue18061@psf.upfronthosting.co.za> Message-ID: mirabilos added the comment: Serhiy Storchaka dixit: >About test_shutil failure. What filesystem are used? /dev/root on / type ext3 (rw,noatime,errors=remount-ro,user_xattr,acl,barrier=1,nodelalloc,data=ordered) >Do you run tests as root? Yes. >Is m68k big-endian? Yes: ILP32 big-endian, 2-byte aligned. bye, //mirabilos -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 00:19:28 2013 From: report at bugs.python.org (mirabilos) Date: Sat, 25 May 2013 22:19:28 +0000 Subject: [issue18062] m68k FPU precision issue In-Reply-To: <1369516829.93.0.967399013079.issue18062@psf.upfronthosting.co.za> Message-ID: mirabilos added the comment: mirabilos dixit: >mirabilos added the comment: >Yes, that?s precisely what?s not working on the most widespread >emulator, at the very least. (I have working code for that, in >three(!) variants, but it just ignores those requests to change >precision.) Here?s the Python testcase made into a standalone test: -----BEGIN cutting here may damage your screen surface----- #include #include #include #ifndef __MirBSD__ #include #endif void runtests(void); void runtests(void) { volatile double x, y, z; /* 1./(1-2**-53) -> 1+2**-52 (correct), 1.0 (double rounding) */ x = 0.99999999999999989; /* 1-2**-53 */ y = 1./x; printf("test#1 %s: %.17E\n", (y == 1.) ? "fail" : "good", y); /* 1e16+2.99999 -> 1e16+2. (correct), 1e16+4. (double rounding) */ x = 1e16; y = 2.99999; z = x + y; printf("test#2 %s: %.17E\n", z == 1e16+4. ? "fail" : "good", z); } int main(void) { #ifdef _FPU_SETCW fpu_control_t cwold, cwnew, cwgot; #endif runtests(); #if (defined(__i386__) || defined(__m68k__)) && defined(_FPU_SETCW) _FPU_GETCW(cwold); #ifdef __i386__ cwnew = 0x127f; #else cwnew = _FPU_RC_NEAREST | _FPU_DOUBLE; #endif _FPU_SETCW(cwnew); _FPU_GETCW(cwgot); printf("changing FPU control word from %08X to %08X => %08X\n", cwold, cwnew, cwgot); runtests(); #endif return (0); } -----END cutting here may damage your screen surface----- Here?s the result of running it on the latest ARAnyM, which did get MPFR-based FPU emulation bugfixes, but apparently still ignores any FPUCW changes (or, at least the ones relating to precision): root at ara3:~ # ./a.out test#1 fail: 1.00000000000000000E+00 test#2 fail: 1.00000000000000040E+16 changing FPU control word from 00000000 to 00000080 => 00000080 test#1 fail: 1.00000000000000000E+00 test#2 fail: 1.00000000000000040E+16 bye, //mirabilos -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 00:31:39 2013 From: report at bugs.python.org (mirabilos) Date: Sat, 25 May 2013 22:31:39 +0000 Subject: [issue18062] m68k FPU precision issue In-Reply-To: <1369520287.82.0.902183008239.issue18062@psf.upfronthosting.co.za> Message-ID: mirabilos added the comment: Stefan Krah dixit: >> fixing this in general would allow keeping the FPUCW on i387 unchanged too. > >Actually dtoa.c (which is used on i387) explicitly requires to change >the control word. Right. By fixing the ?older? code, i386 is not required to change the FPUCW any more and can use it too. The problem with changing the FPUCW on i387 is that it changes from 64/15 bit mantissa/exponent to 53/15 bit which is still not the 53/11 bit of IEEE double, so you *still* get double- rounding issues (with denormal numbers only, I guess) because the internal precision is still higher. And on m68k we simply cannot afford to change the FPUCW because that will cause runtime failures on some implementations. >Looking at the test results, it seems to me that a couple of tests >could be skipped if PY_NO_SHORT_FLOAT_REPR is defined, i.e.the >failures are fully expected. Ah okay. >Not sure about the lgamma etc. failures though, perhaps that's >an emulator bug. If I can get self-contained test cases (preferably in C because that makes it easier for others to test), I can ask people who run real bare-metal Atari or Amiga to test them. Or you can ask on debian-68k at lists.debian.org for testers. I guess a python2.6 runnable testcase would be okay, even for those running an a bit older ?base system?. (I admit mine is not really up to date either, just the build chroots, because of the post-release unfreeze upload peak and related transitions.) bye, //mirabilos -- ?It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.? -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 00:50:44 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 25 May 2013 22:50:44 +0000 Subject: [issue17314] Stop using imp.find_module() in multiprocessing In-Reply-To: <1361994994.99.0.625564916049.issue17314@psf.upfronthosting.co.za> Message-ID: <1369522244.37.0.0303591164576.issue17314@psf.upfronthosting.co.za> Brett Cannon added the comment: Catching the AttributeError is in case a loader is used that doesn't define init_module_attrs(). Since it will be new to Python 3.4 I can't guarantee that it will exist (in case someone doesn't subclass the proper ABC). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 00:54:24 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 25 May 2013 22:54:24 +0000 Subject: [issue18055] Stop using imp in IDLE In-Reply-To: <1369496414.51.0.562875229152.issue18055@psf.upfronthosting.co.za> Message-ID: <1369522464.0.0.865118684304.issue18055@psf.upfronthosting.co.za> Brett Cannon added the comment: If you would prefer to keep using imp in IDLE to make management across versions easier I'm fine with that, just understand my goal is to deprecate imp in Python 3.4 (but won't remove it until Python 4 so people can write Python 2/3 compatible code, much like you with IDLE). So if you're okay with using a deprecated module then this change is strictly not necessary and I can just silence any deprecation warning in the code instead when the deprecation comes about. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 01:06:04 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sat, 25 May 2013 23:06:04 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1369523164.28.0.661995388244.issue17947@psf.upfronthosting.co.za> Eli Bendersky added the comment: Ethan, just a reminder to write that documentation... It's basically a stripped down version of PEP 435 (leave all the philosophy and history out), with a few concrete "reference" sections explaining the API precisely. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 01:21:02 2013 From: report at bugs.python.org (Brett Cannon) Date: Sat, 25 May 2013 23:21:02 +0000 Subject: [issue18065] set __path__ = [] for frozen packages Message-ID: <1369524062.03.0.920595154239.issue18065@psf.upfronthosting.co.za> New submission from Brett Cannon: If you import the frozen __phello__ package, you will notice that __phello__.__path__ == ['__phello__']. While that seems innocuous, that could potentially lead to incorrect results if there just so happens to be a directory named __phello__ which contains a file that isn't a frozen submodule (i.e. FrozenImporter can't find the submodule but PathFinder can find a file that happens to match the module's name). So for that reason I want to simply set __path__ = [] for frozen packages. The language reference for import states setting __path__ to anything makes a module a package and that it just needs to be an iterable that only returns strings (http://docs.python.org/3.4/reference/import.html#packages), so an empty list works. Plus __package__ contains the same information so there is no lost data by doing this. Can anyone think of a good reason not to do this? I can't see why someone would be relying upon this for any reason since the existence of __path__ itself is enough to determine something is a package. ---------- assignee: brett.cannon components: Interpreter Core messages: 190034 nosy: brett.cannon priority: normal severity: normal stage: test needed status: open title: set __path__ = [] for frozen packages type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 01:30:47 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 25 May 2013 23:30:47 +0000 Subject: [issue706263] print raises exception when no console available Message-ID: <1369524647.95.0.995553795944.issue706263@psf.upfronthosting.co.za> Mark Lawrence added the comment: Is it really worth leaving this open? There's no consensus after ten years and it only impacts on Python 2.7. Mark Hammond made his view plain in msg15198, which is supported by the fact that a type has yet to be allocated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 01:31:41 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Sat, 25 May 2013 23:31:41 +0000 Subject: [issue17314] Stop using imp.find_module() in multiprocessing In-Reply-To: <1361994994.99.0.625564916049.issue17314@psf.upfronthosting.co.za> Message-ID: <1369524701.6.0.922229097832.issue17314@psf.upfronthosting.co.za> Richard Oudkerk added the comment: The unit tests pass with the patch already (if we don't delete the "import imp" line). What attributes will be set by init_module_attrs()? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 02:06:41 2013 From: report at bugs.python.org (Roger Serwy) Date: Sun, 26 May 2013 00:06:41 +0000 Subject: [issue18055] Stop using imp in IDLE In-Reply-To: <1369496414.51.0.562875229152.issue18055@psf.upfronthosting.co.za> Message-ID: <1369526801.67.0.279788466575.issue18055@psf.upfronthosting.co.za> Roger Serwy added the comment: @Brett, I agree that IDLE should not be using deprecated modules. I don't know all the ins and outs of the import machinery of Python, so I'll defer to your expertise in that area. :-) @Terry, I have never used this IDLE feature before, so I don't know all it's corner cases or expected behavior. The patch works when opening "os" but fails with "sys". Without the patch, a dialog box appears saying "No source for module sys". With the patch, I get "not a source-based module" and then another dialog "loader does not support get_filename", and then this exception raises: Exception in Tkinter callback Traceback (most recent call last): File "/home/python/python/3.4/Lib/tkinter/__init__.py", line 1475, in __call__ return self.func(*args) File "/home/python/python/3.4/Lib/idlelib/EditorWindow.py", line 680, in open_module self.flist.open(file_path) UnboundLocalError: local variable 'file_path' referenced before assignment Serhiy's review comments on the patch about adding "return" in those three places does fix that problem. Attached is a revision to include Serhiy's suggestions. ---------- Added file: http://bugs.python.org/file30376/imp_remove_rev1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 02:19:15 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 00:19:15 +0000 Subject: [issue706406] fix bug #685846: raw_input defers signals Message-ID: <1369527555.03.0.732158604099.issue706406@psf.upfronthosting.co.za> Mark Lawrence added the comment: Bump this as IIRC other issues discussing SIGINT handling have been processed recently. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 02:23:03 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 00:23:03 +0000 Subject: [issue749722] isinstance and weakref proxies. Message-ID: <1369527783.14.0.0383244967454.issue749722@psf.upfronthosting.co.za> Mark Lawrence added the comment: Good to see that people are really interested in this :( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 02:28:27 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 00:28:27 +0000 Subject: [issue766910] fix one or two bugs in trace.py Message-ID: <1369528107.05.0.647069627304.issue766910@psf.upfronthosting.co.za> Mark Lawrence added the comment: Just a gentle bump. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 02:30:10 2013 From: report at bugs.python.org (Matthew Barnett) Date: Sun, 26 May 2013 00:30:10 +0000 Subject: [issue7940] re.finditer and re.findall should support negative end positions In-Reply-To: <1266329075.25.0.639780854585.issue7940@psf.upfronthosting.co.za> Message-ID: <1369528210.15.0.868436151486.issue7940@psf.upfronthosting.co.za> Matthew Barnett added the comment: I've attached a patch. ---------- keywords: +patch Added file: http://bugs.python.org/file30377/issue7940.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 02:42:00 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 00:42:00 +0000 Subject: [issue814253] Grouprefs in lookbehind assertions Message-ID: <1369528920.11.0.266477137042.issue814253@psf.upfronthosting.co.za> Mark Lawrence added the comment: Can this be closed as a result of work done via #2636 or must it remain open? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 02:52:26 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 26 May 2013 00:52:26 +0000 Subject: [issue16832] Expose cache validity checking support in ABCMeta In-Reply-To: <1357011504.56.0.782130595735.issue16832@psf.upfronthosting.co.za> Message-ID: <1369529546.17.0.247745175126.issue16832@psf.upfronthosting.co.za> Nick Coghlan added the comment: The reason I switched from suggesting an attribute/property to a module level function is because we don't really support properties for process global state. That's why sys has so many getters in it - to make them properties, you would have to add a class object to act as a holder for the property. In this case, we appear to have a singleton that could hold the property (ABCMeta), which is why my original suggestion was to use an ABCMeta attribute. However, what I realised yesterday is that because ABCMeta is a type subclass, it means the only way to make the attribute a property in the future would be to add a metametaclass to hold the property definition. Once I realised that... "if the implementation is hard to explain, it's a bad idea" tipped me over the edge into preferring a simple module level getter function that supported exactly the use cases we care about :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 02:57:26 2013 From: report at bugs.python.org (Matthew Barnett) Date: Sun, 26 May 2013 00:57:26 +0000 Subject: [issue814253] Grouprefs in lookbehind assertions Message-ID: <1369529846.85.0.823272982923.issue814253@psf.upfronthosting.co.za> Matthew Barnett added the comment: Issue #2636 resulted in the regex module, which supports variable-length look-behinds. I don't know how much work it would take even to put a limited fixed-length look-behind fix for this into the re module, so I'm afraid the issue must remain open. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 02:59:30 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 00:59:30 +0000 Subject: [issue821862] ftplib: Strict RFC 959 (telnet in command channel) Message-ID: <1369529969.99.0.60007931326.issue821862@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- versions: +Python 2.7, Python 3.3, Python 3.4 -Python 2.6, Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 03:02:58 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 01:02:58 +0000 Subject: [issue877121] configure detects incorrect compiler optimization Message-ID: <1369530178.74.0.433209428322.issue877121@psf.upfronthosting.co.za> Mark Lawrence added the comment: Who is best placed to backport the fix? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 03:08:31 2013 From: report at bugs.python.org (Roger Serwy) Date: Sun, 26 May 2013 01:08:31 +0000 Subject: [issue17658] pythonw.exe crashes on opening IDLE In-Reply-To: <1365393115.5.0.931092283515.issue17658@psf.upfronthosting.co.za> Message-ID: <1369530511.91.0.430827826836.issue17658@psf.upfronthosting.co.za> Roger Serwy added the comment: I'm closing this issue due since it's root problem is a misconfigured environment variable. ---------- resolution: -> works for me status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 03:10:15 2013 From: report at bugs.python.org (Roger Serwy) Date: Sun, 26 May 2013 01:10:15 +0000 Subject: [issue17658] pythonw.exe crashes on opening IDLE In-Reply-To: <1365393115.5.0.931092283515.issue17658@psf.upfronthosting.co.za> Message-ID: <1369530615.74.0.571509143591.issue17658@psf.upfronthosting.co.za> Roger Serwy added the comment: s/it's/its ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 04:29:14 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 02:29:14 +0000 Subject: [issue923697] SAX2 'property_encoding' feature not supported Message-ID: <1369535354.48.0.0349527167801.issue923697@psf.upfronthosting.co.za> Mark Lawrence added the comment: This is still an issue so the sax handler module property_encoding attribute be set to what URL? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 04:56:14 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 02:56:14 +0000 Subject: [issue967161] pty.spawn() enhancements Message-ID: <1369536974.44.0.841761511527.issue967161@psf.upfronthosting.co.za> Mark Lawrence added the comment: So #2489 broke at least one buildbot and this has to stay open for an enhancement request. Frankly it all confuses the hell out of me, could someone please explain in words of one syllable or less, thanks. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 04:56:28 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 26 May 2013 02:56:28 +0000 Subject: [issue16832] Expose cache validity checking support in ABCMeta In-Reply-To: <1357011504.56.0.782130595735.issue16832@psf.upfronthosting.co.za> Message-ID: <1369536988.3.0.297057848528.issue16832@psf.upfronthosting.co.za> ?ric Araujo added the comment: About future-proofing: do we want to document that the token is an opaque integer (as is done now) or just an opaque object that supports equality comparisons? ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 04:59:01 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 02:59:01 +0000 Subject: [issue940286] pydoc.Helper.help() ignores input/output init parameters Message-ID: <1369537141.55.0.465852516836.issue940286@psf.upfronthosting.co.za> Mark Lawrence added the comment: One commit already so presumably not too much effort needed to close this one. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 05:20:23 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Sun, 26 May 2013 03:20:23 +0000 Subject: [issue18047] Descriptors get invoked in old-style objects and classes In-Reply-To: <1369373983.58.0.00587959802813.issue18047@psf.upfronthosting.co.za> Message-ID: <1369538423.59.0.811252609605.issue18047@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 05:25:28 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 03:25:28 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1369538728.22.0.00479149685754.issue5124@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: +BreamoreBoy, roger.serwy, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 05:29:24 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 03:29:24 +0000 Subject: [issue7776] httplib.py: ._tunnel() broken In-Reply-To: <1264394042.86.0.571652227077.issue7776@psf.upfronthosting.co.za> Message-ID: <1369538964.41.0.515177399393.issue7776@psf.upfronthosting.co.za> Mark Lawrence added the comment: Cameron could you provide a patch for this? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 05:32:51 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 03:32:51 +0000 Subject: [issue7803] setup hangs on disk space requirements In-Reply-To: <1264761765.74.0.819824298395.issue7803@psf.upfronthosting.co.za> Message-ID: <1369539171.35.0.915671685653.issue7803@psf.upfronthosting.co.za> Mark Lawrence added the comment: In 12 years of installing Python on Windows I've never seen this problem. Unless others have seen this and/or it's reproducible I'd suggest this is closed. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 05:36:35 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 03:36:35 +0000 Subject: [issue5664] 2to3 wont convert Cookie.Cookie properly In-Reply-To: <1238642568.2.0.229238012255.issue5664@psf.upfronthosting.co.za> Message-ID: <1369539395.28.0.19154295069.issue5664@psf.upfronthosting.co.za> Mark Lawrence added the comment: I'm assuming msg98615 is correct so this can be closed. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 05:40:38 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 03:40:38 +0000 Subject: [issue7442] _localemodule.c: str2uni() with different LC_NUMERIC and LC_CTYPE In-Reply-To: <1260009859.57.0.721297634888.issue7442@psf.upfronthosting.co.za> Message-ID: <1369539638.33.0.932591883619.issue7442@psf.upfronthosting.co.za> Mark Lawrence added the comment: Could we have a patch review please. Also note that #5905 has been closed. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 05:44:47 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 26 May 2013 03:44:47 +0000 Subject: [issue18055] Stop using imp in IDLE In-Reply-To: <1369496414.51.0.562875229152.issue18055@psf.upfronthosting.co.za> Message-ID: <1369539887.18.0.109069445018.issue18055@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Brett, you misunderstood somethings. I want to apply now to 3.3 and 3.4. This is the right time now that 3.2 final maintenance is out. (In any case, we are no longer patching it. 2.7 gets improvements on a 'reasonable best effort' basis.) It is also clearer and can be easily 'translated' into the skeleton of a testcase. Roger, ditto. But the intent is clear to me. On my Windows, trying to load 'sys' does bring up the 'source' message box, but without 'return', it next triggers the 'loader' message. A bad name gets all three boxes. Anyway, another example of why to test on more than one OS (assuming you did not use Windows). Another change: I think "not a source-based module" should be 'not a Python-coded module'. The intent of the feature is to open any python-coded module that can be imported. C-coded modules are also, ultimately, source-based. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 05:48:37 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 26 May 2013 03:48:37 +0000 Subject: [issue18064] IDLE: add current directory to open_module In-Reply-To: <1369517780.56.0.941397989466.issue18064@psf.upfronthosting.co.za> Message-ID: <1369540117.58.0.797482167205.issue18064@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Code also suggests that this function should be elsewhere, such as in iobinding. This should be in the same place as regular open, wherever that is, since it is an alternative open. Document should be upgraded a bit: "Load module opens Python-coded modules on sys.path in an editor window. The default name is the currently selected text, if any." Tests should be added with this issue. This is the smallest dialog, and the structure of the revised code (#18055) gives a skeleton for a testcase: test_python_module (window open), test_builtin_module (Exception), test_bad_path (different Exception), and maybe even test_bad loader. We should look at tkinter tests for simulating name entry and click. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 05:51:41 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 03:51:41 +0000 Subject: [issue6871] decimal.py: more format issues In-Reply-To: <1252512442.21.0.45305758987.issue6871@psf.upfronthosting.co.za> Message-ID: <1369540301.45.0.171852081427.issue6871@psf.upfronthosting.co.za> Mark Lawrence added the comment: If I'm reading this correctly only issue 2 is outstanding. Opinions please gentlemen. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 05:54:49 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 26 May 2013 03:54:49 +0000 Subject: [issue18055] Stop using imp in IDLE In-Reply-To: <1369496414.51.0.562875229152.issue18055@psf.upfronthosting.co.za> Message-ID: <1369540489.76.0.0374286665779.issue18055@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Roger, sorry, I did not read your message completely. When I open from the console intepreter, I also get the traceback; same behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 06:06:02 2013 From: report at bugs.python.org (Renato Silva) Date: Sun, 26 May 2013 04:06:02 +0000 Subject: [issue12641] Remove -mno-cygwin from distutils In-Reply-To: <1311699751.35.0.569127767575.issue12641@psf.upfronthosting.co.za> Message-ID: <1369541162.48.0.234396140038.issue12641@psf.upfronthosting.co.za> Renato Silva added the comment: > In context it should be clear that the statement "in gcc 4.x it > produces an error preventing build" refers to Cygwin's gcc and not > MinGW's. Which gcc are you referring to? If it refers to Cygwin only, sorry then. However, didn't folks said in MinGW thread that they didn't touch anything about such flag there? If so, then how can it have been removed later in 4.5 or 4.6 instead of 4.0 like in Cygwin? > Yes gcc 4.6 would fail because it won't accept the -mno-cygwin option. > That does not mean that any other MinGW gcc ever *required* the > -mno-cygwin option for anything. Again, I was not saying it was required *for MinGW*, but *for building Pidgin*. Note that I'm not saying either that their use of such option was ever meaningful in the build process (in fact, they have removed such flag while still using 4.4, indicating that it was really useless). > Yes but that particular error message is coming from Cygwin's gcc not > MinGW. As stated by the Pidgin dev in that message the OP does not > know which compiler they are using: > http://pidgin.im/pipermail/support/2011-December/011159.html We actually cannot confirm whether the GCC was from Cygwin, MSYS or Pidgin build box (the correct), and which version. It could be from Cygwin, but still my point stands, that the Pidgin developer does confirm that GCC 4.4 from MinGW *does* accept that flag. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 06:06:42 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 26 May 2013 04:06:42 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1369541202.75.0.00732707880438.issue5124@psf.upfronthosting.co.za> Terry J. Reedy added the comment: On Win7, I get the replacement behavior. I get the same in Notepad and Firefox, so this may be standard Windows behavior. What is standard in other linex and mac apps? If the tk difference is a standard platform difference, I might think we should leave it alone. ---------- nosy: +Todd.Rovito stage: -> test needed type: -> behavior versions: +Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 06:27:54 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 26 May 2013 04:27:54 +0000 Subject: [issue16832] Expose cache validity checking support in ABCMeta In-Reply-To: <1369536988.3.0.297057848528.issue16832@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: The latter is probably better (it should just need a slight tweak to the wording in the docs and docstring) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 07:31:55 2013 From: report at bugs.python.org (Todd Rovito) Date: Sun, 26 May 2013 05:31:55 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1369546315.12.0.548217801418.issue5124@psf.upfronthosting.co.za> Todd Rovito added the comment: "What is standard in other linex and mac apps?" -On Mac OS X 10.8.3 TextEdit I get the replacement behavior -On Linux CentOS 6.4 gedit I get the replacement behavior -On IDLE under the latest 3.4 pull I get the replacement behavior with Max OS X 10.8.3 -On IDLE under the latest 3.4 pull I get the eggsspam behavior with Linux CentOS 6.4 as Weeble described in the original bug report So from my perspective Linux is behaving differently than Windows and Mac OS X. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 07:57:14 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 May 2013 05:57:14 +0000 Subject: [issue18059] Add multibyte encoding support to pyexpat In-Reply-To: <1369507288.26.0.471852341095.issue18059@psf.upfronthosting.co.za> Message-ID: <1369547834.44.0.504591556889.issue18059@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patch updated. Fixed an error in the encodings generator and added additional compatibility check for 8-bit encodings in PyUnknownEncodingHandler(). Feel free to bikesheed the encodings generator. ---------- Added file: http://bugs.python.org/file30378/pyexpat_multibyte_encodings_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 07:57:43 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 May 2013 05:57:43 +0000 Subject: [issue18059] Add multibyte encoding support to pyexpat In-Reply-To: <1369507288.26.0.471852341095.issue18059@psf.upfronthosting.co.za> Message-ID: <1369547863.55.0.88640369263.issue18059@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file30373/pyexpat_multibyte_encodings.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 07:57:57 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 May 2013 05:57:57 +0000 Subject: [issue18059] Add multibyte encoding support to pyexpat In-Reply-To: <1369507288.26.0.471852341095.issue18059@psf.upfronthosting.co.za> Message-ID: <1369547877.62.0.380955103605.issue18059@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file30368/expat_encodings.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 07:58:30 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 May 2013 05:58:30 +0000 Subject: [issue18059] Add multibyte encoding support to pyexpat In-Reply-To: <1369507288.26.0.471852341095.issue18059@psf.upfronthosting.co.za> Message-ID: <1369547910.41.0.787617280494.issue18059@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 08:12:05 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 May 2013 06:12:05 +0000 Subject: [issue18061] m68k Python 3.3 test results In-Reply-To: <1369515304.6.0.15163680976.issue18061@psf.upfronthosting.co.za> Message-ID: <1369548725.3.0.751964739597.issue18061@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > >Do you run tests as root? > Yes. Well, this is issue17746. > >Is m68k big-endian? > Yes: ILP32 big-endian, 2-byte aligned. Please open a new issue for str.find bug. ---------- dependencies: +m68k FPU precision issue, m68k struct alignment issue vs. PyException_HEAD, test_shutil.TestWhich.test_non_matching_mode fails when running as root _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 08:52:42 2013 From: report at bugs.python.org (Ned Deily) Date: Sun, 26 May 2013 06:52:42 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1369551162.34.0.227277647433.issue5124@psf.upfronthosting.co.za> Ned Deily added the comment: X11-based Tk follows general X11 practice with regard to text pasting. See http://wiki.tcl.tk/3771 for some background. Old school X11 users expect pasting to work that way. This is yet another instance where Tk attempts to conform to the platform it is running on. I recommend closing this issue as X11 Tk (and, hence, IDLE) has behaved like this forever and changing it would be painful for many current X11 IDLE users. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 08:55:50 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 May 2013 06:55:50 +0000 Subject: [issue17746] test_shutil.TestWhich.test_non_matching_mode fails when running as root In-Reply-To: <1366099998.54.0.409643145074.issue17746@psf.upfronthosting.co.za> Message-ID: <1369551350.49.0.619075717186.issue17746@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch which skips test_non_matching_mode when run as root (for early skip in discovery stage and for more appropriate for this case report) and when run on OS or FS which doesn't support read-only files (should cover all other cases). ---------- components: +Tests -Library (Lib) keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file30379/test_shutil_skip_test_non_matching_mode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 09:08:48 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 May 2013 07:08:48 +0000 Subject: [issue18059] Add multibyte encoding support to pyexpat In-Reply-To: <1369507288.26.0.471852341095.issue18059@psf.upfronthosting.co.za> Message-ID: <1369552128.17.0.240201642683.issue18059@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file30378/pyexpat_multibyte_encodings_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 09:11:51 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 May 2013 07:11:51 +0000 Subject: [issue18059] Add multibyte encoding support to pyexpat In-Reply-To: <1369507288.26.0.471852341095.issue18059@psf.upfronthosting.co.za> Message-ID: <1369552311.94.0.0222598600606.issue18059@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file30380/pyexpat_multibyte_encodings_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 09:13:35 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 May 2013 07:13:35 +0000 Subject: [issue17746] test_shutil.TestWhich.test_non_matching_mode fails when running as root In-Reply-To: <1366099998.54.0.409643145074.issue17746@psf.upfronthosting.co.za> Message-ID: <1369552415.51.0.305738394319.issue17746@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 09:40:48 2013 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 26 May 2013 07:40:48 +0000 Subject: [issue18062] m68k FPU precision issue In-Reply-To: <1369515651.34.0.291697920686.issue18062@psf.upfronthosting.co.za> Message-ID: <1369554048.65.0.534599691478.issue18062@psf.upfronthosting.co.za> Mark Dickinson added the comment: > The problem with changing the FPUCW on i387 is that it changes > from 64/15 bit mantissa/exponent to 53/15 bit which is still > not the 53/11 bit of IEEE double, so you *still* get double- > rounding issues (with denormal numbers only, I guess) because > the internal precision is still higher. That's not a problem for dtoa.c, at least: dtoa.c avoids any use of subnormals in intermediate calculations. It's not really too much of a problem for Python in general, either. Windows typically operates in this mode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 12:16:44 2013 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 26 May 2013 10:16:44 +0000 Subject: [issue18062] m68k FPU precision issue In-Reply-To: <1369515651.34.0.291697920686.issue18062@psf.upfronthosting.co.za> Message-ID: <1369563404.2.0.769368120092.issue18062@psf.upfronthosting.co.za> Mark Dickinson added the comment: It's also an option not to use dtoa.c: Python still has fallback code that uses the OS double <-> char* conversions for the case where the configuration step can't figure out how to change the FPU control word. In that case compilation should still succeed, and the resulting Python would show: >>> import sys >>> sys.float_repr_style 'legacy' If there are tests failing with the 'legacy' mode, that may just indicate buggy tests that haven't been properly marked as depending on the short float repr. (E.g., by decorating with "@unittest.skipUnless(getattr(sys, 'float_repr_style', '') == 'short'"), or poorly-designed tests that could be rewritten. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 12:31:28 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 May 2013 10:31:28 +0000 Subject: [issue18059] Add multibyte encoding support to pyexpat In-Reply-To: <1369507288.26.0.471852341095.issue18059@psf.upfronthosting.co.za> Message-ID: <1369564288.56.0.100007324054.issue18059@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Patch updated. Yet some tests added and yet some bugs fixed. ---------- Added file: http://bugs.python.org/file30381/pyexpat_multibyte_encodings_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 12:31:37 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 May 2013 10:31:37 +0000 Subject: [issue18059] Add multibyte encoding support to pyexpat In-Reply-To: <1369507288.26.0.471852341095.issue18059@psf.upfronthosting.co.za> Message-ID: <1369564297.77.0.527322713952.issue18059@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file30380/pyexpat_multibyte_encodings_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 12:35:19 2013 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 26 May 2013 10:35:19 +0000 Subject: [issue16580] Add examples to int.to_bytes and int.from_bytes In-Reply-To: <1354217109.61.0.534443148437.issue16580@psf.upfronthosting.co.za> Message-ID: <1369564519.03.0.293486843314.issue16580@psf.upfronthosting.co.za> Mark Dickinson added the comment: The `from_bytes` example code looks fine to me, except that I'd probably use `enumerate` in the iteration; i.e., sum(b << 8*i for i, b in enumerate(little_ordered)) instead of sum(little_ordered[i] << i*8 for i in range(len(little_ordered))) Also, in: if signed and little_ordered and (little_ordered[-1] & 0x80): I wondered why you needed the `little_ordered` check. But I see that `int.from_bytes(b'', 'little', signed=True)` produces `0`, which is a little bit disappointing: I was expecting an exception. (A signed format should have a sign bit, which is impossible if the length of the byte string is 0.) The `to_bytes` example code is missing range checks for the input. It may be clearer to simply state that in the docs, instead of modifying the example code to add the range checks. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 12:43:37 2013 From: report at bugs.python.org (Tim Golden) Date: Sun, 26 May 2013 10:43:37 +0000 Subject: [issue18040] SIGINT catching regression on windows in 2.7 In-Reply-To: <1369513838.33.0.115378342996.issue18040@psf.upfronthosting.co.za> Message-ID: <51A1E754.3070309@timgolden.me.uk> Tim Golden added the comment: Correction: I see the desired behaviour in 3.3/3.4 which is where the overhaul to Ctrl-C handling on Windows was applied. I still can't see it in 2.6 or in 3.1/3.2 on Windows. The problem lies in the fact that PyOS_InterruptOccurred and PyErr_CheckSignals from signalmodule.c both check and reset signalled events. The former is used (solely within myreadline.c) to determine whether a SIGINT has fired; the latter is called in many different places to initiate Python's signal-handling but doesn't return any information about which signal fired. The check in line 70 of Parser/myreadline.c determines that a SIGINT signal has fired, but clears that signal at the same time. Any later call to PyErr_CheckSignals will not see that the SIGINT had fired. The 3.3+ situation is different, as a Windows event is the indication that SIGINT was raised, and the check for this doesn't affect the internal Handlers table which is examined by PyErr_CheckSignals. The attached patch to signalmodule.c appears to produce SIGINT signal handling as desired. Tested only on Windows. It's not clear whether any unittest could be produced for this kind of functionality. ---------- keywords: +patch Added file: http://bugs.python.org/file30382/signalmodule.patch _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff --git a/Modules/signalmodule.c b/Modules/signalmodule.c --- a/Modules/signalmodule.c +++ b/Modules/signalmodule.c @@ -974,7 +974,6 @@ if (PyThread_get_thread_ident() != main_thread) return 0; #endif - Handlers[SIGINT].tripped = 0; return 1; } return 0; From report at bugs.python.org Sun May 26 12:50:40 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 10:50:40 +0000 Subject: [issue8112] xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0) deprecated function "inspect.getargspec()" In-Reply-To: <1268242672.24.0.332132369161.issue8112@psf.upfronthosting.co.za> Message-ID: <1369565440.69.0.741004977032.issue8112@psf.upfronthosting.co.za> Mark Lawrence added the comment: Tormen could you provide a patch for this? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 12:57:16 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 10:57:16 +0000 Subject: [issue8238] Proxy handling In-Reply-To: <1269588795.92.0.67904846936.issue8238@psf.upfronthosting.co.za> Message-ID: <1369565836.72.0.604725677783.issue8238@psf.upfronthosting.co.za> Mark Lawrence added the comment: I can't even try to reproduce this as I've no corporate network as a test bed. Is this still an issue with Python 2.7 or the reworked urllib in Python 3.x? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 13:02:14 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 11:02:14 +0000 Subject: [issue1693050] \w not helpful for non-Roman scripts Message-ID: <1369566134.15.0.721593134673.issue1693050@psf.upfronthosting.co.za> Mark Lawrence added the comment: Am I correct in saying that this must stay open as it targets the re module but as given in msg81221 is fixed in the new regex module? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 13:08:14 2013 From: report at bugs.python.org (koobs) Date: Sun, 26 May 2013 11:08:14 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1369566494.41.0.172414576999.issue15745@psf.upfronthosting.co.za> koobs added the comment: I've moved both of the FreeBSD buildbot slaves off their ZFS-backed home directories and back to good old UFS. I want to ensure FreeBSD support continues to improve, and having slaves get noticed when they fail or regress with ongoing development is a big part of that. This is hard to achieve without movement on this issue, either in the form of a conditional skip, workaround or ultimate resolution ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 13:15:01 2013 From: report at bugs.python.org (koobs) Date: Sun, 26 May 2013 11:15:01 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1369566901.11.0.471190235766.issue15745@psf.upfronthosting.co.za> koobs added the comment: I'm happy to move them back upon request, or create a FreeBSD/ZFS buildslave specially for the job, just let me know. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 13:19:53 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Sun, 26 May 2013 11:19:53 +0000 Subject: [issue8083] urllib proxy interface is too limited In-Reply-To: <1267960974.57.0.282582505856.issue8083@psf.upfronthosting.co.za> Message-ID: <1369567193.18.0.732050576233.issue8083@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang versions: +Python 3.4 -Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 13:57:45 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 11:57:45 +0000 Subject: [issue2554] test_ioctl failed Python 2.6a2 Solaris 10 SUN C In-Reply-To: <1207339545.74.0.114757625359.issue2554@psf.upfronthosting.co.za> Message-ID: <1369569465.11.0.303808748464.issue2554@psf.upfronthosting.co.za> Mark Lawrence added the comment: is this still a problem with 2.7 or 3.x? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 14:05:22 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 26 May 2013 12:05:22 +0000 Subject: [issue749722] isinstance and weakref proxies. Message-ID: <1369569922.73.0.870045435859.issue749722@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Mark, this kind of message isn't useful. The general problem here is not whether it is interesting or not, it is whether it is desireable. My own take is that it would threaten to break existing code, and that making the proxy *too* transparent would be detrimental to debuggability. But people may disagree, and this can only be solved by a discussion on e.g. python-dev. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 14:05:53 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 12:05:53 +0000 Subject: [issue8191] Make arg0 required argument in os.execl* functions In-Reply-To: <1269195535.51.0.216283779059.issue8191@psf.upfronthosting.co.za> Message-ID: <1369569953.1.0.100838865427.issue8191@psf.upfronthosting.co.za> Mark Lawrence added the comment: What conclusions were drawn on python-dev about this issue? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 14:27:23 2013 From: report at bugs.python.org (Andreas Schwab) Date: Sun, 26 May 2013 12:27:23 +0000 Subject: [issue18062] m68k FPU precision issue In-Reply-To: (Thorsten Glaser's message of "Sat, 25 May 2013 22:19:09 +0000 (UTC)") Message-ID: <87hahqgc48.fsf@hase.home> Andreas Schwab added the comment: Thorsten Glaser writes: > root at ara3:~ # ./a.out > test#1 fail: 1.00000000000000000E+00 > test#2 fail: 1.00000000000000040E+16 > changing FPU control word from 00000000 to 00000080 => 00000080 > test#1 fail: 1.00000000000000000E+00 > test#2 fail: 1.00000000000000040E+16 What is the exact sequence of fpu insns? Andreas. ---------- nosy: +schwab _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 14:28:39 2013 From: report at bugs.python.org (A.M. Kuchling) Date: Sun, 26 May 2013 12:28:39 +0000 Subject: [issue967161] pty.spawn() enhancements Message-ID: <1369571319.86.0.648936590839.issue967161@psf.upfronthosting.co.za> A.M. Kuchling added the comment: It looks like the problem on OpenIndiana with #2489 was fixed. As of May 25th, the 3.x build on OpenIndiana is a green. http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.x/builds/5962 So, 2) is a misunderstanding and 1) was carried out in #2489 (despite any objections to putting a feature enhancement in a bugfix, the feature is still there in trunk). Therefore, I'm going to close this bug because there's nothing to do. ---------- resolution: -> out of date stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 14:32:17 2013 From: report at bugs.python.org (A.M. Kuchling) Date: Sun, 26 May 2013 12:32:17 +0000 Subject: [issue18066] Remove SGI-specific code from pty.py Message-ID: <1369571537.69.0.0137495343006.issue18066@psf.upfronthosting.co.za> New submission from A.M. Kuchling: pty.py contains some code that tries to do 'import sgi' and then does something SGI-specific. sgimodule.c was dropped in 3.0alpha1, so this code is now useless. The attached patch removes it; I'm posting the code review largely in case someone wants to suggest changes to the docstring. ---------- files: remove-sgi.txt messages: 190083 nosy: akuchling priority: normal severity: normal stage: patch review status: open title: Remove SGI-specific code from pty.py type: resource usage Added file: http://bugs.python.org/file30383/remove-sgi.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 14:37:24 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 12:37:24 +0000 Subject: [issue8508] 2to3 fixer for gettext's .ugettext In-Reply-To: <1272034086.61.0.0547716106043.issue8508@psf.upfronthosting.co.za> Message-ID: <1369571844.13.0.270084202484.issue8508@psf.upfronthosting.co.za> Mark Lawrence added the comment: Barry, would you like to follow up on this? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 14:51:43 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 12:51:43 +0000 Subject: [issue6483] Modules are not deallocated correctly if m_size = -1 In-Reply-To: <1247573035.84.0.508855898217.issue6483@psf.upfronthosting.co.za> Message-ID: <1369572703.27.0.326940203711.issue6483@psf.upfronthosting.co.za> Mark Lawrence added the comment: Please correct me if I'm wrong but I believe this applies to all Python 3 versions. ---------- nosy: +BreamoreBoy versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 14:58:05 2013 From: report at bugs.python.org (mirabilos) Date: Sun, 26 May 2013 12:58:05 +0000 Subject: [issue18062] m68k FPU precision issue In-Reply-To: <87hahqgc48.fsf@hase.home> Message-ID: mirabilos added the comment: Mark Dickinson dixit: >If there are tests failing with the 'legacy' mode, that may just >indicate buggy tests that haven't been properly marked as depending on >the short float repr. (E.g., by decorating with I think that?s what we?re seeing here. Python 3.3.1 (default, May 10 2013, 02:52:57) [GCC 4.6.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.float_repr_style 'legacy' Andreas Schwab dixit: >What is the exact sequence of fpu insns? That?s all gcc-generated code and a system header? In main (after commenting out the second getcw and printf): jsr runtests #APP | 34 "x.c" 1 fmove.l %fpcr, %d2 | 0 "" 2 #NO_APP move.l %d2,-4(%fp) move.l #128,-8(%fp) #APP | 40 "x.c" 1 fmove.l -8(%fp), %fpcr | 0 "" 2 #NO_APP jsr runtests And the subroutine: runtests: link.w %fp,#-24 move.l %d3,-(%sp) move.l %d2,-(%sp) move.l #1072693247,-8(%fp) move.l #-1,-4(%fp) move.l -8(%fp),%d0 move.l -4(%fp),%d1 fmovecr #0x32,%fp0 move.l %d1,-(%sp) move.l %d0,-(%sp) fmove.d (%sp)+,%fp1 fdiv.x %fp1,%fp0 fmove.d %fp0,-(%sp) move.l (%sp)+,%d0 move.l (%sp)+,%d1 move.l %d0,-16(%fp) move.l %d1,-12(%fp) move.l -16(%fp),%d2 move.l -12(%fp),%d3 move.l -16(%fp),%a0 move.l -12(%fp),%a1 move.l #1072693248,%d0 clr.l %d1 move.l %a1,-(%sp) move.l %a0,-(%sp) fmove.d (%sp)+,%fp0 move.l %d1,-(%sp) move.l %d0,-(%sp) fmove.d (%sp)+,%fp1 fcmp.x %fp1,%fp0 fjne .L2 move.l #.LC0,%d0 jra .L3 .L2: move.l #.LC1,%d0 .L3: move.l #.LC2,%d1 move.l %d3,-(%sp) move.l %d2,-(%sp) move.l %d0,-(%sp) move.l %d1,-(%sp) jsr printf lea (16,%sp),%sp move.l #1128383353,-8(%fp) move.l #937459712,-4(%fp) move.l #1074266106,-16(%fp) move.l #-1043161657,-12(%fp) move.l -8(%fp),%a0 move.l -4(%fp),%a1 move.l -16(%fp),%d0 move.l -12(%fp),%d1 move.l %a1,-(%sp) move.l %a0,-(%sp) fmove.d (%sp)+,%fp0 move.l %d1,-(%sp) move.l %d0,-(%sp) fmove.d (%sp)+,%fp1 fadd.x %fp1,%fp0 fmove.d %fp0,-(%sp) move.l (%sp)+,%d0 move.l (%sp)+,%d1 move.l %d0,-24(%fp) move.l %d1,-20(%fp) move.l -24(%fp),%a0 move.l -20(%fp),%a1 move.l -24(%fp),%d0 move.l -20(%fp),%d1 move.l %d1,-(%sp) move.l %d0,-(%sp) fmove.d (%sp)+,%fp0 fcmp.d #0x4341c37937e08002,%fp0 fjne .L4 move.l #.LC0,%d0 jra .L5 .L4: move.l #.LC1,%d0 .L5: move.l #.LC3,%d1 move.l %a1,-(%sp) move.l %a0,-(%sp) move.l %d0,-(%sp) move.l %d1,-(%sp) jsr printf lea (16,%sp),%sp move.l -32(%fp),%d2 move.l -28(%fp),%d3 unlk %fp rts bye, //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 15:17:51 2013 From: report at bugs.python.org (mirabilos) Date: Sun, 26 May 2013 13:17:51 +0000 Subject: [issue18062] m68k FPU precision issue In-Reply-To: <51A2086D.4080400@Vivier.EU> Message-ID: mirabilos added the comment: Laurent Vivier dixit: > BTW, the result on a real CPU (68040) is : 68881 even ;-) > test#1 fail: 1.00000000000000000E+00 > test#2 fail: 1.00000000000000040E+16 > changing FPU control word from 00000000 to 00000080 => 00000080 > test#1 good: 1.00000000000000022E+00 > test#2 good: 1.00000000000000020E+16 Thanks, that?s what I was guessing. I get similar results on i386. Now as additional data point, UAE/WinUAE/etc. would be interesting. Even so, I?d be very reluctant to add this code to Python to make it change the FPU mode, because Python is heavily used in Debian, and getting varying results between emulation and bare metal is something we?d like to not have? bye, //mirabilos -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 15:30:08 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 26 May 2013 13:30:08 +0000 Subject: [issue766910] fix one or two bugs in trace.py Message-ID: <1369575008.6.0.874807885758.issue766910@psf.upfronthosting.co.za> Eli Bendersky added the comment: Ah, no time, no time... :-/ I may get back to this in the future. Bumping to more relevant versions for now. ---------- versions: +Python 3.3, Python 3.4 -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 15:36:13 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 26 May 2013 13:36:13 +0000 Subject: [issue18034] Last two entries in the programming FAQ are out of date (import related) In-Reply-To: <1369244115.61.0.298181094271.issue18034@psf.upfronthosting.co.za> Message-ID: <1369575373.45.0.0176887209024.issue18034@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 15:36:32 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 26 May 2013 13:36:32 +0000 Subject: [issue18036] "How do I create a .pyc file?" FAQ entry is out of date In-Reply-To: <1369244271.04.0.495588356743.issue18036@psf.upfronthosting.co.za> Message-ID: <1369575392.71.0.825377246835.issue18036@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 15:40:32 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 26 May 2013 13:40:32 +0000 Subject: [issue18047] Descriptors get invoked in old-style objects and classes In-Reply-To: <1369373983.58.0.00587959802813.issue18047@psf.upfronthosting.co.za> Message-ID: <1369575632.62.0.149415677868.issue18047@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 15:41:13 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 26 May 2013 13:41:13 +0000 Subject: [issue18044] Email headers do not properly decode to unicode. In-Reply-To: <1369310256.22.0.862828757307.issue18044@psf.upfronthosting.co.za> Message-ID: <1369575673.92.0.174307813151.issue18044@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 15:41:29 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 26 May 2013 13:41:29 +0000 Subject: [issue18043] No mention of `match.regs` in `re` documentation In-Reply-To: <1369308537.81.0.515783227267.issue18043@psf.upfronthosting.co.za> Message-ID: <1369575689.68.0.29473966302.issue18043@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- components: +Regular Expressions nosy: +ezio.melotti, mrabarnett _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 15:42:20 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 26 May 2013 13:42:20 +0000 Subject: [issue18042] Provide enum.unique class decorator In-Reply-To: <1369299378.37.0.789518154232.issue18042@psf.upfronthosting.co.za> Message-ID: <1369575740.59.0.0396466924134.issue18042@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 15:44:25 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 26 May 2013 13:44:25 +0000 Subject: [issue18033] Example for Profile Module shows incorrect method In-Reply-To: <1369235558.14.0.532987051887.issue18033@psf.upfronthosting.co.za> Message-ID: <1369575865.7.0.661213490173.issue18033@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +ezio.melotti stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 15:45:02 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 26 May 2013 13:45:02 +0000 Subject: [issue18032] set methods should specify whether they consume iterators "lazily" In-Reply-To: <1369223923.83.0.620034016791.issue18032@psf.upfronthosting.co.za> Message-ID: <1369575902.7.0.791112422983.issue18032@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- keywords: +easy nosy: +ezio.melotti stage: -> needs patch versions: +Python 3.3, Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 16:08:40 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 26 May 2013 14:08:40 +0000 Subject: [issue18066] Remove SGI-specific code from pty.py In-Reply-To: <1369571537.69.0.0137495343006.issue18066@psf.upfronthosting.co.za> Message-ID: <1369577320.23.0.580915785004.issue18066@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- components: +Library (Lib) versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 16:24:05 2013 From: report at bugs.python.org (Brett Cannon) Date: Sun, 26 May 2013 14:24:05 +0000 Subject: [issue17314] Stop using imp.find_module() in multiprocessing In-Reply-To: <1361994994.99.0.625564916049.issue17314@psf.upfronthosting.co.za> Message-ID: <1369578245.46.0.859067275103.issue17314@psf.upfronthosting.co.za> Brett Cannon added the comment: In the common case of SourceLoader it will set __loader__, __package__, __file__, and __cached__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 16:26:34 2013 From: report at bugs.python.org (mirabilos) Date: Sun, 26 May 2013 14:26:34 +0000 Subject: [issue18061] m68k Python 3.3 test results In-Reply-To: <1369548725.3.0.751964739597.issue18061@psf.upfronthosting.co.za> Message-ID: mirabilos added the comment: Serhiy Storchaka dixit: >> >Do you run tests as root? >> Yes. > >Well, this is issue17746. OK, I?ll re-run the tests as regular user (need to create one? ?) and with all those fixes applied, then we?ll have a look again. (This will take a while.) Thanks, //mirabilos -- Oh, ich hab mim Bauch Mittelklick gemacht, als ich nach dem Kaffee gegriffen habe? Cool, ich hab ne neue eMail-Signatur Sag doch sowas nich, wenn ich den Kaffee in der Hand habe! Gib mir nen Lappen! Schnell! Das kommt aber nicht mit in die Signatur! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 16:26:35 2013 From: report at bugs.python.org (mirabilos) Date: Sun, 26 May 2013 14:26:35 +0000 Subject: [issue18062] m68k FPU precision issue In-Reply-To: <51A20D81.3050404@Vivier.EU> Message-ID: mirabilos added the comment: Laurent Vivier dixit: > For the "etc" ;-) , in Qemu, I have: Hm, I thought qemu did not emulate an MMU? bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst ?ber *fs ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 16:44:28 2013 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 26 May 2013 14:44:28 +0000 Subject: [issue13772] listdir() doesn't work with non-trivial symlinks In-Reply-To: <1326312074.88.0.322514160628.issue13772@psf.upfronthosting.co.za> Message-ID: <1369579468.46.0.730361303195.issue13772@psf.upfronthosting.co.za> Jason R. Coombs added the comment: Since there's been no additional criticism or discussion on this matter, I'll plan to commit the proposed patch to restore target directory detection. Since the functionality was removed in a bugfix release, it should be acceptable to restore it in a bugfix release. I know 3.2 no longer gets non-security releases, so I'll port the patch to 3.3 and apply it to 3.3 and default. I'll plan to do this tomorrow unless there's further discussion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 16:56:39 2013 From: report at bugs.python.org (A.M. Kuchling) Date: Sun, 26 May 2013 14:56:39 +0000 Subject: [issue17700] Update Curses HOWTO for 3.4 In-Reply-To: <1365719687.97.0.644773548697.issue17700@psf.upfronthosting.co.za> Message-ID: <1369580199.88.0.721269555885.issue17700@psf.upfronthosting.co.za> A.M. Kuchling added the comment: I can't make sense of unget_wch. I used this test program: -------- import curses def main(stdscr): stdscr.addstr(0,0, "Key") stdscr.refresh() curses.ungetch(0x0149) while True: ch = stdscr.get_wch() stdscr.addstr(1,1, repr(ch) + ' ') if ch == 'q': break curses.wrapper(main) -------- If I use curses.unget_wch(chr(0x0149)), the following get_wch() call returns -119, not 0x149. The whole area of wide character support in curses is just a mystery, and I don't know how to resolve my questions. I'll close this item, since I have nothing further to add to the curses howto. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 17:04:59 2013 From: report at bugs.python.org (Jean Brouwers) Date: Sun, 26 May 2013 15:04:59 +0000 Subject: [issue2554] test_ioctl failed Python 2.6a2 Solaris 10 SUN C In-Reply-To: <1369569465.11.0.303808748464.issue2554@psf.upfronthosting.co.za> Message-ID: <08A48F41-32C0-42D1-85C4-88A9AE72E788@Gmail.com> Jean Brouwers added the comment: I haven't retested that yet, but I will as soon as can. /Jean Bouwers On May 26, 2013, at 7:57 AM, Mark Lawrence wrote: > > Mark Lawrence added the comment: > > is this still a problem with 2.7 or 3.x? > > ---------- > nosy: +BreamoreBoy > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 18:04:20 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 26 May 2013 16:04:20 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1369584260.79.0.902076558686.issue17947@psf.upfronthosting.co.za> Eli Bendersky added the comment: I tweaked the code a bit (no functionality changes, mostly cleanups and a bit of refactoring). Figured it will be easier to just send an updated patch than another review. The diff from patch 06 can be seen via the Rietveld interface. Also, after reading the code more carefully, I think we're doing a mistake by over-complicating it for the sake of custom enum metaclasses and over-customization (like auto numbering). The original point Guido raised against auto-numbering was too much magic in the implementation. Well, we already have that in Lib/enum.py - the code is so complex it seems fragile because of the tight coupling with many class and metaclass related protocols. Just defining a wholly new enum implementation that does something very specific seems simpler than customizing the existing one. I'd suggest we stick to the existing Enum + IntEnum, giving up the more complex customizations for now. It can always be added in the future if we see it's very important. ---------- Added file: http://bugs.python.org/file30384/pep-0435.07.eliben.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 18:07:39 2013 From: report at bugs.python.org (R. David Murray) Date: Sun, 26 May 2013 16:07:39 +0000 Subject: [issue8191] Make arg0 required argument in os.execl* functions In-Reply-To: <1269195535.51.0.216283779059.issue8191@psf.upfronthosting.co.za> Message-ID: <1369584459.95.0.967071146263.issue8191@psf.upfronthosting.co.za> R. David Murray added the comment: Mark, just asking that question doesn't really move the issue forward. Doing some research to see if there was any discussion on python-dev, and if not summarizing the issues and starting one, would be what could move the issue forward. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 18:10:39 2013 From: report at bugs.python.org (Roger Serwy) Date: Sun, 26 May 2013 16:10:39 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1369584639.88.0.667332666387.issue5124@psf.upfronthosting.co.za> Roger Serwy added the comment: There are many X11 applications that replace the selection with pasted text. GTK and Qt widgets behave that way. Here's a brief list: gedit (GTK), gummi (GTK), kate (Qt), texmaker (Qt). Tkinter, for me, has become increasingly frustrating due to these subtle platform differences. (See #14146, #13582, and many more that deal with Tk on Mac.) For IDLE, I consider these behavior differences bugs. The attached patch "fixes" this issue. ---------- keywords: +patch Added file: http://bugs.python.org/file30385/issue5124.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 18:29:11 2013 From: report at bugs.python.org (Shriramana Sharma) Date: Sun, 26 May 2013 16:29:11 +0000 Subject: [issue18067] In considering the current directory for importing modules, Python does not honour the output of os.getcwd() Message-ID: <1369585751.87.0.707349991887.issue18067@psf.upfronthosting.co.za> New submission from Shriramana Sharma: Hello. I first asked about this at https://groups.google.com/d/topic/comp.lang.python/ZOGwXGU_TV0/discussion and am only posting this issue due to no reply there. I am using Python 2.7.4 and Python 3.3.1 (default packages) on Kubuntu Raring. On both I experience this same bug. This bug has to do with a Python script called via a symlink. To illustrate it I have included a minimal test case tarball as an attachment. Just run sh test.sh at root of the extracted tree to see what's happening. I am quite unpleasantly surprised that when one calls a Python script via a symlink, and that script asks for a module to be imported, Python searches the directory in which the *target* of the link exists, and uses the version of the library present *there* if any, and raises an exception if not. It even follows a chain of symlinks. Any version of the library present in the same directory as the (user-called) symlink is ignored. This is totally counter-intuitive behaviour and should be treated as a bug and fixed. This is all the more frustrating since running print(os.getcwd()) from the same script correctly prints the current directory in which the *symlink* and not its target exists. (See output of the attached scripts.) Now the symlink is only a user-level file system convenience indicating that I create a virtual file in one place pointing to another file elsewhere. Whatever the rest of the contents of the directory containing the other file is immaterial to me -- I am only interested in the one file I am symlinking to. I am executing a script from a given directory. os.getcwd() correctly prints the path of that directory. I also have a library in that same directory for the script to import. I would expect Python to honour the output of os.getcwd() in doing import too. I read through http://docs.python.org/3/reference/import.html and didn't seem to find any explanation for the current illogical behaviour. (Please point out if I have missed it.) (Note that the same behaviour does not happen with hardlinks, probably since the filesystem itself shows the whole file as existing at the current location.) Output of the test.sh script: **** Trying english/run.py **** CWD: /tmp/symlink-bug/english Hello Shriramana! **** Trying english/run-link.py symlinked to ./run.py **** CWD: /tmp/symlink-bug/english Traceback (most recent call last): File "run-link.py", line 3, in from greet import greet ImportError: No module named greet **** Trying english/run-link-link.py symlinked to ./run-link.py symlinked to english/run.py **** CWD: /tmp/symlink-bug/english Hello Shriramana! **** Trying sanskrit/run-slink.py symlinked to english/run.py **** CWD: /tmp/symlink-bug/sanskrit Hello Shriramana! **** Trying sanskrit/run-hlink.py hardlinked to english/run.py **** CWD: /tmp/symlink-bug/sanskrit Namaste Shriramana! Expected output: (see esp items marked 1 and 2 below): **** Trying english/run.py **** CWD: /tmp/symlink-bug/english Hello Shriramana! 1 **** Trying english/run-link.py symlinked to ./run.py **** CWD: /tmp/symlink-bug/english Hello Shriramana! **** Trying english/run-link-link.py symlinked to ./run-link.py symlinked to english/run.py **** CWD: /tmp/symlink-bug/english Hello Shriramana! 2 **** Trying sanskrit/run-slink.py symlinked to english/run.py **** CWD: /tmp/symlink-bug/sanskrit Namaste Shriramana! **** Trying sanskrit/run-hlink.py hardlinked to english/run.py **** CWD: /tmp/symlink-bug/sanskrit Namaste Shriramana! ---------- components: Extension Modules files: symlink-bug.tar.gz messages: 190098 nosy: jamadagni priority: normal severity: normal status: open title: In considering the current directory for importing modules, Python does not honour the output of os.getcwd() Added file: http://bugs.python.org/file30386/symlink-bug.tar.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 18:52:27 2013 From: report at bugs.python.org (Ethan Furman) Date: Sun, 26 May 2013 16:52:27 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1369587147.42.0.877699818497.issue17947@psf.upfronthosting.co.za> Ethan Furman added the comment: Wow. I definitely felt like an apprentice after reading the changes. Thanks, Eli, that looks worlds better! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 18:56:19 2013 From: report at bugs.python.org (Matthew Barnett) Date: Sun, 26 May 2013 16:56:19 +0000 Subject: [issue1693050] \w not helpful for non-Roman scripts Message-ID: <1369587379.24.0.463108691112.issue1693050@psf.upfronthosting.co.za> Matthew Barnett added the comment: I had to check what re does in Python 3.3: >>> print(len(re.match(r'\w+', '??????').group())) 1 Regex does this: >>> print(len(regex.match(r'\w+', '??????').group())) 6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 19:13:02 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 26 May 2013 17:13:02 +0000 Subject: [issue7940] re.finditer and re.findall should support negative end positions In-Reply-To: <1266329075.25.0.639780854585.issue7940@psf.upfronthosting.co.za> Message-ID: <1369588382.16.0.068898845102.issue7940@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm worrying about backward compatibility. See also issue7951. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 19:34:50 2013 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 26 May 2013 17:34:50 +0000 Subject: [issue7951] Should str.format allow negative indexes when used for __getitem__ access? In-Reply-To: <1266450859.13.0.906832569526.issue7951@psf.upfronthosting.co.za> Message-ID: <1369589690.78.0.473735132639.issue7951@psf.upfronthosting.co.za> Mark Lawrence added the comment: Todd's patch strikes me as fine. If something more detailed is needed I think it would be better to raise a separate issue. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 19:50:38 2013 From: report at bugs.python.org (mirabilos) Date: Sun, 26 May 2013 17:50:38 +0000 Subject: [issue18062] m68k FPU precision issue In-Reply-To: <201305262023.22239.oak@helsinkinet.fi> Message-ID: mirabilos added the comment: Eero Tamminen dixit: >> > Now as additional data point, UAE/WinUAE/etc. would be interesting. > >I built the test with fpu_control.h header from eglibc, using >Sparemint GCC 2.9.5 (with 2010 binutils) and MiNTlib. When it's Nice ;) >I.e. it seems that WinUAE FPU emulation is also lacking FPUCW change >handling (for precision). > >(Hatari's WinUAE CPU core code was synched with upstream last year.) OK, thanks. I?d just say let?s say changing FPU precision is not part of the target we support. (Funnily enough, ColdFire according to the ?net has (unchangeable) 64-bit precision? maybe let?s just say precision on m68k in general is not defined.) bye, //mirabilos -- 17:08??Vutral? fr?her gabs keine packenden smartphones und so 17:08??Vutral? heute gibts frauen die sind facebooks?chtig 17:10??Vutral? aber auch traurig; fr?her warst du als nerd voll am arsch 17:10??Vutral? heute bist du als nerd der einzige der wirklich damit klarkommt ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 20:02:31 2013 From: report at bugs.python.org (Brian Curtin) Date: Sun, 26 May 2013 18:02:31 +0000 Subject: [issue8112] xmlrpc.server: ServerHTMLDoc.docroutine uses (since 3.0) deprecated function "inspect.getargspec()" In-Reply-To: <1268242672.24.0.332132369161.issue8112@psf.upfronthosting.co.za> Message-ID: <1369591351.38.0.328743396226.issue8112@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- nosy: -brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 20:02:57 2013 From: report at bugs.python.org (Brian Curtin) Date: Sun, 26 May 2013 18:02:57 +0000 Subject: [issue2554] test_ioctl failed Python 2.6a2 Solaris 10 SUN C In-Reply-To: <1207339545.74.0.114757625359.issue2554@psf.upfronthosting.co.za> Message-ID: <1369591377.94.0.373100757908.issue2554@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- nosy: -brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 20:05:13 2013 From: report at bugs.python.org (R. David Murray) Date: Sun, 26 May 2013 18:05:13 +0000 Subject: [issue18067] In considering the current directory for importing modules, Python does not honour the output of os.getcwd() In-Reply-To: <1369585751.87.0.707349991887.issue18067@psf.upfronthosting.co.za> Message-ID: <1369591513.86.0.26154844227.issue18067@psf.upfronthosting.co.za> R. David Murray added the comment: This is a duplicate of issue 6386, which does contain an explanation of the behavior. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> committed/rejected status: open -> closed superseder: -> importing yields unexpected results when initial script is a symbolic link type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 20:59:09 2013 From: report at bugs.python.org (Oleg Broytman) Date: Sun, 26 May 2013 18:59:09 +0000 Subject: [issue18068] pickle + weakref.proxy(self) Message-ID: <1369594749.9.0.0448045246945.issue18068@psf.upfronthosting.co.za> New submission from Oleg Broytman: Hello! I've found a problematic behaviour of pickle when it pickles (direct or indirect) weak proxies to self. I suspect pickle cannot detect reference loops with weak proxies. I managed to narrow the case to the following example: import pickle, weakref class TestPickle(object): def __init__(self): self.recursive = weakref.proxy(self) def __getstate__(self): print "__getstate__", id(self) return self.__dict__.copy() def __setstate__(self, d): print "__setstate__", id(self) self.__dict__.update(d) print "- 1 -" test = TestPickle() print "- 2 -" data = pickle.dumps(test, pickle.HIGHEST_PROTOCOL) print "- 3 -" test2 = pickle.loads(data) print "- 4 -" print "Result:", id(test2) print "- 5 -" It prints: - 1 - - 2 - __getstate__ 3075348620 __getstate__ 3075348620 - 3 - __setstate__ 3075348844 __setstate__ 3075349004 - 4 - Result: 3075349004 - 5 - That is, __getstate__ is called twice for the same object. And what is worse, __setstate__ is called twice for different objects. The resulting unpickled object is the last one, but in the library that I have been debugging creation of two different objects during unpickling is a bug. I can fix it by avoiding pickling the proxy and recreating the proxy on unpickling: import pickle, weakref class TestPickle(object): def __init__(self): self.recursive = weakref.proxy(self) def __getstate__(self): print "__getstate__", id(self) d = self.__dict__.copy() del d['recursive'] return d def __setstate__(self, d): print "__setstate__", id(self) self.__dict__.update(d) self.recursive = weakref.proxy(self) print "- 1 -" test = TestPickle() print "- 2 -" data = pickle.dumps(test, pickle.HIGHEST_PROTOCOL) print "- 3 -" test2 = pickle.loads(data) print "- 4 -" print "Result:", id(test2) print "- 5 -" - 1 - - 2 - __getstate__ 3075070092 - 3 - __setstate__ 3075070188 - 4 - Result: 3075070188 - 5 - But I wonder if it's a bug that should be fixed? If it's an expected behaviour it perhaps should be documented as a warning in docs for pickle or weakref or both. ---------- components: Library (Lib) messages: 190105 nosy: phd priority: normal severity: normal status: open title: pickle + weakref.proxy(self) type: behavior versions: Python 2.6, Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 21:15:42 2013 From: report at bugs.python.org (berdario) Date: Sun, 26 May 2013 19:15:42 +0000 Subject: [issue18069] Subprocess picks the wrong executable on Windows Message-ID: <1369595742.19.0.584828873115.issue18069@psf.upfronthosting.co.za> New submission from berdario: To reproduce: I installed 2 versions of python: python2.7 and python3.3, both in C:\ I then used the distribute-setup and get-pip script on both interpreters http://python-distribute.org/distribute_setup.py https://raw.github.com/pypa/pip/master/contrib/get-pip.py I copied C:\Python33\Scripts\pip.exe to C:\Python33\pip.exe And I set up the PATH system variable, to have C:\Python27\Scripts;C:\Python33\; at the beginning When invoking python, it'll pick Python3.3, as expected, and then: > python Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:57:17) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from shutil import which >>> import os >>> os.environ['PATH'] 'C:\\Python27\\Scripts;C:\\Python33\\;C:\\Windows\\system32;C:\\Windows;C:\\Windows\\System32\\Wbem;C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\;C:\\Program Files\\Microsoft Windows Performance Toolkit\\;C:\\Program Files (x86)\\Bazaar;C:\\Program Files\\Mercurial\\;C:\\MinGW\\bin; C:\\Program Files (x86)\\Git\\cmd;C:\\Users\\Dario\\Documents\\WindowsPowerShell\\Modules\\Pscx\\Apps;C:\\Users\\Dario\\Applications\\bin;C:\\Users\\Dario\\Applications\\emacs\\bin' >>> which('pip') 'c:\\python27\\scripts\\pip.exe' >>> from subprocess import call >>> call('pip --version'.split()) Cannot open C:\Python33\pip-script.py 2 >>> ---------- components: Interpreter Core, Windows messages: 190106 nosy: berdario priority: normal severity: normal status: open title: Subprocess picks the wrong executable on Windows type: behavior versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 21:18:07 2013 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 26 May 2013 19:18:07 +0000 Subject: [issue18069] Subprocess picks the wrong executable on Windows In-Reply-To: <1369595742.19.0.584828873115.issue18069@psf.upfronthosting.co.za> Message-ID: <1369595887.61.0.0788066857897.issue18069@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 21:29:57 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 26 May 2013 19:29:57 +0000 Subject: [issue592703] HTTPS does not handle pipelined requests Message-ID: <1369596597.22.0.549021132593.issue592703@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Tried with python2.7.3 I used http://code.activestate.com/recipes/576673-python-http-pipelining/ just replacing the initial call to HTTPConnection() by HTTPSConnection(). The example succeeeds, fetches the three pages, and I checked with strace that the same connection is used for all requests (only reads and writes of encrypted content, no close or connect in between). Is this enough for closing this issue? Or is there a different way to pipelines requests that we should support? ---------- nosy: +amaury.forgeotdarc status: open -> pending versions: +3rd party -Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 21:30:13 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 26 May 2013 19:30:13 +0000 Subject: [issue592703] HTTPS does not handle pipelined requests Message-ID: <1369596613.82.0.523492110854.issue592703@psf.upfronthosting.co.za> Changes by Amaury Forgeot d'Arc : ---------- resolution: -> works for me status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 21:30:21 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 26 May 2013 19:30:21 +0000 Subject: [issue592703] HTTPS does not handle pipelined requests Message-ID: <1369596621.39.0.404299269878.issue592703@psf.upfronthosting.co.za> Changes by Amaury Forgeot d'Arc : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 21:49:07 2013 From: report at bugs.python.org (Eric V. Smith) Date: Sun, 26 May 2013 19:49:07 +0000 Subject: [issue18058] Define is_package for NamespaceLoader In-Reply-To: <1369496923.18.0.904476367209.issue18058@psf.upfronthosting.co.za> Message-ID: <1369597747.5.0.68235686077.issue18058@psf.upfronthosting.co.za> Eric V. Smith added the comment: I think it's just an oversight. ---------- assignee: barry -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 21:50:04 2013 From: report at bugs.python.org (Eric V. Smith) Date: Sun, 26 May 2013 19:50:04 +0000 Subject: [issue18056] Document importlib._bootstrap.NamespaceLoader In-Reply-To: <1369496751.81.0.344197180241.issue18056@psf.upfronthosting.co.za> Message-ID: <1369597804.87.0.23518443728.issue18056@psf.upfronthosting.co.za> Eric V. Smith added the comment: No reason I can think of, other than it never occurred to me to do it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 21:55:57 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 26 May 2013 19:55:57 +0000 Subject: [issue592703] HTTPS does not handle pipelined requests Message-ID: <1369598157.23.0.24309961445.issue592703@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The original report is so under-specified that it's pointless to keep it open. If you encounter an actual bug, feel free to open another issue :) ---------- nosy: +pitrou status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 22:38:14 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 26 May 2013 20:38:14 +0000 Subject: [issue923697] SAX2 'property_encoding' feature not supported Message-ID: <1369600694.21.0.429642316958.issue923697@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Mark, the "http://www.python.org/sax/properties/encoding" is not meant to be a web page. It's like an attribute name, but fully qualified so that attributes given by different organizations don't clash. (There may be different usages of "encoding": is it the one set by the user, or the one determined by the parser? according to Python docs, here it's both) Python's default Expat parser doesn't support this feature, so the present behavior is correct. Proper support should not be difficult to add, with a XmlDeclHandler. ---------- nosy: +amaury.forgeotdarc stage: test needed -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 22:39:05 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 26 May 2013 20:39:05 +0000 Subject: [issue9951] introduce bytes.hex method In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1369600745.95.0.618889336991.issue9951@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Also #3532 ---------- nosy: +terry.reedy versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 22:46:49 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 26 May 2013 20:46:49 +0000 Subject: [issue877121] configure detects incorrect compiler optimization Message-ID: <1369601209.77.0.222031833583.issue877121@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The 3.2 change r85656 removes OPT:Olimit, IMO this should not be backported. But 2.7 already has this warning fixed for icc: http://hg.python.org/cpython/rev/e7c96c1d144b/ We should do the same here. What's the correct way to detect Oracle Studio compiler? ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 22:56:07 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Sun, 26 May 2013 20:56:07 +0000 Subject: [issue706406] fix bug #685846: raw_input defers signals Message-ID: <1369601767.92.0.850774544341.issue706406@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Closing as fixed. I tested with python2.7 and 3.2, both with and without a readline module. Behavior is consistent and looks correct to me: the signal is honored (message printed after 5s), and does not stop the raw_input(), except when it raises an exception, in which case the command exits and the exception is propagated. ---------- nosy: +amaury.forgeotdarc resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 22:56:09 2013 From: report at bugs.python.org (Eli Bendersky) Date: Sun, 26 May 2013 20:56:09 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1369601769.16.0.354457557401.issue17947@psf.upfronthosting.co.za> Eli Bendersky added the comment: Thanks Ethan :) >From my point of view this is LGTM, as long as: * There's ReST documentation * You remove the code to support extensions and customizations not mandated by PEP 435. As I mentioned before, this seems to be a YAGNI that complicates the code needlessly. It's find to keep the changes in some external repo and at a later point discuss their gradual addition similarly to the way Nick has been pushing enhancements through additional issues. We can always add more capabilities to Enum. We can "never" take them away once added, and this complicated code will remain with us forever even if no one ends up using it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 23:05:18 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 26 May 2013 21:05:18 +0000 Subject: [issue18052] IDLE 3.3.2 Windows taskbar icon regression In-Reply-To: <1369437693.91.0.216380064498.issue18052@psf.upfronthosting.co.za> Message-ID: <1369602318.0.0.954599038332.issue18052@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Restarting Windows solves the issue. If nothing else, the installer could end with 'Restart Windows for Idle icons to work correctly'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun May 26 23:09:23 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 26 May 2013 21:09:23 +0000 Subject: [issue1693050] \w not helpful for non-Roman scripts Message-ID: <1369602563.65.0.290101016197.issue1693050@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: +Python 3.3, Python 3.4 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 00:00:53 2013 From: report at bugs.python.org (=?utf-8?q?Guilherme_Sim=C3=B5es?=) Date: Sun, 26 May 2013 22:00:53 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1369605653.34.0.102620407294.issue5124@psf.upfronthosting.co.za> Guilherme Sim?es added the comment: I think IDLE should ignore general X11 practice. I used Linux for years and have never seen this behavior before because almost all programs behave in the Mac/Windows way. ---------- nosy: +Guilherme.Sim?es _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 00:31:41 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 26 May 2013 22:31:41 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1369601769.16.0.354457557401.issue17947@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: Supporting extensions was one of the things that got Ethan's version through review. So -1 on going back on our promise to support those variants. They have been reviewed and tested just as thoroughly as the rest of the design. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 00:33:16 2013 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 26 May 2013 22:33:16 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: Message-ID: Nick Coghlan added the comment: Also, we know for a fact that people plan to use the customisation features - it was making their code work that drove the current extension design. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 00:59:26 2013 From: report at bugs.python.org (Ned Deily) Date: Sun, 26 May 2013 22:59:26 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1369609166.22.0.257687548889.issue5124@psf.upfronthosting.co.za> Ned Deily added the comment: Unfortunately, there is no one right answer to paste behavior on X11, unlike on native Windows and Mac implementations where there is essentially system-wide consistent paste behavior enforced by the underlying operating system. As the Tk Wiki points out (and the comments hers concur), different users are going to have different expectations. If we want to make this behavior available with X11 Tk, then it really should be a user configurable option. Without providing an option, the overriding design principle is that the status quo wins a stalemate (http://www.boredomandlaziness.org/2011/02/status-quo-wins-stalemate.html). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 01:50:02 2013 From: report at bugs.python.org (Matthew Barnett) Date: Sun, 26 May 2013 23:50:02 +0000 Subject: [issue7940] re.finditer and re.findall should support negative end positions In-Reply-To: <1266329075.25.0.639780854585.issue7940@psf.upfronthosting.co.za> Message-ID: <1369612202.63.0.590988053342.issue7940@psf.upfronthosting.co.za> Matthew Barnett added the comment: Like the OP, I would've expected it to handle negative indexes the way that strings do. In practice, I wouldn't normally provide negative indexes; I'd use some string or regex method to determine the search limits, and then pass them to finditer and findall, so they'd be non-negative anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 03:12:50 2013 From: report at bugs.python.org (Eli Bendersky) Date: Mon, 27 May 2013 01:12:50 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1369617170.58.0.442243248429.issue17947@psf.upfronthosting.co.za> Eli Bendersky added the comment: I'm not sure which promises you're referring to Nick, and to whom they were made; the only formal promise we made is PEP 435 - and it doesn't mention this extensibility. I won't argue beyond this comment, since I know I'm part of the minority opinion here. However, I still think this is a mistake. The most important original goal of Enum (as discussed during the language summit) was to replace all the custom enum implementations by one that is standard. A far fledged extension mechanism will just make it so we'll have a fleet of bastardized "extended enums", each with its own capabilities, each different from the others. With one standard Enum, when you're reading someone's code and you see: class Foo(Enum): ... You know very well what Foo is. Restricted extensions like IntEnum and even your @enum.unique are still tolerable because they're explicit: # enum.unique is standard and says what it is explicitly @enum.unique class Foo(Enum): ... But if we open the gates on customization, we'll have: class Foo(AutoEnum): Red, White, Black And: class Bar(SomeOtherAutoEnum): Red = ... White = ... Black = ... And: class Baz(SomeEvenOtherMagicEnum): ... # whatever goes here And we're back to square 1, because these Enums are not standard, and each framework will have its own clever customization one will need to understand in order to read code with Enums. Exposing and documenting the metaclass and customizations of __new__ is a whole coffin for the "there is only one way to do it" decision of stdlib's Enum. It might have been better to just define AutoNumberedEnum, BitfieldEnum and Magic42Enum as part of the enum package in stdlib and be over with it; but this was strongly rejected by others and particularly Guido during the summit and later. Now we're just creating a back-door to get into the same situation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 03:40:44 2013 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 27 May 2013 01:40:44 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1369618844.77.0.92464272893.issue17947@psf.upfronthosting.co.za> Guido van Rossum added the comment: Eli, what's wrong with having a backdoor? Python is literally *full* of backdoors. I have a feeling that somehow you are trying to build an Enum class that is unpythonic in its desire to enforce some kind of "ideal enum" behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 03:57:09 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 27 May 2013 01:57:09 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1369619829.26.0.166379873127.issue5124@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I agree that the paste replace should be added as an option on linux, but without a broader survey of Linux Idle users to convince me otherwise, I have to agree that the default should stay as it is. I do not see any call to make the x11 behavior an option on mac and windows. ---------- type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 04:24:55 2013 From: report at bugs.python.org (Todd Rovito) Date: Mon, 27 May 2013 02:24:55 +0000 Subject: [issue16278] os.rename documentation slightly inaccurate In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za> Message-ID: <1369621495.58.0.541482300692.issue16278@psf.upfronthosting.co.za> Todd Rovito added the comment: Ping!!! I have not heard anything about this patch so I wanted to ping it to get more feedback. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 04:32:40 2013 From: report at bugs.python.org (Eli Bendersky) Date: Mon, 27 May 2013 02:32:40 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1369621960.34.0.805111751877.issue17947@psf.upfronthosting.co.za> Eli Bendersky added the comment: Guido, IMHO back-doors are fine in many cases, just not this one. The way I see it, our main goal here is to collect a bunch of custom implementations of enums under a single umbrella. This is not very different from what was done with OrderedDict and namedtuple at some point. There were probably a bunch of custom implementations, along with more and less commonly used recipes. At some point a single implementation was added to the stdlib, without (AFAICS) major back-doors. Yes, the Enum case is vastly more complex than either OrderedDict or namedtuple, and there is a multitude of different behaviors that can be anticipated (as the lengthy discussions leading to the acceptance of PEP 435 demonstrated). And yet, I was also hoping to have a single canonical implementation, so that people eventually accept it as "the one". Stdlib modules tend to win over in the long run. The other point is that I think the implementation could be much simpler without having these back doors. As it stands now, the code is complex and hence brittle. Any change will be difficult to do because we're locked down very strictly by a set of intrusive and deep, yet externally "promised" interfaces. The same can be said, again, about OrderedDict and namedtuple, the code of which is very straightforward. Maybe I'm blowing this out of proportions, maybe not. I'm not sure. As I said, I don't want to strongly argue about this. If both you and Nick are OK with keeping the customization mechanisms in, I defer to your judgment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 04:42:22 2013 From: report at bugs.python.org (Todd Rovito) Date: Mon, 27 May 2013 02:42:22 +0000 Subject: [issue17511] Idle find function closes after each find operation In-Reply-To: <1363902452.43.0.911749750934.issue17511@psf.upfronthosting.co.za> Message-ID: <1369622542.85.0.116418856286.issue17511@psf.upfronthosting.co.za> Todd Rovito added the comment: I was wondering does it make sense to commit this patch since it is similar to http://bugs.python.org/issue14146 then put the issue in the pending state as we wait for the TK/TCL fix? It seems more consistent to me since this issue is basically the same highlight problem as 14146. I imagine this is very bothersome for Windows users. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 05:24:07 2013 From: report at bugs.python.org (Todd Rovito) Date: Mon, 27 May 2013 03:24:07 +0000 Subject: [issue5124] IDLE - pasting text doesn't delete selection In-Reply-To: <1233514334.85.0.801099495729.issue5124@psf.upfronthosting.co.za> Message-ID: <1369625047.26.0.466220572043.issue5124@psf.upfronthosting.co.za> Todd Rovito added the comment: I haver verified Roger's patch does indeed fix the problem on Linux CentOS 6.4 with IDLE 3.4. The Linux situation is complex. Basically as I see it over the years pure X11 applications are becoming extinct and most developers either use GTK (for GNOME) or QT (for KDE). I don't blame anybody for moving to one of these toolkits because writing a pure X11 application is painful. In the near future Wayland http://en.wikipedia.org/wiki/Wayland_(display_server_protocol) will take over and I wonder how many X11 applications will actually be ported. I agree with Roger we should try and make IDLE as consistent as possible across operating systems. +1 for applying the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 05:52:05 2013 From: report at bugs.python.org (Todd Rovito) Date: Mon, 27 May 2013 03:52:05 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1369626725.91.0.62893457381.issue15392@psf.upfronthosting.co.za> Todd Rovito added the comment: Patch does indeed apply and I get good results!!!!! The patch is well done and provides a nice example on how to write unit tests. +1 for making the commit from me R. David Murray you used the patch command while I used "hg import --no-commit mywork.patch" as specified in the Python Developers Guide. Next time I have an issue I will use patch and see if it works better. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 06:02:28 2013 From: report at bugs.python.org (Todd Rovito) Date: Mon, 27 May 2013 04:02:28 +0000 Subject: [issue2053] IDLE - standardize dialogs In-Reply-To: <1202515821.86.0.159216664847.issue2053@psf.upfronthosting.co.za> Message-ID: <1369627348.44.0.724004059308.issue2053@psf.upfronthosting.co.za> Changes by Todd Rovito : ---------- nosy: +Todd.Rovito _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 06:06:11 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 27 May 2013 04:06:11 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1369627571.45.0.489856699816.issue17947@psf.upfronthosting.co.za> Nick Coghlan added the comment: Eli, remember that TOOWTDI stands for "There's one *obvious* way to do it" rather than "There's *only* one way to do it". The latter interpretation leads to insanely complex APIs that attempt to solve everyone's problems, while the former favours 80% solutions that cover most use cases, with extension hooks that let people handle the other 20% as they see fit. The point of the enum standardisation is to have a conventional way that enums *behave*, and then allow variations on that theme for those cases where the stdlib implementation is "close, but not quite what I need or want". The whole metaclass machinery is built around this concept of letting people create domain specific behaviour, that is still somewhat unified due to conventions like the descriptor protocol. You can do a *lot* with just descriptors, so if you don't need a custom metaclass, you shouldn't use one. PEP 422's class initialisation hook is aimed specifically at certain cases that currently need a metaclass and providing a simpler way to do them that lets you just use "type" as the metaclass instead. It's the same with enums - if you don't need to customise the metaclass, you shouldn't. But there are some use cases (such as syncing the Python level enum definition with a database level one) where additional customisation will be needed. We also want to give people the freedom they need to experiment with different forms of definition time syntactic sugar to see if they can come up with one we like enough to add to the standard library in 3.5. Does documenting these definition time extension points constrain what we're allowed to do in the future? Yes, it does. But, at the same time, it takes a lot of pressure off us to add more features to the standard enum type over time - if people have niche use cases that aren't handled well by the standard solution (and we already know they do), we can point them at the supported extension interface and say "go for it". For the majority of users though, the standard enum type will work fine, just as ordinary classes are adequate for the vast majority of object oriented code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 06:10:05 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 27 May 2013 04:10:05 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1369627805.71.0.290715526663.issue17947@psf.upfronthosting.co.za> Nick Coghlan added the comment: Somewhat related, I *know* you've read type.__new__. Compared to that, enum.EnumMeta.__new__ is still pretty straightforward ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 08:01:11 2013 From: report at bugs.python.org (Ned Deily) Date: Mon, 27 May 2013 06:01:11 +0000 Subject: [issue18050] embedded interpreter or virtualenv fails with "ImportError: cannot import name MAXREPEAT" In-Reply-To: <1369417243.06.0.993082490408.issue18050@psf.upfronthosting.co.za> Message-ID: <1369634470.99.0.834973791828.issue18050@psf.upfronthosting.co.za> Ned Deily added the comment: After spending some time investigating this issue, I believe that potential upgrade compatibility issues have been introduced by the changes for Issue13169. How critical they are and, in particular, whether they violate our implicit promises of maintenance (point) release compatibility are questions for discussion. The signature of the problem is "ImportError: cannot import name MAXREPEAT" as a result of an attempt to import re or a module that itself imports re: Traceback (most recent call last): File "", line 1, in File "/home/nad/issue18050/u/lib/python2.7/re.py", line 105, in import sre_compile File "/home/nad/issue18050/u/lib/python2.7/sre_compile.py", line 14, in import sre_parse File "/home/nad/issue18050/u/lib/python2.7/sre_parse.py", line 17, in from sre_constants import * File "/home/nad/issue18050/u/lib/python2.7/sre_constants.py", line 18, in from _sre import MAXREPEAT ImportError: cannot import name MAXREPEAT The changes for Issue13169 moved the definition of MAXREPEAT into C code and then added an import of the new C constant into Lib/sre_constants.py to continue to provide sre_constants.MAXREPEAT for third-party modules that have been using it. As long as the versions of the Python interpreter and the standard library Python files (sys.prefix/lib/pythonX.Y) remain in sync, there is not a problem. However, if a situation arises where a pre-13169 interpreter is used with a post-13169 standard library, the "cannot import name MAXREPEAT" ImportError will occur. I have found at least two situations where this can happen: 1. when a C application has statically embedded a pre-13169 interpreter and the standard library pointed to by its sys.prefix gets upgraded to a post-13169 version. The interpreter then crashes during initialization in Lib/site.py which imports re in both Python 2 and 3 (for different purposes). 2. when a virtualenv created with a pre-13169 non-shared interpreter is used with an upgraded post-13169 standard library. In this case, the interpreter makes it past initialization because virtualenv (at least, the current version) creates a modified site.py in the virtualenv lib/pythonX.Y that happens to not import re. However, the import error will occur on the first use of re. Side note: 3.3 standard library pyvenv does not seem to have this problem since the created venv symlinks to the sys.prefix interpreter and libs rather than copying it, like virtualenv does. Note that Pythons built with --enable-shared (or --enable-framework on OS X) generally will not have a problem as long as the shared libpythonX.Y and the standard library remain consistent. That is, in both cases above, a Python upgrade will automatically cause both the embedded app and the virtualenv to run with the newer interpreter. AFAICT, the problems will only be seen when using a non-shared Python. I believe the upgrades affected by this problem are: 2.7 through 2.7.3 upgraded to 2.7.4 or 2.7.5 3.3.0 upgraded to 3.3.1 or 3.3.2 3.2 through 3.2.3 upgraded to 3.2.4 or 3.2.5 (unverified) The problem should be fixable by applying a patch along the lines suggested by Samuel. Regardless of whether this is a compatibility break or not, I think we should fix the problem because people are already running into it. (Nosying the release managers for their input.) While related, the root cause of the vim problem reported above is probably more complicated because, although it appears to embed a Python interpreter, the standard library used by the OS X system vim appears to depend on $PATH, apparently incorrect behavior in vim. Unfortunately, OS X vim users on 10.8 (probably also on 10.7) may encounter this problem when they try to use :py if they install an updated version of Python 2.7, such as from python.org or a third-party distributor like Homebrew or MacPorts. And, when vim crashes due to the import error, it leaves the terminal settings in an unusable state. One user workaround might be to create a shell function or alias to tweak PATH before using vim to ensure /usr/bin/python2.7 is found first. Or simply patch re.py in the upgraded Python. ---------- components: +Library (Lib) -Extension Modules nosy: +benjamin.peterson, georg.brandl, serhiy.storchaka priority: normal -> high stage: -> needs patch title: _sre.MAXREPEAT not defined in 2.7.3 -> embedded interpreter or virtualenv fails with "ImportError: cannot import name MAXREPEAT" versions: +Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 09:03:14 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 May 2013 07:03:14 +0000 Subject: [issue18032] set methods should specify whether they consume iterators "lazily" In-Reply-To: <1369223923.83.0.620034016791.issue18032@psf.upfronthosting.co.za> Message-ID: <1369638194.31.0.673360640813.issue18032@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 09:59:28 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 May 2013 07:59:28 +0000 Subject: [issue18032] set methods should specify whether they consume iterators "lazily" In-Reply-To: <1369223923.83.0.620034016791.issue18032@psf.upfronthosting.co.za> Message-ID: <1369641568.61.0.0872321476433.issue18032@psf.upfronthosting.co.za> Raymond Hettinger added the comment: We don't normally document implementation details or the presences or absence of internal optimizations. This gives us freedom to change the implementation and it allows freedom for other implementations (such as Jython, IronPython, and PyPy) to make their own choices. Often those implementations start out with the simplest correct approach and then become increasingly optimized over time. I'm leaving this one open as a possible CPythhon performance enhancement, adding early-out behavior to issubset() when the argument is a non-set, non-dict iterable: def issubset(self, iterable): n = len(self) seen = set() for x in iterable: if x not in seen and x in self: seen.add(x) n -= 1 if not n: return True # early-out return False ---------- components: +Interpreter Core -Documentation type: behavior -> performance versions: -Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 10:20:40 2013 From: report at bugs.python.org (Gael Le Mignot) Date: Mon, 27 May 2013 08:20:40 +0000 Subject: [issue1747670] Limiting data copy in xmlrpclib Message-ID: <1369642840.76.0.909452609854.issue1747670@psf.upfronthosting.co.za> Gael Le Mignot added the comment: It's not something that can be easily benched because it depends a lot of the use case. If some conditions are present (big amount of data sent to XML-RPC, the XML-RPC server taking a long time to answer, end either Python giving back the memory to the OS or another thread reusing the garbage collected memory) the gain in memory can be very significant, in most other cases, it won't change anything. Do you me to craft a simple example where the difference can be seen ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 10:34:49 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 May 2013 08:34:49 +0000 Subject: [issue18047] Descriptors get invoked in old-style objects and classes In-Reply-To: <1369373983.58.0.00587959802813.issue18047@psf.upfronthosting.co.za> Message-ID: <1369643689.75.0.432378507761.issue18047@psf.upfronthosting.co.za> Raymond Hettinger added the comment: IMO nothing should change here (either the docs or the implementation). The OP has observed an implementation detail of old-style classes (which were reimplemented in Python 2.2 using descriptor logic instead of their former hard-wired behaviors). ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 11:55:28 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 May 2013 09:55:28 +0000 Subject: [issue1747670] Limiting data copy in xmlrpclib Message-ID: <1369648528.39.0.256239472763.issue1747670@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, it would be nice if you provided an example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 11:56:05 2013 From: report at bugs.python.org (berdario) Date: Mon, 27 May 2013 09:56:05 +0000 Subject: [issue18069] Subprocess picks the wrong executable on Windows In-Reply-To: <1369595742.19.0.584828873115.issue18069@psf.upfronthosting.co.za> Message-ID: <1369648565.58.0.509591350639.issue18069@psf.upfronthosting.co.za> berdario added the comment: I found out what's the problem, from the CreateProcess docs: http://msdn.microsoft.com/en-us/library/ms682425.aspx """ If the file name does not contain a directory path, the system searches for the executable file in the following sequence: The directory from which the application loaded. The current directory for the parent process. [...] """ This means that subprocess.Popen (and related functions) will always pick an executable in C:\PythonXX (if launched from the interpreter) or from C:\PythonXX\Scripts (if launched from a script/executable installed there) before looking into the PATH. If we want to have the same behavior on *nix platforms and windows, I think that the only way this can be fixed, is by filtering the "executable" and "args" arguments through shutil.which (or a similar approach) Otherwise, the difference in the executable path resolution should be documented. (Either way, in my application, I'll have to reimplement shutil.which to be able to work on older python versions ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 14:05:33 2013 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 27 May 2013 12:05:33 +0000 Subject: [issue672115] Assignment to __bases__ of direct object subclasses Message-ID: <1369656333.16.0.979417974887.issue672115@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 14:05:48 2013 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 27 May 2013 12:05:48 +0000 Subject: [issue672115] Assignment to __bases__ of direct object subclasses Message-ID: <1369656348.37.0.918947828159.issue672115@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- versions: +Python 3.4 -Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 14:49:50 2013 From: report at bugs.python.org (Julian Berman) Date: Mon, 27 May 2013 12:49:50 +0000 Subject: [issue18050] embedded interpreter or virtualenv fails with "ImportError: cannot import name MAXREPEAT" In-Reply-To: <1369417243.06.0.993082490408.issue18050@psf.upfronthosting.co.za> Message-ID: <1369658990.52.0.924516789756.issue18050@psf.upfronthosting.co.za> Changes by Julian Berman : ---------- nosy: +Julian _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 14:59:31 2013 From: report at bugs.python.org (Samuel John) Date: Mon, 27 May 2013 12:59:31 +0000 Subject: [issue18050] embedded interpreter or virtualenv fails with "ImportError: cannot import name MAXREPEAT" In-Reply-To: <1369417243.06.0.993082490408.issue18050@psf.upfronthosting.co.za> Message-ID: <1369659571.41.0.381198368346.issue18050@psf.upfronthosting.co.za> Samuel John added the comment: Ned, incredibly helpful description. Thanks for investigating! I have nothing to add to that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 15:34:17 2013 From: report at bugs.python.org (Ed Maste) Date: Mon, 27 May 2013 13:34:17 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1369661657.02.0.433698244844.issue15745@psf.upfronthosting.co.za> Changes by Ed Maste : ---------- nosy: +Ed.Maste _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 15:59:43 2013 From: report at bugs.python.org (Brett Cannon) Date: Mon, 27 May 2013 13:59:43 +0000 Subject: [issue18070] change importlib.util.module_for_loader to unconditionally set attributes Message-ID: <1369663183.34.0.953229733937.issue18070@psf.upfronthosting.co.za> New submission from Brett Cannon: importlib.util.module_for_loader (as well as set_package and set_loader) only set those attributes either when they are not already set or when the module is new. I realized this is a problem as it means a reload won't work the way one might expect. I want to at least change module_for_loader since I suspect that is in wider use, but probably all three decorators to unconditionally set their respective attributes so reloads operate as expected. Unfortunately that is backwards-incompatible, albeit for probably a rare case if anyone actually cares. Anyone see a reason why doing this is a bad idea and it shouldn't be done? ---------- components: Library (Lib) messages: 190139 nosy: barry, brett.cannon, eric.smith, eric.snow, ncoghlan priority: normal severity: normal stage: test needed status: open title: change importlib.util.module_for_loader to unconditionally set attributes type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 16:07:21 2013 From: report at bugs.python.org (Samuel John) Date: Mon, 27 May 2013 14:07:21 +0000 Subject: [issue18071] _osx_support compiler_fixup Message-ID: <1369663641.63.0.31152522756.issue18071@psf.upfronthosting.co.za> New submission from Samuel John: In the `_osx_support.py` module, there seems to be a bug in the method `compiler_fixup` which occurs if * the `customize_compiler` method from `distutils/sysconfig` has been called and after that * `_compile` from `distutils/unixcompiler.py` is called. The `_compile` method uses `_osx_support.compiler_fixup`. The critical line in compiler_fixup is: `compiler_so = list(compiler_so)`. Usually `compiler_so` is a list like `['cc']` but not when `customize_compiler` (from sysconfig) has been called. The value returned by `sysconfig.get_config_var('LDSHARED')` is a unicode like for example in the case of a Python 2.7.5 built via Homebrew: "cc -bundle -undefined dynamic_lookup -L/homebrew/lib -L/homebrew/opt/sqlite/lib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk". When `list()` is applied to the value, it is split at each character and that cannot be intended. I am not sure if I fully understand, but to fix this in `compiler_fixup`, instead of `compiler_so = list(compiler_so)`, I'd propose something along the lines of: if isinstance(compiler_so, (str,unicode)): compiler_so = compiler_so.split() I found this by trying to `pip install cython` (it uses customize_compiler, I guess) on a homebrewed python. To reproduce in an interactive shell we can emulate what is going on by calling `compiler_fixup` directly with the values sysconfig has stored. The exact string does not matter, because I think the any value returned by `sysconfig_get_config_var` is a (unicode) string and not a list: import sysconfig import _osx_support _osx_support.compiler_fixup(sysconfig.get_config_var('LDSHARED'),sysconfig.get_config_var('CFLAGS')) Not sure if other python versions are affected. I wasn't aware of `_osx_support` at all until now. ---------- assignee: ronaldoussoren components: Macintosh messages: 190140 nosy: hynek, ned.deily, ronaldoussoren, samueljohn priority: normal severity: normal status: open title: _osx_support compiler_fixup versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 16:38:12 2013 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 27 May 2013 14:38:12 +0000 Subject: [issue18070] change importlib.util.module_for_loader to unconditionally set attributes In-Reply-To: <1369663183.34.0.953229733937.issue18070@psf.upfronthosting.co.za> Message-ID: <1369665492.24.0.791672061939.issue18070@psf.upfronthosting.co.za> Eric V. Smith added the comment: I don't think anyone would (or should!) write code that cares, so I think your proposed change is a good one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 16:42:05 2013 From: report at bugs.python.org (Samuel John) Date: Mon, 27 May 2013 14:42:05 +0000 Subject: [issue18071] _osx_support compiler_fixup In-Reply-To: <1369663641.63.0.31152522756.issue18071@psf.upfronthosting.co.za> Message-ID: <1369665725.21.0.746641288051.issue18071@psf.upfronthosting.co.za> Samuel John added the comment: The symptom for the end-user looks kind of weird: running build_ext building 'Cython.Plex.Scanners' extension / A p p l i c a t i o n s / X c o d e . a p p / C o n t e n t s / D e v e l o p e r / T o o l c h a i n s / X c o d e D e f a u l t . x c t o o l c h a i n / u s r / b i n / c l a n g - f n o - s t r i c t - a l i a s i n g - f n o - c o m m o n - d y n a m i c - I / h o m e b r e w / i n c l u d e - I / h o m e b r e w / o p t / s q l i t e / i n c l u d e - i s y s r o o t / A p p l i c a t i o n s / X c o d e . a p p / C o n t e n t s / D e v e l o p e r / P l a t f o r m s / M a c O S X . p l a t f o r m / D e v e l o p e r / S D K s / M a c O S X 1 0 . 8 . s d k - I / A p p l i c a t i o n s / X c o d e . a p p / C o n t e n t s / D e v e l o p e r / P l a t f o r m s / M a c O S X . p l a t f o r m / D e v e l o p e r / S D K s / M a c O S X 1 0 . 8 . s d k / S y s t e m / L i b r a r y / F r a m e w o r k s / T k . f r a m e w o r k / V e r s i o n s / 8 . 5 / H e a d e r s - D N D E B U G - g - f w r a p v - O 3 - W a l l - W s t r i c t - p r o t o t y p e s -I/homebrew/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c Cython/Plex/Scanners.c -o build/temp.macosx-10.8-x86_64-2.7/Cython/Plex/Scanners.o unable to execute /: Permission denied error: command '/' failed with exit status 1 Pasted here to help googlers to find it :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 17:03:42 2013 From: report at bugs.python.org (Brett Cannon) Date: Mon, 27 May 2013 15:03:42 +0000 Subject: [issue18072] Add an implementation of importlib.abc.InspectLoader.get_code Message-ID: <1369667022.96.0.117125531861.issue18072@psf.upfronthosting.co.za> New submission from Brett Cannon: I'm contemplating adding an implementation of importlib.abc.InspectLoader.get_code() which relies on get_source() (and then another version in ExecutionLoader which uses get_filename()). The reason I'm hesitant is get_source() is often an expensive operation thanks to having to decode the source code and do a universal newline conversion. Now I could add the implementation but leave the method abstract, forcing users to make the decision to call super().get_code(), although that's still easy enough that I'm afraid people still won't take into consideration the performance implications. But maybe I'm worrying too much? We're consenting adults, right? So for that reason I'm leaning towards implementing but leaving abstract with a note in the docs that performance should be considered before just blindly calling the abstract method. ---------- components: Library (Lib) messages: 190143 nosy: brett.cannon, eric.snow, ncoghlan priority: normal severity: normal status: open title: Add an implementation of importlib.abc.InspectLoader.get_code versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 17:07:51 2013 From: report at bugs.python.org (Brett Cannon) Date: Mon, 27 May 2013 15:07:51 +0000 Subject: [issue18070] change importlib.util.module_for_loader to unconditionally set attributes In-Reply-To: <1369663183.34.0.953229733937.issue18070@psf.upfronthosting.co.za> Message-ID: <1369667271.93.0.503535504093.issue18070@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 17:08:05 2013 From: report at bugs.python.org (Brett Cannon) Date: Mon, 27 May 2013 15:08:05 +0000 Subject: [issue18072] Add an implementation of importlib.abc.InspectLoader.get_code In-Reply-To: <1369667022.96.0.117125531861.issue18072@psf.upfronthosting.co.za> Message-ID: <1369667285.33.0.366055861154.issue18072@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 17:08:10 2013 From: report at bugs.python.org (Brett Cannon) Date: Mon, 27 May 2013 15:08:10 +0000 Subject: [issue18072] Add an implementation of importlib.abc.InspectLoader.get_code In-Reply-To: <1369667022.96.0.117125531861.issue18072@psf.upfronthosting.co.za> Message-ID: <1369667290.42.0.371753125196.issue18072@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 17:18:01 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 27 May 2013 15:18:01 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1369667881.1.0.305387126404.issue15392@psf.upfronthosting.co.za> R. David Murray added the comment: Heh. Yeah, I use patch because I don't just work with mercurial/python, and I find the patch command simpler to use for applying patches in general, since I never want an autocommit. (The exception would be if I'm applying a patch that involves extended diff stuff that patch doesn't recognize.) It makes sense that the devguide talks about import, though, since the patches here always ought to be things generated by hg and thus handleable by import. I'm not sure why this one would have failed for you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 17:44:33 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Mon, 27 May 2013 15:44:33 +0000 Subject: [issue8083] urllib proxy interface is too limited In-Reply-To: <1267960974.57.0.282582505856.issue8083@psf.upfronthosting.co.za> Message-ID: <1369669473.96.0.398655555662.issue8083@psf.upfronthosting.co.za> Changes by Senthil Kumaran : ---------- assignee: -> orsenthil nosy: +orsenthil _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 18:05:33 2013 From: report at bugs.python.org (Shriramana Sharma) Date: Mon, 27 May 2013 16:05:33 +0000 Subject: [issue6386] importing yields unexpected results when initial script is a symbolic link In-Reply-To: <1246356344.6.0.218965497612.issue6386@psf.upfronthosting.co.za> Message-ID: <1369670733.71.0.675143048088.issue6386@psf.upfronthosting.co.za> Shriramana Sharma added the comment: I'm sorry but I don't get why this is a WONTFIX. I reported what is (now) apparently a dup: issue 18067. Just like the OP of this bug, I feel that in doing testing and such, one would naturally symlink and expect the library in the *current* directory to be imported. And about the CWD, I have demonstrated in issue 18067 how the CWD is in fact reported to be the directory of the *source* of the symlink (i.e. the dir containing the symlink inode) and not the *target* of the symlink. This is precisely what is frustrating about this bug: the fact that Python does not import something from a directory which it reports to be the current directory as per os.getcwd(). While I myself lack the internal CPython code knowledge to fix this, I can't imagine this would be too difficult to fix, given that os.getcwd() already reports the correct current directory -- in setting up the import path list, you just have to use that i.o. whatever else you are using now. Thanks. ---------- nosy: +jamadagni _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 18:07:10 2013 From: report at bugs.python.org (Markus bela) Date: Mon, 27 May 2013 16:07:10 +0000 Subject: [issue17656] Python 2.7.4 breaks ZipFile extraction of zip files with unicode member paths In-Reply-To: <1365391259.55.0.44522935247.issue17656@psf.upfronthosting.co.za> Message-ID: <1369670830.61.0.138659829058.issue17656@psf.upfronthosting.co.za> Changes by Markus bela : ---------- components: +Windows -Library (Lib), Unicode _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 18:50:07 2013 From: report at bugs.python.org (R. David Murray) Date: Mon, 27 May 2013 16:50:07 +0000 Subject: [issue6386] importing yields unexpected results when initial script is a symbolic link In-Reply-To: <1246356344.6.0.218965497612.issue6386@psf.upfronthosting.co.za> Message-ID: <1369673407.43.0.798956863659.issue6386@psf.upfronthosting.co.za> R. David Murray added the comment: When a script is executed by python, it does *not* import from the CWD, it imports from the *location of the script*. From this, then, you can see that there are two possible interpretations of "the location of the script" when the script is a symlink, and we have chosen the more secure (and practical) one: the location of the real script file. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 19:47:42 2013 From: report at bugs.python.org (Dmi Baranov) Date: Mon, 27 May 2013 17:47:42 +0000 Subject: [issue17987] test.support.captured_stderr, captured_stdin not documented In-Reply-To: <1368653423.88.0.898801742943.issue17987@psf.upfronthosting.co.za> Message-ID: <1369676862.54.0.506454708276.issue17987@psf.upfronthosting.co.za> Dmi Baranov added the comment: Added a patch ---------- keywords: +patch nosy: +dmi.baranov Added file: http://bugs.python.org/file30387/issue17987.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 19:59:10 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 May 2013 17:59:10 +0000 Subject: [issue18015] python 2.7.5 fails to unpickle namedtuple pickled by 2.7.3 or 2.7.4 In-Reply-To: <1368988919.46.0.250713350438.issue18015@psf.upfronthosting.co.za> Message-ID: <3bK5Xs36lTz7Lk7@mail.python.org> Roundup Robot added the comment: New changeset 687295c6c8f2 by Raymond Hettinger in branch '2.7': Issue #18015: Fix unpickling of 2.7.3 and 2.7.4 namedtuples. http://hg.python.org/cpython/rev/687295c6c8f2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 20:04:41 2013 From: report at bugs.python.org (Julien Muchembled) Date: Mon, 27 May 2013 18:04:41 +0000 Subject: [issue18073] pickle.Unpickler may read too many bytes, causing hangs with blocking input stream Message-ID: <1369677881.19.0.98233808248.issue18073@psf.upfronthosting.co.za> New submission from Julien Muchembled: I use pickle over sockets to make 2 processes communicate and I experience hangs when the resulting pickle message is exactly 4097 bytes. Attached file is a small script reproducing the issue, trying a few values around 4096. It runs on both Python 2.7 & 3.3: - Python 2.7.3: ok (script exits) - Python 3.3.2: last iteration hangs With strace, you can easily see that after reading the 4097 bytes: [pid 17100] read(3, [pid 17100] <... read resumed> "\200\2X\367\17\0\0 "..., 4096) = 4096 [pid 17100] read(3, ".", 4096) = 1 it reads again without reason: [pid 17100] read(3, No issue with the Python implementation, that you can try with little change: - Python 2.7.3: ok (from pickle import Unpickler) - Python 3.3.2: ok (from pickle import _Unpickler as Unpickler) ---------- components: Extension Modules files: test_case.py messages: 190149 nosy: jm priority: normal severity: normal status: open title: pickle.Unpickler may read too many bytes, causing hangs with blocking input stream type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file30388/test_case.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 20:09:39 2013 From: report at bugs.python.org (Dmi Baranov) Date: Mon, 27 May 2013 18:09:39 +0000 Subject: [issue17987] test.support.captured_stderr, captured_stdin not documented In-Reply-To: <1368653423.88.0.898801742943.issue17987@psf.upfronthosting.co.za> Message-ID: <1369678179.31.0.966572752723.issue17987@psf.upfronthosting.co.za> Dmi Baranov added the comment: Sorry for noise, missed changes in Doc/library/test.rst. Updated patch added ---------- hgrepos: +192 Added file: http://bugs.python.org/file30389/issue17987_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 20:30:20 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 May 2013 18:30:20 +0000 Subject: [issue17987] test.support.captured_stderr, captured_stdin not documented In-Reply-To: <1368653423.88.0.898801742943.issue17987@psf.upfronthosting.co.za> Message-ID: <1369679420.89.0.40593384362.issue17987@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Print to stdin? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 20:34:00 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 May 2013 18:34:00 +0000 Subject: [issue18073] pickle.Unpickler may read too many bytes, causing hangs with blocking input stream In-Reply-To: <1369677881.19.0.98233808248.issue18073@psf.upfronthosting.co.za> Message-ID: <1369679640.5.0.511269274971.issue18073@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +alexandre.vassalotti, pitrou, serhiy.storchaka versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 20:51:11 2013 From: report at bugs.python.org (Dmi Baranov) Date: Mon, 27 May 2013 18:51:11 +0000 Subject: [issue17987] test.support.captured_stderr, captured_stdin not documented In-Reply-To: <1368653423.88.0.898801742943.issue17987@psf.upfronthosting.co.za> Message-ID: <1369680671.3.0.744855248142.issue17987@psf.upfronthosting.co.za> Dmi Baranov added the comment: Yes, I agree that this is not an obvious sample, but: $ ./python -m test.test_support | grep test_captured_stdin test_captured_stdin (__main__.TestSupport) ... ok What's about that? with captured_stdin() as s: s.write('hello\n') s.seek(0) captured = input() assert captured == 'hello' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 22:42:41 2013 From: report at bugs.python.org (Dmi Baranov) Date: Mon, 27 May 2013 20:42:41 +0000 Subject: [issue18033] Example for Profile Module shows incorrect method In-Reply-To: <1369235558.14.0.532987051887.issue18033@psf.upfronthosting.co.za> Message-ID: <1369687361.63.0.548158121186.issue18033@psf.upfronthosting.co.za> Dmi Baranov added the comment: Added py3 patch ---------- keywords: +patch nosy: +dmi.baranov versions: +Python 3.4 Added file: http://bugs.python.org/file30390/issue18033_py3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 22:42:59 2013 From: report at bugs.python.org (Dmi Baranov) Date: Mon, 27 May 2013 20:42:59 +0000 Subject: [issue18033] Example for Profile Module shows incorrect method In-Reply-To: <1369235558.14.0.532987051887.issue18033@psf.upfronthosting.co.za> Message-ID: <1369687379.61.0.207786701287.issue18033@psf.upfronthosting.co.za> Dmi Baranov added the comment: py2 ---------- Added file: http://bugs.python.org/file30391/issue18033_py2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 23:39:36 2013 From: report at bugs.python.org (Dmi Baranov) Date: Mon, 27 May 2013 21:39:36 +0000 Subject: [issue18045] get_python_version is not import in bdist_rpm.py In-Reply-To: <1369355842.75.0.290813933305.issue18045@psf.upfronthosting.co.za> Message-ID: <1369690776.08.0.026338472174.issue18045@psf.upfronthosting.co.za> Dmi Baranov added the comment: Added a patch. Not covered by test, because this case require external module in test package definition. ---------- keywords: +patch nosy: +dmi.baranov Added file: http://bugs.python.org/file30392/issue18045.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon May 27 23:46:44 2013 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 May 2013 21:46:44 +0000 Subject: [issue17206] Py_XDECREF() expands its argument multiple times In-Reply-To: <1360858057.09.0.617835061471.issue17206@psf.upfronthosting.co.za> Message-ID: <3bKBbR6XN3z7LjN@mail.python.org> Roundup Robot added the comment: New changeset aff41a6421c2 by Benjamin Peterson in branch 'default': don't expand the operand to Py_XINCREF/XDECREF/CLEAR/DECREF multiple times (closes #17206) http://hg.python.org/cpython/rev/aff41a6421c2 ---------- nosy: +python-dev resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 00:25:16 2013 From: report at bugs.python.org (Sworddragon) Date: Mon, 27 May 2013 22:25:16 +0000 Subject: [issue18074] argparse: Namespace can contain critical characters Message-ID: <1369693516.49.0.861390993855.issue18074@psf.upfronthosting.co.za> New submission from Sworddragon: Positional arguments which have no dest attribute doesn't replace any - with _. In the attachments is an example script which demonstrate this. The output looks like this: sworddragon at ubuntu:~$ ./args.py foo Namespace(foo-bar2='foo', foo_bar1=None) ---------- components: Library (Lib) files: args.py messages: 190157 nosy: Sworddragon priority: normal severity: normal status: open title: argparse: Namespace can contain critical characters versions: Python 3.3 Added file: http://bugs.python.org/file30393/args.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 00:44:43 2013 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 27 May 2013 22:44:43 +0000 Subject: [issue6386] importing yields unexpected results when initial script is a symbolic link In-Reply-To: <1369673407.43.0.798956863659.issue6386@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: The current behaviour is also needed to sanely support Python scripts symlinked from Linux /bin directories. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 00:51:06 2013 From: report at bugs.python.org (Ned Deily) Date: Mon, 27 May 2013 22:51:06 +0000 Subject: [issue18071] _osx_support compiler_fixup In-Reply-To: <1369663641.63.0.31152522756.issue18071@psf.upfronthosting.co.za> Message-ID: <1369695066.42.0.417070954103.issue18071@psf.upfronthosting.co.za> Ned Deily added the comment: Sorry, I am unable to reproduce the problem with a vanilla Python 2.7.5 and a downloaded Cython 0.19.1 either installing directly with Cython's setup.py or using Pip 1.3.1. customize_compiler is used as part of every extension module build in Distutils; it is not something special. AFAICT, the compiler_so attribute of a CCompiler instance should always be a list. It is intended to be set up as such by the set_executables method of CCompiler (Lib/distutils/ccompiler.py) which calls set_executable for each item, including compiler_so. Now there could be a problem in Python 2 if, for some reason, the value for 'compiler_so' has become a Unicode string: set_executable is looking only for an instance of type str. It looks like the original value for 'compiler_so' is constructed in customize_compiler (in lib/distutils/sysconfig.py) by first concatenating CC + ' ' + CFLAGS, where the CC and CFLAGS values are obtained from the Python build (using get_config_vars) and possibly overridden by environment variables of the same names. Then the value of the config var 'CCSHARED' is appended; it most likely is empty. So I would check to see the types of distutils.sysconfig.get_config_var("CC") and ("CFLAGS") and ("CCSHARED") as well as os.environ["CC"] and ["CFLAGS"]. If any of them return a type unicode string, I think that could explain the behavior you see. The use of Unicode strings for these kinds of values are likely to lead to trouble, one way or another, in Python 2 for sure. (Also, be aware that Cython extends Distutils with its own build_ext to allow building of Cython modules. I took a very quick look at it and did not see any obvious problems.) ---------- assignee: ronaldoussoren -> ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 01:11:43 2013 From: report at bugs.python.org (Sworddragon) Date: Mon, 27 May 2013 23:11:43 +0000 Subject: [issue18074] argparse: Namespace can contain critical characters In-Reply-To: <1369693516.49.0.861390993855.issue18074@psf.upfronthosting.co.za> Message-ID: <1369696303.82.0.630069977979.issue18074@psf.upfronthosting.co.za> Sworddragon added the comment: I have found another report about this: http://bugs.python.org/issue15125 ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 01:12:35 2013 From: report at bugs.python.org (Sworddragon) Date: Mon, 27 May 2013 23:12:35 +0000 Subject: [issue18074] argparse: Namespace can contain critical characters In-Reply-To: <1369693516.49.0.861390993855.issue18074@psf.upfronthosting.co.za> Message-ID: <1369696355.86.0.645394257623.issue18074@psf.upfronthosting.co.za> Changes by Sworddragon : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 01:36:53 2013 From: report at bugs.python.org (Brett Cannon) Date: Mon, 27 May 2013 23:36:53 +0000 Subject: [issue18072] Add an implementation of importlib.abc.InspectLoader.get_code In-Reply-To: <1369667022.96.0.117125531861.issue18072@psf.upfronthosting.co.za> Message-ID: <1369697813.87.0.309845935861.issue18072@psf.upfronthosting.co.za> Brett Cannon added the comment: So it turns out I will simply have to make the methods not abstract anymore. Thanks to multiple inheritance I can't implement the method in ExecutionLoader and keep it abstract in case someone subclasses InspectLoader and then creates another subclass of ExecutionLoader and the InspectLoader subclass w/o making ExecutionLoader.get_code not abstract. But if I can't do it there then it seems silly to leave only InspectLoader.get_code abstract. IOW get_code will not longer be abstract and I will leave a note in the docs to mention you probably want to consider overriding the method for performance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 02:14:10 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 28 May 2013 00:14:10 +0000 Subject: [issue18074] argparse: Namespace can contain critical characters In-Reply-To: <1369693516.49.0.861390993855.issue18074@psf.upfronthosting.co.za> Message-ID: <1369700050.31.0.564377573259.issue18074@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- superseder: -> argparse: positional arguments containing - in name not handled well _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 03:02:08 2013 From: report at bugs.python.org (Brett Cannon) Date: Tue, 28 May 2013 01:02:08 +0000 Subject: [issue18075] Infinite recursion tests triggering a segfault Message-ID: <1369702928.42.0.612737848185.issue18075@psf.upfronthosting.co.za> New submission from Brett Cannon: If you run any test that has infinite recursion (test_json test_exceptions test_sys test_runpy) it will segfault with a fresh checkout under OS X 10.8.3 using Clang. Not sure how widespread this is. I did check that I am using a clean checkout of the default branch. ---------- components: Interpreter Core messages: 190162 nosy: brett.cannon, larry priority: release blocker severity: normal status: open title: Infinite recursion tests triggering a segfault type: crash versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 03:12:50 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 May 2013 01:12:50 +0000 Subject: [issue18072] Add an implementation of importlib.abc.InspectLoader.get_code In-Reply-To: <1369667022.96.0.117125531861.issue18072@psf.upfronthosting.co.za> Message-ID: <3bKH9F4XhVz7Lln@mail.python.org> Roundup Robot added the comment: New changeset 11510db74223 by Brett Cannon in branch 'default': Issue #18072: Implement get_code() for importlib.abc.InspectLoader and http://hg.python.org/cpython/rev/11510db74223 New changeset 2ea849fde22b by Brett Cannon in branch 'default': NEWS entry for issue #18072 http://hg.python.org/cpython/rev/2ea849fde22b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 03:15:26 2013 From: report at bugs.python.org (Brett Cannon) Date: Tue, 28 May 2013 01:15:26 +0000 Subject: [issue18072] Add an implementation of importlib.abc.InspectLoader.get_code In-Reply-To: <1369667022.96.0.117125531861.issue18072@psf.upfronthosting.co.za> Message-ID: <1369703726.41.0.33092099307.issue18072@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 03:24:09 2013 From: report at bugs.python.org (Brett Cannon) Date: Tue, 28 May 2013 01:24:09 +0000 Subject: [issue18076] Implement importlib.util.decode_source_bytes() Message-ID: <1369704249.95.0.785002868519.issue18076@psf.upfronthosting.co.za> New submission from Brett Cannon: Right now importlib.abc.SourceLoader implements get_source(), but most of it is decoding bytes properly. That should probably be abstracted out to importlib.util so that it's available even for loaders which don't provide get_data() or get_filename(). ---------- assignee: brett.cannon components: Library (Lib) messages: 190164 nosy: brett.cannon priority: normal severity: normal stage: test needed status: open title: Implement importlib.util.decode_source_bytes() type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 03:25:17 2013 From: report at bugs.python.org (Brett Cannon) Date: Tue, 28 May 2013 01:25:17 +0000 Subject: [issue18055] Stop using imp in IDLE In-Reply-To: <1369496414.51.0.562875229152.issue18055@psf.upfronthosting.co.za> Message-ID: <1369704317.53.0.944298656542.issue18055@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 03:34:34 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 May 2013 01:34:34 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <3bKHfK4dSkz7Lln@mail.python.org> Roundup Robot added the comment: New changeset 24c3e7e08168 by Terry Jan Reedy in branch '3.3': Issue #15392: Create a unittest framework for IDLE. http://hg.python.org/cpython/rev/24c3e7e08168 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 03:35:16 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 28 May 2013 01:35:16 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1369704916.38.0.612816703663.issue15392@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Before committing, I experimented with disabling test/test_idle. The simple and safe method is to comment out the 'load_tests' line. With no tests discovered, all pass ;-). Without verbosity, there is no indication that there were none. A little harder, and needing to be tested for typos before committing, is to add this line before that line: import unittest; raise unittest.SkipTest('skip for buildbots') Regrtest (py -m test test_idle) registers the unexpected skip. Unittest (py -m test.test_idle) exits with a traceback. This is recorded in an updated README, which also incorporates Todd's suggestion. I also touched up test/test_idle.py. If buildbots do not break, I will work on 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 03:56:05 2013 From: report at bugs.python.org (Shriramana Sharma) Date: Tue, 28 May 2013 01:56:05 +0000 Subject: [issue6386] importing yields unexpected results when initial script is a symbolic link In-Reply-To: <1246356344.6.0.218965497612.issue6386@psf.upfronthosting.co.za> Message-ID: <1369706165.64.0.966524911155.issue6386@psf.upfronthosting.co.za> Shriramana Sharma added the comment: > The current behaviour is also needed to sanely support Python > scripts symlinked from Linux /bin directories. OK that clinched it for me -- I can't argue against that! And obviously it is not meaningful to copy/symlink *all* the current-directory modules a particular script depends upon to the symlink directory as well. And searching both directories (containing the source and target of the symlink) is not good for security I guess. And I also checked the contents of sys.path with my test case -- and sure enough the directory corresponding to the actual output was printed. Just that sys.path is different from os.getcwd() needs some effort to bring into mind. So I think someone should please clearly mention this behaviour in the documentation under http://docs.python.org/3/tutorial/modules.html#the-module-search-path and the Py2 equivalent. Specifically this point needs clarification: ""the directory containing the input script (or the current directory)."" It would be best to remove the text in parantheses (which immediately makes one think of os.getcwd()) and add a clarification like: Note that on filesystems that support symlinks, this means the directory containing the actual script file. Symlinks to the script may be present elsewhere and may be used to invoke the script, but the directories containing those symlinks will *not* be searched for dependency modules. Thank you very much for these clarifications and for your work on Python! Please do add the above documentation clarification, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 04:07:28 2013 From: report at bugs.python.org (Jason R. Coombs) Date: Tue, 28 May 2013 02:07:28 +0000 Subject: [issue13772] listdir() doesn't work with non-trivial symlinks In-Reply-To: <1326312074.88.0.322514160628.issue13772@psf.upfronthosting.co.za> Message-ID: <1369706848.19.0.252644002885.issue13772@psf.upfronthosting.co.za> Jason R. Coombs added the comment: Ugh. So it seems the 3.3 implementation of win_symlink, which is now been renamed to posix_symlink, is now much more complicated. Not only does it handle symlink arguments on Unix platforms, providing abstraction for a couple of underlying system calls, but the Windows implementation also supports once again wide and narrow characters for the path, which means that the directory detection functions I created are no longer suitable as they also need wide and narrow versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 04:08:54 2013 From: report at bugs.python.org (Elazar Gershuni) Date: Tue, 28 May 2013 02:08:54 +0000 Subject: [issue18077] dis.dis throws IndexError Message-ID: <1369706934.04.0.701065482514.issue18077@psf.upfronthosting.co.za> New submission from Elazar Gershuni: >>> dis.dis('pass') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/dis.py", line 45, in dis disassemble_string(x) File "/usr/lib/python2.7/dis.py", line 112, in disassemble_string labels = findlabels(code) File "/usr/lib/python2.7/dis.py", line 166, in findlabels oparg = ord(code[i]) + ord(code[i+1])*256 IndexError: string index out of range it happens for any string. ---------- components: Library (Lib) messages: 190169 nosy: elazar priority: normal severity: normal status: open title: dis.dis throws IndexError type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 04:12:55 2013 From: report at bugs.python.org (Elazar Gershuni) Date: Tue, 28 May 2013 02:12:55 +0000 Subject: [issue18077] dis.dis throws IndexError In-Reply-To: <1369706934.04.0.701065482514.issue18077@psf.upfronthosting.co.za> Message-ID: <1369707175.34.0.768980279024.issue18077@psf.upfronthosting.co.za> Elazar Gershuni added the comment: it happens that: (code, i) == ('pass', 4) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 04:17:12 2013 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 28 May 2013 02:17:12 +0000 Subject: [issue6386] importing yields unexpected results when initial script is a symbolic link In-Reply-To: <1246356344.6.0.218965497612.issue6386@psf.upfronthosting.co.za> Message-ID: <1369707432.84.0.118618325238.issue6386@psf.upfronthosting.co.za> Nick Coghlan added the comment: That's fair - reopening this as a docs bug. ---------- assignee: brett.cannon -> components: +Documentation resolution: wont fix -> stage: test needed -> needs patch status: closed -> open type: behavior -> enhancement versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 05:28:40 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 May 2013 03:28:40 +0000 Subject: [issue13772] listdir() doesn't work with non-trivial symlinks In-Reply-To: <1326312074.88.0.322514160628.issue13772@psf.upfronthosting.co.za> Message-ID: <3bKL9z1YjHzPvG@mail.python.org> Roundup Robot added the comment: New changeset 29a2557d693e by Jason R. Coombs in branch '3.3': Issue #13772: Restored directory detection of targets in `os.symlink` on Windows, which was temporarily removed in Python 3.2.3 due to an incomplete implementation. The implementation now works even if the symlink is created in a location other than the current directory. http://hg.python.org/cpython/rev/29a2557d693e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 05:40:19 2013 From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=) Date: Tue, 28 May 2013 03:40:19 +0000 Subject: [issue18078] threading.Condition to allow notify on a specific waiter Message-ID: <1369712419.12.0.434704480843.issue18078@psf.upfronthosting.co.za> New submission from Jo?o Bernardo: If users could provide an inner lock for `threading.Condition` acquire when making a thread wait, it would allow for notifying a specific waiter. Because of race conditions, using: cond.notify(1) may not wake the thread I want. Also, I may not want to wake the first waiter at all. So my proposal is something along the lines: class Condition: ... def wait(self, timeout=None, lock=None): ... waiter = _allocate_lock() if lock is None else lock ... def notify_one(self, lock): # Maybe could notify a list of locks? try: self._waiters.remove(lock) except ValueError: pass # Maybe RuntimeError("Lock not waiting in this Condition") else: lock.release() ---------- components: Library (Lib) messages: 190173 nosy: JBernardo priority: normal severity: normal status: open title: threading.Condition to allow notify on a specific waiter type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 06:25:14 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 28 May 2013 04:25:14 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1369715114.07.0.419425056463.issue15392@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Last I checked, test_idle passes on the stable buildbots. But it fails on a machine without threads, such as http://buildbot.python.org/all/builders /AMD64%20Fedora%20without%20threads%203.3/builds/752/steps/test/logs/stdio On this machine, thread-related tests are skipped: some seem expected, some not. The chain of imports is test_pathbrowser <- PathBrowser <- ClassBrowser <- PyShell <- threading <- _thread. Since a PyShell import is required to run Idle (PyShell.main), even with just the editor, I will put the _thread import check in test_idle itself rather than sprinkling it throughout the test suite as dependencies are discovered. (Besides the bother of the latter, the dependency could go away if PyShell only uses threading to runs user code in the same process, or delayed if it is used for other features that might not be used.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 07:39:54 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Tue, 28 May 2013 05:39:54 +0000 Subject: [issue5664] 2to3 wont convert Cookie.Cookie properly In-Reply-To: <1238642568.2.0.229238012255.issue5664@psf.upfronthosting.co.za> Message-ID: <1369719594.88.0.332236620798.issue5664@psf.upfronthosting.co.za> Senthil Kumaran added the comment: Not actually, It is still translating to http.cookies.Cookie - which does not exist. $ ./cpythonvenv/bin/2to3-3.4 bug-fixes/test1.py RefactoringTool: Refactored bug-fixes/test1.py --- bug-fixes/test1.py (original) +++ bug-fixes/test1.py (refactored) @@ -1,2 +1,2 @@ -import Cookie -c = Cookie.Cookie('abc') +import http.cookies +c = http.cookies.Cookie('abc') BTW, Cookie.Cookie is a deprecated interface so there is a possibility that only small portion of the real world code which has not updated their Python stdlib idioms since (Python 2.2/Python2.4?) would see this bug manifested. [Note: Long-time users of Cookie.py will remember using Cookie.Cookie() to create an Cookie object. Although deprecated, it is still supported by the code. See the Backward Compatibility notes for more information.] ---------- versions: +Python 3.4 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 08:32:52 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 28 May 2013 06:32:52 +0000 Subject: [issue18077] dis.dis throws IndexError In-Reply-To: <1369706934.04.0.701065482514.issue18077@psf.upfronthosting.co.za> Message-ID: <1369722772.78.0.87776312924.issue18077@psf.upfronthosting.co.za> Ronald Oussoren added the comment: AFAIK dis.dis only decompiles bytecode in python 2, as is mentioned in the documentation at . In Python 3 dis.dis can compile a string with Python source to bytecode and decompile that (see ). Thus this is IMHO not a bug. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 08:53:27 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 28 May 2013 06:53:27 +0000 Subject: [issue11965] Simplify context manager in os.popen In-Reply-To: <1304178570.81.0.335603645525.issue11965@psf.upfronthosting.co.za> Message-ID: <1369724007.34.0.914224921721.issue11965@psf.upfronthosting.co.za> Ronald Oussoren added the comment: Mark: if you know Python you can answer that question yourself by reading the code of the subprocess and os modules. >From a fairly short glance at the code I'd say that _wrap_close is not obsolete. It is a wrapper about a file object for the stdout or stdin stream of a Popen object (depending on the last argument of os.popen), and when _wrap_close.close is called it closes the wrapped stream, then waits for the subprocess to die and returns a *transformation* of the exitcode attribute. If my interpretation of the _wrap_close is correct this issue can be closed as invalid (the code cannot be cleaned up without changing functionality) ---------- nosy: +ronaldoussoren versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 09:26:22 2013 From: report at bugs.python.org (arbour) Date: Tue, 28 May 2013 07:26:22 +0000 Subject: [issue18079] documentation tutorial 3.1.3 typo Message-ID: <1369725982.22.0.36331305671.issue18079@psf.upfronthosting.co.za> New submission from arbour: documentation tutorial 3.1.3 typo at page 15 (21/127) >>> p[0] ['a','b','c'] >>> p[0][1] 'b' should be: >>> x[0] ['a','b','c'] >>> x[0][1] 'b' ---------- assignee: docs at python components: Documentation files: tutorial.pdf messages: 190178 nosy: arbour, docs at python priority: normal severity: normal status: open title: documentation tutorial 3.1.3 typo versions: Python 3.3 Added file: http://bugs.python.org/file30394/tutorial.pdf _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 10:28:50 2013 From: report at bugs.python.org (Elazar Gershuni) Date: Tue, 28 May 2013 08:28:50 +0000 Subject: [issue18077] dis.dis throws IndexError In-Reply-To: <1369706934.04.0.701065482514.issue18077@psf.upfronthosting.co.za> Message-ID: <1369729730.76.0.482393970055.issue18077@psf.upfronthosting.co.za> Elazar Gershuni added the comment: Is it standard procedure to raise an unrelated exception in when an invalid parameter is passed? I did not encounter any other library function that behaves like this. Especially taking the fact that this is the normal usage in python3. How do I supposed to *know* this is not a bug? I can't find similar behavior in other library functions. An IndexError and a traceback *inside the library* does not help. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 10:33:36 2013 From: report at bugs.python.org (Elazar Gershuni) Date: Tue, 28 May 2013 08:33:36 +0000 Subject: [issue18077] dis.dis raises IndexError In-Reply-To: <1369706934.04.0.701065482514.issue18077@psf.upfronthosting.co.za> Message-ID: <1369730016.24.0.595228476851.issue18077@psf.upfronthosting.co.za> Changes by Elazar Gershuni : ---------- title: dis.dis throws IndexError -> dis.dis raises IndexError _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 10:36:23 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 28 May 2013 08:36:23 +0000 Subject: [issue18077] dis.dis throws IndexError In-Reply-To: <1369729730.76.0.482393970055.issue18077@psf.upfronthosting.co.za> Message-ID: Ronald Oussoren added the comment: On 28 May, 2013, at 10:28, Elazar Gershuni wrote: > > Elazar Gershuni added the comment: > > Is it standard procedure to raise an unrelated exception in when an invalid parameter is passed? I did not encounter any other library function that behaves like this. Especially taking the fact that this is the normal usage in python3. This is not the normal usage in python3, but one of the usecases supported in python3. In python3 compiled code is a byte string and source code is a regular (unicode) string, which means the two can easily be recognized, while in python2 both are 'str' strings. > > How do I supposed to *know* this is not a bug? By reading the documentation? > I can't find similar behavior in other library functions. An IndexError and a traceback *inside the library* does not help. Other library functions can also raise fairly obscure exceptions when you pass in bad data, as an example of this "os.path.join(None, 'a')" raises AttributeError. ---------- title: dis.dis raises IndexError -> dis.dis throws IndexError _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 10:43:12 2013 From: report at bugs.python.org (Elazar Gershuni) Date: Tue, 28 May 2013 08:43:12 +0000 Subject: [issue18077] dis.dis throws IndexError In-Reply-To: <1369706934.04.0.701065482514.issue18077@psf.upfronthosting.co.za> Message-ID: <1369730592.08.0.871116055526.issue18077@psf.upfronthosting.co.za> Elazar Gershuni added the comment: If you pass 'None' for `path`, then "'NoneType' object has no attribute 'endswith'" is not as nearly as obscure. But if you insist not to fix it, and don't mind to leave another arbitrary inconsistency between python2 and python3 obscured, I have nothing more to say - you can close it if you want. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 11:27:55 2013 From: report at bugs.python.org (Ned Deily) Date: Tue, 28 May 2013 09:27:55 +0000 Subject: [issue18080] setting CC no longer overrides default linker for extension module builds on OS X Message-ID: <1369733275.86.0.789396593602.issue18080@psf.upfronthosting.co.za> New submission from Ned Deily: As part of the initial changes for Issue13590 in 2.7.3, 3.2.3, and 3.3 (prior to release) to Distutils to support building extension modules on OS X with Xcode 4, code was added to substitute the clang compiler if the older gcc-4.2 supplied with Xcode 3 was not found. In addition, the changes made it easier for the user to override the compiler for both the compile and linking stages: "Also as a convenience, if the user does explicitly set CC, substitute its value as the default compiler in the Distutils LDSHARED configuration variable for OS X." This eliminated the need to construct a complete LDSHARED value. For 2.7.4, 3.2.4, and 3.3.0, more extensive changes were made to fully support the latest releases of Xcode 4. Unfortunately, the code to override LDSHARED if CC is set was inadvertently deleted for these later releases. The attached patch restores the deleted override behavior and adds tests. ---------- assignee: ned.deily components: Distutils, Macintosh messages: 190182 nosy: ned.deily, tarek priority: normal severity: normal stage: patch review status: open title: setting CC no longer overrides default linker for extension module builds on OS X type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 11:30:45 2013 From: report at bugs.python.org (Ned Deily) Date: Tue, 28 May 2013 09:30:45 +0000 Subject: [issue18080] setting CC no longer overrides default linker for extension module builds on OS X In-Reply-To: <1369733275.86.0.789396593602.issue18080@psf.upfronthosting.co.za> Message-ID: <1369733445.24.0.358617503722.issue18080@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- keywords: +patch nosy: +ronaldoussoren Added file: http://bugs.python.org/file30395/issue18080_ldshared_2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 11:44:35 2013 From: report at bugs.python.org (Michael Foord) Date: Tue, 28 May 2013 09:44:35 +0000 Subject: [issue18054] Add more exception related assertions to unittest In-Reply-To: <1369464959.25.0.285327189549.issue18054@psf.upfronthosting.co.za> Message-ID: <1369734275.94.0.87758804406.issue18054@psf.upfronthosting.co.za> Michael Foord added the comment: I'm slightly torn. TestCase has a wide (waaaay too wide) API and adding methods makes it wider. The use cases for these methods are relatively niche, so my instinct would be that these don't meet the bar for inclusion on TestCase. On the other hand, despite their brevity they're hard to get right, so having them in the standard library is helpful from that point of view. I might be more sympathetic to having some helper mixin classes, so that we can provide esoteric-but-difficult assert methods without having to dump them all on TestCase. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 11:46:10 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 09:46:10 +0000 Subject: [issue18079] documentation tutorial 3.1.3 typo In-Reply-To: <1369725982.22.0.36331305671.issue18079@psf.upfronthosting.co.za> Message-ID: <1369734370.01.0.452108363635.issue18079@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: docs at python -> serhiy.storchaka nosy: +serhiy.storchaka versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 11:53:27 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 May 2013 09:53:27 +0000 Subject: [issue18079] documentation tutorial 3.1.3 typo In-Reply-To: <1369725982.22.0.36331305671.issue18079@psf.upfronthosting.co.za> Message-ID: <3bKVjz04kqzPSZ@mail.python.org> Roundup Robot added the comment: New changeset bde91dddbcbc by Serhiy Storchaka in branch '3.3': Issue #18079: Fix a typo in the tutorial. http://hg.python.org/cpython/rev/bde91dddbcbc New changeset 09b88b5bebd0 by Serhiy Storchaka in branch 'default': Issue #18079: Fix a typo in the tutorial. http://hg.python.org/cpython/rev/09b88b5bebd0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 11:55:27 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 09:55:27 +0000 Subject: [issue18077] dis.dis raises IndexError In-Reply-To: <1369706934.04.0.701065482514.issue18077@psf.upfronthosting.co.za> Message-ID: <1369734927.71.0.951191228078.issue18077@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Seconded Ronald. It's not a bug. ---------- nosy: +serhiy.storchaka resolution: -> invalid stage: -> committed/rejected status: open -> closed title: dis.dis throws IndexError -> dis.dis raises IndexError type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 11:56:55 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 28 May 2013 09:56:55 +0000 Subject: [issue18077] dis.dis raises IndexError In-Reply-To: <1369706934.04.0.701065482514.issue18077@psf.upfronthosting.co.za> Message-ID: <1369735015.56.0.101012531567.issue18077@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The automatic compilation of source code cannot be added to the 2.7 version of the dis module because that would be a new feature and we don't add new features in bugfix releases. The feature was added to Python 3.x in issue #6507, and was first included in the 3.2 feature release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 11:57:11 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 09:57:11 +0000 Subject: [issue18079] documentation tutorial 3.1.3 typo In-Reply-To: <1369725982.22.0.36331305671.issue18079@psf.upfronthosting.co.za> Message-ID: <1369735031.39.0.0663264870679.issue18079@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed. Thank you for your report. ---------- resolution: -> fixed stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 11:58:58 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 09:58:58 +0000 Subject: [issue18078] threading.Condition to allow notify on a specific waiter In-Reply-To: <1369712419.12.0.434704480843.issue18078@psf.upfronthosting.co.za> Message-ID: <1369735138.27.0.874521512317.issue18078@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 12:04:58 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 10:04:58 +0000 Subject: [issue18054] Add more exception related assertions to unittest In-Reply-To: <1369464959.25.0.285327189549.issue18054@psf.upfronthosting.co.za> Message-ID: <1369735498.67.0.404455828748.issue18054@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm sure not all user of the TestCase class even know about all it's existing methods. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 12:15:40 2013 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 28 May 2013 10:15:40 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1369736140.19.0.722481218198.issue15392@psf.upfronthosting.co.za> Nick Coghlan added the comment: Building without threads is generally going to be for embedded systems without a GUI anyway, so I think it's fine to just skip the entire IDLE test suite when real threads aren't available. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 12:17:04 2013 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 28 May 2013 10:17:04 +0000 Subject: [issue18054] Add more exception related assertions to unittest In-Reply-To: <1369464959.25.0.285327189549.issue18054@psf.upfronthosting.co.za> Message-ID: <1369736224.75.0.692448984249.issue18054@psf.upfronthosting.co.za> Nick Coghlan added the comment: I like the idea of a separate mixin class like TracebackMixin or TracebackHelper. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 12:22:06 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 10:22:06 +0000 Subject: [issue17987] test.support.captured_stderr, captured_stdin not documented In-Reply-To: <1368653423.88.0.898801742943.issue17987@psf.upfronthosting.co.za> Message-ID: <1369736526.0.0.679260176391.issue17987@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I believe it is a mechanical mistake in test_captured_stdin(). ---------- nosy: +eli.bendersky versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 12:23:38 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 28 May 2013 10:23:38 +0000 Subject: [issue18075] Infinite recursion tests triggering a segfault In-Reply-To: <1369702928.42.0.612737848185.issue18075@psf.upfronthosting.co.za> Message-ID: <1369736618.14.0.0992213959134.issue18075@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I can confirm the problem. It appears to be a stack overflow, when I increase the stack size of the main thead (by adding "-Wl,-stack_size,2faf000" to the link command for BUILDPYTHON) the crash in test_json goes away. Appearently the default maximum stack size isn't large enough for the default value of the recursion limit. An easy workaround (fix?) would be to add -Wl,-stack_size,VALUE to the link flags on OSX, for some sane value of VALUE. The value is the maximum size of the stack of the main thread and doesn't affect process size unless a process actually uses more stack space. It does affect the available free address space, and hence the maximum stack size shouldn't be increased too far (especially for 32-bit builds) ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 12:38:17 2013 From: report at bugs.python.org (Aaron Iles) Date: Tue, 28 May 2013 10:38:17 +0000 Subject: [issue18054] Add more exception related assertions to unittest In-Reply-To: <1369464959.25.0.285327189549.issue18054@psf.upfronthosting.co.za> Message-ID: <1369737497.04.0.0957692560854.issue18054@psf.upfronthosting.co.za> Changes by Aaron Iles : ---------- nosy: +aliles _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 13:00:53 2013 From: report at bugs.python.org (Ankur Ankan) Date: Tue, 28 May 2013 11:00:53 +0000 Subject: [issue8083] urllib proxy interface is too limited In-Reply-To: <1267960974.57.0.282582505856.issue8083@psf.upfronthosting.co.za> Message-ID: <1369738853.79.0.971595025252.issue8083@psf.upfronthosting.co.za> Changes by Ankur Ankan : ---------- nosy: +Ankur.Ankan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 13:03:34 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 28 May 2013 11:03:34 +0000 Subject: [issue18078] threading.Condition to allow notify on a specific waiter In-Reply-To: <1369712419.12.0.434704480843.issue18078@psf.upfronthosting.co.za> Message-ID: <1369739014.53.0.490128273358.issue18078@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I'm not sure what the point is. If you want to wake up a specific thread, you'd probably be better off with a dedicated per-thread synchronization primitive (either a Condition or something else). ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 13:10:05 2013 From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=) Date: Tue, 28 May 2013 11:10:05 +0000 Subject: [issue18078] threading.Condition to allow notify on a specific waiter In-Reply-To: <1369712419.12.0.434704480843.issue18078@psf.upfronthosting.co.za> Message-ID: <1369739405.36.0.376029859325.issue18078@psf.upfronthosting.co.za> Jo?o Bernardo added the comment: I usually have hundreds of threads waiting on a single Condition object and I wake them with .notify_all() Sometimes, I want a specific thread to wake from this condition and finish their job apart from the others. The problem is that I have 2 "conditions" to wait for. I can't just add another Condition object and ask for it to wait for the first (unless there is some sort of `select` mechanism). BTW, I find .notify(N) not much useful, because the docs say it may wake more threads on a different implementation and also I can't never know whom am I waking. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 13:19:09 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 11:19:09 +0000 Subject: [issue18050] embedded interpreter or virtualenv fails with "ImportError: cannot import name MAXREPEAT" In-Reply-To: <1369417243.06.0.993082490408.issue18050@psf.upfronthosting.co.za> Message-ID: <1369739949.32.0.732137706766.issue18050@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I am afraid that importing MAXREPEAT is not the only issue. Short time ago, CODESIZE was increased from 2 to 4 on narrow builds (issue1160). This makes compiled patterns generated by Lib/sre_compile.py incompatible with old _sre module on narrow builds. I think it is a bad idea to mix a different versions of Python stdlib code and corresponded binary extensions. There are other examples when Python and C code changed synchronously and Python code depends on new names exposed by C module (i.e. 35ef949e85d7, b6ec3b717f7e). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 13:44:49 2013 From: report at bugs.python.org (Dmi Baranov) Date: Tue, 28 May 2013 11:44:49 +0000 Subject: [issue17987] test.support.captured_stderr, captured_stdin not documented In-Reply-To: <1368653423.88.0.898801742943.issue17987@psf.upfronthosting.co.za> Message-ID: <1369741489.42.0.368716090486.issue17987@psf.upfronthosting.co.za> Dmi Baranov added the comment: `captured_stdin` test changed, docs updated. ---------- Added file: http://bugs.python.org/file30396/issue17987_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 13:45:55 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 28 May 2013 11:45:55 +0000 Subject: [issue18080] setting CC no longer overrides default linker for extension module builds on OS X In-Reply-To: <1369733275.86.0.789396593602.issue18080@psf.upfronthosting.co.za> Message-ID: <1369741555.22.0.201546173964.issue18080@psf.upfronthosting.co.za> Ronald Oussoren added the comment: LGTM ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 14:12:32 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 12:12:32 +0000 Subject: [issue17987] test.support.captured_stderr, captured_stdin not documented In-Reply-To: <1368653423.88.0.898801742943.issue17987@psf.upfronthosting.co.za> Message-ID: <1369743152.31.0.793357457987.issue17987@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think it will be better to describe all three functions together (as sys.stdin/stdout/stderr). .. function:: captured_stdin() captured_stdout() captured_stderr() ... description ... Example use:: ... example for captured_stdin() ... ... example for captured_stdout() ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 14:25:35 2013 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Tue, 28 May 2013 12:25:35 +0000 Subject: [issue17987] test.support.captured_stderr, captured_stdin not documented In-Reply-To: <1368653423.88.0.898801742943.issue17987@psf.upfronthosting.co.za> Message-ID: <1369743935.1.0.586954762302.issue17987@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: Joining the documentation for captured_stderr and captured_stdout makes sense, as they can really use a single example, and the usage is completely parallel. I'd rather see captured_stdin handled separately, perhaps with some additional comments in the example, to emphasize the intended usage pattern: with support.captured_stdin() as s: # Prepare simulated input: s.write('hello\n') s.seek(0) # Call test code that consumes from stdin: captured = input() self.assertEqual(captured, "hello") ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 14:31:27 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 28 May 2013 12:31:27 +0000 Subject: [issue18075] Infinite recursion tests triggering a segfault In-Reply-To: <1369702928.42.0.612737848185.issue18075@psf.upfronthosting.co.za> Message-ID: <1369744287.38.0.634337931106.issue18075@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The attached patch fixes the problem on OSX by increasing the maximum stack size of the main thread from 8M (the default) to 16M. NOTE: The -Wl,-stack_size,... option cannot be added to LDFLAGS, ld errors out when that option is used when linking a shared library (such as the extensions or libpython.dylib) ---------- stage: -> patch review Added file: http://bugs.python.org/file30397/issue-18075-osx-stacksize.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 14:35:30 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 May 2013 12:35:30 +0000 Subject: [issue18011] Inconsistency between b32decode() documentation, docstring and code In-Reply-To: <1368951549.72.0.00589705304437.issue18011@psf.upfronthosting.co.za> Message-ID: <3bKZJx2mYQzRmp@mail.python.org> Roundup Robot added the comment: New changeset 0b9bcb2ac145 by Serhiy Storchaka in branch '3.3': Issue #18011: base64.b32decode() now raises a binascii.Error if there are http://hg.python.org/cpython/rev/0b9bcb2ac145 New changeset 7446f53ba2d2 by Serhiy Storchaka in branch 'default': Issue #18011: base64.b32decode() now raises a binascii.Error if there are http://hg.python.org/cpython/rev/7446f53ba2d2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 14:36:41 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 12:36:41 +0000 Subject: [issue18011] Inconsistency between b32decode() documentation, docstring and code In-Reply-To: <1368951549.72.0.00589705304437.issue18011@psf.upfronthosting.co.za> Message-ID: <1369744601.22.0.662116879999.issue18011@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 14:43:15 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 May 2013 12:43:15 +0000 Subject: [issue18011] Inconsistency between b32decode() documentation, docstring and code In-Reply-To: <1368951549.72.0.00589705304437.issue18011@psf.upfronthosting.co.za> Message-ID: <3bKZTv1nXjzP9n@mail.python.org> Roundup Robot added the comment: New changeset 29a823f31465 by Serhiy Storchaka in branch 'default': Issue #18011: Silence an unrelated noise introduced in changeset 1b5ef05d6ced. http://hg.python.org/cpython/rev/29a823f31465 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 14:56:32 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 May 2013 12:56:32 +0000 Subject: [issue17746] test_shutil.TestWhich.test_non_matching_mode fails when running as root In-Reply-To: <1366099998.54.0.409643145074.issue17746@psf.upfronthosting.co.za> Message-ID: <3bKZnC4tmczQYY@mail.python.org> Roundup Robot added the comment: New changeset b98380a1d979 by Serhiy Storchaka in branch '3.3': Issue #17746: Skip test_shutil.test_non_matching_mode when run as root or http://hg.python.org/cpython/rev/b98380a1d979 New changeset 96e543ba96a4 by Serhiy Storchaka in branch 'default': Issue #17746: Skip test_shutil.test_non_matching_mode when run as root or http://hg.python.org/cpython/rev/96e543ba96a4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 15:04:48 2013 From: report at bugs.python.org (Dmi Baranov) Date: Tue, 28 May 2013 13:04:48 +0000 Subject: [issue17987] test.support.captured_stderr, captured_stdin not documented In-Reply-To: <1368653423.88.0.898801742943.issue17987@psf.upfronthosting.co.za> Message-ID: <1369746288.71.0.67320619573.issue17987@psf.upfronthosting.co.za> Dmi Baranov added the comment: Amended, as discussed. Also changed documentation from "how to use a context managers with that" to "how it works". ---------- Added file: http://bugs.python.org/file30398/issue17987_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 15:13:16 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 13:13:16 +0000 Subject: [issue17746] test_shutil.TestWhich.test_non_matching_mode fails when running as root In-Reply-To: <1366099998.54.0.409643145074.issue17746@psf.upfronthosting.co.za> Message-ID: <1369746796.91.0.922686259632.issue17746@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 15:18:35 2013 From: report at bugs.python.org (Eli Bendersky) Date: Tue, 28 May 2013 13:18:35 +0000 Subject: [issue17987] test.support.captured_stderr, captured_stdin not documented In-Reply-To: <1368653423.88.0.898801742943.issue17987@psf.upfronthosting.co.za> Message-ID: <1369747115.78.0.405838361499.issue17987@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- nosy: -eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 15:20:37 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Tue, 28 May 2013 13:20:37 +0000 Subject: [issue18075] Infinite recursion tests triggering a segfault In-Reply-To: <1369702928.42.0.612737848185.issue18075@psf.upfronthosting.co.za> Message-ID: <1369747237.97.0.0791888706232.issue18075@psf.upfronthosting.co.za> Ronald Oussoren added the comment: The update fixes the name error mention in rietveld. ---------- Added file: http://bugs.python.org/file30399/issue-18075-osx-stacksize-update.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 15:26:36 2013 From: report at bugs.python.org (Brett Cannon) Date: Tue, 28 May 2013 13:26:36 +0000 Subject: [issue18075] Infinite recursion tests triggering a segfault In-Reply-To: <1369702928.42.0.612737848185.issue18075@psf.upfronthosting.co.za> Message-ID: <1369747596.57.0.388024288639.issue18075@psf.upfronthosting.co.za> Brett Cannon added the comment: LGTM ---------- assignee: -> ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 15:27:56 2013 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Tue, 28 May 2013 13:27:56 +0000 Subject: [issue17987] test.support.captured_stderr, captured_stdin not documented In-Reply-To: <1368653423.88.0.898801742943.issue17987@psf.upfronthosting.co.za> Message-ID: <1369747676.57.0.756090159809.issue17987@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: +1 for issue17987_4.patch Thanks, Dmi! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 15:28:14 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 May 2013 13:28:14 +0000 Subject: [issue18025] Buffer overflow in BufferedIOBase.readinto() In-Reply-To: <1369082078.59.0.190906066186.issue18025@psf.upfronthosting.co.za> Message-ID: <3bKbTn0WBczSNH@mail.python.org> Roundup Robot added the comment: New changeset b864f4056b78 by Serhiy Storchaka in branch '3.3': Issue #18025: Fixed a segfault in io.BufferedIOBase.readinto() when raw http://hg.python.org/cpython/rev/b864f4056b78 New changeset ad56dff3602f by Serhiy Storchaka in branch 'default': Issue #18025: Fixed a segfault in io.BufferedIOBase.readinto() when raw http://hg.python.org/cpython/rev/ad56dff3602f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 15:42:33 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 13:42:33 +0000 Subject: [issue17987] test.support.captured_stderr, captured_stdin not documented In-Reply-To: <1368653423.88.0.898801742943.issue17987@psf.upfronthosting.co.za> Message-ID: <1369748553.27.0.798893328597.issue17987@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > I'd rather see captured_stdin handled separately, perhaps with some > additional comments in the example, to emphasize the intended usage > pattern: However all three functions share a description. sys.stdin also has totally different usage pattern than sys.stdout/stderr, but it's documentation joined with documentation of all sys.std* streams. I think functions should be mentioned in order of it's fd numbers (0 - stdin, 1 - stdout, 2 - stderr). And example for capture_stdout() looks more appropriate then for capture_stderr(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 15:43:33 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 13:43:33 +0000 Subject: [issue18025] Buffer overflow in BufferedIOBase.readinto() In-Reply-To: <1369082078.59.0.190906066186.issue18025@psf.upfronthosting.co.za> Message-ID: <1369748613.74.0.87816192565.issue18025@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 15:45:20 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 13:45:20 +0000 Subject: [issue17872] Crash in marshal.load() with bad reader In-Reply-To: <1367270952.48.0.351702678796.issue17872@psf.upfronthosting.co.za> Message-ID: <1369748720.7.0.45793485459.issue17872@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could anyone review a patch please? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 15:47:55 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 13:47:55 +0000 Subject: [issue15239] Abandoned Tools/unicode/mkstringprep.py In-Reply-To: <1341164174.42.0.994750295138.issue15239@psf.upfronthosting.co.za> Message-ID: <1369748875.07.0.231519448475.issue15239@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Is there a chance, Martin? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 15:50:15 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 13:50:15 +0000 Subject: [issue16741] `int()`, `float()`, etc think python strings are null-terminated In-Reply-To: <1356046641.74.0.314140910069.issue16741@psf.upfronthosting.co.za> Message-ID: <1369749015.03.0.788369114472.issue16741@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Are there any other comments? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 16:35:25 2013 From: report at bugs.python.org (Zachary Ware) Date: Tue, 28 May 2013 14:35:25 +0000 Subject: [issue17846] Building Python on Windows - Supplementary info In-Reply-To: <1366919664.94.0.0931557904055.issue17846@psf.upfronthosting.co.za> Message-ID: <1369751725.64.0.195747344405.issue17846@psf.upfronthosting.co.za> Zachary Ware added the comment: Michael, you may be interested in a configure.bat/make.bat system which I have proposed in issue16895. I would certainly be interested in your review of it, as it seems that core developers who have the ability, inclination, and (probably most importantly) time to review such a patch are few and far between :). In the meantime, I agree that the documentation for building on Windows is a bit lacking. If you would like to make a patch to the devguide, I'd be happy to review it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 16:36:21 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 28 May 2013 14:36:21 +0000 Subject: [issue18078] threading.Condition to allow notify on a specific waiter In-Reply-To: <1369712419.12.0.434704480843.issue18078@psf.upfronthosting.co.za> Message-ID: <1369751781.1.0.159429045713.issue18078@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > BTW, I find .notify(N) not much useful, because the docs say it may wake > more threads on a different implementation and also I can't never know > whom am I waking. The fact that more than N threads can wake up is not a problem if you are retesting an appropriate predicate as soon as your waiting threads awakes. (And if you are not retesting then you are abusing the condition variable.) But it might be nice to be able to wait on multiple conditions at once, assuming they are associated with the same lock. Maybe we could have a static method Condition.wait_for_any(cond_to_pred: dict, timeout=None) -> condition where cond_to_pred is a mapping from condition variable to predicate function to test for. The return value would be the condition variable whose predicate is true (or None if there was a timeout). So then cond.wait_for(pred) would be equivalent to Condition.wait_for_any({cond: pred}) is cond ---------- nosy: +sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 16:37:29 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 28 May 2013 14:37:29 +0000 Subject: [issue18065] set __path__ = [] for frozen packages In-Reply-To: <1369524062.03.0.920595154239.issue18065@psf.upfronthosting.co.za> Message-ID: <1369751849.49.0.109969909292.issue18065@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 16:41:39 2013 From: report at bugs.python.org (Dmi Baranov) Date: Tue, 28 May 2013 14:41:39 +0000 Subject: [issue17987] test.support.captured_stderr, captured_stdin not documented In-Reply-To: <1368653423.88.0.898801742943.issue17987@psf.upfronthosting.co.za> Message-ID: <1369752099.52.0.399302125535.issue17987@psf.upfronthosting.co.za> Dmi Baranov added the comment: Thanks for review, Serhiy - updated. ---------- Added file: http://bugs.python.org/file30400/issue17987_5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 16:44:45 2013 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 28 May 2013 14:44:45 +0000 Subject: [issue16895] Batch file to mimic 'make' on Windows In-Reply-To: <1357677821.21.0.151237367429.issue16895@psf.upfronthosting.co.za> Message-ID: <1369752285.51.0.228049396989.issue16895@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 16:46:28 2013 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 28 May 2013 14:46:28 +0000 Subject: [issue17846] Building Python on Windows - Supplementary info In-Reply-To: <1366919664.94.0.0931557904055.issue17846@psf.upfronthosting.co.za> Message-ID: <1369752388.0.0.441897170941.issue17846@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 16:55:11 2013 From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=) Date: Tue, 28 May 2013 14:55:11 +0000 Subject: [issue18078] threading.Condition to allow notify on a specific waiter In-Reply-To: <1369712419.12.0.434704480843.issue18078@psf.upfronthosting.co.za> Message-ID: <1369752911.84.0.812263010217.issue18078@psf.upfronthosting.co.za> Jo?o Bernardo added the comment: > But it might be nice to be able to wait on multiple conditions at > once, assuming they are associated with the same lock. Maybe we could > have a static method This could solve the waiting problem for the "thread", but also may keep the other Condition objs waiting -- and that may not be problem because I'm already using .notify_all() Probably this function have more use cases than my original idea, but is it simple to wait on several locks? It could be in the form: Condition.wait_for_any(cond_to_pred: dict|list, timeout=None) -> condition For cases when there's no need for a predicate function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 17:03:49 2013 From: report at bugs.python.org (Zachary Ware) Date: Tue, 28 May 2013 15:03:49 +0000 Subject: [issue17691] Fix test discovery for test_univnewlines.py In-Reply-To: <1365621545.24.0.445008426691.issue17691@psf.upfronthosting.co.za> Message-ID: <1369753429.53.0.394322949677.issue17691@psf.upfronthosting.co.za> Zachary Ware added the comment: Looking at this again, the test_main magic wasn't too arcane, so here's a patch that does away with test_main (or load_tests) completely. ---------- Added file: http://bugs.python.org/file30401/test_univnewlines_discovery.v2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 17:20:38 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 28 May 2013 15:20:38 +0000 Subject: [issue8508] 2to3 fixer for gettext's .ugettext In-Reply-To: <1369571844.13.0.270084202484.issue8508@psf.upfronthosting.co.za> Message-ID: <20130528112035.559437b3@anarchist> Barry A. Warsaw added the comment: On May 26, 2013, at 12:37 PM, Mark Lawrence wrote: >Barry, would you like to follow up on this? My personal interest in this has waned, since I try to avoid 2to3 like the plague. ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 17:22:33 2013 From: report at bugs.python.org (Jeffrey C. Jacobs) Date: Tue, 28 May 2013 15:22:33 +0000 Subject: [issue1693050] \w not helpful for non-Roman scripts Message-ID: <1369754553.93.0.0867109625498.issue1693050@psf.upfronthosting.co.za> Jeffrey C. Jacobs added the comment: Matthew, I think that is considered a single word in Sanscrit or Thai so Python 3.x is correct. In this case you've written the Sanscrit word for Hindi. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 17:25:27 2013 From: report at bugs.python.org (R. David Murray) Date: Tue, 28 May 2013 15:25:27 +0000 Subject: [issue18081] test_logging failure in WarningsTest on buildbots Message-ID: <1369754727.16.0.996234462502.issue18081@psf.upfronthosting.co.za> New submission from R. David Murray: The following failure is showing up frequently in the buildbots. I haven't checked closely enough to be sure if it is a heisenberg, but I suspect it is, since it doesn't seem to be related to any of the recent changesets that would have been included in the builds that just failed and that show the failure: ====================================================================== FAIL: test_warnings (test.test_logging.WarningsTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/db3l/buildarea/3.3.bolen-freebsd/build/Lib/test/test_logging.py", line 1796, in test_warnings "dummy.py:42: UserWarning: Explicit\n Dummy line\n") AssertionError: '\nWarning (from warnings module):\n File "dummy.py", line 42\n Dummy line\n [truncated]... != 'dummy.py:42: UserWarning: Explicit\n Dummy line\n' + dummy.py:42: UserWarning: Explicit - - Warning (from warnings module): - File "dummy.py", line 42 - Dummy line ? -- + Dummy line - UserWarning: Explicit - >>> ---------- components: Tests keywords: buildbot messages: 190220 nosy: r.david.murray, vinay.sajip priority: normal severity: normal stage: needs patch status: open title: test_logging failure in WarningsTest on buildbots type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 17:37:15 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 28 May 2013 15:37:15 +0000 Subject: [issue18078] threading.Condition to allow notify on a specific waiter In-Reply-To: <1369712419.12.0.434704480843.issue18078@psf.upfronthosting.co.za> Message-ID: <1369755435.15.0.689376545162.issue18078@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > This could solve the waiting problem for the "thread", but also may > keep the other Condition objs waiting -- and that may not be problem > because I'm already using .notify_all() I don't understand what you mean. > Probably this function have more use cases than my original idea, but > is it simple to wait on several locks? It would be for waiting for several conditions associated with the same lock, not for waiting for several locks. > It could be in the form: > > Condition.wait_for_any(cond_to_pred: dict|list, timeout=None) -> condition > > For cases when there's no need for a predicate function. There is always a need for a predicate function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 17:43:58 2013 From: report at bugs.python.org (Leo Arias) Date: Tue, 28 May 2013 15:43:58 +0000 Subject: [issue16662] load_tests not invoked in package/__init__.py In-Reply-To: <1355217291.85.0.41912767842.issue16662@psf.upfronthosting.co.za> Message-ID: <1369755838.89.0.269042171886.issue16662@psf.upfronthosting.co.za> Changes by Leo Arias : ---------- nosy: +elopio _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 17:52:11 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 15:52:11 +0000 Subject: [issue13355] random.triangular error when low = high=mode In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za> Message-ID: <1369756331.97.0.635379673038.issue13355@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: committed/rejected -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 17:52:38 2013 From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=) Date: Tue, 28 May 2013 15:52:38 +0000 Subject: [issue18078] threading.Condition to allow notify on a specific waiter In-Reply-To: <1369712419.12.0.434704480843.issue18078@psf.upfronthosting.co.za> Message-ID: <1369756358.98.0.893176591834.issue18078@psf.upfronthosting.co.za> Jo?o Bernardo added the comment: > It would be for waiting for several conditions associated with the > same lock, not for waiting for several locks. A Condition uses a 2 lock mechanism: - outer lock: one for all the waiters to access the Condition object - inner lock: one for each waiter to wait on. You cannot associate several conditions to the *inner lock*, because you don't have access to them (otherwise I wouldn't open this issue). You said you want to have several conditions on the lock passed by the user: lock = Lock() cond1 = Condition(lock) cond2 = Condition(lock) Condition.wait_for_any({cond1: foo, cond2: bar}) but because this "lock" object is not the one the thread is waiting on, it won't work. > There is always a need for a predicate function. You may not need to test for a predicate when using .wait() . Only when you're using .wait_for() This is what I'm most interested in mimicking. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 17:59:44 2013 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 28 May 2013 15:59:44 +0000 Subject: [issue13355] random.triangular error when low = high=mode In-Reply-To: <1320577016.77.0.989776485745.issue13355@psf.upfronthosting.co.za> Message-ID: <1369756784.93.0.801878617874.issue13355@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: -mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 18:16:30 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Tue, 28 May 2013 16:16:30 +0000 Subject: [issue15239] Abandoned Tools/unicode/mkstringprep.py In-Reply-To: <1341164174.42.0.994750295138.issue15239@psf.upfronthosting.co.za> Message-ID: <1369757790.13.0.375209659508.issue15239@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I find the patch too large to review, and it appears to contain unrelated changes. Can you kindly split it up into two patches, namely A) changes that are really absolutely necessary to make it work again B) patches that are purely cosmetic, and do not affect the behavior at all (such as rewriting .startswith, or replacing %s with %r) Possibly, there is also C) changes that do change the behavior, but in a way unrelated to the issue at hand; such changes are best left out. Sorry it took so long to react. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 18:31:28 2013 From: report at bugs.python.org (Dwight Guth) Date: Tue, 28 May 2013 16:31:28 +0000 Subject: [issue18082] Inconsistent behavior of IOBase methods on closed files Message-ID: <1369758688.03.0.231740499906.issue18082@psf.upfronthosting.co.za> New submission from Dwight Guth: Consider the following program: import io class A(io.IOBase): def __init__(self): self.x = 5 def read(self, limit=-1): self.x -= 1 if self.x > 0: return b"5" return b"" def seek(self, offset, whence=0): return 0 def write(self, b): pass a = A() a.close() assert a.__next__() == b"5555" assert a.readline() == b"" assert a.tell() == 0 These three operations succeed, even though the file is closed. However, these two operations fail: a.readlines() a.writelines([]) Why do some of the mixin methods on IOBase call _checkClosed and others don't? ---------- components: IO messages: 190224 nosy: dwight.guth priority: normal severity: normal status: open title: Inconsistent behavior of IOBase methods on closed files type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 18:34:53 2013 From: report at bugs.python.org (=?utf-8?q?Maciej_Blizi=C5=84ski?=) Date: Tue, 28 May 2013 16:34:53 +0000 Subject: [issue18083] _sysconfigdata.py is installed in an arch-independent directory Message-ID: <1369758893.79.0.620751759494.issue18083@psf.upfronthosting.co.za> New submission from Maciej Blizi?ski: _sysconfigdata.py is installed into ${prefix}/lib/pythonX.Y/_sysconfigdata.py which is an architecture-independent directory, as opposed to a path starting with e.g. ${libdir}, which is architecture-dependent. But _sysconfigdata.py contains architecture-dependent information, which breaks some installation, specifically Solaris multi-arch. A fix would be to move it to an architecture-dependent directory, but this probably requires some discussion. ----------------------------------------------------------------------- Original question on the mailing list: http://mail.python.org/pipermail/python-list/2013-May/647197.html I'm looking into creating a 32/64-bit Python (2.x and/or 3.x) package for Solaris. The specificity of that package is that I need to include both 32-bit and 64-bit binaries in it. The exact way in which the 32/64 support is done is described at [1]. There currently is a Python package that I maintain, which is 32-bit only[2]. I have made an attempt to build a 64-bit package, and my findings are that the ${prefix}/lib/pythonX.Y/_sysconfigdata.py file contains system-specific information. Note that it's not ${libdir}/pythonX.Y - that would have worked, because I'm specifying different ${libdir} directories when running the 32-bit and 64-bit builds. The Python installer specifically uses ${prefix}/lib/pythonX.Y. For the most part is fine, because most of files in there are not architecture-specific, and it would be quite good to share them among the 32-bit and 64-bit binaries at runtime. The problem is that some files differ. I've described it some more at [3]. Ideally, I'd make _sysconfigdata.py return/set different values depending on the Python runtime that reads it. Something like: if we're 64-bit: set values for the 64-bit platform else: set values for the 32-bit platform It's a similar approach to how we currently handle C header files. See the 'Development packages' section in [1] for more information. The problem is that it would involve somewhat intrusive patching of the Python source code, and in long term that means maintainability issues. ---------- components: Installation messages: 190225 nosy: automatthias priority: normal severity: normal status: open title: _sysconfigdata.py is installed in an arch-independent directory versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 18:51:51 2013 From: report at bugs.python.org (Matthew Barnett) Date: Tue, 28 May 2013 16:51:51 +0000 Subject: [issue1693050] \w not helpful for non-Roman scripts Message-ID: <1369759911.45.0.725849062938.issue1693050@psf.upfronthosting.co.za> Matthew Barnett added the comment: I'm not sure what you're saying. The re module in Python 3.3 matches only the first codepoint, treating the second codepoint as not part of a word, whereas the regex module matches all 6 codepoints, treating them all as part of a single word. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 19:08:47 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 17:08:47 +0000 Subject: [issue18082] Inconsistent behavior of IOBase methods on closed files In-Reply-To: <1369758688.03.0.231740499906.issue18082@psf.upfronthosting.co.za> Message-ID: <1369760927.57.0.756391362267.issue18082@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +benjamin.peterson, hynek, pitrou, stutzbach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 19:15:20 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 28 May 2013 17:15:20 +0000 Subject: [issue18078] threading.Condition to allow notify on a specific waiter In-Reply-To: <1369712419.12.0.434704480843.issue18078@psf.upfronthosting.co.za> Message-ID: <1369761320.86.0.487688212845.issue18078@psf.upfronthosting.co.za> Richard Oudkerk added the comment: > You cannot associate several conditions to the *inner lock*, because you > don't have access to them (otherwise I wouldn't open this issue). Condition.wait_for_any() would create a single inner lock and add it to the _waiters list for each of the condition variables. notify() and notify_all() would need to deal with the possibility that releasing the inner lock fails with ThreadError because it has already been unlocked. > You may not need to test for a predicate when using .wait() . Only when you're > using .wait_for() > This is what I'm most interested in mimicking. (Ignoring timeouts) wait() should be used with the idiom while : cond.wait() This allows the woken thread to check whether it is really supposed to continue -- it sounds like you are not doing this. The only advantage of using wait() over wait_for() is that sometimes it avoids you having to create a named function or lambda function like in cond.wait_for(lambda: not ()) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 19:32:37 2013 From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=) Date: Tue, 28 May 2013 17:32:37 +0000 Subject: [issue18078] threading.Condition to allow notify on a specific waiter In-Reply-To: <1369712419.12.0.434704480843.issue18078@psf.upfronthosting.co.za> Message-ID: <1369762357.95.0.0605126765607.issue18078@psf.upfronthosting.co.za> Jo?o Bernardo added the comment: > Condition.wait_for_any() would create a single inner lock and add it > to the _waiters list for each of the condition variables Now I see your point! Could it also have one (optional) argument so I can provide this lock myself? > while : > cond.wait() > This allows the woken thread to check whether it is really supposed > to continue -- Yes, I use that, but sometimes I have the thread just waiting for cleanup time and there's no need to check a condition. This is one my use cases though... You may want it to be more generic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 19:42:00 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 17:42:00 +0000 Subject: [issue15239] Abandoned Tools/unicode/mkstringprep.py In-Reply-To: <1341164174.42.0.994750295138.issue15239@psf.upfronthosting.co.za> Message-ID: <1369762920.94.0.700778795638.issue15239@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a minimal patch. ---------- Added file: http://bugs.python.org/file30402/mkstringprep_min.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 19:51:24 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 17:51:24 +0000 Subject: [issue15239] Abandoned Tools/unicode/mkstringprep.py In-Reply-To: <1341164174.42.0.994750295138.issue15239@psf.upfronthosting.co.za> Message-ID: <1369763484.46.0.60702153525.issue15239@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a pure cosmetic patch. ---------- Added file: http://bugs.python.org/file30403/mkstringprep_cosmetic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 19:54:09 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 17:54:09 +0000 Subject: [issue15239] Abandoned Tools/unicode/mkstringprep.py In-Reply-To: <1341164174.42.0.994750295138.issue15239@psf.upfronthosting.co.za> Message-ID: <1369763649.31.0.0994254359498.issue15239@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And here is a patch which changes behavior. It adds check for validating end of table detection. ---------- Added file: http://bugs.python.org/file30404/mkstringprep_check.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 20:00:10 2013 From: report at bugs.python.org (Andrew Stormont) Date: Tue, 28 May 2013 18:00:10 +0000 Subject: [issue17925] asynchat.async_chat.initiate_send : del deque[0] is not safe In-Reply-To: <1367934356.3.0.498041746077.issue17925@psf.upfronthosting.co.za> Message-ID: <1369764010.97.0.321803980953.issue17925@psf.upfronthosting.co.za> Andrew Stormont added the comment: Looks like a reasonable fix to me. What needs to be done to get this integrated? ---------- nosy: +andy_js _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 20:15:56 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Tue, 28 May 2013 18:15:56 +0000 Subject: [issue17925] asynchat.async_chat.initiate_send : del deque[0] is not safe In-Reply-To: <1367934356.3.0.498041746077.issue17925@psf.upfronthosting.co.za> Message-ID: <1369764956.04.0.770665077099.issue17925@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: After applying the patch I get these 2 failures on Linux: ====================================================================== FAIL: test_simple_producer (__main__.TestAsynchat) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_asynchat.py", line 198, in test_simple_producer self.fail("join() timed out") AssertionError: join() timed out ====================================================================== FAIL: test_simple_producer (__main__.TestAsynchat_WithPoll) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_asynchat.py", line 198, in test_simple_producer self.fail("join() timed out") AssertionError: join() timed out ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 20:28:56 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Tue, 28 May 2013 18:28:56 +0000 Subject: [issue14616] subprocess docs should mention pipes.quote/shlex.quote In-Reply-To: <1334769157.78.0.557014485739.issue14616@psf.upfronthosting.co.za> Message-ID: <1369765736.75.0.716695581937.issue14616@psf.upfronthosting.co.za> ?ric Araujo added the comment: > .. deprecated:: 1.6 This looks weird to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 20:41:01 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 18:41:01 +0000 Subject: [issue11468] Improve unittest basic example in the doc In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za> Message-ID: <1369766461.57.0.0919514862242.issue11468@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: -serhiy.storchaka stage: commit review -> patch review versions: +Python 3.4 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 21:16:19 2013 From: report at bugs.python.org (Hideaki Takahashi) Date: Tue, 28 May 2013 19:16:19 +0000 Subject: [issue18084] wave.py should use sys.byteorder to determine endianess Message-ID: <1369768579.1.0.487057247518.issue18084@psf.upfronthosting.co.za> New submission from Hideaki Takahashi: wave.py uses struct based endianness detecting code. However there is sys.byteorder in Python since Python 2.0. I think wave.py should use sys.byteorder to determine endianness. ---------- components: Library (Lib) messages: 190235 nosy: hideaki_t priority: normal severity: normal status: open title: wave.py should use sys.byteorder to determine endianess _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 21:17:19 2013 From: report at bugs.python.org (Hideaki Takahashi) Date: Tue, 28 May 2013 19:17:19 +0000 Subject: [issue18084] wave.py should use sys.byteorder to determine endianess In-Reply-To: <1369768579.1.0.487057247518.issue18084@psf.upfronthosting.co.za> Message-ID: <1369768639.53.0.981967566127.issue18084@psf.upfronthosting.co.za> Changes by Hideaki Takahashi : Added file: http://bugs.python.org/file30405/diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 21:22:38 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 19:22:38 +0000 Subject: [issue18085] Verifying refcounts.dat Message-ID: <1369768958.38.0.697954786488.issue18085@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: I found one error in Doc/data/refcounts.dat (see issue9369, second argument of PyObject_CallMethodObjArgs is `PyObject*`, not `char*`). Perhaps there are other errors. How this file was generated first? Is it possible to write a tool which will automatically verify at least signatures of functions? ---------- assignee: docs at python components: Documentation messages: 190236 nosy: docs at python, serhiy.storchaka, skip.montanaro priority: normal severity: normal status: open title: Verifying refcounts.dat type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 21:41:08 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 28 May 2013 19:41:08 +0000 Subject: [issue18084] wave.py should use sys.byteorder to determine endianess In-Reply-To: <1369768579.1.0.487057247518.issue18084@psf.upfronthosting.co.za> Message-ID: <1369770068.77.0.856434503979.issue18084@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 21:46:46 2013 From: report at bugs.python.org (Arnaud Porterie) Date: Tue, 28 May 2013 19:46:46 +0000 Subject: [issue18047] Descriptors get invoked in old-style objects and classes In-Reply-To: <1369373983.58.0.00587959802813.issue18047@psf.upfronthosting.co.za> Message-ID: <1369770406.8.0.771219782221.issue18047@psf.upfronthosting.co.za> Arnaud Porterie added the comment: Sorry if I am missing something, but it seems that the documentation doesn't match the behavior: the doc says that descriptors are invoked only for new styles objects and classes, while the attached code seems to prove the contrary. If my understanding is correct, either the doc or the code should be changed accordingly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 21:48:07 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 May 2013 19:48:07 +0000 Subject: [issue18085] Verifying refcounts.dat In-Reply-To: <1369768958.38.0.697954786488.issue18085@psf.upfronthosting.co.za> Message-ID: <3bKlw663JDz7Lq8@mail.python.org> Roundup Robot added the comment: New changeset 0889ab0d0da1 by Serhiy Storchaka in branch '3.3': Issue #18085: Fix PyObject_CallMethodObjArgs()'s entry in refcounts.dat. http://hg.python.org/cpython/rev/0889ab0d0da1 New changeset ef9d42b98a3d by Serhiy Storchaka in branch '2.7': Issue #18085: Fix PyObject_CallMethodObjArgs()'s entry in refcounts.dat. http://hg.python.org/cpython/rev/ef9d42b98a3d New changeset 6d0fd113a2e4 by Serhiy Storchaka in branch 'default': Issue #18085: Fix PyObject_CallMethodObjArgs()'s entry in refcounts.dat. http://hg.python.org/cpython/rev/6d0fd113a2e4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 21:50:25 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 19:50:25 +0000 Subject: [issue1772673] Replacing char* with const char* Message-ID: <1369770625.42.0.854966107655.issue1772673@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue9369. ---------- dependencies: +const char* for PyObject_CallMethod and PyObject_CallFunction _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 21:55:16 2013 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Tue, 28 May 2013 19:55:16 +0000 Subject: [issue18085] Verifying refcounts.dat In-Reply-To: <1369768958.38.0.697954786488.issue18085@psf.upfronthosting.co.za> Message-ID: <1369770916.49.0.0424203137522.issue18085@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: I'm a little surprised that still exists. The first version was generated manually. ---------- nosy: +fdrake _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 22:06:19 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 28 May 2013 20:06:19 +0000 Subject: [issue16895] Batch file to mimic 'make' on Windows In-Reply-To: <1357677821.21.0.151237367429.issue16895@psf.upfronthosting.co.za> Message-ID: <1369771579.58.0.801179770243.issue16895@psf.upfronthosting.co.za> Richard Oudkerk added the comment: I can't say I know enough about batch files to understand much of the code, but a few notes: Windows XP does not have the command "where" which you use -- Python 3.4 will still support XP. Except perhaps for looping I would prefer to get rid of the use of goto. The fact that some goto targets end in "exit /b ..." make it very confusing as to where "exit /b" will return control. The initial pushd is matched by various popd's which are scattered over hundreds of lines (including one in :usage). I think it would be better to keep matching pushd/popd reasonably close together. For instance, I think you could do something like ... pushd "%~dp0" call :main ... popd exit /b :main ... exit /b It would also be helpful if the end of the subroutines were marked with a comment like rem end :foo ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 22:09:45 2013 From: report at bugs.python.org (Brian Curtin) Date: Tue, 28 May 2013 20:09:45 +0000 Subject: [issue16895] Batch file to mimic 'make' on Windows In-Reply-To: <1357677821.21.0.151237367429.issue16895@psf.upfronthosting.co.za> Message-ID: <1369771785.47.0.0599658321868.issue16895@psf.upfronthosting.co.za> Brian Curtin added the comment: Can't this just be a Python script? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 22:10:47 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 May 2013 20:10:47 +0000 Subject: [issue18084] wave.py should use sys.byteorder to determine endianess In-Reply-To: <1369768579.1.0.487057247518.issue18084@psf.upfronthosting.co.za> Message-ID: <1369771847.83.0.770572864076.issue18084@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I have added some comments on Rietveld. ---------- assignee: -> serhiy.storchaka stage: -> patch review type: -> enhancement versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 22:20:57 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Tue, 28 May 2013 20:20:57 +0000 Subject: [issue16895] Batch file to mimic 'make' on Windows In-Reply-To: <1369771785.47.0.0599658321868.issue16895@psf.upfronthosting.co.za> Message-ID: <51A511A3.9060404@gmail.com> Richard Oudkerk added the comment: > Can't this just be a Python script? That would cause bootstrap issues for people who do not already have python installed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 22:23:07 2013 From: report at bugs.python.org (Brett Cannon) Date: Tue, 28 May 2013 20:23:07 +0000 Subject: [issue18085] Verifying refcounts.dat In-Reply-To: <1369768958.38.0.697954786488.issue18085@psf.upfronthosting.co.za> Message-ID: <1369772587.88.0.986847562975.issue18085@psf.upfronthosting.co.za> Brett Cannon added the comment: Wow, I didn't even know that file existed. It could actually help with some static analysis of the C code to verify that the refcounts are as expected w/o actually having to do inter-procedural analysis to figure out all of the refcount values. I wonder if Dave's gcc work could help either verify the file or benefit from it? ---------- nosy: +brett.cannon, dmalcolm _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 22:26:36 2013 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 28 May 2013 20:26:36 +0000 Subject: [issue18085] Verifying refcounts.dat In-Reply-To: <1369768958.38.0.697954786488.issue18085@psf.upfronthosting.co.za> Message-ID: <1369772796.31.0.527755341755.issue18085@psf.upfronthosting.co.za> Skip Montanaro added the comment: As far as I can tell that file is still manually maintained. I see it mentioned in Doc/conf.py, but nowhere else. It shouldn't be hard to deal with manually, as the C API doesn't change that often. A verifier shouldn't be terribly difficult to write, as Python C source is pretty consistently structured. I'm not volunteering for the task though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 22:26:42 2013 From: report at bugs.python.org (Zachary Ware) Date: Tue, 28 May 2013 20:26:42 +0000 Subject: [issue16895] Batch file to mimic 'make' on Windows In-Reply-To: <1369771579.58.0.801179770243.issue16895@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: > Richard Oudkerk added the comment: > > I can't say I know enough about batch files to understand much of the code, but a few notes: > > Windows XP does not have the command "where" which you use -- Python 3.4 will still support XP. Oh, that is an issue. I don't have an XP machine to test on anymore, thank you for that catch. I found a workaround on StackOverflow that looks short enough to be usable instead. > Except perhaps for looping I would prefer to get rid of the use of goto. The fact that some goto targets end in "exit /b ..." make it very confusing as to where "exit /b" will return control. The only goto's that are not part of loops are now one near the beginning for the -C option, in the target validation routine to show the usage message and die, and in a couple of routines which use "goto no-configure" to show a common message and die. I'd rather not have to copy that message every place it is used, but that is an option. Would just adding comments explaining where execution is going and whether it is coming back be sufficient? > > The initial pushd is matched by various popd's which are scattered over hundreds of lines (including one in :usage). I think it would be better to keep matching pushd/popd reasonably close together. For instance, I think you could do something like > > ... > pushd "%~dp0" > call :main ... > popd > exit /b > > :main > ... > exit /b > Fair enough, I can change that. I tried to keep the matches to the initial pushd to a minimum, but perhaps there are a couple more I can eliminate. > It would also be helpful if the end of the subroutines were marked with a comment like > > rem end :foo > Easy enough, consider it done :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 22:27:27 2013 From: report at bugs.python.org (Brian Curtin) Date: Tue, 28 May 2013 20:27:27 +0000 Subject: [issue16895] Batch file to mimic 'make' on Windows In-Reply-To: <1357677821.21.0.151237367429.issue16895@psf.upfronthosting.co.za> Message-ID: <1369772847.93.0.762566773771.issue16895@psf.upfronthosting.co.za> Brian Curtin added the comment: Don't we already require an existing Python to build some of the third-party stuff, e.g., OpenSSL? I don't think the bootstrapping issue holds that much weight. Adding some huge batch script that maybe one or two people even know how to modify is a much higher cost than just having someone install Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 22:35:18 2013 From: report at bugs.python.org (Zachary Ware) Date: Tue, 28 May 2013 20:35:18 +0000 Subject: [issue16895] Batch file to mimic 'make' on Windows In-Reply-To: <1369772847.93.0.762566773771.issue16895@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: > Brian Curtin added the comment: > > Don't we already require an existing Python to build some of the third-party stuff, e.g., OpenSSL? Only for building a 64-bit Python on 32-bit Windows. Otherwise, OpenSSL is built using the just-built interpreter. > I don't think the bootstrapping issue holds that much weight. Adding some huge batch script that maybe one or two people even know how to modify is a much higher cost than just having someone install Python. Fair enough, but even when Python is installed, there's still the issue of whether it will be findable on PATH, whether .py is in PATHEXT, what version of Python is installed (and which one is on PATH), etc. etc... However, you've made me think; perhaps configure.bat could build a minimal Python that can then be used for a make.py. I'll do some experimenting and see what I can come up with. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 22:52:15 2013 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Tue, 28 May 2013 20:52:15 +0000 Subject: [issue18085] Verifying refcounts.dat In-Reply-To: <1369772796.31.0.527755341755.issue18085@psf.upfronthosting.co.za> Message-ID: Fred L. Drake, Jr. added the comment: Were I adding that today, I'd use a more verbose (but more standard) format, like configparser or JSON. If any further use is going to be made of it, that should be considered. Colon-delimited is a pretty fragile format. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 22:55:55 2013 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 28 May 2013 20:55:55 +0000 Subject: [issue18085] Verifying refcounts.dat In-Reply-To: Message-ID: Skip Montanaro added the comment: > Fred L. Drake, Jr. added the comment: > > Were I adding that today, I'd use a more verbose (but more standard) > format, like configparser or JSON. If any further use is going to be > made of it, that should be considered. Colon-delimited is a pretty > fragile format. Given the context, it should be okay until Python is rewritten in C++. :-) I don't know where this is consumed. Presumably by Sphinx somewhere. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 23:10:19 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 28 May 2013 21:10:19 +0000 Subject: [issue18083] _sysconfigdata.py is installed in an arch-independent directory In-Reply-To: <1369758893.79.0.620751759494.issue18083@psf.upfronthosting.co.za> Message-ID: <1369775419.92.0.175344054353.issue18083@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +dmalcolm, doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 23:37:40 2013 From: report at bugs.python.org (Hideaki Takahashi) Date: Tue, 28 May 2013 21:37:40 +0000 Subject: [issue18084] wave.py should use sys.byteorder to determine endianess In-Reply-To: <1369768579.1.0.487057247518.issue18084@psf.upfronthosting.co.za> Message-ID: <1369777060.35.0.479046949438.issue18084@psf.upfronthosting.co.za> Changes by Hideaki Takahashi : ---------- keywords: +patch Added file: http://bugs.python.org/file30406/18084.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue May 28 23:44:48 2013 From: report at bugs.python.org (Ned Deily) Date: Tue, 28 May 2013 21:44:48 +0000 Subject: [issue18050] embedded interpreter or virtualenv fails with "ImportError: cannot import name MAXREPEAT" In-Reply-To: <1369417243.06.0.993082490408.issue18050@psf.upfronthosting.co.za> Message-ID: <1369777488.23.0.0591679326375.issue18050@psf.upfronthosting.co.za> Ned Deily added the comment: Serhly, while I don't disagree with your points, I should have made clearer that the issue here is that the _sre module is a static module (built into the interpreter executable or shared lib as shown in Modules/Setup.dist) and *not* included in the shared library (sys.prefix/lib/pythonX.Y/) whereas are_constants *is*. If the binaries produced by both the python and C files changes end up in sys.prefix/lib/pythonX.Y, there is not a problem. That's normally the case and I believe that is the case with both of the other examples you cited. So they are not going to exhibit this problem. The problem is when a change introduces a dependency between static and shared modules, like this one does. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 00:07:10 2013 From: report at bugs.python.org (Brett Cannon) Date: Tue, 28 May 2013 22:07:10 +0000 Subject: [issue15767] add ImportNotFoundError In-Reply-To: <1345664718.23.0.712313947558.issue15767@psf.upfronthosting.co.za> Message-ID: <1369778830.94.0.935540411637.issue15767@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 00:36:05 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 May 2013 22:36:05 +0000 Subject: [issue18070] change importlib.util.module_for_loader to unconditionally set attributes In-Reply-To: <1369663183.34.0.953229733937.issue18070@psf.upfronthosting.co.za> Message-ID: <3bKqdw2zqjz7Ljf@mail.python.org> Roundup Robot added the comment: New changeset 185a0e649fb8 by Brett Cannon in branch 'default': Issue #18070: importlib.util.module_for_loader() now sets __loader__ http://hg.python.org/cpython/rev/185a0e649fb8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 00:43:11 2013 From: report at bugs.python.org (Brett Cannon) Date: Tue, 28 May 2013 22:43:11 +0000 Subject: [issue18070] change importlib.util.module_for_loader to unconditionally set attributes In-Reply-To: <1369663183.34.0.953229733937.issue18070@psf.upfronthosting.co.za> Message-ID: <1369780991.41.0.998415236799.issue18070@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> fixed stage: test needed -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 00:46:43 2013 From: report at bugs.python.org (Brett Cannon) Date: Tue, 28 May 2013 22:46:43 +0000 Subject: [issue18086] Create importlib.util.set_attrs_post_import() Message-ID: <1369781203.49.0.533816460652.issue18086@psf.upfronthosting.co.za> New submission from Brett Cannon: There is no good reason to have set_loader and set_package separately. There should just be a single decorator which sets both of those attributes post-import (with the proper doc note saying use module_for_loader instead when possible to have the attributes set during execution). ---------- assignee: brett.cannon components: Library (Lib) messages: 190254 nosy: brett.cannon priority: normal severity: normal stage: test needed status: open title: Create importlib.util.set_attrs_post_import() type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 00:49:21 2013 From: report at bugs.python.org (=?utf-8?q?Dra=C5=BEen_Lu=C4=8Danin?=) Date: Tue, 28 May 2013 22:49:21 +0000 Subject: [issue18087] os.listdir don't show hidden option Message-ID: <1369781361.8.0.806080395259.issue18087@psf.upfronthosting.co.za> New submission from Dra?en Lu?anin: I would like to be able to list a directory, but without showing hidden files. Currently, as discussed in a SO question [1], one has to either code this manually or resort to other libraries (glob). This functionality should be available in the os module. [1]: http://stackoverflow.com/questions/7099290/how-to-ignore-hidden-files-using-os-listdir-python ---------- components: Extension Modules messages: 190255 nosy: kermit666 priority: normal severity: normal status: open title: os.listdir don't show hidden option type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 01:02:28 2013 From: report at bugs.python.org (Matthias Klose) Date: Tue, 28 May 2013 23:02:28 +0000 Subject: [issue18083] _sysconfigdata.py is installed in an arch-independent directory In-Reply-To: <1369758893.79.0.620751759494.issue18083@psf.upfronthosting.co.za> Message-ID: <1369782148.69.0.30023708224.issue18083@psf.upfronthosting.co.za> Matthias Klose added the comment: Did Solaris adopt MultiArch? ;-P Nice! So what I did for the Debian and Ubuntu builds is: - to rename plat-linux to plat- (or plat-) - and install it there. Note that IN.py is another architecture dependent file which differs at least on several linux architectures. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 01:20:32 2013 From: report at bugs.python.org (Dmi Baranov) Date: Tue, 28 May 2013 23:20:32 +0000 Subject: [issue18087] os.listdir don't show hidden option In-Reply-To: <1369781361.8.0.806080395259.issue18087@psf.upfronthosting.co.za> Message-ID: <1369783232.2.0.0953400709565.issue18087@psf.upfronthosting.co.za> Dmi Baranov added the comment: So, I'm having a .gitignore file on Windows. Its hidden or not? In other words, only your code feel the difference in "hidden files policy". BTW, Mas OSX using two ways - dotfiles and "invisible" flags in Finder: $ chflags hidden i-am-hidden-now.txt (but 'ls' showing it) ---------- nosy: +dmi.baranov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 01:45:40 2013 From: report at bugs.python.org (Roundup Robot) Date: Tue, 28 May 2013 23:45:40 +0000 Subject: [issue18080] setting CC no longer overrides default linker for extension module builds on OS X In-Reply-To: <1369733275.86.0.789396593602.issue18080@psf.upfronthosting.co.za> Message-ID: <3bKsBC4ldxz7Ljf@mail.python.org> Roundup Robot added the comment: New changeset ca24bc6a5a4b by Ned Deily in branch '2.7': Issue #18080: When building a C extension module on OS X, if the compiler http://hg.python.org/cpython/rev/ca24bc6a5a4b New changeset 75432fb6b9af by Ned Deily in branch '3.3': Issue #18080: When building a C extension module on OS X, if the compiler http://hg.python.org/cpython/rev/75432fb6b9af New changeset 0512bb1b5b8a by Ned Deily in branch 'default': Issue #18080: merge from 3.3 http://hg.python.org/cpython/rev/0512bb1b5b8a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 01:48:57 2013 From: report at bugs.python.org (Ned Deily) Date: Tue, 28 May 2013 23:48:57 +0000 Subject: [issue18080] setting CC no longer overrides default linker for extension module builds on OS X In-Reply-To: <1369733275.86.0.789396593602.issue18080@psf.upfronthosting.co.za> Message-ID: <1369784937.55.0.240581012376.issue18080@psf.upfronthosting.co.za> Ned Deily added the comment: Committed for release with 2.7.6 and 3.3.3. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 02:08:16 2013 From: report at bugs.python.org (Brett Cannon) Date: Wed, 29 May 2013 00:08:16 +0000 Subject: [issue18088] Create importlib.abc.Loader.init_module_attrs() Message-ID: <1369786095.97.0.622799229859.issue18088@psf.upfronthosting.co.za> New submission from Brett Cannon: There are a bunch of attributes that need to be set on a module, and yet they are only handled by various decorators in importlib.util. The problem with that is there is no way in the API to override or expand upon setting those attributes pre-loading; only post-loading like what set_loader and set_package do. importlib.abc.Loader.init_module_attrs(module) would take a module and then using whatever methods are available, sets as many attributes as possible. This method can either be called before execution of the module's code or after some function is called that directly returns a loaded module (e.g. BuiltinImporter). ---------- assignee: brett.cannon components: Library (Lib) messages: 190260 nosy: brett.cannon priority: normal severity: normal stage: test needed status: open title: Create importlib.abc.Loader.init_module_attrs() type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 02:08:36 2013 From: report at bugs.python.org (Brett Cannon) Date: Wed, 29 May 2013 00:08:36 +0000 Subject: [issue18086] Create importlib.util.set_attrs_post_import() In-Reply-To: <1369781203.49.0.533816460652.issue18086@psf.upfronthosting.co.za> Message-ID: <1369786116.87.0.722774629467.issue18086@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- resolution: -> rejected status: open -> closed superseder: -> Create importlib.abc.Loader.init_module_attrs() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 02:09:44 2013 From: report at bugs.python.org (Brett Cannon) Date: Wed, 29 May 2013 00:09:44 +0000 Subject: [issue18089] Create importlib.abc.InspectLoader.load_module() Message-ID: <1369786184.33.0.5189689694.issue18089@psf.upfronthosting.co.za> New submission from Brett Cannon: ---------- assignee: brett.cannon components: Library (Lib) messages: 190261 nosy: brett.cannon priority: normal severity: normal stage: test needed status: open title: Create importlib.abc.InspectLoader.load_module() type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 02:09:48 2013 From: report at bugs.python.org (Brett Cannon) Date: Wed, 29 May 2013 00:09:48 +0000 Subject: [issue18089] Create importlib.abc.InspectLoader.load_module() In-Reply-To: <1369786184.33.0.5189689694.issue18089@psf.upfronthosting.co.za> Message-ID: <1369786188.97.0.216268545825.issue18089@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- dependencies: +Create importlib.abc.Loader.init_module_attrs() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 03:48:44 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 29 May 2013 01:48:44 +0000 Subject: [issue1554133] PyOS_InputHook() and related API funcs. not documented Message-ID: <3bKvwC132Xz7LkV@mail.python.org> Roundup Robot added the comment: New changeset 672614d809a1 by Andrew Kuchling in branch 'default': #1554133: Document PyOS_InputHook, PyOS_ReadlineFunctionPointer http://hg.python.org/cpython/rev/672614d809a1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 03:49:54 2013 From: report at bugs.python.org (Larry Hastings) Date: Wed, 29 May 2013 01:49:54 +0000 Subject: [issue18090] dict_contains first argument declared register, and shouldn't be Message-ID: <1369792194.1.0.0166087183245.issue18090@psf.upfronthosting.co.za> New submission from Larry Hastings: I'm monkeying around with CPython trunk, and just noticed the following declaration in Objects/dictobject.c: static PyObject * dict_contains(register PyDictObject *mp, PyObject *key) Although dict_contains is a static method, it's cast to PyCFunction and stored in the methoddef array for the dict class. Therefore it must be callable when cast to a PyCFunction--indeed, that's the only way it is ever called. Although the "register" keyword is at best a vague hope, surely it'd be bad news if our wish was granted? The first argument to the PyCFunction typedef is *not* declared register. So if the caller pushed the first argument on the stack, and dict_contains went looking for its first argument in a register... kablooey. Surely we must remove the "register" keyword to this function, and similarly clean up all other functions ever cast to PyCFunction or PyCFunctionWithKeywords. The "register" keyword isn't just a euphemism for "I want this code to go faster" -ly yours, ---------- components: Interpreter Core messages: 190263 nosy: larry priority: low severity: normal stage: needs patch status: open title: dict_contains first argument declared register, and shouldn't be type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 03:50:33 2013 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 29 May 2013 01:50:33 +0000 Subject: [issue1554133] PyOS_InputHook() and related API funcs. not documented Message-ID: <1369792233.54.0.528066684995.issue1554133@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed versions: -Python 2.7, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 04:00:44 2013 From: report at bugs.python.org (Larry Hastings) Date: Wed, 29 May 2013 02:00:44 +0000 Subject: [issue18091] Remove PyNoArgsFunction Message-ID: <1369792844.19.0.815911667989.issue18091@psf.upfronthosting.co.za> New submission from Larry Hastings: There's a typedef in methodobject.h called PyNoArgsFunction. You might think it's used for METH_NOARGS functions--you'd be wrong, those use PyCFunction and pass in NULL for args. No, PyNoArgsFunction is never used. Nor is it documented. It's found in exactly one place in the CPython tree, and that's when it's declared. We should consider removing it. Note that I'm pretty sure this will break external code; a quick Google found that Blender's extension interface uses it. And AFAICT they still use it, and they *have* moved to Python 3. So I could believe the right call is "we better leave it in". I suspect that PyNoArgsFunction *was* used once upon a time. I further suspect that year started with a 1. ---------- components: Interpreter Core messages: 190264 nosy: larry priority: low severity: normal stage: needs patch status: open title: Remove PyNoArgsFunction type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 04:04:36 2013 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 29 May 2013 02:04:36 +0000 Subject: [issue16102] uuid._netbios_getnode() is outdated In-Reply-To: <1349112809.97.0.499056156586.issue16102@psf.upfronthosting.co.za> Message-ID: <1369793076.43.0.994982466352.issue16102@psf.upfronthosting.co.za> A.M. Kuchling added the comment: This patch seems obviously correct to me, so it should be applied. It looks like there's already a test in test_uuid.py that exercises _netbios_getnode() if the netbios module is importable, so there's no test to add, though maybe we need a buildbot that has the module available. ---------- nosy: +akuchling stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 04:22:54 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 29 May 2013 02:22:54 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <3bKwgd3Hj3z7Ll2@mail.python.org> Roundup Robot added the comment: New changeset 968f6094788b by Terry Jan Reedy in branch '3.3': Issue #15392: Do not run tests if threading/_thread not available. Otherwise http://hg.python.org/cpython/rev/968f6094788b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 04:30:26 2013 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 29 May 2013 02:30:26 +0000 Subject: [issue18020] html.escape 10x slower than cgi.escape In-Reply-To: <1369038098.34.0.795942514317.issue18020@psf.upfronthosting.co.za> Message-ID: <1369794626.9.0.397486780946.issue18020@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Matt's patch looks good to me. It removes two module-level dicts, but they're marked as internal, so that's OK. There's already a test case that exercises html.escape(), so I don't think any additional tests are needed. ---------- nosy: +akuchling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 05:34:40 2013 From: report at bugs.python.org (Jeffrey C. Jacobs) Date: Wed, 29 May 2013 03:34:40 +0000 Subject: [issue1693050] \w not helpful for non-Roman scripts Message-ID: <1369798480.17.0.741166211873.issue1693050@psf.upfronthosting.co.za> Jeffrey C. Jacobs added the comment: Maybe you could show us the byte-for-byte hex of the string you're testing so we can examine if it's really a code point intending word boundary or just a code point for the sake of beginning a new character. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 05:53:19 2013 From: report at bugs.python.org (Roger Serwy) Date: Wed, 29 May 2013 03:53:19 +0000 Subject: [issue18052] IDLE 3.3.2 Windows taskbar icon regression In-Reply-To: <1369437693.91.0.216380064498.issue18052@psf.upfronthosting.co.za> Message-ID: <1369799599.4.0.0840954474367.issue18052@psf.upfronthosting.co.za> Roger Serwy added the comment: For me, 3.3.2 32-bit won't pin to the taskbar, but 3.3.1 can. Running lnk-parser on the .lnk files for IDLE reveal no obvious differences. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 05:58:42 2013 From: report at bugs.python.org (Roger Serwy) Date: Wed, 29 May 2013 03:58:42 +0000 Subject: [issue17511] Idle find function closes after each find operation In-Reply-To: <1363902452.43.0.911749750934.issue17511@psf.upfronthosting.co.za> Message-ID: <1369799922.97.0.478037391714.issue17511@psf.upfronthosting.co.za> Roger Serwy added the comment: I debated whether or not to leave #14146 as pending or to close it out altogether. I'd rather not let the design decisions of Tk dictate inconsistent cross-platform behavior for IDLE, but I'm willing to hear Tk's rationale and possible fix for that problem. I would like to commit the current patch and close this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 06:24:23 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 29 May 2013 04:24:23 +0000 Subject: [issue14146] IDLE: source line in editor doesn't highlight when debugging In-Reply-To: <1330401708.67.0.511106941359.issue14146@psf.upfronthosting.co.za> Message-ID: <1369801463.04.0.64858912065.issue14146@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This appears fixed for not, even if not the way we would like. Thanks. If a future tk changes, a new patch will be version-dependent and that will be a new issue. ---------- resolution: later -> fixed status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 06:36:15 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 29 May 2013 04:36:15 +0000 Subject: [issue17511] Idle find function closes after each find operation In-Reply-To: <1363902452.43.0.911749750934.issue17511@psf.upfronthosting.co.za> Message-ID: <1369802175.04.0.159176240473.issue17511@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I closed #14146. Same comment will apply here once this is committed. I would like to try the latest patch here before that, and will try to do so tomorrow. I agree with trying to be consistent across platforms. I am pretty sure that use of multiple personal computers, especially with multiple OSes, is more common than it used to be. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 08:00:40 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 29 May 2013 06:00:40 +0000 Subject: [issue18047] Descriptors get invoked in old-style objects and classes In-Reply-To: <1369373983.58.0.00587959802813.issue18047@psf.upfronthosting.co.za> Message-ID: <1369807240.38.0.140347003993.issue18047@psf.upfronthosting.co.za> Raymond Hettinger added the comment: We document what we're willing to guarantee. The exposure of descriptors in old-style classes was an incidental implementation detail. Sorry, I'm going to close this one. Besides, it's time to start forgetting Python 2 and move along :-) ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 08:25:00 2013 From: report at bugs.python.org (Andreas Jung) Date: Wed, 29 May 2013 06:25:00 +0000 Subject: [issue18092] Python 2.7.5 installation broken on OpenSuse 12.2 Message-ID: <1369808700.25.0.570015045706.issue18092@psf.upfronthosting.co.za> New submission from Andreas Jung: I tried to install 2.7.5 on my OpenSuse 12.2 (latest patches) ajung at blackmoon2:~/sandboxes/mib.portal> cat /etc/issue Welcome to openSUSE 12.2 "Mantis" - Kernel \r (\l). Compilation went fine (no visible errors). Starting the interpreter gives me: ajung at blackmoon2:~/sandboxes/mib.portal> /opt/python-2.7.5/bin/python Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] Python 2.7.5 (default, May 29 2013, 08:19:10) [GCC 4.7.1 20120723 [gcc-4_7-branch revision 189773]] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> Trying to bootstrap a Pyramid project using zc.buildout gives me: ajung at blackmoon2:~/sandboxes/mib.portal> /opt/python-2.7.5/bin/python bootstrap.py Could not find platform dependent libraries Consider setting $PYTHONHOME to [:] Traceback (most recent call last): File "bootstrap.py", line 21, in import os, shutil, sys, tempfile, urllib, urllib2, subprocess File "/opt/python-2.7.5/lib/python2.7/shutil.py", line 12, in import collections File "/opt/python-2.7.5/lib/python2.7/collections.py", line 8, in from _collections import deque, defaultdict ImportError: No module named _collections ---------- messages: 190274 nosy: Andreas.Jung priority: normal severity: normal status: open title: Python 2.7.5 installation broken on OpenSuse 12.2 type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 08:25:15 2013 From: report at bugs.python.org (Andreas Jung) Date: Wed, 29 May 2013 06:25:15 +0000 Subject: [issue18092] Python 2.7.5 installation broken on OpenSuse 12.2 In-Reply-To: <1369808700.25.0.570015045706.issue18092@psf.upfronthosting.co.za> Message-ID: <1369808715.08.0.882652663632.issue18092@psf.upfronthosting.co.za> Changes by Andreas Jung : ---------- components: +Build _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 09:22:13 2013 From: report at bugs.python.org (Ned Deily) Date: Wed, 29 May 2013 07:22:13 +0000 Subject: [issue18092] Python 2.7.5 installation broken on OpenSuse 12.2 In-Reply-To: <1369808700.25.0.570015045706.issue18092@psf.upfronthosting.co.za> Message-ID: <1369812133.35.0.893269243673.issue18092@psf.upfronthosting.co.za> Ned Deily added the comment: Without more information, it is difficult to guess what is going wrong. Please provide exactly what ./configure options you used to build Python and any "make install" options. When you start Python, what values do "sys.prefix", "sys.exec_prefix", and "sys.path" have? Does "python -E" give any different results? ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 09:23:55 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Wed, 29 May 2013 07:23:55 +0000 Subject: [issue18052] IDLE 3.3.2 Windows taskbar icon regression In-Reply-To: <1369437693.91.0.216380064498.issue18052@psf.upfronthosting.co.za> Message-ID: <1369812235.95.0.334682052815.issue18052@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I can't reproduce the issue it all; IDLE just readily pins to the task bar with the correct icon. Can somebody please provide exact steps to reproduce? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 10:41:05 2013 From: report at bugs.python.org (=?utf-8?q?Dra=C5=BEen_Lu=C4=8Danin?=) Date: Wed, 29 May 2013 08:41:05 +0000 Subject: [issue18087] os.listdir don't show hidden option In-Reply-To: <1369781361.8.0.806080395259.issue18087@psf.upfronthosting.co.za> Message-ID: <1369816865.79.0.268260821543.issue18087@psf.upfronthosting.co.za> Dra?en Lu?anin added the comment: I created a first version of the patch (attached as a remote hg repo). It would enable users to exclude hidden files with: import os print(os.listdir(path='.', show_hidden=False)) while still keeping full backwards compatibility, since show_hidden is an optional argument set to True by default. @Dmi Baranov - well, I think aiming at the ls functionality would be a good first step (so we would mimic the -a flag, as explained in the manpage). As far as Windows, that's not too clear, I agree. So far I only added the functionality to the posix_listdir. Do you think this should act the same on Windows - i.e. hiding dotfiles? ---------- hgrepos: +193 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 10:52:22 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 29 May 2013 08:52:22 +0000 Subject: [issue11229] Make the Mac installer more like the Windows installer In-Reply-To: <1297899282.67.0.178978272506.issue11229@psf.upfronthosting.co.za> Message-ID: <1369817542.3.0.485136014298.issue11229@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I'm +1 on the general idea, but have some remarks anyway: 1) "for all users" vs. "current user" This likely requires a post-install script to fix up the load command's in binaries: on OSX binaries contain absolute paths to the libraries the link with (which for the binary installers includes libpython). This is easy to do with macholib, but that's not in the stdlib. An alternative is to use @loader_path, to link with a path relative to the executable, but that would mean you can no longer copy the python binary an expect it to work (which currently does work for framework installs) 2) Tcl/Tk: this is currently not included in the binary installer, although it might be better to start doing that given the problems described in . The disadvantage is that the size of the installer would grow significantly. 3) A pre-install hook that cleans up previous installations of the same feature release would be nice, currently upgrade can keep junk files alive. 4) We're already installing IDLE and the Python documentation in the Application folder (as well as the mac-specific Python Launcher and a tool for updating the command-line shell profile). Adding a link for starting the command-line in Terminal.app is a good idea. 5) I'm not sure about an uninstall option, while it would be nice to have such an option it would also be custom code that runs with increased privileges (for the "all users" install). Sadly enough Apple doesn't have an uninstall option in their packaging solution. ---------- nosy: +ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 11:01:59 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Wed, 29 May 2013 09:01:59 +0000 Subject: [issue11229] Make the Mac installer more like the Windows installer In-Reply-To: <1297899282.67.0.178978272506.issue11229@psf.upfronthosting.co.za> Message-ID: <1369818119.27.0.287422522973.issue11229@psf.upfronthosting.co.za> Ronald Oussoren added the comment: BTW. There is a completely different way for distributing Python: drop the entire installer and provide a zipfile containing a single application bundle. The most likely target for the application is IDLE, with a new menu item for making the command-line tools available (see editors like Textmate and BBEdit for a precedent, or even Xcode). The advantage of a single application bundle is that you don't have to have an installer, users can just drag&drop for installation *and deinstallation*. An added advantage is that there are third party libraries that make it easy to (auto-)update applications, the "check for updates" menu in a lot of Mac apps is based on an opensource library that could be used here is well. There are some disadvatages as well: * It is different than how Python is currently distributed, any change will upset some people * If there's a single application bundle you cannot easily add Python Launcher (although it could be hidden inside the toplevel app) * At least some people will be upset by having to start IDLE at all, even if it would only be used to make the command-line tools available * Someone will have to do the work :-) I intentionally don't list the Mac App store as an advantage or disadvantage, primarily because the app store requires sandboxing and that would make no sense for a general programming tool (a sandboxed version of IDLE app could be used to start scripts, but those scripts would be in the sandbox as well and hence couldn't access most of the system). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 11:39:49 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 29 May 2013 09:39:49 +0000 Subject: [issue18052] IDLE 3.3.2 Windows taskbar icon regression In-Reply-To: <1369437693.91.0.216380064498.issue18052@psf.upfronthosting.co.za> Message-ID: <1369820389.41.0.720450160489.issue18052@psf.upfronthosting.co.za> Terry J. Reedy added the comment: All I did was install (standard, all users) and start Idle without rebooting. Problem goes away after reboot. This happened on previous versions with different hardware. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 11:56:28 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 29 May 2013 09:56:28 +0000 Subject: [issue18087] os.listdir don't show hidden option In-Reply-To: <1369781361.8.0.806080395259.issue18087@psf.upfronthosting.co.za> Message-ID: <1369821388.45.0.00957496964947.issue18087@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: The concept of hidden file depends on the platform, and is independent of the listdir() function. The first thing is to agree on an implementation of the "hidden" property, and expose it as os.path.ishidden. Then we can consider an option to os.listdir. But do we need it? today it does not have any option at all, like isfile or isdir which would be more useful. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 12:00:19 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 May 2013 10:00:19 +0000 Subject: [issue18087] os.listdir don't show hidden option In-Reply-To: <1369781361.8.0.806080395259.issue18087@psf.upfronthosting.co.za> Message-ID: <1369821619.96.0.886380633085.issue18087@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't really understand, since this is an easy one-liner: [n for n in os.listdir(...) if not n.startswith(".")] Also, as mentioned, what you want to hide is not necessarily well-defined. For example, under Unix you might want to hide "*~" files. So I don't think os.listdir() should grow such an option, it's up to user code to decide what should be displayed / reported to the user. (or in other words: while Python provides filesystem-access functions, Python is not a shell) ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 12:03:31 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 May 2013 10:03:31 +0000 Subject: [issue16102] uuid._netbios_getnode() is outdated In-Reply-To: <1349112809.97.0.499056156586.issue16102@psf.upfronthosting.co.za> Message-ID: <1369821811.42.0.711981578729.issue16102@psf.upfronthosting.co.za> Antoine Pitrou added the comment: If noone has reported the issue in years (Google doesn't seem to report any occurrence), perhaps it means the code is simply not used anymore? In which case it should probably be removed. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 12:11:58 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 May 2013 10:11:58 +0000 Subject: [issue9369] const char* for PyObject_CallMethod and PyObject_CallFunction In-Reply-To: <1279965202.04.0.507207277215.issue9369@psf.upfronthosting.co.za> Message-ID: <1369822318.48.0.0252240970658.issue9369@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Looks good to me. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 12:32:36 2013 From: report at bugs.python.org (Dmi Baranov) Date: Wed, 29 May 2013 10:32:36 +0000 Subject: [issue18087] os.listdir don't show hidden option In-Reply-To: <1369781361.8.0.806080395259.issue18087@psf.upfronthosting.co.za> Message-ID: <1369823556.87.0.418032343746.issue18087@psf.upfronthosting.co.za> Dmi Baranov added the comment: > Also, as mentioned, what you want to hide is not necessarily > well-defined. For example, under Unix you might want > to hide "*~" files. Yes, and instead of adding another parameters, something like that: os.listdir(path, show_hidden=False, hidden_files_mask='*~', but_show_directories=True, something_etc=None) I suggest leaving the "hidden files" logic outside of stdlib (in the end-user code). Welcome to `glob` / `fnmatch` modules :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 12:52:23 2013 From: report at bugs.python.org (Dmi Baranov) Date: Wed, 29 May 2013 10:52:23 +0000 Subject: [issue17987] test.support.captured_stderr, captured_stdin not documented In-Reply-To: <1368653423.88.0.898801742943.issue17987@psf.upfronthosting.co.za> Message-ID: <1369824743.39.0.996188740389.issue17987@psf.upfronthosting.co.za> Dmi Baranov added the comment: Fred or Serhiy - any news here? I'm signed Contributor Agreement few days ago, just waiting a change in my profile here, please don't worry about copyright :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 12:58:53 2013 From: report at bugs.python.org (Larry Hastings) Date: Wed, 29 May 2013 10:58:53 +0000 Subject: [issue18090] dict_contains first argument declared register, and shouldn't be In-Reply-To: <1369792194.1.0.0166087183245.issue18090@psf.upfronthosting.co.za> Message-ID: <1369825133.03.0.52111578085.issue18090@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- nosy: +Mark.Shannon, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 13:00:10 2013 From: report at bugs.python.org (Larry Hastings) Date: Wed, 29 May 2013 11:00:10 +0000 Subject: [issue18091] Remove PyNoArgsFunction In-Reply-To: <1369792844.19.0.815911667989.issue18091@psf.upfronthosting.co.za> Message-ID: <1369825210.53.0.635986551301.issue18091@psf.upfronthosting.co.za> Larry Hastings added the comment: Either of you gentlemen care to offer an opinion? ---------- nosy: +benjamin.peterson, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 13:05:57 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 May 2013 11:05:57 +0000 Subject: [issue18087] os.listdir don't show hidden option In-Reply-To: <1369781361.8.0.806080395259.issue18087@psf.upfronthosting.co.za> Message-ID: <1369825557.15.0.76452777268.issue18087@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> rejected stage: -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 13:13:14 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 May 2013 11:13:14 +0000 Subject: [issue9369] const char* for PyObject_CallMethod and PyObject_CallFunction In-Reply-To: <1279965202.04.0.507207277215.issue9369@psf.upfronthosting.co.za> Message-ID: <1369825994.43.0.2981395887.issue9369@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 13:13:41 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 May 2013 11:13:41 +0000 Subject: [issue16102] uuid._netbios_getnode() is outdated In-Reply-To: <1349112809.97.0.499056156586.issue16102@psf.upfronthosting.co.za> Message-ID: <1369826021.67.0.785064264621.issue16102@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 13:16:24 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 29 May 2013 11:16:24 +0000 Subject: [issue18085] Verifying refcounts.dat In-Reply-To: <1369768958.38.0.697954786488.issue18085@psf.upfronthosting.co.za> Message-ID: <1369826184.39.0.385990860361.issue18085@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: And is it necessary to list all functions there? Many functions share the same behavior: they don't change the ownership of PyObject* passed as argument, and return a new reference. Only document functions that don't conform to this rule, like PyTuple_SET_ITEM and PyImport_AddModule. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 13:22:02 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 May 2013 11:22:02 +0000 Subject: [issue18090] dict_contains first argument declared register, and shouldn't be In-Reply-To: <1369792194.1.0.0166087183245.issue18090@psf.upfronthosting.co.za> Message-ID: <1369826522.39.0.168752307127.issue18090@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I would recommend suppressing all "register" keywords from our C source files. It shouldn't make any difference these days. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 13:28:04 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 May 2013 11:28:04 +0000 Subject: [issue18084] wave.py should use sys.byteorder to determine endianess In-Reply-To: <1369768579.1.0.487057247518.issue18084@psf.upfronthosting.co.za> Message-ID: <1369826884.2.0.265883246937.issue18084@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Can you please submit a contributor form? http://python.org/psf/contrib/contrib-form/ http://python.org/psf/contrib/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 13:35:48 2013 From: report at bugs.python.org (Stefan Krah) Date: Wed, 29 May 2013 11:35:48 +0000 Subject: [issue17768] _decimal: allow NUL fill character In-Reply-To: <1366142733.14.0.416773869119.issue17768@psf.upfronthosting.co.za> Message-ID: <1369827348.48.0.602950866274.issue17768@psf.upfronthosting.co.za> Stefan Krah added the comment: Here's a baroque patch for _decimal. It's complicated by the fact that there's no way of knowing what kind of UTF-8 fragments might be hidden in multi-byte separators or decimal points. ---------- Added file: http://bugs.python.org/file30407/issue17768.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 13:51:30 2013 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 29 May 2013 11:51:30 +0000 Subject: [issue18093] Move main functions to a separate Programs directory Message-ID: <1369828290.2.0.750301008205.issue18093@psf.upfronthosting.co.za> New submission from Nick Coghlan: This patch moves the C level main functions for python, _testembed and _freeze_importlib to a new Programs directory. I added README files with my current understanding of the expected contents of the Python, Objects, Modules and Programs directories and also attempted to update the Windows builds (which don't appear to include _testembed at all). ---------- components: Build, Interpreter Core files: move_programs.diff keywords: patch messages: 190292 nosy: ncoghlan priority: normal severity: normal stage: patch review status: open title: Move main functions to a separate Programs directory type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file30408/move_programs.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 13:51:51 2013 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 29 May 2013 11:51:51 +0000 Subject: [issue18093] Move main functions to a separate Programs directory In-Reply-To: <1369828290.2.0.750301008205.issue18093@psf.upfronthosting.co.za> Message-ID: <1369828311.64.0.4185772965.issue18093@psf.upfronthosting.co.za> Changes by Nick Coghlan : Added file: http://bugs.python.org/file30409/move_programs.git.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 13:52:56 2013 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 29 May 2013 11:52:56 +0000 Subject: [issue18093] Move main functions to a separate Programs directory In-Reply-To: <1369828290.2.0.750301008205.issue18093@psf.upfronthosting.co.za> Message-ID: <1369828376.51.0.976241477183.issue18093@psf.upfronthosting.co.za> Nick Coghlan added the comment: Note that the two patches are the same, I was just curious to see the difference in handling between them in terms of the review integration. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 13:54:26 2013 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 29 May 2013 11:54:26 +0000 Subject: [issue18093] Move main functions to a separate Programs directory In-Reply-To: <1369828290.2.0.750301008205.issue18093@psf.upfronthosting.co.za> Message-ID: <1369828466.81.0.471172257793.issue18093@psf.upfronthosting.co.za> Changes by Nick Coghlan : Removed file: http://bugs.python.org/file30408/move_programs.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 13:55:11 2013 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 29 May 2013 11:55:11 +0000 Subject: [issue18093] Move main functions to a separate Programs directory In-Reply-To: <1369828290.2.0.750301008205.issue18093@psf.upfronthosting.co.za> Message-ID: <1369828511.56.0.017547433074.issue18093@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- Removed message: http://bugs.python.org/msg190293 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 14:00:22 2013 From: report at bugs.python.org (=?utf-8?q?Dra=C5=BEen_Lu=C4=8Danin?=) Date: Wed, 29 May 2013 12:00:22 +0000 Subject: [issue18087] os.listdir don't show hidden option In-Reply-To: <1369825557.2.0.484296541513.issue18087@psf.upfronthosting.co.za> Message-ID: Dra?en Lu?anin added the comment: @Amaury Forgeot d'Arc - well, the '.' and '..' special files are detected directly in the listdir code, so I don't think there is any need to interleave this logic any deeper (such as os.path.ishidden). @Antoine Pitrou - a one-liner, but it unnecessarily complicates the code - an optional argument is a much more elegant solution in my opinion. Regarding the *~ files - they are backup files, not hidden files (same as e.g. #somefile# files that Emacs generates). These are shown by ls, just hidden in some desktop environments. Another point is that dotfiles are really something of a special case (especially to programmers http://dotfiles.github.io/ ), because many programs store configurations and special data inside and it makes sense to allow users to omit these. I know I could use glob, I am currently doing that, but it seems like bad practice to switch to a different module that is also in the standard library, just it has the "dotfile detection magic" and os doesn't. The fact is that dotfiles do have special a meaning in Unix operating systems and the os module documentation states that some functionality is only tailored to Unix-based platforms (http://docs.python.org/2/library/os.html): An ?Availability: Unix? note means that this function is commonly found on Unix systems. It does not make any claims about its existence on a specific operating system. On Wed, May 29, 2013 at 1:05 PM, Serhiy Storchaka wrote: > > Changes by Serhiy Storchaka : > > > ---------- > resolution: -> rejected > stage: -> committed/rejected > status: open -> closed > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 14:07:24 2013 From: report at bugs.python.org (Dmi Baranov) Date: Wed, 29 May 2013 12:07:24 +0000 Subject: [issue17681] Work with an extra field of gzip files In-Reply-To: <1365519781.38.0.309194725625.issue17681@psf.upfronthosting.co.za> Message-ID: <1369829244.36.0.74889642075.issue17681@psf.upfronthosting.co.za> Dmi Baranov added the comment: I'll be glad to do it, but having some questions for discussing. First about FEXTRA format - it consists of a series of subfields [1] and current Lib/test/test_gzip.py :: test_read_with_extra having a bit incorrect extra field - sure, if somebody using format from RFC1952. You having a real samples with extra field?. Should we parse subfields here (I have already asked Jean-Loup Gailly, maintainer of registry of subfield IDs, for current registry values and waiting reply) or will just provide extra header as byte string? Next about GzipFile's public interface - GzipFile(...).extra look ugly. Should I extend this ticket to support all metadata headers? FNAME, FCOMMENT, FHCRC, etc - correctly reading now, but no ways to get it outside (and no ways to create a file with FCOMMENT and FHCRC now). Eg, something to like this: GzipFile(...).metadata.FNAME == 'sample.gz' GzipFile(..., extra=b'AP6Test', comment='comment') [1] http://tools.ietf.org/html/rfc1952#section-2.3.1.1 ---------- nosy: +dmi.baranov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 14:20:00 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 May 2013 12:20:00 +0000 Subject: [issue18094] Skip tests in test_uuid not silently Message-ID: <1369830000.95.0.179404474041.issue18094@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Tests in test_uuid just silently skipped if ran on unsuitable platform or if required module is not available. In such cases tests resulted as succesful passed. The proposed patch uses unittest.skipUnless to mark them as skipped. ---------- components: Tests files: test_uuid.patch keywords: patch messages: 190296 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Skip tests in test_uuid not silently type: enhancement versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30410/test_uuid.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 14:25:12 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 May 2013 12:25:12 +0000 Subject: [issue16102] uuid._netbios_getnode() is outdated In-Reply-To: <1349112809.97.0.499056156586.issue16102@psf.upfronthosting.co.za> Message-ID: <1369830312.12.0.515130753245.issue16102@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Any exceptions were silently dropped. And tests silently skipped (issue18094). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 14:32:00 2013 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Wed, 29 May 2013 12:32:00 +0000 Subject: [issue17987] test.support.captured_stderr, captured_stdin not documented In-Reply-To: <1368653423.88.0.898801742943.issue17987@psf.upfronthosting.co.za> Message-ID: <1369830720.49.0.293425430539.issue17987@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: >From v5 of the patch: + A context managers that temporarily replaces the :data:`sys.stdin` / + :data:`sys.stdout` / :data:`sys.stderr` stream with :class:`io.StringIO` + object. I'd go with singular nouns instead of trying to map across them with plurals: Context manager that temporarily replaces the named stream with an :class:`io.StringIO` object. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 14:40:25 2013 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 29 May 2013 12:40:25 +0000 Subject: [issue17925] asynchat.async_chat.initiate_send : del deque[0] is not safe In-Reply-To: <1367934356.3.0.498041746077.issue17925@psf.upfronthosting.co.za> Message-ID: <1369831225.98.0.83470213569.issue17925@psf.upfronthosting.co.za> Xavier de Gaye added the comment: The problem is that when the fifo contains a producer and the more() method of the producer returns a non-empty bytes sequence, then the producer must be put back in the fifo first. This is what does the following change made to Pierrick patch: diff --git a/Lib/asynchat.py b/Lib/asynchat.py --- a/Lib/asynchat.py +++ b/Lib/asynchat.py @@ -229,6 +229,7 @@ except TypeError: data = first.more() if data: + self.producer_fifo.appendleft(first) self.producer_fifo.appendleft(data) continue The asynchat test is OK when the patch is modified with the above change. However, then the patch does not make initiate_send() thread safe. There is now a race condition: another thread may be allowed to run between the two appendleft() calls, this other thread may then call the more() method of 'first' and send the returned bytes. When that happens, the sent data is mis-ordered. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 14:44:30 2013 From: report at bugs.python.org (Giampaolo Rodola') Date: Wed, 29 May 2013 12:44:30 +0000 Subject: [issue17925] asynchat.async_chat.initiate_send : del deque[0] is not safe In-Reply-To: <1367934356.3.0.498041746077.issue17925@psf.upfronthosting.co.za> Message-ID: <1369831470.47.0.841611593187.issue17925@psf.upfronthosting.co.za> Giampaolo Rodola' added the comment: I think we shouldn't expect asynchat to be thread safe in this regard. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 14:44:36 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 May 2013 12:44:36 +0000 Subject: [issue17681] Work with an extra field of gzip and zip files In-Reply-To: <1365519781.38.0.309194725625.issue17681@psf.upfronthosting.co.za> Message-ID: <1369831476.48.0.595941701671.issue17681@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I have an almost ready patch but I doubt about interface. It can be discussed. ZIP file entries have similar extra field and I'm planning to add similar feature to the zipfile module too. Here are preliminary patches. ---------- keywords: +patch title: Work with an extra field of gzip files -> Work with an extra field of gzip and zip files Added file: http://bugs.python.org/file30411/gzip_extra.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 14:45:13 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 May 2013 12:45:13 +0000 Subject: [issue17681] Work with an extra field of gzip and zip files In-Reply-To: <1365519781.38.0.309194725625.issue17681@psf.upfronthosting.co.za> Message-ID: <1369831513.53.0.0318441049933.issue17681@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file30412/zip_extra.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 14:48:01 2013 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 29 May 2013 12:48:01 +0000 Subject: [issue18093] Move main functions to a separate Programs directory In-Reply-To: <1369828290.2.0.750301008205.issue18093@psf.upfronthosting.co.za> Message-ID: <1369831681.0.0.329391952197.issue18093@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 14:48:46 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 May 2013 12:48:46 +0000 Subject: [issue17987] test.support.captured_stderr, captured_stdin not documented In-Reply-To: <1368653423.88.0.898801742943.issue17987@psf.upfronthosting.co.za> Message-ID: <1369831726.57.0.135034227245.issue17987@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: LGTM with Fred's suggestion. ---------- assignee: docs at python -> fdrake _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 14:49:35 2013 From: report at bugs.python.org (englabenny) Date: Wed, 29 May 2013 12:49:35 +0000 Subject: [issue16113] Add SHA-3 (Keccak) support In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za> Message-ID: <1369831775.94.0.756368773017.issue16113@psf.upfronthosting.co.za> englabenny added the comment: NIST has published a tentative schedule for SHA-3 standardization. They expect to publish in the second quarter of 2014. See http://csrc.nist.gov/groups/ST/hash/sha-3/timeline_fips.html and http://csrc.nist.gov/groups/ST/hash/sha-3/sha-3_standardization.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 14:59:11 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 29 May 2013 12:59:11 +0000 Subject: [issue17403] Robotparser fails to parse some robots.txt In-Reply-To: <1363085904.54.0.398684856881.issue17403@psf.upfronthosting.co.za> Message-ID: <3bLBnp4K9fzQ0w@mail.python.org> Roundup Robot added the comment: New changeset 30128355f53b by Senthil Kumaran in branch '3.3': #17403: urllib.parse.robotparser normalizes the urls before adding to ruleline. http://hg.python.org/cpython/rev/30128355f53b New changeset e954d7a3bb8a by Senthil Kumaran in branch 'default': merge from 3.3 http://hg.python.org/cpython/rev/e954d7a3bb8a New changeset bcbad715c2ce by Senthil Kumaran in branch '2.7': #17403: urllib.parse.robotparser normalizes the urls before adding to ruleline. http://hg.python.org/cpython/rev/bcbad715c2ce ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 15:01:09 2013 From: report at bugs.python.org (Andrew Stormont) Date: Wed, 29 May 2013 13:01:09 +0000 Subject: [issue17925] asynchat.async_chat.initiate_send : del deque[0] is not safe In-Reply-To: <1367934356.3.0.498041746077.issue17925@psf.upfronthosting.co.za> Message-ID: <1369832469.33.0.543164727787.issue17925@psf.upfronthosting.co.za> Andrew Stormont added the comment: What about changing: self.producer_fifo.appendleft(first) self.producer_fifo.appendleft(data) To self.producer_fifo.extendleft([data, first]) Assuming deque's extendleft is actually thread safe. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 15:01:33 2013 From: report at bugs.python.org (Senthil Kumaran) Date: Wed, 29 May 2013 13:01:33 +0000 Subject: [issue17403] Robotparser fails to parse some robots.txt In-Reply-To: <1363085904.54.0.398684856881.issue17403@psf.upfronthosting.co.za> Message-ID: <1369832493.48.0.734650260763.issue17403@psf.upfronthosting.co.za> Senthil Kumaran added the comment: This is fixed in default, 3.3 and 2.7. I will merge this change to 3.2 code line before closing this. I shall raise a new request for updating robotparser with other goodies. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 15:48:40 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 29 May 2013 13:48:40 +0000 Subject: [issue17768] _decimal: allow NUL fill character In-Reply-To: <1366142733.14.0.416773869119.issue17768@psf.upfronthosting.co.za> Message-ID: <3bLCtv4v0HzPNt@mail.python.org> Roundup Robot added the comment: New changeset 9156c663d6aa by Stefan Krah in branch '3.3': Issue #17768: Support newline fill character in decimal.py and NUL fill http://hg.python.org/cpython/rev/9156c663d6aa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 16:00:46 2013 From: report at bugs.python.org (Stefan Krah) Date: Wed, 29 May 2013 14:00:46 +0000 Subject: [issue17768] _decimal: allow NUL fill character In-Reply-To: <1366142733.14.0.416773869119.issue17768@psf.upfronthosting.co.za> Message-ID: <1369836046.69.0.0818635674696.issue17768@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 16:07:24 2013 From: report at bugs.python.org (Roman Valov) Date: Wed, 29 May 2013 14:07:24 +0000 Subject: [issue18095] unable to invoke socket.connect with AF_UNSPEC Message-ID: <1369836444.73.0.072481574082.issue18095@psf.upfronthosting.co.za> New submission from Roman Valov: There is a way to "disconnect" UDP socket that was previously "connected" to specific remote endpoint in C: struct sockaddr_in sin; memset((char *)&sin, 0, sizeof(sin)); sin.sin_family = AF_UNSPEC; connect(fd, (struct sockaddr *)&sin, sizeof(sin)); However in this is not available in python, since connect accepts only (host, port) as a parameter for UDP socket. It's possible to drop "port" connection with port=0, however I can't find a way to drop "host" connection. ---------- components: IO messages: 190308 nosy: Roman.Valov priority: normal severity: normal status: open title: unable to invoke socket.connect with AF_UNSPEC type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 16:09:59 2013 From: report at bugs.python.org (Marius Gedminas) Date: Wed, 29 May 2013 14:09:59 +0000 Subject: [issue9736] doctest.DocTestSuite doesn't handle test globs correctly In-Reply-To: <1283367674.32.0.228375766546.issue9736@psf.upfronthosting.co.za> Message-ID: <1369836599.31.0.790053841591.issue9736@psf.upfronthosting.co.za> Marius Gedminas added the comment: This is a duplicate of issue2604, isn't it? ---------- nosy: +mgedmin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 16:34:12 2013 From: report at bugs.python.org (Stefan Drees) Date: Wed, 29 May 2013 14:34:12 +0000 Subject: [issue18093] Move main functions to a separate Programs directory In-Reply-To: <1369828290.2.0.750301008205.issue18093@psf.upfronthosting.co.za> Message-ID: <1369838052.07.0.32686465043.issue18093@psf.upfronthosting.co.za> Changes by Stefan Drees : ---------- nosy: +dilettant _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 16:39:54 2013 From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=) Date: Wed, 29 May 2013 14:39:54 +0000 Subject: [issue18078] threading.Condition to allow notify on a specific waiter In-Reply-To: <1369712419.12.0.434704480843.issue18078@psf.upfronthosting.co.za> Message-ID: <1369838394.61.0.130348427836.issue18078@psf.upfronthosting.co.za> Jo?o Bernardo added the comment: I did what @Richard Oudkerk said and created the "wait_for_any" classmethod for the Condition class. Other Changes: - I had to refactor "wait" and "wait_for" to be specializations of "wait_for_any". - try...except on "notify" because the inner lock might have been released by other condition. - Added two helper functions "_remove_waiter" and "_wait" (the part of the old wait function to re-acquire the inner lock) Bonus: To simplify the use, I added a "from_condition" constructor to create a new condition using the same lock as an existing one. That way, you don't need to record the lock someplace else before creating a new Condition for the same lock. * The current tests pass. * Missing: new tests and docs. ---- Sample: lock = Lock() cond1 = Condition(lock) cond2 = Condition(lock) cond3 = Condition.from_condition(cond1) with lock: Condition.wait_for_any({cond1: foo, cond2: bar}) Condition.wait_for_any([cond1, cond2, cond3]) # no predicates # used on "wait" with cond2: # same thing Condition.wait_for_any({cond3: foo}) --- PS: the patch text is messy because of refactoring and some lines were moved. It is easy to read when applied. ---------- keywords: +patch Added file: http://bugs.python.org/file30413/wait_for_any.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 16:58:51 2013 From: report at bugs.python.org (Hideaki Takahashi) Date: Wed, 29 May 2013 14:58:51 +0000 Subject: [issue18084] wave.py should use sys.byteorder to determine endianess In-Reply-To: <1369768579.1.0.487057247518.issue18084@psf.upfronthosting.co.za> Message-ID: <1369839531.32.0.881354134769.issue18084@psf.upfronthosting.co.za> Hideaki Takahashi added the comment: I signed it and by eSign and got a signed/filed response yesterday. But according to Lifecycle of a patch in developer guide, my name is needed to be added to Misc/ACKS. Can I update patch to do this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 17:12:06 2013 From: report at bugs.python.org (Ethan Furman) Date: Wed, 29 May 2013 15:12:06 +0000 Subject: [issue17947] Code, test, and doc review for PEP-0435 Enum In-Reply-To: <1368168600.94.0.409104207023.issue17947@psf.upfronthosting.co.za> Message-ID: <1369840326.48.0.969268689097.issue17947@psf.upfronthosting.co.za> Ethan Furman added the comment: Working on documentation... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 17:33:02 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 May 2013 15:33:02 +0000 Subject: [issue18084] wave.py should use sys.byteorder to determine endianess In-Reply-To: <1369768579.1.0.487057247518.issue18084@psf.upfronthosting.co.za> Message-ID: <1369841582.75.0.439608825657.issue18084@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, please. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 17:36:32 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 May 2013 15:36:32 +0000 Subject: [issue9369] const char* for PyObject_CallMethod and PyObject_CallFunction In-Reply-To: <1279965202.04.0.507207277215.issue9369@psf.upfronthosting.co.za> Message-ID: <1369841792.15.0.399711776255.issue9369@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: J?rg, Lars, can you please submit a contributor form? http://python.org/psf/contrib/contrib-form/ http://python.org/psf/contrib/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 17:51:18 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 29 May 2013 15:51:18 +0000 Subject: [issue9369] const char* for PyObject_CallMethod and PyObject_CallFunction In-Reply-To: <1279965202.04.0.507207277215.issue9369@psf.upfronthosting.co.za> Message-ID: <3bLGcP3RKTzQhd@mail.python.org> Roundup Robot added the comment: New changeset 0a45896a7cde by Serhiy Storchaka in branch 'default': Issue #9369: The types of `char*` arguments of PyObject_CallFunction() and http://hg.python.org/cpython/rev/0a45896a7cde ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 17:52:16 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 May 2013 15:52:16 +0000 Subject: [issue9369] const char* for PyObject_CallMethod and PyObject_CallFunction In-Reply-To: <1279965202.04.0.507207277215.issue9369@psf.upfronthosting.co.za> Message-ID: <1369842736.28.0.368274197056.issue9369@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: accepted -> fixed stage: commit review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 17:53:39 2013 From: report at bugs.python.org (michael kearney) Date: Wed, 29 May 2013 15:53:39 +0000 Subject: [issue17846] Building Python on Windows - Supplementary info In-Reply-To: <1369751725.64.0.195747344405.issue17846@psf.upfronthosting.co.za> Message-ID: <013a01ce5c84$a70a4670$f51ed350$@kearney@verizon.net> michael kearney added the comment: Thanks for the pointer to your work and discussion in issue16895. I was contemplating something along those lines. I had not started down that path first because I've only relatively recently thrashed the problem enough to understand the issues, and second because I wasn't thrilled with the prospect of implementing anything in microsoft's shell scripting language (called PowerShell now yes?), which being proprietary and primitive would discourage I would think the python community from even considering looking at the code when the inevitable bugs appear. I was intrigued to read in the recent replies to issue 16895 about the suggestion to bootstrap. There is a lot of history to the merits of that approach in other languages. It is surprising to me that the approach isn't used in python. Well I guess, given that python is C under the skin and configure/make is well established unix idiom My progress on this topic has been in fits and starts. It's about what I can tolerate. The state of OpenSLL all by itself is pretty bizarre. Regardless, I believe another fit is in my near future. Judging by the response to your issue there is interest and hope in getting this corner of python under control. I will review your configure/make solution, with luck a patch to the devguide can be just a massive simplification. On the other hand, the discussion of what is going on in automating the process would be useful. The existing docs did help me decode what was going on envetually. -m ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 18:35:09 2013 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 29 May 2013 16:35:09 +0000 Subject: [issue18091] Remove PyNoArgsFunction In-Reply-To: <1369792844.19.0.815911667989.issue18091@psf.upfronthosting.co.za> Message-ID: <1369845309.83.0.95889000288.issue18091@psf.upfronthosting.co.za> Benjamin Peterson added the comment: If you want to convince Blender to stop using it, you can kill it. It's seems fairly harmless, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 18:36:50 2013 From: report at bugs.python.org (Tshepang Lekhonkhobe) Date: Wed, 29 May 2013 16:36:50 +0000 Subject: [issue18093] Move main functions to a separate Programs directory In-Reply-To: <1369828290.2.0.750301008205.issue18093@psf.upfronthosting.co.za> Message-ID: <1369845410.75.0.541686877131.issue18093@psf.upfronthosting.co.za> Changes by Tshepang Lekhonkhobe : ---------- nosy: +tshepang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 18:40:59 2013 From: report at bugs.python.org (Xavier de Gaye) Date: Wed, 29 May 2013 16:40:59 +0000 Subject: [issue17925] asynchat.async_chat.initiate_send : del deque[0] is not safe In-Reply-To: <1367934356.3.0.498041746077.issue17925@psf.upfronthosting.co.za> Message-ID: <1369845659.22.0.136862755741.issue17925@psf.upfronthosting.co.za> Xavier de Gaye added the comment: extendleft is an extension module C function (in the _collections module) that does not release the GIL, so it is thread safe. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 18:45:24 2013 From: report at bugs.python.org (David Taylor) Date: Wed, 29 May 2013 16:45:24 +0000 Subject: [issue18096] bad library order returned by python-config.in Message-ID: <1369845924.16.0.424451971001.issue18096@psf.upfronthosting.co.za> New submission from David Taylor: Misc/python-config.in returns a bad library order when given the --ldflags or --libs arguments. A library should be listed *BEFORE* those libraries that it depends upon. The python library depends upon all the other libraries listed, but it is listed last -- it should be first. When linking with shared libraries, you can generally get away with the current behaviour. When linking with static libraries, it fails ---------- components: Library (Lib) files: xx messages: 190319 nosy: taylor priority: normal severity: normal status: open title: bad library order returned by python-config.in type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file30414/xx _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 18:46:46 2013 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 29 May 2013 16:46:46 +0000 Subject: [issue18085] Verifying refcounts.dat In-Reply-To: <1369826184.39.0.385990860361.issue18085@psf.upfronthosting.co.za> Message-ID: Skip Montanaro added the comment: > And is it necessary to list all functions there? Probably not. However, BITD, I was figuring this stuff out as I was going along by examining the source code and writing down what I found. No regard for common or special cases. S ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 19:21:37 2013 From: report at bugs.python.org (Michel Weinachter) Date: Wed, 29 May 2013 17:21:37 +0000 Subject: [issue18097] Check out my profile on LinkedIn Message-ID: <343561565.10012341.1369848095417.JavaMail.app@ela4-bed83.prod> New submission from Michel Weinachter: LinkedIn ------------ I'd like to include you in my network to share updates and stay in touch. - Michel Michel Weinachter Senior security manager / RSSI at Thales Paris Area, France Confirm that you know Michel Weinachter: https://www.linkedin.com/e/-3qcne3-hhas6r2q-4f/isd/13708904224/XGTvGJjU/?hs=false&tok=26V0lOdbLhnBM1 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/-3qcne3-hhas6r2q-4f/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I4549108961_1/?hs=false&tok=0zmMvplEjhnBM1 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. ---------- files: unnamed messages: 190321 nosy: datamoc priority: normal severity: normal status: open title: Check out my profile on LinkedIn Added file: http://bugs.python.org/file30415/unnamed _______________________________________ Python tracker _______________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: unnamed Type: image/jpeg Size: 1181 bytes Desc: not available URL: From report at bugs.python.org Wed May 29 19:31:08 2013 From: report at bugs.python.org (Matthew Barnett) Date: Wed, 29 May 2013 17:31:08 +0000 Subject: [issue1693050] \w not helpful for non-Roman scripts Message-ID: <1369848668.92.0.290271196311.issue1693050@psf.upfronthosting.co.za> Matthew Barnett added the comment: You could've obtained it from msg76556 or msg190100: >>> print(ascii('??????')) '\u0939\u093f\u0928\u094d\u0926\u0940' >>> import re, regex >>> print(ascii(re.match(r"\w+", '\u0939\u093f\u0928\u094d\u0926\u0940').group())) '\u0939' >>> print(ascii(regex.match(r"\w+", '\u0939\u093f\u0928\u094d\u0926\u0940').group())) '\u0939\u093f\u0928\u094d\u0926\u0940' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 19:31:35 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 29 May 2013 17:31:35 +0000 Subject: [issue18097] spam In-Reply-To: <343561565.10012341.1369848095417.JavaMail.app@ela4-bed83.prod> Message-ID: <1369848695.22.0.597743152807.issue18097@psf.upfronthosting.co.za> Changes by Amaury Forgeot d'Arc : ---------- resolution: -> invalid status: open -> closed title: Check out my profile on LinkedIn -> spam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 20:23:52 2013 From: report at bugs.python.org (Jeffrey C. Jacobs) Date: Wed, 29 May 2013 18:23:52 +0000 Subject: [issue1693050] \w not helpful for non-Roman scripts Message-ID: <1369851832.22.0.476256805938.issue1693050@psf.upfronthosting.co.za> Jeffrey C. Jacobs added the comment: Thanks Matthew and sorry to put you through more work; I just wanted to verify exactly which unicode (UTF-16 I take it) were being used to verify if the UNICODE standard expected them to be treated as unique words or single letters within a word. Sanskrit is an alphabet, not an ideograph so each symbol is considered a letter. So I believe your implementation is correct and yes, you are right, re is at fault. There are just accenting characters and letters in that sequence so they should be interpreted as a single word of 6 letters, as you determine, and not one of the first letter. Mind you, I misinterpreted msg190100 in that I thought you were using findall in which case the answer should be 1, but as far as length of extraction, yes, 6, I totally agree. Sorry for the misunderstanding. http://www.unicode.org/charts/PDF/U0900.pdf contains the code chart for Hindi. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 20:46:46 2013 From: report at bugs.python.org (Matthew Barnett) Date: Wed, 29 May 2013 18:46:46 +0000 Subject: [issue1693050] \w not helpful for non-Roman scripts Message-ID: <1369853206.56.0.184797148682.issue1693050@psf.upfronthosting.co.za> Matthew Barnett added the comment: UTF-16 has nothing to do with it, that's just an encoding (a pair of them actually, UTF-16LE and UTF-16BE). And I don't know why you thought I was using findall in msg190100 when the examples were using match! :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 21:17:37 2013 From: report at bugs.python.org (R. David Murray) Date: Wed, 29 May 2013 19:17:37 +0000 Subject: [issue18097] spam In-Reply-To: <343561565.10012341.1369848095417.JavaMail.app@ela4-bed83.prod> Message-ID: <1369855057.52.0.468760899625.issue18097@psf.upfronthosting.co.za> Changes by R. David Murray : Removed file: http://bugs.python.org/file30415/unnamed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 21:34:08 2013 From: report at bugs.python.org (Eric Snow) Date: Wed, 29 May 2013 19:34:08 +0000 Subject: [issue17449] dev guide appears not to cover the benchmarking suite In-Reply-To: <1363579697.14.0.518781563777.issue17449@psf.upfronthosting.co.za> Message-ID: <1369856048.43.0.642127283413.issue17449@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 21:49:05 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 May 2013 19:49:05 +0000 Subject: [issue18090] dict_contains first argument declared register, and shouldn't be In-Reply-To: <1369792194.1.0.0166087183245.issue18090@psf.upfronthosting.co.za> Message-ID: <1369856945.23.0.96157255656.issue18090@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 21:59:02 2013 From: report at bugs.python.org (Hideaki Takahashi) Date: Wed, 29 May 2013 19:59:02 +0000 Subject: [issue18084] wave.py should use sys.byteorder to determine endianess In-Reply-To: <1369768579.1.0.487057247518.issue18084@psf.upfronthosting.co.za> Message-ID: <1369857542.72.0.133546663125.issue18084@psf.upfronthosting.co.za> Hideaki Takahashi added the comment: Patch updated. Thanks. ---------- Added file: http://bugs.python.org/file30416/18084_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 22:24:34 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 May 2013 20:24:34 +0000 Subject: [issue18090] dict_contains first argument declared register, and shouldn't be In-Reply-To: <1369792194.1.0.0166087183245.issue18090@psf.upfronthosting.co.za> Message-ID: <1369859074.24.0.148356497304.issue18090@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 22:33:58 2013 From: report at bugs.python.org (STINNER Victor) Date: Wed, 29 May 2013 20:33:58 +0000 Subject: [issue1693050] \w not helpful for non-Roman scripts Message-ID: <1369859638.44.0.439395953588.issue1693050@psf.upfronthosting.co.za> STINNER Victor added the comment: Let see Modules/_sre.c: #define SRE_UNI_IS_ALNUM(ch) Py_UNICODE_ISALNUM(ch) #define SRE_UNI_IS_WORD(ch) (SRE_UNI_IS_ALNUM(ch) || (ch) == '_') >>> [ch.isalpha() for ch in '\u0939\u093f\u0928\u094d\u0926\u0940'] [True, False, True, False, True, False] >>> import unicodedata >>> [unicodedata.category(ch) for ch in '\u0939\u093f\u0928\u094d\u0926\u0940'] ['Lo', 'Mc', 'Lo', 'Mn', 'Lo', 'Mc'] So the matching ends at U+093f because its category is a "spacing combining" (Mc), which is part of the Mark category, where the re module expects an alphanumeric character. msg76557: """ Unicode TR#18 defines \w as a shorthand for \p{alpha} \p{gc=Mark} \p{digit} \p{gc=Connector_Punctuation} """ So if we want to respect this standard, the re module needs to be modified to accept other Unicode categories. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 22:36:40 2013 From: report at bugs.python.org (Mark Shannon) Date: Wed, 29 May 2013 20:36:40 +0000 Subject: [issue18090] dict_contains first argument declared register, and shouldn't be In-Reply-To: <1369792194.1.0.0166087183245.issue18090@psf.upfronthosting.co.za> Message-ID: <1369859800.04.0.481254241226.issue18090@psf.upfronthosting.co.za> Mark Shannon added the comment: The register qualifier on the parameter does not alter the calling convention, it determines the storage class of the parameter variable within the function. Having said that I am all in favour in removing any and all "register" declarations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 22:43:22 2013 From: report at bugs.python.org (Larry Hastings) Date: Wed, 29 May 2013 20:43:22 +0000 Subject: [issue18090] dict_contains first argument declared register, and shouldn't be In-Reply-To: <1369792194.1.0.0166087183245.issue18090@psf.upfronthosting.co.za> Message-ID: <1369860202.06.0.8630310716.issue18090@psf.upfronthosting.co.za> Larry Hastings added the comment: > The register qualifier on the parameter does not alter the calling > convention, it determines the storage class of the parameter variable > within the function. You assert that declaring a parameter as "register" instructs the compiler that callers should pass in the argument on the stack, but the function should then copy it to a register? Can you cite a reference? (I admit in advance I can't cite a reference for my assertion that it asks to pass the argument in a register. And we all know the "register" keyword is more or less an unfunny joke to the compiler anyway.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 22:45:22 2013 From: report at bugs.python.org (Roundup Robot) Date: Wed, 29 May 2013 20:45:22 +0000 Subject: [issue18084] wave.py should use sys.byteorder to determine endianess In-Reply-To: <1369768579.1.0.487057247518.issue18084@psf.upfronthosting.co.za> Message-ID: <3bLP7j2FsPzQdB@mail.python.org> Roundup Robot added the comment: New changeset ccffce2dde49 by Serhiy Storchaka in branch 'default': Issue #18084: Use sys.byteorder in wave.py. http://hg.python.org/cpython/rev/ccffce2dde49 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed May 29 23:07:19 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 May 2013 21:07:19 +0000 Subject: [issue18084] wave.py should use sys.byteorder to determine endianess In-Reply-To: <1369768579.1.0.487057247518.issue18084@psf.upfronthosting.co.za> Message-ID: <1369861639.42.0.864002661817.issue18084@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your patch. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 00:02:21 2013 From: report at bugs.python.org (Stefan Krah) Date: Wed, 29 May 2013 22:02:21 +0000 Subject: [issue17247] int and float should detect inconsistent format strings In-Reply-To: <1361312693.56.0.943767612751.issue17247@psf.upfronthosting.co.za> Message-ID: <1369864941.85.0.188720970286.issue17247@psf.upfronthosting.co.za> Stefan Krah added the comment: With this patch float and int should behave like Decimal. It may break existing code that (accidentally) uses both legacy zero padding and explicit alignment. ---------- keywords: +patch stage: needs patch -> patch review versions: -Python 3.3 Added file: http://bugs.python.org/file30417/issue17247.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 00:26:15 2013 From: report at bugs.python.org (Stefan Krah) Date: Wed, 29 May 2013 22:26:15 +0000 Subject: [issue17269] getaddrinfo segfaults on OS X when provided with invalid arguments combinations In-Reply-To: <1361489513.5.0.894275569557.issue17269@psf.upfronthosting.co.za> Message-ID: <1369866375.55.0.896165617621.issue17269@psf.upfronthosting.co.za> Stefan Krah added the comment: Hi, I think this broke the tiger buildbot: http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/6368/steps/test/logs/stdio ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 03:17:48 2013 From: report at bugs.python.org (Ned Deily) Date: Thu, 30 May 2013 01:17:48 +0000 Subject: [issue18098] "Build Applet.app" build fails on OS X 10.8 Message-ID: <1369876668.81.0.148106363969.issue18098@psf.upfronthosting.co.za> New submission from Ned Deily: The Build Applet.app tool for OS X depends on the deprecated EasyDialogs module to interact with the user. EasyDialogs depends on Apple-deprecated Carbon QuickDraw APIs. As of OS X 10.8, the headers for the QuickDraw APIs are no longer supplied with Xcode 4. This means that Build Applet.app can no longer be built on 10.8 unless an earlier version of Xcode and an SDK from an earlier system are used. The Mac/Makefile target "install_BuildApplet" fails with either: ImportError: cannot import name GetNewDialog or AttributeError: 'module' object has no attribute 'GetQDGlobalsScreenBits' depending on whether the interpreter being built supports 32-bit or not. Given that Build Applet.app is already considered deprecated and has been removed in Python 3, it does not seem appropriate to attempt to re-engineer its GUI interface. Instead, the Makefile should just skip building it if EasyDialogs is not available. (Note that the QuickDraw libraries are still being shipped in OS X 10.8, so a "Build Applet.app" built on an older system - such as with the python.org OS X installers - will still run on 10.8. There is no guarantee that will still be true in future versions of OS X.) ---------- assignee: ned.deily components: Build, Macintosh messages: 190333 nosy: ned.deily, ronaldoussoren priority: normal severity: normal stage: needs patch status: open title: "Build Applet.app" build fails on OS X 10.8 versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 03:59:45 2013 From: report at bugs.python.org (Todd Rovito) Date: Thu, 30 May 2013 01:59:45 +0000 Subject: [issue7136] Idle File Menu Option Improvement In-Reply-To: <1255567244.32.0.288243785856.issue7136@psf.upfronthosting.co.za> Message-ID: <1369879185.16.0.613114387159.issue7136@psf.upfronthosting.co.za> Changes by Todd Rovito : ---------- nosy: +Todd.Rovito _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 04:30:09 2013 From: report at bugs.python.org (Todd Rovito) Date: Thu, 30 May 2013 02:30:09 +0000 Subject: [issue7136] Idle File Menu Option Improvement In-Reply-To: <1255567244.32.0.288243785856.issue7136@psf.upfronthosting.co.za> Message-ID: <1369881009.16.0.157404206749.issue7136@psf.upfronthosting.co.za> Todd Rovito added the comment: Roger's patch works but the documentation has changed since he made the patch back in 2011. So I patched the patch and hope this very simple patch will get committed. I will work on a patch for 2.7 next. Today I was teaching a student on how to use Python with IDLE and the student found the existing menu option confusing. I was thrilled a patch already existed and it just needed updated. Thanks! ---------- versions: +Python 3.4 -Python 3.2 Added file: http://bugs.python.org/file30418/7136FileMenuConfusionV23point4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 04:43:17 2013 From: report at bugs.python.org (Todd Rovito) Date: Thu, 30 May 2013 02:43:17 +0000 Subject: [issue7136] Idle File Menu Option Improvement In-Reply-To: <1255567244.32.0.288243785856.issue7136@psf.upfronthosting.co.za> Message-ID: <1369881797.29.0.834936621921.issue7136@psf.upfronthosting.co.za> Todd Rovito added the comment: Same patch but for Python 2.7.5. I just updated the documentation from Roger's excellent patch. ---------- versions: +Python 2.7 Added file: http://bugs.python.org/file30419/7136FileMenuConfusionV22point7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 04:54:37 2013 From: report at bugs.python.org (Ned Deily) Date: Thu, 30 May 2013 02:54:37 +0000 Subject: [issue18098] "Build Applet.app" build fails on OS X 10.8 In-Reply-To: <1369876668.81.0.148106363969.issue18098@psf.upfronthosting.co.za> Message-ID: <1369882477.95.0.159942411182.issue18098@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file30420/issue18098_build_applet.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 06:57:31 2013 From: report at bugs.python.org (Roger Serwy) Date: Thu, 30 May 2013 04:57:31 +0000 Subject: [issue16809] Tk 8.6.0 introduces TypeError. (Tk 8.5.13 works) In-Reply-To: <1356763107.47.0.647000150457.issue16809@psf.upfronthosting.co.za> Message-ID: <1369889851.92.0.755782476668.issue16809@psf.upfronthosting.co.za> Roger Serwy added the comment: The problem I'm encountering is that tk.splitlist() is now being given a Tcl_Obj instead of a "str" type. Since everything is Tcl is a string, explicitly casting a Tcl_Obj to a string seems reasonable. Attached is some proof-of-concept code to work around the issue. Serhiy's patch against 3.4 gives this traceback: [python at saturn 3.4]$ ./python tk_86_error.py 8.6 Traceback (most recent call last): File "tk_86_error.py", line 6, in label.pack_info() File "/home/python/python/3.4/Lib/tkinter/__init__.py", line 1924, in pack_info if value[:1] == '.': TypeError: '_tkinter.Tcl_Obj' object is not subscriptable ---------- stage: patch review -> needs patch Added file: http://bugs.python.org/file30421/tk_86_workaround.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 07:16:13 2013 From: report at bugs.python.org (Roger Serwy) Date: Thu, 30 May 2013 05:16:13 +0000 Subject: [issue7136] Idle File Menu Option Improvement In-Reply-To: <1255567244.32.0.288243785856.issue7136@psf.upfronthosting.co.za> Message-ID: <1369890973.15.0.120476563665.issue7136@psf.upfronthosting.co.za> Roger Serwy added the comment: LGTM. Thanks Todd! ---------- assignee: -> roger.serwy stage: needs patch -> commit review versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 07:35:04 2013 From: report at bugs.python.org (Roger Serwy) Date: Thu, 30 May 2013 05:35:04 +0000 Subject: [issue18052] IDLE 3.3.2 Windows taskbar icon regression In-Reply-To: <1369437693.91.0.216380064498.issue18052@psf.upfronthosting.co.za> Message-ID: <1369892104.83.0.889072369542.issue18052@psf.upfronthosting.co.za> Roger Serwy added the comment: I'm running Win7 64-bit in a VM. The steps for me was to start with a system without any Python version installed. Install 3.3.1 32-bit, and then install 3.3.2 32-bit. IDLE launches with a red Tk icon and pinning it to the task bar does not actually pin IDLE. A reboot does fix the issue, as Terry observed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 07:40:38 2013 From: report at bugs.python.org (paul j3) Date: Thu, 30 May 2013 05:40:38 +0000 Subject: [issue14191] argparse doesn't allow optionals within positionals In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za> Message-ID: <1369892438.91.0.461861579324.issue14191@psf.upfronthosting.co.za> paul j3 added the comment: This is a refinement of the patch with Message188609. In parse_known_intermixed_args, the temporary capture of formatted usage has been put in a try/finally structure. Positionals are now 'deactivated' with action.nargs = SUPPRESS action.default = SUPPRESS To use this, a 'nargs==SUPPRESS' case has been added to the relevant methods. In _get_args_pattern() it acts just like 'nargs=0'. In '_get_values()' it returns 'value=SUPPRESS'. The net effect is that, in take_action(), 'action' is not invoked, and that positional is not added to the namespace. Previously I used nargs=0, which put a [] value in the namespace, which then had to be deleted. I have not added anything about this SUPPRESS option to the documentation (PARSER isn't there either). When the parser uses incompatible features (e.g. REMAINDER), this now raises a TypeError. The effect is similar to giving add_argument incompatible definitions. The 'fallback' that I used earlier can be implemented with a simple 'try/except TypeError'. Other parsing errors go through the usual ArgumentParser.error() method. test_argparse.py has been changed to handle this TypeError. ---------- Added file: http://bugs.python.org/file30422/intermixed.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 07:49:34 2013 From: report at bugs.python.org (Glenn Linderman) Date: Thu, 30 May 2013 05:49:34 +0000 Subject: [issue14191] argparse doesn't allow optionals within positionals In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za> Message-ID: <1369892974.8.0.923885649687.issue14191@psf.upfronthosting.co.za> Glenn Linderman added the comment: These sound like good refinements. You've been thinking. By making the fallback happen externally, it simplifies the implementation of parse_intermixed_args, and forces the application to accept responsibility for calling it with a consistent set of arguments, or calling something else. I like that. I don't really see the fallback as a particularly useful feature, so pushing it outside the stdlib, yet still making it simple to implement for any that do find it to be useful, seems like a good tradeoff. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 08:02:41 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 30 May 2013 06:02:41 +0000 Subject: [issue18093] Move main functions to a separate Programs directory In-Reply-To: <1369828290.2.0.750301008205.issue18093@psf.upfronthosting.co.za> Message-ID: <1369893761.78.0.942825484171.issue18093@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 08:03:31 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 30 May 2013 06:03:31 +0000 Subject: [issue18098] "Build Applet.app" build fails on OS X 10.8 In-Reply-To: <1369876668.81.0.148106363969.issue18098@psf.upfronthosting.co.za> Message-ID: <1369893811.18.0.74802247273.issue18098@psf.upfronthosting.co.za> Ronald Oussoren added the comment: There appears to be an unrelated edit to configure/configure.ac in the patch (moving ARCH_RUN_32BIT to another location), otherwise the patch looks fine. I agree that it isn't worthwhile to try to port EasyDialogs to an API that is available, that's a too large change in a bugfix release and as you mentioned the entire module is gone in py3k. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 08:13:13 2013 From: report at bugs.python.org (Ned Deily) Date: Thu, 30 May 2013 06:13:13 +0000 Subject: [issue18098] "Build Applet.app" build fails on OS X 10.8 In-Reply-To: <1369876668.81.0.148106363969.issue18098@psf.upfronthosting.co.za> Message-ID: <1369894393.13.0.855334279945.issue18098@psf.upfronthosting.co.za> Ned Deily added the comment: Unfortunately, the configure.ac change is not unrelated. It turns out that ARCH_RUN_32BIT has been broken for some time. But it hasn't really mattered up to now where I do really need to force 32-bit mode during the build. Also, the patch isn't quite right for the 10.4 case where LIPO_32BIT_FLAGS is empty. I'll fix it before applying. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 08:16:37 2013 From: report at bugs.python.org (Ned Deily) Date: Thu, 30 May 2013 06:16:37 +0000 Subject: [issue18050] embedded interpreter or virtualenv fails with "ImportError: cannot import name MAXREPEAT" In-Reply-To: <1369417243.06.0.993082490408.issue18050@psf.upfronthosting.co.za> Message-ID: <1369894597.67.0.530949588879.issue18050@psf.upfronthosting.co.za> Ned Deily added the comment: Another report of users being affected by this issue: https://trac.macports.org/ticket/39207 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 08:25:28 2013 From: report at bugs.python.org (Ned Deily) Date: Thu, 30 May 2013 06:25:28 +0000 Subject: [issue18050] embedded interpreter or virtualenv fails with "ImportError: cannot import name MAXREPEAT" In-Reply-To: <1369417243.06.0.993082490408.issue18050@psf.upfronthosting.co.za> Message-ID: <1369895128.22.0.174616649525.issue18050@psf.upfronthosting.co.za> Ned Deily added the comment: Also: http://stackoverflow.com/questions/16301735/importerror-cannot-import-name-maxrepeat-with-cx-freeze ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 08:25:42 2013 From: report at bugs.python.org (zhaoqifa) Date: Thu, 30 May 2013 06:25:42 +0000 Subject: [issue17967] urllib2.open failed to access a url when a perent directory of the url is permission denied In-Reply-To: <1368424209.99.0.52540499369.issue17967@psf.upfronthosting.co.za> Message-ID: <1369895142.95.0.595573530565.issue17967@psf.upfronthosting.co.za> zhaoqifa added the comment: Sorry for replying so late. "1) Will the above change have any security implications." ---It does not seem to me either. "2) On Ubuntu, I am unable to setup a directory based (ACL'ed) anonymous ftp server. The option is either anonymous from ftp root (/) which will map to my operating system folder (/srv/ftp) or non-anonymous. I wonder how your server is configured to allow anonymous from a particular point onwards." ---I configured proftpd like this: DenyAll AllowAll And get message as bellow when login anonymous: lftp perf00:~> cd /home cd: Access failed: 550 /home: No such file or directory lftp perf00:~> cd /home/work cd ok, cwd=/home/work lftp perf00:/home/work> cd /home/work/test cd ok, cwd=/home/work/test lftp perf00:/home/work/test> ls drwxrwxr-x 8 work work 4096 Jun 15 2011 pb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 08:33:52 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 30 May 2013 06:33:52 +0000 Subject: [issue18093] Move main functions to a separate Programs directory In-Reply-To: <1369828290.2.0.750301008205.issue18093@psf.upfronthosting.co.za> Message-ID: <1369895632.35.0.800849755496.issue18093@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 09:08:59 2013 From: report at bugs.python.org (Ned Deily) Date: Thu, 30 May 2013 07:08:59 +0000 Subject: [issue18098] "Build Applet.app" build fails on OS X 10.8 In-Reply-To: <1369876668.81.0.148106363969.issue18098@psf.upfronthosting.co.za> Message-ID: <1369897739.89.0.589537736593.issue18098@psf.upfronthosting.co.za> Changes by Ned Deily : Added file: http://bugs.python.org/file30423/issue985064_plist_validation_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 09:09:11 2013 From: report at bugs.python.org (Ned Deily) Date: Thu, 30 May 2013 07:09:11 +0000 Subject: [issue18098] "Build Applet.app" build fails on OS X 10.8 In-Reply-To: <1369876668.81.0.148106363969.issue18098@psf.upfronthosting.co.za> Message-ID: <1369897751.2.0.1162370359.issue18098@psf.upfronthosting.co.za> Changes by Ned Deily : Removed file: http://bugs.python.org/file30420/issue18098_build_applet.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 09:09:30 2013 From: report at bugs.python.org (Ned Deily) Date: Thu, 30 May 2013 07:09:30 +0000 Subject: [issue18098] "Build Applet.app" build fails on OS X 10.8 In-Reply-To: <1369876668.81.0.148106363969.issue18098@psf.upfronthosting.co.za> Message-ID: <1369897770.19.0.465184487133.issue18098@psf.upfronthosting.co.za> Changes by Ned Deily : Removed file: http://bugs.python.org/file30423/issue985064_plist_validation_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 09:09:45 2013 From: report at bugs.python.org (Ned Deily) Date: Thu, 30 May 2013 07:09:45 +0000 Subject: [issue18098] "Build Applet.app" build fails on OS X 10.8 In-Reply-To: <1369876668.81.0.148106363969.issue18098@psf.upfronthosting.co.za> Message-ID: <1369897785.9.0.537414423944.issue18098@psf.upfronthosting.co.za> Changes by Ned Deily : Added file: http://bugs.python.org/file30424/issue18098_build_applet_rev1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 09:14:59 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 30 May 2013 07:14:59 +0000 Subject: [issue18098] "Build Applet.app" build fails on OS X 10.8 In-Reply-To: <1369876668.81.0.148106363969.issue18098@psf.upfronthosting.co.za> Message-ID: <3bLg6B372Kz7LnC@mail.python.org> Roundup Robot added the comment: New changeset cfdb4598c935 by Ned Deily in branch '2.7': Issue #18098: The deprecated OS X Build Applet.app fails to build on http://hg.python.org/cpython/rev/cfdb4598c935 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 09:16:36 2013 From: report at bugs.python.org (Ned Deily) Date: Thu, 30 May 2013 07:16:36 +0000 Subject: [issue18098] "Build Applet.app" build fails on OS X 10.8 In-Reply-To: <1369876668.81.0.148106363969.issue18098@psf.upfronthosting.co.za> Message-ID: <1369898196.02.0.51141630997.issue18098@psf.upfronthosting.co.za> Ned Deily added the comment: Committed for release in 2.7.6. ---------- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 09:32:37 2013 From: report at bugs.python.org (Ned Deily) Date: Thu, 30 May 2013 07:32:37 +0000 Subject: [issue17269] getaddrinfo segfaults on OS X when provided with invalid arguments combinations In-Reply-To: <1361489513.5.0.894275569557.issue17269@psf.upfronthosting.co.za> Message-ID: <1369899157.48.0.819553446339.issue17269@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +benjamin.peterson, georg.brandl, larry priority: normal -> release blocker resolution: fixed -> stage: committed/rejected -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 10:07:42 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 30 May 2013 08:07:42 +0000 Subject: [issue17269] getaddrinfo segfaults on OS X when provided with invalid arguments combinations In-Reply-To: <1361489513.5.0.894275569557.issue17269@psf.upfronthosting.co.za> Message-ID: <1369901262.05.0.987437179508.issue17269@psf.upfronthosting.co.za> Ronald Oussoren added the comment: That sucks. A patch should be easy, but I probably won't get around to that until sunday. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 10:32:22 2013 From: report at bugs.python.org (Tim Golden) Date: Thu, 30 May 2013 08:32:22 +0000 Subject: [issue18040] SIGINT catching regression on windows in 2.7 In-Reply-To: <1369278066.93.0.310534523814.issue18040@psf.upfronthosting.co.za> Message-ID: <1369902742.33.0.279914743524.issue18040@psf.upfronthosting.co.za> Tim Golden added the comment: Personally, I'm +0 at best on this change. It would achieve consistency with Linux but I'm not sure what you'd do with such functionality. Adding Richard Oudkerk who did the rework of the interrupt signal for 3.3. Richard, any opinion on this? ---------- nosy: +sbt priority: normal -> low stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 10:52:32 2013 From: report at bugs.python.org (Berker Peksag) Date: Thu, 30 May 2013 08:52:32 +0000 Subject: [issue18051] get_python_version undefined in bdist_rpm.py In-Reply-To: <1369425412.53.0.375050257963.issue18051@psf.upfronthosting.co.za> Message-ID: <1369903952.23.0.980459912035.issue18051@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> committed/rejected superseder: -> get_python_version is not import in bdist_rpm.py type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 10:54:06 2013 From: report at bugs.python.org (Berker Peksag) Date: Thu, 30 May 2013 08:54:06 +0000 Subject: [issue18045] get_python_version is not import in bdist_rpm.py In-Reply-To: <1369355842.75.0.290813933305.issue18045@psf.upfronthosting.co.za> Message-ID: <1369904046.85.0.626107549248.issue18045@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> patch review type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 11:36:33 2013 From: report at bugs.python.org (moijes12) Date: Thu, 30 May 2013 09:36:33 +0000 Subject: [issue17375] Add docstrings to methods in the threading module In-Reply-To: <1362648255.88.0.520762515957.issue17375@psf.upfronthosting.co.za> Message-ID: <1369906593.95.0.483967943708.issue17375@psf.upfronthosting.co.za> moijes12 added the comment: Attached is a patch built against Python 3.3. I've taken karlcow's patch and used it for Python 3. I have run the test suite(./python -m test -j3) and the sanity check (make patchcheck) and they worked fine. ---------- nosy: +moijes12 Added file: http://bugs.python.org/file30425/issue-17375-python33.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 11:38:17 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 May 2013 09:38:17 +0000 Subject: [issue18050] embedded interpreter or virtualenv fails with "ImportError: cannot import name MAXREPEAT" In-Reply-To: <1369417243.06.0.993082490408.issue18050@psf.upfronthosting.co.za> Message-ID: <1369906697.55.0.845423062481.issue18050@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I just think that the patch only silences an import error. Is test_re passed with this patch on 32-bit platform with <=2.7.3 static binaries and 2.7.5 py-files? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 12:33:28 2013 From: report at bugs.python.org (Florent Xicluna) Date: Thu, 30 May 2013 10:33:28 +0000 Subject: [issue18099] wsgiref sets Content-Length: 0 on 304 Not Modified Message-ID: <1369910008.93.0.397797975418.issue18099@psf.upfronthosting.co.za> New submission from Florent Xicluna: While testing wsgiref w.r.t RFC2616, I noticed that it sets the Content-Length to 0 when the application returns 304 Not Modified. This is a violation of RFC 2616 section 10.3.5. And the net effect is a weird bug with some browsers (tested with Chrome 27) where the resource is truncated on 304 Not Modified. (the resource was a CSS file in that case) This is loosely related to http://bugs.python.org/issue3839. # How to reproduce: def test_304(): import time from email.utils import formatdate from wsgiref.simple_server import make_server def demo_app(environ, start_response): if 'HTTP_IF_MODIFIED_SINCE' in environ: start_response("304 Not Modified", []) return [] headers = [('Content-Type', 'text/html; charset=utf-8'), ('Last-Modified', formatdate(time.time(), usegmt=True))] start_response("200 OK", headers) return ["Hello World!"] httpd = make_server('127.0.0.1', 8000, demo_app) sa = httpd.socket.getsockname() print("Serving HTTP on %s port %s ..." % sa) httpd.serve_forever() if __name__ == '__main__': test_304() ---------- components: Library (Lib) messages: 190352 nosy: flox, pitrou, pje priority: normal severity: normal status: open title: wsgiref sets Content-Length: 0 on 304 Not Modified type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 12:54:15 2013 From: report at bugs.python.org (Richard Oudkerk) Date: Thu, 30 May 2013 10:54:15 +0000 Subject: [issue18040] SIGINT catching regression on windows in 2.7 In-Reply-To: <1369902742.33.0.279914743524.issue18040@psf.upfronthosting.co.za> Message-ID: <51A72FD0.5070607@gmail.com> Richard Oudkerk added the comment: I am not to familiar with the signal handling machinery. (I only did some refactoring to expose the event handle already used by time.sleep().) The change looks reasonable, but I am also not sure how necessary it is. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 13:49:08 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 30 May 2013 11:49:08 +0000 Subject: [issue18075] Infinite recursion tests triggering a segfault In-Reply-To: <1369702928.42.0.612737848185.issue18075@psf.upfronthosting.co.za> Message-ID: <1369914548.47.0.485567868456.issue18075@psf.upfronthosting.co.za> STINNER Victor added the comment: > Appearently the default maximum stack size isn't large enough for the default value of the recursion limit. Why not changing the recursion limit instead of the size of the stack? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 14:18:35 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 30 May 2013 12:18:35 +0000 Subject: [issue18075] Infinite recursion tests triggering a segfault In-Reply-To: <1369702928.42.0.612737848185.issue18075@psf.upfronthosting.co.za> Message-ID: <1369916315.65.0.514352778634.issue18075@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I'd prefer to keep the default recursion limit the same as on Linux, changing the recursion limit on OSX would just introduce an unnecessary difference between the two platforms. The patch changes the maximum stack size from 8 to 16 MByte, neither of which is huge and shouldn't cause other problems. I'd also like to increase the default stack size for newly created threads (see #18049) and will update that patch to create a 16 MByte stack as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 14:50:20 2013 From: report at bugs.python.org (STINNER Victor) Date: Thu, 30 May 2013 12:50:20 +0000 Subject: [issue18075] Infinite recursion tests triggering a segfault In-Reply-To: <1369916315.65.0.514352778634.issue18075@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > The patch changes the maximum stack size from 8 to 16 MByte, neither of which is huge and shouldn't cause other problems. On Mac OS X: Is the memory allocated at Python startup, or on demand, as the stack grows? If I am correct, the physical memory is allocated on demand on Linux. 2013/5/30 Ronald Oussoren : > > Ronald Oussoren added the comment: > > I'd prefer to keep the default recursion limit the same as on Linux, changing the recursion limit on OSX would just introduce an unnecessary difference between the two platforms. > > The patch changes the maximum stack size from 8 to 16 MByte, neither of which is huge and shouldn't cause other problems. > > I'd also like to increase the default stack size for newly created threads (see #18049) and will update that patch to create a 16 MByte stack as well. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 14:56:22 2013 From: report at bugs.python.org (Tom van Leeuwen) Date: Thu, 30 May 2013 12:56:22 +0000 Subject: [issue18100] socket.sendall() cannot send buffers of 2GB or more Message-ID: <1369918582.13.0.605373457603.issue18100@psf.upfronthosting.co.za> New submission from Tom van Leeuwen: When using socket.sendall() to send a buffer of 2GB or more (for example, numpy.zeros(2*GB, dtype=numpy.uint8) ), it doesn't send anything at all. In socketmodule.c, socket.sendall() sock_sendall uses an int for len, while this should be a Py_ssize_t. ---------- components: Build messages: 190357 nosy: Tom.van.Leeuwen priority: normal severity: normal status: open title: socket.sendall() cannot send buffers of 2GB or more type: behavior versions: Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 15:33:40 2013 From: report at bugs.python.org (Ronald Oussoren) Date: Thu, 30 May 2013 13:33:40 +0000 Subject: [issue18075] Infinite recursion tests triggering a segfault In-Reply-To: Message-ID: <52AE3966-7506-41D9-B302-B65BFD01BB93@mac.com> Ronald Oussoren added the comment: On 30 May, 2013, at 14:50, STINNER Victor wrote: > > STINNER Victor added the comment: > >> The patch changes the maximum stack size from 8 to 16 MByte, neither of which is huge and shouldn't cause other problems. > > On Mac OS X: Is the memory allocated at Python startup, or on demand, > as the stack grows? If I am correct, the physical memory is allocated > on demand on Linux. Memory for the stack is allocated on demand, the parameter sets the maximum size that the stack can grow to. See also man ld(1). Ronald ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 15:59:21 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 May 2013 13:59:21 +0000 Subject: [issue18101] Tk.split() doesn't work with nested Unicode strings Message-ID: <1369922361.42.0.622055843561.issue18101@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Tk.split() doesn't work with nested Unicode strings, but works with nested bytes. >>> import tkinter >>> t = tkinter.Tcl() >>> t.split('a {b c}') ('a', ('b', 'c')) >>> t.split(b'a {b c}') ('a', ('b', 'c')) >>> t.split(('a {b c}',)) ('a {b c}',) >>> t.split((b'a {b c}',)) (('a', ('b', 'c')),) I think this is unintentional. Here is a patch which processes strings inside a tuple as bytes objects. It also adds tests for Tk.splitline() and Tk.split(). ---------- components: Tkinter files: tkinter_split_nested_unicode.patch keywords: patch messages: 190359 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Tk.split() doesn't work with nested Unicode strings type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file30426/tkinter_split_nested_unicode.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 16:08:29 2013 From: report at bugs.python.org (Phil Connell) Date: Thu, 30 May 2013 14:08:29 +0000 Subject: [issue17792] Unhelpful UnboundLocalError due to del'ing of exception target In-Reply-To: <1366329322.51.0.489771554551.issue17792@psf.upfronthosting.co.za> Message-ID: <1369922909.63.0.372860571451.issue17792@psf.upfronthosting.co.za> Changes by Phil Connell : ---------- nosy: +pconnell _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 16:18:21 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 May 2013 14:18:21 +0000 Subject: [issue18101] Tk.split() doesn't work with nested Unicode strings In-Reply-To: <1369922361.42.0.622055843561.issue18101@psf.upfronthosting.co.za> Message-ID: <1369923501.58.0.20916833185.issue18101@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +gpolo, roger.serwy versions: +Python 2.7 Added file: http://bugs.python.org/file30427/tkinter_split_nested_unicode-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 16:22:30 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 May 2013 14:22:30 +0000 Subject: [issue18100] socket.sendall() cannot send buffers of 2GB or more In-Reply-To: <1369918582.13.0.605373457603.issue18100@psf.upfronthosting.co.za> Message-ID: <1369923750.89.0.716924376964.issue18100@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Extension Modules -Build nosy: +pitrou stage: -> needs patch versions: +Python 2.7 -Python 2.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 16:45:33 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 May 2013 14:45:33 +0000 Subject: [issue16809] Tk 8.6.0 introduces TypeError. (Tk 8.5.13 works) In-Reply-To: <1356763107.47.0.647000150457.issue16809@psf.upfronthosting.co.za> Message-ID: <1369925133.29.0.0146444364568.issue16809@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, I considered this option. A sure way to get rid of this and future changes in Tcl types, is get rid of Tcl_Obj at all and always return strings (if it is not a number or list). The drawback of this method is that occurs unnecessary conversion between Tcl and Python types and that information about types is lost. Also it is possible to hamper support for new Tcl types (dict, StateSpec, etc) in future. Another way is much more difficult. We need to allow all Tkinter functions to accept Tcl_Obj. Unfortunately this doesn't solve the problem fully because other code might expect a string instead of Tcl_Obj. We don't have enough test coverage to verify that the changes are sufficient. In any case, there are third-party code, which will also have to change to support the new Tcl versions. ---------- dependencies: +Tk.split() doesn't work with nested Unicode strings _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 16:48:48 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 30 May 2013 14:48:48 +0000 Subject: [issue18100] socket.sendall() cannot send buffers of 2GB or more In-Reply-To: <1369918582.13.0.605373457603.issue18100@psf.upfronthosting.co.za> Message-ID: <1369925328.55.0.211555676007.issue18100@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: "int len = pbuf.len;" Why doesn't gcc emit a warning here? ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 16:50:02 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 May 2013 14:50:02 +0000 Subject: [issue16809] Tk 8.6.0 introduces TypeError. (Tk 8.5.13 works) In-Reply-To: <1356763107.47.0.647000150457.issue16809@psf.upfronthosting.co.za> Message-ID: <1369925402.25.0.125750943889.issue16809@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here are a patch which quickly switch off Tcl_Obj. ---------- Added file: http://bugs.python.org/file30428/tkinter_no_tcl_obj.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 16:53:55 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 May 2013 14:53:55 +0000 Subject: [issue16809] Tk 8.6.0 introduces TypeError. (Tk 8.5.13 works) In-Reply-To: <1356763107.47.0.647000150457.issue16809@psf.upfronthosting.co.za> Message-ID: <1369925635.5.0.399094659418.issue16809@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And here is a patch which allows Tk.splitline() and Tk.split() to work with Tcl_Obj. It also includes some other minor fixes to support Tcl 8.6. The patch includes a fix for issue18101. ---------- Added file: http://bugs.python.org/file30429/tkinter_split.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 16:54:15 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 30 May 2013 14:54:15 +0000 Subject: [issue16809] Tk 8.6.0 introduces TypeError. (Tk 8.5.13 works) In-Reply-To: <1356763107.47.0.647000150457.issue16809@psf.upfronthosting.co.za> Message-ID: <1369925655.71.0.362748608568.issue16809@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file29477/tkinter_splitlist.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 17:25:53 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 30 May 2013 15:25:53 +0000 Subject: [issue18045] get_python_version is not import in bdist_rpm.py In-Reply-To: <1369355842.75.0.290813933305.issue18045@psf.upfronthosting.co.za> Message-ID: <1369927553.83.0.213315820866.issue18045@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks for catching this. I think the patch is incorrect when it replaces ?from sysconfig import get_python_version? by ?from distutils.sysconfig import get_python_version?; it should only add the missing import in bdist_rpm.py, not touch the other modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 17:35:59 2013 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Thu, 30 May 2013 15:35:59 +0000 Subject: [issue18102] except-clause with own exception class inside generator can lead to confusing warning on termination Message-ID: <1369928159.24.0.947067999583.issue18102@psf.upfronthosting.co.za> New submission from Hagen F?rstenau: The following code will sometimes warn about an ignored TypeError('catching classes that do not inherit from BaseException is not allowed',) on termination: class MyException(Exception): pass def gen(): try: yield except MyException: pass g = gen() next(g) Of course, MyException inherits from Exception, so there should be no problem. Apparently, MyException gets destroyed before the generator object (at least sometimes, presumably depending on the hash randomization seed), and the destructor of the generator object then complains because there is no MyException any more. At least that's my explanation of this, without having digged into the code. ---------- components: Interpreter Core messages: 190365 nosy: hagen priority: normal severity: normal status: open title: except-clause with own exception class inside generator can lead to confusing warning on termination type: behavior versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 17:38:51 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 30 May 2013 15:38:51 +0000 Subject: [issue18101] Tk.split() doesn't work with nested Unicode strings In-Reply-To: <1369922361.42.0.622055843561.issue18101@psf.upfronthosting.co.za> Message-ID: <1369928331.64.0.373990621808.issue18101@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 17:40:51 2013 From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=) Date: Thu, 30 May 2013 15:40:51 +0000 Subject: [issue18102] except-clause with own exception class inside generator can lead to confusing warning on termination In-Reply-To: <1369928159.24.0.947067999583.issue18102@psf.upfronthosting.co.za> Message-ID: <1369928451.12.0.202667745179.issue18102@psf.upfronthosting.co.za> Hagen F?rstenau added the comment: s/digged/dug/ :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 17:41:30 2013 From: report at bugs.python.org (R. David Murray) Date: Thu, 30 May 2013 15:41:30 +0000 Subject: [issue18102] except-clause with own exception class inside generator can lead to confusing warning on termination In-Reply-To: <1369928159.24.0.947067999583.issue18102@psf.upfronthosting.co.za> Message-ID: <1369928490.49.0.62519294836.issue18102@psf.upfronthosting.co.za> R. David Murray added the comment: You are almost certainly correct. MyException can get set to None during interpreter shutdown. There are a couple of active issues and a PEP that address this type of problem, so this issue probably isn't needed, but I'll leave that up to Antoine, who is working on it. ---------- nosy: +pitrou, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 17:41:56 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 30 May 2013 15:41:56 +0000 Subject: [issue17792] Unhelpful UnboundLocalError due to del'ing of exception target In-Reply-To: <1366329322.51.0.489771554551.issue17792@psf.upfronthosting.co.za> Message-ID: <1369928516.33.0.270900212795.issue17792@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 17:45:12 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 30 May 2013 15:45:12 +0000 Subject: [issue18090] dict_contains first argument declared register, and shouldn't be In-Reply-To: <1369792194.1.0.0166087183245.issue18090@psf.upfronthosting.co.za> Message-ID: <1369928712.54.0.651757404799.issue18090@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 17:46:48 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 30 May 2013 15:46:48 +0000 Subject: [issue18091] Remove PyNoArgsFunction In-Reply-To: <1369792844.19.0.815911667989.issue18091@psf.upfronthosting.co.za> Message-ID: <1369928808.99.0.0168404891779.issue18091@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 17:49:46 2013 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 30 May 2013 15:49:46 +0000 Subject: [issue18083] _sysconfigdata.py is installed in an arch-independent directory In-Reply-To: <1369758893.79.0.620751759494.issue18083@psf.upfronthosting.co.za> Message-ID: <1369928986.28.0.097835593563.issue18083@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 17:54:11 2013 From: report at bugs.python.org (Dmi Baranov) Date: Thu, 30 May 2013 15:54:11 +0000 Subject: [issue18045] get_python_version is not import in bdist_rpm.py In-Reply-To: <1369355842.75.0.290813933305.issue18045@psf.upfronthosting.co.za> Message-ID: <1369929251.87.0.0950969095775.issue18045@psf.upfronthosting.co.za> Dmi Baranov added the comment: I would agree that the patch is incorrect, if it was produced with additional refactoring or changes in functionality, not described in the issue. It's just a PEP8 compliance at package level. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 17:56:40 2013 From: report at bugs.python.org (Larry Hastings) Date: Thu, 30 May 2013 15:56:40 +0000 Subject: [issue18090] dict_contains first argument declared register, and shouldn't be In-Reply-To: <1369792194.1.0.0166087183245.issue18090@psf.upfronthosting.co.za> Message-ID: <1369929400.08.0.374481481734.issue18090@psf.upfronthosting.co.za> Larry Hastings added the comment: I poked around in a draft of the next ANSI C standard dated April 12 2011. They don't have much to say about the semantics of "register". The definition is found in 6.7.1.6: A declaration of an identi?er for an object with storage-class speci?er "register" suggests that access to the object be as fast as possible. In a footnote they say you can't take the address of something declared "register". In 6.7.6.3.2 they explicitly allow using "register" as part of the specification of a function parameter. However, in 6.9.2 they say "register" cannot appear as part of an external declaration, including those for functions. 6.9.2 is where I stake my claim. If "register" is irrelevant to calling convention, then why would the C standard preclude using it in an external declaration? If it had no effect on the call they wouldn't care. Therefore, declaring a parameter as "register" affects its calling convention. (Or, it would, if "register" actually did anything). Therefore casting a function from using "register" to not using "register" is a bug. Therefore we shouldn't do it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 18:31:09 2013 From: report at bugs.python.org (Dmi Baranov) Date: Thu, 30 May 2013 16:31:09 +0000 Subject: [issue17987] test.support.captured_stderr, captured_stdin not documented In-Reply-To: <1368653423.88.0.898801742943.issue17987@psf.upfronthosting.co.za> Message-ID: <1369931469.46.0.321672729743.issue17987@psf.upfronthosting.co.za> Dmi Baranov added the comment: Amended ---------- Added file: http://bugs.python.org/file30430/issue17987_6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 18:35:41 2013 From: report at bugs.python.org (David Gilman) Date: Thu, 30 May 2013 16:35:41 +0000 Subject: [issue18040] SIGINT catching regression on windows in 2.7 In-Reply-To: <1369278066.93.0.310534523814.issue18040@psf.upfronthosting.co.za> Message-ID: <1369931741.35.0.932669684286.issue18040@psf.upfronthosting.co.za> David Gilman added the comment: So the original motivation here was to piggyback on SIGINT in order to do something like this on Windows: http://stackoverflow.com/questions/132058/showing-the-stack-trace-from-a-running-python-application I've given Tim's patch a shot and I see that I've been barking up the wrong tree. I agree that this one-liner is a kinda invasive change and probably isn't worth putting in a point release. Thanks for the help. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 19:15:45 2013 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 30 May 2013 17:15:45 +0000 Subject: [issue18102] except-clause with own exception class inside generator can lead to confusing warning on termination In-Reply-To: <1369928159.24.0.947067999583.issue18102@psf.upfronthosting.co.za> Message-ID: <1369934145.39.0.690583415667.issue18102@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I will keep this issue alive so that I can check whether it is fixed by further changes. ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 19:44:16 2013 From: report at bugs.python.org (Tim Golden) Date: Thu, 30 May 2013 17:44:16 +0000 Subject: [issue18040] SIGINT catching regression on windows in 2.7 In-Reply-To: <1369278066.93.0.310534523814.issue18040@psf.upfronthosting.co.za> Message-ID: <1369935856.34.0.184075293779.issue18040@psf.upfronthosting.co.za> Tim Golden added the comment: Thanks for the feedback, David. Closing as won't fix. ---------- resolution: -> wont fix stage: patch review -> committed/rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 20:03:34 2013 From: report at bugs.python.org (Stefan Krah) Date: Thu, 30 May 2013 18:03:34 +0000 Subject: [issue18090] dict_contains first argument declared register, and shouldn't be In-Reply-To: <1369792194.1.0.0166087183245.issue18090@psf.upfronthosting.co.za> Message-ID: <1369937014.05.0.46520102477.issue18090@psf.upfronthosting.co.za> Stefan Krah added the comment: +1 for removing all occurrences of "register". Regarding the grammar, we have: function-definition: declaration-specifiers-opt declarator declaration-list-opt compound-statement So I think that "part of an external declaration" refers to the outermost declaration-specifiers, not to some inner declaration-specifiers that are part of the parameter-type-list. Otherwise it would also be forbidden to use "register" in the compound-statement. ;) Thus, IMO this is legal: a) int f (register int x) {return x;} But this is not allowed: b) register int f (int x) {return x;} As Mark said, a) does not alter the calling convention. It's just a request to keep x in a register in the function body once the parameter passing is done. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 20:29:11 2013 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Thu, 30 May 2013 18:29:11 +0000 Subject: [issue18090] dict_contains first argument declared register, and shouldn't be In-Reply-To: <1369792194.1.0.0166087183245.issue18090@psf.upfronthosting.co.za> Message-ID: <1369938551.6.0.186298498827.issue18090@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: > If "register" is irrelevant to calling convention, then why would the C > standard preclude using it in an external declaration? Maybe here "external" is the opposite of "static": "register" is OK in a single translation unit (where the calling convention does not really matter), but not allowed between multiple .c files (which register, anyway?) +1 for removing it. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 20:48:13 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 30 May 2013 18:48:13 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <3bLyV46HWmz7Lrf@mail.python.org> Roundup Robot added the comment: New changeset 93eb15779050 by Terry Jan Reedy in branch '2.7': Issue #15392: Create a unittest framework for IDLE, 2.7 version. http://hg.python.org/cpython/rev/93eb15779050 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 20:49:52 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Thu, 30 May 2013 18:49:52 +0000 Subject: [issue18052] IDLE 3.3.2 Windows taskbar icon regression In-Reply-To: <1369437693.91.0.216380064498.issue18052@psf.upfronthosting.co.za> Message-ID: <1369939792.86.0.490030893696.issue18052@psf.upfronthosting.co.za> Martin v. L?wis added the comment: I can now reproduce it, and asked on SO (http://stackoverflow.com/questions/16843727/) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 21:01:08 2013 From: report at bugs.python.org (Ayank koernia) Date: Thu, 30 May 2013 19:01:08 +0000 Subject: [issue18098] "Build Applet.app" build fails on OS X 10.8 In-Reply-To: <1369876668.81.0.148106363969.issue18098@psf.upfronthosting.co.za> Message-ID: <1369940468.45.0.767242216166.issue18098@psf.upfronthosting.co.za> Changes by Ayank koernia : Added file: http://bugs.python.org/file30431/Tante Girang.uhtml _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 21:02:29 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 30 May 2013 19:02:29 +0000 Subject: [issue18075] Infinite recursion tests triggering a segfault In-Reply-To: <1369702928.42.0.612737848185.issue18075@psf.upfronthosting.co.za> Message-ID: <3bLypX5kwCzQlg@mail.python.org> Roundup Robot added the comment: New changeset b07ad4b5e349 by ?ukasz Langa in branch 'default': Fixed #18075 - Infinite recursion tests triggering a segfault on Mac OS X http://hg.python.org/cpython/rev/b07ad4b5e349 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 21:02:44 2013 From: report at bugs.python.org (Ned Deily) Date: Thu, 30 May 2013 19:02:44 +0000 Subject: [issue18098] "Build Applet.app" build fails on OS X 10.8 In-Reply-To: <1369876668.81.0.148106363969.issue18098@psf.upfronthosting.co.za> Message-ID: <1369940564.0.0.383156013275.issue18098@psf.upfronthosting.co.za> Changes by Ned Deily : Removed file: http://bugs.python.org/file30431/Tante Girang.uhtml _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 21:08:29 2013 From: report at bugs.python.org (Berker Peksag) Date: Thu, 30 May 2013 19:08:29 +0000 Subject: [issue18099] wsgiref sets Content-Length: 0 on 304 Not Modified In-Reply-To: <1369910008.93.0.397797975418.issue18099@psf.upfronthosting.co.za> Message-ID: <1369940909.27.0.871400142714.issue18099@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- versions: -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 21:18:25 2013 From: report at bugs.python.org (Larry Hastings) Date: Thu, 30 May 2013 19:18:25 +0000 Subject: [issue18090] dict_contains first argument declared register, and shouldn't be In-Reply-To: <1369792194.1.0.0166087183245.issue18090@psf.upfronthosting.co.za> Message-ID: <1369941505.43.0.410202690249.issue18090@psf.upfronthosting.co.za> Larry Hastings added the comment: Having re-read the spec a couple times, I am now thoroughly confused and don't know what to think. Certainly I now believe I was previously misinterpreting aspects of the spec. I still think removing "register" from the parameter lists of external functions is a good idea. But smart people work on CPython, particularly on dictobject.c, so I find it easy to believe I'm missing something. If having it there is actually a good idea I'd love to learn why! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 21:22:36 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 30 May 2013 19:22:36 +0000 Subject: [issue18090] dict_contains first argument declared register, and shouldn't be In-Reply-To: <1369792194.1.0.0166087183245.issue18090@psf.upfronthosting.co.za> Message-ID: <1369941756.06.0.668750793702.issue18090@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 21:31:46 2013 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Thu, 30 May 2013 19:31:46 +0000 Subject: [issue18075] Infinite recursion tests triggering a segfault In-Reply-To: <1369702928.42.0.612737848185.issue18075@psf.upfronthosting.co.za> Message-ID: <1369942306.12.0.471658284976.issue18075@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 21:49:14 2013 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 30 May 2013 19:49:14 +0000 Subject: [issue18090] dict_contains first argument declared register, and shouldn't be In-Reply-To: <1369792194.1.0.0166087183245.issue18090@psf.upfronthosting.co.za> Message-ID: <1369943354.48.0.798879537412.issue18090@psf.upfronthosting.co.za> Mark Dickinson added the comment: > +1 for removing all occurrences of "register". Seconded. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 23:06:57 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 30 May 2013 21:06:57 +0000 Subject: [issue18103] Create a GUI test framework for Idle Message-ID: <1369948017.01.0.493052648792.issue18103@psf.upfronthosting.co.za> New submission from Terry J. Reedy: This is a follow-up to #15392, which created the Idle test framework. The similar endpoint for this issue will be a framework for tests that require a gui resource, at least one prototype test file, and documentation of Idle practice. At the moment, completely automated tests that can run on buildbots with a gui, but without human intervention, are a lower priority to me than adding text-only tests. The tkinter test framework should be a starting point, but some things should be modernized, as they were for the basic framework. This means using unittest rather than regrtest. One thing to copy may be to put gui-tests in a separate directory. I presume load_tests() could conditionally load tests in such a directory. It is not clear to me to what extent tk widgets can be created and manipulated without being shown on a screen or needing a 'gui' resource. Idle tests are not intended to test tkinter and tk. A mock_tk could replace at least some gui use. Creating a mock-tk framework would be a different issue from this one. A generic tk mock might possibly go in a tkinter subdirectory. Mocks of Idle classes would belong somewhere below idle_test. As noted in #15392, about 20 idlelib files have primitive non-automated 'main' tests requiring unspecified human action and observation, some of which do not even run. The 'test' is to see whether the action produced the expected response (which one has to know) or to check the appearance of a text or dialog widget. A first step might be to upgrade and semi-automate these instructions with unittests in idle_test/human. Running them all with one documented command or import would be much nicer pleasant than having to discover and run each individually. I might make this a separate sub-issue. ---------- assignee: terry.reedy messages: 190381 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Create a GUI test framework for Idle type: enhancement versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 23:08:03 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 30 May 2013 21:08:03 +0000 Subject: [issue18103] Create a GUI test framework for Idle In-Reply-To: <1369948017.01.0.493052648792.issue18103@psf.upfronthosting.co.za> Message-ID: <1369948083.69.0.758559449617.issue18103@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 23:08:44 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 30 May 2013 21:08:44 +0000 Subject: [issue16226] IDLE crashes on *File / Path browser* In-Reply-To: <1350206279.5.0.670551753566.issue16226@psf.upfronthosting.co.za> Message-ID: <1369948124.21.0.512443067356.issue16226@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Test has been committed on all three branches as part of #15392 ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 23:29:55 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 30 May 2013 21:29:55 +0000 Subject: [issue7883] CallTips.py _find_constructor does not work In-Reply-To: <1265631103.87.0.399117397925.issue7883@psf.upfronthosting.co.za> Message-ID: <1369949395.71.0.950912101931.issue7883@psf.upfronthosting.co.za> Terry J. Reedy added the comment: #12520 deleted _find_constructor in 3.x as it works with, but only with old-style classes (gone in 3.x) and just uses getattr(ob, '__init__', None). I believe the tests in this patch duplicate existing tests at the bottom of CallTips.py (increased from 10 to 30 as part of #12510). I will recheck when I move the existing tests into the new idle_test/test_calltips.py. ---------- versions: +Python 2.7 -Python 3.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 23:32:56 2013 From: report at bugs.python.org (Brian Curtin) Date: Thu, 30 May 2013 21:32:56 +0000 Subject: [issue7883] CallTips.py _find_constructor does not work In-Reply-To: <1265631103.87.0.399117397925.issue7883@psf.upfronthosting.co.za> Message-ID: <1369949576.61.0.836850168366.issue7883@psf.upfronthosting.co.za> Changes by Brian Curtin : ---------- nosy: -brian.curtin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 23:35:36 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 30 May 2013 21:35:36 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1369949736.2.0.0745870571252.issue15392@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Biggest change is no support module in 2.7, so in test_idle.py import inside try:except to skip if dependencies not present. Minor changes in CallTips.py and test_calltips.py. Buildbots are fine. This meets my initial goal; issue done. I opened #18103 for consideration of gui tests. But except for improving the existing no-buildbot, human-needed tests, I consider that a lower priority right now. ---------- resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 23:35:53 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 30 May 2013 21:35:53 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1369949753.73.0.470477482026.issue15392@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 23:36:06 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 30 May 2013 21:36:06 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1369949766.34.0.575055623273.issue15392@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: commit review -> committed/rejected _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu May 30 23:49:01 2013 From: report at bugs.python.org (Ned Deily) Date: Thu, 30 May 2013 21:49:01 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1369950541.39.0.061908800433.issue15392@psf.upfronthosting.co.za> Ned Deily added the comment: The test.support module was renamed in Python 3 from test.test_support in Python 2. While the 3x support has expanded and diverged somewhat, with a bit of try hacking it should be possible to minimize the source differences between the 2.7 and 3.x tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 00:17:27 2013 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 30 May 2013 22:17:27 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <1369952247.4.0.351318476107.issue15392@psf.upfronthosting.co.za> Ezio Melotti added the comment: For the other modules we just use test.test_support on 2.x and test.support in 3.x, without using try/except and without trying to maintain source compatibility with both. You might get a merge conflict every once in a while, but I don't think that's a big deal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 00:25:11 2013 From: report at bugs.python.org (Roundup Robot) Date: Thu, 30 May 2013 22:25:11 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <3bM3JR1CxZz7Ltj@mail.python.org> Roundup Robot added the comment: New changeset 6159916c712e by Terry Jan Reedy in branch '2.7': Issue #15392: Use test.test_support, as used test.support in 3.x. http://hg.python.org/cpython/rev/6159916c712e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 00:31:28 2013 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Thu, 30 May 2013 22:31:28 +0000 Subject: [issue1500504] Alternate RFC 3986 compliant URI parsing module Message-ID: <1369953088.98.0.858834120342.issue1500504@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 02:52:01 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 31 May 2013 00:52:01 +0000 Subject: [issue18104] Idle: make human-mediated GUI tests usable Message-ID: <1369961521.26.0.131640091288.issue18104@psf.upfronthosting.co.za> New submission from Terry J. Reedy: 23 of the 62 idlelib/*.py files have an 'if __name__ ...' test that brings up a tkinter gui widget and waits for the human tester to do ... something. Problems: 0. They are a bit of a nuisance to run individually: either type python -m idlelib.SomeLongNameYoumightMistype or open in an editor and hit F5. Running all is much worse given that I found no list; doing the above with all 62 files to find the 23 is something few would do. 1. About 5 do not run; at least 1 is a simple incomplete 2to3 fix (which means it has never been run with 3.x). I will post separately any that are not obvious. 2. They were written by and for the module authors; some are a puzzle. For example: python -m idlelib.FileList. I do not know what to do to perform the test. 3. About 4 of those that do run do not stop properly, depending on how run. Example: after python -m idlelib.ColorDelegator, the puzzling window (blank on 3.3, not 2.7) seems to close correctly, but open the same file and run with F5 (2.7 or 3.3, Windows) and pressing [x] in the window does nothing. But most do close so this is something different with a few. 4. Even when the test is fairly obvious, (python -m idlelib.MultiStatusBar) there is no way to indicate failure so that an automated record of failures is collected. My overall idea expands on the example of the dialog tests, such as python -m idlelib.aboutDialog Each opens a master test window with a start button that opens a window with the dialog be tested. Make a standardized master window for all tests, add an explanation of what to do (or a button to display it) and buttons to record the result: OK, NothingHappened, or Error (explain in text widget). A test method would set up the explanation and test item, connect both to a master window, run, retrieve result (I have no idea how to do this ;-), and end with AssertTrue(result, explanation). I am thinking to suffix human-only tests with '_H' and put 'test_xyy_H' in a subdirectory such as idle_test/human. Some test files might test several different modules, such as 'test_dialog_H'. ---------- assignee: terry.reedy messages: 190388 nosy: roger.serwy, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle: make human-mediated GUI tests usable type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 02:53:15 2013 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 31 May 2013 00:53:15 +0000 Subject: [issue18103] Create a GUI test framework for Idle In-Reply-To: <1369948017.01.0.493052648792.issue18103@psf.upfronthosting.co.za> Message-ID: <1369961595.8.0.901967949245.issue18103@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I opened #18104 for the human-required gui tests described in the last paragraph above. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 03:06:35 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 31 May 2013 01:06:35 +0000 Subject: [issue15392] Create a unittest framework for IDLE In-Reply-To: <1342673080.97.0.671694156374.issue15392@psf.upfronthosting.co.za> Message-ID: <3bM6tf2XGgz7Lwf@mail.python.org> Roundup Robot added the comment: New changeset 16fea8b0f8c4 by Terry Jan Reedy in branch '3.3': Issue #15392: Finish news entry. http://hg.python.org/cpython/rev/16fea8b0f8c4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 03:17:49 2013 From: report at bugs.python.org (R. David Murray) Date: Fri, 31 May 2013 01:17:49 +0000 Subject: [issue18104] Idle: make human-mediated GUI tests usable In-Reply-To: <1369961521.26.0.131640091288.issue18104@psf.upfronthosting.co.za> Message-ID: <1369963069.53.0.532152533664.issue18104@psf.upfronthosting.co.za> R. David Murray added the comment: Since you *don't* want these to be autodiscovered by testing frameworks, perhaps h_test_xxxx.py would be a better naming scheme. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 08:51:55 2013 From: report at bugs.python.org (Raymond Hettinger) Date: Fri, 31 May 2013 06:51:55 +0000 Subject: [issue18078] threading.Condition to allow notify on a specific waiter In-Reply-To: <1369712419.12.0.434704480843.issue18078@psf.upfronthosting.co.za> Message-ID: <1369983115.92.0.560331604713.issue18078@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 08:54:16 2013 From: report at bugs.python.org (Adam Urban) Date: Fri, 31 May 2013 06:54:16 +0000 Subject: [issue18105] ElementTree writes invalid files when UTF-16 encoding is specified Message-ID: <1369983256.71.0.912927883191.issue18105@psf.upfronthosting.co.za> New submission from Adam Urban: import xml.etree.ElementTree as ET tree = ET.parse("myinput.xml") tree.write("myoutput.xml", encoding="utf-16") ...Output is a garbled mess, often a mix of UTF-8 and UTF-16 bytes... UTF-8 output works fine, but when UTF-16, UTF-16LE, or UTF-16BE are specified the output is mangled. ---------- components: Unicode, XML messages: 190392 nosy: Adam.Urban, ezio.melotti priority: normal severity: normal status: open title: ElementTree writes invalid files when UTF-16 encoding is specified type: behavior versions: 3rd party, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 09:34:58 2013 From: report at bugs.python.org (Bohuslav "Slavek" Kabrda) Date: Fri, 31 May 2013 07:34:58 +0000 Subject: [issue12425] gettext breaks on empty plural-forms value In-Reply-To: <1309246707.61.0.397995745183.issue12425@psf.upfronthosting.co.za> Message-ID: <1369985698.39.0.437863671681.issue12425@psf.upfronthosting.co.za> Changes by Bohuslav "Slavek" Kabrda : ---------- nosy: +bkabrda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 10:13:32 2013 From: report at bugs.python.org (Vajrasky Kok) Date: Fri, 31 May 2013 08:13:32 +0000 Subject: [issue18106] There are unused variables in Lib/test/test_collections.py Message-ID: <1369988012.39.0.245549184475.issue18106@psf.upfronthosting.co.za> New submission from Vajrasky Kok: In two "test_copying" methods in Lib/test/test_collections.py, variable i is never used. My guess is the original test writer forgot to utilize the variable i. For example, in test_copying method in TestOrderedDict class: def test_copying(self): # Check that ordered dicts are copyable, deepcopyable, picklable, # and have a repr/eval round-trip pairs = [('c', 1), ('b', 2), ('a', 3), ('d', 4), ('e', 5), ('f', 6)] od = OrderedDict(pairs) update_test = OrderedDict() update_test.update(od) for i, dup in enumerate([ od.copy(), copy.copy(od), copy.deepcopy(od), pickle.loads(pickle.dumps(od, 0)), pickle.loads(pickle.dumps(od, 1)), pickle.loads(pickle.dumps(od, 2)), pickle.loads(pickle.dumps(od, 3)), pickle.loads(pickle.dumps(od, -1)), eval(repr(od)), update_test, OrderedDict(od), ]): self.assertTrue(dup is not od) self.assertEqual(dup, od) self.assertEqual(list(dup.items()), list(od.items())) self.assertEqual(len(dup), len(od)) self.assertEqual(type(dup), type(od)) The variable i in "for i, dup in enumerate" is never used. The test_copying method in TestCounter class has the same problem. In my opinion, we need to put variable i inside the message in the assert functions to detect which place inside the iteration the test fails. ---------- components: Tests files: test_copying.patch keywords: patch messages: 190393 nosy: vajrasky priority: normal severity: normal status: open title: There are unused variables in Lib/test/test_collections.py versions: Python 3.4 Added file: http://bugs.python.org/file30432/test_copying.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 10:52:01 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 31 May 2013 08:52:01 +0000 Subject: [issue18106] There are unused variables in Lib/test/test_collections.py In-Reply-To: <1369988012.39.0.245549184475.issue18106@psf.upfronthosting.co.za> Message-ID: <1369990321.64.0.897471582582.issue18106@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Perhaps it will be even better to extract loop body as a local function and then call it with different arguments. def check(dup): self.assertTrue(dup is not od) self.assertEqual(dup, od) ... check(od.copy()) check(copy.copy(od)) ... In this case we will see a tested case right in the traceback. ---------- nosy: +ezio.melotti, michael.foord, pitrou, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 11:05:55 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 31 May 2013 09:05:55 +0000 Subject: [issue18105] ElementTree writes invalid files when UTF-16 encoding is specified In-Reply-To: <1369983256.71.0.912927883191.issue18105@psf.upfronthosting.co.za> Message-ID: <1369991155.15.0.769924266241.issue18105@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For 3.3+ it was fixed in issue1767933. ---------- nosy: +eli.bendersky, serhiy.storchaka versions: -3rd party, Python 2.6, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 11:41:45 2013 From: report at bugs.python.org (Cherniavsky Beni) Date: Fri, 31 May 2013 09:41:45 +0000 Subject: [issue10224] Build 3.x documentation using python3.x In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za> Message-ID: <1369993305.57.0.262076810834.issue10224@psf.upfronthosting.co.za> Cherniavsky Beni added the comment: I was only thinking of 3.4, which will have venv and a pip bootstrapper. Is changing the doc build / doctest in scope for minor releases of 3.3 (or even earlier)? The commands I listed (using setup_distribute.py) also work with 3.3. (But they're unsecure -- https://bitbucket.org/tarek/distribute/issue/374/) 3.2 is harder as it doesn't even have builtin venv. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 11:49:53 2013 From: report at bugs.python.org (Armin Rigo) Date: Fri, 31 May 2013 09:49:53 +0000 Subject: [issue18107] 'str(long)' can be made faster Message-ID: <1369993793.36.0.708057511123.issue18107@psf.upfronthosting.co.za> New submission from Armin Rigo: If you have in x some very large number, like 3**200000, then the computation for 'str(x)' is sub-efficient. Nathan Hurst posted to the pypy-dev mailing list a pure Python algo that gives the same result in 2/3rd of the time (in either CPython or PyPy). We would get a similar gain by recoding this algorithm in C. The mail is here: http://mail.python.org/pipermail/pypy-dev/2013-May/011433.html ---------- messages: 190397 nosy: arigo priority: normal severity: normal status: open title: 'str(long)' can be made faster type: performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 12:06:30 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 31 May 2013 10:06:30 +0000 Subject: [issue18107] 'str(long)' can be made faster In-Reply-To: <1369993793.36.0.708057511123.issue18107@psf.upfronthosting.co.za> Message-ID: <1369994790.43.0.775569193161.issue18107@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue3451. ---------- nosy: +mark.dickinson, serhiy.storchaka versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 12:40:51 2013 From: report at bugs.python.org (Vajrasky Kok) Date: Fri, 31 May 2013 10:40:51 +0000 Subject: [issue18106] There are unused variables in Lib/test/test_collections.py In-Reply-To: <1369988012.39.0.245549184475.issue18106@psf.upfronthosting.co.za> Message-ID: <1369996851.34.0.356138234706.issue18106@psf.upfronthosting.co.za> Vajrasky Kok added the comment: According to R. David Murray in Python core-mentorship mailing list addressing me: "It could be that the bug is that the i is not used...it may have been intended to be used in an extended error message in the asserts, so that it would be clear which input failed. In any case, I think the best fix here would probably be to use the new subtests support in unittest." So I used subTest feature in the second patch I upload according to his advice. What do you think? subTest can recognize where the test fails immediately as well. You just have to count the line in the loop. ---------- Added file: http://bugs.python.org/file30433/test_copying_with_subTest.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 12:43:04 2013 From: report at bugs.python.org (Vajrasky Kok) Date: Fri, 31 May 2013 10:43:04 +0000 Subject: [issue18106] There are unused variables in Lib/test/test_collections.py In-Reply-To: <1369988012.39.0.245549184475.issue18106@psf.upfronthosting.co.za> Message-ID: <1369996984.68.0.167251432928.issue18106@psf.upfronthosting.co.za> Vajrasky Kok added the comment: Anyway to make it complete, I upload the patch according to Storchaka's advice too. May the best patch wins! ---------- Added file: http://bugs.python.org/file30434/test_copying_with_def.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 12:49:09 2013 From: report at bugs.python.org (Berker Peksag) Date: Fri, 31 May 2013 10:49:09 +0000 Subject: [issue18039] dbm.open(..., flag="n") does not work and does not give a warning In-Reply-To: <1369269598.14.0.669972141851.issue18039@psf.upfronthosting.co.za> Message-ID: <1369997349.78.0.208602361559.issue18039@psf.upfronthosting.co.za> Berker Peksag added the comment: I can't reproduce it on Windows 7 with Python 3.3.2. Attaching my test script. Here's the output: C:\Python33>python.exe -V Python 3.3.2 C:\Python33>python.exe dbmopen.py bzdew.dat exists? True bzdew.dir exists? True b'hello' b'there' Could you run it and paste here the output? ---------- nosy: +berker.peksag stage: -> test needed Added file: http://bugs.python.org/file30435/dbmopen.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 13:52:30 2013 From: report at bugs.python.org (Terje Wiesener) Date: Fri, 31 May 2013 11:52:30 +0000 Subject: [issue744841] Python-Profiler bug: Bad call Message-ID: <1370001150.73.0.333418148453.issue744841@psf.upfronthosting.co.za> Terje Wiesener added the comment: This bug seems to have resurfaced in newer python versions. I have tested the file attached in the original report (prof2.py) in python 2.6.6 and 2.7 (x86 versions) under Windows 7, and both give the same output: c:\temp>c:\Python27\python.exe prof2.py Exception AssertionError: AssertionError('Bad call', ('prof2.py', 19, 'h'), , , , ) in < bound method C.__del__ of <__main__.C instance at 0x02342A80>> ignored 5 function calls in 0.007 CPU seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 1 0.000 0.000 0.007 0.007 :1() 1 0.001 0.001 0.001 0.001 prof2.py:11(g) 1 0.006 0.006 0.007 0.007 prof2.py:19(h) 1 0.000 0.000 0.000 0.000 prof2.py:7(f) 1 0.000 0.000 0.007 0.007 profile:0(h()) 0 0.000 0.000 profile:0(profiler) ---------- nosy: +Terje.Wiesener type: -> performance versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 13:53:14 2013 From: report at bugs.python.org (Sashko Kopyl) Date: Fri, 31 May 2013 11:53:14 +0000 Subject: [issue18039] dbm.open(..., flag="n") does not work and does not give a warning In-Reply-To: <1369269598.14.0.669972141851.issue18039@psf.upfronthosting.co.za> Message-ID: <1370001194.13.0.191223951295.issue18039@psf.upfronthosting.co.za> Sashko Kopyl added the comment: Here is the output. *** Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit (Intel)] on win32. *** *** Remote Python engine is active *** >>> *** Remote Interpreter Reinitialized *** >>> yoqaA.dat exists? True yoqaA.dir exists? True b'hello' b'there' >>> I would like to focus your attention, that flag "n" creates a database, but does not overwrite it once it is created. So in Windows case there is no difference between "c" and "n" flag. You can have a look at this link where it was originally discussed. http://stackoverflow.com/questions/16647131/how-to-empty-dbm-file-in-python-efficiently ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 15:09:57 2013 From: report at bugs.python.org (Colin Watson) Date: Fri, 31 May 2013 13:09:57 +0000 Subject: [issue18108] shutil.chown should support dir_fd and follow_symlinks keyword arguments Message-ID: <1370005797.04.0.715885093574.issue18108@psf.upfronthosting.co.za> New submission from Colin Watson: Python 3.3 added the dir_fd and follow_symlinks keyword arguments to os.chown; it also added the shutil.chown function. Unfortunately the latter, while useful, does not support these new keyword arguments. It would be helpful if it did. ---------- components: Library (Lib) messages: 190404 nosy: cjwatson priority: normal severity: normal status: open title: shutil.chown should support dir_fd and follow_symlinks keyword arguments versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 15:49:48 2013 From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=) Date: Fri, 31 May 2013 13:49:48 +0000 Subject: [issue15239] Abandoned Tools/unicode/mkstringprep.py In-Reply-To: <1341164174.42.0.994750295138.issue15239@psf.upfronthosting.co.za> Message-ID: <1370008188.4.0.844195554418.issue15239@psf.upfronthosting.co.za> Martin v. L?wis added the comment: Ok, these patches all look fine. Thanks for your effort. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 16:21:29 2013 From: report at bugs.python.org (Armin Rigo) Date: Fri, 31 May 2013 14:21:29 +0000 Subject: [issue18107] 'str(long)' can be made faster In-Reply-To: <1369993793.36.0.708057511123.issue18107@psf.upfronthosting.co.za> Message-ID: <1370010089.74.0.197274666336.issue18107@psf.upfronthosting.co.za> Armin Rigo added the comment: Thanks, I missed it. Sorry for the noise. ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 17:05:07 2013 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 31 May 2013 15:05:07 +0000 Subject: [issue3451] Asymptotically faster divmod and str(long) In-Reply-To: <1217121065.64.0.642253571203.issue3451@psf.upfronthosting.co.za> Message-ID: <1370012707.47.0.100703371005.issue3451@psf.upfronthosting.co.za> Eric V. Smith added the comment: See also issue18107, in particular http://mail.python.org/pipermail/pypy-dev/2013-May/011433.html. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 17:52:04 2013 From: report at bugs.python.org (Zachary Ware) Date: Fri, 31 May 2013 15:52:04 +0000 Subject: [issue18093] Move main functions to a separate Programs directory In-Reply-To: <1369828290.2.0.750301008205.issue18093@psf.upfronthosting.co.za> Message-ID: <1370015524.89.0.410619335013.issue18093@psf.upfronthosting.co.za> Zachary Ware added the comment: I can confirm that the patch doesn't break building on Windows. Would it make any sense to move Windows-specific sources for things like kill_python.exe (PCbuild/kill_python.c), make_buildinfo.exe, make_versioninfo.exe, py.exe (PC/launcher.c) into Programs? Or better to keep them in PC or PCbuild (at least for now, until after this patch is approved)? ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 18:16:41 2013 From: report at bugs.python.org (Zachary Ware) Date: Fri, 31 May 2013 16:16:41 +0000 Subject: [issue18094] Skip tests in test_uuid not silently In-Reply-To: <1369830000.95.0.179404474041.issue18094@psf.upfronthosting.co.za> Message-ID: <1370017001.79.0.857742163043.issue18094@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 18:25:06 2013 From: report at bugs.python.org (Todd Rovito) Date: Fri, 31 May 2013 16:25:06 +0000 Subject: [issue18103] Create a GUI test framework for Idle In-Reply-To: <1369948017.01.0.493052648792.issue18103@psf.upfronthosting.co.za> Message-ID: <1370017506.64.0.138726592119.issue18103@psf.upfronthosting.co.za> Changes by Todd Rovito : ---------- nosy: +Todd.Rovito _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 18:26:13 2013 From: report at bugs.python.org (Todd Rovito) Date: Fri, 31 May 2013 16:26:13 +0000 Subject: [issue18104] Idle: make human-mediated GUI tests usable In-Reply-To: <1369961521.26.0.131640091288.issue18104@psf.upfronthosting.co.za> Message-ID: <1370017573.37.0.729298124325.issue18104@psf.upfronthosting.co.za> Changes by Todd Rovito : ---------- nosy: +Todd.Rovito _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 18:28:16 2013 From: report at bugs.python.org (Hynek Schlawack) Date: Fri, 31 May 2013 16:28:16 +0000 Subject: [issue18108] shutil.chown should support dir_fd and follow_symlinks keyword arguments In-Reply-To: <1370005797.04.0.715885093574.issue18108@psf.upfronthosting.co.za> Message-ID: <1370017696.32.0.904166119587.issue18108@psf.upfronthosting.co.za> Changes by Hynek Schlawack : ---------- nosy: +hynek versions: +Python 3.4 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 20:53:36 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 31 May 2013 18:53:36 +0000 Subject: [issue18066] Remove SGI-specific code from pty.py In-Reply-To: <1369571537.69.0.0137495343006.issue18066@psf.upfronthosting.co.za> Message-ID: <1370026416.19.0.561186877429.issue18066@psf.upfronthosting.co.za> ?ric Araujo added the comment: LGTM. ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 20:56:25 2013 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 31 May 2013 18:56:25 +0000 Subject: [issue18094] Skip tests in test_uuid not silently In-Reply-To: <1369830000.95.0.179404474041.issue18094@psf.upfronthosting.co.za> Message-ID: <1370026585.94.0.610144987423.issue18094@psf.upfronthosting.co.za> ?ric Araujo added the comment: +1 ---------- nosy: +eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 21:35:33 2013 From: report at bugs.python.org (Roundup Robot) Date: Fri, 31 May 2013 19:35:33 +0000 Subject: [issue18094] Skip tests in test_uuid not silently In-Reply-To: <1369830000.95.0.179404474041.issue18094@psf.upfronthosting.co.za> Message-ID: <3bMbVD6bYFzNGX@mail.python.org> Roundup Robot added the comment: New changeset 81c02d2c830d by Serhiy Storchaka in branch '3.3': Issue #18094: test_uuid no more reports skipped tests as passed. http://hg.python.org/cpython/rev/81c02d2c830d New changeset ebd11a19d830 by Serhiy Storchaka in branch 'default': Issue #18094: test_uuid no more reports skipped tests as passed. http://hg.python.org/cpython/rev/ebd11a19d830 New changeset 6ceb5bf24da8 by Serhiy Storchaka in branch '2.7': Issue #18094: test_uuid no more reports skipped tests as passed. http://hg.python.org/cpython/rev/6ceb5bf24da8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 21:45:38 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 31 May 2013 19:45:38 +0000 Subject: [issue18094] Skip tests in test_uuid not silently In-Reply-To: <1369830000.95.0.179404474041.issue18094@psf.upfronthosting.co.za> Message-ID: <1370029538.64.0.6252077307.issue18094@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 21:50:59 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 31 May 2013 19:50:59 +0000 Subject: [issue15239] Abandoned Tools/unicode/mkstringprep.py In-Reply-To: <1341164174.42.0.994750295138.issue15239@psf.upfronthosting.co.za> Message-ID: <1370029859.09.0.59501571888.issue15239@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for review. Should we regenerate Lib/stringprep.py now? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 21:58:40 2013 From: report at bugs.python.org (Dominik Richter) Date: Fri, 31 May 2013 19:58:40 +0000 Subject: [issue18109] os.uname() crashes if hostname contains non-ascii characters Message-ID: <1370030320.3.0.429673365201.issue18109@psf.upfronthosting.co.za> New submission from Dominik Richter: To reproduce (tested on Arch Linux, python 3.3.2): sudo hostname h?t python -c "import os; os.uname()" produces: Traceback (most recent call last): File "", line 1, in UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128) ---------- components: Unicode messages: 190413 nosy: Dominik.Richter, ezio.melotti priority: normal severity: normal status: open title: os.uname() crashes if hostname contains non-ascii characters type: crash versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 22:20:01 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 31 May 2013 20:20:01 +0000 Subject: [issue18085] Verifying refcounts.dat In-Reply-To: <1369768958.38.0.697954786488.issue18085@psf.upfronthosting.co.za> Message-ID: <1370031601.84.0.0718585665567.issue18085@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Since creating refcounts.dat many functions changed their argument's types from `char*` to `const char*`. Here is a patch which fixes mismatches (perhaps not all). refcounts.dat in 3.x contains PyInt_* functions which don't exist in 3.x. ---------- keywords: +patch Added file: http://bugs.python.org/file30436/refcounts_const_char.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 22:22:50 2013 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 31 May 2013 20:22:50 +0000 Subject: [issue18048] Merging test_pep263.py and test_coding.py In-Reply-To: <1369387812.98.0.236232283698.issue18048@psf.upfronthosting.co.za> Message-ID: <1370031770.57.0.0473121078419.issue18048@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +easy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 23:03:36 2013 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Fri, 31 May 2013 21:03:36 +0000 Subject: [issue18109] os.uname() crashes if hostname contains non-ascii characters In-Reply-To: <1370030320.3.0.429673365201.issue18109@psf.upfronthosting.co.za> Message-ID: <1370034216.7.0.190785180484.issue18109@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : ---------- type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 23:45:03 2013 From: report at bugs.python.org (STINNER Victor) Date: Fri, 31 May 2013 21:45:03 +0000 Subject: [issue18109] os.uname() crashes if hostname contains non-ascii characters In-Reply-To: <1370030320.3.0.429673365201.issue18109@psf.upfronthosting.co.za> Message-ID: <1370036703.52.0.136677899949.issue18109@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm unable to set an non-ASCII hostname on Fedora 18 (Linux kernel 3.9.2): $ sudo hostname h?t hostname: the specified hostname is invalid ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 23:48:55 2013 From: report at bugs.python.org (STINNER Victor) Date: Fri, 31 May 2013 21:48:55 +0000 Subject: [issue18109] os.uname() crashes if hostname contains non-ascii characters In-Reply-To: <1370030320.3.0.429673365201.issue18109@psf.upfronthosting.co.za> Message-ID: <1370036935.18.0.616348867092.issue18109@psf.upfronthosting.co.za> STINNER Victor added the comment: See also issue #9377 (similar issue with the socket module). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 23:54:32 2013 From: report at bugs.python.org (Dmi Baranov) Date: Fri, 31 May 2013 21:54:32 +0000 Subject: [issue18109] os.uname() crashes if hostname contains non-ascii characters In-Reply-To: <1370030320.3.0.429673365201.issue18109@psf.upfronthosting.co.za> Message-ID: <1370037272.64.0.482900525632.issue18109@psf.upfronthosting.co.za> Dmi Baranov added the comment: I just checked RFC952 [1] and RFC1123 [2], that host name is incorrect. I think, you need report to Arch Linux bug-tracker. $ sudo hostname h?t hostname: the specified hostname is invalid $ uname -a Linux d9frog9n-desktop 3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26 [1] http://tools.ietf.org/html/rfc952 [2] http://tools.ietf.org/html/rfc1123 ---------- nosy: +dmi.baranov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri May 31 23:57:01 2013 From: report at bugs.python.org (Dmi Baranov) Date: Fri, 31 May 2013 21:57:01 +0000 Subject: [issue18109] os.uname() crashes if hostname contains non-ascii characters In-Reply-To: <1370030320.3.0.429673365201.issue18109@psf.upfronthosting.co.za> Message-ID: <1370037421.02.0.817216891642.issue18109@psf.upfronthosting.co.za> Dmi Baranov added the comment: /offtop Dumn, sorry for duplication here, Victor. We not having websockets here, my page not refreshed. ---------- _______________________________________ Python tracker _______________________________________