From report at bugs.python.org Tue Sep 1 00:12:03 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 31 Aug 2015 22:12:03 +0000 Subject: [issue24973] CFLAGS for Visual Studio In-Reply-To: <1441053291.88.0.612352181445.issue24973@psf.upfronthosting.co.za> Message-ID: <1441059123.86.0.484726720235.issue24973@psf.upfronthosting.co.za> Steve Dower added the comment: I assume you're referring to #24974? The default (for MSVC) is /fp:precise, which should allow fenv_access, but maybe ICL uses /fp:fast by default for the extra speed? It's not a safe 3.5 change now, but compiling with /fp:fast by default and using #pragma float_control(precise, push)/#pragma float_control(pop) around that section may be an option for 3.6, if the benchmarks show some value in it. Either way, the pragma is probably the better way to require particular behaviour for that section of code, rather than changing a global option. I'm not totally opposed to allowing an extra option for setting flags when building, but there'll almost always be a better fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 00:12:18 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 31 Aug 2015 22:12:18 +0000 Subject: [issue24974] ICC on Windows 8.1: _decimal fails to compile without /fp:strict In-Reply-To: <1441057022.82.0.924513920263.issue24974@psf.upfronthosting.co.za> Message-ID: <1441059138.62.0.506542284905.issue24974@psf.upfronthosting.co.za> Steve Dower added the comment: It should be defaulting to precise mode, but maybe ICC has a different default? I wrote on #24973: It's not a safe 3.5 change now, but compiling with /fp:fast by default and using #pragma float_control(precise, push)/#pragma float_control(pop) around that section may be an option for 3.6, if the benchmarks show some value in it. Either way, the pragma is probably the better way to require particular behaviour for that section of code, rather than changing a global option. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 00:34:33 2015 From: report at bugs.python.org (=?utf-8?q?Roberto_S=C3=A1nchez?=) Date: Mon, 31 Aug 2015 22:34:33 +0000 Subject: [issue24966] shutil.get_terminal_size() throws ValueError if stdout is detached, no fallback In-Reply-To: <1440975553.42.0.716947211383.issue24966@psf.upfronthosting.co.za> Message-ID: <1441060473.57.0.203570541561.issue24966@psf.upfronthosting.co.za> Roberto S?nchez added the comment: I totally agree, on the other hand, if the detach() method can cause that some core methods like shutil.get_termina_size() raise an exception then I think that should be warned in the doc of detach(). In all places that I've seen, the detach() method is used to overwrite the stdout in py3, so a sort of advice about the using of detach() It'd save some problems. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 00:36:06 2015 From: report at bugs.python.org (Matheus Vieira Portela) Date: Mon, 31 Aug 2015 22:36:06 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> Message-ID: <1441060566.16.0.709227780404.issue23406@psf.upfronthosting.co.za> Matheus Vieira Portela added the comment: Does anyone else think the note should be expanded? For me, it seems to be pretty accurate although it may indeed be confusing to beginners. If anything, I can work on rewriting it to be more explanatory. ---------- nosy: +matheus.v.portela _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 01:03:57 2015 From: report at bugs.python.org (Matheus Vieira Portela) Date: Mon, 31 Aug 2015 23:03:57 +0000 Subject: [issue18697] Unify arguments names in Unicode object C API documentation In-Reply-To: <1376074126.58.0.40251146149.issue18697@psf.upfronthosting.co.za> Message-ID: <1441062237.08.0.285887042101.issue18697@psf.upfronthosting.co.za> Matheus Vieira Portela added the comment: Just checking, it would be required to update Objects/unicodeobject.c, Include/unicodeobject.h, and Doc/c-api/unicode.rst, right? As far as I saw, "unicode" means a Python object with unicode string, "u" is a UTF-8 encoded C string, "str" and "s" are encoded C strings (UTF-8, UTF-7, ASCII, Latin-1, among others). Is it alright to rename Python unicode objects to "unicode" and the others to simply "str"? These names are more meaningful than the single character alternatives. The same logic would be applied to the other types, always keeping the longer name rather than the single character ones. ---------- nosy: +matheus.v.portela _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 01:49:33 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Mon, 31 Aug 2015 23:49:33 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441064973.26.0.861760351152.issue24912@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Actually, I fail at grep, and actually there are already tons of good tests for __bases__ assignment in test_descr.py. So, patch attached, and analysis follows. Background on __class__ assignment ---------------------------------- While it's certainly surprising, assignment to obj.__class__ and to type.__bases__ has been an explicitly supported feature ever since the advent of new-style classes back in 2.ancient, and typeobject.c goes to great lengths to handle all the weird resulting cases (including stuff like "what if __del__ changes the __class__", "what if someone mutates __bases__ while we are in the middle of method lookup inside a metaclass's mro() method", etc.). To make this safe, of course, we need to somehow check that after making the assignment then the resulting object will still be a valid, self-consistent Python object. The types in question need to have consistent in-memory representations, that their __dict__ slot (if present) is at the same offset, that their memory management callbacks are consistent (if we mutate an object from type A to type B, then A and B must be written in such a way that it's legal to pass an object allocated with A.tp_new to B.tp_dealloc), etc. This compatibility checking occurs in two places: object_set_class and type_set_bases (and several utility functions that they share). For historical reasons, there are two different C representations for type objects in Python: the original representation, which involves statically-allocated structs, and the newer representation, which involves heap-allocated structs. Aside from their allocation, there are a bunch of arcane little differences in things like reference counting, how you set them, etc., which are mostly motivated by the need to maintain compatibility with old code using the original representation -- all the places where they differ are places where the newer representation does something more sensible, it's not possible to create a statically-allocated type except by writing C code that *doesn't* use the stable ABI, etc. Otherwise they're supposed to work the same (eliminating differences between built-in and user-defined classes was the whole point of new-style classes!), but all these quirky implementation differences do leak out into little semantic differences in various places. One of the places where they've historically leaked out is in __class__ and __bases__ assignment. When the compatibility-checking code for types was originally written, it punted on trying to handle the quirky differences between statically-allocated and heap-allocated type objects, and just declared that all statically-allocated types were incompatible with each other. The previous patch ------------------ The patch that is causing all the debate here was reviewed in issue22986, after extensive discussion on python-dev, and the actual diff can be seen here: https://hg.python.org/cpython/rev/c0d25de5919e/ It did two things: 1) It cleaned up a bunch of nasty stuff in the compatibility-checking and assignment code. This fixed some real bugs (e.g., a case where incompatible classes could be considered compatible based on the contents of random memory found by following bogus pointers), and in the process made it robust enough to handle all types, both statically-allocated and heap-allocated. 2) It removed the check in object_set_class that protected the downstream code from ever seeing statically-allocated types - that's the 'if' check here: https://hg.python.org/cpython/rev/c0d25de5919e/#l3.97 As far as we know, this is all working exactly as designed! For example, Serhiy's int subclass at the beginning of the thread is compatible with the int class in the sense that the modified version of the '42' object is still a valid Python object, all its fields are valid, it won't crash the interpreter when deallocated, etc. But of course what we didn't think of is that the interpreter assumes that instances of some particular built-in types are truly immutable, and the interpreter's internal invariants are violated if you can in any way modify an 'int' object in place. Doh. This new patch -------------- So the attached patch modifies the original patch by leaving the cleanups in place, but puts back a guard in object_set_class that disallows __class__ assignment for statically-allocated types EXCEPT that it still allows it specifically in the case of ModuleType subclasses. It also adds a big comment explaining the purpose of the check, and adds tests to make sure that __class__ assignment is disallowed for builtin immutable types. Analysis of the mergeability of this patch: - We still believe that the actual compatibility checking code is strictly better than it used to be, so in any case where these parts of the changes affect Python's semantics, the new results should be better (i.e. less likely to break memory safety and crash the interpreter). - The new guard added by this patch is conservative, but allows a strict superset of what 3.4 and earlier allowed, so it won't break any existing code. - The one way that the proposed new guard is less conservative than the one in 3.4 is that the new one allows ModuleType objects through. Since we believe that the compatibility-checking code is now correct for statically-allocated types, this should be fine from a memory-safety point of view, and because the interpreter definitely does not assume that ModuleType objects are immutable, then this should be safe from that perspective as well. Larry also asked for a "regression test that tried mutating fields on a bunch of interned objects". I'm not sure which fields he was thinking of in particular, but the only entry points that lead to code touched by the original patch are attempts to set __class__ or to set __bases__. *__bases__assignment has always been illegal on statically-allocated types, and has remained illegal through all of these patches*, plus it already has a bunch of tests, so I left it alone. This patch adds tests for __class__ assignment on all the potentially-interned types that I could think of. So..... I think that covers all the bases about what this patch is and why it is appropriate for 3.5.0 (assuming that Larry sticks with treating this as a release-critical bug). I'll post a follow-up with replies to a few specific side comments that people made. ---------- keywords: +patch Added file: http://bugs.python.org/file40310/issue24912.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 01:56:33 2015 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 31 Aug 2015 23:56:33 +0000 Subject: [issue22555] Tracking issue for adjustments to binary/text boundary handling In-Reply-To: <1412481703.35.0.528069461639.issue22555@psf.upfronthosting.co.za> Message-ID: <1441065393.55.0.967706633401.issue22555@psf.upfronthosting.co.za> Nick Coghlan added the comment: For historical purposes, also linking the change in issue #19977 to enable surrogateescape by default on stdin and stdout when the OS claims the locale encoding is ASCII. ---------- dependencies: +Use "surrogateescape" error handler for sys.stdin and sys.stdout on UNIX for the C locale _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 02:03:33 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 01 Sep 2015 00:03:33 +0000 Subject: [issue23993] Use surrogateescape error handler by default in open() if the LC_CTYPE locale is C at startup In-Reply-To: <1429349151.1.0.641370404.issue23993@psf.upfronthosting.co.za> Message-ID: <1441065813.84.0.702401764005.issue23993@psf.upfronthosting.co.za> Nick Coghlan added the comment: I found this discussion again while looking for issue #19977 to reference from issue #24968. "fixed" wasn't the right resolution, so I've moved it to "postponed" - the SSH locale forwarding problem highlighted again in #24968 means I think there's a discussion worth having about reading /etc/locale/conf when it's available, rather than always trusting the glibc locale settings. ---------- resolution: fixed -> postponed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 02:05:15 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 01 Sep 2015 00:05:15 +0000 Subject: [issue24968] Python 3 raises Unicode errors with the xxx.UTF-8 locale In-Reply-To: <1441010532.08.0.980251874816.issue24968@psf.upfronthosting.co.za> Message-ID: <1441065915.56.0.452897619697.issue24968@psf.upfronthosting.co.za> Nick Coghlan added the comment: Looking again at the *specific* bug report here, I'm moving the resolution to "out of date", as it's actually the one we addressed in 3.5 by enabling surrogateescape by default on all of the standard streams when the OS claims the locale encoding is ASCII, not just stderr: http://bugs.python.org/issue19977 That allows us to at least correctly roundtrip data, even if the OS has given has bad encoding settings. The problem with forcing UTF-8 more generally when the OS claims ASCII is that it may be the wrong thing to do and result in data corruption, especially on systems using East Asian codecs. Querying /etc/locale.conf [1] instead of relying on the nominal glibc locale settings should reliably give us correct encoding/locale information on modern Linux systems in cases like this one, where SSH has forwarded mismatched locale settings from a client system to a server shell session. Another issue with relevant background discussion is issue #23993, which speculated on extending the "default to surrogateescape" idea to all open() calls when glibc claims the locale encoding is ASCII. [1] http://www.freedesktop.org/software/systemd/man/locale.conf.html ---------- resolution: not a bug -> out of date _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 03:13:16 2015 From: report at bugs.python.org (David Beazley) Date: Tue, 01 Sep 2015 01:13:16 +0000 Subject: [issue24975] Python 3.5 can't compile AST involving PEP 448 unpacking Message-ID: <1441069996.63.0.493747155256.issue24975@psf.upfronthosting.co.za> New submission from David Beazley: The compile() function is not able to compile an AST created from code that uses some of the new unpacking generalizations in PEP 448. Example: code = ''' a = { 'x':1, 'y':2 } b = { **a, 'z': 3 } ''' # Works ccode = compile(code, '', 'exec') # Crashes import ast tree = ast.parse(code) ccode = compile(tree, '', 'exec') # ---------------------------------- Error Traceback: Traceback (most recent call last): File "bug.py", line 11, in ccode = compile(tree, '', 'exec') ValueError: None disallowed in expression list Note: This bug makes it impossible to try generalized unpacking examples interactively in IPython. ---------- components: Library (Lib) messages: 249442 nosy: dabeaz priority: normal severity: normal status: open title: Python 3.5 can't compile AST involving PEP 448 unpacking type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 03:42:35 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 01 Sep 2015 01:42:35 +0000 Subject: [issue24966] shutil.get_terminal_size() throws ValueError if stdout is detached, no fallback In-Reply-To: <1440975553.42.0.716947211383.issue24966@psf.upfronthosting.co.za> Message-ID: <1441071755.92.0.693456578211.issue24966@psf.upfronthosting.co.za> R. David Murray added the comment: "After the raw stream is detached, the buffer is in an unusable state" pretty much says everything that needs to be said, doesn't it? It certainly seems like anything more does not belong in the detach docs. A mention could possibly be added to the sys.stdin/etc docs, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 03:49:14 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 01 Sep 2015 01:49:14 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> Message-ID: <1441072154.45.0.657513007767.issue23406@psf.upfronthosting.co.za> R. David Murray added the comment: Interesting. I usually start with a project's FAQ because I find they usually give me an overview of the project and an indication of its quality :) The footnote looks very explanatory to me already (complete with examples). The 'confusing to beginners' text could be made a link to the FAQ, though. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 04:14:49 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 01 Sep 2015 02:14:49 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1441060566.16.0.709227780404.issue23406@psf.upfronthosting.co.za> Message-ID: <20150901021154.GC19373@ando.pearwood.info> Steven D'Aprano added the comment: Which note are you referring to? There are at least two mentioned in this thread, the FAQ and a footnote in the docs for stdtypes. If you're referring to the table of operations just below these: https://docs.python.org/2/library/stdtypes.html#sequence-types-str-unicode-list-tuple-bytearray-buffer-xrange https://docs.python.org/3/library/stdtypes.html#common-sequence-operations where the docs say: s * n, n * s n shallow copies of s concatenated I think that could be worded better. It is too easy to misread it as saying that the items of s are copied (as I just did now, despite knowing that they aren't). I would word it: repeat s n times and concatenate which matches the common name of * as the sequence repetition operator, and avoids using the word prone to misinterpretation, "copy". Given how error-prone sequence repetition is, I'd add an example directly in the table: for example, [x]*3 returns [x, x, x] (note that x is not copied). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 04:38:47 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Tue, 01 Sep 2015 02:38:47 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441075127.27.0.543356626649.issue24912@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Mark Shannon wrote: > So, just make sure that you insert the new object into sys.modules *before* doing any imports or calls to code that could import your module and it will all work fine. The problem with doing this is that you're now stuck managing two diverging namespaces: the one associated with your new object that other modules can see, and the one where your __init__.py code is doing all those imports and calls. So if you want this to work then you have to totally rewrite your package's startup sequence, OR you have to insert some code like sys.modules[__name__].__dict__.update(orig_module.__dict__) after *every line* of your __init__.py, OR you have to do some really complicated global analysis of every module inside your package to figure out exactly what the state of these two namespaces is at each possible point during the startup sequence and prove that the divergences don't matter... The key feature of the metamodule approach is that sys.modules["modname"].__dict__ is always the same object as your __init__.py globals(), so there's no change of divergence and it can guarantee that merely enabling metamodule for an existing package will always be safe and have no behavioural effect (until you start using the new metamodule features). This guarantee is hugely important given that the first user will probably be numpy, which is a giant crufty package with millions of users. I promise, we went over all of this on python-dev last year :-) Mark Lemburg wrote: > Python code will generally assume that it can trust > builtin types. It doesn't expect 42 + 2 to clear out the root dir, > just because some package installed from PyPI happens to feel in the > mood for Easter eggs :-) The only reason that'd be possible though is because you went and ran some untrusted code with permissions allowing it to clear out the root dir -- the only way to set up this "exploit" is to run untrusted Python code. Basically you've handed someone a gun, and now you're worried because this patch gives them a new and particularly rube-goldbergian method for pulling the trigger... Except it isn't even a new method; your nasty PyPI package can trivially implement this "easter egg" using only fully-supported features from the stdlib, in any version of Python since 2.5. Here's some nice portable code to do __class__ assignment while dodging *all* the checks in object_set_class: from ctypes import * def set_class(obj, new_class): ob_type_offset = object.__basicsize__ - sizeof(c_void_p) c_void_p.from_address(id(obj) + ob_type_offset).value = id(new_class) I mean, obviously ctypes is nasty and breaks the rules, I'm not saying this justifies making __class__ assignment broken as well. But this bug is no more a *security* problem than the existence of ctypes is. Larry Hasting wrote: > Consider for a moment Google App Engine. If GAE updated to 3.5 with this bug, users would now have the ability to inject code into other people's programs, because interned ints (and a couple other types) are shared across interpreters. Okay, fair enough :-). On GAE this *would* be a security bug because GAE I guess runs an extensively modified and audited fork of Python that implements a full sandbox. I assume this is also why it took them ~2 years to upgrade to 2.7, and why they're shipping 3 year old versions of all their libraries, and why they're now starting to move people to a new setup using OS-level sandboxing instead of interpreter-level sandboxing... Python.org doesn't provide any sandbox guarantees, and this bug is a tiny drop in the bucket compared to what anyone will need to do to add a trustworthy sandbox to CPython 3.5, so for me I still wouldn't call this release critical. But you're the RM, so here's a patch if you want it :-). Serhiy Storchaka wrote; > I'm not sure that allowing __class__ assignment for larger domain of types is desirable. If we will desire that it is not, any enhancements to __class__ assignment should be withdrawn. May be __class__ assignment should be discouraged, deprecated and then disabled for all classes (in 3.6+), and other ways should be proposed to solve problems that are solved with __class__ assignment. I don't necessarily object to the idea of eventually removing __class__ assignment in some future version of Python. It kind of freaks me out too. (Though Guido seems to like it.) I really, really, REALLY object to the idea of -- at this point in the release cycle! -- rejecting a new feature that has gone through review on python-dev, that solves a real problem that's impacting a bunch of people (see all the replies on the numpy-discussion thread linked above of people saying "oh ugh yes this has totally bitten me! please fix it!"), and to do this on the grounds that someone *might* later make an argument for it be removed again in 3.7 and that python-dev might eventually agree with that argument? I mean, c'mon. If it were breaking everything, then that would be grounds for removing it, no question there. But the problems described in this bug report are well understood, and it's trivial to fix them in a conservative way without backing out the original feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 04:50:29 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 01 Sep 2015 02:50:29 +0000 Subject: [issue24969] functools.lru_cache: a way to set decorator arguments at runtime In-Reply-To: <1441036040.75.0.88592797115.issue24969@psf.upfronthosting.co.za> Message-ID: <1441075829.93.0.539806542535.issue24969@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger nosy: +rhettinger versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 04:57:05 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 01 Sep 2015 02:57:05 +0000 Subject: [issue24969] functools.lru_cache: a way to set decorator arguments at runtime In-Reply-To: <1441036040.75.0.88592797115.issue24969@psf.upfronthosting.co.za> Message-ID: <1441076225.24.0.396567365368.issue24969@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > The problem is I can't know the optimal values for 'maxsize', > I need to set them at runtime. The easiest way to go is to wait to start caching until you know the cache size you want: def foo(a, b, c): pass size = get_user_request() foo = lru_cache(foo, maxsize=size) If there is a subsequent need to change the cache size, just rewrap it: size = get_user_request() original_function = foo.__wrapped__ foo = lru_cache(foo, maxsize=size) ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 05:04:02 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 01 Sep 2015 03:04:02 +0000 Subject: [issue24975] Python 3.5 can't compile AST involving PEP 448 unpacking In-Reply-To: <1441069996.63.0.493747155256.issue24975@psf.upfronthosting.co.za> Message-ID: <1441076642.59.0.121757785869.issue24975@psf.upfronthosting.co.za> Yury Selivanov added the comment: Good find, David. Thanks! Please review the attached patch. ---------- keywords: +patch nosy: +benjamin.peterson, larry, ncoghlan, serhiy.storchaka, yselivanov priority: normal -> release blocker stage: -> patch review versions: +Python 3.6 Added file: http://bugs.python.org/file40311/issue24975.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 05:08:33 2015 From: report at bugs.python.org (Matheus Vieira Portela) Date: Tue, 01 Sep 2015 03:08:33 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> Message-ID: <1441076913.22.0.24475614441.issue23406@psf.upfronthosting.co.za> Matheus Vieira Portela added the comment: I was referring to the table of operations. So, what if I replace "n shallow copies of s concatenated" by "repeat s n times and concatenate (to create a multidimensional list, refer to [link to FAQ])"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 05:18:15 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Tue, 01 Sep 2015 03:18:15 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441077495.62.0.287839188367.issue24912@psf.upfronthosting.co.za> Nathaniel Smith added the comment: On further thought, here's a slightly improved version of the patch I posted above. The difference is that the first version allowed through attempted __class__ assignments where either the old or new class was a subclass of ModuleType; the new version only allows through attempted assignments if both the old AND new class are a subclass of ModuleType. In practice this doesn't make any difference, because the compatibility-checking code will reject any attempt to switch from a ModuleType subclass to a non ModuleType subclass or vice-versa. So both patches are correct. But the new patch is more obviously correct. ---------- Added file: http://bugs.python.org/file40312/issue24912-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 06:01:54 2015 From: report at bugs.python.org (Larry Hastings) Date: Tue, 01 Sep 2015 04:01:54 +0000 Subject: [issue24975] Python 3.5 can't compile AST involving PEP 448 unpacking In-Reply-To: <1441069996.63.0.493747155256.issue24975@psf.upfronthosting.co.za> Message-ID: <1441080114.46.0.631969941687.issue24975@psf.upfronthosting.co.za> Larry Hastings added the comment: Good catch! Please file a pull request via bitbucket. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 07:14:28 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 01 Sep 2015 05:14:28 +0000 Subject: [issue24975] Python 3.5 can't compile AST involving PEP 448 unpacking In-Reply-To: <1441069996.63.0.493747155256.issue24975@psf.upfronthosting.co.za> Message-ID: <1441084468.61.0.596601539436.issue24975@psf.upfronthosting.co.za> Nick Coghlan added the comment: Patch looks good to me. I was initially going to query the changes to the break/continue AST tests, but then realised they were needed to avoid a compile error for break/continue outside a loop now that we ensure the resulting AST can be used to generate code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 07:21:12 2015 From: report at bugs.python.org (Zachary Ware) Date: Tue, 01 Sep 2015 05:21:12 +0000 Subject: [issue24973] CFLAGS for Visual Studio In-Reply-To: <1441053291.88.0.612352181445.issue24973@psf.upfronthosting.co.za> Message-ID: <1441084872.39.0.196022887206.issue24973@psf.upfronthosting.co.za> Zachary Ware added the comment: Steve Dower wrote: > I assume you're referring to #24974? It's somewhat related, yes, but I didn't intend for the two issues to be tightly coupled. Both should be dealt with independently of each other. > The default (for MSVC) is /fp:precise, which should allow > fenv_access, but maybe ICL uses /fp:fast by default for the extra > speed? I believe that's correct. > I'm not totally opposed to allowing an extra option for setting flags > when building, but there'll almost always be a better fix. That's probably true. I will say though that it's really hard to pass build options to a buildbot. I have yet to find a way to pass properties with no spaces in the value, for example, "/p:IncludeSSL=false" (if you know of a way to pass that to MSBuild correctly through Tools/buildbot/build.bat called by 2.7's subprocess module, I'm all ears :)). To continue the floating point example, the only method (other than this) I've found to pass in a different model is to hack in another property to check and set FloatingPointModel in the ClCompile ItemDefinitionGroup, which has the same problem as the 'IncludeSSL' issue I mentioned above. With a nice simple 'CFLAGS' property that doesn't care about extra spaces in the value, it becomes possible to pass '/fp:strict' to a buildbot easily. Also, ICC has *a lot* of extra command line options that may be interesting to pass in, but I'm quite sure we don't want to hack any of them into the project files. By the way, '/fp:strict' is just what we've been manually defaulting to for ICC builds since before issue21167 was committed, which made '/fp:strict' unnecessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 07:21:52 2015 From: report at bugs.python.org (Zachary Ware) Date: Tue, 01 Sep 2015 05:21:52 +0000 Subject: [issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model In-Reply-To: <1441057022.82.0.924513920263.issue24974@psf.upfronthosting.co.za> Message-ID: <1441084912.53.0.545802439241.issue24974@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +christopher.hogan title: ICC on Windows 8.1: _decimal fails to compile without /fp:strict -> ICC on Windows 8.1: _decimal fails to compile with default fp model _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 07:42:46 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 01 Sep 2015 05:42:46 +0000 Subject: [issue24829] Use interactive input even if stdout is redirected In-Reply-To: <1439045336.84.0.292650421837.issue24829@psf.upfronthosting.co.za> Message-ID: <1441086166.24.0.930209521189.issue24829@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I recommend this feature request be rejected. The current behavior has been in place for a long time. Changing it may cause more harm than good (especially if the behavior between operating systems becomes more divergent). ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 07:46:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 01 Sep 2015 05:46:08 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441086368.81.0.842372911256.issue24912@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The first time this bug was discovered in issue23726. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 07:47:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 01 Sep 2015 05:47:20 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441086440.44.0.507631605925.issue24912@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +eltoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 07:57:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 01 Sep 2015 05:57:01 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441087021.0.0.686004202756.issue24912@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What if just add settable __class__ property in ModuleType? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 08:41:56 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Tue, 01 Sep 2015 06:41:56 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441089716.95.0.302989264153.issue24912@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Doh, apparently I did once know about issue23726 and then forgot. Good catch. Technically we could add a __class__ field to ModuleType directly, but I think then the ModuleType __class__ setter would basically need to be an exact reimplementation of everything that object_set_class already does? (Since it would still need to check that this particular ModuleType subclass was layout-compatible etc. -- e.g. no new __slots__.) And the end result would behave identically to the patch I just posted, except we'd replace a 2 line check in typeobject.c with some really complicated and bug-prone code in moduleobject.c? I don't think it buys us anything. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 08:49:42 2015 From: report at bugs.python.org (Andrew) Date: Tue, 01 Sep 2015 06:49:42 +0000 Subject: [issue24976] Arithmetic/precision bug when using floating-point numbers Message-ID: <1441090182.8.0.683864424738.issue24976@psf.upfronthosting.co.za> New submission from Andrew: I just recently discovered this bug, but when adding or subtracting a number and a precision error occurs when using at least 1 floating-point number in the operation. For example, 1 - 0.98 should output 0.02, but instead outputs 0..020000000000000018 (at least on my machine). Included is a simple script showing what happens, just when incrementing or decrementing by 0.01 from 0 to 1. I am running Python 3.4.3 on a 64-bit Arch Linux machine. ---------- components: Interpreter Core files: weirdpythonbug.py messages: 249458 nosy: videogames4all priority: normal severity: normal status: open title: Arithmetic/precision bug when using floating-point numbers type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file40313/weirdpythonbug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 08:51:59 2015 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 01 Sep 2015 06:51:59 +0000 Subject: [issue24976] Arithmetic/precision bug when using floating-point numbers In-Reply-To: <1441090182.8.0.683864424738.issue24976@psf.upfronthosting.co.za> Message-ID: <1441090319.19.0.249280764198.issue24976@psf.upfronthosting.co.za> Ezio Melotti added the comment: Thanks for the report, however this is not a Python bug. See: https://docs.python.org/3/tutorial/floatingpoint.html ---------- nosy: +ezio.melotti resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 08:55:35 2015 From: report at bugs.python.org (Francis Greaves) Date: Tue, 01 Sep 2015 06:55:35 +0000 Subject: [issue24971] os.environ.get() does not return the Environment Value in Linux In-Reply-To: <1441041563.63.0.554338723199.issue24971@psf.upfronthosting.co.za> Message-ID: <1441090535.17.0.529044753022.issue24971@psf.upfronthosting.co.za> Francis Greaves added the comment: OK, David, so what have I done wrong to not export it correctly? in my .bashrc I have this export XRIT_DECOMPRESS_PATH="/usr/local/bin/xRITDecompress" so I would expect it to work. Can you please clarify? Many thanks ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 08:57:59 2015 From: report at bugs.python.org (Francis Greaves) Date: Tue, 01 Sep 2015 06:57:59 +0000 Subject: [issue24971] os.environ.get() does not return the Environment Value in Linux In-Reply-To: <1441041563.63.0.554338723199.issue24971@psf.upfronthosting.co.za> Message-ID: <1441090679.22.0.204498997147.issue24971@psf.upfronthosting.co.za> Francis Greaves added the comment: Well since posting the last item it is now working correctly!!!! Thank you for your help ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 09:18:24 2015 From: report at bugs.python.org (=?utf-8?q?Roberto_S=C3=A1nchez?=) Date: Tue, 01 Sep 2015 07:18:24 +0000 Subject: [issue24966] shutil.get_terminal_size() throws ValueError if stdout is detached, no fallback In-Reply-To: <1440975553.42.0.716947211383.issue24966@psf.upfronthosting.co.za> Message-ID: <1441091904.52.0.00893607992873.issue24966@psf.upfronthosting.co.za> Roberto S?nchez added the comment: Yeah, sorry, actually I was thinking in the stdin/out section, the detach() doc itself is Ok, the problem comes when is called in stdin/out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 09:33:41 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 01 Sep 2015 07:33:41 +0000 Subject: [issue24934] django_v2 benchmark not working in Python 3.6 In-Reply-To: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za> Message-ID: <1441092821.92.0.151085300926.issue24934@psf.upfronthosting.co.za> Berker Peksag added the comment: I just downloaded Django-1.8.zip (florin.papa, 2015-08-27 11:49) and opened Django-1.8/django/__init__.py to check the Django version: VERSION = (1, 9, 0, 'alpha', 0) I think GitHub lets you download the master branch by default. I'd suggest to download the source release of Django 1.8.4 at https://pypi.python.org/pypi/Django/1.8.4 ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 09:47:23 2015 From: report at bugs.python.org (=?utf-8?q?Roberto_S=C3=A1nchez?=) Date: Tue, 01 Sep 2015 07:47:23 +0000 Subject: [issue24968] Python 3 raises Unicode errors with the xxx.UTF-8 locale In-Reply-To: <1441010532.08.0.980251874816.issue24968@psf.upfronthosting.co.za> Message-ID: <1441093643.74.0.530569235633.issue24968@psf.upfronthosting.co.za> Roberto S?nchez added the comment: Ok, that makes sense, besides David pointed me about another opened issue that could help to solve cases like this: http://bugs.python.org/issue15216 If the encoding is wrong because the environment but we can change the initial stream encodings (in stdin/out) easily we have a powerful tool to adapt our scripts and patch broken locales like the generated with SSH sessions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 09:48:05 2015 From: report at bugs.python.org (flying sheep) Date: Tue, 01 Sep 2015 07:48:05 +0000 Subject: [issue7175] Define a standard location and API for configuration files In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za> Message-ID: <1441093685.23.0.681738495054.issue7175@psf.upfronthosting.co.za> flying sheep added the comment: no, sorry, but ~/.python is wrong on linux. there exists a standard about where things belong: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html it says that configuration stuff belongs into `XDG_CONFIG_HOME`, with a fallback to `~/.config/` i propose to add the `appdirs` module to the stdlib so that programs finally don?t have to guess and hack around this kind of things. https://pypi.python.org/pypi/appdirs ---------- nosy: +flying sheep _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 10:03:01 2015 From: report at bugs.python.org (Florin Papa) Date: Tue, 01 Sep 2015 08:03:01 +0000 Subject: [issue24934] django_v2 benchmark not working in Python 3.6 In-Reply-To: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za> Message-ID: <1441094581.01.0.93936405181.issue24934@psf.upfronthosting.co.za> Florin Papa added the comment: Please download Django from their github website: https://github.com/django/django I checked and their latest stable release - Django 1.8.4 - from https://pypi.python.org/pypi/Django still has the getargspec issue. Apparently the github version is 1.9.0 alpha. I have modified the patch and archive accordingly. ---------- Added file: http://bugs.python.org/file40314/django_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 10:03:21 2015 From: report at bugs.python.org (Florin Papa) Date: Tue, 01 Sep 2015 08:03:21 +0000 Subject: [issue24934] django_v2 benchmark not working in Python 3.6 In-Reply-To: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za> Message-ID: <1441094601.4.0.390379502011.issue24934@psf.upfronthosting.co.za> Changes by Florin Papa : Added file: http://bugs.python.org/file40315/Django-1.9.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 10:16:59 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 01 Sep 2015 08:16:59 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1441075127.27.0.543356626649.issue24912@psf.upfronthosting.co.za> Message-ID: <55E55EED.70100@egenix.com> Marc-Andre Lemburg added the comment: On 01.09.2015 04:38, Nathaniel Smith wrote: > Mark Lemburg wrote: >> Python code will generally assume that it can trust >> builtin types. It doesn't expect 42 + 2 to clear out the root dir, >> just because some package installed from PyPI happens to feel in the >> mood for Easter eggs :-) > > The only reason that'd be possible though is because you went and ran some untrusted code with permissions allowing it to clear out the root dir -- the only way to set up this "exploit" is to run untrusted Python code. Basically you've handed someone a gun, and now you're worried because this patch gives them a new and particularly rube-goldbergian method for pulling the trigger... I think you're being overly optimistic here. People run unchecked and unverified code all the time; that's not the same as untrusted, since trust develops with time and doesn't get reset with each new package release. Regardless, the above was only an example. The much more likely thing to happen is that some code replaces the .__class__ of some unrelated object by accident via a bug and causes all hell to break loose. > Except it isn't even a new method; your nasty PyPI package can trivially implement this "easter egg" using only fully-supported features from the stdlib, in any version of Python since 2.5. Here's some nice portable code to do __class__ assignment while dodging *all* the checks in object_set_class: > > from ctypes import * > def set_class(obj, new_class): > ob_type_offset = object.__basicsize__ - sizeof(c_void_p) > c_void_p.from_address(id(obj) + ob_type_offset).value = id(new_class) > > I mean, obviously ctypes is nasty and breaks the rules, I'm not saying this justifies making __class__ assignment broken as well. But this bug is no more a *security* problem than the existence of ctypes is. You can disable ctypes easily. OTOH, your patch is inherently changing the language and making it less secure. There's no way to disable it or even prevent using it from inside Python. IMO, that's a huge difference. I also believe that the overall approach is wrong: if you want to add a feature to Python module objects, please stick to those instead of changing the overall interpreter semantics. Some more background: Replacing .__class__ of class instances is a known and useful Python feature. However, in the past this was only possible for regular instances, not for types. With new style classes, this differentiation got blurred and in Python 3 we only have new style classes, so it may look like we always wanted this feature to be available. Yet, I'm not sure whether this was ever intended, or a conscious design decision and because it creates serious problems for the interpreter, it definitely needs go through a PEP process first to make everyone aware of the consequences. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 10:30:45 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 01 Sep 2015 08:30:45 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441096245.29.0.994077940962.issue24912@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Guido, do you have any thoughts on this? Several of us (me included) think http://hg.python.org/lookup/c0d25de5919e probably should not have been done. Mutating non-heap types crosses an implicit boundary that we've long resisted crossing because it opens a can worms and has potential to violate our expectations about how the language works. [Mark Shannon] > Breaking the interpreter in order to facilitate some obscure use case is unacceptable. [Marc-Andre Lemburg] I agree with Mark. This feature opens up a security hole large enough to drive a train through. [Benjamin Peterson] Probably the patch on that bug should be reverted. [Larry Hastings] As Python 3.5 Release Manager, my official statement is: Eek! ---------- assignee: -> Guido.van.Rossum nosy: +Guido.van.Rossum, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 10:37:12 2015 From: report at bugs.python.org (=?utf-8?q?Adam_Barto=C5=A1?=) Date: Tue, 01 Sep 2015 08:37:12 +0000 Subject: [issue24829] Use interactive input even if stdout is redirected In-Reply-To: <1439045336.84.0.292650421837.issue24829@psf.upfronthosting.co.za> Message-ID: <1441096632.12.0.743119620502.issue24829@psf.upfronthosting.co.za> Adam Barto? added the comment: How about reconsidering in the case that the machinery around PyOS_Readline is rewritten as I suggest in #17620 ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 11:14:42 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Tue, 01 Sep 2015 09:14:42 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441098882.48.0.721270196643.issue24912@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Thanks Raymond. Hi Guido. Sorry about the mess. My overview of the situation so far, and of the patch currently attached to this bug, is here (and a bit in the next post): https://bugs.python.org/issue24912#msg249438 >From where I sit this all looks like a massive overreaction/misunderstanding: I introduced a bug, the cause is obvious, and it's straightforward to fix. If we want to fix the bug in the most general manner then that's straightforward but probably more work than we want to do in rc3. If we want to just apply a conservative fix and move on then we have an 8 line patch attached to this bug that does that. Even if we don't apply the patch then there's no security hole, that's just factually incorrect. But it doesn't even matter, because again, we have a patch. If we do apply this patch, then literally the only outcome of all of this will be that __class__ assignment in 3.5 will be (1) less buggy in general, and (2) be allowed, safely, on instances of ModuleType subclasses. I get that the whole concept of __class__ assignment is kinda freaky and unnerving, but I do not understand why some people are insisting that the above needs a PEP... You know, in fact, note to everyone: I hereby withdraw any suggestion that we might want to "fix" the __class__ assignment code to handle the general case beyond ModuleType. Obviously this is super controversial and distracting for reasons I don't really understand, but I don't have to -- the only reason to brought it up in the first place is out of a vague desire to make Python "better", and frankly all I care about at this point is that I don't want to wait another 2 years before I can safely deprecate module-level constants. So let's just apply the attached patch and move on? Nothing broken, no security hole, nothing to eek about. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 11:23:02 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 01 Sep 2015 09:23:02 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441099382.45.0.63201586821.issue24912@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > From where I sit this all looks like a massive > overreaction/misunderstanding: I introduced a bug, the cause is > obvious, and it's straightforward to fix. I agree with Nathaniel here. Let's just commit the fix instead of acting like irrational beings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 11:24:13 2015 From: report at bugs.python.org (Florian Bruhin) Date: Tue, 01 Sep 2015 09:24:13 +0000 Subject: [issue24946] Tkinter tests that fail on linux in tiling window manager In-Reply-To: <1440693856.91.0.458235687359.issue24946@psf.upfronthosting.co.za> Message-ID: <1441099453.89.0.714575494915.issue24946@psf.upfronthosting.co.za> Florian Bruhin added the comment: At least with my WM, there is no concept of having floating windows when in tiling mode, so I don't think that would be possible. I also don't think there's a standard way to tell a window manager to not tile windows. What about opening a simple window with a fixed geometry, checking if this was changed by the WM, and if it is, skip those tests? ---------- nosy: +The Compiler _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 11:25:19 2015 From: report at bugs.python.org (Florian Bruhin) Date: Tue, 01 Sep 2015 09:25:19 +0000 Subject: [issue24946] Tkinter tests that fail on linux in tiling window manager In-Reply-To: <1440693856.91.0.458235687359.issue24946@psf.upfronthosting.co.za> Message-ID: <1441099519.17.0.413616533249.issue24946@psf.upfronthosting.co.za> Changes by Florian Bruhin : ---------- nosy: -The-Compiler _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 11:41:41 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 01 Sep 2015 09:41:41 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441100501.53.0.463001267421.issue24912@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: FWIW: I still think that allowing to change .__class__ on instances of static types if wrong and should be undone. If we want to make this a feature of the language we should have a PEP and the associated discussion to be able to judge and document the possible consequences of such a change. This ticket is the wrong place for such a discussion. Regarding you module object change: Why don't you propose a change on the object itself instead of trying to monkey patch it via a mod.__class__ replacement ? E.g. by defining a hook in the object to set which then permits whatever modification you'd like to make. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 13:26:57 2015 From: report at bugs.python.org (Jake Howard) Date: Tue, 01 Sep 2015 11:26:57 +0000 Subject: [issue24977] shutil copy to non-existant directory Message-ID: <1441106817.15.0.872685605647.issue24977@psf.upfronthosting.co.za> New submission from Jake Howard: If you try and copy a file using shutil.copy to a directory that doesnt exist, it tries to copy the file to the location of the directory, and errors as shutil can't open a directory for 'WB' access, throwing an error, that doesnt reflect the problem. ---------- messages: 249474 nosy: TheOrangeOne priority: normal severity: normal status: open title: shutil copy to non-existant directory type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 13:30:07 2015 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 01 Sep 2015 11:30:07 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1441107007.03.0.549249072928.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: Fixed validate_exprs bug. ---------- Added file: http://bugs.python.org/file40316/pep-498-1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 13:51:13 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 01 Sep 2015 11:51:13 +0000 Subject: [issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model In-Reply-To: <1441057022.82.0.924513920263.issue24974@psf.upfronthosting.co.za> Message-ID: <1441108273.32.0.0335487913463.issue24974@psf.upfronthosting.co.za> Stefan Krah added the comment: On Linux ICC has something like "fast-math" by default. The situation is a bit annoying: On Unix ICC defines __GNUC__, but does not really have all the features. Here ICC defines _MSC_VER, but does not behave like cl.exe. [I know it's a hard problem to be fully compatible, so I'm not blaming the authors.] What happens if you take the C99 path (starting in mpdecimal.c:48)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 14:03:21 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 01 Sep 2015 12:03:21 +0000 Subject: [issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model In-Reply-To: <1441057022.82.0.924513920263.issue24974@psf.upfronthosting.co.za> Message-ID: <1441109001.35.0.147795985667.issue24974@psf.upfronthosting.co.za> Stefan Krah added the comment: Steve: What do you mean by "global option"? The C99 standard says that FENV_ACCESS (if set), is active until the end of the translation unit (here: mpdecimal.c). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 14:04:07 2015 From: report at bugs.python.org (Eugene) Date: Tue, 01 Sep 2015 12:04:07 +0000 Subject: [issue24978] Contributing to Python 2x and 3x Documentation. Translation to Russian. Message-ID: <1441109047.57.0.29993860249.issue24978@psf.upfronthosting.co.za> New submission from Eugene: I am very much begging pardon if this is not the place to ask for, but.. I would like to make a thorough translation of the official Library Reference and the beginners guide to Python 2.x 3.x in Russian language. I am aware this type of translation will be placed at https://wiki.python.org/moin/RussianLanguage as current https://docs.python.org/2/ does not allow changing language. I am pretty much aware the translation should not sound any differently from the original in terms of its style, form and overall attitude. And I would also like to know, if possible, can this link be promoted somewhere at python.org. I am not in the slightest have the intentions of promoting in anywhere but in the place where most russian programmers could most definitely find it - at the oficial Python website. Kind regards, Evgeniy. ---------- assignee: docs at python components: Documentation messages: 249478 nosy: docs at python, overr1de priority: normal severity: normal status: open title: Contributing to Python 2x and 3x Documentation. Translation to Russian. type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 14:14:26 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 01 Sep 2015 12:14:26 +0000 Subject: [issue22798] time.mktime doesn't update time.tzname In-Reply-To: <1415189548.18.0.514821385606.issue22798@psf.upfronthosting.co.za> Message-ID: <1441109666.93.0.948073446935.issue22798@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: mktime() does change several global C runtime variables on Linux. See the man page on http://linux.die.net/man/3/mktime However, the Python documentation does not mention anything about having time.tzname being tied to the C lib global: https://docs.python.org/3.5/library/time.html#time.tzname So I don't think this qualifies as bug. Note that those global C variable are not thread-safe, so you can't really trust their values relating to anything you've just set using mktime() anyway. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 14:19:23 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Tue, 01 Sep 2015 12:19:23 +0000 Subject: [issue22798] time.mktime doesn't update time.tzname In-Reply-To: <1415189548.18.0.514821385606.issue22798@psf.upfronthosting.co.za> Message-ID: <1441109963.25.0.470355981477.issue22798@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: BTW: The most portable way to access the timezone name of a given local time is to use strftime() with %Z as format character. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 14:50:58 2015 From: report at bugs.python.org (Facundo Batista) Date: Tue, 01 Sep 2015 12:50:58 +0000 Subject: [issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model In-Reply-To: <1441057022.82.0.924513920263.issue24974@psf.upfronthosting.co.za> Message-ID: <1441111858.27.0.017167002485.issue24974@psf.upfronthosting.co.za> Changes by Facundo Batista : ---------- nosy: -facundobatista _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 15:04:42 2015 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 01 Sep 2015 13:04:42 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1441112682.0.0.566799538225.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: Make sure f-strings are identified as literals in error messages. ---------- Added file: http://bugs.python.org/file40317/pep-498-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 16:31:14 2015 From: report at bugs.python.org (TJ) Date: Tue, 01 Sep 2015 14:31:14 +0000 Subject: [issue24979] Allow timezone offsets greater than 24 hours Message-ID: <1441117874.73.0.315873537827.issue24979@psf.upfronthosting.co.za> New submission from TJ: The datetime module only supports timezone offsets within 24 hours of UTC: https://docs.python.org/3/library/datetime.html#datetime.tzinfo.utcoffset This seems like an arbitrary restriction, and prevents the library from being used in arbitrary timezone translations. For various reasons, one might need to start a new day (perhaps to implement some business logic) during the regular day. Depending on when/where this is, the effective offset can easily be greater than 24 hours. >>> import datetime >>> import pytz >>> dt = pytz.utc.localize(datetime.datetime.utcnow()) >>> dt datetime.datetime(2015, 8, 31, 23, 30, 55, 590037, tzinfo=) >>> tz = pytz.timezone('Pacific/Auckland_Custom') >>> dt.astimezone(tz) datetime.datetime(2015, 9, 2, 4, 30, 55, 590037, tzinfo=) >>> dt_local = datetime.datetime.now() >>> tz.localize(dt_local) .../python2.7/site-packages/pytz/tzinfo.py in localize(self, dt, is_dst) 314 loc_dt = tzinfo.normalize(dt.replace(tzinfo=tzinfo)) 315 if loc_dt.replace(tzinfo=None) == dt: --> 316 possible_loc_dt.add(loc_dt) 317 318 if len(possible_loc_dt) == 1: ValueError: tzinfo.utcoffset() returned 1440; must be in -1439 .. 1439 Note that although only offsets within 24 hours are supported, it seems to be possible to use astimezone() with arbitrary offsets. So perhaps we gain consistency in removing the restriction altogether? This would not be unprecedented. RFC 2822 allows any offset representable as HHMM: "the zone MUST be within the range -9959 through +9959" Section 3.3 of http://tools.ietf.org/html/rfc2822.html ---------- components: Library (Lib) messages: 249482 nosy: tjhnson priority: normal severity: normal status: open title: Allow timezone offsets greater than 24 hours type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 16:38:29 2015 From: report at bugs.python.org (Eugene Toder) Date: Tue, 01 Sep 2015 14:38:29 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441118309.95.0.0538891954305.issue24912@psf.upfronthosting.co.za> Eugene Toder added the comment: Nathaniel, what if we allow creating module objects from an existing dict instead of always creating a new one. Does this solve your namespace diversion problem? FWIW, when I discovered this change I was quite surprised this came through without a PEP. I agree that the old rules were somewhat arbitrary, but this is a significant change with non-trivial compatibility concerns. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 17:45:09 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 01 Sep 2015 15:45:09 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441122309.6.0.650130988656.issue24912@psf.upfronthosting.co.za> Guido van Rossum added the comment: I don't want to own this, but this is absolutely a release blocker. I see three ways out: - Fix it right (if possible) -- "system immutable" types such as int should not allow __class__ assignment. Risk: there might be other cases (the code being patched is clearly too complex for humans to comprehend). - Roll back the patch; I'm unclear on why Nathaniel would be so heartbroken if he couldn't assign the __class__ of a module (since there are other approaches such as assignment to sys.module[__name__]. - Roll back the patch but replace it with a narrower patch that specifically allows __class__ assignment for modules (but not for other types). But first, why is it so important to assign the __class__ of a module? It seems somebody is trying to make modules into what they weren't meant to be. ---------- assignee: Guido.van.Rossum -> nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 17:54:15 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 01 Sep 2015 15:54:15 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> Message-ID: <1441122855.25.0.170703722493.issue23406@psf.upfronthosting.co.za> R. David Murray added the comment: I agree that the table entry could be made more precise. I would suggest replacing the table entry with "equivalent to adding s to itself n times". This formulation serves to explain *why* the multiply operation works the way it does: >>> a = [1, []] >>> b = a * 4 >>> c = a + a + a + a >>> b [1, [], 1, [], 1, [], 1, []] >>> c [1, [], 1, [], 1, [], 1, []] >>> a.append(2) >>> a [1, [], 2] >>> b [1, [], 1, [], 1, [], 1, []] >>> c [1, [], 1, [], 1, [], 1, []] >>> a[1].append(3) >>> a [1, [3], 2] >>> b [1, [3], 1, [3], 1, [3], 1, [3]] >>> c [1, [3], 1, [3], 1, [3], 1, [3]] I don't think it is appropriate to put an example in the table; IMO that belongs in the footnote where it currently is. You could hyperlink the table entry to the FAQ entry, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 18:11:45 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 01 Sep 2015 16:11:45 +0000 Subject: [issue7175] Define a standard location and API for configuration files In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za> Message-ID: <1441123905.38.0.653946275247.issue7175@psf.upfronthosting.co.za> R. David Murray added the comment: That standard is just wrong, dotfiles belong in $HOME :) I'm only half joking, having grown up with Unix and having had the experience of flailing around for a while before I figured out a particular program's rc file was in .config instead of where I expected it to be, but I *am* half joking, because putting them all in .config is convenient. But most programs don't, so also looking in ~ makes sense to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 18:21:02 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 01 Sep 2015 16:21:02 +0000 Subject: [issue7175] Define a standard location and API for configuration files In-Reply-To: <1441123905.38.0.653946275247.issue7175@psf.upfronthosting.co.za> Message-ID: <20150901122115.0248945c@anarchist.wooz.org> Barry A. Warsaw added the comment: I'm of mixed opinion. I personally don't like cluttering up my $HOME with a jillion dotfiles so I appreciate the organization XDG_CONFIG_HOME offers. But that also makes things less discoverable. Looking in XDG_CONFIG_HOME first with a fallback to $HOME seems like a workable compromise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 18:27:37 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 01 Sep 2015 16:27:37 +0000 Subject: [issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model In-Reply-To: <1441057022.82.0.924513920263.issue24974@psf.upfronthosting.co.za> Message-ID: <1441124857.81.0.699016573765.issue24974@psf.upfronthosting.co.za> Steve Dower added the comment: fenv_access is not available when compiling with /fp:fast, which is apparently ICC's default. The proposed workaround here changes that default to /fp:strict, which is a very different model, for all of CPython. I proposed using #pragma float_control to force /fp:strict locally and enable fenv_access, rather than changing the entire build to use /fp:strict (even though fenv_access is not enabled everywhere by default). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 18:31:06 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 01 Sep 2015 16:31:06 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441125066.53.0.273568456384.issue24912@psf.upfronthosting.co.za> STINNER Victor added the comment: Sorry, I don't have time to read the whole discussion. Since we are *very* close to 3.5 final, I agree with Mark: "Please revert c0d25de5919e. Breaking the interpreter in order to facilitate some obscure use case is unacceptable." We can reintroduce the feature in Python 3.6 with a longer discussion how to implement it, or ensure that we really want it. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 18:34:40 2015 From: report at bugs.python.org (Zachary Ware) Date: Tue, 01 Sep 2015 16:34:40 +0000 Subject: [issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model In-Reply-To: <1441124857.81.0.699016573765.issue24974@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: Steve Dower added the comment: > fenv_access is not available when compiling with /fp:fast, which is apparently ICC's default. > > The proposed workaround here changes that default to /fp:strict, which is a very different model, for all of CPython. I proposed using #pragma float_control to force /fp:strict locally and enable fenv_access, rather than changing the entire build to use /fp:strict (even though fenv_access is not enabled everywhere by default). Note that I'm not suggesting changing the default for everything to /fp:strict. The goal of the project building Python with ICC on Windows is to change nothing for an MSVC build. The default floating point model should not change without a good reason, and this is not it :) I'll experiment with your suggestions, Steve and Stefan, discuss it with Intel, and get back to you here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 18:35:09 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 01 Sep 2015 16:35:09 +0000 Subject: [issue24973] CFLAGS for Visual Studio In-Reply-To: <1441053291.88.0.612352181445.issue24973@psf.upfronthosting.co.za> Message-ID: <1441125309.74.0.179679137934.issue24973@psf.upfronthosting.co.za> Steve Dower added the comment: All environment variables are promoted to MSBuild properties, so if you "set IncludeSSL=false" before building then it will show up (which is exactly how the proposed patch is getting CFLAGS in). Unfortunately, batch file argument parsing is pretty horrid. I'd be happy to move to PowerShell based scripts, but that'll be asking a lot of some people, and probably isn't feasible for the existing buildbots. Another concern about using CFLAGS is people ending up with broken builds because they had something else set in there - mostly because it's near impossible to diagnose remotely. If we call it PY_CFLAGS< move it to pyproject.props, and require "$(BuildForRelease) != 'true'", then I'm fine with it. (The last condition ensures that official release builds via Tools\msi\buildrelease.bat will never be affected, and gives a fairly strong indication not to rely on implicit settings like this. Defaults that we need for actual releases should be integrated properly.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 18:37:36 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 01 Sep 2015 16:37:36 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1441125456.34.0.037188937171.issue24965@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 18:40:55 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 01 Sep 2015 16:40:55 +0000 Subject: [issue7175] Define a standard location and API for configuration files In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za> Message-ID: <1441125655.73.0.0659219591052.issue7175@psf.upfronthosting.co.za> Antoine Pitrou added the comment: If this is about existing config files, then we should make sure we don't break existing installations. Also, multiple possible locations in the home dir are confusing. If this is about new config files, then ~/.config/python/XXX is probably ok. I'm not sure what XDG_CONFIG_HOME is but $XDG_CONFIG_HOME doesn't seem defined under my shell (Xubuntu 15.04). ---------- assignee: eric.araujo -> versions: +Python 3.6 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 18:41:08 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 01 Sep 2015 16:41:08 +0000 Subject: [issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model In-Reply-To: <1441057022.82.0.924513920263.issue24974@psf.upfronthosting.co.za> Message-ID: <1441125668.04.0.394352474066.issue24974@psf.upfronthosting.co.za> Stefan Krah added the comment: If "#pragma float_control(precise, push)" is exactly the MSVC default then I'm fine with putting it on top of FENV_ACCESS. There's nothing speed sensitive going on here: In the 32-bit build the x87 FPU is used for modular multiplication of integers and needs the control word set to 80-bit prec + ROUND_CHOP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 19:16:39 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 01 Sep 2015 17:16:39 +0000 Subject: [issue24934] django_v2 benchmark not working in Python 3.6 In-Reply-To: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za> Message-ID: <1441127799.18.0.77421168213.issue24934@psf.upfronthosting.co.za> Brett Cannon added the comment: I would still rather wait until Django 1.9.0 is officially released else we are benchmarking alpha code which doesn't seem worth it. With Python 3.6.0 not due out until about 15 months after 1.9.0 comes out I think going 3 months without a Django benchmark for 3.6 is acceptable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 19:16:44 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 01 Sep 2015 17:16:44 +0000 Subject: [issue24934] django_v2 benchmark not working in Python 3.6 In-Reply-To: <1440508179.01.0.645988058251.issue24934@psf.upfronthosting.co.za> Message-ID: <1441127804.79.0.800409604224.issue24934@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 19:26:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 01 Sep 2015 17:26:06 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441128366.89.0.475463085761.issue24912@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The c0d25de5919e changeset consists of three parts: 1) Fixes a bug (disallow an assignment of incompatible __class__ that happens to have the same __basesize__). 2) Allows __class__ assignment for module type. 3) Allows __class__ assignment for other types, in particular non-heap builtin types. I think we should keep (1) and disallow (3). (2) is questionable and I for disallowing it too (special cases aren't special enough to break the rules). It is too little time left to 3.5 release, we will have more time to discuss this for 3.6. Nataniel's new patch without special casing ModuleType would be good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 19:29:16 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 01 Sep 2015 17:29:16 +0000 Subject: [issue24978] Contributing to Python 2x and 3x Documentation. Translation to Russian. In-Reply-To: <1441109047.57.0.29993860249.issue24978@psf.upfronthosting.co.za> Message-ID: <1441128556.54.0.261461205585.issue24978@psf.upfronthosting.co.za> Brett Cannon added the comment: Is it time we start managing translations somehow? Or at least have a link off of docs.python.org to various translations so they are easier to discover? ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 19:30:55 2015 From: report at bugs.python.org (Georg Brandl) Date: Tue, 01 Sep 2015 17:30:55 +0000 Subject: [issue24978] Contributing to Python 2x and 3x Documentation. Translation to Russian. In-Reply-To: <1441109047.57.0.29993860249.issue24978@psf.upfronthosting.co.za> Message-ID: <1441128655.75.0.632048232529.issue24978@psf.upfronthosting.co.za> Georg Brandl added the comment: Someone will have to step up to manage this effort. The technical side is pretty much solved with sphinx-i18n. I think this is something the PSF should sponsor. (I wrote a proposal to the board a while ago, but I couldn't find a candidate to do it.) ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 20:13:40 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 01 Sep 2015 18:13:40 +0000 Subject: [issue24975] Python 3.5 can't compile AST involving PEP 448 unpacking In-Reply-To: <1441069996.63.0.493747155256.issue24975@psf.upfronthosting.co.za> Message-ID: <1441131220.3.0.375811068078.issue24975@psf.upfronthosting.co.za> Brett Cannon added the comment: Do we not have a test that compiles the entire stdlib using the ast module? We used to have one for the old compiler package. If don't have such a test we should probably add it even if it requires a -u option. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 20:20:22 2015 From: report at bugs.python.org (Eugene Toder) Date: Tue, 01 Sep 2015 18:20:22 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441131622.42.0.359792301944.issue24912@psf.upfronthosting.co.za> Eugene Toder added the comment: Guido: IIUC the general intention is to support @property and __getattr__ style hooks on the module level. Assigning to sys.modules[name] from the module itself is a bit too late -- there's already a global dict for this module, and no way to create a module from an existing dict, so you end up with two global namespaces which is annoying (but admittedly people live with that). One way around that is to set up import hooks, but this is also annoying, and leaks module implementation outside of its code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 21:00:51 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 01 Sep 2015 19:00:51 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441134051.42.0.763201949953.issue24912@psf.upfronthosting.co.za> Guido van Rossum added the comment: If we don't reach an agreement we should fall back to Serhiy's (1) only. Eugene: Without more motivation that sounds like very questionable functionality to want to add to modules. I don't have time to read the discussion that led up to this, but modules are *intentionally* dumb. We already have classes and instances. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 21:13:12 2015 From: report at bugs.python.org (Joshua Harlow) Date: Tue, 01 Sep 2015 19:13:12 +0000 Subject: [issue24980] Allow for providing 'on_new_thread' callback to 'concurrent.futures.ThreadPoolExecutor' Message-ID: <1441134792.06.0.689087897304.issue24980@psf.upfronthosting.co.za> New submission from Joshua Harlow: In situations where thread-local variables need to be setup it is quite useful to be able to hook into the thread creation process, so that as each new thread is spun up by the ThreadPoolExecutor that the threads created initially call into a provided callback (the callback can then setup thread local state as needed). ---------- messages: 249501 nosy: harlowja priority: normal severity: normal status: open title: Allow for providing 'on_new_thread' callback to 'concurrent.futures.ThreadPoolExecutor' _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 21:14:11 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Tue, 01 Sep 2015 19:14:11 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441134851.94.0.338122980191.issue24912@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Guido van Rossum wrote: > But first, why is it so important to assign the __class__ of a module? It seems somebody is trying to make modules into what they weren't meant to be. Because you told me to do it this way on python-dev :-( https://mail.python.org/pipermail/python-dev/2014-December/137430.html The goal is to make it possible for projects (e.g. numpy) to safely issue a deprecation warning when people access certain module-level constants. The reason this is difficult is that we have several almost-conflicting requirements: 1) we want to be able to override special methods like __getattr__ and __dir__ on modules. And it'd nice if we could have access to things like properties and __repr__ too. 2) we can't control the type used to originally construct the module, because the module object is constructed before the first line of our code is run. 3) we want sys.modules[our_module].__dict__ to always refer to the namespace where __init__.py is executing, for reasons described at the top of msg249446. This is not currently possible when replacing the module object in-place -- if you make a new module object, then now you have the old module's namespace and the new module's namespace, and are responsible for manually keeping them in sync. (This is not a case where "let's do more of those" applies ;-).) Other solutions that were previously considered (in two threads on python-dev and python-ideas with 40+ messages each) include: - tackling (1) directly by defining a new set of special-purpose hooks just for modules (e.g. make ModuleType.__getattr__ check for a special __module_getattr__ function in the module namespace and call it). This is what Marc-Andre is suggesting now (msg249473). OTOH it would be nice to re-use the existing class mechanism instead of reimplementing parts of it just for modules. - tackling (2) directly via wacky stuff like preparsing the file to check for special markers that tell the import machinery what ModuleType subclass to instantiate before the module starts executing (similar to how __future__ imports work) - tackling (3) by adding some new special machinery to module objects, like the ability to replace their __dict__ attribute. This is what Eugene Toder is suggesting now (msg249483). The advantage of allowing __class__ assignment on ModuleType instances is that it solves all these problems by using an existing feature rather than adding any new ones. (I also tried the strategy of switching ModuleType to just *be* a heap type and avoid all these issues, but unfortunately it turns out that this would have broken the stable ABI so I gave up on that.) The diff from 3.4 to 3.5rc2+the attached patch consists of uncontroversial bug fixes, plus two lines of code in typeobject.c that cause module subtypes to be treated similarly to heap types with respect to __class__ assignment: - if (!(newto->tp_flags & Py_TPFLAGS_HEAPTYPE) || - !(oldto->tp_flags & Py_TPFLAGS_HEAPTYPE)) { + if (!(PyType_IsSubtype(newto, &PyModule_Type) && + PyType_IsSubtype(oldto, &PyModule_Type)) && + (!(newto->tp_flags & Py_TPFLAGS_HEAPTYPE) || + !(oldto->tp_flags & Py_TPFLAGS_HEAPTYPE))) { These two lines of code solve an important user-facing issue for numpy, and are far simpler than any of the other proposed solutions. This approach was reviewed by python-dev, and has stood through the entire pre-release cycle so far without anyone producing a single argument yet for why it will cause any problem whatsoever. I'm very sorry for introducing the bug with immutable types, and for not initially addressing it with the seriousness that it deserved. But that bug is fixed now, and unless someone can name an actual problem with the above two lines then I don't see why their association with a now-fixed bug is any reason to go rehash the entire discussion from scratch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 21:15:19 2015 From: report at bugs.python.org (Glyph Lefkowitz) Date: Tue, 01 Sep 2015 19:15:19 +0000 Subject: [issue7175] Define a standard location and API for configuration files In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za> Message-ID: <1441134919.66.0.382073439662.issue7175@psf.upfronthosting.co.za> Glyph Lefkowitz added the comment: XDG_CONFIG_HOME is not generally set to anything; the default of ~/.config is usually fine. However, the point is that you _can_ set it to point at a different location. The relevant specification is here: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html The biggest reason I strongly believe we should follow a specification is that Python is not the only software on the system. If I am an ops person that has to deal with Python and Ruby and Java and C software all the time, *any* consistency is a big help. We don't have to follow *this* specification, but we should follow *some* specification (although this specific one looks like a good one to me). The Python community has no special expertise deciding on locations for configuration files, and so we should not be trying to invent a new and better place for them. There are other advantages to following the XDG spec. If we follow it correctly (and not, like Barry suggested, start adding random other directories like ~/.python), users can easily switch between configuration environments by switching the XDG environment variables (both XDG_CONFIG_DIRS and XDG_CONFIG_HOME), which would be a handy way of ignoring both user-specified config files _and_ system-specified ones, to get a pristine virtualenv-like separation between different config files. Given that they are going to need to set these env vars anyway to redirect spec-compliant libraries that their application may be using, it would be nice to just have _one_ set of meta-configuration variables rather than one for Python and one for C and one for Ruby and so on. Consider the fact that distutils respects "CFLAGS", and did not feel the need to invent "DISTUTILS_FLAGS_FOR_THE_C_COMPILER". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 21:15:40 2015 From: report at bugs.python.org (Joshua Harlow) Date: Tue, 01 Sep 2015 19:15:40 +0000 Subject: [issue24980] Allow for providing 'on_new_thread' callback to 'concurrent.futures.ThreadPoolExecutor' In-Reply-To: <1441134792.06.0.689087897304.issue24980@psf.upfronthosting.co.za> Message-ID: <1441134940.88.0.859803828988.issue24980@psf.upfronthosting.co.za> Changes by Joshua Harlow : ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 21:15:50 2015 From: report at bugs.python.org (Joshua Harlow) Date: Tue, 01 Sep 2015 19:15:50 +0000 Subject: [issue24980] Allow for providing 'on_new_thread' callback to 'concurrent.futures.ThreadPoolExecutor' In-Reply-To: <1441134792.06.0.689087897304.issue24980@psf.upfronthosting.co.za> Message-ID: <1441134950.81.0.412270268119.issue24980@psf.upfronthosting.co.za> Changes by Joshua Harlow : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 21:16:04 2015 From: report at bugs.python.org (Joshua Harlow) Date: Tue, 01 Sep 2015 19:16:04 +0000 Subject: [issue24980] Allow for providing 'on_new_thread' callback to 'concurrent.futures.ThreadPoolExecutor' In-Reply-To: <1441134792.06.0.689087897304.issue24980@psf.upfronthosting.co.za> Message-ID: <1441134964.41.0.119525165981.issue24980@psf.upfronthosting.co.za> Changes by Joshua Harlow : ---------- components: +Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 21:25:49 2015 From: report at bugs.python.org (Mark Shannon) Date: Tue, 01 Sep 2015 19:25:49 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441135549.57.0.347439414566.issue24912@psf.upfronthosting.co.za> Mark Shannon added the comment: I think Nathaniel and Eugene argument that you cannot replace the module in sys.modules safely in erroneous. Immediately after the module is created by importlib it is inserted into sys.modules. The code object for the module is then executed. At that point, when the module code starts executing, no code outside the module has executed since the module was created and the import lock is held so no other thread will be able to import the module. Therefore the only code that can see the module object is the module's own code. Given a custom subclass of module that overrides __getattr__ to fetch values from the original module's __dict__, then an instance of that class can be inserted into sys.modules before any imports or calls to code that would access sys.modules, and the substitution of the module can be done safely. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 21:26:04 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 01 Sep 2015 19:26:04 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441135564.95.0.388595960559.issue24912@psf.upfronthosting.co.za> Guido van Rossum added the comment: I don't think I told you to do it this way -- that message of mind sounded pretty noncommittal in all directions. I do understand your predicament. Can you live with just a special case for modules? __class__ assignment is full of non-portable special cases already. Given how close we are to the release we should tread with a lot of care here -- rolling back a diff is also a big liability. Maybe the "right" solution is to allow __dict__ assignment for modules. But we're too close to the release to add that. Perhaps we can revisit the right way to do it for 3.6? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 21:26:38 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 01 Sep 2015 19:26:38 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441135598.98.0.86891000341.issue24912@psf.upfronthosting.co.za> Guido van Rossum added the comment: PS. I have very little time this week or next to review everything -- if we don't find a reasonable compromise it *will* be rolled back. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 21:27:07 2015 From: report at bugs.python.org (Joshua Harlow) Date: Tue, 01 Sep 2015 19:27:07 +0000 Subject: [issue24980] Allow for providing 'on_new_thread' callback to 'concurrent.futures.ThreadPoolExecutor' In-Reply-To: <1441134792.06.0.689087897304.issue24980@psf.upfronthosting.co.za> Message-ID: <1441135627.33.0.534623980646.issue24980@psf.upfronthosting.co.za> Joshua Harlow added the comment: Initial possible patch. ---------- keywords: +patch type: enhancement -> Added file: http://bugs.python.org/file40318/add_future_callback.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 21:27:30 2015 From: report at bugs.python.org (Eric Fried) Date: Tue, 01 Sep 2015 19:27:30 +0000 Subject: [issue24980] Allow for providing 'on_new_thread' callback to 'concurrent.futures.ThreadPoolExecutor' In-Reply-To: <1441134792.06.0.689087897304.issue24980@psf.upfronthosting.co.za> Message-ID: <1441135650.32.0.901339962737.issue24980@psf.upfronthosting.co.za> Changes by Eric Fried : ---------- nosy: +2uasimojo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 21:30:46 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 01 Sep 2015 19:30:46 +0000 Subject: [issue7175] Define a standard location and API for configuration files In-Reply-To: <1441134919.66.0.382073439662.issue7175@psf.upfronthosting.co.za> Message-ID: <20150901153059.48dcd6c9@anarchist.wooz.org> Barry A. Warsaw added the comment: On Sep 01, 2015, at 07:15 PM, Glyph Lefkowitz wrote: >There are other advantages to following the XDG spec. If we follow it >correctly (and not, like Barry suggested, start adding random other >directories like ~/.python) I was really just suggesting reading from other locations for backward compatibility. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 21:31:33 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Tue, 01 Sep 2015 19:31:33 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441135893.29.0.129409884384.issue24912@psf.upfronthosting.co.za> Nathaniel Smith added the comment: > I do understand your predicament. Can you live with just a special case for modules? __class__ assignment is full of non-portable special cases already. Not only can I live with it, but -- unless I misunderstand your meaning -- this is exactly the approach that I am advocating and have submitted a patch to implement :-). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 21:37:10 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 01 Sep 2015 19:37:10 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441136230.68.0.851973961343.issue24912@psf.upfronthosting.co.za> Guido van Rossum added the comment: OK, then I think it's between you and Serhiy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 21:37:29 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Tue, 01 Sep 2015 19:37:29 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441136249.04.0.856244196436.issue24912@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Pull request version of patch is here: https://bitbucket.org/larry/cpython350/pull-requests/9/fix-issue-24912-disallow-reassigning-the/diff (identical to issue24912-v2.patch except for the addition of a NEWS entry) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 21:46:37 2015 From: report at bugs.python.org (Garfield222) Date: Tue, 01 Sep 2015 19:46:37 +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: <1441136797.16.0.669411664196.issue17849@psf.upfronthosting.co.za> Garfield222 added the comment: Same error happens if http_proxy="223.19.230.181:80" variable is set. ---------- nosy: +Garfield222 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 21:51:47 2015 From: report at bugs.python.org (Garfield222) Date: Tue, 01 Sep 2015 19:51:47 +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: <1441137107.89.0.00338453008097.issue17849@psf.upfronthosting.co.za> Garfield222 added the comment: This error occurs when using youtube-dl Complete log is here: https://github.com/rg3/youtube-dl/issues/6727 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 22:07:34 2015 From: report at bugs.python.org (Yi Ding) Date: Tue, 01 Sep 2015 20:07:34 +0000 Subject: [issue24891] race condition in initstdio() (python aborts running under nohup) In-Reply-To: <1439936328.26.0.889765372825.issue24891@psf.upfronthosting.co.za> Message-ID: <1441138054.44.0.303765881042.issue24891@psf.upfronthosting.co.za> Yi Ding added the comment: I'm not sure this is a race condition. There's a crash every single time python is started when running the test.sh script under nohup. If it's a race condition, it should only happen some of the time, not every single time. Can you reeevaluate the priority? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 22:13:17 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 01 Sep 2015 20:13:17 +0000 Subject: [issue24975] Python 3.5 can't compile AST involving PEP 448 unpacking In-Reply-To: <1441069996.63.0.493747155256.issue24975@psf.upfronthosting.co.za> Message-ID: <1441138397.68.0.60582741948.issue24975@psf.upfronthosting.co.za> Yury Selivanov added the comment: Larry, I created a PR for you: https://bitbucket.org/larry/cpython350/pull-requests/10/issue-24975-fix-ast-compilation-for-pep/diff Brett, Should we do that in a separate issue targeting 3.6 only? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 22:49:15 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 01 Sep 2015 20:49:15 +0000 Subject: [issue24981] Add a test which uses the ast module to compile the stdlib Message-ID: <1441140555.75.0.593788380292.issue24981@psf.upfronthosting.co.za> New submission from Brett Cannon: Issue #24975 shows that we can easily end up with holes in support from the ast module. We should probably make sure we have a test that goes through the entire stdlib, Does an ast.parse(), and then passes the result to compile() to verify no exceptions are raised. We should either avoid the test/ directory or blacklist specific files which will fail because they are designed to be syntactically incorrect. The test can also be behind a -u flag if it turns out to be an expensive test. ---------- components: Tests messages: 249516 nosy: brett.cannon priority: normal severity: normal stage: test needed status: open title: Add a test which uses the ast module to compile the stdlib versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 22:49:43 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 01 Sep 2015 20:49:43 +0000 Subject: [issue24975] Python 3.5 can't compile AST involving PEP 448 unpacking In-Reply-To: <1441069996.63.0.493747155256.issue24975@psf.upfronthosting.co.za> Message-ID: <1441140583.07.0.0732707087726.issue24975@psf.upfronthosting.co.za> Brett Cannon added the comment: Created issue #24981 to track the test case idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 1 23:18:29 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 01 Sep 2015 21:18:29 +0000 Subject: [issue24981] Add a test which uses the ast module to compile the stdlib In-Reply-To: <1441140555.75.0.593788380292.issue24981@psf.upfronthosting.co.za> Message-ID: <1441142309.11.0.0391798598267.issue24981@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 00:19:47 2015 From: report at bugs.python.org (Steve Yeung) Date: Tue, 01 Sep 2015 22:19:47 +0000 Subject: [issue24929] _strptime.TimeRE should not enforce range in regex In-Reply-To: <1440452349.29.0.876134082373.issue24929@psf.upfronthosting.co.za> Message-ID: <1441145987.51.0.736586453073.issue24929@psf.upfronthosting.co.za> Steve Yeung added the comment: I'm not sure what format I'm supposed to provide the test in. I attached a file that has the diff of the changes I made, and how the error message is changed (and improved!) in both datetime and time. ---------- Added file: http://bugs.python.org/file40319/file _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 01:52:53 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 01 Sep 2015 23:52:53 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <20150901235248.38887.68243@psf.io> Roundup Robot added the comment: New changeset abeb625b20c2 by Victor Stinner in branch 'default': Issue #23517: Add "half up" rounding mode to the _PyTime API https://hg.python.org/cpython/rev/abeb625b20c2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 01:57:35 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 01 Sep 2015 23:57:35 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <20150901235731.32117.25648@psf.io> Roundup Robot added the comment: New changeset b690bf218702 by Victor Stinner in branch 'default': Issue #23517: datetime.datetime.fromtimestamp() and https://hg.python.org/cpython/rev/b690bf218702 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 02:03:56 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Sep 2015 00:03:56 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441152236.04.0.614242392719.issue23517@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, I fixed the issue in Python 3.6. Example with the initial message: $ python2.7 -c 'import datetime; print(datetime.datetime.utcfromtimestamp(1424817268.274).microsecond); print(datetime.datetime.utcfromtimestamp(-1424817268.274).microsecond)' 274000 726000 $ python3.6 -c 'import datetime; print(datetime.datetime.utcfromtimestamp(1424817268.274).microsecond); print(datetime.datetime.utcfromtimestamp(-1424817268.274).microsecond)' 274000 726000 I wrote: "On Python < 3.3, datetime.datetime.fromtimestamp(float) doesn't use exactly ROUND_HALF_EVEN, but it looks more to "round half away from zero" (the decimal module doesn't seem to support this exact rounding method)." I was wrong: it's decimal.ROUND_HALF_UP in fact. I will backport the change to Python 3.4 and 3.5. Since this issue was defined as a bugfix, it should be fixed in Python 3.5.1 (too late for 3.5.0). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 02:56:17 2015 From: report at bugs.python.org (Eugene Kolo) Date: Wed, 02 Sep 2015 00:56:17 +0000 Subject: [issue24982] shutil.make_archive doesn't archive empty directories Message-ID: <1441155377.03.0.243318485167.issue24982@psf.upfronthosting.co.za> New submission from Eugene Kolo: Zip file is sometimes known to only contain files and the paths to them, but it can also have have empty folders, they are zero length files with a flag set. make_archive just ignores empty directories, I propose that there should either be a flag, or it should include empty directories by default. ---------- components: Library (Lib) messages: 249522 nosy: eugenek priority: normal severity: normal status: open title: shutil.make_archive doesn't archive empty directories type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 03:27:07 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 02 Sep 2015 01:27:07 +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: <1441157227.51.0.0443771118873.issue17849@psf.upfronthosting.co.za> Martin Panter added the comment: Left some review comments. But I don?t completely understand the test case. Is it true there are proxies that do not send a HTTP status line (like HTTP/1.0 200 Connection Established), but do sned the rest of the HTTP header section? This is what the test case seems to be modelling: Client to proxy request: b"CONNECT foo:80 HTTP/1.0\r\n" b"\r\n" Proxy (plus tunnelled?) response, minus a status line: b"X-Foo: bar\r\n" b"\r\n" b"hello world" It seems more likely that the proxies related to this bug are misbehaving, or there is some other network problem. Of the proxies mentioned in this report that are accessible to me, both of them do not appear to accept CONNECT requests at all. As soon as the first CONNECT line is send, a HTML blob saying ?400 Bad Request? is received, without any HTTP header at all. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 03:33:26 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 02 Sep 2015 01:33:26 +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: <1441157606.47.0.185054321253.issue17849@psf.upfronthosting.co.za> Martin Panter added the comment: A test case with data like this would make more sense to me: # Response without HTTP status line or header, modelling responses sent by # some proxies that do not support CONNECT body = b"400 Bad Request" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 03:41:14 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 02 Sep 2015 01:41:14 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441158074.0.0.141375509145.issue23517@psf.upfronthosting.co.za> Larry Hastings added the comment: > too late for 3.5.0 How's that? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 06:07:12 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 02 Sep 2015 04:07:12 +0000 Subject: [issue24981] Add a test which uses the ast module to compile the stdlib In-Reply-To: <1441140555.75.0.593788380292.issue24981@psf.upfronthosting.co.za> Message-ID: <1441166832.61.0.367517482699.issue24981@psf.upfronthosting.co.za> Raymond Hettinger added the comment: +1 This is a great idea. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 09:48:32 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 02 Sep 2015 07:48:32 +0000 Subject: [issue22758] Regression in Python 3.2 cookie parsing In-Reply-To: <1414577677.93.0.364604019199.issue22758@psf.upfronthosting.co.za> Message-ID: <1441180112.57.0.413054176834.issue22758@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 10:27:06 2015 From: report at bugs.python.org (flying sheep) Date: Wed, 02 Sep 2015 08:27:06 +0000 Subject: [issue7175] Define a standard location and API for configuration files In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za> Message-ID: <1441182426.23.0.993792531669.issue7175@psf.upfronthosting.co.za> flying sheep added the comment: of course if there is a chance that some specific config file exists at a known location, it?s the only sane choice to try and look for it there iff it isn?t in its preferred location. e.g. fontconfig made that switch some time ago: it used to be ~/.fonts.conf, now it?s ${XDG_CONFIG_HOME-$HOME/.config}/fontconfig/fonts.conf the library will look at the new position and if it can?t find anything there, it looks at the old one. but for new config files we should follow standards. on windows and OSX there are different ones: see the current discussion on python-ideas for specifics and problems. but on linux the only standard for this which i know is XDG-base-directories, so we should follow that for new config files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 10:31:06 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 02 Sep 2015 08:31:06 +0000 Subject: [issue24979] Allow timezone offsets greater than 24 hours In-Reply-To: <1441117874.73.0.315873537827.issue24979@psf.upfronthosting.co.za> Message-ID: <1441182666.33.0.0970837101433.issue24979@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 10:41:02 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Sep 2015 08:41:02 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <20150902084058.66018.92626@psf.io> Roundup Robot added the comment: New changeset 30454ef98e81 by Victor Stinner in branch 'default': Backed out changeset b690bf218702 https://hg.python.org/cpython/rev/30454ef98e81 New changeset 700303850cd7 by Victor Stinner in branch 'default': Issue #23517: Fix _PyTime_ObjectToDenominator() https://hg.python.org/cpython/rev/700303850cd7 New changeset 03c97bb04cd2 by Victor Stinner in branch 'default': Issue #23517: Reintroduce unit tests for the old PyTime API since it's still https://hg.python.org/cpython/rev/03c97bb04cd2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 10:47:23 2015 From: report at bugs.python.org (Erik Cederstrand) Date: Wed, 02 Sep 2015 08:47:23 +0000 Subject: [issue12006] strptime should implement %G, %V and %u directives In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za> Message-ID: <1441183643.11.0.202681176304.issue12006@psf.upfronthosting.co.za> Erik Cederstrand added the comment: The going's a bit tough here. I've spent at least 10 times as long on this bug than it took me to work around the fact that Python doesn't support ISO week number round-trip. Python puts a smile on my face every day and I enjoy giving back where I can. But after four years, the smile is getting a bit stiff when I look at this enhancement request. I'm hereby offering a scrumptious, mouth-watering, virtual, blackberry mousse gateau with a honey-roasted almond meringue cake bottom to the person who gets this enhancement committed. In good open-source spirit, everyone who contributed along the way is entitled to a healthy serving and eternal gratitude from me. Bon appetit! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 10:56:47 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Sep 2015 08:56:47 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441184207.35.0.686524371812.issue23517@psf.upfronthosting.co.za> STINNER Victor added the comment: Larry Hasting wrote: >> too late for 3.5.0 > How's that? Well, for example... my change broke all buildbots. I don't think that it's good idea to rush to fix Python 3.5 :-) This part of Python (handling timestamps, especially the rounding mode) is complex, I prefer to check for all buildbots and wait for some feedback from users (wait at least 2 weeks). I reverted my change, another function must be changed: $ python2 -c 'import datetime; print(datetime.timedelta(microseconds=0.5))' 0:00:00.000001 $ python3 -c 'import datetime; print(datetime.timedelta(microseconds=0.5))' 0:00:00 datetime.timedelta must also use the ROUND_HALF_UP method, as Python 2, instead of ROUND_HALF_EVEN (datetime.py uses the round() function). $ python2 -c 'import datetime; print(datetime.timedelta(microseconds=1.5))' 0:00:00.000002 $ python3 -c 'import datetime; print(datetime.timedelta(microseconds=1.5))' 0:00:00.000002 I have to rework my patch to use ROUND_HALF_UP in datetime.timedelta(), datetime.datetime.fromtimestamp() and datetime.datetime.utcfromtimestamp(), and update test_datetime. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 10:57:42 2015 From: report at bugs.python.org (Benedikt Reinartz) Date: Wed, 02 Sep 2015 08:57:42 +0000 Subject: [issue24900] Raising an exception that cannot be unpickled causes hang in ProcessPoolExecutor In-Reply-To: <1440055310.02.0.542767582293.issue24900@psf.upfronthosting.co.za> Message-ID: <1441184262.82.0.913603351755.issue24900@psf.upfronthosting.co.za> Changes by Benedikt Reinartz : ---------- versions: +Python 2.7, Python 3.2, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 11:58:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Sep 2015 09:58:03 +0000 Subject: [issue24900] Raising an exception that cannot be unpickled causes hang in ProcessPoolExecutor In-Reply-To: <1440055310.02.0.542767582293.issue24900@psf.upfronthosting.co.za> Message-ID: <1441187883.42.0.479248976465.issue24900@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch for issue22995 disallows default pickling objects with tp_new == NULL. ---------- nosy: +alexandre.vassalotti, pitrou, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 12:01:46 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Sep 2015 10:01:46 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <20150902100142.32105.62353@psf.io> Roundup Robot added the comment: New changeset df074eb2a5be by Victor Stinner in branch 'default': Issue #23517: Try to fix test_time on "x86 Ubuntu Shared 3.x" buildbot https://hg.python.org/cpython/rev/df074eb2a5be ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 12:14:48 2015 From: report at bugs.python.org (David Unric) Date: Wed, 02 Sep 2015 10:14:48 +0000 Subject: [issue24983] Wrong AttributeError propagation Message-ID: <1441188888.02.0.100621474433.issue24983@psf.upfronthosting.co.za> New submission from David Unric: Hello, it seems python interpreter improperly handles AttributeError exception raised in __getattr__ method, after called by unresolved attribute inside a property. Bellow is a simple Python2 example of a class which defines __getattr__ method and a property, where is non-existing attribute accessed: from __future__ import print_function class MyClass(object): def __getattr__(self, name): print('__getattr__ <<', name) raise AttributeError(name) return 'need know the question' @property def myproperty(self): print(self.missing_attribute) return 42 my_inst = MyClass() print(my_inst.myproperty) # produces following output __getattr__ << missing_attribute __getattr__ << myproperty Traceback (most recent call last): File "a.py", line 84, in main() File "a.py", line 74, in main print('==', my_inst.myproperty) File "a.py", line 36, in __getattr__ raise AttributeError(name) AttributeError: myproperty By the documentation https://docs.python.org/2/reference/datamodel.html#object.__getattr__ , if class defines __getattr__ method, it gets called at AttributeError exception and should return a computed value for name, or raise (new) AttributeError exception. The misbehavior is in 2nd call of __getattr__, with 'myproperty' as an argument. - self.myproperty does exist, no reason to call __getattr__ for it - AttributeError exception raised in __getattr__ should be propagated to the outer stack, no recurrence in the same ---------- components: Interpreter Core messages: 249533 nosy: dunric priority: normal severity: normal status: open title: Wrong AttributeError propagation type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 12:40:13 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 02 Sep 2015 10:40:13 +0000 Subject: [issue24983] Wrong AttributeError propagation In-Reply-To: <1441188888.02.0.100621474433.issue24983@psf.upfronthosting.co.za> Message-ID: <1441190413.28.0.486210541762.issue24983@psf.upfronthosting.co.za> Martin Panter added the comment: First of all, I think your a.py line 74 corresponds to the top-level print() call. My version of the output: >>> print(my_inst.myproperty) __getattr__ << missing_attribute __getattr__ << myproperty Traceback (most recent call last): File "", line 1, in File "", line 4, in __getattr__ AttributeError: myproperty This is a bit tricky, but I _think_ this is working as it is meant to. I think your central problem is an unhandled AttributeError is leaking: 1. Evaluating ?my_inst.myproperty? invokes your myproperty() getter method. 2. That function tries to evaluate ?self.missing_attribute?, which invokes your __getattr__() method. 3. __getattr__() raises AttributeError for ?missing_attribute?. 4. myproperty() does not handle the AttributeError, so it leaks. I?m not sure if the documentation is clear on this, but a property getter raising AttributeError signals that the property attribute does not exist, even though this AttributeError was originally referring to ?missing_attribute?. 5. Python thinks that the ?myproperty? property doesn?t exist, so it falls back to __getattr__(). 6. __getattr__() raises AttributeError for ?myproperty?. Hopefully that makes sense and you can see it is working somewhat sensibly :) ---------- nosy: +martin.panter resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 12:45:17 2015 From: report at bugs.python.org (Stefan Krah) Date: Wed, 02 Sep 2015 10:45:17 +0000 Subject: [issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model In-Reply-To: <1441057022.82.0.924513920263.issue24974@psf.upfronthosting.co.za> Message-ID: <1441190717.66.0.928338876921.issue24974@psf.upfronthosting.co.za> Stefan Krah added the comment: Also note that ICC <= 11.0 did not handle __GNUC__ inline asm correctly, see the comment: Modules/_decimal/libmpdec/umodarith.h:391 I've disabled asm for Linux/ICC in setup.py. I don't know how the situation is with MASM inline asm, but I'd recommend to test at least a couple of exact multiplications and divisions with operands of about 100000 digits (the asm is only used for bignums). There is already one bignum test in test_decimal that *should* catch any oddities, but testing a bit more can't hurt. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 12:49:41 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 02 Sep 2015 10:49:41 +0000 Subject: [issue7175] Define a standard location and API for configuration files In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za> Message-ID: <1441190981.7.0.771367926235.issue7175@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: The XDG standard seems to focus on desktop GUI applications and that's also where it's mostly used. Python has it's own installation scheme, which is documented at the top of sysconfig.py and which we've had ever since distutils became part of the stdlib. For user installs, this bases all installations under the PYTHONUSERBASE dir, which defaults to ~/.local/ on Unix. So user installs go into ~/.local/pythonX.X/ (I also have a ~/.local/python/X.X/ - not sure where that came from). Python also uses ~/.pypirc for PyPI, ~/.python-eggs for setuptools, ~/.python_history for readline history. The installation scheme currently doesn't define a dir for config files, only for "data" files, so adding one would probably be wise. Since we already own ~/.local/pythonX.X/, why not put config files in there ? For some extra Unix touch, we could use ~/.local/pythonX.X/etc/ and then move the cache bits to a ./var/ subdir (by defining another new "cache" entry for the schemes). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 13:13:54 2015 From: report at bugs.python.org (David Unric) Date: Wed, 02 Sep 2015 11:13:54 +0000 Subject: [issue24983] Wrong AttributeError propagation In-Reply-To: <1441188888.02.0.100621474433.issue24983@psf.upfronthosting.co.za> Message-ID: <1441192434.59.0.138912738365.issue24983@psf.upfronthosting.co.za> David Unric added the comment: Thanks for the comprehensive response. I did suspected the 2nd call is caused how it has been described in paragraph 4. And you are probably right. Only think exception instance raised in __getattr__ should not lead to its another call but propagated to outer level, ie. should not get continue in getter in this example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 13:46:21 2015 From: report at bugs.python.org (eryksun) Date: Wed, 02 Sep 2015 11:46:21 +0000 Subject: [issue24983] Wrong AttributeError propagation In-Reply-To: <1441188888.02.0.100621474433.issue24983@psf.upfronthosting.co.za> Message-ID: <1441194381.51.0.160246035046.issue24983@psf.upfronthosting.co.za> eryksun added the comment: > exception instance raised in __getattr__ should not lead > to its another call but propagated to outer level In this case the next outer level is your descriptor implementation. You have to ensure it doesn't leak the AttrubuteError. Otherwise the associated __getattribute__ call is implicitly raising AttributeError, and [by design][1] Python must default to calling __getattr__. [1]: https://docs.python.org/3/reference/datamodel.html#object.__getattribute__ ---------- nosy: +eryksun stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 13:54:44 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Sep 2015 11:54:44 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <20150902115440.28484.67546@psf.io> Roundup Robot added the comment: New changeset 59185ef69166 by Victor Stinner in branch 'default': Issue #23517: test_time, skip a test checking a corner case on floating point https://hg.python.org/cpython/rev/59185ef69166 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 14:35:11 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Sep 2015 12:35:11 +0000 Subject: [issue24297] Lib/symbol.py is out of sync with Grammar/Grammar In-Reply-To: <1432731074.7.0.288731701326.issue24297@psf.upfronthosting.co.za> Message-ID: <20150902123504.65797.95590@psf.io> Roundup Robot added the comment: New changeset bf7ef3bd9a09 by Victor Stinner in branch 'default': Issue 24297: Fix test_symbol on Windows https://hg.python.org/cpython/rev/bf7ef3bd9a09 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 15:15:06 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 02 Sep 2015 13:15:06 +0000 Subject: [issue7175] Define a standard location and API for configuration files In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za> Message-ID: <1441199706.87.0.917531064534.issue7175@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 15:23:46 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 02 Sep 2015 13:23:46 +0000 Subject: [issue24929] _strptime.TimeRE should not enforce range in regex In-Reply-To: <1440452349.29.0.876134082373.issue24929@psf.upfronthosting.co.za> Message-ID: <1441200226.01.0.336600771413.issue24929@psf.upfronthosting.co.za> R. David Murray added the comment: A unit test in test_strptime. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 15:33:28 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 02 Sep 2015 13:33:28 +0000 Subject: [issue24982] shutil.make_archive doesn't archive empty directories In-Reply-To: <1441155377.03.0.243318485167.issue24982@psf.upfronthosting.co.za> Message-ID: <1441200808.25.0.615639015065.issue24982@psf.upfronthosting.co.za> R. David Murray added the comment: See also issue 22219. I think we should fix this in shutil as well. ---------- nosy: +r.david.murray, serhiy.storchaka stage: -> needs patch versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 15:55:49 2015 From: report at bugs.python.org (Ashley Anderson) Date: Wed, 02 Sep 2015 13:55:49 +0000 Subject: [issue12006] strptime should implement %G, %V and %u directives In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za> Message-ID: <1441202149.98.0.52859403947.issue12006@psf.upfronthosting.co.za> Ashley Anderson added the comment: Haha, thanks Erik. It seems you know my tastes enough to not offer a chocolate-based reward. =) I was actually set to "ping" to request a patch review today, as it's been one month since my last submission. Please let me know if I need to update the patch against the current `tip`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 16:07:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Sep 2015 14:07:49 +0000 Subject: [issue23630] support multiple hosts in create_server/start_server In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za> Message-ID: <1441202868.98.0.845013631038.issue23630@psf.upfronthosting.co.za> STINNER Victor added the comment: > The only remaining question is is it OK that we can specify more than one host but only one port? Guido, Victor? I can be convenient to have a single Server object with *all* listening sockets. So I like the idea of supporting multiple ports. It's very cheap to support it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 16:19:11 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Sep 2015 14:19:11 +0000 Subject: [issue23630] support multiple hosts in create_server/start_server In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za> Message-ID: <1441203551.39.0.294399771687.issue23630@psf.upfronthosting.co.za> STINNER Victor added the comment: Since the consensus on python-dev looks more to keep the provisional API for asyncion in Python 3.5, I propose to even modify Python 3.4 to not add too many "if python >= 3.5..." checks in asyncio source code. If you really prefer to keep Python 3.4 unchanged, we should at least add the feature in Python 3.5.1, having to wait for Python 3.6 is too long, no? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 16:27:42 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Sep 2015 14:27:42 +0000 Subject: [issue23630] support multiple hosts in create_server/start_server In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za> Message-ID: <1441204062.14.0.666929213613.issue23630@psf.upfronthosting.co.za> Yury Selivanov added the comment: > I can be convenient to have a single Server object with *all* listening sockets. So I like the idea of supporting multiple ports. It's very cheap to support it. I like the idea too, but I'm not sure how to redesign the function's signature to accept multiple hosts & ports. We have a separate param for 'port', and this patch allows to pass an array of hosts in 'host' argument. Should we allow passing an array of (host, port) tuples in 'host' with 'None' in 'port'? This would be one ugly method... > Since the consensus on python-dev looks more to keep the provisional API for asyncion in Python 3.5, I propose to even modify Python 3.4 to not add too many "if python >= 3.5..." checks in asyncio source code. asyncio is provisional in 3.4 (and now in 3.5 too), so we can just keep updating it in bugfix releases. > If you really prefer to keep Python 3.4 unchanged, we should at least add the feature in Python 3.5.1, having to wait for Python 3.6 is too long, no? This was before we reinstated asyncio as provisional in 3.5. But before committing this change, let's agree if we want this API to accept multiple ports when you specify more than one host. We also need to create a dev branch on github/asyncio, so that it's easier for us to sync PyPI package with CPython releases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 16:28:06 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Sep 2015 14:28:06 +0000 Subject: [issue23630] support multiple hosts in create_server/start_server In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za> Message-ID: <1441204085.99.0.132141943122.issue23630@psf.upfronthosting.co.za> STINNER Victor added the comment: "So I like the idea of supporting multiple ports. It's very cheap to support it." Oh, I had an example in my head: listening on tcp/80 for HTTP and tcp/443 for HTTPS... but it doesn't work. The problem is that the proposed API doesn't allow to specify a protocol factory per port. For such use case, you have to handle multiple servers. Anyway, I still like the idea of listening to multiple hosts and/or multiple ports. It's a common requirement to start a server. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 16:31:58 2015 From: report at bugs.python.org (Yann Sionneau) Date: Wed, 02 Sep 2015 14:31:58 +0000 Subject: [issue23630] support multiple hosts in create_server/start_server In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za> Message-ID: <1441204318.92.0.568915058756.issue23630@psf.upfronthosting.co.za> Yann Sionneau added the comment: About the function's signature to accept multiple hosts & ports, we could - accept host and port arguments being sequences and then we bind to all host:port combinations. Like if len(host) == N and len(port) == M, we bind to N*M sockets. or - accept host and port arguments being sequences and allow repetitions and bind to host:port couples from zip(host, port). I think the first is "clean", but the second allows more flexibility. Like for instance binding to IP1:port1 IP2:port2 but not IP1:port2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 16:35:27 2015 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 02 Sep 2015 14:35:27 +0000 Subject: [issue23630] support multiple hosts in create_server/start_server In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za> Message-ID: <1441204527.73.0.589764597182.issue23630@psf.upfronthosting.co.za> Guido van Rossum added the comment: Let's not extend the API with support for multiple ports. Nobody has asked for it, and clearly the API design is not so simple. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 16:37:11 2015 From: report at bugs.python.org (flying sheep) Date: Wed, 02 Sep 2015 14:37:11 +0000 Subject: [issue7175] Define a standard location and API for configuration files In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za> Message-ID: <1441204631.76.0.458931621446.issue7175@psf.upfronthosting.co.za> flying sheep added the comment: hi mark, i?ve just lengthily replied to you on python-ideas. in short: nope! many command line tools that are relatively new (among them your examples git and pip) honor the specs, my ~/.cache, ~/.config, and ~/.local/share is full of things belonging to libraries, cli tools, my DE, and of course also GUI applications. please let?s continue this discussion on python-ideas if you?re still not convinced ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 16:38:28 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Sep 2015 14:38:28 +0000 Subject: [issue23630] support multiple hosts in create_server/start_server In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za> Message-ID: <1441204708.03.0.814096533591.issue23630@psf.upfronthosting.co.za> Yury Selivanov added the comment: > - accept host and port arguments being sequences and then we bind to all host:port combinations. Like if len(host) == N and len(port) == M, we bind to N*M sockets. I can't think of a real life example for this. But if you need that, you can always implement that on top of function that accepts multiple (host,port) pairs. > - accept host and port arguments being sequences and allow repetitions and bind to host:port couples from zip(host, port). I'm not sure I like this either. This breaks one value `(h,p)` into two values, and passes them in separate collections to separated arguments. Too complex. My proposal is to allow the following: create_server(protofac, [(h1,p1),(h2,p2)]) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 16:41:03 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Sep 2015 14:41:03 +0000 Subject: [issue23630] support multiple hosts in create_server/start_server In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za> Message-ID: <1441204863.03.0.965316834619.issue23630@psf.upfronthosting.co.za> STINNER Victor added the comment: > Let's not extend the API with support for multiple ports. Nobody has asked for it, and clearly the API design is not so simple. Ok. Anyway, the user of the API call call create_server() multiple times, even with the current code. So it's fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 16:45:40 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 02 Sep 2015 14:45:40 +0000 Subject: [issue12006] strptime should implement %G, %V and %u directives In-Reply-To: <1304589823.43.0.534219095158.issue12006@psf.upfronthosting.co.za> Message-ID: <1441205139.99.0.135272547324.issue12006@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 17:54:56 2015 From: report at bugs.python.org (eryksun) Date: Wed, 02 Sep 2015 15:54:56 +0000 Subject: [issue24977] shutil copy to non-existant directory In-Reply-To: <1441106817.15.0.872685605647.issue24977@psf.upfronthosting.co.za> Message-ID: <1441209296.96.0.572331398891.issue24977@psf.upfronthosting.co.za> eryksun added the comment: Do you mean the dst path has a trailing slash, but the directory doesn't exist? shutil.copy doesn't check for a trailing slash, so it attempts to open dst as a regular file. On Linux, and probably most POSIX systems, this results in an EISDIR (is a directory) error. On Windows the error is ERROR_INVALID_NAME, which the CRT maps to EINVAL (invalid argument). ---------- components: +Library (Lib) nosy: +eryksun versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 18:06:50 2015 From: report at bugs.python.org (Tim Tisdall) Date: Wed, 02 Sep 2015 16:06:50 +0000 Subject: [issue24984] document AF_BLUETOOTH socket address formats Message-ID: <1441210010.76.0.198064903239.issue24984@psf.upfronthosting.co.za> New submission from Tim Tisdall: Currently https://docs.python.org/3.6/library/socket.html#socket-families only says "Certain other address families (AF_BLUETOOTH, AF_PACKET, AF_CAN) support specific representations." and there's a comment in the docs saying "document them!"... So, I'm documenting the AF_BLUETOOTH. I'm not sure about which versions this should be added to except for 3.6 so I'm listing the pertinent issues when changes were made: issue929192 seems to be where the current address format was added for L2CAP, RFCOMM, and SCO issue1432399 seems to be where HCI was added issue5510 seems to be where the alternate address format for HCI was added for NetBSD and DragonFlyBSD It seems SCO used to accept a regular string but at 23ab586c427a it was changed to use a `bytes`... I'm not sure the issue behind that. This is my first contribution to CPython so I figured a patch to the docs would be easiest. Please let me know if I'm doing anything wrong! ---------- assignee: docs at python components: Documentation files: bluetooth_socket_docs.patch keywords: patch messages: 249554 nosy: Tim.Tisdall, docs at python priority: normal severity: normal status: open title: document AF_BLUETOOTH socket address formats Added file: http://bugs.python.org/file40320/bluetooth_socket_docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 18:23:10 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 02 Sep 2015 16:23:10 +0000 Subject: [issue24979] Allow timezone offsets greater than 24 hours In-Reply-To: <1441117874.73.0.315873537827.issue24979@psf.upfronthosting.co.za> Message-ID: <1441210990.09.0.694045823999.issue24979@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: The timezone offset range restriction is not arbitrary. It was discussed in issue 5094 (see msg107059 and responses to it.) Nevertheless, there is an open proposal to remove all restrictions on offset values and allow it to be an arbitrary timedelta. See issue 5288, msg248468. I think we should consolidate this issue with #5288. ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 18:26:26 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Sep 2015 16:26:26 +0000 Subject: [issue23630] support multiple hosts in create_server/start_server In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za> Message-ID: <1441211186.42.0.312440715571.issue23630@psf.upfronthosting.co.za> Yury Selivanov added the comment: Yann, I'll commit this as soon as 3.5.0 and 3.4.4 are out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 18:29:29 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 02 Sep 2015 16:29:29 +0000 Subject: [issue24979] Allow timezone offsets greater than 24 hours In-Reply-To: <1441117874.73.0.315873537827.issue24979@psf.upfronthosting.co.za> Message-ID: <1441211369.68.0.471853591794.issue24979@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: BTW, the specific issue that OP complains about is not a datetime issue: apparently pytz has an even tighter restriction on timezone offsets. I am going to close this as a third party issues, but those who support relaxing datetime.timezone restriction to ?24h range are invited to participate in issue 5288 discussion. ---------- resolution: -> third party stage: -> resolved status: open -> closed superseder: -> tzinfo objects with sub-minute offsets are not supported (e.g. UTC+05:53:28) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 19:28:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Sep 2015 17:28:49 +0000 Subject: [issue2786] Names in function call exception should have class names, if they're methods In-Reply-To: <1210191958.85.0.412869826908.issue2786@psf.upfronthosting.co.za> Message-ID: <1441214929.22.0.266030377327.issue2786@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue4322. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 20:13:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Sep 2015 18:13:56 +0000 Subject: [issue23639] Not documented special names In-Reply-To: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za> Message-ID: <1441217636.69.0.94592081854.issue23639@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Clarify documentation of __getinitargs__, __self__ on built-in functions is not as documented _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 20:47:09 2015 From: report at bugs.python.org (David Unric) Date: Wed, 02 Sep 2015 18:47:09 +0000 Subject: [issue24983] Wrong AttributeError propagation In-Reply-To: <1441188888.02.0.100621474433.issue24983@psf.upfronthosting.co.za> Message-ID: <1441219629.86.0.981038973422.issue24983@psf.upfronthosting.co.za> David Unric added the comment: This looks a bit inconsistent. See following version with "manual" getter definition: class MyClass(object): def __init__(self, *args, **kwargs): # setting access to getter by attribute # without use of property decorator self.__dict__['myproperty'] = self._myproperty() def __getattr__(self, name): print('__getattr__ <<', name) raise AttributeError(name) return 'need know the question' def _myproperty(self): print(self.missing_attribute) return 42 my_inst = MyClass() print(my_inst.myproperty) # Produces (expected) output __getattr__ << missing_attribute Traceback (most recent call last): File "a.py", line 55, in my_inst = MyClass() File "a.py", line 33, in __init__ self.__dict__['myproperty'] = self._myproperty() File "a.py", line 48, in _myproperty print(self.missing_attribute) File "a.py", line 37, in __getattr__ raise AttributeError(name) AttributeError: missing_attribute I'd expect the original version using property decorator would behave the same way. Possible issue in property class implementation ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 20:59:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 02 Sep 2015 18:59:18 +0000 Subject: [issue14350] Strange Exception from copying an iterator In-Reply-To: <1332011066.2.0.397754612752.issue14350@psf.upfronthosting.co.za> Message-ID: <1441220358.68.0.979358244716.issue14350@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Actually the tp_new field of list iterator class is NULL. Unpickler raises other error in such case (see issue24900 for example). UnpicklingError: NEWOBJ class argument has NULL tp_new Backported to 2.7 the part of the patch for issue22995 fixes this issue. >>> copy.copy(iter([])) Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython-2.7/Lib/copy.py", line 88, in copy rv = reductor(2) TypeError: can't pickle listiterator objects ---------- dependencies: +Restrict default pickleability nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 21:00:03 2015 From: report at bugs.python.org (Matheus Vieira Portela) Date: Wed, 02 Sep 2015 19:00:03 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> Message-ID: <1441220403.72.0.796371387104.issue23406@psf.upfronthosting.co.za> Matheus Vieira Portela added the comment: I'm attaching a patch to update the stdtypes.rst documentation according to our discussion. I've replaced the table explanation to "equivalent to adding s to itself n times" and added a link to the FAQ entry. I'm not sure, however, where to put the FAQ link. Should it be directly in the table? In this patch, I've put it after the last line of note #2. ---------- keywords: +patch Added file: http://bugs.python.org/file40321/issue23406_doc_stdtypes.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 21:18:22 2015 From: report at bugs.python.org (cburroughs) Date: Wed, 02 Sep 2015 19:18:22 +0000 Subject: [issue13405] Add DTrace probes In-Reply-To: <1321299726.66.0.343368151185.issue13405@psf.upfronthosting.co.za> Message-ID: <1441221502.63.0.0780464699943.issue13405@psf.upfronthosting.co.za> Changes by cburroughs : ---------- nosy: +cburroughs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 21:18:34 2015 From: report at bugs.python.org (cburroughs) Date: Wed, 02 Sep 2015 19:18:34 +0000 Subject: [issue21590] Systemtap and DTrace support In-Reply-To: <1401195995.8.0.935339035852.issue21590@psf.upfronthosting.co.za> Message-ID: <1441221514.1.0.508631991937.issue21590@psf.upfronthosting.co.za> Changes by cburroughs : ---------- nosy: +cburroughs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 21:19:36 2015 From: report at bugs.python.org (cburroughs) Date: Wed, 02 Sep 2015 19:19:36 +0000 Subject: [issue14776] Add SystemTap static markers In-Reply-To: <1336683916.13.0.827403167525.issue14776@psf.upfronthosting.co.za> Message-ID: <1441221576.53.0.833002765574.issue14776@psf.upfronthosting.co.za> Changes by cburroughs : ---------- nosy: +cburroughs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 21:19:44 2015 From: report at bugs.python.org (cburroughs) Date: Wed, 02 Sep 2015 19:19:44 +0000 Subject: [issue4111] Add Systemtap/DTrace probes In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za> Message-ID: <1441221584.75.0.462569505012.issue4111@psf.upfronthosting.co.za> Changes by cburroughs : ---------- nosy: +cburroughs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 21:20:10 2015 From: report at bugs.python.org (David Unric) Date: Wed, 02 Sep 2015 19:20:10 +0000 Subject: [issue24983] Wrong AttributeError propagation In-Reply-To: <1441188888.02.0.100621474433.issue24983@psf.upfronthosting.co.za> Message-ID: <1441221610.45.0.80677998487.issue24983@psf.upfronthosting.co.za> David Unric added the comment: Oops, this was the strict version. The lazy method call version behaves exactly like property getter. So there is probably no implementation bug, but not too well thought out decision design, making debugging AttributeError exceptions in properties difficult and quite misleading. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 21:33:20 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 02 Sep 2015 19:33:20 +0000 Subject: [issue22241] strftime/strptime round trip fails even for UTC datetime object In-Reply-To: <1408620917.6.0.856660367054.issue22241@psf.upfronthosting.co.za> Message-ID: <1441222400.49.0.199285022839.issue22241@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 21:37:53 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 02 Sep 2015 19:37:53 +0000 Subject: [issue24975] Python 3.5 can't compile AST involving PEP 448 unpacking In-Reply-To: <1441069996.63.0.493747155256.issue24975@psf.upfronthosting.co.za> Message-ID: <1441222673.98.0.801691092306.issue24975@psf.upfronthosting.co.za> Larry Hastings added the comment: Merged. Please forward-merge to 3.5.1 and 3.6, thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 21:50:36 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Sep 2015 19:50:36 +0000 Subject: [issue24975] Python 3.5 can't compile AST involving PEP 448 unpacking In-Reply-To: <1441069996.63.0.493747155256.issue24975@psf.upfronthosting.co.za> Message-ID: <20150902195034.14879.98979@psf.io> Roundup Robot added the comment: New changeset e9df8543d7bc by Yury Selivanov in branch '3.5': Issue #24975: Fix AST compilation for PEP 448 syntax. https://hg.python.org/cpython/rev/e9df8543d7bc New changeset ea79be5b201e by Yury Selivanov in branch '3.5': Merge 3.5 heads (issue #24975) https://hg.python.org/cpython/rev/ea79be5b201e New changeset 1dcd7f257ed8 by Yury Selivanov in branch 'default': Merge 3.5 (issue #24975) https://hg.python.org/cpython/rev/1dcd7f257ed8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 21:51:17 2015 From: report at bugs.python.org (William Scullin) Date: Wed, 02 Sep 2015 19:51:17 +0000 Subject: [issue22699] cross-compilation of Python3.4 In-Reply-To: <1413992946.14.0.956103683321.issue22699@psf.upfronthosting.co.za> Message-ID: <1441223477.77.0.732516183459.issue22699@psf.upfronthosting.co.za> Changes by William Scullin : ---------- type: resource usage -> compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 21:51:32 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 02 Sep 2015 19:51:32 +0000 Subject: [issue24975] Python 3.5 can't compile AST involving PEP 448 unpacking In-Reply-To: <1441069996.63.0.493747155256.issue24975@psf.upfronthosting.co.za> Message-ID: <1441223492.28.0.228150568605.issue24975@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks Nick and Larry for code reviews and merge! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 21:58:15 2015 From: report at bugs.python.org (John Nagle) Date: Wed, 02 Sep 2015 19:58:15 +0000 Subject: [issue24985] Python install test fails - OpenSSL - "dh key too small" Message-ID: <1441223895.76.0.826003370838.issue24985@psf.upfronthosting.co.za> New submission from John Nagle: Installing Python 3.4.3 on a new CentOS Linux release 7.1.1503 server. Started with source tarball, did usual ./configure; make; make test SSL test fails with "dh key too small". See below. OpenSSL has recently been modified to reject short keys, due to a security vulnerability. See http://www.ubuntu.com/usn/usn-2639-1/ and see here for an analysis of the issue on a Python install: http://www.alexrhino.net/jekyll/update/2015/07/14/dh-params-test-fail.html Apparently the "dh512.pem" file in the test suite is now obsolete, because the minimum length dh key is now 768. The question is, does this break anything else? Google for "dh key too small" and various other projects report problems. ====================================================================== ERROR: test_dh_params (test.test_ssl.ThreadedTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/sitetruth/private/downloads/python/Python-3.4.3/Lib/test/test_ssl. py", line 2728, in test_dh_params chatty=True, connectionchatty=True) File "/home/sitetruth/private/downloads/python/Python-3.4.3/Lib/test/test_ssl. py", line 1866, in server_params_test s.connect((HOST, server.port)) File "/home/sitetruth/private/downloads/python/Python-3.4.3/Lib/ssl.py", line 846, in connect self._real_connect(addr, False) File "/home/sitetruth/private/downloads/python/Python-3.4.3/Lib/ssl.py", line 837, in _real_connect self.do_handshake() File "/home/sitetruth/private/downloads/python/Python-3.4.3/Lib/ssl.py", line 810, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: SSL_NEGATIVE_LENGTH] dh key too small (_ssl.c:600) ---------------------------------------------------------------------- Ran 99 tests in 12.012s FAILED (errors=1, skipped=4) test test_ssl failed make: *** [test] Error 1 ====================================================================== ---------- components: Installation messages: 249566 nosy: nagle priority: normal severity: normal status: open title: Python install test fails - OpenSSL - "dh key too small" versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 22:30:30 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 02 Sep 2015 20:30:30 +0000 Subject: [issue24986] It should be possible to build successfully without external libraries Message-ID: <1441225829.96.0.402628626785.issue24986@psf.upfronthosting.co.za> New submission from Zachary Ware: We do have the option of leaving out all extension modules ("/p:IncludeExtensions=false"), but it would be nice to be able to build everything that doesn't require external libs. This also be adds an option to skip only Tkinter (analogous to "/p:IncludeSSL=false"), as that's what I actually need at the moment :). I'm not adding options for every external project individually, as most of them are not a big deal, but OpenSSL, Tcl/Tk/Tix, and (on 2.7) bsddb take a long time to compile and might be nice to leave out when they're not needed (so I also added the ability to leave out bsddb on 2.7). Leaving out 3.4 as its project files are not amenable to this kind of change, and 3.4's days are numbered anyway. ---------- assignee: zach.ware components: Build, Windows files: 2.7_external_build_handling.diff keywords: patch messages: 249567 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: patch review status: open title: It should be possible to build successfully without external libraries type: behavior versions: Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40322/2.7_external_build_handling.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 22:30:42 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 02 Sep 2015 20:30:42 +0000 Subject: [issue24986] It should be possible to build successfully without external libraries In-Reply-To: <1441225829.96.0.402628626785.issue24986@psf.upfronthosting.co.za> Message-ID: <1441225842.03.0.0875219200537.issue24986@psf.upfronthosting.co.za> Changes by Zachary Ware : Added file: http://bugs.python.org/file40323/3.5_external_build_handling.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 22:33:46 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 02 Sep 2015 20:33:46 +0000 Subject: [issue24986] It should be possible to build successfully without external libraries In-Reply-To: <1441225829.96.0.402628626785.issue24986@psf.upfronthosting.co.za> Message-ID: <1441226026.02.0.291016054867.issue24986@psf.upfronthosting.co.za> Zachary Ware added the comment: This also changes the behavior of the '-e' flag on build.bat a bit, leaving off '-e' means there will be no attempt to build the modules that require external sources even if the sources are already there. Adding '-e' means building those modules will be attempted, subject to the '--no-' flags. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 22:37:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Sep 2015 20:37:33 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <20150902203730.15726.63307@psf.io> Roundup Robot added the comment: New changeset 0eb8c182131e by Victor Stinner in branch 'default': Issue #23517: datetime.timedelta constructor now rounds microseconds to nearest https://hg.python.org/cpython/rev/0eb8c182131e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 22:50:40 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 02 Sep 2015 20:50:40 +0000 Subject: [issue24913] deque.index() overruns deque boundary In-Reply-To: <1440198546.56.0.00559117738444.issue24913@psf.upfronthosting.co.za> Message-ID: <1441227040.32.0.959265116275.issue24913@psf.upfronthosting.co.za> Larry Hastings added the comment: Assigning to Brett, who has agreed to do the merge to 3.5.0 that Raymond has declined to do. ---------- assignee: larry -> brett.cannon nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 23:01:16 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Sep 2015 21:01:16 +0000 Subject: [issue23965] test_ssl failure on Fedora 22 In-Reply-To: <1429109042.15.0.0394513301498.issue23965@psf.upfronthosting.co.za> Message-ID: <1441227676.28.0.587966496805.issue23965@psf.upfronthosting.co.za> STINNER Victor added the comment: test_ssl is still failing on Fedora 22. I updated Nick's patch (I worked on the default branch). With the patch, test_ssl pass. I didn't try it on other platforms. ---------- nosy: +haypo Added file: http://bugs.python.org/file40324/issue23965_handle_legacy_ssl_peers_disallowed-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 23:03:19 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 02 Sep 2015 21:03:19 +0000 Subject: [issue23965] test_ssl failure on Fedora 22 In-Reply-To: <1429109042.15.0.0394513301498.issue23965@psf.upfronthosting.co.za> Message-ID: <1441227799.43.0.571567832946.issue23965@psf.upfronthosting.co.za> Antoine Pitrou added the comment: As I already said, patch looks fine assuming you've checked it doesn't break mainstream platforms :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 23:10:13 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 02 Sep 2015 21:10:13 +0000 Subject: [issue4322] function with modified __name__ uses original name when there's an arg error In-Reply-To: <1226645058.7.0.820357853432.issue4322@psf.upfronthosting.co.za> Message-ID: <1441228213.09.0.974199208993.issue4322@psf.upfronthosting.co.za> Martin Panter added the comment: Issue 2786 currently proposes to pass __qualname__; if accepted that might also satisfy this report. ---------- dependencies: +Names in function call exception should have class names, if they're methods nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 23:16:28 2015 From: report at bugs.python.org (Georges Racinet) Date: Wed, 02 Sep 2015 21:16:28 +0000 Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?= =?utf-8?q?env_with_--system-site-package?= In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za> Message-ID: <1441228588.63.0.833291288082.issue24875@psf.upfronthosting.co.za> Georges Racinet added the comment: Hi, I have the same symptoms and noticed by accident that you can somewhat workaround it by running pyvenv twice: pyvenv /path/to/env && pyvenv --system-site-packages /path/to/env The first provides pip, the second does not destroy it. At least this works on my Debian 8 installation ---------- nosy: +gracinet _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 23:42:23 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 02 Sep 2015 21:42:23 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> Message-ID: <1441230143.67.0.174640907969.issue23406@psf.upfronthosting.co.za> Martin Panter added the comment: Left some review comments. The positioning of the link to the FAQ entry seems sensible to me, just that the markup could be better :) ---------- nosy: +martin.panter stage: needs patch -> patch review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 2 23:57:44 2015 From: report at bugs.python.org (asduj) Date: Wed, 02 Sep 2015 21:57:44 +0000 Subject: [issue24987] subprocess.Popen with shell=True doesn't create socket Message-ID: <1441231064.17.0.987286732599.issue24987@psf.upfronthosting.co.za> New submission from asduj: I want to run the next command subprocess.Popen("soffice --accept='socket,host=localhost,port=8100;urp;'", shell=True) to make soffice listen localhost:8100. It is work in python 2.7.9, but doesn't in python 3.4.3. I control it by netstat -a | grep 8100 ---------- components: Library (Lib) messages: 249576 nosy: asduj priority: normal severity: normal status: open title: subprocess.Popen with shell=True doesn't create socket versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 00:12:27 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Sep 2015 22:12:27 +0000 Subject: [issue24707] Assertion failed in pymonotonic_new In-Reply-To: <1437753217.88.0.997352550114.issue24707@psf.upfronthosting.co.za> Message-ID: <1441231947.76.0.457360017308.issue24707@psf.upfronthosting.co.za> STINNER Victor added the comment: It occurred on more time on the same buildbot: http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.x/builds/2569/steps/test/logs/stdio ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 00:16:46 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 02 Sep 2015 22:16:46 +0000 Subject: [issue24707] Assertion failed in pymonotonic_new In-Reply-To: <1437753217.88.0.997352550114.issue24707@psf.upfronthosting.co.za> Message-ID: <20150902221641.66860.87770@psf.io> Roundup Robot added the comment: New changeset 4c90b4a4fffa by Victor Stinner in branch '3.5': Issue #24707: Remove assertion in monotonic clock https://hg.python.org/cpython/rev/4c90b4a4fffa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 00:32:46 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 02 Sep 2015 22:32:46 +0000 Subject: [issue24987] subprocess.Popen with shell=True doesn't create socket In-Reply-To: <1441231064.17.0.987286732599.issue24987@psf.upfronthosting.co.za> Message-ID: <1441233166.3.0.467512056772.issue24987@psf.upfronthosting.co.za> Martin Panter added the comment: Can you explain what is working in Python 2.7 that is not working in 3.4? Do you have an exception, error message, relevant netstat output, etc. What platform? I don?t have Open Office on this computer, but I tried the following (Linux) command lines and both did what I expected: "echo --accept='socket,host=localhost,port=8100;urp;'" "sleep 3 && echo done" ---------- nosy: +martin.panter stage: -> test needed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 00:35:00 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 02 Sep 2015 22:35:00 +0000 Subject: [issue24984] document AF_BLUETOOTH socket address formats In-Reply-To: <1441210010.76.0.198064903239.issue24984@psf.upfronthosting.co.za> Message-ID: <1441233300.69.0.162125892009.issue24984@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for the patch and the archeological research. I made some minor grammar nitpicks in the code review. Documentation typically gets applied to all the open branches. In this case 3.4?3.6 should be applicable. Maybe 2.7 also if you are interested; it may need a modified patch though, with different notices about the versions things were introduced. Sounds like most of these addresses were added in 2.4, so no need for a ?New in version? notice unless you add a 2.7 doc patch. But it maybe be useful to mention that the BSD support was added in 3.2. Regarding revision 23ab586c427a (?Renamed PyString to PyBytes?, 2008), I haven?t checked, but you will probably find that was made before Python 3 was released, so it is just one of those differences between Python 2 and 3. ---------- nosy: +martin.panter stage: -> patch review versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 00:55:53 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 02 Sep 2015 22:55:53 +0000 Subject: [issue18383] test_warnings modifies warnings.filters when running with "-W default" In-Reply-To: <1373117774.47.0.846306714059.issue18383@psf.upfronthosting.co.za> Message-ID: <1441234553.94.0.290819407784.issue18383@psf.upfronthosting.co.za> Martin Panter added the comment: Revision c1396d28c440 looks like it may help. Possibly with the 3.5+ assertWarns() half of the problem; I?ll have to have a closer look later. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 01:10:11 2015 From: report at bugs.python.org (Mark Roseman) Date: Wed, 02 Sep 2015 23:10:11 +0000 Subject: [issue24988] IDLE: debugger context menus not working on Mac Message-ID: <1441235411.2.0.839528084251.issue24988@psf.upfronthosting.co.za> New submission from Mark Roseman: Right menu button to invoke context menu (as well as alternative control-click) not set up correctly for Mac in the debugger. Patch attached. ---------- components: IDLE files: debug-mac-context-menu.patch keywords: patch messages: 249582 nosy: kbk, markroseman, roger.serwy, terry.reedy priority: normal severity: normal status: open title: IDLE: debugger context menus not working on Mac type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40325/debug-mac-context-menu.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 01:34:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Sep 2015 23:34:10 +0000 Subject: [issue18383] test_warnings modifies warnings.filters when running with "-W default" In-Reply-To: <1373117774.47.0.846306714059.issue18383@psf.upfronthosting.co.za> Message-ID: <1441236850.11.0.554797665782.issue18383@psf.upfronthosting.co.za> STINNER Victor added the comment: > Revision c1396d28c440 looks like it may help. Possibly with the 3.5+ assertWarns() half of the problem; I?ll have to have a closer look later. Oh, I wasn't aware of this issue. Good to know that I contributed to it :-) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 01:40:26 2015 From: report at bugs.python.org (John Leitch) Date: Wed, 02 Sep 2015 23:40:26 +0000 Subject: [issue24989] scan_eol() Buffer Over-read Message-ID: <1441237226.71.0.655654379606.issue24989@psf.upfronthosting.co.za> New submission from John Leitch: Python 3.5 suffers from a vulnerability caused by the behavior of the scan_eol() function. When called, the function gets a line from the buffer of a BytesIO object by searching for a newline character starting at the position in the buffer. However, if the position is set to a value that is larger than the buffer, this logic will result in a call to memchr that reads off the end of the buffer: /* Move to the end of the line, up to the end of the string, s. */ start = PyBytes_AS_STRING(self->buf) + self->pos; maxlen = self->string_size - self->pos; if (len < 0 || len > maxlen) len = maxlen; if (len) { n = memchr(start, '\n', len); In some applications, it may be possible to exploit this behavior to disclose the contents of adjacent memory. The buffer over-read can be observed by running the following script: import tempfile a = tempfile.SpooledTemporaryFile() a.seek(0b1) a.readlines() Which, depending on the arrangement of memory, may produce an exception such as this: 0:000> g (698.188): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=fff8a14c ebx=0a0a0a0a ecx=00000000 edx=05bb1000 esi=061211b0 edi=89090909 eip=61c6caf2 esp=010af8dc ebp=010af914 iopl=0 nv up ei ng nz ac po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010292 python35!memchr+0x62: 61c6caf2 8b0a mov ecx,dword ptr [edx] ds:002b:05bb1000=???????? 0:000> k1 ChildEBP RetAddr 010af8e0 61b640f1 python35!memchr+0x62 [f:\dd\vctools\crt_bld\SELF_X86\crt\src\INTEL\memchr.asm @ 125] To fix this issue, it is recommended that scan_eol() be updated to check that the position is not greater than or equal to the size of the buffer. A proposed patch is attached. ---------- files: scan_eol_Buffer_Over-read.patch keywords: patch messages: 249584 nosy: JohnLeitch, brycedarling priority: normal severity: normal status: open title: scan_eol() Buffer Over-read type: security versions: Python 3.5 Added file: http://bugs.python.org/file40326/scan_eol_Buffer_Over-read.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 01:40:38 2015 From: report at bugs.python.org (John Leitch) Date: Wed, 02 Sep 2015 23:40:38 +0000 Subject: [issue24989] scan_eol() Buffer Over-read In-Reply-To: <1441237226.71.0.655654379606.issue24989@psf.upfronthosting.co.za> Message-ID: <1441237238.8.0.00242620837684.issue24989@psf.upfronthosting.co.za> Changes by John Leitch : Added file: http://bugs.python.org/file40327/scan_eol_Buffer_Over-read.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 01:46:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Sep 2015 23:46:17 +0000 Subject: [issue24989] scan_eol() Buffer Over-read In-Reply-To: <1441237226.71.0.655654379606.issue24989@psf.upfronthosting.co.za> Message-ID: <1441237577.11.0.297143338071.issue24989@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 01:47:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 02 Sep 2015 23:47:10 +0000 Subject: [issue24707] Assertion failed in pymonotonic_new In-Reply-To: <1437753217.88.0.997352550114.issue24707@psf.upfronthosting.co.za> Message-ID: <1441237630.7.0.835415835069.issue24707@psf.upfronthosting.co.za> STINNER Victor added the comment: I removed the assertion. Thanks for your report! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 01:55:39 2015 From: report at bugs.python.org (Al Sweigart) Date: Wed, 02 Sep 2015 23:55:39 +0000 Subject: [issue24990] Foreign language support in turtle module Message-ID: <1441238139.14.0.540040388391.issue24990@psf.upfronthosting.co.za> New submission from Al Sweigart: I'd like to propose adding foreign language names for the names in the turtle module. This would effectively take this code: import turtle t = turtle.Pen() t.pencolor('green') t.forward(100) ...and have this code in French be completely equivalent: import turtle t = turtle.Plume() t.couleurplume('vert') t.avant(100) (Pardon my google-translate French.) This would be built into the turtle module (the "turtle" name itself would be unchanged). They would be available no matter what the OS's localization settings were set to. This, of course, is terrible way for a software module to implement internationalization, which usually does not apply to the source code names itself. But I'd like to explain why the turtle module is different. The turtle module is not used for professional software development, but instead as a teaching tool for children. While professional developers are expected to obtain proficiency with English, the same does not apply to school kids who are just taking a small computer programming unit. Having the turtle module available in their native language would remove a large barrier and let them focus on the core programming concepts that turtle provides. The popular Scratch tool has a similar internationalized setup and also has LOGO-style commands, so the translation work is already done. Technically, it would be possible to mix multiple natural languages in the same program. This would be a bad practice, but I also don't see it as a common one. The color strings (e.g. 'green') are tk-dependent, but this can be worked around in the turtle module without requiring changes to tk. ---------- components: Library (Lib) messages: 249586 nosy: Al.Sweigart priority: normal severity: normal status: open title: Foreign language support in turtle module type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 01:57:55 2015 From: report at bugs.python.org (Al Sweigart) Date: Wed, 02 Sep 2015 23:57:55 +0000 Subject: [issue24990] Foreign language support in turtle module In-Reply-To: <1441238139.14.0.540040388391.issue24990@psf.upfronthosting.co.za> Message-ID: <1441238275.03.0.915535534331.issue24990@psf.upfronthosting.co.za> Al Sweigart added the comment: I volunteer to produce the patch. I know Bryson's "Teach Your Kids to Code" book (which features Python's turtle module) hasn't been translated to other languages yet. It would be nice to get this committed sooner rather than later. I'm open to ideas for expanding documentation of turtle to other languages. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 04:03:47 2015 From: report at bugs.python.org (Cory Benfield) Date: Thu, 03 Sep 2015 02:03:47 +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: <1441245827.54.0.362837326177.issue17849@psf.upfronthosting.co.za> Cory Benfield added the comment: Martin: as noted in the comments on this issue, I believed the specific test case did not match any of the problems people were encountering: it was just the least bad way to trigger the specific flow that was being encountered. In practice for these issues it's likely some other error condition is involved. Regardless, Python 2.7 claims to support HTTP/0.9, which certainly allows for proxies to not send a status line, so the test case is a reasonable example of what should be supported by httplib. I'll take another run at this patch to see if I can clean it up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 04:06:29 2015 From: report at bugs.python.org (Christoph Gohlke) Date: Thu, 03 Sep 2015 02:06:29 +0000 Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za> Message-ID: <1441245989.4.0.915325218206.issue24872@psf.upfronthosting.co.za> Christoph Gohlke added the comment: > Do you know where that time is being spent? The incremental linker. > I'd guess it's probably O(N**2) with the number of obj file Doesn't seem so. For example the pyrxp 2.1 package contains only 23 C files and takes minutes to link. Most packages compile and link reasonably fast. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 04:09:26 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Sep 2015 02:09:26 +0000 Subject: [issue21192] Idle: Print filename when running a file from editor In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za> Message-ID: <20150903020922.66878.33974@psf.io> Roundup Robot added the comment: New changeset 69ea73015132 by Terry Jan Reedy in branch '2.7': Issue #21192: Change 'RUN' back to 'RESTART' when running editor file. https://hg.python.org/cpython/rev/69ea73015132 New changeset 130a3edcac1d by Terry Jan Reedy in branch '3.4': Issue #21192: Change 'RUN' back to 'RESTART' when running editor file. https://hg.python.org/cpython/rev/130a3edcac1d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 04:16:11 2015 From: report at bugs.python.org (Christoph Gohlke) Date: Thu, 03 Sep 2015 02:16:11 +0000 Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za> Message-ID: <1441246571.09.0.361271030949.issue24872@psf.upfronthosting.co.za> Christoph Gohlke added the comment: I have now recompiled hundreds of Python packages and C/C++/Fortran libraries with the `/MT /GL /LTCG /NODEFAULTLIB:libucrt.lib ucrt.lib` flags. Many packages test OK, only few crashes. Some more findings: The /MT flag forces to also statically link the Intel Fortran runtime library. Some libraries, e.g. OpenCV and Boost DLLs, can not be built with those flags (must be /MD). Although most packages pass unittests (numpy, scipy, matplotlib, etc.), running real world scripts, Pandas unit tests, or simple scripts in IPython notebook, fail semi-randomly with "ImportError: DLL load failed: A dynamic link library (DLL) initialization routine failed". This is reproducible with Python 3.5.0rc2, 64 and 32 bit, on Windows 10 and 7, 64 bit. It seems to be related to the number of extensions and DLLs loaded into the process. This needs more testing. Is there still a limit of how many DLLs, which are statically-linked to the CRT, can be loaded? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 04:21:30 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 03 Sep 2015 02:21:30 +0000 Subject: [issue21192] Idle: Print filename when running a file from editor In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za> Message-ID: <1441246890.12.0.926865094909.issue21192@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Larry, please pull @restart.diff into 3.5.0. I have already applied it to 2.7, 3.4, 3.5.1, and 3.6, so I will null merge from 3.5.0 into 3.5.1 and 3.6. Reason. Aside from Raymond's request above, I was reminded about a week ago that a) when Idle runs in one process, running a file from the editor does *not* cause a restart, and b) we might want to add the option to not restart even when running with two processes. So I agree with Raymond that Idle should say RESTART (or the equivalent) when restarting the execution process and not say it when not, and that 3.5.0 should be consistent with other releases, and not make a change that is reverted in 3.5.1. ---------- nosy: +benjamin.peterson, larry priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 04:29:46 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 03 Sep 2015 02:29:46 +0000 Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za> Message-ID: <1441247386.52.0.444957120871.issue24872@psf.upfronthosting.co.za> Steve Dower added the comment: It may be possible to dynamically link the Fortran library in a similar fashion, though it depends on what code the compiler generates. For Python's purposes, statically linking it probably isn't a bad idea. I'll have to check out whether the FLS limitation still applies, but it seems likely. I wasn't aware of it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 04:39:56 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 03 Sep 2015 02:39:56 +0000 Subject: [issue24913] deque.index() overruns deque boundary In-Reply-To: <1440198546.56.0.00559117738444.issue24913@psf.upfronthosting.co.za> Message-ID: <1441247996.11.0.903555036551.issue24913@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks Brett :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 04:53:04 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 03 Sep 2015 02:53:04 +0000 Subject: [issue24988] IDLE: debugger context menus not working on Mac In-Reply-To: <1441235411.2.0.839528084251.issue24988@psf.upfronthosting.co.za> Message-ID: <1441248784.85.0.411622307854.issue24988@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Ned, can you check this Idle-Mac patch? I presume the same code is used elsewhere. It might be nice to encapsulate it sometime, though I am not sure where to put a context-bind function. ---------- nosy: +ned.deily stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 04:54:52 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 03 Sep 2015 02:54:52 +0000 Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za> Message-ID: <1441248892.75.0.476270510655.issue24872@psf.upfronthosting.co.za> Steve Dower added the comment: The FLS limit is definitely still there, and it still seems to be 127, which would explain the issues. Best fix I have for this is to build with /MD and force vcruntimeXXX.dll to always be copied alongside builds. That will solve the installation issue and the DLL limit, at the cost of complicating licensing and bundling for packages. (The DLL *should* only be loaded once, even if it appears in multiple locations.) I don't think this is necessarily a release blocker though. It may just be better for specific packages to do it - e.g. numpy could include whichever vcruntime DLL was used to at least satisfy all of its PYDs on any Python version. If someone happens to have matched builds of numpy/scipy/pandas (which seems fairly likely) and they're all /MD and bundle vcruntime then that's one FLS index for a decent number of DLLs. A "better" solution might involve a pip extension that can detect which VC redist version is required when extracting a wheel and download/install it for the user (I considered proposing this closer to Python's core, but it really needs to be at download/install time and not load time). Package distros and "packs" are likely to be in a position to distribute the dependencies they need and can avoid it. Unfortunately, I don't see a way to do that from core without effectively restricting the VC version for most people. Hopefully one day I'll get to deal with some easy problems... :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 04:55:14 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 03 Sep 2015 02:55:14 +0000 Subject: [issue24988] IDLE: debugger context menus not working on Mac In-Reply-To: <1441235411.2.0.839528084251.issue24988@psf.upfronthosting.co.za> Message-ID: <1441248914.83.0.549271859877.issue24988@psf.upfronthosting.co.za> Terry J. Reedy added the comment: 'Goto source line' works on Win7. Show stackframe does not do anything that I can see, and seems perhaps redundant. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 05:15:08 2015 From: report at bugs.python.org (Cory Benfield) Date: Thu, 03 Sep 2015 03:15:08 +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: <1441250108.19.0.517680300013.issue17849@psf.upfronthosting.co.za> Cory Benfield added the comment: Ok, new patch now attached. ---------- Added file: http://bugs.python.org/file40328/readline_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 05:22:36 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 03 Sep 2015 03:22:36 +0000 Subject: [issue18383] test_warnings modifies warnings.filters when running with "-W default" In-Reply-To: <1373117774.47.0.846306714059.issue18383@psf.upfronthosting.co.za> Message-ID: <1441250556.38.0.399638864749.issue18383@psf.upfronthosting.co.za> Martin Panter added the comment: Okay so I take back my first proposal of restoring the filters in the test suite, which would bring us back to . Also, my second proposal of setting a flag doesn?t look so easy either. The ?_warnings? C module caches the filters list in a static variable between module reloads, so it is not so easy to keep a flag recording whether the ?warnings? Python module needs to initialize it. I started on a patch, but discovered I would have to make uncomfortable changes to the C module. So unless anyone has any better ideas, I think Alex?s patch is as good and practical enough. And yes Victor?s change does fix the other half of the problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 05:58:34 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 03 Sep 2015 03:58:34 +0000 Subject: [issue24989] scan_eol() Buffer Over-read In-Reply-To: <1441237226.71.0.655654379606.issue24989@psf.upfronthosting.co.za> Message-ID: <1441252714.16.0.12124601453.issue24989@psf.upfronthosting.co.za> Martin Panter added the comment: Simpler test case, which might find a place somewhere like /Lib/test/test_memoryio.py: >>> from io import BytesIO >>> b = BytesIO() >>> b.seek(1) 1 >>> b.readlines() # Should return an empty list Segmentation fault (core dumped) [Exit 139] The patch looks like the right approach. Just watch out for the indentation (tabs vs spaces). However I don?t see why we need the GET_BYTES_SIZE() macro or the (size_t) casting. Would it be okay comparing PyBytes_GET_SIZE() directly to self->pos? They are both meant to be Py_ssize_t. The bug looks like it was introduced by Serhiy?s changes in Issue 15381. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 05:58:49 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Sep 2015 03:58:49 +0000 Subject: [issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model In-Reply-To: <1441057022.82.0.924513920263.issue24974@psf.upfronthosting.co.za> Message-ID: <1441252729.29.0.282075102248.issue24974@psf.upfronthosting.co.za> Zachary Ware added the comment: As far as I can tell, this patch fixes the issue and doesn't break anything. Independent verification of that assertion would be lovely :) For the record, I was able to reproduce the issue on one of the Windows Server 2012 R2 machines after installing ICC 16.0. Weirdly, after that installation, the problem reproduces with both ICC 15.0 and 16.0. I'm not sure why it compiled with ICC 15.0 before installing 16.0, although guessing from what the 16.0 installer was saying it replaced 15's VS 2015 integration with its own, so 15's may have had some bug in this area. ---------- keywords: +patch priority: low -> normal stage: test needed -> patch review Added file: http://bugs.python.org/file40329/_decimal_fp_precise_pragma.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 06:31:34 2015 From: report at bugs.python.org (John Leitch) Date: Thu, 03 Sep 2015 04:31:34 +0000 Subject: [issue24989] scan_eol() Buffer Over-read In-Reply-To: <1441237226.71.0.655654379606.issue24989@psf.upfronthosting.co.za> Message-ID: <1441254694.05.0.0662894194538.issue24989@psf.upfronthosting.co.za> John Leitch added the comment: We based our fix on the check in write_bytes: if (endpos > (size_t)PyBytes_GET_SIZE(self->buf)) { if (resize_buffer(self, endpos) < 0) return -1; } I see now that our casting was extraneous. As for the macro, it was suspected that similar issues may be present and we wanted to write reusable code, but this also seems unnecessary now that it's known the cast is unneeded. Early tomorrow I'll take some time to create a revised patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 06:40:22 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 03 Sep 2015 04:40:22 +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: <1441255222.9.0.491016944884.issue17849@psf.upfronthosting.co.za> Martin Panter added the comment: I still don?t think the test case is a reasonable example. According to , HTTP 0.9 only supported GET, not CONNECT, and doesn?t include any header fields in the protocol (such as your X-Foo: bar). It would make more sense to me to adjust the check at to also check for version == "HTTP/0.9". That would probably eliminate the need to mess too much with the details of the LineAndFileWrapper class. But if you wanted to parse the CONNECT response as a HTTP 0.9 response, I think you should not try to parse any header, because that will tend to skip over the start of the actual response. Also, I assume the change to ?configure? is unrelated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 06:47:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Sep 2015 04:47:23 +0000 Subject: [issue24989] scan_eol() Buffer Over-read In-Reply-To: <1441237226.71.0.655654379606.issue24989@psf.upfronthosting.co.za> Message-ID: <1441255643.16.0.391123564531.issue24989@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka priority: normal -> high versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 07:57:02 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 03 Sep 2015 05:57:02 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441259822.08.0.576222704393.issue24912@psf.upfronthosting.co.za> Nick Coghlan added the comment: I've reviewed the patch, and it looks good to me. Key additions: * truly immutable types (instances of which may be cached) are now explicitly checked in the test suite to ensure they don't support __class__ assignment, even to a subclass * the check for non-heaptypes in __class__ assignment has been restored, with a hardcoded whitelist to bypass that check. The only type on the whitelist for 3.5 is PyModuleType. Thus, this patch will also serve to protect any extension types that were relying on the non-heaptype check to prevent __class__ assignment. The patch also includes a long block comment before the restored check for non-heap types that explains the history and links out to this issue. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 08:08:03 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 03 Sep 2015 06:08:03 +0000 Subject: [issue24991] Define instance mutability explicitly on type objects Message-ID: <1441260483.41.0.785006760825.issue24991@psf.upfronthosting.co.za> New submission from Nick Coghlan: Issue #24912 showed that the interpreter has historically assumed that all instances of non-heap types are immutable when it comes to preventing __class__ reassignment, and changing this assumption caused problems with genuinely immutable types that use implicit instance caching (like string interning and the small integrer cache). More generally, whether or not type instances are mutable or not has been defined somewhat informally - decimal.Decimal instances, for example, are nominally immutable, but this immutability is only by convention, rather than enforced by the interpreter. It may be desirable to be able to explicitly declare instances of a type as mutable or immutable (both from Python and from C), rather than having that property be inferred from other characteristics in a situational way. ---------- messages: 249605 nosy: ncoghlan, njs priority: normal severity: normal status: open title: Define instance mutability explicitly on type objects versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 08:10:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Sep 2015 06:10:40 +0000 Subject: [issue24989] scan_eol() Buffer Over-read In-Reply-To: <1441237226.71.0.655654379606.issue24989@psf.upfronthosting.co.za> Message-ID: <1441260640.34.0.307037042921.issue24989@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It should be self->string_size, not PyBytes_GET_SIZE(self->buf). Thank you for your report and your patch John. Here is revised patch with tests based on Martin's test. Larry, perhaps this bug is grave enough to be fixed in RC3. ---------- components: +Extension Modules, IO stage: -> patch review Added file: http://bugs.python.org/file40330/scan_eol_Buffer_Over-read_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 08:11:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Sep 2015 06:11:06 +0000 Subject: [issue24989] scan_eol() Buffer Over-read In-Reply-To: <1441237226.71.0.655654379606.issue24989@psf.upfronthosting.co.za> Message-ID: <1441260666.31.0.379927004617.issue24989@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 08:12:28 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 03 Sep 2015 06:12:28 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441260748.75.0.286931155773.issue24912@psf.upfronthosting.co.za> Nick Coghlan added the comment: I've filed issue 24991 to suggest reviewing the wider question of how we deal with identifying whether or not a type's instances are expected to be "truly immutable" in the Python 3.6 time frame. For 3.5, I think Nathaniel's proposed patch restoring the assumption that non-heap types are immutable by default, and whitelisting __class__ assignment for PyModuleType specifically is a good way to resolve this with minimal code churn late in the release cycle. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 08:25:42 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Sep 2015 06:25:42 +0000 Subject: [issue23375] test_py3kwarn fails on Windows In-Reply-To: <1422861689.06.0.83900503025.issue23375@psf.upfronthosting.co.za> Message-ID: <1441261542.74.0.185255737607.issue23375@psf.upfronthosting.co.za> Zachary Ware added the comment: Could this have anything to do with the fact that imageop is a 'built-in' (as opposed to 'extension') module on Windows? Either way, I'm about ready to just skip testing the warning for that module on Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 08:51:24 2015 From: report at bugs.python.org (asduj) Date: Thu, 03 Sep 2015 06:51:24 +0000 Subject: [issue24987] subprocess.Popen with shell=True doesn't create socket In-Reply-To: <1441231064.17.0.987286732599.issue24987@psf.upfronthosting.co.za> Message-ID: <1441263084.8.0.472873764952.issue24987@psf.upfronthosting.co.za> asduj added the comment: After executing this code in Python 2.7 I check if OpenOffice is listening the localhost:8100, and get the output: netstat -a | grep 8100 tcp 0 0 localhost:8100 *:* LISTEN If I executing the same code in Python 3.4 and check, I get nothing. Platform: Ubuntu 15.04. In fact, command runs any office installed on the computer (LibreOffice or OpenOffice), and on my computer I have LibreOffice. There are no messages, the command runs normal, just not working as it should. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 08:54:41 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 06:54:41 +0000 Subject: [issue24989] scan_eol() Buffer Over-read In-Reply-To: <1441237226.71.0.655654379606.issue24989@psf.upfronthosting.co.za> Message-ID: <1441263281.1.0.849779691533.issue24989@psf.upfronthosting.co.za> STINNER Victor added the comment: scan_eol_Buffer_Over-read_2.patch looks good to me. > Larry, perhaps this bug is grave enough to be fixed in RC3. Since it looks like a regression in Python 3.5, yes, it's a severe bug. Please send a pull request to Larry for it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 09:14:37 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Sep 2015 07:14:37 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <20150903071432.114986.83192@psf.io> Roundup Robot added the comment: New changeset bf634dfe076f by Victor Stinner in branch 'default': Issue #23517: fromtimestamp() and utcfromtimestamp() methods of https://hg.python.org/cpython/rev/bf634dfe076f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 09:28:48 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Thu, 03 Sep 2015 07:28:48 +0000 Subject: [issue24991] Define instance mutability explicitly on type objects In-Reply-To: <1441260483.41.0.785006760825.issue24991@psf.upfronthosting.co.za> Message-ID: <1441265328.29.0.912726372777.issue24991@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Adding Eric Snow to nosy because it seems like there may be some natural overlap between this and the per-subinterpreter GIL ideas he brought up on python-ideas back in June. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 09:37:44 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 07:37:44 +0000 Subject: [issue23375] test_py3kwarn fails on Windows In-Reply-To: <1422861689.06.0.83900503025.issue23375@psf.upfronthosting.co.za> Message-ID: <1441265864.91.0.332611839583.issue23375@psf.upfronthosting.co.za> STINNER Victor added the comment: > I can't reproduce the failure on Linux. Do you have a 64-bit system? imageop is only built on 32-bit systems... > Looks like a test ordering issue. When test_imageop runs before test_py3kwarn, the warning has presumably already been shown once and so isn't triggered when the test is looking for it (compare build 3092 linked above with 3093, which passed). Yes, I already investigated this issue and I found the same root cause. A Python module implemented in C like imageop cannot be reloaded twice. In fact, it can never be unloaded. Since the warning is emited when the module is loaded, the warning will only be emited once. The issue is not specific to imageop: test_optional_module_removals() must fail on any module implemented in C if the module was already loaded before the test is executed. > Either way, I'm about ready to just skip testing the warning for that module on Windows. The correct fix is to skip the test if the module was already loaded and if the module is implemented in C. Attached patch implements this fix. I don't know how to test if a module is implemented in C or not. I chose to check if its filename ends with ".py" (or .pyc or .pyo). ---------- keywords: +patch nosy: +haypo Added file: http://bugs.python.org/file40331/test_py3kwarn.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 09:38:33 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 07:38:33 +0000 Subject: [issue23375] test_py3kwarn fails on Windows In-Reply-To: <1422861689.06.0.83900503025.issue23375@psf.upfronthosting.co.za> Message-ID: <1441265913.79.0.995604759647.issue23375@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file40331/test_py3kwarn.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 09:38:39 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 07:38:39 +0000 Subject: [issue23375] test_py3kwarn fails on Windows In-Reply-To: <1422861689.06.0.83900503025.issue23375@psf.upfronthosting.co.za> Message-ID: <1441265919.55.0.460965743675.issue23375@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file40332/test_py3kwarn-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 09:43:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 07:43:17 +0000 Subject: [issue23375] test_py3kwarn fails on Windows In-Reply-To: <1422861689.06.0.83900503025.issue23375@psf.upfronthosting.co.za> Message-ID: <1441266197.88.0.685952540503.issue23375@psf.upfronthosting.co.za> STINNER Victor added the comment: To easily test my patch, you can inject a Python 3 DeprecationWarning in the unicodedata module using attached unicodedata.patch, and then modify Lib/test/test_py3kwarn.py to add "unicodedata" to the "optional_modules" list. I tested my patch on Linux (Fedora 22, 64-bit system). ---------- Added file: http://bugs.python.org/file40333/unicodedata.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 10:09:09 2015 From: report at bugs.python.org (Christoph Gohlke) Date: Thu, 03 Sep 2015 08:09:09 +0000 Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za> Message-ID: <1441267749.61.0.503825924591.issue24872@psf.upfronthosting.co.za> Christoph Gohlke added the comment: Just to confirm: the following script fails with `ImportError: DLL load failed` on Python 3.5.0rc2. It fails around the 120th extension. The script passes on Python 3.4.3. Also, Python 3.5.0rc2 (not Python 3.4.3) requires the `extra_postargs=['/DLL']` argument to the `link_shared_lib` function, otherwise the linker fails with `LINK : fatal error LNK1561: entry point must be defined`. ``` # test_issue24872.py # # Build up to 256 C extension modules and import them. # # On Python 3.5.0rc2 for Windows this raises "ImportError: DLL load failed: # A dynamic link library (DLL) initialization routine failed." # # http://bugs.python.org/issue24872 import os import sys from importlib import import_module from distutils import ccompiler assert sys.platform == 'win32' assert sys.version_info > (3, 2) c_source = """/* Minimal Python 3 extension module */ #include "Python.h" static struct PyModuleDef moduledef = { PyModuleDef_HEAD_INIT, "%s", NULL, -1, NULL, NULL, NULL, NULL, NULL }; PyMODINIT_FUNC PyInit_%s(void) { return PyModule_Create(&moduledef); } """ cl = ccompiler.new_compiler() for i in range(256): name = '_tmp%.3i' % i try: os.remove(name+'.pyd') except FileNotFoundError: pass with open(name+'.c', 'w') as fh: fh.write(c_source % (name, name)) objects = cl.compile([name+'.c']) cl.link_shared_lib(objects, output_libname=name, extra_postargs=['/DLL'], export_symbols=["PyInit_"+name]) for ext in 'c', 'obj', 'exp', 'lib': os.remove(name+'.'+ext) os.rename(name+'.dll', name+'.pyd') import_module(name) ``` ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 10:18:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Sep 2015 08:18:28 +0000 Subject: [issue23375] test_py3kwarn fails on Windows In-Reply-To: <1422861689.06.0.83900503025.issue23375@psf.upfronthosting.co.za> Message-ID: <1441268308.13.0.378246206128.issue23375@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The approach LGTM. I left comments on Rietveld. ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 10:25:31 2015 From: report at bugs.python.org (Larry Hastings) Date: Thu, 03 Sep 2015 08:25:31 +0000 Subject: [issue24989] scan_eol() Buffer Over-read In-Reply-To: <1441237226.71.0.655654379606.issue24989@psf.upfronthosting.co.za> Message-ID: <1441268731.65.0.828699140261.issue24989@psf.upfronthosting.co.za> Larry Hastings added the comment: Yes, please create a pull request for this patch. Thanks! And just to confirm: I just applied patch 2 to CPython, then undid the change to bytesio.c. The new test fails, and sometimes Python will segmentation fault. If I then apply the patch to bytesio.c it passes. Nice work! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 10:25:36 2015 From: report at bugs.python.org (Larry Hastings) Date: Thu, 03 Sep 2015 08:25:36 +0000 Subject: [issue24989] scan_eol() Buffer Over-read In-Reply-To: <1441237226.71.0.655654379606.issue24989@psf.upfronthosting.co.za> Message-ID: <1441268736.43.0.448570966466.issue24989@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- priority: high -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 10:27:07 2015 From: report at bugs.python.org (Larry Hastings) Date: Thu, 03 Sep 2015 08:27:07 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441268827.42.0.347450654713.issue24912@psf.upfronthosting.co.za> Larry Hastings added the comment: Mark, Victor, Benjamin: how do you feel about v2 patch vs rolling back the change entirely? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 10:31:06 2015 From: report at bugs.python.org (Larry Hastings) Date: Thu, 03 Sep 2015 08:31:06 +0000 Subject: [issue21192] Idle: Print filename when running a file from editor In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za> Message-ID: <1441269066.76.0.643054582363.issue21192@psf.upfronthosting.co.za> Larry Hastings added the comment: Terry, if you want this pulled in to Python 3.5.0, you'll need to create a pull request on Bitbucket. Instructions are here: https://mail.python.org/pipermail/python-dev/2015-August/141167.html and here: https://mail.python.org/pipermail/python-dev/2015-August/141365.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 10:49:23 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Sep 2015 08:49:23 +0000 Subject: [issue23375] test_py3kwarn fails on Windows In-Reply-To: <1422861689.06.0.83900503025.issue23375@psf.upfronthosting.co.za> Message-ID: <20150903084921.17987.34037@psf.io> Roundup Robot added the comment: New changeset d739bc20d7b2 by Victor Stinner in branch '2.7': Issue #23375: Fix test_py3kwarn for modules implemented in C https://hg.python.org/cpython/rev/d739bc20d7b2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 10:50:00 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 08:50:00 +0000 Subject: [issue23375] test_py3kwarn fails on Windows In-Reply-To: <1422861689.06.0.83900503025.issue23375@psf.upfronthosting.co.za> Message-ID: <1441270200.27.0.815892325294.issue23375@psf.upfronthosting.co.za> STINNER Victor added the comment: > The approach LGTM. I left comments on Rietveld. Thanks for the review. I replaced warnings.warn() with a simple print(). This issue should now be fixed. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 10:53:37 2015 From: report at bugs.python.org (Larry Hastings) Date: Thu, 03 Sep 2015 08:53:37 +0000 Subject: [issue24305] The new import system makes it inconvenient to correctly issue a deprecation warning for a module In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za> Message-ID: <1441270417.8.0.0843656576731.issue24305@psf.upfronthosting.co.za> Larry Hastings added the comment: Well, this is making me nervous to apply during the RCs. But... I'm willing to risk it. My price: I want to see this run on a bunch of otherwise-healthy buildbots to make sure it doesn't break any platforms. In case you've never done such a thing, here's how: create a "server-side clone" on hg.python.org, apply the patch to that tree, and push to the server-side clone. Then grab a fistful of URLs to "custom" buildbots from here: http://buildbot.python.org/all/waterfall and visit each individual page, e.g. http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%20custom and use the "Force Build" GUI at the bottom to kick off a build using the server-side clone with the patch applied. Nathaniel: If Brett doesn't have the time to deal with this, I can make the server-side clone and check in the patch onto it. You can then kick off the builds and report back the results. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 11:28:43 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Thu, 03 Sep 2015 09:28:43 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441272523.27.0.228040740293.issue24912@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Since I know there's a lot of text here for people to process, here's an attempted TL;DR (with inspiration from Serhiy's msg249495): There were three parts to the original change: 1) Bug fixes for typeobject.c 2) Enabling __class__ assignment for module objects 3) Enabling __class__ assignment for other objects, in particular all non-heap types, including 'int', 'str', etc. Everyone agrees we want to revert (3), which is the bit that has caused all the problems. And I don't think anyone has argued for reverting (1) after learning that it is separable from the rest. So the main question still under discussion is whether we want to revert (2)+(3), or just revert (3) alone. (Either of these is easy to do; the attached "v2" patch implements the revert (3) alone option.) My position: When making changes for rc3 (!), we should definitely revert any functionality that is breaking things, and should definitely not revert any functionality that isn't. The (3) change obviously meets this bar, so we'll revert it. But when it comes to module objects specifically -- the (2) change -- then (AFAICT) no-one has identified any problem with the functionality itself, even though it's been specifically discussed and reviewed multiple times over the last year, and been enabled all the way through the pre-release with explicit tests provided, etc. The only argument I see raised against it here is that there might be some more-or-less-equivalent but maybe-more-aesthetic way of accomplishing the same thing, so maybe we should revert it now so we can get in another round of bikeshedding. And if this had been raised a few months ago I'd have been sympathetic... but IMO the rc3 release is too late to be churning functionality based purely on aesthetics, so I think we should revert (3) alone, while leaving (1)+(2) in place. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 11:34:48 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 03 Sep 2015 09:34:48 +0000 Subject: [issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model In-Reply-To: <1441057022.82.0.924513920263.issue24974@psf.upfronthosting.co.za> Message-ID: <1441272888.53.0.995386079967.issue24974@psf.upfronthosting.co.za> Stefan Krah added the comment: Are you sure that you always tested the 32-bit build, also with ICC 15.0? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 11:53:53 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 09:53:53 +0000 Subject: [issue24992] collections.OrderedDict constructor (odict_new) doesn't handle PyDict_New() failure Message-ID: <1441274033.3.0.407992349306.issue24992@psf.upfronthosting.co.za> New submission from STINNER Victor: If PyDict_New() fails (ex: memory allocation failure), odict_new() returns a new OrderedDict with an exception set. It's a bug. Attached patch fixes it. odict_new() constructor also returns NULL without destroying the newly created object if _odict_initialize() fails. My patch also fixes this. My patch inlines _odict_initialize() into odict_new() and avoids useless initialization to 0. ---------- files: odict.patch keywords: patch messages: 249625 nosy: eric.snow, haypo priority: normal severity: normal status: open title: collections.OrderedDict constructor (odict_new) doesn't handle PyDict_New() failure versions: Python 3.6 Added file: http://bugs.python.org/file40334/odict.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 11:55:02 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 09:55:02 +0000 Subject: [issue24992] collections.OrderedDict constructor (odict_new) doesn't handle PyDict_New() failure In-Reply-To: <1441274033.3.0.407992349306.issue24992@psf.upfronthosting.co.za> Message-ID: <1441274102.53.0.63346468182.issue24992@psf.upfronthosting.co.za> STINNER Victor added the comment: You can try the odict_failmalloc.py program with a Python compiled in debug mode to see the bug. The script requires: https://pypi.python.org/pypi/pyfailmalloc ---------- Added file: http://bugs.python.org/file40335/odict_failmalloc.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 12:41:35 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 03 Sep 2015 10:41:35 +0000 Subject: [issue22241] strftime/strptime round trip fails even for UTC datetime object In-Reply-To: <1408620917.6.0.856660367054.issue22241@psf.upfronthosting.co.za> Message-ID: <1441276895.83.0.236369839741.issue22241@psf.upfronthosting.co.za> Berker Peksag added the comment: I left a couple comments on Rietveld. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 12:49:48 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 10:49:48 +0000 Subject: [issue24993] The C function PyCodec_NameReplaceErrors doesn't handle PyCapsule_Import() failure Message-ID: <1441277388.17.0.438973463566.issue24993@psf.upfronthosting.co.za> New submission from STINNER Victor: The namereplace error handler introduced in Python 3.5 doesn't handle correctly PyCapsule_Import() failure. If the function raises an exception, the PyCodec_NameReplaceErrors() function must return NULL. I see that the code correctly handle the case where PyCodec_NameReplaceErrors() failed, but it doesn't clear the exception. Attached patch changes PyCodec_NameReplaceErrors() to return immediatly NULL if PyCodec_NameReplaceErrors() failed. Or should we log the exception (PyErr_WriteUnraisable) and then clear it? PyErr_WriteUnraisable is usually used in corner case when it's impossible to report bugs to the function caller. ---------- files: namereplace_errors.patch keywords: patch messages: 249628 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: The C function PyCodec_NameReplaceErrors doesn't handle PyCapsule_Import() failure versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40336/namereplace_errors.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 12:50:18 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 10:50:18 +0000 Subject: [issue24993] The C function PyCodec_NameReplaceErrors doesn't handle PyCapsule_Import() failure In-Reply-To: <1441277388.17.0.438973463566.issue24993@psf.upfronthosting.co.za> Message-ID: <1441277418.62.0.368148960506.issue24993@psf.upfronthosting.co.za> STINNER Victor added the comment: Note: I found the bug when running test_codecs using failmalloc, a library to inject MemoryError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 12:50:31 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 03 Sep 2015 10:50:31 +0000 Subject: [issue7175] Define a standard location and API for configuration files In-Reply-To: <1441204631.76.0.458931621446.issue7175@psf.upfronthosting.co.za> Message-ID: <55E825E6.8020302@egenix.com> Marc-Andre Lemburg added the comment: On 02.09.2015 16:37, flying sheep wrote: > > hi mark, i?ve just lengthily replied to you on python-ideas. > > in short: nope! many command line tools that are relatively new (among them your examples git and pip) honor the specs, my ~/.cache, ~/.config, and ~/.local/share is full of things belonging to libraries, cli tools, my DE, and of course also GUI applications. > > please let?s continue this discussion on python-ideas if you?re still not convinced ? I think we're mixing two discussions here: 1. How Python itself should install config files, data, etc. 2. How applications written using Python should get help from some module to determine where to install their config files, data, etc. For 1. we already have a solution (in sysconfig.py). If you want to change or amend this, I think a PEP is needed, since the consequences will affect a lot of users. For 2. we can use whatever convention or standard is en vogue today. The module would have to pay close attention to providing backwards compatibility right from the start, since these conventions are bound to change over time. Note that this ticket started with the location of the distutils config file. The title has since been broadened way too much for a ticket. I'd suggest closing it as out-of-date and going with a proper PEP process or development of a new stdlib module on python-ideas and -dev. Given the experience with the platform module, I'm not convinced that the Python release process is suitable to properly respond to platform changes, so it may be better to simply have a standard module on PyPI for 2. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 13:14:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 11:14:04 +0000 Subject: [issue23719] PEP 475: port test_eintr to Windows In-Reply-To: <1426853391.45.0.421512531157.issue23719@psf.upfronthosting.co.za> Message-ID: <1441278844.79.0.163179206997.issue23719@psf.upfronthosting.co.za> STINNER Victor added the comment: The change ed0e6a9c11af replaced os.fork() with subprocess to try to fix race conditions in test_eintr (the test sometimes hangs on FreeBSD buildbots). os.fork() is not available on Windows, so this change should help to port test_eintr to Windows. About win32-sleep-test.diff: I'm not sure that it's a good idea to introduce a new thread in test_eintr. Signal handlers is more complex when we have multiple threads. Would it be possible to spawn a new process which will send a signal every N seconds to its parent? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 13:37:19 2015 From: report at bugs.python.org (flying sheep) Date: Thu, 03 Sep 2015 11:37:19 +0000 Subject: [issue7175] Define a standard location and API for configuration files In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za> Message-ID: <1441280239.66.0.532158431723.issue7175@psf.upfronthosting.co.za> flying sheep added the comment: you?re right about the two problems being mixed, however not about the standards. also you?re intermingling conventions with actual standards. the directory standards for all three big OSs are either not going to change or fitted with a backwards-compatibility layer (like windows did with the ?My Music/Videos/*? folders): https://developer.apple.com/library/mac/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/MacOSXDirectories/MacOSXDirectories.html http://windows.microsoft.com/de-de/windows-8/what-appdata-folder https://msdn.microsoft.com/en-us/library/windows/desktop/dd378457%28v=vs.85%29.aspx http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html all three OSs have stable, widely followed standards in place, and the idea of providing a python stdlib API for them received an almost unanimously positive response ? with the sole exception being you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 14:15:42 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 03 Sep 2015 12:15:42 +0000 Subject: [issue7175] Define a standard location and API for configuration files In-Reply-To: <1441280239.66.0.532158431723.issue7175@psf.upfronthosting.co.za> Message-ID: <55E839DD.3020503@egenix.com> Marc-Andre Lemburg added the comment: On 03.09.2015 13:37, flying sheep wrote: > all three OSs have stable, widely followed standards in place, and the idea of providing a python stdlib API for them received an almost unanimously positive response ? with the sole exception being you. I'm not against developing another module based on appdirs for this. I do question the usefulness of having such a module in the stdlib, since I've already gone through a similar experience with the platform module I wrote several years ago. Ongoing development is not really possible once a module is in the stdlib and older Python releases don't benefit from new developments either. Regarding standard vs. convention: that's all smoke and mirrors :-) A standard that's not being adopted is not a standard. A convention may well turn into a standard without ever being written down as one. A module implementing any such standards or conventions will have to address more than just one way of doing things in order to stay compatible with existing software or new developments. That's what I wanted to say. But this ticket is not about that discussion anyway... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 14:22:24 2015 From: report at bugs.python.org (Matheus Vieira Portela) Date: Thu, 03 Sep 2015 12:22:24 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> Message-ID: <1441282944.34.0.335285884035.issue23406@psf.upfronthosting.co.za> Matheus Vieira Portela added the comment: Applying review comments. Now, there is an internal link to the FAQ entry on multidimensional lists. ---------- Added file: http://bugs.python.org/file40337/issue23406_doc_stdtypes_and_faq.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 14:39:22 2015 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 03 Sep 2015 12:39:22 +0000 Subject: [issue24987] subprocess.Popen with shell=True doesn't create socket In-Reply-To: <1441231064.17.0.987286732599.issue24987@psf.upfronthosting.co.za> Message-ID: <1441283962.15.0.81896957968.issue24987@psf.upfronthosting.co.za> Eric V. Smith added the comment: With both python 2 and 3, what does "ps -efww | fgrep soffice" produce? ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 15:14:31 2015 From: report at bugs.python.org (Petr Viktorin) Date: Thu, 03 Sep 2015 13:14:31 +0000 Subject: [issue24748] Change of behavior for importlib between 3.4 and 3.5 with DLL loading In-Reply-To: <1438176027.56.0.467476097176.issue24748@psf.upfronthosting.co.za> Message-ID: <1441286071.43.0.952594915454.issue24748@psf.upfronthosting.co.za> Petr Viktorin added the comment: Indeed. I don't have access to a Windows machine, but I will try reproducing the problem on another system. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 15:35:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Sep 2015 13:35:58 +0000 Subject: [issue24993] The C function PyCodec_NameReplaceErrors doesn't handle PyCapsule_Import() failure In-Reply-To: <1441277388.17.0.438973463566.issue24993@psf.upfronthosting.co.za> Message-ID: <1441287358.78.0.140668158834.issue24993@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The purpose was to make the dependence of unicodedata optional. Here is a patch that adds missing lines to clear import error. But your approach looks reasonable too and the patch is correct. I have no strong preferences, but now I think that probably your approach is more preferable because it makes the code simpler and errors more explicit. Please commit your patch Victor if you don't see new reasons for original approach. ---------- assignee: -> haypo stage: -> commit review type: -> behavior Added file: http://bugs.python.org/file40338/namereplace_ignore_unicodedata_import_error.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 15:40:13 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 13:40:13 +0000 Subject: [issue24993] The C function PyCodec_NameReplaceErrors doesn't handle PyCapsule_Import() failure In-Reply-To: <1441277388.17.0.438973463566.issue24993@psf.upfronthosting.co.za> Message-ID: <1441287613.08.0.56021134572.issue24993@psf.upfronthosting.co.za> STINNER Victor added the comment: > The purpose was to make the dependence of unicodedata optional. In which case the unicodedata module is missing? It's always part of CPython no? > (...) but now I think that probably your approach is more preferable because it makes the code simpler and errors more explicit. Yeah, it's not a good practice to *hide* errors. At least, your patch must log the error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 15:56:44 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 03 Sep 2015 13:56:44 +0000 Subject: [issue23375] test_py3kwarn fails on Windows In-Reply-To: <1422861689.06.0.83900503025.issue23375@psf.upfronthosting.co.za> Message-ID: <1441288604.13.0.637749581629.issue23375@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 15:57:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Sep 2015 13:57:28 +0000 Subject: [issue24992] collections.OrderedDict constructor (odict_new) doesn't handle PyDict_New() failure In-Reply-To: <1441274033.3.0.407992349306.issue24992@psf.upfronthosting.co.za> Message-ID: <1441288648.74.0.306711060334.issue24992@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If don't initialize fields, then they will be not initialized in odict_dealloc, odict_tp_clear and odict_traverse. But _odict_FIRST(od) and od->od_weakreflist are used in these functions. I would allocate a dict for od_inst_dict before calling PyDict_Type.tp_new. An allocator can release GIL and call Python code, and at that moment the OrderedDict object is in inconsistent state. I already were fell in similar trap with lru_cache (issue14373, msg246573). ---------- nosy: +rhettinger, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 16:03:54 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 14:03:54 +0000 Subject: [issue24992] collections.OrderedDict constructor (odict_new) doesn't handle PyDict_New() failure In-Reply-To: <1441274033.3.0.407992349306.issue24992@psf.upfronthosting.co.za> Message-ID: <1441289034.87.0.559016889822.issue24992@psf.upfronthosting.co.za> STINNER Victor added the comment: > If don't initialize fields, then they will be not initialized in odict_dealloc Old code initialized all fields to zero (or NULL), like "_odict_FIRST(od) = NULL;". The type allocator fills the newly allocated with zeros. So setting fields again to zero is redundant (useless). > I would allocate a dict for od_inst_dict before calling PyDict_Type.tp_new. An allocator can release GIL and call Python code, and at that moment the OrderedDict object is in inconsistent state. Yes, but the newly created object is not still private at this point, there is only one reference known in the C code. dict_new() has the same design. You can please elaborate the issue? We only give the reference to the caller when the newly created OrderedDict is fully initialized (consistent). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 16:09:11 2015 From: report at bugs.python.org (Tim Tisdall) Date: Thu, 03 Sep 2015 14:09:11 +0000 Subject: [issue24984] document AF_BLUETOOTH socket address formats In-Reply-To: <1441210010.76.0.198064903239.issue24984@psf.upfronthosting.co.za> Message-ID: <1441289351.45.0.835467886929.issue24984@psf.upfronthosting.co.za> Tim Tisdall added the comment: I'm not sure the proper way to update the patch... I can't seem to edit the existing one or replace it. I'm uploading an updated one, but should I simply "unlink" (aka delete) the old one? ---------- Added file: http://bugs.python.org/file40339/bluetooth_socket_docs_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 16:15:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Sep 2015 14:15:08 +0000 Subject: [issue24993] The C function PyCodec_NameReplaceErrors doesn't handle PyCapsule_Import() failure In-Reply-To: <1441287613.08.0.56021134572.issue24993@psf.upfronthosting.co.za> Message-ID: <2019697.H9edTKd0Wn@raxxla> Serhiy Storchaka added the comment: > In which case the unicodedata module is missing? It's always part of CPython > no? It was optional in Python 2 (at least in Unicode-disabled build). Perhaps it can be exclude from custom build in Python 3 too. > Yeah, it's not a good practice to *hide* errors. At least, your patch must > log the error. Then please commit your patch. We can reenable optional dependency later if it will be needed for embedded systems. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 16:18:35 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 14:18:35 +0000 Subject: [issue24993] The C function PyCodec_NameReplaceErrors doesn't handle PyCapsule_Import() failure In-Reply-To: <1441277388.17.0.438973463566.issue24993@psf.upfronthosting.co.za> Message-ID: <1441289915.3.0.432899336905.issue24993@psf.upfronthosting.co.za> STINNER Victor added the comment: > It was optional in Python 2 (at least in Unicode-disabled build). Yeah, even if I don't think that anyone is really using python without unicode in the wild. I guess that too many libraries don't work without unicode. Well, anyway this issue is for Python 3.6 which has always unicode support :-) > Perhaps it can be exclude from custom build in Python 3 too. Right, some patches were proposed to disable some features of Python to get a smaller Python core/stdlib, but some developers were opposed to this idea. It's not supported officially by Python, so I don't think that we should polute the code for an hypothetic use case. If you use a custom build, you must be prepared to some corner case bugs. If you modify the build, you are able to fix such simple issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 16:20:53 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Sep 2015 14:20:53 +0000 Subject: [issue24993] The C function PyCodec_NameReplaceErrors doesn't handle PyCapsule_Import() failure In-Reply-To: <1441277388.17.0.438973463566.issue24993@psf.upfronthosting.co.za> Message-ID: <20150903142047.66854.49178@psf.io> Roundup Robot added the comment: New changeset ac1995b01028 by Victor Stinner in branch '3.5': Issue #24993: Handle import error in namereplace error handler https://hg.python.org/cpython/rev/ac1995b01028 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 16:21:12 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 14:21:12 +0000 Subject: [issue24993] The C function PyCodec_NameReplaceErrors doesn't handle PyCapsule_Import() failure In-Reply-To: <1441277388.17.0.438973463566.issue24993@psf.upfronthosting.co.za> Message-ID: <1441290072.61.0.500749467172.issue24993@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 16:24:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Sep 2015 14:24:09 +0000 Subject: [issue24992] collections.OrderedDict constructor (odict_new) doesn't handle PyDict_New() failure In-Reply-To: <1441289034.87.0.559016889822.issue24992@psf.upfronthosting.co.za> Message-ID: <1776712.uzkECe3EL7@raxxla> Serhiy Storchaka added the comment: > We only give the reference to the caller when the newly created OrderedDict > is fully initialized (consistent). See msg246573. PyDict_New() can trigger garbage collecting and traversing , and GC have a reference to underinitialized OrderedDict and can call odict_traverse() for it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 16:25:50 2015 From: report at bugs.python.org (Tim Tisdall) Date: Thu, 03 Sep 2015 14:25:50 +0000 Subject: [issue24984] document AF_BLUETOOTH socket address formats In-Reply-To: <1441210010.76.0.198064903239.issue24984@psf.upfronthosting.co.za> Message-ID: <1441290350.26.0.26316988011.issue24984@psf.upfronthosting.co.za> Tim Tisdall added the comment: Martin, the odd thing with the SCO protocol is it's expecting an bluetooth address as a byte string (ex b'12:23:34:45:56:67' [note the `b`]) where the other 3 are expecting a regular string (ex '12:23:34:45:56:67'). I think it may have been a case of someone doing a blanket search-and-replace and missing the consequences there, but I'm really not sure. However, this is somewhat besides the point as right now I'm trying to focus on just documenting the actual behaviour. ;) The issue is, what versions have the changes from 23ab586c427a in it, and what versions come before that where it's probably expecting a regular string. Unfortunately I can't access the web interface for the repo at the moment so I can't even try to figure that out at right now. (Though, I haven't confirmed that the old method was looking at regular strings or not...) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 16:33:29 2015 From: report at bugs.python.org (Tim Tisdall) Date: Thu, 03 Sep 2015 14:33:29 +0000 Subject: [issue24984] document AF_BLUETOOTH socket address formats In-Reply-To: <1441210010.76.0.198064903239.issue24984@psf.upfronthosting.co.za> Message-ID: <1441290809.81.0.187344303608.issue24984@psf.upfronthosting.co.za> Tim Tisdall added the comment: I'm not really sure how to add a `versionadded` tag to specify that only the BSD-specific support was added in 3.2 (as general support was there prior to that). If I just add the plain tag below that bullet point it would imply that the whole protocol was added in 3.2 . Perhaps I should reword it to just list the original (prior to 3.2) documentation, then add the difference with BSD in a separate paragraph such that I can tag just that part? Or maybe I shouldn't bother? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 16:37:19 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 14:37:19 +0000 Subject: [issue24992] collections.OrderedDict constructor (odict_new) doesn't handle PyDict_New() failure In-Reply-To: <1441274033.3.0.407992349306.issue24992@psf.upfronthosting.co.za> Message-ID: <1441291039.75.0.597293683076.issue24992@psf.upfronthosting.co.za> STINNER Victor added the comment: > See msg246573. PyDict_New() can trigger garbage collecting and traversing and GC have a reference to underinitialized OrderedDict and can call odict_traverse() for it. Oooh ok, I understand. I updated my patch to implement your idea. ---------- Added file: http://bugs.python.org/file40340/odict-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 16:38:20 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 14:38:20 +0000 Subject: [issue24992] collections.OrderedDict constructor (odict_new) doesn't handle PyDict_New() failure In-Reply-To: <1441274033.3.0.407992349306.issue24992@psf.upfronthosting.co.za> Message-ID: <1441291100.8.0.692396757298.issue24992@psf.upfronthosting.co.za> STINNER Victor added the comment: @Serhiy: Python 3.5 is impacted. Do you consider this bug serious enough to request a pull request in Larry's branch for Python 3.5.0? ---------- nosy: +larry versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 16:40:27 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 14:40:27 +0000 Subject: [issue24993] The C function PyCodec_NameReplaceErrors doesn't handle PyCapsule_Import() failure In-Reply-To: <1441290072.65.0.544342620172.issue24993@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Thanks for your review and your cool error handler. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 16:50:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Sep 2015 14:50:25 +0000 Subject: [issue24992] collections.OrderedDict constructor (odict_new) doesn't handle PyDict_New() failure In-Reply-To: <1441274033.3.0.407992349306.issue24992@psf.upfronthosting.co.za> Message-ID: <1441291825.37.0.0145950667908.issue24992@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It looks to me as an ordinal bug and that is encountered only in special circumstances with small probability. I think it can wait for 3.5.1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 16:54:57 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 14:54:57 +0000 Subject: [issue24992] collections.OrderedDict constructor (odict_new) doesn't handle PyDict_New() failure In-Reply-To: <1441274033.3.0.407992349306.issue24992@psf.upfronthosting.co.za> Message-ID: <1441292097.01.0.236286037286.issue24992@psf.upfronthosting.co.za> STINNER Victor added the comment: > It looks to me as an ordinal bug and that is encountered only in special circumstances with small probability. I think it can wait for 3.5.1. Ok, I agree. What about the second patch, does it look ok? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 17:03:17 2015 From: report at bugs.python.org (Tim Tisdall) Date: Thu, 03 Sep 2015 15:03:17 +0000 Subject: [issue24984] document AF_BLUETOOTH socket address formats In-Reply-To: <1441210010.76.0.198064903239.issue24984@psf.upfronthosting.co.za> Message-ID: <1441292597.37.0.947583363473.issue24984@psf.upfronthosting.co.za> Tim Tisdall added the comment: I added a note to BTPROTO_SCO that it doesn't work in FreeBSD (I forgot to mention that). ---------- Added file: http://bugs.python.org/file40341/bluetooth_socket_docs_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 17:11:16 2015 From: report at bugs.python.org (Cameron Walker) Date: Thu, 03 Sep 2015 15:11:16 +0000 Subject: [issue24994] Python 3.4.2 64-bit Installer error (Please insert the disk:) Message-ID: <1441293076.64.0.808974817159.issue24994@psf.upfronthosting.co.za> New submission from Cameron Walker: I had attempted to uninstall python 3.4.2 from the start menu in Windows 7, but it was still visible in my Programs and features. I tried to uninstall it from there but it said it was missing some files. So I re-downloaded the installer, but when it tried to install, the following error came up. Please insert the disk: with an Ok and Cancel prompt. When I click on Ok it causes the same error to reappear, but clicking cancel causes it to abort. Please help. ---------- components: Windows messages: 249654 nosy: Cameron Walker, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Python 3.4.2 64-bit Installer error (Please insert the disk:) type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 17:14:34 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 03 Sep 2015 15:14:34 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> Message-ID: <1441293274.23.0.647984121752.issue23406@psf.upfronthosting.co.za> R. David Murray added the comment: Looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 17:15:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 03 Sep 2015 15:15:31 +0000 Subject: [issue24992] collections.OrderedDict constructor (odict_new) doesn't handle PyDict_New() failure In-Reply-To: <1441274033.3.0.407992349306.issue24992@psf.upfronthosting.co.za> Message-ID: <1441293331.22.0.517596381071.issue24992@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I left a nitpick. In any case the patch LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 17:16:12 2015 From: report at bugs.python.org (Cameron Walker) Date: Thu, 03 Sep 2015 15:16:12 +0000 Subject: [issue24994] Python 3.4.2 64-bit Installer error (Please insert the disk:) In-Reply-To: <1441293076.64.0.808974817159.issue24994@psf.upfronthosting.co.za> Message-ID: <1441293372.02.0.260748480698.issue24994@psf.upfronthosting.co.za> Cameron Walker added the comment: Never mind. I just had to click repair... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 17:16:45 2015 From: report at bugs.python.org (Yann Sionneau) Date: Thu, 03 Sep 2015 15:16:45 +0000 Subject: [issue23630] support multiple hosts in create_server/start_server In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za> Message-ID: <1441293405.46.0.63162768924.issue23630@psf.upfronthosting.co.za> Yann Sionneau added the comment: Here is a new patch without any dependency on netifaces. Thanks Victor for the great deal of help for all the mock() stuff! ---------- Added file: http://bugs.python.org/file40342/multibind6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 17:23:45 2015 From: report at bugs.python.org (Tim Tisdall) Date: Thu, 03 Sep 2015 15:23:45 +0000 Subject: [issue24984] document AF_BLUETOOTH socket address formats In-Reply-To: <1441210010.76.0.198064903239.issue24984@psf.upfronthosting.co.za> Message-ID: <1441293825.82.0.109429999649.issue24984@psf.upfronthosting.co.za> Tim Tisdall added the comment: changed "This protocol does not work under FreeBSD." to the more accurate "This protocol is not supported under FreeBSD." ---------- Added file: http://bugs.python.org/file40343/bluetooth_socket_docs_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 17:34:41 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 03 Sep 2015 15:34:41 +0000 Subject: [issue24990] Foreign language support in turtle module In-Reply-To: <1441238139.14.0.540040388391.issue24990@psf.upfronthosting.co.za> Message-ID: <1441294481.74.0.152913803127.issue24990@psf.upfronthosting.co.za> R. David Murray added the comment: There is a discussion elsewhere about whether it is time to start formalizing translation efforts for the python docs (Sphinx supports it). Unfortunately I don't remember where I saw it (probably another issue in the tracker. I can see your argument about turtle being special in this regard. There's no guarantee a patch would be accepted, though, so before you do much work on it I'd recommend posting to python-ideas about it. Regardless of that, it would be a new feature and so can only go into 3.6, unless you can get some consensus for this being another exception to that rule like Idle is :) ---------- nosy: +gregorlingl, r.david.murray versions: +Python 3.6 -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 17:46:21 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Sep 2015 15:46:21 +0000 Subject: [issue24994] Python 3.4.2 64-bit Installer error (Please insert the disk:) In-Reply-To: <1441293076.64.0.808974817159.issue24994@psf.upfronthosting.co.za> Message-ID: <1441295181.35.0.896974673217.issue24994@psf.upfronthosting.co.za> Zachary Ware added the comment: Glad you solved it for yourself :) ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 17:47:43 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 15:47:43 +0000 Subject: [issue1103213] Adding the missing socket.recvall() method Message-ID: <1441295263.06.0.80048257972.issue1103213@psf.upfronthosting.co.za> STINNER Victor added the comment: recvall.patch: implement socket.socket.recvall() in pure Python. It raises a new socket.IncompleteReadError (copied from asyncio) exception if the connection is closed before we got the expected number of bytes. The patch has unit tests, document the new method and the new exception. TODO: I don't like how the method handles timeout. The method must fail if it takes longer than socket.gettimeout() seconds, whereas currently the timeout is reset each time we got data from the server. If the idea of the new socket method is accepted, I will reimplement it in C. In C, it's more easy to implement the timeout as I want. In Python, the socket timeout cannot be changed temporary, because it would impact other threads which may use the same socket. I changed how socket.sendall() handle timeout in Python 3.5, it is now the maximum total duration to send all data. The timeout is no more reset each time we send a packet. Related discussion: https://mail.python.org/pipermail/python-dev/2015-April/139001.html See also the issue #23236 which adds a timeout reset each time we get data to the asyncio read() method. It will be complementary to the existing "wait(read(), timeout)" timeout method, it's for a different use case. ---------- Added file: http://bugs.python.org/file40344/recvall.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 17:51:03 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Sep 2015 15:51:03 +0000 Subject: [issue24992] collections.OrderedDict constructor (odict_new) doesn't handle PyDict_New() failure In-Reply-To: <1441274033.3.0.407992349306.issue24992@psf.upfronthosting.co.za> Message-ID: <20150903155059.14877.33134@psf.io> Roundup Robot added the comment: New changeset ef1f5aebe1a6 by Victor Stinner in branch '3.5': Issue #24992: Fix error handling and a race condition (related to garbage https://hg.python.org/cpython/rev/ef1f5aebe1a6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 17:51:45 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 03 Sep 2015 15:51:45 +0000 Subject: [issue7175] Define a standard location and API for configuration files In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za> Message-ID: <1441295505.47.0.845296511762.issue7175@psf.upfronthosting.co.za> R. David Murray added the comment: As someone else mentioned, the freedesktop standard is only really "widely followed" by desktop aps. My own .config directory contains 8 entries, while there are 13 rc files/directories in my homedir (one of which is my X windows manager :) That's not to mention the 50+ config files in my home directory that don't end with 'rc'.... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 17:51:57 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 15:51:57 +0000 Subject: [issue24992] collections.OrderedDict constructor (odict_new) doesn't handle PyDict_New() failure In-Reply-To: <1441274033.3.0.407992349306.issue24992@psf.upfronthosting.co.za> Message-ID: <1441295517.55.0.0651303194745.issue24992@psf.upfronthosting.co.za> STINNER Victor added the comment: > I left a nitpick. In any case the patch LGTM. Ok, fixed. I pushed my fix. Thanks for the review Serhiy. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 17:51:58 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 03 Sep 2015 15:51:58 +0000 Subject: [issue24305] The new import system makes it inconvenient to correctly issue a deprecation warning for a module In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za> Message-ID: <1441295518.83.0.522601991046.issue24305@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: larry -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 17:53:34 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Sep 2015 15:53:34 +0000 Subject: [issue24305] The new import system makes it inconvenient to correctly issue a deprecation warning for a module In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za> Message-ID: <1441295614.9.0.532984691012.issue24305@psf.upfronthosting.co.za> Zachary Ware added the comment: Just to note, there's an easier way to run a custom build on multiple bots: go to http://buildbot.python.org/all/builders/ and scroll (way) down to the section for forcing a build on custom builders (you can search for 'Repo path:' (with the colon)), check the box next to all the builders you want, then fill out the Repo path, your name, reason, and revision. You can also force the build on *all* custom builders; search for the second hit on 'Repo path:'. ...might not hurt if we document that somewhere. ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 17:55:41 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 03 Sep 2015 15:55:41 +0000 Subject: [issue24984] document AF_BLUETOOTH socket address formats In-Reply-To: <1441210010.76.0.198064903239.issue24984@psf.upfronthosting.co.za> Message-ID: <1441295741.4.0.654050470592.issue24984@psf.upfronthosting.co.za> R. David Murray added the comment: Uploading new patches is correct. We generally don't unlink the old ones unless the history starts to get really confusing. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 18:02:20 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Sep 2015 16:02:20 +0000 Subject: [issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model In-Reply-To: <1441057022.82.0.924513920263.issue24974@psf.upfronthosting.co.za> Message-ID: <1441296140.39.0.456130102912.issue24974@psf.upfronthosting.co.za> Zachary Ware added the comment: I tested both 32 and 64 bit, with MSVC 14 (VS 2015) and ICC 15.0 (backed by VS 2015). I can go ahead and commit this to a sandbox for buildbot testing if it would help. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 18:23:31 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 03 Sep 2015 16:23:31 +0000 Subject: [issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model In-Reply-To: <1441057022.82.0.924513920263.issue24974@psf.upfronthosting.co.za> Message-ID: <1441297411.1.0.815245168429.issue24974@psf.upfronthosting.co.za> Stefan Krah added the comment: Hmm, I don't see a 32-bit ICC buildbot. This problem can only occur on 32-bit with -DPPRO defined. Please go ahead and commit the patch. The inline asm miscompilation problem I mentioned earlier was solved in 12.0 (I think), so let's just assume it's gone (probably it has never been an issue for MASM anyway). ---------- assignee: -> zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 18:42:29 2015 From: report at bugs.python.org (Mark Roseman) Date: Thu, 03 Sep 2015 16:42:29 +0000 Subject: [issue24988] IDLE: debugger context menus not working on Mac In-Reply-To: <1441235411.2.0.839528084251.issue24988@psf.upfronthosting.co.za> Message-ID: <1441298549.49.0.829613248738.issue24988@psf.upfronthosting.co.za> Mark Roseman added the comment: Terry, the new code I've proposed includes a "tkextras" module that is a good place for these sort of little convenience functions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 18:46:08 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Sep 2015 16:46:08 +0000 Subject: [issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model In-Reply-To: <1441057022.82.0.924513920263.issue24974@psf.upfronthosting.co.za> Message-ID: <1441298768.61.0.0916705316183.issue24974@psf.upfronthosting.co.za> Zachary Ware added the comment: There's not a 32-bit ICC buildbot, though I could force one. But since you say commit it, I'll commit it ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 18:52:14 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 03 Sep 2015 16:52:14 +0000 Subject: [issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model In-Reply-To: <1441057022.82.0.924513920263.issue24974@psf.upfronthosting.co.za> Message-ID: <1441299134.27.0.0196393889333.issue24974@psf.upfronthosting.co.za> Stefan Krah added the comment: We can always blame any fallout on ICC. ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 18:58:39 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Sep 2015 16:58:39 +0000 Subject: [issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model In-Reply-To: <1441057022.82.0.924513920263.issue24974@psf.upfronthosting.co.za> Message-ID: <20150903165835.15716.88934@psf.io> Roundup Robot added the comment: New changeset 863407e80370 by Zachary Ware in branch '3.5': Issue #24974: Force fp-model precice in mpdecimal.c on Windows https://hg.python.org/cpython/rev/863407e80370 New changeset 88c28d29afe4 by Zachary Ware in branch 'default': Closes #24974: Merge with 3.5 https://hg.python.org/cpython/rev/88c28d29afe4 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 18:59:30 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 03 Sep 2015 16:59:30 +0000 Subject: [issue24974] ICC on Windows 8.1: _decimal fails to compile with default fp model In-Reply-To: <1441057022.82.0.924513920263.issue24974@psf.upfronthosting.co.za> Message-ID: <1441299570.88.0.639057180105.issue24974@psf.upfronthosting.co.za> Zachary Ware added the comment: Committed! Thank you Steve for the suggestion and Stefan for the approval. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 19:00:44 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 03 Sep 2015 17:00:44 +0000 Subject: [issue24992] collections.OrderedDict constructor (odict_new) doesn't handle PyDict_New() failure In-Reply-To: <1441274033.3.0.407992349306.issue24992@psf.upfronthosting.co.za> Message-ID: <1441299644.5.0.795533350145.issue24992@psf.upfronthosting.co.za> Yury Selivanov added the comment: Is this something that we should ship in 3.5.0rc3? ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 19:05:56 2015 From: report at bugs.python.org (TJ) Date: Thu, 03 Sep 2015 17:05:56 +0000 Subject: [issue24979] Allow timezone offsets greater than 24 hours In-Reply-To: <1441117874.73.0.315873537827.issue24979@psf.upfronthosting.co.za> Message-ID: <1441299956.96.0.114280587962.issue24979@psf.upfronthosting.co.za> TJ added the comment: Thanks for the pointer to #5288. Happy to consolidate there. In my reading of #5094 (from which I pulled your RFC 2822 reference), the justification I found was "For the allowable range, follow the datetime docs as someone might be relying on that specification already". But this didn't explain why it was in the spec in the first place, and that is the decision I thought was arbitrary, not the decision to maintain the restriction. Splitting hairs at this point. Looking forward to the restriction being removed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 19:11:50 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 03 Sep 2015 17:11:50 +0000 Subject: [issue24979] Allow timezone offsets greater than 24 hours In-Reply-To: <1441117874.73.0.315873537827.issue24979@psf.upfronthosting.co.za> Message-ID: <1441300310.67.0.173547274061.issue24979@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I always thought that restriction came from ISO 8601, but at the moment I don't have it to check. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 19:27:08 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 03 Sep 2015 17:27:08 +0000 Subject: [issue24913] deque.index() overruns deque boundary In-Reply-To: <1440198546.56.0.00559117738444.issue24913@psf.upfronthosting.co.za> Message-ID: <1441301228.9.0.144120181426.issue24913@psf.upfronthosting.co.za> Brett Cannon added the comment: PR created, Larry. ---------- assignee: brett.cannon -> larry stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 19:56:08 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 03 Sep 2015 17:56:08 +0000 Subject: [issue24988] IDLE: debugger context menus not working on Mac In-Reply-To: <1441235411.2.0.839528084251.issue24988@psf.upfronthosting.co.za> Message-ID: <1441302968.32.0.0780068745769.issue24988@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The standard on Windows is to bring up a context menu on right-button-release, not on r-b-press. What about linux and mac? Thunderbird and Notepad++ move the insertion cursor on rb-press, That is the paste position even if the mouse is moved before release. Notepad does not move the insert cursor. MS Word is confusing, erasing the cursor when the menu is displayed and moving it when the menu goes away. EditorWindow.py has this code for context menu event binding: if macosxSupport.isAquaTk(): # Some OS X systems have only one mouse button, # so use control-click for pulldown menus there. # (Note, AquaTk defines <2> as the right button if # present and the Tk Text widget already binds <2>.) text.bind("",self.right_menu_event) else: # Elsewhere, use right-click for pulldown menus. text.bind("<3>",self.right_menu_event) Testing with my middle button, a press and release act the same as left click to move the insertion cursor to the mouse cursor. Moving my mouse while holding the middle button down moves the text pane within the text window. The insertion cursor is not moved. This is pretty much redundant with using the scroll wheel or scroll bar. Would it confuse Mac users to have rt-click for context menu only work in debugger? Could we make rt-click work in editor windows by recording position or time on press and compare position or time on release? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 20:16:36 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 03 Sep 2015 18:16:36 +0000 Subject: [issue24988] IDLE: debugger context menus not working on Mac In-Reply-To: <1441235411.2.0.839528084251.issue24988@psf.upfronthosting.co.za> Message-ID: <1441304196.98.0.309905425133.issue24988@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I just found #24801 which addressed the editor issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 21:01:47 2015 From: report at bugs.python.org (asduj) Date: Thu, 03 Sep 2015 19:01:47 +0000 Subject: [issue24987] subprocess.Popen with shell=True doesn't create socket In-Reply-To: <1441231064.17.0.987286732599.issue24987@psf.upfronthosting.co.za> Message-ID: <1441306907.66.0.364105590969.issue24987@psf.upfronthosting.co.za> asduj added the comment: Hello, Eric and Martin! I don't know what happened, but now it works. I have checked this problem on two computers two days ago, and then the command was not working. But now, I run exactly that command, and it works as should. I don't know what has changed. Maybe, because I installed the OS update before I test again. Thank you for attention and your time. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 21:16:50 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 19:16:50 +0000 Subject: [issue24992] collections.OrderedDict constructor (odict_new) doesn't handle PyDict_New() failure In-Reply-To: <1441274033.3.0.407992349306.issue24992@psf.upfronthosting.co.za> Message-ID: <1441307810.34.0.174465322164.issue24992@psf.upfronthosting.co.za> STINNER Victor added the comment: Yury wrote: > Is this something that we should ship in 3.5.0rc3? I don't think so. I agree with Serhiy who wrote: > It looks to me as an ordinal bug and that is encountered only in special circumstances with small probability. I think it can wait for 3.5.1. It looks like the bug can only occurs in case of very low memory (an empty dict takes 1 KB or less) which is a rare use case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 21:34:55 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Sep 2015 19:34:55 +0000 Subject: [issue3199] 2.6b1 Build Fails On OSX 10.5 In-Reply-To: <1214404356.07.0.352296574281.issue3199@psf.upfronthosting.co.za> Message-ID: <20150903193452.11258.4480@psf.io> Roundup Robot added the comment: New changeset 94f61fe22edf by Victor Stinner in branch '3.4': Don't use defined() in C preprocessor macros https://hg.python.org/cpython/rev/94f61fe22edf ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 22:00:57 2015 From: report at bugs.python.org (Larry Hastings) Date: Thu, 03 Sep 2015 20:00:57 +0000 Subject: [issue24913] deque.index() overruns deque boundary In-Reply-To: <1440198546.56.0.00559117738444.issue24913@psf.upfronthosting.co.za> Message-ID: <1441310457.62.0.266426315943.issue24913@psf.upfronthosting.co.za> Larry Hastings added the comment: Merged. Please do a (null) merge forward into 3.5.1 and 3.6. Thanks! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 22:01:59 2015 From: report at bugs.python.org (Mark Shannon) Date: Thu, 03 Sep 2015 20:01:59 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441310519.32.0.689034355176.issue24912@psf.upfronthosting.co.za> Mark Shannon added the comment: Larry, of the two choices, I prefer rolling back the change entirely. I would like to see the bug fixes for typeobject.c applied, but I see no reason why making the __class__ of module objects assignable should be included. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 22:25:46 2015 From: report at bugs.python.org (Larry Hastings) Date: Thu, 03 Sep 2015 20:25:46 +0000 Subject: [issue21192] Idle: Print filename when running a file from editor In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za> Message-ID: <1441311946.26.0.123101808024.issue21192@psf.upfronthosting.co.za> Larry Hastings added the comment: On the other hand, I do not hold with marking a minor cosmetic change like this as "release blocker". I'm willing to accept the change, given PEP 434, but I'm not going to delay any releases for it. ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 22:28:03 2015 From: report at bugs.python.org (Larry Hastings) Date: Thu, 03 Sep 2015 20:28:03 +0000 Subject: [issue24305] The new import system makes it inconvenient to correctly issue a deprecation warning for a module In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za> Message-ID: <1441312083.61.0.322579415218.issue24305@psf.upfronthosting.co.za> Larry Hastings added the comment: That *is* easier, thanks. Though the UI for that is baffling. Protip: search for the section where all the "custom" builders are listed all in one section, three-quarters of the way down the page. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 22:34:28 2015 From: report at bugs.python.org (Eugene Toder) Date: Thu, 03 Sep 2015 20:34:28 +0000 Subject: [issue24991] Define instance mutability explicitly on type objects In-Reply-To: <1441260483.41.0.785006760825.issue24991@psf.upfronthosting.co.za> Message-ID: <1441312468.81.0.742401494186.issue24991@psf.upfronthosting.co.za> Changes by Eugene Toder : ---------- nosy: +eltoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 22:44:09 2015 From: report at bugs.python.org (Al Sweigart) Date: Thu, 03 Sep 2015 20:44:09 +0000 Subject: [issue24990] Foreign language support in turtle module In-Reply-To: <1441238139.14.0.540040388391.issue24990@psf.upfronthosting.co.za> Message-ID: <1441313049.7.0.168545077689.issue24990@psf.upfronthosting.co.za> Al Sweigart added the comment: Good idea. I'll bring it up on the python-ideas list. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 23:03:48 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 03 Sep 2015 21:03:48 +0000 Subject: [issue24987] subprocess.Popen with shell=True doesn't create socket In-Reply-To: <1441231064.17.0.987286732599.issue24987@psf.upfronthosting.co.za> Message-ID: <1441314228.37.0.506962167464.issue24987@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> works for me _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 23:13:47 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 03 Sep 2015 21:13:47 +0000 Subject: [issue24995] better exception message when an unsupported object is passed to `async for` (pep 492) Message-ID: <1441314827.75.0.533925414566.issue24995@psf.upfronthosting.co.za> New submission from Yury Selivanov: Should we raise something like "'int' object is not an asynchronous iterable", instead of "'async for' requires an object with __aiter__ method, got int"? >>> foo().send(None) Traceback (most recent call last): File "", line 1, in File "", line 2, in foo TypeError: 'async for' requires an object with __aiter__ method, got int >>> for i in 1: pass ... Traceback (most recent call last): File "", line 1, in TypeError: 'int' object is not iterable ---------- assignee: yselivanov components: Interpreter Core messages: 249689 nosy: gvanrossum, haypo, ncoghlan, yselivanov priority: normal severity: normal status: open title: better exception message when an unsupported object is passed to `async for` (pep 492) type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 23:29:13 2015 From: report at bugs.python.org (Mark Roseman) Date: Thu, 03 Sep 2015 21:29:13 +0000 Subject: [issue24996] IDLE: debugger local/global vars should not be editable Message-ID: <1441315753.96.0.0493251705052.issue24996@psf.upfronthosting.co.za> New submission from Mark Roseman: In the debugger, the values for the variables shown in the locals/globals panes are editable (i.e. using Entry widget) but I don't see any mechanism to have those changes affect anything. If I'm not missing something, why Entry and not Label? ---------- messages: 249690 nosy: kbk, markroseman, roger.serwy, terry.reedy priority: normal severity: normal status: open title: IDLE: debugger local/global vars should not be editable type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 23:32:10 2015 From: report at bugs.python.org (Mark Roseman) Date: Thu, 03 Sep 2015 21:32:10 +0000 Subject: [issue15347] IDLE - does not close if the debugger was active In-Reply-To: <1342207963.58.0.539607447258.issue15347@psf.upfronthosting.co.za> Message-ID: <1441315930.56.0.928855749372.issue15347@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 23:32:46 2015 From: report at bugs.python.org (Mark Roseman) Date: Thu, 03 Sep 2015 21:32:46 +0000 Subject: [issue15348] IDLE - shell becomes unresponsive if debugger windows is closed while active. In-Reply-To: <1342208290.25.0.778184843655.issue15348@psf.upfronthosting.co.za> Message-ID: <1441315966.5.0.963788113436.issue15348@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 23:39:13 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 03 Sep 2015 21:39:13 +0000 Subject: [issue24995] better exception message when an unsupported object is passed to `async for` (pep 492) In-Reply-To: <1441314827.75.0.533925414566.issue24995@psf.upfronthosting.co.za> Message-ID: <1441316353.41.0.254786999284.issue24995@psf.upfronthosting.co.za> Guido van Rossum added the comment: Did you get multiple complaints about this? The existing error doesn't seem so bad. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 23:50:01 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 03 Sep 2015 21:50:01 +0000 Subject: [issue21192] Idle: Print filename when running a file from editor In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za> Message-ID: <1441317001.88.0.0838149407529.issue21192@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Sorry, my memory was that I was supposed to that as a signal, but maybe that was with a different RM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 23:54:11 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 03 Sep 2015 21:54:11 +0000 Subject: [issue24995] better exception message when an unsupported object is passed to `async for` (pep 492) In-Reply-To: <1441314827.75.0.533925414566.issue24995@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: IMHO the current message is clear enough. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 23:56:10 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 03 Sep 2015 21:56:10 +0000 Subject: [issue24996] IDLE: debugger local/global vars should not be editable In-Reply-To: <1441315753.96.0.0493251705052.issue24996@psf.upfronthosting.co.za> Message-ID: <1441317370.89.0.692693100115.issue24996@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I already brought this up as part of one of the StackViewer/Debugger/merge issues. Replacing the list with a tree would automatically change this unless the tree was changed to have a entry. Why? My speculation is an intention never carried out. Labels could be made to look different, so that cannot be the reason. Can a ttk Treeview allow entries in a column, in case we ever wanted to make changes propagate? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 3 23:57:17 2015 From: report at bugs.python.org (Cory Benfield) Date: Thu, 03 Sep 2015 21:57:17 +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: <1441317437.59.0.955296989034.issue17849@psf.upfronthosting.co.za> Cory Benfield added the comment: Martin, the idea of simply rejecting the LifeAndFileWrapper HTTP/0.9 fallback for _tunnel feels reasonable to me, that can work. Let me whip up an alternative patch that does that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 00:05:32 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 03 Sep 2015 22:05:32 +0000 Subject: [issue24995] better exception message when an unsupported object is passed to `async for` (pep 492) In-Reply-To: <1441314827.75.0.533925414566.issue24995@psf.upfronthosting.co.za> Message-ID: <1441317932.37.0.836271442391.issue24995@psf.upfronthosting.co.za> Yury Selivanov added the comment: I saw this reddit thread: https://www.reddit.com/r/Python/comments/3ewnwq/async_function_as_generator_for_async_for/ where people are struggling with understanding how 'async for' works. Which led me to check what error messages we raise when we pass a wrong object to it. Turns out the message is fine, but different from what we raise on iter(1) etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 00:06:33 2015 From: report at bugs.python.org (Mark Roseman) Date: Thu, 03 Sep 2015 22:06:33 +0000 Subject: [issue24996] IDLE: debugger local/global vars should not be editable In-Reply-To: <1441315753.96.0.0493251705052.issue24996@psf.upfronthosting.co.za> Message-ID: <1441317993.25.0.70807383174.issue24996@psf.upfronthosting.co.za> Mark Roseman added the comment: Thanks Terry, sorry I missed your previous mention of this. From what I recall the treeview doesn't allow editable items, but what I've done in similar circumstances before (editing text items on a canvas in drawing type programs) was 'place' an entry widget on top of it at the right location as needed and then get rid of the entry when done, which provides the correct effect. You know what, I think I know why they might have used an Entry widget... for really long values of variables the entry can stay a fixed width and will horizontal scroll, but a label will expand to the size of the content ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 00:09:37 2015 From: report at bugs.python.org (Cory Benfield) Date: Thu, 03 Sep 2015 22:09:37 +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: <1441318177.04.0.245725522331.issue17849@psf.upfronthosting.co.za> Cory Benfield added the comment: Ok, version three of the patch is now available. ---------- Added file: http://bugs.python.org/file40345/readline_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 00:09:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Sep 2015 22:09:58 +0000 Subject: [issue24989] scan_eol() Buffer Over-read In-Reply-To: <1441237226.71.0.655654379606.issue24989@psf.upfronthosting.co.za> Message-ID: <20150903220946.66874.52036@psf.io> Roundup Robot added the comment: New changeset a5858c30db7c by Serhiy Storchaka in branch '3.5': Issue #24989: Fixed buffer overread in BytesIO.readline() if a position is https://hg.python.org/cpython/rev/a5858c30db7c New changeset 215800fb955d by Serhiy Storchaka in branch 'default': Issue #24989: Fixed buffer overread in BytesIO.readline() if a position is https://hg.python.org/cpython/rev/215800fb955d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 00:36:01 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 03 Sep 2015 22:36:01 +0000 Subject: [issue24913] deque.index() overruns deque boundary In-Reply-To: <1440198546.56.0.00559117738444.issue24913@psf.upfronthosting.co.za> Message-ID: <20150903223554.114789.25940@psf.io> Roundup Robot added the comment: New changeset 9f8c59e61594 by Brett Cannon in branch '3.5': Issue #24913: Fix overrun error in deque.index(). https://hg.python.org/cpython/rev/9f8c59e61594 New changeset d093d87e449c by Brett Cannon in branch '3.5': Merge from 3.5.0 for issue #24913 https://hg.python.org/cpython/rev/d093d87e449c New changeset c6e0c29913ec by Brett Cannon in branch 'default': Merge from 3.5 for issue #24913 https://hg.python.org/cpython/rev/c6e0c29913ec ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 00:37:15 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 03 Sep 2015 22:37:15 +0000 Subject: [issue24913] deque.index() overruns deque boundary In-Reply-To: <1440198546.56.0.00559117738444.issue24913@psf.upfronthosting.co.za> Message-ID: <1441319835.74.0.618958819952.issue24913@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, that should cover 3.5.0 and then null merge through 3.5 and default. I thus consider my favour to Larry done and Raymond now owes me one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 02:10:33 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 04 Sep 2015 00:10:33 +0000 Subject: [issue24992] collections.OrderedDict constructor (odict_new) doesn't handle PyDict_New() failure In-Reply-To: <1441274033.3.0.407992349306.issue24992@psf.upfronthosting.co.za> Message-ID: <1441325433.72.0.493970372946.issue24992@psf.upfronthosting.co.za> Eric Snow added the comment: Thanks for taking care of this, Victor (and Serhiy). :) ---------- stage: -> resolved type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 02:23:13 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 00:23:13 +0000 Subject: [issue24996] IDLE: debugger local/global vars should not be editable In-Reply-To: <1441315753.96.0.0493251705052.issue24996@psf.upfronthosting.co.za> Message-ID: <1441326193.93.0.948583169998.issue24996@psf.upfronthosting.co.za> Terry J. Reedy added the comment: That makes sense, given that a string or list could be indefinitely long. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 03:35:01 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 01:35:01 +0000 Subject: [issue21192] Idle: Print filename when running a file from editor In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za> Message-ID: <1441330501.65.0.332044075402.issue21192@psf.upfronthosting.co.za> Terry J. Reedy added the comment: https://bitbucket.org/larry/cpython350/pull-requests/12/issue-21192-change-run-back-to-restart/diff ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 03:54:05 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 01:54:05 +0000 Subject: [issue21192] Idle: Print filename when running a file from editor In-Reply-To: <1441269066.76.0.643054582363.issue21192@psf.upfronthosting.co.za> Message-ID: <55E8F995.1030108@udel.edu> Terry J. Reedy added the comment: On 9/3/2015 4:31 AM, Larry Hastings wrote: > Terry, if you want this pulled in to Python 3.5.0, you'll need to create a pull request on Bitbucket. Instructions are here: > > https://mail.python.org/pipermail/python-dev/2015-August/141167.html I don't remember seeing this, but done now. > and here: > > https://mail.python.org/pipermail/python-dev/2015-August/141365.html I did get this. This step 4: Pull from the 3.5.0 repo into your "cpython351-merge" directory. % hg pull ssh://hg at bitbucket.org/larry/cpython350 gives me a Putty Fatal Error: Disconnected: No supported authentication methods available (server sent publickey). I presume it would require a key on deposit, as with python.org. It seems however that hg pull https://terryjreedy at bitbucket.org/larry/cpython350 might work in that it searched for changes and found none (as expected). There is something odd about the size of your clone. My cpython clone is 928 MB on disk with 30300 files, while the clone of my fork of your repository is 1.59 GB for 14500 files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 04:27:13 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 04 Sep 2015 02:27:13 +0000 Subject: [issue24991] Define instance mutability explicitly on type objects In-Reply-To: <1441260483.41.0.785006760825.issue24991@psf.upfronthosting.co.za> Message-ID: <1441333633.96.0.0210226876228.issue24991@psf.upfronthosting.co.za> Eric Snow added the comment: Yeah, this definitely relates to the project I'm working on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 05:34:55 2015 From: report at bugs.python.org (Duane Griffin) Date: Fri, 04 Sep 2015 03:34:55 +0000 Subject: [issue17582] xml.etree.ElementTree does not preserve whitespaces in attributes In-Reply-To: <1364660794.69.0.883579635559.issue17582@psf.upfronthosting.co.za> Message-ID: <1441337695.97.0.262088313434.issue17582@psf.upfronthosting.co.za> Duane Griffin added the comment: Here is a patch with a unit test for the new escaping functionality. I believe it covers all the new cases. Additional code is not required for cElementTree as the serialisation code is all Python. ---------- nosy: +duaneg Added file: http://bugs.python.org/file40346/17582-etree-whitespace-test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 05:35:42 2015 From: report at bugs.python.org (Milan Oberkirch) Date: Fri, 04 Sep 2015 03:35:42 +0000 Subject: [issue18540] imaplib.IMAP4() ends with "Name or service not known" on Fedora 18 In-Reply-To: <1374657571.18.0.17831195671.issue18540@psf.upfronthosting.co.za> Message-ID: <1441337742.61.0.99886231432.issue18540@psf.upfronthosting.co.za> Milan Oberkirch added the comment: I shouldn't criticize my own patches if I want to have them committed: Here comes the final and perfect patch for this issue ;) (I only rephrased the comment for the test to make the intuition clear.) ---------- Added file: http://bugs.python.org/file40347/imaplib_interpret_empty_string_as_None-final.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 06:24:09 2015 From: report at bugs.python.org (A Kaptur) Date: Fri, 04 Sep 2015 04:24:09 +0000 Subject: [issue24857] mock: Crash on comparing call_args with long strings In-Reply-To: <1439454881.01.0.0909899225137.issue24857@psf.upfronthosting.co.za> Message-ID: <1441340649.55.0.567028046391.issue24857@psf.upfronthosting.co.za> A Kaptur added the comment: It looks like there's a related bug in call_args around __ne__: >>> m = Mock() >>> m(1,2) >>> m.call_args call(1, 2) >>> m.call_args == call(1,2) True >>> m.call_args != call(1,2) True Any reason not to define __ne__ as not __eq__? Otherwise it looks like you fall back to tuple.__ne__, which does the wrong thing here. ---------- nosy: +akaptur _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 06:38:32 2015 From: report at bugs.python.org (A Kaptur) Date: Fri, 04 Sep 2015 04:38:32 +0000 Subject: [issue24857] mock: Crash on comparing call_args with long strings In-Reply-To: <1439454881.01.0.0909899225137.issue24857@psf.upfronthosting.co.za> Message-ID: <1441341512.02.0.646244662349.issue24857@psf.upfronthosting.co.za> A Kaptur added the comment: Here's a simple patch + test for the original bug. I'll file the __ne__ question separately. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file40348/issue24857.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 06:54:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Sep 2015 04:54:22 +0000 Subject: [issue24989] scan_eol() Buffer Over-read In-Reply-To: <1441237226.71.0.655654379606.issue24989@psf.upfronthosting.co.za> Message-ID: <1441342462.29.0.451723552154.issue24989@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: https://bitbucket.org/larry/cpython350/pull-requests/13/issue-24989/diff ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 06:56:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Sep 2015 04:56:19 +0000 Subject: [issue24986] It should be possible to build successfully without external libraries In-Reply-To: <1441225829.96.0.402628626785.issue24986@psf.upfronthosting.co.za> Message-ID: <20150904045615.101476.14209@psf.io> Roundup Robot added the comment: New changeset 2bc91f1f2b34 by Zachary Ware in branch '2.7': Issue #24986: Allow building Python without external libraries on Windows https://hg.python.org/cpython/rev/2bc91f1f2b34 New changeset 301c36746e42 by Zachary Ware in branch '3.5': Issue #24986: Allow building Python without external libraries on Windows https://hg.python.org/cpython/rev/301c36746e42 New changeset 50d38fa13282 by Zachary Ware in branch 'default': Closes #24986: Merge with 3.5 https://hg.python.org/cpython/rev/50d38fa13282 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 06:59:57 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 04 Sep 2015 04:59:57 +0000 Subject: [issue24986] It should be possible to build successfully without external libraries In-Reply-To: <1441225829.96.0.402628626785.issue24986@psf.upfronthosting.co.za> Message-ID: <1441342797.85.0.925958349313.issue24986@psf.upfronthosting.co.za> Zachary Ware added the comment: The committed versions are slightly different, I had bad logic in adding _socket to ExtensionModules (if IncludeExternals was false while IncludeSSL was true, _socket wasn't added). build.bat also uses the property names instead of its own internal names so as not to stomp on the environment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 07:07:38 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 Sep 2015 05:07:38 +0000 Subject: [issue21192] Idle: Print filename when running a file from editor In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za> Message-ID: <1441343258.11.0.205853430247.issue21192@psf.upfronthosting.co.za> Larry Hastings added the comment: Pull request accepted, please forward-merge. Thanks! > There is something odd about the size of your clone. My cpython > clone is 928 MB on disk with 30300 files, while the clone of my fork > of your repository is 1.59 GB for 14500 files. I have no idea why. All I can tell you is, I made my cpython350 directory by forking the official Bitbucket mirror of the cpython tree ( https://bitbucket.org/mirror/cpython ) and updating it. If you're on a UNIX-y filesystem (something with hardlinks), the "relink" extension for Mercurial can help cut down on the disk space consumed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 07:08:39 2015 From: report at bugs.python.org (A Kaptur) Date: Fri, 04 Sep 2015 05:08:39 +0000 Subject: [issue24997] mock.call_args compares as equal and not equal Message-ID: <1441343319.6.0.391788581363.issue24997@psf.upfronthosting.co.za> New submission from A Kaptur: mock.call_args can be both equal to and not equal to another object: >>> m = Mock() >>> m(1,2) >>> m.call_args call(1, 2) >>> m.call_args == call(1,2) True >>> m.call_args != call(1,2) True This appears to be a recent regression - it repros on trunk, but not on 3.3 or 2.7 with mock 1.3.0. ---------- components: Library (Lib) messages: 249715 nosy: akaptur priority: normal severity: normal stage: needs patch status: open title: mock.call_args compares as equal and not equal type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 07:11:54 2015 From: report at bugs.python.org (Paul Clarke) Date: Fri, 04 Sep 2015 05:11:54 +0000 Subject: [issue24998] docs: subprocess.Popen example has extra/invalid parameter Message-ID: <1441343514.48.0.676306018011.issue24998@psf.upfronthosting.co.za> New submission from Paul Clarke: in "subprocess" module documentation has a section for "replacing older functions with subprocess", specifically 17.1.4.5 "replacing os.popen", which includes the example on "return code handling", specifically this line: -- process = Popen("cmd", 'w', shell=True, stdin=PIPE) -- That 'w' shouldn't be there. ---------- assignee: docs at python components: Documentation messages: 249716 nosy: Paul Clarke, docs at python priority: normal severity: normal status: open title: docs: subprocess.Popen example has extra/invalid parameter versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 07:13:49 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 Sep 2015 05:13:49 +0000 Subject: [issue24989] scan_eol() Buffer Over-read In-Reply-To: <1441237226.71.0.655654379606.issue24989@psf.upfronthosting.co.za> Message-ID: <1441343629.97.0.39920676103.issue24989@psf.upfronthosting.co.za> Larry Hastings added the comment: Pull request accepted. Please forward-merge. Thanks! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 07:37:08 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Sep 2015 05:37:08 +0000 Subject: [issue24989] scan_eol() Buffer Over-read In-Reply-To: <1441237226.71.0.655654379606.issue24989@psf.upfronthosting.co.za> Message-ID: <20150904053704.101492.70317@psf.io> Roundup Robot added the comment: New changeset 2b6ce7e9595c by Serhiy Storchaka in branch '3.5': Issue #24989: Fixed buffer overread in BytesIO.readline() if a position is https://hg.python.org/cpython/rev/2b6ce7e9595c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 08:14:48 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Sep 2015 06:14:48 +0000 Subject: [issue24986] It should be possible to build successfully without external libraries In-Reply-To: <1441225829.96.0.402628626785.issue24986@psf.upfronthosting.co.za> Message-ID: <20150904061444.68885.13618@psf.io> Roundup Robot added the comment: New changeset 252d4760f28b by Zachary Ware in branch '2.7': Issue #24986: Save some bandwidth from svn.python.org https://hg.python.org/cpython/rev/252d4760f28b New changeset 4e7ce0b10eea by Zachary Ware in branch '3.5': Issue #24986: Save some bandwidth from svn.python.org https://hg.python.org/cpython/rev/4e7ce0b10eea New changeset eca6ecc62b95 by Zachary Ware in branch 'default': Issue #24986: Merge with 3.5 https://hg.python.org/cpython/rev/eca6ecc62b95 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 08:53:14 2015 From: report at bugs.python.org (eryksun) Date: Fri, 04 Sep 2015 06:53:14 +0000 Subject: [issue24998] docs: subprocess.Popen example has extra/invalid parameter In-Reply-To: <1441343514.48.0.676306018011.issue24998@psf.upfronthosting.co.za> Message-ID: <1441349594.29.0.686470320115.issue24998@psf.upfronthosting.co.za> Changes by eryksun : ---------- keywords: +easy priority: normal -> low versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 08:58:30 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 06:58:30 +0000 Subject: [issue24635] test_typing is flaky In-Reply-To: <1436924045.27.0.387044794067.issue24635@psf.upfronthosting.co.za> Message-ID: <1441349910.82.0.222359750722.issue24635@psf.upfronthosting.co.za> STINNER Victor added the comment: Is there any progress on this issue? It's still failing randomly: http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.5/builds/221/steps/test/logs/stdio ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 08:59:51 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 06:59:51 +0000 Subject: [issue24635] test_typing is flaky In-Reply-To: <1436924045.27.0.387044794067.issue24635@psf.upfronthosting.co.za> Message-ID: <1441349991.32.0.374302320567.issue24635@psf.upfronthosting.co.za> STINNER Victor added the comment: ====================================================================== FAIL: test_abstractset (test.test_typing.CollectionsAbcTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/srv/buildbot/buildarea/3.5.bolen-ubuntu/build/Lib/test/test_typing.py", line 955, in test_abstractset assert isinstance(set(), typing.AbstractSet) AssertionError ====================================================================== FAIL: test_bytestring (test.test_typing.CollectionsAbcTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/srv/buildbot/buildarea/3.5.bolen-ubuntu/build/Lib/test/test_typing.py", line 979, in test_bytestring assert isinstance(b'', typing.ByteString) AssertionError ====================================================================== FAIL: test_container (test.test_typing.CollectionsAbcTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/srv/buildbot/buildarea/3.5.bolen-ubuntu/build/Lib/test/test_typing.py", line 951, in test_container assert isinstance([], typing.Container) AssertionError ====================================================================== FAIL: test_iterable (test.test_typing.CollectionsAbcTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/srv/buildbot/buildarea/3.5.bolen-ubuntu/build/Lib/test/test_typing.py", line 936, in test_iterable assert isinstance([], typing.Iterable) AssertionError ====================================================================== FAIL: test_iterator (test.test_typing.CollectionsAbcTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/srv/buildbot/buildarea/3.5.bolen-ubuntu/build/Lib/test/test_typing.py", line 942, in test_iterator assert isinstance(it, typing.Iterator) AssertionError ====================================================================== FAIL: test_mapping (test.test_typing.CollectionsAbcTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/srv/buildbot/buildarea/3.5.bolen-ubuntu/build/Lib/test/test_typing.py", line 963, in test_mapping assert isinstance({}, typing.Mapping) AssertionError ====================================================================== FAIL: test_mutablemapping (test.test_typing.CollectionsAbcTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/srv/buildbot/buildarea/3.5.bolen-ubuntu/build/Lib/test/test_typing.py", line 967, in test_mutablemapping assert isinstance({}, typing.MutableMapping) AssertionError ====================================================================== FAIL: test_mutablesequence (test.test_typing.CollectionsAbcTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/srv/buildbot/buildarea/3.5.bolen-ubuntu/build/Lib/test/test_typing.py", line 975, in test_mutablesequence assert isinstance([], typing.MutableSequence) AssertionError ====================================================================== FAIL: test_mutableset (test.test_typing.CollectionsAbcTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/srv/buildbot/buildarea/3.5.bolen-ubuntu/build/Lib/test/test_typing.py", line 959, in test_mutableset assert isinstance(set(), typing.MutableSet) AssertionError ====================================================================== FAIL: test_sequence (test.test_typing.CollectionsAbcTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/srv/buildbot/buildarea/3.5.bolen-ubuntu/build/Lib/test/test_typing.py", line 971, in test_sequence assert isinstance([], typing.Sequence) AssertionError ---------------------------------------------------------------------- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 09:06:22 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 Sep 2015 07:06:22 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1441350382.15.0.838315954803.issue21998@psf.upfronthosting.co.za> Larry Hastings added the comment: Surely this is too late for 3.5? ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 09:07:16 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 Sep 2015 07:07:16 +0000 Subject: [issue22970] asyncio: Cancelling wait() after notification leaves Condition in an inconsistent state In-Reply-To: <1417404582.01.0.276361050449.issue22970@psf.upfronthosting.co.za> Message-ID: <1441350436.17.0.418368066047.issue22970@psf.upfronthosting.co.za> Larry Hastings added the comment: Is anyone going to try and fix this for 3.5.0? Or should we "kick the can down the road" and reassign it to 3.6? ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 09:07:36 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 07:07:36 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1441350456.36.0.428878479446.issue21998@psf.upfronthosting.co.za> STINNER Victor added the comment: > Surely this is too late for 3.5? I'm not 100% convinced that asyncio must support fork, so it's too late :-) Anyway, we don't care, asyncio will be under provisional status for one more cycle (3.5) :-p ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 09:08:36 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 Sep 2015 07:08:36 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1417530925.56.0.55888060474.issue22980@psf.upfronthosting.co.za> Message-ID: <1441350516.4.0.251577520001.issue22980@psf.upfronthosting.co.za> Larry Hastings added the comment: I sure hope not. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 09:09:16 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 Sep 2015 07:09:16 +0000 Subject: [issue23623] Python 3.5 docs need to clarify how to set PATH, etc In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za> Message-ID: <1441350556.26.0.961820851531.issue23623@psf.upfronthosting.co.za> Larry Hastings added the comment: Can we close this out? ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 09:10:16 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 Sep 2015 07:10:16 +0000 Subject: [issue24745] Better default font for editor In-Reply-To: <1438129028.22.0.104228147207.issue24745@psf.upfronthosting.co.za> Message-ID: <1441350616.8.0.834634688361.issue24745@psf.upfronthosting.co.za> Larry Hastings added the comment: Anything happening with this? We tag 3.5.0rc3 in about 36 hours. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 09:11:32 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 Sep 2015 07:11:32 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441350692.35.0.880894723925.issue23517@psf.upfronthosting.co.za> Larry Hastings added the comment: I will happy delegate to Tim Peters whether or not this should be fixed in 3.5.0, or whether it should wait until 3.5.1 or even 3.6. Tim, ball's in your court! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 09:12:05 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 Sep 2015 07:12:05 +0000 Subject: [issue24748] Change of behavior for importlib between 3.4 and 3.5 with DLL loading In-Reply-To: <1438176027.56.0.467476097176.issue24748@psf.upfronthosting.co.za> Message-ID: <1441350725.21.0.738224290359.issue24748@psf.upfronthosting.co.za> Larry Hastings added the comment: Anything happening with this? We tag 3.5.0rc3 in about 36 hours. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 09:12:15 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 Sep 2015 07:12:15 +0000 Subject: [issue24635] test_typing is flaky In-Reply-To: <1436924045.27.0.387044794067.issue24635@psf.upfronthosting.co.za> Message-ID: <1441350735.29.0.907252114926.issue24635@psf.upfronthosting.co.za> Larry Hastings added the comment: Anything happening with this? We tag 3.5.0rc3 in about 36 hours. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 09:12:55 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 07:12:55 +0000 Subject: [issue24635] test_typing is flaky In-Reply-To: <1436924045.27.0.387044794067.issue24635@psf.upfronthosting.co.za> Message-ID: <1441350775.9.0.883193739484.issue24635@psf.upfronthosting.co.za> STINNER Victor added the comment: > Anything happening with this? We tag 3.5.0rc3 in about 36 hours. I believe that it's a bug in test_typing, not in the typing module. So it must not block the release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 09:13:43 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 Sep 2015 07:13:43 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1441350823.81.0.906601132738.issue21998@psf.upfronthosting.co.za> Larry Hastings added the comment: I've remarked it as "normal" priority and moved it to 3.6. Not my problem anymore! :D ---------- priority: deferred blocker -> normal versions: +Python 3.6 -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 09:13:50 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 Sep 2015 07:13:50 +0000 Subject: [issue21998] asyncio: support fork In-Reply-To: <1405613445.85.0.0173565539891.issue21998@psf.upfronthosting.co.za> Message-ID: <1441350830.2.0.929513649787.issue21998@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- nosy: -larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 09:14:20 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 Sep 2015 07:14:20 +0000 Subject: [issue24635] test_typing is flaky In-Reply-To: <1436924045.27.0.387044794067.issue24635@psf.upfronthosting.co.za> Message-ID: <1441350860.32.0.449321098984.issue24635@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- priority: deferred blocker -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 09:39:16 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 07:39:16 +0000 Subject: [issue21192] Idle: Print filename when running a file from editor In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za> Message-ID: <1441352356.28.0.881898569057.issue21192@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This was pull #12. Am I correct in thinking that all the merges Serhiy did after for pull #13 included the null merge for this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 09:49:17 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 Sep 2015 07:49:17 +0000 Subject: [issue21192] Idle: Print filename when running a file from editor In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za> Message-ID: <1441352957.38.0.269400780526.issue21192@psf.upfronthosting.co.za> Larry Hastings added the comment: The pull requests are numbered by creation order, not by merge order. Normally I'd expect that yes, Serhiy's merge would include yours. But it didn't work out that way. If you look at the changeset graph: https://bitbucket.org/larry/cpython350/commits/all Serhiy merged his revision (2b6ce7e), not my merge commit afterwards (07e04c3) which includes your change. So your change still needs to be forward-merged. Please pull and merge the current head (07e04c3), thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 09:52:54 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 07:52:54 +0000 Subject: [issue24635] test_typing is flaky In-Reply-To: <1436924045.27.0.387044794067.issue24635@psf.upfronthosting.co.za> Message-ID: <1441353174.49.0.445300515046.issue24635@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, I found a short script to reproduce the bug: -- import typing: assert isinstance([], typing.Container) assert isinstance([], typing.Container) -- The first check calls typing.GenericMeta.__subclasscheck__(list) which calls abc.ABCMeta.__subclasscheck__(typing.Container, list). The problem is that not only abc.ABCMeta.__subclasscheck__() returns False, but it adds also list to typing.Container._abc_negative_cache. The next check returns False without calling typing.GenericMeta.__subclasscheck__(list), in fact ABCMeta.__instancecheck__(typing.GenericMeta, list) returns immediatly False because list is in typing.Container._abc_negative_cache. The problem: GenericMeta calls ABCMeta.__subclasscheck__() which returns False, but ABCMeta.__subclasscheck__() also stores the result "False" in cache, whereas it's not the expected result. Should we override __instancecheck__ in GenericMeta? @Guido: are you interested to fix this complex metaclass/type issue? I don't have time to fix it right now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 10:05:54 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 08:05:54 +0000 Subject: [issue21192] Idle: Print filename when running a file from editor In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za> Message-ID: <1441353953.99.0.390833305297.issue21192@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Since your merge contains the changes that Serhiy already merged, I expect that there will be some conflicts. If so, the only thing I would know to do is revert and make mine and his null merges. If that is correct, will do. Making merge clone now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 10:19:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Sep 2015 08:19:12 +0000 Subject: [issue21192] Idle: Print filename when running a file from editor In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za> Message-ID: <20150904081908.68887.46627@psf.io> Roundup Robot added the comment: New changeset 09cd7d57b080 by Terry Jan Reedy in branch '3.5': Issue #21192: Change 'RUN' back to 'RESTART' when running editor file. https://hg.python.org/cpython/rev/09cd7d57b080 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 10:19:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Sep 2015 08:19:12 +0000 Subject: [issue24989] scan_eol() Buffer Over-read In-Reply-To: <1441237226.71.0.655654379606.issue24989@psf.upfronthosting.co.za> Message-ID: <20150904081908.68887.74737@psf.io> Roundup Robot added the comment: New changeset 07e04c34bab5 by Larry Hastings in branch '3.5': Merged in storchaka/cpython350 (pull request #13) https://hg.python.org/cpython/rev/07e04c34bab5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 10:21:52 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 Sep 2015 08:21:52 +0000 Subject: [issue21192] Idle: Print filename when running a file from editor In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za> Message-ID: <1441354912.32.0.982032852633.issue21192@psf.upfronthosting.co.za> Larry Hastings added the comment: There won't be conflicts with Serhiy's merge--just the opposite. His pull request was merged first, so it's perfect that he did his forward merge first. He's already resolved any conflicts with his merge, and so when you merge you'll only have to worry about your own changes. Just merge the current head (07e04c3), it'll be fine, honest! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 10:22:53 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 08:22:53 +0000 Subject: [issue21192] Idle: Print filename when running a file from editor In-Reply-To: <1397078686.2.0.0309283772804.issue21192@psf.upfronthosting.co.za> Message-ID: <1441354973.69.0.374773579834.issue21192@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I was wrong, no conflicts. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 10:34:53 2015 From: report at bugs.python.org (Thomas) Date: Fri, 04 Sep 2015 08:34:53 +0000 Subject: [issue24964] Add tunnel CONNECT response headers to httplib / http.client In-Reply-To: <1440956510.2.0.613573748355.issue24964@psf.upfronthosting.co.za> Message-ID: <1441355693.27.0.206680106159.issue24964@psf.upfronthosting.co.za> Thomas added the comment: Martin: Thanks for your quick answer (and sorry for sending the whole file) ! I think it is indeed a good idea to detach the proxy connection and treat it as any other connection, as you did in your patch. It would be great if you would be able to dig it up ! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 10:40:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Sep 2015 08:40:00 +0000 Subject: [issue24745] Better default font for editor In-Reply-To: <1438129028.22.0.104228147207.issue24745@psf.upfronthosting.co.za> Message-ID: <20150904083956.66852.53494@psf.io> Roundup Robot added the comment: New changeset 34a8078f6249 by Terry Jan Reedy in branch '2.7': Issue #24745: Prevent IDLE initialization crash with Tk 8.4; patch by Ned Deily. https://hg.python.org/cpython/rev/34a8078f6249 New changeset b4830b9f8c10 by Terry Jan Reedy in branch '3.4': Issue #24745: Prevent IDLE initialization crash with Tk 8.4; patch by Ned Deily. https://hg.python.org/cpython/rev/b4830b9f8c10 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 10:42:25 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 08:42:25 +0000 Subject: [issue24745] Better default font for editor In-Reply-To: <1438129028.22.0.104228147207.issue24745@psf.upfronthosting.co.za> Message-ID: <1441356145.08.0.641245446375.issue24745@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I backported change already in 3.5.0+. ---------- priority: deferred blocker -> normal resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 10:53:09 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 08:53:09 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441356789.18.0.766937367536.issue23517@psf.upfronthosting.co.za> STINNER Victor added the comment: Backport to Python 3.4 splitted in 3 patches: * (1) timedelta_round_half_up_py34.patch, backport changeset 0eb8c182131e: "datetime.timedelta constructor now rounds microseconds to nearest with ties going away from zero (ROUND_HALF_UP)". * (2) round_half_up.patch: add _PyTime_ROUND_HALF_UP rounding mode to the _PyTime API * (3) fromtimestamp_round_half_up.patch, backport changeset bf634dfe076f: "fromtimestamp() and utcfromtimestamp() methods of datetime.datetime now round microseconds to nearest with ties going away from zero (ROUND_HALF_UP)" ---------- keywords: +patch Added file: http://bugs.python.org/file40349/timedelta_round_half_up_py34.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 10:53:19 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 08:53:19 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441356799.14.0.631706005585.issue23517@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file40350/round_half_up_py34.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 10:53:31 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 08:53:31 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441356811.15.0.109782552547.issue23517@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file40351/fromtimestamp_round_half_up_py34.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 10:55:47 2015 From: report at bugs.python.org (Ezio Melotti) Date: Fri, 04 Sep 2015 08:55:47 +0000 Subject: [issue23144] html.parser.HTMLParser: setting 'convert_charrefs = True' leads to dropped text In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za> Message-ID: <1441356947.7.0.388236634863.issue23144@psf.upfronthosting.co.za> Ezio Melotti added the comment: I'll try to take care of this during the weekend. Feel free to ping me if I don't. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 11:11:45 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 09:11:45 +0000 Subject: [issue22970] asyncio: Cancelling wait() after notification leaves Condition in an inconsistent state In-Reply-To: <1417404582.01.0.276361050449.issue22970@psf.upfronthosting.co.za> Message-ID: <1441357905.8.0.351743046396.issue22970@psf.upfronthosting.co.za> STINNER Victor added the comment: asyncio keeps its "provisional API" status in the Python 3.5 cycle, so this issue must not block the 3.5.0 release. It can be fixed later. This issue is complex, I'm not convinced that asyncio-fix-wait-cancellation-race.patch is the best fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 11:53:33 2015 From: report at bugs.python.org (Paul Moore) Date: Fri, 04 Sep 2015 09:53:33 +0000 Subject: [issue23623] Python 3.5 docs need to clarify how to set PATH, etc In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za> Message-ID: <1441360413.06.0.87696955302.issue23623@psf.upfronthosting.co.za> Paul Moore added the comment: Now that "Add Python to PATH" is an option on the front screen of the installer (not hidden behind the scary "customize" option) this can be closed. I recall Steve suggesting there might be issues with the way a user install results in the path entries coming after the system path, but let's not worry about those unless we get specific issue reports. ---------- priority: deferred blocker -> normal resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 12:10:09 2015 From: report at bugs.python.org (Petr Viktorin) Date: Fri, 04 Sep 2015 10:10:09 +0000 Subject: [issue24748] Change of behavior for importlib between 3.4 and 3.5 with DLL loading In-Reply-To: <1438176027.56.0.467476097176.issue24748@psf.upfronthosting.co.za> Message-ID: <1441361409.83.0.995920564146.issue24748@psf.upfronthosting.co.za> Petr Viktorin added the comment: So, if I understand correctly, the problem is that the new imp.load_dynamic in 3.5.0b checks sys.modules, so if a module of the same name was loaded previously, it's only reloaded, skipping the create_module step. This patch bypasses that check, so a new module is always loaded. This brings this aspect of imp.load_dynamic to how it was in 3.4. However, I have no way to test if it fixes pywin32 or py2exe. ---------- keywords: +patch Added file: http://bugs.python.org/file40352/issue24748.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 12:23:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 10:23:10 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC Message-ID: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> New submission from STINNER Victor: The crash occurred on the buildbot "x86-64 Windows Server 2012R2 ICC 3.x". Do you we officially support the ICC compiler? -- There are still some curious compiler warnings: Objects\longobject.c(4498): warning #63: shift count is too large => "#if LONG_MAX >> 2*PyLong_SHIFT" Objects\longobject.c(4519): warning #63: shift count is too large => "#if LONG_MAX >> 2*PyLong_SHIFT" I don't understand the test: do we test if the result is zero? On Windows, a long is only 32-bits. I guess that PyLong_SHIFT is 30 (so 2*PyLong_SHIFT=60). Maybe we should put "#elif defined(PY_LONG_LONG) && PY_LLONG_MAX >> 2*PyLong_SHIFT" before? -- The crash itself: http://buildbot.python.org/all/builders/x86-64%20Windows%20Server%202012R2%20ICC%203.x/builds/83/steps/test/logs/stdio [ 14/398] test_re Fatal Python error: Segmentation fault Current thread 0x00000578 (most recent call first): File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\re.py", line 163 in match File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\test_re.py", line 976 in test_sre_character_class_literals File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\case.py", line 600 in run File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\case.py", line 648 in __call__ File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\suite.py", line 122 in run File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\suite.py", line 84 in __call__ File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\suite.py", line 122 in run File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\suite.py", line 84 in __call__ File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\suite.py", line 122 in run File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\suite.py", line 84 in __call__ File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\unittest\runner.py", line 176 in run File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\support\__init__.py", line 1775 in _run_suite File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\lib\test\support\__init__.py", line 1809 in run_unittest File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\..\lib\test\regrtest.py", line 1280 in test_runner File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\..\lib\test\regrtest.py", line 1281 in runtest_inner File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\..\lib\test\regrtest.py", line 968 in runtest File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\..\lib\test\regrtest.py", line 763 in main File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\..\lib\test\regrtest.py", line 1565 in main_in_temp_cwd File "C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\..\lib\test\regrtest.py", line 1590 in ---------- components: Build, Windows messages: 249749 nosy: haypo, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC type: crash versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 12:23:35 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 04 Sep 2015 10:23:35 +0000 Subject: [issue18540] imaplib.IMAP4() ends with "Name or service not known" on Fedora 18 In-Reply-To: <1374657571.18.0.17831195671.issue18540@psf.upfronthosting.co.za> Message-ID: <1441362215.09.0.830698503254.issue18540@psf.upfronthosting.co.za> Berker Peksag added the comment: Hi Milan, thanks for the updated patch. Did you see my review comments? http://bugs.python.org/review/18540/ ---------- nosy: +berker.peksag stage: -> patch review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 12:23:56 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 10:23:56 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1441362236.76.0.952158707113.issue24999@psf.upfronthosting.co.za> STINNER Victor added the comment: Zachary Ware is the administrator of the buildbot. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 12:55:59 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 04 Sep 2015 10:55: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: <1441364159.21.0.136126518654.issue17849@psf.upfronthosting.co.za> Martin Panter added the comment: Patch 3 looks better IMO. Now instead of the TypeError, we should see an error something like socket.error: Tunnel connection failed: 200 I?ll commit this in a day or so, perhaps with an improved error message, like ?Invalid response from tunnel request?. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 13:05:56 2015 From: report at bugs.python.org (Marco Paolini) Date: Fri, 04 Sep 2015 11:05:56 +0000 Subject: [issue24891] race condition in initstdio() (python aborts running under nohup) In-Reply-To: <1439936328.26.0.889765372825.issue24891@psf.upfronthosting.co.za> Message-ID: <1441364756.85.0.775546651593.issue24891@psf.upfronthosting.co.za> Marco Paolini added the comment: Attaching a patch. Does it make any sense? ---------- keywords: +patch nosy: +mpaolini Added file: http://bugs.python.org/file40353/issue24891.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 13:08:46 2015 From: report at bugs.python.org (Marco Paolini) Date: Fri, 04 Sep 2015 11:08:46 +0000 Subject: [issue24891] race condition in initstdio() (python aborts running under nohup) In-Reply-To: <1439936328.26.0.889765372825.issue24891@psf.upfronthosting.co.za> Message-ID: <1441364926.84.0.275316157496.issue24891@psf.upfronthosting.co.za> Marco Paolini added the comment: ops wrong patch... trying again. ---------- Added file: http://bugs.python.org/file40354/issue24891.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 13:08:57 2015 From: report at bugs.python.org (Marco Paolini) Date: Fri, 04 Sep 2015 11:08:57 +0000 Subject: [issue24891] race condition in initstdio() (python aborts running under nohup) In-Reply-To: <1439936328.26.0.889765372825.issue24891@psf.upfronthosting.co.za> Message-ID: <1441364937.17.0.14550070817.issue24891@psf.upfronthosting.co.za> Changes by Marco Paolini : Removed file: http://bugs.python.org/file40353/issue24891.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 13:48:46 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 04 Sep 2015 11:48:46 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> Message-ID: <1441367326.63.0.570144590857.issue23406@psf.upfronthosting.co.za> Martin Panter added the comment: I was about to commit this, but I think I was wrong about one of my comments. The list that is multiplied is indeed shallow-copied. E.g. ?[x] * 1? copies the list, but the reference to x is the same. I propose to commit the second patch, except to revert one of the sentences to the first patch, so it reads: Note also that the copies are shallow; nested structures are not copied but referenced. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 14:12:55 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 12:12:55 +0000 Subject: [issue24891] race condition in initstdio() (python aborts running under nohup) In-Reply-To: <1441364937.25.0.0266598801626.issue24891@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Yes, it looks like a good approach. Some comments: - please mention this issue "Issue #24891" and explain the issue in a comment in create_stdio_checked() - it would be safer to check the exception type, to be extra safe - you must clear the exception - why not putting the code in create_stdio() directly? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 14:25:41 2015 From: report at bugs.python.org (Alex Etling) Date: Fri, 04 Sep 2015 12:25:41 +0000 Subject: [issue25000] _mock_call does not properly grab args and kwargs Message-ID: <1441369541.43.0.73938065209.issue25000@psf.upfronthosting.co.za> New submission from Alex Etling: Consider the following lines of code: def test_mock(val): fake_mock = Mock() a = {} fake_mock.func(a) a['val'] = 5 fake_mock.func.assert_has_calls([call({})]) What i would expect would be for this statement to pass. What I actually see is the following: Traceback (most recent call last): File "/gc/gclib/python/tests/kafka_production/encoding_test.py", line 121, in test_mock fake_mock.func.assert_has_calls([call({})]) File "/usr/local/lib/python2.7/dist-packages/mock.py", line 863, in assert_has_calls 'Actual: %r' % (calls, self.mock_calls) AssertionError: Calls not found. Expected: [call({})] Actual: [call({'val': 5})] Mock thinks that I have passed in {'val': 5}, when I in fact did pass in {}. The errors seems to be the way args and kwargs are being grabbed in _mock_call function ---------- components: Macintosh messages: 249757 nosy: ned.deily, paetling, ronaldoussoren priority: normal severity: normal status: open title: _mock_call does not properly grab args and kwargs type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 14:28:52 2015 From: report at bugs.python.org (Alex Etling) Date: Fri, 04 Sep 2015 12:28:52 +0000 Subject: [issue25000] _mock_call does not properly grab args and kwargs In-Reply-To: <1441369541.43.0.73938065209.issue25000@psf.upfronthosting.co.za> Message-ID: <1441369732.41.0.112884539486.issue25000@psf.upfronthosting.co.za> Alex Etling added the comment: I attempted to fix this by just deepcopying on creation of the _call object, on line 927 of mock.py but this caused a lot of strange errors I did not expect. If you could advise on how best to proceed to fix, I would greatly appreciate it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 14:40:12 2015 From: report at bugs.python.org (flying sheep) Date: Fri, 04 Sep 2015 12:40:12 +0000 Subject: [issue7175] Define a standard location and API for configuration files In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za> Message-ID: <1441370412.34.0.886368888274.issue7175@psf.upfronthosting.co.za> flying sheep added the comment: just because people do something doesn?t mean it?s right. i guess the tendency for CLI applications to do it wrong comes from 1. their ad-hoc beginnings. you usually start with one script file and extend it 2. availability expanduser('~') is in the stdlib and more well-known than e.g. appdirs, and people don?t like to add dependencies to small things 3. the shell and old, widely used applications using ~/.appname, so it?s more well-know to do that on the other hand, GUI applications usually have a build system in place for UI file compilation, need a .desktop file installed, and so on, i.e. need more boilerplate and dependencies from the start, and people have to research how to do things properly. GUI libraries have their built-in standard dirs interfaces as well. ???????? another thing. on the python-ideas thread someone mentioned that > I count 17 of those on my Windows machine (!) right now, including .idlerc, .ipython, .matplotlib, .ipylint.d etc. this is horrible! this is so obviously the wrong thing to do. i hope having the module will reduce the number of similar atrocities. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 15:25:52 2015 From: report at bugs.python.org (Michael Foord) Date: Fri, 04 Sep 2015 13:25:52 +0000 Subject: [issue7175] Define a standard location and API for configuration files In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za> Message-ID: <1441373152.0.0.757907612166.issue7175@psf.upfronthosting.co.za> Changes by Michael Foord : ---------- nosy: -michael.foord _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 15:39:46 2015 From: report at bugs.python.org (Marco Paolini) Date: Fri, 04 Sep 2015 13:39:46 +0000 Subject: [issue24891] race condition in initstdio() (python aborts running under nohup) In-Reply-To: <1439936328.26.0.889765372825.issue24891@psf.upfronthosting.co.za> Message-ID: <1441373986.32.0.143863734885.issue24891@psf.upfronthosting.co.za> Marco Paolini added the comment: @haypo thanks for the quick review. This new issue24891_2.patch covers all of the points you raised except the "check exception type" which I am still figuring out. ---------- Added file: http://bugs.python.org/file40355/issue24891_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 16:03:44 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Sep 2015 14:03:44 +0000 Subject: [issue24998] docs: subprocess.Popen example has extra/invalid parameter In-Reply-To: <1441343514.48.0.676306018011.issue24998@psf.upfronthosting.co.za> Message-ID: <20150904140341.12017.66883@psf.io> Roundup Robot added the comment: New changeset 0ff7aa9a438f by R David Murray in branch '2.7': #24998: fix cut and paste error in subprocess example. https://hg.python.org/cpython/rev/0ff7aa9a438f New changeset 47e711a7416b by R David Murray in branch '3.4': #24998: fix cut and paste error in subprocess example. https://hg.python.org/cpython/rev/47e711a7416b New changeset fa53edb32962 by R David Murray in branch '3.5': Merge: #24998: fix cut and paste error in subprocess example. https://hg.python.org/cpython/rev/fa53edb32962 New changeset 75e10a5cbf43 by R David Murray in branch 'default': Merge: #24998: fix cut and paste error in subprocess example. https://hg.python.org/cpython/rev/75e10a5cbf43 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 16:05:52 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Sep 2015 14:05:52 +0000 Subject: [issue24998] docs: subprocess.Popen example has extra/invalid parameter In-Reply-To: <1441343514.48.0.676306018011.issue24998@psf.upfronthosting.co.za> Message-ID: <1441375552.89.0.198339312677.issue24998@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for the report. I'm surprised that hasn't been noticed before. I'm also wondering why the 'shell=True' was removed from the example in the python3 docs (and why whoever did that didn't notice the bug :), but that would be a separate issue (someone would need to figure out why the change was made before undoing it...) ---------- nosy: +r.david.murray resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 16:14:18 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Sep 2015 14:14:18 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1441376058.24.0.432399340294.issue24999@psf.upfronthosting.co.za> R. David Murray added the comment: We don't officially support ICC yet, but the buildbots are a step in the direction of proposing that we do. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 16:19:20 2015 From: report at bugs.python.org (Yann Sionneau) Date: Fri, 04 Sep 2015 14:19:20 +0000 Subject: [issue23630] support multiple hosts in create_server/start_server In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za> Message-ID: <1441376360.15.0.645338689233.issue23630@psf.upfronthosting.co.za> Yann Sionneau added the comment: A new (and hopefully last?) version of the patch, thanks again for the review Victor! ---------- Added file: http://bugs.python.org/file40356/multibind7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 16:23:13 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Sep 2015 14:23:13 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> Message-ID: <1441376593.04.0.101670870642.issue23406@psf.upfronthosting.co.za> R. David Murray added the comment: What is actually happening is that the *contents* of the list are copied, but the list itself is not. This is a consequence of the definition in terms of +. So, yes, that is a shallow copy, but not quite in the sense that mylist.copy() is a shallow copy, since the references to the contents of s get appended to the list being constructed by *, not a new list that is a "copy" of s. You are correct that "s is only referenced" is not really accurate. But how about "Note that the contents of the *s* object are not copied, they are referenced multiple times". I think that highlights the source of the confusion: that the *contents* are not copied. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 16:24:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 14:24:17 +0000 Subject: [issue24891] race condition in initstdio() (python aborts running under nohup) In-Reply-To: <1439936328.26.0.889765372825.issue24891@psf.upfronthosting.co.za> Message-ID: <1441376657.21.0.914606072881.issue24891@psf.upfronthosting.co.za> STINNER Victor added the comment: > This new issue24891_2.patch covers all of the points you raised except the "check exception type" which I am still figuring out. See my patch issue24891_3.patch which calls PyErr_ExceptionMatches(PyExc_OSError). If you like it, I can push it to Python 3.4-3.6. ---------- Added file: http://bugs.python.org/file40357/issue24891_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 16:24:50 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Sep 2015 14:24:50 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> Message-ID: <1441376690.58.0.407548565848.issue23406@psf.upfronthosting.co.za> R. David Murray added the comment: Sorry, I meant "references to the content are copied" in my first sentence there. This just goes to show why this is complicated to explain :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 16:30:53 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Sep 2015 14:30:53 +0000 Subject: [issue7175] Define a standard location and API for configuration files In-Reply-To: <1256037677.34.0.670034749287.issue7175@psf.upfronthosting.co.za> Message-ID: <1441377053.41.0.644450646902.issue7175@psf.upfronthosting.co.za> R. David Murray added the comment: The "tendency of CLI applications to do it wrong" comes from the fact that they are following the *older* unix (de-facto) standard, which is to put config files in the home directory as dot files. That is, they are *not* doing it wrong, they are following the older unix de-facto standard and not the freedesktop.org standard (which, you will note, is a standard arising out of GUI applications, not CLI applications). Not, mind, you, that I think .config is a bad standard, I'm just saying that if you want to follow standards you need to account for the legacy standard as well as the new standard. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 16:41:46 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Sep 2015 14:41:46 +0000 Subject: [issue24635] test_typing is flaky In-Reply-To: <1436924045.27.0.387044794067.issue24635@psf.upfronthosting.co.za> Message-ID: <1441377706.11.0.366157627063.issue24635@psf.upfronthosting.co.za> Guido van Rossum added the comment: Sorry, this is a bug in typing.py. https://github.com/ambv/typehinting/issues/155 It's a subtle bug but the first reporter has done some good research; I will try to find time to fix it today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 16:53:07 2015 From: report at bugs.python.org (Marco Paolini) Date: Fri, 04 Sep 2015 14:53:07 +0000 Subject: [issue24891] race condition in initstdio() (python aborts running under nohup) In-Reply-To: <1439936328.26.0.889765372825.issue24891@psf.upfronthosting.co.za> Message-ID: <1441378387.43.0.0129695212467.issue24891@psf.upfronthosting.co.za> Marco Paolini added the comment: @haypo, yeah, definitely better than mine! All good for me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 17:01:56 2015 From: report at bugs.python.org (Tim Peters) Date: Fri, 04 Sep 2015 15:01:56 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441378916.75.0.119366356336.issue23517@psf.upfronthosting.co.za> Tim Peters added the comment: Larry, I appreciate the vote of confidence, but I'm ill-equipped to help at the patch level: I'm solely on Windows, and (long story) don't even have a C compiler at the moment. The patch(es) are too broad and delicate to be sure of without kicking the tires (running contrived examples). So I would sub-delegate to Alexander and/or Mark. They understand the issues too. I was just the most annoying about insisting it get fixed ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 17:19:38 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 15:19:38 +0000 Subject: [issue23630] support multiple hosts in create_server/start_server In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za> Message-ID: <1441379978.29.0.862646009117.issue23630@psf.upfronthosting.co.za> STINNER Victor added the comment: Good. I have less comments, it's getting better at each iteration ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 17:31:53 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Sep 2015 15:31:53 +0000 Subject: [issue24891] race condition in initstdio() (python aborts running under nohup) In-Reply-To: <1439936328.26.0.889765372825.issue24891@psf.upfronthosting.co.za> Message-ID: <20150904153151.11254.8017@psf.io> Roundup Robot added the comment: New changeset e67bf9c9a898 by Victor Stinner in branch '3.4': Fix race condition in create_stdio() https://hg.python.org/cpython/rev/e67bf9c9a898 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 17:34:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Sep 2015 15:34:26 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1441380866.91.0.375561395935.issue24999@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > I don't understand the test: do we test if the result is zero? We test that signed long is enough to contain 2 digits. May be it should be written as LONG_MAX >> PyLong_SHIFT >> PyLong_SHIFT. > Maybe we should put "#elif defined(PY_LONG_LONG) && PY_LLONG_MAX >> 2*PyLong_SHIFT" before? No. We need to use long long only if long is not enough. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 17:35:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 15:35:10 +0000 Subject: [issue24891] race condition in initstdio() (python aborts running under nohup) In-Reply-To: <1439936328.26.0.889765372825.issue24891@psf.upfronthosting.co.za> Message-ID: <1441380910.89.0.0577303541705.issue24891@psf.upfronthosting.co.za> STINNER Victor added the comment: > @haypo, yeah, definitely better than mine! All good for me. Ok. I added your name to Misc/ACKS. I had to do some tricks to apply the patch to Python 3.4 (code was in Python/pythonrun.c) and then to merge to Python 3.5 (code moved to Python/pylifecycle.c). But I checked the fix in each version using gdb: * put a breakpoint on create_stdio, * type "print close(0)" after the first is_valid_fd() check, * see that the open() exception is correctly handled (type "next", "next", ... and check that we go to the error: label and then enter the if() block) Thanks for your patch Marco. I prefer to be extra safe by checking the raised exception to minimize the risk of regression. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 17:36:47 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 15:36:47 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1441381007.35.0.224155704226.issue24999@psf.upfronthosting.co.za> STINNER Victor added the comment: > We test that signed long is enough to contain 2 digits. May be it should be written as LONG_MAX >> PyLong_SHIFT >> PyLong_SHIFT. Ok, but I don't understand "if ". Does it mean "if != 0"? Maybe we can use SIZEOF_LONG instead of LONG_MAX? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 17:38:40 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 04 Sep 2015 15:38:40 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1441381120.16.0.519226063221.issue24999@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 17:40:27 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 15:40:27 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441381227.84.0.349220693791.issue23517@psf.upfronthosting.co.za> STINNER Victor added the comment: > Larry, I appreciate the vote of confidence, but I'm ill-equipped to help at the patch level: (...) The patch(es) are too broad and delicate to be sure of without kicking the tires (running contrived examples). Well, the patches change how timedelta, .fromtimestamp() and .utcfromtimestamp() round the number of microseconds. It's a deliberate choice since it was decided that the current rounding mode is a bug, and not a feature :-) The code is well tested. There are unit tests on how numbers are rounded for: timedelta, .(utc)fromtimestamp(), and even the C private API _PyTime. The code is (almost) the same in default and was validated on various platforms. So I'm confident on the change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 17:51:57 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 04 Sep 2015 15:51:57 +0000 Subject: [issue25000] _mock_call does not properly grab args and kwargs In-Reply-To: <1441369541.43.0.73938065209.issue25000@psf.upfronthosting.co.za> Message-ID: <1441381917.9.0.458697005321.issue25000@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +michael.foord, rbcollins -ned.deily, ronaldoussoren versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 17:52:32 2015 From: report at bugs.python.org (Tim Peters) Date: Fri, 04 Sep 2015 15:52:32 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441381952.76.0.204993850588.issue23517@psf.upfronthosting.co.za> Tim Peters added the comment: That's great, Victor! Another person trying the code with their own critical eyes would still be prudent. Two days ago you wrote: > This part of Python (handling timestamps, especially > the rounding mode) is complex, I prefer to check for > all buildbots and wait for some feedback from users > (wait at least 2 weeks). It's not entirely clear why that switched to "So I'm confident on the change." in 12 days short of 2 weeks ;-) I have no reason to doubt your confidence. Just saying some independent checking is prudent (but I can't do it at this time). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 18:07:42 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 04 Sep 2015 16:07:42 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441382862.4.0.165759256383.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I'll try to find the time to kick the tires on this patch this weekend. ---------- assignee: -> belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 18:18:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 04 Sep 2015 16:18:25 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1441383505.0.0.390883769035.issue24999@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, it means "if != 0". The condition is equivalent to SIZEOF_LONG*CHAR_BIT-1 >= 2*PyLong_SHIFT on binary computers with two-complementarn two's-complement integers. But current form looks more natural to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 18:22:25 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 16:22:25 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1441383745.44.0.389306496813.issue24999@psf.upfronthosting.co.za> STINNER Victor added the comment: > The condition is equivalent to SIZEOF_LONG*CHAR_BIT-1 >= 2*PyLong_SHIFT on binary computers with two-complementarn two's-complement integers. But current form looks more natural to me. Oh by the way: I have no idea if the test_re crash is related to this warning :-) I don't plan to install ICC to reproduce the issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 18:23:57 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 04 Sep 2015 16:23:57 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1441383837.72.0.498450046569.issue24999@psf.upfronthosting.co.za> Zachary Ware added the comment: Replacing the two instances of "LONG_MAX >> 2*PyLong_SHIFT" with "SIZEOF_LONG*CHAR_BIT-1 >= 2*PyLong_SHIFT" fixes the warnings, but does nothing for test_re. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 18:41:45 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 04 Sep 2015 16:41:45 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1441384905.37.0.434628017828.issue24999@psf.upfronthosting.co.za> Zachary Ware added the comment: Another lovely facet of this segfault: it doesn't occur when built in Debug configuration. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 18:42:06 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 16:42:06 +0000 Subject: [issue24956] Default value for an argument that is not in the choices list gets accepted In-Reply-To: <1440843994.53.0.0278400690294.issue24956@psf.upfronthosting.co.za> Message-ID: <1441384926.09.0.44588212404.issue24956@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Which module are you asking about? We could ask author of behavior in question as to intention. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 18:47:45 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 16:47:45 +0000 Subject: [issue24635] test_typing is flaky In-Reply-To: <1441377706.11.0.366157627063.issue24635@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > It's a subtle bug but the first reporter has done some good research; I will try to find time to fix it today. Oh, it's already known and investigated by someone else. Great. I didn't know this github project. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 18:52:37 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 16:52:37 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1441381952.76.0.204993850588.issue23517@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: 2015-09-04 17:52 GMT+02:00 Tim Peters : > That's great, Victor! Another person trying the code with their own critical eyes would still be prudent. Sure! > It's not entirely clear why that switched to "So I'm confident on the change." in 12 days short of 2 weeks ;-) He he. 2 days ago, the buildbots were broken for various reasons. I fixed a lot of issues (unrelated to this rounding mode issue), so I now got the confirmation that the test pass on all platforms. > I have no reason to doubt your confidence. Just saying some independent checking is prudent (but I can't do it at this time). Sorry if I wasn't clear. I'm confident, but not enough to not wait for a review :-) -- Usually, I don't wait for a review simply because there are too few reviewers :-( I spent the last 3 years to work alone on the funnny _PyTime C API project. I started to write an article to tell this journey ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 18:52:57 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 16:52:57 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1441382862.4.0.165759256383.issue23517@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Alexander Belopolsky added the comment: > I'll try to find the time to kick the tires on this patch this weekend. Cool! Keep me in touch ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 18:54:47 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 04 Sep 2015 16:54:47 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441385687.83.0.219886228409.issue23517@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 18:58:28 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 04 Sep 2015 16:58:28 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441385908.39.0.709726962367.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Victor, Do I understand correctly that this is already committed in 3.4 - 3.6 development branches and we just need to decide whether to cherry-pick this fix to 3.5rc? Is the "review" link up-to date? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 19:05:44 2015 From: report at bugs.python.org (Sworddragon) Date: Fri, 04 Sep 2015 17:05:44 +0000 Subject: [issue24956] Default value for an argument that is not in the choices list gets accepted In-Reply-To: <1440843994.53.0.0278400690294.issue24956@psf.upfronthosting.co.za> Message-ID: <1441386344.43.0.755094093724.issue24956@psf.upfronthosting.co.za> Sworddragon added the comment: I was thinking about cases where the default is variable for example a call to platform.machine() while the choices list (and the script itself) might not support all exotic architectures for its use that might be returned now or in a future version of Python from this function. In this case the call to platform.machine() could be wrapped into a function that checks if the returned value is one of the values in the choices list but that would be the same that I would normally expect to be done by the argparse module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 19:23:16 2015 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 04 Sep 2015 17:23:16 +0000 Subject: [issue21159] configparser.InterpolationMissingOptionError is not very intuitive In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za> Message-ID: <1441387396.05.0.94742675306.issue21159@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Thanks for handling this, I was indeed busy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 19:23:19 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 04 Sep 2015 17:23:19 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441387399.42.0.0538482317678.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: It looks like this patch violates fromtimestamp(s) == EPOCH + timedelta(seconds=s) invariant: Python 3.6.0a0 (default:73911e6c97c8, Sep 4 2015, 13:14:12) >>> E = datetime(1970,1,1,tzinfo=timezone.utc) >>> s = -1/2**7 >>> datetime.fromtimestamp(s, timezone.utc) == E + timedelta(seconds=s) False ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 19:23:56 2015 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 04 Sep 2015 17:23:56 +0000 Subject: [issue23572] functools.singledispatch fails when "not BaseClass" is True In-Reply-To: <1425385029.2.0.304023107943.issue23572@psf.upfronthosting.co.za> Message-ID: <1441387436.62.0.616189646439.issue23572@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Thank you for fixing this and sorry for not being responsive sooner! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 19:28:49 2015 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 04 Sep 2015 17:28:49 +0000 Subject: [issue24488] ConfigParser.getboolean fails on boolean options In-Reply-To: <1434991517.36.0.491167534114.issue24488@psf.upfronthosting.co.za> Message-ID: <1441387729.02.0.160298219166.issue24488@psf.upfronthosting.co.za> ?ukasz Langa added the comment: As R. David pointed out, this is fixed in Python 3 by emphasizing configparser is designed to hold strings at all times. Changing this would break lots of existing code out there. So, sadly, #wontfix. Thank you for your report though. If you find the documentation is misleading, create a change for that and we'll submit it. ---------- resolution: -> wont fix stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 19:29:53 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 17:29:53 +0000 Subject: [issue24957] python -m pdb error.py: stuck in unexitable infinite prompt loop In-Reply-To: <1440863094.43.0.957124241662.issue24957@psf.upfronthosting.co.za> Message-ID: <1441387793.57.0.463073792238.issue24957@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Pdb says "Running 'cont' or 'step' will restart the program" but it seems to restart on any recognized command other than 'h' and traps everything else. I verified behavior on Win7 with ordinary syntax error 'a = = 1' on installed 2.7.10 and 3.4.3. Removed qualifiers from title. Doc says ''' python3 -m pdb myscript.py When invoked as a script, pdb will automatically enter post-mortem debugging if the program being debugged exits abnormally. After post-mortem debugging (or after normal exit of the program), pdb will restart the program.''' But not being able to exit could not have been the intention. Looking at the code. ---------- nosy: +georg.brandl, terry.reedy stage: -> test needed title: python3 -mpdb gets stuck in an unexitable infinite prompt loop when running some Python 2 code with syntax errors -> python -m pdb error.py: stuck in unexitable infinite prompt loop versions: +Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 19:33:29 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Sep 2015 17:33:29 +0000 Subject: [issue24956] Default value for an argument that is not in the choices list gets accepted In-Reply-To: <1440843994.53.0.0278400690294.issue24956@psf.upfronthosting.co.za> Message-ID: <1441388009.12.0.150612073553.issue24956@psf.upfronthosting.co.za> R. David Murray added the comment: I assume you are talking about the behavior of the argparse 'choices' feature? That is what my comment was addressed to. I didn't actually run a test to see if it behaves the way you describe :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 19:35:09 2015 From: report at bugs.python.org (Tim Peters) Date: Fri, 04 Sep 2015 17:35:09 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441388109.36.0.976663108602.issue23517@psf.upfronthosting.co.za> Tim Peters added the comment: FYI, that invariant failed for me just now under the released 3.4.3 too: Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from datetime import * >>> E = datetime(1970,1,1,tzinfo=timezone.utc) >>> s = -1/2**7 >>> datetime.fromtimestamp(s, timezone.utc) datetime.datetime(1969, 12, 31, 23, 59, 59, 992187, tzinfo=datetime.timezone.utc) >>> E + timedelta(seconds=s) datetime.datetime(1969, 12, 31, 23, 59, 59, 992188, tzinfo=datetime.timezone.utc) It's an exactly-tied rounding case for the exactly-representable-in-binary s = -0.0078125. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 19:40:25 2015 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 04 Sep 2015 17:40:25 +0000 Subject: [issue2651] Strings passed to KeyError do not round trip In-Reply-To: <1208453081.65.0.886847251895.issue2651@psf.upfronthosting.co.za> Message-ID: <1441388425.43.0.0926719047211.issue2651@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 19:43:14 2015 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 04 Sep 2015 17:43:14 +0000 Subject: [issue24142] ConfigParser._read doesn't join multi-line values collected while reading if a ParsingError occured In-Reply-To: <1431014086.96.0.315028213592.issue24142@psf.upfronthosting.co.za> Message-ID: <1441388594.24.0.458080144608.issue24142@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- assignee: -> lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 19:43:24 2015 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Fri, 04 Sep 2015 17:43:24 +0000 Subject: [issue24086] Configparser interpolation is unexpected In-Reply-To: <1430421130.2.0.837084015548.issue24086@psf.upfronthosting.co.za> Message-ID: <1441388604.9.0.0331579904401.issue24086@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- assignee: -> lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 19:43:26 2015 From: report at bugs.python.org (John Leitch) Date: Fri, 04 Sep 2015 17:43:26 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441388606.65.0.54708948585.issue24917@psf.upfronthosting.co.za> Changes by John Leitch : ---------- nosy: +belopolsky, lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 19:49:44 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 17:49:44 +0000 Subject: [issue16180] cannot quit pdb when there is a syntax error in the debuggee (must kill it) In-Reply-To: <1349811204.12.0.797224741983.issue16180@psf.upfronthosting.co.za> Message-ID: <1441388984.05.0.808200117727.issue16180@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Reported again in #24957 Xavier, your link is out of date. ---------- nosy: +georg.brandl, terry.reedy stage: -> test needed versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 19:50:44 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 17:50:44 +0000 Subject: [issue24957] python -m pdb error.py: stuck in unexitable infinite prompt loop In-Reply-To: <1440863094.43.0.957124241662.issue24957@psf.upfronthosting.co.za> Message-ID: <1441389044.19.0.372227176978.issue24957@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> duplicate stage: test needed -> resolved status: open -> closed superseder: -> cannot quit pdb when there is a syntax error in the debuggee (must kill it) type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 19:54:00 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 04 Sep 2015 17:54:00 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441389240.62.0.525727261014.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Can someone check 3.3? I believe that was the release where we tried to get various rounding issues right. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 20:13:15 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Sep 2015 18:13:15 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> Message-ID: <1441390395.44.0.402840751485.issue23406@psf.upfronthosting.co.za> R. David Murray added the comment: Or better, "items in the list *s* are not copied..." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 20:15:44 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 04 Sep 2015 18:15:44 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441390544.34.0.410683932834.issue24917@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Is there a CERT report associated with this vulnerability? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 20:18:13 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 04 Sep 2015 18:18:13 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441390693.49.0.628871551734.issue24917@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 20:18:29 2015 From: report at bugs.python.org (John Leitch) Date: Fri, 04 Sep 2015 18:18:29 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441390709.7.0.133172291052.issue24917@psf.upfronthosting.co.za> John Leitch added the comment: Currently, no. Would you like us to report this and future vulnerabilities to CERT? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 20:19:06 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 18:19:06 +0000 Subject: [issue16180] cannot quit pdb when there is a syntax error in the debuggee (must kill it) In-Reply-To: <1349811204.12.0.797224741983.issue16180@psf.upfronthosting.co.za> Message-ID: <1441390746.17.0.817402137308.issue16180@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Simple fix attached. I copied the exit code from this part of the 'while True:' loop. try: pdb._runscript(mainpyfile) if pdb._user_requested_quit: break print("The program finished and will be restarted") I am not sure if the conditional is still needed there. Xavier, if you have a better patch, please upload it. ---------- keywords: +patch Added file: http://bugs.python.org/file40358/pdbloopfix.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 20:22:33 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 18:22:33 +0000 Subject: [issue24960] Can't use pip or easy_install with embeddable zip file. In-Reply-To: <1440869782.83.0.207113001402.issue24960@psf.upfronthosting.co.za> Message-ID: <1441390953.6.0.378668070367.issue24960@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +Marcus.Smith, dstufft, ncoghlan, paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 20:24:52 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 18:24:52 +0000 Subject: [issue24964] Add tunnel CONNECT response headers to httplib / http.client In-Reply-To: <1440956510.2.0.613573748355.issue24964@psf.upfronthosting.co.za> Message-ID: <1441391092.05.0.41817909372.issue24964@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thomas, please sign a contributor agreement for your patches to be considered. https://www.python.org/psf/contrib/ https://www.python.org/psf/contrib/contrib-form/ ---------- nosy: +terry.reedy stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 20:26:29 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 18:26:29 +0000 Subject: [issue24969] functools.lru_cache: a way to set decorator arguments at runtime In-Reply-To: <1441036040.75.0.88592797115.issue24969@psf.upfronthosting.co.za> Message-ID: <1441391189.73.0.416116757251.issue24969@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 20:30:03 2015 From: report at bugs.python.org (Donald Stufft) Date: Fri, 04 Sep 2015 18:30:03 +0000 Subject: [issue24960] Can't use pip or easy_install with embeddable zip file. In-Reply-To: <1440869782.83.0.207113001402.issue24960@psf.upfronthosting.co.za> Message-ID: <1441391403.41.0.512215490032.issue24960@psf.upfronthosting.co.za> Donald Stufft added the comment: This looks more like lib2to3 doesn't support running from a .zip archive. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 20:32:02 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 04 Sep 2015 18:32:02 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441391522.25.0.408742305083.issue24917@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: This is happening in windows-only code, so not being a windows user I cannot reproduce it. It does not look like something new. This code was last touched in #10653. Can someone confirm that only 3.5 is affected? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 20:34:06 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 04 Sep 2015 18:34:06 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441391646.67.0.287575987981.issue24917@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > Would you like us to report this and future vulnerabilities to CERT? If it affects released versions, I think this is the right thing to do. Note that I don't know what PSF policy is on this is or whether they even have one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 20:34:35 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 18:34:35 +0000 Subject: [issue24972] IDLE: revisit text highlighting for inactive windows on win32 In-Reply-To: <1441047261.05.0.292381389884.issue24972@psf.upfronthosting.co.za> Message-ID: <1441391675.24.0.495874201238.issue24972@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Rather than copying the nosy list from an old issue, which likely contains people no longer interested, better to announce a followup on the old issue. I am not sure what you want me to try out. If it is a code change, please upload a patch. If it is a user action, please specify. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 20:38:05 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 04 Sep 2015 18:38:05 +0000 Subject: [issue24748] Change of behavior for importlib between 3.4 and 3.5 with DLL loading In-Reply-To: <1438176027.56.0.467476097176.issue24748@psf.upfronthosting.co.za> Message-ID: <1441391885.91.0.0307235631836.issue24748@psf.upfronthosting.co.za> Brett Cannon added the comment: Assuming I didn't screw this up -- I'm new to the whole Windows development thing -- the new test along with the rest of the test suite pass under Windows 10 on the default branch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 21:00:40 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Sep 2015 19:00:40 +0000 Subject: [issue24635] test_typing is flaky In-Reply-To: <1436924045.27.0.387044794067.issue24635@psf.upfronthosting.co.za> Message-ID: <20150904190034.68885.31390@psf.io> Roundup Robot added the comment: New changeset d1f41c614e62 by Guido van Rossum in branch '3.5': Issue #24635: Fixed flakiness in test_typing.py. https://hg.python.org/cpython/rev/d1f41c614e62 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 21:01:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Sep 2015 19:01:19 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <20150904190117.12006.75371@psf.io> Roundup Robot added the comment: New changeset a0194ec4195c by Eric V. Smith in branch 'default': Removed Implementation Limitations section. While the version of the code on http://bugs.python.org/issue24965 has the 255 expression limitation, I'm going to remove this limit. The i18n section was purely speculative. We can worry about it if/when we add i18n and i-strings. https://hg.python.org/peps/rev/a0194ec4195c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 21:02:19 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Sep 2015 19:02:19 +0000 Subject: [issue24635] test_typing is flaky In-Reply-To: <1436924045.27.0.387044794067.issue24635@psf.upfronthosting.co.za> Message-ID: <1441393339.46.0.534712393131.issue24635@psf.upfronthosting.co.za> Guido van Rossum added the comment: Fixed now on the 3.5 branch. I still have to merge to default and create the pull request for Larry. ---------- assignee: -> gvanrossum resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 21:19:10 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Sep 2015 19:19:10 +0000 Subject: [issue24635] test_typing is flaky In-Reply-To: <1436924045.27.0.387044794067.issue24635@psf.upfronthosting.co.za> Message-ID: <1441394350.36.0.368752827348.issue24635@psf.upfronthosting.co.za> Guido van Rossum added the comment: Pull request for Larry: https://bitbucket.org/larry/cpython350/pull-requests/14/fix-issue-24635/diff ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 21:21:38 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Sep 2015 19:21:38 +0000 Subject: [issue24635] test_typing is flaky In-Reply-To: <1436924045.27.0.387044794067.issue24635@psf.upfronthosting.co.za> Message-ID: <1441394498.02.0.557348004454.issue24635@psf.upfronthosting.co.za> Guido van Rossum added the comment: BTW, I screwed up and committed this into the public 3.5 repo first (and merged from there into default). I guess once Larry has merged the fix into his special closed 3.5 bitbucket repo I should do a null merge from there back to public 3.5 and forward the null merge to 3.6 as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 21:22:26 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Sep 2015 19:22:26 +0000 Subject: [issue24635] test_typing is flaky In-Reply-To: <1436924045.27.0.387044794067.issue24635@psf.upfronthosting.co.za> Message-ID: <1441394546.35.0.100489083448.issue24635@psf.upfronthosting.co.za> Guido van Rossum added the comment: Assigning to Larry since the next step is his. ---------- assignee: gvanrossum -> larry priority: high -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 21:30:08 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 04 Sep 2015 19:30:08 +0000 Subject: [issue24954] No way to generate or parse timezone as produced by datetime.isoformat() In-Reply-To: <1440801281.72.0.545558404714.issue24954@psf.upfronthosting.co.za> Message-ID: <1441395008.08.0.223643938365.issue24954@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: This request is similar to (if not a duplicate of) issue 15873. Gnu date uses the following extensions to %z instruction of strftime/strptime: %z +hhmm numeric timezone (e.g., -0400) %:z +hh:mm numeric timezone (e.g., -04:00) %::z +hh:mm:ss numeric time zone (e.g., -04:00:00) %:::z numeric time zone with : to necessary precision (e.g., -04, +05:30) I think it is reasonable to add those to python. ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 21:32:23 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 04 Sep 2015 19:32:23 +0000 Subject: [issue24954] No way to generate or parse timezone as produced by datetime.isoformat() In-Reply-To: <1440801281.72.0.545558404714.issue24954@psf.upfronthosting.co.za> Message-ID: <1441395143.44.0.379415731949.issue24954@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 21:49:21 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 04 Sep 2015 19:49:21 +0000 Subject: [issue24635] test_typing is flaky In-Reply-To: <1436924045.27.0.387044794067.issue24635@psf.upfronthosting.co.za> Message-ID: <1441396161.04.0.161143169776.issue24635@psf.upfronthosting.co.za> Larry Hastings added the comment: Pull request accepted. Please forward merge, thanks! And, yes, this will be a null merge because you already separately committed it to 3.5. ---------- assignee: larry -> gvanrossum stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 21:54:15 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 19:54:15 +0000 Subject: [issue24981] Add a test which uses the ast module to compile the stdlib In-Reply-To: <1441140555.75.0.593788380292.issue24981@psf.upfronthosting.co.za> Message-ID: <1441396455.46.0.577114473097.issue24981@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The attached recurses one level deep in Lib. Catching UnicodeDecodeError on file read is needed at least for "test/test_source_encoding.py 'utf-8' codec can't decode byte 0xf0 in position 267: invalid continuation byte". Catching "badxxx.py" is needed for several test/ modules. This test may have found another hole: It prints "C:/programs/Python35/Lib\distutils _msvccompiler.py None disallowed in expression list" whereas >>> compile(open('C:/programs/Python35/Lib\distutils\_msvccompiler.py').read(), '', 'exec') at 0x00000000034A3F60, file "", line 8> ---------- nosy: +terry.reedy Added file: http://bugs.python.org/file40359/temast.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 21:55:30 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 19:55:30 +0000 Subject: [issue24981] Add a test which uses the ast module to compile the stdlib In-Reply-To: <1441140555.75.0.593788380292.issue24981@psf.upfronthosting.co.za> Message-ID: <1441396530.81.0.275734524196.issue24981@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Forgot to mention: runtime 4 seconds. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 21:56:28 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 19:56:28 +0000 Subject: [issue24981] Add a test which uses the ast module to compile the stdlib In-Reply-To: <1441140555.75.0.593788380292.issue24981@psf.upfronthosting.co.za> Message-ID: <1441396588.56.0.859219489791.issue24981@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Ran with installed 3.5.0rc1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 21:57:25 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Sep 2015 19:57:25 +0000 Subject: [issue24635] test_typing is flaky In-Reply-To: <1436924045.27.0.387044794067.issue24635@psf.upfronthosting.co.za> Message-ID: <20150904195722.15734.72961@psf.io> Roundup Robot added the comment: New changeset 0f37918440c9 by Guido van Rossum in branch 'default': Issue #24635: Fixed flakiness in test_typing.py. (Merge from 3.5.) https://hg.python.org/cpython/rev/0f37918440c9 New changeset 438dde69871d by Guido van Rossum in branch '3.5': Fix issue #24635. https://hg.python.org/cpython/rev/438dde69871d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 21:57:35 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Sep 2015 19:57:35 +0000 Subject: [issue24635] test_typing is flaky In-Reply-To: <1436924045.27.0.387044794067.issue24635@psf.upfronthosting.co.za> Message-ID: <1441396655.53.0.797586128715.issue24635@psf.upfronthosting.co.za> Guido van Rossum added the comment: OK, done. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 22:03:15 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 20:03:15 +0000 Subject: [issue24990] Foreign language support in turtle module In-Reply-To: <1441238139.14.0.540040388391.issue24990@psf.upfronthosting.co.za> Message-ID: <1441396995.42.0.597587068263.issue24990@psf.upfronthosting.co.za> Terry J. Reedy added the comment: > discussion elsewhere #24978, translate docs to Russian ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 22:09:05 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 20:09:05 +0000 Subject: [issue24997] mock.call_args compares as equal and not equal In-Reply-To: <1441343319.6.0.391788581363.issue24997@psf.upfronthosting.co.za> Message-ID: <1441397345.67.0.90968395866.issue24997@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +michael.foord, rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 22:12:01 2015 From: report at bugs.python.org (Yi Ding) Date: Fri, 04 Sep 2015 20:12:01 +0000 Subject: [issue24891] race condition in initstdio() (python aborts running under nohup) In-Reply-To: <1439936328.26.0.889765372825.issue24891@psf.upfronthosting.co.za> Message-ID: <1441397521.48.0.480662532626.issue24891@psf.upfronthosting.co.za> Yi Ding added the comment: Thank you everyone! I will test the next rc of 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 22:23:28 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 20:23:28 +0000 Subject: [issue24891] race condition in initstdio() (python aborts running under nohup) In-Reply-To: <1441397521.48.0.480662532626.issue24891@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I don't plan to send a pull request to the Python 3.5 release manager. This bug existed since Python 3.0, the fix can wait for Python 3.5.1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 22:30:24 2015 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 04 Sep 2015 20:30:24 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441398624.08.0.0253515387237.issue23517@psf.upfronthosting.co.za> Mark Lawrence added the comment: Python 3.3.5 (v3.3.5:62cf4e77f785, Mar 9 2014, 10:35:05) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from datetime import * >>> E = datetime(1970,1,1,tzinfo=timezone.utc) >>> s = -1/2**7 >>> datetime.fromtimestamp(s, timezone.utc) datetime.datetime(1969, 12, 31, 23, 59, 59, 992187, tzinfo=datetime.timezone.utc) >>> E + timedelta(seconds=s) datetime.datetime(1969, 12, 31, 23, 59, 59, 992187, tzinfo=datetime.timezone.utc) FWIW Windows 10. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 22:30:34 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 04 Sep 2015 20:30:34 +0000 Subject: [issue24981] Add a test which uses the ast module to compile the stdlib In-Reply-To: <1441140555.75.0.593788380292.issue24981@psf.upfronthosting.co.za> Message-ID: <1441398634.53.0.0496263427769.issue24981@psf.upfronthosting.co.za> Brett Cannon added the comment: Two things about the UTF-8 decode issue. One is you don't need to decode the source for it to be compiled; ast.parse()/compile() will work from bytes objects and thus handle the decoded for you. Two, if you want to decode source files into text, use importlib.util.decode_source(). Since Terry's script shows a complete compilation of the stdlib is very fast, we should make this a proper test. Any resulting test should probably should go into test_compile(). We can have it read all files and those that raise a a SyntaxError or some such exception can simply be skipped as the test is about AST -> code and not source -> AST (although we could theoretically have the test validate the failure with a source -> code compilation as well and verify the same exception is raised). We can also double-check that any AST -> code failure passes under source -> code and then report a failure (basically I'm trying to avoid blacklisting files that are test cases for the compiler overall and are known to fail). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 22:38:19 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 20:38:19 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1441398624.08.0.0253515387237.issue23517@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Oh, it looks like my implementation of ROUND_HALF_UP is wrong. Negative numbers are not correctly rounded :-/ I'm working on a fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 22:46:57 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 04 Sep 2015 20:46:57 +0000 Subject: [issue25001] Make --nowindows argument to regrtest propagate when running with -j Message-ID: <1441399617.05.0.891415993838.issue25001@psf.upfronthosting.co.za> New submission from Brett Cannon: Not sure how feasible this is, but when running tests under Windows it's very nice to run with --nowindows on, else you get barraged with a ton of debugging warnings. The problem is that if you use -j the use of --nowindows gets turned off. It would be nice if using --nowindows worked with -j to speed up test execution on Windows while also being less noisy. ---------- components: Tests, Windows messages: 249828 nosy: brett.cannon, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: Make --nowindows argument to regrtest propagate when running with -j type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 22:48:03 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Sep 2015 20:48:03 +0000 Subject: [issue25002] Deprecate asyncore/asynchat Message-ID: <1441399683.85.0.786847810998.issue25002@psf.upfronthosting.co.za> New submission from Guido van Rossum: Now that we've got asyncio in two releases (3.4 and 3.5) we should start deprecating asyncore and asynchat. There isn't much use of these in the stdlib (smtpd.py uses them, and a bunch of tests) and we should probably rewrite those to use asyncio. Maybe smtpd.py can be deprecated itself. ---------- messages: 249829 nosy: gvanrossum priority: normal severity: normal status: open title: Deprecate asyncore/asynchat versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 22:50:04 2015 From: report at bugs.python.org (Donald Stufft) Date: Fri, 04 Sep 2015 20:50:04 +0000 Subject: [issue25002] Deprecate asyncore/asynchat In-Reply-To: <1441399683.85.0.786847810998.issue25002@psf.upfronthosting.co.za> Message-ID: <1441399804.83.0.00733642797735.issue25002@psf.upfronthosting.co.za> Donald Stufft added the comment: I'm all for deprecating asyncore/asynchat but should deprecating them wait until asyncio is no longer provisional? ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 22:52:18 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Sep 2015 20:52:18 +0000 Subject: [issue25002] Deprecate asyncore/asynchat In-Reply-To: <1441399683.85.0.786847810998.issue25002@psf.upfronthosting.co.za> Message-ID: <1441399938.49.0.318033070008.issue25002@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 22:53:09 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Sep 2015 20:53:09 +0000 Subject: [issue25002] Deprecate asyncore/asynchat In-Reply-To: <1441399683.85.0.786847810998.issue25002@psf.upfronthosting.co.za> Message-ID: <1441399989.44.0.102475999407.issue25002@psf.upfronthosting.co.za> Guido van Rossum added the comment: Yes, in 3.6 asyncio will no longer be provisional and we can start deprecating async{ore,hat}. Which is why I marked this bug with 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 22:53:20 2015 From: report at bugs.python.org (paul j3) Date: Fri, 04 Sep 2015 20:53:20 +0000 Subject: [issue24956] Default value for an argument that is not in the choices list gets accepted In-Reply-To: <1440843994.53.0.0278400690294.issue24956@psf.upfronthosting.co.za> Message-ID: <1441400000.15.0.650703532116.issue24956@psf.upfronthosting.co.za> paul j3 added the comment: A related issue which Sworddragon found just before starting this issue is http://bugs.python.org/issue9625 The handling of defaults in argparse is a bit complicated. In general it errs on the side of giving the user/developer freedom to set them how ever they want. That's especially true in the case of non-string defaults. A default does not have to be something that the user could give. In particular the default 'default' is None, which can't be parsed from the command line. The same for boolean values (the default 'type' does not translate string 'False' to boolean 'False'.) Errors in the defaults are usually caught during program development. If the calling code generates the defaults dynamically, it seems reasonable that it should also check that they are valid. The validity test for choices is a simple 'in' (contains) one. 'choices' can be a list or dictionary (keys), and can even be dynamically generated. parser = .... choices = default = if default not in choices: parser.add_argument(..., choices=choices, default=default) etc. ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 22:55:41 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 20:55:41 +0000 Subject: [issue25002] Deprecate asyncore/asynchat In-Reply-To: <1441399683.85.0.786847810998.issue25002@psf.upfronthosting.co.za> Message-ID: <1441400141.7.0.255055461996.issue25002@psf.upfronthosting.co.za> STINNER Victor added the comment: The documentation of both modules begin with the following note: "This module exists for backwards compatibility only. For new code we recommend using asyncio." What do you mean by deprecating the module? Emit a PendingDeprecationWarning in Python 3.6 and emit a DeprecationWarning in Python 3.7? > Maybe smtpd.py can be deprecated itself. Maybe it can be fun to rewrite the module using asyncio, but I'm not convinced that a SMTP server in the Python stdlib is super useful. (A HTTP server *is* very useful, it saved my life multiple times when I worked on embedded devices without any server available to transfer files.) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 23:05:01 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 04 Sep 2015 21:05:01 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441400701.77.0.641885820308.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Victor, I did not quite understand why you've chosen ROUND_HALF_UP over ROUND_HALF_EVEN, but as long as fromtimestamp() uses the same rounding as timedelta() - I am happy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 23:09:05 2015 From: report at bugs.python.org (Tim Peters) Date: Fri, 04 Sep 2015 21:09:05 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441400945.66.0.0225501223128.issue23517@psf.upfronthosting.co.za> Tim Peters added the comment: Alex, if you like, I'll take the blame for the rounding method - I did express a preference for it here: http://bugs.python.org/issue23517#msg249309 When I looked at the code earlier, the round-half-up implementation looked good to me (floor(x+0.5) if x >= 0 else ceil(x-0.5)). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 23:27:45 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 21:27:45 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441402065.4.0.389174827113.issue23517@psf.upfronthosting.co.za> STINNER Victor added the comment: > I did not quite understand why you've chosen ROUND_HALF_UP over ROUND_HALF_EVEN, but as long as fromtimestamp() uses the same rounding as timedelta() - I am happy. Not only Tim prefers this rounding mode, Python 2.7 also uses the same mode, and the original poster basically said that Python 3 doesn't behave like Python 2. So... the most obvious rounding mode is the same than Python 2, ROUND_HALF_UP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 23:44:28 2015 From: report at bugs.python.org (John Beck) Date: Fri, 04 Sep 2015 21:44:28 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) Message-ID: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> New submission from John Beck: A recent Solaris build upgrade resulted in a massive slowdown of a package operation (our package client is written in Python). Some DTrace revealed this was because os.urandom() calls had slowed down by a factor of over 300. This turned out to be caused by an upgrade of Python from 2.7.9 to 2.7.10 which included: - Issue #22585: On OpenBSD 5.6 and newer, os.urandom() now calls getentropy(), instead of reading /dev/urandom, to get pseudo-random bytes. By adding ac_cv_func_getentropy=no to our configure options, we were able to get back the performance we had lost. But our security experts warned: --- OpenBSD only has getentropy(2) and we are compatible with that. Linux has both getentropy(2) and getrandom(2) Solaris has getentropy(2) and getrandom(2). The bug is in Python it should not use getentropy(2) for the implementation of os.urandom() unless it builds its own DRBG (Deterministic Random Bit Generator) around that - which will mean it is "caching" and thus only calling getentropy() for seeding very infrequently. You can not substitute getentropy() for getrandom(), if you need randomness then entropy does not suffice. They are using getentropy(2) correctly in the implementation of _PyRandom_Init(). I would personally recommend that the upstream adds os.getentropy() changes os.urandom() to use getrandom(buf, sz, GRND_NONBLOCK) and os.random() to use getrandom(buf, sz, GRND_RANDOM). As it is the upstream implementation is arguably a security vulnerability since you can not use entropy where you need randomness. --- where by "upstream" he meant "python.org". So I am filing this bug to request those changes. I can probably prototype this in the reasonable near future, but I wanted to get the bug filed sooner rather than later. ---------- components: Interpreter Core messages: 249837 nosy: jbeck priority: normal severity: normal status: open title: os.urandom() should call getrandom(2) not getentropy(2) versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 23:46:54 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 21:46:54 +0000 Subject: [issue24975] Python 3.5 can't compile AST involving PEP 448 unpacking In-Reply-To: <1441069996.63.0.493747155256.issue24975@psf.upfronthosting.co.za> Message-ID: <1441403214.63.0.897763494947.issue24975@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Upon writing a proof-of-concept file for #24981, I discovered an stdlib file that gave the same error. C:/programs/Python35/Lib\distutils/_msvccompiler.py ValueError: None disallowed in expression list I presume the applied fix will apply to this also. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 23:58:22 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 21:58:22 +0000 Subject: [issue24981] Add a test which uses the ast module to compile the stdlib In-Reply-To: <1441140555.75.0.593788380292.issue24981@psf.upfronthosting.co.za> Message-ID: <1441403902.99.0.749796663538.issue24981@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The distutils error is a ValueError, which was printed as such before I added 'Exception' to the except statement. I did not initially catch SyntaxError separately because some are caught during the compile phase. Revised file corrects 'pass' to 'continue' and continues with parse errors also. Many test/badsyntax files have compile-time syntax errors. SyntaxError 'await' outside function (badsyntax_async1.py, line 1) SyntaxError 'yield' inside async function (badsyntax_async6.py, line 2) SyntaxError from __future__ imports must occur at the beginning of the file (badsyntax_future10.py, line 3) SyntaxError future feature rested_snopes is not defined (badsyntax_future3.py, line 3) SyntaxError not a chance (badsyntax_future9.py, line 3) Attached is a fully recursive version that only report compile errors for non-'badsyntax' files. It takes about 2 seconds more. Output: C:/programs/Python35/Lib\distutils _msvccompiler.py ValueError None disallowed in expression list 1776 (files compiled) I excluded site-packages after testing on 3.4 because pylint has bad syntax examples giving a page of error messages. ---------- Added file: http://bugs.python.org/file40360/tem_ast2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 4 23:59:25 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 04 Sep 2015 21:59:25 +0000 Subject: [issue24956] Default value for an argument that is not in the choices list gets accepted In-Reply-To: <1440843994.53.0.0278400690294.issue24956@psf.upfronthosting.co.za> Message-ID: <1441403965.93.0.659526111375.issue24956@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +bethard _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:06:21 2015 From: report at bugs.python.org (John Beck) Date: Fri, 04 Sep 2015 22:06:21 +0000 Subject: [issue25004] test_mmap should catch f.close() failure in LargeMmapTests._make_test_file() Message-ID: <1441404381.95.0.01039017408.issue25004@psf.upfronthosting.co.za> New submission from John Beck: When running test_mmap on a partition with < 4GB free, it back-traced: Traceback (most recent call last): File "/usr/lib/python3.4/test/test_mmap.py", line 728, in _make_test_file f.flush() OSError: [Errno 28] No space left on device During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.4/test/test_mmap.py", line 735, in test_large_offset with self._make_test_file(0x14FFFFFFF, b" ") as f: File "/usr/lib/python3.4/test/test_mmap.py", line 730, in _make_test_file f.close() OSError: [Errno 28] No space left on device but by wrapping the f.close() inside another try/except block, its failure was caught and the test was able to complete, resulting in a skip for this sub-test and an OK for the overall test. ---------- components: Tests files: 26-test_mmap.patch keywords: patch messages: 249840 nosy: jbeck priority: normal severity: normal status: open title: test_mmap should catch f.close() failure in LargeMmapTests._make_test_file() versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40361/26-test_mmap.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:09:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 04 Sep 2015 22:09:31 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <20150904220925.101486.92421@psf.io> Roundup Robot added the comment: New changeset 3c29d05c0710 by Victor Stinner in branch 'default': Issue #23517: Fix implementation of the ROUND_HALF_UP rounding mode in https://hg.python.org/cpython/rev/3c29d05c0710 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:11:28 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 04 Sep 2015 22:11:28 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441404688.17.0.916809805271.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: It would be nice to hear from Mark Dickinson on this. In Python 3, we took a much more systematic approach to rounding than a rather haphazard Python 2. For example, the rounding mode for timedelta(0, float_seconds) is not specified in Python 2, but it is in Python 3: https://docs.python.org/2/library/datetime.html#datetime.timedelta https://docs.python.org/3/library/datetime.html#datetime.timedelta ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:18:06 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 22:18:06 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441405086.62.0.817233993851.issue23517@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file40362/round_half_up_py34-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:18:56 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Sep 2015 22:18:56 +0000 Subject: [issue24956] Default value for an argument that is not in the choices list gets accepted In-Reply-To: <1440843994.53.0.0278400690294.issue24956@psf.upfronthosting.co.za> Message-ID: <1441405136.56.0.0473758298097.issue24956@psf.upfronthosting.co.za> R. David Murray added the comment: OK, I'm going to close this as "not a bug" then, as it seems to be an intentional design decision. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:19:22 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 22:19:22 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441405162.48.0.51087513011.issue23517@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file40363/fromtimestamp_round_half_up_py34-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:19:29 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 22:19:29 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441405169.56.0.524503037716.issue23517@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file40350/round_half_up_py34.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:19:30 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 22:19:30 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441405170.93.0.815585074412.issue23517@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file40351/fromtimestamp_round_half_up_py34.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:21:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 22:21:04 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441405264.07.0.390684523634.issue23517@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file40363/fromtimestamp_round_half_up_py34-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:21:22 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 22:21:22 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441405282.34.0.544631482175.issue23517@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file40364/fromtimestamp_round_half_up_py34-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:22:57 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 04 Sep 2015 22:22:57 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1441405377.88.0.922842298946.issue25003@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +haypo stage: -> needs patch type: -> security _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:25:06 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 22:25:06 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441405506.48.0.27961174019.issue23517@psf.upfronthosting.co.za> STINNER Victor added the comment: > Is the "review" link up-to date? Oh, I wrote a patch serie, but Rietveld doesn't know the dependencies between my patches... So I attached combined_py34.patch which combines the 3 patches into a single one, hard to reviewer, but it should work with Rietveld. ---------- Added file: http://bugs.python.org/file40365/combined_py34.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:31:29 2015 From: report at bugs.python.org (Tim Peters) Date: Fri, 04 Sep 2015 22:31:29 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441405889.61.0.585398320917.issue23517@psf.upfronthosting.co.za> Tim Peters added the comment: Yes, it would be good to hear from Mark. When I first saw this report, I checked to see whether he was on the nosy list. He is, but is apparently busy elsewhere. My opinions haven't changed: nearest/even is unnatural for rounding times ("sometimes up, sometimes down" grates against the nature of monotonically non-decreasing timestamps), but it doesn't make a lick of real difference. If the inconsequential choice was documented, then sure, that it _was_ documented makes it consequential, so that's the one that must be used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:33:27 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 04 Sep 2015 22:33:27 +0000 Subject: [issue25001] Make --nowindows argument to regrtest propagate when running with -j In-Reply-To: <1441399617.05.0.891415993838.issue25001@psf.upfronthosting.co.za> Message-ID: <1441406007.59.0.626678344004.issue25001@psf.upfronthosting.co.za> Steve Dower added the comment: I'd be happy to always disable assert dialogs/output in regrtest, and then use "-n" to enable stderr output. That way people simply testing their own debug builds don't think it's failed, and the buildbots keep all the output they currently have. ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:34:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 22:34:49 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441406089.09.0.859505105051.issue23517@psf.upfronthosting.co.za> STINNER Victor added the comment: > My opinions haven't changed: nearest/even is unnatural for rounding times ("sometimes up, sometimes down" grates against the nature of monotonically non-decreasing timestamps), By the way, why does Python use ROUND_HALF_EVEN for round()? It also feels unnatural to me! >>> round(0.5) 0 >>> round(1.5) 2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:38:26 2015 From: report at bugs.python.org (Tim Peters) Date: Fri, 04 Sep 2015 22:38:26 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441406306.53.0.0762306238477.issue23517@psf.upfronthosting.co.za> Tim Peters added the comment: Victor, there are good "theoretical" reasons for using half/even rounding in _general_ use. But this bug report isn't the place to get into them. Here it just should be enough to note that the IEEE 754 floating point standard _requires_ half/even to be the default rounding mode. Slowly but surely, all the world's non-business computer applications are moving toward that. Python is just one of 'em. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:43:50 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 04 Sep 2015 22:43:50 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441406630.48.0.363736737577.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > By the way, why does Python use ROUND_HALF_EVEN for round()? ROUND_HALF_EVEN does not introduce statistical bias in your floating point data. With this choice a randomly chosen decimal has an equal chance of being rounded up or down. I think one can prove the same for a binary float being converted to a decimal with a fixed number of places after dot. The builtin round() is a unique beast and I would have to ask Mark to know what its statistical properties are, but in general round-half-to-even is justified by the desire of not introducing a statistical bias and I don't think the natural asymmetry of the time line matters in this argument. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:46:03 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 04 Sep 2015 22:46:03 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441406763.97.0.197881622145.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Here is what Wikipedia has to say on the subject: """ Round half to even .. This method treats positive and negative values symmetrically, and is therefore free of sign bias. More importantly, for reasonable distributions of y values, the expected (average) value of the rounded numbers is the same as that of the original numbers. However, this rule will introduce a towards-zero bias when y ? 0.5 is even, and a towards-infinity bias for when it is odd. """ https://en.wikipedia.org/wiki/Rounding#Round_half_to_even ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:47:59 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 04 Sep 2015 22:47:59 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441406879.81.0.442313847083.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: .. and here is an unbeatable argument: "this variant of the round-to-nearest method is also called unbiased rounding, convergent rounding, statistician's rounding, **Dutch rounding**, Gaussian rounding, odd?even rounding, or bankers' rounding." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:49:18 2015 From: report at bugs.python.org (Yann Sionneau) Date: Fri, 04 Sep 2015 22:49:18 +0000 Subject: [issue23630] support multiple hosts in create_server/start_server In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za> Message-ID: <1441406958.7.0.266968208602.issue23630@psf.upfronthosting.co.za> Yann Sionneau added the comment: Yet another version of the patch according to the last review. ---------- Added file: http://bugs.python.org/file40366/multibind8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:49:21 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 04 Sep 2015 22:49:21 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441406961.29.0.265569621493.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: .. and "[Round half to even] is the default rounding mode used in IEEE 754 computing functions and operators." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:52:36 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Sep 2015 22:52:36 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441407156.03.0.728602312415.issue24912@psf.upfronthosting.co.za> Guido van Rossum added the comment: We should have something for rc3, which is imminent. I vote for (1) and (2) if Serhiy thinks the patch is ready. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 00:54:41 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 04 Sep 2015 22:54:41 +0000 Subject: [issue25002] Deprecate asyncore/asynchat In-Reply-To: <1441399683.85.0.786847810998.issue25002@psf.upfronthosting.co.za> Message-ID: <1441407281.72.0.501243618182.issue25002@psf.upfronthosting.co.za> Guido van Rossum added the comment: Ideally these modules should emit a deprecation warning starting in 3.6 (when asyncio is no longer provisional) and we should strive to delete them per 3.8. If nobody rewrites smptd.py using asyncio it should be deleted at the same time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 01:03:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 04 Sep 2015 23:03:49 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1441406961.29.0.265569621493.issue23517@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Ok, thanks for the explanation :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 01:08:04 2015 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 04 Sep 2015 23:08:04 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441408084.49.0.0710450725023.issue24917@psf.upfronthosting.co.za> Mark Lawrence added the comment: I have tried the reproducer on Windows 10 with 2.6, 2.7, 3.3, 3.4, 3.5 and 3.6. In every case I got this. C:\py -3.4 -c"from time import *;strftime('AA%'*0x10000)" Traceback (most recent call last): File "", line 1, in ValueError: Invalid format string ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 01:08:42 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 04 Sep 2015 23:08:42 +0000 Subject: [issue25002] Deprecate asyncore/asynchat In-Reply-To: <1441399683.85.0.786847810998.issue25002@psf.upfronthosting.co.za> Message-ID: <1441408122.22.0.0015067734405.issue25002@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 01:09:09 2015 From: report at bugs.python.org (Brian Hou) Date: Fri, 04 Sep 2015 23:09:09 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows Message-ID: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> New submission from Brian Hou: With Python 3.5.0rc2 (tested with both Git BASH and Cmder on Windows 8): $ python3 >>> import webbrowser >>> webbrowser.open_new('http://example.com/?a=1&b=2') 'b' is not recognized as an internal or external command, operable program or batch file. True The opened page is http://example.com/?a=1 rather than http://example.com/?a=1&b=2. Trying to open a URL with only one field works as expected. ---------- components: Library (Lib), Windows messages: 249858 nosy: Brian Hou, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: webbrowser breaks on query strings with multiple fields on Windows type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 01:09:32 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 04 Sep 2015 23:09:32 +0000 Subject: [issue25001] Make --nowindows argument to regrtest propagate when running with -j In-Reply-To: <1441399617.05.0.891415993838.issue25001@psf.upfronthosting.co.za> Message-ID: <1441408172.75.0.0632675828752.issue25001@psf.upfronthosting.co.za> Brett Cannon added the comment: Steve's idea SGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 01:12:49 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 04 Sep 2015 23:12:49 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441408369.52.0.273386271935.issue24917@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > In every case I got [ValueError] You shouldn't have. I am no Windows expert, but I suspect something is wrong with your use of the command line. Please try it at the Python prompt or put the code in a script. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 01:23:29 2015 From: report at bugs.python.org (John Leitch) Date: Fri, 04 Sep 2015 23:23:29 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441409009.97.0.409947763904.issue24917@psf.upfronthosting.co.za> John Leitch added the comment: > I have tried the reproducer on Windows 10 with 2.6, 2.7, 3.3, 3.4, 3.5 and 3.6. In every case I got this. What you are observing is due to the arrangement and contents of process memory. With a simple repro (such as the one provided), there's a good chance the null terminator of the format string will be followed by more null bytes, and thus the code will appear to work as intended. In more complex scripts where memory is ultimately reused, it's more likely that the null terminator will be followed by garbage, non-null bytes. To make the issue reproduce more reliably, use GFlags to enable heap tail checking, heap free checking, and page heap. https://msdn.microsoft.com/en-us/library/windows/hardware/ff549557(v=vs.85).aspx Then, when you repro the issue, you'll see the crash because the uninitialized memory will contain the fill pattern 0xd0 rather than 0x00, like this: 0:000> db edx-0x10 08ef2ff0 41 25 41 41 25 41 41 25-00 d0 d0 d0 d0 d0 d0 d0 A%AA%AA%........ 08ef3000 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 08ef3010 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 08ef3020 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 08ef3030 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 08ef3040 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 08ef3050 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 08ef3060 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? To be clear, heap verification is not a requirement--the bug can indeed be reproduced without it. However, it will make life easier by introducing more determinism. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 01:26:20 2015 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 04 Sep 2015 23:26:20 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441409180.24.0.608757468412.issue24917@psf.upfronthosting.co.za> Mark Lawrence added the comment: Python prompt or script makes no difference. C:\Users\Mark\Desktop>py -2.6 time_strftime_Buffer_Over-read.py Traceback (most recent call last): File "time_strftime_Buffer_Over-read.py", line 2, in strftime("AA%"*0x10000) ValueError: Invalid format string Python 3.5.0rc2 (v3.5.0rc2:cc15d736d860, Aug 25 2015, 05:08:37) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from time import * >>> strftime("AA%"*0x10000) Traceback (most recent call last): File "", line 1, in ValueError: Invalid format string ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 01:27:19 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 04 Sep 2015 23:27:19 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441409239.14.0.393437636148.issue24917@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Sorry for a bad guess. John's advise makes much more sense than mine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 01:34:11 2015 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 04 Sep 2015 23:34:11 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441409651.44.0.738089791913.issue24917@psf.upfronthosting.co.za> Mark Lawrence added the comment: Okay, so presumably this applies to all supported versions and not just 3.5? Can you also remove the reproducer and supply specific instructions on how to build the code so that the problem can be reproduced. ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 01:34:54 2015 From: report at bugs.python.org (Wenzel Jakob) Date: Fri, 04 Sep 2015 23:34:54 +0000 Subject: [issue25006] List pybind11 binding generator Message-ID: <1441409694.33.0.221981890825.issue25006@psf.upfronthosting.co.za> New submission from Wenzel Jakob: Hi, over the last few months, I've been developing a library ("pybind11") for creating Python bindings of C++ code. It is similar in spirit to Boost.Python but uses a very different minimalist approach. It would be fantastic to get this library listed here: https://docs.python.org/3/faq/extending.html The purpose of this ticket is that somebody with permissions might add it to this page. pybind11 is here: https://github.com/wjakob/pybind11 Please let me know if you need any additional information. Thank you, Wenzel ---------- assignee: docs at python components: Documentation messages: 249865 nosy: docs at python, wenzel priority: normal severity: normal status: open title: List pybind11 binding generator type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 01:42:51 2015 From: report at bugs.python.org (Mathieu Pasquet) Date: Fri, 04 Sep 2015 23:42:51 +0000 Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?= =?utf-8?q?env_with_--system-site-package?= In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za> Message-ID: <1441410171.7.0.753491250957.issue24875@psf.upfronthosting.co.za> Mathieu Pasquet added the comment: This bug actually makes the --system-site-packages option useless, because it prevents installation of any package inside the virtualenv unless one tries the workaround given by gracinet. ---------- nosy: +mathieui _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 01:47:22 2015 From: report at bugs.python.org (John Leitch) Date: Fri, 04 Sep 2015 23:47:22 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441410442.47.0.458474996561.issue24917@psf.upfronthosting.co.za> John Leitch added the comment: It very well may apply to versions apart from 3.5. Our test environment is quite complex and unfriendly to working with multiple versions of Python. Plus, we're strapped for time, so we tend to file under the version we're currently targeting and defer to those better equipped and more familiar with the codebase. The repro file is fine and there's no need to rebuild anything; the heap verification I'm suggesting is applied to binaries, not source. You can find information here: https://msdn.microsoft.com/en-us/library/windows/hardware/ff549557(v=vs.85).aspx Install the debugging tools, run GFlags, select the python.exe/pythonw.exe image file, and apply the settings I mentioned in my previous post. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 01:58:16 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 04 Sep 2015 23:58:16 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441411096.92.0.91038823998.issue24917@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: John, There is no doubt that this is a bona fide bug. I was just hoping that someone with a Windows development machine would help figuring out the affected versions. >From the hg history, it looks like the faulty code is present in all versions starting from 3.2: https://hg.python.org/cpython/annotate/977c5753ca32/Modules/timemodule.c#l515 I will set the issue versions accordingly. ---------- versions: +Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 02:02:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 05 Sep 2015 00:02:43 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441411363.3.0.191915806352.issue24912@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: issue24912-v2.patch LGTM. ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 02:03:56 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 05 Sep 2015 00:03:56 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441411436.79.0.679660921427.issue24917@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I will keep the "security" classification, but will not increase the priority. Accepting format strings from untrusted sources is a vulnerability in and by itself and in most cases those strings are literals. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 02:04:07 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 05 Sep 2015 00:04:07 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441411447.38.0.27501386643.issue24912@psf.upfronthosting.co.za> Guido van Rossum added the comment: Serhiy, can you commit it and prepare a PR for Larry? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 02:10:11 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 05 Sep 2015 00:10:11 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441411811.63.0.243928573511.issue24917@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: FWIW, the patch looks good to me, but it needs to be reviewed by a Windows developer. ---------- components: +Extension Modules _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 02:33:07 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 05 Sep 2015 00:33:07 +0000 Subject: [issue25002] Deprecate asyncore/asynchat In-Reply-To: <1441399683.85.0.786847810998.issue25002@psf.upfronthosting.co.za> Message-ID: <1441413187.25.0.675084082527.issue25002@psf.upfronthosting.co.za> Eric V. Smith added the comment: I use smtpd.py for testing my code. But it's not such a big deal that I couldn't live without it. If I have some time to burn, I might convert it to asyncio so I can continue to use it. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 02:41:34 2015 From: report at bugs.python.org (John Leitch) Date: Sat, 05 Sep 2015 00:41:34 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441413694.45.0.694530645404.issue24917@psf.upfronthosting.co.za> John Leitch added the comment: When I get a bit of slackspace (probably tomorrow afternoon/evening) I can test on the spectrum of versions to confirm the issue is in >= 3.2. I'll also look into improving our automation so all future reports can have the appropriate versions flagged. Regarding untrusted format strings, I believe you are mistaken. In native applications, untrusted format strings are problematic because an attacker can use injected tokens to read/write arbitrary memory, which can be leveraged to attain code execution. However, in the context of Python, a format string with too many tokens should be handled safely, resulting in a Python exception rather than exploitable memory corruption. This is the behavior observed in format string handling throughout Python (and indeed most managed/scripting languages). Yes, in most Python programs format strings will be constants, and using dynamically constructed format strings may be considered a bad practice. But, should a developer choose to pass a dynamically constructed string (for example, functionality that allows untrusted users to specify custom time formatting), it's not unreasonable for them to expect memory safety to be maintained. Of course, if there's a risk I'm overlooking I'd like to better understand it, and the relevant Python documentation should be updated. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 02:54:27 2015 From: report at bugs.python.org (Tim Peters) Date: Sat, 05 Sep 2015 00:54:27 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441414467.14.0.0239292021401.issue23517@psf.upfronthosting.co.za> Tim Peters added the comment: Goodness. It's the properties of "randomly chosen decimals" that have nothing to do with timestamps ;-) timestamps aren't random, so "statistical bias" is roughly meaningless in this context. I gave a specific example before of how nearest/even destroys obvious regularities in a _sequence_ of timestamps, where half-up preserves as much of the input regularity as possible. That's worth more than a million abstract "head arguments" on Wikipedia. But it doesn't make a lick of real difference either way. We're rounding to microseconds, and there are only 64 "fractional parts" where the methods could _possibly_ deliver different results: those of the form i/128 for i in range(1, 128, 2). All and only those are exactly representable in base 2, and require exactly 7 decimal digits "after the decimal point" to express in decimal, _and_ end with "5" in decimal. Half end with "25" while the other half with "75". So Alex's 1/128 is one of the only 32 possible fractional parts where it makes a difference. We systematically force all these cases to even, and dare think that's _not_ "biased"? Half-up would leave half the results even and half odd, exactly the same as the _input_ odd/even distribution of the 6th digit. And preserve the input strict alternation between even and odd in the 6th digit. nearest/even destroys all of that. Except that, I agree, there's no arguing with "Dutch rounding" ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 02:57:47 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 05 Sep 2015 00:57:47 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441414667.36.0.786273381504.issue24917@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: As far as I know, the practical consequence of "security" classification for the issue is how many affected older versions will be patched. I am keeping that and the 3.2 - 3.5 versions range. The priority may affect whether this will make it into 3.5.0. I'll defer this decision to the release managers. If you want an authoritative answer on the impact of this issue - report it to CERT or FIRST and get them compute the CVSS score. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 03:06:03 2015 From: report at bugs.python.org (Larry Hastings) Date: Sat, 05 Sep 2015 01:06:03 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441415163.35.0.355063913899.issue24917@psf.upfronthosting.co.za> Larry Hastings added the comment: Yes, I'd like this fix in 3.5.0. One bit of feedback on the patch: outbuf is a char * (or wchar_t *), therefore outbuf[1] is a char (or wchar_t). You shouldn't compare it to NULL. I'm not sure we still support any compilers that define NULL as (void *)0, but we might. Anyway, please instead compare to '\0'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 03:12:56 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 05 Sep 2015 01:12:56 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441415576.39.0.45444040304.issue24917@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > if there's a risk I'm overlooking I'd like to better understand it, > and the relevant Python documentation should be updated. I don't think there is any special risk that you are overlooking other than a documented fact that Python's strftime is a thin layer on top of system strftime and these are notoriously buggy on many systems. A python application that accepts custom formats from users should limit those formats to a set that is known to work on the targeted platforms. Relying on strftime to properly return an error code and not do anything nasty is probably not a good idea. This said, I express no opinion on the severity of this bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 03:25:22 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 05 Sep 2015 01:25:22 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441416322.37.0.937691349335.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > timestamps aren't random, so "statistical bias" is roughly meaningless in this context. I agree. I don't think I made any arguments about timestamps specifically other than a consistency with timedeltas. In the later case, I think all the usual arguments for half-to-even tiebreaker apply. Let's just leave it at "When in doubt - use Dutch rounding." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 03:26:17 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 05 Sep 2015 01:26:17 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows In-Reply-To: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> Message-ID: <1441416377.91.0.787267446616.issue25005@psf.upfronthosting.co.za> R. David Murray added the comment: Thank you for reporting this. I see that the Windows browser class uses shell=True, and that is wrong from a security standpoint. This appears to be a regression from 3.4, introduced by issue 8232. Since this is a security regression there either needs to be a fix or that changeset should be backed out. ---------- nosy: +r.david.murray priority: normal -> release blocker type: behavior -> security versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 03:29:11 2015 From: report at bugs.python.org (John Leitch) Date: Sat, 05 Sep 2015 01:29:11 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441416551.25.0.828520683148.issue24917@psf.upfronthosting.co.za> John Leitch added the comment: Attached is a revised patch. ---------- Added file: http://bugs.python.org/file40367/time_strftime_Buffer_Over-read_v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 03:37:13 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 05 Sep 2015 01:37:13 +0000 Subject: [issue25002] Deprecate asyncore/asynchat In-Reply-To: <1441399683.85.0.786847810998.issue25002@psf.upfronthosting.co.za> Message-ID: <1441417033.22.0.640978388673.issue25002@psf.upfronthosting.co.za> R. David Murray added the comment: smtpd is used for testing smtplib. It is also used in test_logging. I would object to having it removed, but I suspect we can manage to rewrite it by 3.8. Maybe Eric and I can collaborate on it. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 03:49:29 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 05 Sep 2015 01:49:29 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441417769.05.0.757950339519.issue24917@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Hmm, on Mac OSX "%" and "A%" are valid format strings: >>> time.strftime("%") '%' >>> time.strftime("A%") 'A%' Mark's experiments show that on Windows they are not. What about the other platforms affected by the patch? I am concerned about the bottom part of the patch. A nitpick: an existing error message is "Invalid format string". I would either reuse it or make it "Incomplete format string". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 04:16:17 2015 From: report at bugs.python.org (John Leitch) Date: Sat, 05 Sep 2015 02:16:17 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441419377.32.0.145081568373.issue24917@psf.upfronthosting.co.za> John Leitch added the comment: I plucked the error message from the % operator: >>> '%' % 'foo' Traceback (most recent call last): File "", line 1, in ValueError: incomplete format >>> '%z' % 'foo' Traceback (most recent call last): File "", line 1, in ValueError: unsupported format character 'z' (0x7a) at index 1 That said, it should be more consistent. I went with the latter suggestion since it's more informative. An updated patch is attached. As for platform compatibility, I'd certainly feel better if someone could test the Sun/AIX changes. Unfortunately, I'm unable to do so. It's interesting that OSX accepts "%". As per the spec, "%%" is a "%" literal, and the behavior of invalid tokens such as "%" is undefined. ---------- Added file: http://bugs.python.org/file40368/time_strftime_Buffer_Over-read_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 04:28:11 2015 From: report at bugs.python.org (Tim Peters) Date: Sat, 05 Sep 2015 02:28:11 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441420091.03.0.443946185089.issue23517@psf.upfronthosting.co.za> Tim Peters added the comment: Bah. It doesn't matter who's consuming the rounding of a binary float to decimal microseconds: there are only 32 possible fractional parts where nearest/even and half-up deliver different results. half-up preserves properties of these specific inputs that nearest/even destroys. These inputs themselves have no bias - they're utterly uniformly spaced. Not only does nearest/even _introduce_ bias on these inputs by destroying these properties, it doesn't even preserve the spacing between them. Half-up leaves them all 5 microseconds apart, while nearest/even creates a bizarre "sometimes 4 microseconds apart, sometimes 6" output spacing out of thin air. So it's not a question of "when in doubt" to me, it's a question of "live up to what the docs already say". Although, again, it doesn't make a lick of real difference. That's why we'll never stop arguing about it ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 04:34:54 2015 From: report at bugs.python.org (Tim Peters) Date: Sat, 05 Sep 2015 02:34:54 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441420494.34.0.452123812052.issue23517@psf.upfronthosting.co.za> Tim Peters added the comment: > Half-up leaves them all 5 microseconds apart, When only looking at the decimal digit in the 6th place after rounding. Which is all I did look at ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 05:45:09 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 05 Sep 2015 03:45:09 +0000 Subject: [issue24995] better exception message when an unsupported object is passed to `async for` (pep 492) In-Reply-To: <1441314827.75.0.533925414566.issue24995@psf.upfronthosting.co.za> Message-ID: <1441424709.57.0.608050336417.issue24995@psf.upfronthosting.co.za> Nick Coghlan added the comment: In tandem with an "asynchronous iterable" glossary entry, that could be a nice improvement. Even without such a change the first hit for "python asynchronous iterable" is PEP 492, so it will get folks pointed in the right direction. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 05:56:31 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 05 Sep 2015 03:56:31 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441425391.83.0.317823824569.issue24912@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm creating the PR for Larry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 05:58:11 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 05 Sep 2015 03:58:11 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441425491.31.0.425856220959.issue24912@psf.upfronthosting.co.za> Guido van Rossum added the comment: PR: https://bitbucket.org/larry/cpython350/pull-requests/15/issue-24912-prevent-__class__-assignment/diff ---------- assignee: -> larry resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 05:59:16 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Sat, 05 Sep 2015 03:59:16 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441425556.62.0.848738598198.issue24912@psf.upfronthosting.co.za> Nathaniel Smith added the comment: There's already a PR on bitbucket that I made, in case that's helpful. The only difference from the v2 patch are that I rephrased some of the comment in a more neutral way (based on feedback from Mark posted on the PR itself), and added a NEWS entry. It does have a slightly more unsightly history graph due to the edit plus merging to resolve a conflict in NEWS. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 06:02:43 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 05 Sep 2015 04:02:43 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441425763.18.0.300148041895.issue24912@psf.upfronthosting.co.za> Guido van Rossum added the comment: Oh. I feel dumb now. I guess I'll let Larry choose. If it's just a matter of comment text we can always improve it in 3.5.1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 06:09:27 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 05 Sep 2015 04:09:27 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows In-Reply-To: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> Message-ID: <1441426167.35.0.714930454238.issue25005@psf.upfronthosting.co.za> Steve Dower added the comment: It'll have to be backed out. There may be a fix to salvage some of the functionality, but it's certainly too significant at this stage. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 06:28:53 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Sat, 05 Sep 2015 04:28:53 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441427333.39.0.574801867662.issue24912@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Sorry, you were too quick for me :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 06:37:49 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 05 Sep 2015 04:37:49 +0000 Subject: [issue2651] Strings passed to KeyError do not round trip In-Reply-To: <1208453081.65.0.886847251895.issue2651@psf.upfronthosting.co.za> Message-ID: <1441427869.77.0.629580687569.issue2651@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 07:07:53 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 05 Sep 2015 05:07:53 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> Message-ID: <1441429673.81.0.86258620331.issue23406@psf.upfronthosting.co.za> Martin Panter added the comment: That works for me. Here is a new patch using David?s new wording. ---------- Added file: http://bugs.python.org/file40369/issue23406_doc_stdtypes.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 07:37:54 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 05 Sep 2015 05:37:54 +0000 Subject: [issue24748] Change of behavior for importlib between 3.4 and 3.5 with DLL loading In-Reply-To: <1438176027.56.0.467476097176.issue24748@psf.upfronthosting.co.za> Message-ID: <1441431474.8.0.466567343622.issue24748@psf.upfronthosting.co.za> Nick Coghlan added the comment: Huh, for some reason the Rietveld diff missed the changes to _testmultiphase.c that are in the patch file. The change looks good to me. The test adds a new "test.imp_dummy" module, imports that, and then ensures it can be replaced by using imp.load_dynamic to import "test.imp_dummy" from the _testmultiphase module instead. The functional change itself is isolated to imp.load_dynamic, so no other code paths will be affected. ---------- stage: test needed -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 07:51:03 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 05 Sep 2015 05:51:03 +0000 Subject: [issue24984] document AF_BLUETOOTH socket address formats In-Reply-To: <1441210010.76.0.198064903239.issue24984@psf.upfronthosting.co.za> Message-ID: <1441432263.29.0.0687897557368.issue24984@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a suggestion of how to add a versionchanged tag. Let me know if it is accurate or not. (I?m not actually familiar with the history.) ---------- Added file: http://bugs.python.org/file40370/bluetooth_socket_docs_5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 08:20:50 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 05 Sep 2015 06:20:50 +0000 Subject: [issue24964] Add tunnel CONNECT response headers to httplib / http.client In-Reply-To: <1440956510.2.0.613573748355.issue24964@psf.upfronthosting.co.za> Message-ID: <1441434050.53.0.774916446815.issue24964@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: test needed -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 08:27:38 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 05 Sep 2015 06:27:38 +0000 Subject: [issue24964] Add tunnel CONNECT response headers to httplib / http.client In-Reply-To: <1440956510.2.0.613573748355.issue24964@psf.upfronthosting.co.za> Message-ID: <1441434458.32.0.685059249619.issue24964@psf.upfronthosting.co.za> Martin Panter added the comment: This is the patch I had in mind. It looks like it only implements the detach() method, so we would still need to add support for passing in the tunnel details to the HTTPSConnection constructor. This patch would allow doing stuff at a lower level than the existing tunnel functionality. The patch includes a test case for getting the proxy?s response header fields, and another test case illustrating how a plain text HTTP 2 upgrade could work. ---------- keywords: +patch stage: -> needs patch Added file: http://bugs.python.org/file40371/http-detach.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 10:50:41 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 05 Sep 2015 08:50:41 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <20150905085037.66870.66937@psf.io> Roundup Robot added the comment: New changeset d755f75019c8 by Victor Stinner in branch 'default': Issue #23517: Skip a datetime test on Windows https://hg.python.org/cpython/rev/d755f75019c8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 11:55:32 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sat, 05 Sep 2015 09:55:32 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1441417769.05.0.757950339519.issue24917@psf.upfronthosting.co.za> Message-ID: <55EABC01.7050208@egenix.com> Marc-Andre Lemburg added the comment: On 05.09.2015 03:49, Alexander Belopolsky wrote: > > Alexander Belopolsky added the comment: > > Hmm, on Mac OSX "%" and "A%" are valid format strings: > >>>> time.strftime("%") > '%' >>>> time.strftime("A%") > 'A%' > > Mark's experiments show that on Windows they are not. What about the other platforms affected by the patch? I am concerned about the bottom part of the patch. Trailing '%' are valid on Linux, just as using unsupported format codes (those as passed through as is). On Windows, the C lib strftime() segfaults with a trailing '%', just as it does with unsupported format codes. I have this code in mxDateTime to check for this: static int _mxDateTime_CheckWindowsStrftime(char *fmt, struct tm *tm) { char *p; /* Range checks */ Py_Assert(tm->tm_sec < 60, PyExc_ValueError, ".strftime() cannot format leap seconds on Windows"); Py_Assert(tm->tm_mday <= 31, PyExc_ValueError, ".strftime() cannot format days > 31 on Windows"); /* Scan format string for invalid codes */ for (p = fmt; *p != '\0'; p++) { register char code; if (*p != '%') continue; code = *++p; /* Check for supported format codes; see https://msdn.microsoft.com/en-us/library/fe06s4ak.aspx */ switch (code) { case 'a': case 'A': case 'b': case 'B': case 'c': case 'd': case 'H': case 'I': case 'i': case 'm': case 'M': case 'p': case 'S': case 'U': case 'w': case 'W': case 'x': case 'X': case 'y': case 'Y': case 'z': case 'Z': case '%': continue; case '\0': Py_Error(PyExc_ValueError, "format string may not end with a '%' character " "on Windows"); default: Py_ErrorWithArg(PyExc_ValueError, "format code '%c' not supported on Windows", code); } } return 0; onError: return -1; } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 12:09:00 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Sat, 05 Sep 2015 10:09:00 +0000 Subject: [issue16180] cannot quit pdb when there is a syntax error in the debuggee (must kill it) In-Reply-To: <1349811204.12.0.797224741983.issue16180@psf.upfronthosting.co.za> Message-ID: <1441447740.32.0.501873420839.issue16180@psf.upfronthosting.co.za> Xavier de Gaye added the comment: Slightly better in that pdb exits in case of a syntax error instead of proposing to restart the program which does not make sense. A test case is included. ---------- Added file: http://bugs.python.org/file40372/pdb_syntax_error.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 12:36:45 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 05 Sep 2015 10:36:45 +0000 Subject: [issue22995] Restrict default pickleability In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za> Message-ID: <1441449405.14.0.613629249544.issue22995@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue14350 and issue24900. Both will be solved by disabling pickling when tp_new is NULL (a part of proposed patch). So that I think the patch should be applied to all releases. ---------- type: enhancement -> behavior versions: +Python 2.7, Python 3.4, Python 3.6 Added file: http://bugs.python.org/file40373/pickle_restrictions_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 12:42:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 05 Sep 2015 10:42:33 +0000 Subject: [issue25007] Add support of copy protocol to zlib compressors and decompressors Message-ID: <1441449753.43.0.0389421030599.issue25007@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: zlib compressor and decompressor objects can be copied with the copy() method, but not with copy.copy(). It is easy to add support of copy protocol to them (just add __copy__() as an alias to copy()). ---------- components: Library (Lib) messages: 249902 nosy: nadeem.vawda, serhiy.storchaka, twouters priority: normal severity: normal status: open title: Add support of copy protocol to zlib compressors and decompressors type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 13:13:52 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 05 Sep 2015 11:13:52 +0000 Subject: [issue24748] Change of behavior for importlib between 3.4 and 3.5 with DLL loading In-Reply-To: <1438176027.56.0.467476097176.issue24748@psf.upfronthosting.co.za> Message-ID: <1441451632.7.0.9336326667.issue24748@psf.upfronthosting.co.za> Nick Coghlan added the comment: 3.5.0 PR for the change is at https://bitbucket.org/larry/cpython350/pull-requests/16 This *is* a regression (since it's an unintended behavioural change in imp.load_dynamic), but it's one with a relatively straightforward workaround, so it would also be reasonable to defer fixing it to 3.5.1. On the other hand, the risk is low, since the only functional change is in imp.load_dynamic itself, rather than in the core import machinery (that calls the underlying loader methods directly rather than going through the imp module API). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 13:41:17 2015 From: report at bugs.python.org (eryksun) Date: Sat, 05 Sep 2015 11:41:17 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441453277.56.0.362880267537.issue24917@psf.upfronthosting.co.za> eryksun added the comment: > On Windows, the C lib strftime() segfaults with a trailing '%', > just as it does with unsupported format codes. No, it doesn't segfault; it invokes the invalid parameter handler (IPH). This could always be configured for the whole process, but with VC 14 it can also be configured per thread. I think it was Steve Dower who updated time_strftime to take advantage of this feature in 3.5, using the new macros _Py_BEGIN_SUPPRESS_IPH and _Py_END_SUPPRESS_IPH. This allowed removing the following check that used to be in the code prior to 3.5: if (outbuf[1]=='\0' || !strchr("aAbBcdHIjmMpSUwWxXyYzZ%", outbuf[1])) { PyErr_SetString(PyExc_ValueError, "Invalid format string"); Py_DECREF(format); return NULL; } With this change the time module no longer has to make assumptions about what the CRT considers to be a valid format string in order to avoid invoking the IPH. However, this also accidentally removed checking whether outbuf[1]=='\0'. Now, instead of calling the default IPH that terminates the process, Python's _silent_invalid_parameter_handler gets called, which of course does nothing by design: >>> import time >>> time.strftime('A%') Breakpoint 0 hit python35!_silent_invalid_parameter_handler: 00000000`5eadae50 c20000 ret 0 0:000> k8 Child-SP RetAddr Call Site 00000000`002af018 000007fe`e9d8d2ab python35!_silent_invalid_parameter_handler 00000000`002af020 000007fe`e9d8d2c9 ucrtbase!invalid_parameter+0x103 00000000`002af060 000007fe`e9dafedc ucrtbase!invalid_parameter_noinfo+0x9 00000000`002af0a0 000007fe`e9dac359 ucrtbase!Wcsftime_l+0x168 00000000`002af140 000007fe`e9dac3f5 ucrtbase!Strftime_l+0x155 00000000`002af1d0 00000000`5e9fc785 ucrtbase!strftime+0x15 00000000`002af210 00000000`5ea7d5c2 python35!time_strftime+0x1f5 00000000`002af2b0 00000000`5eaf8fd0 python35!PyCFunction_Call+0x122 ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 13:51:21 2015 From: report at bugs.python.org (Larry Hastings) Date: Sat, 05 Sep 2015 11:51:21 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441453881.23.0.462219286328.issue24917@psf.upfronthosting.co.za> Larry Hastings added the comment: Rather than debating about how various platforms handle malformed format strings for strftime(), and whether or not they crash, we should simply prevent the native strftime() function from seeing them in the first place. I'd like the "v3" patch in 3.5.0rc3. Can someone create a pull request? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 13:59:23 2015 From: report at bugs.python.org (Thomas Belhalfaoui) Date: Sat, 05 Sep 2015 11:59:23 +0000 Subject: [issue24964] Add tunnel CONNECT response headers to httplib / http.client In-Reply-To: <1440956510.2.0.613573748355.issue24964@psf.upfronthosting.co.za> Message-ID: <1441454363.06.0.931188125768.issue24964@psf.upfronthosting.co.za> Thomas Belhalfaoui added the comment: Terry: Thanks for the form, I just filled it. Martin: Thanks for sending your patch. I will dive into it, and try to figure out how to add support for passing in the tunnel details to the HTTPSConnection constructor. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 14:22:30 2015 From: report at bugs.python.org (Larry Hastings) Date: Sat, 05 Sep 2015 12:22:30 +0000 Subject: [issue24305] The new import system makes it inconvenient to correctly issue a deprecation warning for a module In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za> Message-ID: <1441455750.6.0.0363004784567.issue24305@psf.upfronthosting.co.za> Larry Hastings added the comment: Okay. Right now creating server-side clones is broken. So I have repurposed one of my existing (old, dead) server-side clones for testing this. It's called "ssh://hg at hg.python.org/larry/path_error2". I just fired off this change on all the "custom" buildbots. I'm going to bed. If it passed everything in the morning I'll just check it in to 3.5.0, and hail mary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 14:27:49 2015 From: report at bugs.python.org (eryksun) Date: Sat, 05 Sep 2015 12:27:49 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441456069.84.0.718097734393.issue24917@psf.upfronthosting.co.za> eryksun added the comment: > Rather than debating about how various platforms handle malformed > format strings for strftime(), and whether or not they crash, we > should simply prevent the native strftime() function from seeing > them in the first place. Of course the check needs to be restored. I wasn't suggesting to go back to the default IPH to have it terminate the process. That won't help, anyway. The potential over-read is in the for loop, before calling strftime. I just thought the context for the accidental removal was relevant. Care needs to be taken when removing checks that were put in place to avoid the default IPH, because those checks may serve a dual purpose in the surrounding code. The patch also fixes the AIX/Sun code, which needs to be applied to 3.4 as well. I don't think this issue applies to 3.2 and 3.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 16:08:38 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 05 Sep 2015 14:08:38 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441462118.46.0.546993276385.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > It doesn't matter who's consuming the rounding of a binary > float to decimal microseconds That is true, but what does matter is who is producing the incoming floats. Consider an extreme case of a timer that ticks twice a microsecond and gives you results in a timespec struct style sec, nsec pair. If you convert those to timedeltas with timedelta(0, sec, nsec/1000), you will see half of nsec/1000 floats ending in .5 and half ending with .0. If you have a large sample of (sec, nsec) measurements, the mean of corresponding timedeltas will be 0.25?s larger with the half-up rounding than the actual mean of your samples. Is round-half-to-even a panacea? Of course not. In an extreme case if all your measurements are 1.5?s - it will not help at all, but in a more realistic sample you are likely to have an approximately equal number of even and odd ?s and the Dutch rounding will affect the mean much less than round-half-up. As you said, for most uses none of this matters, but we are not discussing a change to timedelta(0, s) rounding here. All I want from this issue is to keep the promise that we make in the docs: On the POSIX compliant platforms, utcfromtimestamp(timestamp) is equivalent to the following expression: datetime(1970, 1, 1) + timedelta(seconds=timestamp) https://docs.python.org/3/library/datetime.html#datetime.datetime.utcfromtimestamp Tim, while we have this entertaining theoretical dispute, I am afraid we are leaving Victor confused about what he has to do in his patch. I think we agree that fromtimestamp() should use Dutch rounding. We only disagree why. If this is the case, please close this thread with a clear advise to use round-half-to-even and we can continue discussing the rationale privately or in a different forum. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 18:46:37 2015 From: report at bugs.python.org (Tim Peters) Date: Sat, 05 Sep 2015 16:46:37 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441471597.97.0.241641168782.issue23517@psf.upfronthosting.co.za> Tim Peters added the comment: Victor, sorry if I muddied the waters here: Alex & I do agree nearest/even must be used. It's documented for timedelta already, and the seconds-from-the-epoch invariant Alex showed is at least as important to preserve as round-tripping. Alex, agreed about the overall mean in the example, but expect that continuing to exchange contrived examples isn't really a major life goal for either of us ;-) Thanks for playing along. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 19:08:13 2015 From: report at bugs.python.org (Brett Cannon) Date: Sat, 05 Sep 2015 17:08:13 +0000 Subject: [issue25008] Deprecate smtpd Message-ID: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za> New submission from Brett Cannon: As mentioned in passing in issue #25002, perhaps smtpd should be deprecated or at least be updated to use asyncio. ---------- components: Library (Lib) messages: 249911 nosy: brett.cannon priority: normal severity: normal stage: needs patch status: open title: Deprecate smtpd versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 19:08:52 2015 From: report at bugs.python.org (Brett Cannon) Date: Sat, 05 Sep 2015 17:08:52 +0000 Subject: [issue25002] Deprecate asyncore/asynchat In-Reply-To: <1441399683.85.0.786847810998.issue25002@psf.upfronthosting.co.za> Message-ID: <1441472932.82.0.161864703353.issue25002@psf.upfronthosting.co.za> Brett Cannon added the comment: I opened http://bugs.python.org/issue25008 to discuss deprecating smtpd since this issue is about asyncore/asynchat. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 19:10:08 2015 From: report at bugs.python.org (Brett Cannon) Date: Sat, 05 Sep 2015 17:10:08 +0000 Subject: [issue25008] Deprecate smtpd In-Reply-To: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za> Message-ID: <1441473008.14.0.0909356959075.issue25008@psf.upfronthosting.co.za> Brett Cannon added the comment: I should mention one of the motivations behind deprecating smtpd is that no one should be using that module to run an SMTP server and it doesn't provide utility like http.server does and so we probably should drop the code to prevent anyone accidentally using it and not have to maintain it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 19:12:53 2015 From: report at bugs.python.org (Alex Willmer) Date: Sat, 05 Sep 2015 17:12:53 +0000 Subject: [issue25009] queue.Queue() does not validate the maxsize argument Message-ID: <1441473173.56.0.310584962633.issue25009@psf.upfronthosting.co.za> New submission from Alex Willmer: The maxsize argument when initializing a Queue is expected to be an int (technically anything that can be compared to an int). However the class takes any value. In Python 3 this throws "TypeError: unorderable types" once e.g. .put() is called. On the basis that errors should not pass silent, should maxsize be checked for compatibility at initialization time? e.g. Desired: >>> import queue >>> q = queue.Queue(range(10)) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.5/queue.py", line nnn, in __init__() ... TypeError: 'range' object cannot be interpreted as an integer Actual: Python 3.5.0rc2 (default, Aug 25 2015, 20:29:07) [GCC 5.2.1 20150825] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import queue >>> q = queue.Queue(range(10)) # Silently accepts an invalid maxsize >>> q.put('foo') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.5/queue.py", line 127, in put if self.maxsize > 0: TypeError: unorderable types: range() > int() ---------- components: Library (Lib) messages: 249914 nosy: Alex.Willmer priority: normal severity: normal status: open title: queue.Queue() does not validate the maxsize argument type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 19:36:46 2015 From: report at bugs.python.org (Shaun Walbridge) Date: Sat, 05 Sep 2015 17:36:46 +0000 Subject: [issue25010] minor typo in PCBuild readme.txt Message-ID: <1441474606.12.0.269999159131.issue25010@psf.upfronthosting.co.za> New submission from Shaun Walbridge: A minor documentation fix. Currently, the top-level PCBuild readme.txt mentions in the final section 'Your Own Extension DLLs' that the example project is located in ../PC/example/, but the example location is ../PC/example_nt/. ---------- assignee: docs at python components: Documentation files: pyd-typo.diff keywords: patch messages: 249915 nosy: docs at python, scw priority: normal severity: normal status: open title: minor typo in PCBuild readme.txt type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file40374/pyd-typo.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 20:53:03 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 05 Sep 2015 18:53:03 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows In-Reply-To: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> Message-ID: <1441479183.98.0.180293769441.issue25005@psf.upfronthosting.co.za> Steve Dower added the comment: Here's an alternative to backing out the change, and it's simpler than I expected when I said it would be too much for 3.5.0. We add an 'arguments' parameter to os.startfile and use that instead of subprocess.call(shell=True). The underlying ShellExecute call does not do any argument processing, so you can pass through any arguments you like. In the attached patch, I only added the argument for when Unicode strings are used, since byte strings are deprecated, but it's fairly trivial to add it to both. I'll add a backout patch next so they can be compared. ---------- keywords: +patch Added file: http://bugs.python.org/file40375/25005_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 20:58:27 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 05 Sep 2015 18:58:27 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows In-Reply-To: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> Message-ID: <1441479507.97.0.13452902539.issue25005@psf.upfronthosting.co.za> Steve Dower added the comment: Patch for backing out #8232's changes. ---------- Added file: http://bugs.python.org/file40376/25005_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 21:02:19 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 05 Sep 2015 19:02:19 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows In-Reply-To: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> Message-ID: <1441479739.83.0.16349132985.issue25005@psf.upfronthosting.co.za> Steve Dower added the comment: Patch 1 also requires a minor update to Doc\library\os.rst: -.. function:: startfile(path[, operation]) +.. function:: startfile(path[, operation[, arguments]]) ... +*arguments* is passed to the underlying :c:func:`ShellExecute` +call. Its format is determined by the target file and operation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 21:07:43 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 05 Sep 2015 19:07:43 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441480063.29.0.55717212568.issue24917@psf.upfronthosting.co.za> Steve Dower added the comment: I'll do the PR. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 21:18:07 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 05 Sep 2015 19:18:07 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441480687.87.0.507924568588.issue24917@psf.upfronthosting.co.za> Steve Dower added the comment: > Rather than debating about how various platforms handle malformed > format strings for strftime(), and whether or not they crash, we > should simply prevent the native strftime() function from seeing > them in the first place. The crash is nothing to do with the native strftime() function - Python was crashing because it *tried* to prevent malformed strings and we (I) got it wrong. If we were simply passing the string through unchecked this would not have been an issue (or it would have been an issue against the CRT). PR at https://bitbucket.org/larry/cpython350/pull-requests/18/issue-24917-time_strftime-buffer-over-read/diff ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 21:48:09 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 05 Sep 2015 19:48:09 +0000 Subject: [issue24910] Windows MSIs don't have unique display names In-Reply-To: <1440182992.59.0.13997851785.issue24910@psf.upfronthosting.co.za> Message-ID: <20150905194806.14883.57150@psf.io> Roundup Robot added the comment: New changeset 3594400f3202 by Steve Dower in branch '3.5': Issue #24910: Windows MSIs now have unique display names. https://hg.python.org/cpython/rev/3594400f3202 New changeset 0295d2cdc9d3 by Steve Dower in branch 'default': Issue #24910: Windows MSIs now have unique display names. https://hg.python.org/cpython/rev/0295d2cdc9d3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 21:48:33 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 05 Sep 2015 19:48:33 +0000 Subject: [issue24910] Windows MSIs don't have unique display names In-Reply-To: <1440182992.59.0.13997851785.issue24910@psf.upfronthosting.co.za> Message-ID: <1441482513.43.0.777085449053.issue24910@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 22:33:46 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 05 Sep 2015 20:33:46 +0000 Subject: [issue23551] IDLE to provide menu options for using PIP In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za> Message-ID: <1441485226.3.0.881633126878.issue23551@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This is really needed. A number of recent threads on python-list indicate that beginners are having problems with using pip. Donald, can you answer Saimadhav's questions two messages above? Saimadhav, can you post whatever you have done so far? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 22:42:56 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 05 Sep 2015 20:42:56 +0000 Subject: [issue23551] IDLE to provide menu link to PIP gui. In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za> Message-ID: <1441485776.76.0.376366911635.issue23551@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Nick, Paul, Marcus, can any of you answer Saimadhav's question 3 messages up? ---------- nosy: +Marcus.Smith, ncoghlan, paul.moore title: IDLE to provide menu options for using PIP -> IDLE to provide menu link to PIP gui. versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 22:46:51 2015 From: report at bugs.python.org (Donald Stufft) Date: Sat, 05 Sep 2015 20:46:51 +0000 Subject: [issue23551] IDLE to provide menu link to PIP gui. In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za> Message-ID: <1441486011.63.0.996081240509.issue23551@psf.upfronthosting.co.za> Donald Stufft added the comment: pip doesn't really support being called as an API, there's been requests for it before but nobody has yet come forward to specify what parts in particular they need. The practical effect of this is that there's no backwards compatibility promises for anything you import from pip currently. I would suggest using a subprocess to communicate with pip unless you can define what operations you need so the pip developers can settle on a real public API for them. As for your actual questions: 1. I'm pretty sure it requires restarting the process because pkg_resources has a cache and pip currently isn't designed in a way that it assumes you're going to freeze in anything but it's own process. 2. I think this depends on what version of of Python it's being used with and where the user installed it to. I think Steve Dower has switched Python 3.5's default install location to Program Files which does require it to be run as an administrator if you want to install into the site-packages instead of the user packages directory. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 22:48:11 2015 From: report at bugs.python.org (Donald Stufft) Date: Sat, 05 Sep 2015 20:48:11 +0000 Subject: [issue23551] IDLE to provide menu link to PIP gui. In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za> Message-ID: <1441486091.12.0.309123140509.issue23551@psf.upfronthosting.co.za> Changes by Donald Stufft : ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 22:49:31 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 05 Sep 2015 20:49:31 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1441471597.97.0.241641168782.issue23517@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Alex & I do agree nearest/even must be used. Ok, so Python 3.6 should be updated to use ROUND_HALF_EVEN, and then updated patches should be backported to Python 3.4 and 3.5. Right? Right now, Python 3.6 uses ROUND_HALF_UP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 23:05:28 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Sat, 05 Sep 2015 21:05:28 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441487128.26.0.752624694308.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: You may find it easier to start with a patch for 3.5 which is the only time sensitive task. I'll be happy to review your code in whatever form you find it easier to submit, but I believe in hg it is easier to forward port than to backport. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 23:21:59 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 05 Sep 2015 21:21:59 +0000 Subject: [issue23551] IDLE to provide menu link to PIP gui. In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za> Message-ID: <1441488119.05.0.226305008793.issue23551@psf.upfronthosting.co.za> Mark Lawrence added the comment: Can we use ideas from https://sites.google.com/site/pydatalog/python/pip-for-windows ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 23:29:27 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 05 Sep 2015 21:29:27 +0000 Subject: [issue25011] Smarter rl complete: hide private and special names Message-ID: <1441488567.65.0.369817501077.issue25011@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: When press tabulation just after the dot, the output is too long. It contains all attributes, most of them are dunder names. >>> int. int.__abs__( int.__doc__ int.__int__( int.__pos__( int.__round__( int.__truediv__( int.__add__( int.__eq__( int.__invert__( int.__pow__( int.__rpow__( int.__trunc__( int.__and__( int.__flags__ int.__itemsize__ int.__prepare__( int.__rrshift__( int.__weakrefoffset__ int.__base__( int.__float__( int.__le__( int.__qualname__ int.__rshift__( int.__xor__( int.__bases__ int.__floor__( int.__lshift__( int.__radd__( int.__rsub__( int.bit_length( int.__basicsize__ int.__floordiv__( int.__lt__( int.__rand__( int.__rtruediv__( int.conjugate( int.__bool__( int.__format__( int.__mod__( int.__rdivmod__( int.__rxor__( int.denominator int.__call__( int.__ge__( int.__module__ int.__reduce__( int.__setattr__( int.from_bytes( int.__ceil__( int.__getattribute__( int.__mro__ int.__reduce_ex__( int.__sizeof__( int.imag int.__class__( int.__getnewargs__( int.__mul__( int.__repr__( int.__str__( int.mro( int.__delattr__( int.__gt__( int.__name__ int.__rfloordiv__( int.__sub__( int.numerator int.__dict__ int.__hash__( int.__ne__( int.__rlshift__( int.__subclasscheck__( int.real int.__dictoffset__ int.__index__( int.__neg__( int.__rmod__( int.__subclasses__( int.to_bytes( int.__dir__( int.__init__( int.__new__( int.__rmul__( int.__subclasshook__( int.__divmod__( int.__instancecheck__( int.__or__( int.__ror__( int.__text_signature__ Proposed patch hides underscored names and show dunder names only if a prefix starts with '__', and private members only if a prefix starts with '_'. >>> int. int.bit_length( int.conjugate( int.denominator int.from_bytes( int.imag int.mro( int.numerator int.real int.to_bytes( >>> int.__ int.__abs__( int.__divmod__( int.__init__( int.__neg__( int.__rlshift__( int.__sub__( int.__add__( int.__doc__ int.__instancecheck__( int.__new__( int.__rmod__( int.__subclasscheck__( int.__and__( int.__eq__( int.__int__( int.__or__( int.__rmul__( int.__subclasses__( int.__base__( int.__flags__ int.__invert__( int.__pos__( int.__ror__( int.__subclasshook__( int.__bases__ int.__float__( int.__itemsize__ int.__pow__( int.__round__( int.__text_signature__ int.__basicsize__ int.__floor__( int.__le__( int.__prepare__( int.__rpow__( int.__truediv__( int.__bool__( int.__floordiv__( int.__lshift__( int.__qualname__ int.__rrshift__( int.__trunc__( int.__call__( int.__format__( int.__lt__( int.__radd__( int.__rshift__( int.__weakrefoffset__ int.__ceil__( int.__ge__( int.__mod__( int.__rand__( int.__rsub__( int.__xor__( int.__class__( int.__getattribute__( int.__module__ int.__rdivmod__( int.__rtruediv__( int.__delattr__( int.__getnewargs__( int.__mro__ int.__reduce__( int.__rxor__( int.__dict__ int.__gt__( int.__mul__( int.__reduce_ex__( int.__setattr__( int.__dictoffset__ int.__hash__( int.__name__ int.__repr__( int.__sizeof__( int.__dir__( int.__index__( int.__ne__( int.__rfloordiv__( int.__str__( (The completion of int._ returns nothing because int has no private members). ---------- components: Library (Lib) files: rlcomplete_filter_private.patch keywords: patch messages: 249928 nosy: pitrou, serhiy.storchaka, twouters priority: normal severity: normal stage: patch review status: open title: Smarter rl complete: hide private and special names type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file40377/rlcomplete_filter_private.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 23:38:44 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 05 Sep 2015 21:38:44 +0000 Subject: [issue25009] queue.Queue() does not validate the maxsize argument In-Reply-To: <1441473173.56.0.310584962633.issue25009@psf.upfronthosting.co.za> Message-ID: <1441489124.75.0.254562652912.issue25009@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The norm for pure python code is to duck type when objects are used rather than when they are passed in. The Queue module is very old and for the most part, its straight-forward design has worked out well (i.e. there aren't any real usability issues in actual practice). Accordingly, I'm going to decline the request. ---------- assignee: -> rhettinger nosy: +rhettinger resolution: -> rejected status: open -> closed type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 23:40:10 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 05 Sep 2015 21:40:10 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1441489210.09.0.795197854965.issue25003@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 23:41:49 2015 From: report at bugs.python.org (Mark Shannon) Date: Sat, 05 Sep 2015 21:41:49 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441489309.66.0.157874644977.issue24912@psf.upfronthosting.co.za> Mark Shannon added the comment: Why has the change allowing the __class__ attribute of modules been merged? It is not necessary (as I have stated repeatedly) and not known to be safe. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 23:44:10 2015 From: report at bugs.python.org (Larry Hastings) Date: Sat, 05 Sep 2015 21:44:10 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441489450.69.0.584000756536.issue24912@psf.upfronthosting.co.za> Larry Hastings added the comment: Because the BDFL asked that it be so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 23:44:42 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 05 Sep 2015 21:44:42 +0000 Subject: [issue17582] xml.etree.ElementTree does not preserve whitespaces in attributes In-Reply-To: <1364660794.69.0.883579635559.issue17582@psf.upfronthosting.co.za> Message-ID: <1441489482.91.0.499358391636.issue17582@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Stefan, can you opine on the patches and whether they should be backported? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 23:47:38 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 05 Sep 2015 21:47:38 +0000 Subject: [issue24969] functools.lru_cache: a way to set decorator arguments at runtime In-Reply-To: <1441036040.75.0.88592797115.issue24969@psf.upfronthosting.co.za> Message-ID: <1441489658.85.0.35416909949.issue24969@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Sorry, I'm going to reject this one. This option was considered during the design of the LRU cache and not included because it complicated the design, because the use cases were not common (the norm is set and forget), and because the __wrapped__ attribute provides a means of rewrapping or unwrapping as needed (i.e. there are reasonable workarounds). ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 23:51:50 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 05 Sep 2015 21:51:50 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1441489910.33.0.389882434003.issue24999@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 5 23:52:20 2015 From: report at bugs.python.org (Mark Shannon) Date: Sat, 05 Sep 2015 21:52:20 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441489940.15.0.729184973479.issue24912@psf.upfronthosting.co.za> Mark Shannon added the comment: Well, there are important reasons why not to make the __class__ attribute of modules mutable. First of all, there is no valid rationale. How do know for sure that modifying the class of the sys or builtins module is not going to cause much the same problems the changing the class of ints did? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 00:05:25 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 05 Sep 2015 22:05:25 +0000 Subject: [issue25008] Deprecate smtpd In-Reply-To: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za> Message-ID: <1441490725.61.0.7560637203.issue25008@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Bringing in Eric V Smith's comment in http://bugs.python.org/issue25002#msg249873 : ''' I use smtpd.py for testing my code. But it's not such a big deal that I couldn't live without it. If I have some time to burn, I might convert it to asyncio so I can continue to use it. ''' Bringing in R David Murray's comment in http://bugs.python.org/issue25002#msg249882 : '''smtpd is used for testing smtplib. It is also used in test_logging. I would object to having it removed, but I suspect we can manage to rewrite it by 3.8. Maybe Eric and I can collaborate on it. ''' ---------- nosy: +barry, rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 00:05:48 2015 From: report at bugs.python.org (David Barnett) Date: Sat, 05 Sep 2015 22:05:48 +0000 Subject: [issue25012] pathlib should allow converting to absolute paths without resolving symlinks Message-ID: <1441490748.21.0.647656961559.issue25012@psf.upfronthosting.co.za> New submission from David Barnett: There doesn't seem to be any helper in pathlib to expand a relative path to an absolute path *without* resolving symlinks. For example, if I want to convert pathlib.Path('some/path') to pathlib.Path('/full/path/to/some/path') where some/path is a symlink, my best option seems to be pathlib.Path(os.path.abspath(str(pathlib.Path('some/path')))) ---------- components: Library (Lib) messages: 249936 nosy: mu_mind priority: normal severity: normal status: open title: pathlib should allow converting to absolute paths without resolving symlinks type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 00:11:34 2015 From: report at bugs.python.org (Tim Peters) Date: Sat, 05 Sep 2015 22:11:34 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1441491094.55.0.189513682269.issue24999@psf.upfronthosting.co.za> Tim Peters added the comment: The longobject.c warnings are almost certainly unrelated to the test_re crash. If shifting right twice (adding parens for clarity): (LONG_MAX >> PyLong_SHIFT) >> PyLong_SHIFT. squashes the warnings, that would be a substantially clearer way to express the intent than the SIZEOF_LONG*CHAR_BIT-1 >= 2*PyLong_SHIFT spelling. Adding a comment *explaining* the intent would be even better. For the segfault issue, best guess is that it's a compiler optimization bug. Not common as mud, or even as common as nuisance warnings, but not all that rare either ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 00:15:10 2015 From: report at bugs.python.org (Mark Shannon) Date: Sat, 05 Sep 2015 22:15:10 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441491310.46.0.0641411976029.issue24912@psf.upfronthosting.co.za> Mark Shannon added the comment: Oh, and has anyone considered the potential impact this might have on Jython or PyPy? Modules are quite fundamental to the way that Python works. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 00:20:56 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 05 Sep 2015 22:20:56 +0000 Subject: [issue23551] IDLE to provide menu link to PIP gui. In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za> Message-ID: <1441491656.54.0.749461489814.issue23551@psf.upfronthosting.co.za> Steve Dower added the comment: I actually made the default per-user, specifically for cases like this. With a default install that the current user has done, pip does not need to be run as admin. If the system administrator has installed Python for all users, then --user needs to be specified to run without admin. (Could the admin add config to pip for all users to make this the default? I know we discussed it - don't remember what the result was.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 00:21:44 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 05 Sep 2015 22:21:44 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <20150905222141.101504.41700@psf.io> Roundup Robot added the comment: New changeset 27cc5cce0292 by Guido van Rossum in branch '3.5': Issue #24912: Prevent __class__ assignment to immutable built-in objects. https://hg.python.org/cpython/rev/27cc5cce0292 New changeset 1c55f169f4ee by Guido van Rossum in branch '3.5': Issue #24912: Prevent __class__ assignment to immutable built-in objects. (Merge 3.5.0 -> 3.5) https://hg.python.org/cpython/rev/1c55f169f4ee New changeset b045465e5dba by Guido van Rossum in branch 'default': Issue #24912: Prevent __class__ assignment to immutable built-in objects. (Merge 3.5 -> 3.6) https://hg.python.org/cpython/rev/b045465e5dba ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 00:24:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 05 Sep 2015 22:24:26 +0000 Subject: [issue25012] pathlib should allow converting to absolute paths without resolving symlinks In-Reply-To: <1441490748.21.0.647656961559.issue25012@psf.upfronthosting.co.za> Message-ID: <1441491866.96.0.151205677071.issue25012@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: pathlib.Path.cwd() / pathlib.Path('some/path') ---------- nosy: +pitrou, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 00:32:55 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 05 Sep 2015 22:32:55 +0000 Subject: [issue25008] Deprecate smtpd In-Reply-To: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za> Message-ID: <1441492375.65.0.408303141193.issue25008@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, I would like to see the module live on (after conversion to asyncio). Doug Hellman's example at https://pymotw.com/2/smtpd/ makes for a nice demonstration of Python's capabilities. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 00:40:20 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 05 Sep 2015 22:40:20 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441492820.0.0.475732507616.issue24912@psf.upfronthosting.co.za> Guido van Rossum added the comment: Mark, please calm down. Modules are incredibly simple objects compared to classes -- and yet you can change the __class__ of a class. You can also directly modify the __dict__ of a module. You can shoot yourself in the foot phenomenally this way, but that's not the point. The point is not to violate *internal* constraints of the interpreter. Changing immutable objects was violating such a constraint. Changing a module's __class__ is not. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 00:46:40 2015 From: report at bugs.python.org (Mark Shannon) Date: Sat, 05 Sep 2015 22:46:40 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441493200.93.0.879919409198.issue24912@psf.upfronthosting.co.za> Mark Shannon added the comment: Guido, I just think this change is misguided. The original rationale for the change just doesn't hold water. If you want the change anyway, then fine, but this seems an odd way to introduce it. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 00:47:12 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 05 Sep 2015 22:47:12 +0000 Subject: [issue23551] IDLE to provide menu link to PIP gui. In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za> Message-ID: <1441493232.0.0.435871530279.issue23551@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Pip's rather extensive command-line API can also be used as a code API. The signature of pip.main is (args=None), where args = sys.argv[1:] if not passed. I presume this will not change. Reusing the command-list API had the advantage of reusing the existing docs, help output, and knowlege of how to use pip. The API is to run 'status = pip.main(args)', where args is a list containing quoted versions of the command-line args, the same as one would pass to subprocess.Popen. Output is strings written to stdout (and stderr), which can be captured with StringIO. While not as nice as getting, say, a list of strings from a list_command function, I consider this better than repeatedly calling Popen and getting encoded bytes (in whatever encoding) from pipes. I tested this with list, show pip, help install, and install --upgrade pip. After a shell restart, import pip imported the new version. I am working on a wrapper for the pip.main call. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 00:48:55 2015 From: report at bugs.python.org (Donald Stufft) Date: Sat, 05 Sep 2015 22:48:55 +0000 Subject: [issue23551] IDLE to provide menu link to PIP gui. In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za> Message-ID: <1441493335.92.0.357459534274.issue23551@psf.upfronthosting.co.za> Donald Stufft added the comment: Yea ``pip.main(args)`` won't change. I'm not sure how well parts of pip will handle being in a persistent-ish process, but the API itself will work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 00:52:22 2015 From: report at bugs.python.org (Donald Stufft) Date: Sat, 05 Sep 2015 22:52:22 +0000 Subject: [issue23551] IDLE to provide menu link to PIP gui. In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za> Message-ID: <1441493542.44.0.0110877490611.issue23551@psf.upfronthosting.co.za> Donald Stufft added the comment: There is a "site" config file which works for all installs on that particular machine, there is not a per Python configuration file, though I don't see why we couldn't add one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 00:52:57 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Sat, 05 Sep 2015 22:52:57 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441493577.76.0.335663316342.issue24912@psf.upfronthosting.co.za> Nathaniel Smith added the comment: I didn't want to get further into the weeds of debating basic design points on the tracker while blocking rc3, but, for the record -- the proposal in msg249504 that one could keep the namespace of an old and new module object effectively in sync by defining __getattr__ on the new module doesn't work AFAICT. (I assume this is the basis of Mark's assertion that the change is unmotivated.) Going through __getattr__ creates an unacceptable performance hit on attribute access. You can avoid this by copying the namespace entries over (b/c __getattr__ is only called as a fallback when __dict__ lookup fails), but then you have the same problem as before of needing to keep things in sync. (And remember that module globals can change at any time -- the __globals__ pointer for any functions defined in that module will continue to point to the old namespace.) Re: PyPy: last I heard their main complaint about __class__ assignment was that it was hard to restrict it to *only* handle the cases that CPython does. (They do have a concept of "heap types"; AFAICT it's just a flag that says "the CPython version of this type has some quirks that we need to check for and emulate".) Not sure about Jython, but I doubt they have a natural heap/non-heap type distinction either. Thanks Guido for handling the patches! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 01:19:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 05 Sep 2015 23:19:05 +0000 Subject: [issue16180] cannot quit pdb when there is a syntax error in the debuggee (must kill it) In-Reply-To: <1349811204.12.0.797224741983.issue16180@psf.upfronthosting.co.za> Message-ID: <20150905231902.66864.11562@psf.io> Roundup Robot added the comment: New changeset 26c4db1a0aea by Terry Jan Reedy in branch '2.7': Issue #16180: Exit pdb if file has syntax error, instead of trapping user https://hg.python.org/cpython/rev/26c4db1a0aea New changeset 2d4aac2ab253 by Terry Jan Reedy in branch '3.4': Issue #16180: Exit pdb if file has syntax error, instead of trapping user https://hg.python.org/cpython/rev/2d4aac2ab253 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 01:20:31 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 05 Sep 2015 23:20:31 +0000 Subject: [issue16180] cannot quit pdb when there is a syntax error in the debuggee (must kill it) In-Reply-To: <1349811204.12.0.797224741983.issue16180@psf.upfronthosting.co.za> Message-ID: <1441495231.32.0.860289273046.issue16180@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> fixed stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 02:13:43 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 Sep 2015 00:13:43 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441498423.49.0.903086877609.issue24917@psf.upfronthosting.co.za> Larry Hastings added the comment: Pull request accepted. Please forward-merge. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 04:27:21 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 06 Sep 2015 02:27:21 +0000 Subject: [issue23551] IDLE to provide menu link to PIP gui. In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za> Message-ID: <1441506441.37.0.427176050866.issue23551@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The persistence issue is why I tried several calls before posting above. I am hoping that none of your command functions leave pip unusable, or if they do, you would be willing to have them fixed. Attached is promised wrapper. ---------- Added file: http://bugs.python.org/file40378/tem_pip.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 04:29:29 2015 From: report at bugs.python.org (Donald Stufft) Date: Sun, 06 Sep 2015 02:29:29 +0000 Subject: [issue23551] IDLE to provide menu link to PIP gui. In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za> Message-ID: <1441506569.02.0.755786905072.issue23551@psf.upfronthosting.co.za> Donald Stufft added the comment: Yea, we'd be willing to fix things where we can. I think the biggest problem you'll run into is probably going to be pkg_resources and it's module scoped cache of the sys.path and what items are installed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 04:51:48 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Sun, 06 Sep 2015 02:51:48 +0000 Subject: [issue25008] Deprecate smtpd In-Reply-To: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za> Message-ID: <1441507908.62.0.486947614837.issue25008@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Removing smtpd would definitely be a hardship for me right now, probably for obvious reasons. I use it in testing frameworks, and even wrote a library called lazr.smtptest that is built around smtpd. In Mailman, we have an LMTP server built on smtpd that implements *the* official way of getting mail into the system from an upstream mail server. Mailman 3 core FWIW is Python 3.4 and 3.5 compatible. That all being said, I've also been thinking lately about an asyncio-based reimplementation of SMTP and LMTP. asyncore/chat and smtpd are not the easiest modules to work with, extend, understand, or debug. I'd be very happy to collaborate with folks on an asyncio-based version. Maybe we can put that out as a third party module, with a long term plan on pulling it into the stdlib and promoting it instead of smtpd. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 04:57:47 2015 From: report at bugs.python.org (Eric Snow) Date: Sun, 06 Sep 2015 02:57:47 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441508267.33.0.904388613358.issue24912@psf.upfronthosting.co.za> Eric Snow added the comment: While I recognize the practicality/purity argument here, I somewhat agree with Mark. Assigning to module.__class__ makes sense for the use case, but it does open up a number of negative possible side effects (e.g. changing sys.__class__). Ideally it would be restricted to just the currently running module, but doing that through __class__ assignment is not a great idea. Having a dedicated builtin function or even syntax would make more sense. In some ways I'm reminded of __metaclass__ in Python 2 class definitions. Something like that has come up before but didn't get a lot of momentum at the time. Ultimately I'd like to see a more explicit mechanism to meet the need that motivated the __class__ change here (as well as the replace-this-module-in-sys-modules technique). [1] While you can already accomplish this via a custom finder, that's not the most convenient tool for this sort of situation. FWIW, if assigning to sys.modules[__name__].__class__ is the blessed way then we should make it official in the language reference. The same goes for modules replacing themselves in sys.modules. If we have reservations about making either official (which I for one do [2]) then we should work on a more appropriate official solution. [1] It all boils down to customizing the current module's type from within the module rather than from outside (using a custom loader). [2] Neither spelling is very friendly. ---------- nosy: +brett.cannon, eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 05:25:03 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 06 Sep 2015 03:25:03 +0000 Subject: [issue23551] IDLE to provide menu link to PIP gui. In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za> Message-ID: <1441509903.08.0.00489111755165.issue23551@psf.upfronthosting.co.za> Terry J. Reedy added the comment: You are right. While multiple info requests work, I found a test that fails. 'list' showed that I had Pillow 2.7.0. 'install -U Pillow' updated to 2.9.0'. 'list' again still showed 2.7.0. 'show Pillow' then failed because 2.7.0 could not be found. After an install, we need to delete the one local reference to pip(.main), which should remain the only reference, and reload to refresh that cache. There is an obscure bug in either python, pip, or tem_pip such that runpip('-h') silently crashes python in both console and Idle. I will try to localize it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 06:02:09 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 Sep 2015 04:02:09 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <20150906040205.66864.96384@psf.io> Roundup Robot added the comment: New changeset 09b62202d9b7 by Steve Dower in branch '3.5': Issue #24917: time_strftime() Buffer Over-read. Patch by John Leitch. https://hg.python.org/cpython/rev/09b62202d9b7 New changeset 8b81b7ad2d0a by Steve Dower in branch '3.5': Issue #24917: Moves NEWS entry under Library. https://hg.python.org/cpython/rev/8b81b7ad2d0a New changeset a29b49d57769 by Steve Dower in branch '3.4': Issue #24917: time_strftime() Buffer Over-read. Patch by John Leitch. https://hg.python.org/cpython/rev/a29b49d57769 New changeset 6fc744ac3953 by Steve Dower in branch 'default': Issue #24917: time_strftime() Buffer Over-read. Patch by John Leitch. https://hg.python.org/cpython/rev/6fc744ac3953 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 06:04:15 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 Sep 2015 04:04:15 +0000 Subject: [issue24748] Change of behavior for importlib between 3.4 and 3.5 with DLL loading In-Reply-To: <1438176027.56.0.467476097176.issue24748@psf.upfronthosting.co.za> Message-ID: <1441512255.16.0.171913220766.issue24748@psf.upfronthosting.co.za> Larry Hastings added the comment: Pull request accepted. I had to do it manually, as I got a Misc/NEWS merge conflict. But from where I'm sitting it looks like Bitbucket understands the pull request was accepted and merged. Please forward-merge. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 06:04:37 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 Sep 2015 04:04:37 +0000 Subject: [issue24748] Change of behavior for importlib between 3.4 and 3.5 with DLL loading In-Reply-To: <1438176027.56.0.467476097176.issue24748@psf.upfronthosting.co.za> Message-ID: <1441512277.82.0.340320429464.issue24748@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- assignee: -> ncoghlan resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 06:08:38 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 06 Sep 2015 04:08:38 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441512518.18.0.795824498452.issue24917@psf.upfronthosting.co.za> Steve Dower added the comment: I applied the AIX fix to 3.4 (introduced in #19634). Python 3.2 and 3.3 aren't affected. ---------- assignee: -> steve.dower resolution: -> fixed stage: patch review -> commit review status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 06:44:06 2015 From: report at bugs.python.org (Saimadhav Heblikar) Date: Sun, 06 Sep 2015 04:44:06 +0000 Subject: [issue23551] IDLE to provide menu link to PIP gui. In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za> Message-ID: <1441514646.75.0.308896658226.issue23551@psf.upfronthosting.co.za> Saimadhav Heblikar added the comment: Hi Terry, Unfortunately, I had to perform a system reinstall, which wiped out the patch. I dont mind doing it again, but it might take until the weekend to complete. Also, now my questions from earlier are answered, it should be easier. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 06:49:19 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 Sep 2015 04:49:19 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441514959.16.0.423960429903.issue24917@psf.upfronthosting.co.za> Larry Hastings added the comment: The tests from this patch fail on Linux. ----- First: There is no trailing % test on Linux, and glibc's strftime() happily ignores a trailing %, so no ValueError is raised. Python should do either one or the other of the following: 1) Python should enforce no trailing % in the strftime format string, or 2) the test suite shouldn't assume that a trailing % in the strftime value string raises a ValueError. I can live with either of these, not sure what the right decision is. ----- Second: The test from the patch assumes that strftime('%#') will raise a ValueError. Again, strftime in Linux glibc happily accepts "%#" as a format string and thus no ValueError is raised. Python is agnostic about native format units in the strftime() format string. Therefore I strongly assert that Python must not assume that "%#" is an illegal format string. Therefore the tests must not assume that "%#" raises ValueError. Given that the code used to crash, I do want the code path exercised in the test suite. So I propose that the test attempt time.strftime('%#') and accept either success or ValueError. ----- Given that I've accepted this patch into 3.5.0, and it's now blocking my release, it is implicitly a "release blocker". I need to resolve this tonight before I can tag 3.5.0rc3. I'm going to dinner, and maybe we can have a quick discussion and come to a decision in the next hour or two. p.s. The checkin also flunked PEP 7. *sigh* ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 07:01:34 2015 From: report at bugs.python.org (John Leitch) Date: Sun, 06 Sep 2015 05:01:34 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441515694.02.0.471054810078.issue24917@psf.upfronthosting.co.za> John Leitch added the comment: Is there a way to see what style guidelines have been violated? The only thing I can think of is the curly braces in the Windows check, but I was following the conventions of the surrounding code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 07:10:29 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 Sep 2015 05:10:29 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <55ebcac1.4842420a.4934f.5439@mx.google.com> Larry Hastings added the comment: The starting curly brace goes on the same line as the statement starting the block. Keywords followed by a left parenthesis get a space between the keyword and the parenthesis. It's a small matter, I'm really much more interested in reconciling the behavior of strftime and its tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 07:24:48 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 Sep 2015 05:24:48 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441517088.35.0.317176656163.issue24917@psf.upfronthosting.co.za> Larry Hastings added the comment: Sorry, maybe you inherited those violations. I was in a hurry and not in a charitable frame of mind. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 07:26:00 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 06 Sep 2015 05:26:00 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441517160.47.0.250981319513.issue24917@psf.upfronthosting.co.za> Steve Dower added the comment: I'll fix the PEP 7 stuff (mostly inherited). MSVC can also handle '%#' and '%' as format strings (producing '' in both cases). If that matches libc behaviour, I see no reason to raise a ValueError here apart from consistency with previous Python releases. If consistency with system C libraries is preferred, then I'll change the condition to simply break out of the loop and make the test call the function expecting success. I assume there's an AIX buildbot we can watch to see the impact on that part? ---------- nosy: +georg.brandl priority: normal -> release blocker resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 07:30:57 2015 From: report at bugs.python.org (John Leitch) Date: Sun, 06 Sep 2015 05:30:57 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441517457.58.0.698560349236.issue24917@psf.upfronthosting.co.za> John Leitch added the comment: Yikes--your comment prompted me to look at the check-in, and it seems my patch wasn't properly applied. The curly braces got tweaked, which is minor as you stated, but more importantly the AIX code should not decref format. That could introduce problems bigger than what this patch was attempting to fix. And, not to dwell, but where do you see a keyword immediately followed by a left parens? I want to make sure everything is properly polished in the future, and the only thing I see is the untouched "for". Regarding your initial concerns: 1) I think we should enforce no trailing % so as to not pass format strings that may cause undefined behavior. 2) How about expecting ValueError on Windows/AIX, and pass on all other platforms? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 07:34:36 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 06 Sep 2015 05:34:36 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441517676.56.0.267380444815.issue24917@psf.upfronthosting.co.za> Steve Dower added the comment: Whoops, must have done a bad copy-paste to get that DECREF in there (I couldn't apply the patch directly because it didn't come from an HG repo, so I had to do it by hand). MSVC seems somewhat inconsistent about its response: >>> strftime('aaa%') '' >>> strftime('aaaa%') Traceback (most recent call last): File "", line 1, in ValueError: Invalid format string How closely do we want to simply expose the underlying C library's behaviour? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 07:49:35 2015 From: report at bugs.python.org (John Leitch) Date: Sun, 06 Sep 2015 05:49:35 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441518575.75.0.672372551868.issue24917@psf.upfronthosting.co.za> John Leitch added the comment: If it's so wildly inconsistent, it's my opinion that Python should perform its own validation to achieve better cross-platform support. The alternative is playing a never ending game of whack-a-mole, or just accepting that format strings may cause exceptions in some platforms but not others. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 07:57:05 2015 From: report at bugs.python.org (eryksun) Date: Sun, 06 Sep 2015 05:57:05 +0000 Subject: [issue25012] pathlib should allow converting to absolute paths without resolving symlinks In-Reply-To: <1441490748.21.0.647656961559.issue25012@psf.upfronthosting.co.za> Message-ID: <1441519025.28.0.886164858542.issue25012@psf.upfronthosting.co.za> eryksun added the comment: There's a public method that's almost what you want: >>> print(pathlib.Path.absolute.__doc__) Return an absolute version of this path. This function works even if the path doesn't point to anything. No normalization is done, i.e. all '.' and '..' will be kept along. Use resolve() to get the canonical path to a file. However, it appears to be only accidentally public. It isn't tested; it isn't mentioned in the docs; and it doesn't do the [expected] path normalization. Currently it's used as a default in resolve() if self._flavour.resolve(self) returns None. ---------- nosy: +eryksun versions: +Python 3.4 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 08:04:11 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 06 Sep 2015 06:04:11 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441519451.89.0.66286874828.issue24917@psf.upfronthosting.co.za> Steve Dower added the comment: Having now read over this whole issue, I don't actually see where the security vulnerability is (on Windows at least). This is a user-mode read, so it can only access memory in the same process, and it doesn't display it anywhere. The worst that can happen is that it hits an unreadable page and crashes, which falls under "undefined behaviour due to invalid input". I think we should just revert the patch completely. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 08:05:40 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 Sep 2015 06:05:40 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441519540.51.0.500477243216.issue24917@psf.upfronthosting.co.za> Larry Hastings added the comment: I have convinced myself that disallowing trailing % marks on all platforms is the right thing to do. Whether or not the underlying platform tolerates it, it is never *valid* input to strftime. I have a patch incubating at home. I'll put it up for review when I get back, maybe an hour. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 08:08:36 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 06 Sep 2015 06:08:36 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441519716.51.0.442441803267.issue24917@psf.upfronthosting.co.za> Steve Dower added the comment: I'll get my commits out of the way to make the buildbots green again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 08:10:27 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 Sep 2015 06:10:27 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <55ebd8cf.635e460a.30ec8.555b@mx.google.com> Larry Hastings added the comment: Oh, maybe it was all like that before. Sorry, I was in a hurry and not in a charitable frame of mind. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 08:14:45 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 Sep 2015 06:14:45 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <20150906061442.27687.25986@psf.io> Roundup Robot added the comment: New changeset 73227e857d6b by Steve Dower in branch '3.5': Issue #24917: Backed out changeset 09b62202d9b7 https://hg.python.org/cpython/rev/73227e857d6b New changeset 743924064dc8 by Steve Dower in branch 'default': Issue #24917: Backed out changeset 09b62202d9b7 https://hg.python.org/cpython/rev/743924064dc8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 08:18:38 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 06 Sep 2015 06:18:38 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441520318.89.0.622683514458.issue24917@psf.upfronthosting.co.za> Steve Dower added the comment: Yeah, I came in late and in too much of a rush too :( Backed out the broken changes, and now I'm off to bed. Not convinced there's anything that needs fixing here, and IIRC we argued through the different platform behaviours on the issue when I removed the null check that was preventing the overread. If we do anything now, it should just be `if (outbuf[1] == '\0') break` to avoid the overread. strftime() is probably too far gone to make it consistent across platforms now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 08:34:54 2015 From: report at bugs.python.org (John Leitch) Date: Sun, 06 Sep 2015 06:34:54 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441521294.85.0.177418140959.issue24917@psf.upfronthosting.co.za> John Leitch added the comment: Yes, this is a user-mode read, but I disagree with the assertion that it's not possible to use this to disclose memory. While it isn't as critical as something that outright dumps memory, there is logic that throws exceptions based on values encountered while reading outside the bounds of the buffer. This could be used as a channel to infer what is or isn't in adjacent memory. That it's user-mode doesn't matter--if an application exposes the format string as attack surface, suddenly process memory can be probed. So, it's not heartbleed, but it does have security implications. If you'd like, I can take a shot at building a PoC. Further, it's best to err on the side of caution with bugs like these; just because it doesn't seem like major issue now doesn't mean someone won't come along in the future and prove otherwise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 08:54:28 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 Sep 2015 06:54:28 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441522468.68.0.19767362412.issue24917@psf.upfronthosting.co.za> Larry Hastings added the comment: I'm going to back this out of 3.5.0rc3. I'm still willing to discuss accepting it into 3.5.0 final in some form, but for now I don't want to hold up the release. Steve: it should never be possible to crash the Python interpreter with well-formed Python code. Whether or not it's possible to exploit it, I do think this crash is something the interpreter should prevent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 08:57:19 2015 From: report at bugs.python.org (eryksun) Date: Sun, 06 Sep 2015 06:57:19 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441522639.02.0.971484918797.issue24917@psf.upfronthosting.co.za> eryksun added the comment: > MSVC seems somewhat inconsistent about its response: > >>> strftime('aaa%') > '' That's not due to MSVC. It's setting errno to EINVAL. The problem is that time_strftime is testing (buflen > 0 || i >= 256 * fmtlen). The initial value of the outbuf size i is 1024, so when (fmtlen <= 4), the value of (256 * fmtlen) is less than or equal to i, and it assumes "the format yields an empty result" without considering the value of errno. So instead of raising an exception for EINVAL, it calls PyUnicode_DecodeLocaleAndSize to return an empty string: >>> strftime('aaa%') Breakpoint 1 hit ucrtbase!strftime: 000007fe`e2bac3e0 4883ec38 sub rsp,38h 0:000> gu python35!time_strftime+0x1f5: 00000000`5de9c785 488bcb mov rcx,rbx 0:000> be 0; g Breakpoint 0 hit ucrtbase!_errno: 000007fe`e2b341b0 48895c2408 mov qword ptr [rsp+8],rbx ss:00000000`0028f320=ffffffffffffffff errno is 22: 0:000> pt; dd @rax l1 00000000`002ddb50 00000016 0:000> bd 0; g Breakpoint 2 hit python35!PyUnicode_DecodeLocaleAndSize: 00000000`5df55070 4053 push rbx 0:000> k 2 Child-SP RetAddr Call Site 00000000`0028f318 00000000`5de9c81a python35!PyUnicode_DecodeLocaleAndSize 00000000`0028f320 00000000`5df1d5c2 python35!time_strftime+0x28a 0:000> g '' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 09:51:11 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 Sep 2015 07:51:11 +0000 Subject: [issue24305] The new import system makes it inconvenient to correctly issue a deprecation warning for a module In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za> Message-ID: <1441525871.55.0.359785415625.issue24305@psf.upfronthosting.co.za> Larry Hastings added the comment: It was basically okay on the buildbots--no worse than cpython would have been before the checkin. (A lot of the buildbots are... wonky.) I checked it in to cpython350 directly. I'll do the forward merge after 3.5.0rc3 goes out the door. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 09:52:32 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 Sep 2015 07:52:32 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441525952.27.0.560700368823.issue24917@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 09:53:19 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 Sep 2015 07:53:19 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441525999.62.0.581288706257.issue24912@psf.upfronthosting.co.za> Larry Hastings added the comment: Marking as closed for now. If we decide it's a problem we can reopen later. ---------- stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 09:59:10 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Sun, 06 Sep 2015 07:59:10 +0000 Subject: [issue24305] The new import system makes it inconvenient to correctly issue a deprecation warning for a module In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za> Message-ID: <1441526350.54.0.691471643316.issue24305@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Hooray! Thanks Larry. Would it make sense to do a 3.4.x backport, or is that closed now with 3.5 being imminent? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 10:04:19 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 Sep 2015 08:04:19 +0000 Subject: [issue24305] The new import system makes it inconvenient to correctly issue a deprecation warning for a module In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za> Message-ID: <1441526659.56.0.00668006074616.issue24305@psf.upfronthosting.co.za> Larry Hastings added the comment: I don't think it'd be appropriate to backport to 3.4--that ship has sailed. 3.4 requires a stacklevel=8 and that's that. If we backported it and it shipped in 3.4.4, "correct" code would have to use a stacklevel=8 for 3.4.0 through 3.4.3, and stacklevel=2 for 3.4.4 and above. Ugh! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 10:05:38 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 Sep 2015 08:05:38 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows In-Reply-To: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> Message-ID: <1441526738.85.0.995923743688.issue25005@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 10:06:01 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 Sep 2015 08:06:01 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows In-Reply-To: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> Message-ID: <1441526761.07.0.676567159089.issue25005@psf.upfronthosting.co.za> Larry Hastings added the comment: Marking this as deferred, as I'm not convinced I should ship either of those patches in 3.5.0rc3. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 10:08:22 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 Sep 2015 08:08:22 +0000 Subject: [issue24585] Windows installer does not detect existing installs In-Reply-To: <1436285916.26.0.0298485642616.issue24585@psf.upfronthosting.co.za> Message-ID: <1441526902.72.0.710389075189.issue24585@psf.upfronthosting.co.za> Larry Hastings added the comment: What happened with this? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 10:56:26 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Sun, 06 Sep 2015 08:56:26 +0000 Subject: [issue24305] The new import system makes it inconvenient to correctly issue a deprecation warning for a module In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za> Message-ID: <1441529786.59.0.917694278092.issue24305@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Some limited code search statistics posted upthread (msg244448) suggest that ~100% of real-world code is using stacklevel=2 unconditionally and thus getting incorrect results on 3.3 and 3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 10:57:47 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 Sep 2015 08:57:47 +0000 Subject: [issue24305] The new import system makes it inconvenient to correctly issue a deprecation warning for a module In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za> Message-ID: <1441529867.49.0.209572000905.issue24305@psf.upfronthosting.co.za> Larry Hastings added the comment: Yes, I saw that. That doesn't mean we should change the interface they are using (incorrectly) eighteen months after it shipped. We take backwards-compatibility pretty seriously here in the Python world, bugs and all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 11:04:16 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Sun, 06 Sep 2015 09:04:16 +0000 Subject: [issue24305] The new import system makes it inconvenient to correctly issue a deprecation warning for a module In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za> Message-ID: <1441530256.72.0.145735386173.issue24305@psf.upfronthosting.co.za> Nathaniel Smith added the comment: Also just checked searchcode.com, which allows more fine-grained queries, and it reports ~6500 hits for "stacklevel=2" and exactly 0 for "stacklevel=8". Huh. So the official word is that requiring stacklevel=8 on 3.4 is not a bug, rather all those modules are buggy? I've been telling people who asked to just leave the stacklevel=2 thing alone rather than adding version-specific conditionals, but I guess I can pass that on. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 11:05:17 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 Sep 2015 09:05:17 +0000 Subject: [issue24305] The new import system makes it inconvenient to correctly issue a deprecation warning for a module In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za> Message-ID: <1441530317.89.0.945354446151.issue24305@psf.upfronthosting.co.za> Larry Hastings added the comment: Unless I'm overruled, yes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 11:26:03 2015 From: report at bugs.python.org (Nathaniel Smith) Date: Sun, 06 Sep 2015 09:26:03 +0000 Subject: [issue24305] The new import system makes it inconvenient to correctly issue a deprecation warning for a module In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za> Message-ID: <1441531563.83.0.836511609619.issue24305@psf.upfronthosting.co.za> Nathaniel Smith added the comment: ok ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 12:36:43 2015 From: report at bugs.python.org (Xavier de Gaye) Date: Sun, 06 Sep 2015 10:36:43 +0000 Subject: [issue25013] run_pdb() in test_pdb.py always returns stderr as None Message-ID: <1441535803.94.0.131993266269.issue25013@psf.upfronthosting.co.za> New submission from Xavier de Gaye: The attached patch fixes this. ---------- components: Library (Lib) files: run_pdb.patch keywords: patch messages: 249989 nosy: terry.reedy, xdegaye priority: normal severity: normal status: open title: run_pdb() in test_pdb.py always returns stderr as None type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file40379/run_pdb.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 13:41:44 2015 From: report at bugs.python.org (Felix Kaiser) Date: Sun, 06 Sep 2015 11:41:44 +0000 Subject: [issue24902] http.server: on startup, show host/port as URL In-Reply-To: <1440074614.12.0.491243146535.issue24902@psf.upfronthosting.co.za> Message-ID: <1441539704.7.0.788439832246.issue24902@psf.upfronthosting.co.za> Felix Kaiser added the comment: So do I, but I can live with either way. Can one of you merge one of these patches? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 14:32:15 2015 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 Sep 2015 12:32:15 +0000 Subject: [issue25014] Add contextlib.itercm() Message-ID: <1441542735.79.0.482816688867.issue25014@psf.upfronthosting.co.za> New submission from Ezio Melotti: Add an itercm() function that receives an iterable that supports the context manager protocol (e.g. files) and calls enter/exit without having to use the with statement explicitly. The implementation is pretty straightforward (unless I'm missing something): def itercm(cm): with cm: yield from cm Example usages: def cat(fnames): lines = chain.from_iterable(itercm(open(f)) for f in fnames) for line in lines: print(line, end='') This will close the files as soon as the last line is read. The __exit__ won't be called until the generator is exhausted, so the user should make sure that it is (if he wants __exit__ to be closed). __exit__ is still called in case of exception. Attached a clearer example of how it works. Do you think this would be a good addition to contextlib (or perhaps itertools)? P.S. I'm also contemplating the idea of having e.g. it = itercm(fname, func=open) to call func lazily once the first next(it) happens, but I haven't thought in detail about the implications of this. I also haven't considered how this interacts with coroutines. ---------- components: Library (Lib) files: itercm-example.txt messages: 249991 nosy: ezio.melotti, ncoghlan, rhettinger priority: normal severity: normal stage: needs patch status: open title: Add contextlib.itercm() type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file40380/itercm-example.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 15:14:21 2015 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 Sep 2015 13:14:21 +0000 Subject: [issue25014] Add contextlib.itercm() In-Reply-To: <1441542735.79.0.482816688867.issue25014@psf.upfronthosting.co.za> Message-ID: <1441545261.7.0.192244822349.issue25014@psf.upfronthosting.co.za> Ezio Melotti added the comment: FTR one of the reason that led me to itercm() is: with open(fname) as f: transformed = (transform(line) for line in f) filtered = (line for line in lines if filter(line)) # ... Now filtered must be completely consumed before leaving the body of the `with` otherwise this happens: >>> with open(fname) as f: ... transformed = (transform(line) for line in f) ... filtered = (line for line in lines if filter(line)) ... >>> # ... >>> next(filtered) ValueError: I/O operation on closed file. With itercm() it's possible to do: f = itercm(open(fname)) transformed = (transform(line) for line in f) filtered = (line for line in lines if filter(line)) ... # someone consumes filtered down the line lazily # and eventually the file gets closed itercm() could also be used (abused?) where a regular `with` would do just fine to save one extra line and indentation level (at the cost of an extra import), e.g.: def lazy_cat(fnames): for fname in fnames: yield from itercm(open(fname)) instead of: def lazy_cat(fnames): for fname in fnames: with open(fname) as f: yield from f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 15:49:17 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 06 Sep 2015 13:49:17 +0000 Subject: [issue24585] Windows installer does not detect existing installs In-Reply-To: <1436285916.26.0.0298485642616.issue24585@psf.upfronthosting.co.za> Message-ID: <1441547357.5.0.783873690526.issue24585@psf.upfronthosting.co.za> Steve Dower added the comment: Good to go! ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 15:54:41 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 06 Sep 2015 13:54:41 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441547681.45.0.57203667115.issue24917@psf.upfronthosting.co.za> Steve Dower added the comment: Larry: agreed, no crashing. We'll get the trivial fix in that doesn't raise any error, and should probably stop suppressing the exception in the situation eryksun describes. That will correctly expose the platform's strftime semantics. Unless you want to write more thorough validation of incoming strings, I'll work something up later today or tomorrow. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 15:57:13 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 06 Sep 2015 13:57:13 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows In-Reply-To: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> Message-ID: <1441547833.6.0.581934459027.issue25005@psf.upfronthosting.co.za> Steve Dower added the comment: Does that mean not shipping either of them in 3.5.0 at all? Do you need convincing or a simpler patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 16:53:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Sep 2015 14:53:36 +0000 Subject: [issue24982] shutil.make_archive doesn't archive empty directories In-Reply-To: <1441155377.03.0.243318485167.issue24982@psf.upfronthosting.co.za> Message-ID: <1441551216.39.0.237114549959.issue24982@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 17:31:52 2015 From: report at bugs.python.org (Thomas Belhalfaoui) Date: Sun, 06 Sep 2015 15:31:52 +0000 Subject: [issue24964] Add tunnel CONNECT response headers to httplib / http.client In-Reply-To: <1440956510.2.0.613573748355.issue24964@psf.upfronthosting.co.za> Message-ID: <1441553512.18.0.0948796291183.issue24964@psf.upfronthosting.co.za> Thomas Belhalfaoui added the comment: Martin, I went through your patch and made some simple tests, and I have a couple of questions. 1) When I run the following code, I get a "Bad file descriptor" : conn = httplib.HTTPConnection("uk.proxymesh.com", 31280) conn.set_tunnel("www.google.com", 80) conn.request("GET", "/") resp = conn.getresponse() print(resp.read()) So I tweaked the "getresponse" function so that it does not call "self.close()" (i.e. the connection stays open after the CONNECT request) in that case, and it seems to works fine. 2) I added "self.sock, _ = tunnel" in HTTPConnection constructor, to try your use case, but I get "http.client.RemoteDisconnected: Remote end closed connection without response". Do you think it makes sense or am I missing something ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 17:48:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Sep 2015 15:48:58 +0000 Subject: [issue24982] shutil.make_archive doesn't archive empty directories In-Reply-To: <1441155377.03.0.243318485167.issue24982@psf.upfronthosting.co.za> Message-ID: <1441554538.34.0.82327436332.issue24982@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch. Should this be considered as a bug fix rather than new feature? ---------- keywords: +patch nosy: +eric.araujo, tarek stage: needs patch -> patch review Added file: http://bugs.python.org/file40381/make_archive_zip_dirs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 17:55:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Sep 2015 15:55:01 +0000 Subject: [issue25014] Add contextlib.itercm() In-Reply-To: <1441542735.79.0.482816688867.issue25014@psf.upfronthosting.co.za> Message-ID: <1441554901.66.0.450604310397.issue25014@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What if the last line will be never read? We had bugs with resource leaks in generators, and I'm not sure that all such bugs were fixed. ---------- nosy: +pitrou, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 19:02:27 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 06 Sep 2015 17:02:27 +0000 Subject: [issue22241] strftime/strptime round trip fails even for UTC datetime object In-Reply-To: <1408620917.6.0.856660367054.issue22241@psf.upfronthosting.co.za> Message-ID: <1441558947.66.0.539043880031.issue22241@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Addressed review comments. ---------- Added file: http://bugs.python.org/file40382/issue22241-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 19:07:36 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 Sep 2015 17:07:36 +0000 Subject: [issue22241] strftime/strptime round trip fails even for UTC datetime object In-Reply-To: <1408620917.6.0.856660367054.issue22241@psf.upfronthosting.co.za> Message-ID: <20150906170733.12013.47147@psf.io> Roundup Robot added the comment: New changeset f904b7eb3981 by Alexander Belopolsky in branch 'default': Closes Issue#22241: timezone.utc name is now plain 'UTC', not 'UTC-00:00'. https://hg.python.org/cpython/rev/f904b7eb3981 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 19:09:31 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 06 Sep 2015 17:09:31 +0000 Subject: [issue22241] strftime/strptime round trip fails even for UTC datetime object In-Reply-To: <1408620917.6.0.856660367054.issue22241@psf.upfronthosting.co.za> Message-ID: <1441559371.09.0.668061208688.issue22241@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- resolution: -> fixed stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 19:09:43 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 06 Sep 2015 17:09:43 +0000 Subject: [issue22241] strftime/strptime round trip fails even for UTC datetime object In-Reply-To: <1408620917.6.0.856660367054.issue22241@psf.upfronthosting.co.za> Message-ID: <1441559383.61.0.379073170937.issue22241@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 19:37:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Sep 2015 17:37:32 +0000 Subject: [issue24858] python3 -m test -ugui -v test_tk gives 3 failures under Debian unstable (sid) In-Reply-To: <1439486580.93.0.0912467403749.issue24858@psf.upfronthosting.co.za> Message-ID: <1441561052.85.0.661423993095.issue24858@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Laura, could you please report a bug to Debian? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 20:26:24 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 Sep 2015 18:26:24 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za> Message-ID: <20150906182621.27703.48572@psf.io> Roundup Robot added the comment: New changeset d51a82f68a70 by Serhiy Storchaka in branch 'default': Issue #15989: Fixed some scarcely probable integer overflows. https://hg.python.org/cpython/rev/d51a82f68a70 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 20:28:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Sep 2015 18:28:50 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za> Message-ID: <1441564130.85.0.585141356061.issue15989@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: One of changes to Modules/_io/_iomodule.c is no longer actual since issue21679. Change to Modules/selectmodule.c is no longer actual since issue23485 (f54bc2c52dfd). The rest changes were committed to 3.6 only. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 20:39:34 2015 From: report at bugs.python.org (Brett Cannon) Date: Sun, 06 Sep 2015 18:39:34 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1441564774.9.0.410009161069.issue24915@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 20:42:28 2015 From: report at bugs.python.org (Brett Cannon) Date: Sun, 06 Sep 2015 18:42:28 +0000 Subject: [issue24938] Measure if _warnings.c is still worth having In-Reply-To: <1440528567.54.0.786073455364.issue24938@psf.upfronthosting.co.za> Message-ID: <1441564948.47.0.383165432388.issue24938@psf.upfronthosting.co.za> Brett Cannon added the comment: After thinking about it and with _warnings.c not exactly changing very much I think I'm going to call YAGNI on ripping out _warnings.c. ---------- resolution: -> works for me status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 20:44:17 2015 From: report at bugs.python.org (Brett Cannon) Date: Sun, 06 Sep 2015 18:44:17 +0000 Subject: [issue24779] Python/ast.c: decode_unicode is never called with rawmode=True In-Reply-To: <1438533157.42.0.19611866983.issue24779@psf.upfronthosting.co.za> Message-ID: <1441565057.88.0.181811574597.issue24779@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 20:53:12 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 06 Sep 2015 18:53:12 +0000 Subject: [issue17582] xml.etree.ElementTree does not preserve whitespaces in attributes In-Reply-To: <1364660794.69.0.883579635559.issue17582@psf.upfronthosting.co.za> Message-ID: <1441565592.61.0.493148283995.issue17582@psf.upfronthosting.co.za> Stefan Behnel added the comment: Patch and test look correct. They fix a bug that produces incorrect output, so I vote for backporting them. Most code won't see the difference as whitespace control characters are rare in attribute values. And code that uses them will benefit from correctness. Obviously, there might also be breakage in the rare case that code puts control characters into attribute values and expects them to disappear magically, but then it's the user code that is wrong here. Only issue is that serialisation is slow already and this change slows it down a bit more. Every attribute value will now be searched 8 times instead of 5 times. I added a minor review comment that would normally reduce it to 7. timeit suggests to me that the overall overhead is still tiny, though, and thus acceptable: $ python3.5 -m timeit -s "s = 'askhfalsdhfashldfsadf'" "'\n' in s" 10000000 loops, best of 3: 0.0383 usec per loop $ python3.5 -m timeit -s "s = 'askhfalsdhfashldfsadf'" "s.replace('\n', 'y')" 10000000 loops, best of 3: 0.151 usec per loop $ python3.5 -m timeit -s "s = 'askhfalsdhfashldfsadf'; rep=s.replace" "rep('\n', 'y')" 10000000 loops, best of 3: 0.12 usec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 20:55:36 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 Sep 2015 18:55:36 +0000 Subject: [issue23144] html.parser.HTMLParser: setting 'convert_charrefs = True' leads to dropped text In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za> Message-ID: <20150906185533.11262.98006@psf.io> Roundup Robot added the comment: New changeset ef82131d0c93 by Ezio Melotti in branch '3.4': #23144: Make sure that HTMLParser.feed() returns all the data, even when convert_charrefs is True. https://hg.python.org/cpython/rev/ef82131d0c93 New changeset 1f6155ffcaf6 by Ezio Melotti in branch '3.5': #23144: merge with 3.4. https://hg.python.org/cpython/rev/1f6155ffcaf6 New changeset 48ae9d66c720 by Ezio Melotti in branch 'default': #23144: merge with 3.5. https://hg.python.org/cpython/rev/48ae9d66c720 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 20:56:30 2015 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 Sep 2015 18:56:30 +0000 Subject: [issue23144] html.parser.HTMLParser: setting 'convert_charrefs = True' leads to dropped text In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za> Message-ID: <1441565790.47.0.15300649897.issue23144@psf.upfronthosting.co.za> Ezio Melotti added the comment: Fixed, thanks for the report! ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed versions: +Python 3.6 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 20:57:25 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 06 Sep 2015 18:57:25 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440879703.45.0.682803049675.issue24915@psf.upfronthosting.co.za> Message-ID: <55EC8C93.3030702@behnel.de> Stefan Behnel added the comment: > The only thing that was a bit mystifying were the errors during the > initial profile run. There is so much that floats by in the terminal > window that I completely missed the warnings about errors during the > test run not being anything to worry about. Then wouldn't it be better to suppress (or at least reduce) the output of the test runs in this case? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 21:02:13 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sun, 06 Sep 2015 19:02:13 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za> Message-ID: <1441566133.36.0.532016251499.issue15989@psf.upfronthosting.co.za> Eric V. Smith added the comment: Isn't Python-ast.c a generated file? ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 21:02:52 2015 From: report at bugs.python.org (Laura Creighton) Date: Sun, 06 Sep 2015 19:02:52 +0000 Subject: [issue24858] python3 -m test -ugui -v test_tk gives 3 failures under Debian unstable (sid) In-Reply-To: <1439486580.93.0.0912467403749.issue24858@psf.upfronthosting.co.za> Message-ID: <1441566172.44.0.249993236233.issue24858@psf.upfronthosting.co.za> Laura Creighton added the comment: I could. Have you heard from doko? If python3 on debian unstable is about to become python3.5 and things work fine on 3.5 I wonder if it is worth the effort. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 21:05:52 2015 From: report at bugs.python.org (Brett Cannon) Date: Sun, 06 Sep 2015 19:05:52 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1441566352.39.0.894735085055.issue24915@psf.upfronthosting.co.za> Brett Cannon added the comment: I guess the test output -- both stdout and stderr -- could be redirected to /dev/null as simply using -q with regrtest will still lead to failures being emitted and random output which no one cares about except people inspecting the test output. Just need to make sure to mention that all output is suppressed so people don't think the process is hanging. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 21:15:24 2015 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 06 Sep 2015 19:15:24 +0000 Subject: [issue25014] Add contextlib.itercm() In-Reply-To: <1441542735.79.0.482816688867.issue25014@psf.upfronthosting.co.za> Message-ID: <1441566924.35.0.617786081047.issue25014@psf.upfronthosting.co.za> Ezio Melotti added the comment: If you are talking about generators that never get exhausted, the fact that the __exit__ is never invoked is expected and something that developers should take into account while using itercm(). I'm not aware of other generators-related issues that might cause leaks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 21:16:05 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 06 Sep 2015 19:16:05 +0000 Subject: [issue25015] Idle: scroll Text faster with mouse wheel Message-ID: <1441566965.71.0.33630989907.issue25015@psf.upfronthosting.co.za> New submission from Terry J. Reedy: https://stackoverflow.com/questions/32414942/python-scroll-speed At least on Win7, tk.Texts scroll, by default, at an anemic 2-3 lines per wheel click, ignoring the system wheel setting. What happens on other systems? I consider this a probable tk bug, at least on Widows, but we can override the default (on Windows) with def mousescroll(event): return 'break' text.bind('', mousescroll) turtledemo.__main__ has wheel code (for font resizing) for Windows, Linux, and Mac. Unless we can access system settings, we might add a config option. ---------- messages: 250013 nosy: terry.reedy priority: normal severity: normal stage: test needed status: open title: Idle: scroll Text faster with mouse wheel type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 21:50:41 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 06 Sep 2015 19:50:41 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441569041.5.0.700002873922.issue24917@psf.upfronthosting.co.za> Steve Dower added the comment: New patch attached that just breaks out of the scanning loop and lets the system CRT handle invalid format strings. Fixes the condition that was suppressing some errors on Windows. Also fixed the PEP 7 issues around the changed code (I believe). No new test because the crash cannot be reliably reproduced and the expected results vary dramatically between platforms. The two if/break lines in the AIX branch should also be applied to 3.4 to prevent crashes. The rest of the fix (including the PEP 7 fixes) should not. ---------- versions: -Python 3.2, Python 3.3 Added file: http://bugs.python.org/file40383/24917_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 22:22:01 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 06 Sep 2015 20:22:01 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows In-Reply-To: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> Message-ID: <1441570921.02.0.547685574606.issue25005@psf.upfronthosting.co.za> R. David Murray added the comment: You have to ship one of them by ("one of them" being either the fix or the backout) in 3.5.0, Larry, otherwise you are introducing a security vulnerability into 3.5 that doesn't exist in 3.4. If you don't ship it in rc3, then there's no chance that 3.5.0 will be unchanged from rc3, which is the ideal we should be aiming for (that's why it's called a "release *candidate*"). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 22:24:17 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 06 Sep 2015 20:24:17 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> Message-ID: <1441571057.36.0.567386586753.issue23406@psf.upfronthosting.co.za> R. David Murray added the comment: Looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 22:29:50 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 06 Sep 2015 20:29:50 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1348167705.87.0.588220983695.issue15989@psf.upfronthosting.co.za> Message-ID: <20150906202947.14873.87521@psf.io> Roundup Robot added the comment: New changeset e53df7955192 by Serhiy Storchaka in branch 'default': Make asdl_c.py to generate Python-ast.c changed in issue #15989. https://hg.python.org/cpython/rev/e53df7955192 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 22:31:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Sep 2015 20:31:06 +0000 Subject: [issue15989] Possible integer overflow of PyLong_AsLong() results In-Reply-To: <1441566133.36.0.532016251499.issue15989@psf.upfronthosting.co.za> Message-ID: <1994507.6RTDGsejE4@raxxla> Serhiy Storchaka added the comment: > Isn't Python-ast.c a generated file? Good catch Eric. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 22:38:15 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 06 Sep 2015 20:38:15 +0000 Subject: [issue25008] Deprecate smtpd In-Reply-To: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za> Message-ID: <1441571895.29.0.469333808088.issue25008@psf.upfronthosting.co.za> R. David Murray added the comment: I believe that smtpd is used for a *lot* of testing code (anyone who is writing smtp clients in python, pretty much, and probably some writing in other languages). I really don't see the rationale for removing it, assuming we can rewrite it "in time". On the other hand, are we really going to *remove* asyncore/asynchat? Or is this a "deprecation in place" like optparse? If the latter then I don't really care if the same is done to smtpd :) If the former, why, if we've kept optparse? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 22:59:26 2015 From: report at bugs.python.org (John Leitch) Date: Sun, 06 Sep 2015 20:59:26 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441573166.4.0.13243435706.issue24917@psf.upfronthosting.co.za> John Leitch added the comment: First, let me begin by saying I believe this patch will fix the buffer over-read, which is a good step forward. However, after giving the matter more thought, and at the risk of wearing out my welcome, I am of the belief that relying on the CRT to handle malformed format strings is the wrong approach. As per the C spec, strftime's behavior when handling invalid format strings is undefined: "If a conversion specifier is not one of the above, the behavior is undefined" Quite often, "undefined" translates to "exploitable". And at the very least, by not performing thorough enough validation, Python is misusing strftime(), which may lead to crashes or undermine memory safety. Of course, this is all speculation--I haven't the time or resource to learn other platforms to see what's possible. But, even if I could, the task would be Sisyphean because there's simply no way to know what the future holds when dealing with implementation that could change at any point. I realize we must be pragmatic with matters such as this, and a dramatic change could be breaking for some Python apps. Even so, I feel it's worth vocalizing these concerns. As a principal, I think that "safe", well-formed Python should never be able to perform operations that lead to undefined behavior in the underlying runtime. Alright, rant done. If at any point in time locking down Python's strftime with more aggressive validation is considered viable, I am more than willing to take a shot at submitting a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 23:00:51 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 06 Sep 2015 21:00:51 +0000 Subject: [issue24982] shutil.make_archive doesn't archive empty directories In-Reply-To: <1441155377.03.0.243318485167.issue24982@psf.upfronthosting.co.za> Message-ID: <1441573251.24.0.285167972884.issue24982@psf.upfronthosting.co.za> R. David Murray added the comment: I think it could be considered a bug fix, given that other archive programs, including zipfile itself, act in this way, and it is relatively unlikely that anyone is *depending* on make_archive not including empty directories (ie: that it would break their code if these directories were included). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 23:19:11 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 06 Sep 2015 21:19:11 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441574351.48.0.395261808028.issue24917@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Historically, time and os modules have been considered low level, thin wrappers over system libc functions. Users of these modules are the proverbial "consenting adults" who should understand their power and the associated risks. The place to provide a better behaved strftime function is the datetime module, but I would leave time.stftime pretty much the way it is and would only consider making *fewer* checks on Windows if _Py_BEGIN_SUPPRESS_IPH / _Py_END_SUPPRESS_IPH macros can indeed help to avoid crashes on illegal format strings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 6 23:55:24 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 06 Sep 2015 21:55:24 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441576524.74.0.384425801875.issue24917@psf.upfronthosting.co.za> Steve Dower added the comment: FWIW, those macros prevent a certain class of "undefined behavior," which in this case is to terminate the process rather than return an error code. They don't do anything to prevent crashes due to exploitation or malicious code. The place for more robust formatting is datetime.__format__(), which from a quick test seems to be more strict about what is in the format string. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 00:04:04 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 06 Sep 2015 22:04:04 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441577044.05.0.667407237386.issue24917@psf.upfronthosting.co.za> Larry Hastings added the comment: Having slept on it, I agree with Steve. We should make the minimal change necessary in order to not crash. However, it still needs a regression test. The test can use JohnLeitch's proposed test as a good starting point, but it must accept either success or ValueError as passing the test. I still think there's merit in detecting a trailing unquoted % at the end of the format string, but that would only be appropriate for 3.6 at this point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 00:07:28 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 Sep 2015 22:07:28 +0000 Subject: [issue25011] Smarter rl complete: hide private and special names In-Reply-To: <1441488567.65.0.369817501077.issue25011@psf.upfronthosting.co.za> Message-ID: <1441577248.54.0.0920720792699.issue25011@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I like the idea, though some people may object to breaking their worflow (tm). Nosy'ing David just in case ;-) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 00:10:57 2015 From: report at bugs.python.org (Jakub Wilk) Date: Sun, 06 Sep 2015 22:10:57 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1441577457.29.0.797951211101.issue15873@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 00:11:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 06 Sep 2015 22:11:32 +0000 Subject: [issue25015] Idle: scroll Text faster with mouse wheel In-Reply-To: <1441566965.71.0.33630989907.issue25015@psf.upfronthosting.co.za> Message-ID: <1441577492.02.0.275378973844.issue25015@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: On X Window the scroll step in text widget is constant (50 pixels). On Windows and Mac OS it should depend on mouse settings. Run with, execute bind . {puts %D} and try to roll mouse wheel on Tk window with different speed and settings. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 00:13:10 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 06 Sep 2015 22:13:10 +0000 Subject: [issue25014] Add contextlib.itercm() In-Reply-To: <1441542735.79.0.482816688867.issue25014@psf.upfronthosting.co.za> Message-ID: <1441577590.9.0.317537102647.issue25014@psf.upfronthosting.co.za> Martin Panter added the comment: I had also thought of this kind of function, but I dismissed it because it would either have to rely on garbage collection or an explicit close() call to close the generator in case the iteration is aborted. I think it might need some kind of ?with-for? combined statement added to the langauge to be bulletproof. Considering the second example in your script, ?exit is called in case of errors?: What is stopping the interpreter from storing the iterator of the current ?for? loop in the top-level frame object? Then the iterator would be referenced by the exception traceback, and prevent garbage collection of its itercm() instance. Hypothetically: __traceback__ ? tb_frame ? ?for? iterator ? itercm() instance Also, I would tend to put this sort of function in ?itertools?, since generators are not context managers by design. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 00:14:56 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Sun, 06 Sep 2015 22:14:56 +0000 Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za> Message-ID: <1441577696.79.0.927207987332.issue15873@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 00:30:35 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 06 Sep 2015 22:30:35 +0000 Subject: [issue25014] Add contextlib.itercm() In-Reply-To: <1441542735.79.0.482816688867.issue25014@psf.upfronthosting.co.za> Message-ID: <1441578635.08.0.564733902144.issue25014@psf.upfronthosting.co.za> Nick Coghlan added the comment: __exit__ will still get invoked even if the generator is never exhausted: >>> def itercm(cm): ... with cm: ... yield from cm ... >>> class TestCM: ... def __iter__(self): ... yield 6 ... yield 9 ... yield 42 ... def __enter__(self): ... return self ... def __exit__(self, *args): ... print("Terminated CM") ... >>> itr = itercm(TestCM()) >>> next(itr) 6 >>> del itr Terminated CM We addressed the major problems with generators failing to clean up resources back when generator.close() was introduced in PEP 342, and then Antoine addressed the cyclic GC problem in PEP 442. The key thing that itercm() adds over the status quo is that if the generator *is* exhausted, then the resource *will* be cleaned up immediately. If the generator *isn't* exhausted, then it falls back to non-deterministic GC based cleanup, which is what you'd get today by not using a context manager at all. To be convinced that we need a third cleanup option beyond "always deterministic" and "always non-deterministic", I'd need some concrete use cases where the success case needs deterministic cleanup, but the error case is OK with non-deterministic cleanup. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 00:34:03 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 06 Sep 2015 22:34:03 +0000 Subject: [issue25014] Add contextlib.itercm() In-Reply-To: <1441542735.79.0.482816688867.issue25014@psf.upfronthosting.co.za> Message-ID: <1441578843.92.0.661067314395.issue25014@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't think I like this idea. It's not really a common use case (I've never wished I had itercm()) and it will make it possible to write slightly obscure code. Of course you can already write obscure code using itertools :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 00:45:38 2015 From: report at bugs.python.org (eryksun) Date: Sun, 06 Sep 2015 22:45:38 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441579538.48.0.455263715426.issue24917@psf.upfronthosting.co.za> eryksun added the comment: With MSVC, if errno is cleared before calling strftime, then when buflen == 0 you know whether it's an invalid format string (EINVAL) or maxsize is too small (ERANGE). There's no need to guess. Oddly, only EINVAL is documented, even though setting ERANGE has been in the implementation for years. VC 10 (strftime.c): /* error - return an empty string */ *(strstart)='\0'; /* now return our error/insufficient buffer indication */ if ( !failed && left <= 0 ) { /* do not report this as an error to allow the caller to resize */ errno=ERANGE; } else { _VALIDATE_RETURN( FALSE, EINVAL, 0); } VC 14 (time/wcsftime.cpp): // Error: return an empty string: *string = L'\0'; // Now return our error/insufficient buffer indication: if (!failed && remaining <= 0) { // Do not report this as an error to allow the caller to resize: errno = ERANGE; } else { _VALIDATE_RETURN(false, EINVAL, 0); } ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 01:14:22 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 06 Sep 2015 23:14:22 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441581262.51.0.90226017602.issue24917@psf.upfronthosting.co.za> Steve Dower added the comment: How's this for the test (I added an explanatory comment, since it may look like it isn't testing anything to someone who isn't familiar with the issue): def test_strftime_format_check(self): # Test that strftime does not crash on invalid format strings # that may trigger a buffer overread. When not triggered, # strftime may succeed or raise ValueError depending on # the platform. for x in [ '', 'A', '%A', '%AA' ]: for y in range(0x0, 0x10): for z in [ '%', 'A%', 'AA%', '%A%', 'A%A%', '%#' ]: try: time.strftime(x * y + z) except ValueError: pass ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 03:20:45 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Sep 2015 01:20:45 +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: <20150907012041.14881.30988@psf.io> Roundup Robot added the comment: New changeset 3510e5d435db by Martin Panter in branch '2.7': Issue #17849: Raise sensible exception for invalid HTTP tunnel response https://hg.python.org/cpython/rev/3510e5d435db ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 03:23:30 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 07 Sep 2015 01:23:30 +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: <1441589010.25.0.661292690766.issue17849@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks Cory. Error now looks like this: $ https_proxy=http://223.19.230.181:80 ./python -c 'from urllib2 import *; urlopen("https://bugs.python.org/issue17849")' [. . .] urllib2.URLError: ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 04:18:13 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Sep 2015 02:18:13 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> Message-ID: <20150907021810.101480.53654@psf.io> Roundup Robot added the comment: New changeset 6c222848badd by Martin Panter in branch '2.7': Issue #23406: Clarify documentation on multiplying a sequence https://hg.python.org/cpython/rev/6c222848badd New changeset 57f8c7ad7782 by Martin Panter in branch '3.4': Issue #23406: Clarify documentation on multiplying a sequence https://hg.python.org/cpython/rev/57f8c7ad7782 New changeset f624b7fd3b83 by Martin Panter in branch '3.5': Issue #23406: Merge 3.4 into 3.5 https://hg.python.org/cpython/rev/f624b7fd3b83 New changeset d2b3c7c5ef02 by Martin Panter in branch 'default': Issue #23406: Merge 3.5 into 3.6 https://hg.python.org/cpython/rev/d2b3c7c5ef02 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 04:21:17 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 07 Sep 2015 02:21:17 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> Message-ID: <1441592477.04.0.904531312273.issue23406@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 04:24:33 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 07 Sep 2015 02:24:33 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441592673.14.0.124704868816.issue24917@psf.upfronthosting.co.za> Steve Dower added the comment: New PR: https://bitbucket.org/larry/cpython350/pull-requests/19/issue-24917-time_strftime-buffer-over-read ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 04:39:31 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 Sep 2015 02:39:31 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows In-Reply-To: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> Message-ID: <1441593571.85.0.278659325804.issue25005@psf.upfronthosting.co.za> Larry Hastings added the comment: I want to ship something, but I don't think it'll be either of those patches in their current form. Maybe I'm dense, but I don't feel like I understand these patches. They have very different approaches. The first one attempts to rehabilitate the patch by running the browser directly instead of using "start"? Do the features added in issue 8232 still work? The second one just backs out the feature completely? The features added in issue 8232 are gone? And both patches switch from using subprocess.call(shell=True) to os.startfile(), which is the security hole David is talking about, which isn't actually what this bug is about. Do both patches fix the erroneous behavior observed by the original bug report, with "&" being interpreted as a shell command separator? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 04:41:15 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 07 Sep 2015 02:41:15 +0000 Subject: [issue25014] Add contextlib.itercm() In-Reply-To: <1441542735.79.0.482816688867.issue25014@psf.upfronthosting.co.za> Message-ID: <1441593675.14.0.270704636135.issue25014@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > I don't think I like this idea. It's not really a common use > case (I've never wished I had itercm()) and it will make it > possible to write slightly obscure code. Of course you can > already write obscure code using itertools :-) I concur with Antoine and think the world is better off without this one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 04:49:18 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 07 Sep 2015 02:49:18 +0000 Subject: [issue25004] test_mmap should catch f.close() failure in LargeMmapTests._make_test_file() In-Reply-To: <1441404381.95.0.01039017408.issue25004@psf.upfronthosting.co.za> Message-ID: <1441594158.71.0.274201849171.issue25004@psf.upfronthosting.co.za> Martin Panter added the comment: Patch looks good to me. Anything that fails flush() is likely to also fail close(). But I cannot reproduce the actual failure. Perhaps it requires a file system like FAT that doesn?t support ?holes? in files. ---------- nosy: +berker.peksag, martin.panter stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 04:55:38 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 Sep 2015 02:55:38 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441594538.51.0.566302784707.issue24917@psf.upfronthosting.co.za> Larry Hastings added the comment: Steve, did you confirm that the test triggers the array bounds bug when the patch *isn't* applied? I want to confirm both that a) the test exercises the bug, and b) the fix fixes the bug. I assume you ran the test suite with the patch applied, so that covers b). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 05:06:03 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 07 Sep 2015 03:06:03 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441595163.23.0.601843048458.issue24917@psf.upfronthosting.co.za> Steve Dower added the comment: I wasn't able to repro the crash at all, even with the debugging flags that make this sort of issue more prominent. It relies on a very precise layout of multiple objects in memory, or possibly a specific sequence of allocations/deallocations, as well as a format string ending in an unescaped '%' or (on Windows) '%#'. It's still obviously an issue though - we should have the check for '\0' there by any reasonably analysis of the code, or else should not be adding 2 to the pointer to start the next step of the search. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 05:26:12 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 Sep 2015 03:26:12 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441596372.97.0.536015858012.issue24917@psf.upfronthosting.co.za> Larry Hastings added the comment: Okay, I think *I* reproduced it. 1) I pulled your cpython350 fork down locally. 2) I updated to your checkin that fixed the bug. (c31dad22c80d) 3) I reverted the change to Modules/timemodule.c to put the bug back: % hg cat -r 97393 Modules/timemodule.c > Modules/timemodule.c 4) I changed line 611 (or so) from "#if defined(MS_WINDOWS) && !defined(HAVE_WCSFTIME)" to "#if 1" so I'd get the code that had the bug. 5) I ran "./configure --with-valgrind && make" to make it. 6) I ran "valgrind ./python -m test test_time" and ***Valgrind complained about an array overrun***. 7) I restored the bugfix to Modules/timemodule.c, then reinstated the change from 4) above. 8) I ran make and valgrind again and didn't get the complaint about the array overrun. For grins I also tried enabling the other stanza of code that has the bug (the AIX / sun / have_wcsftime) and observed the same thing. Is that convincing? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 05:36:33 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 07 Sep 2015 03:36:33 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441596993.6.0.378067021567.issue24917@psf.upfronthosting.co.za> Steve Dower added the comment: Good enough for me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 05:55:27 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 Sep 2015 03:55:27 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441598127.31.0.00636935525888.issue23517@psf.upfronthosting.co.za> Larry Hastings added the comment: So is this considered broken enough that I need to accept a fix for 3.5.0? And has a consensus been reached about exactly what that fix would be? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 05:56:03 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 Sep 2015 03:56:03 +0000 Subject: [issue22970] asyncio: Cancelling wait() after notification leaves Condition in an inconsistent state In-Reply-To: <1417404582.01.0.276361050449.issue22970@psf.upfronthosting.co.za> Message-ID: <1441598163.15.0.645768730776.issue22970@psf.upfronthosting.co.za> Larry Hastings added the comment: Reassigning to 3.6. ---------- priority: deferred blocker -> release blocker versions: +Python 3.6 -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 05:56:37 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 Sep 2015 03:56:37 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1417530925.56.0.55888060474.issue22980@psf.upfronthosting.co.za> Message-ID: <1441598197.16.0.493870424139.issue22980@psf.upfronthosting.co.za> Larry Hastings added the comment: I'm leaving this open just because we're apparently waiting on some "What's New" docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 05:57:24 2015 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Sep 2015 03:57:24 +0000 Subject: [issue22970] asyncio: Cancelling wait() after notification leaves Condition in an inconsistent state In-Reply-To: <1417404582.01.0.276361050449.issue22970@psf.upfronthosting.co.za> Message-ID: <1441598244.2.0.824595331678.issue22970@psf.upfronthosting.co.za> Guido van Rossum added the comment: (It could be fixed in 3.5.1, since asyncio is still provisional in 3.5.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 06:06:10 2015 From: report at bugs.python.org (Tim Peters) Date: Mon, 07 Sep 2015 04:06:10 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441598770.2.0.0481717679568.issue23517@psf.upfronthosting.co.za> Tim Peters added the comment: Universal consensus on ROUND_HALF_EVEN, yes. I would like to see it repaired for 3.5.0, but that's just me saying so without offering to do a single damned thing to make it happen ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 06:07:38 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 Sep 2015 04:07:38 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441598858.24.0.712590597867.issue23517@psf.upfronthosting.co.za> Larry Hastings added the comment: Well, I'm already holding up rc3 on one other issue, might as well fix this too. Can somebody make me a pull request? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 06:08:05 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 Sep 2015 04:08:05 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441598885.89.0.992013443478.issue23517@psf.upfronthosting.co.za> Larry Hastings added the comment: I suspect we're not fixing this in 3.4, so I'm removing 3.4 from the version list. ---------- versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 06:16:18 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 07 Sep 2015 04:16:18 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows In-Reply-To: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> Message-ID: <1441599378.56.0.174124355402.issue25005@psf.upfronthosting.co.za> Steve Dower added the comment: subprocess with shell=True turns it into a "cmd.exe /C "start chrome.exe ..."" type command, which means the arguments will use shell parsing (e.g. > for redirection, & for multiple commands, etc.) "start" in cmd.exe behaves the same as os.startfile, but can also accept arguments. Patch 1 lets startfile accept arguments, so we don't have to go via cmd.exe to launch the browser (we're still resolving it via the shell, so the behaviour is the same, but the arguments are never interpreted using shell rules). All the functionality of #8232 is still there and still works. Patch 2 is a rollback of #8232, so we ship the same functionality as in Python 3.4. Because this only supports the default browser and does not support selecting between new tab/window, it can go back to using os.startfile without arguments. A third option would be to find some other way to discover the full path to each browser and launch it without using start/os.startfile. (This is what I was thinking originally when I said it would be too big a change.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 06:18:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Sep 2015 04:18:00 +0000 Subject: [issue23406] interning and list comprehension leads to unexpected behavior In-Reply-To: <1423313726.28.0.32804996181.issue23406@psf.upfronthosting.co.za> Message-ID: <20150907041757.11268.55690@psf.io> Roundup Robot added the comment: New changeset 2640a4630e9e by Martin Panter in branch '3.5': Issue #23406: Remove specific line number from susp-ignored.csv https://hg.python.org/cpython/rev/2640a4630e9e New changeset 48f1e9a47301 by Martin Panter in branch 'default': Issue #23406: Merge 3.5 into 3.6 https://hg.python.org/cpython/rev/48f1e9a47301 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 06:18:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Sep 2015 04:18:00 +0000 Subject: [issue25004] test_mmap should catch f.close() failure in LargeMmapTests._make_test_file() In-Reply-To: <1441404381.95.0.01039017408.issue25004@psf.upfronthosting.co.za> Message-ID: <20150907041757.11268.38955@psf.io> Roundup Robot added the comment: New changeset 7a9dddc11f2e by Martin Panter in branch '3.4': Issue #25004: Handle out-of-disk-space error in LargeMmapTests https://hg.python.org/cpython/rev/7a9dddc11f2e New changeset fd4bf05b32ba by Martin Panter in branch '3.5': Issue #25004: Merge 3.4 into 3.5 https://hg.python.org/cpython/rev/fd4bf05b32ba New changeset 6c9159661aa8 by Martin Panter in branch 'default': Issue #25004: Merge 3.5 into 3.6 https://hg.python.org/cpython/rev/6c9159661aa8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 06:19:54 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 07 Sep 2015 04:19:54 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows In-Reply-To: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> Message-ID: <1441599594.32.0.53531544379.issue25005@psf.upfronthosting.co.za> Steve Dower added the comment: To be more specific, with patch 1 applied: subprocess.call("start file a&b>x", shell=True) is equivalent to typing the following at a command prompt: start file a & b > x That is, "start file a" and then do "b", redirecting the output from "b" to a file named "x". With the change to os.startfile, we can write it as this: os.startfile("file", "open", "a&b>x") Which matches what we intended above. (startfile implies "start ", and passes the third argument to the launched program without modification.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 06:21:06 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 07 Sep 2015 04:21:06 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows In-Reply-To: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> Message-ID: <1441599666.5.0.321241602924.issue25005@psf.upfronthosting.co.za> Steve Dower added the comment: Oh, and the "start" is necessary because, while the Windows kernel can only resolve "chrome.exe" if it appears on PATH, the Windows shell has some other ways to resolve it. By using ShellExecute (via 'start' or startfile), we can let the OS find it rather than having to find it ourselves. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 06:26:28 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 Sep 2015 04:26:28 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows In-Reply-To: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> Message-ID: <1441599988.67.0.879768943968.issue25005@psf.upfronthosting.co.za> Larry Hastings added the comment: So, whatever the security hole is that subprocess.call(shell=True) leaves open, os.startfile() doesn't have? os.startfile() doesn't use a shell? (How does it find the full path to the executable?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 06:27:40 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 07 Sep 2015 04:27:40 +0000 Subject: [issue25004] test_mmap should catch f.close() failure in LargeMmapTests._make_test_file() In-Reply-To: <1441404381.95.0.01039017408.issue25004@psf.upfronthosting.co.za> Message-ID: <1441600060.99.0.532842397574.issue25004@psf.upfronthosting.co.za> Martin Panter added the comment: Okay I was able to force the error by using all my disk space up, and confirmed the change works. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 06:42:29 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 07 Sep 2015 04:42:29 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows In-Reply-To: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> Message-ID: <1441600949.88.0.575598861977.issue25005@psf.upfronthosting.co.za> Steve Dower added the comment: Correct. os.startfile uses ShellExecute (https://msdn.microsoft.com/en-us/library/windows/desktop/bb762153.aspx), which is the same API that the shell uses for the 'start' command. So by using os.startfile we get the same behaviour, but we're calling in after the terminal would have done its own parsing (for piping/redirection/etc.). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 06:45:18 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 Sep 2015 04:45:18 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows In-Reply-To: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> Message-ID: <1441601118.2.0.45874520361.issue25005@psf.upfronthosting.co.za> Larry Hastings added the comment: Well, so, what do you recommend I do here? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 06:53:32 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 07 Sep 2015 04:53:32 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows In-Reply-To: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> Message-ID: <1441601612.36.0.29002343073.issue25005@psf.upfronthosting.co.za> Steve Dower added the comment: Rollback. I'm not 100% confident in patch 1 (too many things I can't predict) and with only a week it probably won't get enough testing to flush out other surprises. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 06:56:33 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 07 Sep 2015 04:56:33 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows In-Reply-To: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> Message-ID: <1441601793.05.0.588085589006.issue25005@psf.upfronthosting.co.za> Steve Dower added the comment: I guess now I've been that definitive I'll go make you a PR :) If someone (perhaps Brandon?) is willing to thoroughly validate patch 1 we might be able to consider it for 3.5.1 (the only API change is to startfile() - the webbrowser API is already there, it just doesn't report much). Otherwise, it'll have to be 3.6. (But will it get any more tested there? Not so sure...) ---------- nosy: +jbmilam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 07:03:34 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 07 Sep 2015 05:03:34 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows In-Reply-To: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> Message-ID: <1441602214.08.0.165754593085.issue25005@psf.upfronthosting.co.za> Steve Dower added the comment: PR is: https://bitbucket.org/larry/cpython350/pull-requests/20/issue-25005-backout-fix-for-8232-because/diff ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 07:12:00 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 Sep 2015 05:12:00 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441602720.34.0.268973931876.issue24917@psf.upfronthosting.co.za> Larry Hastings added the comment: Backout pull request merged, please forward-merge, thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 07:12:21 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 Sep 2015 05:12:21 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows In-Reply-To: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> Message-ID: <1441602741.0.0.185215843977.issue25005@psf.upfronthosting.co.za> Larry Hastings added the comment: Backout pull request merged, please forward-merge, thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 07:13:10 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 Sep 2015 05:13:10 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441602790.61.0.294437345196.issue24917@psf.upfronthosting.co.za> Larry Hastings added the comment: (I meant, just normal pull request. I did your two pull requests right in a row and got my wires crossed.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 07:28:56 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 07 Sep 2015 05:28:56 +0000 Subject: [issue25013] run_pdb() in test_pdb.py always returns stderr as None In-Reply-To: <1441535803.94.0.131993266269.issue25013@psf.upfronthosting.co.za> Message-ID: <1441603736.5.0.0789606917325.issue25013@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Xavier, thanks for the idea. It seems sensible and I considered applying this, but since this is an internal pdb test design change rather than a pdb bug fix, and two other tests seem candidates for the same change, I am going to leave it to Gerog or someone else to review. I do not understand the details of run_pdb, the reason why some tests use it and other inline a subprocess call, or why they all mix together stdout and stderr. ---------- components: +Tests nosy: +georg.brandl stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 07:33:26 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 Sep 2015 05:33:26 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441604006.5.0.0635078686781.issue23517@psf.upfronthosting.co.za> Larry Hastings added the comment: Okay, this is literally the only thing rc3 is waiting on now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 07:34:07 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 Sep 2015 05:34:07 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441604047.3.0.734686042922.issue24917@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 07:34:44 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 Sep 2015 05:34:44 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows In-Reply-To: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> Message-ID: <1441604084.38.0.354534786814.issue25005@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 07:36:25 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 Sep 2015 05:36:25 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1441604185.65.0.179201148365.issue8232@psf.upfronthosting.co.za> Larry Hastings added the comment: This was backed out of 3.5, as we discovered it introduced a security hole just before 3.5.0 shipped. (See issue 25005 for more.) Since it's been backed out, I've reopened the issue. However I've moved it forward to 3.6, as it's no longer viable to accept for 3.5. ---------- resolution: fixed -> stage: resolved -> needs patch status: closed -> open versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 07:36:44 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 Sep 2015 05:36:44 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1441604204.02.0.770115523281.issue8232@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- nosy: -larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 07:38:03 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Sep 2015 05:38:03 +0000 Subject: [issue24748] Change of behavior for importlib between 3.4 and 3.5 with DLL loading In-Reply-To: <1438176027.56.0.467476097176.issue24748@psf.upfronthosting.co.za> Message-ID: <20150907053800.11254.8753@psf.io> Roundup Robot added the comment: New changeset 087464c9f982 by Nick Coghlan in branch '3.5': Close #24748: Restore imp.load_dynamic compatibility https://hg.python.org/cpython/rev/087464c9f982 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 07:38:03 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Sep 2015 05:38:03 +0000 Subject: [issue24305] The new import system makes it inconvenient to correctly issue a deprecation warning for a module In-Reply-To: <1432769809.77.0.211799866082.issue24305@psf.upfronthosting.co.za> Message-ID: <20150907053800.11254.7886@psf.io> Roundup Robot added the comment: New changeset 94966dfd3bd3 by Larry Hastings in branch '3.5': Issue #24305: Prevent import subsystem stack frames from being counted https://hg.python.org/cpython/rev/94966dfd3bd3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 07:38:04 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Sep 2015 05:38:04 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <20150907053800.11254.30139@psf.io> Roundup Robot added the comment: New changeset c31dad22c80d by Steve Dower in branch '3.5': Issue #24917: time_strftime() buffer over-read. https://hg.python.org/cpython/rev/c31dad22c80d New changeset f185917498ca by Steve Dower in branch '3.4': Issue #24917: time_strftime() buffer over-read. https://hg.python.org/cpython/rev/f185917498ca ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 07:38:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Sep 2015 05:38:05 +0000 Subject: [issue25005] webbrowser breaks on query strings with multiple fields on Windows In-Reply-To: <1441408149.94.0.43004072786.issue25005@psf.upfronthosting.co.za> Message-ID: <20150907053800.11254.74130@psf.io> Roundup Robot added the comment: New changeset aa60b34d5200 by Steve Dower in branch '3.5': Issue #25005: Backout fix for #8232 because of use of unsafe subprocess.call(shell=True) https://hg.python.org/cpython/rev/aa60b34d5200 New changeset 7d320c3bf9c6 by Larry Hastings in branch '3.5': Merged in stevedower/cpython350 (pull request #20) https://hg.python.org/cpython/rev/7d320c3bf9c6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 07:38:06 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Sep 2015 05:38:06 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <20150907053800.11254.12685@psf.io> Roundup Robot added the comment: New changeset aa60b34d5200 by Steve Dower in branch '3.5': Issue #25005: Backout fix for #8232 because of use of unsafe subprocess.call(shell=True) https://hg.python.org/cpython/rev/aa60b34d5200 New changeset 7d320c3bf9c6 by Larry Hastings in branch '3.5': Merged in stevedower/cpython350 (pull request #20) https://hg.python.org/cpython/rev/7d320c3bf9c6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 07:40:46 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 07 Sep 2015 05:40:46 +0000 Subject: [issue25015] Idle: scroll Text faster with mouse wheel In-Reply-To: <1441566965.71.0.33630989907.issue25015@psf.upfronthosting.co.za> Message-ID: <1441604446.75.0.258270247101.issue25015@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The SO OP reported Idle Shell and Editor behavior. I retested minimal tk.Text(root).pack(), eliminating Idle as a factor, before and after changing system lines setting from 3 to 9, and got the constant same behavior. The now too small 50 pixels seems about what it is doing. Serhiy, I do not understand your 'Run ...' sentence. ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 07:49:54 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 07 Sep 2015 05:49:54 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1441604994.88.0.396817085759.issue8232@psf.upfronthosting.co.za> Steve Dower added the comment: Here's an alternate patch I proposed on #25005 before we decided to back out the change. The problem is that subprocess.call() with shell=True is unsafe because we don't escape shell operators (such as &, <, >, |). The fix in this patch is to allow passing arguments to os.startfile so we can use that instead. Arguments do not need to be escaped in this case. ---------- Added file: http://bugs.python.org/file40384/25005_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 07:57:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Sep 2015 05:57:17 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1441604006.5.0.0635078686781.issue23517@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I understand that I have to implement a new rounding mode. The code will be new, I'm not condifent enough to push it immedialty into python 3.5. IMHO a buggy rounding mode is worse than keeping the current rounding mode. The rounding mode changed in python 3.3. There is no urgency to fix it. I will change python 3.6, then 3.4 and 3.5.1. Le 7 sept. 2015 07:33, "Larry Hastings" a ?crit : > > Larry Hastings added the comment: > > Okay, this is literally the only thing rc3 is waiting on now. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 07:59:42 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Sep 2015 05:59:42 +0000 Subject: [issue24889] Idle: always start with focus In-Reply-To: <1439928191.61.0.630343371617.issue24889@psf.upfronthosting.co.za> Message-ID: <20150907055940.14859.19881@psf.io> Roundup Robot added the comment: New changeset 741b033c5290 by Terry Jan Reedy in branch '2.7': Issue #24889: When starting Idle, force focus onto Idle window if not already https://hg.python.org/cpython/rev/741b033c5290 New changeset d7449bac2c6d by Terry Jan Reedy in branch '3.4': Issue #24889: When starting Idle, force focus onto Idle window if not already https://hg.python.org/cpython/rev/d7449bac2c6d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 08:02:24 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 07 Sep 2015 06:02:24 +0000 Subject: [issue24889] Idle: always start with focus In-Reply-To: <1439928191.61.0.630343371617.issue24889@psf.upfronthosting.co.za> Message-ID: <1441605744.6.0.128233893934.issue24889@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thanks for the research and verification that this is harmless. It has been a daily annoyance. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 08:04:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Sep 2015 06:04:48 +0000 Subject: [issue25015] Idle: scroll Text faster with mouse wheel In-Reply-To: <1441566965.71.0.33630989907.issue25015@psf.upfronthosting.co.za> Message-ID: <1441605888.07.0.215511565952.issue25015@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You can measure your mouse speed with following pure Tcl/Tk script. ---------- Added file: http://bugs.python.org/file40385/MouseWheelTrace.tcl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 08:05:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Sep 2015 06:05:26 +0000 Subject: [issue25015] Idle: scroll Text faster with mouse wheel In-Reply-To: <1441566965.71.0.33630989907.issue25015@psf.upfronthosting.co.za> Message-ID: <1441605925.99.0.989497485859.issue25015@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Or with following Python script. ---------- Added file: http://bugs.python.org/file40386/MouseWheelTrace.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 08:27:26 2015 From: report at bugs.python.org (Chase Albert) Date: Mon, 07 Sep 2015 06:27:26 +0000 Subject: [issue25016] defaultdict's pop gives a KeyError Message-ID: <1441607246.41.0.522388405407.issue25016@psf.upfronthosting.co.za> New submission from Chase Albert: `defaultdict(list).pop(1)` raises a KeyError, this is not what I expected (I expected an empty list). ---------- components: Library (Lib) messages: 250080 nosy: rob.anyone priority: normal severity: normal status: open title: defaultdict's pop gives a KeyError type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 08:37:47 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 07 Sep 2015 06:37:47 +0000 Subject: [issue25016] defaultdict's pop gives a KeyError In-Reply-To: <1441607246.41.0.522388405407.issue25016@psf.upfronthosting.co.za> Message-ID: <1441607867.56.0.771806179174.issue25016@psf.upfronthosting.co.za> Martin Panter added the comment: I think this is by design. Under it says ?__missing__() is _not_ called for any operations besides __getitem__().? What gave you the impression that pop() should return a default value? ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 08:46:39 2015 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 07 Sep 2015 06:46:39 +0000 Subject: [issue24748] Change of behavior for importlib between 3.4 and 3.5 with DLL loading In-Reply-To: <1438176027.56.0.467476097176.issue24748@psf.upfronthosting.co.za> Message-ID: <1441608399.04.0.00380887673341.issue24748@psf.upfronthosting.co.za> Nick Coghlan added the comment: Just noting explicitly that this has been forward merged to the default branch by Steve Dower after Larry merged in the latest 3.5.0 rc changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 08:49:25 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 Sep 2015 06:49:25 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441608565.94.0.524778059761.issue23517@psf.upfronthosting.co.za> Larry Hastings added the comment: Is it appropriate to make this change as a "bug fix", in already-released versions of Python? Would you be happy or sad if you updated your Python from 3.x.y to 3.x.y+1 and the rounding method used when converting floats to datetime stamps changed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 08:56:09 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 07 Sep 2015 06:56:09 +0000 Subject: [issue24813] Idle Help dialogs shouldn't be modal In-Reply-To: <1438921182.01.0.453311500566.issue24813@psf.upfronthosting.co.za> Message-ID: <1441608969.59.0.507943875402.issue24813@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Or we can broaden this in the other direction, to redesign AboutDialog. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 09:12:40 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 07 Sep 2015 07:12:40 +0000 Subject: [issue24964] Add tunnel CONNECT response headers to httplib / http.client In-Reply-To: <1440956510.2.0.613573748355.issue24964@psf.upfronthosting.co.za> Message-ID: <1441609960.77.0.283577358003.issue24964@psf.upfronthosting.co.za> Martin Panter added the comment: 1) The real problem is when _tunnel() internally calls getresponse(), it notices the connection cannot be reused for another request, and closes the socket object. Perhaps I should rethink my logic; maybe move sock and detach() to HTTPResponse. 2) With some rough experimentation, passing tunnel through the HTTPConnection (plain text HTTP) constructor seems to work for me. However if you meant HTTPSConnection (over TLS) instead, you will probably need to manually do the wrap_socket() step. Maybe that?s why your connection is being dropped. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 10:36:45 2015 From: report at bugs.python.org (Ivan Levkivskyi) Date: Mon, 07 Sep 2015 08:36:45 +0000 Subject: [issue24272] PEP 484 docs In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za> Message-ID: <1441615005.92.0.528456714072.issue24272@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Guido, are you going to commit our patches before 3.5.final? Is there a merge conflict now? Should I rebase my diff? If necessary I could make a clean patch combining two patches (my and Daniel's) on top of what Zachary did. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 10:57:33 2015 From: report at bugs.python.org (Petr Viktorin) Date: Mon, 07 Sep 2015 08:57:33 +0000 Subject: [issue24951] Idle test_configdialog fails on Fedora 23, 3.6 In-Reply-To: <1440744246.57.0.722923206189.issue24951@psf.upfronthosting.co.za> Message-ID: <1441616253.01.0.356208005908.issue24951@psf.upfronthosting.co.za> Petr Viktorin added the comment: Sorry for the delay; I lost the mail notification. I don't have a config-main.cfg file. The last output from the test, with the print added: test_dialog (idlelib.idle_test.test_configdialog.ConfigDialogTest) ... ('.139655680391704', 'configure', '-borderwidth', 5) ('.139655680391704.139655680370912.139655680371640.139655680370184.139655676916736.139655676917048.139655676917672', 'configure', '-command', '139655677350312yview') ('.139655680391704.139655680370912.139655680371640.139655680370184.139655676916736.139655676917048.139655676917360', 'configure', '-yscrollcommand', '139655677341608set') ('.139655680391704.139655680370912.139655680371640.139655680370184.139655676916736.139655676917152.139655676918296', 'configure', '-menu', ) ('.139655680391704.139655680370912.139655680371640.139655680370184.139655676916736.139655676917152.139655676918296', 'configure') ('.139655680391704.139655680370912.139655680371640.139655680345608.139655676932496.139655676932704', 'configure', '-state', 'disabled') ('.139655680391704.139655680370912.139655680371640.139655680345608.139655676932496.139655677333032.139655677332408', 'configure', '-menu', ) ('.139655680391704.139655680370912.139655680371640.139655680345608.139655676932496.139655677333032.139655677332408', 'configure', '-highlightthickness', 0) ('.139655680391704.139655680370912.139655680371640.139655680345608.139655676932600.139655676935200', 'configure', '-menu', ) ('.139655680391704.139655680370912.139655680371640.139655680345608.139655676932600.139655676935200', 'configure') ('.139655680391704.139655680370912.139655680371640.139655680345608.139655676932600.139655676935616', 'configure', '-menu', ) ('.139655680391704.139655680370912.139655680371640.139655680345608.139655676932600.139655676935616', 'configure') ('.139655680391704.139655680370912.139655680371640.139655680789328.139655676961480.139655676961688.139655676961896', 'configure', '-command', '139655676968648yview') ('.139655680391704.139655680370912.139655680371640.139655680789328.139655676961480.139655676961688.139655676962000', 'configure', '-command', '139655676973368xview') ('.139655680391704.139655680370912.139655680371640.139655680789328.139655676961480.139655676961688.139655676962104', 'configure', '-yscrollcommand', '139655676973928set') ('.139655680391704.139655680370912.139655680371640.139655680789328.139655676961480.139655676961688.139655676962104', 'configure', '-xscrollcommand', '139655676974600set') ('.139655680391704.139655680370912.139655680371640.139655680789328.139655676961584.139655676963352.139655676963976', 'configure', '-menu', ) ('.139655680391704.139655680370912.139655680371640.139655680789328.139655676961584.139655676963352.139655676963976', 'configure') ('.139655680391704.139655680370912.139655680371640.139655680789328.139655676961584.139655676963352.139655676964392', 'configure', '-menu', ) ('.139655680391704.139655680370912.139655680371640.139655680789328.139655676961584.139655676963352.139655676964392', 'configure') ('.139655680391704.139655680370912.139655680371640.139655677346192.139655676990984.139655676992648.139655676992856', 'configure', '-command', '139655676998504yview') ('.139655680391704.139655680370912.139655680371640.139655677346192.139655676990984.139655676992648.139655676992960', 'configure', '-yscrollcommand', '139655677003496set') ('.139655680391704.139655680370912.139655680371640.139655680370184.139655676916736.139655676918920.139655676919024', 'configure', '-font', '{dejavu sans mono} {} normal') ERROR ====================================================================== ERROR: test_dialog (idlelib.idle_test.test_configdialog.ConfigDialogTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/pviktori/dev/cpython/Lib/idlelib/idle_test/test_configdialog.py", line 27, in test_dialog d=ConfigDialog(self.root, 'Test', _utest=True) File "/home/pviktori/dev/cpython/Lib/idlelib/configDialog.py", line 71, in __init__ self.LoadConfigs() File "/home/pviktori/dev/cpython/Lib/idlelib/configDialog.py", line 1078, in LoadConfigs self.LoadFontCfg() File "/home/pviktori/dev/cpython/Lib/idlelib/configDialog.py", line 980, in LoadFontCfg self.SetFontSample() File "/home/pviktori/dev/cpython/Lib/idlelib/configDialog.py", line 858, in SetFontSample self.labelFontSample.config(font=newFont) File "/home/pviktori/dev/cpython/Lib/tkinter/__init__.py", line 1331, in configure return self._configure('configure', cnf, kw) File "/home/pviktori/dev/cpython/Lib/tkinter/__init__.py", line 1322, in _configure self.tk.call(_flatten((self._w, cmd)) + self._options(cnf)) _tkinter.TclError: expected integer but got "" ---------------------------------------------------------------------- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 11:01:37 2015 From: report at bugs.python.org (Thomas Guettler) Date: Mon, 07 Sep 2015 09:01:37 +0000 Subject: [issue25017] htmllib deprecated: Which library to use? Missing sane default in docs Message-ID: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za> New submission from Thomas Guettler: At the top of the htmllib module: > Deprecated since version 2.6: The htmllib module has been removed in > Python 3. Source: https://docs.python.org/2/library/htmllib.html#module-htmllib Newcomers need more advice: Which library should be used? I know there are many html parsing libraries. But there should be a sane default for newcomers. Is there already an agreement of a sane default html parsing library? ---------- assignee: docs at python components: Documentation messages: 250088 nosy: docs at python, guettli priority: normal severity: normal status: open title: htmllib deprecated: Which library to use? Missing sane default in docs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 11:05:42 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Sep 2015 09:05:42 +0000 Subject: [issue25018] test_shutil.test_make_archive() fails on Windows Message-ID: <1441616742.69.0.0154007377208.issue25018@psf.upfronthosting.co.za> New submission from STINNER Victor: It looks like test_shutil fails since the changeset 4383ff47ffface248c8eabedf0f4c3bdab11f535: http://buildbot.python.org/all/builders/AMD64%20Windows8.1%20Non-Debug%203.x/builds/315/ ====================================================================== FAIL: test_make_tarball (test.test_shutil.TestShutil) ---------------------------------------------------------------------- Traceback (most recent call last): File "B:\buildarea\3.x.ware-win81-release\build\lib\test\test_shutil.py", line 987, in test_make_tarball self.assertTrue(os.path.isfile(tarball)) AssertionError: False is not true ---------- components: Tests messages: 250089 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: test_shutil.test_make_archive() fails on Windows versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 11:06:34 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Sep 2015 09:06:34 +0000 Subject: [issue25018] test_shutil.test_make_archive() fails on Windows 8.1 In-Reply-To: <1441616742.69.0.0154007377208.issue25018@psf.upfronthosting.co.za> Message-ID: <1441616794.14.0.500757062965.issue25018@psf.upfronthosting.co.za> STINNER Victor added the comment: The test pass on Windows 7 and Windows 10 buildbots. ---------- title: test_shutil.test_make_archive() fails on Windows -> test_shutil.test_make_archive() fails on Windows 8.1 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 11:19:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Sep 2015 09:19:17 +0000 Subject: [issue25018] test_shutil.test_make_archive() fails on Windows 8.1 In-Reply-To: <1441616742.69.0.0154007377208.issue25018@psf.upfronthosting.co.za> Message-ID: <1441617557.06.0.77242705876.issue25018@psf.upfronthosting.co.za> STINNER Victor added the comment: Strange, the bug is only on one buildbot. It pass on the Windows 8 buildbot: http://buildbot.python.org/all/builders/AMD64%20Windows8%203.x/builds/1249 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 11:50:08 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 07 Sep 2015 09:50:08 +0000 Subject: [issue25017] htmllib deprecated: Which library to use? Missing sane default in docs In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za> Message-ID: <1441619408.12.0.327367378565.issue25017@psf.upfronthosting.co.za> Martin Panter added the comment: PEP 3108 says ?Superseded by HTMLParser?. I presume this means Python 3?s ?html.parser? module (called ?HTMLParser? in Python 2). I guess a lot of work would be involved in changing existing code over, but it shouldn?t be much of a problem for someone writing new code. ---------- nosy: +martin.panter versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 12:11:04 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 07 Sep 2015 10:11:04 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1441620664.52.0.662325088647.issue24915@psf.upfronthosting.co.za> Alecsandru Patrascu added the comment: I've updated the patches with redirect to /dev/null, as is it is more clearer to the user what is our intent, without having him to necessarily read the regrtest documentation. I've also added a warning message regarding the output and ported all these lines to 3.6 and to the README files also. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 12:11:25 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 07 Sep 2015 10:11:25 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1441620685.95.0.727869746802.issue24915@psf.upfronthosting.co.za> Changes by Alecsandru Patrascu : Added file: http://bugs.python.org/file40387/python2.7-pgo-v07.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 12:11:32 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 07 Sep 2015 10:11:32 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1441620692.91.0.473251956654.issue24915@psf.upfronthosting.co.za> Changes by Alecsandru Patrascu : Added file: http://bugs.python.org/file40388/python3.6-pgo-v07.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 12:11:48 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 07 Sep 2015 10:11:48 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1441620708.44.0.223116333352.issue24915@psf.upfronthosting.co.za> Changes by Alecsandru Patrascu : Added file: http://bugs.python.org/file40389/README2.7-pgo-v02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 12:11:55 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 07 Sep 2015 10:11:55 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1441620715.56.0.43268076496.issue24915@psf.upfronthosting.co.za> Changes by Alecsandru Patrascu : Added file: http://bugs.python.org/file40390/README3.6-pgo-v02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 12:15:05 2015 From: report at bugs.python.org (Andre Merzky) Date: Mon, 07 Sep 2015 10:15:05 +0000 Subject: [issue24862] subprocess.Popen behaves incorrect when moved in process tree In-Reply-To: <1439520939.88.0.252356845124.issue24862@psf.upfronthosting.co.za> Message-ID: <1441620905.63.0.510109400903.issue24862@psf.upfronthosting.co.za> Andre Merzky added the comment: Hi again, can I do anything to help moving this forward? Thanks, Andre. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 12:39:49 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 07 Sep 2015 10:39:49 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1441622389.34.0.0282898537872.issue24915@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Please don't call it "PROFILE_TASK_X86" - the architecture should have nothing to do with it. Actually, there shouldn't be any architecture-specific check at all. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 12:41:12 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 07 Sep 2015 10:41:12 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1441622472.8.0.502580679526.issue24915@psf.upfronthosting.co.za> Antoine Pitrou added the comment: As for the dual 2.7/3.6 aspect: I don't really understand it. If this is committed to 2.7 it should also be committed to 3.5. It doesn't threaten the stability of the interpreter in any way, given it does not affect the default build path. There's no reason why packagers of Python 3.5 should have to separately maintain a patch to have access to this improvement. ---------- nosy: +larry versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 12:58:41 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Sep 2015 10:58:41 +0000 Subject: [issue25018] test_shutil.test_make_archive() fails on Windows 8.1 In-Reply-To: <1441616742.69.0.0154007377208.issue25018@psf.upfronthosting.co.za> Message-ID: <20150907105838.68857.55404@psf.io> Roundup Robot added the comment: New changeset 7bd6b8076c48 by Serhiy Storchaka in branch '3.4': Explicitly test archive name in shutil.make_archive() tests to expose failure https://hg.python.org/cpython/rev/7bd6b8076c48 New changeset beda04bf5991 by Serhiy Storchaka in branch '2.7': Explicitly test archive name in shutil.make_archive() tests to expose failure https://hg.python.org/cpython/rev/beda04bf5991 New changeset f842c2b710ed by Serhiy Storchaka in branch '3.5': Explicitly test archive name in shutil.make_archive() tests to expose failure https://hg.python.org/cpython/rev/f842c2b710ed New changeset 738e227d0891 by Serhiy Storchaka in branch 'default': Explicitly test archive name in shutil.make_archive() tests to expose failure https://hg.python.org/cpython/rev/738e227d0891 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 13:00:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Sep 2015 11:00:07 +0000 Subject: [issue25018] test_shutil.test_make_archive() fails on Windows 8.1 In-Reply-To: <1441616742.69.0.0154007377208.issue25018@psf.upfronthosting.co.za> Message-ID: <1441623607.77.0.554764517809.issue25018@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is a consequence of 9774088c8ff7. I don't know why the test fails. Added explicit checks for archive name. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 13:21:53 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 07 Sep 2015 11:21:53 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1441624913.49.0.0123601442565.issue24915@psf.upfronthosting.co.za> Alecsandru Patrascu added the comment: I named this task PROFILE_TASK_X86 because it is rigorously tested and we have proven that regrtest performs better on this architecture. Until any other clear evidence and solid measurements that regrtest is performing better on other architectures exists, I'd keep it this way. Even though this does not threaten the stability of the interpreter in any way, the dual aspect you mentioned appears because CPython 2 and 3 have slightly different makefile rule format. To create a common patch working cross-versions will create a very tangled Makefile. If you all agree that having an unified patch for both versions is acceptable, I will work on that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 13:36:29 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 07 Sep 2015 11:36:29 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1441625789.69.0.803522165553.issue24915@psf.upfronthosting.co.za> Stefan Krah added the comment: I don't think we should provide any performance guarantees in the Makefile. +1 for not special-casing x86 (does it include amd64?). As I understood, Antoine was not talking about a unified patch but about applying the 3.6 patch to 3.5 right away. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 14:04:13 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 Sep 2015 12:04:13 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441627453.01.0.977113982765.issue23517@psf.upfronthosting.co.za> Larry Hastings added the comment: Well, for now I assume it really truly genuinely isn't going in 3.5.0. I suppose we can debate about 3.4.x and 3.5.1 later, once we have a fix everybody is happy with. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 14:15:00 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 07 Sep 2015 12:15:00 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1441628100.93.0.721140773283.issue24915@psf.upfronthosting.co.za> Changes by Alecsandru Patrascu : Removed file: http://bugs.python.org/file40387/python2.7-pgo-v07.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 14:15:12 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 07 Sep 2015 12:15:12 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1441628111.98.0.228982108679.issue24915@psf.upfronthosting.co.za> Changes by Alecsandru Patrascu : Removed file: http://bugs.python.org/file40388/python3.6-pgo-v07.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 14:15:28 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 07 Sep 2015 12:15:28 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1441628128.87.0.207219150102.issue24915@psf.upfronthosting.co.za> Changes by Alecsandru Patrascu : Added file: http://bugs.python.org/file40391/python2.7-pgo-v07.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 14:15:35 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 07 Sep 2015 12:15:35 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1441628135.04.0.0751786924324.issue24915@psf.upfronthosting.co.za> Changes by Alecsandru Patrascu : Added file: http://bugs.python.org/file40392/python3.6-pgo-v07.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 14:17:00 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 07 Sep 2015 12:17:00 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1441628220.12.0.773412918834.issue24915@psf.upfronthosting.co.za> Alecsandru Patrascu added the comment: If you are talking just about the 3.6 patch, it is called this way to emphasize the fact that it is intended for the development branch. It is perfectly compatible with 3.5, therefore it is not needed for packagers to maintain two distinct versions. I've tested with: hg update 3.5 ; hg import --no-commit python3.6-pgo-v07.patch ; ./configure ; make profile-opt I also renamed the profile task makefile name. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 14:26:40 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 07 Sep 2015 12:26:40 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441628800.31.0.765045460046.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Larry> Well, for now I assume it really truly genuinely isn't going in 3.5.0. This is an unfortunate outcome. Larry> I suppose we can debate about 3.4.x and 3.5.1 later It is even more unfortunate that the question of whether this regression is a bug or not is up for debate again. Victor> The code will be new, I'm not condifent enough to push it immedialty into python 3.5. I don't understand why any new code is needed to fix a regression. All you need to do is to revert a few chunks of 1e9cc1a03365 where the regression was introduced. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 14:38:39 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 Sep 2015 12:38:39 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441629519.72.0.126433935284.issue23517@psf.upfronthosting.co.za> Larry Hastings added the comment: If the guy doing the work says "don't merge it in 3.5.0", and we're at the final release candidate before 3.5.0 final ships, and we don't even have a patch that everyone likes yet... it does seem like it's not going to happen for 3.5.0. Unfortunate perhaps but that's the situation we're in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 14:42:18 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 07 Sep 2015 12:42:18 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1441629738.27.0.532144037737.issue24915@psf.upfronthosting.co.za> Stefan Krah added the comment: Just (hopefully) for extra clarity: As you mentioned, the 3.6 patch is perfect for 3.5, too. The reason why 3.5 was brought up is to ask Larry, our release manager, to allow it already for 3.5. Technically it's an enhancement/new feature, but practically it is zero risk and for PR reassons we should probably not "make 2.7 faster" before 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 14:46:57 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 07 Sep 2015 12:46:57 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1441630017.62.0.196253896262.issue24999@psf.upfronthosting.co.za> Stefan Krah added the comment: The buildbot segfaults all over the place, also in test_tokenize and test_json: http://buildbot.python.org/all/builders/x86-64%20Windows%20Server%202012R2%20ICC%203.x/builds/89/steps/test/logs/stdio Running the tests under the VS debugger is probably the fastest way to find out why (I don't have the Intel compiler). ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 14:56:39 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Sep 2015 12:56:39 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441630599.78.0.0669517848521.issue23517@psf.upfronthosting.co.za> STINNER Victor added the comment: > All you need to do is to revert a few chunks of 1e9cc1a03365 where the regression was introduced. Hum, please don't revert this change. I spent a lot of days to write pytime.c/.h. My patches add more unit tests to datetime, to test the exact rounding mode. > Well, for now I assume it really truly genuinely isn't going in 3.5.0. I suppose we can debate about 3.4.x and 3.5.1 later, once we have a fix everybody is happy with. The rounding mode of microseconds only impact a very few people. The rounding mode changed in 3.3, again in 3.4 and again in 3.5. This issue is the first bug report. So I think it's fine to modify 3.4.x and 3.5.x. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 15:28:30 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 07 Sep 2015 13:28:30 +0000 Subject: [issue25018] test_shutil.test_make_archive() fails on Windows 8.1 In-Reply-To: <1441616742.69.0.0154007377208.issue25018@psf.upfronthosting.co.za> Message-ID: <1441632510.63.0.472623519521.issue25018@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 15:38:05 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 07 Sep 2015 13:38:05 +0000 Subject: [issue25014] Add contextlib.itercm() In-Reply-To: <1441542735.79.0.482816688867.issue25014@psf.upfronthosting.co.za> Message-ID: <1441633085.25.0.372053207873.issue25014@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 15:38:47 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 07 Sep 2015 13:38:47 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441633127.33.0.937029526786.issue23517@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Victor> please don't revert this change. I did not suggest reverting the entire commit. The change that affects fromdatetime() is just - us = round(frac * 1e6) + us = int(frac * 1e6) in datetime.py. It is probably more involved in _datetimemodule.c, but cannot be that bad. You can still keep pytime.c/.h. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 16:10:45 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 07 Sep 2015 14:10:45 +0000 Subject: [issue25002] Deprecate asyncore/asynchat In-Reply-To: <1441400141.7.0.255055461996.issue25002@psf.upfronthosting.co.za> Message-ID: <20150907101040.07a5de52@anarchist.wooz.org> Barry A. Warsaw added the comment: On Sep 04, 2015, at 08:55 PM, STINNER Victor wrote: >Maybe it can be fun to rewrite the module using asyncio, but I'm not >convinced that a SMTP server in the Python stdlib is super useful. As I mentioned in issue25008, removing smtpd would be a hardship for myself, and I don't think I'm alone. I would however love to have (and maybe even work on ) an asyncio-based version. I do think it is useful to have an SMTP server in the stdlib - and actually, I'd also like to have an LMTP server there too. But I think we can take baby steps toward this by some folks getting together and writing a third party asyncio-based module, releasing this on PyPI and eventually leading to its inclusion in Python down the road. I think there's no hurry to remove smtpd, but it can be deprecated-in-place like optparse, as someone else mentioned. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 16:26:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Sep 2015 14:26:49 +0000 Subject: [issue25008] Deprecate smtpd In-Reply-To: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za> Message-ID: <1441636009.73.0.626104363698.issue25008@psf.upfronthosting.co.za> STINNER Victor added the comment: Even if it may be possible to support asyncore/asynchat and asyncio at the same time, I would prefer to drop asyncore/asynchat support to simplify the code. The problem is that the API will be very different. asyncio has a different design. You don't instanciate a class to open a network connection, but you have to call "yield from loop.create_connection()" in a coroutine. We might provide helper blocking functions starting the server for us and then running the event loop until CTRL+c is pressed (or another event to stop to stop the loop). Rewriting smtpd with asyncio would allow to use it in an asyncio application. In 2015, I expect to see more and more applications using asyncio than asyncore/asynchat. Can we modify the issue title to "Rewrite smtpd with asyncio"? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 16:34:13 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Mon, 07 Sep 2015 14:34:13 +0000 Subject: [issue25008] Deprecate smtpd In-Reply-To: <1441636009.73.0.626104363698.issue25008@psf.upfronthosting.co.za> Message-ID: <20150907103410.3caf2037@anarchist.wooz.org> Barry A. Warsaw added the comment: On Sep 07, 2015, at 02:26 PM, STINNER Victor wrote: >Can we modify the issue title to "Rewrite smtpd with asyncio"? Sure, although I'm currently thinking it's best to go third party until the API and implementation settle down. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 16:44:23 2015 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 07 Sep 2015 14:44:23 +0000 Subject: [issue25008] Deprecate smtpd In-Reply-To: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za> Message-ID: <1441637063.48.0.728631546095.issue25008@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 17:00:32 2015 From: report at bugs.python.org (Brandon Milam) Date: Mon, 07 Sep 2015 15:00:32 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1441638032.75.0.312277322551.issue8232@psf.upfronthosting.co.za> Brandon Milam added the comment: applying 25005_1.patch patching file Lib/webbrowser.py Hunk #1 FAILED at 498 Hunk #2 FAILED at 524 Hunk #3 FAILED at 532 Hunk #4 FAILED at 540 Hunk #5 FAILED at 548 I'm trying to apply your patch after applying webbrowserfix6.patch but I am encountering problems. I first tried "hg import --no-commit file.patch" for both patches but it wouldn't let me use the command two times in a row without committing the changes for the first one so I tried committing the webbrowserfix6.patch changes and then using the import command and I get this error message. I would like to try to make sure the code still does what it is supposed to but I can't check until I can get both patches in. Hunk #6 FAILED at 556 6 out of 6 hunks FAILED -- saving rejects to file Lib/webbrowser.py.rej patching file Modules/posixmodule.c Hunk #1 FAILED at 10522 Hunk #2 FAILED at 10578 Hunk #3 FAILED at 10590 Hunk #4 FAILED at 10606 Hunk #5 FAILED at 10616 5 out of 5 hunks FAILED -- saving rejects to file Modules/posixmodule.c.rej abort: patch failed to apply ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 17:09:28 2015 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 07 Sep 2015 15:09:28 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441638568.2.0.485918479752.issue23517@psf.upfronthosting.co.za> Mark Dickinson added the comment: FWIW, count me as +1 on roundTiesToEven, mostly just for consistency. It's easier to remember that pretty much everything in Python 3 does round-ties-to-even (round function, string formatting, float literal evaluations, int-to-float conversion, Fraction-to-float conversion, ...) than to have to remember that there's a handful of corner cases where we do roundTiesToAway instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 17:38:15 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 07 Sep 2015 15:38:15 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1441640295.36.0.894227903534.issue8232@psf.upfronthosting.co.za> Steve Dower added the comment: Try doing: hg up -r 4e329892817c1eed81aafd14e82b8ef23b45a6e6 hg import --no-commit http://bugs.python.org/file40384/25005_1.patch That *should* apply it where I originally made it from. I'll do the same and rebase the patch against tip. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 17:40:12 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 07 Sep 2015 15:40:12 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1441640412.02.0.476384364755.issue8232@psf.upfronthosting.co.za> Steve Dower added the comment: New patch against 3.6. ---------- Added file: http://bugs.python.org/file40393/8232_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 17:56:02 2015 From: report at bugs.python.org (John Leitch) Date: Mon, 07 Sep 2015 15:56:02 +0000 Subject: [issue25019] xmlparse_setattro() Type Confusion Message-ID: <1441641362.28.0.731210993135.issue25019@psf.upfronthosting.co.za> New submission from John Leitch: Python 3.4 and 3.5 suffer from a vulnerability caused by the behavior of the xmlparse_setattro() function. When called, the function uses the provided name argument in several conditional statements which assume that the name argument is a string. However, if a name argument is provided that is not a string, this logic will make several calls to PyUnicode_CompareWithASCIIString that expect a string, yet receive some other type of object, leading to a type confusion vulnerability: static int xmlparse_setattro(xmlparseobject *self, PyObject *name, PyObject *v) { /* Set attribute 'name' to value 'v'. v==NULL means delete */ if (v == NULL) { PyErr_SetString(PyExc_RuntimeError, "Cannot delete attribute"); return -1; } assert(PyUnicode_Check(name)); if (PyUnicode_CompareWithASCIIString(name, "buffer_text") == 0) { [...] } In some applications, it may be possible to exploit this behavior to achieve arbitrary code execution. The type confusion can be observed by running the following script: from xml.parsers.expat import * p = ParserCreate() p.__setattr__(range(0xF), 0) Which, depending on the arrangement of memory, may produce an exception such as this: 0:000> g (d84.ce0): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=0086f904 ebx=0086f8fc ecx=0050005c edx=00b60138 esi=0050005e edi=00b60138 eip=61e9a967 esp=0086f8c8 ebp=0086f8e0 iopl=0 nv up ei ng nz na pe cy cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010287 python35!find_maxchar_surrogates+0x37: 61e9a967 0fb701 movzx eax,word ptr [ecx] ds:002b:0050005c=???? 0:000> k3 ChildEBP RetAddr 0086f8e0 61e9aa35 python35!find_maxchar_surrogates+0x37 [c:\build\cpython\objects\unicodeobject.c @ 1417] 0086f908 61eabcf3 python35!_PyUnicode_Ready+0x35 [c:\build\cpython\objects\unicodeobject.c @ 1466] 0086f918 61c547c3 python35!PyUnicode_CompareWithASCIIString+0x13 [c:\build\cpython\objects\unicodeobject.c @ 10784] To fix this issue, it is recommended that xmlparse_setattro() be updated to validate that the name argument is a string and return out of the function early if it is not. A proposed patch is attached. Credit: John Leitch (johnleitch at outlook.com), Bryce Darling (darlingbryce at gmail.com) ---------- components: XML files: xmlparse_setattro_Type_Confusion.py messages: 250116 nosy: JohnLeitch priority: normal severity: normal status: open title: xmlparse_setattro() Type Confusion type: security versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file40394/xmlparse_setattro_Type_Confusion.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 17:58:55 2015 From: report at bugs.python.org (John Leitch) Date: Mon, 07 Sep 2015 15:58:55 +0000 Subject: [issue25019] xmlparse_setattro() Type Confusion In-Reply-To: <1441641362.28.0.731210993135.issue25019@psf.upfronthosting.co.za> Message-ID: <1441641535.81.0.396155561559.issue25019@psf.upfronthosting.co.za> Changes by John Leitch : ---------- keywords: +patch Added file: http://bugs.python.org/file40395/xmlparse_setattro_Type_Confusion.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 18:02:32 2015 From: report at bugs.python.org (John Leitch) Date: Mon, 07 Sep 2015 16:02:32 +0000 Subject: [issue25019] xmlparse_setattro() Type Confusion In-Reply-To: <1441641362.28.0.731210993135.issue25019@psf.upfronthosting.co.za> Message-ID: <1441641752.67.0.351114652789.issue25019@psf.upfronthosting.co.za> Changes by John Leitch : ---------- nosy: +brycedarling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 18:02:58 2015 From: report at bugs.python.org (John Leitch) Date: Mon, 07 Sep 2015 16:02:58 +0000 Subject: [issue25019] xmlparse_setattro() Type Confusion In-Reply-To: <1441641362.28.0.731210993135.issue25019@psf.upfronthosting.co.za> Message-ID: <1441641778.18.0.119428071126.issue25019@psf.upfronthosting.co.za> Changes by John Leitch : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 18:57:40 2015 From: report at bugs.python.org (Brandon Milam) Date: Mon, 07 Sep 2015 16:57:40 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1441645060.41.0.172075335805.issue8232@psf.upfronthosting.co.za> Brandon Milam added the comment: Ok I've been able to test the new patch now and I'm not sure that os.startfile is going to work. I've been able to get os.startfile() to open a specified browser (>>> os.startfile("chrome.exe", "open")), however, the function does not allow additional arguments(>>> os.startfile("chrome.exe", "open", "www.yahoo.com") Traceback (most recent call last): File "", line 1, in TypeError: startfile() takes at most 2 arguments (3 given))) so not even a url will be allowed to be specified as the code is written in the patch let alone specifying new window or new tab. Is this an error on os.startfile's part? The documentation for it seems to indicate that it should take multiple inputs. I don't have much experience with C to be able to find out figure out what the rest of your patch accomplished. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 18:58:24 2015 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 07 Sep 2015 16:58:24 +0000 Subject: [issue24272] PEP 484 docs In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za> Message-ID: <1441645104.74.0.37444974581.issue24272@psf.upfronthosting.co.za> Guido van Rossum added the comment: I apologize, I've been distracted. I will try to get to this before 3.5.0 final goes out! I don't know if the fixes will end up in the tar ball but they will certainly be on docs.python.org. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 19:00:48 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Sep 2015 17:00:48 +0000 Subject: [issue25018] test_shutil.test_make_archive() fails on Windows 8.1 In-Reply-To: <1441616742.69.0.0154007377208.issue25018@psf.upfronthosting.co.za> Message-ID: <20150907170045.114948.81390@psf.io> Roundup Robot added the comment: New changeset 58937cd19a85 by Serhiy Storchaka in branch '3.4': Issue #25018: Fixed testing shutil.make_archive() with relative base_name on https://hg.python.org/cpython/rev/58937cd19a85 New changeset d9c4b35e3fdc by Serhiy Storchaka in branch '2.7': Issue #25018: Fixed testing shutil.make_archive() with relative base_name on https://hg.python.org/cpython/rev/d9c4b35e3fdc New changeset 4312b6549590 by Serhiy Storchaka in branch '3.5': Issue #25018: Fixed testing shutil.make_archive() with relative base_name on https://hg.python.org/cpython/rev/4312b6549590 New changeset b076b62731b7 by Serhiy Storchaka in branch 'default': Issue #25018: Fixed testing shutil.make_archive() with relative base_name on https://hg.python.org/cpython/rev/b076b62731b7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 19:18:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Sep 2015 17:18:08 +0000 Subject: [issue25018] test_shutil.test_make_archive() fails on Windows 8.1 In-Reply-To: <1441616742.69.0.0154007377208.issue25018@psf.upfronthosting.co.za> Message-ID: <1441646288.72.0.378990086141.issue25018@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I hope that I preserved the intention of the test. It tested relative make_archive() with base_name. Original test first changed working directory and drive (to the same drive as the drive of output file) and then called private function _make_tarball(). After my refactoring the code became call make_archive() that resolve base_name before changing current directory. The peculiarity of the buildbot is that it crates temporary files on different drive that current drive, and relative base_name were resolved to wrong absolute name. Now the code changes current directory before calling make_archive() with relative base_name argument and the test makes sense on non-Windows. Also added similar test for zip format. ---------- assignee: -> serhiy.storchaka stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 19:20:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Sep 2015 17:20:40 +0000 Subject: [issue25019] xmlparse_setattro() Type Confusion In-Reply-To: <1441641362.28.0.731210993135.issue25019@psf.upfronthosting.co.za> Message-ID: <1441646440.98.0.716779488429.issue25019@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 19:24:24 2015 From: report at bugs.python.org (Mark Roseman) Date: Mon, 07 Sep 2015 17:24:24 +0000 Subject: [issue23551] IDLE to provide menu link to PIP gui. In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za> Message-ID: <1441646664.88.0.776843665515.issue23551@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 19:30:11 2015 From: report at bugs.python.org (Mark Roseman) Date: Mon, 07 Sep 2015 17:30:11 +0000 Subject: [issue22460] idle editor: replace all in selection In-Reply-To: <1411381735.15.0.967867369025.issue22460@psf.upfronthosting.co.za> Message-ID: <1441647011.81.0.244121137663.issue22460@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 19:30:24 2015 From: report at bugs.python.org (Mark Roseman) Date: Mon, 07 Sep 2015 17:30:24 +0000 Subject: [issue13586] IDLE: Replace selected not working/consistent with find In-Reply-To: <1323668532.6.0.615781606265.issue13586@psf.upfronthosting.co.za> Message-ID: <1441647024.22.0.999467111836.issue13586@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 19:30:36 2015 From: report at bugs.python.org (Mark Roseman) Date: Mon, 07 Sep 2015 17:30:36 +0000 Subject: [issue22179] Idle. Search dialog found text not highlited on Windows In-Reply-To: <1407672062.65.0.813743837574.issue22179@psf.upfronthosting.co.za> Message-ID: <1441647036.51.0.3641210261.issue22179@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 19:30:48 2015 From: report at bugs.python.org (Mark Roseman) Date: Mon, 07 Sep 2015 17:30:48 +0000 Subject: [issue18590] Found text not always highlighted by Replace dialog on Windows In-Reply-To: <1375128565.7.0.113615028691.issue18590@psf.upfronthosting.co.za> Message-ID: <1441647048.84.0.0324698551554.issue18590@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 19:31:04 2015 From: report at bugs.python.org (Mark Roseman) Date: Mon, 07 Sep 2015 17:31:04 +0000 Subject: [issue16893] Generate Idle help from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1441647064.82.0.716992694504.issue16893@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 19:38:14 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 07 Sep 2015 17:38:14 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1441647494.81.0.099002124987.issue8232@psf.upfronthosting.co.za> Steve Dower added the comment: The C part of the patch adds an extra argument to startfile to accept the arguments. You'll need to rebuild Python to test the change completely - it's no longer just a pure Python change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 20:43:01 2015 From: report at bugs.python.org (Mark Roseman) Date: Mon, 07 Sep 2015 18:43:01 +0000 Subject: [issue24972] IDLE: revisit text highlighting for inactive windows on win32 In-Reply-To: <1441047261.05.0.292381389884.issue24972@psf.upfronthosting.co.za> Message-ID: <1441651381.95.0.926442842199.issue24972@psf.upfronthosting.co.za> Mark Roseman added the comment: See inactiveselection.patch. This addresses the original bug of the debugger not highlighting the correct line, and also various issues with the find windows not highlighting the selection they have found, e.g. #22179, #18590 ---------- keywords: +patch Added file: http://bugs.python.org/file40396/inactiveselection.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 21:54:19 2015 From: report at bugs.python.org (Thomas Guettler) Date: Mon, 07 Sep 2015 19:54:19 +0000 Subject: [issue25017] htmllib deprecated: Which library to use? Missing sane default in docs In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za> Message-ID: <1441655659.3.0.28930443912.issue25017@psf.upfronthosting.co.za> Thomas Guettler added the comment: This issue is just about documentation. No code change is required for it. How to update the docs, to point to html.parser? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 21:56:27 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Sep 2015 19:56:27 +0000 Subject: [issue25019] xmlparse_setattro() Type Confusion In-Reply-To: <1441641362.28.0.731210993135.issue25019@psf.upfronthosting.co.za> Message-ID: <20150907195624.17977.87368@psf.io> Roundup Robot added the comment: New changeset ff2c4f281720 by Serhiy Storchaka in branch '3.4': Issue #25019: Fixed a crash caused by setting non-string key of expat parser. https://hg.python.org/cpython/rev/ff2c4f281720 New changeset 6006231dcaae by Serhiy Storchaka in branch '3.5': Issue #25019: Fixed a crash caused by setting non-string key of expat parser. https://hg.python.org/cpython/rev/6006231dcaae New changeset edf25acae637 by Serhiy Storchaka in branch 'default': Issue #25019: Fixed a crash caused by setting non-string key of expat parser. https://hg.python.org/cpython/rev/edf25acae637 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 21:58:32 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 07 Sep 2015 19:58:32 +0000 Subject: [issue25017] htmllib deprecated: Which library to use? Missing sane default in docs In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za> Message-ID: <1441655912.29.0.728512246704.issue25017@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +ezio.melotti _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 22:07:55 2015 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 07 Sep 2015 20:07:55 +0000 Subject: [issue25017] htmllib deprecated: Which library to use? Missing sane default in docs In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za> Message-ID: <1441656475.7.0.259959921882.issue25017@psf.upfronthosting.co.za> Ezio Melotti added the comment: If you want to create a patch, you have to edit the file Doc/library/htmllib.rst in the 2.7 branch. You can find information about cloning the CPython repository and switching branch in the devguide. The warning should suggest :mod:`HTMLParser` for Python 2 and the equivalent :mod:`html.parser` for Python 3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 22:09:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Sep 2015 20:09:57 +0000 Subject: [issue25019] xmlparse_setattro() Type Confusion In-Reply-To: <1441641362.28.0.731210993135.issue25019@psf.upfronthosting.co.za> Message-ID: <1441656597.94.0.481277142002.issue25019@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your contribution John. The committed patch slightly differs from the proposed patch. Error message now is the same as in setattr() and general __setattr__(). Tests are moved to existing test class for testing of attribute setting. Improved tests for valid attributes. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: security -> crash versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 22:20:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 07 Sep 2015 20:20:55 +0000 Subject: [issue25018] test_shutil.test_make_archive() fails on Windows 8.1 In-Reply-To: <1441616742.69.0.0154007377208.issue25018@psf.upfronthosting.co.za> Message-ID: <1441657255.81.0.431262972387.issue25018@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The build bot is green. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 22:22:28 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 07 Sep 2015 20:22:28 +0000 Subject: [issue24272] PEP 484 docs In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za> Message-ID: <1441657348.13.0.887046234439.issue24272@psf.upfronthosting.co.za> Larry Hastings added the comment: Doc fixes are always welcome. Barring mishaps I should tag 3.5.0 final on Saturday; it'd be sweet if you could get me your diff no later than Friday night. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 22:56:18 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 07 Sep 2015 20:56:18 +0000 Subject: [issue25012] pathlib should allow converting to absolute paths without resolving symlinks In-Reply-To: <1441490748.21.0.647656961559.issue25012@psf.upfronthosting.co.za> Message-ID: <1441659378.42.0.466571306047.issue25012@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Yes, this wasn't meant to be a public method really. I'm still on the fence as to whether we should expose something like this. What is your use case? ---------- type: behavior -> enhancement versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 23:06:35 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 07 Sep 2015 21:06:35 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1441659995.48.0.725812533571.issue24999@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I *think* shifting by an amount larger than the operand's width is undefined behaviour (at least LLVM clearly seems to think so, since it gives different results on x86 and ARM), so the compiler is probably allowed to do what it wants (even return 42). ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 23:54:51 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 07 Sep 2015 21:54:51 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1441662891.88.0.239294181197.issue25003@psf.upfronthosting.co.za> STINNER Victor added the comment: Attached patch (for Python 3.4) removes code to use getentropy() in os.urandom(). ---------- keywords: +patch Added file: http://bugs.python.org/file40397/remove_get_entropy.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 7 23:57:18 2015 From: report at bugs.python.org (Mark Roseman) Date: Mon, 07 Sep 2015 21:57:18 +0000 Subject: [issue16893] Generate Idle help from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1441663038.76.0.959949263903.issue16893@psf.upfronthosting.co.za> Mark Roseman added the comment: If it's useful, I quickly threw together a routine that takes the HTML generated by Sphinx, and using html.parser, strips out the navigation stuff, and stuffs it into a Tk text widget, doing appropriate things with the subset of the formatting it uses (lists, headings, etc.). If something like that seems appropriate to use, let me know and I can clean it up a bit and post it as a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 00:15:43 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 07 Sep 2015 22:15:43 +0000 Subject: [issue22241] strftime/strptime round trip fails even for UTC datetime object In-Reply-To: <1408620917.6.0.856660367054.issue22241@psf.upfronthosting.co.za> Message-ID: <20150907221540.14865.87047@psf.io> Roundup Robot added the comment: New changeset ea1bfb64e898 by Victor Stinner in branch 'default': Issue #22241: Fix a compiler waring https://hg.python.org/cpython/rev/ea1bfb64e898 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 00:27:55 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 07 Sep 2015 22:27:55 +0000 Subject: [issue25011] Smarter rl complete: hide private and special names In-Reply-To: <1441488567.65.0.369817501077.issue25011@psf.upfronthosting.co.za> Message-ID: <1441664875.71.0.468651760642.issue25011@psf.upfronthosting.co.za> R. David Murray added the comment: Sounds good to me, especially the __ part. I don't actually use completions, though :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 00:56:13 2015 From: report at bugs.python.org (Brandon Milam) Date: Mon, 07 Sep 2015 22:56:13 +0000 Subject: [issue8232] webbrowser.open incomplete on Windows In-Reply-To: <1269541962.46.0.762619344208.issue8232@psf.upfronthosting.co.za> Message-ID: <1441666573.03.0.879400659897.issue8232@psf.upfronthosting.co.za> Brandon Milam added the comment: Finally got it rebuilt after having trouble with visual studio for awhile. I've tested the new patch and it is still able to properly find both chrome and firefox and is able to differentiate between new window and new tab for those two browsers so it appears to still be working. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 00:56:55 2015 From: report at bugs.python.org (Davin Potts) Date: Mon, 07 Sep 2015 22:56:55 +0000 Subject: [issue21505] cx_freeze multiprocessing bug In-Reply-To: <1400047714.39.0.600066285372.issue21505@psf.upfronthosting.co.za> Message-ID: <1441666615.79.0.571074214856.issue21505@psf.upfronthosting.co.za> Davin Potts added the comment: Closing as there is no additional information forthcoming from the OP and per the prior comments, Torsten's suggestion seems as helpful as anything that can be offered without more info. ---------- resolution: -> out of date status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 01:04:00 2015 From: report at bugs.python.org (Davin Potts) Date: Mon, 07 Sep 2015 23:04:00 +0000 Subject: [issue24475] The docs never define what a pool "task" is In-Reply-To: <1434733537.74.0.146405679971.issue24475@psf.upfronthosting.co.za> Message-ID: <1441667040.45.0.657520547223.issue24475@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 01:09:25 2015 From: report at bugs.python.org (Davin Potts) Date: Mon, 07 Sep 2015 23:09:25 +0000 Subject: [issue24484] multiprocessing cleanup occasionally throws exception In-Reply-To: <1434899306.98.0.122661278895.issue24484@psf.upfronthosting.co.za> Message-ID: <1441667365.54.0.203953321113.issue24484@psf.upfronthosting.co.za> Davin Potts added the comment: The 'crash' type is reserved for core dump type situations; 'behavior' is more appropriate for the misbehavior your describe. ---------- type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 01:12:55 2015 From: report at bugs.python.org (Davin Potts) Date: Mon, 07 Sep 2015 23:12:55 +0000 Subject: [issue23992] multiprocessing: MapResult shouldn't fail fast upon exception In-Reply-To: <1429347621.56.0.157795358647.issue23992@psf.upfronthosting.co.za> Message-ID: <1441667575.84.0.447726970811.issue23992@psf.upfronthosting.co.za> Davin Potts added the comment: @neologix: Budgeting time this week to have a proper look -- sorry I haven't gotten back to it sooner. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 01:21:29 2015 From: report at bugs.python.org (David Barnett) Date: Mon, 07 Sep 2015 23:21:29 +0000 Subject: [issue25012] pathlib should allow converting to absolute paths without resolving symlinks In-Reply-To: <1441490748.21.0.647656961559.issue25012@psf.upfronthosting.co.za> Message-ID: <1441668089.6.0.408013141759.issue25012@psf.upfronthosting.co.za> David Barnett added the comment: The idiom of pathlib.Path.cwd() / pathlib.Path('some/path') isn't too bad of an approach if it could just be mentioned in the docs. I would intuitively expected something like pathlib.Path('some/path').resolve(follow_symlinks=False) My use case was that I had an equality check like this failing: expected_path = pathlib.Path.cwd() / pathlib.Path('some/path') pathlib.Path('some/path') == expected_path I suppose I should file that as a separate bug because semantically those paths are equal, but I was trying to work around it like pathlib.Path('some/path').resolve() == expected_path which in my case still failed because some/path was a symlink. Even if that's fixed, I would still expect to run into cases where I wanted to print specifically the relative or absolute path in informational messages and would not want to follow symlinks (e.g., in "Requested path X not found", the user would recognize the absolute path as the one they entered but not necessarily the symlink-resolved version). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 01:59:46 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 07 Sep 2015 23:59:46 +0000 Subject: [issue25016] defaultdict's pop gives a KeyError In-Reply-To: <1441607246.41.0.522388405407.issue25016@psf.upfronthosting.co.za> Message-ID: <1441670386.31.0.261678063629.issue25016@psf.upfronthosting.co.za> R. David Murray added the comment: It would not be sensible for pop to return the default value, since the point of pop is to *remove* a key from the dictionary (while returning the existing value), whereas the point defaultdict is to *add* key to the dictionary with the default value if you retrieve a non-existent key. As Martin said, an important aspect of defaultdict is that *only* getattr has this default behavior; things like 'in' still work like a regular dictionary with a defaultdict. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 02:14:51 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 08 Sep 2015 00:14:51 +0000 Subject: [issue24862] subprocess.Popen behaves incorrect when moved in process tree In-Reply-To: <1439520939.88.0.252356845124.issue24862@psf.upfronthosting.co.za> Message-ID: <1441671291.58.0.735778069626.issue24862@psf.upfronthosting.co.za> R. David Murray added the comment: Not really. Give GPS a couple more weeks to respond, and then maybe bring it up on python-dev. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 02:39:27 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Sep 2015 00:39:27 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1441672767.33.0.946946518685.issue25003@psf.upfronthosting.co.za> Guido van Rossum added the comment: I got several long private emails from Theo De Raadt about this issue. I think the gist of it all is that most likely (a) the app most likely shouldn't be calling os.urandom() that often, and (b) Solaris getentropy() is apparently stunningly slow. Theo also seems to imply that "entropy" as a concept is debunked, and OpenBSD getentropy() and getrandom() are essentially the same thing except that the former's interface is faster (because it doesn't use a FD). So it is also possible that using getentropy() instead of getrandom() was unnecessary; possibly the speed difference would be noticeable via Python. Perhaps the getentropy() check can explicitly rule out Solaris (either at the autoconf level or in the random.c source code) if you prefer to keep the getentropy() call on OpenBSD. ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 02:42:13 2015 From: report at bugs.python.org (Mark Roseman) Date: Tue, 08 Sep 2015 00:42:13 +0000 Subject: [issue25020] IDLE - centralize ui policies and small utilities Message-ID: <1441672933.59.0.053445062367.issue25020@psf.upfronthosting.co.za> New submission from Mark Roseman: Certain policy decisions should be in one place in the code (DRY). These could be based on preferences or environment (should we be using ttk?), which operating system we're using (what hand cursor looks best?) or even the version of the operating system we're running (do we need to include a sizegrip?), etc. Similarly, there are some small utilities that should be available in many places (e.g. what events to bind to for context menu clicks, setting a dialog to modal appearance) that don't necessarily fit elsewhere. I've attached ui.py which will be a starting place for these sorts of things. ---------- components: IDLE files: ui.py messages: 250143 nosy: kbk, markroseman, roger.serwy, terry.reedy priority: normal severity: normal status: open title: IDLE - centralize ui policies and small utilities type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40398/ui.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 04:04:12 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 08 Sep 2015 02:04:12 +0000 Subject: [issue25014] Add contextlib.itercm() In-Reply-To: <1441542735.79.0.482816688867.issue25014@psf.upfronthosting.co.za> Message-ID: <1441677852.43.0.972907745612.issue25014@psf.upfronthosting.co.za> Yury Selivanov added the comment: TBH, I don't like the idea. It would take me some time to digest the code every time I see this. > lines = chain.from_iterable(itercm(open(f)) for f in fnames) This looks like an extremely rare use case. ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 04:44:31 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 08 Sep 2015 02:44:31 +0000 Subject: [issue25014] Add contextlib.itercm() In-Reply-To: <1441542735.79.0.482816688867.issue25014@psf.upfronthosting.co.za> Message-ID: <1441680271.44.0.306464566247.issue25014@psf.upfronthosting.co.za> Nick Coghlan added the comment: Having spent a few days pondering this after Ezio first mentioned the concept to me on IRC, I'm rejecting this on the basis of "not every 3 line function needs to be in the standard library". The vast majority of iterable CM use cases are going to fall into one of the following two categories: * deterministic cleanup is needed regardless of success or failure * non-deterministic cleanup is acceptable regardless of success or failure In the former case, you don't continue iteration after the with statement ends, in the latter, you don't need to use the context manager aspects at all. Those cases which don't fall into that category would generally be better served by an appropriately named helper function that conveys the author's intent, rather than describing what the function does internally: def chain_files(names): for name in names: with open(name) as f: yield from f def cat(fnames): for line in chain_files(fnames): print(line, end='') The implementation of the helper function can then optionally be switched to a compositional approach without affecting the usage: def itercm(cm): with cm: yield from cm def iterfile(name): return itercm(open(name)) def chain_files(names): return chain.from_iterable(iterfile(name) for name in names) For the more concrete use case of "iterate over several files in sequence", we have the fileinput module: https://docs.python.org/3/library/fileinput.html That already opens and closes files as it goes, so chain_files() can actually be implemented as: def chain_files(names): with fileinput.input(names) as files: return chain.from_iterable(files) ---------- resolution: -> rejected stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 04:54:29 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Sep 2015 02:54:29 +0000 Subject: [issue24982] shutil.make_archive doesn't archive empty directories In-Reply-To: <1441155377.03.0.243318485167.issue24982@psf.upfronthosting.co.za> Message-ID: <20150908025426.115020.16912@psf.io> Roundup Robot added the comment: New changeset 705ec4145f06 by Serhiy Storchaka in branch '2.7': Issue #24982: shutil.make_archive() with the "zip" format now adds entries https://hg.python.org/cpython/rev/705ec4145f06 New changeset 19216f5f6ee0 by Serhiy Storchaka in branch '3.4': Issue #24982: shutil.make_archive() with the "zip" format now adds entries https://hg.python.org/cpython/rev/19216f5f6ee0 New changeset 142a5027ab3e by Serhiy Storchaka in branch '3.5': Issue #24982: shutil.make_archive() with the "zip" format now adds entries https://hg.python.org/cpython/rev/142a5027ab3e New changeset 6907716e7ccb by Serhiy Storchaka in branch 'default': Issue #24982: shutil.make_archive() with the "zip" format now adds entries https://hg.python.org/cpython/rev/6907716e7ccb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 05:07:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Sep 2015 03:07:43 +0000 Subject: [issue25011] Smarter rl complete: hide private and special names In-Reply-To: <1441488567.65.0.369817501077.issue25011@psf.upfronthosting.co.za> Message-ID: <1441681663.69.0.903794321786.issue25011@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is improved patch. The completion of empty prefix now returns the list of private names if there are no public names. The completion of empty prefix or prefix '_' now returns the list of dunder names if there are no non-dunder names. For example try "None.". In addition attr_matches() no longer returns duplicated names. ---------- Added file: http://bugs.python.org/file40399/rlcomplete_filter_private_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 05:08:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Sep 2015 03:08:21 +0000 Subject: [issue24982] shutil.make_archive doesn't archive empty directories In-Reply-To: <1441155377.03.0.243318485167.issue24982@psf.upfronthosting.co.za> Message-ID: <1441681701.07.0.945033511645.issue24982@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 05:20:52 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 08 Sep 2015 03:20:52 +0000 Subject: [issue22460] idle editor: replace all in selection In-Reply-To: <1411381735.15.0.967867369025.issue22460@psf.upfronthosting.co.za> Message-ID: <1441682452.5.0.14522267096.issue22460@psf.upfronthosting.co.za> Raymond Hettinger added the comment: -0 on doing this. The current Find/Replace works pretty well even for replacements within a block (though it takes a few clicks to apply them one at a time). In general, IDLE aspires to be minimalist and favor rapid learnability over having more features and options ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 05:25:02 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 08 Sep 2015 03:25:02 +0000 Subject: [issue25008] Deprecate smtpd In-Reply-To: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za> Message-ID: <1441682702.86.0.727869092117.issue25008@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Unless there is a drop-in replacement, I don't think this should be deprecated or removed. Our biggest problem in the Python world is getting organizations using Python 2 to switch to Python 3. Deprecating modules that have been a part of the firmament for a long time works against that goal. Side note: a quick search shows that people are still writing SMTPD modules in other languages (i.e. Go now has one) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 05:33:11 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 08 Sep 2015 03:33:11 +0000 Subject: [issue25002] Deprecate asyncore/asynchat In-Reply-To: <1441399683.85.0.786847810998.issue25002@psf.upfronthosting.co.za> Message-ID: <1441683190.99.0.579508275287.issue25002@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Now that we've got asyncio in two releases (3.4 and 3.5) > we should start deprecating asyncore and asynchat. If we care about making it easier for organizations to move from Python 2 to Python 3, we should develop a strong aversion to deprecating modules that have been around for a long time and aren't broken. In addition, we should give weight and support to the numerous projects that are trying to have a code base the runs in both Python 2 and Python 3 (hence the astonishing success of the six module). Already my tooling for testing Python 3.6 is broken because some core dev aggressively removed functions from the inspect module that were deprecated in favor of using Signature objects. That broke the popular Hypothesis testing tool which was carefully written to work for both Python 2 and Python 3. In order to work again that tool will have to be modified to copy in the old code that was just taken out. don't-leave-your-users-behind-ly yours ... ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 05:53:14 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Sep 2015 03:53:14 +0000 Subject: [issue25002] Deprecate asyncore/asynchat In-Reply-To: <1441399683.85.0.786847810998.issue25002@psf.upfronthosting.co.za> Message-ID: <1441684394.52.0.186814283421.issue25002@psf.upfronthosting.co.za> Guido van Rossum added the comment: Then can we at least close any feature requests for asyncore/asynchat as wontfix? (And porting smtpd.py to asyncio is still a good idea.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 05:55:02 2015 From: report at bugs.python.org (John Leitch) Date: Tue, 08 Sep 2015 03:55:02 +0000 Subject: [issue25021] product_setstate() Out-of-bounds Read Message-ID: <1441684502.22.0.0994334100718.issue25021@psf.upfronthosting.co.za> New submission from John Leitch: Python 3.3, 3.4, and 3.5 suffer from a vulnerability caused by the behavior of the product_setstate() function. When called, the function loops over the state tuple provided and clamps each given index to a value within a range from 0 up to the max number of pools. Then, it loops over the pools and gets an item from the pool using the previously clamped index value. However, for the upper bound, the clamping logic is using the number of pools and not the size of the individual pool, which can result in a call to PyTuple_GET_ITEM that uses an index outside of the bounds of the pool: for (i=0; i n-1) index = n-1; lz->indices[i] = index; } result = PyTuple_New(n); if (!result) return NULL; for (i=0; ipools, i); PyObject *element = PyTuple_GET_ITEM(pool, lz->indices[i]); Py_INCREF(element); PyTuple_SET_ITEM(result, i, element); } The invalid result of the PyTyple_GET_ITEM() expression is then passed to Py_INCREF(), which performs a write operation that corrupts memory. In some applications, it may be possible to exploit this behavior to corrupt sensitive information, crash, or achieve code execution. The out-of-bounds write can be observed by running the following script: import itertools p = itertools.product((0,),(0,)) p.__setstate__((0, 1)) Which, depending on the arrangement of memory, may produce an exception such as this: 0:000> g (ea4.11a4): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=0000c962 ebx=059e8f80 ecx=00000000 edx=00000000 esi=004af564 edi=05392f78 eip=613211eb esp=004af4d0 ebp=004af4f8 iopl=0 nv up ei pl nz na po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202 python35_d!product_setstate+0x13b: 613211eb 8b5108 mov edx,dword ptr [ecx+8] ds:002b:00000008=???????? 0:000> k1 ChildEBP RetAddr 004af4f8 61553a22 python35_d!product_setstate+0x13b [c:\source\python-3.5.0b3\modules\itertoolsmodule.c @ 2266] In some cases, EIP corruption may occur: 0:000> r eax=00000000 ebx=03e0f790 ecx=6d2ad658 edx=00000002 esi=03e0f790 edi=6d0dbb20 eip=00000000 esp=004cf6a0 ebp=004cf6ac iopl=0 nv up ei pl nz na po nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202 00000000 ?? ??? 0:000> k4 ChildEBP RetAddr WARNING: Frame IP not in any known module. Following frames may be wrong. 004cf69c 6d08a390 0x0 004cf6ac 6d02b688 python35!PyIter_Next+0x10 004cf6c0 6d0dbb6e python35!chain_next+0x58 004cf6d0 6d0a021d python35!wrap_next+0x4e To fix this issue, it is recommended that product_setstate() be updated to clamp indices within a range from 0 up to the size of the pool in the body of the result tuple building loop. A proposed patch is attached. Credit: John Leitch (johnleitch at outlook.com), Bryce Darling (darlingbryce at gmail.com) ---------- files: product_setstate_Type_Confusion.patch keywords: patch messages: 250152 nosy: JohnLeitch, brycedarling, rhettinger priority: normal severity: normal status: open title: product_setstate() Out-of-bounds Read type: security versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file40400/product_setstate_Type_Confusion.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 05:55:20 2015 From: report at bugs.python.org (John Leitch) Date: Tue, 08 Sep 2015 03:55:20 +0000 Subject: [issue25021] product_setstate() Out-of-bounds Read In-Reply-To: <1441684502.22.0.0994334100718.issue25021@psf.upfronthosting.co.za> Message-ID: <1441684520.66.0.784162129471.issue25021@psf.upfronthosting.co.za> Changes by John Leitch : Added file: http://bugs.python.org/file40401/product_setstate_Type_Confusion.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 06:16:05 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 08 Sep 2015 04:16:05 +0000 Subject: [issue16893] Generate Idle help from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1441685765.45.0.340670345241.issue16893@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Trying to produce .txt from .rst or .html was the original idea but the result in the upload help.txt is not terribly good. We decided that it is reasonable these days to depend on a browser being present and use the webbrowser module to display the html in a browser. Some effort has been put into getting decent looking html from rst. On windows, the .chm installed with Python can be used as a backup should the browser not work. The reason for not simply starting a browser on the online Idle page is that the online docs reflect the repository version of Idle, which may have features not in the released version. So a 'frozen' doc is needed. (Note that the .chm is already frozen.) The steps and issues I see. 1. Should there be a separate idlehelp target, as in Zach's v4 patch, or should copying the one file be part of building the html files. The issue here is making sure that the idlelib/help.html is rebuilt at the time of release. Re-generating the html files is, I presume, part of the release process, whereas a separate step would have to somehow be added. 2. We already use webbrowser to start the online docs, I believe on all systems. The code can be reused with a different target. 3. Is an exact copy ok, or should some nagivation be removed? We need to try the file as is and see. 4. The html file should be added to .hgignore and not checked into the repository. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 06:32:23 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Sep 2015 04:32:23 +0000 Subject: [issue25010] minor typo in PCBuild readme.txt In-Reply-To: <1441474606.12.0.269999159131.issue25010@psf.upfronthosting.co.za> Message-ID: <20150908043220.68867.96382@psf.io> Roundup Robot added the comment: New changeset 7f4102a9818b by Zachary Ware in branch '3.4': Issue #25010: Fix path for .pyd example project. https://hg.python.org/cpython/rev/7f4102a9818b New changeset 309c0331726b by Zachary Ware in branch '3.5': Issue #25010: Merge with 3.4 https://hg.python.org/cpython/rev/309c0331726b New changeset 3829f567d269 by Zachary Ware in branch 'default': Closes #25010: Merge with 3.5 https://hg.python.org/cpython/rev/3829f567d269 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 06:33:33 2015 From: report at bugs.python.org (Zachary Ware) Date: Tue, 08 Sep 2015 04:33:33 +0000 Subject: [issue25010] minor typo in PCBuild readme.txt In-Reply-To: <1441474606.12.0.269999159131.issue25010@psf.upfronthosting.co.za> Message-ID: <1441686813.55.0.761458498256.issue25010@psf.upfronthosting.co.za> Zachary Ware added the comment: Thanks for the report and patch! Unfortunately, that example is so completely out of date we'd probably be better off to remove it, but we can at least point to the right path :) ---------- nosy: +zach.ware versions: +Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 06:42:30 2015 From: report at bugs.python.org (Zachary Ware) Date: Tue, 08 Sep 2015 04:42:30 +0000 Subject: [issue25022] Remove PC/example_nt/ Message-ID: <1441687350.45.0.29239152419.issue25022@psf.upfronthosting.co.za> New submission from Zachary Ware: The instructions and examples in PC/example_nt/ are hopelessly outdated (the readme says "It has been tested with VC++ 7.1 on Python 2.4" on default!). Is there any reason to keep and update the example, or can we just drop it? ---------- assignee: docs at python components: Documentation, Windows messages: 250156 nosy: docs at python, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Remove PC/example_nt/ type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 07:27:40 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 08 Sep 2015 05:27:40 +0000 Subject: [issue25021] product_setstate() Out-of-bounds Read In-Reply-To: <1441684502.22.0.0994334100718.issue25021@psf.upfronthosting.co.za> Message-ID: <1441690060.21.0.259016879952.issue25021@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 07:31:23 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 08 Sep 2015 05:31:23 +0000 Subject: [issue25021] product_setstate() Out-of-bounds Read In-Reply-To: <1441684502.22.0.0994334100718.issue25021@psf.upfronthosting.co.za> Message-ID: <1441690283.55.0.402380261486.issue25021@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +kristjan.jonsson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 07:32:07 2015 From: report at bugs.python.org (grizlupo) Date: Tue, 08 Sep 2015 05:32:07 +0000 Subject: [issue25023] time.strftime('%a'), ValueError: embedded null byte, in ko locale Message-ID: <1441690327.52.0.627876952587.issue25023@psf.upfronthosting.co.za> New submission from grizlupo: >>> locale.setlocale(locale.LC_ALL, 'en') 'en' >>> time.strftime('%a') 'Tue' >>> locale.setlocale(locale.LC_ALL, 'ko') 'ko' >>> time.strftime('%a') Traceback (most recent call last): File "", line 1, in ValueError: embedded null byte >>> ---------- components: Unicode messages: 250157 nosy: ezio.melotti, haypo, sy LEE priority: normal severity: normal status: open title: time.strftime('%a'), ValueError: embedded null byte, in ko locale type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 07:36:20 2015 From: report at bugs.python.org (Antony Lee) Date: Tue, 08 Sep 2015 05:36:20 +0000 Subject: [issue25024] Allow passing "delete=False" to TemporaryDirectory Message-ID: <1441690580.39.0.270846340544.issue25024@psf.upfronthosting.co.za> New submission from Antony Lee: I would like to suggest allowing passing "delete=False" to the TemporaryDirectory constructor, with the effect that the directory is not deleted when the TemporaryDirectory context manager exits, or when the TemporaryDirectory object is deleted. I realize that this would effectively duplicate the functionality of mkdtemp, but this is similar to the redundancy between NamedTemporaryFile(delete=False) and mkstemp, and would make it easier to switch between the two behaviors (which is useful e.g. when debugging, where you may need to look at the temporary files "post-mortem"). ---------- components: Library (Lib) messages: 250158 nosy: Antony.Lee priority: normal severity: normal status: open title: Allow passing "delete=False" to TemporaryDirectory versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 07:38:22 2015 From: report at bugs.python.org (koobs) Date: Tue, 08 Sep 2015 05:38:22 +0000 Subject: [issue25025] Missing 3.5.0 RC3 tarballs (FTP) Message-ID: <1441690702.95.0.161159545328.issue25025@psf.upfronthosting.co.za> New submission from koobs: 3.5.0 rc3 tarballs appear to be missing on: https://www.python.org/ftp/python/3.5.0/ ---------- messages: 250159 nosy: koobs priority: normal severity: normal status: open title: Missing 3.5.0 RC3 tarballs (FTP) versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 08:06:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Sep 2015 06:06:58 +0000 Subject: [issue25023] time.strftime('%a'), ValueError: embedded null byte, in ko locale In-Reply-To: <1441690327.52.0.627876952587.issue25023@psf.upfronthosting.co.za> Message-ID: <1441692418.04.0.205416872383.issue25023@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What is your OS? On Ubuntu: >>> import locale, time >>> locale.setlocale(locale.LC_ALL, 'ko_KR.UTF-8') 'ko_KR.UTF-8' >>> time.strftime('%a') '?' >>> locale.setlocale(locale.LC_ALL, 'ko_KR.eucKR') 'ko_KR.eucKR' >>> time.strftime('%a') '?' >>> locale.setlocale(locale.LC_ALL, 'ko_KR') Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython/Lib/locale.py", line 595, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting >>> locale.setlocale(locale.LC_ALL, 'ko') Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython/Lib/locale.py", line 595, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting ---------- components: +Library (Lib) nosy: +lemburg, loewis, serhiy.storchaka type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 08:22:50 2015 From: report at bugs.python.org (Zachary Ware) Date: Tue, 08 Sep 2015 06:22:50 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1441693370.52.0.826806447823.issue24999@psf.upfronthosting.co.za> Zachary Ware added the comment: Stefan Krah commented: > The buildbot segfaults all over the place, also in test_tokenize > and test_json: To be fair, other buildbots are also segfaulting (or otherwise silently failing) on those: 3.4 on XP, test_json: http://buildbot.python.org/all/builders/x86%20XP-4%203.4/builds/1190/steps/test/logs/stdio 3.5 on 7, test_tokenize: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.5/builds/250/steps/test/logs/stdio ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 08:23:36 2015 From: report at bugs.python.org (Zachary Ware) Date: Tue, 08 Sep 2015 06:23:36 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1441693416.27.0.802958691905.issue24999@psf.upfronthosting.co.za> Zachary Ware added the comment: Note: the ICC buildbot does fail much more consistently on those. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 08:35:17 2015 From: report at bugs.python.org (koobs) Date: Tue, 08 Sep 2015 06:35:17 +0000 Subject: [issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2). Message-ID: <1441694117.96.0.393183554729.issue25026@psf.upfronthosting.co.za> New submission from koobs: In my current attempt to create a FreeBSD port for python35, I've come across a patch rejection for the fcntlmodule.c for a local port patch we've been carrying since Python 2.6: https://svnweb.freebsd.org/ports/head/lang/python27/files/patch-Modules__fcntlmodule.c?revision=391238&view=markup The original commit log for this change is: ==================================== Fix fcntl module to accept 'unsigned long' type commands for ioctl(2). Although POSIX says the type is 'int', all BSD variants (including Mac OS X) have been using 'unsigned long' type for very long time and its use predates the standard long enough. For certain commands (e.g., TIOCSWINSZ, FIONBIO), the Python value may get sign-extended on 64-bit platforms (by implicit type promotion) and it causes annoying warnings from kernel such as this: WARNING pid 24509 (python2.6): ioctl sign-extension ioctl ffffffff8004667e ==================================== I'm not sure how this should be fixed upstream, nor clear on how to re-patch it given recent changes to fcntlmodule.c ---------- components: Interpreter Core keywords: easy messages: 250163 nosy: koobs priority: normal severity: normal status: open title: (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2). type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 09:24:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Sep 2015 07:24:18 +0000 Subject: [issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2). In-Reply-To: <1441694117.96.0.393183554729.issue25026@psf.upfronthosting.co.za> Message-ID: <1441697058.7.0.782712674138.issue25026@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You need just replace unsigned_int with unsigned_long in Clinic declaration for fcntl.ioctl in Modules/fcntlmodule.c and regenerate Clinic code (make clinic). ---------- nosy: +larry, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 09:26:42 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Sep 2015 07:26:42 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441693370.52.0.826806447823.issue24999@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Zachary Ware added the comment: > To be fair, other buildbots are also segfaulting (or otherwise silently failing) on those: Sorry, the following issues are unrelated. > 3.4 on XP, test_json: > http://buildbot.python.org/all/builders/x86%20XP-4%203.4/builds/1190/steps/test/logs/stdio This one is old. We don't really support Windows XP. If I recall correctly, Windows XP doesn't handle correctly stack overflow. > 3.5 on 7, test_tokenize: > http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.5/builds/250/steps/test/logs/stdio This is a timeout, not a crash. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 09:29:51 2015 From: report at bugs.python.org (koobs) Date: Tue, 08 Sep 2015 07:29:51 +0000 Subject: [issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2). In-Reply-To: <1441694117.96.0.393183554729.issue25026@psf.upfronthosting.co.za> Message-ID: <1441697391.82.0.598223625423.issue25026@psf.upfronthosting.co.za> koobs added the comment: Thanks for the insight Serhiy. A few questions .. Is clinic code updated based on *.c declarations at build time? If not when/how is the best place/method to run this for our ports/package builds? Does your suggestion to switch unsigned_int to unsigned_long imply that the following lines are no longer necessary? - if (PyArg_ParseTuple(args, "O&Iw#|i:ioctl", + if (PyArg_ParseTuple(args, "O&kw#|i:ioctl", How do we get something like this fixed upstream for FreeBSD/OSX? If left un-patched, what is the impact on the user/system? Just a warning on console? ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 09:39:52 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 08 Sep 2015 07:39:52 +0000 Subject: [issue25012] pathlib should allow converting to absolute paths without resolving symlinks In-Reply-To: <1441668089.6.0.408013141759.issue25012@psf.upfronthosting.co.za> Message-ID: <55EE90C2.7090007@free.fr> Antoine Pitrou added the comment: Le 08/09/2015 01:21, David Barnett a ?crit : > > My use case was that I had an equality check like this failing: > expected_path = pathlib.Path.cwd() / pathlib.Path('some/path') > pathlib.Path('some/path') == expected_path > I suppose I should file that as a separate bug because semantically those paths are equal, but I was trying to work around it like > pathlib.Path('some/path').resolve() == expected_path > which in my case still failed because some/path was a symlink. Semantically, the paths are equal only in that particular system configuration, with os.getcwd() pointing to a particular directory. Path comparison is done on "pure" path objects (as explained in the documentation) and therefore doesn't take into account system specifics. This makes comparisons much more predictable. Currently the way to implement "absolute" comparison is to call .resolve() on both paths. Note you might care about actual file identity and call os.path.samefile() instead. > Even if that's fixed, I would still expect to run into cases where I wanted to print specifically the relative or absolute path in informational messages and would not want to follow symlinks (e.g., in "Requested path X not found", the user would recognize the absolute path as the one they entered but not necessarily the symlink-resolved version). Yes... and yet that may be misleading, since the "absolute" path obtained may not correspond to the actual one, especially if ".." fragments are collapsed. I'll have to think about this one a bit more. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 09:53:14 2015 From: report at bugs.python.org (Larry Hastings) Date: Tue, 08 Sep 2015 07:53:14 +0000 Subject: [issue23415] add-to-pydotorg does not support .exe installers for Windows In-Reply-To: <1423433584.82.0.0803149544554.issue23415@psf.upfronthosting.co.za> Message-ID: <1441698794.47.0.179564757378.issue23415@psf.upfronthosting.co.za> Larry Hastings added the comment: I fixed it. My original attempted hack had bad regular expressions. Once my regular expressions worked properly it was all fine. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 10:05:36 2015 From: report at bugs.python.org (Christoph Gohlke) Date: Tue, 08 Sep 2015 08:05:36 +0000 Subject: [issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules Message-ID: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za> New submission from Christoph Gohlke: This issue was first mentioned at . The attached script (test_dll_load_failed.py) builds up to 256 C extension modules and imports them. On Python 3.4.3 the script passes while on Python 3.5.0rc3 the script fails with: ``` Traceback (most recent call last): File "test_dll_load_failed.py", line 42, in import_module(name) File "X:\Python35\lib\importlib\__init__.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 986, in _gcd_import File "", line 969, in _find_and_load File "", line 958, in _find_and_load_unlocked File "", line 666, in _load_unlocked File "", line 577, in module_from_spec File "", line 903, in create_module File "", line 222, in _call_with_frames_removed ImportError: DLL load failed: A dynamic link library (DLL) initialization routine failed. ``` Tested on Windows 7 and 10, 64 bit, with Python 3.5.0rc3, 32 and 64 bit. Due to this issue the "scientific stack" is practically unusable. For example, Pandas unit tests error or abort. In a Jupyter notebook, the following simple imports fail (using current builds from ): ``` In [1]: import matplotlib.pyplot import pandas import statsmodels.api --------------------------------------------------------------------------- ImportError Traceback (most recent call last) in () 1 import matplotlib.pyplot 2 import pandas ----> 3 import statsmodels.api X:\Python35\lib\site-packages\scipy\signal\__init__.py in () 276 # The spline module (a C extension) provides: 277 # cspline2d, qspline2d, sepfir2d, symiirord1, symiirord2 --> 278 from .spline import * 279 280 from .bsplines import * ImportError: DLL load failed: A dynamic link library (DLL) initialization routine failed. ``` The cause of this issue is that as of Python 3.5.0rc1 C extension modules are linked statically to the multi-threaded runtime library (/MT) instead of the multi-threaded DLL runtime library (/MD). A process can not load more than 127 statically-linked CRT DLLs using LoadLibrary due to a limit of fiber-local storage (FLS) as mentioned in the following links: To put the 127 limit in perspective: the pywin32 package contains 51 C extension modules, pygame 36, scipy 65, and scikit-image 41. In addition to C extension modules, the 127 limit also applies to statically-linked CRT DLLs that are dynamically loaded via Ctypes or LoadLibrary. ---------- components: Extension Modules, Windows messages: 250169 nosy: cgohlke, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Python 3.5.0rc3 on Windows can not load more than 127 C extension modules versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 10:06:27 2015 From: report at bugs.python.org (Christoph Gohlke) Date: Tue, 08 Sep 2015 08:06:27 +0000 Subject: [issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules In-Reply-To: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za> Message-ID: <1441699587.59.0.0264620490154.issue25027@psf.upfronthosting.co.za> Changes by Christoph Gohlke : Added file: http://bugs.python.org/file40402/test_dll_load_failed.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 10:06:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Sep 2015 08:06:37 +0000 Subject: [issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2). In-Reply-To: <1441694117.96.0.393183554729.issue25026@psf.upfronthosting.co.za> Message-ID: <1441699597.53.0.464316912063.issue25026@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: No, the clinic code is not updated at build time. Your should either update clinic code just after patching Modules/fcntlmodule.c (Python 3 is needed), or update clinic code at patch creation time and include changes of generated clinic files in the patch. Generated clinic files contain a code for argument parsing (PyArg_ParseTuple...). I don't know if there is easy way to make this change conditionally for FreeBSD/OSX. The only way that I know is writing custom converters. Perhaps the original commit log is outdated. What was the type of code at the time of this log? Now it is unsigned int and this doesn't make sign extension when casted to unsigned long. While the code parameter is in the range 0..0xffffffff, unpatched code shouldn't have any visible effects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 10:09:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Sep 2015 08:09:50 +0000 Subject: [issue25018] test_shutil.test_make_archive() fails on Windows 8.1 In-Reply-To: <1441616742.69.0.0154007377208.issue25018@psf.upfronthosting.co.za> Message-ID: <1441699790.81.0.0346295747728.issue25018@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Tests failed on Mac OS X. http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.5/builds/254/steps/test/logs/stdio ====================================================================== FAIL: test_make_tarball (test.test_shutil.TestShutil) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/buildbot/buildarea/3.5.murray-snowleopard/build/Lib/test/test_shutil.py", line 986, in test_make_tarball self.assertEqual(tarball, base_name + '.tar.gz') AssertionError: '/private/var/folders/0-/0-cd8XI2HU86vol3rX[38 chars]r.gz' != '/var/folders/0-/0-cd8XI2HU86vol3rXsMTU+++T[30 chars]r.gz' - /private/var/folders/0-/0-cd8XI2HU86vol3rXsMTU+++TY/-Tmp-/tmpy8jleen7/archive.tar.gz ? -------- + /var/folders/0-/0-cd8XI2HU86vol3rXsMTU+++TY/-Tmp-/tmpy8jleen7/archive.tar.gz ====================================================================== FAIL: test_make_zipfile (test.test_shutil.TestShutil) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/buildbot/buildarea/3.5.murray-snowleopard/build/Lib/test/test_shutil.py", line 1075, in test_make_zipfile self.assertEqual(res, base_name + '.zip') AssertionError: '/private/var/folders/0-/0-cd8XI2HU86vol3rX[35 chars].zip' != '/var/folders/0-/0-cd8XI2HU86vol3rXsMTU+++T[27 chars].zip' - /private/var/folders/0-/0-cd8XI2HU86vol3rXsMTU+++TY/-Tmp-/tmpgs7euvvg/archive.zip ? -------- + /var/folders/0-/0-cd8XI2HU86vol3rXsMTU+++TY/-Tmp-/tmpgs7euvvg/archive.zip ---------------------------------------------------------------------- This was fixed in bbf72b164720. ---------- nosy: +ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 11:04:25 2015 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 08 Sep 2015 09:04:25 +0000 Subject: [issue25021] product_setstate() Out-of-bounds Read In-Reply-To: <1441684502.22.0.0994334100718.issue25021@psf.upfronthosting.co.za> Message-ID: <1441703065.38.0.493474549408.issue25021@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Interesting. Let me have a look. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 11:19:23 2015 From: report at bugs.python.org (koobs) Date: Tue, 08 Sep 2015 09:19:23 +0000 Subject: [issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2). In-Reply-To: <1441694117.96.0.393183554729.issue25026@psf.upfronthosting.co.za> Message-ID: <1441703963.86.0.82898163986.issue25026@psf.upfronthosting.co.za> koobs added the comment: @Serhiy If by "type of code at the time of commit" you mean upstream python code, msg250163 contains a link to what bits we replace in fcntlmodule.c and that "I -> k" has always been the same. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 11:36:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Sep 2015 09:36:51 +0000 Subject: [issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2). In-Reply-To: <1441694117.96.0.393183554729.issue25026@psf.upfronthosting.co.za> Message-ID: <1441705011.89.0.198053589347.issue25026@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Originally the type of the code variable in fcntl_ioctl() was int. In cbad1f5cabb1 it was changed to unsigned int. I guess that the log message that you cited was written before this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 11:46:02 2015 From: report at bugs.python.org (=?utf-8?q?Yves_M=C3=BCller?=) Date: Tue, 08 Sep 2015 09:46:02 +0000 Subject: [issue25028] Reading unicode json string fails depending on LANG env Message-ID: <1441705562.15.0.558425697033.issue25028@psf.upfronthosting.co.za> New submission from Yves M?ller: I am trying to read json containing a UTF-8 string from a file. It works when running it from a shell with LANG=en_GB.utf8 set, but fails from the empty environment. > python3 --version Python 3.4.0 > cat test.json { "test": "?ml?ute" } > env -u LANG python3 -c 'import json; json.load(open("test.json"))' Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.4/json/__init__.py", line 265, in load return loads(fp.read(), File "/usr/lib/python3.4/encodings/ascii.py", line 26, in decode return codecs.ascii_decode(input, self.errors)[0] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 11: ordinal not in range(128) > > env LANG=en_GB.UTF-8 python3 -c 'import json; print(json.load(open("test.json")))' {'test': '?ml?ute'} ---------- components: Unicode messages: 250175 nosy: ezio.melotti, haypo, yves priority: normal severity: normal status: open title: Reading unicode json string fails depending on LANG env versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 11:55:47 2015 From: report at bugs.python.org (eryksun) Date: Tue, 08 Sep 2015 09:55:47 +0000 Subject: [issue25023] time.strftime('%a'), ValueError: embedded null byte, in ko locale In-Reply-To: <1441690327.52.0.627876952587.issue25023@psf.upfronthosting.co.za> Message-ID: <1441706147.69.0.70916556001.issue25023@psf.upfronthosting.co.za> eryksun added the comment: It seems VC 14 has a bug here. In the new C runtime, strftime is implemented by calling wcsftime as follows: size_t const result = _Wcsftime_l(wstring.get(), maxsize, wformat.get(), timeptr, lc_time_arg, locale); if (result == 0) return 0; // Copy output from wide char string if (!WideCharToMultiByte(lc_time_cp, 0, wstring.get(), -1, string, static_cast(maxsize), nullptr, nullptr)) { __acrt_errno_map_os_error(GetLastError()); return 0; } return result; The WideCharToMultiByte call returns the number of bytes in the converted string, but strftime doesn't update the value of "result". This worked correctly in the old CRT. For example, in 3.4 built with VC 10: >>> sys.version_info[:2] (3, 4) >>> locale.setlocale(locale.LC_ALL, 'kor_kor') 'Korean_Korea.949' >>> time.strftime('%a') '\ud654' Here's an overview of the problem in 3.5, stepped through in the debugger: >>> sys.version_info[:2] (3, 5) >>> locale.setlocale(locale.LC_ALL, 'ko') 'ko' >>> time.strftime('%a') Breakpoint 0 hit ucrtbase!Wcsftime_l: 000007fe`e9e6fd74 48895c2410 mov qword ptr [rsp+10h],rbx ss:00000000`003df6d8=0000000000666ce0 wcsftime returns the output buffer length in wide characters: 0:000> pt; r rax rax=0000000000000001 WideCharToMultiByte is called to convert the wide-character string to the locale encoding: 0:000> pc ucrtbase!Strftime_l+0x17f: 000007fe`e9e6c383 ff15dfa00200 call qword ptr [ucrtbase!_imp_WideCharToMultiByte (000007fe`e9e96468)] ds:000007fe` e9e96468={KERNELBASE!WideCharToMultiByte (000007fe`fd631be0)} 0:000> p ucrtbase!Strftime_l+0x185: 000007fe`e9e6c389 85c0 test eax,eax This returns the length of the converted string (including the null): 0:000> r rax rax=0000000000000003 But strftime ignores this value, and instead returns the wide-character string length, which gets passed to PyUnicode_DecodeLocaleAndSize: 0:000> bp python35!PyUnicode_DecodeLocaleAndSize 0:000> g Breakpoint 1 hit python35!PyUnicode_DecodeLocaleAndSize: 00000000`5ec15160 4053 push rbx 0:000> r rdx rdx=0000000000000001 U+D654 was converted correctly to '\xc8\cad' (codepaged 949): 0:000> db @rcx l3 00000000`007e5d20 c8 ad 00 ... However, since (str[len] != '\0'), PyUnicode_DecodeLocaleAndSize errors out as follows: 0:000> bd 0,1; g Traceback (most recent call last): File "", line 1, in ValueError: embedded null byte It works as expected if the length is manually changed to 2: >>> time.strftime('%a') Breakpoint 1 hit python35!PyUnicode_DecodeLocaleAndSize: 00000000`5ec15160 4053 push rbx 0:000> r rdx=2 0:000> g '\ud654' The string is null-terminated, so can time_strftime simply substitute PyUnicode_DecodeLocale in place of PyUnicode_DecodeLocaleAndSize? ---------- components: +Windows nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 11:59:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Sep 2015 09:59:32 +0000 Subject: [issue25023] time.strftime('%a'), ValueError: embedded null byte, in ko locale In-Reply-To: <1441690327.52.0.627876952587.issue25023@psf.upfronthosting.co.za> Message-ID: <1441706372.56.0.0953409339868.issue25023@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +belopolsky -serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 12:30:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 08 Sep 2015 10:30:13 +0000 Subject: [issue25029] MemoryError in test_strptime Message-ID: <1441708213.63.0.825636103813.issue25029@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: All builds on edelsohn-fedora-ppc64 are red starting from build 55 for 3.x and build 41 for 3.5. 3.4 is green. http://buildbot.python.org/all/builders/PPC64%20Fedora%203.x/builds/55/ http://buildbot.python.org/all/builders/PPC64%20Fedora%203.5/builds/41/ ====================================================================== ERROR: test_TimeRE_recreation (test.test_strptime.CacheTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/shager/cpython-buildarea/3.5.edelsohn-fedora-ppc64/build/Lib/test/test_strptime.py", line 565, in test_TimeRE_recreation _strptime._strptime_time('10', '%d') File "/home/shager/cpython-buildarea/3.5.edelsohn-fedora-ppc64/build/Lib/_strptime.py", line 494, in _strptime_time tt = _strptime(data_string, format)[0] File "/home/shager/cpython-buildarea/3.5.edelsohn-fedora-ppc64/build/Lib/_strptime.py", line 312, in _strptime _TimeRE_cache = TimeRE() File "/home/shager/cpython-buildarea/3.5.edelsohn-fedora-ppc64/build/Lib/_strptime.py", line 190, in __init__ self.locale_time = LocaleTime() File "/home/shager/cpython-buildarea/3.5.edelsohn-fedora-ppc64/build/Lib/_strptime.py", line 75, in __init__ self.__calc_am_pm() File "/home/shager/cpython-buildarea/3.5.edelsohn-fedora-ppc64/build/Lib/_strptime.py", line 114, in __calc_am_pm am_pm.append(time.strftime("%p", time_tuple).lower()) MemoryError ---------------------------------------------------------------------- ---------- components: Extension Modules messages: 250177 nosy: David.Edelsohn, larry, serhiy.storchaka priority: normal severity: normal status: open title: MemoryError in test_strptime type: crash versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 12:54:55 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 08 Sep 2015 10:54:55 +0000 Subject: [issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2). In-Reply-To: <1441694117.96.0.393183554729.issue25026@psf.upfronthosting.co.za> Message-ID: <1441709695.64.0.246996997405.issue25026@psf.upfronthosting.co.za> Martin Panter added the comment: If necessary, perhaps we could unconditionally change the Python-level argument to unsigned_long, and then add a conditional bit in the C code to convert it to int if appropriate. But I wonder if most of the problem is fixed by Issue 1471 (linked from the commit Serhiy identified). As I see it, your patch should now only be needed to support ?code? values outside of the range of unsigned_int, e.g. that require > 32 bits. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 13:01:52 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 08 Sep 2015 11:01:52 +0000 Subject: [issue25025] Missing 3.5.0 RC3 tarballs (FTP) In-Reply-To: <1441690702.95.0.161159545328.issue25025@psf.upfronthosting.co.za> Message-ID: <1441710112.35.0.569409309505.issue25025@psf.upfronthosting.co.za> Martin Panter added the comment: They seem to be there now: https://www.python.org/ftp/python/3.5.0/Python-3.5.0rc3.tar.xz https://www.python.org/ftp/python/3.5.0/Python-3.5.0rc3.tgz Perhaps you were just too impatient? Or maybe confused by the strange sorting, EXE files following tar files? ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 13:08:00 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 08 Sep 2015 11:08:00 +0000 Subject: [issue25028] Reading unicode json string fails depending on LANG env In-Reply-To: <1441705562.15.0.558425697033.issue25028@psf.upfronthosting.co.za> Message-ID: <1441710480.23.0.874861462005.issue25028@psf.upfronthosting.co.za> Martin Panter added the comment: By default, open("test.json") will open the file in text mode, decoding from the encoding determined by your environment. See , in particular, ?The default encoding is platform dependent (whatever locale.getpreferredencoding() returns)?. If your file?s encoding is determined some other way, you should specify that other encoding. For JSON, I understand UTF-8 is generally always used, so you should call open("test.json", encoding="utf-8"). ---------- nosy: +martin.panter resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 13:19:39 2015 From: report at bugs.python.org (Petr Viktorin) Date: Tue, 08 Sep 2015 11:19:39 +0000 Subject: [issue24937] Multiple problems in getters & setters in capsulethunk.h In-Reply-To: <1440520892.99.0.130273606833.issue24937@psf.upfronthosting.co.za> Message-ID: <1441711179.53.0.865798468484.issue24937@psf.upfronthosting.co.za> Petr Viktorin added the comment: This patch removes capsulethunk.h from the docs, and directs the kind reader to the py3c project, which carries a fixed and tested version of it, along with the docs. Larry, would you be OK with releasing capsulethunk.h under the MIT license? The PSF license is not suitable for external projects, and mixing licenses is somewhat awkward. ---------- versions: -Python 3.3, Python 3.4 Added file: http://bugs.python.org/file40403/capsulethunk-py3c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 13:23:55 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 08 Sep 2015 11:23:55 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1441711435.43.0.50508803541.issue24999@psf.upfronthosting.co.za> Stefan Krah added the comment: Yes, according to C99 the shift is undefined: 6.5.7: "If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 13:26:48 2015 From: report at bugs.python.org (Petr Viktorin) Date: Tue, 08 Sep 2015 11:26:48 +0000 Subject: [issue13053] Add Capsule migration documentation to "cporting" In-Reply-To: <1317224248.53.0.263122473581.issue13053@psf.upfronthosting.co.za> Message-ID: <1441711608.49.0.923321543615.issue13053@psf.upfronthosting.co.za> Petr Viktorin added the comment: As capsulethunk.h is only needed for Python 2.6 and below, which are no longer maintained, in issue24937 we are discussing moving the header to an external project. ---------- nosy: +encukou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 13:37:48 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 08 Sep 2015 11:37:48 +0000 Subject: [issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules In-Reply-To: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za> Message-ID: <1441712268.23.0.691085247664.issue25027@psf.upfronthosting.co.za> Stefan Krah added the comment: If the scientific stack is unusable, I think this should be a release blocker. ---------- nosy: +skrah priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 13:39:27 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 08 Sep 2015 11:39:27 +0000 Subject: [issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules In-Reply-To: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za> Message-ID: <1441712367.51.0.831119946832.issue25027@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 13:50:25 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 08 Sep 2015 11:50:25 +0000 Subject: [issue25017] htmllib deprecated: Which library to use? Missing sane default in docs In-Reply-To: <1441616497.34.0.0999815194375.issue25017@psf.upfronthosting.co.za> Message-ID: <1441713025.42.0.995167572344.issue25017@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +easy stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 13:55:08 2015 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 08 Sep 2015 11:55:08 +0000 Subject: [issue25021] product_setstate() Out-of-bounds Read In-Reply-To: <1441684502.22.0.0994334100718.issue25021@psf.upfronthosting.co.za> Message-ID: <1441713308.65.0.514039833834.issue25021@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: An alternative patch. Please test this since I don't have a development system. ---------- keywords: +needs review Added file: http://bugs.python.org/file40404/itertoolsmodule.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 13:56:58 2015 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Tue, 08 Sep 2015 11:56:58 +0000 Subject: [issue25021] product_setstate() Out-of-bounds Read In-Reply-To: <1441684502.22.0.0994334100718.issue25021@psf.upfronthosting.co.za> Message-ID: <1441713418.29.0.964853548716.issue25021@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: There are two problems with the previous patch: 1) it can put out of bounds values into lz->indices. This can cause problems then next time product_next() is called. 2) the case of a pool having zero size is not dealt with (it wasn't before either). My patch should deal with both cases, but please verify since I don't have access to a python dev system at the moment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 14:02:19 2015 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 08 Sep 2015 12:02:19 +0000 Subject: [issue25014] Add contextlib.itercm() In-Reply-To: <1441542735.79.0.482816688867.issue25014@psf.upfronthosting.co.za> Message-ID: <1441713739.33.0.920266042263.issue25014@psf.upfronthosting.co.za> Ezio Melotti added the comment: > Having spent a few days pondering this after Ezio first mentioned the > concept to me on IRC, I'm rejecting this on the basis of "not every 3 > line function needs to be in the standard library". When I first mentioned this to Nick on IRC, the implementation of itercm() was a not-so-trivial function that called __enter__/__exit__ manually while catching StopIteration. It only occurred to me while posting this issue, that the same could be achieved with a simple `yield from` in a `with`. I also didn't realize that the __exit__ called in case of error in the attached example was triggered by the garbage collector. I therefore agree that a somewhat obscure and non-deterministic three-liner doesn't belong in the standard library. Thanks everyone for the feedback! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 14:03:58 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 08 Sep 2015 12:03:58 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1441713838.64.0.450137550582.issue24999@psf.upfronthosting.co.za> Stefan Krah added the comment: Perhaps the stack overflow hypothesis applies here, too. You could try changing Py_DEFAULT_RECURSION_LIMIT in ceval.c to lower values. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 14:26:39 2015 From: report at bugs.python.org (Larry Hastings) Date: Tue, 08 Sep 2015 12:26:39 +0000 Subject: [issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules In-Reply-To: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za> Message-ID: <1441715199.55.0.312154589239.issue25027@psf.upfronthosting.co.za> Larry Hastings added the comment: This is your wheelhouse, Steve. ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 14:28:35 2015 From: report at bugs.python.org (Larry Hastings) Date: Tue, 08 Sep 2015 12:28:35 +0000 Subject: [issue25029] MemoryError in test_strptime In-Reply-To: <1441708213.63.0.825636103813.issue25029@psf.upfronthosting.co.za> Message-ID: <1441715315.23.0.155126047523.issue25029@psf.upfronthosting.co.za> Larry Hastings added the comment: Any clue here? Is this unaligned access? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 14:32:21 2015 From: report at bugs.python.org (Larry Hastings) Date: Tue, 08 Sep 2015 12:32:21 +0000 Subject: [issue24937] Multiple problems in getters & setters in capsulethunk.h In-Reply-To: <1440520892.99.0.130273606833.issue24937@psf.upfronthosting.co.za> Message-ID: <1441715541.93.0.737194118992.issue24937@psf.upfronthosting.co.za> Larry Hastings added the comment: I'm the author of capsulethunk.h, and I am happy to relicense it under MIT. How would you feel about leaving capsulethunk.h there, for posterity's sakes, but adding "for updates please see py3c"? We could even update the capsulethunk.h there. I'm not saying "we have to do it this way", I'm asking whether the users would be better served by leaving the example around vs removing it and forcing them to go looking on an external web site. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 14:35:56 2015 From: report at bugs.python.org (David Edelsohn) Date: Tue, 08 Sep 2015 12:35:56 +0000 Subject: [issue25029] MemoryError in test_strptime In-Reply-To: <1441708213.63.0.825636103813.issue25029@psf.upfronthosting.co.za> Message-ID: <1441715756.1.0.722706665025.issue25029@psf.upfronthosting.co.za> David Edelsohn added the comment: PPC64 is not a strict alignment system. The system is running a non-recent release of Fedora, so it could be a bad interaction with libc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 14:41:22 2015 From: report at bugs.python.org (koobs) Date: Tue, 08 Sep 2015 12:41:22 +0000 Subject: [issue25025] Missing 3.5.0 RC3 tarballs (FTP) In-Reply-To: <1441690702.95.0.161159545328.issue25025@psf.upfronthosting.co.za> Message-ID: <1441716082.03.0.622775670582.issue25025@psf.upfronthosting.co.za> koobs added the comment: @Martin, weird, I'm still not seeing any files/dirs matching 'rc3'. I have refreshed properly (cache-control 0 + empty cache) and still getting a similar listing. Fresh fetch output on the index URL: Python-3.5.0rc1.tar.xz 11-Aug-2015 01:00 14798596^M Python-3.5.0rc1.tar.xz.asc 11-Aug-2015 01:00 819^M Python-3.5.0rc1.tgz 11-Aug-2015 00:59 20038557^M Python-3.5.0rc1.tgz.asc 11-Aug-2015 01:00 819^M Python-3.5.0rc2.tar.xz 25-Aug-2015 17:26 14841476^M Python-3.5.0rc2.tar.xz.asc 25-Aug-2015 17:26 819^M Python-3.5.0rc2.tgz 25-Aug-2015 17:25 20055455^M Python-3.5.0rc2.tgz.asc 25-Aug-2015 17:26 819^M python-3.5.0a1-amd64-webinstall.exe 08-Feb-2015 03:14 916296^M python-3.5.0a1-amd64.exe 08-Feb-2015 03:14 22844576^M python-3.5.0a1-macosx10.5.pkg 08-Feb-2015 02:28 25160803^M python-3.5.0a1-macosx10.5.pkg.asc 8-Feb-2015 02:28 819^M Resolved host is: 103.245.222.223 Perhaps too-aggressive cache configuration, or not so good revalidate settings @ Fastly? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 14:47:45 2015 From: report at bugs.python.org (Mark Roseman) Date: Tue, 08 Sep 2015 12:47:45 +0000 Subject: [issue16893] Generate Idle help from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1441716465.43.0.389549641714.issue16893@psf.upfronthosting.co.za> Mark Roseman added the comment: Ok. In case you're curious or might find it useful elsewhere, I've attached sphinxview.py, which renders the HTML into a text widget (with formatting, it's not converted to plain text). ---------- Added file: http://bugs.python.org/file40405/sphinxview.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 15:19:35 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 08 Sep 2015 13:19:35 +0000 Subject: [issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules In-Reply-To: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za> Message-ID: <1441718375.87.0.67886779686.issue25027@psf.upfronthosting.co.za> Steve Dower added the comment: Let me experiment today with a few of the proposals I posted in the other thread and get back to you. I suspect someone will need to ship vcruntime.dll, and I'd rather it was the extension. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 15:20:09 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 08 Sep 2015 13:20:09 +0000 Subject: [issue25022] Remove PC/example_nt/ In-Reply-To: <1441687350.45.0.29239152419.issue25022@psf.upfronthosting.co.za> Message-ID: <1441718409.2.0.983767839036.issue25022@psf.upfronthosting.co.za> Steve Dower added the comment: Go for it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 15:30:56 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Sep 2015 13:30:56 +0000 Subject: [issue25029] MemoryError in test_strptime In-Reply-To: <1441708213.63.0.825636103813.issue25029@psf.upfronthosting.co.za> Message-ID: <1441719056.26.0.724289421821.issue25029@psf.upfronthosting.co.za> STINNER Victor added the comment: I ran test_strptime & test_os with tracemalloc: test_os memory peak is higher than test_strptime memory peak (I ran the two tests independently). So the bug cannot be reproduce on my Fedora 22 (x86_64). ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 15:37:29 2015 From: report at bugs.python.org (Petr Viktorin) Date: Tue, 08 Sep 2015 13:37:29 +0000 Subject: [issue24937] Multiple problems in getters & setters in capsulethunk.h In-Reply-To: <1440520892.99.0.130273606833.issue24937@psf.upfronthosting.co.za> Message-ID: <1441719449.32.0.468126844231.issue24937@psf.upfronthosting.co.za> Petr Viktorin added the comment: Thank you for the license. I mentioned my project mainly as a place where this code can be *tested*. I have no problem with keeping capsulethunk.h in the Python docs, and synchronizing the two projects if changes are made on either side. In other words, feel free to use the first patch :) Regarding users ? in my opinion, including a whole header directly in the docs is questionable (to me it smells of untested copy-paste code), and the link goes to hg.python.org ? an external site from the users' point of view. Also, if someone needs to port CObject, their extension is very likely to be complicated enough to need much more material than the HOWTO provides. See py3c's `modernization docs`_ for several things the HOWTO doesn't address. So, in my obviously biased opinion, linking to py3c will help users. (Perhaps a link to py3c should be at the top of the HOWTO, but that's not for this issue. I'm working to get to a point where I'm comfortable suggesting that.) There's obviously the question of whether I should be improving the HOWTO rather than starting my own thing. I have three reasons: testability, the fact that py3c docs are already way too long for a HOWTO, and the fact that py3c is quite opinionated. (The more opinionated, the more more in-depth the solutions can be. I've been toning it down lately, though.) _ modernization docs: http://py3c.readthedocs.org/en/latest/guide-modernization.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 15:40:36 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Sep 2015 13:40:36 +0000 Subject: [issue25029] MemoryError in test_strptime In-Reply-To: <1441708213.63.0.825636103813.issue25029@psf.upfronthosting.co.za> Message-ID: <1441719636.76.0.900261937713.issue25029@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh wait, the VmPeak is *much* high when running test_strptime: * test_os VmPeak: 380 992 kB * test_strptime VmPeak: 8 608 972 kB (8 GB!?) 1 GB should be enough for everybody: $ bash -c 'ulimit -v 1000000; ./python -m test -v test_strptime' .. ====================================================================== ERROR: test_TimeRE_recreation (test.test_strptime.CacheTests) ---------------------------------------------------------------------- Traceback (most recent call last): ... File "/home/haypo/prog/python/default/Lib/_strptime.py", line 75, in __init__ self.__calc_am_pm() File "/home/haypo/prog/python/default/Lib/_strptime.py", line 114, in __calc_am_pm am_pm.append(time.strftime("%p", time_tuple).lower()) MemoryError ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 15:44:41 2015 From: report at bugs.python.org (shiyao.ma) Date: Tue, 08 Sep 2015 13:44:41 +0000 Subject: [issue25030] io.[Text]IOBase.seek doesn't take keyword parameter Message-ID: <1441719881.64.0.378247085729.issue25030@psf.upfronthosting.co.za> New submission from shiyao.ma: The doc is here: https://docs.python.org/3.5/library/io.html#io.IOBase.seek and here: https://docs.python.org/3.5/library/io.html#io.TextIOBase.seek It is said the parameter list is in the form of: seek(offset, whence=SEEK_SET) But actually only: seek(offset) or seek(offset, whence) is allowed. Passing seek(offset, whence=SEEK_FOOBAR) will throw an error. The patch fixes the function signature as seek(offset[, whence]) ---------- assignee: docs at python components: Documentation files: seek.patch keywords: patch messages: 250200 nosy: berker.peksag, docs at python, ezio.melotti, introom priority: normal severity: normal status: open title: io.[Text]IOBase.seek doesn't take keyword parameter versions: Python 3.5 Added file: http://bugs.python.org/file40406/seek.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 15:48:53 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Sep 2015 13:48:53 +0000 Subject: [issue25029] MemoryError in test_strptime In-Reply-To: <1441708213.63.0.825636103813.issue25029@psf.upfronthosting.co.za> Message-ID: <1441720133.17.0.887147122077.issue25029@psf.upfronthosting.co.za> STINNER Victor added the comment: It's a regression introduced by c31dad22c80d (Issue #24917). ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 15:49:20 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Sep 2015 13:49:20 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441720160.57.0.672033196875.issue24917@psf.upfronthosting.co.za> STINNER Victor added the comment: The change c31dad22c80d introduced a regression: issue #25029. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 15:52:21 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Sep 2015 13:52:21 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441720341.33.0.381520756076.issue24917@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, tracemalloc sees the memory peak of 8 GB too: $ ./python -X tracemalloc -i -m test -v test_strptime ... SystemExit: True >>> import tracemalloc; tracemalloc.get_traced_memory()[1] / 1024.**2 8201.658247947693 Memory peak: 8201.7 MB (8.2 GB!). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 15:58:31 2015 From: report at bugs.python.org (Tim Tisdall) Date: Tue, 08 Sep 2015 13:58:31 +0000 Subject: [issue24984] document AF_BLUETOOTH socket address formats In-Reply-To: <1441210010.76.0.198064903239.issue24984@psf.upfronthosting.co.za> Message-ID: <1441720711.36.0.0381367881096.issue24984@psf.upfronthosting.co.za> Tim Tisdall added the comment: Martin, looks good. Thanks for pointing out how to properly tag the version change, and thanks for adding me to the ACKS file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 16:01:27 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 08 Sep 2015 14:01:27 +0000 Subject: [issue25029] MemoryError in test_strptime In-Reply-To: <1441708213.63.0.825636103813.issue25029@psf.upfronthosting.co.za> Message-ID: <1441720887.17.0.91726182769.issue25029@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I would blame this change: . The rest should not have any effect on Linux. ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 16:10:52 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Sep 2015 14:10:52 +0000 Subject: [issue25029] MemoryError in test_strptime In-Reply-To: <1441708213.63.0.825636103813.issue25029@psf.upfronthosting.co.za> Message-ID: <1441721451.99.0.380501262334.issue25029@psf.upfronthosting.co.za> STINNER Victor added the comment: Script to reproduce the issue: --- import time import locale import pprint time_tuple = time.struct_time((1999,3,17,1,44,55,2,76,0)) p1 = time.strftime("%p", time_tuple) print("current LC_TIME", repr(p1)) locale.setlocale(locale.LC_TIME, ('de_DE', 'UTF8')) p2 = time.strftime("%p", time_tuple) print("de_DE (UTF8)", repr(p2)) --- Output: --- $ python3.4 bug.py current LC_TIME 'AM' de_DE (UTF8) '' --- The problem is that strftime()/wcsftime() *can* return 0, it's not an error. Whereas c31dad22c80d considers that if buflen is 0 but fmtlen is smaller than 5, we must retry with a larger buffer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 16:13:05 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Sep 2015 14:13:05 +0000 Subject: [issue25029] MemoryError in test_strptime In-Reply-To: <1441708213.63.0.825636103813.issue25029@psf.upfronthosting.co.za> Message-ID: <1441721585.27.0.798943391411.issue25029@psf.upfronthosting.co.za> STINNER Victor added the comment: Again, this issue remembers me the idea of rewriting strftime() in Python. We already have _strptime.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 16:25:01 2015 From: report at bugs.python.org (David Barnett) Date: Tue, 08 Sep 2015 14:25:01 +0000 Subject: [issue25012] pathlib should allow converting to absolute paths without resolving symlinks In-Reply-To: <1441490748.21.0.647656961559.issue25012@psf.upfronthosting.co.za> Message-ID: <1441722301.71.0.310351160424.issue25012@psf.upfronthosting.co.za> David Barnett added the comment: Right, and to clarify a bit further why I didn't just use A.resolve() == B.resolve() from the beginning, this is in a unit test where the equality check wasn't in my code. I wanted to assert I received a certain call on my mock, like mock_open_method.assert_called_once_with(pathlib.Path('foo')) so it's much more convenient to be able to create a path object that matches with my target path instead of more complicated matching. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 16:28:02 2015 From: report at bugs.python.org (David Barnett) Date: Tue, 08 Sep 2015 14:28:02 +0000 Subject: [issue25012] pathlib should allow converting to absolute paths without resolving symlinks In-Reply-To: <1441490748.21.0.647656961559.issue25012@psf.upfronthosting.co.za> Message-ID: <1441722482.1.0.889272117097.issue25012@psf.upfronthosting.co.za> David Barnett added the comment: And the symlinks for my paths refer to really cryptic hashes in a virtual filesystem for the tests, so rendering them into the assertion failed errors would really make the failure messages hard to interpret. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 16:29:21 2015 From: report at bugs.python.org (Michael Foord) Date: Tue, 08 Sep 2015 14:29:21 +0000 Subject: [issue25000] _mock_call does not properly grab args and kwargs In-Reply-To: <1441369541.43.0.73938065209.issue25000@psf.upfronthosting.co.za> Message-ID: <1441722561.78.0.972027427282.issue25000@psf.upfronthosting.co.za> Michael Foord added the comment: This is actually the specified and documented behaviour of mock when it is passed mutable arguments. Deep copying arguments on calls is rife with potential problems (not everything can be copied and it breaks comparison by identity). The documentation suggests ways around this: https://docs.python.org/3/library/unittest.mock-examples.html#coping-with-mutable-arguments ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 16:39:21 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Sep 2015 14:39:21 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1441723161.23.0.231446789619.issue25003@psf.upfronthosting.co.za> Guido van Rossum added the comment: Also, Theo believes that our Mersenne Twister is outdated and os.urandom() is the only reasonable alternative. So we might as well keep it fast. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 17:14:18 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 08 Sep 2015 15:14:18 +0000 Subject: [issue25029] MemoryError in test_strptime In-Reply-To: <1441708213.63.0.825636103813.issue25029@psf.upfronthosting.co.za> Message-ID: <1441725258.19.0.113874781394.issue25029@psf.upfronthosting.co.za> Steve Dower added the comment: Sorry Larry. I'll fix it. ---------- assignee: -> steve.dower priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 17:15:28 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 08 Sep 2015 15:15:28 +0000 Subject: [issue24917] time_strftime() Buffer Over-read In-Reply-To: <1440286759.85.0.888607571963.issue24917@psf.upfronthosting.co.za> Message-ID: <1441725328.85.0.907351623659.issue24917@psf.upfronthosting.co.za> Steve Dower added the comment: I'll fix it on #25029. This thread is already too long for my liking. ---------- resolution: -> fixed status: open -> closed superseder: -> MemoryError in test_strptime _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 17:20:18 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 08 Sep 2015 15:20:18 +0000 Subject: [issue25002] Deprecate asyncore/asynchat In-Reply-To: <1441399683.85.0.786847810998.issue25002@psf.upfronthosting.co.za> Message-ID: <1441725618.24.0.6246322929.issue25002@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, stopping changing asyncore/asynchat also means it becomes a stable target for people who *are* using it for 2/3 code. We may have effectively done this already (without closing the open issues): the last asyncore-specific change (as opposed to library-wide changes that also hit asyncore) was a ResourceWarning added by Victor in June of 2014. Likewise for asynchat. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 17:25:46 2015 From: report at bugs.python.org (eryksun) Date: Tue, 08 Sep 2015 15:25:46 +0000 Subject: [issue25029] MemoryError in test_strptime In-Reply-To: <1441708213.63.0.825636103813.issue25029@psf.upfronthosting.co.za> Message-ID: <1441725946.65.0.378260442417.issue25029@psf.upfronthosting.co.za> eryksun added the comment: Steve, it seems to me that for MSVC the EINVAL test should come first: _Py_BEGIN_SUPPRESS_IPH olderr = errno; errno = 0; buflen = format_time(outbuf, i, fmt, &buf); err = errno; errno = olderr; _Py_END_SUPPRESS_IPH if (buflen == 0 && err == EINVAL) { PyErr_SetString(PyExc_ValueError, "Invalid format string"); break; } Then the old test could be restored, i.e. (buflen > 0 || i >= 256 * fmtlen). ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 17:31:47 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 08 Sep 2015 15:31:47 +0000 Subject: [issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules In-Reply-To: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za> Message-ID: <1441726307.61.0.09332473299.issue25027@psf.upfronthosting.co.za> Stefan Krah added the comment: Is Python-core built with /MD? I cannot see the flags in the buildbot logs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 17:31:48 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 08 Sep 2015 15:31:48 +0000 Subject: [issue25024] Allow passing "delete=False" to TemporaryDirectory In-Reply-To: <1441690580.39.0.270846340544.issue25024@psf.upfronthosting.co.za> Message-ID: <1441726308.28.0.538764891798.issue25024@psf.upfronthosting.co.za> R. David Murray added the comment: The two cases are not parallel, in that NamedTemporaryFile closes the file at the end of the context manager, whereas the *only* thing the TemporaryDirectory does is delete the directory on cleanup. There is some value to the "parallel interface" argument, so I'm only -0 on this. ---------- nosy: +r.david.murray type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 17:34:43 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 08 Sep 2015 15:34:43 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1441726483.4.0.680011134793.issue24999@psf.upfronthosting.co.za> R. David Murray added the comment: Ah, interesting. We know that there are stack overflow issues on the ICC windows build (they show up consistently in a debug build). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 17:35:29 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 08 Sep 2015 15:35:29 +0000 Subject: [issue25029] MemoryError in test_strptime In-Reply-To: <1441708213.63.0.825636103813.issue25029@psf.upfronthosting.co.za> Message-ID: <1441726529.94.0.078910710163.issue25029@psf.upfronthosting.co.za> Steve Dower added the comment: @eryksun - that's exactly what I've just done :) Unfortunately, I don't have a _locale module, so I can't do Victor's test. Attached my patch in case Victor is around to test it. ---------- keywords: +patch Added file: http://bugs.python.org/file40407/25029_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 17:36:10 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 08 Sep 2015 15:36:10 +0000 Subject: [issue25025] Missing 3.5.0 RC3 tarballs (FTP) In-Reply-To: <1441690702.95.0.161159545328.issue25025@psf.upfronthosting.co.za> Message-ID: <1441726570.29.0.0606340346073.issue25025@psf.upfronthosting.co.za> Berker Peksag added the comment: koobs and I have confirmed(on #python-dev) this was a cache issue. ---------- nosy: +berker.peksag resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 17:40:07 2015 From: report at bugs.python.org (koobs) Date: Tue, 08 Sep 2015 15:40:07 +0000 Subject: [issue25025] Missing 3.5.0 RC3 tarballs (FTP) on Fastly nodes In-Reply-To: <1441690702.95.0.161159545328.issue25025@psf.upfronthosting.co.za> Message-ID: <1441726807.31.0.979868860366.issue25025@psf.upfronthosting.co.za> koobs added the comment: Was a bug, now fixed (adjust title/resolution to compensate) Thanks Berker! ---------- resolution: not a bug -> fixed title: Missing 3.5.0 RC3 tarballs (FTP) -> Missing 3.5.0 RC3 tarballs (FTP) on Fastly nodes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 17:40:48 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 08 Sep 2015 15:40:48 +0000 Subject: [issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules In-Reply-To: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za> Message-ID: <1441726848.28.0.237718887441.issue25027@psf.upfronthosting.co.za> Steve Dower added the comment: Kind-of... We use the same flags I described in my blog[1] so that we don't have any version-specific dependencies. You should (might) see /MT in the build logs, but then we replace most of the static CRT with the dynamic (but versionless) one. The versioned parts (including the FlsAlloc call - module initialization is compiler version specific) are statically linked. I'm going to try and update distutils to build with /MD again (sorry Christoph!) and include vcruntime###.dll in the output. That way, people who bdist_wheel will include all of their own dependencies and don't have to worry about whether users are on Python 3.5.0 or 3.9.9. [1]: http://stevedower.id.au/blog/building-for-python-3-5/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 17:40:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Sep 2015 15:40:49 +0000 Subject: [issue25002] Deprecate asyncore/asynchat In-Reply-To: <1441725618.24.0.6246322929.issue25002@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: If you care of smooth python 2 => python 3 migration, I suggest to deprecate smtpd and remove it later, when asyncore & asynchat will also be removed (ex: in Python 4?). I suggest to write a *new* SMTP server module using asyncio. As I explained, the API will be very different for the user of the API. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 17:41:07 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 08 Sep 2015 15:41:07 +0000 Subject: [issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules In-Reply-To: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za> Message-ID: <1441726867.32.0.484407163763.issue25027@psf.upfronthosting.co.za> Stefan Krah added the comment: It seems to be /MTd. Sorry for the noise (and yay! for horizontal scrolling :). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 17:44:21 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Sep 2015 15:44:21 +0000 Subject: [issue25029] MemoryError in test_strptime In-Reply-To: <1441708213.63.0.825636103813.issue25029@psf.upfronthosting.co.za> Message-ID: <1441727061.16.0.662211059529.issue25029@psf.upfronthosting.co.za> STINNER Victor added the comment: My test runs the following command on Linux (Fedora 22): make && bash -c 'ulimit -v 1000000; ./python -u -m test -v test_strptime' * current default branch (rev 3c0c153d6b02): MemoryError * with 25029_1.patch: the test pass ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 17:45:42 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 08 Sep 2015 15:45:42 +0000 Subject: [issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules In-Reply-To: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za> Message-ID: <1441727142.44.0.403638477507.issue25027@psf.upfronthosting.co.za> Stefan Krah added the comment: The reason I asked: We had issues where extension modules linked against a different CRT had isolated locale settings from the interpreter, i.e., changes made by the module would not be seen by the interpreter. I don't know if this is still an issue with the new runtimes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 17:49:34 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 08 Sep 2015 15:49:34 +0000 Subject: [issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules In-Reply-To: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za> Message-ID: <1441727374.91.0.0597027547158.issue25027@psf.upfronthosting.co.za> Steve Dower added the comment: It shouldn't be - locale state is in the shared part of the CRT. That is one of the reasons I was keen to move to this model (everyone seems to think that FILE* is the only problem with mixing CRT versions :) ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 17:52:03 2015 From: report at bugs.python.org (Stefan Krah) Date: Tue, 08 Sep 2015 15:52:03 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1441727523.48.0.735457325661.issue24999@psf.upfronthosting.co.za> Stefan Krah added the comment: Visual studio apparently has the option /F to set the stack size. Maybe ICC has one, too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 17:53:19 2015 From: report at bugs.python.org (Mark Roseman) Date: Tue, 08 Sep 2015 15:53:19 +0000 Subject: [issue25031] IDLE - file list improvements Message-ID: <1441727599.54.0.0383020553407.issue25031@psf.upfronthosting.co.za> New submission from Mark Roseman: This is a placeholder for what will be a series of patches to the FileList to generalize and enhance it. This is part of generalizing pieces of IDLE to be more flexible, including things like editors not necessarily being in toplevel windows, dialogs not being modal, etc. The goal is to turn the FileList into an application "hub" that knows about the various pieces of the application, and can be used for communication between them. Some aspects of this will include: 1. Ensuring other modules don't use internal implementation (e.g. dict/inversedict) so can change it later. 2. Merging PyShellFileList into here (will keep things simpler). 3. Having FileList launch/keep track of certain dialogs (e.g. config) or other non-editor components. 4. Eventually take on some other responsibilities from editors, part of a general component/container refactoring. ---------- components: IDLE messages: 250229 nosy: kbk, markroseman, roger.serwy, terry.reedy priority: normal severity: normal status: open title: IDLE - file list improvements type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 17:56:46 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 08 Sep 2015 15:56:46 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1441727806.84.0.0609027053957.issue24999@psf.upfronthosting.co.za> R. David Murray added the comment: By the way Stefan, if you want a copy of the ICC compiler to test with, you can contact Robert.S.Cohn at intel.com. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 18:02:56 2015 From: report at bugs.python.org (Mark Roseman) Date: Tue, 08 Sep 2015 16:02:56 +0000 Subject: [issue25031] IDLE - file list improvements In-Reply-To: <1441727599.54.0.0383020553407.issue25031@psf.upfronthosting.co.za> Message-ID: <1441728176.58.0.878424385181.issue25031@psf.upfronthosting.co.za> Mark Roseman added the comment: This first patch is a straight refactoring so that other modules do not touch the FileList internals. This is done in two steps. First, we remove references to inversedict etc. from outside FileList. Second, we run all notifications through FileList. So for example when the config dialog wants to notify all editors of changes, it previously walked through the list of windows and called various editor methods directly. Now, the config dialog asks FileList to notify all editors. Each editor implements the callback to make the needed changes. Same code, just moved to a more appropriate place. The config dialog no longer needs any knowledge of FileList or of EditorWindow. Later more of these sorts of callbacks will be added. Doing it this way provides a framework where different components might respond differently to these notifications. ---------- keywords: +patch Added file: http://bugs.python.org/file40408/hide_flist_internals.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 18:11:46 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 08 Sep 2015 16:11:46 +0000 Subject: [issue25002] Deprecate asyncore/asynchat In-Reply-To: <1441399683.85.0.786847810998.issue25002@psf.upfronthosting.co.za> Message-ID: <1441728706.11.0.0793666801512.issue25002@psf.upfronthosting.co.za> Brett Cannon added the comment: Victor's suggestion also aligns with my thinking on the subject as well: deprecate the modules but simply leave them sitting there for compatibility reasons until Python 4 of whenever we feel like the Python 2 transition is done for those that will ever bother making the switch. That way people's expectations are in the proper alignment of where things will end up and code won't break if it straddles Python 2 & 3 short of having to silence a deprecation warning. I think this is a good use of PendingDeprecationWarning and the message both in the deprecation and the docs can make it clear that the removal date is not planned but you should avoid using the module in new code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 18:14:52 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Sep 2015 16:14:52 +0000 Subject: [issue25002] Deprecate asyncore/asynchat In-Reply-To: <1441399683.85.0.786847810998.issue25002@psf.upfronthosting.co.za> Message-ID: <1441728892.95.0.470347892974.issue25002@psf.upfronthosting.co.za> STINNER Victor added the comment: > Ideally these modules should emit a deprecation warning starting in 3.6 Is it ok to add the PendingDeprecationWarning in Python 3.5.1? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 18:29:28 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Sep 2015 16:29:28 +0000 Subject: [issue25002] Deprecate asyncore/asynchat In-Reply-To: <1441399683.85.0.786847810998.issue25002@psf.upfronthosting.co.za> Message-ID: <1441729768.83.0.00255697315205.issue25002@psf.upfronthosting.co.za> Guido van Rossum added the comment: > Is it ok to add the PendingDeprecationWarning in Python 3.5.1? I prefer to wait until 3.6. A bugfix release should not rock the boat, it should not make your code emit new warnings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 18:42:56 2015 From: report at bugs.python.org (Mark Roseman) Date: Tue, 08 Sep 2015 16:42:56 +0000 Subject: [issue24813] Idle Help dialogs shouldn't be modal In-Reply-To: <1438921182.01.0.453311500566.issue24813@psf.upfronthosting.co.za> Message-ID: <1441730576.4.0.717250248314.issue24813@psf.upfronthosting.co.za> Mark Roseman added the comment: Have attached about.patch, which changes the about dialog to no longer be modal, as well as does a substantial redesign, where the various help texts are displayed within the dialog itself, rather than launching (further modal) new windows. Note: this new dialog works on both Tk 8.4 and 8.5+ ---------- keywords: +patch Added file: http://bugs.python.org/file40409/about.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 18:58:23 2015 From: report at bugs.python.org (Mark Roseman) Date: Tue, 08 Sep 2015 16:58:23 +0000 Subject: [issue18590] Found text not always highlighted by Replace dialog on Windows In-Reply-To: <1375128565.7.0.113615028691.issue18590@psf.upfronthosting.co.za> Message-ID: <1441731503.57.0.0628483705626.issue18590@psf.upfronthosting.co.za> Mark Roseman added the comment: See #24972 for fix ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 18:59:00 2015 From: report at bugs.python.org (Mark Roseman) Date: Tue, 08 Sep 2015 16:59:00 +0000 Subject: [issue22179] Idle. Search dialog found text not highlited on Windows In-Reply-To: <1407672062.65.0.813743837574.issue22179@psf.upfronthosting.co.za> Message-ID: <1441731540.6.0.786416767175.issue22179@psf.upfronthosting.co.za> Mark Roseman added the comment: See #24972 for fix ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 18:59:53 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 08 Sep 2015 16:59:53 +0000 Subject: [issue16893] Generate Idle help from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1441731593.16.0.514269923291.issue16893@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This looks more maintainable than I expected, so I will definite try it out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 19:01:01 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 08 Sep 2015 17:01:01 +0000 Subject: [issue25002] Deprecate asyncore/asynchat In-Reply-To: <1441399683.85.0.786847810998.issue25002@psf.upfronthosting.co.za> Message-ID: <1441731661.05.0.375416552383.issue25002@psf.upfronthosting.co.za> Raymond Hettinger added the comment: In addition to a PendingDeprecationWarning in 3.6, it might be nice to put a note in the asyncore/asynchat docs like we did for optparse. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 19:04:58 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 08 Sep 2015 17:04:58 +0000 Subject: [issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules In-Reply-To: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za> Message-ID: <1441731898.05.0.568578222761.issue25027@psf.upfronthosting.co.za> Steve Dower added the comment: Attached a fix for distutils that will include the required vcruntime DLL with the extension. This is purely Python source code and only needs to be patched on the build machine. I have tested with a numpy build from source (setup.py bdist_wheel) and it works correctly on a clean Win7 machine with only a Python 3.5.0rc3 install. When multiple vcruntime###.dll files are available, the first one that is loaded wins. This means that if you can guarantee a particular import occurs first, you can omit the DLL elsewhere in your package. There is no way to determine this automatically, Because of the way I wrote the patch, if you build with DISTUTILS_USE_SDK set, you will get the old static linking unless you also define PY_VCRUNTIME_REDIST to the path of the file to include. If the redist file cannot be found (you probably don't have the compiler either, but assuming you do), you will get the old static linking. I think this is the right balance of "works-by-default" and "I know what I'm doing let me control it" (though now I put them next to each other, I could rename the variable to DISTUTILS_VCRUNTIME_REDIST). Will work up a test for it, but wanted to get feedback on the approach first. ---------- keywords: +patch Added file: http://bugs.python.org/file40410/25027_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 19:20:55 2015 From: report at bugs.python.org (Tim Peters) Date: Tue, 08 Sep 2015 17:20:55 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1441732855.36.0.511648936065.issue25003@psf.upfronthosting.co.za> Tim Peters added the comment: Guido, you're clearly talking with someone who knows too much ;-) If we're using the Twister for _anything_ related to crypto-level randomness, then I'd appalled - it was utterly unsuitable for any such purpose from day 1. But as a general-purpose generator for non-crypto uses, it remains an excellent choice, and still a nearly de facto standard for "almost all" such purposes. There are general-purpose generators I like better now, but won't push in that direction until the Twister's "nearly de facto standard" status fades. Better to be a follower than a leader in this area. ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 19:22:33 2015 From: report at bugs.python.org (Mark Roseman) Date: Tue, 08 Sep 2015 17:22:33 +0000 Subject: [issue25032] IDLE - same menubar across application Message-ID: <1441732953.33.0.194435848116.issue25032@psf.upfronthosting.co.za> New submission from Mark Roseman: Right now the menubar is slightly different for the shell (has Debug) and the editor windows (has Format and Run). I'd like to suggest the same menubar be used for all windows. Rationale: 1. Easier to use, especially for systems that share a single menubar visually across the top of screen. 2. Later on we'll likely have situations where shell and one or more editors are part of the same toplevel window. Implementation Notes: 1. Tk lets you reuse the same menubar across multiple toplevel windows (it actually creates a 'clone' every time it gets attached to the window). 2. This will simplify code e.g. for managing help and windows menus, which now have to do the same thing for multiple menubars. 3. Using tabbed windows, while it's possible to swap the menubar on the fly as you swap windows, it's not necessarily desirable to do so. 4. I've mocked up a system for menu validation/dispatch that will simplify how menu commands are handled now depending on what window is in front, and makes it easier to ensure the right things are enabled/disabled based on context. ---------- components: IDLE messages: 250242 nosy: kbk, markroseman, roger.serwy, terry.reedy priority: normal severity: normal status: open title: IDLE - same menubar across application versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 19:29:12 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Sep 2015 17:29:12 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1441733352.28.0.752698192813.issue25003@psf.upfronthosting.co.za> Guido van Rossum added the comment: To Theo it's probably inconceivable that anyone would be using random numbers for anything besides crypto security. :-) His favorite is arc4random() (but he notes it's not based on RC4 anymore, but uses chacha -- I have no idea what any of that means :-). He did say userland PRNG a few times. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 19:31:57 2015 From: report at bugs.python.org (Ron Barak) Date: Tue, 08 Sep 2015 17:31:57 +0000 Subject: [issue25033] Python 2.7.10 make - fails on some Standard Library Modules Message-ID: <1441733517.89.0.892919144959.issue25033@psf.upfronthosting.co.za> New submission from Ron Barak: UnixWare7 only supports Python 1.6 I added Python 2.7.10 from sources. Python works, but its make did not finish cleanly: several Standard Library modules failed to build (see attached: it has to be a screenshot since VirtualBox does not support cut-and-paste on UnixWare). Can you suggest what should be done so that `multiprocessing`, `ssl`, and `select` will compile/build successfully? ---------- components: Build files: Python_make_failure.PNG messages: 250244 nosy: ronbarak priority: normal severity: normal status: open title: Python 2.7.10 make - fails on some Standard Library Modules versions: Python 2.7 Added file: http://bugs.python.org/file40411/Python_make_failure.PNG _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 19:39:57 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 08 Sep 2015 17:39:57 +0000 Subject: [issue25033] Python 2.7.10 make - fails on some Standard Library Modules In-Reply-To: <1441733517.89.0.892919144959.issue25033@psf.upfronthosting.co.za> Message-ID: <1441733997.36.0.277764850399.issue25033@psf.upfronthosting.co.za> R. David Murray added the comment: This tracker is for reporting bugs in python. Our help forum is the python-list mailing list. Please post your questions there. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 19:50:25 2015 From: report at bugs.python.org (Donald Stufft) Date: Tue, 08 Sep 2015 17:50:25 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1441734625.3.0.0067864636191.issue25003@psf.upfronthosting.co.za> Donald Stufft added the comment: (A)RC4 and ChaCha are just two stream ciphers that let you encrypt some data, they work by essentially producing a psuedo-random stream of data in a deterministic manner based off of a key, and than that is XOR'd with the data you want to encrypt. arc4random (ab)uses this and uses "real" entropy (e.g. randomness pulled from random noise on the network and such) as the "key" and then uses the psuedo-random stream of data as the values you get when you ask arc4random for some random data. The actual process is quite a bit more complex then that, but that's the basic gist. Userspace PRNG's are not a very good idea for reasons better explained by an expert: http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ And yea, using MT for anything that needs a CSPRNG (that is, a Cryptographically Secure Psuedo Random Number Generator) is a real bad idea, because the numbers it outputs are not "really" random. I'm of a mind that the APIs should default to CSPRNGs (so ``random`` should default to SystemRandom) and using something like MT should be opt in via something like "UnsafeFastRandom) or something. That ship is almost certainly sailed at this point though. ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 19:53:04 2015 From: report at bugs.python.org (Donald Stufft) Date: Tue, 08 Sep 2015 17:53:04 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1441734784.29.0.716477047688.issue25003@psf.upfronthosting.co.za> Donald Stufft added the comment: Oh yea, and (A)RC4 is broken and shouldn't be used for anything anymore, ChaCha is much better and is pretty great. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 20:01:46 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 08 Sep 2015 18:01:46 +0000 Subject: [issue24199] Idle: remove idlelib.idlever.py and its use in About dialog In-Reply-To: <1431650285.59.0.600694723613.issue24199@psf.upfronthosting.co.za> Message-ID: <1441735306.51.0.386955541255.issue24199@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Re-opening because there is still the issue of adding a deprecation warning on import. Brett, can you either point me toward or post here the code you are planning to use for other stdlib modules? ---------- nosy: +brett.cannon resolution: fixed -> stage: resolved -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 20:06:24 2015 From: report at bugs.python.org (Michael Foord) Date: Tue, 08 Sep 2015 18:06:24 +0000 Subject: [issue22197] Allow better verbosity / output control in test cases In-Reply-To: <1408030741.18.0.985330245232.issue22197@psf.upfronthosting.co.za> Message-ID: <1441735584.12.0.385113951734.issue22197@psf.upfronthosting.co.za> Michael Foord added the comment: Using the runner as a "context" passed to test cases (and accessible from tests) for this kind of configuration seems like a good approach to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 20:07:56 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Sep 2015 18:07:56 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1441735676.04.0.188867514007.issue25003@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 20:11:02 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 08 Sep 2015 18:11:02 +0000 Subject: [issue24199] Idle: remove idlelib.idlever.py and its use in About dialog In-Reply-To: <1431650285.59.0.600694723613.issue24199@psf.upfronthosting.co.za> Message-ID: <1441735862.01.0.855667835914.issue24199@psf.upfronthosting.co.za> Brett Cannon added the comment: Typically it's warnings.warn(message, DeprecationWarning, stacklevel=2), but that stack level is wrong for Python 3.3 - 3.4 (fixed in 3.5.0). If this is purely for Python 3.6 I might be adding a nicer API for module deprecations, but if this is for other versions then the call above is the right one except for Python 3.3/3.4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 20:24:26 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 08 Sep 2015 18:24:26 +0000 Subject: [issue22197] Allow better verbosity / output control in test cases In-Reply-To: <1408030741.18.0.985330245232.issue22197@psf.upfronthosting.co.za> Message-ID: <1441736666.61.0.681825832586.issue22197@psf.upfronthosting.co.za> R. David Murray added the comment: I like that approach as well, it is the kind of API I've been finding myself writing a fair bit lately (a context passed to class instances that otherwise don't store global state themselves). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 20:26:19 2015 From: report at bugs.python.org (John Leitch) Date: Tue, 08 Sep 2015 18:26:19 +0000 Subject: [issue25021] product_setstate() Out-of-bounds Read In-Reply-To: <1441684502.22.0.0994334100718.issue25021@psf.upfronthosting.co.za> Message-ID: <1441736779.4.0.00430060319444.issue25021@psf.upfronthosting.co.za> John Leitch added the comment: Glancing over the code, I see the issues you describe. Tonight I will verify your revised patch and report back. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 20:34:24 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 08 Sep 2015 18:34:24 +0000 Subject: [issue24989] scan_eol() Buffer Over-read In-Reply-To: <1441237226.71.0.655654379606.issue24989@psf.upfronthosting.co.za> Message-ID: <1441737264.25.0.648241838294.issue24989@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 20:36:09 2015 From: report at bugs.python.org (Adam) Date: Tue, 08 Sep 2015 18:36:09 +0000 Subject: [issue24928] mock.patch.dict spoils order of items in collections.OrderedDict In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za> Message-ID: <1441737369.48.0.327605168092.issue24928@psf.upfronthosting.co.za> Changes by Adam : ---------- nosy: +azsorkin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 20:36:46 2015 From: report at bugs.python.org (Adam) Date: Tue, 08 Sep 2015 18:36:46 +0000 Subject: [issue24899] Add an os.path <=> pathlib equivalence table in pathlib docs In-Reply-To: <1440050617.44.0.44226546659.issue24899@psf.upfronthosting.co.za> Message-ID: <1441737406.41.0.167352442791.issue24899@psf.upfronthosting.co.za> Changes by Adam : ---------- nosy: +azsorkin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 20:36:57 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 08 Sep 2015 18:36:57 +0000 Subject: [issue24913] deque.index() overruns deque boundary In-Reply-To: <1440198546.56.0.00559117738444.issue24913@psf.upfronthosting.co.za> Message-ID: <1441737417.21.0.337460940955.issue24913@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 20:37:34 2015 From: report at bugs.python.org (Adam) Date: Tue, 08 Sep 2015 18:37:34 +0000 Subject: [issue10716] Modernize pydoc to use better HTML and separate CSS In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za> Message-ID: <1441737454.24.0.633275858987.issue10716@psf.upfronthosting.co.za> Changes by Adam : ---------- nosy: +azsorkin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 20:39:42 2015 From: report at bugs.python.org (Adam) Date: Tue, 08 Sep 2015 18:39:42 +0000 Subject: [issue24249] unittest API for detecting test failure in cleanup/teardown In-Reply-To: <1432155715.32.0.956645145974.issue24249@psf.upfronthosting.co.za> Message-ID: <1441737582.41.0.960503545026.issue24249@psf.upfronthosting.co.za> Changes by Adam : ---------- nosy: +azsorkin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 21:06:30 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 08 Sep 2015 19:06:30 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441739190.84.0.391061500335.issue24912@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 21:08:02 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Tue, 08 Sep 2015 19:08:02 +0000 Subject: [issue24991] Define instance mutability explicitly on type objects In-Reply-To: <1441260483.41.0.785006760825.issue24991@psf.upfronthosting.co.za> Message-ID: <1441739282.68.0.189454433532.issue24991@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 21:23:13 2015 From: report at bugs.python.org (Anthon van der Neut) Date: Tue, 08 Sep 2015 19:23:13 +0000 Subject: [issue25034] string.Formatter accepts empty fields but displays wrong when nested Message-ID: <1441740193.79.0.679577096269.issue25034@psf.upfronthosting.co.za> New submission from Anthon van der Neut: Since 3.4.1, string.Formatter() accepts empty keys {}. If these are nested they give different results from explicitly numbered, where the same arguments applied "".format() give the expected results: from string import Formatter f = Formatter() fmt0 = "X {:<{}} {} X" fmt1 = "X {0:<{1}} {2} X" for fmt in [fmt0, fmt1]: x = f.format(fmt, 'ab', 5, 1) y = fmt.format( 'ab', 5, 1) print(x) print(y) gives: X ab 5 X X ab 1 X X ab 1 X X ab 1 X of which the first line is incorrect. ---------- components: Library (Lib) messages: 250253 nosy: anthon priority: normal severity: normal status: open title: string.Formatter accepts empty fields but displays wrong when nested type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 21:23:56 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 08 Sep 2015 19:23:56 +0000 Subject: [issue24912] The type of cached objects is mutable In-Reply-To: <1440194570.97.0.676736000835.issue24912@psf.upfronthosting.co.za> Message-ID: <1441740236.6.0.0173302518137.issue24912@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: -Guido.van.Rossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 21:27:25 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 08 Sep 2015 19:27:25 +0000 Subject: [issue25034] string.Formatter accepts empty fields but displays wrong when nested In-Reply-To: <1441740193.79.0.679577096269.issue25034@psf.upfronthosting.co.za> Message-ID: <1441740445.11.0.691545977474.issue25034@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 21:49:40 2015 From: report at bugs.python.org (Anthon van der Neut) Date: Tue, 08 Sep 2015 19:49:40 +0000 Subject: [issue25034] string.Formatter accepts empty fields but displays wrong when nested In-Reply-To: <1441740193.79.0.679577096269.issue25034@psf.upfronthosting.co.za> Message-ID: <1441741780.11.0.204892079982.issue25034@psf.upfronthosting.co.za> Anthon van der Neut added the comment: Here is a patch for Python-3.5.0rc3/Lib/test/test_string.py unittests fail: --- /opt/python/3.5/lib/python3.5/test/test_string.py 2015-09-08 17:06:07.099197904 +0200 +++ test_string.py 2015-09-08 21:47:01.471634309 +0200 @@ -58,6 +58,8 @@ 'foo{1}{num}{1}'.format(None, 'bar', num=6)) self.assertEqual(fmt.format('{:^{}}', 'bar', 6), '{:^{}}'.format('bar', 6)) + self.assertEqual(fmt.format('{:^{}} {}', 'bar', 6, 'X'), + '{:^{}} {}'.format('bar', 6, 'X')) self.assertEqual(fmt.format('{:^{pad}}{}', 'foo', 'bar', pad=6), '{:^{pad}}{}'.format('foo', 'bar', pad=6)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 21:57:22 2015 From: report at bugs.python.org (Mark Roseman) Date: Tue, 08 Sep 2015 19:57:22 +0000 Subject: [issue24760] IDLE settings dialog shouldn't be modal In-Reply-To: <1438297628.71.0.179622085434.issue24760@psf.upfronthosting.co.za> Message-ID: <1441742242.5.0.862185151824.issue24760@psf.upfronthosting.co.za> Mark Roseman added the comment: Note: about dialog part of the 'demodalize' patch split off and now in #24813; the bulk of the rest of it, which is really providing a cleaner FileList API rather than direct access to internals from EditorWindow, is in #25031. After the latter patch is accepted, I'll put up a new patch here that is just the changes to make settings modeless... will be just a dozen lines of code or so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 22:28:26 2015 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 08 Sep 2015 20:28:26 +0000 Subject: [issue25034] string.Formatter accepts empty fields but displays wrong when nested In-Reply-To: <1441740193.79.0.679577096269.issue25034@psf.upfronthosting.co.za> Message-ID: <1441744106.23.0.618896887551.issue25034@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- assignee: -> eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 22:53:58 2015 From: report at bugs.python.org (Christoph Gohlke) Date: Tue, 08 Sep 2015 20:53:58 +0000 Subject: [issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules In-Reply-To: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za> Message-ID: <1441745638.79.0.130567934401.issue25027@psf.upfronthosting.co.za> Christoph Gohlke added the comment: I understand that distributing dependent DLLs next to extension modules is considered the best approach (which nevertheless fails in common cases), however vcruntime140.dll is a special case since it will be shared by almost all extension modules and can be considered a system library. My Python 3.4 installation contains 913 .pyd files in 277 directories under Lib\site-packages. With the proposed change there will be ~277 redundant vcruntime140.dll files under Python 3.5. Size is not an issue since vcruntime140.dll is small (~87 KB for 64 bit). Many extension modules are installed directly into Lib\site-packages (no package directory). Uninstalling any one of those extension modules using pip or "wininstaller" will delete vcruntime140.dll from Lib\site-packages, potentially breaking the other extension modules in Lib\site-packages. IANAL, but under GPL "you may not distribute these [runtime] libraries in compiled DLL form with the program" . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 23:29:53 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Sep 2015 21:29:53 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1441747793.3.0.613397111412.issue25003@psf.upfronthosting.co.za> STINNER Victor added the comment: Thread on python-dev: https://mail.python.org/pipermail/python-dev/2015-September/141439.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 23:46:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Sep 2015 21:46:17 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1441748777.17.0.19708740096.issue25003@psf.upfronthosting.co.za> STINNER Victor added the comment: > Perhaps the getentropy() check can explicitly rule out Solaris (either at the autoconf level or in the random.c source code) if you prefer to keep the getentropy() call on OpenBSD. Ok, here is a patch implementing this option. It keeps getentropy() on OpenBSD for os.urandom(), but it disables getentropy() on Solaris for os.urandom(). I don't know if my py_getrandom() function calling syscall(SYS_getrandom, buffer, size, 0) works on Solaris. The flags are hardcoded, and I don't know if the include is enough to get the syscall() function. (Does Solaris uses the GNU C library?) @jbeck: Can you please test this patch on the default branch of Python? Can you tell if the HAVE_GETRANDOM_SYSCALL check succeed on Solaris? (do you have "#define HAVE_GETRANDOM_SYSCALL 1" in pyconfig.h?) The configure scripts tries to compile the following C program: #include int main() { const int flags = 0; char buffer[1]; int n; /* ignore the result, Python checks for ENOSYS at runtime */ (void)syscall(SYS_getrandom, buffer, sizeof(buffer), flags); return 0; } ---------- Added file: http://bugs.python.org/file40412/urandom_solaris.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 8 23:59:50 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Sep 2015 21:59:50 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <20150908215920.101504.19725@psf.io> Roundup Robot added the comment: New changeset d0bb896f9b14 by Victor Stinner in branch 'default': Revert change 0eb8c182131e: https://hg.python.org/cpython/rev/d0bb896f9b14 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 00:19:57 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 08 Sep 2015 22:19:57 +0000 Subject: [issue25002] Deprecate asyncore/asynchat In-Reply-To: <1441399683.85.0.786847810998.issue25002@psf.upfronthosting.co.za> Message-ID: <1441750797.91.0.843094469233.issue25002@psf.upfronthosting.co.za> Mark Lawrence added the comment: IIRC I flagged up oustanding asyncore/asynchat issues months or even years back and Victor closed a lot down, so there shouldn't be many left to deal with. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 00:21:43 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 08 Sep 2015 22:21:43 +0000 Subject: [issue23738] Clarify documentation of positional-only default values In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za> Message-ID: <1441750903.26.0.179595334373.issue23738@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- dependencies: +io.[Text]IOBase.seek doesn't take keyword parameter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 00:41:12 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 08 Sep 2015 22:41:12 +0000 Subject: [issue25030] io.[Text]IOBase.seek doesn't take keyword parameter In-Reply-To: <1441719881.64.0.378247085729.issue25030@psf.upfronthosting.co.za> Message-ID: <1441752072.25.0.0150141170486.issue25030@psf.upfronthosting.co.za> Martin Panter added the comment: This also bugs me, and the same problem exists in other parts of the documentation. Perhaps you might be interested in Issue 23738 and whether changing to the new notation used by PEP 457, pydoc, help(), Argument Clinic is any good: seek(offset, whence=SEEK_SET, /) But in the mean time, I think the proposed patch is okay, and would certainly benefit the Python 2 documetation where using the new PEP 457 slash indicator is less likely to be appropriate. ---------- nosy: +martin.panter versions: +Python 2.7, Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 00:44:12 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 08 Sep 2015 22:44:12 +0000 Subject: [issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules In-Reply-To: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za> Message-ID: <1441752252.68.0.603544127635.issue25027@psf.upfronthosting.co.za> Steve Dower added the comment: vcruntime140.dll *is* a system library when installed properly, and if someone installs VCRedist then all the bundled ones should be ignored. Over time, I expect to see extensions appear that depend on vcruntime150.dll rather than 140.dll, so it won't always be shared by all extensions. However, if someone has vcruntime140.dll installed and an extension requires vcruntime150.dll, they will get errors unless that extension includes the correct version. We can't ship currently-nonexistent versions with Python 3.5, and if extensions have to depend on what's installed then Python 3.5 extensions will forever be tied to MSVC 14.0. GPL code should either statically link or recommend their users install VCRedist separately. I'm not going to compromise compiler version independence because of one license. The uninstall issue is something I hadn't considered. Maybe we can special-case pip uninstalling it from the site-packages folder? *Paul* - any thoughts? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 01:01:55 2015 From: report at bugs.python.org (Sworddragon) Date: Tue, 08 Sep 2015 23:01:55 +0000 Subject: [issue25035] Getter/setter for argparse keys Message-ID: <1441753315.66.0.921652253193.issue25035@psf.upfronthosting.co.za> New submission from Sworddragon: On making a look at the argparse documentation to figure out if I can get the value of the choices key of a specific argument after argument parsing or if I have to implement it myself I noticed that there is a getter/setter for the default key (ArgumentParser.get_default and ArgumentParser.set_defaults) but not for the other keys. Maybe this could also be implemented for the other keys, probably as a generic function that takes as an extra argument the requested key. ---------- components: Library (Lib) messages: 250263 nosy: Sworddragon priority: normal severity: normal status: open title: Getter/setter for argparse keys type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 01:03:21 2015 From: report at bugs.python.org (Mark Roseman) Date: Tue, 08 Sep 2015 23:03:21 +0000 Subject: [issue25036] IDLE - infrastructure changes so editors don't assume they're in a toplevel Message-ID: <1441753399.73.0.466397630291.issue25036@psf.upfronthosting.co.za> New submission from Mark Roseman: A necessary prerequisite of tabbed windows, editor and shell in same window etc. as per #24826, is that editors stop thinking they are in their own toplevel window. The attached component.patch is unfortunately long, but this was necessary due to the highly inter-related nature of the changes. It results in no functionality changes to IDLE at this point, just a reorganization. In summary, WindowList.ListedToplevel was abstracted into a more general Container, which will later be expanded to do more than just a simple toplevel (though that is all it is now). EditorWindow (and friends) no longer call window operations like wm_title themselves, but go through a Container API. At the same time, a new Component base class was created, which EditorWindow and several others now inherit from. Components get inserted into Containers of course, and the base class ensures certain things the Container needs are present. (The Component also can respond to callbacks from other Components sent via the file list; this approach is used in the patch in #25031 for configuration changes). Finally, what remained of WindowList (effectively a simplified WindowList class, but not ListedTopLevel) was folded into FileList. In terms of understanding and/or reviewing this patch, I'd recommend the following: 1. start with container.py 2. then component.py 3. then a simple example of how it's applied, ClassBrowser.py 4. a slightly more verbose, but equally simple example, Debugger.py 5. FileList.py (mostly comes from WindowList, but note how used by container.py 6. then EditorWindow.py ---------- components: IDLE files: component.patch keywords: patch messages: 250264 nosy: kbk, markroseman, roger.serwy, terry.reedy priority: normal severity: normal status: open title: IDLE - infrastructure changes so editors don't assume they're in a toplevel type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40413/component.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 01:04:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 08 Sep 2015 23:04:28 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <20150908230425.15726.39192@psf.io> Roundup Robot added the comment: New changeset 171d5590ebc3 by Victor Stinner in branch 'default': Issue #23517: fromtimestamp() and utcfromtimestamp() methods of https://hg.python.org/cpython/rev/171d5590ebc3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 01:10:27 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 08 Sep 2015 23:10:27 +0000 Subject: [issue25029] MemoryError in test_strptime In-Reply-To: <1441708213.63.0.825636103813.issue25029@psf.upfronthosting.co.za> Message-ID: <1441753827.12.0.587760176491.issue25029@psf.upfronthosting.co.za> Steve Dower added the comment: Thanks. I'll submit a PR for 3.5.0 later tonight - can't seem to clone Larry's repo successfully at work for some reason. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 01:46:35 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 08 Sep 2015 23:46:35 +0000 Subject: [issue24862] subprocess.Popen behaves incorrect when moved in process tree In-Reply-To: <1439520939.88.0.252356845124.issue24862@psf.upfronthosting.co.za> Message-ID: <1441755995.3.0.990736894508.issue24862@psf.upfronthosting.co.za> Gregory P. Smith added the comment: My gut feeling is to say "don't do that" when it comes to passing subprocess instances between processes (ie: pickling and unpickling them) and expecting them to work as if nothing had changed... You already acknowledge that this is a strange thing for an application to do and that you have a workaround in your application. BUT: It does looks like we are doing something a bit weird here with the waitpid errno.ECHILD exception. However letting this bubble up to the application may, at this point, cause new bugs in code that isn't expecting it so I'm not sure we should change that in any circumstances. :/ FWIW there is also a comment at the end of the related issue1731717 (for Popen.wait() rather than .poll()) with a suggestion to ponder (though not directly related to this issue, if it is still relevant). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 01:59:53 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Sep 2015 23:59:53 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441756793.65.0.127609210743.issue23517@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file40349/timedelta_round_half_up_py34.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 01:59:54 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Sep 2015 23:59:54 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441756794.56.0.415497723504.issue23517@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file40362/round_half_up_py34-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 01:59:55 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Sep 2015 23:59:55 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441756795.22.0.436056470724.issue23517@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file40364/fromtimestamp_round_half_up_py34-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 01:59:56 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 08 Sep 2015 23:59:56 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441756796.19.0.0732291604191.issue23517@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file40365/combined_py34.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 02:00:37 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 09 Sep 2015 00:00:37 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441756837.16.0.876685252922.issue23517@psf.upfronthosting.co.za> Larry Hastings added the comment: I wish people wouldn't remove old patches. There's no harm in leaving them, and it may be a useful historical record. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 02:02:08 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Sep 2015 00:02:08 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441756928.85.0.432136285834.issue23517@psf.upfronthosting.co.za> STINNER Victor added the comment: I modified Python 3.6 to use ROUND_HALF_EVEN rounding mode in datetime.timedelta, datetime.datetime.fromtimestamp(), datetime.datetime.utcfromtimestamp(). round_half_even_py34.patch: Backport this change to Python 3.4. I tried to write a minimal patch only changing datetime, not pytime. ---------- Added file: http://bugs.python.org/file40414/round_half_even_py34.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 02:04:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Sep 2015 00:04:17 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441757057.97.0.00654284365507.issue23517@psf.upfronthosting.co.za> STINNER Victor added the comment: > I wish people wouldn't remove old patches. There's no harm in leaving them, and it may be a useful historical record. It became hard to read this issue, it has a long history. My old patches for Python 3.4 were for ROUND_HALF_UP, but it was then decided to use ROUND_HALF_EVEN. Technically, patches are not "removed" but "unlinked" from the issue: you can get from the history at the bottom of this page. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 04:14:49 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 09 Sep 2015 02:14:49 +0000 Subject: [issue25029] MemoryError in test_strptime In-Reply-To: <1441708213.63.0.825636103813.issue25029@psf.upfronthosting.co.za> Message-ID: <1441764889.64.0.994024508013.issue25029@psf.upfronthosting.co.za> Steve Dower added the comment: PR at https://bitbucket.org/larry/cpython350/pull-requests/21/issue-25029-memoryerror-in-test_strptime/diff ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 04:23:05 2015 From: report at bugs.python.org (eryksun) Date: Wed, 09 Sep 2015 02:23:05 +0000 Subject: [issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules In-Reply-To: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za> Message-ID: <1441765385.41.0.324393952316.issue25027@psf.upfronthosting.co.za> eryksun added the comment: I think 3.5 should be distributed with vcruntime140.dll. It seems a waste for python.exe, python35.dll, and all of the extension modules and dependent DLLs to each take an FLS slot: >>> import ctypes # +1 for _ctypes >>> kernel32 = ctypes.WinDLL('kernel32') >>> kernel32.FlsGetValue.restype = ctypes.c_void_p >>> [x for x in range(128) if kernel32.FlsGetValue(x)] [1, 2, 4, 5, 6, 8] >>> import pyexpat, select, unicodedata, winsound >>> import _bz2, _decimal, _elementtree, _hashlib >>> import _lzma, _msi, _multiprocessing, _overlapped >>> import _socket, _sqlite3, _ssl, _tkinter >>> [x for x in range(128) if kernel32.FlsGetValue(x)] [1, 2, 4, 5, 6, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27] ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 04:29:03 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 09 Sep 2015 02:29:03 +0000 Subject: [issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules In-Reply-To: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za> Message-ID: <1441765743.95.0.12325157659.issue25027@psf.upfronthosting.co.za> Steve Dower added the comment: Okay, here's a proposal: We bundle vcruntime140.dll with Python's normal install, so it's always there and extensions that use it do not need to ship anything. When distutils._msvccompiler is used to build an extension with a *different* version of MSVC, it will copy the dependency or statically link (as in my attached patch). This does not prevent us from changing the compiler used for 3.5, as long as we continue to ship both vcruntime140.dll and the newer version, and extensions build with newer compilers will include the dependency or pick up the bundled one if they are on a version that includes it. (Extensions that use C++ and depend on msvcp###.dll will need to ship that themselves, obviously.) I'll post a new patch shortly, but it's only a very small change from this one for distutils, and the rest is in the installer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 05:42:58 2015 From: report at bugs.python.org (Steven Barker) Date: Wed, 09 Sep 2015 03:42:58 +0000 Subject: [issue23447] Import fails when doing a circular import involving an `import *` In-Reply-To: <1423679925.56.0.995999383567.issue23447@psf.upfronthosting.co.za> Message-ID: <1441770178.58.0.818461580314.issue23447@psf.upfronthosting.co.za> Steven Barker added the comment: I've managed to partially fix my build environment, so I can verify that my patch (attached previously) works as intended. I'm not completely sure that it doesn't break unrelated things as my build still has lots of failing tests (which all appear to be unrelated to this issue). Nothing obviously new breaks with the patch applied. The test I added in the patch does fail (as expected) on the unpatched interpreter, but passes on a patched version (though I've just noticed that the attempt at catching the exception doesn't work, since the current import code raises an AttributeError rather than the ImportError I had expected). I don't believe any other tests failed anew on the patched code, but like I said, I've got a lot of unrelated test failures so I might be missing some subtle issues. I'm attaching an updated version of the patch with better exception handling in the test code. The patch applies cleanly to the latest dev branch. I'd appreciate any reviews or other feedback. ---------- Added file: http://bugs.python.org/file40415/23447_3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 05:43:10 2015 From: report at bugs.python.org (Alan) Date: Wed, 09 Sep 2015 03:43:10 +0000 Subject: [issue25037] ValueError: invalid literal for int() with base 16: b'[\r\n' Message-ID: <1441770190.19.0.487767055641.issue25037@psf.upfronthosting.co.za> New submission from Alan: I've written a piece of code to POST request to a web service. =========================================================================== import json import urllib from urllib import request from urllib import parse def Payload(start_date, end_date, pnode_list): payload = {"startDate": start_date, "endDate": end_date, "pnodelist": pnode_list} return json.dumps(payload) def DownloadData(url, payload, header): data = [] request = urllib.request.Request(url, payload, header) try: response = urllib.request.urlopen(request) except urllib.error.URLError as e: print("URLError occured.") except urllib.error.HTTPError as e: print("HTTPError occured.") else: #response.chunked = False #if this line is commented, ValueError will be thrown... data = json.loads(response.read().decode("utf-8")) return data def main(): url = "https://dataminer.pjm.com/dataminer/rest/public/api/markets/dayahead/lmp/daily" payload = Payload("2015-07-01", "2015-07-01", [135389795]) header = {"Content-Type": "application/json"} data = DownloadData(url, payload.encode("utf-8"), header) print(data) if __name__ == "__main__": main() =========================================================================== However, "ValueError:invalid literal for int() with base 16: b'[\r\n'" is thrown when the HTTPResponse.read() is invoked: Traceback (most recent call last): File "C:\Python34\lib\http\client.py", line 587, in _readall_chunked chunk_left = self._read_next_chunk_size() File "C:\Python34\lib\http\client.py", line 559, in _read_next_chunk_si return int(line, 16) ValueError: invalid literal for int() with base 16: b'[\r\n' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "textpjm.py", line 34, in main() File "textpjm.py", line 30, in main data = DownloadData(url, payload.encode("utf-8"), header) File "textpjm.py", line 23, in DownloadData data = json.loads(response.read().decode("utf-8")) File "C:\Python34\lib\http\client.py", line 506, in read return self._readall_chunked() File "C:\Python34\lib\http\client.py", line 591, in _readall_chunked raise IncompleteRead(b''.join(value)) http.client.IncompleteRead: IncompleteRead(0 bytes read) I've found a solution to avoid this exception: before HTTPResponse.read() is called, I have to set HTTPResponse.chunked to be False! I wonder if there's something wrong in HTTPResponse. ---------- components: Library (Lib) files: testpjm.py messages: 250275 nosy: alan priority: normal severity: normal status: open title: ValueError: invalid literal for int() with base 16: b'[\r\n' type: crash versions: Python 3.4 Added file: http://bugs.python.org/file40416/testpjm.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 05:43:41 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 09 Sep 2015 03:43:41 +0000 Subject: [issue25029] MemoryError in test_strptime In-Reply-To: <1441708213.63.0.825636103813.issue25029@psf.upfronthosting.co.za> Message-ID: <1441770221.47.0.391993113707.issue25029@psf.upfronthosting.co.za> Larry Hastings added the comment: Does this need a Misc/NEWS entry? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 05:54:44 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 09 Sep 2015 03:54:44 +0000 Subject: [issue23738] Clarify documentation of positional-only default values In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za> Message-ID: <1441770884.18.0.740784731076.issue23738@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +berker.peksag versions: +Python 3.6 Added file: http://bugs.python.org/file40417/pos-defaults.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 05:56:01 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Sep 2015 03:56:01 +0000 Subject: [issue23738] Clarify documentation of positional-only default values In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za> Message-ID: <20150909035557.15730.75199@psf.io> Roundup Robot added the comment: New changeset fdb5d84f9948 by Martin Panter in branch '3.4': Issue #23738: Document and test actual keyword parameter names https://hg.python.org/cpython/rev/fdb5d84f9948 New changeset 40bf1ca3f715 by Martin Panter in branch '3.5': Issue #23738: Merge 3.4 into 3.5 https://hg.python.org/cpython/rev/40bf1ca3f715 New changeset 6177482ce6a1 by Martin Panter in branch 'default': Issue #23738: Merge 3.5 into 3.6 https://hg.python.org/cpython/rev/6177482ce6a1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 05:58:50 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 09 Sep 2015 03:58:50 +0000 Subject: [issue23738] Clarify documentation of positional-only default values In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za> Message-ID: <1441771130.84.0.872947389563.issue23738@psf.upfronthosting.co.za> Martin Panter added the comment: I have committed the obvious keyword argument name fixes from my patch. Now patch v3 contains just the PEP 457 changes to be considered. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 06:11:08 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 09 Sep 2015 04:11:08 +0000 Subject: [issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules In-Reply-To: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za> Message-ID: <1441771868.53.0.416696300927.issue25027@psf.upfronthosting.co.za> Steve Dower added the comment: New patch. Mostly build and installer changes, but the distutils/_msvccompiler.py is also part of it. I've run a full build and done basic testing with a full test run going now, but I don't have a clean machine handy to try it without the full CRT install, so that'll have to wait until tomorrow. This *basically* reverts the build back to /MD for everything. The one exception is that distutils now knows which DLLs are shipped with Python and if a vcruntime is needed that isn't included, it will be put into the dist (or statically linked). So wheels created with 3.5.6 and MSVC 15.0 will still run against 3.5.0, even if the user has not installed the latest VCRedist. ---------- Added file: http://bugs.python.org/file40418/25027_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 06:14:39 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 09 Sep 2015 04:14:39 +0000 Subject: [issue25029] MemoryError in test_strptime In-Reply-To: <1441708213.63.0.825636103813.issue25029@psf.upfronthosting.co.za> Message-ID: <1441772079.05.0.449203012989.issue25029@psf.upfronthosting.co.za> Steve Dower added the comment: Probably should, since the fix that caused it was in for rc3. There's no section for 3.5.0 final yet though (that's my excuse, anyway :) ) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 06:22:57 2015 From: report at bugs.python.org (shiyao.ma) Date: Wed, 09 Sep 2015 04:22:57 +0000 Subject: [issue25030] io. In-Reply-To: <1441752072.25.0.0150141170486.issue25030@psf.upfronthosting.co.za> Message-ID: shiyao.ma added the comment: Thanks for your comment. I had a read of pep457. It's still in draft status, so incorporating the / indicator is not much a concern AFAIK. Any further modification for me to do to get that merged? ---------- title: io.[Text]IOBase.seek doesn't take keyword parameter -> io. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 06:30:37 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 09 Sep 2015 04:30:37 +0000 Subject: [issue25037] ValueError: invalid literal for int() with base 16: b'[\r\n' In-Reply-To: <1441770190.19.0.487767055641.issue25037@psf.upfronthosting.co.za> Message-ID: <1441773037.87.0.458309232096.issue25037@psf.upfronthosting.co.za> Martin Panter added the comment: It looks like this is a fault in the server. It does not appear to support Connection: close over HTTP 1.1, which is what Python?s ?urllib.request? module uses. I think you will either have to get the server fixed, or work around the problem by using the low level ?http.client? module, where you can avoid sending a ?Connection: close? header field. However see also Issue 12849, where various other people (including myself at one stage) have found this ?Connection: close? flag triggers various server problems. HTTP responses from the server with and without the ?close? flag: ## HTTP 1.1 without Connection: close ? good chunked response ## POST /dataminer/rest/public/api/markets/dayahead/lmp/daily HTTP/1.1 Host: dataminer.pjm.com Content-Type: application/json Content-Length: 80 {"startDate": "2015-07-01", "endDate": "2015-07-01", "pnodelist": [135389795]} HTTP/1.1 200 OK Server: Apache-Coyote/1.1 X-UA-Compatible: IE=edge Cache-Control: no-cache Expires: -1 X-Powered-By: ASP.NET X-AspNet-Version: 4.0.30319 X-Request-UUID: 09513fea-ac35-41ea-bf1b-b69357f42594 Transfer-Encoding: chunked Server: Microsoft-IIS/7.5 Date: Wed, 09 Sep 2015 04:12:34 GMT Pragma: no-cache Content-Type: application/json Transfer-Encoding: chunked Set-Cookie: dataminer=1923355820.36895.0000; path=/ 1a44 [ { "publishDate": "2015-07-01T04:00:00Z", [. . .] ## HTTP 1.1 with Connection: close ? invalid chunked response ## POST /dataminer/rest/public/api/markets/dayahead/lmp/daily HTTP/1.1 Host: dataminer.pjm.com Connection: close Content-Type: application/json Content-Length: 80 {"startDate": "2015-07-01", "endDate": "2015-07-01", "pnodelist": [135389795]} HTTP/1.1 200 OK Server: Apache-Coyote/1.1 X-UA-Compatible: IE=edge Cache-Control: no-cache Connection: close Expires: -1 X-Powered-By: ASP.NET X-AspNet-Version: 4.0.30319 X-Request-UUID: 0b43546c-d484-47a1-aff3-384f62a94a5a Transfer-Encoding: chunked Server: Microsoft-IIS/7.5 Date: Wed, 09 Sep 2015 04:13:00 GMT Pragma: no-cache Content-Type: application/json Connection: close [ { "publishDate": "2015-07-01T04:00:00Z", [. . .] ---------- nosy: +martin.panter resolution: -> third party status: open -> closed superseder: -> Cannot override 'connection: close' in urllib2 headers type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 06:35:11 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 09 Sep 2015 04:35:11 +0000 Subject: [issue25037] ValueError: invalid literal for int() with base 16: b'[\r\n' In-Reply-To: <1441770190.19.0.487767055641.issue25037@psf.upfronthosting.co.za> Message-ID: <1441773311.5.0.921486567656.issue25037@psf.upfronthosting.co.za> Martin Panter added the comment: FYI maybe your workaround of clearing HTTPResponse.chunked will work at the moment, but it would break if the server ever gets fixed and starts sending proper chunked responses. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 06:50:04 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 09 Sep 2015 04:50:04 +0000 Subject: [issue25030] io.[Text]IOBase.seek doesn't take keyword parameter In-Reply-To: <1441719881.64.0.378247085729.issue25030@psf.upfronthosting.co.za> Message-ID: <1441774204.87.0.437968609443.issue25030@psf.upfronthosting.co.za> Martin Panter added the comment: I will try to commit your patch today when I up to it. Maybe the ?draft? status of that PEP is out of date. The slash (/) indicator is already being used in some places in pydoc, e.g. $ pydoc object.__eq__ Help on wrapper_descriptor in object: object.__eq__ = __eq__(self, value, /) Return self==value. ---------- assignee: docs at python -> martin.panter stage: -> commit review title: io. -> io.[Text]IOBase.seek doesn't take keyword parameter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 06:56:11 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 09 Sep 2015 04:56:11 +0000 Subject: [issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules In-Reply-To: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za> Message-ID: <1441774571.12.0.759573008545.issue25027@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 07:07:21 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 09 Sep 2015 05:07:21 +0000 Subject: [issue12849] Cannot override 'connection: close' in urllib2 headers In-Reply-To: <1314559168.55.0.630424901631.issue12849@psf.upfronthosting.co.za> Message-ID: <1441775241.97.0.680958175096.issue12849@psf.upfronthosting.co.za> Martin Panter added the comment: Just closed Issue 25037 about a server that omits the chunk length headers when ?Connection: closed? is used. I wonder if it would be such a bad idea to just remove the ?Connection: closed? flag. It was added in 2004 in revision 5e7455fb8db6, but I do not agree with the reason given in the commit message and comment. Adding the flag is only really a courtesy to the server, saying it can drop the connection once it sends the response. Removing it in theory shouldn?t change anything about how the client parses the HTTP response, but in practice it seems it may improve compatibility with buggy servers. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 07:35:59 2015 From: report at bugs.python.org (John Leitch) Date: Wed, 09 Sep 2015 05:35:59 +0000 Subject: [issue25021] product_setstate() Out-of-bounds Read In-Reply-To: <1441684502.22.0.0994334100718.issue25021@psf.upfronthosting.co.za> Message-ID: <1441776959.93.0.625511839042.issue25021@psf.upfronthosting.co.za> John Leitch added the comment: All appears well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 08:03:18 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 09 Sep 2015 06:03:18 +0000 Subject: [issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules In-Reply-To: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za> Message-ID: <1441778598.56.0.0879388018215.issue25027@psf.upfronthosting.co.za> Steve Dower added the comment: FYI: we're making a new release (right now!) with the patch applied, that should go out tomorrow. If anyone spots anything important in the patch, I still really want to hear about it, but hopefully having something installable means we'll get at least a few days of testing before locking it in. All my apologies for waiting until the last minute before giving up on the crusade to avoid including the versioned files in Python. The timing is unfortunate, but I'm sure we're going to have the best compatibility story possible right now. So thanks for indulging me, and I hope I haven't put too many people through too much anguish. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 08:11:50 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Sep 2015 06:11:50 +0000 Subject: [issue24199] Idle: remove idlelib.idlever.py and its use in About dialog In-Reply-To: <1431650285.59.0.600694723613.issue24199@psf.upfronthosting.co.za> Message-ID: <20150909061146.68873.46605@psf.io> Roundup Robot added the comment: New changeset 55b62e2c59f8 by Terry Jan Reedy in branch '2.7': Issue 24199: Deprecate idlelib.idlever with a warning on import. https://hg.python.org/cpython/rev/55b62e2c59f8 New changeset c51514826126 by Terry Jan Reedy in branch '3.4': Issue 24199: Deprecate idlelib.idlever with a warning on import. https://hg.python.org/cpython/rev/c51514826126 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 08:14:32 2015 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 09 Sep 2015 06:14:32 +0000 Subject: [issue24991] Define instance mutability explicitly on type objects In-Reply-To: <1441260483.41.0.785006760825.issue24991@psf.upfronthosting.co.za> Message-ID: <1441779272.1.0.80304860152.issue24991@psf.upfronthosting.co.za> Nick Coghlan added the comment: Also adding Trent Nelson to the nosy list, as I believe this capability could potentially be relevant to PyParallel. The reason I say that is that if instance mutability (or the lack thereof) becomes a first class language concept, then we may be able to adopt a Rust style model where mutability can be made *thread relative*. Thread relative immutability would be trickier than global immutability, but hopefully still feasible. ---------- nosy: +trent _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 08:25:22 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 09 Sep 2015 06:25:22 +0000 Subject: [issue24199] Idle: remove idlelib.idlever.py and its use in About dialog In-Reply-To: <1431650285.59.0.600694723613.issue24199@psf.upfronthosting.co.za> Message-ID: <1441779922.23.0.954333235374.issue24199@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thanks, Brett. Since I am not wrapping the warning, the default stacklevel seems to work on all versions. Still to do: 1. Something in the docs (all branches), but with an eye toward other deprecations coming later. 2. Actually remove file in 3.6 branch, but only after ImportError does not crash Python when running without a console (ie, with sys.stderr == None)). An future issue to fix this will be a dependency. ---------- versions: +Python 3.6 -Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 08:50:05 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 09 Sep 2015 06:50:05 +0000 Subject: [issue24984] document AF_BLUETOOTH socket address formats In-Reply-To: <1441210010.76.0.198064903239.issue24984@psf.upfronthosting.co.za> Message-ID: <1441781405.52.0.287385732263.issue24984@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 08:50:22 2015 From: report at bugs.python.org (Anthon van der Neut) Date: Wed, 09 Sep 2015 06:50:22 +0000 Subject: [issue25034] string.Formatter accepts empty fields but displays wrong when nested In-Reply-To: <1441740193.79.0.679577096269.issue25034@psf.upfronthosting.co.za> Message-ID: <1441781422.17.0.0724708119896.issue25034@psf.upfronthosting.co.za> Anthon van der Neut added the comment: The problem lies in the recursive call to _vformat which might consume fields without name ({}) and increment auto_arg_index, but that incremented value was not returned to the parent. Since the line became longer than pep8 allowed I wrapped all of the method call arguments to the next line, hope that that's ok. The patch is against the mercurial repository and works for 3.4.1 upwards. ---------- keywords: +patch Added file: http://bugs.python.org/file40419/25034.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 08:56:50 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Sep 2015 06:56:50 +0000 Subject: [issue25038] test_os.TestSendfile.test_keywords() introduced a regression Message-ID: <1441781810.94.0.0104425602054.issue25038@psf.upfronthosting.co.za> New submission from STINNER Victor: The change e42e2bd47168 introduced a regression, test_os started to fail on FreeBSD. What is the rationale of the change? For example, test_os pass in the previous build on the same buildbot. I don't know if it makes sense to pass None to headers and/or trailers. Please revert the change or fix the test. ((But we must continue to test headers=None and trailers=None, even if these parameters now raise a TypeError). ====================================================================== ERROR: test_keywords (test.test_os.TestSendfile) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_os.py", line 2334, in test_keywords headers=None, trailers=None, flags=0) TypeError: sendfile() headers must be a sequence or None ---------- messages: 250292 nosy: haypo, martin.panter priority: normal severity: normal status: open title: test_os.TestSendfile.test_keywords() introduced a regression versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 08:59:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Sep 2015 06:59:28 +0000 Subject: [issue24984] document AF_BLUETOOTH socket address formats In-Reply-To: <1441210010.76.0.198064903239.issue24984@psf.upfronthosting.co.za> Message-ID: <20150909065924.115088.9536@psf.io> Roundup Robot added the comment: New changeset da9b26670e44 by Martin Panter in branch '3.4': Issue #24984: Document AF_BLUETOOTH socket address formats https://hg.python.org/cpython/rev/da9b26670e44 New changeset 4ce8450da22d by Martin Panter in branch '3.5': Issue #24984: Merge 3.4 into 3.5 https://hg.python.org/cpython/rev/4ce8450da22d New changeset ec4ba0cb1ce0 by Martin Panter in branch 'default': Issue #24984: Merge 3.5 into 3.6 https://hg.python.org/cpython/rev/ec4ba0cb1ce0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 09:07:06 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 09 Sep 2015 07:07:06 +0000 Subject: [issue25038] test_os.TestSendfile.test_keywords() introduced a regression In-Reply-To: <1441781810.94.0.0104425602054.issue25038@psf.upfronthosting.co.za> Message-ID: <1441782426.0.0.940409251296.issue25038@psf.upfronthosting.co.za> Martin Panter added the comment: I believe revision e42e2bd47168 is actually the cure, and test failure is actually caused by a new test I added in revision fdb5d84f9948. So hopefully things are fixed now, but I will keep an eye on the buildbots. In fdb5d84f9948, I originally added the test_keywords() test to ensure the correct parameter name of ?count? to sendfile(). Neither headers=None nor trailers=None were ever supported. It is just that the documentation and error messages which mislead me to write that test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 10:22:02 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 09 Sep 2015 08:22:02 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441786922.25.0.0981051892657.issue23517@psf.upfronthosting.co.za> Larry Hastings added the comment: Given Victor's reluctance to get this in to 3.5.0, this can't even be marked as a "deferred blocker" anymore. Demoting to normal priority. ---------- priority: deferred blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 10:31:25 2015 From: report at bugs.python.org (Paul Moore) Date: Wed, 09 Sep 2015 08:31:25 +0000 Subject: [issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules In-Reply-To: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za> Message-ID: <1441787485.74.0.876489243438.issue25027@psf.upfronthosting.co.za> Paul Moore added the comment: > Maybe we can special-case pip uninstalling it from the site-packages folder? *Paul* - any thoughts? Sorry, I've been following this thread but it's been moving pretty fast, so I'm probably replying too late to be helpful now :-( One alternative thought I had was to bundle vcruntime140.dll in a separate wheel, which other wheels can depend on. Then we get pip's usual dependency resolution to handle ensuring that the runtime is present. It's possible to special-case vcruntime, what I'd do is modify distutils to omit vcruntime140.dll from the RECORD file - then nothing (pip, distlib, other install tools) views the vcruntime file as being "owned" by a particular package. I'm not overly keen on that solution, though, as it's clearly a hack and would be a maintainability issue going forward. But it does keep the code changes isolated to the core, rather than needing pip/setuptools changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 11:08:30 2015 From: report at bugs.python.org (Camilla Montonen) Date: Wed, 09 Sep 2015 09:08:30 +0000 Subject: [issue25039] Docs: Link to Stackless Python in Design and History FAQ section is broken Message-ID: <1441789710.22.0.139129124794.issue25039@psf.upfronthosting.co.za> New submission from Camilla Montonen: The link to Stackless Python here https://docs.python.org/2/faq/design.html#can-t-you-emulate-threads-in-the-interpreter-instead-of-relying-on-an-os-specific-thread-implementation is broken. I get an "Internal Server Error" when trying to access it. ---------- assignee: docs at python components: Documentation messages: 250297 nosy: Winterflower, docs at python priority: normal severity: normal status: open title: Docs: Link to Stackless Python in Design and History FAQ section is broken versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 11:13:10 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 09 Sep 2015 09:13:10 +0000 Subject: [issue24984] document AF_BLUETOOTH socket address formats In-Reply-To: <1441210010.76.0.198064903239.issue24984@psf.upfronthosting.co.za> Message-ID: <1441789990.55.0.0236421427156.issue24984@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Tim. I think we can also create separate issues for AF_PACKET and AF_CAN and mark them as "easy". ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 11:21:41 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 09 Sep 2015 09:21:41 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1417530925.56.0.55888060474.issue22980@psf.upfronthosting.co.za> Message-ID: <1441790501.66.0.571254678807.issue22980@psf.upfronthosting.co.za> Larry Hastings added the comment: Here's an attempt at a What's New section for this change. I expect it's wrong! Maybe someone can fix it. Maybe it's actually better than not having one at all. Can we maybe get a round or two of edits on this and get something in for 3.5 final? ---------- Added file: http://bugs.python.org/file40420/larry.whatsnew35.ext.module.suffix.diff.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 11:25:50 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 09 Sep 2015 09:25:50 +0000 Subject: [issue25039] Docs: Link to Stackless Python in Design and History FAQ section is broken In-Reply-To: <1441789710.22.0.139129124794.issue25039@psf.upfronthosting.co.za> Message-ID: <1441790750.96.0.192767534833.issue25039@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report, Camilla. This could be a temporary problem with the Stackless website. Can you ask on http://www.stackless.com/mailman/listinfo/stackless? ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 12:51:52 2015 From: report at bugs.python.org (Laura Creighton) Date: Wed, 09 Sep 2015 10:51:52 +0000 Subject: [issue25039] Docs: Link to Stackless Python in Design and History FAQ section is broken In-Reply-To: <1441789710.22.0.139129124794.issue25039@psf.upfronthosting.co.za> Message-ID: <1441795912.86.0.0859190853417.issue25039@psf.upfronthosting.co.za> Laura Creighton added the comment: I do not think that asking there will help right now because the problem is that the whole site is down, and mailman isn't running either ... ---------- nosy: +lac _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 14:31:06 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 09 Sep 2015 12:31:06 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1417530925.56.0.55888060474.issue22980@psf.upfronthosting.co.za> Message-ID: <1441801866.84.0.0106961418578.issue22980@psf.upfronthosting.co.za> Berker Peksag added the comment: Adding Yury since he and Elvis are working on Doc/whatsnew/3.5.rst and they might want to take a look at the latest patch. ---------- nosy: +berker.peksag, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 14:54:11 2015 From: report at bugs.python.org (Gautier Portet) Date: Wed, 09 Sep 2015 12:54:11 +0000 Subject: [issue25040] xml.sax.make_parser makes bad use of parser_list argument default value Message-ID: <1441803251.56.0.483557486647.issue25040@psf.upfronthosting.co.za> New submission from Gautier Portet: When using xml.sax.make_parser(), there is a potential problem with the parser_list default value. If another module used a default value, like the problematic parser from PyXML, your module will also use it as default parser. You should change this: def make_parser(parser_list = []): by this : def make_parser(parser_list = None): And change the following code accordingly. BTW, I fixed by problem by simply using xml.sax.make_parser([]) ---------- components: XML messages: 250303 nosy: Gautier Portet priority: normal severity: normal status: open title: xml.sax.make_parser makes bad use of parser_list argument default value type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 14:58:01 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 09 Sep 2015 12:58:01 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441803481.8.0.869358682267.issue23517@psf.upfronthosting.co.za> Larry Hastings added the comment: Given Victor's reluctance to get this in to 3.5.0, this can't even be marked as a "deferred blocker" anymore. Demoting to normal priority. ---------- priority: deferred blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 15:05:24 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 09 Sep 2015 13:05:24 +0000 Subject: [issue25035] Getter/setter for argparse keys In-Reply-To: <1441753315.66.0.921652253193.issue25035@psf.upfronthosting.co.za> Message-ID: <1441803924.48.0.214541598041.issue25035@psf.upfronthosting.co.za> R. David Murray added the comment: Can you provide some specific use cases, please? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 15:07:57 2015 From: report at bugs.python.org (Tim Tisdall) Date: Wed, 09 Sep 2015 13:07:57 +0000 Subject: [issue25041] document AF_PACKET socket address format Message-ID: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za> New submission from Tim Tisdall: As mentioned in #24984, I'm making another issue to document the address format for AF_PACKET. In this case there's already documentation in Modules/socketmodule.c that says: - an AF_PACKET socket address is a tuple containing a string specifying the ethernet interface and an integer specifying the Ethernet protocol number to be received. For example: ("eth0",0x1234). Optional 3rd,4th,5th elements in the tuple specify packet-type and ha-type/addr. But nothing has been added to Doc/library/socket.rst . The documentation needs to be confirmed with the code. (It probably should be altered somewhat to state how you "specify packet-type and ha-type/addr"... and maybe what a "ha-type/addr" is... A quick Google search found this very useful reference: https://books.google.ca/books?id=Chr1NDlUcI8C&pg=PA472&ots=OCEwyjdXJo&sig=PuNG72WIvv4-A924f9MvzPtgQDc&hl=en&sa=X&ved=0CE8Q6AEwCGoVChMI6IiTyoDqxwIVCTs-Ch3bCAXy#v=onepage&q&f=false ) ---------- assignee: docs at python components: Documentation messages: 250306 nosy: Tim.Tisdall, docs at python priority: normal severity: normal status: open title: document AF_PACKET socket address format type: enhancement versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 15:09:58 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Sep 2015 13:09:58 +0000 Subject: [issue25041] document AF_PACKET socket address format In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za> Message-ID: <1441804198.07.0.733733816052.issue25041@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 15:11:58 2015 From: report at bugs.python.org (Tim Tisdall) Date: Wed, 09 Sep 2015 13:11:58 +0000 Subject: [issue25041] document AF_PACKET socket address format In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za> Message-ID: <1441804318.05.0.466039652782.issue25041@psf.upfronthosting.co.za> Tim Tisdall added the comment: Right now the docs say "Certain other address families (:const:`AF_PACKET`, :const:`AF_CAN`) support specific representations.". I was going to create a separate issue for AF_CAN, but it seems that it's already documented... When documentation is added for AF_PACKET, please remove the above mentioned line entirely as AF_CAN is already documented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 15:12:16 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 09 Sep 2015 13:12:16 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1417530925.56.0.55888060474.issue22980@psf.upfronthosting.co.za> Message-ID: <1441804336.68.0.972445742153.issue22980@psf.upfronthosting.co.za> Steve Dower added the comment: Only thing I'd add is that the extra tag is optional (on Windows at least), and Python will happily import extensions without it. But extensions with a mismatched tag won't be loaded. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 15:13:12 2015 From: report at bugs.python.org (Tim Tisdall) Date: Wed, 09 Sep 2015 13:13:12 +0000 Subject: [issue24984] document AF_BLUETOOTH socket address formats In-Reply-To: <1441210010.76.0.198064903239.issue24984@psf.upfronthosting.co.za> Message-ID: <1441804392.61.0.477129872513.issue24984@psf.upfronthosting.co.za> Tim Tisdall added the comment: I created #25041 to handle AF_PACKET. It seems AF_CAN is already in the docs, so the person making the change for AF_PACKET can just remove that mention of AF_CAN farther down. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 15:48:15 2015 From: report at bugs.python.org (Paul Moore) Date: Wed, 09 Sep 2015 13:48:15 +0000 Subject: [issue25042] Create an "embedding SDK" distribution? Message-ID: <1441806495.82.0.106064192938.issue25042@psf.upfronthosting.co.za> New submission from Paul Moore: At the moment, building an application that embeds Python requires the user to have a full install of Python on the build machine, to get access to the include and library files. Now that we provide an embeddable build of Python on Windows, would it be worth also having an "embedding SDK" which consisted of a zipfile distribution of the include and lib files? This may be pointless, as it's not that hard to install Python onto a development system, and even if it is, you'd just need to grab the "include" and "libs" directories from an existing installation, so creating your own SDK is pretty trivial. It's also extra work in the release process to provide the extra distribution file. So I'm OK if this is viewed as not worth it. The main advantage of having such an "SDK" would be strengthening the message that embedding is a well-supported scenario. ---------- assignee: steve.dower components: Windows messages: 250310 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: low severity: normal status: open title: Create an "embedding SDK" distribution? type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 15:51:04 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 09 Sep 2015 13:51:04 +0000 Subject: [issue23144] html.parser.HTMLParser: setting 'convert_charrefs = True' leads to dropped text In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za> Message-ID: <1441806664.72.0.811421542199.issue23144@psf.upfronthosting.co.za> Larry Hastings added the comment: The Misc/NEWS entry for this was added under Python 3.5.0rc3. But, since no pull request has been made for this change, this change hasn't been merged into 3.5.0. It will ship as part of Python 3.5.1. I've moved the Misc/NEWS entry accordingly. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 15:56:38 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Sep 2015 13:56:38 +0000 Subject: [issue25029] MemoryError in test_strptime In-Reply-To: <1441708213.63.0.825636103813.issue25029@psf.upfronthosting.co.za> Message-ID: <20150909135634.101490.54077@psf.io> Roundup Robot added the comment: New changeset bd7aed300a1b by Steve Dower in branch '3.5': Issue #25029: MemoryError in test_strptime https://hg.python.org/cpython/rev/bd7aed300a1b New changeset 706b9eaba734 by Steve Dower in branch '3.5': Merge fix for #25029 https://hg.python.org/cpython/rev/706b9eaba734 New changeset cceaccb6ec5a by Steve Dower in branch '3.5': Adds Mics/NEWS entry for issue #25029. https://hg.python.org/cpython/rev/cceaccb6ec5a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 15:56:39 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Sep 2015 13:56:39 +0000 Subject: [issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules In-Reply-To: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za> Message-ID: <20150909135633.101490.4532@psf.io> Roundup Robot added the comment: New changeset 8374472c6a6e by Steve Dower in branch '3.5': Issue #25027: Reverts partial-static build options and adds vcruntime140.dll to Windows installation. https://hg.python.org/cpython/rev/8374472c6a6e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 16:12:30 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 09 Sep 2015 14:12:30 +0000 Subject: [issue25041] document AF_PACKET socket address format In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za> Message-ID: <1441807950.34.0.0686189763127.issue25041@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +easy stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 17:00:39 2015 From: report at bugs.python.org (Tim Tisdall) Date: Wed, 09 Sep 2015 15:00:39 +0000 Subject: [issue25043] document socket constants for Bluetooth Message-ID: <1441810839.86.0.110626914047.issue25043@psf.upfronthosting.co.za> New submission from Tim Tisdall: further to #24984, I noticed there are constants that aren't mentioned in the docs. Also BDADDR_ALL is missing (which is defined in Bluez's bluetooth.h) so I added it. Now, I'm not totally clear on supplying multi-version patches... I know 3.5 is in "freeze" so I'm guessing adding the BDADDR_ALL constant is a no-no. I guess I checkout out the different version branches, make the changes, and then create a patch labelled for which version it's for? (I see the patch has the hash for which commit it's to be applied to, but not which branch) The repo is down right now, so I'll include a patch once I can update my local copy... :( ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 250314 nosy: Tim.Tisdall, docs at python priority: normal severity: normal status: open title: document socket constants for Bluetooth type: enhancement versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 17:17:06 2015 From: report at bugs.python.org (John Beck) Date: Wed, 09 Sep 2015 15:17:06 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1441811826.57.0.44865993092.issue25003@psf.upfronthosting.co.za> John Beck added the comment: @haypo: Yes, that patch works (applied to 3.5.0rc3; proxy problems are preventing me from updating my clone of the default branch at the moment) i.e., pyconfig.h shows: #define HAVE_GETRANDOM_SYSCALL 1 To answer your other questions: * Calling syscall(SYS_getrandom, buffer, size, 0) does work on Solaris. * Our does declare syscall(). * Solaris does not use the GNU C library, but our own libc, which does support getrandom(3) as of Solaris 11.3 (which will be released in the near future) and Solaris 12 (which is in Beta but has a release date in the more distant future). Prior to applying this patch, I had needed to tweak py_getrandom() to recognize EINVAL in addition to ENOSYS as sufficient reason to turn off getrandom_works. I still have that tweak in place, but have not yet tried backing it out to see if things still behave with your patch. Let me know if there is any more information I can provide, and thanks for your attention to this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 17:27:22 2015 From: report at bugs.python.org (Tim Tisdall) Date: Wed, 09 Sep 2015 15:27:22 +0000 Subject: [issue25044] bring BTPROTO_SCO inline with other Bluetooth protocols Message-ID: <1441812442.49.0.0898907161184.issue25044@psf.upfronthosting.co.za> New submission from Tim Tisdall: All of the BTPROTO_ protocols accept tuples with Bluetooth addresses as regular strings. SCO accepts a byte-string which represents a Bluetooth address. The change was made at 23ab586c427a With the current implementation we get this error: >>> import socket >>> x = socket.socket(socket.AF_BLUETOOTH, socket.SOCK_SEQPACKET, socket.BTPROTO_SCO) >>> x.bind(socket.BDADDR_ANY) Traceback (most recent call last): File "", line 1, in OSError: getsockaddrarg: wrong format This is because socket.BDADDR_ANY is a string while the bind() is expecting a binary string. So the workaround would be to call x.bind(socket.BDADDR_ANY.encode()) . Is it acceptable to change it to accept a regular string to match the other address methods and constants? This would be essentially a breaking change, however on something that wasn't really documented prior to #24984 . I'll submit a patch when the repo is back up... ---------- messages: 250316 nosy: Tim.Tisdall priority: normal severity: normal status: open title: bring BTPROTO_SCO inline with other Bluetooth protocols type: enhancement versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 17:27:52 2015 From: report at bugs.python.org (Tim Tisdall) Date: Wed, 09 Sep 2015 15:27:52 +0000 Subject: [issue25044] bring BTPROTO_SCO inline with other Bluetooth protocols In-Reply-To: <1441812442.49.0.0898907161184.issue25044@psf.upfronthosting.co.za> Message-ID: <1441812472.69.0.691005355112.issue25044@psf.upfronthosting.co.za> Changes by Tim Tisdall : ---------- components: +Extension Modules _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 17:36:26 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 09 Sep 2015 15:36:26 +0000 Subject: [issue23447] Import fails when doing a circular import involving an `import *` In-Reply-To: <1423679925.56.0.995999383567.issue23447@psf.upfronthosting.co.za> Message-ID: <1441812986.37.0.268711340217.issue23447@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 17:39:19 2015 From: report at bugs.python.org (Philippe Lambotte) Date: Wed, 09 Sep 2015 15:39:19 +0000 Subject: [issue25045] smtplib throws exception TypeError: readline() Message-ID: <1441813159.97.0.113522893348.issue25045@psf.upfronthosting.co.za> New submission from Philippe Lambotte: smtplib smtpserver.ehlo() will throw exception. The error message : Traceback (most recent call last): File "snippet.email.sendmail.py", line 34, in smtpserver.ehlo() File "/usr/lib/python3.2/smtplib.py", line 421, in ehlo (code, msg) = self.getreply() File "/usr/lib/python3.2/smtplib.py", line 367, in getreply line = self.file.readline(_MAXLINE + 1) TypeError: readline() takes exactly 1 positional argument (2 given) smtplib works with python 2.7, but not with 3.2 If I remove the passed parameter, it works in 3.2 : line = self.file.readline() ---------- components: email messages: 250317 nosy: barry, phlambotte, r.david.murray priority: normal severity: normal status: open title: smtplib throws exception TypeError: readline() type: behavior versions: Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 18:05:08 2015 From: report at bugs.python.org (Julio) Date: Wed, 09 Sep 2015 16:05:08 +0000 Subject: [issue25046] ImportError: No module named Multiprocessing Message-ID: <1441814708.41.0.657407363164.issue25046@psf.upfronthosting.co.za> New submission from Julio: Hi!, I have a problem to import a multiprocessing module. I am using Python 2.7 and Windows 8. The program (.py) is executed since MS-DOS console. If I run the program the output is "ImportError: No module named multiprocessing". If I execute "import multiprocessing" on Python Command Line I don't have problems, but It isn't useful for my program, because I need to import since my own file .py What do you recommend me?. I need to get benefit from the process-based parallelism and to use several processors. Thank you so much! ---------- components: Library (Lib) messages: 250318 nosy: jlmora priority: normal severity: normal status: open title: ImportError: No module named Multiprocessing versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 18:11:19 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 09 Sep 2015 16:11:19 +0000 Subject: [issue25042] Create an "embedding SDK" distribution? In-Reply-To: <1441806495.82.0.106064192938.issue25042@psf.upfronthosting.co.za> Message-ID: <1441815079.78.0.550374308746.issue25042@psf.upfronthosting.co.za> Steve Dower added the comment: It may be worth it. What I'd rather have people do is to install using the regular installer and include both debug symbols and debug binaries. This will put it in a registered location that can be auto detected (I have written a template for Visual Studio that does just that for extensions - will be released soon), and also gives a pretty solid debugging experience. Probably we just need to get word out that it's a valuable scenario and do some walkthroughs/tutorials (good PyCon topic?). In my paid-work life doing developer tools for Python developers, it's certainly something that we as Microsoft are willing to offer (with VS tie-ins, obviously - when you're paid you are also owned :) ), but I've got no opposition to supporting this. To do an extra package, I'd need to hear that: * people aren't able to install a full Python distro in these contexts * people *are* able/willing to extract and configure a ZIP distro of the same things * people aren't confident building against a full distro and releasing with the embedded distro >From a Visual Studio POV, making a NuGet package containing the embedded Python distro and the build headers would be pretty cool, simply for the IDE integration. Doesn't really help other IDEs, but since they're all different I think they'll all need specific solutions anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 18:12:10 2015 From: report at bugs.python.org (Stefan Krah) Date: Wed, 09 Sep 2015 16:12:10 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1441815130.67.0.995778427024.issue24999@psf.upfronthosting.co.za> Stefan Krah added the comment: Thanks, I've contacted Robert. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 18:18:42 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 09 Sep 2015 16:18:42 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) In-Reply-To: <1441811826.57.0.44865993092.issue25003@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > Prior to applying this patch, I had needed to tweak py_getrandom() to recognize EINVAL in addition to ENOSYS as sufficient reason to turn off getrandom_works. In which case getrandom() fails with EINVAL? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 18:19:15 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 09 Sep 2015 16:19:15 +0000 Subject: [issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2). In-Reply-To: <1441694117.96.0.393183554729.issue25026@psf.upfronthosting.co.za> Message-ID: <1441815555.65.0.160356142726.issue25026@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The question is: are ioctl codes outside of the unsigned int range used on BSD family or Mac OS X? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 18:27:45 2015 From: report at bugs.python.org (John Beck) Date: Wed, 09 Sep 2015 16:27:45 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1441816065.76.0.889279765297.issue25003@psf.upfronthosting.co.za> John Beck added the comment: Yes, the syscall was failing with EINVAL. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 18:52:59 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 09 Sep 2015 16:52:59 +0000 Subject: [issue25040] xml.sax.make_parser makes bad use of parser_list argument default value In-Reply-To: <1441803251.56.0.483557486647.issue25040@psf.upfronthosting.co.za> Message-ID: <1441817579.76.0.589407759455.issue25040@psf.upfronthosting.co.za> R. David Murray added the comment: Can you explain how this manifests? make_parser neither mutates the list nor returns it, so I don't see how this is a bug. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 19:00:39 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 09 Sep 2015 17:00:39 +0000 Subject: [issue25045] smtplib throws exception TypeError: readline() In-Reply-To: <1441813159.97.0.113522893348.issue25045@psf.upfronthosting.co.za> Message-ID: <1441818039.27.0.354722527774.issue25045@psf.upfronthosting.co.za> R. David Murray added the comment: Can you explain how to reproduce the problem? That code is working fine in the unit tests, and the file object returned by socket.makefile has a readline method that accepts a size argument, so I'm guessing there is something odd going on with your code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 19:04:12 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 09 Sep 2015 17:04:12 +0000 Subject: [issue25046] ImportError: No module named Multiprocessing In-Reply-To: <1441814708.41.0.657407363164.issue25046@psf.upfronthosting.co.za> Message-ID: <1441818252.73.0.375772782433.issue25046@psf.upfronthosting.co.za> R. David Murray added the comment: I suggest posting your question to the python-list mailing list, you are much more likely to get help there. This tracker is for bugs in python, and what you describe sounds like a problem with your program and/or your setup (if 'import multiprocessing' works at the command line, it should work in a program if run by the same python interpreter as you used at the command line). ---------- nosy: +r.david.murray resolution: -> works for me stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 20:04:52 2015 From: report at bugs.python.org (Philippe Lambotte) Date: Wed, 09 Sep 2015 18:04:52 +0000 Subject: [issue25045] smtplib throws exception TypeError: readline() In-Reply-To: <1441813159.97.0.113522893348.issue25045@psf.upfronthosting.co.za> Message-ID: <1441821892.34.0.102242072362.issue25045@psf.upfronthosting.co.za> Philippe Lambotte added the comment: The code is : #!/usr/bin/env python3 #-*- coding: utf-8 -*- import smtplib, os from email.mime.multipart import MIMEMultipart from email.mime.base import MIMEBase from email.mime.text import MIMEText from email.utils import COMMASPACE, formatdate from email import encoders EMAIL_FROM = 'emailfrom at mywebsite.net' EMAIL_TO = ['emailto at mywebsite.net'] SENDER_LOGIN = 'mylogin' SENDER_PASSWORD = 'mypassword' SMTP_HOST = 'smtp.myhoster.net' SMTP_PORT = 587 SMTP_IS_STARTTLS = True SUBJECT ="This is the subject" TEXT = 'This is a test' FILES = list() # ['dummy_text.txt'] def send_mail_with_attachment( send_from, send_to, subject, text, files=[], server="localhost", port=587, username='', password='', isTls=True): msg = MIMEMultipart() msg['From'] = send_from msg['To'] = COMMASPACE.join(send_to) msg['Date'] = formatdate(localtime = True) msg['Subject'] = subject msg.attach( MIMEText(text) ) if len(files) > 0 : for f in files: part = MIMEBase('application', "octet-stream") part.set_payload( open(f,"rb").read() ) encoders.encode_base64(part) part.add_header('Content-Disposition', 'attachment; filename="{0}"'.format(os.path.basename(f))) msg.attach(part) smtp = smtplib.SMTP(server, port) if isTls: smtp.starttls() smtp.login(username,password) smtp.sendmail(send_from, send_to, msg.as_string()) smtp.quit() send_mail_with_attachment(EMAIL_FROM,EMAIL_TO,SUBJECT,TEXT,FILES,SMTP_HOST,SMTP_PORT,SENDER_LOGIN,SENDER_PASSWORD,SMTP_IS_STARTTLS) When I run it, I have the following message : Traceback (most recent call last): File "snippet.email.envoyer_un_mail_au_format_html.py", line 46, in send_mail_with_attachment(EMAIL_FROM,EMAIL_TO,SUBJECT,TEXT,FILES,SMTP_HOST,SMTP_PORT,SENDER_LOGIN,SENDER_PASSWORD,SMTP_IS_STARTTLS) File "snippet.email.envoyer_un_mail_au_format_html.py", line 42, in send_mail_with_attachment smtp.login(username,password) File "/usr/lib/python3.2/smtplib.py", line 595, in login self.ehlo_or_helo_if_needed() File "/usr/lib/python3.2/smtplib.py", line 554, in ehlo_or_helo_if_needed if not (200 <= self.ehlo()[0] <= 299): File "/usr/lib/python3.2/smtplib.py", line 421, in ehlo (code, msg) = self.getreply() File "/usr/lib/python3.2/smtplib.py", line 367, in getreply line = self.file.readline(_MAXLINE + 1) TypeError: readline() takes exactly 1 positional argument (2 given) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 21:43:38 2015 From: report at bugs.python.org (Simeon Warner) Date: Wed, 09 Sep 2015 19:43:38 +0000 Subject: [issue25047] xml.etree.ElementTree encoding declaration should be capital ('UTF-8') rather than lowercase ('utf-8') Message-ID: <1441827818.89.0.928682692456.issue25047@psf.upfronthosting.co.za> New submission from Simeon Warner: Seems that in python3 the XML encoding declaration from xml.etree.ElementTree has changed from 2.x in that it is now lowercased, e.g. 'utf-8'. While the XML spec [1] says that decoders _SHOULD_ understand this, the encoding string _SHOULD_ be 'UTF-8'. It seems that keeping to the standard in the vein of being strictly conformant in encoding, lax in decoding will give maximum compatibility. It also seems like an unhelpful change for 2.x to 3.x migration though that is perhaps a minor issue (but how I noticed it). Can show with: >cat a.py from xml.etree.ElementTree import ElementTree, Element import os, sys print(sys.version_info) if sys.version_info > (3, 0): fp = os.fdopen(sys.stdout.fileno(), 'wb') else: fp = sys.stdout root = Element('hello',{'beer':'good'}) ElementTree(root).write(fp, encoding='UTF-8', xml_declaration=True) fp.write(b"\n") >python a.py sys.version_info(major=2, minor=7, micro=5, releaselevel='final', serial=0) >python3 a.py sys.version_info(major=3, minor=4, micro=2, releaselevel='final', serial=0) Cheers, Simeon [1] "In an encoding declaration, the values "UTF-8", "UTF-16", ... should be used for the various encodings and transformations of Unicode" and then later "XML processors should match character encoding names in a case-insensitive way". ---------- components: XML messages: 250328 nosy: zimeon priority: normal severity: normal status: open title: xml.etree.ElementTree encoding declaration should be capital ('UTF-8') rather than lowercase ('utf-8') type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 22:10:11 2015 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Sep 2015 20:10:11 +0000 Subject: [issue24272] PEP 484 docs In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za> Message-ID: <1441829411.79.0.0852749482745.issue24272@psf.upfronthosting.co.za> Guido van Rossum added the comment: Pull Request: https://bitbucket.org/larry/cpython350/pull-requests/24/docs-update-for-typing-module/diff ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 22:13:30 2015 From: report at bugs.python.org (Sworddragon) Date: Wed, 09 Sep 2015 20:13:30 +0000 Subject: [issue25035] Getter/setter for argparse keys In-Reply-To: <1441753315.66.0.921652253193.issue25035@psf.upfronthosting.co.za> Message-ID: <1441829610.61.0.454453562716.issue25035@psf.upfronthosting.co.za> Sworddragon added the comment: I was myself in the case where I needed the values of the choices key of 2 specific arguments. Currently I'm solving this by storing them in variables but probably it could be cleaner by using a getter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 22:33:01 2015 From: report at bugs.python.org (Ivan Levkivskyi) Date: Wed, 09 Sep 2015 20:33:01 +0000 Subject: [issue24272] PEP 484 docs In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za> Message-ID: <1441830781.3.0.453756310144.issue24272@psf.upfronthosting.co.za> Ivan Levkivskyi added the comment: Thank you, Guido! I have noticed single quotes in line 38: type hinted using `Callable[[Arg1Type, Arg2Type], ReturnType]` I think it would be logical to replace it with double quotes: ``Callable[[Arg1Type, Arg2Type], ReturnType]`` as Zachary did in the rest of the text. By the way, you have marked my patch as Daniels and vice versa in the commit descriptions, but that probably does not matter :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 22:38:09 2015 From: report at bugs.python.org (Guido van Rossum) Date: Wed, 09 Sep 2015 20:38:09 +0000 Subject: [issue24272] PEP 484 docs In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za> Message-ID: <1441831089.19.0.671815066885.issue24272@psf.upfronthosting.co.za> Guido van Rossum added the comment: I apologize for the mix-up! The code review tool didn't help. Regarding the single quotes, there seem to be a bunch more of these, and as cutting a PR is a fair bit of labor I'd rather not fix that. We can fix this once 3.5.0 it out of the door (hopefully this weekend). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 22:40:42 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 09 Sep 2015 20:40:42 +0000 Subject: [issue24857] mock: Crash on comparing call_args with long strings In-Reply-To: <1439454881.01.0.0909899225137.issue24857@psf.upfronthosting.co.za> Message-ID: <20150909204035.101500.65134@psf.io> Roundup Robot added the comment: New changeset 83ea55a1204a by Berker Peksag in branch '3.4': Issue #24857: Comparing call_args to a long sequence now correctly returns a https://hg.python.org/cpython/rev/83ea55a1204a New changeset df91c1879e56 by Berker Peksag in branch '3.5': Issue #24857: Comparing call_args to a long sequence now correctly returns a https://hg.python.org/cpython/rev/df91c1879e56 New changeset 6853b4bc0b22 by Berker Peksag in branch 'default': Issue #24857: Comparing call_args to a long sequence now correctly returns a https://hg.python.org/cpython/rev/6853b4bc0b22 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 22:45:22 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 09 Sep 2015 20:45:22 +0000 Subject: [issue24857] mock: Crash on comparing call_args with long strings In-Reply-To: <1439454881.01.0.0909899225137.issue24857@psf.upfronthosting.co.za> Message-ID: <1441831521.99.0.108715158336.issue24857@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! For the record, the __ne__ issue created by A Kaptur is issue 24997. ---------- nosy: +berker.peksag resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 23:35:00 2015 From: report at bugs.python.org (Marc Bouvier) Date: Wed, 09 Sep 2015 21:35:00 +0000 Subject: [issue25048] %e Directive Missing in Datetime Documentation Message-ID: <1441834500.22.0.00847516918827.issue25048@psf.upfronthosting.co.za> New submission from Marc Bouvier: The %e directive is missing in the Datetime documentation. I have tried this directive in 2.6.6, 2.7.2, and 2.7.10 using datetime.datetime.strftime(datetime.datetime.now(), '%A, %B %e, %Y') and it works in all cases. The below documentation line is pulled from, http://linux.die.net/man/3/strftime. The behavior is the same. %e Like %d, the day of the month as a decimal number, but a leading zero is replaced by a space. (SU) ---------- assignee: docs at python components: Documentation messages: 250335 nosy: docs at python, marcrbouvier priority: normal severity: normal status: open title: %e Directive Missing in Datetime Documentation type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 23:38:23 2015 From: report at bugs.python.org (Marc Bouvier) Date: Wed, 09 Sep 2015 21:38:23 +0000 Subject: [issue25048] %e Directive Missing in Datetime Documentation In-Reply-To: <1441834500.22.0.00847516918827.issue25048@psf.upfronthosting.co.za> Message-ID: <1441834703.4.0.840655521797.issue25048@psf.upfronthosting.co.za> Marc Bouvier added the comment: Sorry, the documentation page I am looking at is https://docs.python.org/2/library/datetime.html#strftime-and-strptime-behavior and https://docs.python.org/3/library/datetime.html#strftime-and-strptime-behavior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 23:45:09 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 09 Sep 2015 21:45:09 +0000 Subject: [issue25048] %e Directive Missing in Datetime Documentation In-Reply-To: <1441834500.22.0.00847516918827.issue25048@psf.upfronthosting.co.za> Message-ID: <1441835109.69.0.576415455335.issue25048@psf.upfronthosting.co.za> R. David Murray added the comment: strftime passes the string through to the OS, which sometimes supports more format codes than the ones documented as working on all platforms. There is a note in the docs about this. ---------- nosy: +r.david.murray resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 9 23:45:17 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 09 Sep 2015 21:45:17 +0000 Subject: [issue25048] %e Directive Missing in Datetime Documentation In-Reply-To: <1441834500.22.0.00847516918827.issue25048@psf.upfronthosting.co.za> Message-ID: <1441835117.27.0.366217809613.issue25048@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 00:29:34 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 09 Sep 2015 22:29:34 +0000 Subject: [issue25043] document socket constants for Bluetooth In-Reply-To: <1441810839.86.0.110626914047.issue25043@psf.upfronthosting.co.za> Message-ID: <1441837774.79.0.977118401059.issue25043@psf.upfronthosting.co.za> Martin Panter added the comment: The new constant would probably have to go into 3.6 only. I suggest make two patches: your documentation patch to be applied to 3.4+, and the new constant, against 3.6 only. Also, it would be good to get a unit test for the new constant. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 00:52:01 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 09 Sep 2015 22:52:01 +0000 Subject: [issue24984] document AF_BLUETOOTH socket address formats In-Reply-To: <1441210010.76.0.198064903239.issue24984@psf.upfronthosting.co.za> Message-ID: <1441839121.84.0.674591159497.issue24984@psf.upfronthosting.co.za> Martin Panter added the comment: Hello again. The patch I committed says BTPROTO_SCO accepts a bytes-like object. However I suspect it is actually restricted to bytes only: >>> s = socket(AF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_SCO) >>> s.bind(bytearray(b"12:23:34:45:56:67")) Traceback (most recent call last): File "", line 1, in OSError: getsockaddrarg: wrong format >>> s.bind(b"12:23:34:45:56:67") If you can confirm this, I will update the documentation. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 01:07:10 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 09 Sep 2015 23:07:10 +0000 Subject: [issue25044] bring BTPROTO_SCO inline with other Bluetooth protocols In-Reply-To: <1441812442.49.0.0898907161184.issue25044@psf.upfronthosting.co.za> Message-ID: <1441840030.21.0.0580415690346.issue25044@psf.upfronthosting.co.za> Martin Panter added the comment: Perhaps making it accept both bytes and text strings is a sensible option. Similar to how AF_INET can bind to both "localhost" and b"localhost". ---------- nosy: +martin.panter stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 01:09:40 2015 From: report at bugs.python.org (Matthias Klose) Date: Wed, 09 Sep 2015 23:09:40 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1417530925.56.0.55888060474.issue22980@psf.upfronthosting.co.za> Message-ID: <1441840180.22.0.3899706797.issue22980@psf.upfronthosting.co.za> Matthias Klose added the comment: thanks for the draft! I'm not sure how to describe this properly. The extension names are derived from https://wiki.debian.org/Multiarch/Tuples and this again is derived from the GNU triplets/quadruplets. there is no "cpu" and "os" part, depending on the architecture some ABI parts are either encoded in the "cpu" part or the "os" part. So what about just enumerating the most common cases (i386-linux-gnu, x86_64-linux-gnu, arm-linux-gnueabi (still used for the old Raspberry Pi), arm-linux-gnueabihf), and then point to the "spec"? The above examples have some irregular cases, most other cases just follow the triplets. I wouldn't mention x86_64-linux-gnux32 explicitly. Until now there are only unreleased or experimental distros. Not sure if it is worth mentioning that this would allow distributing "fat" wheels. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 01:15:38 2015 From: report at bugs.python.org (Mark Roseman) Date: Wed, 09 Sep 2015 23:15:38 +0000 Subject: [issue15347] IDLE - does not close if the debugger was active In-Reply-To: <1342207963.58.0.539607447258.issue15347@psf.upfronthosting.co.za> Message-ID: <1441840538.22.0.99922295675.issue15347@psf.upfronthosting.co.za> Mark Roseman added the comment: Debugger.py has a nested call to mainloop() ... which is almost always a bad idea. I'm betting the close is being handled in this mainloop, and there are no more events being generated, meaning the real mainloop towards the bottom of PyShell (which checks if we've got open windows) is never being reentered. Will try to look at this closer, but in case anyone has a chance in the interim... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 01:17:17 2015 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 09 Sep 2015 23:17:17 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1441840637.28.0.570067510454.issue24965@psf.upfronthosting.co.za> Changes by Eric V. Smith : Removed file: http://bugs.python.org/file40302/pep-498.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 01:17:23 2015 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 09 Sep 2015 23:17:23 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1441840643.26.0.737512053503.issue24965@psf.upfronthosting.co.za> Changes by Eric V. Smith : Removed file: http://bugs.python.org/file40316/pep-498-1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 01:17:31 2015 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 09 Sep 2015 23:17:31 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1441840651.72.0.65432422026.issue24965@psf.upfronthosting.co.za> Changes by Eric V. Smith : Removed file: http://bugs.python.org/file40317/pep-498-2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 01:57:43 2015 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 09 Sep 2015 23:57:43 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1441843063.01.0.84694228763.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: This implements the accepted PEP 498. The only other real change I plan on making is to do dynamic memory allocation when building the expressions that make up a JoinedStr AST node. The code has all of the places to do that already laid out, it's just a matter of hooking it up. There's one nit where I accept 'f' and 'F', but the PEP just says 'f'. I'm not sure if we should accept the upper case version. I'd think not, but all of the other ones (b, r, and u) do. I need to do one more scan for memory leaks. I've rearranged some code since the last time I checked for leaks, and that's always a recipe for some sneaking in. And I need to write some more tests, mostly for syntax errors, but also for a few edge conditions. Comments welcome. ---------- Added file: http://bugs.python.org/file40421/pep-498-3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 03:07:09 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 10 Sep 2015 01:07:09 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1441843063.01.0.84694228763.issue24965@psf.upfronthosting.co.za> Message-ID: <20150909210704.575e8fa1@limelight.wooz.org> Barry A. Warsaw added the comment: On Sep 09, 2015, at 11:57 PM, Eric V. Smith wrote: >There's one nit where I accept 'f' and 'F', but the PEP just says 'f'. I'm >not sure if we should accept the upper case version. I'd think not, but all >of the other ones (b, r, and u) do. I think it should be consistent with the other prefixes. Shouldn't be a big deal to amend the PEP to describe this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 04:14:02 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 10 Sep 2015 02:14:02 +0000 Subject: [issue25047] xml.etree.ElementTree encoding declaration should be capital ('UTF-8') rather than lowercase ('utf-8') In-Reply-To: <1441827818.89.0.928682692456.issue25047@psf.upfronthosting.co.za> Message-ID: <1441851242.15.0.442133861561.issue25047@psf.upfronthosting.co.za> Martin Panter added the comment: I agree that Python should not be converting the supplied encoding name to lowercase, although I guess reverting this has the potential to upset people?s output (e.g. if they depend on the checksum or something). ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 04:16:20 2015 From: report at bugs.python.org (Larry Hastings) Date: Thu, 10 Sep 2015 02:16:20 +0000 Subject: [issue24272] PEP 484 docs In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za> Message-ID: <1441851380.08.0.855532321416.issue24272@psf.upfronthosting.co.za> Larry Hastings added the comment: Pull request accepted! Please forward-merge, thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 04:28:07 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 10 Sep 2015 02:28:07 +0000 Subject: [issue22622] ElementTree only writes declaration when passed encoding In-Reply-To: <1413198968.88.0.623198680069.issue22622@psf.upfronthosting.co.za> Message-ID: <1441852087.63.0.613398409113.issue22622@psf.upfronthosting.co.za> Martin Panter added the comment: As far as I can tell this was already working, even in 3.4.0a1 (the first pre-release of 3.4): >>> tree.write('/dev/stdout', xml_declaration=True) But it is not working in Python 2: >>> tree.write('/dev/stdout', xml_declaration=True) Looking at the history, I am confused because a 3.2.3 revision (df8609f1854d) comes up in the history of 2.7?s /Doc/library/xml.etree.elementtree.rst. Perhaps it is just that the documentation has inherited some wording from Python 3. Possibly also relevant: revision 57e631f and Issue 8047. ---------- nosy: +martin.panter stage: -> needs patch versions: +Python 2.7 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 04:39:10 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 10 Sep 2015 02:39:10 +0000 Subject: [issue24272] PEP 484 docs In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za> Message-ID: <1441852750.48.0.822316722716.issue24272@psf.upfronthosting.co.za> Guido van Rossum added the comment: Merged and pushed. Let's please use a new issue for any further patches. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 04:47:13 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Sep 2015 02:47:13 +0000 Subject: [issue22464] Speed up fractions implementation In-Reply-To: <1411407434.75.0.285038516488.issue22464@psf.upfronthosting.co.za> Message-ID: <20150910024710.27689.24443@psf.io> Roundup Robot added the comment: New changeset 6c8e2c6e3a99 by Yury Selivanov in branch '3.5': whatsnew/3.5: Mention issue 22464 https://hg.python.org/cpython/rev/6c8e2c6e3a99 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 04:50:45 2015 From: report at bugs.python.org (paul j3) Date: Thu, 10 Sep 2015 02:50:45 +0000 Subject: [issue25035] Getter/setter for argparse keys In-Reply-To: <1441753315.66.0.921652253193.issue25035@psf.upfronthosting.co.za> Message-ID: <1441853445.33.0.557635078168.issue25035@psf.upfronthosting.co.za> paul j3 added the comment: `parser.set_defaults` lets you set a default for any `dest`. It does not have to be connected with an argument. See what the docs say about using it to set an action linked to a subparser. `arg1 = parser.add_argument(...)` returns an `Action` object. The parser collects these objects in its lists, but you can also save a reference to it yourself. I'd suggest doing this in an interactive shell, and see for yourself the attributes of this object. Simply doing a 'print' on the object shows a number of the attributes (but not all). It is possible to view, and in some cases, even modify these attributes directly. `args.choices` gives you access to the `choices` attribute. I don't think there's a need for getter/setter methods for Action attributes. The attributes are accessible by normal Python object approaches. p.s. Another forum for asking argparse how-to questions is Stackoverflow. Just tag it 'argparse'. ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 05:14:54 2015 From: report at bugs.python.org (koobs) Date: Thu, 10 Sep 2015 03:14:54 +0000 Subject: [issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2). In-Reply-To: <1441694117.96.0.393183554729.issue25026@psf.upfronthosting.co.za> Message-ID: <1441854894.09.0.345589511233.issue25026@psf.upfronthosting.co.za> koobs added the comment: @Serhiy If anyone can provide me some test code (I dont know how to test it) I'm happy to test it on 'unpatched' 2.7 and 3.5 ports ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 05:41:08 2015 From: report at bugs.python.org (Sworddragon) Date: Thu, 10 Sep 2015 03:41:08 +0000 Subject: [issue25035] Getter/setter for argparse keys In-Reply-To: <1441753315.66.0.921652253193.issue25035@psf.upfronthosting.co.za> Message-ID: <1441856468.26.0.427271750484.issue25035@psf.upfronthosting.co.za> Sworddragon added the comment: I'm actually not fully sure why you are telling me this all, especially in this specific way. But I would also go the other way, by removing ArgumentParser.get_default and ArgumentParser.set_defaults if we think the current ways of getting/setting are enough. Mainly I think consistence is the important here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 06:24:08 2015 From: report at bugs.python.org (paul j3) Date: Thu, 10 Sep 2015 04:24:08 +0000 Subject: [issue25035] Getter/setter for argparse keys In-Reply-To: <1441753315.66.0.921652253193.issue25035@psf.upfronthosting.co.za> Message-ID: <1441859048.13.0.541137568155.issue25035@psf.upfronthosting.co.za> paul j3 added the comment: `get_default` and `set_defaults` are parser methods, and do more than set or get a particular Action attribute. 'Set' for example changes both the 'parser._defaults' attribute, and a 'action.default' attribute. Defaults are complex and can be defined in at least 3 different ways. 'choices' (and other things like 'required', 'nargs', even 'default') is an attribute of a specific Action (argument object). You normally only set these in one way, as parameters of the `add_argument` method. 'action.default' and 'action.choices' are 'public' attributes. 'parser._defaults' is a 'private' attribute. A setter method is the right way to change a 'private' attribute (if needed). It usually isn't need for a 'public' one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 10:04:18 2015 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 10 Sep 2015 08:04:18 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1441872258.59.0.511717726748.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: I discussed it with Guido and added 'F' to the PEP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 10:10:44 2015 From: report at bugs.python.org (Jurjen N.E. Bos) Date: Thu, 10 Sep 2015 08:10:44 +0000 Subject: [issue25049] Strange behavior under doctest: staticmethods have different __globals__ Message-ID: <1441872644.04.0.758819356949.issue25049@psf.upfronthosting.co.za> New submission from Jurjen N.E. Bos: I found a pretty obscure bug/documentation issue. It only happens if you use global variables in static methods under doctest. The thing is that this code fails under doctest, while anyone would expect it to work at first sight: class foo: @staticmethod def bar(): """ >>> GLOBAL = 5; foo.bar() 5 """ print(GLOBAL) The cause of the problem is that the static method has a __globals__ that for reasons beyond my understanding is not equal to the globals when run under doctest. This might be a doctest bug, or there might be a reason for it that I don't get: than it must be documented, before it stupifies others. The behaviour is the same under python 2 and 3. The attached file shows all (written for Python 3, but can be trivially adapted for python 2), including the workaround. ---------- components: Library (Lib) files: t.py messages: 250355 nosy: jneb priority: normal severity: normal status: open title: Strange behavior under doctest: staticmethods have different __globals__ type: enhancement Added file: http://bugs.python.org/file40422/t.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 10:23:03 2015 From: report at bugs.python.org (Adam Groszer) Date: Thu, 10 Sep 2015 08:23:03 +0000 Subject: [issue25050] windows installer does not allow 32 and 64 installs side by side Message-ID: <1441873383.62.0.21526123437.issue25050@psf.upfronthosting.co.za> New submission from Adam Groszer: Installed with python-3.4.3.msi first, then wanted a 64bit side-by-side )of course in an other folder) Wanted to install python-3.4.3.amd64.msi, the first thing this one did is removed the 32bit install :-( ---------- components: Installation, Windows messages: 250356 nosy: Adam.Groszer, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: windows installer does not allow 32 and 64 installs side by side type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 11:57:02 2015 From: report at bugs.python.org (Piotr) Date: Thu, 10 Sep 2015 09:57:02 +0000 Subject: [issue25051] 'compile' refuses BOM. Message-ID: <1441879022.95.0.331071960409.issue25051@psf.upfronthosting.co.za> New submission from Piotr: Similar to Issue 679880 >>> compile(open("bom3.py").read(), "bom3.py", 'exec') Traceback (most recent call last): File "", line 1, in File "bom3.py", line 1 ???# coding: utf-8 ^ SyntaxError: invalid character in identifier ---------- components: Unicode files: bom3.py messages: 250357 nosy: Karulis, ezio.melotti, haypo priority: normal severity: normal status: open title: 'compile' refuses BOM. type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file40423/bom3.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 12:04:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Sep 2015 10:04:48 +0000 Subject: [issue25051] 'compile' refuses BOM. In-Reply-To: <1441879022.95.0.331071960409.issue25051@psf.upfronthosting.co.za> Message-ID: <1441879488.57.0.978669920054.issue25051@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: open() uses locale encoding by default. You should specify correct encoding explicitly for portability and unambiguity. >>> compile(open("bom3.py", encoding="utf-8-sig").read(), "bom3.py", 'exec') at 0xb707a7a0, file "bom3.py", line 2> ---------- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 12:06:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Sep 2015 10:06:08 +0000 Subject: [issue25051] 'compile' refuses BOM. In-Reply-To: <1441879022.95.0.331071960409.issue25051@psf.upfronthosting.co.za> Message-ID: <1441879568.47.0.205685258484.issue25051@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: open() uses locale encoding by default. You should specify correct encoding explicitly for portability and unambiguity. >>> compile(open("bom3.py", encoding="utf-8-sig").read(), "bom3.py", 'exec') at 0xb707a7a0, file "bom3.py", line 2> ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 12:08:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Sep 2015 10:08:04 +0000 Subject: [issue25051] 'compile' refuses BOM. In-Reply-To: <1441879022.95.0.331071960409.issue25051@psf.upfronthosting.co.za> Message-ID: <1441879684.17.0.996184643298.issue25051@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 12:11:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Sep 2015 10:11:53 +0000 Subject: [issue25052] Test Message-ID: <1441879913.16.0.652873375905.issue25052@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Just for testing if I can create a *new* issue. ---------- messages: 250360 nosy: serhiy.storchaka priority: normal severity: normal status: open title: Test _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 13:21:27 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 10 Sep 2015 11:21:27 +0000 Subject: [issue25021] product_setstate() Out-of-bounds Read In-Reply-To: <1441684502.22.0.0994334100718.issue25021@psf.upfronthosting.co.za> Message-ID: <1441884087.27.0.550916105156.issue25021@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> kristjan.jonsson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 13:31:47 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 10 Sep 2015 11:31:47 +0000 Subject: [issue25051] 'compile' refuses BOM. In-Reply-To: <1441879022.95.0.331071960409.issue25051@psf.upfronthosting.co.za> Message-ID: <1441884707.69.0.0210913713771.issue25051@psf.upfronthosting.co.za> STINNER Victor added the comment: Lib/test/test_tokenize.py contains a test for a Python script encoded to UTF-8 and starting with the UTF-8 BOM, Lib/test/tokenize_tests-utf8-coding-cookie-and-utf8-bom-sig.txt. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 13:33:42 2015 From: report at bugs.python.org (Stanislaw Izaak Pitucha) Date: Thu, 10 Sep 2015 11:33:42 +0000 Subject: [issue25053] Possible race condition in Pool Message-ID: <1441884822.26.0.222476862534.issue25053@psf.upfronthosting.co.za> New submission from Stanislaw Izaak Pitucha: This is something that happened once and I cannot reproduce anymore. In an IPython session I've done the following (see session below), which resulted in pool.map raising its internal exceptions in cases where it shouldn't. Then it worked again. (see in/out 29) Running exactly the same lines again did not result in the same behaviour. I tried multiple times in the same session as well as new sessions. Looks like a weird race / corruption. I'm on Ubuntu's '3.4.3 (default, Mar 26 2015, 22:03:40) \n[GCC 4.9.2]'. Running with 2 virtualised cores (vmware). 64-bit system. In [21]: import multiprocessing In [22]: p=multiprocessing.Pool() ... (unrelated, checked p.map? and other helps) In [26]: class A(object): def a(self, i): print("boo", i, multiprocessing.current_process()) ....: In [27]: obj = A() In [28]: p.map(obj.a, [1,2,3,4]) Process ForkPoolWorker-1: Process ForkPoolWorker-2: Traceback (most recent call last): Traceback (most recent call last): File "/usr/lib/python3.4/multiprocessing/process.py", line 254, in _bootstrap self.run() File "/usr/lib/python3.4/multiprocessing/process.py", line 254, in _bootstrap self.run() File "/usr/lib/python3.4/multiprocessing/process.py", line 93, in run self._target(*self._args, **self._kwargs) File "/usr/lib/python3.4/multiprocessing/process.py", line 93, in run self._target(*self._args, **self._kwargs) File "/usr/lib/python3.4/multiprocessing/pool.py", line 108, in worker task = get() File "/usr/lib/python3.4/multiprocessing/pool.py", line 108, in worker task = get() File "/usr/lib/python3.4/multiprocessing/queues.py", line 357, in get return ForkingPickler.loads(res) AttributeError: Can't get attribute 'A' on File "/usr/lib/python3.4/multiprocessing/queues.py", line 357, in get return ForkingPickler.loads(res) AttributeError: Can't get attribute 'A' on boo 3 boo 4 ^CProcess ForkPoolWorker-4: Process ForkPoolWorker-3: Traceback (most recent call last): Traceback (most recent call last): File "/usr/lib/python3.4/multiprocessing/process.py", line 254, in _bootstrap self.run() File "/usr/lib/python3.4/multiprocessing/process.py", line 93, in run self._target(*self._args, **self._kwargs) File "/usr/lib/python3.4/multiprocessing/process.py", line 254, in _bootstrap self.run() File "/usr/lib/python3.4/multiprocessing/process.py", line 93, in run self._target(*self._args, **self._kwargs) File "/usr/lib/python3.4/multiprocessing/pool.py", line 108, in worker task = get() File "/usr/lib/python3.4/multiprocessing/pool.py", line 108, in worker task = get() File "/usr/lib/python3.4/multiprocessing/queues.py", line 354, in get with self._rlock: File "/usr/lib/python3.4/multiprocessing/queues.py", line 355, in get res = self._reader.recv_bytes() File "/usr/lib/python3.4/multiprocessing/synchronize.py", line 96, in __enter__ return self._semlock.__enter__() KeyboardInterrupt File "/usr/lib/python3.4/multiprocessing/connection.py", line 216, in recv_bytes buf = self._recv_bytes(maxlength) File "/usr/lib/python3.4/multiprocessing/connection.py", line 416, in _recv_bytes buf = self._recv(4) File "/usr/lib/python3.4/multiprocessing/connection.py", line 383, in _recv chunk = read(handle, remaining) KeyboardInterrupt --------------------------------------------------------------------------- KeyboardInterrupt Traceback (most recent call last) in () ----> 1 p.map(obj.a, [1,2,3,4]) /usr/lib/python3.4/multiprocessing/pool.py in map(self, func, iterable, chunksize) 258 in a list that is returned. 259 ''' --> 260 return self._map_async(func, iterable, mapstar, chunksize).get() 261 262 def starmap(self, func, iterable, chunksize=None): /usr/lib/python3.4/multiprocessing/pool.py in get(self, timeout) 591 592 def get(self, timeout=None): --> 593 self.wait(timeout) 594 if not self.ready(): 595 raise TimeoutError /usr/lib/python3.4/multiprocessing/pool.py in wait(self, timeout) 588 589 def wait(self, timeout=None): --> 590 self._event.wait(timeout) 591 592 def get(self, timeout=None): /usr/lib/python3.4/threading.py in wait(self, timeout) 551 signaled = self._flag 552 if not signaled: --> 553 signaled = self._cond.wait(timeout) 554 return signaled 555 finally: /usr/lib/python3.4/threading.py in wait(self, timeout) 288 try: # restore state no matter what (e.g., KeyboardInterrupt) 289 if timeout is None: --> 290 waiter.acquire() 291 gotit = True 292 else: KeyboardInterrupt: In [29]: p.map(obj.a, [1,2,3,4]) boo 1 boo 2 boo 3 boo 4 Out[29]: [None, None, None, None] ---------- components: Library (Lib) messages: 250362 nosy: Stanislaw Izaak Pitucha priority: normal severity: normal status: open title: Possible race condition in Pool type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 14:04:51 2015 From: report at bugs.python.org (Piotr) Date: Thu, 10 Sep 2015 12:04:51 +0000 Subject: [issue25051] 'compile' refuses BOM. In-Reply-To: <1441879022.95.0.331071960409.issue25051@psf.upfronthosting.co.za> Message-ID: <1441886691.92.0.425184105066.issue25051@psf.upfronthosting.co.za> Piotr added the comment: Ok I have tried it(I had to remove ????? from *.txt - my cp is 1250): c:\tmp>type test.py compile(open("tokenize_tests-utf8-coding-cookie-and-utf8-bom-sig.txt").read(), "bom3.py", 'exec') c:\tmp>c:\Python34\python.exe test.py Traceback (most recent call last): File "test.py", line 1, in compile(open("tokenize_tests-utf8-coding-cookie-and-utf8-bom-sig.txt").read(), "bom3.py", 'exec') File "bom3.py", line 1 ???# -*- coding: utf-8 -*- ^ SyntaxError: invalid character in identifier Is it something in my setup? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 14:19:56 2015 From: report at bugs.python.org (Alcolo Alcolo) Date: Thu, 10 Sep 2015 12:19:56 +0000 Subject: [issue25054] Capturing start of line '^' Message-ID: <1441887596.73.0.766811958538.issue25054@psf.upfronthosting.co.za> New submission from Alcolo Alcolo: Why re.findall('^|a', 'a') != ['', 'a'] ? We have: re.findall('^|a', ' a') == ['', 'a'] and re.findall('$|a', ' a') == ['a', ''] Capturing '^' take the 1st character. It's look like a bug ... ---------- components: Regular Expressions messages: 250364 nosy: Alcolo Alcolo, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: Capturing start of line '^' type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 14:20:30 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 10 Sep 2015 12:20:30 +0000 Subject: [issue15012] test issue In-Reply-To: <1338954222.11.0.497891813063.issue15012@psf.upfronthosting.co.za> Message-ID: <1441887630.7.0.702121473155.issue15012@psf.upfronthosting.co.za> R. David Murray added the comment: Test issue update. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 14:27:44 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 10 Sep 2015 12:27:44 +0000 Subject: [issue25054] Capturing start of line '^' In-Reply-To: <1441887596.73.0.766811958538.issue25054@psf.upfronthosting.co.za> Message-ID: <1441888064.35.0.981651201246.issue25054@psf.upfronthosting.co.za> R. David Murray added the comment: ^ finds an empty match at the beginning of the string, $ finds an empty match at the end. I don't see the bug (but I'm not a regex expert). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 14:39:01 2015 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Thu, 10 Sep 2015 12:39:01 +0000 Subject: [issue25021] product_setstate() Out-of-bounds Read In-Reply-To: <1441684502.22.0.0994334100718.issue25021@psf.upfronthosting.co.za> Message-ID: <1441888741.52.0.245344459256.issue25021@psf.upfronthosting.co.za> Kristj?n Valur J?nsson added the comment: Thanks, I'll get this committed and merged asap. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 15:02:37 2015 From: report at bugs.python.org (Tim Tisdall) Date: Thu, 10 Sep 2015 13:02:37 +0000 Subject: [issue25043] document socket constants for Bluetooth In-Reply-To: <1441810839.86.0.110626914047.issue25043@psf.upfronthosting.co.za> Message-ID: <1441890157.31.0.806017964161.issue25043@psf.upfronthosting.co.za> Tim Tisdall added the comment: I'm not sure how to unit test a constant... it's just a string. If you're asking for a unit test for when you'd actually make use of the constant, I haven't been able to figure out that situation yet. It seems like in Bluez 4.101 it's used to issue a command to all interfaces (but in contexts I don't quite understand), but in Bluez 5.XX there's no example or documentation of its use (it remains as a constant, though). [looking through the Bluez git, I found where the constant was added in 2004 and the log message is simply "Add BDADDR_ALL constant"; http://git.kernel.org/cgit/bluetooth/bluez.git/commit/?id=c7b26f3e5d03e1d54dfb945e5ca0c041da524348 ] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 15:09:54 2015 From: report at bugs.python.org (Tim Tisdall) Date: Thu, 10 Sep 2015 13:09:54 +0000 Subject: [issue25043] document socket constants for Bluetooth In-Reply-To: <1441810839.86.0.110626914047.issue25043@psf.upfronthosting.co.za> Message-ID: <1441890594.02.0.661321009594.issue25043@psf.upfronthosting.co.za> Changes by Tim Tisdall : ---------- keywords: +patch Added file: http://bugs.python.org/file40424/bdaddr_36_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 15:10:04 2015 From: report at bugs.python.org (Tim Tisdall) Date: Thu, 10 Sep 2015 13:10:04 +0000 Subject: [issue25043] document socket constants for Bluetooth In-Reply-To: <1441810839.86.0.110626914047.issue25043@psf.upfronthosting.co.za> Message-ID: <1441890604.63.0.486052830628.issue25043@psf.upfronthosting.co.za> Changes by Tim Tisdall : Added file: http://bugs.python.org/file40425/bdaddr_34_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 15:11:15 2015 From: report at bugs.python.org (Tim Tisdall) Date: Thu, 10 Sep 2015 13:11:15 +0000 Subject: [issue25043] document socket constants for Bluetooth In-Reply-To: <1441810839.86.0.110626914047.issue25043@psf.upfronthosting.co.za> Message-ID: <1441890675.87.0.618407060096.issue25043@psf.upfronthosting.co.za> Changes by Tim Tisdall : Added file: http://bugs.python.org/file40426/bdaddr_35_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 15:14:14 2015 From: report at bugs.python.org (Tim Tisdall) Date: Thu, 10 Sep 2015 13:14:14 +0000 Subject: [issue24984] document AF_BLUETOOTH socket address formats In-Reply-To: <1441210010.76.0.198064903239.issue24984@psf.upfronthosting.co.za> Message-ID: <1441890854.06.0.374870743494.issue24984@psf.upfronthosting.co.za> Tim Tisdall added the comment: oops. yeah, I got my terminology wrong. It accepts only a byte-string. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 15:34:55 2015 From: report at bugs.python.org (Matthew Barnett) Date: Thu, 10 Sep 2015 13:34:55 +0000 Subject: [issue25054] Capturing start of line '^' In-Reply-To: <1441887596.73.0.766811958538.issue25054@psf.upfronthosting.co.za> Message-ID: <1441892095.14.0.748261677353.issue25054@psf.upfronthosting.co.za> Matthew Barnett added the comment: After matching '^', it advances so that it won't find the same match again (and again and again...). Unfortunately, that means that it sometimes misses some matches. It's a known issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 15:35:36 2015 From: report at bugs.python.org (eryksun) Date: Thu, 10 Sep 2015 13:35:36 +0000 Subject: [issue25051] 'compile' refuses BOM. In-Reply-To: <1441879022.95.0.331071960409.issue25051@psf.upfronthosting.co.za> Message-ID: <1441892136.11.0.510819429378.issue25051@psf.upfronthosting.co.za> eryksun added the comment: You're passing an already decoded string, so the BOM is treated as text. Instead open the file in binary mode, i.e. open("bom3.py", "rb"). This way the BOM will be detected when decoding the source bytes. Here's an example that passes the source as a bytes object: >>> source = b'\xef\xbb\xbf#coding: utf-8\nprint("spam")' >>> code = compile(source, '', 'exec') >>> exec(code) spam Or you could also decode the file contents without the BOM via open("bom3.py", encoding="utf-8-sig"). ---------- nosy: +eryksun resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 15:36:08 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 10 Sep 2015 13:36:08 +0000 Subject: [issue24272] PEP 484 docs In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za> Message-ID: <1441892168.72.0.380027619327.issue24272@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 15:36:29 2015 From: report at bugs.python.org (Tim Tisdall) Date: Thu, 10 Sep 2015 13:36:29 +0000 Subject: [issue25044] bring BTPROTO_SCO inline with other Bluetooth protocols In-Reply-To: <1441812442.49.0.0898907161184.issue25044@psf.upfronthosting.co.za> Message-ID: <1441892189.54.0.0968627039749.issue25044@psf.upfronthosting.co.za> Tim Tisdall added the comment: Yes, then any existing implementations will continue to work. One sticky issue with all of this... there's no existing tests as per #7687 . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 15:37:25 2015 From: report at bugs.python.org (Tim Tisdall) Date: Thu, 10 Sep 2015 13:37:25 +0000 Subject: [issue7687] Bluetooth support untested In-Reply-To: <1263367703.76.0.187821272753.issue7687@psf.upfronthosting.co.za> Message-ID: <1441892245.17.0.635184313654.issue7687@psf.upfronthosting.co.za> Changes by Tim Tisdall : ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 15:45:28 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 10 Sep 2015 13:45:28 +0000 Subject: [issue23270] Use the new __builtin_mul_overflow() of Clang and GCC 5 to check for integer overflow In-Reply-To: <1421661010.06.0.656712864154.issue23270@psf.upfronthosting.co.za> Message-ID: <1441892728.76.0.772031492142.issue23270@psf.upfronthosting.co.za> STINNER Victor added the comment: Implementation for any compiler using the new builtin if available: http://thread.gmane.org/gmane.linux.kernel/2000004 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 15:45:35 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 10 Sep 2015 13:45:35 +0000 Subject: [issue23270] Use the new __builtin_mul_overflow() of Clang and GCC 5 to check for integer overflow In-Reply-To: <1421661010.06.0.656712864154.issue23270@psf.upfronthosting.co.za> Message-ID: <1441892735.96.0.0903333590826.issue23270@psf.upfronthosting.co.za> STINNER Victor added the comment: Implementation for any compiler using the new builtin if available: http://thread.gmane.org/gmane.linux.kernel/2000004 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 15:48:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Sep 2015 13:48:34 +0000 Subject: [issue25055] Test Message-ID: <1441892914.52.0.893228162112.issue25055@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Just test if the tracker works for me now. ---------- messages: 250375 nosy: serhiy.storchaka priority: normal severity: normal status: open title: Test _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 15:51:57 2015 From: report at bugs.python.org (Tim Tisdall) Date: Thu, 10 Sep 2015 13:51:57 +0000 Subject: [issue25056] no support for Bluetooth LE in socket Message-ID: <1441893116.99.0.907046270099.issue25056@psf.upfronthosting.co.za> New submission from Tim Tisdall: When Bluetooth LE support was added to Bluez they expanded sockaddr_l2 (the struct for making L2CAP connections) to include a l2_bdaddr_type. Since the existing code initializes the struct with 0's the type is set to regular Bluetooth (BDADDR_BREDR). An additional optional argument is needed to allow it to also be set to BDADDR_LE_PUBLIC or BDADDR_LE_RANDOM which indicate it's a LE connection to be made. ---------- components: Library (Lib) messages: 250376 nosy: Tim.Tisdall priority: normal severity: normal status: open title: no support for Bluetooth LE in socket type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 15:54:34 2015 From: report at bugs.python.org (Adam) Date: Thu, 10 Sep 2015 13:54:34 +0000 Subject: [issue25041] document AF_PACKET socket address format In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za> Message-ID: <1441893274.89.0.87594364475.issue25041@psf.upfronthosting.co.za> Changes by Adam : ---------- nosy: +azsorkin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 16:02:01 2015 From: report at bugs.python.org (Alcolo Alcolo) Date: Thu, 10 Sep 2015 14:02:01 +0000 Subject: [issue25054] Capturing start of line '^' In-Reply-To: <1441887596.73.0.766811958538.issue25054@psf.upfronthosting.co.za> Message-ID: <1441893721.42.0.692609182104.issue25054@psf.upfronthosting.co.za> Alcolo Alcolo added the comment: Naively, I thinked that ^ is be considered as a 0-length token (like $, \b, \B), then after capturing it, we can read the next token : 'a' (for the input string "a"). I use a simple work around: prepending my string with ' ' (because ' ' is neutral with my regex results). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 16:03:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Sep 2015 14:03:33 +0000 Subject: [issue15012] test issue In-Reply-To: <1338954222.11.0.497891813063.issue15012@psf.upfronthosting.co.za> Message-ID: <1441893813.12.0.797115472061.issue15012@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Test. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 16:04:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Sep 2015 14:04:38 +0000 Subject: [issue15012] test issue In-Reply-To: <1338954222.11.0.497891813063.issue15012@psf.upfronthosting.co.za> Message-ID: <1441893878.48.0.78543625893.issue15012@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 16:04:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Sep 2015 14:04:53 +0000 Subject: [issue15012] test issue In-Reply-To: <1338954222.11.0.497891813063.issue15012@psf.upfronthosting.co.za> Message-ID: <1441893893.8.0.751410387773.issue15012@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 16:07:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Sep 2015 14:07:29 +0000 Subject: [issue15012] test issue In-Reply-To: <1338954222.11.0.497891813063.issue15012@psf.upfronthosting.co.za> Message-ID: <1441894049.51.0.407339574588.issue15012@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Test again. ---------- nosy: +serhiy.storchaka status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 16:10:56 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 10 Sep 2015 14:10:56 +0000 Subject: [issue15012] test issue In-Reply-To: <1338954222.11.0.497891813063.issue15012@psf.upfronthosting.co.za> Message-ID: <1441894256.03.0.0662591312252.issue15012@psf.upfronthosting.co.za> STINNER Victor added the comment: victor test ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 16:13:27 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Sep 2015 14:13:27 +0000 Subject: [issue15012] test issue In-Reply-To: <1338954222.11.0.497891813063.issue15012@psf.upfronthosting.co.za> Message-ID: <1441894407.7.0.0207671058583.issue15012@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Test. ---------- nosy: +serhiy.storchaka status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 16:31:56 2015 From: report at bugs.python.org (shiyao.ma) Date: Thu, 10 Sep 2015 14:31:56 +0000 Subject: [issue25057] Make parameter of io.base to be positional and keyword Message-ID: <1441895516.87.0.702583727095.issue25057@psf.upfronthosting.co.za> New submission from shiyao.ma: The parameters for io.[Text]IOBase.seek are currently positional only, as discussed in http://bugs.python.org/issue25030. We make the parameters to be both positional and keyword based. ---------- files: patch.diff keywords: patch messages: 250382 nosy: berker.peksag, ezio.melotti, introom priority: normal severity: normal status: open title: Make parameter of io.base to be positional and keyword type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file40427/patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 17:06:41 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 10 Sep 2015 15:06:41 +0000 Subject: [issue25050] windows installer does not allow 32 and 64 installs side by side In-Reply-To: <1441873383.62.0.21526123437.issue25050@psf.upfronthosting.co.za> Message-ID: <1441897601.05.0.733793710044.issue25050@psf.upfronthosting.co.za> Steve Dower added the comment: This is an issue with 3.4.3 only, and I suspect it was something funny in the build config that should just work with 3.4.4 - adding Martin to make sure. Basically, the upgrade code in the 32-bit installer was (I think) the code used for dev snapshots. Both installers are supposed to remove dev snapshots, so the 64-bit installer will remove it. If you install the 64-bit version first then you can have both. ---------- nosy: +loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 17:07:32 2015 From: report at bugs.python.org (David Fraser) Date: Thu, 10 Sep 2015 15:07:32 +0000 Subject: [issue21657] pip.get_installed_distributions() Does not return packages in the current working directory In-Reply-To: <1401867835.25.0.432205285247.issue21657@psf.upfronthosting.co.za> Message-ID: <1441897652.94.0.96959010111.issue21657@psf.upfronthosting.co.za> David Fraser added the comment: Filed with pypa at https://github.com/pypa/pip/issues/3091 ---------- nosy: +davidfraser _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 18:03:40 2015 From: report at bugs.python.org (Benedikt Reinartz) Date: Thu, 10 Sep 2015 16:03:40 +0000 Subject: [issue24900] Raising an exception that cannot be unpickled causes hang in ProcessPoolExecutor In-Reply-To: <1440055310.02.0.542767582293.issue24900@psf.upfronthosting.co.za> Message-ID: <1441901020.79.0.125722012759.issue24900@psf.upfronthosting.co.za> Benedikt Reinartz added the comment: That would touch 2, but as this is happening in the exception handling already that would need to be catched and handled by itself. However, one could then do without a "pickle -> unpickle" dance. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 18:04:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Sep 2015 16:04:24 +0000 Subject: [issue25024] Allow passing "delete=False" to TemporaryDirectory In-Reply-To: <1441690580.39.0.270846340544.issue25024@psf.upfronthosting.co.za> Message-ID: <1441901064.46.0.288839151116.issue25024@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm inclined to reject this idea too. ---------- nosy: +georg.brandl, ncoghlan, pitrou, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 18:13:54 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 Sep 2015 16:13:54 +0000 Subject: [issue25024] Allow passing "delete=False" to TemporaryDirectory In-Reply-To: <1441690580.39.0.270846340544.issue25024@psf.upfronthosting.co.za> Message-ID: <1441901634.04.0.152037069614.issue25024@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The idea looks ok to me, but you'd have to provide a patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 18:30:03 2015 From: report at bugs.python.org (Juan Jimenez-Anca) Date: Thu, 10 Sep 2015 16:30:03 +0000 Subject: [issue25058] Right square bracket argparse metavar Message-ID: <1441902603.18.0.552996969637.issue25058@psf.upfronthosting.co.za> New submission from Juan Jimenez-Anca: When trying to assign the metavar in add_argument() method of argparse module I'm unable to include characters after a right square bracket. Trying to set something like this: metavar="[host:database:collection:]field" would raise an AssertionError, which includes: File "/usr/lib64/python3.4/argparse.py", line 329, in _format_usage assert ' '.join(opt_parts) == opt_usage However, the following is accepted: metavar="[host:database:collection:]field" ---------- components: Library (Lib) messages: 250388 nosy: cortopy priority: normal severity: normal status: open title: Right square bracket argparse metavar type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 18:32:01 2015 From: report at bugs.python.org (Juan Jimenez-Anca) Date: Thu, 10 Sep 2015 16:32:01 +0000 Subject: [issue25058] Right square bracket argparse metavar In-Reply-To: <1441902603.18.0.552996969637.issue25058@psf.upfronthosting.co.za> Message-ID: <1441902721.49.0.220159496647.issue25058@psf.upfronthosting.co.za> Juan Jimenez-Anca added the comment: My apologies for the formatting of the last line. This is my issue corrected: When trying to assign the metavar in add_argument() method of argparse module I'm unable to include characters after a right square bracket. Trying to set something like this: metavar="[host:database:collection:]field" would raise an AssertionError, which includes: File "/usr/lib64/python3.4/argparse.py", line 329, in _format_usage assert ' '.join(opt_parts) == opt_usage However, the following is accepted: metavar="[host:database:collection:] field" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 18:45:21 2015 From: report at bugs.python.org (Saimadhav Heblikar) Date: Thu, 10 Sep 2015 16:45:21 +0000 Subject: [issue25059] Mistake in input-output tutorial regarding print() seperator Message-ID: <1441903521.59.0.166588959306.issue25059@psf.upfronthosting.co.za> New submission from Saimadhav Heblikar: Feel free to make changes to the patch if you want to improve the sentence structure. ---------- assignee: docs at python components: Documentation messages: 250390 nosy: docs at python, sahutd priority: normal severity: normal status: open title: Mistake in input-output tutorial regarding print() seperator versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 18:46:03 2015 From: report at bugs.python.org (Saimadhav Heblikar) Date: Thu, 10 Sep 2015 16:46:03 +0000 Subject: [issue25059] Mistake in input-output tutorial regarding print() seperator In-Reply-To: <1441903521.59.0.166588959306.issue25059@psf.upfronthosting.co.za> Message-ID: <1441903563.19.0.0926836088619.issue25059@psf.upfronthosting.co.za> Changes by Saimadhav Heblikar : Added file: http://bugs.python.org/file40428/issue25059 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 19:01:36 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 10 Sep 2015 17:01:36 +0000 Subject: [issue25060] BUILD_MAP stack effect suboptimal Message-ID: <1441904496.93.0.249532808894.issue25060@psf.upfronthosting.co.za> New submission from Antoine Pitrou: In PyCompile_OpcodeStackEffect() compile.c: case BUILD_MAP: return 1; But starting from 3.5, BUILD_MAP pops 2*oparg objects from the stack. ---------- components: Interpreter Core messages: 250391 nosy: benjamin.peterson, georg.brandl, pitrou priority: normal severity: normal status: open title: BUILD_MAP stack effect suboptimal type: resource usage versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 19:09:35 2015 From: report at bugs.python.org (Matthew Barnett) Date: Thu, 10 Sep 2015 17:09:35 +0000 Subject: [issue25054] Capturing start of line '^' In-Reply-To: <1441887596.73.0.766811958538.issue25054@psf.upfronthosting.co.za> Message-ID: <1441904975.84.0.42821864439.issue25054@psf.upfronthosting.co.za> Matthew Barnett added the comment: Just to confirm, it _is_ a bug. It tries to avoid getting stuck, but the way it does that causes it to skip a character, sometimes missing a match it should have found. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 19:09:55 2015 From: report at bugs.python.org (Davin Potts) Date: Thu, 10 Sep 2015 17:09:55 +0000 Subject: [issue25053] Possible race condition in Pool In-Reply-To: <1441884822.26.0.222476862534.issue25053@psf.upfronthosting.co.za> Message-ID: <1441904995.2.0.32043483109.issue25053@psf.upfronthosting.co.za> Davin Potts added the comment: I have been able to reproduce the behavior you described under 3.5 under one set of circumstances so far. When attempting to use classes/functions/other not defined in an importable module, an AttributeError is expected as you observed. The viability of that existing Pool to perform further useful work has been compromised and no promises are made regarding its continued behavior. In general, the recommendations in https://docs.python.org/3.4/library/multiprocessing.html#multiprocessing-programming hold to avoid these situations. Understanding the exact set of circumstances to provoke situations where viable work can continue with a locally-defined (not in an importable module) function/class is perhaps worth further investigation. That said, multiple places in the multiprocessing docs (including the introductory paragraphs) provide the guidance to always use functions/classes whose definitions are importable. Hence, I'm inclined to mark this mentally as "interesting" but on the bug tracker as "not a bug". Any objections? ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 19:11:14 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 10 Sep 2015 17:11:14 +0000 Subject: [issue25059] Mistake in input-output tutorial regarding print() seperator In-Reply-To: <1441903521.59.0.166588959306.issue25059@psf.upfronthosting.co.za> Message-ID: <1441905074.19.0.108972211082.issue25059@psf.upfronthosting.co.za> R. David Murray added the comment: Well, it's a tutorial. I'm not sure it makes sense to introduce sep at that point, that's more appropriate for when the user is more advanced and looking at the reference documentation. (Frankly, I've *never* used that feature, and I've been using python for longer than it has had that feature :) I could see changing 'always' to 'by default' and leaving it at that, though. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 19:17:50 2015 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 10 Sep 2015 17:17:50 +0000 Subject: [issue25059] Mistake in input-output tutorial regarding print() seperator In-Reply-To: <1441903521.59.0.166588959306.issue25059@psf.upfronthosting.co.za> Message-ID: <1441905470.27.0.410241243157.issue25059@psf.upfronthosting.co.za> Eric V. Smith added the comment: +1 on the "by default" change. ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 19:20:03 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 10 Sep 2015 17:20:03 +0000 Subject: [issue24272] PEP 484 docs In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za> Message-ID: <1441905603.4.0.932657817929.issue24272@psf.upfronthosting.co.za> Berker Peksag added the comment: By the way, for some reason the changes in revision e361130782d4 are not in Doc/library/typing.rst. For example, io documentation on current default branch: https://hg.python.org/cpython/file/default/Doc/library/typing.rst#l376 io documentation on current 3.5 branch: https://hg.python.org/cpython/file/3.5/Doc/library/typing.rst#l376 Updates to the io documntation in revision e361130782d4: https://hg.python.org/cpython/rev/e361130782d4#l1.67 Also, my clone is up-to-date: changeset: 97855:d433d74e0377 tag: tip user: Victor Stinner date: Thu Sep 10 16:00:06 2015 +0200 files: Python/pytime.c description: pytime: oops, fix typos on Windows ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 19:20:06 2015 From: report at bugs.python.org (Saimadhav Heblikar) Date: Thu, 10 Sep 2015 17:20:06 +0000 Subject: [issue25059] Mistake in input-output tutorial regarding print() seperator In-Reply-To: <1441903521.59.0.166588959306.issue25059@psf.upfronthosting.co.za> Message-ID: <1441905606.1.0.265464796485.issue25059@psf.upfronthosting.co.za> Saimadhav Heblikar added the comment: Agreed with both David Murray and Eric. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 19:56:18 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 10 Sep 2015 17:56:18 +0000 Subject: [issue24272] PEP 484 docs In-Reply-To: <1441905603.4.0.932657817929.issue24272@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: I suck at merge. :-( No idea what happened. To fix it, I have now just copied the file again from the larry branch and committed that in 3.5, then merged up to 3.6 (default). changeset: 97856:8a7814a3613b branch: 3.5 parent: 97847:6c8e2c6e3a99 user: Guido van Rossum date: Thu Sep 10 10:52:11 2015 -0700 summary: Restore doc updates to typing.rst by Ivan Levkivskyi and Daniel Andrade Groppe. changeset: 97857:7fc4306d537b tag: tip parent: 97855:d433d74e0377 parent: 97856:8a7814a3613b user: Guido van Rossum date: Thu Sep 10 10:54:10 2015 -0700 summary: Restore doc updates to typing.rst by Ivan Levkivskyi and Daniel Andrade Groppe. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 20:04:05 2015 From: report at bugs.python.org (desbma) Date: Thu, 10 Sep 2015 18:04:05 +0000 Subject: [issue25061] Add native enum support for argparse Message-ID: <1441908245.42.0.23532628335.issue25061@psf.upfronthosting.co.za> New submission from desbma: I often find myself using the following pattern with argparse: import argparse import enum CustomEnumType = enum.Enum("CustomEnumType", ("VAL1", "VAL2", "VAL3", ...)) arg_parser = argparse.ArgumentParser(...) ... arg_parser.add_argument("-p", "--param", type="string", action="store", choices=tuple(t.name.lower() for t in CustomEnumType), default=CustomEnumType.VAL1.name.lower(), dest="param" ...) args = arg_parser.parse_args() args.param = CustomEnumType[args.param.upper()] I think it would be a great addition to be able to pass the enum type to the add_argument 'type' parameter directly, and have it validate the input and store the resulting enum. ---------- messages: 250399 nosy: desbma priority: normal severity: normal status: open title: Add native enum support for argparse type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 20:15:02 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 10 Sep 2015 18:15:02 +0000 Subject: [issue25061] Add native enum support for argparse In-Reply-To: <1441908245.42.0.23532628335.issue25061@psf.upfronthosting.co.za> Message-ID: <1441908902.99.0.857902337292.issue25061@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 20:27:11 2015 From: report at bugs.python.org (desbma) Date: Thu, 10 Sep 2015 18:27:11 +0000 Subject: [issue3548] subprocess.pipe function In-Reply-To: <1218561839.36.0.810217326739.issue3548@psf.upfronthosting.co.za> Message-ID: <1441909631.44.0.39043206017.issue3548@psf.upfronthosting.co.za> Changes by desbma : ---------- nosy: +desbma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 20:33:32 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 10 Sep 2015 18:33:32 +0000 Subject: [issue25062] Doc linter error: [2] library/typing.rst:358: default role used Message-ID: <1441910012.45.0.819788505611.issue25062@psf.upfronthosting.co.za> New submission from STINNER Victor: The Docs buildbot is red since the changeset 7fc4306d537b5feedb7f9dac54d96ed378c093a7. http://buildbot.python.org/all/builders/Docs%203.x/builds/52 ---------- assignee: docs at python components: Documentation messages: 250400 nosy: docs at python, gvanrossum, haypo priority: normal severity: normal status: open title: Doc linter error: [2] library/typing.rst:358: default role used versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 20:38:12 2015 From: report at bugs.python.org (desbma) Date: Thu, 10 Sep 2015 18:38:12 +0000 Subject: [issue25061] Add native enum support for argparse In-Reply-To: <1441908245.42.0.23532628335.issue25061@psf.upfronthosting.co.za> Message-ID: <1441910292.54.0.728064077665.issue25061@psf.upfronthosting.co.za> Changes by desbma : ---------- components: +Library (Lib) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 20:38:50 2015 From: report at bugs.python.org (desbma) Date: Thu, 10 Sep 2015 18:38:50 +0000 Subject: [issue25063] shutil.copyfileobj should internally use os.sendfile when possible Message-ID: <1441910330.09.0.484556764779.issue25063@psf.upfronthosting.co.za> New submission from desbma: Sorry if it has already been discussed, or if this is a stupid idea. By looking at the signature, my thought was that the only use of shutil.copyfileobj was to wrap the use of sendfile, and use a fallback if it is not available on the system or not usable with "fake" Python files (not having a file descriptor, eg. like gzip.GzipFile). By looking at the implementation, I was surprised that it does not try to call os.sendfile. ---------- components: Library (Lib) messages: 250401 nosy: desbma priority: normal severity: normal status: open title: shutil.copyfileobj should internally use os.sendfile when possible _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 20:49:19 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 10 Sep 2015 18:49:19 +0000 Subject: [issue1103213] Adding a recvexactly() to socket.socket: receive exactly n bytes Message-ID: <1441910959.95.0.106116120878.issue1103213@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, in fact recvall() is a bad name. The io module uses the "readall()" name to really read all content of a file, whereas "recvall(N)" here only read up to N bytes. It would be better to reuse the same name than asyncio, "readexactly(N)": https://docs.python.org/dev/library/asyncio-stream.html#asyncio.StreamReader.readexactly asyncio and http.client already have their IncompleteRead exceptions. Maybe it would be time to add a builtin exception? ---------- title: Adding the missing socket.recvall() method -> Adding a recvexactly() to socket.socket: receive exactly n bytes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 20:59:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 10 Sep 2015 18:59:04 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1441911544.24.0.850963251671.issue25003@psf.upfronthosting.co.za> STINNER Victor added the comment: > Yes, the syscall was failing with EINVAL. Sorry, I don't understand. Do you mean that calling a non-existant syscall on Solaris fails with EINVAL? Calling the getrandom() syscall on Solaris < 11.3 fails with EINVAL? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 20:59:15 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 10 Sep 2015 18:59:15 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) on Solaris In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1441911555.19.0.344293011344.issue25003@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: os.urandom() should call getrandom(2) not getentropy(2) -> os.urandom() should call getrandom(2) not getentropy(2) on Solaris _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 20:59:21 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 10 Sep 2015 18:59:21 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) on Solaris 11.3 and newer In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1441911561.57.0.554014929605.issue25003@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: os.urandom() should call getrandom(2) not getentropy(2) on Solaris -> os.urandom() should call getrandom(2) not getentropy(2) on Solaris 11.3 and newer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 21:01:35 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 10 Sep 2015 19:01:35 +0000 Subject: [issue25029] MemoryError in test_strptime In-Reply-To: <1441708213.63.0.825636103813.issue25029@psf.upfronthosting.co.za> Message-ID: <1441911695.4.0.763199315277.issue25029@psf.upfronthosting.co.za> STINNER Victor added the comment: The test doesn't fail anymore on buildbots. I ran manually test_strptime with a memory limit of 1 GB on Python 3.5 and 3.6: the test pass. Can we close the issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 21:03:23 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 10 Sep 2015 19:03:23 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441911803.52.0.771528014147.issue23517@psf.upfronthosting.co.za> STINNER Victor added the comment: Alexander: can you please review attached round_half_even_py34.patch? It's the minimum patch to fix datetime/timedelta rounding for Python 3.4 (and 3.5). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 21:04:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Sep 2015 19:04:58 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1441911898.49.0.411861122449.issue23517@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 21:10:04 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 10 Sep 2015 19:10:04 +0000 Subject: [issue25063] shutil.copyfileobj should internally use os.sendfile when possible In-Reply-To: <1441910330.09.0.484556764779.issue25063@psf.upfronthosting.co.za> Message-ID: <1441912204.18.0.412031551142.issue25063@psf.upfronthosting.co.za> R. David Murray added the comment: No, it's to copy file like objects that aren't necessarily true file system objects. The only requirement is that they support a minimal file-like object interface. There is no suggestion or requirement that the object supports file descriptors (which would make it a real os file object). I think changing it to use os.sendfile if possible would be too risky in terms of causing unexpected breakage (objects that look like they have a file descriptor but really don't), especially since handling file system files is explicitly not the purpose of copyfileobj. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 21:12:42 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 10 Sep 2015 19:12:42 +0000 Subject: [issue24909] Windows: subprocess.Popen: race condition for leaking inheritable handles In-Reply-To: <1440175915.18.0.538138459653.issue24909@psf.upfronthosting.co.za> Message-ID: <1441912362.67.0.455415359281.issue24909@psf.upfronthosting.co.za> STINNER Victor added the comment: > The one potential problem that I see is that it looks like specifying PROC_THREAD_ATTRIBUTE_HANDLE_LIST means that no other handles are inherited, even if they are inheritable. We can maybe add a parameter to configure the behaviour: keep current behaviour by default in Python 3.6 and change the default in Python 3.7 for example. > I could add Windows support for pass_fds, (...) Yes, we need a new "pass_handles" parameter to pass a list of handles which will be explicitly inherited. This parameter is useful even if you inherit all inheritable handles, because handles can be non-inhertable too. It's the same with pass_fds: if you pass a file descriptor in pass_fds, it will be marked as inheritable to be passed to the child. I guess that "pass_handles" will be implemented with PROC_THREAD_ATTRIBUTE_HANDLE_LIST, or by making handles temporary inheritable if PROC_THREAD_ATTRIBUTE_HANDLE_LIST is not available. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 21:16:34 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 10 Sep 2015 19:16:34 +0000 Subject: [issue25062] Doc linter error: [2] library/typing.rst:358: default role used In-Reply-To: <1441910012.45.0.819788505611.issue25062@psf.upfronthosting.co.za> Message-ID: <1441912594.71.0.355699394793.issue25062@psf.upfronthosting.co.za> Guido van Rossum added the comment: That link gives me a timeout right now. How can I run the doc linter manually? "make html" in the Doc tree didn't alert me to this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 21:18:44 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 10 Sep 2015 19:18:44 +0000 Subject: [issue24870] Optimize coding with surrogateescape and surrogatepass error handlers In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za> Message-ID: <1441912724.94.0.609963703125.issue24870@psf.upfronthosting.co.za> STINNER Victor added the comment: I rebased patch because faster-decode-ascii-surrogateescape.patch was generated in git format, and the git format is not accepted by Rietveld (the Review button). ---------- Added file: http://bugs.python.org/file40429/faster-decode-ascii-surrogateescape.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 21:20:15 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 10 Sep 2015 19:20:15 +0000 Subject: [issue24821] The optimization of string search can cause pessimization In-Reply-To: <1438927886.02.0.407236930114.issue24821@psf.upfronthosting.co.za> Message-ID: <1441912815.85.0.81628181091.issue24821@psf.upfronthosting.co.za> STINNER Victor added the comment: > I think we should use more robust optimization. What do you propose? I don't understand the purpose of the issue. Do you want to remove the optimization? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 21:25:01 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 10 Sep 2015 19:25:01 +0000 Subject: [issue25062] Doc linter error: [2] library/typing.rst:358: default role used In-Reply-To: <1441910012.45.0.819788505611.issue25062@psf.upfronthosting.co.za> Message-ID: <1441913101.46.0.515135581893.issue25062@psf.upfronthosting.co.za> Guido van Rossum added the comment: Maybe Zach knows how to fix this since he fixed it for an earlier version? (Sorry Zach!) ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 21:26:39 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 10 Sep 2015 19:26:39 +0000 Subject: [issue25062] Doc linter error: [2] library/typing.rst:358: default role used In-Reply-To: <1441910012.45.0.819788505611.issue25062@psf.upfronthosting.co.za> Message-ID: <1441913199.12.0.854572272551.issue25062@psf.upfronthosting.co.za> Zachary Ware added the comment: Guido van Rossum added the comment: > That link gives me a timeout right now. How can I run the doc linter manually? "make html" in the Doc tree didn't alert me to this issue. "make check" is the doc linter. I've considered whether to back that buildbot off to only warn on 'lint' or 'suspicious' failure, but warnings aren't reported by the IRC notifier. Anyone else have an opinion on that? I'll try to get this fixed soonish, but if anyone can beat me to it, feel free :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 21:31:58 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 10 Sep 2015 19:31:58 +0000 Subject: [issue25062] Doc linter error: [2] library/typing.rst:358: default role used In-Reply-To: <1441910012.45.0.819788505611.issue25062@psf.upfronthosting.co.za> Message-ID: <1441913518.36.0.988665835237.issue25062@psf.upfronthosting.co.za> Zachary Ware added the comment: Oh right, Berker already beat me to it: changeset 97861:72e696bc480a 3.5 Fix typos and improve markup in typing.rst. author Berker Peksag date Thu, 10 Sep 2015 21:55:50 +0300 (35 minutes ago) parents a380841644b2 children c52194da1ae2 47e9d7ddb06a files Doc/library/typing.rst diffstat 1 files changed, 18 insertions(+), 19 deletions(-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 21:32:58 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 10 Sep 2015 19:32:58 +0000 Subject: [issue25062] Doc linter error: [2] library/typing.rst:358: default role used In-Reply-To: <1441910012.45.0.819788505611.issue25062@psf.upfronthosting.co.za> Message-ID: <1441913578.51.0.298930728775.issue25062@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 21:33:51 2015 From: report at bugs.python.org (Davin Potts) Date: Thu, 10 Sep 2015 19:33:51 +0000 Subject: [issue25053] Possible race condition in Pool In-Reply-To: <1441884822.26.0.222476862534.issue25053@psf.upfronthosting.co.za> Message-ID: <1441913631.65.0.33121834853.issue25053@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- status: open -> pending versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 21:37:04 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 10 Sep 2015 19:37:04 +0000 Subject: [issue25062] Doc linter error: [2] library/typing.rst:358: default role used In-Reply-To: <1441910012.45.0.819788505611.issue25062@psf.upfronthosting.co.za> Message-ID: <1441913824.32.0.365105866026.issue25062@psf.upfronthosting.co.za> Guido van Rossum added the comment: Thanks everyone! This episode shows I should not try to commit CPython stuff. Period. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 21:40:25 2015 From: report at bugs.python.org (John Beck) Date: Thu, 10 Sep 2015 19:40:25 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) on Solaris 11.3 and newer In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1441914025.15.0.479700669367.issue25003@psf.upfronthosting.co.za> John Beck added the comment: Sorry, let me try to clarify. ENOSYS is the correct errno value to check for, for the situation (e.g., Solaris < 11.3) of a non-existent system call. But EINVAL should also be checked for to make sure the system call was invoked with proper parameters. My builds of Python 3.5.0.X (don't recall whether X was a late Beta or release candidate) were core dumping because Python was making that syscall but not checking for EINVAL, and thus assuming the call was valid, when it was not. Sorry, I did not try to debug why it was invalid. But once I added EINVAL, alongside ENOSYS, as a reason to set getrandom_works to 0, then python started behaving properly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 22:01:59 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 10 Sep 2015 20:01:59 +0000 Subject: [issue25029] MemoryError in test_strptime In-Reply-To: <1441708213.63.0.825636103813.issue25029@psf.upfronthosting.co.za> Message-ID: <1441915319.66.0.197062980022.issue25029@psf.upfronthosting.co.za> Steve Dower added the comment: Done. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 22:03:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Sep 2015 20:03:49 +0000 Subject: [issue25022] Remove PC/example_nt/ In-Reply-To: <1441687350.45.0.29239152419.issue25022@psf.upfronthosting.co.za> Message-ID: <20150910200346.12019.67628@psf.io> Roundup Robot added the comment: New changeset a30598e59964 by Zachary Ware in branch '2.7': Issue #25022: Remove PC/example_nt/ https://hg.python.org/cpython/rev/a30598e59964 New changeset de3e1c81ecd7 by Zachary Ware in branch '3.4': Issue #25022: Remove PC/example_nt/ https://hg.python.org/cpython/rev/de3e1c81ecd7 New changeset 2460fa584323 by Zachary Ware in branch '3.5': Issue #25022: Merge with 3.4 https://hg.python.org/cpython/rev/2460fa584323 New changeset e1ddec83a311 by Zachary Ware in branch 'default': Closes #25022: Merge with 3.5 https://hg.python.org/cpython/rev/e1ddec83a311 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 22:24:01 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 10 Sep 2015 20:24:01 +0000 Subject: [issue25022] Remove PC/example_nt/ In-Reply-To: <1441687350.45.0.29239152419.issue25022@psf.upfronthosting.co.za> Message-ID: <1441916641.45.0.994907807269.issue25022@psf.upfronthosting.co.za> Zachary Ware added the comment: Erk...just discovered there's a section of Doc/extending/windows.rst that depends on example_nt that will need to be excised. ---------- resolution: fixed -> stage: resolved -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 22:39:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 10 Sep 2015 20:39:39 +0000 Subject: [issue24821] The optimization of string search can cause pessimization In-Reply-To: <1438927886.02.0.407236930114.issue24821@psf.upfronthosting.co.za> Message-ID: <1441917579.81.0.0585247358953.issue24821@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I was going to provide another optimization (I had an idea), but it is not so easy as looked to me at first glance. This issue exists rather as a reminder to me. I should make a second attempt. ---------- resolution: -> remind _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 23:13:05 2015 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 10 Sep 2015 21:13:05 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1441919585.76.0.497513809581.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: This version does dynamic allocation for the expression list, and fixes some memory leaks and early decrefs. I think it's complete, but I'll take some more passes through it checking for leaks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 23:13:34 2015 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 10 Sep 2015 21:13:34 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1441919614.18.0.70544745856.issue24965@psf.upfronthosting.co.za> Changes by Eric V. Smith : Added file: http://bugs.python.org/file40430/pep-498-4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 23:14:47 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Sep 2015 21:14:47 +0000 Subject: [issue25022] Remove PC/example_nt/ In-Reply-To: <1441687350.45.0.29239152419.issue25022@psf.upfronthosting.co.za> Message-ID: <20150910211444.15714.12962@psf.io> Roundup Robot added the comment: New changeset 3456af022541 by Zachary Ware in branch '2.7': Issue #25022: Add NEWS, fix docs to not mention the old example. https://hg.python.org/cpython/rev/3456af022541 New changeset c535bf72aa60 by Zachary Ware in branch '3.4': Issue #25022: Add NEWS, fix docs to not mention the old example. https://hg.python.org/cpython/rev/c535bf72aa60 New changeset 70c97a626c41 by Zachary Ware in branch '3.5': Issue #25022: Merge with 3.4 https://hg.python.org/cpython/rev/70c97a626c41 New changeset 8c436c36a4a7 by Zachary Ware in branch 'default': Closes #25022 (again): Merge with 3.5 https://hg.python.org/cpython/rev/8c436c36a4a7 ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 23:28:46 2015 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 10 Sep 2015 21:28:46 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1441920526.01.0.267806955266.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: The good news is that the performance is pretty good, and finally I have a case where I can beat %-formatting: $ ./python.bat -mtimeit -s 'a=2' "'%s' % a" 1000000 loops, best of 3: 0.883 usec per loop $ ./python.bat -mtimeit -s 'a=2' '"{}".format(a)' 1000000 loops, best of 3: 1.16 usec per loop $ ./python.bat -mtimeit -s 'a=2' 'f"{a}"' 1000000 loops, best of 3: 0.792 usec per loop This example is mildly contrived, and the performance of f-strings is slightly worse than %-formatting once the f-strings contains both expressions and literals. I could speed it up significantly (I think) by adding opcodes for 2 things: calling __format__ and joining the strings together. Calling __format__ in an opcode could be a win because I could optimize for known types (str, int, float). Having a join opcode would be a win because I could use _PyUnicodeWriter instead of ''.join. I'm inclined to check this code in as-is, then optimize it later, if we think it's needed and if I get motivated. For reference, here's the ast and opcodes for f'a={a}': >>> ast.dump(ast.parse("f'a={a}'")) "Module(body=[Expr(value=JoinedStr(values=[Str(s='a='), FormattedValue(value=Name(id='a', ctx=Load()), conversion=0, format_spec=None)]))])" >>> dis.dis("f'a={a}'") 1 0 LOAD_CONST 0 ('') 3 LOAD_ATTR 0 (join) 6 LOAD_CONST 1 ('a=') 9 LOAD_NAME 1 (a) 12 LOAD_ATTR 2 (__format__) 15 LOAD_CONST 0 ('') 18 CALL_FUNCTION 1 (1 positional, 0 keyword pair) 21 BUILD_LIST 2 24 CALL_FUNCTION 1 (1 positional, 0 keyword pair) 27 RETURN_VALUE ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 10 23:55:03 2015 From: report at bugs.python.org (Sworddragon) Date: Thu, 10 Sep 2015 21:55:03 +0000 Subject: [issue25035] Getter/setter for argparse keys In-Reply-To: <1441753315.66.0.921652253193.issue25035@psf.upfronthosting.co.za> Message-ID: <1441922103.15.0.459991157415.issue25035@psf.upfronthosting.co.za> Sworddragon added the comment: In this case probably all is fine then. But there is a minor thing I noticed from one of your previous posts: You said parser.add_argument returns an Action object but I noticed that this is not mentioned on "16.4.3. The add_argument() method". Is it maybe mentioned somewhere else or probably just missing? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 00:27:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 10 Sep 2015 22:27:58 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1417530925.56.0.55888060474.issue22980@psf.upfronthosting.co.za> Message-ID: <20150910222755.15708.57656@psf.io> Roundup Robot added the comment: New changeset 1744d65705d0 by Yury Selivanov in branch '3.5': whatsnew/3.5: Describe changes in issue #22980 https://hg.python.org/cpython/rev/1744d65705d0 New changeset cfbcb3a6a848 by Yury Selivanov in branch 'default': Merge 3.5 (issue #22980, whatsnew/3.5) https://hg.python.org/cpython/rev/cfbcb3a6a848 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 00:30:36 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 10 Sep 2015 22:30:36 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1417530925.56.0.55888060474.issue22980@psf.upfronthosting.co.za> Message-ID: <1441924236.88.0.168137441548.issue22980@psf.upfronthosting.co.za> Yury Selivanov added the comment: Larry, Matthias, Steve, Berker - I've mentioned this issue in the whatsnew (applied Larry's patch with some modifications to address comments from Steve and Matthias). Please review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 00:31:57 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 10 Sep 2015 22:31:57 +0000 Subject: [issue25063] shutil.copyfileobj should internally use os.sendfile when possible In-Reply-To: <1441910330.09.0.484556764779.issue25063@psf.upfronthosting.co.za> Message-ID: <1441924317.95.0.65514198492.issue25063@psf.upfronthosting.co.za> Martin Panter added the comment: I agree it is a nice idea, but have the same concern as David. Many pseudo file objects wrap real file descriptors. E.g. BufferedReader hides unread data in a buffer, GzipFile decompresses data, HTTPResponse decodes chunks. Detecting when sendfile() is appropriate would be hard to do. And I understand some platforms only support sockets. Also I notice that 3.5 has a new socket.sendfile() method (Issue 17552), which partly overlaps with this proposal. BTW the 3.4 os documentation should not mention the socket method, but it does! ---------- nosy: +martin.panter type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 00:38:47 2015 From: report at bugs.python.org (paul j3) Date: Thu, 10 Sep 2015 22:38:47 +0000 Subject: [issue25058] Right square bracket argparse metavar In-Reply-To: <1441902603.18.0.552996969637.issue25058@psf.upfronthosting.co.za> Message-ID: <1441924727.19.0.527692411277.issue25058@psf.upfronthosting.co.za> paul j3 added the comment: This assertion error caused by brackets (and other 'odd' characters) in the metavar is a known issue. http://bugs.python.org/issue11874 http://bugs.python.org/issue14046 The formatter that handles line wrapping of the usage line is fragile. ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 01:18:25 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 10 Sep 2015 23:18:25 +0000 Subject: [issue25057] Make parameter of io.base to be positional and keyword In-Reply-To: <1441895516.87.0.702583727095.issue25057@psf.upfronthosting.co.za> Message-ID: <1441927105.75.0.904617489862.issue25057@psf.upfronthosting.co.za> Martin Panter added the comment: I?m not sure this is a good idea. IOBase is a base class, so adding to its API really means everybody?s subclasses may need to be updated to support the proper keyword argument names. Even ignoring classes outside Python?s standard library, it looks like you would need to update BufferedReader, FileIO, etc. What is the reason you want to add keyword argument support? See also Issue 8706 about doing this in general to other functions. I can think of one or two weak reasons why this might be useful: * It allows swapping the arguments: file.seek(whence=SEEK_CUR, offset=+4) may be slightly more readable, because the offset has to be interpreted in the context of ?whence?. * It could allow usage like functools.partial(file.seek, whence=SEEK_CUR)(offset) Also, making the offset default to zero might be useful for doing file.seek(whence=SEEK_END). If we do go ahead with this, it would need documenting (version changed note), and test cases. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 01:24:53 2015 From: report at bugs.python.org (paul j3) Date: Thu, 10 Sep 2015 23:24:53 +0000 Subject: [issue25061] Add native enum support for argparse In-Reply-To: <1441908245.42.0.23532628335.issue25061@psf.upfronthosting.co.za> Message-ID: <1441927493.84.0.154136637297.issue25061@psf.upfronthosting.co.za> paul j3 added the comment: The `type` parameter is a *function* that takes a string, and returns a valid value. If it can't convert the string it is supposed to raise an error. The default one is a do-nothing identity (take a string, return the string). `int` is the Python function that converts a string to an integer. Same for `float`. Your example could be implemented with a simple type function: def enumtype(astring): try: return CustomEnumType[astring.upper()] except KeyError: raise argparse.ArgumentError() parser=argparse.ArgumentParser() parser.add_argument("-p", type=enumtype, default="VAL1") print(parser.parse_args([])) print(parser.parse_args(["-p","val2"])) print(parser.parse_args(["-p","val4"])) which produces: 1557:~/mypy$ python3 issue25061.py Namespace(p=) Namespace(p=) usage: issue25061.py [-h] [-p P] issue25061.py: error: argument -p: invalid enumtype value: 'val4' The default and 'val2' produce enum values in the Namespace. 'val4' raises an error, resulting in the usage and error message. I tried to customize the error message to include the list of valid strings, but it looks like I'll have to dig into the calling tree to do that right. Still the default message is useful, displaying the name of the 'type' function. If we were to add 'enum' support it would have to be something like 'argparse.FileType', a factory class that would take an enum class as parameter, and create a function like my sample. ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 01:27:10 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 10 Sep 2015 23:27:10 +0000 Subject: [issue25043] document socket constants for Bluetooth In-Reply-To: <1441810839.86.0.110626914047.issue25043@psf.upfronthosting.co.za> Message-ID: <1441927630.05.0.437480663971.issue25043@psf.upfronthosting.co.za> Martin Panter added the comment: Well if the constant is not very useful then maybe we shouldn?t add it :) For testing, nothing complicated. Maybe check the module attributes exist, and are strings. In the past, people have converted module-level constants to enums, and introduced a typo in a name along the way. Even the simplest test case would pick up this sort of typo. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 02:15:11 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 11 Sep 2015 00:15:11 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1417530925.56.0.55888060474.issue22980@psf.upfronthosting.co.za> Message-ID: <1441930511.7.0.204343684678.issue22980@psf.upfronthosting.co.za> Steve Dower added the comment: There's no dot before the debug marker on Windows. Otherwise, looks good to me. Thanks for writing this up. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 03:00:56 2015 From: report at bugs.python.org (paul j3) Date: Fri, 11 Sep 2015 01:00:56 +0000 Subject: [issue25061] Add native enum support for argparse In-Reply-To: <1441908245.42.0.23532628335.issue25061@psf.upfronthosting.co.za> Message-ID: <1441933256.77.0.625122143232.issue25061@psf.upfronthosting.co.za> paul j3 added the comment: Here's a type function that enumerates the enum in the error message: def enumtype(astring): try: return CustomEnumType[astring.upper()] except KeyError: msg = ', '.join([t.name.lower() for t in CustomEnumType]) msg = 'CustomEnumType: use one of {%s}'%msg raise argparse.ArgumentTypeError(msg) You could do the same sort of enumeration in the `help` parameter (or even the metavar). One further note - the input string is first passed through `type`, then it is checked against the `choices` (if any). If it is converted to the enum in an type function, the choices will also have to be enums, not their string representation. String defaults are (usually) passed through `type`. Nonstring defaults are not converted or tested. So the value of this sort of type function depends on whether it is more convenient to work with the string representation or the enum itself. When exactly do you want the commandline string to be converted to the enum? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 03:26:03 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 11 Sep 2015 01:26:03 +0000 Subject: [issue25038] test_os.TestSendfile.test_keywords() introduced a regression In-Reply-To: <1441781810.94.0.0104425602054.issue25038@psf.upfronthosting.co.za> Message-ID: <1441934763.58.0.704868936806.issue25038@psf.upfronthosting.co.za> Martin Panter added the comment: Victor, the BSD and OS X buildbots seem to be passing test_os now. E.g.: http://buildbot.python.org/all/buildslaves/koobs-freebsd10 http://buildbot.python.org/all/buildslaves/intel-yosemite-icc Do you agree we can close this? ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 04:07:25 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 Sep 2015 02:07:25 +0000 Subject: [issue16893] Generate Idle help from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1441937245.38.0.22781283014.issue16893@psf.upfronthosting.co.za> Terry J. Reedy added the comment: In msg185726 Ned said "Ironically, the Tk text widget is perfectly capable of rendering richer text styles." He was and is correct. Mark Roseman offered to take up the challenge. In spite of my skepticism, he went ahead and built sphinxview around HTMLParser. This reduced the core of the problem to "for each tag, content, and end tag, what state change or text insertion is needed. The result is simple enough for me to understand and even edit. I sent Mark a detailed comparison of the Firefox rendering of idle.html and his tk rendering. He replied with a new version whose output is essentially identical to Firefox's (minus links), including the green example box. I intend to use a third version and will work on a full patch. When running in a repository clone, Idle could access ../../Doc/build/html/library/idle.html. But for installations, idle.html needs to be in idlelib. I guess the only was to guarantee this everywhere (excepting overt downstream removals) is to commit it into the repository, unlike most other files built from .rst files). To help make sure this happens, I would like to add a comment at the top of idle.rst. The devguide sentence on comments is unclear to me. Will the following work? .. # After editing this, also build html, copy idle.html to idlelib, test, and upload or commit the html diff also. It would be nice if the copy and commit process were added to the release process, but I will go ahead even without that. A nicely rendered, slightly out-of-date .html will be a great improvement over the current situation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 04:13:11 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 11 Sep 2015 02:13:11 +0000 Subject: [issue13559] Use sendfile where possible in httplib In-Reply-To: <1323377245.96.0.509517020675.issue13559@psf.upfronthosting.co.za> Message-ID: <1441937591.95.0.784906467986.issue13559@psf.upfronthosting.co.za> Martin Panter added the comment: The multiple personalities of HTTPConnection.send() and friends is a bit of a can of worms. I suggest working on Issue 23740 to get an idea of what kinds of file objects are meant to be supported, and what things may work by accident and be used in the real world. For instance, is it possible to manually set Content-Length, and say supply a GzipFile reader, or file object positioned halfway through the file? How does this interact with the socket.sendfile() call? ---------- dependencies: +http.client request and send method have some datatype issues nosy: +martin.panter stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 04:26:28 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 11 Sep 2015 02:26:28 +0000 Subject: [issue25047] xml.etree.ElementTree encoding declaration should be capital ('UTF-8') rather than lowercase ('utf-8') In-Reply-To: <1441827818.89.0.928682692456.issue25047@psf.upfronthosting.co.za> Message-ID: <1441938388.7.0.235657015424.issue25047@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: -> needs patch versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 04:27:22 2015 From: report at bugs.python.org (Stanislaw Izaak Pitucha) Date: Fri, 11 Sep 2015 02:27:22 +0000 Subject: [issue25053] Possible race condition in Pool In-Reply-To: <1441884822.26.0.222476862534.issue25053@psf.upfronthosting.co.za> Message-ID: <1441938442.72.0.635684206368.issue25053@psf.upfronthosting.co.za> Stanislaw Izaak Pitucha added the comment: I agree with what you said mostly. I wonder though if the message could be clearer in the docs. I remember that the rule about the module being importable without side-effects, but didn't even consider that for the interactive session. If I understand your analysis correctly, you're basically saying that "don't use multiprocessing" could be a general rule for interactive interpreters? Which would also affect any ipython session like ipython notebooks? (seems to be confirmed if you google for "multiprocessing ipython crash"...) If that's true, maybe that specific case should be spelled out in the docs more explicitly. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 04:36:39 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Sep 2015 02:36:39 +0000 Subject: [issue24984] document AF_BLUETOOTH socket address formats In-Reply-To: <1441210010.76.0.198064903239.issue24984@psf.upfronthosting.co.za> Message-ID: <20150911023636.15716.80430@psf.io> Roundup Robot added the comment: New changeset 00db99149cdd by Martin Panter in branch '3.4': Issue #24984: BTPROTO_SCO supports only bytes objects https://hg.python.org/cpython/rev/00db99149cdd New changeset b507a7e79154 by Martin Panter in branch '3.5': Issue #24984: Merge BTPROTO_SCO doc fix from 3.4 into 3.5 https://hg.python.org/cpython/rev/b507a7e79154 New changeset 7e4391155d9c by Martin Panter in branch 'default': Issue #24984: Merge BTPROTO_SCO doc fix from 3.5 https://hg.python.org/cpython/rev/7e4391155d9c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 04:37:33 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 11 Sep 2015 02:37:33 +0000 Subject: [issue24984] document AF_BLUETOOTH socket address formats In-Reply-To: <1441210010.76.0.198064903239.issue24984@psf.upfronthosting.co.za> Message-ID: <1441939053.07.0.136568811282.issue24984@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 05:00:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Sep 2015 03:00:00 +0000 Subject: [issue25022] Remove PC/example_nt/ In-Reply-To: <1441687350.45.0.29239152419.issue25022@psf.upfronthosting.co.za> Message-ID: <20150911025957.17981.39867@psf.io> Roundup Robot added the comment: New changeset 8ba735b018d2 by Martin Panter in branch '3.4': Issue #25022: Avoid warning about unused suspicious rule https://hg.python.org/cpython/rev/8ba735b018d2 New changeset b75b4a6e1c9b by Martin Panter in branch '3.5': Issue #25022: Merge susp-ignored.csv from 3.4 into 3.5 https://hg.python.org/cpython/rev/b75b4a6e1c9b New changeset 8902bcea59be by Martin Panter in branch 'default': Issue #25022: Merge susp-ignored.csv from 3.5 https://hg.python.org/cpython/rev/8902bcea59be New changeset 1a52db3ef0e8 by Martin Panter in branch '2.7': Issue #25022: Avoid warning about unused suspicious rule https://hg.python.org/cpython/rev/1a52db3ef0e8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 05:06:40 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 11 Sep 2015 03:06:40 +0000 Subject: [issue16893] Generate Idle help from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1441940800.11.0.987500404001.issue16893@psf.upfronthosting.co.za> Zachary Ware added the comment: I'd be happy to work on making an 'idledoc' target for the Doc/ makefiles that works with Mark's viewer. I can't guarantee any kind of timeframe, but the idledoc target wouldn't be necessary right off the bat; it could be done after the main bulk of the patch is committed. As far as reST comments, the syntax is: """ .. This is a comment. This is still the same comment. And more of the same comment. This is no longer part of the comment """ See http://docutils.sourceforge.net/docs/user/rst/quickref.html#comments ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 05:46:56 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 11 Sep 2015 03:46:56 +0000 Subject: [issue25064] Adjust tempfile documentation for bytes filename support Message-ID: <1441943216.0.0.731717269075.issue25064@psf.upfronthosting.co.za> New submission from Martin Panter: This is a followup to Issue 24230, which added support for bytes filenames to ?tempfile? module. Currently I think the documentation is misleading, for example it suggests the default values are prefix="tmp" and suffix="", when they are actually None to avoid forcing a text filename. I suggest this patch to fix the problem. The patch also merges the paragraphs that describe ?suffix? and ?prefix?, and points out that mktemp() does not support these changes. ---------- assignee: docs at python components: Documentation files: tempfile-sig.patch keywords: patch messages: 250440 nosy: docs at python, gregory.p.smith, martin.panter priority: normal severity: normal stage: patch review status: open title: Adjust tempfile documentation for bytes filename support versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40431/tempfile-sig.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 06:11:35 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Sep 2015 04:11:35 +0000 Subject: [issue25060] BUILD_MAP stack effect suboptimal In-Reply-To: <1441904496.93.0.249532808894.issue25060@psf.upfronthosting.co.za> Message-ID: <20150911041131.114658.85110@psf.io> Roundup Robot added the comment: New changeset 6c1b0dd07340 by Benjamin Peterson in branch '3.5': compute stack effect of BUILD_MAP correctly (closes #25060) https://hg.python.org/cpython/rev/6c1b0dd07340 New changeset 7d76df6dafde by Benjamin Peterson in branch 'default': merge 3.5 (#25060) https://hg.python.org/cpython/rev/7d76df6dafde ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 06:21:31 2015 From: report at bugs.python.org (=?utf-8?b?TWFydMOtbiBHYWl0w6Fu?=) Date: Fri, 11 Sep 2015 04:21:31 +0000 Subject: [issue25065] https://docs.python.org/library should redirect to Python 3 doc Message-ID: <1441945291.84.0.526704676456.issue25065@psf.upfronthosting.co.za> New submission from Mart?n Gait?n: The canonical link for documentation https://docs.python.org/ redirect to the index page of the stable Python 3's documentation However, https://docs.python.org/library still redirects to the Python 2 standard lib's docs. To be consequent https://docs.python.org/library should redirect to https://docs.python.org/3/library/ ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 250442 nosy: Mart?n Gait?n, docs at python priority: normal severity: normal status: open title: https://docs.python.org/library should redirect to Python 3 doc type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 06:25:12 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 11 Sep 2015 04:25:12 +0000 Subject: [issue25066] Better repr for multiprocessing.synchronize objects Message-ID: <1441945512.28.0.268911334925.issue25066@psf.upfronthosting.co.za> New submission from Davin Potts: Inspired by issue24391 and the changes proposed to the threading module's reprs for Event, Semaphore, BoundedSemaphore, and Barrier, the corresponding objects in the multiprocessing module should have their reprs updated accordingly. ---------- assignee: davin components: Library (Lib) messages: 250443 nosy: davin, jnoller, sbt priority: normal severity: normal stage: needs patch status: open title: Better repr for multiprocessing.synchronize objects type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 06:26:01 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 11 Sep 2015 04:26:01 +0000 Subject: [issue25066] Better repr for multiprocessing.synchronize objects In-Reply-To: <1441945512.28.0.268911334925.issue25066@psf.upfronthosting.co.za> Message-ID: <1441945561.07.0.258083932543.issue25066@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- dependencies: +Better repr for threading objects _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 06:36:23 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 11 Sep 2015 04:36:23 +0000 Subject: [issue25066] Better repr for multiprocessing.synchronize objects In-Reply-To: <1441945512.28.0.268911334925.issue25066@psf.upfronthosting.co.za> Message-ID: <1441946183.46.0.218351120538.issue25066@psf.upfronthosting.co.za> Davin Potts added the comment: This patch implements the majority opinion from issue24391 for the desired format of the reprs produced by Event, Semaphore, BoundedSemaphore, and Barrier. It provides tests around each, inspired by Serhiy's preliminary patch for that same issue but adapted for multiprocessing. These tests pass on all but 2 -- it is expected that those 2 will pass once the threading module has been similarly updated as some of the combinatoric tests leverage threading.Event in some cases and multiprocessing.Event in others (and so on for the other synchronization objects). At present, Serhiy's patch still needs updating to match the majority opinion on the repr format, hence it could not yet be applied in combination with this patch for testing. Tests thus far have been performed on OS X 10.10.3. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file40432/issue_25066_sync_objects_reprs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 06:40:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Sep 2015 04:40:51 +0000 Subject: [issue25030] io.[Text]IOBase.seek doesn't take keyword parameter In-Reply-To: <1441719881.64.0.378247085729.issue25030@psf.upfronthosting.co.za> Message-ID: <20150911044047.101480.48575@psf.io> Roundup Robot added the comment: New changeset 0ca216f5276e by Martin Panter in branch '3.4': Issue #25030: Do not document seek() as if it accepts keyword arguments https://hg.python.org/cpython/rev/0ca216f5276e New changeset 77784422da4d by Martin Panter in branch '2.7': Issue #25030: Do not document seek() as if it accepts keyword arguments https://hg.python.org/cpython/rev/77784422da4d New changeset a0c6f5358029 by Martin Panter in branch '3.5': Issue #25030: Merge seek() doc fixes from 3.4 into 3.5 https://hg.python.org/cpython/rev/a0c6f5358029 New changeset c4bb0da8b45e by Martin Panter in branch 'default': Issue #25030: Merge seek() doc fixes from 3.5 https://hg.python.org/cpython/rev/c4bb0da8b45e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 06:44:18 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 11 Sep 2015 04:44:18 +0000 Subject: [issue24391] Better repr for threading objects In-Reply-To: <1433586102.76.0.662503832113.issue24391@psf.upfronthosting.co.za> Message-ID: <1441946658.82.0.818804316572.issue24391@psf.upfronthosting.co.za> Davin Potts added the comment: Echoing Larry's insightful summary, it would not be particularly rewarding to pursue a goal of making the whole world of reprs consistent. But as Antoine and Serhiy began to point out, the multiprocessing module not only has its own Event, Semaphore, BoundedSemaphore, and Barrier, it attempts to directly mirror the threading module's equivalents. If there's a change to the reprs for these in the threading module, then given the special relationship between multiprocessing and threading, I suggest it is worth the effort to update multiprocessing accordingly. I have created issue25066 to separately address this proposed change to multiprocessing. I've gone ahead and provided a patch for issue25066 to reflect the "majority opinion" on the reprs' desired format. That patch should pass all tests once Serhiy's patch is similarly updated to match what Larry summarized. If this issue does reach a happy conclusion and Serhiy finds time to update his patch, would someone please also take a moment to review the patch in issue25066? ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 06:46:29 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 11 Sep 2015 04:46:29 +0000 Subject: [issue25030] io.[Text]IOBase.seek doesn't take keyword parameter In-Reply-To: <1441719881.64.0.378247085729.issue25030@psf.upfronthosting.co.za> Message-ID: <1441946789.03.0.20831336994.issue25030@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for the patch. I took the liberty of also fixing the doc string of BytesIO.seek(). ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 06:46:56 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 11 Sep 2015 04:46:56 +0000 Subject: [issue25066] Better repr for multiprocessing.synchronize objects In-Reply-To: <1441945512.28.0.268911334925.issue25066@psf.upfronthosting.co.za> Message-ID: <1441946816.59.0.659378661372.issue25066@psf.upfronthosting.co.za> Davin Potts added the comment: To Antoine's point in issue24391, here too, these modifications to the format of the repr are estimated to have very little impact or risk to breaking existing code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 06:53:03 2015 From: report at bugs.python.org (Davin Potts) Date: Fri, 11 Sep 2015 04:53:03 +0000 Subject: [issue23484] SemLock acquire() keyword arg 'blocking' is invalid In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za> Message-ID: <1441947183.45.0.0182199604267.issue23484@psf.upfronthosting.co.za> Davin Potts added the comment: @berker.peksag, @r.david.murray: Could I gently nudge one of you into committing the final versions of these patches? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 06:54:57 2015 From: report at bugs.python.org (Petri Lehtinen) Date: Fri, 11 Sep 2015 04:54:57 +0000 Subject: [issue25067] Hello Message-ID: <1441947297.37.0.741766147946.issue25067@psf.upfronthosting.co.za> Changes by Petri Lehtinen : ---------- files: attachment.zip nosy: petri.lehtinen priority: normal severity: normal status: open title: Hello Added file: http://bugs.python.org/file40433/attachment.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 06:57:10 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 11 Sep 2015 04:57:10 +0000 Subject: [issue25065] https://docs.python.org/library should redirect to Python 3 doc In-Reply-To: <1441945291.84.0.526704676456.issue25065@psf.upfronthosting.co.za> Message-ID: <1441947430.0.0.259161594155.issue25065@psf.upfronthosting.co.za> Zachary Ware added the comment: This is by design, see PEP 430 for rationale. Eventually the Python 3 docs will be the default, but that day isn't quite here yet. ---------- nosy: +zach.ware resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 07:36:00 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 11 Sep 2015 05:36:00 +0000 Subject: [issue24225] Idlelib: changing file names In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za> Message-ID: <1441949760.89.0.553429775725.issue24225@psf.upfronthosting.co.za> Terry J. Reedy added the comment: A new factor has entered the picture: the opportunity to move dialogs from using tk widgets to ttk widgets. However, we cannot yet drop support for systems that do not have ttk widgets. We could accommodate using both sets of dialog widgets by adding lots of conditional code within each file as needed, but that would only solve the ttk or not issue. I decided instead to have separate files. This way, the ttk files can have pep 8 names and style and refactorings. New files will be declared private in docstrings. When a new file is written, corresponding old files, if imported (by an extension or non-idle program) when ttk *is* being used , will raise a Deprecation Warning. The same idea will be used for the text window files for shell, edit, and output, which badly need refactoring both as they are and to allow tabbed windows with multiple files. Overall, the plan is to gradually add new files to all current versions (except, probably, 3.4) and delete old files in the future (possibly in 3.6, but not decided now). The transition overlap will be messier than a simple rename, but will avoid the problems of patch merges and immediately breaking 3rd-party code. And the result will be much more and much better than a simple rename. ---------- assignee: -> terry.reedy resolution: -> later stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 07:51:37 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 11 Sep 2015 05:51:37 +0000 Subject: [issue25038] test_os.TestSendfile.test_keywords() introduced a regression In-Reply-To: <1441934763.58.0.704868936806.issue25038@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Sure, close the issue if the regression is fixed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 08:08:48 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 11 Sep 2015 06:08:48 +0000 Subject: [issue25067] Spam Message-ID: <1441951728.35.0.185133393117.issue25067@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: -petri.lehtinen resolution: -> not a bug stage: -> resolved status: open -> closed title: Hello -> Spam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 08:09:01 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 11 Sep 2015 06:09:01 +0000 Subject: [issue25067] Spam Message-ID: <1441951741.32.0.278127182826.issue25067@psf.upfronthosting.co.za> Changes by Zachary Ware : Removed file: http://bugs.python.org/file40433/attachment.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 10:36:25 2015 From: report at bugs.python.org (shiyao.ma) Date: Fri, 11 Sep 2015 08:36:25 +0000 Subject: [issue25057] Make parameter of io.base to be positional and keyword In-Reply-To: <1441927105.75.0.904617489862.issue25057@psf.upfronthosting.co.za> Message-ID: shiyao.ma added the comment: You've listed much of the benefits it can bring about. The real problem is there are many places like iobase.seek to modify to support keyword argument, and seems not many people think it's a good idea to do that, per issue 8706. But I think the former is the main hinder. If there is one commiter that is interested to merge in the related code, I might consider taking my time and handling the rest related similar functions, including the test and the doc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 10:46:13 2015 From: report at bugs.python.org (Chuang Cao) Date: Fri, 11 Sep 2015 08:46:13 +0000 Subject: [issue25068] The proxy key's string should ignore case. Message-ID: <1441961173.2.0.654001525277.issue25068@psf.upfronthosting.co.za> New submission from Chuang Cao: When use a urllib2.ProxyHandler to set a proxy, if the proxies's key is an upper string, like "HTTP", "HTTPS". The proxy url can't be used, because they can't find the _open function. Two way can sovle the issue. 1. Specify it in document to let users to use a lower string like "http". 2. Add a patch in urllib2.py: diff -up ./urllib2.py.orig ./urllib2.py --- ./urllib2.py.orig 2015-09-11 15:06:55.686927934 +0800 +++ ./urllib2.py 2015-09-11 16:56:48.306138898 +0800 @@ -102,6 +102,7 @@ import sys import time import urlparse import bisect +import string try: from cStringIO import StringIO @@ -713,6 +714,7 @@ class ProxyHandler(BaseHandler): assert hasattr(proxies, 'has_key'), "proxies must be a mapping" self.proxies = proxies for type, url in proxies.items(): + type = string.lower(type) setattr(self, '%s_open' % type, lambda r, proxy=url, type=type, meth=self.proxy_open: \ meth(r, proxy, type)) I think the second way is a good way. ---------- components: Library (Lib) messages: 250454 nosy: Chuang Cao priority: normal severity: normal status: open title: The proxy key's string should ignore case. type: resource usage versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 11:02:49 2015 From: report at bugs.python.org (Chris Angelico) Date: Fri, 11 Sep 2015 09:02:49 +0000 Subject: [issue25068] The proxy key's string should ignore case. In-Reply-To: <1441961173.2.0.654001525277.issue25068@psf.upfronthosting.co.za> Message-ID: <1441962169.52.0.0223051642319.issue25068@psf.upfronthosting.co.za> Chris Angelico added the comment: This sounds like a feature enhancement, which means it (almost certainly) won't be applied to Python 2.7. Does the same question come up in Python 3? Also (FWIW) if you can confidently assume that all the keys are strings. then type.lower() is better than string.lower(type). ---------- nosy: +Rosuav _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 11:30:14 2015 From: report at bugs.python.org (Chris Angelico) Date: Fri, 11 Sep 2015 09:30:14 +0000 Subject: [issue24684] socket.getaddrinfo(host) doesn't ensure that host.encode() returns a byte string In-Reply-To: <1437548572.03.0.160792945123.issue24684@psf.upfronthosting.co.za> Message-ID: <1441963814.89.0.904394062187.issue24684@psf.upfronthosting.co.za> Chris Angelico added the comment: ISTM this is a case where Python's core shouldn't be using assert. It's possible for userland code to trigger an assertion failure, which means it should be a regular if(..) raise. Patch attached. @haypo, what do you mean by "fuzzing"? Is there something I've missed here? ---------- keywords: +patch nosy: +Rosuav Added file: http://bugs.python.org/file40434/dont_assert.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 11:39:08 2015 From: report at bugs.python.org (Chris Angelico) Date: Fri, 11 Sep 2015 09:39:08 +0000 Subject: [issue24684] socket.getaddrinfo(host) doesn't ensure that host.encode() returns a byte string In-Reply-To: <1437548572.03.0.160792945123.issue24684@psf.upfronthosting.co.za> Message-ID: <1441964348.91.0.108244572138.issue24684@psf.upfronthosting.co.za> Chris Angelico added the comment: Oops, forgot to add a test. Using a variant of poc_getaddr.py to construct something which fails on current CPython tip, and passes with the patch. ---------- Added file: http://bugs.python.org/file40435/dont_assert_with_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 11:50:40 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 11 Sep 2015 09:50:40 +0000 Subject: [issue25068] The proxy key's string should ignore case. In-Reply-To: <1441961173.2.0.654001525277.issue25068@psf.upfronthosting.co.za> Message-ID: <1441965040.31.0.584556038811.issue25068@psf.upfronthosting.co.za> Martin Panter added the comment: Looking at the code, I think Python 3 is in the same boat. Most things in Python are case-sensitive, but I think it is reasonable to make an exception here, since the protocol schemes in general are insensitive. E.g. urlopen("HTTPS://bugs.python.org/issue25068") still uses "https" internally. It would be good to include a test case and a note in the documentation if we added this though. ---------- nosy: +martin.panter stage: -> needs patch type: resource usage -> enhancement versions: +Python 3.6 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 11:52:30 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 11 Sep 2015 09:52:30 +0000 Subject: [issue23484] SemLock acquire() keyword arg 'blocking' is invalid In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za> Message-ID: <1441965150.06.0.280561268631.issue23484@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- assignee: docs at python -> berker.peksag versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 11:52:58 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 11 Sep 2015 09:52:58 +0000 Subject: [issue25068] The proxy key's string should ignore case. In-Reply-To: <1441961173.2.0.654001525277.issue25068@psf.upfronthosting.co.za> Message-ID: <1441965178.19.0.120010480408.issue25068@psf.upfronthosting.co.za> Martin Panter added the comment: On the other hand, a documentation update saying it has to be lower case would be fine for Python 2.7 and 3.4+, if you wanted to go that way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 11:58:18 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 11 Sep 2015 09:58:18 +0000 Subject: [issue25038] test_os.TestSendfile.test_keywords() introduced a regression In-Reply-To: <1441781810.94.0.0104425602054.issue25038@psf.upfronthosting.co.za> Message-ID: <1441965498.67.0.367897024229.issue25038@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- components: +Tests resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 12:00:54 2015 From: report at bugs.python.org (guilimo) Date: Fri, 11 Sep 2015 10:00:54 +0000 Subject: [issue25069] Clean issue when generator not exhausted (garbage collector related?) Message-ID: <1441965654.18.0.0798037188462.issue25069@psf.upfronthosting.co.za> New submission from guilimo: Hello! I experienced a strange behavior when using a generator, with some code encapsulated in a try/finally clause or a context manager. If the generator is not exhausted when we leave the script (because normal end of script, uncatched exception, etc...), I expect an internal mechanism to execute properly the finally clause (or __exit__ if context manager). However, in some specific cases, it seems that this mechanism does not work as expected. Example ======= Consider the following code: import time def create_generator(): try: yield finally: time.sleep(2) ct = create_generator() ct.next() If you try to execute it, you will get a: "Exception AttributeError: "'NoneType' object has no attribute 'sleep'" in ignored" Description =========== My understanding is the following (but I may be wrong): At the end of the script, the garbage collector automatically calls the close() method of the generator. As a result, GeneratorExit is raised from the "yield", the finally clause is executed, but for some reason, time does not exist anymore (already collected by the GC?). If you try just a print "xxx" instead of the time.sleep, it seems that there is not any problem. Important note: =============== An other very strange thing: It seems that if I use an other name than "ct" for the generator, the same exact code runs flawlessly... You can find attached 3 examples (with try/finally, with a context manager, and with an other name for the generator). I also found this ticket where some discussion may be related to my situation, even if not describing exactly my current problem: https://bugs.python.org/issue25014 ---------- components: Interpreter Core files: examples.zip messages: 250460 nosy: guilimo priority: normal severity: normal status: open title: Clean issue when generator not exhausted (garbage collector related?) type: crash versions: Python 2.7 Added file: http://bugs.python.org/file40436/examples.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 12:43:09 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Sep 2015 10:43:09 +0000 Subject: [issue24684] socket.getaddrinfo(host) doesn't ensure that host.encode() returns a byte string In-Reply-To: <1437548572.03.0.160792945123.issue24684@psf.upfronthosting.co.za> Message-ID: <20150911104306.101492.74548@psf.io> Roundup Robot added the comment: New changeset 2bff115e6ba0 by Victor Stinner in branch '3.4': Issue #24684: socket.socket.getaddrinfo() now calls https://hg.python.org/cpython/rev/2bff115e6ba0 New changeset 0c13674cf8b5 by Victor Stinner in branch '2.7': Issue #24684: socket.socket.getaddrinfo() now calls https://hg.python.org/cpython/rev/0c13674cf8b5 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 12:45:32 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 11 Sep 2015 10:45:32 +0000 Subject: [issue24684] socket.getaddrinfo(host) doesn't ensure that host.encode() returns a byte string In-Reply-To: <1437548572.03.0.160792945123.issue24684@psf.upfronthosting.co.za> Message-ID: <1441968332.23.0.388393327585.issue24684@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, I fixed the bug in Python 2.7, 3.4, 3.5 and 3.6. (Python 2.7 was also impacted for custom *unicode* strings.) Thanks for your bug report paul! > ISTM this is a case where Python's core shouldn't be using assert. It's possible for userland code to trigger an assertion failure, which means it should be a regular if(..) raise. Right, this check is implemented in PyUnicode_AsEncodedString(). Moreover, PyUnicode_AsEncodedString() calls directly the codec, it doesn't call the encode() method of the input string. (Sorry, I wrote PyUnicode_AsEncodedObject() which has a different purpose.) > @haypo, what do you mean by "fuzzing"? This: https://en.wikipedia.org/wiki/Fuzz_testing ---------- resolution: -> fixed status: open -> closed versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 12:50:35 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 11 Sep 2015 10:50:35 +0000 Subject: [issue25066] Better repr for multiprocessing.synchronize objects In-Reply-To: <1441945512.28.0.268911334925.issue25066@psf.upfronthosting.co.za> Message-ID: <1441968635.87.0.465467975781.issue25066@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 13:19:23 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 11 Sep 2015 11:19:23 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) on Solaris 11.3 and newer In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1441970363.76.0.306157308642.issue25003@psf.upfronthosting.co.za> STINNER Victor added the comment: > But EINVAL should also be checked for to make sure the system call was invoked with proper parameters. py_getrandom() calls Py_FatalError() or raises an OSError on EINVAL. The error is not silently ignored. > My builds of Python 3.5.0.X (don't recall whether X was a late Beta or release candidate) were core dumping because Python was making that syscall but not checking for EINVAL, Py_FatalError() calls abort(). Usually, operating systems dump a core dump in this case. But it is the expected behaviour. Python now refuses to start if the OS random number generator doesn't work. There are similar checks on the system and monotonic clocks for example. > ... and thus assuming the call was valid, when it was not. Ah! Finally you explain the problem :-) I wrote py_getrandom() for Linux. I didn't expect other operating systems to implement the getrandom() syscall. I hardcoded the flags (0) for example. py_getrandom() calls directly the syscall, because I like the new cool getrandom() syscall of Linux: it avoids the need of a private file descriptor. It would be much better to call a function of the C library, but the GNU C library didn't expose the function yet... On Solaris, the function is available in C, no need to call directly the syscall. It would be better to call the C function, and check if it's available in configure. Can you please try remove_get_entropy.patch + urandom_solaris.patch? ---------- Added file: http://bugs.python.org/file40437/getrandom_solaris.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 13:46:06 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 11 Sep 2015 11:46:06 +0000 Subject: [issue25069] Clean issue when generator not exhausted (garbage collector related?) In-Reply-To: <1441965654.18.0.0798037188462.issue25069@psf.upfronthosting.co.za> Message-ID: <1441971965.99.0.39536315608.issue25069@psf.upfronthosting.co.za> Martin Panter added the comment: You are basically right that it is garbage collection which causes your generator instance to be cleaned up, and in this instance it is happening after ?time.sleep? has been set to None. It could also happen in the order, which would explain why changing names changes the behaviour you see. Why the interpreter has to set module globals to None I?ve never quite understood. Maybe it is to guarantee that modules involved in garbage cycles with __del__() can still be partly cleaned up, otherwise such a cycle could easily keep lots of modules alive via globals. This is not documented very obviously either. The best I can find at the moment is the warning under , which says ?when __del__() is invoked in response to a module being deleted, [globals may be] in the process of being torn down?. The same applies to generator cleanup code. Looking through Python code you will often find workarounds such as prefixing globals with an underscore or caching references in non-global locations. My recommended workaround though is to avoid relying on garbage collection as much as possible, and instead use a try / finally or ?with? block. Then you know exactly when your generator will be cleaned up: ct = create_generator() try: ct.next() finally: ct.close() from contextlib import closing with closing(create_generator()) as ct: ct.next() ---------- nosy: +martin.panter type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 14:09:02 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 11 Sep 2015 12:09:02 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1441973342.5.0.648186635741.issue24965@psf.upfronthosting.co.za> Martin Panter added the comment: Another version of that AST that is better for my digestion: f'a={a}' Module(body=[Expr( value=JoinedStr(values=[ Str(s='a='), FormattedValue( value=Name(id='a', ctx=Load()), conversion=0, format_spec=None, ), ]), )]) I have been reading over the test cases, and left a bunch of suggestions for more edge cases etc. Some of them might reflect that I haven?t completely learnt how the inner Python expression syntax, outer string escaping syntax, {{curly bracket}} escaping, automatic concatenation, etc, are all meant to fit together. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 14:22:37 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 11 Sep 2015 12:22:37 +0000 Subject: [issue25069] Clean issue when generator not exhausted (garbage collector related?) In-Reply-To: <1441965654.18.0.0798037188462.issue25069@psf.upfronthosting.co.za> Message-ID: <1441974157.69.0.885072938963.issue25069@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, it is (was) to break otherwise unbreakable GC cycles involving __del__. Many improvements have been made to these algorithms in python3, such that __del__ methods no longer create unbreakable cycles, although I believe a few cases still remain. Since some python interpreters do not do GC the way CPython does, it is always best to not depend on GC cleanup but instead to be explicit. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 14:40:40 2015 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 11 Sep 2015 12:40:40 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1441975240.86.0.356615842945.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: Thanks, Martin. I've posted my replies. I'll add some more tests, and work on the triple quoted string bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 15:03:44 2015 From: report at bugs.python.org (Antti Haapala) Date: Fri, 11 Sep 2015 13:03:44 +0000 Subject: [issue25070] Python 2.6 - Python 3.4 allows unparenthesized generator with *args, **kw, forbidden in 3.5 Message-ID: <1441976624.09.0.810536371871.issue25070@psf.upfronthosting.co.za> New submission from Antti Haapala: User DeTeReR asked a question (http://stackoverflow.com/questions/32521140/generator-as-function-argument) on Stack Overflow about a special case of code that seemed to work in Python 3.4: f(1 for x in [1], *[2]) and f(*[2], 1 for x in [1]) I found out that when Python 2.6 introduced the "keyword arguments after *args", the checks in ast.c did not follow: for (i = 0; i < NCH(n); i++) { node *ch = CHILD(n, i); if (TYPE(ch) == argument) { if (NCH(ch) == 1) nargs++; else if (TYPE(CHILD(ch, 1)) == gen_for) ngens++; else nkeywords++; } } if (ngens > 1 || (ngens && (nargs || nkeywords))) { ast_error(n, "Generator expression must be parenthesized " "if not sole argument"); return NULL; } the *args, **kwargs were not considered to be of type "argument" by the Grammar, and thus the error was not generated in this case. Further down, the error "non-keyword arg after keyword arg" was not triggered in the case of sole unparenthesized generator expression. Now, the parsing changes in 3.5 have disallowed all of these constructs: f(1 for i in [42], **kw) f(1 for i in [42], *args) f(*args, 1 for i in [42]) which were (erroneously) allowed in previous versions. I believe at least 3.5 release notes should mention this change. ---------- components: Interpreter Core messages: 250468 nosy: ztane priority: normal severity: normal status: open title: Python 2.6 - Python 3.4 allows unparenthesized generator with *args, **kw, forbidden in 3.5 type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 15:15:52 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 11 Sep 2015 13:15:52 +0000 Subject: [issue25070] Python 2.6 - Python 3.4 allows unparenthesized generator with *args, **kw, forbidden in 3.5 In-Reply-To: <1441976624.09.0.810536371871.issue25070@psf.upfronthosting.co.za> Message-ID: <1441977352.24.0.542224679932.issue25070@psf.upfronthosting.co.za> STINNER Victor added the comment: I guess that it's a consequence of the PEP 448 "additional unpacking generalizations". ---------- nosy: +haypo, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 15:25:48 2015 From: report at bugs.python.org (Antti Haapala) Date: Fri, 11 Sep 2015 13:25:48 +0000 Subject: [issue25070] Python 2.6 - Python 3.4 allows unparenthesized generator with *args, **kw, forbidden in 3.5 In-Reply-To: <1441976624.09.0.810536371871.issue25070@psf.upfronthosting.co.za> Message-ID: <1441977948.96.0.0622952910747.issue25070@psf.upfronthosting.co.za> Antti Haapala added the comment: @haypo yes. I must add that I found out that Python 2.5 also allows f(1 for x in [1], *a) and f(1 for x in [1], **kw) but not f(*a, 1 for x in [1]) So I do not know if the first and second cases were intentional or not. Also, in Python 2.6 - 3.4, f(*a, 1 for x in [1]) provides the generator as the *first* positional argument, in 3.5 it'd be the last one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 15:46:52 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 11 Sep 2015 13:46:52 +0000 Subject: [issue25070] Python 2.6 - Python 3.4 allows unparenthesized generator with *args, **kw, forbidden in 3.5 In-Reply-To: <1441976624.09.0.810536371871.issue25070@psf.upfronthosting.co.za> Message-ID: <1441979212.0.0.18504621429.issue25070@psf.upfronthosting.co.za> Stefan Krah added the comment: According to the human readable grammar in the docs https://docs.python.org/3/reference/expressions.html#calls I'd say this was a bug that is now fixed in 3.5. The call should either take a single unparenthesized generator expression or an argument_list (which may contain parenthesized generator expressions). ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 15:50:45 2015 From: report at bugs.python.org (Tim Tisdall) Date: Fri, 11 Sep 2015 13:50:45 +0000 Subject: [issue25043] document socket constants for Bluetooth In-Reply-To: <1441810839.86.0.110626914047.issue25043@psf.upfronthosting.co.za> Message-ID: <1441979445.16.0.708399235375.issue25043@psf.upfronthosting.co.za> Tim Tisdall added the comment: Okay, since there's currently no existing tests for the Bluetooth components of socket and the only example for BDADDR_ALL seems to be for something I'm not sure you can do in socket, I'm just going to not bother including it. I've attached a 3.6 patch without BDADDR_ALL. ---------- Added file: http://bugs.python.org/file40438/bdaddr_36_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 15:50:47 2015 From: report at bugs.python.org (Antti Haapala) Date: Fri, 11 Sep 2015 13:50:47 +0000 Subject: [issue25070] Python 2.6 - Python 3.4 allows unparenthesized generator with *args, **kw, forbidden in 3.5 In-Reply-To: <1441976624.09.0.810536371871.issue25070@psf.upfronthosting.co.za> Message-ID: <1441979447.98.0.0509681377391.issue25070@psf.upfronthosting.co.za> Antti Haapala added the comment: Yeah, it is a bug in 2.5 too; https://docs.python.org/2.5/ref/calls.html call ::= primary "(" [argument_list [","] | expression genexpr_for] ")" ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 15:58:47 2015 From: report at bugs.python.org (Brian Boonstra) Date: Fri, 11 Sep 2015 13:58:47 +0000 Subject: [issue24927] multiprocessing.Pool hangs forever on segfault In-Reply-To: <1440435917.07.0.324379639121.issue24927@psf.upfronthosting.co.za> Message-ID: <1441979927.41.0.249993102151.issue24927@psf.upfronthosting.co.za> Brian Boonstra added the comment: See also issue 22393 ---------- nosy: +brianboonstra _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 16:27:51 2015 From: report at bugs.python.org (Nikita Klimov) Date: Fri, 11 Sep 2015 14:27:51 +0000 Subject: [issue24899] Add an os.path <=> pathlib equivalence table in pathlib docs In-Reply-To: <1440050617.44.0.44226546659.issue24899@psf.upfronthosting.co.za> Message-ID: <1441981671.24.0.904595012557.issue24899@psf.upfronthosting.co.za> Changes by Nikita Klimov : ---------- nosy: +klimov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 16:30:57 2015 From: report at bugs.python.org (Tim Tisdall) Date: Fri, 11 Sep 2015 14:30:57 +0000 Subject: [issue25043] document socket constants for Bluetooth In-Reply-To: <1441810839.86.0.110626914047.issue25043@psf.upfronthosting.co.za> Message-ID: <1441981857.21.0.165501205044.issue25043@psf.upfronthosting.co.za> Tim Tisdall added the comment: okay, I talked to one of the Bluez developers and he recommended leaving out BDADDR_ALL since it doesn't seem to correspond to anything in the kernel. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 18:10:01 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 11 Sep 2015 16:10:01 +0000 Subject: [issue25071] Windows installer requires TargetDir parameter when installing quietly Message-ID: <1441987801.17.0.563318681861.issue25071@psf.upfronthosting.co.za> New submission from Steve Dower: If you run the installer without UI and without specifying an installation path, it will not install. For example: C:\> python-3.5.0rc4-amd64-webinstall.exe /passive The workaround is to specify TargetPath: C:\> python-3.5.0rc4-amd64-webinstall.exe /passive TargetPath="C:\Python35_x64" However, this workaround should not be necessary. We should use the default path based on the InstallAllUsers setting (false by default). ---------- assignee: steve.dower components: Installation, Windows messages: 250476 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: Windows installer requires TargetDir parameter when installing quietly type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 18:10:26 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 11 Sep 2015 16:10:26 +0000 Subject: [issue25071] Windows installer requires TargetDir parameter when installing quietly In-Reply-To: <1441987801.17.0.563318681861.issue25071@psf.upfronthosting.co.za> Message-ID: <1441987826.94.0.513021633718.issue25071@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- nosy: +takluyver _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 18:12:32 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 11 Sep 2015 16:12:32 +0000 Subject: [issue25071] Windows installer requires TargetDir parameter when installing quietly In-Reply-To: <1441987801.17.0.563318681861.issue25071@psf.upfronthosting.co.za> Message-ID: <1441987952.9.0.732417621016.issue25071@psf.upfronthosting.co.za> Steve Dower added the comment: Adding Larry, as this either needs a fix or a prominent release note for 3.5.0 (or we document the bug in the docs). I *think* the fix will be fairly simple and constrained entire to one file. Should have something ready later today. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 19:11:41 2015 From: report at bugs.python.org (John Beck) Date: Fri, 11 Sep 2015 17:11:41 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) on Solaris 11.3 and newer In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1441991501.59.0.116250827009.issue25003@psf.upfronthosting.co.za> John Beck added the comment: Yes, those patches work, with a caveat. While testing this, I found out why I had needed EINVAL earlier (and still do, for now): there is a bug in the Solaris implementation of getrandom(2). If flags are 0 and the buffer size > 1024, then it fails with EINVAL. That is only supposed to happen for a buffer that big if GNRD_RANDOM is set in flags but GNRD_NONBLOCK is not set. So until that bug is fixed, I have to patch py_getrandom() to treat EINVAL like ENOSYS and fall back to using /dev/urandom as if getrandom(2) were not supported. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 19:57:28 2015 From: report at bugs.python.org (Vincent Caloone) Date: Fri, 11 Sep 2015 17:57:28 +0000 Subject: [issue25072] CGI large POST data string truncated Message-ID: <1441994248.84.0.261500887085.issue25072@psf.upfronthosting.co.za> New submission from Vincent Caloone: For "large" POST request (> 25 ko), cgi.FieldStorage() doesn't contains all field in the html form. When we trace the root of the issue, it is located in file server.py : if self.command.lower() == "post" and nbytes > 0: data = self.rfile.read(nbytes) the size of 'rfile' is less than the number of byte we attemp to read 'nbyte' with is corresponding to the Content-Length of the POST request header. Issue seems to be linked with buffering since changing rbufsize from 0 to -1 : # Make rfile unbuffered -- we need to read one line and then pass # the rest to a subprocess, so we can't use buffered input. #rbufsize = 0 rbufsize = -1 stop the issue. Any idea of the real root of this issue ? Many thanks. ---------- messages: 250479 nosy: Vincent Caloone priority: normal severity: normal status: open title: CGI large POST data string truncated type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 19:58:11 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 11 Sep 2015 17:58:11 +0000 Subject: [issue25071] Windows installer requires TargetDir parameter when installing quietly In-Reply-To: <1441987801.17.0.563318681861.issue25071@psf.upfronthosting.co.za> Message-ID: <1441994291.32.0.585458523789.issue25071@psf.upfronthosting.co.za> Steve Dower added the comment: Patch attached. PR for 3.5.0 at: https://bitbucket.org/larry/cpython350/pull-requests/25/issue-25071-windows-installer-should-not/diff ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file40439/25071_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 19:59:56 2015 From: report at bugs.python.org (Jake Garver) Date: Fri, 11 Sep 2015 17:59:56 +0000 Subject: [issue24903] Do not verify destdir argument to compileall In-Reply-To: <1440090340.94.0.960846948858.issue24903@psf.upfronthosting.co.za> Message-ID: <1441994396.87.0.948898714566.issue24903@psf.upfronthosting.co.za> Jake Garver added the comment: Updated patch. Same as before, but updates tests. Sorry I went MIA on this issue. ---------- Added file: http://bugs.python.org/file40440/python34_compileall_ddir_2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 20:09:38 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 11 Sep 2015 18:09:38 +0000 Subject: [issue25073] Document asyncio.test_utils Message-ID: <1441994978.81.0.376266304966.issue25073@psf.upfronthosting.co.za> New submission from Zachary Ware: asyncio.test_utils is not documented. I'm unsure as to whether that's because it's meant to be private, or if it just hasn't been done yet. ---------- assignee: docs at python components: Documentation, asyncio messages: 250482 nosy: docs at python, gvanrossum, haypo, yselivanov, zach.ware priority: normal severity: normal stage: needs patch status: open title: Document asyncio.test_utils type: enhancement versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 20:15:43 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 11 Sep 2015 18:15:43 +0000 Subject: [issue25073] Document asyncio.test_utils In-Reply-To: <1441994978.81.0.376266304966.issue25073@psf.upfronthosting.co.za> Message-ID: <1441995343.59.0.862172934834.issue25073@psf.upfronthosting.co.za> Yury Selivanov added the comment: It's meant to be private. ---------- resolution: -> not a bug stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 20:17:01 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 11 Sep 2015 18:17:01 +0000 Subject: [issue25073] Document asyncio.test_utils In-Reply-To: <1441994978.81.0.376266304966.issue25073@psf.upfronthosting.co.za> Message-ID: <1441995421.91.0.484835201408.issue25073@psf.upfronthosting.co.za> Guido van Rossum added the comment: Agreed, but then why isn't it in the tests directory? There are some examples in the asyncio repo on GitHub that use test_utils.dummy_ssl_context(), and that's probably why; but that's a fairly bad practice plus it's really a one-liner. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 20:17:14 2015 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 11 Sep 2015 18:17:14 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1441995434.21.0.584822351524.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: Thanks again, Martin. I've found 4 bugs so far, based on your suggested tests. The ones I haven't fixed are: 'fur' strings don't work (something in the lexer), and triple quoted strings don't work correctly. I'm working on both of those, and should have an updated patch in the next day or so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 20:25:08 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 11 Sep 2015 18:25:08 +0000 Subject: [issue25071] Windows installer requires TargetDir parameter when installing quietly In-Reply-To: <1441987801.17.0.563318681861.issue25071@psf.upfronthosting.co.za> Message-ID: <1441995908.46.0.0736421322644.issue25071@psf.upfronthosting.co.za> Larry Hastings added the comment: Pull request approved. Hopefully the last one for 3.5.0! Please forward-merge. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 20:31:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Sep 2015 18:31:51 +0000 Subject: [issue25071] Windows installer requires TargetDir parameter when installing quietly In-Reply-To: <1441987801.17.0.563318681861.issue25071@psf.upfronthosting.co.za> Message-ID: <20150911183145.114820.40417@psf.io> Roundup Robot added the comment: New changeset da8f2767b6cc by Steve Dower in branch '3.5': Issue #25071: Windows installer should not require TargetDir parameter when installing quietly https://hg.python.org/cpython/rev/da8f2767b6cc New changeset bb7363b8b50e by Steve Dower in branch 'default': Issue #25071: Windows installer should not require TargetDir parameter when installing quietly https://hg.python.org/cpython/rev/bb7363b8b50e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 20:32:09 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 11 Sep 2015 18:32:09 +0000 Subject: [issue25071] Windows installer requires TargetDir parameter when installing quietly In-Reply-To: <1441987801.17.0.563318681861.issue25071@psf.upfronthosting.co.za> Message-ID: <1441996329.8.0.00542550161454.issue25071@psf.upfronthosting.co.za> Steve Dower added the comment: I hope so too :) ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 20:47:57 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Sep 2015 18:47:57 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1441997277.9.0.0120435992582.issue24915@psf.upfronthosting.co.za> Brett Cannon added the comment: Attached is what I plan to commit to Python 2.7 assuming everyone is happy with the outcome. I tweaked the echoed messages from Alecsandru's patch, pulled in the README changes, and dropped the x86 checks as Antoine and Stefan requested. Assuming people are happy with the patch I will also apply it to Python 3.5 with the appropriate tweaks. ---------- Added file: http://bugs.python.org/file40441/issue24915-python2.7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 21:16:08 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Fri, 11 Sep 2015 19:16:08 +0000 Subject: [issue25074] Bind logger and waninigs modules for asyncio __del__ methods Message-ID: <1441998965.13.0.504603864253.issue25074@psf.upfronthosting.co.za> New submission from Andrew Svetlov: See https://github.com/KeepSafe/aiohttp/issues/497 for the reason. Desctructors and descendant code (`loop.call_exception_handler()`) can be called on interpreter shutdown stage, which leads to printouts like 'None object has no attribute "errror"'. ---------- assignee: asvetlov components: asyncio files: asyncio_bind_modules.patch keywords: patch messages: 250490 nosy: asvetlov, gvanrossum, haypo, yselivanov priority: normal severity: normal stage: patch review status: open title: Bind logger and waninigs modules for asyncio __del__ methods type: enhancement versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40442/asyncio_bind_modules.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 21:18:43 2015 From: report at bugs.python.org (Brian Trotter) Date: Fri, 11 Sep 2015 19:18:43 +0000 Subject: [issue20629] Python ctypes BigEndianStructure bitfield assignment misbehavior in Linux In-Reply-To: <1392414202.99.0.0705946156557.issue20629@psf.upfronthosting.co.za> Message-ID: <1441999123.77.0.693168566926.issue20629@psf.upfronthosting.co.za> Brian Trotter added the comment: I am experiencing the same bug with c_uint32 bitfields inside BigEndianStructure in Python 3.4.0 on Ubuntu 14.04.3 x64. No problem in Windows 7 x64. As shown in the example below, the fourth byte is the only one that is written correctly. This is a rather significant error. Source: import ctypes class BitFieldsBE(ctypes.BigEndianStructure): _pack_ = 1 _fields_ = [ ('a', ctypes.c_uint32, 8), ('b', ctypes.c_uint32, 8), ('c', ctypes.c_uint32, 8), ('d', ctypes.c_uint32, 8)] class BitFieldsLE(ctypes.LittleEndianStructure): _pack_ = 1 _fields_ = [ ('a', ctypes.c_uint32, 8), ('b', ctypes.c_uint32, 8), ('c', ctypes.c_uint32, 8), ('d', ctypes.c_uint32, 8)] be = BitFieldsBE() le = BitFieldsLE() def prints(arg): print(arg) print('be',bytes(be)) print('le',bytes(le)) prints('00000000') be.a = 0xba; be.b = 0xbe; be.c = 0xfa; be.d = 0xce le.a = 0xba; le.b = 0xbe; le.c = 0xfa; le.d = 0xce prints('babeface') be.a = 0xde; be.b = 0xad; be.c = 0xbe; be.d = 0xef le.a = 0xde; le.b = 0xad; le.c = 0xbe; le.d = 0xef prints('deadbeef') Output: 00000000 be b'\x00\x00\x00\x00' le b'\x00\x00\x00\x00' babeface be b'\x00\xfa\x00\xce' le b'\xba\xbe\xfa\xce' deadbeef be b'\x00\xbe\x00\xef' le b'\xde\xad\xbe\xef' ---------- nosy: +Brian Trotter type: -> behavior versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 21:32:05 2015 From: report at bugs.python.org (Yury Selivanov) Date: Fri, 11 Sep 2015 19:32:05 +0000 Subject: [issue25073] Document asyncio.test_utils In-Reply-To: <1441994978.81.0.376266304966.issue25073@psf.upfronthosting.co.za> Message-ID: <1441999925.45.0.998905554996.issue25073@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Agreed, but then why isn't it in the tests directory? I think that the main reason is to make it possible for tests to import some common functionality from 'asyncio' package, when you run them from the cloned github asyncio repo. In fact, I think we should prefix the module with an underscore. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 21:48:28 2015 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 11 Sep 2015 19:48:28 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442000908.12.0.186967688036.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: It turns out 'fur' strings aren't a thing, because 'ur' strings aren't. >From tokenizer.c: /* ur"" and ru"" are not supported */ And the PEP: https://www.python.org/dev/peps/pep-0414/#exclusion-of-raw-unicode-literals I'll add a test to make sure this fails. So I just need to work on the triple-quoted string problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 22:15:18 2015 From: report at bugs.python.org (Guido van Rossum) Date: Fri, 11 Sep 2015 20:15:18 +0000 Subject: [issue25073] Document asyncio.test_utils In-Reply-To: <1441994978.81.0.376266304966.issue25073@psf.upfronthosting.co.za> Message-ID: <1442002518.7.0.161262743375.issue25073@psf.upfronthosting.co.za> Guido van Rossum added the comment: The _ is a good idea. Please do fix up the examples! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 23:06:43 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 11 Sep 2015 21:06:43 +0000 Subject: [issue23447] Import fails when doing a circular import involving an `import *` In-Reply-To: <1423679925.56.0.995999383567.issue23447@psf.upfronthosting.co.za> Message-ID: <1442005603.55.0.543552201395.issue23447@psf.upfronthosting.co.za> Brett Cannon added the comment: Here is Steven's patch touched up. I still have not decided if the semantic change is worth it. If anyone else has an opinion please feel free to speak up. All tests do pass, though, so it at least doesn't seem to directly break anything. ---------- Added file: http://bugs.python.org/file40443/issue23447.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 23:12:06 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 11 Sep 2015 21:12:06 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) on Solaris 11.3 and newer In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1442005926.87.0.0432148606507.issue25003@psf.upfronthosting.co.za> STINNER Victor added the comment: > While testing this, I found out why I had needed EINVAL earlier (and still do, for now): there is a bug in the Solaris implementation of getrandom(2). If flags are 0 and the buffer size > 1024, then it fails with EINVAL. That is only supposed to happen for a buffer that big if GNRD_RANDOM is set in flags but GNRD_NONBLOCK is not set. So until that bug is fixed, ... Ah! So it was useful to dig the EINVAL issue, it's a bug in the kernel :-) You wrote that the final version of Solaris 11.3 and 12 was not released yet. Can we expect a fix in the kernel before the final version? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 23:18:08 2015 From: report at bugs.python.org (John Beck) Date: Fri, 11 Sep 2015 21:18:08 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) on Solaris 11.3 and newer In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1442006288.1.0.188312802843.issue25003@psf.upfronthosting.co.za> John Beck added the comment: I have queried the engineer who owns the kernel bug and will post an update once I hear back from him. But as it is already almost midnight on Friday in his geo, it may well be Monday before I hear back. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 23:36:19 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 11 Sep 2015 21:36:19 +0000 Subject: [issue25043] document socket constants for Bluetooth In-Reply-To: <1441810839.86.0.110626914047.issue25043@psf.upfronthosting.co.za> Message-ID: <1442007379.84.0.380517989694.issue25043@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for your work on this. I think the patch is good, although I might add :const:`BDADDR_ANY` etc markup around the references within the text. By the way, you don?t normally need to make separate patches for each branch. When I commit this I will just apply the 3.4 version, and then automatically merging to the other branches should be trivial. ---------- assignee: docs at python -> martin.panter nosy: +berker.peksag stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 23:36:53 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 11 Sep 2015 21:36:53 +0000 Subject: [issue25072] CGI large POST data string truncated In-Reply-To: <1441994248.84.0.261500887085.issue25072@psf.upfronthosting.co.za> Message-ID: <1442007413.02.0.718912540812.issue25072@psf.upfronthosting.co.za> R. David Murray added the comment: Any chance you could provide code that demonstrates this bug? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 11 23:40:29 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 11 Sep 2015 21:40:29 +0000 Subject: [issue25070] Python 2.6 - Python 3.4 allows unparenthesized generator with *args, **kw, forbidden in 3.5 In-Reply-To: <1441976624.09.0.810536371871.issue25070@psf.upfronthosting.co.za> Message-ID: <1442007629.68.0.953844035676.issue25070@psf.upfronthosting.co.za> R. David Murray added the comment: If we have decided that this is a "fixed bug", it should indeed be mentioned in what's new for 3.5 since it is a behavior change. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 01:32:13 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Sep 2015 23:32:13 +0000 Subject: [issue25043] document socket constants for Bluetooth In-Reply-To: <1441810839.86.0.110626914047.issue25043@psf.upfronthosting.co.za> Message-ID: <20150911233210.11272.73855@psf.io> Roundup Robot added the comment: New changeset 152568976062 by Martin Panter in branch '3.4': Issue #25043: Document BDADDR_ and HCI_ Bluetooth socket constants https://hg.python.org/cpython/rev/152568976062 New changeset 3f475417eadd by Martin Panter in branch '3.5': Issue #25043: Merge Bluetooth doc from 3.4 into 3.5 https://hg.python.org/cpython/rev/3f475417eadd New changeset 5325233f117d by Martin Panter in branch 'default': Issue #25043: Merge Bluetooth doc from 3.5 https://hg.python.org/cpython/rev/5325233f117d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 01:33:48 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 11 Sep 2015 23:33:48 +0000 Subject: [issue25043] document socket constants for Bluetooth In-Reply-To: <1441810839.86.0.110626914047.issue25043@psf.upfronthosting.co.za> Message-ID: <1442014428.4.0.881559889632.issue25043@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 01:37:46 2015 From: report at bugs.python.org (Ramin Farajpour Cami) Date: Fri, 11 Sep 2015 23:37:46 +0000 Subject: [issue25075] issue from python in encode base64 with Json Model Message-ID: <1442014666.01.0.500652392111.issue25075@psf.upfronthosting.co.za> New submission from Ramin Farajpour Cami: Hi, issue from python in encode base64 with Json Model in twice encode with base64 output python different with JAVA and C# , if programmer using rest-service in server side and other programmer using UI(Python Django) in client site , this encode different for encode and decode with match json encode model, real example : 1- go to https://www.base64encode.org/ 2- using {"userName":"admin","password":"admin"} (default UTF-8) 3-first encode oupput : "eyJ1c2VyTmFtZSI6ImFkbWluIiwicGFzc3dvcmQiOiJhZG1pbiJ9" 4-again second encode "eyJ1c2VyTmFtZSI6ImFkbWluIiwicGFzc3dvcmQiOiJhZG1pbiJ9" output : "ZXlKMWMyVnlUbUZ0WlNJNkltRmtiV2x1SWl3aWNHRnpjM2R2Y21RaU9pSmhaRzFwYmlKOQ==" now second output python json model : Microsoft Windows [Version 6.2.9200] (c) 2012 Microsoft Corporation. All rights reserved. C:\Users\Matthew F4rr3ll>python Python 2.7.7 (default, Jun 1 2014, 14:21:57) [MSC v.1500 64 bit (AMD64)] on win 32 Type "help", "copyright", "credits" or "license" for more information. >>> import json >>> s1='{"userName":"admin","password":"admin"}' >>> s2 = s1.encode("base64") >>> e = s2.encode("base64") >>> print e ZXlKMWMyVnlUbUZ0WlNJNkltRmtiV2x1SWl3aWNHRnpjM2R2Y21RaU9pSmhaRzFwYmlKOQo= >>> >>> >>> now check this output : ZXlKMWMyVnlUbUZ0WlNJNkltRmtiV2x1SWl3aWNHRnpjM2R2Y21RaU9pSmhaRzFwYmlKOQo= ZXlKMWMyVnlUbUZ0WlNJNkltRmtiV2x1SWl3aWNHRnpjM2R2Y21RaU9pSmhaRzFwYmlKOQ== you see in two encode different in end line in ("o=" != "==") also i know resolve this but you should fix in end line encode match with other language Thanks, Ramin ---------- components: 2to3 (2.x to 3.x conversion tool) messages: 250502 nosy: Ramin Farajpour Cami priority: normal severity: normal status: open title: issue from python in encode base64 with Json Model type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 01:56:37 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 11 Sep 2015 23:56:37 +0000 Subject: [issue25063] shutil.copyfileobj should internally use os.sendfile when possible In-Reply-To: <1441910330.09.0.484556764779.issue25063@psf.upfronthosting.co.za> Message-ID: <20150911235633.12009.16527@psf.io> Roundup Robot added the comment: New changeset 3d9cbbad8a04 by Martin Panter in branch '3.4': Issue #25063: socket.sendfile() does not exist in 3.4 https://hg.python.org/cpython/rev/3d9cbbad8a04 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 02:19:49 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 12 Sep 2015 00:19:49 +0000 Subject: [issue25075] issue from python in encode base64 with Json Model In-Reply-To: <1442014666.01.0.500652392111.issue25075@psf.upfronthosting.co.za> Message-ID: <1442017189.25.0.10914597955.issue25075@psf.upfronthosting.co.za> Martin Panter added the comment: This seems to be as documented. Have a look at the definition of ?base64_codec? under , which says ?the result always includes a trailing '\n' ?. In fact, line breaks are also added for longer encodings so that each line is ? 76 symbols. >>> e.decode("base64") 'eyJ1c2VyTmFtZSI6ImFkbWluIiwicGFzc3dvcmQiOiJhZG1pbiJ9\n' Your alternative encoding does not include that trailing newline. If you don?t want the ?MIME Base-64? multiline encoding maybe you should use something like base64.b64encode() directly. See also Issue 16473 where I proposed a patch to fix the Python 3 documentation that links to the wrong equivalent function. ---------- nosy: +martin.panter resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 02:20:18 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 12 Sep 2015 00:20:18 +0000 Subject: [issue25075] issue from python in encode base64 with Json Model In-Reply-To: <1442014666.01.0.500652392111.issue25075@psf.upfronthosting.co.za> Message-ID: <1442017218.91.0.681224349266.issue25075@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- components: -2to3 (2.x to 3.x conversion tool) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 02:26:40 2015 From: report at bugs.python.org (Ramin Farajpour Cami) Date: Sat, 12 Sep 2015 00:26:40 +0000 Subject: [issue25075] issue from python in encode base64 with Json Model In-Reply-To: <1442014666.01.0.500652392111.issue25075@psf.upfronthosting.co.za> Message-ID: <1442017600.07.0.425534659805.issue25075@psf.upfronthosting.co.za> Ramin Farajpour Cami added the comment: why any update in python 2.7? you should using a function this code change : enc_sec = ZXlKMWMyVnlUbUZ0WlNJNkltRmtiV2x1SWl3aWNHRnpjM2R2Y21RaU9pSmhaRzFwYmlKOQo= url = re.sub('\o=$','',enc_sec) result = url.replace('\n','==') print result ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 02:30:55 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 12 Sep 2015 00:30:55 +0000 Subject: [issue25075] issue from python in encode base64 with Json Model In-Reply-To: <1442014666.01.0.500652392111.issue25075@psf.upfronthosting.co.za> Message-ID: <1442017855.19.0.0855917357385.issue25075@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 02:50:28 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 12 Sep 2015 00:50:28 +0000 Subject: [issue16473] quopri module differences in quoted-printable text with whitespace In-Reply-To: <1352928126.09.0.115783436578.issue16473@psf.upfronthosting.co.za> Message-ID: <1442019028.11.0.339658825491.issue16473@psf.upfronthosting.co.za> Martin Panter added the comment: Will commit a slightly modified version of my doc patch to 3.4+, since mentioning the wrong functions is confusing. But I think we still need to fix the ?binascii? decoding, and have a look at Alejandro?s test suite patch. ---------- nosy: +berker.peksag stage: -> needs patch type: -> behavior versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 02:59:27 2015 From: report at bugs.python.org (Ramin Farajpour Cami) Date: Sat, 12 Sep 2015 00:59:27 +0000 Subject: [issue25075] issue from python in encode base64 with Json Model In-Reply-To: <1442014666.01.0.500652392111.issue25075@psf.upfronthosting.co.za> Message-ID: <1442019567.43.0.226723106042.issue25075@psf.upfronthosting.co.za> Ramin Farajpour Cami added the comment: no close plz, i using python 2.7.3 i get this output without "\n"? code: json_obj='{"userName": "admin", "password": "admin"}' enc = json_obj.encode("base64") print enc enc_sec = re.sub('\n$','',enc) print enc_sec sec = enc_sec.encode("base64") print sec Output: {"userName": "admin", "password": "admin"} eyJ1c2VyTmFtZSI6ICJhZG1pbiIsICJwYXNzd29yZCI6ICJhZG1pbiJ9 ZXlKMWMyVnlUbUZ0WlNJNklDSmhaRzFwYmlJc0lDSndZWE56ZDI5eVpDSTZJQ0poWkcxcGJpSjk= ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 03:44:43 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 Sep 2015 01:44:43 +0000 Subject: [issue16473] quopri module differences in quoted-printable text with whitespace In-Reply-To: <1352928126.09.0.115783436578.issue16473@psf.upfronthosting.co.za> Message-ID: <20150912014439.101474.27888@psf.io> Roundup Robot added the comment: New changeset de82f41d6669 by Martin Panter in branch '3.4': Issue #16473: Fix byte transform codec documentation; test quotetabs=True https://hg.python.org/cpython/rev/de82f41d6669 New changeset 28cd11dc2915 by Martin Panter in branch '3.5': Issue #16473: Merge codecs doc and test from 3.4 into 3.5 https://hg.python.org/cpython/rev/28cd11dc2915 New changeset 3ecb5766ba15 by Martin Panter in branch 'default': Issue #16473: Merge codecs doc and test from 3.5 https://hg.python.org/cpython/rev/3ecb5766ba15 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 04:56:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 Sep 2015 02:56:31 +0000 Subject: [issue16473] quopri module differences in quoted-printable text with whitespace In-Reply-To: <1352928126.09.0.115783436578.issue16473@psf.upfronthosting.co.za> Message-ID: <20150912025628.101482.81649@psf.io> Roundup Robot added the comment: New changeset cfb0481c89d7 by Martin Panter in branch '2.7': Issue #16473: Fix byte transform codec documentation; test quotetabs=True https://hg.python.org/cpython/rev/cfb0481c89d7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 05:22:56 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Sep 2015 03:22:56 +0000 Subject: [issue25008] Deprecate smtpd In-Reply-To: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za> Message-ID: <1442028176.31.0.632600701165.issue25008@psf.upfronthosting.co.za> Terry J. Reedy added the comment: http://nullege.com/codes/search?cq=import+smtpd shows 135 hits. FWIW, import+asyncore get 972. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 05:28:12 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 12 Sep 2015 03:28:12 +0000 Subject: [issue25070] Python 2.6 - Python 3.4 allows unparenthesized generator with *args, **kw, forbidden in 3.5 In-Reply-To: <1441976624.09.0.810536371871.issue25070@psf.upfronthosting.co.za> Message-ID: <1442028492.34.0.751749437657.issue25070@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 05:36:39 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 12 Sep 2015 03:36:39 +0000 Subject: [issue25070] Python 2.6 - Python 3.4 allows unparenthesized generator with *args, **kw, forbidden in 3.5 In-Reply-To: <1441976624.09.0.810536371871.issue25070@psf.upfronthosting.co.za> Message-ID: <1442028999.19.0.556956771241.issue25070@psf.upfronthosting.co.za> Yury Selivanov added the comment: > If we have decided that this is a "fixed bug", [..] I'd call this a bug fix. The old syntax was completely unreadable. Should I close this issue? > [..] it should indeed be mentioned in what's new for 3.5 since it is a behavior change. Sure, I'll document it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 06:41:06 2015 From: report at bugs.python.org (TAKASE Arihiro) Date: Sat, 12 Sep 2015 04:41:06 +0000 Subject: [issue25076] Wrong parameter name in distutils documentation Message-ID: <1442032866.5.0.225181106977.issue25076@psf.upfronthosting.co.za> New submission from TAKASE Arihiro: In Doc/distutils/apiref.rst, the palameter name of CCompiler.library_option is *lib*, but written *dir* in the documentation. This also applies to the docstring of CCompiler.library_option(). The attached patch fixes it. ---------- assignee: docs at python components: Documentation files: library_option.patch keywords: patch messages: 250512 nosy: artakase, docs at python priority: normal severity: normal status: open title: Wrong parameter name in distutils documentation type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40444/library_option.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 07:54:43 2015 From: report at bugs.python.org (irdb) Date: Sat, 12 Sep 2015 05:54:43 +0000 Subject: [issue10614] ZipFile: add a filename_encoding argument In-Reply-To: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za> Message-ID: <1442037283.88.0.0872514234926.issue10614@psf.upfronthosting.co.za> Changes by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 07:55:36 2015 From: report at bugs.python.org (irdb) Date: Sat, 12 Sep 2015 05:55:36 +0000 Subject: [issue10972] zipfile: add "unicode" option to the force the filename encoding to UTF-8 In-Reply-To: <1295611245.09.0.199855932712.issue10972@psf.upfronthosting.co.za> Message-ID: <1442037336.69.0.023196398913.issue10972@psf.upfronthosting.co.za> Changes by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 09:23:30 2015 From: report at bugs.python.org (Marius Gedminas) Date: Sat, 12 Sep 2015 07:23:30 +0000 Subject: [issue25077] Compiler warnings: initialization from incompatible pointer type Message-ID: <1442042610.13.0.957335882034.issue25077@psf.upfronthosting.co.za> New submission from Marius Gedminas: I'm seeing these compiler warnings while trying to build Python 3.5 on Ubuntu 15.04: In file included from Python/ceval.c:300:0: Python/ceval_gil.h: In function ?drop_gil?: Python/ceval_gil.h:181:144: warning: initialization from incompatible pointer type _Py_atomic_store_relaxed(&gil_last_holder, tstate); ^ In file included from Python/ceval.c:300:0: Python/ceval_gil.h: In function ?take_gil?: Python/ceval_gil.h:243:144: warning: initialization from incompatible pointer type _Py_atomic_store_relaxed(&gil_last_holder, tstate); ^ Python/pystate.c: In function ?PyThreadState_Swap?: Python/pystate.c:509:147: warning: initialization from incompatible pointer type _Py_atomic_store_relaxed(&_PyThreadState_Current, newts); ^ /home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c: In function ?classify_argument?: /home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c:224:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] for (i = 0; i < words; i++) ^ /home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c:245:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] for (i = 0; i < num; i++) ^ /home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c:264:20: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] for (i = 1; i < words; i++) ^ /home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c:270:16: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] for (i = 0; i < words; i++) ^ /home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c: In function ?examine_argument?: /home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c:323:17: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] for (i = 0; i < n; ++i) ^ /home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c: In function ?ffi_call?: /home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c:484:18: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] for (j = 0; j < n; j++, a += 8, size -= 8) ^ /home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c: In function ?ffi_closure_unix64_inner?: /home/mg/src/cpython/Modules/_ctypes/libffi/src/x86/ffi64.c:659:18: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] for (j = 0; j < n; j++, a += 8) ^ I saw bug #1616 and thought you might want to know about these. ---------- components: Build messages: 250513 nosy: mgedmin priority: normal severity: normal status: open title: Compiler warnings: initialization from incompatible pointer type type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 10:13:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 12 Sep 2015 08:13:33 +0000 Subject: [issue16473] quopri module differences in quoted-printable text with whitespace In-Reply-To: <1352928126.09.0.115783436578.issue16473@psf.upfronthosting.co.za> Message-ID: <1442045613.7.0.366954579249.issue16473@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Mentioned functions are not exact equivalents of codecs. They are preferable way to to obtain the similar (apart from minor details) output. ---------- nosy: +ncoghlan, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 11:46:44 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Sat, 12 Sep 2015 09:46:44 +0000 Subject: [issue25078] Document InstallAllUsers installer parameter default 0 Message-ID: <1442051204.9.0.216289255081.issue25078@psf.upfronthosting.co.za> New submission from Thomas Kluyver: In testing the 3.5.0rc4 default installer, I found that the default for InstallAllUsers appears to be 0, whereas it's currently documented as 1. ---------- assignee: docs at python components: Documentation files: installallusers-default.patch keywords: patch messages: 250515 nosy: docs at python, steve.dower, takluyver priority: normal severity: normal status: open title: Document InstallAllUsers installer parameter default 0 versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40445/installallusers-default.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 11:49:19 2015 From: report at bugs.python.org (Optimal BPM) Date: Sat, 12 Sep 2015 09:49:19 +0000 Subject: [issue25079] Tokenize generates NL instead of NEWLINE for comments Message-ID: <1442051359.49.0.451935650182.issue25079@psf.upfronthosting.co.za> New submission from Optimal BPM: Quoting the documentation: tokenize.NL Token value used to indicate a non-terminating newline. The NEWLINE token indicates the end of a logical line of Python code; NL tokens are generated when a logical line of code is continued over multiple physical lines. This doesn't seem to be entirely true. At the end of comments, an .NL, not .NEWLINE is generated: TokenInfo(type=55 (NL), string='\n', start=(5, 22), end=(5, 23), line='# Some docs for the IF\n') As a comment cannot extend over several lines, if would appear that a NEWLINE would be appropriate? ---------- components: Interpreter Core messages: 250516 nosy: Optimal BPM priority: normal severity: normal status: open title: Tokenize generates NL instead of NEWLINE for comments type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 14:04:41 2015 From: report at bugs.python.org (Stefan Krah) Date: Sat, 12 Sep 2015 12:04:41 +0000 Subject: [issue25079] Tokenize generates NL instead of NEWLINE for comments In-Reply-To: <1442051359.49.0.451935650182.issue25079@psf.upfronthosting.co.za> Message-ID: <1442059481.94.0.483118983059.issue25079@psf.upfronthosting.co.za> Stefan Krah added the comment: See: https://docs.python.org/3/reference/lexical_analysis.html#blank-lines ---------- assignee: -> docs at python components: +Documentation -Interpreter Core nosy: +docs at python, skrah resolution: -> not a bug stage: -> resolved status: open -> closed type: behavior -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 14:08:35 2015 From: report at bugs.python.org (Kostis ankostis) Date: Sat, 12 Sep 2015 12:08:35 +0000 Subject: [issue25080] The example-code for making XLM-RPC requests through proxy, fail! Message-ID: <1442059715.67.0.31958758043.issue25080@psf.upfronthosting.co.za> New submission from Kostis ankostis: The example code provided at the bottom of the reference-page: https://docs.python.org/2/library/xmlrpclib.html#example-of-client-usage for making XML-RPC requests through a proxy by defining a custom transport fails (at least) in python-3.4! Obviously it has been kept intact from `xmlrpclib` python-2 but `xmlrpc.client` API has changed and consequently the code fails. Here is a IPython session demonstratin the problem: >>> import xmlrpc.client, http.client >>> >>> class ProxiedTransport(xmlrpc.client.Transport): ... def set_proxy(self, proxy): ... self.proxy = proxy ... def make_connection(self, host): ... self.realhost = host ... h = http.client.HTTP(self.proxy) ... return h ... def send_request(self, connection, handler, request_body): ... connection.putrequest("POST", 'http://%s%s' % (self.realhost, handler)) ... def send_host(self, connection, host): ... connection.putheader('Host', self.realhost) ... >>> p = ProxiedTransport() >>> p.set_proxy('proxy-server:8080') >>> server = xmlrpc.client.Server('http://time.xmlrpc.com/RPC2', transport=p) >>> print(server.currentTime.getCurrentTime()) Traceback (most recent call last): File "D:\Apps\WinPython-64bit-3.4.3.4\python-3.4.3.amd64\lib\site-packages\IPython\core\interactiveshell.py", line 3035, in run_code exec(code_obj, self.user_global_ns, self.user_ns) File "", line 1, in print(server.currentTime.getCurrentTime()) File "D:\Apps\WinPython-64bit-3.4.3.4\python-3.4.3.amd64\lib\xmlrpc\client.py", line 1098, in __call__ return self.__send(self.__name, args) File "D:\Apps\WinPython-64bit-3.4.3.4\python-3.4.3.amd64\lib\xmlrpc\client.py", line 1437, in __request verbose=self.__verbose File "D:\Apps\WinPython-64bit-3.4.3.4\python-3.4.3.amd64\lib\xmlrpc\client.py", line 1140, in request return self.single_request(host, handler, request_body, verbose) File "D:\Apps\WinPython-64bit-3.4.3.4\python-3.4.3.amd64\lib\xmlrpc\client.py", line 1152, in single_request http_conn = self.send_request(host, handler, request_body, verbose) TypeError: send_request() takes 4 positional arguments but 5 were given ---------- assignee: docs at python components: Demos and Tools, Documentation messages: 250518 nosy: Kostis ankostis, docs at python priority: normal severity: normal status: open title: The example-code for making XLM-RPC requests through proxy, fail! versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 14:10:46 2015 From: report at bugs.python.org (Stefan Krah) Date: Sat, 12 Sep 2015 12:10:46 +0000 Subject: [issue25070] Python 2.6 - Python 3.4 allows unparenthesized generator with *args, **kw, forbidden in 3.5 In-Reply-To: <1441976624.09.0.810536371871.issue25070@psf.upfronthosting.co.za> Message-ID: <1442059846.52.0.816387163894.issue25070@psf.upfronthosting.co.za> Stefan Krah added the comment: I think the issue can be closed (after updating "what's new"). Even if we wanted to keep backwards compatibility, it's too late now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 14:16:04 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 12 Sep 2015 12:16:04 +0000 Subject: [issue16473] quopri module differences in quoted-printable text with whitespace In-Reply-To: <1352928126.09.0.115783436578.issue16473@psf.upfronthosting.co.za> Message-ID: <1442060164.44.0.759167319037.issue16473@psf.upfronthosting.co.za> Martin Panter added the comment: The list of functions were added in Issue 17844. I made the change today because I forgot that the listed functions weren?t exactly equivalent when investigating Issue 25075. Base64-codec encodes to multiple lines, but b64encode() returns the raw encoding without line breaks. I see that base64.encodebytes() is listed as a ?legacy interface?, but as far as I can tell nothing outside the legacy interface does any line splitting. Hex-codec encodes to lowercase, but b16encode() returns uppercase, following RFC 4648. Quopri-codec encodes all whitespace, but quopri.encodestring() lets most whitespace through verbatim by default. In this case I think it would be reasonable to change back to encodestring() if we say that quotetabs=True is passed in. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 16:00:52 2015 From: report at bugs.python.org (shiyao.ma) Date: Sat, 12 Sep 2015 14:00:52 +0000 Subject: [issue25007] Add support of copy protocol to zlib compressors and decompressors In-Reply-To: <1441449753.43.0.0389421030599.issue25007@psf.upfronthosting.co.za> Message-ID: <1442066452.95.0.928753514921.issue25007@psf.upfronthosting.co.za> shiyao.ma added the comment: per serhiy's suggestion, added two aliases. ---------- keywords: +patch nosy: +introom Added file: http://bugs.python.org/file40446/patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 17:31:38 2015 From: report at bugs.python.org (Larry Hastings) Date: Sat, 12 Sep 2015 15:31:38 +0000 Subject: [issue25027] Python 3.5.0rc3 on Windows can not load more than 127 C extension modules In-Reply-To: <1441699536.95.0.946857245232.issue25027@psf.upfronthosting.co.za> Message-ID: <1442071898.76.0.635693544038.issue25027@psf.upfronthosting.co.za> Larry Hastings added the comment: Pull request accepted. Please forward-merge, thanks! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 18:05:40 2015 From: report at bugs.python.org (Davin Potts) Date: Sat, 12 Sep 2015 16:05:40 +0000 Subject: [issue23992] multiprocessing: MapResult shouldn't fail fast upon exception In-Reply-To: <1429347621.56.0.157795358647.issue23992@psf.upfronthosting.co.za> Message-ID: <1442073940.16.0.520220444178.issue23992@psf.upfronthosting.co.za> Davin Potts added the comment: The patches make good sense to me -- I have no comments to add in a review. I spent more time than I care to admit concerned with the idea that error_callback (exposed by map_async which map sits on top of) should perhaps be called not just once at the end but each time an exception occurs. Motivated by past jobs which failed overall to yield any results because one out of a million of the inputs triggered an error, I thought the idea very appealing and experimented with implementing it (with happy results). Googling for it though, I found plenty of examples of people asking questions about how callback and error_callback are intended to work -- though the documentation is not explicit on this particular point, most of those search results correctly document in the wild that error_callback is called only once at the end just like callback. I think it best to leave that functionality just as you have it now. Thanks for creating the patch -- looks great to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 18:05:48 2015 From: report at bugs.python.org (Davin Potts) Date: Sat, 12 Sep 2015 16:05:48 +0000 Subject: [issue23992] multiprocessing: MapResult shouldn't fail fast upon exception In-Reply-To: <1429347621.56.0.157795358647.issue23992@psf.upfronthosting.co.za> Message-ID: <1442073948.1.0.626285005892.issue23992@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 18:13:19 2015 From: report at bugs.python.org (Larry Hastings) Date: Sat, 12 Sep 2015 16:13:19 +0000 Subject: [issue22980] C extension naming doesn't take bitness into account In-Reply-To: <1417530925.56.0.55888060474.issue22980@psf.upfronthosting.co.za> Message-ID: <1442074399.07.0.836854497329.issue22980@psf.upfronthosting.co.za> Larry Hastings added the comment: It's fixed! So it's finally closed. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 18:40:47 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 12 Sep 2015 16:40:47 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442076047.24.0.0933065967904.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: After discussing it with Guido, I've removed the ability to combine 'f' with 'u'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 18:42:20 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 Sep 2015 16:42:20 +0000 Subject: [issue25021] product_setstate() Out-of-bounds Read In-Reply-To: <1441684502.22.0.0994334100718.issue25021@psf.upfronthosting.co.za> Message-ID: <20150912164217.11252.8753@psf.io> Roundup Robot added the comment: New changeset 8cc052c28910 by Kristj?n Valur J?nsson in branch '3.3': Issue #25021: Correctly make sure that product.__setstate__ does not access https://hg.python.org/cpython/rev/8cc052c28910 New changeset 4f85b6228697 by Kristj?n Valur J?nsson in branch '3.4': Issue #25021: Merge from 3.3 to 3.4 https://hg.python.org/cpython/rev/4f85b6228697 New changeset ca628ccec846 by Kristj?n Valur J?nsson in branch '3.5': Issue #25021: Merge 3.4 to 3.5 https://hg.python.org/cpython/rev/ca628ccec846 New changeset 92e7ac79c681 by Kristj?n Valur J?nsson in branch 'default': Issue #25021: Merge 3.5 to default https://hg.python.org/cpython/rev/92e7ac79c681 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 18:43:06 2015 From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=) Date: Sat, 12 Sep 2015 16:43:06 +0000 Subject: [issue25021] product_setstate() Out-of-bounds Read In-Reply-To: <1441684502.22.0.0994334100718.issue25021@psf.upfronthosting.co.za> Message-ID: <1442076186.35.0.499550112724.issue25021@psf.upfronthosting.co.za> Changes by Kristj?n Valur J?nsson : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 19:29:59 2015 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 12 Sep 2015 17:29:59 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442078999.28.0.801466688012.issue24965@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: I've started working on implementing this feature in Cython and I'd like to confirm a few edge cases: - f'{ {1: 2\N{RIGHT CURLY BRACKET}[1]}' == '2' (string escape rules work even within the expressions) - f'{ '''foo''' }' is a syntax error - f'{ """foo 'bar'""" }' is a syntax error ---------- nosy: +Jelle Zijlstra _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 19:36:01 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 12 Sep 2015 17:36:01 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442079361.28.0.0387659033862.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: Yes, Jelle, you are correct in all 3 cases. Remember that the steps are to extract the string from the source code, decode backslash escapes, and only then treat it as an f-string. For the first case, without the 'f' prefix: '{ {1: 2\N{RIGHT CURLY BRACKET}[1]}' == '{ {1: 2}[1]}' Then, applying the 'f': f'{ {1: 2}[1]}' == '2'. For the last 2, since they're syntax errors without the 'f', they're also syntax errors with the 'f'. I'll have a new version, with tests for all of these cases, posted in the next few hours. You can leverage the tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 22:34:25 2015 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 12 Sep 2015 20:34:25 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442090065.29.0.178963018563.issue24965@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Thanks! Here are a few more cases I came across with the existing implementation: >>> f"{'a\\'b'}" File "", line 1 SyntaxError: missing '}' in format string expression I believe this is valid and should produce "a'b". >>> f"{x!s!s}" File "", line 1 SyntaxError: single '}' encountered in format string Could use a better error message. >>> x = 3 >>> f"{x!s{y}}" '3y}' Not sure how this happened. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 23:24:18 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 12 Sep 2015 21:24:18 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442093058.49.0.457087952341.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: This one has been fixed: >>> f"{'a\\'b'}" "a'b" This one was a bug that I previously fixed, that Martin pointed out: >>> f"{x!s!s}" File "", line 1 SyntaxError: invalid character following conversion character And this is the same bug: >>> f"{x!s{y}}" File "", line 1 SyntaxError: invalid character following conversion character I'm wrapping up my new code plus tests. I'll post it Real Soon Now. Thanks for your help. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 23:24:24 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 12 Sep 2015 21:24:24 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442093064.7.0.292227024023.issue24965@psf.upfronthosting.co.za> Martin Panter added the comment: Regarding wrong error messages, I?ve learnt the hard way that it is often best to use assertRaisesRegex() instead of assertRaises(), to ensure that the actual exception you have in mind is being triggered, rather than a typo or something. Though that might upset your assertSyntaxErrors() helper. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 23:25:55 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 12 Sep 2015 21:25:55 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442093155.84.0.727904486896.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: Agreed on checking the error messages better. Especially since even the simplest of errors (like leaving out a quote) results in a syntax error in parsing the string, not parsing inside the f-string. I'll look at it eventually. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 23:43:39 2015 From: report at bugs.python.org (Nikita Klimov) Date: Sat, 12 Sep 2015 21:43:39 +0000 Subject: [issue24899] Add an os.path <=> pathlib equivalence table in pathlib docs In-Reply-To: <1440050617.44.0.44226546659.issue24899@psf.upfronthosting.co.za> Message-ID: <1442094219.17.0.304781285077.issue24899@psf.upfronthosting.co.za> Nikita Klimov added the comment: I make a correlation table, plan to finish by September 16 or earlier ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 23:50:09 2015 From: report at bugs.python.org (Davin Potts) Date: Sat, 12 Sep 2015 21:50:09 +0000 Subject: [issue24948] Multiprocessing not timely flushing stack trace to stderr In-Reply-To: <1440710429.87.0.104720490474.issue24948@psf.upfronthosting.co.za> Message-ID: <1442094609.38.0.191413980395.issue24948@psf.upfronthosting.co.za> Davin Potts added the comment: If I understand your motivations correctly, I'd restate them as: you want a mechanism for being immediately notified of an exception in a parent process without waiting on any child processes of that parent to finish and furthermore propose this should be the default behavior. Quick side note: As the docs explain and as the code you propose modifying in Lib/multiprocessing/process.py shows, a Process is designed to track its live children. Interrupting or otherwise destroying a parent process's ability to track its children even after experiencing an exception in its target function would not be desirable. I think we agree that the current behavior you describe is not catastrophic in any sense -- the exception occurs, the process finishes waiting on its children, and that exception bubbles up at the end -- nothing is lost or suppressed. This becomes a question of when should a calling routine be notified of such an exception (happening in what I was just calling a parent process): immediately, if we ask for it, or when it's otherwise done? Different use cases motivate different answers to this question. The current behavior satisfies many common use cases and thankfully it is not difficult to implement the other behaviors in your own code. It can start with a try-except inside the example function 'f' where the except clause's code takes some appropriate action right away rather than waiting on the children, if that is what is desired. def f(): try: p = mp.Process(target=g) p.start() 1/0 p.join() except Exception as e: # Take action, sound the alarm, call out the guards, notify the BDFL! raise e I'm not sure I see the relation to issue13812 which is concerned with traceback text that was sent to stderr but surprisingly wasn't getting flushed to stderr. This issue has no such problem with flushes on stderr -- we are not waiting on stderr here, we are waiting on the parent to finish waiting on its children before any traceback gets written to stderr. ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 23:51:23 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 12 Sep 2015 21:51:23 +0000 Subject: [issue25070] Python 2.6 - Python 3.4 allows unparenthesized generator with *args, **kw, forbidden in 3.5 In-Reply-To: <1441976624.09.0.810536371871.issue25070@psf.upfronthosting.co.za> Message-ID: <20150912215120.114948.95940@psf.io> Roundup Robot added the comment: New changeset 10a9d4acd9cb by Yury Selivanov in branch '3.5': whatsnew/3.5 More edits https://hg.python.org/cpython/rev/10a9d4acd9cb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 23:52:41 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 12 Sep 2015 21:52:41 +0000 Subject: [issue25070] Python 2.6 - Python 3.4 allows unparenthesized generator with *args, **kw, forbidden in 3.5 In-Reply-To: <1441976624.09.0.810536371871.issue25070@psf.upfronthosting.co.za> Message-ID: <1442094761.73.0.0734431626953.issue25070@psf.upfronthosting.co.za> Yury Selivanov added the comment: What's new is now updated with description of this issue. Closing it now. ---------- resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 23:52:42 2015 From: report at bugs.python.org (Davin Potts) Date: Sat, 12 Sep 2015 21:52:42 +0000 Subject: [issue24948] Multiprocessing not timely flushing stack trace to stderr In-Reply-To: <1440710429.87.0.104720490474.issue24948@psf.upfronthosting.co.za> Message-ID: <1442094762.57.0.364808306234.issue24948@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 23:53:00 2015 From: report at bugs.python.org (Davin Potts) Date: Sat, 12 Sep 2015 21:53:00 +0000 Subject: [issue24948] Multiprocessing not timely flushing stack trace to stderr In-Reply-To: <1440710429.87.0.104720490474.issue24948@psf.upfronthosting.co.za> Message-ID: <1442094780.25.0.0730601264255.issue24948@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- nosy: +jnoller, sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 23:56:16 2015 From: report at bugs.python.org (Davin Potts) Date: Sat, 12 Sep 2015 21:56:16 +0000 Subject: [issue23992] multiprocessing: MapResult shouldn't fail fast upon exception In-Reply-To: <1429347621.56.0.157795358647.issue23992@psf.upfronthosting.co.za> Message-ID: <1442094976.41.0.668460455438.issue23992@psf.upfronthosting.co.za> Davin Potts added the comment: As an aside: issue24948 seems to show there are others who would find the immediate-multiple-error_callback idea attractive. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 12 23:58:18 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 12 Sep 2015 21:58:18 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442095098.44.0.912672706861.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: This patch fixes triple-quoted strings, plus a few bugs. I'm going to commit it tomorrow, barring any unforeseen issues. ---------- Added file: http://bugs.python.org/file40447/pep-498-5.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 00:33:01 2015 From: report at bugs.python.org (Andre Merzky) Date: Sat, 12 Sep 2015 22:33:01 +0000 Subject: [issue24862] subprocess.Popen behaves incorrect when moved in process tree In-Reply-To: <1439520939.88.0.252356845124.issue24862@psf.upfronthosting.co.za> Message-ID: <1442097181.47.0.385268821911.issue24862@psf.upfronthosting.co.za> Andre Merzky added the comment: Yes, I have a workaround (and even a clean solution) in my code. My interest in this ticket is more academic than anything else :) Thanks for the pointer to issue1731717. While I am not sure which 'comment at the end' you exactly refer to, the whole discussion provides some more insight on why SIGCHLD is handled the way it is, so that was interesting. I agree that changing the behavior in a way which is unexpected for existing applications is something one wants to avoid, generally. I can't judge if it is worth to break existing code to get more correctness in a corner case -- depends on how much (and what kind of) code relies on it, which I have no idea about. One option to minimize change and improve correctness might be to keep track of the parent process. So one would keep self.parent=os.getpid() along with self.pid. In the implementation of _internal_poll one can then check if self.parent==os.getpid() still holds, and raise an ECHILD or EINVAL otherwise. That would catch the pickle/unpickle across processes case (I don't know Python well enough to see if there are easier ways to check if a class instance is passed across process boundaries). The above would still not be fully POSIX (it ignores process groups which would allow to wait on non-direct descendants), but going down that route would probably almost result in a reimplementation of what libc does... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 00:55:57 2015 From: report at bugs.python.org (Mark Roseman) Date: Sat, 12 Sep 2015 22:55:57 +0000 Subject: [issue25036] IDLE - infrastructure changes so editors don't assume they're in a toplevel In-Reply-To: <1441753399.73.0.466397630291.issue25036@psf.upfronthosting.co.za> Message-ID: <1442098557.57.0.600719741287.issue25036@psf.upfronthosting.co.za> Mark Roseman added the comment: FYI, I've gone past this point in my own playground, to the point of having a working tabbed editor implementation. It's not that much further actually. Here are the next steps: 1. Change so that Container is passed to Components on creation, rather than Component creating its own container. 2. Change statusbar so that it's in control of what is displayed, and EditorWindow just pings it to update itself; statusbar calls into EditorWindow and chooses what info to get. 3. Change so that container decides how to display title, EditorWindow just says title has changed. Add saved/dirty status info to Container. 4. Create Container subclass TabbedContainer using the separate uitabs.py widget I put together. Manages the tabs and switching in different content as tabs are switched. Altogether < 100 lines of code. 5. Create Container subclass ProxyContainer, representing what's managed by a single tab. Just passes things off to TabbedContainer. < 50 lines of code. 6. Change FileList to created a TabbedContainer and then ProxyContainers for each shell/editor added. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 00:58:11 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 12 Sep 2015 22:58:11 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442098691.86.0.727562665152.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: I'll probably ensure that all of the parsing errors contain "format string" or "f-string" or similar. That way the regex check is easier, and the user can search for it more easily. It remains to be seen how these are referenced in the documentation. "f-string" seems much easier to say and search for, but seems too slangy for the docs. But "format string" seems ambiguous and hard to search for. I guess time will tell. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 01:08:59 2015 From: report at bugs.python.org (Mark Roseman) Date: Sat, 12 Sep 2015 23:08:59 +0000 Subject: [issue20917] Idle: Enhance font change notification system In-Reply-To: <1394741097.69.0.88319958865.issue20917@psf.upfronthosting.co.za> Message-ID: <1442099339.68.0.370607588607.issue20917@psf.upfronthosting.co.za> Mark Roseman added the comment: The new 'component' infrastructure provides the mechanism for passing these kinds of notifications around. Allowing extensions (in whatever form they'll exist with the new stuff) to take part in this notification mechanism would be a small (and sensible) addition to that. ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 01:34:17 2015 From: report at bugs.python.org (Andre Merzky) Date: Sat, 12 Sep 2015 23:34:17 +0000 Subject: [issue24862] subprocess.Popen behaves incorrect when moved in process tree In-Reply-To: <1439520939.88.0.252356845124.issue24862@psf.upfronthosting.co.za> Message-ID: <1442100857.22.0.0271804743159.issue24862@psf.upfronthosting.co.za> Andre Merzky added the comment: This is patch is meant to be illustrative rather than functional (but it works in the limited set of cases I tested). ---------- keywords: +patch Added file: http://bugs.python.org/file40448/subprocess.py.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 01:35:47 2015 From: report at bugs.python.org (Andre Merzky) Date: Sat, 12 Sep 2015 23:35:47 +0000 Subject: [issue24862] subprocess.Popen behaves incorrect when moved in process tree In-Reply-To: <1439520939.88.0.252356845124.issue24862@psf.upfronthosting.co.za> Message-ID: <1442100947.91.0.18904558736.issue24862@psf.upfronthosting.co.za> Changes by Andre Merzky : Removed file: http://bugs.python.org/file40448/subprocess.py.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 01:36:00 2015 From: report at bugs.python.org (Andre Merzky) Date: Sat, 12 Sep 2015 23:36:00 +0000 Subject: [issue24862] subprocess.Popen behaves incorrect when moved in process tree In-Reply-To: <1439520939.88.0.252356845124.issue24862@psf.upfronthosting.co.za> Message-ID: <1442100960.26.0.268924616561.issue24862@psf.upfronthosting.co.za> Changes by Andre Merzky : Added file: http://bugs.python.org/file40449/subprocess.py.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 02:15:37 2015 From: report at bugs.python.org (Jelle Zijlstra) Date: Sun, 13 Sep 2015 00:15:37 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442103337.03.0.215942560131.issue24965@psf.upfronthosting.co.za> Jelle Zijlstra added the comment: Is this behavior intentional? >>> str = len >>> x = 'foo' >>> f'{x!s}' '3' >>> '{!s}'.format(x) 'foo' Or similarly: >>> import builtins >>> del builtins.repr >>> f'{x!r}' Traceback (most recent call last): File "", line 1, in NameError: name 'repr' is not defined ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 02:22:09 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 Sep 2015 00:22:09 +0000 Subject: [issue25076] Wrong parameter name in distutils documentation In-Reply-To: <1442032866.5.0.225181106977.issue25076@psf.upfronthosting.co.za> Message-ID: <20150913002153.11248.29096@psf.io> Roundup Robot added the comment: New changeset 1208c85af6d5 by Benjamin Peterson in branch '3.4': fix name of argument in docstring and the docs (closes #25076) https://hg.python.org/cpython/rev/1208c85af6d5 New changeset 63bbe9f80909 by Benjamin Peterson in branch '2.7': fix name of argument in docstring and the docs (closes #25076) https://hg.python.org/cpython/rev/63bbe9f80909 New changeset f4dc1b8bb4b6 by Benjamin Peterson in branch 'default': merge 3.5 (#25076) https://hg.python.org/cpython/rev/f4dc1b8bb4b6 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 02:23:08 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sun, 13 Sep 2015 00:23:08 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442103788.56.0.716340318404.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: Both of those are known (to me!) byproducts of the current implementation. If my crazy idea of adding opcodes to speed up f-strings flies, then this issue will go away. I consider this a corner case that doesn't need to be addressed before committing this code. I wouldn't emulate it one way or the other just yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 05:07:16 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 13 Sep 2015 03:07:16 +0000 Subject: [issue25081] Windows installer Upgrade->Customize->Back goes to Install page Message-ID: <1442113636.61.0.345920202816.issue25081@psf.upfronthosting.co.za> New submission from Steve Dower: If you already have Python 3.5.0b4 or later installed and you go to install a later version, it starts with an "Upgrade" page. If you hit customize from the page, then Back, you end up at the original Install page. You should be at the Customize page. ---------- components: Windows messages: 250547 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: low severity: normal status: open title: Windows installer Upgrade->Customize->Back goes to Install page type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 06:21:21 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 13 Sep 2015 04:21:21 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442118081.73.0.245315372119.issue24965@psf.upfronthosting.co.za> Martin Panter added the comment: I?m actually trying out your patch now. A couple strange errors and observations: >>> f"{'{'}" # Why is this allowed in an outer format expression-- '{' >>> f"{3:{'{'}>10}" # --but not inside a format specifier? SyntaxError: nesting of '{' in format specifier is not allowed >>> opening = "{"; f"{3:{opening}>10}" # Workaround '{{{{{{{{{3' >>> f"{3:{'}'}<10}" # Error message is very strange! SyntaxError: missing '}' in format string expression >>> f"{\x00}" # It seems this is treated as a null terminator File "", line 1 ( ^ SyntaxError: unexpected EOF while parsing >>> f"{'s'!\x00:.<10}" # Default conversion is the null character? 's.........' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 07:36:11 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 13 Sep 2015 05:36:11 +0000 Subject: [issue25021] product_setstate() Out-of-bounds Read In-Reply-To: <1441684502.22.0.0994334100718.issue25021@psf.upfronthosting.co.za> Message-ID: <1442122571.3.0.0704471993764.issue25021@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 08:42:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Sep 2015 06:42:29 +0000 Subject: [issue25082] Editing What's New In Python 3.5 Message-ID: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Added this issue as a place for discussion and release blocker for 3.5. ---------- assignee: yselivanov components: Documentation messages: 250549 nosy: larry, serhiy.storchaka, yselivanov priority: release blocker severity: normal status: open title: Editing What's New In Python 3.5 versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 09:27:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Sep 2015 07:27:18 +0000 Subject: [issue25082] Editing What's New In Python 3.5 In-Reply-To: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> Message-ID: <1442129238.4.0.231523553999.issue25082@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Some modules in the "Improved Modules" section are out of lexicographic order: csv, ssl. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 09:32:48 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 13 Sep 2015 07:32:48 +0000 Subject: [issue25082] Editing What's New In Python 3.5 In-Reply-To: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> Message-ID: <1442129568.94.0.00156518323773.issue25082@psf.upfronthosting.co.za> Larry Hastings added the comment: You wait until the day of release for 3.5.0 final, then create a "release blocker" because some items in the What's New documentation aren't lexographically sorted? We tagged the release yesterday. The installers are already built. I am not holding up the release for this. ---------- priority: release blocker -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 11:17:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Sep 2015 09:17:59 +0000 Subject: [issue25082] Editing What's New In Python 3.5 In-Reply-To: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> Message-ID: <1442135879.33.0.591603490632.issue25082@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Sorry, but I thought that such issue already exist. Yury and Elvis made a lot of changes in What's New in few last days and continue to edit it. Are these changes included in 3.5.0 final? Without their What's New just isn't ready. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 11:22:27 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Sep 2015 09:22:27 +0000 Subject: [issue25082] Editing What's New In Python 3.5 In-Reply-To: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> Message-ID: <1442136147.42.0.86563906987.issue25082@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Personally I found few interesting Python 3.5 features just reading recent commit log for Doc/whatsnew/3.5.rst. Without this they would be unknown for me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 11:24:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Sep 2015 09:24:05 +0000 Subject: [issue25082] Editing What's New In Python 3.5 In-Reply-To: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> Message-ID: <1442136245.17.0.30192085271.issue25082@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: >-constructor. All converters defined in config parser (either by subclassing or >+constructor, or All converters defined in config parser (either by subclassing or Looks as unfinished editing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 11:45:14 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 13 Sep 2015 09:45:14 +0000 Subject: [issue25082] Editing What's New In Python 3.5 In-Reply-To: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> Message-ID: <1442137514.49.0.722715061408.issue25082@psf.upfronthosting.co.za> Larry Hastings added the comment: First, the What's New on the website is generated from the 3.5 branch in hg.python.org. So it's already up-to-date. That's the one most people will refer to. Second, if the What's New was really that horribly out of date, and we wanted people who download the documentation to get a fresh one, we could easily update the downloadable documentation; it ships separately. There would be no need to hold up the release for this. And finally, I actually backported the What's New in 3.5 to the 3.5.0 release yesterday. You can only see evidence of it in one place right now: https://hg.python.org/releasing/3.5/rev/955911b49328 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 13:26:12 2015 From: report at bugs.python.org (tzickel) Date: Sun, 13 Sep 2015 11:26:12 +0000 Subject: [issue25083] Python can sometimes create incorrect .pyc files Message-ID: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za> New submission from tzickel: I had a non-reproducible issue occur a few times in which python 2.7.9 would produce .pyc files with empty code objects on a network drive under windows. The .pyc might have been created due to intermittent network errors that are hard to reproduce reliably. The .pyc files would override the previous correct .pyc files that existed in the same place. The incorrect .pyc is a valid file, but instead of having the code object of the original .py file compiled, it would have the code object of an empty .py file. Python would then go on to use the incorrect .pyc file until it is manually deleted. This peculiar .pyc files got me thinking about how cpython can produce such an incorrect .pyc file instead of failing. The main issue here is that getc function, returns EOF both on EOF and on file error. It seems as if the tokenizer starts reading the file stream, and gets an EOF directly, it would not check if it resulted from actually reading an empty file or because of an file error, and happily return an empty AST which would be then compiled to a bad empty code .pyc instead of aborting the process because of an file error. ---------- messages: 250556 nosy: tzickel priority: normal severity: normal status: open title: Python can sometimes create incorrect .pyc files type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 13:39:43 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sun, 13 Sep 2015 11:39:43 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442144383.82.0.613843724055.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: On 9/13/2015 12:21 AM, Martin Panter wrote: >>>> f"{'{'}" # Why is this allowed in an outer format expression-- > '{' >>>> f"{3:{'{'}>10}" # --but not inside a format specifier? This is me being lazy about detecting recursion. I'll fix it. >>>> f"{\x00}" # It seems this is treated as a null terminator > File "", line 1 > ( > ^ > SyntaxError: unexpected EOF while parsing This is a byproduct of using PyParser_ASTFromString. I'm not particularly included to do anything about it. Is there any practical use case? >>>> f"{'s'!\x00:.<10}" # Default conversion is the null character? > 's.........' Yes, that's the default. I'll switch to -1, which I think won't have this issue. Thanks for the review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 14:29:46 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 Sep 2015 12:29:46 +0000 Subject: [issue25082] Editing What's New In Python 3.5 In-Reply-To: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> Message-ID: <20150913122943.12017.84055@psf.io> Roundup Robot added the comment: New changeset 59f7007fbf3c by Yury Selivanov in branch '3.5': whatsnew/3.5: Reorder stuff (issue #25082). https://hg.python.org/cpython/rev/59f7007fbf3c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 14:31:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 Sep 2015 12:31:19 +0000 Subject: [issue25082] Editing What's New In Python 3.5 In-Reply-To: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> Message-ID: <20150913123117.17965.77697@psf.io> Roundup Robot added the comment: New changeset aa288ad94089 by Yury Selivanov in branch '3.5': whatsnew/3.5: Fix typo (issue #25082) https://hg.python.org/cpython/rev/aa288ad94089 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 14:45:18 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 13 Sep 2015 12:45:18 +0000 Subject: [issue25082] Editing What's New In Python 3.5 In-Reply-To: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> Message-ID: <1442148318.14.0.49047413996.issue25082@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Some modules in the "Improved Modules" section are out of lexicographic order: csv, ssl. Yes, these two weren't properly ordered by *2nd* letter. Fixed. >>-constructor. All converters defined in config parser (either by subclassing or Good catch. Both Elvis and I are going to do a final thorough pass over the whatsnew to fix hiccups like this one. In no way this should be a release blocker. > Second, if the What's New was really that horribly out of date, and we wanted people who download the documentation to get a fresh one, we could easily update the downloadable documentation; it ships separately. There would be no need to hold up the release for this. I'd say it's in a ready shape. We've spent tons of time refining it, syncing NEWS items first, looking for undocumented changes in commits without NEWS updates, syncing docs by versionadded/changed (both ways), etc. I'm fairly confident that 99% of changes are now documented. We'll fix the remaining typos/formatting issues in a few hours. > And finally, I actually backported the What's New in 3.5 to the 3.5.0 release yesterday. Thanks for doing that, Larry! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 14:47:26 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 13 Sep 2015 12:47:26 +0000 Subject: [issue25082] Editing What's New In Python 3.5 In-Reply-To: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> Message-ID: <1442148446.03.0.332977201176.issue25082@psf.upfronthosting.co.za> Larry Hastings added the comment: I'm hoping to release 3.5.0 final in the next hour or two. I don't want to hold up the release for your changes. However, when you're done making changes to the document, and they're all checked in, let me know and I'll manually build it and push it to the web site. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 15:00:36 2015 From: report at bugs.python.org (Elvis Pranskevichus) Date: Sun, 13 Sep 2015 13:00:36 +0000 Subject: [issue25082] Editing What's New In Python 3.5 In-Reply-To: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> Message-ID: <1442149236.12.0.471481649415.issue25082@psf.upfronthosting.co.za> Changes by Elvis Pranskevichus : ---------- nosy: +Elvis.Pranskevichus _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 15:40:44 2015 From: report at bugs.python.org (Flavio Grossi) Date: Sun, 13 Sep 2015 13:40:44 +0000 Subject: [issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x) Message-ID: <1442151642.39.0.456899707142.issue25084@psf.upfronthosting.co.za> New submission from Flavio Grossi: threading.Condition.wait(timeout=x) is implemented in python 2 as a semi-busy loop which causes cpu wakeups and unexpected cpu use. I think this is somewhat problematic since it causes problems in all modules which use that method, such as Queue.get() when used with a timeout. This issue has been reported and "fixed" in red hat based distributions in a way which i find problematic, as detailed here: https://bugzilla.redhat.com/show_bug.cgi?id=1230802 The attached patch backports the following change from py3 to fix the problem: https://hg.python.org/cpython/rev/01d1fd775d16/ ---------- components: Library (Lib) files: timedlock.patch keywords: patch messages: 250562 nosy: flavio, pitrou priority: normal severity: normal status: open title: remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x) type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file40450/timedlock.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 15:45:45 2015 From: report at bugs.python.org (Wolfgang Langner) Date: Sun, 13 Sep 2015 13:45:45 +0000 Subject: [issue25085] Windows x86-64 embeddable zip file contains test directorys Message-ID: <1442151945.16.0.782887699168.issue25085@psf.upfronthosting.co.za> New submission from Wolfgang Langner: The Windows x86-64 embeddable zip file (and possible the one for 32bit) includes some unnecessary test folders in python35.zip with test scripts. python35.zip\distutils\tests\ python35.zip\unittest\test\ python35.zip\lib2to3\tests\ python35.zip\ctypes\test\ python35.zip\sqlite3\test\ Python Version 3.5 rc4 This is only a minor issue, because it affects only size not functionality. ---------- components: Installation, Windows messages: 250563 nosy: paul.moore, steve.dower, tds333, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows x86-64 embeddable zip file contains test directorys type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 15:51:08 2015 From: report at bugs.python.org (Wolfgang Langner) Date: Sun, 13 Sep 2015 13:51:08 +0000 Subject: [issue25086] Windows x86-64 embeddable zip file, lot of big EXE files in distuils Message-ID: <1442152268.71.0.790140517875.issue25086@psf.upfronthosting.co.za> New submission from Wolfgang Langner: In the Windows x86-64 embeddable zip file in python35.zip\distutils\command\ are a lot of big EXE files. Possible during build for different VC compilers. I don't know the exact structure but thing there should only be EXE's for the actual used compiler to build Python. But there are: wininst-10.0-amd64.exe wininst-10.0.exe wininst-14.0-amd64.exe wininst-14.0.exe wininst-6.0.exe wininst-7.1.exe wininst-8.0.exe wininst-9.0-amd64.exe wininst-9.0.exe These files are really big, and some or all? possible not needed for and embeddable zip distributed Python. ---------- components: Distutils, Installation, Windows messages: 250564 nosy: dstufft, eric.araujo, paul.moore, steve.dower, tds333, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows x86-64 embeddable zip file, lot of big EXE files in distuils type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 15:52:18 2015 From: report at bugs.python.org (Stefan Krah) Date: Sun, 13 Sep 2015 13:52:18 +0000 Subject: [issue25087] Type variable substitution in type instances Message-ID: <1442152338.46.0.937548163334.issue25087@psf.upfronthosting.co.za> New submission from Stefan Krah: If a type scheme is instantiated, should the type variables in the class body be substituted? This is an example (typed by hand on a locked down Windows machine, may contain errors): alpha = TypeVar('alpha') beta = TypeVar('beta') class ABTuple(Generic[alpha, beta]): def __init__(self, a : alpha, b : beta): self.value = (a, b) get_type_hints(ABTuple.__init__) ==> {'b': ~beta, 'a': ~alpha} IntIntTuple = ABTuple[int, int] IntIntTuple ==> __main__.ABTuple[int, int] get_type_hints(IntIntTuple.__init__) {'b': ~beta, 'a': ~alpha} ^^^^^^ ^^^^^^ Since the type has been specialized, these should ideally be 'int'. ---------- components: Interpreter Core messages: 250565 nosy: gvanrossum, skrah priority: normal severity: normal status: open title: Type variable substitution in type instances type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 15:57:35 2015 From: report at bugs.python.org (Florent Gallaire) Date: Sun, 13 Sep 2015 13:57:35 +0000 Subject: [issue24665] CJK support for textwrap In-Reply-To: <1437276510.99.0.116072917153.issue24665@psf.upfronthosting.co.za> Message-ID: <1442152655.14.0.355750393579.issue24665@psf.upfronthosting.co.za> Changes by Florent Gallaire : Added file: http://bugs.python.org/file40451/CJK+fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 16:57:17 2015 From: report at bugs.python.org (Elvis Pranskevichus) Date: Sun, 13 Sep 2015 14:57:17 +0000 Subject: [issue25082] Editing What's New In Python 3.5 In-Reply-To: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> Message-ID: <1442156237.07.0.102963080106.issue25082@psf.upfronthosting.co.za> Elvis Pranskevichus added the comment: Larry, it looks like the "Detailed Release Information" link on the release page still points to rc3, which is a 404 now. Also, there doesn't seem to be a link to the "What's new" document, only a Misc/NEWS link. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 16:59:50 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 13 Sep 2015 14:59:50 +0000 Subject: [issue25082] Editing What's New In Python 3.5 In-Reply-To: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> Message-ID: <1442156390.98.0.789584307349.issue25082@psf.upfronthosting.co.za> Larry Hastings added the comment: The "Detailed Release Information" link is correct. You probably just have an old cached copy of something. I could add a "What's New" link somewhere. Though both of these things are interesting, neither of them is relevant to this issue. Maybe you could jump on IRC and report them in real time? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 17:04:42 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 13 Sep 2015 15:04:42 +0000 Subject: [issue25082] Editing What's New In Python 3.5 In-Reply-To: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> Message-ID: <1442156682.74.0.911747694351.issue25082@psf.upfronthosting.co.za> Stefan Behnel added the comment: Could I get a little note in the collections.abc section that the new ABCs "Generator", "Coroutine" and "Awaitable" are available as backports in the "backports_abc" package on PyPI? https://pypi.python.org/pypi/backports_abc I'd like to prevent others from innocently feeling a needless need to roll their own solution. ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 17:28:54 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 13 Sep 2015 15:28:54 +0000 Subject: [issue25082] Editing What's New In Python 3.5 In-Reply-To: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> Message-ID: <1442158134.7.0.296639477399.issue25082@psf.upfronthosting.co.za> Yury Selivanov added the comment: Larry, Please rebuild the documentation, we've pushed the last round of edits in 746add37495c. Also, could you please merge 3.5 into default -- I don't know how to resolve some conflicts after your 3.5.0 -> 3.5 merge. > I could add a "What's New" link somewhere. Thanks for adding it! Can we make it a bit more prominent by moving it to the top of the page? PEP links are important, but what's new is more digestible. Stefan, I've added a link to your package. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 17:29:48 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 13 Sep 2015 15:29:48 +0000 Subject: [issue25082] Editing What's New In Python 3.5 In-Reply-To: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> Message-ID: <1442158188.36.0.941008305024.issue25082@psf.upfronthosting.co.za> Yury Selivanov added the comment: And can we point https://docs.python.org/3/ to 3.5 docs? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 17:31:01 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 13 Sep 2015 15:31:01 +0000 Subject: [issue25082] Editing What's New In Python 3.5 In-Reply-To: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> Message-ID: <1442158261.25.0.335359897832.issue25082@psf.upfronthosting.co.za> Larry Hastings added the comment: I don't know how to do it. I asked the Documentation Expert member of the Python 3.5 release team, but it seems he's afk at the moment. I'm trying to find someone else who knows how to do it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 17:43:19 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 13 Sep 2015 15:43:19 +0000 Subject: [issue25082] Editing What's New In Python 3.5 In-Reply-To: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> Message-ID: <1442158999.21.0.923282708062.issue25082@psf.upfronthosting.co.za> Stefan Behnel added the comment: Thanks, Yury! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 17:45:05 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 13 Sep 2015 15:45:05 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442159105.11.0.26975811051.issue24965@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +elvis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 17:48:22 2015 From: report at bugs.python.org (Naveen Togar) Date: Sun, 13 Sep 2015 15:48:22 +0000 Subject: [issue25088] scipy (0.16.0) install fails on 3.5 Message-ID: <1442159302.54.0.00542584787984.issue25088@psf.upfronthosting.co.za> New submission from Naveen Togar: SciPy install using pip fails with the following error: Running from scipy source directory. /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/numpy/distutils/system_info.py:594: UserWarning: Specified path /usr/local/include/python3.5m is invalid. warnings.warn('Specified path %s is invalid.' % d) /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/numpy/distutils/system_info.py:594: UserWarning: Specified path /usr/include/python3.5m is invalid. warnings.warn('Specified path %s is invalid.' % d) "object of type 'type' has no len()" in evaluating 'len(list)' (available names: []) "object of type 'type' has no len()" in evaluating 'len(list)' (available names: []) "object of type 'type' has no len()" in evaluating 'len(list)' (available names: []) "object of type 'type' has no len()" in evaluating 'len(list)' (available names: []) "object of type 'type' has no len()" in evaluating 'len(list)' (available names: []) "object of type 'type' has no len()" in evaluating 'len(list)' (available names: []) error: library dfftpack has Fortran sources but no Fortran compiler found ---------------------------------------- Command "/Library/Frameworks/Python.framework/Versions/3.5/bin/python3.5 -c "import setuptools, tokenize;__file__='/private/var/folders/jg/dd63x6c54t9g3qcr2c1xk9680000gn/T/pip-build-kb3aqu9u/scipy/setup.py';exec(compile(getattr(tokenize, 'open', open)(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --record /var/folders/jg/dd63x6c54t9g3qcr2c1xk9680000gn/T/pip-dljex650-record/install-record.txt --single-version-externally-managed --compile" failed with error code 1 in /private/var/folders/jg/dd63x6c54t9g3qcr2c1xk9680000gn/T/pip-build-kb3aqu9u/scipy I didn't have any issues on Python 3.4. I am on OS X Yosemite. ---------- components: Installation messages: 250573 nosy: ntogar priority: normal severity: normal status: open title: scipy (0.16.0) install fails on 3.5 type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 18:20:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Sep 2015 16:20:23 +0000 Subject: [issue25082] Editing What's New In Python 3.5 In-Reply-To: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> Message-ID: <1442161223.27.0.249934479492.issue25082@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: ssl should be between sqlite3 and subprocess. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 19:00:27 2015 From: report at bugs.python.org (Carol Willing) Date: Sun, 13 Sep 2015 17:00:27 +0000 Subject: [issue25088] scipy (0.16.0) install fails on 3.5 In-Reply-To: <1442159302.54.0.00542584787984.issue25088@psf.upfronthosting.co.za> Message-ID: <1442163627.93.0.196550372047.issue25088@psf.upfronthosting.co.za> Carol Willing added the comment: I am unable to pip install scipy, numpy, or pandas using 3.5.0 on OS X 10.10.4. After installing Python 3.5 using the installer downloaded from Python.org page, I created a virtualenv using `pyvenv myscipy` and activated with `source myscipy\bin\activate`. `python -V` returns 3.5.0. `pip install scipy` succeeds in `Collecting scipy` and downloading 100% of file. It hangs after that indication for 1m 21s with no warnings or errors. Cancelled the operation. I tried with scipy, numpy, pandas with no success. I also tried `python -m pip install scipy==0.16` and it also stalled with no warning or errors. `pip search` and `pip install flask` worked fine in the 3.5 virtualenv. ---------- nosy: +willingc priority: normal -> high stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 19:12:41 2015 From: report at bugs.python.org (Naveen Togar) Date: Sun, 13 Sep 2015 17:12:41 +0000 Subject: [issue25088] scipy (0.16.0) install fails on 3.5 In-Reply-To: <1442159302.54.0.00542584787984.issue25088@psf.upfronthosting.co.za> Message-ID: <1442164361.7.0.579559416893.issue25088@psf.upfronthosting.co.za> Naveen Togar added the comment: I didn't have any issues with either numpy or pandas. I just tried installing matplotlib and that failed too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 19:13:37 2015 From: report at bugs.python.org (desbma) Date: Sun, 13 Sep 2015 17:13:37 +0000 Subject: [issue25061] Add native enum support for argparse In-Reply-To: <1441908245.42.0.23532628335.issue25061@psf.upfronthosting.co.za> Message-ID: <1442164417.61.0.511762807963.issue25061@psf.upfronthosting.co.za> desbma added the comment: I would like the enum type to be stored directly. With your approach, the user does not know what are the possible choices, until he/she tries a invalid value and get the exception. If I pass the enum type to the choice parameter, the help message is not very user friendly (""...) and does not accurately represent possible input strings. Anyway, my first example snippet works and does what I need, but it feels a bit like a hack. In my opinion this is a classic use case for enums, that should be handled more naturally by the argparse module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 19:18:00 2015 From: report at bugs.python.org (desbma) Date: Sun, 13 Sep 2015 17:18:00 +0000 Subject: [issue25063] shutil.copyfileobj should internally use os.sendfile when possible In-Reply-To: <1441910330.09.0.484556764779.issue25063@psf.upfronthosting.co.za> Message-ID: <1442164680.41.0.014274463486.issue25063@psf.upfronthosting.co.za> desbma added the comment: If I understand you correctly, a naive implementation like this: use_chunk_copy = False try: fdsrc = fsrc.fileno() fddst = fdst.fileno() except OSError: # fallback on current chunk based Python copy use_chunk_copy = True else: # we have 2 fd, try sendfile try: os.sendfile(fdsrc, fddst) except AttributeError: # sendfile not available use_chunk_copy = True if use_chunk_copy: # use current Python based chunk copy ...would not work because some file like objects expose fileno(), even though it does not accurately represent the file because they wrap it to add special behavior (like GzipFile). I don't understand, if they alter the file behavior, why do they expose fileno()? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 19:34:37 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 13 Sep 2015 17:34:37 +0000 Subject: [issue25082] Editing What's New In Python 3.5 In-Reply-To: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> Message-ID: <1442165677.4.0.517056398987.issue25082@psf.upfronthosting.co.za> Yury Selivanov added the comment: > ssl should be between sqlite3 and subprocess. It makes sense that ssl module description follows the socket module. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 19:40:16 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sun, 13 Sep 2015 17:40:16 +0000 Subject: [issue25087] Type variable substitution in type instances In-Reply-To: <1442152338.46.0.937548163334.issue25087@psf.upfronthosting.co.za> Message-ID: <1442166016.12.0.922497067089.issue25087@psf.upfronthosting.co.za> Guido van Rossum added the comment: Good question. Let's discuss this in the type hinting / pep 484 tracker: https://github.com/ambv/typehinting/issues/156 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 19:50:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 13 Sep 2015 17:50:12 +0000 Subject: [issue25082] Editing What's New In Python 3.5 In-Reply-To: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> Message-ID: <1442166612.67.0.738853051501.issue25082@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Many thanks to Yury and Elvis for your work on What's New. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 20:32:16 2015 From: report at bugs.python.org (Carol Willing) Date: Sun, 13 Sep 2015 18:32:16 +0000 Subject: [issue25088] scipy (0.16.0) install fails on 3.5 In-Reply-To: <1442159302.54.0.00542584787984.issue25088@psf.upfronthosting.co.za> Message-ID: <1442169136.27.0.772272513368.issue25088@psf.upfronthosting.co.za> Carol Willing added the comment: Naveen, I was able to resolve this problem for installation by installing gfortran using the instructions here: http://hpc.sourceforge.net/ After gfortran is successfully installed, I was able to ``pip install scipy -v`` the libraries that depend on gfortran. It did take 8m 39s to execute the install of scipy which is why I used the -v (verbose) option so that I could see that it was still working. It would be good for numpy and scipy to indicate more clearly the absence or inability to find gfortran with a more obvious error message. My recommendation is to close this issue if you are able to successfully install. ---------- priority: high -> normal stage: needs patch -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 21:03:08 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 13 Sep 2015 19:03:08 +0000 Subject: [issue25082] Editing What's New In Python 3.5 In-Reply-To: <1442126549.39.0.8000328932.issue25082@psf.upfronthosting.co.za> Message-ID: <1442170988.42.0.857761057578.issue25082@psf.upfronthosting.co.za> Yury Selivanov added the comment: Thanks, Serhiy! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 22:03:16 2015 From: report at bugs.python.org (paul j3) Date: Sun, 13 Sep 2015 20:03:16 +0000 Subject: [issue25061] Add native enum support for argparse In-Reply-To: <1441908245.42.0.23532628335.issue25061@psf.upfronthosting.co.za> Message-ID: <1442174596.82.0.95873424982.issue25061@psf.upfronthosting.co.za> paul j3 added the comment: I'm not quite sure what you mean by 'the enum type to be stored directly'. With my type function, the string input is converted to an enum object and that is stored in the Namespace. You can't be any more direct than that. Or are you thinking that `argparse` has some catalog of 'types' that it uses to check for value validity and conversion? There isn't such a collection. The value of the 'type' parameter has to be a callable. (There is a registry mechanism, but that just maps strings on to callables.) My suggestion does not provide help, but that isn't hard to write that for yourself. A help parameter like: help='Enum: {%s}'%','.join([t.name for t in CustomEnumType]) would display: usage: ipython3 [-h] [-p P] optional arguments: -h, --help show this help message and exit -p P Enum: {VAL1,VAL2,VAL3} For really long lists you could write a multiline help and display it with a RAW formatter. I wouldn't use 'choices' with a type function like this. The type function takes care of all the necessary testing and error messaging. As you write, displaying the enum values would just be confusing. If we define a dictionary wrapper for the enum class, the use of 'choices' might not seem so hacky: enumDict = {t.name.lower():t for t in CustomEnumType} parser.add_argument("-q", default="val1", choices=enumDict) parser.print_help() producing: usage: ipython3 [-h] [-p P] [-q {val1,val3,val2}] optional arguments: -h, --help show this help message and exit -p P Enum: {VAL1,VAL2,VAL3} -q {val1,val3,val2} The keys of a 'choices' dictionary are used automatically in the usage and help. That's nice when there are a few choices, but not so good when there are many. Those problems have been discussed in other bug issues. This dictionary can be used just like your code to convert the Namespace string to an enum object: In [57]: parser.parse_args([]) Out[57]: Namespace(p=, q='val1') In [58]: enumDict[_.q] Out[58]: And of course 'choices' handles the error listing as well - a plus or minus: In [59]: parser.parse_args(['-q','test']) usage: ipython3 [-h] [-p P] [-q {val1,val3,val2}] ipython3: error: argument -q: invalid choice: 'test' (choose from 'val1', 'val3', 'val2') ... If we are going add anything to streamline the handling of 'enums', it should also streamline the handling of any mapping. The main thing that 'enums' adds to Python is a uniqueness constraint - which is an insignificant issue in the argparse context. My custom type function would work just as well with a dictionary. And a dictionary would allow the use of aliases, as well as the upper/lower tweaking. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 22:22:19 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 13 Sep 2015 20:22:19 +0000 Subject: [issue25063] shutil.copyfileobj should internally use os.sendfile when possible In-Reply-To: <1441910330.09.0.484556764779.issue25063@psf.upfronthosting.co.za> Message-ID: <1442175739.47.0.320786923527.issue25063@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 22:32:20 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 13 Sep 2015 20:32:20 +0000 Subject: [issue25088] scipy (0.16.0) install fails on 3.5 In-Reply-To: <1442159302.54.0.00542584787984.issue25088@psf.upfronthosting.co.za> Message-ID: <1442176340.93.0.0848692096412.issue25088@psf.upfronthosting.co.za> Ned Deily added the comment: For 3.4 and 2.7, the SciPy and matplotlib projects supply pre-compiled wheels for their distributions. As of this moment, they haven't yet updated their PyPI entries with 3.5 wheels (.whl files). Until they do, pip would fall back to trying to build them from source, which as Carol points out, will likely require installing additional non-Apple build tools, like gfortran. Suggest you check on the mailing lists or other support forums for the SciPy and matplotlib projects to see when each expects to have OS X wheels available for 3.5. I'd guess it won't be long since both are popular downloads. ---------- nosy: +ned.deily resolution: -> third party stage: test needed -> resolved status: open -> closed type: compile error -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 22:50:40 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 13 Sep 2015 20:50:40 +0000 Subject: [issue25063] shutil.copyfileobj should internally use os.sendfile when possible In-Reply-To: <1441910330.09.0.484556764779.issue25063@psf.upfronthosting.co.za> Message-ID: <1442177440.7.0.431828028477.issue25063@psf.upfronthosting.co.za> Martin Panter added the comment: I don?t know the exact reasoning, but fileno() could be useful for other purposes, e.g. passing to stat() to find the last modification time, passing to select() to see if data is available. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 13 23:42:11 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 13 Sep 2015 21:42:11 +0000 Subject: [issue25078] Document InstallAllUsers installer parameter default 0 In-Reply-To: <1442051204.9.0.216289255081.issue25078@psf.upfronthosting.co.za> Message-ID: <20150913214207.68857.7176@psf.io> Roundup Robot added the comment: New changeset 399b7d5616f1 by Steve Dower in branch '3.5': Closes #25078: Document InstallAllUsers installer parameter default 0 https://hg.python.org/cpython/rev/399b7d5616f1 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 00:44:57 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 13 Sep 2015 22:44:57 +0000 Subject: [issue25089] Can't run Python Launcher on Windows Message-ID: <1442184297.36.0.379341480925.issue25089@psf.upfronthosting.co.za> New submission from Mark Lawrence: I first asked a few days ago, see this thread http://www.gossamer-threads.com/lists/python/python/1216917. You can work around it by running "repair" but it takes an age to run for what, to me anyway, is a minor irritant. ---------- components: Windows messages: 250588 nosy: BreamoreBoy, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Can't run Python Launcher on Windows type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 01:44:39 2015 From: report at bugs.python.org (Mark Roseman) Date: Sun, 13 Sep 2015 23:44:39 +0000 Subject: [issue25090] IDLE: alternative to class browser / code context Message-ID: <1442187879.71.0.781728346587.issue25090@psf.upfronthosting.co.za> New submission from Mark Roseman: Proposal for an alternative or perhaps replacement of both the code context extension, as well as the class browser (rooted at a particular file, not the path browser). I'll direct your attention to the attached browser.png. On the right is IDLE's class browser window of ClassBrowser.py. On the left, I've got the same file loaded into TextMate. In the TextMate status bar, it shows you where you're currently located (here, in the __init__ function). When you click on that part of the status bar, it brings up a scrollable menu showing the structure of the file. I think it's easier to read than IDLE's, despite having more information (description of the parameters), thanks to reduction in 'chart junk'. Downside of this approach is that you can't have a window along the side so you can navigate the code while seeing the class display. Though that might best be achieved if IDLE added a sidebar, rather than a true separate window. ---------- components: IDLE files: browser.png messages: 250589 nosy: kbk, markroseman, roger.serwy, terry.reedy priority: normal severity: normal status: open title: IDLE: alternative to class browser / code context type: enhancement versions: Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40452/browser.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 02:14:44 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 14 Sep 2015 00:14:44 +0000 Subject: [issue25090] IDLE: alternative to class browser / code context In-Reply-To: <1442187879.71.0.781728346587.issue25090@psf.upfronthosting.co.za> Message-ID: <1442189684.35.0.382038404699.issue25090@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I don't see anything that replaces Code Context. That extension is priceless for people editing classes and methods that extend more than one screen. ISTM, there are too many sweeping change proposals that seem to base on general look and feel but disregard how people actually use these tools. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 02:15:22 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Sep 2015 00:15:22 +0000 Subject: [issue25089] Can't run Python Launcher on Windows In-Reply-To: <1442184297.36.0.379341480925.issue25089@psf.upfronthosting.co.za> Message-ID: <1442189722.74.0.543982192556.issue25089@psf.upfronthosting.co.za> Steve Dower added the comment: I don't understand what you did and what the result was from that thread. * What options did you select when installing 3.5? * What other Python versions did you have? What options were used to install them? * Where was py.exe before installing 3.5? * Can you attach all of the logs from your 3.5 install (from your %TEMP%)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 03:29:52 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 14 Sep 2015 01:29:52 +0000 Subject: [issue25089] Can't run Python Launcher on Windows In-Reply-To: <1442184297.36.0.379341480925.issue25089@psf.upfronthosting.co.za> Message-ID: <1442194192.48.0.777020867764.issue25089@psf.upfronthosting.co.za> Terry J. Reedy added the comment: For anyone else reading this, Mark says he already re-tried with 3.5.0. The only problem I had with the install on my Win7, with 2.7.10, 3.4.3, and 3.5.0rc3 already present, is that 3.4.3 is still the default python (started by 'python') in spite of checking everything relevant when installing 3.5.0. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 03:37:45 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 14 Sep 2015 01:37:45 +0000 Subject: [issue25091] Please revert the Windows Installer to micro type. Message-ID: <1442194665.29.0.878710305111.issue25091@psf.upfronthosting.co.za> New submission from Terry J. Reedy: The 3.4.3 installer used normal size type (10 point, I believe) in the dialog boxes. I can more or less read this with by non 20/20 eyes. The new 3.5.0 installer uses a smaller type (8? 7? point), which for even more people will mean using a magnifier. Please revert this anti-accessibility change. Instead, increase to 12 point if possible. I noticed that the Python logo picture is also shrunken by about 20%. I checked side-by-side with the 3.4.3 box, so all system settings were the same for both. ---------- components: Installation, Windows messages: 250593 nosy: paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware priority: normal severity: normal status: open title: Please revert the Windows Installer to micro type. versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 03:40:33 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 14 Sep 2015 01:40:33 +0000 Subject: [issue25091] Please revert the Windows Installer swithch to micro type. In-Reply-To: <1442194665.29.0.878710305111.issue25091@psf.upfronthosting.co.za> Message-ID: <1442194833.91.0.729139530388.issue25091@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- title: Please revert the Windows Installer to micro type. -> Please revert the Windows Installer swithch to micro type. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 04:22:47 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 14 Sep 2015 02:22:47 +0000 Subject: [issue6691] Support for nested classes and function for pyclbr In-Reply-To: <1250117262.14.0.353515413158.issue6691@psf.upfronthosting.co.za> Message-ID: <1442197367.36.0.661673222043.issue6691@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- type: -> enhancement versions: +Python 3.6 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 04:27:47 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Sep 2015 02:27:47 +0000 Subject: [issue25089] Can't run Python Launcher on Windows In-Reply-To: <1442184297.36.0.379341480925.issue25089@psf.upfronthosting.co.za> Message-ID: <1442197667.54.0.678803438452.issue25089@psf.upfronthosting.co.za> Steve Dower added the comment: Yeah, it's basically impossible to manage PATH automatically. You've probably installed 3.5 just for yourself while 3.4 is installed for all users. In this case, 3.5 will always lose because Windows puts user paths after system paths. You could modify 3.4 to remove it from PATH or use py.exe, which resolves versions correctly. Or you can modify your PATH manually. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 04:29:08 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Sep 2015 02:29:08 +0000 Subject: [issue25091] Windows Installer uses small font In-Reply-To: <1442194665.29.0.878710305111.issue25091@psf.upfronthosting.co.za> Message-ID: <1442197748.11.0.114194834126.issue25091@psf.upfronthosting.co.za> Steve Dower added the comment: Thanks for pointing this out. I'll take a look before 3.5.1. ---------- title: Please revert the Windows Installer swithch to micro type. -> Windows Installer uses small font _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 04:29:36 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 14 Sep 2015 02:29:36 +0000 Subject: [issue1612262] Class Browser doesn't show internal classes Message-ID: <1442197776.83.0.346744436187.issue1612262@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Class Browser is now a module browser as it includes functions not in classes. I guess pyclbr does this. Enhancing this for current versions would require adding a private copy of enhanced pyclbr to idlelib. ---------- nosy: +terry.reedy priority: low -> normal versions: +Python 2.7, Python 3.5, Python 3.6 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 04:31:31 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Sep 2015 02:31:31 +0000 Subject: [issue25091] Windows Installer uses small font In-Reply-To: <1442194665.29.0.878710305111.issue25091@psf.upfronthosting.co.za> Message-ID: <1442197891.44.0.307932475951.issue25091@psf.upfronthosting.co.za> Steve Dower added the comment: Actually, what DPI setting are you using? With new UI, it's possible that we're not scaling the same way as before. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 04:43:00 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 14 Sep 2015 02:43:00 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442198580.25.0.346158237509.issue24965@psf.upfronthosting.co.za> Martin Panter added the comment: Regarding the null terminator, I was mainly smoke testing your code. :) Maybe it would be too hard to support properly. Although I could imagine someone doing things like this: >>> d = {b"key\x00": "value"} >>> f"key={d[b'key\x00']}" # Oops, escape code at wrong level File "", line 1 (d[b'key ^ SyntaxError: EOL while scanning string literal >>> rf"key={d[b'key\x00']}" # Corrected 'key=value' I also finished quickly reading over the C code, with a couple more review comments. But I am not familiar with the files involved to thoroughly review. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 04:46:51 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 14 Sep 2015 02:46:51 +0000 Subject: [issue25090] IDLE: remove noisy icons from class (module) browser In-Reply-To: <1442187879.71.0.781728346587.issue25090@psf.upfronthosting.co.za> Message-ID: <1442198811.79.0.0139491085857.issue25090@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Adding function arguments to the module browser, misnamed Class Browser, is #20827. That leaves removing the noisy icons from class and def entries (where they do not fit anyway), as the concrete appearance change proposal here. Better to use the space for arguments. Adding nested classes is #1612262 (9 years ago). I just noticed that there is a 6 year old patch that needs to be reviewed. The TextMate box has a checkmark at the current location. Having an editor know about an attached module browser and inform it of the cursor's location would be a separate issue. It would be relatively easy when code context is active. But nested classes and functions cannot be marked until they are displayed. A module browser, even enhanced to display nested classes and functions, could not replace code context since the latter includes nested compound statements within functions. I think code context would be even more useful if it were to display the complete context, using as many lines as needed, instead of some fixed number. But I have not written a patch yet or opened an issue. ---------- title: IDLE: alternative to class browser / code context -> IDLE: remove noisy icons from class (module) browser _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 04:54:18 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 14 Sep 2015 02:54:18 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 Message-ID: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> New submission from Terry J. Reedy: PS C:\Users\Terry> py -3 -m test test_datetime [1/1] test_datetime test test_datetime failed -- Traceback (most recent call last): File "C:\Programs\Python 3.5\lib\test\datetimetester.py", line 1154, in test_strftime self.assertEqual(t.strftime(""), "") # SF bug #761337 ValueError: Invalid format string Same result 3 times. ---------- components: Library (Lib) messages: 250600 nosy: belopolsky, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Regression: test_datetime fails on 3.5, Win 7, works on 3.4 type: behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 05:11:33 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 14 Sep 2015 03:11:33 +0000 Subject: [issue12420] distutils tests fail if PATH is not defined In-Reply-To: <1309177997.74.0.17903211546.issue12420@psf.upfronthosting.co.za> Message-ID: <1442200293.75.0.305107423087.issue12420@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The following failures on new 3.5.0 seems related as they all end with the same message about vcvarsall.bat (slightly different from 3.4 failures). ====================================================================== ERROR: test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase) ---------------------------------------------------------------------- ====================================================================== ERROR: test_optional_extension (distutils.tests.test_build_ext.BuildExtTestCase) ---------------------------------------------------------------------- ====================================================================== ERROR: test_get_outputs (distutils.tests.test_build_ext.ParallelBuildExtTestCase) ---------------------------------------------------------------------- ====================================================================== ERROR: test_optional_extension (distutils.tests.test_build_ext.ParallelBuildExtTestCase) ---------------------------------------------------------------------- ====================================================================== ERROR: test_compiler_options (distutils.tests.test_msvccompiler.msvccompilerTestCase) ---------------------------------------------------------------------- ====================================================================== ERROR: test_vcruntime_copy (distutils.tests.test_msvccompiler.msvccompilerTestCase) ---------------------------------------------------------------------- ====================================================================== ERROR: test_vcruntime_skip_copy (distutils.tests.test_msvccompiler.msvccompilerTestCase) ---------------------------------------------------------------------- ====================================================================== FAIL: test_customize_compiler_before_get_config_vars (distutils.tests.test_sysconfig.SysconfigTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Programs\Python 3.5\lib\distutils\tests\test_sysconfig.py", line 197, in test_customize_compiler_before_get_c onfig_vars self.assertEqual(0, p.returncode, "Subprocess failed: " + outs) AssertionError: 0 != 1 : Subprocess failed: Traceback (most recent call last): File "@test_5504_tmp", line 5, in rc = config.try_compile('int x;') File "C:\Programs\Python 3.5\lib\distutils\command\config.py", line 227, in try_compile self._compile(body, headers, include_dirs, lang) File "C:\Programs\Python 3.5\lib\distutils\command\config.py", line 133, in _compile self.compiler.compile([src], include_dirs=include_dirs) File "C:\Programs\Python 3.5\lib\distutils\_msvccompiler.py", line 315, in compile self.initialize() File "C:\Programs\Python 3.5\lib\distutils\_msvccompiler.py", line 208, in initialize vc_env = _get_vc_env(plat_spec) File "C:\Programs\Python 3.5\lib\distutils\_msvccompiler.py", line 83, in _get_vc_env raise DistutilsPlatformError("Unable to find vcvarsall.bat") distutils.errors.DistutilsPlatformError: Unable to find vcvarsall.bat ---------------------------------------------------------------------- Ran 234 tests in 1.108s FAILED (failures=1, errors=7, skipped=28) Warning -- threading._dangling was modified by test_distutils Warning -- files was modified by test_distutils ---------- nosy: +steve.dower, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 05:17:19 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 14 Sep 2015 03:17:19 +0000 Subject: [issue25093] New 3.5.0 failure in test_tcl on win7 Message-ID: <1442200639.15.0.127298727385.issue25093@psf.upfronthosting.co.za> New submission from Terry J. Reedy: [324/397/3] test_tcl '\\TEJAREX\C$\Programs\Python' is not recognized as an internal or external command, operable program or batch file. test test_tcl failed -- Traceback (most recent call last): File "C:\Programs\Python 3.5\lib\test\test_tcl.py", line 247, in testLoadWithUNC self.assertIn('tkinter', f.read()) AssertionError: 'tkinter' not found in '' I am pretty sure test ran fine in .0rc about a month ago, as it does in 3.4.3. ---------- components: Tkinter, Windows messages: 250602 nosy: paul.moore, serhiy.storchaka, steve.dower, terry.reedy, tim.golden, zach.ware priority: normal severity: normal status: open title: New 3.5.0 failure in test_tcl on win7 type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 05:42:58 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 14 Sep 2015 03:42:58 +0000 Subject: [issue25094] Test_tools not working on Windows. Message-ID: <1442202178.75.0.918340459191.issue25094@psf.upfronthosting.co.za> New submission from Terry J. Reedy: When run at part of test suite on 3.5.0 (win7) [341/397/4] test_tools Usage: 2to3 [options] file|dir ... regrtest.py: error: no such option: --slaveargs test test_tools failed -- Traceback (most recent call last): File "C:\Programs\Python 3.5\lib\optparse.py", line 1386, in parse_args stop = self._process_args(largs, rargs, values) File "C:\Programs\Python 3.5\lib\optparse.py", line 1426, in _process_args self._process_long_opt(rargs, values) File "C:\Programs\Python 3.5\lib\optparse.py", line 1479, in _process_long_opt opt = self._match_long_opt(opt) File "C:\Programs\Python 3.5\lib\optparse.py", line 1464, in _match_long_opt return _match_abbrev(opt, self._long_opt) File "C:\Programs\Python 3.5\lib\optparse.py", line 1669, in _match_abbrev raise BadOptionError(s) optparse.BadOptionError: no such option: --slaveargs During handling of the above exception, another exception occurred: Traceback (most recent call last): File "C:\Programs\Python 3.5\lib\test\test_tools\test_sundry.py", line 36, in test_sundry import_tool(name) File "C:\Programs\Python 3.5\lib\test\test_tools\__init__.py", line 22, in import_tool return importlib.import_module(toolname) File "C:\Programs\Python 3.5\lib\importlib\__init__.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 986, in _gcd_import File "", line 969, in _find_and_load File "", line 958, in _find_and_load_unlocked File "", line 673, in _load_unlocked File "", line 662, in exec_module File "", line 222, in _call_with_frames_removed File "C:\Programs\Python 3.5\Tools\scripts\2to3.py", line 5, in sys.exit(main("lib2to3.fixes")) File "C:\Programs\Python 3.5\lib\lib2to3\main.py", line 179, in main options, args = parser.parse_args(args) File "C:\Programs\Python 3.5\lib\optparse.py", line 1388, in parse_args self.error(str(err)) File "C:\Programs\Python 3.5\lib\optparse.py", line 1568, in error self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg)) File "C:\Programs\Python 3.5\lib\optparse.py", line 1558, in exit sys.exit(status) SystemExit: 2 run by itselt (-m test test_tools) PS C:\Users\Terry> py -3 -m test test_tools [1/1] test_tools RefactoringTool: Skipping optional fixer: buffer RefactoringTool: Skipping optional fixer: idioms RefactoringTool: Skipping optional fixer: set_literal RefactoringTool: Skipping optional fixer: ws_comma RefactoringTool: Can't open test_tools: [Errno 2] No such file or directory: 'test_tools' RefactoringTool: No files need to be modified. RefactoringTool: There was 1 error: RefactoringTool: Can't open test_tools: [Errno 2] No such file or directory: 'test_tools' Warning -- logging._handlerList was modified by test_tools test test_tools failed -- Traceback (most recent call last): File "C:\Programs\Python 3.5\lib\test\test_tools\test_sundry.py", line 36, in test_sundry import_tool(name) File "C:\Programs\Python 3.5\lib\test\test_tools\__init__.py", line 22, in import_tool return importlib.import_module(toolname) File "C:\Programs\Python 3.5\lib\importlib\__init__.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 986, in _gcd_import File "", line 969, in _find_and_load File "", line 958, in _find_and_load_unlocked File "", line 673, in _load_unlocked File "", line 662, in exec_module File "", line 222, in _call_with_frames_removed File "C:\Programs\Python 3.5\Tools\scripts\2to3.py", line 5, in sys.exit(main("lib2to3.fixes")) SystemExit: 1 With 3.4.3, shorter message about multiple errors ---------- messages: 250603 nosy: terry.reedy priority: normal severity: normal status: open title: Test_tools not working on Windows. type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 05:52:03 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 14 Sep 2015 03:52:03 +0000 Subject: [issue25089] Can't run Python Launcher on Windows In-Reply-To: <1442184297.36.0.379341480925.issue25089@psf.upfronthosting.co.za> Message-ID: <1442202723.78.0.416565410403.issue25089@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I did installed 3.5 for all users. Logging into another user and back changed 'python' association. So ok now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 05:52:07 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Sep 2015 03:52:07 +0000 Subject: [issue25093] New 3.5.0 failure in test_tcl on win7 In-Reply-To: <1442200639.15.0.127298727385.issue25093@psf.upfronthosting.co.za> Message-ID: <1442202727.89.0.931199265416.issue25093@psf.upfronthosting.co.za> Zachary Ware added the comment: Looks like an issue with a space in the path. That test has been flaky in the past, though, I assume it's failed multiple times? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 05:56:33 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 14 Sep 2015 03:56:33 +0000 Subject: [issue25095] test_httpservers hangs on 3.5.0, win 7 Message-ID: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za> New submission from Terry J. Reedy: test_httpservers ok on 3.4.3, hangs indefinitely (over an hour) on 3.5.0, win 7. ---------- components: Library (Lib), Tests, Windows messages: 250606 nosy: paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware priority: normal severity: normal status: open title: test_httpservers hangs on 3.5.0, win 7 type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 06:00:07 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 14 Sep 2015 04:00:07 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442203207.86.0.770077571784.issue25092@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Looks like something related to issue 24917. ---------- nosy: +JohnLeitch, steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 06:06:25 2015 From: report at bugs.python.org (Felix Yan) Date: Mon, 14 Sep 2015 04:06:25 +0000 Subject: [issue25096] test_gdb failed to read version for gdb >= 7.10 Message-ID: <1442203585.89.0.599357729495.issue25096@psf.upfronthosting.co.za> New submission from Felix Yan: The regex in test_gdb reads only one digit of gdb's minor version, which would fail for gdb >= 7.10, and skip the test as 7.1 < 7.4. Original commit: https://hg.python.org/cpython/rev/b71cda2f48c6#l1.9 Patch attached. ---------- components: Tests files: test_gdb-version-fix.patch keywords: patch messages: 250608 nosy: felixonmars priority: normal severity: normal status: open title: test_gdb failed to read version for gdb >= 7.10 type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file40453/test_gdb-version-fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 06:07:14 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 14 Sep 2015 04:07:14 +0000 Subject: [issue25093] New 3.5.0 failure in test_tcl on win7 In-Reply-To: <1442200639.15.0.127298727385.issue25093@psf.upfronthosting.co.za> Message-ID: <1442203634.84.0.0703888467245.issue25093@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I tried more that once before submitting. That directory was a mistake. I since reinstalled 3.5.0 to put it in \Python35 (no space, ) and it works. Does it fail dependable in 'Program Files'? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 06:09:19 2015 From: report at bugs.python.org (John Leitch) Date: Mon, 14 Sep 2015 04:09:19 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442203759.12.0.210300609077.issue25092@psf.upfronthosting.co.za> Changes by John Leitch : ---------- nosy: +brycedarling _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 06:21:07 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Sep 2015 04:21:07 +0000 Subject: [issue25097] test_logging may fail with 'Access is denied' when pywin32 is installed Message-ID: <1442204467.58.0.479620846783.issue25097@psf.upfronthosting.co.za> New submission from Zachary Ware: With an installed Python with pywin32 installed, running the test as a non-privileged user: ====================================================================== ERROR: test_basic (test.test_logging.NTEventLogHandlerTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python34\lib\test\test_logging.py", line 4108, in test_basic h = logging.handlers.NTEventLogHandler('test_logging') File "C:\Python34\lib\logging\handlers.py", line 1011, in __init__ self._welu.AddSourceToRegistry(appname, dllname, logtype) File "C:\Python34\lib\site-packages\win32\lib\win32evtlogutil.py", line 35, in AddSourceToRegistry "SYSTEM\\CurrentControlSet\\Services\\EventLog\\%s\\%s" % (eventLogType, appName)) pywintypes.error: (5, 'RegCreateKey', 'Access is denied.') The test should skip in the case of 'Access is denied'. Assumed to affect 2.7 and up, but haven't checked anything but 3.4. ---------- components: Library (Lib), Windows keywords: easy messages: 250610 nosy: paul.moore, steve.dower, tim.golden, vinay.sajip, zach.ware priority: normal severity: normal stage: needs patch status: open title: test_logging may fail with 'Access is denied' when pywin32 is installed type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 06:22:20 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 14 Sep 2015 04:22:20 +0000 Subject: [issue25089] Can't run Python Launcher on Windows In-Reply-To: <1442184297.36.0.379341480925.issue25089@psf.upfronthosting.co.za> Message-ID: <1442204540.84.0.922772910012.issue25089@psf.upfronthosting.co.za> Mark Lawrence added the comment: I install for all users, don't put Python on the PATH, other than that I think everything is selected. I've 2.6, 2.7. 3.3 and 3.4. I had 3.5.0rc4 and upgraded the existing installation to 3.5.0 full release. I've no idea where py.exe was, but it is now in C:\Windows. This is what I expect having just read PEP397. Do you really want all logs from the 3.5.0 install and the repair, that's 21 files? It's an odd number as there is no log file for the launcher in the install but there is in the repair. The same is true for the rc4 logs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 06:23:55 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Sep 2015 04:23:55 +0000 Subject: [issue25098] test_uuid fails with pywin32 installed Message-ID: <1442204635.01.0.244240422269.issue25098@psf.upfronthosting.co.za> New submission from Zachary Ware: With installed Python with pywin32 installed: ====================================================================== ERROR: test_netbios_getnode (test.test_uuid.TestInternals) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Python34\lib\test\test_uuid.py", line 479, in test_netbios_getnode node = uuid._netbios_getnode() File "C:\Python34\lib\uuid.py", line 432, in _netbios_getnode adapters._pack() File "C:\Python34\lib\site-packages\win32\lib\netbios.py", line 219, in _pack self._buffer_[:] = struct.pack(*(self._format,) + tuple(vals)) struct.error: argument for 's' must be a bytes object Assumed to affect all 3.x versions, but only confirmed on 3.4. ---------- components: Library (Lib), Windows messages: 250612 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: test_uuid fails with pywin32 installed type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 06:28:40 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 14 Sep 2015 04:28:40 +0000 Subject: [issue12420] distutils tests fail if PATH is not defined In-Reply-To: <1309177997.74.0.17903211546.issue12420@psf.upfronthosting.co.za> Message-ID: <1442204920.45.0.959035511951.issue12420@psf.upfronthosting.co.za> Mark Lawrence added the comment: "Unable to find vcvarsall.bat" is raised when Visual Studio isn't installed or it's the incorrect version, so I don't believe these are the same at all. ---------- components: -Distutils2 nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 06:32:53 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Sep 2015 04:32:53 +0000 Subject: [issue25099] test_compileall fails when run by unprivileged user on installed Python Message-ID: <1442205173.06.0.618332067063.issue25099@psf.upfronthosting.co.za> New submission from Zachary Ware: ====================================================================== FAIL: test_no_args_respects_force_flag (test.test_compileall.CommandLineTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Program Files\Python 3.5\lib\test\test_compileall.py", line 229, in test_no_args_respects_force_flag self.assertRunOK('-f', PYTHONPATH=self.directory) File "C:\Program Files\Python 3.5\lib\test\test_compileall.py", line 179, in assertRunOK *self._get_run_args(args), **env_vars) File "C:\Program Files\Python 3.5\lib\test\support\script_helper.py", line 135, in assert_python_ok return _assert_python(True, *args, **env_vars) File "C:\Program Files\Python 3.5\lib\test\support\script_helper.py", line 121, in _assert_python err)) AssertionError: Process return code is 1 command line: ['C:\\Program Files\\Python 3.5\\python.exe', '-X', 'faulthandler', '-S', '-m', 'compileall', '-f'] stdout: --- (... truncated stdout ...)rror: [Errno 13] Permission denied: 'C:\\Program Files\\Python 3.5\\lib\\__pycache__\\sre_compile.cpython-35.pyc.978608563184' Compiling 'C:\\Program Files\\Python 3.5\\lib\\sre_constants.py'... No such problem on installed 3.4.3. ---------- components: Tests, Windows messages: 250614 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: test_compileall fails when run by unprivileged user on installed Python type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 06:34:34 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Sep 2015 04:34:34 +0000 Subject: [issue12420] distutils tests fail if PATH is not defined In-Reply-To: <1309177997.74.0.17903211546.issue12420@psf.upfronthosting.co.za> Message-ID: <1442205274.7.0.177878067717.issue12420@psf.upfronthosting.co.za> Zachary Ware added the comment: Agreed with Mark; I don't see anywhere that lack of PATH would affect the failures you're seeing, Terry. Do you have VS2015 installed? If not, the failure of distutils to skip the tests that need it should be raised as a separate issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 06:38:16 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Sep 2015 04:38:16 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442205496.07.0.276199798601.issue25092@psf.upfronthosting.co.za> Zachary Ware added the comment: I can reproduce. I'm bewildered as to why none of the buildbots are complaining about this. ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 06:42:06 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 14 Sep 2015 04:42:06 +0000 Subject: [issue25083] Python can sometimes create incorrect .pyc files In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za> Message-ID: <1442205726.37.0.343876242329.issue25083@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Inspecting the 2.7 code: https://hg.python.org/cpython/file/2.7/Python/import.c#l761 following that down to https://hg.python.org/cpython/file/2.7/Python/marshal.c#l1126 it looks like it does the right thing on EOF error (from either getc or from fread) and raises an exception which aborts load_compiled_module. ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 06:42:12 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Sep 2015 04:42:12 +0000 Subject: [issue25094] Test_tools not working on Windows. In-Reply-To: <1442202178.75.0.918340459191.issue25094@psf.upfronthosting.co.za> Message-ID: <1442205732.17.0.298695756916.issue25094@psf.upfronthosting.co.za> Zachary Ware added the comment: Interesting, I got a different failure on 3.5.0: ====================================================================== ERROR: test_sundry (test.test_tools.test_sundry.TestSundryScripts) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Program Files\Python 3.5\lib\optparse.py", line 1386, in parse_args stop = self._process_args(largs, rargs, values) File "C:\Program Files\Python 3.5\lib\optparse.py", line 1430, in _process_args self._process_short_opts(rargs, values) File "C:\Program Files\Python 3.5\lib\optparse.py", line 1512, in _process_short_opts raise BadOptionError(opt) optparse.BadOptionError: no such option: -u During handling of the above exception, another exception occurred: Traceback (most recent call last): File "C:\Program Files\Python 3.5\lib\test\test_tools\test_sundry.py", line 36, in test_sundry import_tool(name) File "C:\Program Files\Python 3.5\lib\test\test_tools\__init__.py", line 22, in import_tool return importlib.import_module(toolname) File "C:\Program Files\Python 3.5\lib\importlib\__init__.py", line 126, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 986, in _gcd_import File "", line 969, in _find_and_load File "", line 958, in _find_and_load_unlocked File "", line 673, in _load_unlocked File "", line 662, in exec_module File "", line 222, in _call_with_frames_removed File "C:\Program Files\Python 3.5\Tools\scripts\2to3.py", line 5, in sys.exit(main("lib2to3.fixes")) File "C:\Program Files\Python 3.5\lib\lib2to3\main.py", line 179, in main options, args = parser.parse_args(args) File "C:\Program Files\Python 3.5\lib\optparse.py", line 1388, in parse_args self.error(str(err)) File "C:\Program Files\Python 3.5\lib\optparse.py", line 1568, in error self.exit(2, "%s: error: %s\n" % (self.get_prog_name(), msg)) File "C:\Program Files\Python 3.5\lib\optparse.py", line 1558, in exit sys.exit(status) SystemExit: 2 I had no failures on 3.4.3. ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 06:42:27 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 14 Sep 2015 04:42:27 +0000 Subject: [issue25083] Python can sometimes create incorrect .pyc files In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za> Message-ID: <1442205747.26.0.163369385101.issue25083@psf.upfronthosting.co.za> Gregory P. Smith added the comment: we'll need a test case .pyc where this happens. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 06:42:47 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 14 Sep 2015 04:42:47 +0000 Subject: [issue25100] Test_distutils fails instead of skipping if no VS2015 Message-ID: <1442205767.42.0.746068733086.issue25100@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Moved here from #12420 as a new and separate issue after diagnosis by Mark Lawrence and Zack Ware. The following failures on new 3.5.0 all end with the same message about vcvarsall.bat (slightly different from 3.4 failures). ====================================================================== ERROR: test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase) ---------------------------------------------------------------------- ====================================================================== ERROR: test_optional_extension (distutils.tests.test_build_ext.BuildExtTestCase) ---------------------------------------------------------------------- ====================================================================== ERROR: test_get_outputs (distutils.tests.test_build_ext.ParallelBuildExtTestCase) ---------------------------------------------------------------------- ====================================================================== ERROR: test_optional_extension (distutils.tests.test_build_ext.ParallelBuildExtTestCase) ---------------------------------------------------------------------- ====================================================================== ERROR: test_compiler_options (distutils.tests.test_msvccompiler.msvccompilerTestCase) ---------------------------------------------------------------------- ====================================================================== ERROR: test_vcruntime_copy (distutils.tests.test_msvccompiler.msvccompilerTestCase) ---------------------------------------------------------------------- ====================================================================== ERROR: test_vcruntime_skip_copy (distutils.tests.test_msvccompiler.msvccompilerTestCase) ---------------------------------------------------------------------- ====================================================================== FAIL: test_customize_compiler_before_get_config_vars (distutils.tests.test_sysconfig.SysconfigTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Programs\Python 3.5\lib\distutils\tests\test_sysconfig.py", line 197, in test_customize_compiler_before_get_c onfig_vars self.assertEqual(0, p.returncode, "Subprocess failed: " + outs) AssertionError: 0 != 1 : Subprocess failed: Traceback (most recent call last): File "@test_5504_tmp", line 5, in rc = config.try_compile('int x;') File "C:\Programs\Python 3.5\lib\distutils\command\config.py", line 227, in try_compile self._compile(body, headers, include_dirs, lang) File "C:\Programs\Python 3.5\lib\distutils\command\config.py", line 133, in _compile self.compiler.compile([src], include_dirs=include_dirs) File "C:\Programs\Python 3.5\lib\distutils\_msvccompiler.py", line 315, in compile self.initialize() File "C:\Programs\Python 3.5\lib\distutils\_msvccompiler.py", line 208, in initialize vc_env = _get_vc_env(plat_spec) File "C:\Programs\Python 3.5\lib\distutils\_msvccompiler.py", line 83, in _get_vc_env raise DistutilsPlatformError("Unable to find vcvarsall.bat") distutils.errors.DistutilsPlatformError: Unable to find vcvarsall.bat ---------------------------------------------------------------------- Ran 234 tests in 1.108s FAILED (failures=1, errors=7, skipped=28) Warning -- threading._dangling was modified by test_distutils Warning -- files was modified by test_distutils ---------- components: Distutils, Tests, Windows messages: 250620 nosy: dstufft, eric.araujo, paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware priority: normal severity: normal status: open title: Test_distutils fails instead of skipping if no VS2015 versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 06:44:11 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 14 Sep 2015 04:44:11 +0000 Subject: [issue12420] distutils tests fail if PATH is not defined In-Reply-To: <1309177997.74.0.17903211546.issue12420@psf.upfronthosting.co.za> Message-ID: <1442205851.53.0.104518762775.issue12420@psf.upfronthosting.co.za> Terry J. Reedy added the comment: No VS2015 yet. New issue #25100. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 06:45:24 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 14 Sep 2015 04:45:24 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442205924.35.0.881299662725.issue25092@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 06:47:36 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Sep 2015 04:47:36 +0000 Subject: [issue25093] New 3.5.0 failure in test_tcl on win7 In-Reply-To: <1442200639.15.0.127298727385.issue25093@psf.upfronthosting.co.za> Message-ID: <1442206056.92.0.191353196186.issue25093@psf.upfronthosting.co.za> Zachary Ware added the comment: Yes, installation in 'Program Files' produces the failure. Looks like it's probably just bad quoting in the test, but I haven't looked at the code yet. This probably affects 2.7 and up, I don't think there have been any changes to that test in recent branches. ---------- keywords: +easy stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 06:49:54 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Sep 2015 04:49:54 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442206194.65.0.229730183423.issue25092@psf.upfronthosting.co.za> Zachary Ware added the comment: Interestingly, the re-run performed by regrtest's '-w' flag did not fail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 06:54:05 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Sep 2015 04:54:05 +0000 Subject: [issue25101] test_zipfile failure when run by unprivileged user with installed Python Message-ID: <1442206445.71.0.486177418249.issue25101@psf.upfronthosting.co.za> New submission from Zachary Ware: ====================================================================== ERROR: test_write_with_optimization (test.test_zipfile.PyZipFileTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Program Files\Python 3.5\lib\test\test_zipfile.py", line 771, in test_write_with_optimization zipfp.writepy(packagedir) File "C:\Program Files\Python 3.5\lib\zipfile.py", line 1756, in writepy fname, arcname = self._get_codename(initname[0:-3], basename) File "C:\Program Files\Python 3.5\lib\zipfile.py", line 1882, in _get_codename if not _compile(file_py, optimize=self._optimize): File "C:\Program Files\Python 3.5\lib\zipfile.py", line 1819, in _compile py_compile.compile(file, doraise=True, optimize=optimize) File "C:\Program Files\Python 3.5\lib\py_compile.py", line 143, in compile importlib._bootstrap_external._write_atomic(cfile, bytecode, mode) File "", line 106, in _write_atomic PermissionError: [Errno 13] Permission denied: 'C:\\Program Files\\Python 3.5\\lib\\email\\__pycache__\\__init__.cpython-35.opt-1.pyc.755404532528' ---------- components: Tests, Windows messages: 250624 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: test_zipfile failure when run by unprivileged user with installed Python type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 07:01:16 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Sep 2015 05:01:16 +0000 Subject: [issue25102] Windows installer: 'precompile standard library' option should pre-compile with -O and -OO Message-ID: <1442206876.09.0.966951912645.issue25102@psf.upfronthosting.co.za> New submission from Zachary Ware: Since the default all-users install location is now Program Files and thus not world-writable and with the advent of optimization-tagged .pyc files, the 'precompile' option in the installer should also precompile with -O and -OO. ---------- assignee: steve.dower components: Installation, Windows messages: 250625 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows installer: 'precompile standard library' option should pre-compile with -O and -OO type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 07:12:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Sep 2015 05:12:21 +0000 Subject: [issue25093] New 3.5.0 failure in test_tcl on win7 In-Reply-To: <1442200639.15.0.127298727385.issue25093@psf.upfronthosting.co.za> Message-ID: <1442207541.74.0.2689799558.issue25093@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you please test with following patch? ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file40454/testLoadWithUNC.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 07:16:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Sep 2015 05:16:21 +0000 Subject: [issue25101] test_zipfile failure when run by unprivileged user with installed Python In-Reply-To: <1442206445.71.0.486177418249.issue25101@psf.upfronthosting.co.za> Message-ID: <1442207781.91.0.823099287187.issue25101@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ah, os.access() doesn't work on Windows. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 07:32:11 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Sep 2015 05:32:11 +0000 Subject: [issue25093] New 3.5.0 failure in test_tcl on win7 In-Reply-To: <1442200639.15.0.127298727385.issue25093@psf.upfronthosting.co.za> Message-ID: <1442208731.75.0.0607482626419.issue25093@psf.upfronthosting.co.za> Zachary Ware added the comment: The patch works, with an added 'import subprocess' and after removing the 'f.close()' check. I hadn't realized this test was still using os.popen, that's fairly horrible :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 07:33:44 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Sep 2015 05:33:44 +0000 Subject: [issue25103] 3.5.0 installed standard library on Windows has LF line endings Message-ID: <1442208824.41.0.568116526355.issue25103@psf.upfronthosting.co.za> New submission from Zachary Ware: It would be nice to install the standard library (and test suite) with CRLF line endings, to allow for reading/editing with Notepad. Horrible though it is, it's at least always available :) Steve, this may just be an issue of how your repository is checked out; I assume if your working directory has LF line endings, that will propagate to the installer/installed files? The hg 'eol' extension takes care of making everything CRLF on Windows, but only if it's enabled before the working directory is created (you can force an EOL update by doing `hg up null && hg up 3.5` with 'eol' enabled). ---------- assignee: steve.dower components: Installation, Windows messages: 250629 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: 3.5.0 installed standard library on Windows has LF line endings versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 07:33:52 2015 From: report at bugs.python.org (m) Date: Mon, 14 Sep 2015 05:33:52 +0000 Subject: [issue25104] Wrong documentation for "chr(i)" function. Message-ID: <1442208832.43.0.566078957807.issue25104@psf.upfronthosting.co.za> New submission from m: The documentation of the "chr(i)" function is not correct, it states that The valid range for the argument is from 0 through 1,114,111 (0x10FFFF in base 16). Correction: The valid range for the argument is from 0 through 255 (0xFF in base 16). ---------- assignee: docs at python components: Documentation messages: 250630 nosy: docs at python, m priority: normal severity: normal status: open title: Wrong documentation for "chr(i)" function. type: compile error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 07:41:05 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Sep 2015 05:41:05 +0000 Subject: [issue25104] Wrong documentation for "chr(i)" function. In-Reply-To: <1442208832.43.0.566078957807.issue25104@psf.upfronthosting.co.za> Message-ID: <1442209265.45.0.345431576732.issue25104@psf.upfronthosting.co.za> Zachary Ware added the comment: You appear to be reading the Python 3 documentation and using Python 2: $ python3 Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 23 2015, 02:52:03) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> chr(1234) '?' >>> ^D $ python2 Python 2.7.10 (v2.7.10:15c95b7d81dc, May 23 2015, 09:33:12) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> chr(1234) Traceback (most recent call last): File "", line 1, in ValueError: chr() arg not in range(256) ---------- nosy: +zach.ware resolution: -> not a bug stage: -> resolved status: open -> closed type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 08:11:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Sep 2015 06:11:48 +0000 Subject: [issue25101] test_zipfile failure when run by unprivileged user with installed Python In-Reply-To: <1442206445.71.0.486177418249.issue25101@psf.upfronthosting.co.za> Message-ID: <1442211108.91.0.740821133447.issue25101@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that check write access by just trying to create a file. ---------- keywords: +patch stage: needs patch -> patch review versions: +Python 2.7, Python 3.4, Python 3.6 Added file: http://bugs.python.org/file40455/test_zipfile_check_write_access.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 08:25:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Sep 2015 06:25:41 +0000 Subject: [issue25099] test_compileall fails when run by unprivileged user on installed Python In-Reply-To: <1442205173.06.0.618332067063.issue25099@psf.upfronthosting.co.za> Message-ID: <1442211941.66.0.0131983236037.issue25099@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The failure can be reproduced on Linux if make the Lib/__pycache__/ directory non-writable. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 08:30:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Sep 2015 06:30:08 +0000 Subject: [issue25099] test_compileall fails when run by unprivileged user on installed Python In-Reply-To: <1442205173.06.0.618332067063.issue25099@psf.upfronthosting.co.za> Message-ID: <1442212208.82.0.0245915995077.issue25099@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +benjamin.peterson, brett.cannon, eric.snow, georg.brandl, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 08:32:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Sep 2015 06:32:54 +0000 Subject: [issue25098] test_uuid fails with pywin32 installed In-Reply-To: <1442204635.01.0.244240422269.issue25098@psf.upfronthosting.co.za> Message-ID: <1442212374.2.0.679676016876.issue25098@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Looks as a bug in pywin32. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 08:38:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Sep 2015 06:38:19 +0000 Subject: [issue25093] New 3.5.0 failure in test_tcl on win7 In-Reply-To: <1442200639.15.0.127298727385.issue25093@psf.upfronthosting.co.za> Message-ID: <1442212699.82.0.726935881873.issue25093@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Please commit corrected patch. ---------- assignee: -> zach.ware stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 08:39:17 2015 From: report at bugs.python.org (Naveen Togar) Date: Mon, 14 Sep 2015 06:39:17 +0000 Subject: [issue25088] scipy (0.16.0) install fails on 3.5 In-Reply-To: <1442159302.54.0.00542584787984.issue25088@psf.upfronthosting.co.za> Message-ID: <1442212757.39.0.183081103915.issue25088@psf.upfronthosting.co.za> Naveen Togar added the comment: Carol, Ned Thanks for the info. I'm going to install gfortran and proceed with the installing scipy and matplotlib. Naveen ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 08:54:48 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Sep 2015 06:54:48 +0000 Subject: [issue25105] Docs 3.x buildbot: Message-ID: <1442213688.52.0.64987156832.issue25105@psf.upfronthosting.co.za> New submission from STINNER Victor: It looks like the changeset 34f941df3476 introduced a bug: http://buildbot.python.org/all/builders/Docs%203.x/builds/86/steps/suspicious/logs/stdio writing output... [ 99%] whatsnew/3.5 WARNING: [whatsnew/3.5:924] ":root" found in "'WARNING:root:warning\n'" WARNING: [whatsnew/3.5:924] ":warning" found in "'WARNING:root:warning\n'" WARNING: [whatsnew/3.5:1244] "::" found in ">>> addr6 = ipaddress.IPv6Address('::1')" ---------- assignee: docs at python components: Documentation messages: 250637 nosy: docs at python, haypo, yselivanov priority: normal severity: normal status: open title: Docs 3.x buildbot: versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 09:01:28 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Sep 2015 07:01:28 +0000 Subject: [issue25105] Docs 3.x buildbot: ":root" found in ... In-Reply-To: <1442213688.52.0.64987156832.issue25105@psf.upfronthosting.co.za> Message-ID: <1442214088.14.0.71530107337.issue25105@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Docs 3.x buildbot: -> Docs 3.x buildbot: ":root" found in ... _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 09:02:07 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Sep 2015 07:02:07 +0000 Subject: [issue25105] Docs 3.x buildbot: ":root" found in ... In-Reply-To: <1442213688.52.0.64987156832.issue25105@psf.upfronthosting.co.za> Message-ID: <1442214127.49.0.0330500431217.issue25105@psf.upfronthosting.co.za> STINNER Victor added the comment: It looks like a bug in the "suspicious" tool which should skip preformatted blocks (blocks starting with "::"). +don't provide any options to redirect it:: + + >>> import contextlib, io, logging + >>> f = io.StringIO() + >>> with contextlib.redirect_stderr(f): + ... logging.warning('warning') + ... + >>> f.getvalue() + 'WARNING:root:warning\n' + +(Contributed by Berker Peksag in :issue:`22389`.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 09:29:28 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 14 Sep 2015 07:29:28 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object Message-ID: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> New submission from Alecsandru Patrascu: Hi All, This is Alecsandru from Server Scripting Languages Optimization team at Intel Corporation. I would like to submit a patch that improves the performance of the hash computation code on stringobject, bufferobject and unicodeobject. As can be seen from the attached sample performance results from the Grand Unified Python Benchmark, speedups up to 40% were observed. Furthermore, we see a 5-7% performance on OpenStack/Swift, where most of the code is in Python 2.7. Attached is the patch that modifies Object/stringobject.c, Object/bufferobject.c and Object/unicodeobject.c files. We built and tested this patch for Python 2.7 on our Linux machines (CentOS 7/Ubuntu Server 14.04, Intel Xeon Haswell/Broadwell with 18/8 cores). Steps to apply the patch: 1. hg clone https://hg.python.org/cpython cpython 2. cd cpython 3. hg update 2.7 4. Copy hash8.patch to the current directory 5. hg import --no-commit hash8.patch 6. ./configure 7. make In the following, please find our sample performance results measured on a XEON Haswell machine. Hardware (HW): Intel XEON (Haswell) 18 Cores BIOS settings: Intel Turbo Boost Technology: false Hyper-Threading: false Operating System: Ubuntu 14.04.3 LTS trusty OS configuration: CPU freq set at fixed: 2.0GHz by echo 2000000 > /sys/devices/system/cpu/cpu*/cpufreq/scaling_min_freq echo 2000000 > /sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq Address Space Layout Randomization (ASLR) disabled (to reduce run to run variation) by echo 0 > /proc/sys/kernel/randomize_va_space GCC version: gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04) Benchmark: Grand Unified Python Benchmark (GUPB) GUPB Source: https://hg.python.org/benchmarks/ Python2.7 results: Python source: hg clone https://hg.python.org/cpython cpython Python Source: hg update 2.7 Benchmarks Speedup(%) unpack_sequence 40.32733766 chaos 24.84002537 chameleon 23.01392651 silent_logging 22.27202911 django 20.83842317 etree_process 20.46968294 nqueens 20.34234985 pathlib 19.63445919 pidigits 19.34722148 etree_generate 19.25836634 pybench 19.06895825 django_v2 18.06073108 etree_iterparse 17.3797149 fannkuch 17.08120879 pickle_list 16.60363602 raytrace 16.0316265 slowpickle 15.86611184 pickle_dict 15.30447114 call_simple 14.42909032 richards 14.2949594 simple_logging 13.6522626 etree_parse 13.38113097 json_dump_v2 12.26588885 float 11.88164311 mako 11.20606516 spectral_norm 11.04356684 hg_startup 10.57686164 mako_v2 10.37912648 slowunpickle 10.24030714 go 10.03567319 meteor_contest 9.956231435 normal_startup 9.607401586 formatted_logging 9.601244811 html5lib 9.082603748 2to3 8.741557816 html5lib_warmup 8.268150981 nbody 7.507012306 regex_compile 7.153922724 bzr_startup 7.140244739 telco 6.869411927 slowspitfire 5.746323922 tornado_http 5.24360121 rietveld 3.865704876 regex_v8 3.777622219 hexiom2 3.586305282 json_dump 3.477551682 spambayes 3.183991854 fastunpickle 2.971645347 fastpickle 0.673086656 regex_effbot 0.127946837 json_load 0.023727176 Thank you, Alecsandru ---------- components: Interpreter Core files: hash8-v01.patch keywords: patch messages: 250639 nosy: alecsandru.patrascu priority: normal severity: normal status: open title: Hash computation speedup for {buffer,string,unicode}object type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file40456/hash8-v01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 10:06:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Sep 2015 08:06:57 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442218017.43.0.106103632946.issue25106@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Python 2.7 is closed for adding new features. Python 3.4+ uses different code for calculating hashes. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 10:20:27 2015 From: report at bugs.python.org (Sergei) Date: Mon, 14 Sep 2015 08:20:27 +0000 Subject: [issue25107] Windows 32-bit: exe-files doesn't run Message-ID: <1442218827.64.0.651428561761.issue25107@psf.upfronthosting.co.za> New submission from Sergei: Can't run IDLE or python command line on Windows XP 32-bit after installation. ---------- components: IDLE, Interpreter Core files: Clipboard02.jpg messages: 250641 nosy: Sergio priority: normal severity: normal status: open title: Windows 32-bit: exe-files doesn't run type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file40457/Clipboard02.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 10:21:58 2015 From: report at bugs.python.org (Sergei) Date: Mon, 14 Sep 2015 08:21:58 +0000 Subject: [issue25107] Windows 32-bit: exe-files doesn't run In-Reply-To: <1442218827.64.0.651428561761.issue25107@psf.upfronthosting.co.za> Message-ID: <1442218918.22.0.603792614328.issue25107@psf.upfronthosting.co.za> Changes by Sergei : Removed file: http://bugs.python.org/file40457/Clipboard02.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 10:22:12 2015 From: report at bugs.python.org (Sergei) Date: Mon, 14 Sep 2015 08:22:12 +0000 Subject: [issue25107] Windows 32-bit: exe-files doesn't run In-Reply-To: <1442218827.64.0.651428561761.issue25107@psf.upfronthosting.co.za> Message-ID: <1442218932.79.0.909856373517.issue25107@psf.upfronthosting.co.za> Changes by Sergei : Added file: http://bugs.python.org/file40458/Clipboard02.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 10:23:20 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Sep 2015 08:23:20 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442219000.01.0.881722048382.issue25106@psf.upfronthosting.co.za> STINNER Victor added the comment: > Python 2.7 is closed for adding new features. Python 3.4+ uses different code for calculating hashes. The code doesn't modify the hash function. It's a common loop unroll optimization technique. Since the optimization can be seen on real world benchmark, I think that it's worth to take this optimization. ---------- nosy: +haypo type: enhancement -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 10:41:13 2015 From: report at bugs.python.org (Chris Angelico) Date: Mon, 14 Sep 2015 08:41:13 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442220073.18.0.842950328956.issue25106@psf.upfronthosting.co.za> Chris Angelico added the comment: Hmm. Is Duff's Device a valid construct for CPython? It'd shorten this a lot... ---------- nosy: +Rosuav _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 10:46:07 2015 From: report at bugs.python.org (Chris Angelico) Date: Mon, 14 Sep 2015 08:46:07 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442220367.65.0.497430461597.issue25106@psf.upfronthosting.co.za> Chris Angelico added the comment: Or at very least, can fallthrough be used in the switch block, so there aren't 7+6+5+4+3+2+1 copies of the same line? -- Not a C performance expert -- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 11:00:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Sep 2015 09:00:43 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442220367.65.0.497430461597.issue25106@psf.upfronthosting.co.za> Message-ID: <1792645.ZJ5bhCSutE@raxxla> Serhiy Storchaka added the comment: > Or at very least, can fallthrough be used in the switch block, so there > aren't 7+6+5+4+3+2+1 copies of the same line? It is how _Py_HashBytes is implemented in 3.4+. ---------- title: Hash computation speedup for {buffer,string,unicode}object -> Hash computation speedup for {buffer, string, unicode}object _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 11:16:55 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 14 Sep 2015 09:16:55 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442222215.73.0.728317913194.issue25106@psf.upfronthosting.co.za> Alecsandru Patrascu added the comment: Yes, sure it can be implemented in smaller space, as Serhiy and Chris well pointed out. I submitted the 01 version like that just to be clear that I don't want to re-implement a new hash computing value and just unroll the loop in the existing one. I will submit a new version based on this observations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 11:43:11 2015 From: report at bugs.python.org (Oleg N) Date: Mon, 14 Sep 2015 09:43:11 +0000 Subject: [issue25107] Windows 32-bit: exe-files doesn't run In-Reply-To: <1442218827.64.0.651428561761.issue25107@psf.upfronthosting.co.za> Message-ID: <1442223791.29.0.816805145847.issue25107@psf.upfronthosting.co.za> Oleg N added the comment: You need ucrtbase.dll. Extract this archive to your Python35-32 folder and try to run python. ---------- nosy: +Oleg N Added file: http://bugs.python.org/file40459/ucrtbase.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 11:52:11 2015 From: report at bugs.python.org (Oleg N) Date: Mon, 14 Sep 2015 09:52:11 +0000 Subject: [issue25107] Windows 32-bit: exe-files doesn't run In-Reply-To: <1442218827.64.0.651428561761.issue25107@psf.upfronthosting.co.za> Message-ID: <1442224331.71.0.228976828267.issue25107@psf.upfronthosting.co.za> Oleg N added the comment: This dll probobly won't work. Read at the end of this article http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx how to obtain ucrtbase. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 12:13:43 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 14 Sep 2015 10:13:43 +0000 Subject: [issue25108] traceback.extract_stack() compatibility break in 3.5 Message-ID: <1442225623.41.0.830396346015.issue25108@psf.upfronthosting.co.za> New submission from Antoine Pitrou: This can be considered a regression, although perhaps it may not be desirable to fix it in a later release. In 3.4: >>> def f(): return traceback.extract_stack() ... >>> print([x[0:3] for x in f()]) [('', 1, ''), ('', 1, 'f')] In 3.5: >>> print([x[0:3] for x in f()]) [('', 1, ''), ('', 1, 'f'), ('/home/antoine/35/lib/python3.5/traceback.py', 201, 'extract_stack')] Note how the traceback module suddenly appears in the extracted stack. This breaks any application which uses a fixed offset into the returned stack to look up for information. ---------- components: Library (Lib) messages: 250649 nosy: larry, ncoghlan, pitrou, rbcollins priority: normal severity: normal status: open title: traceback.extract_stack() compatibility break in 3.5 type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 12:15:38 2015 From: report at bugs.python.org (Robert Collins) Date: Mon, 14 Sep 2015 10:15:38 +0000 Subject: [issue25108] traceback.extract_stack() compatibility break in 3.5 In-Reply-To: <1442225623.41.0.830396346015.issue25108@psf.upfronthosting.co.za> Message-ID: <1442225738.29.0.529243476484.issue25108@psf.upfronthosting.co.za> Robert Collins added the comment: Hmm, I think we can fix this. Its leaking due to the use of a helper I think. So - we should just fix this [and add a test, since clearly the test coverage is insufficient] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 12:16:19 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 14 Sep 2015 10:16:19 +0000 Subject: [issue25108] traceback.extract_stack() compatibility break in 3.5 In-Reply-To: <1442225623.41.0.830396346015.issue25108@psf.upfronthosting.co.za> Message-ID: <1442225779.86.0.208401775489.issue25108@psf.upfronthosting.co.za> Larry Hastings added the comment: Tracebacks aren't my forte, but this does smell like a regression and something that should be fixed. My worry about things like this is that it isn't as much a "bug" as a "badly implemented interface". As in, that's the interface in 3.5, and people will depend on it, and we change it in a point release at our peril. (That's why I didn't permit "fixing" warnings.warn(stacklevel=) for 3.4.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 12:21:35 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 14 Sep 2015 10:21:35 +0000 Subject: [issue25108] traceback.extract_stack() compatibility break in 3.5 In-Reply-To: <1442225623.41.0.830396346015.issue25108@psf.upfronthosting.co.za> Message-ID: <1442226095.31.0.877278193278.issue25108@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Note the doc says "Extract the raw traceback from the current stack frame". The "current stack frame" may be assumed to be the caller's (as it is in previous Python releases). Fortunately, this is also worked around by calling `extract_stack(sys._getframe())`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 12:49:36 2015 From: report at bugs.python.org (tzickel) Date: Mon, 14 Sep 2015 10:49:36 +0000 Subject: [issue25083] Python can sometimes create incorrect .pyc files In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za> Message-ID: <1442227776.0.0.672391675414.issue25083@psf.upfronthosting.co.za> tzickel added the comment: You are not looking at the correct code, the function you are pointing to, check_compiled_module is run to check the existing .pyc (it is a good question, why the .pyc is overriden, but that is a secondary issue, which I cannot reproduce as I've said by demand). I am talking about the code which creates a new (and incorrect) .pyc in parse_source_module: https://hg.python.org/cpython/file/2.7/Python/import.c#l861 calls in the end to Py_UniversalNewlineFgets https://hg.python.org/cpython/file/2.7/Objects/fileobject.c#l2749 you can see that function will return NULL if it gets an EOF because of a file error, and then the tokenises which calls it will not know if it got NULL because of EOF or file error, and compile the AST and generate an incorrect .pyc file. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 12:55:04 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 14 Sep 2015 10:55:04 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442228104.27.0.319816615654.issue25106@psf.upfronthosting.co.za> Changes by Alecsandru Patrascu : Added file: http://bugs.python.org/file40460/hash8-v02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 12:55:54 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 14 Sep 2015 10:55:54 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442228154.95.0.288119204141.issue25106@psf.upfronthosting.co.za> Alecsandru Patrascu added the comment: I've submitted a more compact version of the previous code (hash8-v02.patch) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 13:26:51 2015 From: report at bugs.python.org (Matthias Klose) Date: Mon, 14 Sep 2015 11:26:51 +0000 Subject: [issue25109] test_code_module tests fail when run from the installed location Message-ID: <1442230011.36.0.482937736349.issue25109@psf.upfronthosting.co.za> New submission from Matthias Klose: seen when running the tests in the installed location: the test expects: Traceback (most recent call last): File "", line 1, in ValueError but it gets: Traceback (most recent call last): File "/usr/lib/python3.5/code.py", line 91, in runcode exec(code, self.locals) File "", line 1, in ValueError same for the other failing test case. Re-running test 'test_code_module' in verbose mode test_banner (test.test_code_module.TestInteractiveConsole) ... ok test_cause_tb (test.test_code_module.TestInteractiveConsole) ... FAIL test_console_stderr (test.test_code_module.TestInteractiveConsole) ... ok test_context_tb (test.test_code_module.TestInteractiveConsole) ... FAIL test_ps1 (test.test_code_module.TestInteractiveConsole) ... ok test_ps2 (test.test_code_module.TestInteractiveConsole) ... ok test_syntax_error (test.test_code_module.TestInteractiveConsole) ... ok test_sysexcepthook (test.test_code_module.TestInteractiveConsole) ... ok ====================================================================== FAIL: test_cause_tb (test.test_code_module.TestInteractiveConsole) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python3.5/test/test_code_module.py", line 96, in test_cause_tb self.assertIn(expected, output) AssertionError: '\nAttributeError\n\nThe above exception was the direct cause of the following exception:\n\nTraceback (most recent call last):\n File "", line 1, in \nValueError\n' not found in 'Python on \nType "help", "copyright", "credits" or "license" for more information.\n(InteractiveConsole)\nAttributeError\n\nThe above exception was the direct cause of the following exception:\n\nTraceback (most recent call last):\n File "/usr/lib/python3.5/code.py", line 91, in runcode\n exec(code, self.locals)\n File "", line 1, in \nValueError\n\n' ====================================================================== FAIL: test_context_tb (test.test_code_module.TestInteractiveConsole) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python3.5/test/test_code_module.py", line 114, in test_context_tb self.assertIn(expected, output) AssertionError: '\nTraceback (most recent call last):\n File "", line 1, in \nNameError: name \'ham\' is not defined\n\nDuring handling of the above exception, another exception occurred:\n\nTraceback (most recent call last):\n File "", line 2, in \nNameError: name \'eggs\' is not defined\n' not found in 'Python on \nType "help", "copyright", "credits" or "license" for more information.\n(InteractiveConsole)\nTraceback (most recent call last):\n File "", line 1, in \nNameError: name \'ham\' is not defined\n\nDuring handling of the above exception, another exception occurred:\n\nTraceback (most recent call last):\n File "/usr/lib/python3.5/code.py", line 91, in runcode\n exec(code, self.locals)\n File "", line 2, in \nNameError: name \'eggs\' is not defined\n\n' ---------- components: Tests messages: 250655 nosy: doko priority: normal severity: normal status: open title: test_code_module tests fail when run from the installed location versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 13:27:09 2015 From: report at bugs.python.org (tzickel) Date: Mon, 14 Sep 2015 11:27:09 +0000 Subject: [issue25083] Python can sometimes create incorrect .pyc files In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za> Message-ID: <1442230029.84.0.955335403887.issue25083@psf.upfronthosting.co.za> Changes by tzickel : ---------- nosy: +brett.cannon, meador.inge _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 13:27:30 2015 From: report at bugs.python.org (Matthias Klose) Date: Mon, 14 Sep 2015 11:27:30 +0000 Subject: [issue17750] allow the testsuite to run in the installed location In-Reply-To: <1366108780.66.0.667292537865.issue17750@psf.upfronthosting.co.za> Message-ID: <1442230050.51.0.920631410635.issue17750@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- dependencies: +test_code_module tests fail when run from the installed location _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 13:38:46 2015 From: report at bugs.python.org (Peter) Date: Mon, 14 Sep 2015 11:38:46 +0000 Subject: [issue19746] No introspective way to detect ModuleImportFailure in unittest In-Reply-To: <1385262963.63.0.210713286499.issue19746@psf.upfronthosting.co.za> Message-ID: <1442230726.24.0.628100747106.issue19746@psf.upfronthosting.co.za> Peter added the comment: This comment is just to note that this change broke our (exotic?) usage of unittest.TestLoader().loadTestsFromName(name) inside a try/except since under Python 3.5 some expected exceptions are no longer raised. My nasty workaround hack: https://github.com/biopython/biopython/commit/929fbfbcf2d1ba65ec460a413128dd5e6f68f5bf I think it is unfortunate that the .errors attribute is just a list of messages as strings, rather than the original exception object(s) which would be easier to handle (e.g. using the subclass hierarchy). ---------- nosy: +maubp _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 14:02:59 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Sep 2015 12:02:59 +0000 Subject: [issue25063] shutil.copyfileobj should internally use os.sendfile when possible In-Reply-To: <1441910330.09.0.484556764779.issue25063@psf.upfronthosting.co.za> Message-ID: <1442232179.9.0.387157126522.issue25063@psf.upfronthosting.co.za> R. David Murray added the comment: I'm going to reject this. If you think there is enough value in this to warrant the complications that would be required to ensure backward compatibility (assuming that is even possible), you could bring it up again on python-ideas. ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 14:18:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Sep 2015 12:18:55 +0000 Subject: [issue17750] allow the testsuite to run in the installed location In-Reply-To: <1366108780.66.0.667292537865.issue17750@psf.upfronthosting.co.za> Message-ID: <1442233135.91.0.642129038813.issue17750@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +test_compileall fails when run by unprivileged user on installed Python, test_zipfile failure when run by unprivileged user with installed Python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 15:03:13 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Sep 2015 13:03:13 +0000 Subject: [issue25102] Windows installer: 'precompile standard library' option should pre-compile with -O and -OO In-Reply-To: <1442206876.09.0.966951912645.issue25102@psf.upfronthosting.co.za> Message-ID: <1442235793.49.0.443303289627.issue25102@psf.upfronthosting.co.za> Steve Dower added the comment: Doesn't it? It's supposed to... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 15:08:11 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Sep 2015 13:08:11 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442236091.37.0.638554321869.issue25092@psf.upfronthosting.co.za> Steve Dower added the comment: Maybe errno needs to be explicitly cleared before calling strftime or else we're seeing someone else's EINVAL? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 15:08:41 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Sep 2015 13:08:41 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442236121.83.0.395706309879.issue25092@psf.upfronthosting.co.za> Steve Dower added the comment: (In the C code I mean, not in the test.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 15:08:54 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Sep 2015 13:08:54 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442236134.97.0.239623149853.issue25092@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 15:24:22 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Sep 2015 13:24:22 +0000 Subject: [issue25107] Windows 32-bit: exe-files doesn't run In-Reply-To: <1442218827.64.0.651428561761.issue25107@psf.upfronthosting.co.za> Message-ID: <1442237062.15.0.622975612241.issue25107@psf.upfronthosting.co.za> Zachary Ware added the comment: Windows XP is not supported by Python 3.5. See PEP 11 for details. ---------- components: +Windows -IDLE nosy: +paul.moore, steve.dower, tim.golden, zach.ware resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 15:25:58 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 14 Sep 2015 13:25:58 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442237158.45.0.792725156884.issue25092@psf.upfronthosting.co.za> Stefan Krah added the comment: Yes, errno should always be cleared before use (in C99 at least, not sure what the crt does). ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 15:28:26 2015 From: report at bugs.python.org (eryksun) Date: Mon, 14 Sep 2015 13:28:26 +0000 Subject: [issue25107] Windows 32-bit: exe-files doesn't run In-Reply-To: <1442218827.64.0.651428561761.issue25107@psf.upfronthosting.co.za> Message-ID: <1442237306.85.0.352233712512.issue25107@psf.upfronthosting.co.za> eryksun added the comment: The latest version that supports Windows XP is 3.4.3. ---------- components: +IDLE -Windows nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 15:30:17 2015 From: report at bugs.python.org (eryksun) Date: Mon, 14 Sep 2015 13:30:17 +0000 Subject: [issue25107] Windows 32-bit: exe-files doesn't run In-Reply-To: <1442218827.64.0.651428561761.issue25107@psf.upfronthosting.co.za> Message-ID: <1442237417.27.0.486713396217.issue25107@psf.upfronthosting.co.za> Changes by eryksun : ---------- components: +Windows -IDLE _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 15:32:25 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Sep 2015 13:32:25 +0000 Subject: [issue25089] Can't run Python Launcher on Windows In-Reply-To: <1442184297.36.0.379341480925.issue25089@psf.upfronthosting.co.za> Message-ID: <1442237545.78.0.470856737664.issue25089@psf.upfronthosting.co.za> Steve Dower added the comment: Just the main log file from the initial install is enough if there's no log for the launcher. It probably means the initial setup startup deselected it for some reason. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 15:44:11 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Sep 2015 13:44:11 +0000 Subject: [issue25103] 3.5.0 installed standard library on Windows has LF line endings In-Reply-To: <1442208824.41.0.568116526355.issue25103@psf.upfronthosting.co.za> Message-ID: <1442238251.06.0.136169245126.issue25103@psf.upfronthosting.co.za> R. David Murray added the comment: I'm pretty sure the hg eol extension would need to get involved here. This may not be worth the pain it would likely cause, but I could be wrong :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 15:44:50 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 14 Sep 2015 13:44:50 +0000 Subject: [issue25089] Can't run Python Launcher on Windows In-Reply-To: <1442184297.36.0.379341480925.issue25089@psf.upfronthosting.co.za> Message-ID: <1442238290.82.0.176643627691.issue25089@psf.upfronthosting.co.za> Changes by Mark Lawrence : Added file: http://bugs.python.org/file40461/Python 3.5.0 (64-bit)_20150913191600.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 16:01:41 2015 From: report at bugs.python.org (eryksun) Date: Mon, 14 Sep 2015 14:01:41 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442239301.32.0.302262098226.issue25092@psf.upfronthosting.co.za> eryksun added the comment: > errno should always be cleared before use (in C99 at least, > not sure what the crt does). The CRT's strftime doesn't clear errno. I suggested clearing it in issue 25029, msg250215. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 16:12:47 2015 From: report at bugs.python.org (Florian Apolloner) Date: Mon, 14 Sep 2015 14:12:47 +0000 Subject: [issue25110] Documentation sometimes still links to py3.4 Message-ID: <1442239967.4.0.711853703781.issue25110@psf.upfronthosting.co.za> New submission from Florian Apolloner: Compare those two URLs: https://docs.python.org/3/whatsnew/ https://docs.python.org/3/ The first one shows version 3.4, whereas the later shows version 3.5. ---------- messages: 250667 nosy: Florian.Apolloner priority: normal severity: normal status: open title: Documentation sometimes still links to py3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 16:12:56 2015 From: report at bugs.python.org (Florian Apolloner) Date: Mon, 14 Sep 2015 14:12:56 +0000 Subject: [issue25110] Documentation sometimes still links to py3.4 In-Reply-To: <1442239967.4.0.711853703781.issue25110@psf.upfronthosting.co.za> Message-ID: <1442239976.1.0.535492470885.issue25110@psf.upfronthosting.co.za> Changes by Florian Apolloner : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 16:20:25 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Sep 2015 14:20:25 +0000 Subject: [issue25110] Documentation sometimes still links to py3.4 In-Reply-To: <1442239967.4.0.711853703781.issue25110@psf.upfronthosting.co.za> Message-ID: <1442240425.9.0.821071441962.issue25110@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 17:02:15 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 14 Sep 2015 15:02:15 +0000 Subject: [issue25110] Documentation sometimes still links to py3.4 In-Reply-To: <1442239967.4.0.711853703781.issue25110@psf.upfronthosting.co.za> Message-ID: <1442242935.4.0.53199930281.issue25110@psf.upfronthosting.co.za> Larry Hastings added the comment: Old version stuck in the CDN cache. I cleared the cache, it's fine now. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 17:03:04 2015 From: report at bugs.python.org (Mark Roseman) Date: Mon, 14 Sep 2015 15:03:04 +0000 Subject: [issue25090] IDLE: remove noisy icons from class (module) browser In-Reply-To: <1442187879.71.0.781728346587.issue25090@psf.upfronthosting.co.za> Message-ID: <1442242984.07.0.969884443787.issue25090@psf.upfronthosting.co.za> Mark Roseman added the comment: Thanks Raymond. As an 'outsider' I rely on people like you to provide feedback based on your experience to some of the proposals I'm floating here. On a more specific note... This one came about mainly as I was looking at the class (module) browser. I thought it a bit limited/clunky, which as Terry noted has been brought up before. I noticed many editors/IDEs do a status bar thing showing current class and/or function, often as a gateway to navigating through the structure. I've found it a convenient and compact navigational cue/tool. I've also seen this used in addition to or in conjunction with a sidebar showing the file structure, highlighting current location. I've admittedly only briefly tried Code Context (and personally based on that limited experience didn't find it particularly helpful, and somewhat visually disruptive), and the mention here was almost an afterthought (since the status bar thing does provide a coarse level of context). I'd actually be curious to see how other editors/IDEs implement the same sort of feature as there may be some nice tweaks to steal - do you have any pointers? Again, I greatly appreciate the feedback. In regards to your comment on "too many sweeping change proposals" I'd certainly like to hear any suggestions you may have around process, general concerns, etc. Thanks again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 17:12:23 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 14 Sep 2015 15:12:23 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442243543.62.0.993625332734.issue25106@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 17:31:14 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Sep 2015 15:31:14 +0000 Subject: [issue25089] Can't run Python Launcher on Windows In-Reply-To: <1442184297.36.0.379341480925.issue25089@psf.upfronthosting.co.za> Message-ID: <1442244674.7.0.483519315666.issue25089@psf.upfronthosting.co.za> Steve Dower added the comment: Yep, as part of the upgrade detection we're choosing not to install the launcher. Not sure whether that's because of a bug or a previous install on your machine, but I'll take a closer look. ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 17:33:22 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Sep 2015 15:33:22 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442244802.25.0.0145929188195.issue25092@psf.upfronthosting.co.za> Steve Dower added the comment: I guess when I said I'd done "exactly" what you suggested I misread that part... whoops. This is a pretty nasty bug to workaround... do we have any way for a user to clear errno from their own code? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 18:09:46 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Sep 2015 16:09:46 +0000 Subject: [issue25102] Windows installer: 'precompile standard library' option should pre-compile with -O and -OO In-Reply-To: <1442206876.09.0.966951912645.issue25102@psf.upfronthosting.co.za> Message-ID: <1442246986.44.0.950421414048.issue25102@psf.upfronthosting.co.za> Zachary Ware added the comment: It doesn't appear to; my 'C:\Program Files\Python 3.5\Lib\__pycache__' is full of .pyc's, but none with an optimization tag. To confirm with math rather than eyesight, according to 'dir' there are 168 files in Lib\, and 168 in Lib\__pycache__ rather than the expected 168*3. For the record, I have not run this Python as a privileged user, so the contents of __pycache__ are not incidental; they were definitely created by the precompile option. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 18:26:02 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 14 Sep 2015 16:26:02 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442247962.91.0.0844984615619.issue25092@psf.upfronthosting.co.za> Stefan Krah added the comment: Clearing is easy: errno = 0; :) C library functions are not supposed to set errno to 0 by themselves (C99: paragraph 7.5). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 18:27:52 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Sep 2015 16:27:52 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442248072.97.0.43740671101.issue25092@psf.upfronthosting.co.za> Steve Dower added the comment: I get that part. Is there a way people can set errno to zero from Python code? Or do we need to ship 3.5.1 already? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 18:29:03 2015 From: report at bugs.python.org (desbma) Date: Mon, 14 Sep 2015 16:29:03 +0000 Subject: [issue25061] Add native enum support for argparse In-Reply-To: <1441908245.42.0.23532628335.issue25061@psf.upfronthosting.co.za> Message-ID: <1442248143.45.0.912463017159.issue25061@psf.upfronthosting.co.za> desbma added the comment: > With my type function, the string input is converted to an enum object and that is stored in the Namespace. You can't be any more direct than that. Yes I know, but in that case it's missing the autogenerated help message with the possible choices. I know I can generate it manually, it just does not feel right for doing something so simple. IMO the goal of argparse is to unload the burden of checking/validating parameters manually, generating help messages with default/possible values, etc. Your solution with a dictionnary is similar to what I currently use and wrote in my example, with the added drawback that the keys are randomly ordered in the help message, unless I use OrderedDict (one more import and more boilerplate code). Each approach has its drawbacks, unless you write some additional code to workaround each limitation. In a perfect world, argparse would: * only show to the user the enum names, and use it in help/error messages, possible choice set, etc. * after parsing, set the real enum value in the namespace * and most importantly: to do that, don't require more code than just passing the enum ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 18:29:22 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Sep 2015 16:29:22 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442248162.95.0.760027256042.issue25092@psf.upfronthosting.co.za> STINNER Victor added the comment: It's common in Modules/posixmodule.c to set errno to 0 before calling a C function, especially when "errno != 0" is checked after the call (because it's the only way to check if the function failed?). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 18:35:56 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 14 Sep 2015 16:35:56 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442248556.55.0.337606034699.issue25092@psf.upfronthosting.co.za> R. David Murray added the comment: Given all the changes in the windows support in 3.5, I will not be at all surprised if we need to spin 3.5.1 much more quickly than we normally would in any case. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 18:39:28 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 14 Sep 2015 16:39:28 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442248768.59.0.732610890312.issue25092@psf.upfronthosting.co.za> Stefan Krah added the comment: Steve, sorry if I misunderstand you: My point (and eryksun's) was that errno is currently not cleared before the call to format_time() in Modules/timemodule.c:657 I didn't look at this issue in depth, just pointing out a possible cause. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 18:41:58 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 14 Sep 2015 16:41:58 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442248918.38.0.858265113188.issue25092@psf.upfronthosting.co.za> Stefan Krah added the comment: Argh, finally I got it: You suggested that Python users work around this in 3.5 by setting errno from the interpreter. I think it's better to release 3.5.1 early. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 18:42:43 2015 From: report at bugs.python.org (eryksun) Date: Mon, 14 Sep 2015 16:42:43 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442248963.63.0.227510213004.issue25092@psf.upfronthosting.co.za> eryksun added the comment: > Is there a way people can set errno to zero from Python code? > Or do we need to ship 3.5.1 already? The only the thing that comes to mind is using ctypes based on the CRT's implementation of errno: import ctypes import errno import time ucrtbase = ctypes.CDLL('ucrtbase') ucrtbase._errno.restype = ctypes.POINTER(ctypes.c_int) c_errno = ucrtbase._errno().contents >>> time.strftime('') '' >>> c_errno.value = errno.EINVAL; time.strftime('') Traceback (most recent call last): File "", line 1, in ValueError: Invalid format string ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 18:46:17 2015 From: report at bugs.python.org (John Beck) Date: Mon, 14 Sep 2015 16:46:17 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) on Solaris 11.3 and newer In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1442249177.6.0.279614710461.issue25003@psf.upfronthosting.co.za> John Beck added the comment: The owner of the Solaris kernel bug has confirmed that he plans to get the fix into both Solaris 12 and 11.3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 18:49:31 2015 From: report at bugs.python.org (eryksun) Date: Mon, 14 Sep 2015 16:49:31 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442249371.15.0.183815308282.issue25092@psf.upfronthosting.co.za> eryksun added the comment: But it should go without saying that clearing errno from Python isn't reliable considering how much code executes between Python statements. It needs to be cleared right before call strftime, and optionally the old value needs to be saved first in order to restore it, if you're concerned about that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 18:58:40 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Sep 2015 16:58:40 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442249920.59.0.923714936857.issue25092@psf.upfronthosting.co.za> Steve Dower added the comment: I'm not worried about preserving it - strftime is supposed to be a very thin wrapper around the underlying strftime. I think David's right and we'll be shipping 3.5.1 pretty soon regardless (though a lot of the issues seem to be due to changed installation locations and have existing for a long time, just that the people who regularly change the defaults apparently haven't reported them). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 19:01:24 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Sep 2015 17:01:24 +0000 Subject: [issue25102] Windows installer: 'precompile standard library' option should pre-compile with -O and -OO In-Reply-To: <1442206876.09.0.966951912645.issue25102@psf.upfronthosting.co.za> Message-ID: <1442250084.37.0.239048064946.issue25102@psf.upfronthosting.co.za> Steve Dower added the comment: Right, it's just doing the single pass. You're proposing making a slow part of the install three times slower, correct? Just to confirm :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 19:05:07 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 14 Sep 2015 17:05:07 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442250307.18.0.627840686454.issue25106@psf.upfronthosting.co.za> Brett Cannon added the comment: Is this applicable to Python 3 at all? From Serhiy's comment I think this might be a backport of a technique already used there, but it's not entirely clear as Alecsandru didn't say why there wasn't a 3.6 patch. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 19:09:23 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 14 Sep 2015 17:09:23 +0000 Subject: [issue25102] Windows installer: 'precompile standard library' option should pre-compile with -O and -OO In-Reply-To: <1442206876.09.0.966951912645.issue25102@psf.upfronthosting.co.za> Message-ID: <1442250563.63.0.243819090183.issue25102@psf.upfronthosting.co.za> Zachary Ware added the comment: Steve Dower added the comment: > You're proposing making a slow part of the install three times slower, correct? Just to confirm :) Indeed I am :). Or extend the precompile options to let the user do whatever of the three they want. The precompile option is meant as a startup time optimization. -O and -OO are meant as (very slim) runtime optimizations; it only makes sense that people actually concerned enough to use -O/-OO would rather have their startup time optimized as well. This is pretty low priority, though. ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 19:14:51 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 14 Sep 2015 17:14:51 +0000 Subject: [issue25099] test_compileall fails when run by unprivileged user on installed Python In-Reply-To: <1442205173.06.0.618332067063.issue25099@psf.upfronthosting.co.za> Message-ID: <1442250891.51.0.425716675295.issue25099@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 19:25:48 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 14 Sep 2015 17:25:48 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442251548.55.0.859789163457.issue25106@psf.upfronthosting.co.za> Alecsandru Patrascu added the comment: This patch is not applicable to Python 3, as it already has a better hash function and has the same unrolling technique applied. As Brett well observed, it is a backport of an optimization technique used in Python 3, applied to the existing hash function in 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 19:29:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Sep 2015 17:29:07 +0000 Subject: [issue25108] traceback.extract_stack() compatibility break in 3.5 In-Reply-To: <1442225623.41.0.830396346015.issue25108@psf.upfronthosting.co.za> Message-ID: <1442251747.52.0.685367729983.issue25108@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that restores compatibility. There were no tests for print_stack(), format_stack(), and extract_stack() without arguments. New tests are passed with 3.4. There is a difference between this bug and warnings.warn(stacklevel=) at import time. In the latter the behavior is changed when we specify the stacklevel and we can't workaround this besides change the specified stacklevel depending on Python version. In the former the behavior is changed only when we don't specify a frame. The workaround is version independed: specify the frame explicitly. Therefore we will not break a code with a workaround for 3.5.0, but will fix a code without workaround. ---------- keywords: +patch nosy: +serhiy.storchaka stage: -> patch review Added file: http://bugs.python.org/file40462/traceback_extract_stack.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 19:30:19 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 14 Sep 2015 17:30:19 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442251819.91.0.0656468762803.issue25106@psf.upfronthosting.co.za> Brett Cannon added the comment: If this is applying something we already did in Python 3 and it doesn't break compatibility then this should fall under the same sort of backport exemption that Guido granted for the eval loop performance enhancements that Intel did a couple months back. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 19:34:13 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Sep 2015 17:34:13 +0000 Subject: [issue25099] test_compileall fails when run by unprivileged user on installed Python In-Reply-To: <1442205173.06.0.618332067063.issue25099@psf.upfronthosting.co.za> Message-ID: <1442252053.84.0.822177912898.issue25099@psf.upfronthosting.co.za> Steve Dower added the comment: IIRC there's an existing issue for this. (Or it may have just been mentioned in a "things that don't work when you're not root" list on an issue.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 19:39:10 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 14 Sep 2015 17:39:10 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442252350.37.0.559739096838.issue25106@psf.upfronthosting.co.za> Alecsandru Patrascu added the comment: Yes, it doesn't break the compatibility with existing applications. To make sure, we tested it in various scenarios and workloads. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 19:43:57 2015 From: report at bugs.python.org (Chris Angelico) Date: Mon, 14 Sep 2015 17:43:57 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442252637.28.0.0696208607272.issue25106@psf.upfronthosting.co.za> Chris Angelico added the comment: +1 for anything that makes Python faster with provably no semantic changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 19:48:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Sep 2015 17:48:43 +0000 Subject: [issue25111] Broken compatibility in FrameSummary equality Message-ID: <1442252923.78.0.0672158797601.issue25111@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Since 3.5 traceback.extract_tb() and traceback.extract_stack() return a list (actually list's subclass StackSummary) of FrameSummary objects instead of a list of tuples. FrameSummary is not fully compatible with tuple. One important incompatibility is in the comparing. >>> import traceback >>> traceback.extract_stack()[0] == ('', 1, '', '') Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython-3.5/Lib/traceback.py", line 254, in __eq__ return (self.filename == other.filename and AttributeError: 'tuple' object has no attribute 'filename' In general __eq__ shouldn't raise an exception. Issue25108 is needed to be fixed first for tests. Here is a patch that restores compatibility. An alternative solution would be to make FrameSummary a subclass of tuple (namedtuple). ---------- components: Library (Lib) messages: 250693 nosy: rbcollins, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Broken compatibility in FrameSummary equality type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 19:49:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Sep 2015 17:49:00 +0000 Subject: [issue25111] Broken compatibility in FrameSummary equality In-Reply-To: <1442252923.78.0.0672158797601.issue25111@psf.upfronthosting.co.za> Message-ID: <1442252940.76.0.353209856029.issue25111@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file40463/traceback_FrameSummary_equality.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 19:52:47 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Sep 2015 17:52:47 +0000 Subject: [issue25099] test_compileall fails when run by unprivileged user on installed Python In-Reply-To: <1442205173.06.0.618332067063.issue25099@psf.upfronthosting.co.za> Message-ID: <1442253167.02.0.0634148832084.issue25099@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Existing issue21264 reports about failure of different test. It may be the same issue or different but related issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 20:01:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 14 Sep 2015 18:01:02 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442253662.47.0.816087630568.issue25106@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The code for str and buffer can be shared as _Py_HashBytes() (as in 3.4+). Also please add comments in the switch block as in 3.4+. Should we ask Guido for granting backport exemption for this optimization? ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 20:02:05 2015 From: report at bugs.python.org (Thijs van Dien) Date: Mon, 14 Sep 2015 18:02:05 +0000 Subject: [issue25112] Windows installer assigns non-existent icons to Python file types Message-ID: <1442253725.07.0.74818964148.issue25112@psf.upfronthosting.co.za> New submission from Thijs van Dien: Whenever the Python launcher is selected, the installer sets the icon for common Python file extensions, i.e. .py, .pyc, .pyo, .pyw, .pyz and .pyzw. Formerly (under Python 3.4) the icons were located in DLLs in the Python installation directory. The new installer assigns either py.exe,1 or py.exe,2 as the icon. Because py.exe contains just a single icon, the only valid icon index is 0. As a result of the invalid icon, all Python files show up with either blank or generic icons. Probably those icons have not been included as they should have. Tested on Windows 7 SP1, both X86 and AMD64, both fresh a fresh install and one with quite a bit of history. It occurs with all appropriate Python 3.5 installers (pick any of X86/AMD64 and web/non-web). Make sure the Python launcher is selected; the default settings will do. ---------- components: Installation, Windows files: Screen Shot 2015-09-14 at 20.00.50.png messages: 250696 nosy: paul.moore, steve.dower, thijsvandien, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows installer assigns non-existent icons to Python file types type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file40464/Screen Shot 2015-09-14 at 20.00.50.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 20:02:38 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 14 Sep 2015 18:02:38 +0000 Subject: [issue25099] test_compileall fails when run by unprivileged user on installed Python In-Reply-To: <1442205173.06.0.618332067063.issue25099@psf.upfronthosting.co.za> Message-ID: <1442253758.75.0.470461661853.issue25099@psf.upfronthosting.co.za> Brett Cannon added the comment: It sounds like some tests just need to have a decorator that blocks execution if the relevant __pycache__ isn't writable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 20:14:17 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 14 Sep 2015 18:14:17 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442254457.57.0.469852695919.issue25106@psf.upfronthosting.co.za> Brett Cannon added the comment: Assuming Benjamin doesn't object I don't think we need to explicit ask Guido. He made his feelings quite clear about allowing backports of performance improvements that already exist in Python 3 and have been battle-tested. Having said that, I hope Intel is also looking at Python 3 improvements and not solely backporting stuff to Python 2.7. =) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 20:41:17 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Sep 2015 18:41:17 +0000 Subject: [issue25112] Windows installer assigns non-existent icons to Python file types In-Reply-To: <1442253725.07.0.74818964148.issue25112@psf.upfronthosting.co.za> Message-ID: <1442256077.48.0.24317881842.issue25112@psf.upfronthosting.co.za> Steve Dower added the comment: That is indeed what happened. The resource file for the launcher was not updated (or the update got lost... I was fairly sure I did it) Attached patch fixes it. ---------- assignee: -> steve.dower keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file40465/25112_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 20:44:05 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Sep 2015 18:44:05 +0000 Subject: [issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler In-Reply-To: <1439666438.45.0.776156037138.issue24872@psf.upfronthosting.co.za> Message-ID: <1442256245.26.0.634574474076.issue24872@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 20:53:53 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Sep 2015 18:53:53 +0000 Subject: [issue25102] Windows installer: 'precompile standard library' option should pre-compile with -O and -OO In-Reply-To: <1442206876.09.0.966951912645.issue25102@psf.upfronthosting.co.za> Message-ID: <1442256833.79.0.363908034908.issue25102@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file40466/25102_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 21:03:25 2015 From: report at bugs.python.org (Geoffrey Spear) Date: Mon, 14 Sep 2015 19:03:25 +0000 Subject: [issue24836] Consistent failure in test_email on OS X Snow Leopard buildbot for Python 3.5 In-Reply-To: <1439116162.62.0.659790998501.issue24836@psf.upfronthosting.co.za> Message-ID: <1442257405.26.0.0451044233675.issue24836@psf.upfronthosting.co.za> Changes by Geoffrey Spear : ---------- nosy: +geoffreyspear _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 21:32:14 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 14 Sep 2015 19:32:14 +0000 Subject: [issue25113] documentation version switcher is broken Message-ID: <1442259134.08.0.318415245407.issue25113@psf.upfronthosting.co.za> New submission from Yury Selivanov: The dropdown that allowed to switch the Python version for docs disappeared with py3.5 release. ---------- messages: 250700 nosy: eric.araujo, ezio.melotti, georg.brandl, larry, yselivanov priority: high severity: normal status: open title: documentation version switcher is broken type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 22:42:02 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Sep 2015 20:42:02 +0000 Subject: [issue25074] Bind logger and waninigs modules for asyncio __del__ methods In-Reply-To: <1441998965.13.0.504603864253.issue25074@psf.upfronthosting.co.za> Message-ID: <1442263322.67.0.661123248407.issue25074@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't like such "hacks". IMHO It's too late to try to log errors, to execute code to cleanup objects, etc. You should try to implement something in aiohttp or even in the application to cleanup objects at exit. For example, it's probably wrong if you still have tasks when the event loop is closed. Especially if tasks are still pending. See this part of the doc which lists "pending tasks at exit": https://docs.python.org/dev/library/asyncio-dev.html#chain-coroutines-correctly For "exceptions never consumed", I proposed a different enhancement in asyncio directly: https://bugs.python.org/issue24598 What do you think? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 22:44:34 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 14 Sep 2015 20:44:34 +0000 Subject: [issue25113] documentation version switcher is broken In-Reply-To: <1442259134.08.0.318415245407.issue25113@psf.upfronthosting.co.za> Message-ID: <1442263474.08.0.060251841826.issue25113@psf.upfronthosting.co.za> Berker Peksag added the comment: Looks like version_switch.js is not included into HTML. SPHINXOPTS='-A versionswitcher=1' make -C Doc/ htmlview works for me locally on the 3.5 branch. Perhaps 3.5 docs were created manually or without running "make autobuild-{dev,html,stable}"? ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 22:56:17 2015 From: report at bugs.python.org (paul j3) Date: Mon, 14 Sep 2015 20:56:17 +0000 Subject: [issue25061] Add native enum support for argparse In-Reply-To: <1441908245.42.0.23532628335.issue25061@psf.upfronthosting.co.za> Message-ID: <1442264177.81.0.0770566960303.issue25061@psf.upfronthosting.co.za> paul j3 added the comment: Here's a EnumType factory class, modeled on FileType. class EnumType(object): """Factory for creating enum object types """ def __init__(self, enumclass): self.enums = enumclass def __call__(self, astring): name = self.enums.__name__ try: return self.enums[astring.upper()] except KeyError: msg = ', '.join([t.name.lower() for t in self.enums]) msg = '%s: use one of {%s}'%(name, msg) raise argparse.ArgumentTypeError(msg) def __repr__(self): astr = ', '.join([t.name.lower() for t in self.enums]) return '%s(%s)' % (self.enums.__name__, astr) It would be used like: parser=argparse.ArgumentParser() parser.add_argument("-p", type=EnumType(CustomEnumType), default="VAL1", help = 'type info: %(type)s') 'EnumType(CustomEnumType)' is as close as we are going to get to 'simply passing the enum' to the parser, given the current 'type' syntax. This statement produces a callable object, the equivalent of my previous function. By giving the class a `__repr__` it can also be used in the 'help' with the '%(type)s' syntax. That's the main functionality that this factory adds to my previous function definition. parser.print_help() print(parser.parse_args([])) print(parser.parse_args(["-p","val2"])) print(parser.parse_args(["-p","val4"])) produces usage: issue25061.py [-h] [-p P] optional arguments: -h, --help show this help message and exit -p P type info: CustomEnumType(val1, val2, val3) Namespace(p=) Namespace(p=) usage: issue25061.py [-h] [-p P] issue25061.py: error: argument -p: CustomEnumType: use one of {val1, val2, val3} I was toying with writing a custom Action class that would create its own type and help attributes based on the enum parameter. But since this EnumType.__repr__ takes care of the help angle, I don't think I'll bother. If there's enough interest, I can imagine casting this EnumType as a formal patch, complete with tests and documentation. Till then, feel free to experiment with and refine these ideas. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 14 23:53:50 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 14 Sep 2015 21:53:50 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442267630.72.0.888874342428.issue25106@psf.upfronthosting.co.za> Gregory P. Smith added the comment: attaching an updated patch. fwiw, in my own quick tests i'm not seeing a performance difference on the benchmark suite. but i am not trying to run it in such an isolated quiet machine locked freq. environment. it is still a good idea regardless. _some_ compilers really benefit from the manually unrolling. any that already unrolled things themselves should not care. ---------- Added file: http://bugs.python.org/file40467/hash8-v03-gps01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 00:00:47 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Sep 2015 22:00:47 +0000 Subject: [issue25114] asynico: add ssl_object extra info Message-ID: <1442268047.01.0.688232314675.issue25114@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch adds the "ssl_object" extra information to SSL sockets. For the legacy SSL implementation, it's a ssl.SSLSocket instance. For the new SSL implementation, it's a ssl.SSLObject instance. ssl.SSLObject and ssl.SSLSocket have a similar but different API. Both classes provide important methods like getpeercert(). This issue fixes a regressions of Python 3.5 compared to Python 3.4 in asyncio SSL sockets: it's no more possible to get the peer certificate as a binary object (only as text). See the issue #22768. My patch adds also unit tests on SSL extra info. We only had poor unit tests on these info. ---------- components: asyncio files: ssl_object.patch keywords: patch messages: 250705 nosy: gvanrossum, haypo, mathieui, yselivanov priority: normal severity: normal status: open title: asynico: add ssl_object extra info versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40468/ssl_object.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 00:02:11 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Sep 2015 22:02:11 +0000 Subject: [issue25114] asynico: add ssl_object extra info In-Reply-To: <1442268047.01.0.688232314675.issue25114@psf.upfronthosting.co.za> Message-ID: <1442268131.8.0.538504481052.issue25114@psf.upfronthosting.co.za> STINNER Victor added the comment: Workaround for Python 3.5.0: force the legacy SSL implementation. For example, monkey patch the asyncio module with: asyncio.sslproto._is_sslproto_availabe=lambda: False ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 00:02:34 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Sep 2015 22:02:34 +0000 Subject: [issue22768] Add a way to get the peer certificate of a SSL Transport In-Reply-To: <1414693136.26.0.003644122895.issue22768@psf.upfronthosting.co.za> Message-ID: <1442268154.23.0.39533816198.issue22768@psf.upfronthosting.co.za> STINNER Victor added the comment: In Python 3.5, it's no more possible to get the peer certificate as binary. See the issue #25114 for a general fix. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 00:02:54 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Sep 2015 22:02:54 +0000 Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?= =?utf-8?q?env_with_--system-site-package?= In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za> Message-ID: <1442268174.09.0.244086023671.issue24875@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 00:05:30 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Sep 2015 22:05:30 +0000 Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?= =?utf-8?q?env_with_--system-site-package?= In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za> Message-ID: <1442268330.97.0.0797482490259.issue24875@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 00:13:10 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Sep 2015 22:13:10 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442268790.16.0.534875117754.issue25092@psf.upfronthosting.co.za> Steve Dower added the comment: Patch attached. I haven't been able to repro the issue locally without the fix, but it seems indisputably correct behavior. We could also skip most of the function for an empty format string and save ourselves a lot of work. That would avoid the ambiguous returned "is it zero-length or is it an error" value. ---------- keywords: +patch Added file: http://bugs.python.org/file40469/25092_1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 00:13:29 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Sep 2015 22:13:29 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442268809.58.0.63577120423.issue25092@psf.upfronthosting.co.za> Steve Dower added the comment: (The fix is indisputably correct, is what I meant.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 00:14:39 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Sep 2015 22:14:39 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442268879.55.0.989833591663.issue25092@psf.upfronthosting.co.za> STINNER Victor added the comment: +#if defined _MSC_VER && _MSC_VER >= 1400 && defined(__STDC_SECURE_LIB__) + errno = 0; +#endif This code is too complex. Please remove the #if and always set errno to 0, on any platform! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 00:27:29 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Sep 2015 22:27:29 +0000 Subject: [issue25096] test_gdb failed to read version for gdb >= 7.10 In-Reply-To: <1442203585.89.0.599357729495.issue25096@psf.upfronthosting.co.za> Message-ID: <1442269649.53.0.0446282336166.issue25096@psf.upfronthosting.co.za> STINNER Victor added the comment: Fixed by changesets 21d6b2752fe8 (2.7) and 6a8aa246485e (3.4). Thanks for your bug report and your patch! ---------- nosy: +haypo resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 00:34:50 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Sep 2015 22:34:50 +0000 Subject: [issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x) In-Reply-To: <1442151642.39.0.456899707142.issue25084@psf.upfronthosting.co.za> Message-ID: <1442270090.16.0.868828822324.issue25084@psf.upfronthosting.co.za> STINNER Victor added the comment: As you noticed, this issue was correctly fixed in Python 3 by using the C timed acquire methods of locks, instead of polling. The problem is that Python 2 supports a wide range of threading models: Python/thread_atheos.h Python/thread_beos.h Python/thread_cthread.h Python/thread_lwp.h Python/thread_nt.h Python/thread_os2.h Python/thread_pth.h Python/thread_pthread.h Python/thread_sgi.h Python/thread_solaris.h Python/thread_wince.h In Python 3, it was possible to use more features of OS threads because we dropped all implementations to only keep the 2 major implementations: Python/thread_nt.h Python/thread_pthread.h Your change adds a new feature to threading.Lock in Python 2: -.. method:: Lock.acquire([blocking]) +.. method:: Lock.acquire(blocking=True, timeout=-1) But features cannot be added to Python 2 anymore! The backport changes critical C code. There is a (high) risk of introducing a regression. I suggest to close this issue as WONTFIX. @Benjamin (Python 2.7 release manager): What do you think? In 2015, it's time to upgrade to Python 3! https://docs.python.org/3/howto/pyporting.html ---------- nosy: +benjamin.peterson, haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 00:39:56 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Sep 2015 22:39:56 +0000 Subject: [issue24391] Better repr for threading objects In-Reply-To: <1433586102.76.0.662503832113.issue24391@psf.upfronthosting.co.za> Message-ID: <1442270396.9.0.529357766711.issue24391@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 00:42:32 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 14 Sep 2015 22:42:32 +0000 Subject: [issue25077] Compiler warnings: initialization from incompatible pointer type In-Reply-To: <1442042610.13.0.957335882034.issue25077@psf.upfronthosting.co.za> Message-ID: <1442270552.93.0.71879685432.issue25077@psf.upfronthosting.co.za> STINNER Victor added the comment: For ceval, it comes from pyatomic.h: see my atomic_pointer.patch attached to the issue #25077. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 01:18:47 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 14 Sep 2015 23:18:47 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442272727.98.0.262903733518.issue25092@psf.upfronthosting.co.za> Steve Dower added the comment: We don't check errno on any other platform. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 01:45:20 2015 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 14 Sep 2015 23:45:20 +0000 Subject: [issue25108] traceback.extract_stack() compatibility break in 3.5 In-Reply-To: <1442225623.41.0.830396346015.issue25108@psf.upfronthosting.co.za> Message-ID: <1442274320.92.0.75497784385.issue25108@psf.upfronthosting.co.za> Nick Coghlan added the comment: Serhiy's explanation and fix look good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 02:05:30 2015 From: report at bugs.python.org (Felipe) Date: Tue, 15 Sep 2015 00:05:30 +0000 Subject: [issue23078] unittest.mock patch autospec doesn't work on staticmethods In-Reply-To: <1418892323.1.0.910322233262.issue23078@psf.upfronthosting.co.za> Message-ID: <1442275530.05.0.174463317022.issue23078@psf.upfronthosting.co.za> Felipe added the comment: The attached patch implements these changes through _callable instead. This patch also ensures that the underlying object that staticmethod and classmethod wrap is a callable object as well. ---------- Added file: http://bugs.python.org/file40470/issue23078.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 02:37:26 2015 From: report at bugs.python.org (Robert Collins) Date: Tue, 15 Sep 2015 00:37:26 +0000 Subject: [issue25108] traceback.extract_stack() compatibility break in 3.5 In-Reply-To: <1442225623.41.0.830396346015.issue25108@psf.upfronthosting.co.za> Message-ID: <1442277446.52.0.975521424003.issue25108@psf.upfronthosting.co.za> Robert Collins added the comment: wouldn't changing walk_stack to add one more f_back be better? Seems odd to work around it... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 03:31:16 2015 From: report at bugs.python.org (Grant Bremer) Date: Tue, 15 Sep 2015 01:31:16 +0000 Subject: [issue25115] SSL_set_verify_depth not exposed by the ssl module Message-ID: <1442280676.76.0.937947035148.issue25115@psf.upfronthosting.co.za> New submission from Grant Bremer: The SSL_set_verify_depth OpenSSL method is not currently exposed by the ssl module. The context object would seem to be the proper place for it as an instance method. ---------- components: Library (Lib) messages: 250718 nosy: Grant Bremer priority: normal severity: normal status: open title: SSL_set_verify_depth not exposed by the ssl module type: enhancement versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 04:31:56 2015 From: report at bugs.python.org (Grant Bremer) Date: Tue, 15 Sep 2015 02:31:56 +0000 Subject: [issue25115] SSL_set_verify_depth not exposed by the ssl module In-Reply-To: <1442280676.76.0.937947035148.issue25115@psf.upfronthosting.co.za> Message-ID: <1442284316.11.0.0914100921546.issue25115@psf.upfronthosting.co.za> Changes by Grant Bremer : ---------- hgrepos: +316 keywords: +patch Added file: http://bugs.python.org/file40471/verify_depth.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 05:53:43 2015 From: report at bugs.python.org (Kevin Zhang) Date: Tue, 15 Sep 2015 03:53:43 +0000 Subject: [issue25116] It failed to install Py3.5 on win2008R2 Message-ID: <1442289223.22.0.363627873073.issue25116@psf.upfronthosting.co.za> New submission from Kevin Zhang: OS: Windows Server 2008 R2 Enterprise I'm remote desktop to the server and try to install Python3.5 released version. Remote desktop user/privilege: administrator There is no window about installation pop up after I double clicked python-3.5.0.exe. I could provide more info as you need. ---------- components: Installation messages: 250719 nosy: Kevin Zhang priority: normal severity: normal status: open title: It failed to install Py3.5 on win2008R2 versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 05:56:40 2015 From: report at bugs.python.org (Kevin Zhang) Date: Tue, 15 Sep 2015 03:56:40 +0000 Subject: [issue25116] It failed to install Py3.5 on win2008R2 In-Reply-To: <1442289223.22.0.363627873073.issue25116@psf.upfronthosting.co.za> Message-ID: <1442289400.53.0.231584996529.issue25116@psf.upfronthosting.co.za> Kevin Zhang added the comment: I have installed Python2.7 and Python3.4 on this server before. Python3.4 installation works well after I failed to executed python-3.5.0.exe. Thanks again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 06:12:17 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 15 Sep 2015 04:12:17 +0000 Subject: [issue25095] test_httpservers hangs on 3.5.0, win 7 In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za> Message-ID: <1442290337.78.0.297117850478.issue25095@psf.upfronthosting.co.za> Martin Panter added the comment: Can you identify which test case hangs? E.g. on Linux I can run the following to see each test case run: ./python -m unittest -v test.test_httpservers ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 07:26:59 2015 From: report at bugs.python.org (Marius Gedminas) Date: Tue, 15 Sep 2015 05:26:59 +0000 Subject: [issue25117] Windows installer: precompiling stdlib fails with missing DLL errors Message-ID: <1442294819.71.0.839651529049.issue25117@psf.upfronthosting.co.za> New submission from Marius Gedminas: I installed Python 3.5 on a Windows Server 2012 VM, twice (once the 32-bit, and once the 64-bit version). When it started throwing error dialogs at me, I started taking screenshots: http://imgur.com/a/zwfz4. What happened: - I selected advanced installation - checked "install for all users" - changed the install path to c:\python35 (and c:\python35-64) - when the installer reached "Precompiling standard library" I got the error: "Python has stopped working". - clicking "check online for a solution" produces this explanation: "api-ms-win-crt-runtime-l1-1-0.dll is missing from your computer". - dismissing the error dialog leads the installer to say the installation is finished (presumably successfully); Python seems to work. (The last dialog about VCRUNTIME140.dll is unrelated -- it's what happens if I try to use Python 3.7 to run virtualenv to create a Python 3.5 virtualenv. I'll file a separate bug, once I figure out if it's a Python or a virtualenv bug.) ---------- components: Installation messages: 250722 nosy: mgedmin priority: normal severity: normal status: open title: Windows installer: precompiling stdlib fails with missing DLL errors versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 07:35:56 2015 From: report at bugs.python.org (Aaron Meurer) Date: Tue, 15 Sep 2015 05:35:56 +0000 Subject: [issue25117] Windows installer: precompiling stdlib fails with missing DLL errors In-Reply-To: <1442294819.71.0.839651529049.issue25117@psf.upfronthosting.co.za> Message-ID: <1442295356.16.0.341972195116.issue25117@psf.upfronthosting.co.za> Changes by Aaron Meurer : ---------- nosy: +Aaron.Meurer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 07:52:11 2015 From: report at bugs.python.org (Rocco Matano) Date: Tue, 15 Sep 2015 05:52:11 +0000 Subject: [issue25118] OSError in os.waitpid Message-ID: <1442296331.17.0.794192242028.issue25118@psf.upfronthosting.co.za> New submission from Rocco Matano: On windows and python up to 3.4 using the combination of os.spawnX(os.P_NOWAIT, ...) and os.waitpid() worked as expected, but with python 3.5 this no longer works. In fact os.waitpid() now raises an OSError when the child process terminates. Running this simple script demonstrates that: import sys import os import time print(sys.version) file = r'c:\windows\system32\cmd.exe' args = [file, '/C', 'ping', '1.1.1.1', '-n', '1', '>NUL'] env = os.environ t0 = time.time() ret = os.spawnve(os.P_NOWAIT, file, args, env) pid, status = os.waitpid(ret, 0) t1 = time.time() print("process took %.1f seconds" % (t1 - t0)) I get the following outputs: C:\Users\rmatano\test_py35>py -3.4 test_waitpid.py 3.4.0 (v3.4.0:04f714765c13, Mar 16 2014, 19:25:23) [MSC v.1600 64 bit (AMD64)] process took 3.6 seconds C:\Users\rmatano\test_py35>py -3.5 test_waitpid.py 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit (AMD64)] Traceback (most recent call last): File "twp.py", line 13, in pid, status = os.waitpid(ret, 0) OSError: [Errno 0] Error I guess this is a bug rather than a intended change in behavior, isn't it? ---------- components: Library (Lib) messages: 250723 nosy: rocco.matano priority: normal severity: normal status: open title: OSError in os.waitpid type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 08:03:20 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 15 Sep 2015 06:03:20 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442297000.61.0.916620817665.issue25106@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Testing this on a host with a fixed frequency and mostx background tasks disabled I cannot reproduce the speedups you list. I see no significant change on most of them and a 6% slowdown on json_load and a 1-4% slowdown on regex_v8 (not sure if those are in the noise) I suspect your comparison was including other patches or was not built the same. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 08:37:02 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 15 Sep 2015 06:37:02 +0000 Subject: [issue25095] test_httpservers hangs on 3.5.0, win 7 In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za> Message-ID: <1442299022.94.0.599574482963.issue25095@psf.upfronthosting.co.za> Terry J. Reedy added the comment: test_get (test.test_httpservers.RequestHandlerLoggingTestCase) ... same on repeat ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 08:46:13 2015 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 15 Sep 2015 06:46:13 +0000 Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?= =?utf-8?q?env_with_--system-site-package?= In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za> Message-ID: <1442299573.85.0.637133279243.issue24875@psf.upfronthosting.co.za> Vinay Sajip added the comment: I don't believe this is a pyvenv bug: pyvenv invokes bin/python -Im ensurepip --upgrade --default-pip -v which then terminates with Requirement already up-to-date: pip in /usr/lib/python3.4/site-packages as you can see from the console output. So the problem appears to be with ensurepip - all the pyvenv script does is to invoke ensurepip. Adding dstufft to nosy. ---------- nosy: +dstufft _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 09:17:17 2015 From: report at bugs.python.org (Flavio Grossi) Date: Tue, 15 Sep 2015 07:17:17 +0000 Subject: [issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x) In-Reply-To: <1442151642.39.0.456899707142.issue25084@psf.upfronthosting.co.za> Message-ID: <1442301437.71.0.57707149835.issue25084@psf.upfronthosting.co.za> Flavio Grossi added the comment: First of all, thank you for your support. I fully understand what you are saying, however, being stuck to python 2.7 because of libraries still not ported to 3, this is a serious problem to us, and, while i agree this would introduce a new "feature", it also fixes a bug which in some cases renders some functionalities (Queue.get() for example) not very usable as it is. Is there any chance this will be fixed? Or even having the remaining thread implementations fixed will lead to reject this? Thank you ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 09:24:41 2015 From: report at bugs.python.org (eryksun) Date: Tue, 15 Sep 2015 07:24:41 +0000 Subject: [issue25118] OSError in os.waitpid In-Reply-To: <1442296331.17.0.794192242028.issue25118@psf.upfronthosting.co.za> Message-ID: <1442301881.82.0.173957676531.issue25118@psf.upfronthosting.co.za> eryksun added the comment: This bug is due to issue 23285, which improved support for EINTR handling. os_waitpid_impl was changed to use the following do-while loop: do { Py_BEGIN_ALLOW_THREADS res = _cwait(&status, pid, options); Py_END_ALLOW_THREADS } while (res < 0 && errno == EINTR && !(async_err = PyErr_CheckSignals())); if (res != 0) return (!async_err) ? posix_error() : NULL; The last test should be (res < 0) instead of (res != 0). That's why you're getting a no-error exception. It seems to me this entire loop should be removed. The Windows C runtime doesn't set errno to EINTR. In the case of _cwait it doesn't even use an alertable wait (i.e. it can't be interrupted by a regular asynchronous procedure call). ---------- components: +Windows nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 09:34:14 2015 From: report at bugs.python.org (matteo) Date: Tue, 15 Sep 2015 07:34:14 +0000 Subject: [issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x) In-Reply-To: <1442151642.39.0.456899707142.issue25084@psf.upfronthosting.co.za> Message-ID: <1442302454.87.0.995987981957.issue25084@psf.upfronthosting.co.za> Changes by matteo : ---------- nosy: +matteo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 09:38:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Sep 2015 07:38:49 +0000 Subject: [issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x) In-Reply-To: <1442301437.71.0.57707149835.issue25084@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: 2015-09-15 9:17 GMT+02:00 Flavio Grossi : > however, being stuck to python 2.7 because of libraries still not ported to 3, this is a serious problem to us, Are there private libraries or public libraries? If there are public, what are these libraries. I ported a lot of libraries last year, more and more libraries are compatible with Python 3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:02:16 2015 From: report at bugs.python.org (Larry Hastings) Date: Tue, 15 Sep 2015 08:02:16 +0000 Subject: [issue25113] documentation version switcher is broken In-Reply-To: <1442259134.08.0.318415245407.issue25113@psf.upfronthosting.co.za> Message-ID: <1442304136.95.0.841860243122.issue25113@psf.upfronthosting.co.za> Larry Hastings added the comment: When I built the documentation, I used % release.py --export 3.5.0 (release.py coming from hg.python.org/release, a collection of release manager tools.) I then installed this build as the 3.5.0 documentation, specifically the build from "python-3.5.0-docs-html.tar.bz2". I do that so that people don't complain "hey the documentation is out of date!" when the release goes live. I wouldn't be surprised if the version picker is suppressed in this build, as it's intended to be installed by users. However, there's a cron job that rebuilds the documentation automatically. I'm not sure how often, but I think it's every couple of hours. That build process, whatever it is, should definitely enable the version picker. Normally the cron job would have overwritten the docs by now. However I just discovered I left the docs non-group-writeable when I installed them, which meant the cron job couldn't overwrite them. I just fixed that, and hopefully within a couple of hours the cron job will awake from its slumber and overwrite everything. tl;dr: Hopefully it'll silently fix itself sometime today. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:06:25 2015 From: report at bugs.python.org (Georg Brandl) Date: Tue, 15 Sep 2015 08:06:25 +0000 Subject: [issue25113] documentation version switcher is broken In-Reply-To: <1442259134.08.0.318415245407.issue25113@psf.upfronthosting.co.za> Message-ID: <1442304385.26.0.861298466218.issue25113@psf.upfronthosting.co.za> Georg Brandl added the comment: This is what PEP 101 has to say: ___ If this is a final release (even a maintenance release), also unpack the HTML docs to /srv/docs.python.org/release/X.Y.Z on docs.iad1.psf.io. Make sure the files are in group "docs". If it is a release of a security-fix-only version, tell the DE to build a version with the "version switcher" and put it there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:07:25 2015 From: report at bugs.python.org (Georg Brandl) Date: Tue, 15 Sep 2015 08:07:25 +0000 Subject: [issue25113] documentation version switcher is broken In-Reply-To: <1442259134.08.0.318415245407.issue25113@psf.upfronthosting.co.za> Message-ID: <1442304445.75.0.63665368389.issue25113@psf.upfronthosting.co.za> Changes by Georg Brandl : ---------- Removed message: http://bugs.python.org/msg250731 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:07:33 2015 From: report at bugs.python.org (Georg Brandl) Date: Tue, 15 Sep 2015 08:07:33 +0000 Subject: [issue25113] documentation version switcher is broken In-Reply-To: <1442259134.08.0.318415245407.issue25113@psf.upfronthosting.co.za> Message-ID: <1442304453.26.0.995336467309.issue25113@psf.upfronthosting.co.za> Georg Brandl added the comment: NM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:10:15 2015 From: report at bugs.python.org (Marius Gedminas) Date: Tue, 15 Sep 2015 08:10:15 +0000 Subject: [issue25119] Windows installer fails to install VCRUNTIME140.DLL Message-ID: <1442304615.44.0.515104060995.issue25119@psf.upfronthosting.co.za> New submission from Marius Gedminas: 1. Install Python 3.5 using the official Windows installer 2. Get a shell 3. python -m ensurepip (because the installer didn't install pip for me -- is that another bug? I thought the installer was supposed to run ensurepip for me? Is it fallout from bug 25117?) 4. python -m pip install virtualenv (gets me version 13.1.2) 5. python -m virtualenv env I expect: a virtualenv in ./env I get: a GUI error dialog saying "The program can't start because VCRUNTIME140.dll is missing from your computer." ---------- components: Installation messages: 250733 nosy: mgedmin priority: normal severity: normal status: open title: Windows installer fails to install VCRUNTIME140.DLL versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:13:10 2015 From: report at bugs.python.org (Djoudi Benarfa) Date: Tue, 15 Sep 2015 08:13:10 +0000 Subject: [issue25120] Python want Message-ID: <1442304790.82.0.947550272031.issue25120@psf.upfronthosting.co.za> Changes by Djoudi Benarfa : ---------- components: Installation files: py-install-xp.bmp nosy: djoudi, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Python want type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file40472/py-install-xp.bmp _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:15:05 2015 From: report at bugs.python.org (Djoudi Benarfa) Date: Tue, 15 Sep 2015 08:15:05 +0000 Subject: [issue25120] Python want Message-ID: <1442304905.6.0.742389878117.issue25120@psf.upfronthosting.co.za> New submission from Djoudi Benarfa: The Python installation on Windows XP has a bizarre behavior. No option is displayed in the first window of the installer (See attached screen capture). but when I click blindly in the empty space, the installer continue to the next window. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:15:49 2015 From: report at bugs.python.org (Djoudi Benarfa) Date: Tue, 15 Sep 2015 08:15:49 +0000 Subject: [issue25120] Python install on windows XP In-Reply-To: <1442304905.6.0.742389878117.issue25120@psf.upfronthosting.co.za> Message-ID: <1442304949.39.0.884949783721.issue25120@psf.upfronthosting.co.za> Changes by Djoudi Benarfa : ---------- title: Python want -> Python install on windows XP _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:23:14 2015 From: report at bugs.python.org (Djoudi Benarfa) Date: Tue, 15 Sep 2015 08:23:14 +0000 Subject: [issue25120] No option displayed in the Python install on windows XP In-Reply-To: <1442304905.6.0.742389878117.issue25120@psf.upfronthosting.co.za> Message-ID: <1442305394.84.0.966085029221.issue25120@psf.upfronthosting.co.za> Changes by Djoudi Benarfa : ---------- title: Python install on windows XP -> No option displayed in the Python install on windows XP _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:26:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Sep 2015 08:26:31 +0000 Subject: [issue25118] OSError in os.waitpid In-Reply-To: <1442296331.17.0.794192242028.issue25118@psf.upfronthosting.co.za> Message-ID: <20150915082628.114789.72012@psf.io> Roundup Robot added the comment: New changeset 9a80c687c28d by Victor Stinner in branch '3.5': Issue #25118: Fix a regression of Python 3.5.0 in os.waitpid() on Windows. https://hg.python.org/cpython/rev/9a80c687c28d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:26:54 2015 From: report at bugs.python.org (Larry Hastings) Date: Tue, 15 Sep 2015 08:26:54 +0000 Subject: [issue25120] No option displayed in the Python install on windows XP In-Reply-To: <1442304905.6.0.742389878117.issue25120@psf.upfronthosting.co.za> Message-ID: <1442305614.28.0.200788576949.issue25120@psf.upfronthosting.co.za> Larry Hastings added the comment: Python 3.5 is not supported on Windows XP. The Python core dev team's policy is, a major Python version (e.g. 3.4, 3.5) only supports the Windows versions that are currently supported by Microsoft at the time of the initial release (e.g. 3.4.0 final, 3.5.0 final): https://www.python.org/dev/peps/pep-0011/#microsoft-windows Microsoft ended support for Windows XP on April 8, 2014: http://windows.microsoft.com/en-GB/windows/lifecycle Python 3.5.0 final was released on September 13, 2015, seventeen months later. Therefore, Python 3.5 is the first Python release to drop support for Windows XP. ---------- nosy: +larry resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:28:22 2015 From: report at bugs.python.org (eryksun) Date: Tue, 15 Sep 2015 08:28:22 +0000 Subject: [issue25120] No option displayed in the Python install on windows XP In-Reply-To: <1442304905.6.0.742389878117.issue25120@psf.upfronthosting.co.za> Message-ID: <1442305702.43.0.931552911044.issue25120@psf.upfronthosting.co.za> eryksun added the comment: Maybe the download page should direct XP users to install 3.4.x. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:34:16 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Sep 2015 08:34:16 +0000 Subject: [issue25118] OSError in os.waitpid In-Reply-To: <1442296331.17.0.794192242028.issue25118@psf.upfronthosting.co.za> Message-ID: <1442306056.21.0.296612392667.issue25118@psf.upfronthosting.co.za> STINNER Victor added the comment: Oops :-/ Yet another Python 3.5.0 regression, it's now fixed. os.waitpid() was not tested at all on Windows. os.waitpid() is not the best option to wait for a subprocess completion. By the way, you should use the subprocess module which is more portable, is widely used, etc. IMHO os.spawn*() is more kept for backward compatibility. > It seems to me this entire loop should be removed. The Windows C runtime doesn't set errno to EINTR. In the case of _cwait it doesn't even use an alertable wait (i.e. it can't be interrupted by a regular asynchronous procedure call). Well, it looks like you are right: _cwait() cannot be interrupted on Windows. But I chose to only fix the if() after the loop... just in case. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:34:47 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Sep 2015 08:34:47 +0000 Subject: [issue25118] OSError in os.waitpid() on Windows [3.5.0 regression] In-Reply-To: <1442296331.17.0.794192242028.issue25118@psf.upfronthosting.co.za> Message-ID: <1442306087.06.0.731139632932.issue25118@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed title: OSError in os.waitpid -> OSError in os.waitpid() on Windows [3.5.0 regression] versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:38:38 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Sep 2015 08:38:38 +0000 Subject: [issue25095] test_httpservers hangs on 3.5.0, win 7 In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za> Message-ID: <1442306318.86.0.726454075305.issue25095@psf.upfronthosting.co.za> STINNER Victor added the comment: Where does it hang? For example, try to run the test using: python.exe -m test -v --timeout=10 test_httpservers Can it be a firewall or antivirus issue? Try to add some print() in TestServerThread.run() to check if the HTTP server is running or not. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:39:25 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Sep 2015 08:39:25 +0000 Subject: [issue25116] It failed to install Py3.5 on win2008R2 In-Reply-To: <1442289223.22.0.363627873073.issue25116@psf.upfronthosting.co.za> Message-ID: <1442306365.41.0.951512364831.issue25116@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:39:47 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Sep 2015 08:39:47 +0000 Subject: [issue25115] SSL_set_verify_depth not exposed by the ssl module In-Reply-To: <1442280676.76.0.937947035148.issue25115@psf.upfronthosting.co.za> Message-ID: <1442306387.37.0.815487971812.issue25115@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:40:09 2015 From: report at bugs.python.org (Djoudi Benarfa) Date: Tue, 15 Sep 2015 08:40:09 +0000 Subject: [issue25120] No option displayed in the Python install on windows XP In-Reply-To: <1442304905.6.0.742389878117.issue25120@psf.upfronthosting.co.za> Message-ID: <1442306409.36.0.471104425357.issue25120@psf.upfronthosting.co.za> Djoudi Benarfa added the comment: Thanks for your response, I didn't know it. +1 eryksun, this should be mentioned in python website. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:43:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Sep 2015 08:43:17 +0000 Subject: [issue25115] SSL_set_verify_depth not exposed by the ssl module In-Reply-To: <1442280676.76.0.937947035148.issue25115@psf.upfronthosting.co.za> Message-ID: <1442306597.29.0.036543212755.issue25115@psf.upfronthosting.co.za> STINNER Victor added the comment: + if (depth < 0 || depth > 100) { Why 100 and not 10 or 1000? SSL_CTX_set_verify_depth() is unable to check the depth? The patch lacks unit tests and documentation. The patch is for Python 2.7, it would be better to write a patch for the default branch (future Python 3.6). ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:45:59 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Sep 2015 08:45:59 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442306759.15.0.499406490988.issue25092@psf.upfronthosting.co.za> STINNER Victor added the comment: > We don't check errno on any other platform. Oh ok. The code becomes more and more verbose because of Windows :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:47:30 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Sep 2015 08:47:30 +0000 Subject: [issue25103] 3.5.0 installed standard library on Windows has LF line endings In-Reply-To: <1442208824.41.0.568116526355.issue25103@psf.upfronthosting.co.za> Message-ID: <1442306850.45.0.278478763659.issue25103@psf.upfronthosting.co.za> STINNER Victor added the comment: > It would be nice to install the standard library (and test suite) with CRLF line endings, to allow for reading/editing with Notepad. Oh maybe Windows can realized in 2015 that other operating systems use different line ending and enhance notepad to be more "portable"? :-p ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:48:21 2015 From: report at bugs.python.org (Larry Hastings) Date: Tue, 15 Sep 2015 08:48:21 +0000 Subject: [issue25103] 3.5.0 installed standard library on Windows has LF line endings In-Reply-To: <1442208824.41.0.568116526355.issue25103@psf.upfronthosting.co.za> Message-ID: <1442306901.8.0.0893242722204.issue25103@psf.upfronthosting.co.za> Larry Hastings added the comment: Is this a change (I hesitate to use the word "regression") as of Python 3.5.0? ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:48:34 2015 From: report at bugs.python.org (eryksun) Date: Tue, 15 Sep 2015 08:48:34 +0000 Subject: [issue25119] Windows installer fails to install VCRUNTIME140.DLL In-Reply-To: <1442304615.44.0.515104060995.issue25119@psf.upfronthosting.co.za> Message-ID: <1442306914.99.0.321351266096.issue25119@psf.upfronthosting.co.za> eryksun added the comment: virtualenv fails to copy vcruntime140.dll. Use the standard library's venv module instead. ---------- nosy: +eryksun resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:53:49 2015 From: report at bugs.python.org (Larry Hastings) Date: Tue, 15 Sep 2015 08:53:49 +0000 Subject: [issue25120] No option displayed in the Python install on windows XP In-Reply-To: <1442304905.6.0.742389878117.issue25120@psf.upfronthosting.co.za> Message-ID: <1442307229.56.0.373900568842.issue25120@psf.upfronthosting.co.za> Larry Hastings added the comment: That's an interesting thought, eryksun. I'll pass it along to the python.org web developers. Djoudi, it is mentioned on the Python web site, in the What's New In Python 3.5 document: https://docs.python.org/3.5/whatsnew/3.5.html#unsupported-operating-systems ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:57:34 2015 From: report at bugs.python.org (Alexander Belchenko) Date: Tue, 15 Sep 2015 08:57:34 +0000 Subject: [issue25121] python logger can't wrap log file and blows with traceback Message-ID: <1442307454.43.0.792328825134.issue25121@psf.upfronthosting.co.za> New submission from Alexander Belchenko: We're using standard logging library for logs. On machine of my colleague there is constantly traceback like this: [11:21:29] PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: 'C:\\Users\\Andrew\\Desktop\\server\\logs\\2015-0 9-09_10-44-03\\2015-09-09_10-44-04-middleman-684.log.1' Logged from file middleman.py, line 379 Traceback (most recent call last): File "c:\python33\lib\logging\handlers.py", line 73, in emit self.doRollover() File "c:\python33\lib\logging\handlers.py", line 176, in doRollover self.rotate(self.baseFilename, dfn) File "c:\python33\lib\logging\handlers.py", line 116, in rotate os.rename(source, dest) middleman.py, line 379 is simple call to logger.debug: self.logger.debug('node %s is already processing, packet %s postponed', node_id, packet_no) It's strange that another log file with different basename in the same logs directory is wrapping without problems. Anyway, my complain is about traceback. I don't think it's good behavior that my application crashes because logging library can't wrap file. The problem for me - I have no idea how to catch and ignore such problem, because it's in the logging internals. ---------- components: Library (Lib), Windows messages: 250747 nosy: bialix, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: python logger can't wrap log file and blows with traceback type: crash versions: Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 10:59:08 2015 From: report at bugs.python.org (Djoudi Benarfa) Date: Tue, 15 Sep 2015 08:59:08 +0000 Subject: [issue25120] No option displayed in the Python install on windows XP In-Reply-To: <1442304905.6.0.742389878117.issue25120@psf.upfronthosting.co.za> Message-ID: <1442307548.62.0.232557923414.issue25120@psf.upfronthosting.co.za> Djoudi Benarfa added the comment: I got it, thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 11:04:45 2015 From: report at bugs.python.org (Alexander Belchenko) Date: Tue, 15 Sep 2015 09:04:45 +0000 Subject: [issue25121] python logger can't wrap log file and blows with traceback In-Reply-To: <1442307454.43.0.792328825134.issue25121@psf.upfronthosting.co.za> Message-ID: <1442307885.63.0.841378255545.issue25121@psf.upfronthosting.co.za> Alexander Belchenko added the comment: PermissionError mentions file name "C:\\Users\\Andrew\\Desktop\\server\\logs\\2015-0 9-09_10-44-03\\2015-09-09_10-44-04-middleman-684.log.1" - but this file does not exist in log directory. There is only "C:\\Users\\Andrew\\Desktop\\server\\logs\\2015-0 9-09_10-44-03\\2015-09-09_10-44-04-middleman-684.log" so I think it's about unable to rename. Python 3.3.5 64 bits Windows 7 64 bits. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 11:07:49 2015 From: report at bugs.python.org (Flavio Grossi) Date: Tue, 15 Sep 2015 09:07:49 +0000 Subject: [issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x) In-Reply-To: <1442151642.39.0.456899707142.issue25084@psf.upfronthosting.co.za> Message-ID: <1442308069.06.0.450810640428.issue25084@psf.upfronthosting.co.za> Flavio Grossi added the comment: >> however, being stuck to python 2.7 because of libraries > Are there private libraries or public libraries? It is a mix of public and internal libraries with the main public blockers being twisted and apache thrift (and other libs which have py3 alternatives but don't have retrocompatible apis). (Yes, twisted is almost supported, but still has some parts not ready for python 3) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 11:58:19 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 15 Sep 2015 09:58:19 +0000 Subject: [issue25095] test_httpservers hangs on 3.5.0, win 7 In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za> Message-ID: <1442311099.43.0.872063216585.issue25095@psf.upfronthosting.co.za> Terry J. Reedy added the comment: test_get (test.test_httpservers.RequestHandlerLoggingTestCase) ... Timeout (0:00:10)! Thread 0x00001654 (most recent call first): File "C:\Programs\Python35\lib\socket.py", line 571 in readinto File "C:\Programs\Python35\lib\http\server.py", line 383 in handle_one_request File "C:\Programs\Python35\lib\http\server.py", line 417 in handle File "C:\Programs\Python35\lib\socketserver.py", line 684 in __init__ File "C:\Programs\Python35\lib\socketserver.py", line 357 in finish_request File "C:\Programs\Python35\lib\socketserver.py", line 344 in process_request File "C:\Programs\Python35\lib\socketserver.py", line 318 in _handle_request_noblock File "C:\Programs\Python35\lib\socketserver.py", line 239 in serve_forever File "C:\Programs\Python35\lib\test\test_httpservers.py", line 47 in run File "C:\Programs\Python35\lib\threading.py", line 923 in _bootstrap_inner File "C:\Programs\Python35\lib\threading.py", line 891 in _bootstrap Thread 0x000017f8 (most recent call first): File "C:\Programs\Python35\lib\socket.py", line 571 in readinto File "C:\Programs\Python35\lib\http\client.py", line 243 in _read_status File "C:\Programs\Python35\lib\http\client.py", line 282 in begin File "C:\Programs\Python35\lib\http\client.py", line 1174 in getresponse File "C:\Programs\Python35\lib\test\test_httpservers.py", line 257 in test_get File "C:\Programs\Python35\lib\unittest\case.py", line 597 in run File "C:\Programs\Python35\lib\unittest\case.py", line 645 in __call__ File "C:\Programs\Python35\lib\unittest\suite.py", line 122 in run File "C:\Programs\Python35\lib\unittest\suite.py", line 84 in __call__ File "C:\Programs\Python35\lib\unittest\suite.py", line 122 in run File "C:\Programs\Python35\lib\unittest\suite.py", line 84 in __call__ File "C:\Programs\Python35\lib\unittest\runner.py", line 176 in run File "C:\Programs\Python35\lib\test\support\__init__.py", line 1775 in _run_suite File "C:\Programs\Python35\lib\test\support\__init__.py", line 1809 in run_unittest File "C:\Programs\Python35\lib\test\test_httpservers.py", line 890 in test_main File "C:\Programs\Python35\lib\test\regrtest.py", line 1281 in runtest_inner File "C:\Programs\Python35\lib\test\regrtest.py", line 979 in runtest File "C:\Programs\Python35\lib\test\regrtest.py", line 763 in main File "C:\Programs\Python35\lib\test\regrtest.py", line 1565 in main_in_temp_cwd File "C:\Programs\Python35\lib\test\__main__.py", line 3 in File "C:\Programs\Python35\lib\runpy.py", line 85 in _run_code File "C:\Programs\Python35\lib\runpy.py", line 170 in _run_module_as_main ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 12:08:41 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 15 Sep 2015 10:08:41 +0000 Subject: [issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x) In-Reply-To: <1442151642.39.0.456899707142.issue25084@psf.upfronthosting.co.za> Message-ID: <1442311721.96.0.539747182722.issue25084@psf.upfronthosting.co.za> Nick Coghlan added the comment: For the sake of folks writing single-source code, and needing to support Python 2.7 for at least as long as we're supporting it upstream, I believe it would be beneficial to have consistency here. For those that didn't follow the Fedora/RHEL issue chain, the original Fedora 19 bug report was https://bugzilla.redhat.com/show_bug.cgi?id=917709 and the corresponding "won't fix" upstream issue was issue 17748. Unfortunately, in addition to only helping in a subset of cases, the workaround we applied also extends the affected APIs in an undocumented way that's incompatible with the Python 3 changes to the same API, so I've suggested that regardless of the verdict upstream, we should bring the API extension into line with Python 3 downstream. ---------- nosy: +bkabrda, ncoghlan, rkuska _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 12:09:39 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Sep 2015 10:09:39 +0000 Subject: [issue25122] test_eintr randomly fails on FreeBSD Message-ID: <1442311779.01.0.43728096223.issue25122@psf.upfronthosting.co.za> New submission from STINNER Victor: I'm unable to reproduce the hang. It's probably a race condition since sometimes the test pass. It may depend on the system load, the number of CPU cores, and other factors. I tried to use faulthandler.dump_traceback_later() in the changeset ebccac60b9e7, but it didn't print the traceback of the blocked test. So I don't know which eintr test is blocked. In the changeset ed0e6a9c11af, I rewrote test_eintr.py to use subprocess instead of os.fork(). I was supposed to reduce the risk of race condition, but the hang still occurs. On FreeBSD, I know that any thread can receive a signal, and most Python tests only expect that the signal is received from a specific thread. But test_eintr.py runs Lib/test/eintrdata/eintr_tester.py in a subprocess to avoid threads, and Lib/test/eintrdata/eintr_tester.py itself uses subprocess to spawn child processes, so it should also avoid threads. So I don't think that the issue is related to threads. At least, it would help to know which test hangs. Example: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.x/builds/3337/steps/test/logs/stdio [398/398] test_eintr Timeout (1:00:00)! Thread 0x0000000801807400 (most recent call first): File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/selectors.py", line 375 in select File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/subprocess.py", line 1698 in _communicate File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/subprocess.py", line 1068 in communicate File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/script_helper.py", line 86 in run_python_until_end File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/script_helper.py", line 96 in _assert_python File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/script_helper.py", line 135 in assert_python_ok File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_eintr.py", line 17 in test_all File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/case.py", line 600 in run File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/case.py", line 648 in __call__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 122 in run File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 84 in __call__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 122 in run File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 84 in __call__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 122 in run File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 84 in __call__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/runner.py", line 176 in run File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/__init__.py", line 1775 in _run_suite File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/__init__.py", line 1809 in run_unittest File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 1280 in test_runner File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 1281 in runtest_inner File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 968 in runtest File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 532 in main File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 1565 in main_in_temp_cwd File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 1590 in File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 85 in _run_code File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 170 in _run_module_as_main Traceback (most recent call last): File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/__main__.py", line 3, in regrtest.main_in_temp_cwd() File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 1565, in main_in_temp_cwd main() File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 738, in main raise Exception("Child error on {}: {}".format(test, result[1])) Exception: Child error on test_eintr: Exit code 1 *** [buildbottest] Error code 1 ---------- messages: 250753 nosy: haypo priority: normal severity: normal status: open title: test_eintr randomly fails on FreeBSD versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 12:19:37 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Sep 2015 10:19:37 +0000 Subject: [issue25122] test_eintr randomly fails on FreeBSD In-Reply-To: <1442311779.01.0.43728096223.issue25122@psf.upfronthosting.co.za> Message-ID: <20150915101933.27683.4201@psf.io> Roundup Robot added the comment: New changeset 3d9164aecc6f by Victor Stinner in branch 'default': Issue #25122: try to debug test_eintr hang on FreeBSD https://hg.python.org/cpython/rev/3d9164aecc6f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 12:28:32 2015 From: report at bugs.python.org (Robin) Date: Tue, 15 Sep 2015 10:28:32 +0000 Subject: [issue25123] Logging Documentation - dictConfig disable_existing_loggers Message-ID: <1442312912.97.0.962237041326.issue25123@psf.upfronthosting.co.za> New submission from Robin: logging.config.dictConfig appears to share the same parameter as logging.config.fileConfig - disable_existing_loggers. This parameter is documented for fileConfig but not dictConfig. Suggest update to dictConfig documentation section. ---------- assignee: docs at python components: Documentation messages: 250755 nosy: coderobot, docs at python priority: normal severity: normal status: open title: Logging Documentation - dictConfig disable_existing_loggers type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 13:09:25 2015 From: report at bugs.python.org (Christian Ullrich) Date: Tue, 15 Sep 2015 11:09:25 +0000 Subject: [issue25124] No single .msi available for 3.5 release Message-ID: <1442315365.32.0.493745807723.issue25124@psf.upfronthosting.co.za> New submission from Christian Ullrich: The item "A new installer for Windows has replaced the old MSI" appears on the "What's new" page as an "improvement". It is not. I disagree strongly with the decision to abandon MSI packages for Windows distribution in 3.5. This decision should be reversed immediately, if not sooner. The .msi package format was introduced well over ten years ago. Since that day, there has been *no* excuse at all to distribute software for Windows in any other form (except "a simple ZIP will do"). The MSI file format's main advantage over ad-hoc executable installers or wrappers is in automated installation. There are several ways to deploy software in a corporate network, such as SCCM/SMS and GPO. While the former can deal with .exe packages, using MSIs is much simpler. In an MSI, the Feature table offers clear information about how to install only part of a product (ADDLOCAL=x,y,z either works as intended or fails cleanly). An .exe wrapper does not provide this information in an obvious way, instead, the user has to rely on external documentation to discover the installable features. Python's Windows packages have been exemplary for years. This change needlessly gives up this reputation. As far as the Universal CRT is concerned, for which there are no redist MSIs available, it should be clear that Python is not responsible for installing it, as it is a system component now. If ucrtbase.dll/KB2999226 is not present on the target system, the Python installation should simply abort and inform the user about the missing prerequisite. (Also, as Microsoft is pushing it into the market at seemingly any cost, the market share of Windows 10 with included UCRT is likely to increase quickly, making the wrapper ever more unnecessary. Servers are, of course, another story.) Finally, just in case there were any plans on display for the last several months: I do not usually venture into basements to check for leopards. Python's Windows packaging was perfectly fine, and there was no reason to assume that this would change, rather the opposite, in fact. ---------- components: Installation messages: 250756 nosy: Christian.Ullrich priority: normal severity: normal status: open title: No single .msi available for 3.5 release versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 13:29:00 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 15 Sep 2015 11:29:00 +0000 Subject: [issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x) In-Reply-To: <1442151642.39.0.456899707142.issue25084@psf.upfronthosting.co.za> Message-ID: <1442316540.96.0.966557699048.issue25084@psf.upfronthosting.co.za> Antoine Pitrou added the comment: There's no consistency issue here, Python 3 just shows better performance and resource usage. Python 2 has always had the busy polling implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 13:45:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Sep 2015 11:45:53 +0000 Subject: [issue25108] traceback.extract_stack() compatibility break in 3.5 In-Reply-To: <1442277446.52.0.975521424003.issue25108@psf.upfronthosting.co.za> Message-ID: <2127591.p6yF570NMm@raxxla> Serhiy Storchaka added the comment: > wouldn't changing walk_stack to add one more f_back be better? print_stack and format_stack need to add two more f_backs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 13:59:30 2015 From: report at bugs.python.org (Thijs van Dien) Date: Tue, 15 Sep 2015 11:59:30 +0000 Subject: [issue25125] "Edit with IDLE" does not work for shortcuts Message-ID: <1442318370.13.0.116980940121.issue25125@psf.upfronthosting.co.za> New submission from Thijs van Dien: Right clicking a Python file shows "Edit with IDLE" in the context menu, then offering a next menu where one can choose which particular version of IDLE should be used. This works fine. Whenever a shortcut is created to a Python file, the same context menu is shown, but clicking for example "Edit with IDLE 3.5 (32-bit)" does not seem to do anything. This is probably related to a change in the command used to launch IDLE with the file to be edited. Tested on a fresh install of Windows 7 SP1 X86 and AMD64, with Python 3.5.0 X86. ---------- components: IDLE, Installation, Windows messages: 250759 nosy: paul.moore, steve.dower, thijsvandien, tim.golden, zach.ware priority: normal severity: normal status: open title: "Edit with IDLE" does not work for shortcuts type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 14:18:04 2015 From: report at bugs.python.org (Rocco Matano) Date: Tue, 15 Sep 2015 12:18:04 +0000 Subject: [issue25118] OSError in os.waitpid() on Windows [3.5.0 regression] In-Reply-To: <1442296331.17.0.794192242028.issue25118@psf.upfronthosting.co.za> Message-ID: <1442319484.1.0.830653292621.issue25118@psf.upfronthosting.co.za> Rocco Matano added the comment: I know that using os.spawn and and os.waitpid this way is not the best option, but a 3rd party tool i am using (scons) is doing it that way. So no scons with Python 3.5.0. (I am also aware that scons does not yet support Python 3.x officially.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 14:18:36 2015 From: report at bugs.python.org (Thijs van Dien) Date: Tue, 15 Sep 2015 12:18:36 +0000 Subject: [issue25112] Windows installer assigns non-existent icons to Python file types In-Reply-To: <1442253725.07.0.74818964148.issue25112@psf.upfronthosting.co.za> Message-ID: <1442319516.31.0.176046228918.issue25112@psf.upfronthosting.co.za> Thijs van Dien added the comment: Thanks for the update. I'm not sure why the proper assignment of icons now depends on the installation of the Python launcher (py.exe). The icons are installed in the DLLs directory just like before. Perhaps I'm not familiar enough with the purpose of the launcher, but it seems to me that python.exe and pythonw.exe are enough to do something with Python files. Therefore, in my opinion, Python files should always be associated with Python and get the proper icons, regardless of the presence of the Python launcher. You may consider this a secondary issue, in which case I'd gladly open another ticket. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 14:26:28 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Sep 2015 12:26:28 +0000 Subject: [issue25118] OSError in os.waitpid() on Windows [3.5.0 regression] In-Reply-To: <1442296331.17.0.794192242028.issue25118@psf.upfronthosting.co.za> Message-ID: <1442319988.3.0.117314808139.issue25118@psf.upfronthosting.co.za> STINNER Victor added the comment: > I know that using os.spawn and and os.waitpid this way is not the best option, but a 3rd party tool i am using (scons) is doing it that way. No worry, it was just a comment. Anyway, the bug is now fixed and will be part of the next Python 3.5.1 release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 14:28:20 2015 From: report at bugs.python.org (Thijs van Dien) Date: Tue, 15 Sep 2015 12:28:20 +0000 Subject: [issue25126] Non-web installer fails without a connection when doing debug install Message-ID: <1442320100.9.0.744175303386.issue25126@psf.upfronthosting.co.za> New submission from Thijs van Dien: Python 3.5.0 offers a web installer. This implies that the other installer works offline. This is the case for the default component selection. When debug symbols/binaries are selected, the setup fails with error code 0x80070642 saying the user aborted the installation. This is a severe usability issue. Either everything should be included, or, if that makes the installer too big, "Install debugging symbols" should be "Download and install debugging symbols" - likewise "Install debug binaries" should be "Download and install debug binaries." When downloading fails, the failure message should mention that, rather than blaming the user for something they haven't done. Tested under Windows 7 SP1 X86 with the X86 non-web installer of Python 3.5.0. ---------- components: Installation, Windows messages: 250763 nosy: paul.moore, steve.dower, thijsvandien, tim.golden, zach.ware priority: normal severity: normal status: open title: Non-web installer fails without a connection when doing debug install type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 14:33:33 2015 From: report at bugs.python.org (Thijs van Dien) Date: Tue, 15 Sep 2015 12:33:33 +0000 Subject: [issue25126] Non-web installer fails without a connection when doing debug install In-Reply-To: <1442320100.9.0.744175303386.issue25126@psf.upfronthosting.co.za> Message-ID: <1442320413.5.0.869370417189.issue25126@psf.upfronthosting.co.za> Thijs van Dien added the comment: Although I think the issue is pretty clear, I'm attaching the log file for completion's sake. ---------- Added file: http://bugs.python.org/file40473/Python 3.5.0 (32-bit)_20150915141555.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 14:35:25 2015 From: report at bugs.python.org (Thijs van Dien) Date: Tue, 15 Sep 2015 12:35:25 +0000 Subject: [issue25112] Windows installer assigns non-existent icons to Python file types In-Reply-To: <1442253725.07.0.74818964148.issue25112@psf.upfronthosting.co.za> Message-ID: <1442320525.04.0.0963418681983.issue25112@psf.upfronthosting.co.za> Thijs van Dien added the comment: On the other hand, if the launcher is somehow strictly necessary, then why is it optional? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 14:55:26 2015 From: report at bugs.python.org (Donald Stufft) Date: Tue, 15 Sep 2015 12:55:26 +0000 Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?= =?utf-8?q?env_with_--system-site-package?= In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za> Message-ID: <1442321726.52.0.468360590213.issue24875@psf.upfronthosting.co.za> Donald Stufft added the comment: You probably need to either pass --ignore-installed to pip when invoking it inside of venv, or you need to disable system_site_packages (internally to venv) until after pip is installed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 15:27:38 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 15 Sep 2015 13:27:38 +0000 Subject: [issue25121] python logger can't wrap log file and blows with traceback In-Reply-To: <1442307454.43.0.792328825134.issue25121@psf.upfronthosting.co.za> Message-ID: <1442323658.47.0.186820057253.issue25121@psf.upfronthosting.co.za> R. David Murray added the comment: Are you using a rotating file handler for the logger? You should take a look at some of the other issues in this tracker about RotatingFileHandler and Windows. I will be interested in Vinay's answer to your question about the exception being allowed to bubble up. I suspect it has to do with the fact that you would be completely losing your logging data if it were ignored. ---------- nosy: +r.david.murray, vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 15:30:05 2015 From: report at bugs.python.org (Yegor Yefremov) Date: Tue, 15 Sep 2015 13:30:05 +0000 Subject: [issue13508] ctypes' find_library breaks with ARM ABIs In-Reply-To: <1322664873.68.0.763423976883.issue13508@psf.upfronthosting.co.za> Message-ID: <1442323805.49.0.128741117773.issue13508@psf.upfronthosting.co.za> Yegor Yefremov added the comment: This issue is still up to date. Most impacted are distos like for example Buldroot (http://buildroot.org/). Usual production rootfs provide neither gcc nor /sbin/ldconfig nor objdump. So find_library() is doomed from the very beginning. Such packages like pyusb, pyudev etc. rely on find_library() and are not usable in such environment. Pyusb developers had to create an extra backend to overcome this issue (https://github.com/walac/pyusb/pull/29). So common solution would be very useful for such environments. ---------- nosy: +Yegor Yefremov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 15:30:22 2015 From: report at bugs.python.org (Alexander Belchenko) Date: Tue, 15 Sep 2015 13:30:22 +0000 Subject: [issue25121] python logger can't wrap log file and blows with traceback In-Reply-To: <1442307454.43.0.792328825134.issue25121@psf.upfronthosting.co.za> Message-ID: <1442323822.98.0.275281165892.issue25121@psf.upfronthosting.co.za> Alexander Belchenko added the comment: Yes. it's rotating file handler. I'll try to recreate this issue with simpler test application, so I can provide something as example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 15:30:32 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 15 Sep 2015 13:30:32 +0000 Subject: [issue25123] Logging Documentation - dictConfig disable_existing_loggers In-Reply-To: <1442312912.97.0.962237041326.issue25123@psf.upfronthosting.co.za> Message-ID: <1442323832.08.0.496667674872.issue25123@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 15:33:25 2015 From: report at bugs.python.org (Alexander Belchenko) Date: Tue, 15 Sep 2015 13:33:25 +0000 Subject: [issue25121] python logger RotatingFileHandler can't wrap log file and blows with traceback In-Reply-To: <1442307454.43.0.792328825134.issue25121@psf.upfronthosting.co.za> Message-ID: <1442324005.1.0.431752762908.issue25121@psf.upfronthosting.co.za> Changes by Alexander Belchenko : ---------- title: python logger can't wrap log file and blows with traceback -> python logger RotatingFileHandler can't wrap log file and blows with traceback _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 15:48:37 2015 From: report at bugs.python.org (Marius Gedminas) Date: Tue, 15 Sep 2015 13:48:37 +0000 Subject: [issue25119] Windows installer fails to install VCRUNTIME140.DLL In-Reply-To: <1442304615.44.0.515104060995.issue25119@psf.upfronthosting.co.za> Message-ID: <1442324917.53.0.305481055106.issue25119@psf.upfronthosting.co.za> Marius Gedminas added the comment: Thank you for the pointer! It's hard to tell which software component is at fault when multiple components fail to collaborate. I cannot choose to use venv because I'm actually using tox, which runs virtualenv for a bunch of Python versions, some of which don't even have venv. I've filed a virtualenv bug: https://github.com/pypa/virtualenv/issues/796 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 16:15:42 2015 From: report at bugs.python.org (Alexander Belchenko) Date: Tue, 15 Sep 2015 14:15:42 +0000 Subject: [issue25121] python logger RotatingFileHandler can't wrap log file and blows with traceback In-Reply-To: <1442307454.43.0.792328825134.issue25121@psf.upfronthosting.co.za> Message-ID: <1442326542.05.0.684160999246.issue25121@psf.upfronthosting.co.za> Alexander Belchenko added the comment: I have suspicion about this issue. In my application tornado framework is used. I setup logger for my own code, but use the same logger for tornado, so all messages from tornado itself go into the same log file. As I said earlier it's strange but one log file works as expected. This log file is not used by tornado. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 16:16:31 2015 From: report at bugs.python.org (Zachary Ware) Date: Tue, 15 Sep 2015 14:16:31 +0000 Subject: [issue25124] No single .msi available for 3.5 release In-Reply-To: <1442315365.32.0.493745807723.issue25124@psf.upfronthosting.co.za> Message-ID: <1442326591.45.0.148014588846.issue25124@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- assignee: -> steve.dower components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 16:28:19 2015 From: report at bugs.python.org (Alexander Belchenko) Date: Tue, 15 Sep 2015 14:28:19 +0000 Subject: [issue25121] python logger RotatingFileHandler can't wrap log file and blows with traceback In-Reply-To: <1442307454.43.0.792328825134.issue25121@psf.upfronthosting.co.za> Message-ID: <1442327299.62.0.872035020714.issue25121@psf.upfronthosting.co.za> Alexander Belchenko added the comment: Update to previous comment. I use the same settings for tornado logger (e.g. filename). logger = logging.getLogger('tornado') setup_logger(logger, log_config) So I have 2 loggers in one application which are trying to write to the same file. I guess it's out of supported use cases? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 16:31:53 2015 From: report at bugs.python.org (Alexander Belchenko) Date: Tue, 15 Sep 2015 14:31:53 +0000 Subject: [issue25121] python logger RotatingFileHandler can't wrap log file and blows with traceback In-Reply-To: <1442307454.43.0.792328825134.issue25121@psf.upfronthosting.co.za> Message-ID: <1442327513.76.0.31346241083.issue25121@psf.upfronthosting.co.za> Alexander Belchenko added the comment: According to documentation on RotateFileHandler "When this file is filled, it is closed and renamed to app.log.1, and if files app.log.1, app.log.2, etc. exist, then they are renamed to app.log.2, app.log.3 etc. respectively." But we have 2 loggers which holds open file inside the same process. And while one handler is trying to close and rename file, another handler (tornado, which writes something to log only when there are errors actually) is holding file open. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 16:47:12 2015 From: report at bugs.python.org (Jakub Wilk) Date: Tue, 15 Sep 2015 14:47:12 +0000 Subject: [issue25127] typo in concurrent.futures.Executor.shutdown() example Message-ID: <1442328432.29.0.90090219234.issue25127@psf.upfronthosting.co.za> New submission from Jakub Wilk: Typo in the example code in : in the last line, it should be "src4.txt", not "src3.txt". ---------- assignee: docs at python components: Documentation messages: 250774 nosy: docs at python, jwilk priority: normal severity: normal status: open title: typo in concurrent.futures.Executor.shutdown() example _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 16:56:00 2015 From: report at bugs.python.org (tzickel) Date: Tue, 15 Sep 2015 14:56:00 +0000 Subject: [issue25083] Python can sometimes create incorrect .pyc files In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za> Message-ID: <1442328960.64.0.33783011267.issue25083@psf.upfronthosting.co.za> tzickel added the comment: As for the "example" .pyc just create an empty 0 byte .py file and compile it, that is the same .pyc that is created in my system (instead in my case the .py is not empty). Just so people don't have to trace the code like I did, here is the traceback of the primary issue. Remember that my hypothesis is that fopen returns an FILE stream, that returns EOF on the first get because of an I/O error, not because the file is empty: --> GETC is called, and gets EOF on the first try, and thus Py_UniversalNewlineFgets returns NULL * frame #0: 0x0000000109fe4c44 Python`Py_UniversalNewlineFgets frame #1: 0x0000000109fc972c Python`decoding_fgets + 321 frame #2: 0x0000000109fc9262 Python`tok_nextc + 918 frame #3: 0x0000000109fc830e Python`PyTokenizer_Get + 171 frame #4: 0x0000000109fc5853 Python`parsetok + 128 frame #5: 0x000000010a066748 Python`PyParser_ASTFromFile + 109 -> Now load_source_module has an empty AST which will get compiled to an empty code module -> this code is optmized so we don't see the parse_source_module call here, but write_compiled_module will be called afterwards with the empty AST tree instead of aborting... frame #6: 0x000000010a05e3b5 Python`load_source_module + 671 frame #7: 0x000000010a05f003 Python`import_submodule + 270 frame #8: 0x000000010a05ebc6 Python`load_next + 284 frame #9: 0x000000010a05cb5d Python`PyImport_ImportModuleLevel + 453 frame #10: 0x000000010a042641 Python`builtin___import__ + 135 .... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 16:59:10 2015 From: report at bugs.python.org (Alexander Belchenko) Date: Tue, 15 Sep 2015 14:59:10 +0000 Subject: [issue25121] python logger RotatingFileHandler can't wrap log file and blows with traceback In-Reply-To: <1442307454.43.0.792328825134.issue25121@psf.upfronthosting.co.za> Message-ID: <1442329150.56.0.725360075079.issue25121@psf.upfronthosting.co.za> Alexander Belchenko added the comment: Based on my last assumption I'm able to reproduce this issue with simple test attached. If I comment out the line setup_logger(loggerB) The everything works OK. Once this line in - it's traceback. I guess it's fair to say the bug in my code and one never should use this approach. On Linux it never traceback but I think it may have other unvisible issues. I expect you mark this as "won't fix" but maybe you want to look at it. ---------- Added file: http://bugs.python.org/file40474/test-issue25121.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 17:11:40 2015 From: report at bugs.python.org (yavvsy) Date: Tue, 15 Sep 2015 15:11:40 +0000 Subject: [issue25128] https://docs.python.org/3/download.html incorrect links to files (cannot download) Message-ID: <1442329900.03.0.985918373135.issue25128@psf.upfronthosting.co.za> New submission from yavvsy: When clicking on a download link in: https://docs.python.org/3/download.html The links point to files that don't exist (older document version) For example: https://docs.python.org/ftp/python/doc/3.5.0/python-3.5.0-docs-pdf-letter.zip should be instead: https://docs.python.org/ftp/python/doc/3.5.0/python-3.5.0a3-docs-pdf-letter.zip ---------- assignee: docs at python components: Documentation messages: 250777 nosy: docs at python, yavvsy priority: normal severity: normal status: open title: https://docs.python.org/3/download.html incorrect links to files (cannot download) type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 17:22:42 2015 From: report at bugs.python.org (Zachary Ware) Date: Tue, 15 Sep 2015 15:22:42 +0000 Subject: [issue25117] Windows installer: precompiling stdlib fails with missing DLL errors In-Reply-To: <1442294819.71.0.839651529049.issue25117@psf.upfronthosting.co.za> Message-ID: <1442330562.08.0.904074614289.issue25117@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 17:53:50 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 15 Sep 2015 15:53:50 +0000 Subject: [issue25074] Bind logger and waninigs modules for asyncio __del__ methods In-Reply-To: <1441998965.13.0.504603864253.issue25074@psf.upfronthosting.co.za> Message-ID: <1442332430.62.0.115291557579.issue25074@psf.upfronthosting.co.za> Andrew Svetlov added the comment: > You should try to implement something in aiohttp or even in the application to cleanup objects at exit. For example, it's probably wrong if you still have tasks when the event loop is closed. Especially if tasks are still pending. The problem is for client API. For server I have more control and implemented checks like you suggest. For for client lazy user writes floppy code like: client = aiohttp.ClientSession() resp = yield from client.get(url) text = yield from resp.text() Client is closed by GC, at the moment is not determined is loop has been closed or not (GC releases object in non-determenistic way). So without changes I just cannot use `loop.call_exception_handler()` in `__del__` methods. It's not only aiohttp issue but we should get rid of `call_exception_handler()` reports in asyncio itself for the same reason. We have `logger` and `warnings` modules usage e.g. in asyncio transports, it's not safe if transport is not closed properly before interpreter shutdown. `subprecess` module has tricks for proper destruction like I've used in my patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 18:03:42 2015 From: report at bugs.python.org (Zachary Ware) Date: Tue, 15 Sep 2015 16:03:42 +0000 Subject: [issue25103] 3.5.0 installed standard library on Windows has LF line endings In-Reply-To: <1442208824.41.0.568116526355.issue25103@psf.upfronthosting.co.za> Message-ID: <1442333022.24.0.578087934575.issue25103@psf.upfronthosting.co.za> Zachary Ware added the comment: Victor: that would be ideal, but hoping for that seems an exercise in futility :) Larry: It seems to be; the test case that brought it my attention (Lib\test\test_tcl.py) has CRLF in my 3.4.3 install and LF in 3.5.0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 18:13:09 2015 From: report at bugs.python.org (Larry Hastings) Date: Tue, 15 Sep 2015 16:13:09 +0000 Subject: [issue25103] 3.5.0 installed standard library on Windows has LF line endings In-Reply-To: <1442208824.41.0.568116526355.issue25103@psf.upfronthosting.co.za> Message-ID: <1442333589.24.0.93744487622.issue25103@psf.upfronthosting.co.za> Larry Hastings added the comment: Well, even if the Windows build was on fire and children were dying, we couldn't do anything about it until next week--Steve's on vacation. I expect he'll weigh in on this when he gets back. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 18:18:35 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 15 Sep 2015 16:18:35 +0000 Subject: [issue25115] SSL_set_verify_depth not exposed by the ssl module In-Reply-To: <1442280676.76.0.937947035148.issue25115@psf.upfronthosting.co.za> Message-ID: <1442333915.57.0.18733280102.issue25115@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> patch review versions: +Python 3.6 -Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 18:43:43 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Sep 2015 16:43:43 +0000 Subject: [issue25105] Docs 3.x buildbot: ":root" found in ... In-Reply-To: <1442213688.52.0.64987156832.issue25105@psf.upfronthosting.co.za> Message-ID: <20150915164338.11268.98057@psf.io> Roundup Robot added the comment: New changeset 953a14984aec by Berker Peksag in branch '3.5': Issue #25105: Update susp-ignored.csv to avoid false positives https://hg.python.org/cpython/rev/953a14984aec New changeset efdbe17a9208 by Berker Peksag in branch 'default': Issue #25105: Update susp-ignored.csv to avoid false positives https://hg.python.org/cpython/rev/efdbe17a9208 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 18:55:10 2015 From: report at bugs.python.org (Grant Bremer) Date: Tue, 15 Sep 2015 16:55:10 +0000 Subject: [issue25115] SSL_set_verify_depth not exposed by the ssl module In-Reply-To: <1442280676.76.0.937947035148.issue25115@psf.upfronthosting.co.za> Message-ID: <1442336110.04.0.421562939784.issue25115@psf.upfronthosting.co.za> Grant Bremer added the comment: I had thought that I had found documentation that the max depth is 100 and anything higher is ignored -- and as I read that back to me, I believe I read an example passage and interpreted it incorrectly. I'll remove that. We primarily use Python 2.7, so I started there. I'll submit another patch with changes on the 3.5 branch and add tests. ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 18:56:41 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 15 Sep 2015 16:56:41 +0000 Subject: [issue25105] Docs 3.x buildbot: ":root" found in ... In-Reply-To: <1442213688.52.0.64987156832.issue25105@psf.upfronthosting.co.za> Message-ID: <1442336201.54.0.382154060051.issue25105@psf.upfronthosting.co.za> Berker Peksag added the comment: Looks happy now: http://buildbot.python.org/all/builders/Docs%203.x/builds/104 Thanks for the report, Victor. ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 19:00:10 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Sep 2015 17:00:10 +0000 Subject: [issue25127] typo in concurrent.futures.Executor.shutdown() example In-Reply-To: <1442328432.29.0.90090219234.issue25127@psf.upfronthosting.co.za> Message-ID: <20150915170005.5937.45042@psf.io> Roundup Robot added the comment: New changeset 8f94e695f56b by Berker Peksag in branch '3.4': Issue #25127: Fix typo in concurrent.futures.rst https://hg.python.org/cpython/rev/8f94e695f56b New changeset afe82e6f00df by Berker Peksag in branch '3.5': Issue #25127: Fix typo in concurrent.futures.rst https://hg.python.org/cpython/rev/afe82e6f00df New changeset 23ad070a6a2d by Berker Peksag in branch 'default': Issue #25127: Fix typo in concurrent.futures.rst https://hg.python.org/cpython/rev/23ad070a6a2d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 19:00:50 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 15 Sep 2015 17:00:50 +0000 Subject: [issue25127] typo in concurrent.futures.Executor.shutdown() example In-Reply-To: <1442328432.29.0.90090219234.issue25127@psf.upfronthosting.co.za> Message-ID: <1442336450.04.0.469345246493.issue25127@psf.upfronthosting.co.za> Berker Peksag added the comment: Fixed. Thanks, Jakub. ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 19:28:03 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 15 Sep 2015 17:28:03 +0000 Subject: [issue25129] suboptimal floating-point floor division Message-ID: <1442338083.45.0.230324673027.issue25129@psf.upfronthosting.co.za> New submission from Antoine Pitrou: >>> (78*6e-8) / 6e-8 78.0 >>> (78*6e-8) // 6e-8 77.0 Note this doesn't make divmod() wrong: >>> q, r = divmod(78*6e-8, 6e-8) >>> q, r (77.0, 5.999999999999965e-08) >>> r < 6e-8 True >>> q * 6e-8 + r == 78*6e-8 True But, still, it is somewhat of an oddity to not return the real quotient when it is an exact integer. Note this came from a Numpy issue where Numpy actually shows better behaviour: https://github.com/numpy/numpy/issues/6127 ---------- components: Interpreter Core messages: 250786 nosy: mark.dickinson, pitrou, tim.peters priority: normal severity: normal status: open title: suboptimal floating-point floor division type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 19:42:42 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 15 Sep 2015 17:42:42 +0000 Subject: [issue25128] https://docs.python.org/3/download.html incorrect links to files (cannot download) In-Reply-To: <1442329900.03.0.985918373135.issue25128@psf.upfronthosting.co.za> Message-ID: <1442338962.93.0.919375715468.issue25128@psf.upfronthosting.co.za> Berker Peksag added the comment: The correct link for python-3.5.0-docs-pdf-letter.zip should be https://docs.python.org/3/archives/python-3.5.0-docs-pdf-letter.zip It was a cache issue and should be resolved now. I can confirm that all links at https://docs.python.org/3/download.html are working for me. Can you please check again? ---------- nosy: +berker.peksag resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 19:47:17 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 15 Sep 2015 17:47:17 +0000 Subject: [issue25113] documentation version switcher is broken In-Reply-To: <1442259134.08.0.318415245407.issue25113@psf.upfronthosting.co.za> Message-ID: <1442339237.19.0.70889839998.issue25113@psf.upfronthosting.co.za> Berker Peksag added the comment: > tl;dr: Hopefully it'll silently fix itself sometime today. Yes, it's working now. Thanks for the explanation. ---------- resolution: -> fixed stage: -> resolved status: open -> closed type: enhancement -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 20:15:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 15 Sep 2015 18:15:25 +0000 Subject: [issue25130] Make tests more PyPy compatible Message-ID: <1442340924.34.0.752221775968.issue25130@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: PyPy includes modified Python 2.7 tests for testing compatibility. Some of changes skips tests for features that are not implemented in PyPy or are CPython specific, some reflects differences between error types or messages in CPython and PyPy, some are needed because PyPy doesn't use reference counting, some are workarounds for known PyPy or CPython bugs. The purpose of this issue is to port harmless non PyPy-specific changes. I'll split full patch on several parts for easier review. The first patch in a series just adds gc.collect() or test.test_support.gc_collect() calls to force calling destructors or freeing memory. ---------- assignee: serhiy.storchaka components: Tests files: pypy_tests_gc_collect-2.7.patch keywords: patch messages: 250789 nosy: benjamin.peterson, fijall, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Make tests more PyPy compatible type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40475/pypy_tests_gc_collect-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 20:28:25 2015 From: report at bugs.python.org (Claudiu Popa) Date: Tue, 15 Sep 2015 18:28:25 +0000 Subject: [issue25131] The AST for dict and set displays has the lineno of the first value Message-ID: <1442341705.94.0.0242549644551.issue25131@psf.upfronthosting.co.za> New submission from Claudiu Popa: Hi, In Python 3.5, the lineno for dict and set display ASTs is the line number of the first value, not the line number of the display character, as it was until 3.5. Here's an example: from ast import parse module = parse('''{ '1':'2', } ''') dict_display = module.body[0].value print(dict_display.lineno) I don't seem to find anything related to this in the documentation, but I presume this is a side effect of the new parser changes. It would nice to have this fixed or at least documented. ---------- components: Library (Lib) messages: 250790 nosy: Claudiu.Popa priority: normal severity: normal status: open title: The AST for dict and set displays has the lineno of the first value type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 20:33:18 2015 From: report at bugs.python.org (siva) Date: Tue, 15 Sep 2015 18:33:18 +0000 Subject: [issue25132] unable to install mongo-python-driver-3.0.3 driver Message-ID: <1442341998.85.0.950034440583.issue25132@psf.upfronthosting.co.za> New submission from siva: Hi There, I am using Python 2.7.10. When I am trying to install mongo-python-driver-3.0.3 driver it's showing an error. Here, I am attaching the screenshot taken from my machine. Thanks in advance for you quick help. [root at localhost mongo-python-driver-3.0.3]# whereis python python: /usr/bin/python /usr/bin/python2.4 /usr/lib/python2.4 /usr/local/bin/python2.7-config /usr/local/bin/python2.7 /usr/local/bin/python /usr/local/lib/python2.7 /usr/include/python2.4 /usr/share/man/man1/python.1.gz [root at localhost mongo-python-driver-3.0.3]# which python /usr/local/bin/python [root at localhost mongo-python-driver-3.0.3]# python -V Python 2.7.10 [root at localhost mongo-python-driver-3.0.3]# pwd /root/mongo-python-driver-3.0.3 [root at localhost mongo-python-driver-3.0.3]# ls bson CONTRIBUTING.rst doc ez_setup.py green_framework_test.py gridfs LICENSE MANIFEST.in pymongo README.rst RELEASE.rst setup.py test tools tox.ini [root at localhost mongo-python-driver-3.0.3]# python setup.py install Downloading https://pypi.python.org/packages/source/s/setuptools/setuptools-1.4.2.tar.gz Traceback (most recent call last): File "setup.py", line 20, in use_setuptools() File "/root/mongo-python-driver-3.0.3/ez_setup.py", line 132, in use_setuptools return _do_download(version, download_base, to_dir, download_delay) File "/root/mongo-python-driver-3.0.3/ez_setup.py", line 110, in _do_download to_dir, download_delay) File "/root/mongo-python-driver-3.0.3/ez_setup.py", line 290, in download_setuptools downloader(url, saveto) File "/root/mongo-python-driver-3.0.3/ez_setup.py", line 215, in download_file_wget _clean_check(cmd, target) File "/root/mongo-python-driver-3.0.3/ez_setup.py", line 160, in _clean_check subprocess.check_call(cmd) File "/usr/local/lib/python2.7/subprocess.py", line 540, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '['wget', 'https://pypi.python.org/packages/source/s/setuptools/setuptools-1.4.2.tar.gz', '--quiet', '--output-document', '/root/mongo-python-driver-3.0.3/setuptools-1.4.2.tar.gz']' returned non-zero exit status 1 ---------- components: Installation messages: 250791 nosy: siva priority: normal severity: normal status: open title: unable to install mongo-python-driver-3.0.3 driver type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 20:34:44 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 15 Sep 2015 18:34:44 +0000 Subject: [issue25133] Clarify that the constants in selectors are module-level Message-ID: <1442342084.77.0.0114888594817.issue25133@psf.upfronthosting.co.za> New submission from Brett Cannon: If you read the docs for the selectors module it isn't obvious that the constants EVENT_WRITE and EVENT_READ are module-level and not on the various classes since they are in the Classes section of the doc. Shouldn't require any more than adding the word "module" to "the constants below". ---------- assignee: brett.cannon components: Documentation keywords: easy messages: 250792 nosy: brett.cannon priority: low severity: normal stage: needs patch status: open title: Clarify that the constants in selectors are module-level versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 20:47:00 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Sep 2015 18:47:00 +0000 Subject: [issue25131] The AST for dict and set displays has the lineno of the first value In-Reply-To: <1442341705.94.0.0242549644551.issue25131@psf.upfronthosting.co.za> Message-ID: <1442342820.74.0.851972771925.issue25131@psf.upfronthosting.co.za> STINNER Victor added the comment: Using hg bisect, I found the revision a65f685ba8c0: changeset: 95886:a65f685ba8c0 user: Benjamin Peterson date: Tue May 05 20:16:41 2015 -0400 files: Grammar/Grammar Include/Python-ast.h Include/dictobject.h Include/opcode.h Lib/importlib/_bootstrap_external.py Lib/opcode.py Lib/test/test_ast.py Lib/test/test_extcall.py Lib/test/test_grammar.py Lib/test/test_parser.py Lib/test/test_syntax.py Lib/test/test_unpack_ex.py Misc/ACKS Misc/NEWS Modules/parsermodule.c Objects/dictobject.c Parser/Python.asdl Python/Python-ast.c Python/ast.c Python/ceval.c Python/compile.c Python/graminit.c Python/importlib_external.h Python/opcode_targets.h Python/symtable.c Tools/parser/unparse.py description: PEP 448: additional unpacking generalizations (closes #2292) Patch by Neil Girdhar. ---------- nosy: +benjamin.peterson, haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 20:52:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Sep 2015 18:52:17 +0000 Subject: [issue25131] The AST for dict and set displays has the lineno of the first value In-Reply-To: <1442341705.94.0.0242549644551.issue25131@psf.upfronthosting.co.za> Message-ID: <1442343137.07.0.908698426361.issue25131@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +neil.g _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 20:53:07 2015 From: report at bugs.python.org (Cyd Haselton) Date: Tue, 15 Sep 2015 18:53:07 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1442343187.13.0.724052075416.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Ryan, Here's the results after the edit to the ctypes test. I also re-compiled gdb with python support, which is why this took so long (gdb) file ./python Load new symbol table from "./python"? (y or n) y Reading symbols from ./python...done. Traceback (most recent call last): File "/bld/pyt/cpython-android/python-gdb.py", line 59, in _type_char_ptr = gdb.lookup_type('char').pointer() # char* AttributeError: 'module' object has no attribute 'lookup_type' (gdb) set args -m tests (gdb) set sysroot /usr/gcc-4.9-pie/sysroot (gdb) run Starting program: /bld/pyt/cpython-android/python -m tests setpgrp failed in child: No such process warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. Program received signal SIGILL, Illegal instruction. 0xb6a63cc8 in ?? () (gdb) bt Python Exception No module named 'gdb.frames': #0 0xb6a63cc8 in ?? () #1 0xb6a5feb0 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 20:54:13 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 15 Sep 2015 18:54:13 +0000 Subject: [issue25121] python logger RotatingFileHandler can't wrap log file and blows with traceback In-Reply-To: <1442307454.43.0.792328825134.issue25121@psf.upfronthosting.co.za> Message-ID: <1442343253.84.0.716159161976.issue25121@psf.upfronthosting.co.za> R. David Murray added the comment: Vinay has closed other issues reporting this two-open-files problem in the past (which was why i recommended you read through some of them :). Windows causes problems when there are two open file handles and a rename is attempted, so no, that is not a supported configuration for the logging module. So I'm going to close it as not a bug. If you can propose a way to make things work better, by all means open an enhancement issue. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 21:02:34 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 15 Sep 2015 19:02:34 +0000 Subject: [issue25132] unable to install mongo-python-driver-3.0.3 driver In-Reply-To: <1442341998.85.0.950034440583.issue25132@psf.upfronthosting.co.za> Message-ID: <1442343754.46.0.870492653253.issue25132@psf.upfronthosting.co.za> R. David Murray added the comment: This tracker is for bugs in python itself. You should report this to the mongo-python-driver project. (If they find there really is a problem in python, which doesn't look likely from your traceback, a new issue with specifics can be opened.) ---------- nosy: +r.david.murray resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 21:24:37 2015 From: report at bugs.python.org (Tim Peters) Date: Tue, 15 Sep 2015 19:24:37 +0000 Subject: [issue25129] suboptimal floating-point floor division In-Reply-To: <1442338083.45.0.230324673027.issue25129@psf.upfronthosting.co.za> Message-ID: <1442345077.64.0.0433158743993.issue25129@psf.upfronthosting.co.za> Tim Peters added the comment: Stare at footnote 2 for the Reference Manual's "Binary arithmetic operations" section: """ [2] If x is very close to an exact integer multiple of y, it?s possible for x//y to be one larger than (x-x%y)//y due to rounding. In such cases, Python returns the latter result, in order to preserve that divmod(x,y)[0] * y + x % y be very close to x. """ This is such a case. >>> x 4.679999999999999e-06 >>> y 6e-08 >>> divmod(x,y)[0] * y + x % y == x True >>> (x/y) * y + x % y == x False >>> ((x/y) * y + x % y) / x # and not close at all 1.0128205128205128 Yes, trying to preserve identities in floating-point always was a fool's errand ;-) Note that "but x is an _exact_ integer multiple of y, not just 'very close to'" would be succumbing to an illusion: >>> dx = decimal.Decimal(x) >>> dy = decimal.Decimal(y) >>> dx / dy Decimal('77.99999999999999426488108630') It's just that x/y _appears_ to be an exact integer (78) due to rounding. As the decimal calcs show, infinite-precision floor division really would return 77. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 21:41:20 2015 From: report at bugs.python.org (Nikita Klimov) Date: Tue, 15 Sep 2015 19:41:20 +0000 Subject: [issue24899] Add an os.path <=> pathlib equivalence table in pathlib docs In-Reply-To: <1440050617.44.0.44226546659.issue24899@psf.upfronthosting.co.za> Message-ID: <1442346080.33.0.719534229406.issue24899@psf.upfronthosting.co.za> Nikita Klimov added the comment: Patch in attach. Could anybody do review? ---------- keywords: +patch Added file: http://bugs.python.org/file40476/pathlib-os-correlation-doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 22:05:38 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 15 Sep 2015 20:05:38 +0000 Subject: [issue25129] suboptimal floating-point floor division In-Reply-To: <1442338083.45.0.230324673027.issue25129@psf.upfronthosting.co.za> Message-ID: <1442347538.13.0.0932549175791.issue25129@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Hum, I see. What is the rounding mode used by true division, by the way? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 22:07:45 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Sep 2015 20:07:45 +0000 Subject: [issue25129] suboptimal floating-point floor division In-Reply-To: <1442338083.45.0.230324673027.issue25129@psf.upfronthosting.co.za> Message-ID: <1442347665.29.0.163619837827.issue25129@psf.upfronthosting.co.za> STINNER Victor added the comment: IEEE 754 uses the ROUND_HALF_EVEN rounding mode by default: https://en.wikipedia.org/wiki/Rounding#Round_half_to_even That's why round() uses the same rounding mode. I discovered recently while working on the datetime module :-) (issue #23517) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 22:09:16 2015 From: report at bugs.python.org (Tim Peters) Date: Tue, 15 Sep 2015 20:09:16 +0000 Subject: [issue25129] suboptimal floating-point floor division In-Reply-To: <1442338083.45.0.230324673027.issue25129@psf.upfronthosting.co.za> Message-ID: <1442347756.0.0.432588801779.issue25129@psf.upfronthosting.co.za> Tim Peters added the comment: > What is the rounding mode used by true division, For binary floats? It inherits whatever the platform C's x/y double division uses. Should be nearest/even on "almost all" platforms now, unless the user fiddles with their FPU's rounding flags. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 22:16:52 2015 From: report at bugs.python.org (Nikita Klimov) Date: Tue, 15 Sep 2015 20:16:52 +0000 Subject: [issue13253] 2to3 fix_renames renames sys.maxint only in imports In-Reply-To: <1319437552.82.0.780264952493.issue13253@psf.upfronthosting.co.za> Message-ID: <1442348212.01.0.374725365053.issue13253@psf.upfronthosting.co.za> Nikita Klimov added the comment: I'm interesting to research this. I can show results by 23 September, I think. ---------- nosy: +klimov versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 22:35:42 2015 From: report at bugs.python.org (Bar Harel) Date: Tue, 15 Sep 2015 20:35:42 +0000 Subject: [issue25134] SSL asyncio Message-ID: <1442349342.4.0.267068744355.issue25134@psf.upfronthosting.co.za> New submission from Bar Harel: Seems like at https://docs.python.org/3.5/library/asyncio-eventloop.html#creating-connections (Creating connections) in asyncio, it states that "On Windows with ProactorEventLoop, SSL/TLS is not supported." But on the ProactorEventLoop it states that SSL support was added in 3.5 Please remove the "unsupported" statement in the docs of 3.5 and 3.6 p.s. Is there a way I can fix these errors myself instead of hassling other people? ---------- assignee: docs at python components: Documentation messages: 250803 nosy: Bar Harel, docs at python priority: normal severity: normal status: open title: SSL asyncio versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 22:40:15 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Sep 2015 20:40:15 +0000 Subject: [issue25122] test_eintr randomly fails on FreeBSD In-Reply-To: <1442311779.01.0.43728096223.issue25122@psf.upfronthosting.co.za> Message-ID: <20150915204012.16642.415@psf.io> Roundup Robot added the comment: New changeset edbc35d8babb by Victor Stinner in branch 'default': Issue #25122: Fix test_eintr, kill child process on error https://hg.python.org/cpython/rev/edbc35d8babb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 22:42:14 2015 From: report at bugs.python.org (Markus Unterwaditzer) Date: Tue, 15 Sep 2015 20:42:14 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1442349734.85.0.72917090109.issue20438@psf.upfronthosting.co.za> Markus Unterwaditzer added the comment: It should be properly noted that the API isn't going to be actually removed anytime soon. Also I think issuing a warning about this was a mistake. For software that wants to stay compatible with both Python 2 and 3 it's basically useless. ---------- nosy: +untitaker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 22:43:36 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Sep 2015 20:43:36 +0000 Subject: [issue25134] SSL asyncio In-Reply-To: <1442349342.4.0.267068744355.issue25134@psf.upfronthosting.co.za> Message-ID: <20150915204333.24035.15349@psf.io> Roundup Robot added the comment: New changeset d371ce905395 by Victor Stinner in branch '3.5': Issue #25134: Update asyncio doc for SSL on Windows https://hg.python.org/cpython/rev/d371ce905395 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 22:45:14 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Sep 2015 20:45:14 +0000 Subject: [issue25134] SSL asyncio In-Reply-To: <1442349342.4.0.267068744355.issue25134@psf.upfronthosting.co.za> Message-ID: <1442349914.23.0.446346466093.issue25134@psf.upfronthosting.co.za> STINNER Victor added the comment: > But on the ProactorEventLoop it states that SSL support was added in 3.5 Right, I forgot to update the doc. Thanks for the bug report. > p.s. Is there a way I can fix these errors myself instead of hassling other people? Sure, you can write patches and open an issue with your patch. * Clone Python repository: hg clone http://hg.python.org/cpython/ * Edit the doc: Doc/library/asyncio*.rst * Produce a patch: hg diff > patch Don't hesitate to enhance asyncio doc! Patches are welcome! ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 22:45:25 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 15 Sep 2015 20:45:25 +0000 Subject: [issue25134] SSL asyncio In-Reply-To: <1442349342.4.0.267068744355.issue25134@psf.upfronthosting.co.za> Message-ID: <1442349925.27.0.223378828685.issue25134@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 22:46:52 2015 From: report at bugs.python.org (Markus Unterwaditzer) Date: Tue, 15 Sep 2015 20:46:52 +0000 Subject: [issue20438] inspect: Deprecate getfullargspec? In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za> Message-ID: <1442350012.29.0.220386574113.issue20438@psf.upfronthosting.co.za> Markus Unterwaditzer added the comment: My last comment was in reference to getfullargspec, which is, as far as I understand, not going to be deprecated until after 3.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 23:00:20 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Sep 2015 21:00:20 +0000 Subject: [issue25122] test_eintr randomly fails on FreeBSD In-Reply-To: <1442311779.01.0.43728096223.issue25122@psf.upfronthosting.co.za> Message-ID: <20150915210013.114986.43298@psf.io> Roundup Robot added the comment: New changeset 24dbca4e746c by Victor Stinner in branch 'default': Issue #25122: test_eintr: don't redirect stdout to stderr https://hg.python.org/cpython/rev/24dbca4e746c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 15 23:38:05 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 15 Sep 2015 21:38:05 +0000 Subject: [issue25080] The example-code for making XLM-RPC requests through proxy, fail! In-Reply-To: <1442059715.67.0.31958758043.issue25080@psf.upfronthosting.co.za> Message-ID: <1442353085.28.0.409027558916.issue25080@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- components: -Demos and Tools stage: -> needs patch type: -> behavior versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 00:02:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 15 Sep 2015 22:02:00 +0000 Subject: [issue25122] test_eintr randomly fails on FreeBSD In-Reply-To: <1442311779.01.0.43728096223.issue25122@psf.upfronthosting.co.za> Message-ID: <20150915220155.68875.3376@psf.io> Roundup Robot added the comment: New changeset 5388fa98f7a3 by Victor Stinner in branch 'default': Issue #25122: optimize test_eintr https://hg.python.org/cpython/rev/5388fa98f7a3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 01:00:25 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 15 Sep 2015 23:00:25 +0000 Subject: [issue25080] The example-code for making XML-RPC requests through proxy, fail! In-Reply-To: <1442059715.67.0.31958758043.issue25080@psf.upfronthosting.co.za> Message-ID: <1442358025.7.0.433134063583.issue25080@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- title: The example-code for making XLM-RPC requests through proxy, fail! -> The example-code for making XML-RPC requests through proxy, fail! _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 01:12:56 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 15 Sep 2015 23:12:56 +0000 Subject: [issue25135] Deques to adopt the standard clearing procedure for mutable objects Message-ID: <1442358776.69.0.0875538895398.issue25135@psf.upfronthosting.co.za> New submission from Raymond Hettinger: The clear method for deques is possibly reentrant. Use the safer technique used in listobject.c, setobject.c, and dictobject.c. ---------- assignee: rhettinger components: Extension Modules messages: 250811 nosy: rhettinger priority: normal severity: normal stage: patch review status: open title: Deques to adopt the standard clearing procedure for mutable objects versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 01:13:33 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 15 Sep 2015 23:13:33 +0000 Subject: [issue25135] Deques to adopt the standard clearing procedure for mutable objects In-Reply-To: <1442358776.69.0.0875538895398.issue25135@psf.upfronthosting.co.za> Message-ID: <1442358813.0.0.264975265693.issue25135@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- keywords: +patch Added file: http://bugs.python.org/file40477/deque_nonreentrant_clear.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 01:53:14 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 15 Sep 2015 23:53:14 +0000 Subject: [issue25130] Make tests more PyPy compatible In-Reply-To: <1442340924.34.0.752221775968.issue25130@psf.upfronthosting.co.za> Message-ID: <1442361194.82.0.540237673627.issue25130@psf.upfronthosting.co.za> Martin Panter added the comment: Left some comments. There are a few test cases that I suspect are relying on side effects of garbage collection to perform some other test, and it would be better to rework the test. In the other cases, I agree that actual garbage collection behaviour is being tested, and it makes sense to call gc_collect() or similar. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 03:03:03 2015 From: report at bugs.python.org (Tim Smith) Date: Wed, 16 Sep 2015 01:03:03 +0000 Subject: [issue25136] Python doesn't find Xcode 7 stub libraries Message-ID: <1442365383.18.0.302201830729.issue25136@psf.upfronthosting.co.za> New submission from Tim Smith: In Xcode 7, Apple is replacing many of the .dylibs in SDKROOT with textual stubs. [1] These files exist on disk with filenames like: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib/libz.tbd They are short YAML documents that look like this: [2] The same linker invocation that has always worked will continue to work with Xcode 7 (i.e. you still pass `-lz` to the linker), but this disrupts the checks that cpython's setup.py uses to determine if it can build extension modules. The dylibs physically exist on disk in /usr/lib, but since we've set -isysroot to the appropriate SDKROOT in CPPFLAGS, distutils searches for the dylibs in the sysroot path, and does not find them (since they have been replaced with .tbd stubs). Since distutils cannot find the libraries, setup.py declines to attempt to build any of the extension modules that depend on libraries in the OS X SDK, even though it would have succeeded if it had tried. Several Homebrew users have reported this while trialling Xcode 7 [3]. distutils should treat the .tbd files as a "real" library so that compiler.find_library_file succeeds and setup.py will proceed to attempt to build the extension modules. The attached diff applies against the 3.5.0 release and allows extension modules to be built against Xcode 7 without installing the Command-Line Tools package. If anyone is experiencing this issue, a workaround is to install the Xcode Command Line Tools package with `xcode-select --install` (which, among other things, installs headers to /usr/include), ensure the CLT is active with `xcode-select -s /Library/Developer/CommandLineTools`, and do not include `-isysroot` in CPPFLAGS when building python. [1]: https://forums.developer.apple.com/thread/4572 [2]: https://gist.github.com/474233e561e28e1a8866 [3]: https://github.com/Homebrew/homebrew/issues/41085 ---------- components: Build, Distutils, Macintosh files: xcode-stubs.diff keywords: patch messages: 250813 nosy: dstufft, eric.araujo, ned.deily, ronaldoussoren, tdsmith priority: normal severity: normal status: open title: Python doesn't find Xcode 7 stub libraries type: compile error Added file: http://bugs.python.org/file40478/xcode-stubs.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 03:36:32 2015 From: report at bugs.python.org (Markus Holtermann) Date: Wed, 16 Sep 2015 01:36:32 +0000 Subject: [issue25137] Behavioral change / regression? with nested functools.partial Message-ID: <1442367392.37.0.924790344603.issue25137@psf.upfronthosting.co.za> New submission from Markus Holtermann: Since #7830 nested partials are flattened. This is a behavioral change that causes a test failure in Django because we use nested partials to resolve relationships between models: https://github.com/django/django/pull/4423#issuecomment-138996095 In my opinion this is a regression since there's no way to turn off the new behavior. ---------- components: Library (Lib) messages: 250814 nosy: MarkusH, belopolsky priority: normal severity: normal status: open title: Behavioral change / regression? with nested functools.partial type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 03:46:26 2015 From: report at bugs.python.org (Tim Graham) Date: Wed, 16 Sep 2015 01:46:26 +0000 Subject: [issue25137] Behavioral change / regression? with nested functools.partial In-Reply-To: <1442367392.37.0.924790344603.issue25137@psf.upfronthosting.co.za> Message-ID: <1442367986.71.0.428175900584.issue25137@psf.upfronthosting.co.za> Changes by Tim Graham : ---------- nosy: +Tim.Graham _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 04:00:51 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 16 Sep 2015 02:00:51 +0000 Subject: [issue25137] Behavioral change / regression? with nested functools.partial In-Reply-To: <1442367392.37.0.924790344603.issue25137@psf.upfronthosting.co.za> Message-ID: <1442368851.04.0.346961620603.issue25137@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +ncoghlan, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 04:10:52 2015 From: report at bugs.python.org (Tim Peters) Date: Wed, 16 Sep 2015 02:10:52 +0000 Subject: [issue25129] suboptimal floating-point floor division In-Reply-To: <1442338083.45.0.230324673027.issue25129@psf.upfronthosting.co.za> Message-ID: <1442369452.51.0.401131704006.issue25129@psf.upfronthosting.co.za> Tim Peters added the comment: BTW, I find this very hard to understand: "it?s possible for x//y to be one larger than" ... This footnote was written long before "//" was defined for floats. IIRC, the original version must have said something like: "it's possible for floor(x/y) to be one larger than" ... instead. Which does make sense ... yup, the old docs were actually coherent here ;-) https://docs.python.org/release/2.1/ref/binary.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 04:20:23 2015 From: report at bugs.python.org (Simon Charette) Date: Wed, 16 Sep 2015 02:20:23 +0000 Subject: [issue25137] Behavioral change / regression? with nested functools.partial In-Reply-To: <1442367392.37.0.924790344603.issue25137@psf.upfronthosting.co.za> Message-ID: <1442370023.43.0.418553205438.issue25137@psf.upfronthosting.co.za> Changes by Simon Charette : ---------- nosy: +charettes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 06:06:21 2015 From: report at bugs.python.org (Tim Smith) Date: Wed, 16 Sep 2015 04:06:21 +0000 Subject: [issue25136] Python doesn't find Xcode 7 stub libraries In-Reply-To: <1442365383.18.0.302201830729.issue25136@psf.upfronthosting.co.za> Message-ID: <1442376381.59.0.834005053332.issue25136@psf.upfronthosting.co.za> Changes by Tim Smith : Added file: http://bugs.python.org/file40479/xcode-stubs-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 07:22:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Sep 2015 05:22:32 +0000 Subject: [issue25130] Make tests more PyPy compatible In-Reply-To: <1442340924.34.0.752221775968.issue25130@psf.upfronthosting.co.za> Message-ID: <1442380952.54.0.0234712485747.issue25130@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your comments Martin. I need a time to think over them and provide alternative solutions that less depend on garbage collecting. May be Maciej can answer questions about causes of some PyPy changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 08:52:45 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Sep 2015 06:52:45 +0000 Subject: [issue25138] test_socket: socket.EAI_NODATA doesn't exist on FreeBSD Message-ID: <1442386365.65.0.414098178984.issue25138@psf.upfronthosting.co.za> New submission from STINNER Victor: test_socket.test_idna() uses socket.EAI_NODATA constant which doesn't exists on FreeBSD. http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/3697/steps/test/logs/stdio ====================================================================== ERROR: test_idna (test.test_socket.GeneralModuleTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_socket.py", line 1294, in test_idna socket.gethostbyname('python.org') socket.gaierror: [Errno 8] hostname nor servname provided, or not known During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_socket.py", line 1296, in test_idna if e.errno == socket.EAI_NODATA: AttributeError: module 'socket' has no attribute 'EAI_NODATA' ---------- components: Tests messages: 250817 nosy: haypo priority: normal severity: normal status: open title: test_socket: socket.EAI_NODATA doesn't exist on FreeBSD versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 08:55:30 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Sep 2015 06:55:30 +0000 Subject: [issue25122] test_eintr randomly fails on FreeBSD In-Reply-To: <1442311779.01.0.43728096223.issue25122@psf.upfronthosting.co.za> Message-ID: <1442386530.66.0.312955606952.issue25122@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, I got the first interesting result thanks to my enhancements of test_eintr: [383/398/1] test_eintr test_read (__main__.OSEINTRTest) ... ok test_wait (__main__.OSEINTRTest) ... ok test_wait3 (__main__.OSEINTRTest) ... ok test_wait4 (__main__.OSEINTRTest) ... ok test_waitpid (__main__.OSEINTRTest) ... ok test_write (__main__.OSEINTRTest) ... ok test_accept (__main__.SocketEINTRTest) ... ok test_open (__main__.SocketEINTRTest) ... Timeout (0:05:00)! Thread 0x0000000801807400 (most recent call first): File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/eintrdata/eintr_tester.py", line 340 in File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/eintrdata/eintr_tester.py", line 334 in _test_open File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/eintrdata/eintr_tester.py", line 340 in test_open File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/case.py", line 600 in run File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/case.py", line 648 in __call__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 122 in run File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 84 in __call__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 122 in run File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 84 in __call__ File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/runner.py", line 176 in run File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/__init__.py", line 1775 in _run_suite File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/__init__.py", line 1809 in run_unittest File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/eintrdata/eintr_tester.py", line 461 in test_main File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/eintrdata/eintr_tester.py", line 465 in test_all (test.test_eintr.EINTRTests) ... FAIL ====================================================================== FAIL: test_all (test.test_eintr.EINTRTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_eintr.py", line 25, in test_all self.assertEqual(exitcode, 0) AssertionError: 1 != 0 ---------------------------------------------------------------------- Ran 1 test in 306.939s FAILED (failures=1) Warning -- files was modified by test_eintr test test_eintr failed ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 09:01:24 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 16 Sep 2015 07:01:24 +0000 Subject: [issue25137] Behavioral change / regression? with nested functools.partial In-Reply-To: <1442367392.37.0.924790344603.issue25137@psf.upfronthosting.co.za> Message-ID: <1442386884.02.0.934787176893.issue25137@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The specific attributes of a partial are not documented, so it is you are relying on them. Using partial as a container is also a bit unexpected... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 09:09:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Sep 2015 07:09:10 +0000 Subject: [issue25137] Behavioral change / regression? with nested functools.partial In-Reply-To: <1442367392.37.0.924790344603.issue25137@psf.upfronthosting.co.za> Message-ID: <1442387350.19.0.308185298734.issue25137@psf.upfronthosting.co.za> STINNER Victor added the comment: > In my opinion this is a regression since there's no way to turn off the new behavior. Well, it depends on your point of view :-) On the performance point of view, it's much faster to flatten heavily nested partials like: >>> import functools >>> f = functools.partial(print, 1) >>> f = functools.partial(f, 2) >>> f = functools.partial(f, 3) >>> f = functools.partial(f, 4) >>> f = functools.partial(f, 5) >>> f() 1 2 3 4 5 > This is a behavioral change that causes a test failure in Django because we use nested partials to resolve relationships between models Can you point me to the code? Why do you need to know the full chain of nested partials? If you need to remember the chain of actions, maybe you can store it manually? You can add an attribute to a functools.partial() object. Or you can create a subclass of functools.partial. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 09:12:37 2015 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 16 Sep 2015 07:12:37 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442387557.18.0.838120857618.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: I rewrote the format_spec parser to recursively call the f-string parser, so any oddness in what's allowed in a format_spec is gone. It took way longer than I thought, but the code is better for it. ---------- Added file: http://bugs.python.org/file40480/pep-498-6.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 09:23:46 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 16 Sep 2015 07:23:46 +0000 Subject: [issue25122] test_eintr randomly fails on FreeBSD In-Reply-To: <1442311779.01.0.43728096223.issue25122@psf.upfronthosting.co.za> Message-ID: <20150916072343.24047.49479@psf.io> Roundup Robot added the comment: New changeset 30bc256f2346 by Victor Stinner in branch 'default': Issue #25122: add debug traces to test_eintr.test_open() https://hg.python.org/cpython/rev/30bc256f2346 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 09:27:49 2015 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 16 Sep 2015 07:27:49 +0000 Subject: [issue25129] suboptimal floating-point floor division In-Reply-To: <1442338083.45.0.230324673027.issue25129@psf.upfronthosting.co.za> Message-ID: <1442388469.84.0.653167780152.issue25129@psf.upfronthosting.co.za> Mark Dickinson added the comment: I agree with Tim that this is the correct behaviour. Antoine: okay to close? Or should we leave it open for the doc fix that Tim noticed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 09:33:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Sep 2015 07:33:42 +0000 Subject: [issue25130] Make tests more PyPy compatible In-Reply-To: <1442340924.34.0.752221775968.issue25130@psf.upfronthosting.co.za> Message-ID: <1442388821.99.0.881009921654.issue25130@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Just for reference here is a full difference between 2.7 tests in PyPy and CPython. It makes tests fail in CPython and skips some tests or makes them too lenient. ---------- Added file: http://bugs.python.org/file40481/pypy_tests-2.7_full.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 09:41:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Sep 2015 07:41:41 +0000 Subject: [issue25129] suboptimal floating-point floor division In-Reply-To: <1442338083.45.0.230324673027.issue25129@psf.upfronthosting.co.za> Message-ID: <1442389301.15.0.440266788881.issue25129@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: >>> from fractions import Fraction >>> Fraction(78*6e-8) / Fraction(6e-8) Fraction(353610802237278976, 4533471823554859) >>> Fraction(78*6e-8) // Fraction(6e-8) 77 >>> float(Fraction(78*6e-8) / Fraction(6e-8)) 78.0 >>> Fraction(78*6e-8) / Fraction(6e-8) - 78 Fraction(-26, 4533471823554859) The root of the issue is that >>> Fraction(78*6e-8) != Fraction(78*6, 10**8) True >>> Fraction(6e-8) != Fraction(6, 10**8) True ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 09:49:51 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 16 Sep 2015 07:49:51 +0000 Subject: [issue25129] suboptimal floating-point floor division In-Reply-To: <1442338083.45.0.230324673027.issue25129@psf.upfronthosting.co.za> Message-ID: <1442389791.23.0.447325812099.issue25129@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I have no problem with closing. Admittedly, I opened this issue mostly to get a witty and enlightening response :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 09:52:05 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Sep 2015 07:52:05 +0000 Subject: [issue25129] suboptimal floating-point floor division In-Reply-To: <1442338083.45.0.230324673027.issue25129@psf.upfronthosting.co.za> Message-ID: <1442389925.8.0.630408490886.issue25129@psf.upfronthosting.co.za> STINNER Victor added the comment: """ The root of the issue is that >>> Fraction(78*6e-8) != Fraction(78*6, 10**8) True >>> Fraction(6e-8) != Fraction(6, 10**8) True """ It's not an issue, it's just a fact: floating point rounding is annoying and very few people understand it :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 09:59:11 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Sep 2015 07:59:11 +0000 Subject: [issue25122] test_eintr randomly fails on FreeBSD In-Reply-To: <1442311779.01.0.43728096223.issue25122@psf.upfronthosting.co.za> Message-ID: <1442390351.79.0.911263911319.issue25122@psf.upfronthosting.co.za> STINNER Victor added the comment: More debug traces: test_open (__main__.SocketEINTRTest) ... try to open '@test_57236_tmp' fifo for writing, pid 57236 try to open '@test_57236_tmp' fifo for reading, pid 57305, ppid 57236 '@test_57236_tmp' fifo opened for reading and closed, pid 57305, ppid 57236 Timeout (0:05:00)! Thread 0x0000000802006400 (most recent call first): File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/eintrdata/eintr_tester.py", line 354 in File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/eintrdata/eintr_tester.py", line 345 in _test_open File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/eintrdata/eintr_tester.py", line 354 in test_open File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/case.py", line 600 in run File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/case.py", line 648 in __call__ File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 122 in run File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 84 in __call__ File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 122 in run File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 84 in __call__ File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/runner.py", line 176 in run File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 1775 in _run_suite File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 1809 in run_unittest File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/eintrdata/eintr_tester.py", line 475 in test_main File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/eintrdata/eintr_tester.py", line 479 in ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 10:00:21 2015 From: report at bugs.python.org (Florian Bruhin) Date: Wed, 16 Sep 2015 08:00:21 +0000 Subject: [issue24493] subprocess with env=os.environ doesn't preserve environment variables when calling a 32bit process on Windows 8.1 In-Reply-To: <1435091827.68.0.4316449172.issue24493@psf.upfronthosting.co.za> Message-ID: <1442390421.18.0.997680634958.issue24493@psf.upfronthosting.co.za> Florian Bruhin added the comment: I just ran into this again - when trying to run `git` via subprocess with "env" set, I got: # Start the process try: hp, ht, pid, tid = _winapi.CreateProcess(executable, args, # no special security None, None, int(not close_fds), creationflags, env, cwd, > startupinfo) E FileNotFoundError: [WinError 2] The system cannot find the file specified This only seems to happen when starting my Python process in cmd.exe, not when it's started via my buildbot (CI). Again, when passing shell=True everything worked - except when passing `cwd` as well, then it's broken again. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 10:02:11 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Sep 2015 08:02:11 +0000 Subject: [issue24493] subprocess with env=os.environ doesn't preserve environment variables when calling a 32bit process on Windows 8.1 In-Reply-To: <1435091827.68.0.4316449172.issue24493@psf.upfronthosting.co.za> Message-ID: <1442390531.59.0.917991784876.issue24493@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 10:41:05 2015 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 16 Sep 2015 08:41:05 +0000 Subject: [issue25129] suboptimal floating-point floor division In-Reply-To: <1442338083.45.0.230324673027.issue25129@psf.upfronthosting.co.za> Message-ID: <1442392865.06.0.0978674421754.issue25129@psf.upfronthosting.co.za> Mark Dickinson added the comment: > What is the rounding mode used by true division, by the way? Probably not what you were asking, but with respect to true division of integers (int / int -> float), we always use round-half-to-even. Any deviation from that (non-IEEE 754 platforms excepted) is a bug that should be reported. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 10:51:46 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Sep 2015 08:51:46 +0000 Subject: [issue25122] test_eintr randomly fails on FreeBSD In-Reply-To: <1442311779.01.0.43728096223.issue25122@psf.upfronthosting.co.za> Message-ID: <1442393506.65.0.25431238584.issue25122@psf.upfronthosting.co.za> STINNER Victor added the comment: Syscalls traced by truss. Parent process: 1436: unlink("fifo_5950861521") ERR#2 'No such file or directory' 1436: open("fifo_5950861521",O_WRONLY|O_CLOEXEC,00) ERR#4 'Interrupted system call' 1436: open("fifo_5950861521",O_WRONLY|O_CLOEXEC,00) ERR#4 'Interrupted system call' ... 1436: open("fifo_5950861521",O_WRONLY|O_CLOEXEC,00) ERR#4 'Interrupted system call' Child process: 2689: open("fifo_5950861521",O_CLOEXEC,00) = 3 (0x3) 2689: close(3) ERR#4 'Interrupted system call' Hum, it looks like the child process gets signals, many syscalls are interrupted by signals. In my simple test, 7 syscalls were interrupted by signals in the child process. I didn't expect "setitimer" to be inherited by subprocess.Popen. The suspicious thing is that close() fails with EINTR in the child process and it is not retried. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 10:54:53 2015 From: report at bugs.python.org (Maciej Fijalkowski) Date: Wed, 16 Sep 2015 08:54:53 +0000 Subject: [issue25130] Make tests more PyPy compatible In-Reply-To: <1442340924.34.0.752221775968.issue25130@psf.upfronthosting.co.za> Message-ID: <1442393693.18.0.0595100954176.issue25130@psf.upfronthosting.co.za> Maciej Fijalkowski added the comment: Hi I can answer precise questions, which tests are you asking about? Note that if the point is to unify the test suite, would be cool to make changes to both pypy and cpython and not just change cpython one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 11:26:03 2015 From: report at bugs.python.org (=?utf-8?b?0JDQu9C10LrRgdC10Lkg0KHQvNC40YDQvdC+0LI=?=) Date: Wed, 16 Sep 2015 09:26:03 +0000 Subject: [issue25139] Just a little refactoring Message-ID: <1442395563.59.0.192959239996.issue25139@psf.upfronthosting.co.za> New submission from ??????? ???????: https://github.com/python/cpython/blob/3.5/Lib/socketserver.py#L627 Must be: try: self.finish_request(request, client_address) except: self.handle_error(request, client_address) finally: self.shutdown_request(request) ---------- components: Library (Lib) hgrepos: 317 messages: 250833 nosy: ??????? ??????? priority: normal severity: normal status: open title: Just a little refactoring type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 12:01:56 2015 From: report at bugs.python.org (Maciej Fijalkowski) Date: Wed, 16 Sep 2015 10:01:56 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442397716.17.0.220586689545.issue25106@psf.upfronthosting.co.za> Maciej Fijalkowski added the comment: I find numbers really hard to believe. It would mean that over 40% of django templates is string hashing (assuming 2x speedup) which really sounds unbelievable. In fact in PyPy I never found string hashing to be significant while I would expect PyPy to have string hashing more of a bottleneck, since it's almost never optimized away really. What made you think string hashing is a good target for optimizations? ---------- nosy: +fijall _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 12:32:20 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 16 Sep 2015 10:32:20 +0000 Subject: [issue25130] Make tests more PyPy compatible In-Reply-To: <1442340924.34.0.752221775968.issue25130@psf.upfronthosting.co.za> Message-ID: <1442399540.94.0.170023007896.issue25130@psf.upfronthosting.co.za> Martin Panter added the comment: Maciej: I put a few questions and comments in the code review. See the (also linked next to Serhiy?s first patch). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 12:39:14 2015 From: report at bugs.python.org (Maciej Fijalkowski) Date: Wed, 16 Sep 2015 10:39:14 +0000 Subject: [issue25130] Make tests more PyPy compatible In-Reply-To: <1442340924.34.0.752221775968.issue25130@psf.upfronthosting.co.za> Message-ID: <1442399954.8.0.559372338967.issue25130@psf.upfronthosting.co.za> Maciej Fijalkowski added the comment: Hi Looking through your comments, yes, maybe those tests or those things require fixing. We at pypy don't have enough will to fight python-dev most of the time, so the usual approach is to do "minimal hack that works" without trying to dwelve into why this or that works that way. Obviously feel free to fix the underlaying issue, we'll be happy to commit it to pypy ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 12:59:18 2015 From: report at bugs.python.org (Andrey Fedyashov) Date: Wed, 16 Sep 2015 10:59:18 +0000 Subject: [issue25140] platform.platform() incorrectly identifies Windows 10 as 'Windows-8-6.2.9200' Message-ID: <1442401158.46.0.714656065046.issue25140@psf.upfronthosting.co.za> New submission from Andrey Fedyashov: Here's actual OS version: OS Name: Microsoft Windows 10 Enterprise Insider Preview OS Version: 10.0.10534 N/A Build 10534 OS Manufacturer: Microsoft Corporation OS Configuration: Standalone Workstation OS Build Type: Multiprocessor Free Here is bug repro with Python 3.4 Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import platform >>> platform.platform() 'Windows-8-6.2.9200' Here is bug repro with Python 2.7 Python 2.7.10 (default, May 23 2015, 09:44:00) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import platform >>> platform.platform() 'Windows-8-6.2.9200' ---------- components: Library (Lib), Windows messages: 250837 nosy: Andrey Fedyashov, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: platform.platform() incorrectly identifies Windows 10 as 'Windows-8-6.2.9200' type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 13:22:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 16 Sep 2015 11:22:11 +0000 Subject: [issue25140] platform.platform() incorrectly identifies Windows 10 as 'Windows-8-6.2.9200' In-Reply-To: <1442401158.46.0.714656065046.issue25140@psf.upfronthosting.co.za> Message-ID: <1442402531.99.0.328677713662.issue25140@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: A duplicate of issue19143? ---------- nosy: +lemburg, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 13:46:03 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 16 Sep 2015 11:46:03 +0000 Subject: [issue25140] platform.platform() incorrectly identifies Windows 10 as 'Windows-8-6.2.9200' In-Reply-To: <1442402531.99.0.328677713662.issue25140@psf.upfronthosting.co.za> Message-ID: <55F9566C.9070603@egenix.com> Marc-Andre Lemburg added the comment: On 16.09.2015 13:22, Serhiy Storchaka wrote: > > A duplicate of issue19143? I guess so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 13:46:20 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 16 Sep 2015 11:46:20 +0000 Subject: [issue25140] platform.platform() incorrectly identifies Windows 10 as 'Windows-8-6.2.9200' In-Reply-To: <1442401158.46.0.714656065046.issue25140@psf.upfronthosting.co.za> Message-ID: <1442403980.93.0.171710631313.issue25140@psf.upfronthosting.co.za> Changes by Marc-Andre Lemburg : ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 13:47:34 2015 From: report at bugs.python.org (Jonas Obrist) Date: Wed, 16 Sep 2015 11:47:34 +0000 Subject: [issue24927] multiprocessing.Pool hangs forever on segfault In-Reply-To: <1440435917.07.0.324379639121.issue24927@psf.upfronthosting.co.za> Message-ID: <1442404054.43.0.443245856485.issue24927@psf.upfronthosting.co.za> Changes by Jonas Obrist : ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 13:48:27 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 16 Sep 2015 11:48:27 +0000 Subject: [issue19143] Finding the Windows version getting messier (detect windows 8.1?) In-Reply-To: <1380675004.25.0.239416620624.issue19143@psf.upfronthosting.co.za> Message-ID: <1442404107.7.0.363196393203.issue19143@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Steve: Could you please merge your changes into platform.py ? I think it should go into Python 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 14:04:48 2015 From: report at bugs.python.org (Grant Bremer) Date: Wed, 16 Sep 2015 12:04:48 +0000 Subject: [issue25115] SSL_set_verify_depth not exposed by the ssl module In-Reply-To: <1442280676.76.0.937947035148.issue25115@psf.upfronthosting.co.za> Message-ID: <1442405088.26.0.684473500113.issue25115@psf.upfronthosting.co.za> Changes by Grant Bremer : ---------- hgrepos: -316 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 14:08:25 2015 From: report at bugs.python.org (Grant Bremer) Date: Wed, 16 Sep 2015 12:08:25 +0000 Subject: [issue25115] SSL_set_verify_depth not exposed by the ssl module In-Reply-To: <1442280676.76.0.937947035148.issue25115@psf.upfronthosting.co.za> Message-ID: <1442405304.99.0.0570268068479.issue25115@psf.upfronthosting.co.za> Grant Bremer added the comment: Attached is a patch for the 3.5 branch. The test is minimal -- we are relying on the underlying OpenSSL library and its context to manage the data. I have removed the data validation from the set function -- OpenSSL seems happy to accept negative numbers for depth, even if that is a non-sensical value. I have started on the documentation, and can do a more comprehensive job if the code section is good or mostly good. I'll do the same for the 2.7 patch. ---------- Added file: http://bugs.python.org/file40483/verify_depth-3.5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 14:11:20 2015 From: report at bugs.python.org (Petri Lehtinen) Date: Wed, 16 Sep 2015 12:11:20 +0000 Subject: [issue25141] Spam In-Reply-To: <1442402300.63.0.765455905044.issueNone@psf.upfronthosting.co.za> Message-ID: <1442405480.53.0.425516133748.issue25141@psf.upfronthosting.co.za> Changes by Petri Lehtinen : ---------- status: open -> closed title: Returned mail: see transcript for details -> Spam _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 14:11:32 2015 From: report at bugs.python.org (Petri Lehtinen) Date: Wed, 16 Sep 2015 12:11:32 +0000 Subject: [issue25141] Spam In-Reply-To: <1442402300.63.0.765455905044.issueNone@psf.upfronthosting.co.za> Message-ID: <1442405492.84.0.55802334913.issue25141@psf.upfronthosting.co.za> Changes by Petri Lehtinen : Removed file: http://bugs.python.org/file40482/mail.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 14:22:35 2015 From: report at bugs.python.org (Brian Boonstra) Date: Wed, 16 Sep 2015 12:22:35 +0000 Subject: [issue22393] multiprocessing.Pool shouldn't hang forever if a worker process dies unexpectedly In-Reply-To: <1410474786.78.0.264797717105.issue22393@psf.upfronthosting.co.za> Message-ID: <1442406155.1.0.185319629414.issue22393@psf.upfronthosting.co.za> Changes by Brian Boonstra : ---------- nosy: +brianboonstra _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 14:29:44 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 16 Sep 2015 12:29:44 +0000 Subject: [issue24493] subprocess with env=os.environ doesn't preserve environment variables when calling a 32bit process on Windows 8.1 In-Reply-To: <1435091827.68.0.4316449172.issue24493@psf.upfronthosting.co.za> Message-ID: <1442406584.67.0.700900901044.issue24493@psf.upfronthosting.co.za> R. David Murray added the comment: Sounds like there's something in the cwd that is making the difference (this being Windows which looks for things in the cwd always). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 14:33:34 2015 From: report at bugs.python.org (Florian Bruhin) Date: Wed, 16 Sep 2015 12:33:34 +0000 Subject: [issue24493] subprocess with env=os.environ doesn't preserve environment variables when calling a 32bit process on Windows 8.1 In-Reply-To: <1435091827.68.0.4316449172.issue24493@psf.upfronthosting.co.za> Message-ID: <1442406814.27.0.0277425043777.issue24493@psf.upfronthosting.co.za> Florian Bruhin added the comment: > Sounds like there's something in the cwd that is making the difference (this being Windows which looks for things in the cwd always). The cwd is an empty temporary directory. And that still wouldn't explain why passing env=os.environ breaks it as well, and why it only breaks in cmd.exe, and only when launching a 32bit process ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 14:38:11 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 16 Sep 2015 12:38:11 +0000 Subject: [issue25095] test_httpservers hangs on 3.5.0, win 7 In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za> Message-ID: <1442407091.89.0.0584776667937.issue25095@psf.upfronthosting.co.za> Martin Panter added the comment: According to those back traces, the server has apparently already handled one request and is waiting for a second request. However the client is still waiting for a response from its original request. Some things I might try would be to disable the server, and make my own dummy server to see if it responds to that. Similarly, disable the client and manually make a request to the server and see what the response is. On Linux the ?socat? or ?netcat? programs are useful for this stuff, or you can just use the Python interactive interpreter to create a socket and send and receive. Client connection is made at . Server is constructed at . You could also try adding self.con.set_debuglevel(99) to the test_get() method, though I suspect it will just output the request sent, and not report any reply or headers. In my case the test works, and I see: send: b'GET / HTTP/1.1\r\nHost: 127.0.0.1:48059\r\nAccept-Encoding: identity\r\n\r\n' reply: 'HTTP/1.1 200 OK\r\n' [Unit test output] header: Server header: Date $ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 14:47:57 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Sep 2015 12:47:57 +0000 Subject: [issue25095] test_httpservers hangs on 3.5.0, win 7 In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za> Message-ID: <1442407677.87.0.492885854966.issue25095@psf.upfronthosting.co.za> STINNER Victor added the comment: You may try "hg bisect" to find which revision broke test_httpservers. It can be slow if you have to recompile manually Python :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 16:14:18 2015 From: report at bugs.python.org (eryksun) Date: Wed, 16 Sep 2015 14:14:18 +0000 Subject: [issue24493] subprocess with env=os.environ doesn't preserve environment variables when calling a 32bit process on Windows 8.1 In-Reply-To: <1435091827.68.0.4316449172.issue24493@psf.upfronthosting.co.za> Message-ID: <1442412858.41.0.188614430611.issue24493@psf.upfronthosting.co.za> eryksun added the comment: The issue as I understand it is that, on this particular Windows 8.1 system, passing a non-NULL lpEnvironment to CreateProcess works when starting a native 64-bit executable, but fails when starting a 32-bit executable via the WOW64 system. The child process instead gets an empty environment block. As an additional check, run the following command in 64-bit cmd.exe: start "" /I "%SystemRoot%\SysWOW64\cmd.exe" The /I option of the start command passes the shell's original environment to CreateProcess, so it should exhibit the same empty-environment problem when starting 32-bit cmd.exe. In this case you'll get cmd's default environment, which includes COMSPEC, PATHEXT, and PROMPT. Since inheriting the current environment works in all cases and passing a custom environment works for 64-bit executables, the workaround that I suggested is to use shell=True to pass your custom environment to the shell. The 32-bit executable thus inherits the custom environment from the shell. If using shell=True is a security concern, then you can replace it with a Python script that executes and waits for the child process. > when passing shell=True everything worked - except > when passing `cwd` as well, then it's broken again. Since the shell executes the file, a relative path is resolved against the shell's working directory. If you set the latter via the cwd parameter, then pass the file's path as either relative to the cwd path or as a fully qualified path. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 16:16:29 2015 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 16 Sep 2015 14:16:29 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442412989.25.0.588890264629.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: Simplified error handling, fixed 2 memory leaks. All tests now pass with no leaks. This should be the final version. ---------- Added file: http://bugs.python.org/file40484/pep-498-7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 16:48:47 2015 From: report at bugs.python.org (Sebastian Kreft) Date: Wed, 16 Sep 2015 14:48:47 +0000 Subject: [issue25142] Misleading error when initing ImportError Message-ID: <1442414927.94.0.928583151354.issue25142@psf.upfronthosting.co.za> New submission from Sebastian Kreft: ImportError now supports the keyword arguments name and path. However, when passing invalid keyword arguments, the reported error is misleading, as shown below. In [1]: ImportError('lib', name='lib') Out[1]: ImportError('lib') In [2]: ImportError('lib', name='lib', foo='foo') --------------------------------------------------------------------------- TypeError Traceback (most recent call last) in () ----> 1 ImportError('lib', name='lib', foo='foo') TypeError: ImportError does not take keyword arguments ---------- messages: 250850 nosy: Sebastian Kreft priority: normal severity: normal status: open title: Misleading error when initing ImportError versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 17:36:45 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 16 Sep 2015 15:36:45 +0000 Subject: [issue25140] platform.platform() incorrectly identifies Windows 10 as 'Windows-8-6.2.9200' In-Reply-To: <1442401158.46.0.714656065046.issue25140@psf.upfronthosting.co.za> Message-ID: <1442417805.17.0.186644884661.issue25140@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- superseder: -> Finding the Windows version getting messier (detect windows 8.1?) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 17:37:02 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 16 Sep 2015 15:37:02 +0000 Subject: [issue25140] platform.platform() incorrectly identifies Windows 10 as 'Windows-8-6.2.9200' In-Reply-To: <1442401158.46.0.714656065046.issue25140@psf.upfronthosting.co.za> Message-ID: <1442417822.26.0.921227982213.issue25140@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 18:12:57 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 16 Sep 2015 16:12:57 +0000 Subject: [issue25113] documentation version switcher is broken In-Reply-To: <1442259134.08.0.318415245407.issue25113@psf.upfronthosting.co.za> Message-ID: <1442419977.61.0.82023569168.issue25113@psf.upfronthosting.co.za> Yury Selivanov added the comment: The switcher isn't visible on all pages, I suspect we need to bust caches on cdns/varnish ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 18:18:06 2015 From: report at bugs.python.org (Paul) Date: Wed, 16 Sep 2015 16:18:06 +0000 Subject: [issue25143] 3.5 install fails poorly on Windows XP Message-ID: <1442420286.68.0.457975935538.issue25143@psf.upfronthosting.co.za> New submission from Paul: Running the installer on an unsupported system (such as Windows XP)should fail gracefully and not just leave the user hanging. https://mail.python.org/pipermail/python-list/2015-September/696789.html ---------- components: Installation messages: 250852 nosy: pwatson at phs.org priority: normal severity: normal status: open title: 3.5 install fails poorly on Windows XP type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 18:19:31 2015 From: report at bugs.python.org (Paul) Date: Wed, 16 Sep 2015 16:19:31 +0000 Subject: [issue25143] 3.5 install fails poorly on Windows XP In-Reply-To: <1442420286.68.0.457975935538.issue25143@psf.upfronthosting.co.za> Message-ID: <1442420371.4.0.4914036222.issue25143@psf.upfronthosting.co.za> Paul added the comment: Installing on an unsupported platform should fail gracefully. https://mail.python.org/pipermail/python-list/2015-September/696789.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 18:25:46 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 16 Sep 2015 16:25:46 +0000 Subject: [issue25143] 3.5 install fails poorly on Windows XP In-Reply-To: <1442420286.68.0.457975935538.issue25143@psf.upfronthosting.co.za> Message-ID: <1442420746.13.0.5983257595.issue25143@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- components: +Windows -Installation nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 18:34:35 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 16 Sep 2015 16:34:35 +0000 Subject: [issue25142] Misleading error when initing ImportError In-Reply-To: <1442414927.94.0.928583151354.issue25142@psf.upfronthosting.co.za> Message-ID: <1442421275.88.0.0663341639655.issue25142@psf.upfronthosting.co.za> Brett Cannon added the comment: I bet it's because of https://hg.python.org/cpython/file/tip/Objects/exceptions.c#l64 which is called by https://hg.python.org/cpython/file/tip/Objects/exceptions.c#l643 . ---------- components: +Interpreter Core nosy: +brett.cannon type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 18:41:02 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 16 Sep 2015 16:41:02 +0000 Subject: [issue25143] 3.5 install fails poorly on Windows XP In-Reply-To: <1442420286.68.0.457975935538.issue25143@psf.upfronthosting.co.za> Message-ID: <1442421662.39.0.608000526862.issue25143@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- assignee: -> steve.dower components: +Installation stage: -> needs patch versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 19:01:10 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 16 Sep 2015 17:01:10 +0000 Subject: [issue24927] multiprocessing.Pool hangs forever on segfault In-Reply-To: <1440435917.07.0.324379639121.issue24927@psf.upfronthosting.co.za> Message-ID: <1442422870.75.0.737273867199.issue24927@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> resolved superseder: -> multiprocessing.Pool shouldn't hang forever if a worker process dies unexpectedly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 19:02:40 2015 From: report at bugs.python.org (Skip Montanaro) Date: Wed, 16 Sep 2015 17:02:40 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442422960.59.0.394889138352.issue25106@psf.upfronthosting.co.za> Changes by Skip Montanaro : ---------- nosy: +skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 19:04:38 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 16 Sep 2015 17:04:38 +0000 Subject: [issue25113] documentation version switcher is broken In-Reply-To: <1442259134.08.0.318415245407.issue25113@psf.upfronthosting.co.za> Message-ID: <1442423078.42.0.643959712809.issue25113@psf.upfronthosting.co.za> Ned Deily added the comment: We are pursuing the stale CDN cache issue with #python-infra. It appears that, as it stands, the cached doc pages will expire within a week. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 19:20:42 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 16 Sep 2015 17:20:42 +0000 Subject: [issue25142] Misleading error when initing ImportError In-Reply-To: <1442414927.94.0.928583151354.issue25142@psf.upfronthosting.co.za> Message-ID: <1442424042.43.0.623225810477.issue25142@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the report. This is a duplicate of issue 21578. ---------- nosy: +berker.peksag resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Misleading error message when ImportError called with invalid keyword args _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 19:21:23 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 16 Sep 2015 17:21:23 +0000 Subject: [issue21578] Misleading error message when ImportError called with invalid keyword args In-Reply-To: <1401078695.26.0.813929580296.issue21578@psf.upfronthosting.co.za> Message-ID: <1442424083.2.0.701028820334.issue21578@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> patch review versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 19:25:00 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 16 Sep 2015 17:25:00 +0000 Subject: [issue24598] asyncio: add background task detecting reference cycles In-Reply-To: <1436450645.37.0.566562867718.issue24598@psf.upfronthosting.co.za> Message-ID: <1442424300.8.0.527922297949.issue24598@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 19:35:32 2015 From: report at bugs.python.org (Felipe) Date: Wed, 16 Sep 2015 17:35:32 +0000 Subject: [issue25144] 3.5 Win install fails with "TARGETDIR" Message-ID: <1442424932.17.0.0389991499722.issue25144@psf.upfronthosting.co.za> New submission from Felipe: The 3.5 Windows installer fails with "The TARGETDIR variable must be provided when invoking this installer" Here are the steps I followed: 1. Initial screen: - uncheck the add path and all users options - select "Customize installation" 2. Optional features: - Check all boxes except "all users" 3. Advanced options - Uncheck all - Pick a different path to install to (clean folder) 4. A message box pops up saying "The TARGETDIR variable must be provided when invoking this installer" -- I hit OK. 5. Final screen showing 0x8007063 - Fatal error during installation I've saved the log file and can upload if helpful, but will have to remove personal info first ---------- components: Installation messages: 250857 nosy: fov priority: normal severity: normal status: open title: 3.5 Win install fails with "TARGETDIR" type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 19:38:26 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Wed, 16 Sep 2015 17:38:26 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442425106.74.0.85041868879.issue25106@psf.upfronthosting.co.za> Alecsandru Patrascu added the comment: Please hold this patch for a while, while I analyze the received feedback. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 19:38:49 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 16 Sep 2015 17:38:49 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442425129.83.0.104391378602.issue25106@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 19:57:35 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 16 Sep 2015 17:57:35 +0000 Subject: [issue25139] Just a little refactoring In-Reply-To: <1442395563.59.0.192959239996.issue25139@psf.upfronthosting.co.za> Message-ID: <1442426255.5.0.447099380235.issue25139@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: -> patch review versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 19:58:31 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 16 Sep 2015 17:58:31 +0000 Subject: [issue25139] Just a little refactoring In-Reply-To: <1442395563.59.0.192959239996.issue25139@psf.upfronthosting.co.za> Message-ID: <1442426311.23.0.908614225928.issue25139@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 20:48:19 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 16 Sep 2015 18:48:19 +0000 Subject: [issue22627] Calling timestamp() on a datetime object modifies the timestamp of a different datetime object. In-Reply-To: <1413250305.11.0.302636475589.issue22627@psf.upfronthosting.co.za> Message-ID: <1442429299.54.0.869314607868.issue22627@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I am reopening this issue as an "enhancement" because I would like to revisit it in light of PEP 495. ---------- assignee: -> belopolsky resolution: not a bug -> status: closed -> open type: behavior -> enhancement versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 20:51:59 2015 From: report at bugs.python.org (Tim Graham) Date: Wed, 16 Sep 2015 18:51:59 +0000 Subject: [issue25137] Behavioral change / regression? with nested functools.partial In-Reply-To: <1442367392.37.0.924790344603.issue25137@psf.upfronthosting.co.za> Message-ID: <1442429519.37.0.996868829791.issue25137@psf.upfronthosting.co.za> Tim Graham added the comment: We can use an alternate approach in Django, if appropriate: https://github.com/django/django/pull/5294 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 21:54:17 2015 From: report at bugs.python.org (Djoudi Benarfa) Date: Wed, 16 Sep 2015 19:54:17 +0000 Subject: [issue25143] 3.5 install fails poorly on Windows XP In-Reply-To: <1442420286.68.0.457975935538.issue25143@psf.upfronthosting.co.za> Message-ID: <1442433257.26.0.625580709886.issue25143@psf.upfronthosting.co.za> Djoudi Benarfa added the comment: The Python installer could check what operating system the user is trying to install python on and if it's not supported then, information him, and maybe redirect him to the correct python version. ---------- nosy: +djoudi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 22:13:13 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 16 Sep 2015 20:13:13 +0000 Subject: [issue25113] documentation version switcher is broken In-Reply-To: <1442259134.08.0.318415245407.issue25113@psf.upfronthosting.co.za> Message-ID: <1442434393.65.0.320340377705.issue25113@psf.upfronthosting.co.za> Mark Lawrence added the comment: This wasn't working for me earlier but it is now at 21:11 BST so I'd assume we can leave this closed. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 23:32:38 2015 From: report at bugs.python.org (Robert Xiao) Date: Wed, 16 Sep 2015 21:32:38 +0000 Subject: [issue25145] urllib how-to should be updated to remove PyGoogle Message-ID: <1442439158.29.0.495500663722.issue25145@psf.upfronthosting.co.za> New submission from Robert Xiao: PyGoogle has been dead for 6-7 years at this point (probably longer), yet the newest urllib documentation (https://docs.python.org/3/howto/urllib2.html#id1) still refers to it in a footnote: [1] Like Google for example. The proper way to use google from a program is to use PyGoogle of course. This should probably be amended to remove the outdated reference altogether (the footnote itself can probably just go). While we're at it: the user agent version strings are _really_ old - MSIE 5.5 and MSIE 6.0. I know they are just illustrative, but couldn't we at least update them to something from the last decade? :P ---------- assignee: docs at python components: Documentation messages: 250863 nosy: docs at python, nneonneo priority: normal severity: normal status: open title: urllib how-to should be updated to remove PyGoogle versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 16 23:50:21 2015 From: report at bugs.python.org (Mark Roseman) Date: Wed, 16 Sep 2015 21:50:21 +0000 Subject: [issue25146] IDLE debugger could better visualize program execution Message-ID: <1442440221.76.0.764553903841.issue25146@psf.upfronthosting.co.za> New submission from Mark Roseman: (This touches a bit on things mentioned in #14111) I'm looking through the debugger code in IDLE, and now understand that it's essentially trying to make a GUI program act like a command line program. Hence the nested call to mainloop(), when we receive a trace execution callback. This is the equivalent of saying "stop here until I input something, and then continue along" at which point the callback completes and we return to the running program. Right now, if you run a program with the debugger on, and just hit Go, it's just like you're not running it in the debugger at all. I've mentioned elsewhere (#15347) that I suspect the nested mainloop is behind some of the instability problems related to quitting when the debugger is active. But if we don't assume that each time we print where we are we have to wait for input, we can do some more interesting things. Most importantly, we should be able to say "Go", and actually watch our program being executed. In other words, whenever it goes to the next statement, the debugger actually shows that statement, highlights the line in the source file, updates variables, etc. -- all without user interaction. Someone can sit back and watch, getting a better understanding of what their program is doing while running. You'd be able to see if a program was stuck in a loop, without necessarily going through it one statement at a time, step by step, or setting breakpoints. It also makes it clearer that the program is running because you see something happening... now there's not great feedback in that regard. Similarly, some of the issues with pausing/continuing or stopping the program become a bit easier to deal with. ---------- components: IDLE messages: 250864 nosy: kbk, markroseman, roger.serwy, terry.reedy priority: normal severity: normal status: open title: IDLE debugger could better visualize program execution type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 00:01:35 2015 From: report at bugs.python.org (Zachary Ware) Date: Wed, 16 Sep 2015 22:01:35 +0000 Subject: [issue25145] urllib how-to should be updated to remove PyGoogle In-Reply-To: <1442439158.29.0.495500663722.issue25145@psf.upfronthosting.co.za> Message-ID: <1442440895.94.0.101776090751.issue25145@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- stage: -> needs patch versions: +Python 2.7 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 00:06:48 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Sep 2015 22:06:48 +0000 Subject: [issue25122] test_eintr randomly fails on FreeBSD In-Reply-To: <1442311779.01.0.43728096223.issue25122@psf.upfronthosting.co.za> Message-ID: <1442441208.42.0.85385620089.issue25122@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, I'm now quite sure that it's a bug in the FreeBSD kernel or in the BSD C library. The C library ignores EINTR: if the close() syscalls fails with EINTR, the C close() function returns a success. When the close() syscall fails with EINTR, the test hangs. It's unclear to me if the close() syscall fails with EINTR in the parent or in the child process. I'm quite sure that the FreeBSD truss tool (tool to trace syscalls) has bugs too, so it's hard to be sure what happens exactly. Attached tarball eintr_bug.tar.gz reproduces the bug in a program written in pure C language. So it's not a bug in Python. For test_eintr, we should skip the test on FreeBSD (until the bug is fixed in FreeBSD). ---------- Added file: http://bugs.python.org/file40485/eintr_bug.tar.gz _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 00:18:03 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 16 Sep 2015 22:18:03 +0000 Subject: [issue23551] IDLE to provide menu link to PIP gui. In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za> Message-ID: <1442441883.38.0.229671908948.issue23551@psf.upfronthosting.co.za> Terry J. Reedy added the comment: On python-ideas, Wes Turner reported Stallion, a visual (browser) + command line package manager interface. I believe it uses pip 'under the hood'. http://perone.github.io/stallion/ has screenshots that can give gui design ideas, though these are more elaborate than what we need. Package at https://pypi.python.org/pypi/Stallion ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 00:38:23 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 16 Sep 2015 22:38:23 +0000 Subject: [issue25122] test_eintr randomly fails on FreeBSD In-Reply-To: <1442311779.01.0.43728096223.issue25122@psf.upfronthosting.co.za> Message-ID: <1442443103.59.0.80467156317.issue25122@psf.upfronthosting.co.za> STINNER Victor added the comment: I reported the bug on the FreeBSD bug tracker: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203162 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 01:14:17 2015 From: report at bugs.python.org (Conrad Meyer) Date: Wed, 16 Sep 2015 23:14:17 +0000 Subject: [issue25122] test_eintr randomly fails on FreeBSD In-Reply-To: <1442311779.01.0.43728096223.issue25122@psf.upfronthosting.co.za> Message-ID: <1442445257.86.0.323285085221.issue25122@psf.upfronthosting.co.za> Changes by Conrad Meyer : ---------- nosy: +Conrad Meyer _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 01:31:32 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 16 Sep 2015 23:31:32 +0000 Subject: [issue25146] IDLE debugger could better visualize program execution In-Reply-To: <1442440221.76.0.764553903841.issue25146@psf.upfronthosting.co.za> Message-ID: <1442446292.62.0.978088618041.issue25146@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I agree that without breakpoints set, Go is currently useless. I believe that you are proposing that it become a 'Start slide show' button, where a 'slide' is the execution of one statement. I really like this idea. Like music or dance notation, a programs is a static representation of a dynamic performance. An expert programmer, like an expert musician or dancer, can imagine a performance. But without seeing a calculation performance, novice programmers may have trouble knowing what they are supposed to be doing. For Python, calculation results are made visible by namespace bindings. Suggestions based on experience with automated slide shows: * a user-settable delay between statement execution (possible 0). * use space bar to stop and start * allow single stepping while stopped, and space-bar restart after A debugger-specific suggestion: * step over functions whose code is not in a clean editor window (no unsaved edits) try: filename = f.__globals__['__file__'] except AttributeError: # builtin function or method else: if filename not in filelist or buffer dirty: else: > trying to make a GUI program act like a command line program. I don't think I understand that completely, except perhaps that the reason for the nested event loop is to avoid blocking the main event loop. And maybe that you believe we can avoid the likely troublesome nested loop without blocking the main loop. (It does seem like judicious use of .after, commands, and callbacks should avoid needing a nested loop.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 02:04:46 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 17 Sep 2015 00:04:46 +0000 Subject: [issue25144] 3.5 Win install fails with "TARGETDIR" In-Reply-To: <1442424932.17.0.0389991499722.issue25144@psf.upfronthosting.co.za> Message-ID: <1442448286.33.0.870525033635.issue25144@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 02:24:08 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 17 Sep 2015 00:24:08 +0000 Subject: [issue25117] Windows installer: precompiling stdlib fails with missing DLL errors In-Reply-To: <1442294819.71.0.839651529049.issue25117@psf.upfronthosting.co.za> Message-ID: <1442449448.46.0.574289793712.issue25117@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Pre-compiling should generally not be needed; I try to remember to uncheck it. If you do want everything compiled, read the doc for compileall module. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 02:39:19 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 17 Sep 2015 00:39:19 +0000 Subject: [issue25124] No single .msi available for 3.5 release In-Reply-To: <1442315365.32.0.493745807723.issue25124@psf.upfronthosting.co.za> Message-ID: <1442450359.22.0.815869368787.issue25124@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I will let Steve Dower explain or link to explanations for the change. But there were reasons. All of the approximately 10 pre-releases for 3.5.0 have been in the new .exe format. See https://www.python.org/downloads/release/python-350a1/ , which offered python-3.5.0a1-amd64.exe last Feb 8. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 03:49:37 2015 From: report at bugs.python.org (eryksun) Date: Thu, 17 Sep 2015 01:49:37 +0000 Subject: [issue25117] Windows installer: precompiling stdlib fails with missing DLL errors In-Reply-To: <1442294819.71.0.839651529049.issue25117@psf.upfronthosting.co.za> Message-ID: <1442454577.16.0.305932215569.issue25117@psf.upfronthosting.co.za> eryksun added the comment: There should be a bunch of logs named "Python 3.5.0*.log" in your user's %TEMP% directory. If you don't mind, zip them up and attach the file to this issue for Steve Dower to review when he returns from vacation. In the mean time, try directly installing the Universal CRT update, [KB2999226][1]. For Server 2012 R2, [KB2919355][2] should be installed first. [1]: http://www.microsoft.com/en-us/download/details.aspx?id=48234 [2]: http://www.microsoft.com/en-us/download/details.aspx?id=42334 ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 03:53:38 2015 From: report at bugs.python.org (eryksun) Date: Thu, 17 Sep 2015 01:53:38 +0000 Subject: [issue25117] Windows installer: precompiling stdlib fails with missing DLL errors In-Reply-To: <1442294819.71.0.839651529049.issue25117@psf.upfronthosting.co.za> Message-ID: <1442454818.86.0.559597037148.issue25117@psf.upfronthosting.co.za> eryksun added the comment: > Pre-compiling should generally not be needed It's a useful optimization if Python is installed to a directory that doesn't grant write access to regular users, such as %ProgramFiles%. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 04:37:17 2015 From: report at bugs.python.org (Peter Bray) Date: Thu, 17 Sep 2015 02:37:17 +0000 Subject: [issue1471934] Python libcrypt build problem on Solaris 8, 9, 10 and OpenSolaris Message-ID: <1442457437.27.0.326193748546.issue1471934@psf.upfronthosting.co.za> Peter Bray added the comment: While I have not tested the patch provided, the following ls(1) command on Sun Solaris 10 Update 8 and Oracle Solaris 10 Update 11, show that on (at least) X86 systems, there is no -lcrypt for 64-bit builds. So a patch is required on 64-bit builds, and possibly 32-bit builds if library variant (_d vs _i) consistency is required. % ls -l /usr/lib/**/libcrypt* | sed -e 's/ 1 root .* 20.. //' lrwxrwxrwx /usr/lib/amd64/libcrypt_d.so -> ./libcrypt_d.so.1 -rwxr-xr-x /usr/lib/amd64/libcrypt_d.so.1 lrwxrwxrwx /usr/lib/amd64/libcrypt_i.so -> libcrypt_i.so.1 -rwxr-xr-x /usr/lib/amd64/libcrypt_i.so.1 lrwxrwxrwx /usr/lib/amd64/libcryptoutil.so -> libcryptoutil.so.1 -rwxr-xr-x /usr/lib/amd64/libcryptoutil.so.1 lrwxrwxrwx /usr/lib/libcrypt.so -> libcrypt_d.so lrwxrwxrwx /usr/lib/libcrypt.so.1 -> libcrypt_d.so.1 lrwxrwxrwx /usr/lib/libcrypt_d.so -> ./libcrypt_d.so.1 -rwxr-xr-x /usr/lib/libcrypt_d.so.1 lrwxrwxrwx /usr/lib/libcrypt_i.so -> ./libcrypt_i.so.1 -rwxr-xr-x /usr/lib/libcrypt_i.so.1 lrwxrwxrwx /usr/lib/libcryptoutil.so -> ./libcryptoutil.so.1 -rwxr-xr-x /usr/lib/libcryptoutil.so.1 PS: Solaris 11.2 (X86) on the other hand does have a -lcrypt for both 32-bit and 64-bit libraries (libcrypt.so -> ./libcrypt.so.1) ---------- nosy: +illumino _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 05:00:10 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 17 Sep 2015 03:00:10 +0000 Subject: [issue25135] Deques to adopt the standard clearing procedure for mutable objects In-Reply-To: <1442358776.69.0.0875538895398.issue25135@psf.upfronthosting.co.za> Message-ID: <1442458810.58.0.653771059438.issue25135@psf.upfronthosting.co.za> Changes by Raymond Hettinger : Added file: http://bugs.python.org/file40486/deque_nonreentrant_clear2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 07:36:31 2015 From: report at bugs.python.org (Marius Gedminas) Date: Thu, 17 Sep 2015 05:36:31 +0000 Subject: [issue25117] Windows installer: precompiling stdlib fails with missing DLL errors In-Reply-To: <1442294819.71.0.839651529049.issue25117@psf.upfronthosting.co.za> Message-ID: <1442468191.8.0.289777173322.issue25117@psf.upfronthosting.co.za> Changes by Marius Gedminas : Added file: http://bugs.python.org/file40487/Python 3.5.0 installer crash logs.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 08:20:37 2015 From: report at bugs.python.org (Yu Tomita) Date: Thu, 17 Sep 2015 06:20:37 +0000 Subject: [issue24928] mock.patch.dict spoils order of items in collections.OrderedDict In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za> Message-ID: <1442470837.53.0.0854198559288.issue24928@psf.upfronthosting.co.za> Yu Tomita added the comment: Submitting a patch. To support both iterable and mapping in the same way as with dict(...), `values` is updated to be a list of length-2 iterables instead of using copy call. Patch includes unittest which tests the reported problem. ---------- keywords: +patch nosy: +nekobon Added file: http://bugs.python.org/file40488/issue24928.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 08:51:13 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 17 Sep 2015 06:51:13 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za> Message-ID: <1442472673.11.0.214656685415.issue23496@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: -ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 09:04:10 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 17 Sep 2015 07:04:10 +0000 Subject: [issue24773] Add local time disambiguation flag to datetime In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za> Message-ID: <1442473450.8.0.311089242252.issue24773@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: -ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 09:18:27 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 17 Sep 2015 07:18:27 +0000 Subject: [issue25147] Enum: remove dependency on OrderedDict Message-ID: <1442474307.48.0.698040907458.issue25147@psf.upfronthosting.co.za> New submission from Ethan Furman: Pulling in collections.OrderedDict has a significant startup cost (from what I've heard, and can easily believe by glancing at all the imports in collections.__init__). By keeping a separate list for the Enum member names using Enum in the stdlib becomes more attractive. ---------- assignee: ethan.furman messages: 250875 nosy: barry, eli.bendersky, ethan.furman priority: normal severity: normal stage: patch review status: open title: Enum: remove dependency on OrderedDict versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 09:24:21 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 17 Sep 2015 07:24:21 +0000 Subject: [issue25147] Enum: remove dependency on OrderedDict In-Reply-To: <1442474307.48.0.698040907458.issue25147@psf.upfronthosting.co.za> Message-ID: <1442474661.25.0.477760573728.issue25147@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- keywords: +patch Added file: http://bugs.python.org/file40489/issue25147.stoneleaf.01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 10:34:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 17 Sep 2015 08:34:07 +0000 Subject: [issue25135] Deques to adopt the standard clearing procedure for mutable objects In-Reply-To: <1442358776.69.0.0875538895398.issue25135@psf.upfronthosting.co.za> Message-ID: <1442478847.38.0.431954029306.issue25135@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I left comments on Rietveld. Perhaps you missed Rietveld messages in the Spam folder. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 11:12:31 2015 From: report at bugs.python.org (Barry Scott) Date: Thu, 17 Sep 2015 09:12:31 +0000 Subject: [issue25148] Windows registry PythonCore key changed inconsistent with other releases Message-ID: <1442481151.22.0.29783958187.issue25148@psf.upfronthosting.co.za> New submission from Barry Scott: I am used to looking in HKLM:\SOFTWARE\Python\PythonCore\%(py_maj)d.%(py_min)d\InstallPath to find out where python is installed so that my installation kit can add itself to site-packages. I just found that the registry key used for 32 bit python 3.5 on windows changed to be '3.5-32', which I can change my installer to cope with. However the key for the 64bit install is ?3.5? but not '3.5-64'. This seems like a regression to me in the interface to Python on Windows. Is there a reason not to use the original naming? Barry ---------- components: Installation messages: 250877 nosy: barry.scott priority: normal severity: normal status: open title: Windows registry PythonCore key changed inconsistent with other releases versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 11:13:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 17 Sep 2015 09:13:39 +0000 Subject: [issue25147] Enum: remove dependency on OrderedDict In-Reply-To: <1442474307.48.0.698040907458.issue25147@psf.upfronthosting.co.za> Message-ID: <1442481219.55.0.743770997564.issue25147@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This change has visible side effect: __members__ is no longer ordered. This should be reflected in the documentation and in What's New. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 11:18:07 2015 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 17 Sep 2015 09:18:07 +0000 Subject: [issue25148] Windows registry PythonCore key changed inconsistent with other releases In-Reply-To: <1442481151.22.0.29783958187.issue25148@psf.upfronthosting.co.za> Message-ID: <1442481487.65.0.219304509434.issue25148@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +steve.dower type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 11:32:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 17 Sep 2015 09:32:38 +0000 Subject: [issue24982] shutil.make_archive doesn't archive empty directories In-Reply-To: <1441155377.03.0.243318485167.issue24982@psf.upfronthosting.co.za> Message-ID: <1442482358.65.0.121328502802.issue24982@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 12:34:35 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 17 Sep 2015 10:34:35 +0000 Subject: [issue25147] Enum: remove dependency on OrderedDict In-Reply-To: <1442474307.48.0.698040907458.issue25147@psf.upfronthosting.co.za> Message-ID: <1442486075.15.0.588293962222.issue25147@psf.upfronthosting.co.za> STINNER Victor added the comment: > This change has visible side effect: __members__ is no longer ordered. This property of part of the PEP 435 (enum): "The special attribute __members__ is an ordered dictionary mapping names to members." IMHO if we really want to change this, it must be discussed on the python-dev mailing list. To keep __members__ ordered, we can delay the creation of the OrderedDict at the first access to __members__: start with a dict, and use the ordered _all_member_names_ to created the ordered dictionary. Attached patch implements this idea. I checked enum.Enum and enum.IntEnum classes and the @enum.unique decorated: __members__ is not used to declare the class. Hum, I had to modify a little bit @enum.unique to not access __members__. ---------- nosy: +haypo Added file: http://bugs.python.org/file40490/delayed_ordered_dict.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 13:28:41 2015 From: report at bugs.python.org (eryksun) Date: Thu, 17 Sep 2015 11:28:41 +0000 Subject: [issue25117] Windows installer: precompiling stdlib fails with missing DLL errors In-Reply-To: <1442294819.71.0.839651529049.issue25117@psf.upfronthosting.co.za> Message-ID: <1442489321.17.0.229922174977.issue25117@psf.upfronthosting.co.za> eryksun added the comment: Per "Python 3.5.0 (32-bit)_20150914055131.log", the installer detects the OS as NT 6.2.9200 (Windows 8/Server 2012), and installs Windows8-RT-KB2999226-x64.msu. [0A68:0EC8][2015-09-14T05:51:31]i001: Burn v3.10.0.1823, Windows v6.2 (Build 9200: Service Pack 0), path: C:\Users\mg\Downloads\python-3.5.0.exe [0F48:03B4][2015-09-14T05:54:05]i301: Applying execute package: crt_14.0_v6.2_x64, action: Install, path: C:\ProgramData\Package Cache\ 0F275C704EE13CA9E98834DB6DA50D4693FF2BAF\ Windows8-RT-KB2999226-x64.msu, arguments: '"C:\Windows\SysNative\wusa.exe" "C:\ProgramData\Package Cache\ 0F275C704EE13CA9E98834DB6DA50D4693FF2BAF\ Windows8-RT-KB2999226-x64.msu" /quiet /norestart' which seems to succeed: [0A68:0EC8][2015-09-14T05:54:24]i319: Applied execute package: crt_14.0_v6.2_x64, result: 0x0, restart: Required Yet trying to run py.exe to compile the standard library fails with STATUS_DLL_NOT_FOUND (0xC0000135): [0F48:03B4][2015-09-14T05:55:11]i301: Applying execute package: compileall_AllUsers, action: Install, path: C:\ProgramData\Package Cache\ 1D1205B0F2D3B4B31CC368C86271206AEF327163\py.exe, arguments: '"C:\ProgramData\Package Cache\ 1D1205B0F2D3B4B31CC368C86271206AEF327163\py.exe" -3.5-32 -E -s -Wi "C:\Python35\Lib\compileall.py" -f -x "bad_coding|badsyntax|site-packages|py2_| lib2to3\\tests|venv\\scripts" "C:\Python35\Lib"' [0F48:03B4][2015-09-14T05:57:24]e000: Error 0xc0000135: Process returned error: 0xc0000135 Your screenshot shows that api-ms-win-crt-runtime-l1-1-0.dll is missing. Does this DLL exist in "%SystemRoot%\SysWOW64"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 14:16:58 2015 From: report at bugs.python.org (AndreC) Date: Thu, 17 Sep 2015 12:16:58 +0000 Subject: [issue25149] datetime.weekday() off by one if handling a date from utcfromtimestamp() Message-ID: <1442492218.93.0.0814077677929.issue25149@psf.upfronthosting.co.za> New submission from AndreC: I've stumbled over an odd datetime.weekday() behaviour in Python 2.7.8 (default, Jun 18 2015, 18:54:19) [GCC 4.9.1] on linux2) under Ubuntu. weekday() is off by 1. Code to reproduce: from datetime import datetime date = datetime.utcfromtimestamp(int('1410446564')) # datetime.datetime(2014, 9, 11, 14, 42, 44) date.weekday() # should be 4, not 3 I can reproduce this behaviour on our dev and production systems, and just tested it locally with python 3.4.3. Since I'm not a smart man, I might overlook something silly... ---------- components: Library (Lib) messages: 250881 nosy: odianus priority: normal severity: normal status: open title: datetime.weekday() off by one if handling a date from utcfromtimestamp() type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 14:48:26 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 17 Sep 2015 12:48:26 +0000 Subject: [issue25135] Deques to adopt the standard clearing procedure for mutable objects In-Reply-To: <1442358776.69.0.0875538895398.issue25135@psf.upfronthosting.co.za> Message-ID: <1442494106.03.0.991544488351.issue25135@psf.upfronthosting.co.za> Raymond Hettinger added the comment: How does newblock() mutate the deque? Does PyMem_Malloc() do anything other than call malloc()? We hold the GIL so there doesn't seem to be a need to use PyMem_RawMalloc(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 14:58:35 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 17 Sep 2015 12:58:35 +0000 Subject: [issue25135] Deques to adopt the standard clearing procedure for mutable objects In-Reply-To: <1442358776.69.0.0875538895398.issue25135@psf.upfronthosting.co.za> Message-ID: <1442494715.17.0.135663945739.issue25135@psf.upfronthosting.co.za> STINNER Victor added the comment: "Does PyMem_Malloc() do anything other than call malloc()? We hold the GIL so there doesn't seem to be a need to use PyMem_RawMalloc()." Well, the difference between PyMem_Malloc() and PyMem_RawMalloc() is subtle. Right now, it should only impact debug tools hooking on the memory allocators. But one day I would like to try to modify PyMem_Malloc() to reuse PyObject_Malloc(). I don't see why PyMem_Malloc() shouldn't be optimized for small applications. But it's hard to benchmark such change, and it depends on the platform. I already had to use different config for memory allocators depending on the platform :-/ The implementation of tracemalloc uses a different overallocation factor on Windows and on other platforms. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 14:59:00 2015 From: report at bugs.python.org (Alexander Heger) Date: Thu, 17 Sep 2015 12:59:00 +0000 Subject: [issue25150] yt package pip compile/install error Message-ID: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za> New submission from Alexander Heger: trying to install the yt package, most recent version 3.2.1 on python 3.5.0 using pip pip3 install -U yt error output attached. The same package installs fine with python 3.4.3, same compiler and also build from scratch, so the suspicion is that it is related to the new 3.5.0 version. The system installed is the current Fedora 22, gcc 5.1.1-4. ---------- components: Extension Modules files: error.txt hgrepos: 318 messages: 250884 nosy: axh priority: normal severity: normal status: open title: yt package pip compile/install error type: compile error versions: Python 3.5 Added file: http://bugs.python.org/file40491/error.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 15:10:31 2015 From: report at bugs.python.org (AndreC) Date: Thu, 17 Sep 2015 13:10:31 +0000 Subject: [issue25149] datetime.weekday() off by one if handling a date from utcfromtimestamp() In-Reply-To: <1442492218.93.0.0814077677929.issue25149@psf.upfronthosting.co.za> Message-ID: <1442495431.35.0.678786647614.issue25149@psf.upfronthosting.co.za> AndreC added the comment: as I said, I'm not a smart man, the sort order was wrong and the year was simply wrong... sorry :-/ ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 15:13:00 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 17 Sep 2015 13:13:00 +0000 Subject: [issue25150] yt package pip compile/install error In-Reply-To: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za> Message-ID: <1442495580.61.0.358911639697.issue25150@psf.upfronthosting.co.za> STINNER Victor added the comment: It looks like the problem is that yt uses OpenMP whereas OpenMP doesn't support atomic operations: In file included from /home/alex/Python/include/python3.5m/pyatomic.h:12:0, from /home/alex/Python/include/python3.5m/Python.h:53, from build/src.linux-x86_64-3.5/yt/utilities/lib/geometry_utils.c:4: /usr/lib/gcc/x86_64-redhat-linux/5.1.1/include/stdatomic.h:40:1: sorry, unimplemented: ???_Atomic??? with OpenMP typedef _Atomic _Bool atomic_bool; ^ I'm not sure that Include/pyatomic.h should be included by the main Include/Python.h header. We already skipped Include/pyatomic.h on C++ because this header is incompatible with C++. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 15:13:53 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 17 Sep 2015 13:13:53 +0000 Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5) In-Reply-To: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za> Message-ID: <1442495633.62.0.807825738714.issue25150@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: yt package pip compile/install error -> 3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5) versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 15:45:35 2015 From: report at bugs.python.org (Felipe) Date: Thu, 17 Sep 2015 13:45:35 +0000 Subject: [issue25144] 3.5 Win install fails with "TARGETDIR" In-Reply-To: <1442424932.17.0.0389991499722.issue25144@psf.upfronthosting.co.za> Message-ID: <1442497535.4.0.221204619344.issue25144@psf.upfronthosting.co.za> Changes by Felipe : Added file: http://bugs.python.org/file40492/Python 3.5.0 (32-bit)_20150916132422.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 15:55:40 2015 From: report at bugs.python.org (Laura Creighton) Date: Thu, 17 Sep 2015 13:55:40 +0000 Subject: [issue25151] venv does not work with debian releases, if you want to install pip Message-ID: <1442498140.39.0.803363525343.issue25151@psf.upfronthosting.co.za> New submission from Laura Creighton: I am reporting this here so that the next person who runs into this and looks into the bug tracker will find out what to do. You cannot create a venv with Python3.3, 3.4, 3.5. on debian (and likely on many debian-derived distros). Instead you get Error: Command '['/bin/python3.4', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1 Debian knows all about this, but they don't want to make changes. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732703 Instead, if you want venv to work you will need to install the debian packages python3-venv (for 3.4) and python3.5-venv for 3.5. Can somebody close this issue now, as this is clearly a debian issue and not a Python bug. I am just reporting it here so that somebody else who has the problem can find out what to do. ---------- components: Distutils messages: 250887 nosy: dstufft, eric.araujo, lac priority: normal severity: normal status: open title: venv does not work with debian releases, if you want to install pip type: behavior versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 16:05:21 2015 From: report at bugs.python.org (Alexander Heger) Date: Thu, 17 Sep 2015 14:05:21 +0000 Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5) In-Reply-To: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za> Message-ID: <1442498721.58.0.132267817877.issue25150@psf.upfronthosting.co.za> Alexander Heger added the comment: When I just comment out the #include "pyatomic.h" line, python 3.5.0 will no longer compile gcc -pthread -c -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I. -IInclude -I./Include -DPy_BUILD_CORE -o Programs/python.o ./Programs/python.c In file included from Include/traceback.h:8:0, from Include/Python.h:97, from ./Programs/python.c:3: Include/pystate.h:186:8: error: unknown type name ?_Py_atomic_address? PyAPI_DATA(_Py_atomic_address) _PyThreadState_Current; ^ Makefile:747: recipe for target 'Programs/python.o' failed make: *** [Programs/python.o] Error 1 pystate.h: /* Assuming the current thread holds the GIL, this is the PyThreadState for the current thread. Issue #23644: pyatomic.h is incompatible with C++ (yet). Disable PyThreadState_GET() optimization: declare it as an alias to PyThreadState_Get(), as done for limited API. */ #if !defined(Py_LIMITED_API) && !defined(__cplusplus) PyAPI_DATA(_Py_atomic_address) _PyThreadState_Current; #endif ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 16:08:50 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 17 Sep 2015 14:08:50 +0000 Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5) In-Reply-To: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za> Message-ID: <1442498930.87.0.523552821567.issue25150@psf.upfronthosting.co.za> STINNER Victor added the comment: "When I just comment out the << #include "pyatomic.h" >> line, python 3.5.0 will no longer compile" Sure. My idea is to "disable" the header with we are not building Python itself. There is a nice define for that: Py_BUILD_CORE. See attached patch. Since all symbols in pyatomic.h are prefixed by _Py, this header is fully part of the Python private API and so it's fine to modify it in a bugfix release (3.5.0 => 3.5.1). ---------- keywords: +patch Added file: http://bugs.python.org/file40493/pyatomic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 16:09:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 17 Sep 2015 14:09:59 +0000 Subject: [issue25135] Deques to adopt the standard clearing procedure for mutable objects In-Reply-To: <1442358776.69.0.0875538895398.issue25135@psf.upfronthosting.co.za> Message-ID: <1442498999.16.0.205513743318.issue25135@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that doesn't need newblock(). ---------- Added file: http://bugs.python.org/file40494/deque_nonreentrant_clear3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 16:11:31 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 17 Sep 2015 14:11:31 +0000 Subject: [issue25151] venv does not work with debian releases, if you want to install pip In-Reply-To: <1442498140.39.0.803363525343.issue25151@psf.upfronthosting.co.za> Message-ID: <1442499091.21.0.2885337165.issue25151@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 16:13:32 2015 From: report at bugs.python.org (Laura Creighton) Date: Thu, 17 Sep 2015 14:13:32 +0000 Subject: [issue25152] venv documentation doesn't tell you how to specify a particular version of python Message-ID: <1442499212.73.0.745656543772.issue25152@psf.upfronthosting.co.za> New submission from Laura Creighton: https://docs.python.org/3/library/venv.html nowhere explicitly states how you are supposed to get a venv with a particular python version. Users of virtualenv will be looking for a -p option. The doc says: "Creation of virtual environments is done by executing the pyvenv script:" which undoubtably works if you _have_ a pyenv script, but I don't have one. It is nowhere stated where I should find one. Fortunately, I can also run things as some_python_version -m venv myvenv This, everybody is able to do. (However, it may not work, see issue 25151 -- but forget that for now.) This is something that everybody ought to be able to do. Thus I propose either deleting the mention of pyenv, (if it is exactly equivalent to running python -m venv) or expanding the section, indicating where the script lives, and why you might want to run it instead of python -m venv. Then, before the line: The command, if run with -h, will show the available options: add the line: The version of python used in the venv is determined at this time. If the default version of python is not the one desired, use: /path/to/the/python/I/want -m venv myenv instead. (Plus, if there is a way to do this with pyenv, then list that part here). ---------- assignee: docs at python components: Distutils, Documentation messages: 250891 nosy: docs at python, dstufft, eric.araujo, lac priority: normal severity: normal status: open title: venv documentation doesn't tell you how to specify a particular version of python versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 16:24:38 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 17 Sep 2015 14:24:38 +0000 Subject: [issue25152] venv documentation doesn't tell you how to specify a particular version of python In-Reply-To: <1442499212.73.0.745656543772.issue25152@psf.upfronthosting.co.za> Message-ID: <1442499878.48.0.972935881132.issue25152@psf.upfronthosting.co.za> R. David Murray added the comment: Our documentation describes what you get if you install Python using our distribution of python. If you do that, you (by default) get a pyvenv script, and it points to the version of python that you just (last) installed. Distributions change this. We can't document what every distribution does. That said, I think it would be a good idea to move the description of calling it via 'python -m venv' to be the *first* mention, and *then* describing pyvenv (and noting that it is installed by our installers but a vendor install may do something different, including omit it). ---------- nosy: +r.david.murray versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 17:46:15 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 17 Sep 2015 15:46:15 +0000 Subject: [issue25153] PCbuild/*.vcxproj* should use CRLF line endings Message-ID: <1442504775.33.0.605516301888.issue25153@psf.upfronthosting.co.za> New submission from Zachary Ware: PCbuild/*.vcxproj* should be added to .hgeol to force them to CRLF. A couple of reasons: 1) They're only used on Windows, where the default (terrible, but always available) editor doesn't understand LF 2) More importantly, the tcl, tk, and tix projects use labels in the NMakeCommandLine script, which can fail confusingly when that script has LF line endings (the error is "The system cannot find the batch label specified - build") Thanks to Andres Guzman-ballen for bringing this to my attention again. I have also seen this on my Windows 8.1 Non-Debug buildbot, where I worked around it by turning on the hg 'eol' extension so that everything would be converted to CRLF on checkout. ---------- assignee: zach.ware components: Build, Windows messages: 250893 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: PCbuild/*.vcxproj* should use CRLF line endings type: behavior versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 17:57:57 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 17 Sep 2015 15:57:57 +0000 Subject: [issue25136] Python doesn't find Xcode 7 stub libraries In-Reply-To: <1442365383.18.0.302201830729.issue25136@psf.upfronthosting.co.za> Message-ID: <1442505477.85.0.61233880843.issue25136@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the analysis and the patches, Tim. Now that Xcode 7 is released, we'll need to ensure we fully support the new stubs. But, as you note, the workaround as always is to make sure that the current Command Line Tools are installed, the configuration that we test with. ---------- assignee: -> ned.deily stage: -> patch review versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 18:14:04 2015 From: report at bugs.python.org (Eric Snow) Date: Thu, 17 Sep 2015 16:14:04 +0000 Subject: [issue25147] Enum: remove dependency on OrderedDict In-Reply-To: <1442474307.48.0.698040907458.issue25147@psf.upfronthosting.co.za> Message-ID: <1442506444.73.0.236521983645.issue25147@psf.upfronthosting.co.za> Eric Snow added the comment: OrderedDict has a C implementation now. So try the following: try: from _collections import OrderedDict except ImportError: from collections import OrderedDict ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 18:36:15 2015 From: report at bugs.python.org (Laura Creighton) Date: Thu, 17 Sep 2015 16:36:15 +0000 Subject: [issue25152] venv documentation doesn't tell you how to specify a particular version of python In-Reply-To: <1442499212.73.0.745656543772.issue25152@psf.upfronthosting.co.za> Message-ID: <1442507775.5.0.681488817067.issue25152@psf.upfronthosting.co.za> Laura Creighton added the comment: On thinking things over, I think that venv is, as it stands now, only able to work with python3.3 and greater. If you want to build a virtualenv for python 2.7, then I think venv is not for you. I think this needs to be mentioned. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 18:40:02 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 17 Sep 2015 16:40:02 +0000 Subject: [issue25152] venv documentation doesn't tell you how to specify a particular version of python In-Reply-To: <1442499212.73.0.745656543772.issue25152@psf.upfronthosting.co.za> Message-ID: <1442508002.3.0.0355401117993.issue25152@psf.upfronthosting.co.za> R. David Murray added the comment: Not in the python3 docs, it doesn't. The python3 docs are documenting python3. But, this is another reason the -m venv description should be first, to make it clear it is *part* of the python version, not a standalone package that might work with multiple python versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 18:40:39 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 17 Sep 2015 16:40:39 +0000 Subject: [issue25147] Enum: remove dependency on OrderedDict In-Reply-To: <1442474307.48.0.698040907458.issue25147@psf.upfronthosting.co.za> Message-ID: <1442508039.63.0.14572408876.issue25147@psf.upfronthosting.co.za> Ethan Furman added the comment: Is pulling in `_collections` not as resource intensive as pulling in `collections`? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 18:51:34 2015 From: report at bugs.python.org (Laura Creighton) Date: Thu, 17 Sep 2015 16:51:34 +0000 Subject: [issue25152] venv documentation doesn't tell you how to specify a particular version of python In-Reply-To: <1442499212.73.0.745656543772.issue25152@psf.upfronthosting.co.za> Message-ID: <1442508694.55.0.710819078935.issue25152@psf.upfronthosting.co.za> Laura Creighton added the comment: The problem is that people who run into venv will think that it is virtualenv made into part of the standard library. Thus they will have a great expectation that there will be a -p option to specify the python version that they want and that they can get 2.7. As Josh Billings (American humourist) wrote: "It ain't ignorance causes so much trouble; it's folks knowing so much that ain't so." A 'this is not virtualenv' message would be useful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 19:22:41 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 17 Sep 2015 17:22:41 +0000 Subject: [issue25147] Enum: remove dependency on OrderedDict In-Reply-To: <1442474307.48.0.698040907458.issue25147@psf.upfronthosting.co.za> Message-ID: <1442510561.76.0.553751648149.issue25147@psf.upfronthosting.co.za> R. David Murray added the comment: _collections exists because it contains only the stuff that is needed at python startup. So it is loaded regardless, and thus is very cheap to import elsewhere :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 19:24:44 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 17 Sep 2015 17:24:44 +0000 Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5) In-Reply-To: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za> Message-ID: <1442510684.96.0.0625898252109.issue25150@psf.upfronthosting.co.za> Brett Cannon added the comment: If everything in the header is a _Py definition then I agree we should hide it in Python.h from the public. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 19:28:07 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 17 Sep 2015 17:28:07 +0000 Subject: [issue25152] venv documentation doesn't tell you how to specify a particular version of python In-Reply-To: <1442499212.73.0.745656543772.issue25152@psf.upfronthosting.co.za> Message-ID: <1442510887.29.0.483094099093.issue25152@psf.upfronthosting.co.za> Brett Cannon added the comment: Maybe we should consider dropping the generic pyvenv script or at least only install it with a full version suffix like pyvenv3.6 to prevent this kind of confusion (I have this issue all the time with pip and it drives me nuts). At the very minimum we should do as David suggests and bump up the `python -m` suggestion up as the first one. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 19:32:44 2015 From: report at bugs.python.org (Marius Gedminas) Date: Thu, 17 Sep 2015 17:32:44 +0000 Subject: [issue25117] Windows installer: precompiling stdlib fails with missing DLL errors In-Reply-To: <1442294819.71.0.839651529049.issue25117@psf.upfronthosting.co.za> Message-ID: <1442511164.83.0.857830724763.issue25117@psf.upfronthosting.co.za> Marius Gedminas added the comment: Yes, it exists: http://imgur.com/YCmApN7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 19:44:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 17 Sep 2015 17:44:00 +0000 Subject: [issue25147] Enum: remove dependency on OrderedDict In-Reply-To: <1442474307.48.0.698040907458.issue25147@psf.upfronthosting.co.za> Message-ID: <1442511840.06.0.732841037464.issue25147@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: _collections exists because it contains C implementations of some collections classes or helpers. _collections itself is imported only in collections and threading. And in threading the same idiom as proposed by Eric is used: try: from _collections import deque as _deque except ImportError: from collections import deque as _deque What is the cost of importing OrderedDict at all? Ethan, can you provide any measurement results? ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 19:55:40 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 17 Sep 2015 17:55:40 +0000 Subject: [issue25147] Enum: remove dependency on OrderedDict In-Reply-To: <1442474307.48.0.698040907458.issue25147@psf.upfronthosting.co.za> Message-ID: <1442512540.36.0.175701198752.issue25147@psf.upfronthosting.co.za> Ethan Furman added the comment: _collections sounds cool, but the flip side is any python without the C implemntation would still have the slower startup, right? No, I don't have measurements -- just that I have heard importing collections can have an effect on startup time. Of course, it's only a cost you pay once, so maybe it's not a big deal. On the other hand, I could make __members__ a caching property that doesn't import OrderedDict until it is used, and not use it internally -- and I can't think of any reason why the stdlib would need to access __members__ itself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 19:55:57 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 17 Sep 2015 17:55:57 +0000 Subject: [issue25152] venv documentation doesn't tell you how to specify a particular version of python In-Reply-To: <1442499212.73.0.745656543772.issue25152@psf.upfronthosting.co.za> Message-ID: <1442512557.01.0.661079494906.issue25152@psf.upfronthosting.co.za> R. David Murray added the comment: I was surprised myself that pyvenv wasn't at least named pyvenv3. I think I've only ever used it once, mostly I use the -m because then I *know* what version of python I'm getting. I'd be in favor of dropping the script except that that would be a backward compatibility break. (Gentoo at least would probably recreate it so that 'pyvenv' continued to work no matter which version of python you had selected as your system default). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 20:14:12 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 17 Sep 2015 18:14:12 +0000 Subject: [issue25152] venv documentation doesn't tell you how to specify a particular version of python In-Reply-To: <1442499212.73.0.745656543772.issue25152@psf.upfronthosting.co.za> Message-ID: <1442513652.91.0.569456143513.issue25152@psf.upfronthosting.co.za> Brett Cannon added the comment: It would break backwards-compatibility, but the fix is to simply switch to `python3 -m venv` which still gives you the same semantics of using the newest Python 3 installation you have so the work to change is minimal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 20:16:04 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 17 Sep 2015 18:16:04 +0000 Subject: [issue25152] venv documentation doesn't tell you how to specify a particular version of python In-Reply-To: <1442499212.73.0.745656543772.issue25152@psf.upfronthosting.co.za> Message-ID: <1442513764.89.0.161102402922.issue25152@psf.upfronthosting.co.za> Brett Cannon added the comment: Actually, I like the idea of dropping pyvenv enough that I'm going to create an issue for it and bring it up on python-dev. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 20:27:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 17 Sep 2015 18:27:22 +0000 Subject: [issue25147] Enum: remove dependency on OrderedDict In-Reply-To: <1442474307.48.0.698040907458.issue25147@psf.upfronthosting.co.za> Message-ID: <1442514442.77.0.999839640077.issue25147@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I tried to measure import time with different patches and didn't notice any difference. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 20:35:21 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 17 Sep 2015 18:35:21 +0000 Subject: [issue25154] Drop the pyvenv script Message-ID: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za> New submission from Brett Cannon: I propose that the pyvenv script be deprecated in Python 3.5 and removed in Python 3.8. The reason for this proposal is because it is non-obvious what version of Python a pyvenv command is tied to (heck, it isn't necessarily obvious that it's Python 3). There would be no loss in functionality since the exact same functionality is available through `python3 -m venv`. This is a backwards-compatibility change, hence the deprecation, but changing various shell scripts and such should be trivial thanks to the -m flag. This would also help promote the use of -m, especially for any projects that rely on being tied to a specific installed interpreter. As pointed out in issue #25152, virtualenv provides a -p flag to specify what version of Python should be used to create a virtual environment: https://virtualenv.pypa.io/en/latest/reference.html#virtualenv-command. The pyvenv script and venv package provide no such mechanism since it is included in the stdlib, which makes sense since improvements will be tied to the stdlib of the Python interpreter being used while virtualenv is a standalone project/app. Some may argue that worrying about this is unnecessary, but we are already ending up with OSs that come with multiple versions of Python pre-installed, let alone when people install their own versions of Python on top of the system installation. For instance, OS X Yosemite comes with Python 2.6 and 2.7, and then if you install the latest version of Python independently you end up with 3 installations. If they all happened to have a pyvenv script you wouldn't easily know which Python interpreter the pyvenv command was going to use for the virtual environment. Since the pyvenv script is just a script, the deprecation will be in the form of a message printed to sys.stderr in the Tools/scripts/pyvenv file mentioning that the deprecation and that people should switch to `python3 -m venv` instead. The long deprecation cycle is for those who have pyvenv provided by their OS and only upgrade Python every few years, and thus run the risk of missing the deprecation warning. As for the deprecation in Python 3.5.1, that's to get the warning out immediately and to minimize people missing the deprecation prior to the removal. ---------- components: Installation messages: 250910 nosy: brett.cannon priority: normal severity: normal stage: needs patch status: open title: Drop the pyvenv script type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 20:39:51 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 17 Sep 2015 18:39:51 +0000 Subject: [issue25147] Enum: remove dependency on OrderedDict In-Reply-To: <1442474307.48.0.698040907458.issue25147@psf.upfronthosting.co.za> Message-ID: <1442515191.2.0.375449498722.issue25147@psf.upfronthosting.co.za> Ethan Furman added the comment: In that case I'll go with _collections; if performance does become an issue with other pythons later we can add the caching property. Thanks for all the insights. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 20:57:36 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 17 Sep 2015 18:57:36 +0000 Subject: [issue25154] Drop the pyvenv script In-Reply-To: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za> Message-ID: <1442516256.89.0.817193157936.issue25154@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 20:58:57 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 17 Sep 2015 18:58:57 +0000 Subject: [issue25154] Drop the pyvenv script In-Reply-To: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za> Message-ID: <1442516337.26.0.43397018305.issue25154@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I'm sympathetic, given that in Debian/Ubuntu (and maybe other distros) where we have both Python 3.4 and 3.5, we have to install /usr/bin/pyvenv-3.4 and pyvenv-3.5, and then use symlinks to provide the default version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 21:24:33 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 17 Sep 2015 19:24:33 +0000 Subject: [issue25135] Deques to adopt the standard clearing procedure for mutable objects In-Reply-To: <1442358776.69.0.0875538895398.issue25135@psf.upfronthosting.co.za> Message-ID: <1442517873.15.0.317914448857.issue25135@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Serhiy contends that calling newblock() can mutate the deque (its only external call is PyMem_Malloc()). I'm trying understand how that could be possible if it is just a thin wrapper around malloc. Before gumming-up the code in an effort to avoid calling newblock(), I want to understand whether there is an actual issue here and if so whether PyMem_RawMalloc() would solve the problem directly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 21:25:40 2015 From: report at bugs.python.org (Vitaly Murashev) Date: Thu, 17 Sep 2015 19:25:40 +0000 Subject: [issue25155] datetime.datetime.now() raises Message-ID: <1442517940.02.0.585598680273.issue25155@psf.upfronthosting.co.za> New submission from Vitaly Murashev: Current time on my machine with Windows7x64 is set to year 2045 for test purposes. Since Python3.5(amd64) I have an OverflowError when I am trying to call datetime.datetime.now() It looks like a regress since there was no such error on Python3.4.3 Could anyone please give me a note, whether it would be reasonable for me to wait for a patch in Python3.5.x, or such behavior is common since 3.5 and should not use it in my 'strange' case at all ? A bit of details: Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import datetime >>> datetime.datetime.now() Traceback (most recent call last): File "", line 1, in OverflowError: timestamp too large to convert to C _PyTime_t >>> Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import datetime >>> datetime.datetime.now() datetime.datetime(2045, 4, 2, 2, 42, 8, 359375) >>> ---------- components: Interpreter Core, Windows messages: 250914 nosy: paul.moore, steve.dower, tim.golden, vmurashev, zach.ware priority: normal severity: normal status: open title: datetime.datetime.now() raises type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 21:34:27 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 17 Sep 2015 19:34:27 +0000 Subject: [issue25155] datetime.datetime.now() raises In-Reply-To: <1442517940.02.0.585598680273.issue25155@psf.upfronthosting.co.za> Message-ID: <1442518467.79.0.879499147237.issue25155@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 21:51:22 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 17 Sep 2015 19:51:22 +0000 Subject: [issue25155] datetime.datetime.now() raises In-Reply-To: <1442517940.02.0.585598680273.issue25155@psf.upfronthosting.co.za> Message-ID: <1442519482.08.0.00443518470128.issue25155@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 21:51:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 17 Sep 2015 19:51:40 +0000 Subject: [issue25135] Deques to adopt the standard clearing procedure for mutable objects In-Reply-To: <1442358776.69.0.0875538895398.issue25135@psf.upfronthosting.co.za> Message-ID: <1442519500.54.0.663307370859.issue25135@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I perhaps were overcautious. There is a difference between the case of deque and the case of lru_cache and OrderedDict. The latter creates Python object (PyDict_New) that can trigger garbage collecting, and the former calls only PyMem_Malloc. The latter can cause a crash in common use, and the former only with special memory allocation hooks (Victor, perhaps we should disable GC for executing hooks). But my version of the patch solves not only this issue. It eliminates the use of possibly re-entrant alternate method. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 22:02:27 2015 From: report at bugs.python.org (desbma) Date: Thu, 17 Sep 2015 20:02:27 +0000 Subject: [issue25061] Add native enum support for argparse In-Reply-To: <1441908245.42.0.23532628335.issue25061@psf.upfronthosting.co.za> Message-ID: <1442520147.49.0.222740348801.issue25061@psf.upfronthosting.co.za> desbma added the comment: Thanks for sharing this code, I like the factory idea. I'll have a look at creating a custom Action class too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 22:07:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 17 Sep 2015 20:07:00 +0000 Subject: [issue25147] Enum: remove dependency on OrderedDict In-Reply-To: <1442515191.2.0.375449498722.issue25147@psf.upfronthosting.co.za> Message-ID: <1931799.jz6OpaHETC@raxxla> Serhiy Storchaka added the comment: If there is no any evidences, we shouldn't change a code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 22:08:05 2015 From: report at bugs.python.org (desbma) Date: Thu, 17 Sep 2015 20:08:05 +0000 Subject: [issue25156] shutil.copyfile should internally use os.sendfile when possible Message-ID: <1442520485.03.0.419427125487.issue25156@psf.upfronthosting.co.za> New submission from desbma: This is related to issue25063 (https://bugs.python.org/issue25063). Trying to use sendfile internally in shutil.copyfileobj was considered risky because of special Python files that expose a file descriptor but wrap it to add special behavior (eg: GzipFile). I believe such risk does not exist for shutil.copyfile, and it would be possible to use sendfile if available. ---------- components: Library (Lib) messages: 250918 nosy: desbma priority: normal severity: normal status: open title: shutil.copyfile should internally use os.sendfile when possible type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 22:14:01 2015 From: report at bugs.python.org (Alexander Heger) Date: Thu, 17 Sep 2015 20:14:01 +0000 Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5) In-Reply-To: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za> Message-ID: <1442520841.27.0.224829210406.issue25150@psf.upfronthosting.co.za> Alexander Heger added the comment: if I just include this patch, some modules don't build: (...) gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -Ibuild/temp.linux-x86_64-3.5/libffi/include -Ibuild/temp.linux-x86_64-3.5/libffi -I/home/alex/Python-3.5.0/Modules/_ctypes/libffi/src -I./Include -I/home/alex/Python/include -I. -IInclude -I/usr/local/include -I/home/alex/Python-3.5.0/Include -I/home/alex/Python-3.5.0 -c /home/alex/Python-3.5.0/Modules/_ctypes/_ctypes.c -o build/temp.linux-x86_64-3.5/home/alex/Python-3.5.0/Modules/_ctypes/_ctypes.o -Wall -fexceptions /home/alex/Python-3.5.0/Modules/_ctypes/_ctypes.c: In function ?PyCSimpleType_from_param?: /home/alex/Python-3.5.0/Modules/_ctypes/_ctypes.c:2062:15: error: ?_PyThreadState_Current? undeclared (first use in this function) if (Py_EnterRecursiveCall("while processing _as_parameter_")) { ^ /home/alex/Python-3.5.0/Modules/_ctypes/_ctypes.c:2062:15: note: each undeclared identifier is reported only once for each function it appears in /home/alex/Python-3.5.0/Modules/_ctypes/_ctypes.c:2062:28: error: ?__atomic_load_ptr? undeclared (first use in this function) if (Py_EnterRecursiveCall("while processing _as_parameter_")) { ^ /home/alex/Python-3.5.0/Modules/_ctypes/_ctypes.c:2062:66: error: argument 1 of ?__atomic_load? must be a non-void pointer type if (Py_EnterRecursiveCall("while processing _as_parameter_")) { ^ /home/alex/Python-3.5.0/Modules/_ctypes/_ctypes.c:2062:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] if (Py_EnterRecursiveCall("while processing _as_parameter_")) { ^ /home/alex/Python-3.5.0/Modules/_ctypes/_ctypes.c:2067:62: error: argument 1 of ?__atomic_load? must be a non-void pointer type /home/alex/Python-3.5.0/Modules/_ctypes/_ctypes.c:2067:21: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] Py_LeaveRecursiveCall(); ^ /home/alex/Python-3.5.0/Modules/_ctypes/_ctypes.c:2067:62: error: argument 1 of ?__atomic_load? must be a non-void pointer type /home/alex/Python-3.5.0/Modules/_ctypes/_ctypes.c:2067:139: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] Failed to build these modules: _ctypes _decimal _json _pickle ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 23:17:49 2015 From: report at bugs.python.org (Laura Creighton) Date: Thu, 17 Sep 2015 21:17:49 +0000 Subject: [issue25154] Drop the pyvenv script In-Reply-To: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za> Message-ID: <1442524669.07.0.619393028876.issue25154@psf.upfronthosting.co.za> Laura Creighton added the comment: Due to debian policy decision https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732703 neither pyenv nor python -m venv may work for you. While things are getting changed, it would be good if people running into this problem got a better error message than: Error: Command '['/bin/python3.4', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1 such as 'Your python may not be configured with ensure-pip' ---------- nosy: +lac _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 23:49:44 2015 From: report at bugs.python.org (Ulrich Fieseler) Date: Thu, 17 Sep 2015 21:49:44 +0000 Subject: [issue25143] 3.5 install fails poorly on Windows XP In-Reply-To: <1442420286.68.0.457975935538.issue25143@psf.upfronthosting.co.za> Message-ID: <1442526584.51.0.234041890673.issue25143@psf.upfronthosting.co.za> Ulrich Fieseler added the comment: Even better: Clearly (and ASAP!) document on download page that 3.4.3 is the last version usable in XP! This avoids useless downloads and a lot of confusion as clicking somewhere in the erroneously white area above the `Cancel' button in the 3.5.0 installer window will get the installation running (see mailing list thread quoted), only to experience error messages like `python.exe is not a valid win32 application' (translated from what I get in German, exact wording in English might be different) when trying to run the interpreter. That message is not helpful at all, either! Actually, searching the web for that message yields various suggestions how to fix the problem (useless here), taking me two days before I finally found the thread on the mailing list. :-( :-( ---------- nosy: +UlFie _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 17 23:52:58 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 17 Sep 2015 21:52:58 +0000 Subject: [issue25154] Drop the pyvenv script In-Reply-To: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za> Message-ID: <1442526778.98.0.385882279826.issue25154@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 00:43:16 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 17 Sep 2015 22:43:16 +0000 Subject: [issue25154] Drop the pyvenv script In-Reply-To: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za> Message-ID: <1442529796.9.0.863622563748.issue25154@psf.upfronthosting.co.za> Brett Cannon added the comment: the ensurepip case is another issue, so if you want you can file a separate issue for it so it doesn't get lost. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 01:05:36 2015 From: report at bugs.python.org (Laura Creighton) Date: Thu, 17 Sep 2015 23:05:36 +0000 Subject: [issue25151] venv does not work with debian releases, if you want to install pip In-Reply-To: <1442498140.39.0.803363525343.issue25151@psf.upfronthosting.co.za> Message-ID: <1442531136.39.0.834869582983.issue25151@psf.upfronthosting.co.za> Laura Creighton added the comment: And now, I want to open this again. I'd like to change python -m venv (and pyenv) to say something more useful than Command '['/bin/python3.4', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1 if it cannot find the ensurepip module. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 01:36:02 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Thu, 17 Sep 2015 23:36:02 +0000 Subject: [issue25155] datetime.datetime.now() raises In-Reply-To: <1442517940.02.0.585598680273.issue25155@psf.upfronthosting.co.za> Message-ID: <1442532962.94.0.65758106324.issue25155@psf.upfronthosting.co.za> Josh Rosenberg added the comment: It looks like between 3.4.3 and 3.5, datetime_best_possible changed from using _PyTime_gettimeofday with a _PyTime_timeval to using _PyTime_AsTimeval with struct timeval. The difference is that _PyTime_timeval appears to have been defined with a proper time_t for secs, where struct timeval is defined (on Windows) with a long which is still 32 bits on Windows, so we reintroduced the Y2K38 problem. The bug was introduced while trying to support #22117: "Rewrite pytime.h to work on nanoseconds" in reve93eeadef0c3: https://hg.python.org/cpython/rev/e93eeadef0c3 ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 02:36:49 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 18 Sep 2015 00:36:49 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442536609.57.0.0518386749269.issue24965@psf.upfronthosting.co.za> Martin Panter added the comment: Another strange error message (though maybe the new test changes you mentioned caught this): >>> f'{3:{10}' # Actually missing a closing bracket '}' File "", line 1 SyntaxError: f-string: unexpected '}' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 02:40:16 2015 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 18 Sep 2015 00:40:16 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442536816.46.0.398051587267.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: > Martin Panter added the comment: > > Another strange error message (though maybe the new test changes you mentioned caught this): > >>>> f'{3:{10}' # Actually missing a closing bracket '}' > File "", line 1 > SyntaxError: f-string: unexpected '}' Yes, I found that one, too. Sorry to waste your time on this, but I literally just finished the test changes 15 minutes ago. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 03:11:24 2015 From: report at bugs.python.org (Donal Duane) Date: Fri, 18 Sep 2015 01:11:24 +0000 Subject: [issue25158] Python 3.2.2 and 3.5.0 Do not seem compatible with OpenSSL 1.0.2d on Solaris 10 Message-ID: <1442538684.06.0.30749904186.issue25158@psf.upfronthosting.co.za> New submission from Donal Duane: Hi, I have been trying to compile both Python 3.2.2, and 3.5.0 with OpenSSL 1.0.2d. Python 3.2.2 succeeds to compile and install, but fails to load the OpenSSL module: >>> import ssl ld.so.1: python3.2: fatal: relocation error: file /usr/local/ssl/lib/libssl.so.1.0.0: symbol EVP_aes_128_cbc_hmac_sha256: referenced symbol not found Killed Python 3.5.0 fails to make install: ld.so.1: python: fatal: relocation error: file /usr/local/ssl/lib/libssl.so.1.0.0: symbol EVP_aes_128_cbc_hmac_sha256: referenced symbol not found *** Error code 137 make: Fatal error: Command failed for target `install' Has anyone seen this behavior? Up to now, we have been successfully using Python 3.2.2 with OpenSSL 1.0.1j, but cannot use that version anymore due to a critical SSL security bug. I would greatly appreciate any information on the above errors. Regards, D?nal ---------- components: Extension Modules messages: 250928 nosy: eeiddne priority: normal severity: normal status: open title: Python 3.2.2 and 3.5.0 Do not seem compatible with OpenSSL 1.0.2d on Solaris 10 type: compile error versions: Python 3.2, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 03:22:32 2015 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 18 Sep 2015 01:22:32 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442539352.54.0.330579909269.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: Hopefully the last version. ---------- Added file: http://bugs.python.org/file40495/pep-498-8.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 04:39:41 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 18 Sep 2015 02:39:41 +0000 Subject: [issue25047] xml.etree.ElementTree encoding declaration should be capital ('UTF-8') rather than lowercase ('utf-8') In-Reply-To: <1441827818.89.0.928682692456.issue25047@psf.upfronthosting.co.za> Message-ID: <1442543981.41.0.968158547051.issue25047@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch which changes the code to respect the letter case specified by the user, although it still compares the special strings "unicode", "us-ascii", and "utf-8" case-insensitively, and the default encoding is still lowercase. Let me know what you think. >>> tree = ElementTree(Element('hello', {'beer': 'good'})) >>> tree.write(stdout.buffer, encoding="UTF-8", xml_declaration=True); print() >>> tree.write(stdout.buffer, encoding="UTF-8"); print() >>> tree.write(stdout.buffer, xml_declaration=True); print() ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file40496/etree-encoding.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 06:11:09 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 18 Sep 2015 04:11:09 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442549469.68.0.705398495934.issue24965@psf.upfronthosting.co.za> Martin Panter added the comment: I left a few more comments on Reitveld. Checking the error messages does make me feel a lot more comfortable though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 06:49:36 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Sep 2015 04:49:36 +0000 Subject: [issue24840] implement bool conversion for enums to prevent odd edge case In-Reply-To: <1439251772.85.0.609570031312.issue24840@psf.upfronthosting.co.za> Message-ID: <20150918044932.11696.10936@psf.io> Roundup Robot added the comment: New changeset 87a9dff5106c by Ethan Furman in branch 'default': Close issue24840: Enum._value_ is queried for bool(); original patch by Mike Lundy https://hg.python.org/cpython/rev/87a9dff5106c ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 06:53:42 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 18 Sep 2015 04:53:42 +0000 Subject: [issue25147] Enum: remove dependency on OrderedDict In-Reply-To: <1442474307.48.0.698040907458.issue25147@psf.upfronthosting.co.za> Message-ID: <1442552022.12.0.429256078758.issue25147@psf.upfronthosting.co.za> Ethan Furman added the comment: Serhiy, your objection is noted, thank you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 07:04:21 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Sep 2015 05:04:21 +0000 Subject: [issue25147] Enum: remove dependency on OrderedDict In-Reply-To: <1442474307.48.0.698040907458.issue25147@psf.upfronthosting.co.za> Message-ID: <20150918050418.16599.25514@psf.io> Roundup Robot added the comment: New changeset b77916d2d7cc by Ethan Furman in branch 'default': Close issue25147: use C implementation of OrderedDict https://hg.python.org/cpython/rev/b77916d2d7cc ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 07:14:35 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 18 Sep 2015 05:14:35 +0000 Subject: [issue25147] Enum: remove dependency on OrderedDict In-Reply-To: <1442474307.48.0.698040907458.issue25147@psf.upfronthosting.co.za> Message-ID: <1442553275.97.0.952533348773.issue25147@psf.upfronthosting.co.za> Zachary Ware added the comment: That change could use a comment stating why it's doing things that way instead of the 'obvious' way. ---------- nosy: +zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 07:22:52 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Sep 2015 05:22:52 +0000 Subject: [issue24756] doctest run_docstring_examples does have an obvious utility In-Reply-To: <1438262830.97.0.532585638369.issue24756@psf.upfronthosting.co.za> Message-ID: <20150918052249.94107.23161@psf.io> Roundup Robot added the comment: New changeset 64d48786d6b0 by Ethan Furman in branch '2.7': Issue24756: clarify usage of run_docstring_examples() https://hg.python.org/cpython/rev/64d48786d6b0 New changeset ce595a047bd9 by Ethan Furman in branch '3.4': Issue24756: clarify usage of run_docstring_examples() https://hg.python.org/cpython/rev/ce595a047bd9 New changeset 767cc99020d2 by Ethan Furman in branch '3.5': Issue24756: clarify usage of run_docstring_examples() https://hg.python.org/cpython/rev/767cc99020d2 New changeset c8689d3df68a by Ethan Furman in branch 'default': Close issue24756: clarify usage of run_docstring_examples() https://hg.python.org/cpython/rev/c8689d3df68a ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 07:45:40 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 18 Sep 2015 05:45:40 +0000 Subject: [issue24766] Subclass of property doesn't preserve instance __doc__ when using doc= argument In-Reply-To: <1438362123.61.0.0930515598899.issue24766@psf.upfronthosting.co.za> Message-ID: <1442555140.47.0.479986024057.issue24766@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: -larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 07:46:51 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 18 Sep 2015 05:46:51 +0000 Subject: [issue24766] Subclass of property doesn't preserve instance __doc__ when using doc= argument In-Reply-To: <1438362123.61.0.0930515598899.issue24766@psf.upfronthosting.co.za> Message-ID: <1442555211.88.0.555126078451.issue24766@psf.upfronthosting.co.za> Ethan Furman added the comment: ethan at code:~/source/python/issue25147$ ./python -m test.regrtest -R3:3 test_property [1/1] test_property Eggs # from print() inside test beginning 6 repetitions 123456 Spam # the new value from the previous run seems stuck test test_property failed -- Traceback (most recent call last): File "/home/ethan/source/python/issue25147/Lib/test/test_property.py", line 175, in test_property_decorator_doc_writable self.assertEqual(sub.__class__.spam.__doc__, 'Eggs') AssertionError: 'Spam' != 'Eggs' - Spam + Eggs 1 test failed: test_property ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 07:55:47 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 18 Sep 2015 05:55:47 +0000 Subject: [issue25147] Enum: remove dependency on OrderedDict In-Reply-To: <1442474307.48.0.698040907458.issue25147@psf.upfronthosting.co.za> Message-ID: <1442555747.36.0.178637505887.issue25147@psf.upfronthosting.co.za> Stefan Behnel added the comment: > _collections sounds cool, but the flip side is any python without the C implemntation would still have the slower startup, right? I wouldn't bother too much with that, certainly not given the order we are talking about here. Jython's startup time is slowed down mostly by the JVM startup time anyway. And if you use PyPy then it's exactly because you do *not* care about the startup time but about performance improvements for long running code. ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 07:56:13 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Sep 2015 05:56:13 +0000 Subject: [issue25147] Enum: remove dependency on OrderedDict In-Reply-To: <1442474307.48.0.698040907458.issue25147@psf.upfronthosting.co.za> Message-ID: <20150918055610.3668.44543@psf.io> Roundup Robot added the comment: New changeset c0363f849624 by Ethan Furman in branch 'default': Issue 25147: add reason for using _collections https://hg.python.org/cpython/rev/c0363f849624 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 08:07:43 2015 From: report at bugs.python.org (Alexander Heger) Date: Fri, 18 Sep 2015 06:07:43 +0000 Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5) In-Reply-To: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za> Message-ID: <1442556463.03.0.61658212018.issue25150@psf.upfronthosting.co.za> Alexander Heger added the comment: So, apparently, more than just one spot needs to be fixed. I also tried just modifying the Python.h after install, but that does not do the trick either. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 08:10:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Sep 2015 06:10:06 +0000 Subject: [issue25159] Import time regression Message-ID: <1442556606.15.0.522584302018.issue25159@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: There are regressions in import time in 3.5 and 3.6. $ for i in `seq 5`; do ./python -I -m timeit -n1 -r1 "import enum"; done Python 3.4: 1 loops, best of 1: 3.45 msec per loop 1 loops, best of 1: 3.43 msec per loop 1 loops, best of 1: 3.55 msec per loop 1 loops, best of 1: 3.54 msec per loop 1 loops, best of 1: 3.42 msec per loop Python 3.5: 1 loops, best of 1: 4.38 msec per loop 1 loops, best of 1: 4.31 msec per loop 1 loops, best of 1: 4.32 msec per loop 1 loops, best of 1: 4.32 msec per loop 1 loops, best of 1: 4.4 msec per loop Python 3.6: 1 loops, best of 1: 20.2 msec per loop 1 loops, best of 1: 20.2 msec per loop 1 loops, best of 1: 22 msec per loop 1 loops, best of 1: 20.3 msec per loop 1 loops, best of 1: 20.4 msec per loop $ for i in `seq 5`; do ./python -I -m timeit -n1 -r1 -s "import sys; sys.modules.clear()" -- "import enum"; done Python 3.4: 1 loops, best of 1: 29.5 msec per loop 1 loops, best of 1: 29.3 msec per loop 1 loops, best of 1: 30 msec per loop 1 loops, best of 1: 28.9 msec per loop 1 loops, best of 1: 29.2 msec per loop Python 3.5: 1 loops, best of 1: 43.8 msec per loop 1 loops, best of 1: 44 msec per loop 1 loops, best of 1: 43.5 msec per loop 1 loops, best of 1: 43.1 msec per loop 1 loops, best of 1: 43.8 msec per loop Python 3.6: 1 loops, best of 1: 59.8 msec per loop 1 loops, best of 1: 59.1 msec per loop 1 loops, best of 1: 58.8 msec per loop 1 loops, best of 1: 58.6 msec per loop 1 loops, best of 1: 61.9 msec per loop And even in importing already imported and cached module there is small regression. $ for i in `seq 5`; do ./python -I -m timeit "import enum"; done Python 3.4: 100000 loops, best of 3: 3.04 usec per loop 100000 loops, best of 3: 3.07 usec per loop 100000 loops, best of 3: 3.08 usec per loop 100000 loops, best of 3: 3.11 usec per loop 100000 loops, best of 3: 3.04 usec per loop Python 3.5: 100000 loops, best of 3: 3.27 usec per loop 100000 loops, best of 3: 3.22 usec per loop 100000 loops, best of 3: 3.18 usec per loop 100000 loops, best of 3: 3.28 usec per loop 100000 loops, best of 3: 3.17 usec per loop Python 3.6: 100000 loops, best of 3: 3.29 usec per loop 100000 loops, best of 3: 3.26 usec per loop 100000 loops, best of 3: 3.34 usec per loop 100000 loops, best of 3: 3.35 usec per loop 100000 loops, best of 3: 3.35 usec per loop ---------- messages: 250941 nosy: brett.cannon, eric.snow, ncoghlan, serhiy.storchaka priority: normal severity: normal status: open title: Import time regression type: performance versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 08:25:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Sep 2015 06:25:14 +0000 Subject: [issue25147] Enum: remove dependency on OrderedDict In-Reply-To: <1442474307.48.0.698040907458.issue25147@psf.upfronthosting.co.za> Message-ID: <1442557514.59.0.678615803613.issue25147@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: But the comment is false. That change doesn't reduce startup cost. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 08:33:24 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 18 Sep 2015 06:33:24 +0000 Subject: [issue25147] Enum: remove dependency on OrderedDict In-Reply-To: <1442474307.48.0.698040907458.issue25147@psf.upfronthosting.co.za> Message-ID: <1442558004.54.0.164187689473.issue25147@psf.upfronthosting.co.za> Stefan Behnel added the comment: Let's say the change minimises the dependencies. That is a reasonable goal, too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 08:46:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Sep 2015 06:46:19 +0000 Subject: [issue25108] traceback.extract_stack() compatibility break in 3.5 In-Reply-To: <1442225623.41.0.830396346015.issue25108@psf.upfronthosting.co.za> Message-ID: <1442558779.09.0.614491008008.issue25108@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 08:51:53 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 06:51:53 +0000 Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5) In-Reply-To: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za> Message-ID: <1442559113.23.0.212846310799.issue25150@psf.upfronthosting.co.za> STINNER Victor added the comment: /home/alex/Python-3.5.0/Modules/_ctypes/_ctypes.c:2062:15: error: ?_PyThreadState_Current? undeclared (first use in this function) if (Py_EnterRecursiveCall("while processing _as_parameter_")) { ^ Ah yes, if you check the fix for C++ (changeset cb05b6d7aacd), I also had to modify pystate.h. Please try pyatomic-2.patch which hides more CPython internals in public headers. ---------- Added file: http://bugs.python.org/file40497/pyatomic-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 09:01:37 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 07:01:37 +0000 Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5) In-Reply-To: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za> Message-ID: <1442559697.48.0.684017290944.issue25150@psf.upfronthosting.co.za> STINNER Victor added the comment: I created a venv with a Python patched with pyatomic-2.patch: I successfully installed yt. yt depends on numpy & Cython: good news, numpy & Cython were compiled correctly. These two libraries are well known users of the Python C API. It's not enough to check if this change breaks modules on PyPI, but it's still a good news :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 09:06:19 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 07:06:19 +0000 Subject: [issue25160] Stop using deprecated imp module; imp should now emit a real DeprecationWarning Message-ID: <1442559979.71.0.954965412351.issue25160@psf.upfronthosting.co.za> New submission from STINNER Victor: The imp module is deprecated since Python 3.4. In Python 3.4, imp uses a PendingDeprecationWarning, and Python 3.5... hum, still a PendingDeprecationWarning. It was not supposed to become a real DeprecationWarning? Anyway, the imp module is still used in some places of the Python stdlib: Lib/modulefinder.py:14: import imp Python/makeopcodetargets.py:9:import imp Tools/i18n/pygettext.py:159:import imp Tools/importbench/importbench.py:10:import imp modulefinder explicitly ignore the warning :-( with warnings.catch_warnings(): warnings.simplefilter('ignore', PendingDeprecationWarning) import imp ---------- messages: 250946 nosy: brett.cannon, haypo priority: normal severity: normal status: open title: Stop using deprecated imp module; imp should now emit a real DeprecationWarning versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 09:10:21 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Sep 2015 07:10:21 +0000 Subject: [issue25108] traceback.extract_stack() compatibility break in 3.5 In-Reply-To: <1442225623.41.0.830396346015.issue25108@psf.upfronthosting.co.za> Message-ID: <20150918071016.81639.67461@psf.io> Roundup Robot added the comment: New changeset c9fb4362fb9f by Serhiy Storchaka in branch '3.5': Issue #25108: Omitted internal frames in traceback functions print_stack(), https://hg.python.org/cpython/rev/c9fb4362fb9f New changeset 4e617566bcb6 by Serhiy Storchaka in branch 'default': Issue #25108: Omitted internal frames in traceback functions print_stack(), https://hg.python.org/cpython/rev/4e617566bcb6 New changeset 9f57c937958f by Serhiy Storchaka in branch '3.4': Issue #25108: Backported tests for traceback functions print_stack(), https://hg.python.org/cpython/rev/9f57c937958f New changeset f6125114b55f by Serhiy Storchaka in branch '2.7': Issue #25108: Backported tests for traceback functions print_stack(), https://hg.python.org/cpython/rev/f6125114b55f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 09:11:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Sep 2015 07:11:14 +0000 Subject: [issue25108] traceback.extract_stack() compatibility break in 3.5 In-Reply-To: <1442225623.41.0.830396346015.issue25108@psf.upfronthosting.co.za> Message-ID: <1442560274.14.0.710453512641.issue25108@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 09:11:52 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 18 Sep 2015 07:11:52 +0000 Subject: [issue25160] Stop using deprecated imp module; imp should now emit a real DeprecationWarning In-Reply-To: <1442559979.71.0.954965412351.issue25160@psf.upfronthosting.co.za> Message-ID: <1442560312.11.0.635226994799.issue25160@psf.upfronthosting.co.za> Berker Peksag added the comment: > Python/makeopcodetargets.py:9:import imp See issue 20021. ---------- components: +Library (Lib) nosy: +berker.peksag stage: -> needs patch type: -> enhancement versions: -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 09:12:35 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Sep 2015 07:12:35 +0000 Subject: [issue25160] Stop using deprecated imp module; imp should now emit a real DeprecationWarning In-Reply-To: <1442559979.71.0.954965412351.issue25160@psf.upfronthosting.co.za> Message-ID: <20150918071234.11694.77889@psf.io> Roundup Robot added the comment: New changeset 03cd8340e0ce by Victor Stinner in branch '3.5': Issue #25160: Fix import_init() comments and messages https://hg.python.org/cpython/rev/03cd8340e0ce ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 09:19:24 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 18 Sep 2015 07:19:24 +0000 Subject: [issue25160] Stop using deprecated imp module; imp should now emit a real DeprecationWarning In-Reply-To: <1442559979.71.0.954965412351.issue25160@psf.upfronthosting.co.za> Message-ID: <1442560764.8.0.913609786538.issue25160@psf.upfronthosting.co.za> Berker Peksag added the comment: > Lib/modulefinder.py:14: import imp I forgot to link issue 20020 in my earlier message :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 09:21:30 2015 From: report at bugs.python.org (TAKASE Arihiro) Date: Fri, 18 Sep 2015 07:21:30 +0000 Subject: [issue25161] Missing periods at the end of sentences Message-ID: <1442560890.27.0.253223646248.issue25161@psf.upfronthosting.co.za> New submission from TAKASE Arihiro: The attached patch adds some periods in docs. This applies to 3.x. ---------- assignee: docs at python components: Documentation files: periods.patch keywords: patch messages: 250951 nosy: artakase, docs at python priority: normal severity: normal status: open title: Missing periods at the end of sentences type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40498/periods.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 09:22:54 2015 From: report at bugs.python.org (TAKASE Arihiro) Date: Fri, 18 Sep 2015 07:22:54 +0000 Subject: [issue25161] Missing periods at the end of sentences In-Reply-To: <1442560890.27.0.253223646248.issue25161@psf.upfronthosting.co.za> Message-ID: <1442560974.2.0.695927997477.issue25161@psf.upfronthosting.co.za> TAKASE Arihiro added the comment: Added patch for 2.7. ---------- Added file: http://bugs.python.org/file40499/periods-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 09:23:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Sep 2015 07:23:20 +0000 Subject: [issue25111] Broken compatibility in FrameSummary equality In-Reply-To: <1442252923.78.0.0672158797601.issue25111@psf.upfronthosting.co.za> Message-ID: <1442561000.5.0.331294621151.issue25111@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed patch and added tests. ---------- Added file: http://bugs.python.org/file40500/traceback_FrameSummary_equality_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 10:06:21 2015 From: report at bugs.python.org (Christian Ullrich) Date: Fri, 18 Sep 2015 08:06:21 +0000 Subject: [issue25162] Windows installation does not appear in list of installed applications Message-ID: <1442563581.64.0.527655601006.issue25162@psf.upfronthosting.co.za> New submission from Christian Ullrich: The new Windows installer always places the uninstallation registry key into HKCU of the executing user. This is correct for a per-user installation, but when run with InstallAllUsers=1, the key should go into HKLM instead. The "Programs and Features" list of installed applications is assembled from the HKLM and HKCU keys. In many cases, a system-wide installation will be performed by temporarily elevating the installer to a user account with administrator privileges on the local system. However, since Vista, the "Programs and Features" list is always run in the logged-on user's Explorer process, even when started by a different user (such as in an elevated command prompt). With the uninstallation key going into HKCU of some administrative account, the Python installation will not appear in this list, hence, cannot easily be removed. Ceterum censeo: This bug would have been avoided by using MSI as the distribution package format. ---------- components: Installation, Windows messages: 250954 nosy: Christian.Ullrich, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows installation does not appear in list of installed applications type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 10:13:20 2015 From: report at bugs.python.org (Christian Ullrich) Date: Fri, 18 Sep 2015 08:13:20 +0000 Subject: [issue25163] Windows installer in AllUsers mode presents wrong installation path Message-ID: <1442564000.23.0.122739262623.issue25163@psf.upfronthosting.co.za> New submission from Christian Ullrich: When run with InstallAllUsers=1, the Windows installer displays (%LOCALAPPDATA%)\Programs\Python\Python35 as the installation target directory, but actually installs into the path for a system-wide installation, "%PROGRAMFILES%\Python 3.5". Ceterum censeo: This bug could have been avoided, and would certainly have been detected in time, by using MSI as the distribution package format. Because most MSI UI will display TARGETDIR as the target directory, an accidental override (or missing override) of this path would have been obvious. ---------- components: Installation, Windows messages: 250955 nosy: Christian.Ullrich, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows installer in AllUsers mode presents wrong installation path type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 10:21:22 2015 From: report at bugs.python.org (Christian Ullrich) Date: Fri, 18 Sep 2015 08:21:22 +0000 Subject: [issue25164] Windows default installation path is inconsistent between per-user and system-wide installation Message-ID: <1442564482.39.0.225945260969.issue25164@psf.upfronthosting.co.za> New submission from Christian Ullrich: On Windows, a per-user installation uses %LOCALAPPDATA%\Programs\Python\Python35 as the default target directory. A system-wide (InstallAllUsers=1) installation, however, goes into "%PROGRAMFILES%\Python 3.5" instead. The two directory names should be consistent with each other (and with earlier versions), that is, should be "Python35" in all cases. ---------- components: Installation, Windows messages: 250956 nosy: Christian.Ullrich, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows default installation path is inconsistent between per-user and system-wide installation type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 11:03:04 2015 From: report at bugs.python.org (Christian Ullrich) Date: Fri, 18 Sep 2015 09:03:04 +0000 Subject: [issue25165] Windows uninstallation should not remove launcher if other versions remain Message-ID: <1442566984.06.0.904088337084.issue25165@psf.upfronthosting.co.za> New submission from Christian Ullrich: Uninstalling 3.5 on Windows removes the py.exe launcher. If it was installed in the system-wide path (%SYSTEMROOT%), it may have replaced an existing copy from an earlier version. In this case, removing the launcher will break this remaining installation, requiring a repair. Instead, the launcher should not be deleted. It uses the static CRT, hence has no DLL dependencies that would be removed by the uninstallation, and it will -- as PEP 397 demands -- select the Python version it starts based on the command line and the available installations. Ceterum censeo: This bug could have been avoided by using MSI as the distribution package format and using the same component code for the launcher file in all supporting versions. Even if the file itself is different, the identical component code would have ensured through reference counting that it would only have been removed with the last referencing installation. Upward compatibility of older launchers could have become a problem, though. ---------- components: Installation, Windows messages: 250957 nosy: Christian.Ullrich, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows uninstallation should not remove launcher if other versions remain type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 11:31:35 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Sep 2015 09:31:35 +0000 Subject: [issue25122] test_eintr randomly fails on FreeBSD In-Reply-To: <1442311779.01.0.43728096223.issue25122@psf.upfronthosting.co.za> Message-ID: <20150918093130.115507.39211@psf.io> Roundup Robot added the comment: New changeset 90722634f211 by Victor Stinner in branch 'default': Issue #25122: Fix test_eintr.test_open() on FreeBSD https://hg.python.org/cpython/rev/90722634f211 New changeset f347ea4391f3 by Victor Stinner in branch '3.5': Issue #25122: sync test_eintr with Python 3.6 https://hg.python.org/cpython/rev/f347ea4391f3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 11:34:58 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 09:34:58 +0000 Subject: [issue24836] Consistent failure in test_email on OS X Snow Leopard buildbot for Python 3.5 In-Reply-To: <1439116162.62.0.659790998501.issue24836@psf.upfronthosting.co.za> Message-ID: <1442568898.09.0.466399778749.issue24836@psf.upfronthosting.co.za> STINNER Victor added the comment: "The buildbot needs to upgrade its timezone files, they are quite out of date." For me the fix is quite simple: skip this specific test on old versions of Mac OS X. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 11:43:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Sep 2015 09:43:58 +0000 Subject: [issue25101] test_zipfile failure when run by unprivileged user with installed Python In-Reply-To: <1442206445.71.0.486177418249.issue25101@psf.upfronthosting.co.za> Message-ID: <1442569438.18.0.0239945690998.issue25101@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, using TemporaryFile for testing write access is not good on Windows, because there is an issue with TemporaryFile that it repeats attempts to create a file in read-only directory. Updated patch used constant file name. ---------- Added file: http://bugs.python.org/file40501/test_zipfile_check_write_access_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 13:13:44 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 18 Sep 2015 11:13:44 +0000 Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5) In-Reply-To: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za> Message-ID: <1442574824.87.0.571634345266.issue25150@psf.upfronthosting.co.za> Stefan Behnel added the comment: Would there be a way to expose these internals rather than hiding them? ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 13:18:10 2015 From: report at bugs.python.org (Christian Ullrich) Date: Fri, 18 Sep 2015 11:18:10 +0000 Subject: [issue25166] Windows AllUsers installation places uninstaller in user profile Message-ID: <1442575090.58.0.314641407957.issue25166@psf.upfronthosting.co.za> New submission from Christian Ullrich: A system-wide installation on Windows (using InstallAllUsers=1) still places the uninstall executable into the profile (%LOCALAPPDATA%) of the installing user. If that user profile is deleted, the (system-wide) installation cannot be removed anymore. Ceterum censeo: This bug would have been avoided by using MSI as the distribution package format. ---------- components: Installation, Windows messages: 250962 nosy: Christian.Ullrich, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows AllUsers installation places uninstaller in user profile versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 13:27:03 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Sep 2015 11:27:03 +0000 Subject: [issue25155] datetime.datetime.now() raises In-Reply-To: <1442517940.02.0.585598680273.issue25155@psf.upfronthosting.co.za> Message-ID: <20150918112700.9939.48215@psf.io> Roundup Robot added the comment: New changeset 203134592edf by Victor Stinner in branch 'default': Issue #25155: Add _PyTime_AsTimevalTime_t() function https://hg.python.org/cpython/rev/203134592edf ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 13:34:14 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 11:34:14 +0000 Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5) In-Reply-To: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za> Message-ID: <1442576054.05.0.674723983218.issue25150@psf.upfronthosting.co.za> STINNER Victor added the comment: > Would there be a way to expose these internals rather than hiding them? Here is the issue is that pyatomic.h cannot be compiled on OpenMP. We had the same issue with C++. In fact, it doesn't make sense to compile pyatomic.h differently to access an atomic variable from an extension module. We must always use exactly the same implementation, otherwise bad things will happen. A solution for that is to hide the implementation details and only expose high level APIs. For example, pyatomic.h must be completly hidden. A consequence is that the _PyThreadState_Current variable must be hidden to. _PyThreadState_Current is an implementation detail, you must not access it directly. The PyThreadState_GET() macro uses directly the _PyThreadState_Current variable. So the solution to expose the "PyThreadState_GET" symbol (not necessary as a macro) is to define it as an alias to the PyThreadState_Get() *function*. The advantage of using a function is that we don't expose implementation details to third-party extensions, it avoids the risk of ABI incompatibilies. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 13:47:02 2015 From: report at bugs.python.org (james) Date: Fri, 18 Sep 2015 11:47:02 +0000 Subject: [issue25167] THE SCORCH TRIALS OF MAZE RUNNER DISFACTION LOGGIC Message-ID: <1442576822.25.0.748464063855.issue25167@psf.upfronthosting.co.za> New submission from james: http://www.thebigidea.co.nz/profile/james/65456 http://www.cyclefish.com/hebucoho/ https://soundation.com/user/MazeRunnerTheScorchTrials https://issuu.com/mazerunnerthescorchtrials http://poputka.ua/user-profile-39591.aspx http://www.pikore.com/mazerunnerthescorch https://instagram.com/mazerunnerthescorch/ http://iconosquare.com/mazerunnerthescorch https://tofo.me/mazerunnerthescorch http://buzzsta.com/mazerunnerthescorch https://bitbucket.org/hebucoho/ ---------- components: asyncio messages: 250965 nosy: gvanrossum, haypo, leo, yselivanov priority: normal severity: normal status: open title: THE SCORCH TRIALS OF MAZE RUNNER DISFACTION LOGGIC versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 13:53:42 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 11:53:42 +0000 Subject: [issue25167] THE SCORCH TRIALS OF MAZE RUNNER DISFACTION LOGGIC In-Reply-To: <1442576822.25.0.748464063855.issue25167@psf.upfronthosting.co.za> Message-ID: <1442577222.55.0.355637034903.issue25167@psf.upfronthosting.co.za> STINNER Victor added the comment: obvious spam ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 13:56:14 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Sep 2015 11:56:14 +0000 Subject: [issue25155] datetime.datetime.now() raises In-Reply-To: <1442517940.02.0.585598680273.issue25155@psf.upfronthosting.co.za> Message-ID: <20150918115606.94125.64323@psf.io> Roundup Robot added the comment: New changeset 4ca99a0a18e4 by Victor Stinner in branch '3.5': Issue #25155: Add _PyTime_AsTimevalTime_t() function https://hg.python.org/cpython/rev/4ca99a0a18e4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 13:57:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 11:57:17 +0000 Subject: [issue25155] datetime.datetime.now() raises In-Reply-To: <1442517940.02.0.585598680273.issue25155@psf.upfronthosting.co.za> Message-ID: <1442577437.41.0.415927201498.issue25155@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh wow, I didn't expect such much headaches when I worked on unifiying the code to handle timestamps in the C part of CPython... > The bug was introduced while trying to support #22117: "Rewrite pytime.h to work on nanoseconds" in reve93eeadef0c3: https://hg.python.org/cpython/rev/e93eeadef0c3 Yeah, the changeset e93eeadef0c3 was the last change to drop the last function of the old PyTime. Well... in fact, I also had to keep _PyTime_ObjectToTime_t() and _PyTime_ObjectToTimeval() for the exact same reason: support timestamp after the year 2038 on Windows. Right, the tv_sec field of a timeval structure on Windows has the C type long, whereas it has the type time_t on all other platforms... I fixed the bug in Python 3.5 and 3.6. Thanks for your bug report. I didn't expect to test year 2038 bug on the latest release, thanks time traveler :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 13:59:39 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Sep 2015 11:59:39 +0000 Subject: [issue25155] datetime.datetime.now() raises In-Reply-To: <1442517940.02.0.585598680273.issue25155@psf.upfronthosting.co.za> Message-ID: <20150918115936.11714.26406@psf.io> Roundup Robot added the comment: New changeset 5bfcccf229c4 by Victor Stinner in branch '3.5': Issue #25155: document the bugfix in Misc/NEWS https://hg.python.org/cpython/rev/5bfcccf229c4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 14:00:45 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 12:00:45 +0000 Subject: [issue25155] Windows: datetime.datetime.now() raises an OverflowError for date after year 2038 In-Reply-To: <1442517940.02.0.585598680273.issue25155@psf.upfronthosting.co.za> Message-ID: <1442577645.09.0.792554695163.issue25155@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: datetime.datetime.now() raises -> Windows: datetime.datetime.now() raises an OverflowError for date after year 2038 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 14:00:51 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 12:00:51 +0000 Subject: [issue25155] Windows: datetime.datetime.now() raises an OverflowError for date after year 2038 In-Reply-To: <1442517940.02.0.585598680273.issue25155@psf.upfronthosting.co.za> Message-ID: <1442577651.59.0.880484537296.issue25155@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 14:13:55 2015 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 18 Sep 2015 12:13:55 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442578435.52.0.610628383647.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: Cleaned up the error handling in fstring_expression_compile so it's easier to verify and more robust in the face of future changes. Added a test for an un-doubled '}', which is an error in a top-level literal (and ends a nested expression). Modified existing tests to match. ---------- Added file: http://bugs.python.org/file40502/pep-498-9.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 14:22:44 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Sep 2015 12:22:44 +0000 Subject: [issue25155] Windows: datetime.datetime.now() raises an OverflowError for date after year 2038 In-Reply-To: <1442517940.02.0.585598680273.issue25155@psf.upfronthosting.co.za> Message-ID: <20150918122230.81645.6@psf.io> Roundup Robot added the comment: New changeset f1cc1f379b00 by Victor Stinner in branch '3.5': Issue #25155: Fix _PyTime_Divide() rounding https://hg.python.org/cpython/rev/f1cc1f379b00 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 14:23:21 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 18 Sep 2015 12:23:21 +0000 Subject: [issue25019] xmlparse_setattro() Type Confusion In-Reply-To: <1441641362.28.0.731210993135.issue25019@psf.upfronthosting.co.za> Message-ID: <1442579001.8.0.799440594325.issue25019@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 14:25:14 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 18 Sep 2015 12:25:14 +0000 Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5) In-Reply-To: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za> Message-ID: <1442579114.1.0.388791129812.issue25150@psf.upfronthosting.co.za> Stefan Behnel added the comment: Understood and agreed. Second patch looks good to me. Cython calls PyThreadState_GET() in pretty much every helper function that deals with exceptions, but I doubt that the potential speed difference is going to be relevant in the real world. And we target CPython's API level anyway, not the ABI, so the C code will just adapt at compile time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 14:58:34 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Sep 2015 12:58:34 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <20150918125828.81643.24285@psf.io> Roundup Robot added the comment: New changeset ee1cf1b188d2 by Victor Stinner in branch '3.4': Issue #23517: Fix rounding in fromtimestamp() and utcfromtimestamp() methods https://hg.python.org/cpython/rev/ee1cf1b188d2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:01:57 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 13:01:57 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1442581317.8.0.281957923714.issue23517@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, I fixed Python 3.4 and 3.5 too: fromtimestamp() and utcfromtimestamp() now uses also ROUND_HALF_EVEN rounding mode, as timedelta constructor. I explained in Misc/NEWS that the change was made to respect the property: (datetime(1970,1,1) + timedelta(seconds=t)) == datetime.utcfromtimestamp(t) Thanks Alexander Belopolsky & Tim Peters for your explanation on rounding. It's not a simple problem :-) Thanks Tommaso Barbugli for the bug report: it's now fixed on all (maintained) Python 3 versions: 3.4, 3.5 and 3.6. The fix will be part of Python 3.5.1. ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:06:10 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 18 Sep 2015 13:06:10 +0000 Subject: [issue24199] Idle: remove idlelib.idlever.py and its use in About dialog In-Reply-To: <1431650285.59.0.600694723613.issue24199@psf.upfronthosting.co.za> Message-ID: <1442581570.38.0.656183815597.issue24199@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: > Since I am not wrapping the warning, the default stacklevel seems to work on all versions. The purpose of stacklevel=2 here would be to make warning message indicate which file contains import of deprecated module. See below example, which shows that stacklevel=2 in formatter.py and imp.py results in message pointing to bbb.py as containing imports of deprecated modules: $ cat aaa.py import bbb $ cat bbb.py import formatter import imp import idlelib.idlever $ python3.5 -Wd -c 'import aaa' /tmp/bbb.py:1: DeprecationWarning: the formatter module is deprecated and will be removed in Python 3.6 import formatter /tmp/bbb.py:2: PendingDeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses import imp /usr/lib64/python3.5/idlelib/idlever.py:10: DeprecationWarning: The separate Idle version was eliminated years ago; idlelib.idlever is no longer used by Idle and will be removed in 3.6 or later. Use from sys import version IDLE_VERSION = version[:version.index(' ')] w.warn(__doc__, DeprecationWarning) $ ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:09:14 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Sep 2015 13:09:14 +0000 Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5) In-Reply-To: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za> Message-ID: <20150918130905.98380.36437@psf.io> Roundup Robot added the comment: New changeset d4fcb362f7c6 by Victor Stinner in branch '3.5': Issue #25150: Hide the private _Py_atomic_xxx symbols from the public https://hg.python.org/cpython/rev/d4fcb362f7c6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:09:58 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 13:09:58 +0000 Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5) In-Reply-To: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za> Message-ID: <1442581798.56.0.611860273855.issue25150@psf.upfronthosting.co.za> STINNER Victor added the comment: I pushed my fix pyatomic-2.patch to Python 3.5 and 3.6. Thanks for the bug report Alexander Heger! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:11:31 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 13:11:31 +0000 Subject: [issue23517] datetime.utcfromtimestamp rounds results incorrectly In-Reply-To: <1424817522.64.0.693607620573.issue23517@psf.upfronthosting.co.za> Message-ID: <1442581891.17.0.367838306548.issue23517@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:16:40 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 13:16:40 +0000 Subject: [issue25114] asynico: add ssl_object extra info In-Reply-To: <1442268047.01.0.688232314675.issue25114@psf.upfronthosting.co.za> Message-ID: <1442582200.32.0.583189797557.issue25114@psf.upfronthosting.co.za> STINNER Victor added the comment: Guido? Yury? Can you please review attached patch? It looks like a Python 3.5 regression. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:19:00 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 13:19:00 +0000 Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5) In-Reply-To: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za> Message-ID: <1442582340.08.0.572315928044.issue25150@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:19:59 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 13:19:59 +0000 Subject: [issue25122] test_eintr randomly fails on FreeBSD In-Reply-To: <1442311779.01.0.43728096223.issue25122@psf.upfronthosting.co.za> Message-ID: <1442582399.11.0.618131788336.issue25122@psf.upfronthosting.co.za> STINNER Victor added the comment: test_eintr should now be fixed in Python 3.5 and 3.6: I skipped the test_open() and test_os_open() tests of test_eintr on FreeBSD. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:20:39 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 13:20:39 +0000 Subject: [issue25137] Behavioral change / regression? with nested functools.partial In-Reply-To: <1442367392.37.0.924790344603.issue25137@psf.upfronthosting.co.za> Message-ID: <1442582439.53.0.984657100814.issue25137@psf.upfronthosting.co.za> STINNER Victor added the comment: Can we close this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:22:19 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 13:22:19 +0000 Subject: [issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x) In-Reply-To: <1442151642.39.0.456899707142.issue25084@psf.upfronthosting.co.za> Message-ID: <1442582539.97.0.295184896279.issue25084@psf.upfronthosting.co.za> STINNER Victor added the comment: Nick, Antoine: do you agree to close this issue as WONTFIX for the reasons explained in msg250712? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:23:55 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 13:23:55 +0000 Subject: [issue25077] Compiler warnings: initialization from incompatible pointer type In-Reply-To: <1442042610.13.0.957335882034.issue25077@psf.upfronthosting.co.za> Message-ID: <1442582635.3.0.284025835172.issue25077@psf.upfronthosting.co.za> STINNER Victor added the comment: "For ceval, it comes from pyatomic.h: see my atomic_pointer.patch attached to the issue #25077." Oops, it's the issue #22038. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:30:45 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 13:30:45 +0000 Subject: [issue25129] Rounding mode of floating-point floor division is not well documented In-Reply-To: <1442338083.45.0.230324673027.issue25129@psf.upfronthosting.co.za> Message-ID: <1442583045.42.0.95134636644.issue25129@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: suboptimal floating-point floor division -> Rounding mode of floating-point floor division is not well documented _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:31:00 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 13:31:00 +0000 Subject: [issue25129] Rounding mode of floating-point division is not well documented In-Reply-To: <1442338083.45.0.230324673027.issue25129@psf.upfronthosting.co.za> Message-ID: <1442583060.75.0.95168121639.issue25129@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Rounding mode of floating-point floor division is not well documented -> Rounding mode of floating-point division is not well documented _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:37:15 2015 From: report at bugs.python.org (Chris Angelico) Date: Fri, 18 Sep 2015 13:37:15 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442583435.28.0.49439105244.issue24965@psf.upfronthosting.co.za> Changes by Chris Angelico : ---------- nosy: +Rosuav _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:38:49 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 18 Sep 2015 13:38:49 +0000 Subject: [issue25159] Import time regression In-Reply-To: <1442556606.15.0.522584302018.issue25159@psf.upfronthosting.co.za> Message-ID: <1442583529.58.0.470661810667.issue25159@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:38:54 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Sep 2015 13:38:54 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) on Solaris 11.3 and newer In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <20150918133847.94121.46070@psf.io> Roundup Robot added the comment: New changeset 8b0c2c7cb4a7 by Victor Stinner in branch 'default': Issue #25003: On Solaris 11.3 or newer, os.urandom() now uses the getrandom() https://hg.python.org/cpython/rev/8b0c2c7cb4a7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:39:24 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 18 Sep 2015 13:39:24 +0000 Subject: [issue25167] Spam In-Reply-To: <1442576822.25.0.748464063855.issue25167@psf.upfronthosting.co.za> Message-ID: <1442583564.24.0.973971258697.issue25167@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- components: -asyncio nosy: -gvanrossum, haypo, leo, yselivanov stage: -> resolved title: THE SCORCH TRIALS OF MAZE RUNNER DISFACTION LOGGIC -> Spam versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:40:06 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 18 Sep 2015 13:40:06 +0000 Subject: [issue25167] Spam In-Reply-To: <1442577222.55.0.355637034903.issue25167@psf.upfronthosting.co.za> Message-ID: <1442583606.39.0.286070360909.issue25167@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- Removed message: http://bugs.python.org/msg250965 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:43:30 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 13:43:30 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) on Solaris 11.3 and newer In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1442583810.11.0.286758843848.issue25003@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, I pushed a first fix for Python 3.6. The changeset 8b0c2c7cb4a7 keeps getentropy() on OpenBSD, but it explicitly excludes getentropy() on Solaris ("!defined(sun)"). It adds support for the getrandom() function. As the EINVAL error will be fixed in the final version of Solaris 11.3, I chose to not support this specific error. @John Beck: Does it look good to you? Can you test it? You may have to manually modify the code to not pass a value too large to getrandom() until the Solaris kernel is fixed. If John and buildbots are happy, I will backport the change to Python 2.7, 3.4 and 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:48:01 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 13:48:01 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1442584081.42.0.0318488139244.issue24999@psf.upfronthosting.co.za> STINNER Victor added the comment: """ If shifting right twice (adding parens for clarity): (LONG_MAX >> PyLong_SHIFT) >> PyLong_SHIFT. squashes the warnings, that would be a substantially clearer way to express the intent than the SIZEOF_LONG*CHAR_BIT-1 >= 2*PyLong_SHIFT spelling. Adding a comment *explaining* the intent would be even better. """ Ok, here is a patch implementing this issue: long_shift_ub.patch. I'm unable to test it with ICC, but we can try to push it and check on the ICC buildbots. ---------- keywords: +patch Added file: http://bugs.python.org/file40503/long_shift_ub.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:49:45 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 13:49:45 +0000 Subject: [issue21874] test_strptime fails on rhel/centos/fedora systems In-Reply-To: <1403826345.9.0.88896627543.issue21874@psf.upfronthosting.co.za> Message-ID: <1442584185.39.0.793056782713.issue21874@psf.upfronthosting.co.za> STINNER Victor added the comment: No feedback: I close the issue. I consider that the issue is gone. (I have no issue on my Fedora 22.) ---------- nosy: +haypo resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:50:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 13:50:49 +0000 Subject: [issue25168] test_datetime.test_strptime() random failures on "s390x SLES" buildbots Message-ID: <1442584249.02.0.854297601638.issue25168@psf.upfronthosting.co.za> New submission from STINNER Victor: It looks like the failure is random. It probably depends on the test order. http://buildbot.python.org/all/builders/s390x%20SLES%203.4/builds/45/steps/test/logs/stdio ====================================================================== ERROR: test_strptime (test.datetimetester.TestDateTimeTZ_Pure) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/test/datetimetester.py", line 1941, in test_strptime dt = strptime(dtstr, "%z %Z") File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/datetime.py", line 1607, in strptime return _strptime._strptime_datetime(cls, date_string, format) File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/_strptime.py", line 500, in _strptime_datetime tt, fraction = _strptime(data_string, format) File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/_strptime.py", line 337, in _strptime (data_string, format)) ValueError: time data '-0500 EST' does not match format '%z %Z' ====================================================================== ERROR: test_strptime (test.datetimetester.TestDateTime_Pure) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/test/datetimetester.py", line 1941, in test_strptime dt = strptime(dtstr, "%z %Z") File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/datetime.py", line 1607, in strptime return _strptime._strptime_datetime(cls, date_string, format) File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/_strptime.py", line 500, in _strptime_datetime tt, fraction = _strptime(data_string, format) File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/_strptime.py", line 337, in _strptime (data_string, format)) ValueError: time data '-0500 EST' does not match format '%z %Z' ====================================================================== ERROR: test_strptime (test.datetimetester.TestSubclassDateTime_Pure) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/test/datetimetester.py", line 1941, in test_strptime dt = strptime(dtstr, "%z %Z") File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/datetime.py", line 1607, in strptime return _strptime._strptime_datetime(cls, date_string, format) File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/_strptime.py", line 500, in _strptime_datetime tt, fraction = _strptime(data_string, format) File "/home/dje/cpython-buildarea/3.4.edelsohn-sles-z/build/Lib/_strptime.py", line 337, in _strptime (data_string, format)) ValueError: time data '-0500 EST' does not match format '%z %Z' ---------- keywords: buildbot messages: 250987 nosy: belopolsky, haypo, serhiy.storchaka priority: normal severity: normal status: open title: test_datetime.test_strptime() random failures on "s390x SLES" buildbots versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:51:48 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 13:51:48 +0000 Subject: [issue25008] Deprecate smtpd (based on deprecated asyncore/asynchat): write a new smtp server with asyncio In-Reply-To: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za> Message-ID: <1442584308.19.0.114440197193.issue25008@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Deprecate smtpd -> Deprecate smtpd (based on deprecated asyncore/asynchat): write a new smtp server with asyncio _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:54:10 2015 From: report at bugs.python.org (Tim Graham) Date: Fri, 18 Sep 2015 13:54:10 +0000 Subject: [issue25137] Behavioral change / regression? with nested functools.partial In-Reply-To: <1442367392.37.0.924790344603.issue25137@psf.upfronthosting.co.za> Message-ID: <1442584450.03.0.526227209614.issue25137@psf.upfronthosting.co.za> Tim Graham added the comment: It's fine with me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 15:55:33 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 13:55:33 +0000 Subject: [issue25137] Behavioral change / regression? with nested functools.partial In-Reply-To: <1442367392.37.0.924790344603.issue25137@psf.upfronthosting.co.za> Message-ID: <1442584533.52.0.806856377949.issue25137@psf.upfronthosting.co.za> STINNER Victor added the comment: Tim Graham wrote: "It's fine with me." Oh, I see that your pull request was merged. I'm now closing the issue. Anyway, thanks for the bug report. It's always good to have feedback on behaviour changes, even when they are legit :-) ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 16:08:18 2015 From: report at bugs.python.org (Erik Bray) Date: Fri, 18 Sep 2015 14:08:18 +0000 Subject: [issue24766] Subclass of property doesn't preserve instance __doc__ when using doc= argument In-Reply-To: <1438362123.61.0.0930515598899.issue24766@psf.upfronthosting.co.za> Message-ID: <1442585298.36.0.232180684814.issue24766@psf.upfronthosting.co.za> Erik Bray added the comment: Interesting--in fairness to myself, that test seems to fail without my patch too (without the -R it passes, but with -R3:3 it fails). So it looks like a pre-existing issue. But I'll see if I can do something about that while I'm at it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 16:14:00 2015 From: report at bugs.python.org (Markus Holtermann) Date: Fri, 18 Sep 2015 14:14:00 +0000 Subject: [issue25137] Behavioral change / regression? with nested functools.partial In-Reply-To: <1442367392.37.0.924790344603.issue25137@psf.upfronthosting.co.za> Message-ID: <1442585640.35.0.76080192221.issue25137@psf.upfronthosting.co.za> Markus Holtermann added the comment: Interesting thing tough, this optimization is nowhere mentioned in the 3.5 release notes ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 16:17:00 2015 From: report at bugs.python.org (Laura Creighton) Date: Fri, 18 Sep 2015 14:17:00 +0000 Subject: [issue25157] Installing Python 3.5.0 32bit on Windows 8.1 64bit system gives Error 0x80240017 In-Reply-To: <1442526643.4.0.412457342038.issue25157@psf.upfronthosting.co.za> Message-ID: <1442585820.57.0.994790565468.issue25157@psf.upfronthosting.co.za> Laura Creighton added the comment: The person with the problem has reported to webmaster than the first method in this list http://wind8apps.com/error-0x80240017-windows/ did not fix his problem. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 16:17:49 2015 From: report at bugs.python.org (John Beck) Date: Fri, 18 Sep 2015 14:17:49 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) on Solaris 11.3 and newer In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1442585869.17.0.788778546118.issue25003@psf.upfronthosting.co.za> John Beck added the comment: I have tested your patch with 3.5, and it works fine, although I did have to make a minor change to get test_os to pass. In test_os.py you had: ... USE_GETENTROPY = ((sysconfig.get_config_var('HAVE_GETENTROPY') == 1) and not sys.platform.startswith("sunos")) HAVE_GETRANDOM = (sysconfig.get_config_var('HAVE_GETRANDOM_SYSCALL') == 1) @unittest.skipIf(USE_GETENTROPY, "getentropy() does not use a file descriptor") @unittest.skipIf(HAVE_GETRANDOM, "getrandom() does not use a file descriptor") ... whereas I came up with this: ... USE_GETENTROPY = ((sysconfig.get_config_var('HAVE_GETENTROPY') == 1) and not sys.platform.startswith("sunos")) HAVE_GETRANDOM = (sysconfig.get_config_var('HAVE_GETRANDOM') == 1) HAVE_GETRANDOM_SYSCALL = (sysconfig.get_config_var('HAVE_GETRANDOM_SYSCALL') == 1) @unittest.skipIf(USE_GETENTROPY, "getentropy() does not use a file descriptor") @unittest.skipIf(HAVE_GETRANDOM, "getrandom() does not use a file descriptor") @unittest.skipIf(HAVE_GETRANDOM_SYSCALL, "getrandom() does not use a file descriptor") ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 16:22:06 2015 From: report at bugs.python.org (Erik Bray) Date: Fri, 18 Sep 2015 14:22:06 +0000 Subject: [issue24766] Subclass of property doesn't preserve instance __doc__ when using doc= argument In-Reply-To: <1438362123.61.0.0930515598899.issue24766@psf.upfronthosting.co.za> Message-ID: <1442586126.68.0.720752667571.issue24766@psf.upfronthosting.co.za> Erik Bray added the comment: Actually, of course that test would fail when run repeatedly--it sets the property docstring from 'Eggs' to 'Spam' on the first run, but then doesn't set it back to its original value. Since the PropertyWritableDocs class used in that test is module-level it doesn't get reset. I'd just update that test to return the docstring to its original value if you want it to pass under such a condition. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 16:26:39 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Sep 2015 14:26:39 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) on Solaris 11.3 and newer In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <20150918142635.3648.36372@psf.io> Roundup Robot added the comment: New changeset 221e09b89186 by Victor Stinner in branch 'default': Issue #25003: Skip test_os.URandomFDTests on Solaris 11.3 and newer https://hg.python.org/cpython/rev/221e09b89186 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 16:27:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 14:27:04 +0000 Subject: [issue25003] os.urandom() should call getrandom(2) not getentropy(2) on Solaris 11.3 and newer In-Reply-To: <1441403068.22.0.654234676609.issue25003@psf.upfronthosting.co.za> Message-ID: <1442586424.72.0.185368816036.issue25003@psf.upfronthosting.co.za> STINNER Victor added the comment: "I have tested your patch with 3.5, and it works fine, although I did have to make a minor change to get test_os to pass. In test_os.py you had: (...)" Oh right, I fixed test_os too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 16:27:11 2015 From: report at bugs.python.org (Erik Bray) Date: Fri, 18 Sep 2015 14:27:11 +0000 Subject: [issue24766] Subclass of property doesn't preserve instance __doc__ when using doc= argument In-Reply-To: <1438362123.61.0.0930515598899.issue24766@psf.upfronthosting.co.za> Message-ID: <1442586431.37.0.755963081943.issue24766@psf.upfronthosting.co.za> Erik Bray added the comment: Attached an additional patch to test_property_decorator_doc_writable so that it can pass on repeated runs. ---------- Added file: http://bugs.python.org/file40504/property-doc-test2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 16:27:23 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 18 Sep 2015 14:27:23 +0000 Subject: [issue24836] Consistent failure in test_email on OS X Snow Leopard buildbot for Python 3.5 In-Reply-To: <1439116162.62.0.659790998501.issue24836@psf.upfronthosting.co.za> Message-ID: <1442586443.17.0.330269316861.issue24836@psf.upfronthosting.co.za> R. David Murray added the comment: That would be fine with me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 16:34:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Sep 2015 14:34:19 +0000 Subject: [issue24836] Consistent failure in test_email on OS X Snow Leopard buildbot for Python 3.5 In-Reply-To: <1439116162.62.0.659790998501.issue24836@psf.upfronthosting.co.za> Message-ID: <20150918143402.81639.70839@psf.io> Roundup Robot added the comment: New changeset 9fb47dcd02fd by Victor Stinner in branch '3.4': Issue #24836: Skip FormatDateTests of test_email.test_utils on Mac OS X Snow https://hg.python.org/cpython/rev/9fb47dcd02fd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 16:42:49 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Sep 2015 14:42:49 +0000 Subject: [issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x) In-Reply-To: <1442151642.39.0.456899707142.issue25084@psf.upfronthosting.co.za> Message-ID: <1442587369.45.0.851700593663.issue25084@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Yes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 16:44:43 2015 From: report at bugs.python.org (Erik Bray) Date: Fri, 18 Sep 2015 14:44:43 +0000 Subject: [issue24324] Remove -Wunreachable-code flag In-Reply-To: <1432907477.51.0.798249204562.issue24324@psf.upfronthosting.co.za> Message-ID: <1442587483.02.0.643991618226.issue24324@psf.upfronthosting.co.za> Erik Bray added the comment: This would definitely be nice to fix. I panicked a bit because of this when I compiled my extension modules against Python 3.5 for the first time. ---------- nosy: +erik.bray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 16:54:36 2015 From: report at bugs.python.org (John Taylor) Date: Fri, 18 Sep 2015 14:54:36 +0000 Subject: [issue25169] multiprocess documentation Message-ID: <1442588076.4.0.907099744388.issue25169@psf.upfronthosting.co.za> New submission from John Taylor: In the Windows Help File for Python 3.5: 17.2 multiprocessing 17.2.1.1 The Process class 2nd code example: "To show the individual process IDs involved, here is an expanded example" def info(title): print(title) print('module name:', __name__) if hasattr(os, 'getppid'): # only available on Unix print('parent process:', os.getppid()) print('process id:', os.getpid()) os.getppid() is now available on Windows, so you can remove the if statement. ---------- assignee: docs at python components: Documentation messages: 251002 nosy: docs at python, jftuga priority: normal severity: normal status: open title: multiprocess documentation versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 17:06:30 2015 From: report at bugs.python.org (John Taylor) Date: Fri, 18 Sep 2015 15:06:30 +0000 Subject: [issue25169] multiprocess documentation In-Reply-To: <1442588076.4.0.907099744388.issue25169@psf.upfronthosting.co.za> Message-ID: <1442588790.01.0.818600131808.issue25169@psf.upfronthosting.co.za> John Taylor added the comment: To follow up on my previous message, I looked at the documentation for os.getppid(). It states: Changed in version 3.2: Added support for Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 17:21:03 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 15:21:03 +0000 Subject: [issue24324] Remove -Wunreachable-code flag In-Reply-To: <1432907477.51.0.798249204562.issue24324@psf.upfronthosting.co.za> Message-ID: <1442589663.42.0.023148955018.issue24324@psf.upfronthosting.co.za> STINNER Victor added the comment: Can you please propose a patch? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 17:26:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Sep 2015 15:26:49 +0000 Subject: [issue25168] test_datetime.test_strptime() random failures on "s390x SLES" buildbots In-Reply-To: <1442584249.02.0.854297601638.issue25168@psf.upfronthosting.co.za> Message-ID: <1442590009.18.0.530859975982.issue25168@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Perhaps related issues: issue6641, issue13309, issue22377, issue22426. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 17:31:22 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 18 Sep 2015 15:31:22 +0000 Subject: [issue24766] Subclass of property doesn't preserve instance __doc__ when using doc= argument In-Reply-To: <1438362123.61.0.0930515598899.issue24766@psf.upfronthosting.co.za> Message-ID: <1442590282.15.0.827643794631.issue24766@psf.upfronthosting.co.za> Ethan Furman added the comment: Thanks for checking that out, Erik. I was hoping it was a testing issue, but I ran out of time to verify. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 17:33:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Sep 2015 15:33:36 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1442590416.29.0.606083405733.issue24999@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I'm fine with both variants: (LONG_MAX >> PyLong_SHIFT) >> PyLong_SHIFT and SIZEOF_LONG*CHAR_BIT-1 >= 2*PyLong_SHIFT (the latter can be simplified to 8*SIZEOF_LONG > 2*PyLong_SHIFT). A comment on the next line explains the condition, it can be extended if needed. I'm fine with Victor's patch too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 17:35:21 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 18 Sep 2015 15:35:21 +0000 Subject: [issue25159] Import time regression In-Reply-To: <1442556606.15.0.522584302018.issue25159@psf.upfronthosting.co.za> Message-ID: <1442590521.77.0.952390821817.issue25159@psf.upfronthosting.co.za> Brett Cannon added the comment: I don't know how much of this is directly importlib's fault, at least in the 3.5 -> 3.6 case, as very little has changed in the bootstrap code since 3.6 started: https://hg.python.org/cpython/log/default/Lib/importlib/_bootstrap.py and https://hg.python.org/cpython/log/default/Lib/importlib/_bootstrap_external.py and https://hg.python.org/cpython/log/default/Python/import.c . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:08:02 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 16:08:02 +0000 Subject: [issue25159] Import time regression In-Reply-To: <1442556606.15.0.522584302018.issue25159@psf.upfronthosting.co.za> Message-ID: <1442592482.48.0.636065896842.issue25159@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:10:12 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 18 Sep 2015 16:10:12 +0000 Subject: [issue25159] Import time regression In-Reply-To: <1442556606.15.0.522584302018.issue25159@psf.upfronthosting.co.za> Message-ID: <1442592612.75.0.764413001079.issue25159@psf.upfronthosting.co.za> STINNER Victor added the comment: Even if Python 3.5 startup is slower than Python 3.4 startup, I'm more concerned by Python 3.6! What happens in Python 3.6? Are you sure that all binaries were compiled in release mode? Why do you import enum? The bare minimum is "pass" :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:29:17 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:29:17 +0000 Subject: [issue15191] tkinter convenience dialogs don't use themed widgets In-Reply-To: <1340700094.05.0.57171486761.issue15191@psf.upfronthosting.co.za> Message-ID: <1442593757.41.0.460310605053.issue15191@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:30:34 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:30:34 +0000 Subject: [issue17060] IDLE -- jump to home should not go past the PS1 and PS2 prompts In-Reply-To: <1359364664.26.0.133025400757.issue17060@psf.upfronthosting.co.za> Message-ID: <1442593834.69.0.252725375238.issue17060@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:31:15 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:31:15 +0000 Subject: [issue18064] IDLE: add current directory to open_module In-Reply-To: <1369517780.56.0.941397989466.issue18064@psf.upfronthosting.co.za> Message-ID: <1442593875.88.0.764897038177.issue18064@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:31:35 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:31:35 +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: <1442593895.99.0.852491605462.issue11229@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:32:02 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:32:02 +0000 Subject: [issue14440] Close background process if IDLE closes abnormally. In-Reply-To: <1333027712.59.0.103811521392.issue14440@psf.upfronthosting.co.za> Message-ID: <1442593922.8.0.184107901798.issue14440@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:32:22 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:32:22 +0000 Subject: [issue15308] IDLE - add an "Interrupt Execution" to shell menu In-Reply-To: <1341865491.11.0.0892141451607.issue15308@psf.upfronthosting.co.za> Message-ID: <1442593942.01.0.51464577719.issue15308@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:33:30 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:33:30 +0000 Subject: [issue18318] Idle: stop depending on console output In-Reply-To: <1372373009.47.0.618602359328.issue18318@psf.upfronthosting.co.za> Message-ID: <1442594010.04.0.627385248439.issue18318@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:33:56 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:33:56 +0000 Subject: [issue18444] IDLE: Mac OS X pressing ctrl-A in Python shell moved cursor before the prompt, which then makes the keyboard unresponsive. In-Reply-To: <1373777050.16.0.963661085579.issue18444@psf.upfronthosting.co.za> Message-ID: <1442594036.63.0.298970897629.issue18444@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:34:54 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:34:54 +0000 Subject: [issue12913] Add a debugging howto In-Reply-To: <1315323088.65.0.459623812563.issue12913@psf.upfronthosting.co.za> Message-ID: <1442594094.33.0.456690227589.issue12913@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:35:52 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:35:52 +0000 Subject: [issue1080387] Making IDLE Themes and Keys Config more Robust Message-ID: <1442594152.19.0.965499124785.issue1080387@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:36:24 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:36:24 +0000 Subject: [issue20579] OS X IDLE keyboard accelerators fail or misbehave with Cocoa Tk In-Reply-To: <1392027042.62.0.0419013450349.issue20579@psf.upfronthosting.co.za> Message-ID: <1442594184.54.0.539055914939.issue20579@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:36:57 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:36:57 +0000 Subject: [issue20827] IDLE : Display function argument list in ClassBrowser In-Reply-To: <1393772724.12.0.548840750027.issue20827@psf.upfronthosting.co.za> Message-ID: <1442594217.44.0.493724585916.issue20827@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:37:17 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:37:17 +0000 Subject: [issue1350] IDLE - CallTips enhancement - show full doc-string in new window In-Reply-To: <1193540394.75.0.209428889105.issue1350@psf.upfronthosting.co.za> Message-ID: <1442594237.11.0.432206092324.issue1350@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:38:12 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:38:12 +0000 Subject: [issue21674] Idle: Add 'find all' in current file In-Reply-To: <1402000832.05.0.464293408794.issue21674@psf.upfronthosting.co.za> Message-ID: <1442594292.03.0.773675914282.issue21674@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:38:27 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:38:27 +0000 Subject: [issue21647] Idle unittests: make gui, mock switching easier. In-Reply-To: <1401775120.92.0.367070549797.issue21647@psf.upfronthosting.co.za> Message-ID: <1442594307.11.0.889507001124.issue21647@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:39:51 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:39:51 +0000 Subject: [issue8231] Unable to run IDLE without write-access to home directory In-Reply-To: <1269531569.44.0.352644957859.issue8231@psf.upfronthosting.co.za> Message-ID: <1442594391.0.0.466064330116.issue8231@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:40:22 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:40:22 +0000 Subject: [issue21588] Idle: make editor title bar user configurable In-Reply-To: <1401167354.94.0.454935095166.issue21588@psf.upfronthosting.co.za> Message-ID: <1442594422.07.0.182938981226.issue21588@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:40:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 18 Sep 2015 16:40:36 +0000 Subject: [issue25159] Import time regression In-Reply-To: <1442556606.15.0.522584302018.issue25159@psf.upfronthosting.co.za> Message-ID: <1442594436.96.0.354047890712.issue25159@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is not startup time, this is import time. All binaries were compiled in release mode. The regression is reproducible with other modules. $ for i in `seq 5`; do ./python -I -m timeit -n1 -r1 "import zipfile"; done Python 3.4: 1 loops, best of 1: 46 msec per loop 1 loops, best of 1: 45.3 msec per loop 1 loops, best of 1: 45.9 msec per loop 1 loops, best of 1: 45.1 msec per loop 1 loops, best of 1: 45.3 msec per loop Python 3.5: 1 loops, best of 1: 49.1 msec per loop 1 loops, best of 1: 49.9 msec per loop 1 loops, best of 1: 50 msec per loop 1 loops, best of 1: 49.9 msec per loop 1 loops, best of 1: 53.7 msec per loop Python 3.6: 1 loops, best of 1: 66.3 msec per loop 1 loops, best of 1: 64.2 msec per loop 1 loops, best of 1: 64.6 msec per loop 1 loops, best of 1: 65.1 msec per loop 1 loops, best of 1: 64.2 msec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:40:52 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:40:52 +0000 Subject: [issue14111] IDLE Debugger should handle interrupts In-Reply-To: <1330112839.68.0.0096879566667.issue14111@psf.upfronthosting.co.za> Message-ID: <1442594452.99.0.765706110918.issue14111@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:41:09 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:41:09 +0000 Subject: [issue21973] Idle should not quit on corrupted user config files In-Reply-To: <1405252905.33.0.296703763462.issue21973@psf.upfronthosting.co.za> Message-ID: <1442594469.63.0.908720934499.issue21973@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:46:12 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:46:12 +0000 Subject: [issue24455] IDLE debugger causes crash if not quitted properly before next run In-Reply-To: <1434383850.99.0.136251358232.issue24455@psf.upfronthosting.co.za> Message-ID: <1442594772.25.0.147064067041.issue24455@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:46:41 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:46:41 +0000 Subject: [issue5594] IDLE startup configuration In-Reply-To: <1238311210.52.0.532490988344.issue5594@psf.upfronthosting.co.za> Message-ID: <1442594801.38.0.56133882686.issue5594@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:46:59 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:46:59 +0000 Subject: [issue20580] IDLE should support platform-specific default config defaults In-Reply-To: <1392027551.21.0.533992391985.issue20580@psf.upfronthosting.co.za> Message-ID: <1442594819.25.0.337007179316.issue20580@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:43:32 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:43:32 +0000 Subject: [issue22354] Idle: highlite tabs In-Reply-To: <1410095822.07.0.751550923398.issue22354@psf.upfronthosting.co.za> Message-ID: <1442594612.36.0.277924942054.issue22354@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:45:25 2015 From: report at bugs.python.org (Mark Roseman) Date: Fri, 18 Sep 2015 16:45:25 +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: <1442594725.13.0.778866877384.issue2704@psf.upfronthosting.co.za> Changes by Mark Roseman : ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:41:16 2015 From: report at bugs.python.org (tzickel) Date: Fri, 18 Sep 2015 16:41:16 +0000 Subject: [issue25083] Python can sometimes create incorrect .pyc files In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za> Message-ID: <1442594476.99.0.72643074534.issue25083@psf.upfronthosting.co.za> tzickel added the comment: Not sure why nobody has responded yet, but I have gone up and made a patch for the problem for 2.7 HEAD. Would be great if someone with more understanding of python's source could say if this is the optimal place to do the ferror test. I am able to see that this patch fixes the issue (now the import fails on EOF with an error instead of producing an empty valid AST and an empty code object .pyc file) Unfortunately testing that the patch fixes the issue, currently involves LD_PRELOADing an dynamic library which hooks __srget (because thats what the getc macro in Py_UniversalNewlineFgets uses in posix systems) to return EOF, and ferror to return a non zero result: If the code for the hooking dynamic library is needed, please tell me (I can't figure out how to make an automated test for it). ----- shell$ cat a.py print 'hi' Before fixing python: shell$ ls a.py* a.py shell$ DYLD_FORCE_FLAT_NAMESPACE=1 DYLD_INSERT_LIBRARIES=libblah.dylib python Python 2.7.10 (default, Jul 13 2015, 12:05:58) [GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.environ['BORK_IO_TEST'] = 'a' # this activates the EOF / ferror >>> import a # this should print 'hi' or fail but does not... >>> a >>> exit() shell$ ls a.py* a.py a.pyc You can see that it accepted a.py as an empty file and a bad a.pyc was created. After the patch: shell$ ls a.py* a.py shell$ DYLD_FORCE_FLAT_NAMESPACE=1 DYLD_INSERT_LIBRARIES=libblah.dylib ./python.exe Python 2.7.10+ (2.7:f6125114b55f+, Sep 18 2015, 19:18:34) [GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.72)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.environ['BORK_IO_TEST'] = 'a' >>> import a Traceback (most recent call last): File "", line 1, in File "a.py", line 1 ^ SyntaxError: unexpected EOF while parsing >>> a Traceback (most recent call last): File "", line 1, in NameError: name 'a' is not defined >>> exit() shell$ ls a.py* a.py Now the import failed, and of course no empty code .pyc file was created. ---------- keywords: +patch nosy: +benjamin.peterson Added file: http://bugs.python.org/file40505/ferror_check_in_tokenizer.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 18:59:24 2015 From: report at bugs.python.org (Bar Harel) Date: Fri, 18 Sep 2015 16:59:24 +0000 Subject: [issue25169] multiprocess documentation In-Reply-To: <1442588076.4.0.907099744388.issue25169@psf.upfronthosting.co.za> Message-ID: <1442595564.05.0.88347494919.issue25169@psf.upfronthosting.co.za> Bar Harel added the comment: Here's a quick minor patch to fix, works on a re-compiled doc. ---------- keywords: +patch nosy: +bar.harel Added file: http://bugs.python.org/file40506/multiprocessing_patch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 19:25:39 2015 From: report at bugs.python.org (Petr Prikryl) Date: Fri, 18 Sep 2015 17:25:39 +0000 Subject: [issue16322] time.tzname on Python 3.3.0 for Windows is decoded by wrong encoding In-Reply-To: <1351166210.69.0.0993824857313.issue16322@psf.upfronthosting.co.za> Message-ID: <1442597139.72.0.22732078752.issue16322@psf.upfronthosting.co.za> Petr Prikryl added the comment: I have just observed behaviour for the Czech locale. I tried to avoid collisions with stdout encoding, writing the strings into a file using UTF-8 encoding: tzname_bug.py -------------------------------------------------- #!python3 import time import sys with open('tzname_bug.txt', 'w', encoding='utf-8') as f: f.write(sys.version + '\n') f.write('Should be: St?edn? Evropa (b??n? ?as) | St?edn? Evropa (letn? ?as)\n') f.write('but it is: ' + time.tzname[0] + ' | ' + time.tzname[1] + '\n') f.write(' types: ' + repr(type(time.tzname[0])) + ' | ' + repr(type(time.tzname[1])) + '\n') f.write('Should be as ascii: ' + ascii('St?edn? Evropa (b??n? ?as) | St?edn? Evropa (letn? ?as)') + '\n') f.write('but it is as ascii: ' + ascii(time.tzname[0]) + ' | ' + ascii(time.tzname[1]) + '\n') ----------------------------------- It creates the tzname_bug.txt with the content (copy/pasted from UNICODE-capable editor (Notepad++, the indicator at the right bottom corner shows UTF-8. ----------------------------------- 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit (AMD64)] Should be: St?edn? Evropa (b??n? ?as) | St?edn? Evropa (letn? ?as) but it is: St?edn? Evropa (b??n? ?as) | St?edn? Evropa (letn? ?as) types: | Should be as ascii: 'St\u0159edn\xed Evropa (b\u011b\u017en\xfd \u010das) | St\u0159edn\xed Evropa (letn\xed \u010das)' but it is as ascii: 'St\xf8edn\xed Evropa (b\xec\x9en\xfd \xe8as)' | 'St\xf8edn\xed Evropa (letn\xed \xe8as)' ----------------------------------- ---------- nosy: +prikryl Added file: http://bugs.python.org/file40507/tzname_bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 19:26:32 2015 From: report at bugs.python.org (Bar Harel) Date: Fri, 18 Sep 2015 17:26:32 +0000 Subject: [issue25145] urllib how-to should be updated to remove PyGoogle In-Reply-To: <1442439158.29.0.495500663722.issue25145@psf.upfronthosting.co.za> Message-ID: <1442597192.51.0.0125720273564.issue25145@psf.upfronthosting.co.za> Bar Harel added the comment: A quick patch updating the mime and removing the mentioning of PyGoogle. We can add a different example in the future if we wish. ---------- keywords: +patch nosy: +bar.harel Added file: http://bugs.python.org/file40508/urllib_howto.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 19:32:16 2015 From: report at bugs.python.org (Bar Harel) Date: Fri, 18 Sep 2015 17:32:16 +0000 Subject: [issue25145] urllib how-to should be updated to remove PyGoogle In-Reply-To: <1442439158.29.0.495500663722.issue25145@psf.upfronthosting.co.za> Message-ID: <1442597536.74.0.888252502155.issue25145@psf.upfronthosting.co.za> Bar Harel added the comment: Added a similar patch to 2.7 ---------- Added file: http://bugs.python.org/file40509/urllib_howto27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 19:32:39 2015 From: report at bugs.python.org (Brendan Barnwell) Date: Fri, 18 Sep 2015 17:32:39 +0000 Subject: [issue16701] Docs missing the behavior of += (in-place add) for lists. In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za> Message-ID: <1442597559.55.0.0510389405166.issue16701@psf.upfronthosting.co.za> Brendan Barnwell added the comment: This needs to be fixed. The documentation for the behavior of += on lists needs to be with the documentation on lists. The existing, vague documentation that += works in-place "when possible" is insufficient. A central feature of Python is that the behavior of operators like + and += is overridable on a per-type basis. Hence, the Language Reference is not the appropriate place for describing the behavior of += on a particular type. The behavior of += on lists should be documented where the behavior of lists is documented (as, for instance, the behavior of + on lists already is), not where the syntax of += is documented. Someone just asked a question on StackOverflow about this (http://stackoverflow.com/questions/32657637/python-changing-variables-vs-arrays-in-functions/32657770#32657770). It is embarrassing to have to tell people, "To know what += does on a type, you need to look at the documentation for that type. . . except that the documentation for the builtin types doesn't document what some operators do." ---------- nosy: +BrenBarn _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 19:36:42 2015 From: report at bugs.python.org (Skip Montanaro) Date: Fri, 18 Sep 2015 17:36:42 +0000 Subject: [issue24324] Remove -Wunreachable-code flag In-Reply-To: <1432907477.51.0.798249204562.issue24324@psf.upfronthosting.co.za> Message-ID: <1442597802.85.0.590321226723.issue24324@psf.upfronthosting.co.za> Skip Montanaro added the comment: This seems to work for me. Diff against default. I have no idea how old the autoconf setup is here at work. I imagine you'll want to only apply the configure.ac patch and regenerate configure. ---------- keywords: +patch Added file: http://bugs.python.org/file40510/unreached.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 19:51:06 2015 From: report at bugs.python.org (Giampaolo Rodola') Date: Fri, 18 Sep 2015 17:51:06 +0000 Subject: [issue1103213] Adding a recvexactly() to socket.socket: receive exactly n bytes Message-ID: <1442598666.02.0.305480265662.issue1103213@psf.upfronthosting.co.za> Changes by Giampaolo Rodola' : ---------- nosy: +giampaolo.rodola _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 20:11:31 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 18 Sep 2015 18:11:31 +0000 Subject: [issue25021] product_setstate() Out-of-bounds Read In-Reply-To: <1441684502.22.0.0994334100718.issue25021@psf.upfronthosting.co.za> Message-ID: <1442599891.46.0.191460431136.issue25021@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 20:41:34 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 18 Sep 2015 18:41:34 +0000 Subject: [issue25170] 3.5.0 documentation archives missing Message-ID: <1442601694.39.0.291720811899.issue25170@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: Documentation archives for final 3.5.0 release are missing in https://www.python.org/ftp/python/doc/3.5.0/ (Compare it with e.g. https://www.python.org/ftp/python/doc/3.4.0/ and https://www.python.org/ftp/python/doc/3.4.3/) ---------- assignee: larry components: Documentation messages: 251018 nosy: Arfrever, larry priority: normal severity: normal status: open title: 3.5.0 documentation archives missing versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 20:44:10 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 18 Sep 2015 18:44:10 +0000 Subject: [issue25170] 3.5.0 documentation archives missing In-Reply-To: <1442601694.39.0.291720811899.issue25170@psf.upfronthosting.co.za> Message-ID: <1442601850.09.0.371871752406.issue25170@psf.upfronthosting.co.za> Larry Hastings added the comment: They don't go there, they go in https://docs.python.org/3.5/archives/ Where is the documentation that this "https://www.python.org/ftp/python/doc/3.5.0/" directory is an officially supported directory? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 20:52:49 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 18 Sep 2015 18:52:49 +0000 Subject: [issue25083] Python can sometimes create incorrect .pyc files In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za> Message-ID: <1442602369.35.0.520655933759.issue25083@psf.upfronthosting.co.za> Brett Cannon added the comment: I have not looked at your patch, tzickel, but I just wanted to let you know a lack of reply just means lack of time on the part of the core developers. We are all volunteers and essentially don't get paid to spend our time to work on Python. Add in the fact that this is an odd edge case issue on Python 2.7 and that lowers the priority for someone to get to it when there are more pressing issues related to the new 3.5.0 release. Hopefully someone who has a good understanding of the low-level C details you are talking about in your patch will be able to make a good judgment as to whether the test case and patch make sense. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 20:55:36 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 18 Sep 2015 18:55:36 +0000 Subject: [issue25154] Drop the pyvenv script In-Reply-To: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za> Message-ID: <1442602536.09.0.0201575149637.issue25154@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I have a patch which will at least improve the error message when `python3 -m venv` fails because python3-venv isn't installed on Debian/Ubuntu. I will work with Doko on this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 21:13:21 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Fri, 18 Sep 2015 19:13:21 +0000 Subject: [issue25170] 3.5.0 documentation archives missing In-Reply-To: <1442601694.39.0.291720811899.issue25170@psf.upfronthosting.co.za> Message-ID: <1442603601.61.0.905592268933.issue25170@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: https://www.python.org/ftp/python/doc/ contains documentation for all previous versions since Python 1.1, so https://www.python.org/ftp/python/doc/${Version} can be considered official. https://docs.python.org/${Version}/archives URL scheme is not working for majority of versions. E.g. there is no https://docs.python.org/3.3/archives/ Usage of https://www.python.org/ftp/ for documentation archives is also consistent with usage of it e.g. for source archives (e.g. https://www.python.org/ftp/python/3.5.0/Python-3.5.0.tar.xz). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 21:54:59 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Sep 2015 19:54:59 +0000 Subject: [issue25085] Windows x86-64 embeddable zip file contains test directorys In-Reply-To: <1442151945.16.0.782887699168.issue25085@psf.upfronthosting.co.za> Message-ID: <1442606099.37.0.448931902901.issue25085@psf.upfronthosting.co.za> Terry J. Reedy added the comment: tkinter\test and idlelib\idle_test are others. I presume all these directories are installed in a normal install even when "[] include tests" is left unchecked. There is one non-unittest file in idle_help, htest.py, that I would not want omitted, as I believe there may be reasons, especially in the future, for users to run it. I could move it up into idlelib itself. This is probably an anomaly, but it might be a good idea to check with maintainers of each package. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 22:37:49 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Sep 2015 20:37:49 +0000 Subject: [issue25103] 3.5.0 installed standard library on Windows has LF line endings In-Reply-To: <1442208824.41.0.568116526355.issue25103@psf.upfronthosting.co.za> Message-ID: <1442608669.91.0.574159943842.issue25103@psf.upfronthosting.co.za> Terry J. Reedy added the comment: AFAIK, Wordpad is also always available (has been at least up to Win 7), and it works with \n file and font resizing is obvious, but it is paper-oriented and for me, defaults to 8-1/2 x 11 with 1-1/4 side margins, leaving 6", too small for 80 char lines. The 'ruler' does not work to change page margins or spacing of existing text. One has to discover to go to / PageSetup to display as one needs to. On the other hand, Notepad uses the full width of the window, as sized. So I have to reluctantly call this a regression. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 22:57:18 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Sep 2015 20:57:18 +0000 Subject: [issue25109] test_code_module tests fail when run from the installed location In-Reply-To: <1442230011.36.0.482937736349.issue25109@psf.upfronthosting.co.za> Message-ID: <1442609838.93.0.213619768267.issue25109@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This is 3.5+ only as 2.7 does not have the module and 3.4 does not have the 2 test_xyz_tb functions that failed. This works OK on Win7. C:\Users\Terry>python -m test -v test_code_module == CPython 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit (AMD64)] == Windows-7-6.1.7601-SP1 little-endian == hash algorithm: siphash24 64bit == C:\Users\Terry\AppData\Local\Temp\test_python_4952 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_enviro nment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) [1/1] test_code_module test_banner (test.test_code_module.TestInteractiveConsole) ... ok test_cause_tb (test.test_code_module.TestInteractiveConsole) ... ok test_console_stderr (test.test_code_module.TestInteractiveConsole) ... ok test_context_tb (test.test_code_module.TestInteractiveConsole) ... ok test_ps1 (test.test_code_module.TestInteractiveConsole) ... ok test_ps2 (test.test_code_module.TestInteractiveConsole) ... ok test_syntax_error (test.test_code_module.TestInteractiveConsole) ... ok test_sysexcepthook (test.test_code_module.TestInteractiveConsole) ... ok What system did you use? (System dependence is odd, but there it is ;-) The obvious fix is to reduce 'expected' to the common part, and at least for the second test, split into 2 assertIns. ---------- nosy: +terry.reedy stage: -> needs patch type: -> behavior versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 23:00:25 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Sep 2015 21:00:25 +0000 Subject: [issue17756] test_syntax_error fails when run in the installed location In-Reply-To: <1366111959.84.0.955866306047.issue17756@psf.upfronthosting.co.za> Message-ID: <1442610025.06.0.360055058184.issue17756@psf.upfronthosting.co.za> Terry J. Reedy added the comment: In the absence of any further issue in over a year, can this be closed? ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 23:05:41 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Sep 2015 21:05:41 +0000 Subject: [issue17758] test_site fails when the user does not have a home directory In-Reply-To: <1366120279.38.0.306129828747.issue17758@psf.upfronthosting.co.za> Message-ID: <1442610341.93.0.753487217229.issue17758@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Unfixed for 2 years. How about skipping the test if os.makedirs(site.USER_SITE) fails? ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 23:06:33 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 18 Sep 2015 21:06:33 +0000 Subject: [issue25170] 3.5.0 documentation archives missing In-Reply-To: <1442601694.39.0.291720811899.issue25170@psf.upfronthosting.co.za> Message-ID: <1442610393.7.0.432610217144.issue25170@psf.upfronthosting.co.za> Larry Hastings added the comment: The official way to download the documentation is from this page: https://docs.python.org/3.5/download.html which links to the "archives" directory. When python.org changed to the new site, some things moved around. I guess this was one of those things. Anyway, there's no bug here. ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 23:14:23 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Sep 2015 21:14:23 +0000 Subject: [issue17773] test_pydoc fails with the installed testsuite (2.7) In-Reply-To: <1366195138.79.0.33949510354.issue17773@psf.upfronthosting.co.za> Message-ID: <1442610863.12.0.642736851864.issue17773@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Tests all pass on win7 with installed 2.7.10 (and 3.4.3 and 3.5.0). Is there a current failure on something else? ---------- nosy: +terry.reedy type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 23:43:38 2015 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 18 Sep 2015 21:43:38 +0000 Subject: [issue25103] 3.5.0 installed standard library on Windows has LF line endings In-Reply-To: <1442208824.41.0.568116526355.issue25103@psf.upfronthosting.co.za> Message-ID: <1442612618.84.0.278362218217.issue25103@psf.upfronthosting.co.za> Mark Lawrence added the comment: Windows 10 has Wordpad, I've never liked 'nice', as far as I'm concerned it's completely meaningless, and right now we've more important things to think about on Windows. Hence all in all to me this is a nothing issue. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 23:46:39 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Sep 2015 21:46:39 +0000 Subject: [issue21264] test_compileall fails to build in the installed location In-Reply-To: <1397674780.07.0.532661626869.issue21264@psf.upfronthosting.co.za> Message-ID: <1442612799.01.0.622294297321.issue21264@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Verified failure on installed 3.4.3, Win 7, with 3 rather than 1 error (all similar). test_no_args_compiles_path (test.test_compileall.CommandLineTests) ... FAIL test_no_args_respects_force_flag (test.test_compileall.CommandLineTests) ... FAIL test_no_args_respects_quiet_flag (test.test_compileall.CommandLineTests) ... FAIL test_pep3147_paths_doubleoptimize (test.test_compileall.CommandLineTests) ... ok First traceback ends with AssertionError: Process return code is 1, command line was: ['C:\\Programs\\Python34\\python.exe', '-X', 'faulthandler', '-S', '-m', 'compil eall'], stderr follows: followed by another ending with File "C:\Programs\Python34\lib\encodings\cp1252.py", line 19, in encode return codecs.charmap_encode(input,self.errors,encoding_table)[0] UnicodeEncodeError: 'charmap' codec can't encode character '\U00011111' in position 38: character maps to Why is an astral char in the error message? Will try patch. ---------- nosy: +terry.reedy type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Sep 18 23:58:30 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 18 Sep 2015 21:58:30 +0000 Subject: [issue25159] Import time regression In-Reply-To: <1442556606.15.0.522584302018.issue25159@psf.upfronthosting.co.za> Message-ID: <1442613510.56.0.563454114864.issue25159@psf.upfronthosting.co.za> Brett Cannon added the comment: It should also be mentioned that startup time from 3.4 to default has not been affected according to Intel's daily benchmark run which is usually the most obvious place you see import performance issues: normal_startup 0.63661% 0.39540% 0.45931% 5.22018% ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 00:11:38 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Sep 2015 22:11:38 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <20150918221132.81629.54469@psf.io> Roundup Robot added the comment: New changeset 0f4e6c303531 by Brett Cannon in branch '2.7': Issue #24915: Make PGO builds support Clang and use the test suite for https://hg.python.org/cpython/rev/0f4e6c303531 New changeset f211c8f554f9 by Brett Cannon in branch '2.7': Give proper credit for issue #24915 https://hg.python.org/cpython/rev/f211c8f554f9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 00:17:47 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Sep 2015 22:17:47 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <20150918221742.11692.61487@psf.io> Roundup Robot added the comment: New changeset 7fcff838d09e by Brett Cannon in branch '3.5': Issue #24915: Add Clang support to PGO builds and use the test suite https://hg.python.org/cpython/rev/7fcff838d09e New changeset 7749fc0a5ea6 by Brett Cannon in branch 'default': Merge for issue #24915 https://hg.python.org/cpython/rev/7749fc0a5ea6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 00:18:42 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 18 Sep 2015 22:18:42 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1442614722.9.0.960240024232.issue24915@psf.upfronthosting.co.za> Brett Cannon added the comment: Thanks to Alecsandru and Intel for the patches! ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 00:19:33 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 18 Sep 2015 22:19:33 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1442614773.05.0.186319438963.issue24915@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thank you Brett for committing this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 00:21:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 18 Sep 2015 22:21:33 +0000 Subject: [issue25133] Clarify that the constants in selectors are module-level In-Reply-To: <1442342084.77.0.0114888594817.issue25133@psf.upfronthosting.co.za> Message-ID: <20150918222128.11712.81909@psf.io> Roundup Robot added the comment: New changeset f03c074b6242 by Brett Cannon in branch 'default': Merge for issue #25133 https://hg.python.org/cpython/rev/f03c074b6242 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 00:22:08 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 18 Sep 2015 22:22:08 +0000 Subject: [issue25133] Clarify that the constants in selectors are module-level In-Reply-To: <1442342084.77.0.0114888594817.issue25133@psf.upfronthosting.co.za> Message-ID: <1442614928.26.0.126708744211.issue25133@psf.upfronthosting.co.za> Brett Cannon added the comment: Changeset 8054a9f788e7 has the 3.5 change. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 01:04:41 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Sep 2015 23:04:41 +0000 Subject: [issue21264] test_compileall fails to build in the installed location In-Reply-To: <1397674780.07.0.532661626869.issue21264@psf.upfronthosting.co.za> Message-ID: <1442617481.83.0.561160883198.issue21264@psf.upfronthosting.co.za> Terry J. Reedy added the comment: David, I am nosying you because this issue proposes to modify two test functions you added to test_compileall. See my prior message. -- For me, the test failed at every first occurrence of 'PYTHONPATH=' in the 3 functions. With one occurrence removed, the next in the same function failed. With all 6 removed, I get 1 error: FAIL: test_no_args_compiles_path (test.test_compileall.CommandLineTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Programs\Python34\lib\test\test_compileall.py", line 179, in test_no_args_compiles_path self.assertNotCompiled(self.initfn) File "C:\Programs\Python34\lib\test\test_compileall.py", line 159, in assertNotCompiled self.assertFalse(os.path.exists(path)) AssertionError: True is not false The tests all pass in current uninstalled 3.4.3+ repository. If I remove all 6, I get the error above. Changing how the directory is passed apparently changes what get compiled. From the title of the test ad the comment "# Note that -l is implied for the no args case.", this is expected and is the point of the test. So deleting 'PYTHONPATH=' must be wrong. I believe we should detect that modifying the environment will not work before calling assertRunOK and skip the latter if it cannot work. The other two functions were added in #19532 by RDM. I think we need to know why they were written as they are before changing them. Perhaps they pass with 'PYTHONPATH=' removed because they are incomplete. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 01:16:15 2015 From: report at bugs.python.org (Remi Pointel) Date: Fri, 18 Sep 2015 23:16:15 +0000 Subject: [issue25171] does not build on OpenBSD with no value defined for PY_GETENTROPY Message-ID: <1442618175.28.0.599214895418.issue25171@psf.upfronthosting.co.za> New submission from Remi Pointel: Hi, I'm trying to build Python on OpenBSD-current, but it does not build because it seems that PY_GETENTROPY does not have a value. $ make ... gcc -pthread -c -fno-strict-aliasing -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -O2 -pipe -Werror=declaration-after-statement -I. -IInclude -I./Include -DPy_BUILD_CORE -o Python/random.o Python/random.c Python/random.c:367:20: error: #if with no expression Python/random.c: In function '_PyOS_URandom': Python/random.c:370: warning: implicit declaration of function 'dev_urandom_python' Python/random.c:414:20: error: #if with no expression Python/random.c: In function '_PyRandom_Init': Python/random.c:417: warning: implicit declaration of function 'dev_urandom_noraise' Python/random.c:430:20: error: #if with no expression Python/random.c: In function '_PyRandom_Fini': Python/random.c:433: warning: implicit declaration of function 'dev_urandom_close' *** Error 1 in /home/remi/dev/cpython (Makefile:1534 'Python/random.o') If I defined the PY_GETENTROPY to the value "1" line 76, it seems to works fine. Remi. ---------- files: Python_random_c messages: 251040 nosy: rpointel priority: normal severity: normal status: open title: does not build on OpenBSD with no value defined for PY_GETENTROPY versions: Python 3.6 Added file: http://bugs.python.org/file40511/Python_random_c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 01:19:22 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Sep 2015 23:19:22 +0000 Subject: [issue25131] The AST for dict and set displays has the lineno of the first value In-Reply-To: <1442341705.94.0.0242549644551.issue25131@psf.upfronthosting.co.za> Message-ID: <1442618362.27.0.454454818109.issue25131@psf.upfronthosting.co.za> Terry J. Reedy added the comment: A fix should include a new ast test, such as self.assertEqual(parse("{\n1:2}").body[0].value.lineno, 1) I verified that the equivalent assert passes on 3.4.3, fails on 3.5.0. ---------- nosy: +terry.reedy stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 01:35:44 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Sep 2015 23:35:44 +0000 Subject: [issue25139] Just a little refactoring In-Reply-To: <1442395563.59.0.192959239996.issue25139@psf.upfronthosting.co.za> Message-ID: <1442619344.73.0.758440534605.issue25139@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I believe this is equivalent. In general, bare excepts should be either made more specific or commented as intentional. Since derived classes can override finish_request, and fail any which way, the latter is probably appropriate here: # derived classes may override finish_request ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 01:42:48 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Sep 2015 23:42:48 +0000 Subject: [issue25157] Installing Python 3.5.0 32bit on Windows 8.1 64bit system gives Error 0x80240017 In-Reply-To: <1442526643.4.0.412457342038.issue25157@psf.upfronthosting.co.za> Message-ID: <1442619768.44.0.802652870353.issue25157@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Uploads are not limited to patches. Please attach such long text files instead of pasting. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 01:57:12 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 18 Sep 2015 23:57:12 +0000 Subject: [issue25158] Python 3.2.2 and 3.5.0 Do not seem compatible with OpenSSL 1.0.2d on Solaris 10 In-Reply-To: <1442538684.06.0.30749904186.issue25158@psf.upfronthosting.co.za> Message-ID: <1442620632.69.0.964026443773.issue25158@psf.upfronthosting.co.za> Terry J. Reedy added the comment: If you are concerned about security and compiling 3.2.2, I would expect you should use the latest release, 3.2.6, with several fixes including security fixes. There should be one more security release in early 2016. I believe 3.5.0 has 1.0.2c. I don't know our policy on supporting new versions, or exactly who handles ssl updates. ---------- nosy: +dstufft, georg.brandl, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 02:28:09 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 19 Sep 2015 00:28:09 +0000 Subject: [issue25159] Regression in time to import a module In-Reply-To: <1442556606.15.0.522584302018.issue25159@psf.upfronthosting.co.za> Message-ID: <1442622489.6.0.146075823428.issue25159@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Clarify title; regression is not in 'import time'. I am working on timing the import of Lib/*.py on windows. I already discovered that unix-only crypt is present on windows (but should not be). ---------- nosy: +terry.reedy title: Import time regression -> Regression in time to import a module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 02:49:31 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 19 Sep 2015 00:49:31 +0000 Subject: [issue25172] Unix-only crypt should not be present on Windows. Message-ID: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za> New submission from Terry J. Reedy: Except for crypt, all the modules labeled 'Unix' or 'Linux' on the module index https://docs.python.org/3/py-modindex.html are absent from /Lib on Windows. 'import xyz' fails with "ImportError: no module named 'zyz'". (I presume the same is true on unix for Windows-only modules.) However, crypt is present, and 'import crypt' fails with "...'_crypt'", leading one to think that the C accelerator should be present but is not. Assuming that _crypt should (cannot) not be present, please add crypt to the list of modules omitted from the Windows installer, however this is done. And if 'unix-only' is obsolete and _crypt should be present, please fix this instead. ;-) This is 3.x issue only, as crypt is not present in my Windows 2.7.10 /Lib. The fact that is was somehow added to some 3.x prompted me to look and see if there is anything useful without _crypt present. I think not. ---------- components: Library (Lib), Windows messages: 251046 nosy: jafo, paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware priority: normal severity: normal status: open title: Unix-only crypt should not be present on Windows. versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 04:04:56 2015 From: report at bugs.python.org (John Mark Vandenberg) Date: Sat, 19 Sep 2015 02:04:56 +0000 Subject: [issue19003] email.generator.BytesGenerator corrupts data by changing line endings In-Reply-To: <1378885640.45.0.020973506597.issue19003@psf.upfronthosting.co.za> Message-ID: <1442628296.82.0.465283257569.issue19003@psf.upfronthosting.co.za> Changes by John Mark Vandenberg : ---------- nosy: +John.Mark.Vandenberg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 04:09:11 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 19 Sep 2015 02:09:11 +0000 Subject: [issue25161] Missing periods at the end of sentences In-Reply-To: <1442560890.27.0.253223646248.issue25161@psf.upfronthosting.co.za> Message-ID: <1442628551.01.0.846822531194.issue25161@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 04:10:03 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 19 Sep 2015 02:10:03 +0000 Subject: [issue25169] multiprocess documentation In-Reply-To: <1442588076.4.0.907099744388.issue25169@psf.upfronthosting.co.za> Message-ID: <1442628603.41.0.866246126974.issue25169@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 04:20:05 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 19 Sep 2015 02:20:05 +0000 Subject: [issue24199] Idle: remove idlelib.idlever.py and its use in About dialog In-Reply-To: <1431650285.59.0.600694723613.issue24199@psf.upfronthosting.co.za> Message-ID: <1442629205.44.0.0809257890824.issue24199@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I get it now: the last line should be 'import idlelib.idlever' instead of the redundant line from idlever itself. Will change, and thanks for correcting this before I so the same in multiple other modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 04:26:48 2015 From: report at bugs.python.org (Mark Roseman) Date: Sat, 19 Sep 2015 02:26:48 +0000 Subject: [issue25173] IDLE - several common dialogs don't have correct parent set Message-ID: <1442629608.18.0.497476300551.issue25173@psf.upfronthosting.co.za> New submission from Mark Roseman: The confirmation, file, etc. common dialogs in tkinter accept both a 'master' and a 'parent' argument. Master is not required (it will use parent if not provided). Parent is used to associate the dialog with a given window. On Mac OS X, using parent further turns this into a 'sheet' attached to that window. Most places in IDLE we're correctly using parent, but there are several places that master is provided, but not parent, e.g. IOBinding.py. This is most noticeable doing a 'do you want to save before closing...' where now it is not attached to the window on Mac, but it should be. Need to go through the code, every place the common dialogs are used and check if master/parent are being used correctly. ---------- components: IDLE messages: 251048 nosy: kbk, markroseman, roger.serwy, terry.reedy priority: normal severity: normal status: open title: IDLE - several common dialogs don't have correct parent set versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 04:45:58 2015 From: report at bugs.python.org (Jared Bevis) Date: Sat, 19 Sep 2015 02:45:58 +0000 Subject: [issue25174] Backspace Escape Character at End of String Message-ID: <1442630758.17.0.869659981248.issue25174@psf.upfronthosting.co.za> New submission from Jared Bevis: I'm a new python learner but I noticed inconsistent behavior of the backspace character when used in strings. I'm running 2.7.10. Whenever the backspace character '\b' is at the very end of a string, nothing happens, but if it is in the middle of string it behaves as expected. For example: print "12345" + '\b' returns: >>>12345 But: print "12345" + '\b' + '6' returns: >>> 12346 ---------- components: Regular Expressions messages: 251049 nosy: Jared Bevis, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: Backspace Escape Character at End of String type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 05:56:21 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 19 Sep 2015 03:56:21 +0000 Subject: [issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x) In-Reply-To: <1442151642.39.0.456899707142.issue25084@psf.upfronthosting.co.za> Message-ID: <1442634981.66.0.635120161048.issue25084@psf.upfronthosting.co.za> Nick Coghlan added the comment: The consistency issue I was referring to related to the "timeout" argument - we currently have a patch applied to Fedora (and derivatives) that instead adds a "balanced=True" flag argument so you can pass "polling=False" to turn off the busy loop (at the risk of a long wake-up delay). This means the current situation we have in Fedora (et al) is: * Python 2 only code can pass "balanced=False" (but probably wouldn't want to due to the potential increase in wake-up latency) * Python 3 only code can specify a timeout directly * Single source Python 2/3 code can't do either (since the API signatures are different) So downstream I'll be advocating in favour of Flavio's pthread patch regardless of what we do upstream - that way hybrid Python 2/3 code that's specific to the Fedora derived ecosystem (and we have a lot of that in the operating system layer) can eventually be updated to use threading timeouts while remaining consistent between Fedora (which is switching the system Python to Python 3) and RHEL/CentOS 7 (which will continue to use Python 2.7). For upstream, I think it would be desirable to backport the timeout argument and simply have it throw RuntimeError if used with any of the backends other than thread_nt and thread_pthread. That way single source Python 2/3 code gains access to the timeout option, while code relying on one of the no-longer-available-in-Python-3 threading backends doesn't incur any stability risks. However, I don't feel strongly enough about that to argue in favour of it against opposition - I'm happy enough to confine my argument to changing the downstream Fedora/RHEL/CentOS patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 06:00:34 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 19 Sep 2015 04:00:34 +0000 Subject: [issue25174] Backspace Escape Character at End of String In-Reply-To: <1442630758.17.0.869659981248.issue25174@psf.upfronthosting.co.za> Message-ID: <1442635234.0.0.491843898602.issue25174@psf.upfronthosting.co.za> Martin Panter added the comment: Python itself doesn?t treat backspace specially. What you are probably seeing is the terminal interpreting the backspace specially by moving the cursor left (without erasing anything). >>> s = "12345" + '\b' + '6' >>> s '12345\x086' >>> s[5] # ASCII code for backspace is 0x08 '\x08' If you redirect the output to a file or other program, you will also see the backspace code is still there: $ python2 -c 'print "12345" + "\b" + "6"' | hexdump -C 00000000 31 32 33 34 35 08 36 0a |12345.6.| 00000008 ---------- components: -Regular Expressions nosy: +martin.panter resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 07:29:52 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 19 Sep 2015 05:29:52 +0000 Subject: [issue25173] IDLE - several common dialogs don't have correct parent set In-Reply-To: <1442629608.18.0.497476300551.issue25173@psf.upfronthosting.co.za> Message-ID: <1442640591.99.0.101949585039.issue25173@psf.upfronthosting.co.za> Terry J. Reedy added the comment: General comments on 'master' versus 'parent': This seems to be a matter of confusion in tkinterland. When I have asked before about the difference, all I have gotten is that they are more or less the same. http://effbot.org/tkinterbook/entry.htm, for instance, used 'parent' and 'master' interchangeably in the text, says the signature is 'master=None', copying the docstring, and then says "*master*\n\tParent widget". Thinking "Ah, they are the same thing" is quite easy after reading this. A widely recommended reference, http://infohost.nmt.edu/tcc/help/pubs/tkinter/web/index.html, which has otherwise been very helpful to me, documents widgets as having a required 'parent'. (I don't blame it for avoid the complication of a default Tk().) But Widget(parent=root) and Widget(master=root) are not normally the same. But simple tests may not obviously show a difference, because 'master=None' really means 'master= terry.reedy stage: -> needs patch type: -> behavior versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 08:02:44 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 19 Sep 2015 06:02:44 +0000 Subject: [issue21259] replace "except: pass" by "except Exception: pass" In-Reply-To: <1397671015.92.0.0555120458036.issue21259@psf.upfronthosting.co.za> Message-ID: <1442642564.78.0.206349687715.issue21259@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- superseder: -> Fix bare excepts in various places in std lib _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 08:02:56 2015 From: report at bugs.python.org (Mark Mikofski) Date: Sat, 19 Sep 2015 06:02:56 +0000 Subject: [issue25112] Windows installer assigns non-existent icons to Python file types In-Reply-To: <1442253725.07.0.74818964148.issue25112@psf.upfronthosting.co.za> Message-ID: <1442642576.64.0.160406126165.issue25112@psf.upfronthosting.co.za> Mark Mikofski added the comment: +1 I just wasted at least an hour on this. :( should have checked bugs first. Google says nothing, so I thought I was going crazy. I saw that py.exe had only one icon and that Python.File had c:\windows\py.exe, 1 while Python.CompiledFile had C:\windows\py.exe, 2, so I thought that might be it, but I just wasn't sure. Are the Py2 and Py3 icons exactly the same? if so, then IMO just use the py.ico and pyc.ico icons in the DLLs folder as suggested ---------- nosy: +bwanamarko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 08:23:26 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 19 Sep 2015 06:23:26 +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: <1442643806.44.0.420590277754.issue17319@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- Removed message: http://bugs.python.org/msg227645 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 08:23:43 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 19 Sep 2015 06:23:43 +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: <1442643823.03.0.423430734659.issue17319@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- Removed message: http://bugs.python.org/msg227647 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 08:28:46 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 19 Sep 2015 06:28:46 +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: <1442644126.54.0.433410052831.issue17319@psf.upfronthosting.co.za> Martin Panter added the comment: The proposed patch changes the code to 500 if the code is invalid (rather than raising an exception as I initially assumed). I would be inclined to leave send_response() without any extra error checking or handling, unless this is a common problem and there is a real need for it. Although I reckon it might be nice to have a generic (higher-level) exception handler for the HTTP server that responds with ?500 Internal server error? if possible. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 08:36:24 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 19 Sep 2015 06:36:24 +0000 Subject: [issue21259] replace "except: pass" by "except Exception: pass" In-Reply-To: <1397671015.92.0.0555120458036.issue21259@psf.upfronthosting.co.za> Message-ID: <1442644584.24.0.761619274592.issue21259@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > I presume you do not mind if I reclose this. Thanks, please do reclose this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 08:44:25 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 19 Sep 2015 06:44:25 +0000 Subject: [issue25161] Missing periods at the end of sentences In-Reply-To: <1442560890.27.0.253223646248.issue25161@psf.upfronthosting.co.za> Message-ID: <1442645065.97.0.901573860566.issue25161@psf.upfronthosting.co.za> Martin Panter added the comment: All the changes in the non-2.7 patch look reasonable to me. I left two review comments suggesting a few extra minor edits. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 08:44:40 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 19 Sep 2015 06:44:40 +0000 Subject: [issue25159] Regression in time to import a module In-Reply-To: <1442556606.15.0.522584302018.issue25159@psf.upfronthosting.co.za> Message-ID: <1442645080.94.0.354680409805.issue25159@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I did not find any significant different between 3.4 and 3.5 on Windows running the following: import os, time from importlib import import_module files = os.listdir("C:/Programs/Python34/Lib") excludes = {'antigravity.py', 'compileall.py', 'crypt.py', 'pty.py', 'this.py', 'tty.py', '__phello__.foo.py'} start = time.monotonic() for name in files: if name.endswith('.py') and name not in excludes: try: import_module(name[:-3]) except: print(name) print(time.monotonic()-start) Other than a couple of outliers, the time was consintly about .29 seconds with both 3.4 and 3.5: F:\Python\dev>py -3.x c:/programs/python34/tem.py The 3.5 run is a bit odd since it runs both 3.4 code and 3.5 code, but there were no extra exceptions once I added the needed exclusions (pyt and tty are also unix only) for 3.4. The same code runs equally faster with Idle (.17 seconds), but that must be because Idle has already imported so many more /Lib modules (not including idlelib/*) than python itself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 08:44:47 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 19 Sep 2015 06:44:47 +0000 Subject: [issue25161] Missing periods at the end of sentences In-Reply-To: <1442560890.27.0.253223646248.issue25161@psf.upfronthosting.co.za> Message-ID: <1442645087.38.0.270715548315.issue25161@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 08:47:13 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 19 Sep 2015 06:47:13 +0000 Subject: [issue25139] socketserver.ThreadingMixIn exception handler: Just a little refactoring In-Reply-To: <1442395563.59.0.192959239996.issue25139@psf.upfronthosting.co.za> Message-ID: <1442645233.57.0.950599793119.issue25139@psf.upfronthosting.co.za> Martin Panter added the comment: I suggest changing the ?except? clause to ?except BaseException?, which would make the intention clearer. As an alternative, see also my Issue 23430, were I proposed not catching exceptions like KeyboardInterrupt and SystemExit, by changing this to: try: self.finish_request(request, client_address) except Exception: self.handle_error(request, client_address) finally: self.shutdown_request(request) ---------- nosy: +martin.panter title: Just a little refactoring -> socketserver.ThreadingMixIn exception handler: Just a little refactoring _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 09:01:20 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 19 Sep 2015 07:01:20 +0000 Subject: [issue25138] test_socket: socket.EAI_NODATA doesn't exist on FreeBSD In-Reply-To: <1442386365.65.0.414098178984.issue25138@psf.upfronthosting.co.za> Message-ID: <1442646080.64.0.19453552245.issue25138@psf.upfronthosting.co.za> Martin Panter added the comment: Maybe it is good enough use something like this as a workaround, with an appropriate comment: if e.errno == getattr(socket, "EAI_NODATA", None): # Symbol not defined on FreeBSD However I wonder if it would be reasonable to set this constant (and similar undefined error codes) to a dummy value like None by default in the module. The documentation already says ?for a few symbols, default values are provided?. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 09:03:37 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 19 Sep 2015 07:03:37 +0000 Subject: [issue25138] test_socket: socket.EAI_NODATA doesn't exist on FreeBSD In-Reply-To: <1442386365.65.0.414098178984.issue25138@psf.upfronthosting.co.za> Message-ID: <1442646217.8.0.913736907586.issue25138@psf.upfronthosting.co.za> Martin Panter added the comment: Actually, None is probably a bad default, since gaierror().errno also defaults to None. Maybe choose some other unlikely non-integer object instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 09:55:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 19 Sep 2015 07:55:46 +0000 Subject: [issue25101] test_zipfile failure when run by unprivileged user with installed Python In-Reply-To: <1442206445.71.0.486177418249.issue25101@psf.upfronthosting.co.za> Message-ID: <1442649346.5.0.0255676279758.issue25101@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 10:00:56 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 19 Sep 2015 08:00:56 +0000 Subject: [issue25101] test_zipfile failure when run by unprivileged user with installed Python In-Reply-To: <1442206445.71.0.486177418249.issue25101@psf.upfronthosting.co.za> Message-ID: <20150919080052.3642.88584@psf.io> Roundup Robot added the comment: New changeset 80d002edc9c1 by Serhiy Storchaka in branch '3.4': Issue #25101: Try to create a file to test write access in test_zipfile. https://hg.python.org/cpython/rev/80d002edc9c1 New changeset fe84898fbe98 by Serhiy Storchaka in branch '2.7': Issue #25101: Try to create a file to test write access in test_zipfile. https://hg.python.org/cpython/rev/fe84898fbe98 New changeset 6899bf8d21c3 by Serhiy Storchaka in branch '3.5': Issue #25101: Try to create a file to test write access in test_zipfile. https://hg.python.org/cpython/rev/6899bf8d21c3 New changeset 399746fde4f8 by Serhiy Storchaka in branch 'default': Issue #25101: Try to create a file to test write access in test_zipfile. https://hg.python.org/cpython/rev/399746fde4f8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 10:01:08 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 19 Sep 2015 08:01:08 +0000 Subject: [issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x) In-Reply-To: <1442151642.39.0.456899707142.issue25084@psf.upfronthosting.co.za> Message-ID: <1442649668.87.0.992101366794.issue25084@psf.upfronthosting.co.za> STINNER Victor added the comment: About the new optional balanced parameter added downstream to Fedora, the patch is very small compared to timedlock.patch. It only changes the Python code, not the C code: --- /home/haypo/prog/python/2.7/Lib/threading.py 2014-11-05 15:05:11.432003853 +0100 +++ /usr/lib64/python2.7/threading.py 2015-07-05 16:16:00.000000000 +0200 @@ -306,7 +306,7 @@ else: return True - def wait(self, timeout=None): + def wait(self, timeout=None, balancing=True): """Wait until notified or until a timeout occurs. If the calling thread has not acquired the lock when this method is @@ -355,7 +355,10 @@ remaining = endtime - _time() if remaining <= 0: break - delay = min(delay * 2, remaining, .05) + if balancing: + delay = min(delay * 2, remaining, 0.05) + else: + delay = remaining _sleep(delay) if not gotit: if __debug__: (with some additional changes to pass balanced parameter) Compare: $ diffstat balanced.patch threading.py | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) $ diffstat timedlock.patch Doc/library/thread.rst | 31 ++++++++++--- Doc/library/threading.rst | 32 +++++++++++++- Include/pythread.h | 37 ++++++++++++++++ Lib/dummy_thread.py | 8 +++ Lib/multiprocessing/pool.py | 6 +- Lib/test/lock_tests.py | 44 +++++++++++++++++-- Lib/threading.py | 25 +++-------- Modules/threadmodule.c | 53 +++++++++++++++++++---- Python/thread_nt.h | 33 +++++++++++--- Python/thread_pthread.h | 98 +++++++++++++++++++++++++++++++++++--------- 10 files changed, 296 insertions(+), 71 deletions(-) Do you know if the balanced parameter is used in the wild? Such code only works with Python 2 on Fedora/CentOS/RHEL, right? "For upstream, I think it would be desirable to backport the timeout argument and simply have it throw RuntimeError if used with any of the backends other than thread_nt and thread_pthread." It's not how Python handles portability. There are two choices in Python: * some functions are only available on some platforms, ex: os.fork() * the feature is supported by all platforms and Python uses a different implementation depending on the platform (ex: os.kill) Raising RuntimeError depending on the platform is not a good practice. "That way single source Python 2/3 code gains access to the timeout option, while code relying on one of the no-longer-available-in-Python-3 threading backends doesn't incur any stability risks." This issue is about the performance of Condition.wait(). The timeout parameter already exists on Python 2 in Condition.wait(). So it's already possible to write a single code base compatible with Python 2 and Python 3. If you are talking about adding e *new* timeout parameter to threading.Lock, it's a new feature. Usually, we don't add new features in minor releases. It makes maintenace more complex: you cannot guarantee anymore that an application written for Python 2.7.x will work on Python 2.7.y. If you really want this, I consider that a PEP is required to define exactly the scope of such change. "However, I don't feel strongly enough about that to argue in favour of it against opposition - I'm happy enough to confine my argument to changing the downstream Fedora/RHEL/CentOS patch." For this specific change (optimizing Condition.wait(timeout) using OS timeout), it makes sense to have a downstream only patch because the change will be specific to Linux. Well, I'm not strongly opposed to optimize Python 2, but since the patch is not portable, if you really want it, I consider that the topic should be discussed on python-dev to have a wide audience. ---------- Added file: http://bugs.python.org/file40512/balanced.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 10:02:19 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 19 Sep 2015 08:02:19 +0000 Subject: [issue25138] test_socket: socket.EAI_NODATA doesn't exist on FreeBSD In-Reply-To: <1442386365.65.0.414098178984.issue25138@psf.upfronthosting.co.za> Message-ID: <1442649739.28.0.215933264897.issue25138@psf.upfronthosting.co.za> STINNER Victor added the comment: It would be better to catch the FreeBSD error code when the hostname is not known. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 10:05:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 19 Sep 2015 08:05:16 +0000 Subject: [issue25101] test_zipfile failure when run by unprivileged user with installed Python In-Reply-To: <1442206445.71.0.486177418249.issue25101@psf.upfronthosting.co.za> Message-ID: <1442649916.25.0.0600032457177.issue25101@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 10:10:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 19 Sep 2015 08:10:00 +0000 Subject: [issue25011] Smarter rl complete: hide private and special names In-Reply-To: <1441488567.65.0.369817501077.issue25011@psf.upfronthosting.co.za> Message-ID: <1442650200.47.0.770806806749.issue25011@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: If no one has objections, I'll commit the patch. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 10:14:15 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 19 Sep 2015 08:14:15 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1442650455.97.0.520085349143.issue24915@psf.upfronthosting.co.za> STINNER Victor added the comment: Hum, the change 7fcff838d09e broke the buildbot "AMD64 Debian PGO 3.5". It would nice to add Clang support without loosing GCC support :-D http://buildbot.python.org/all/builders/AMD64%20Debian%20PGO%203.5/builds/274 ---------- nosy: +haypo resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 10:31:43 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 19 Sep 2015 08:31:43 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1442651503.98.0.342250624292.issue24999@psf.upfronthosting.co.za> STINNER Victor added the comment: pylong_digits.patch: new patch add two local inlined functions _PyLong_AsDigits() and _PyLong_FromDigits() to make the code more readable. Does it look good to you? I chose two shifts since only Tim Peters has an opinion on it, and he prefers two shifts :-) ---------- Added file: http://bugs.python.org/file40513/pylong_digits.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 10:44:47 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 19 Sep 2015 08:44:47 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1442652287.43.0.854525494115.issue24999@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This variant look overcomplicated to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 11:34:48 2015 From: report at bugs.python.org (eryksun) Date: Sat, 19 Sep 2015 09:34:48 +0000 Subject: [issue16322] time.tzname on Python 3.3.0 for Windows is decoded by wrong encoding In-Reply-To: <1351166210.69.0.0993824857313.issue16322@psf.upfronthosting.co.za> Message-ID: <1442655288.94.0.331617908978.issue16322@psf.upfronthosting.co.za> eryksun added the comment: To decode the tzname strings, Python calls mbstowcs, which on Windows uses Latin-1 in the "C" locale. However, in this locale the tzname strings are actually encoded using the system ANSI codepage (e.g. 1250 for Central/Eastern Europe). So it ends up decoding ANSI strings as Latin-1 mojibake. For example: >>> s 'St?edn? Evropa (b??n? ?as) | St?edn? Evropa (letn? ?as)' >>> s.encode('1250').decode('latin-1') 'St?edn? Evropa (b?\x9en? ?as) | St?edn? Evropa (letn? ?as)' You can work around the inconsistency by calling setlocale(LC_ALL, "") before anything imports the time module. This should set a locale that's not "C", in which case the codepage should be consistent. Of course, this won't help if you can't control when the time module is first imported. The latter wouldn't be a issue if time.tzset were implemented on Windows. You can at least use ctypes to call the CRT's _tzset function. This solves the problem with time.strftime('%Z'). You can also get the CRT's tzname by calling the exported __tzname function. Here's a Python 3.5 example that sets the current thread to use Russian and creates a new tzname tuple: import ctypes import locale kernel32 = ctypes.WinDLL('kernel32') ucrtbase = ctypes.CDLL('ucrtbase') MUI_LANGUAGE_NAME = 8 kernel32.SetThreadPreferredUILanguages(MUI_LANGUAGE_NAME, 'ru-RU\0', None) locale.setlocale(locale.LC_ALL, 'ru-RU') # reset tzname in current locale ucrtbase._tzset() ucrtbase.__tzname.restype = ctypes.POINTER(ctypes.c_char_p * 2) c_tzname = ucrtbase.__tzname()[0] tzname = tuple(tz.decode('1251') for tz in c_tzname) # print Cyrillic characters to the console kernel32.SetConsoleOutputCP(1251) stdout = open(1, 'w', buffering=1, encoding='1251', closefd=0) >>> print(tzname, file=stdout) ('????? ? ??????? UTC', '????? ? ??????? UTC') ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 12:00:05 2015 From: report at bugs.python.org (Flavio Grossi) Date: Sat, 19 Sep 2015 10:00:05 +0000 Subject: [issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x) In-Reply-To: <1442151642.39.0.456899707142.issue25084@psf.upfronthosting.co.za> Message-ID: <1442656805.36.0.353393507984.issue25084@psf.upfronthosting.co.za> Flavio Grossi added the comment: > About the new optional balanced parameter added downstream to Fedora, the patch is very small compared to timedlock.patch. It only changes the Python code, not the C code The balancing fix has 3 main problems imo: - It causes long delays to receive the notification (i.e. with a timeout of 30s the caller may be notified after 30s in the worst case) - It doesn't apply to other affected APIs, e.g. Queue.get() which uses a condition internally. - It only fixes the problem in python programs which explicitly use it (and being redhat specific i guess it is not very used) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 12:01:04 2015 From: report at bugs.python.org (Rishit Bansal) Date: Sat, 19 Sep 2015 10:01:04 +0000 Subject: [issue25175] Documentation-Tkinter wrong statement Message-ID: <1442656864.32.0.801468754438.issue25175@psf.upfronthosting.co.za> New submission from Rishit Bansal: The statement required to check whether Tkinter is installed on a system is mentioned in the documentation as python -m tkinter , whereas it is supposed to be python -m Tkinter (with a big 't'). Please correct this error on the documentation here:https://docs.python.org/3/library/tkinter.html as it is very misleading to beginners. ---------- assignee: docs at python components: Documentation messages: 251070 nosy: Rishit Bansal, docs at python priority: normal severity: normal status: open title: Documentation-Tkinter wrong statement type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 12:14:47 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 19 Sep 2015 10:14:47 +0000 Subject: [issue25175] Documentation-Tkinter wrong statement In-Reply-To: <1442656864.32.0.801468754438.issue25175@psf.upfronthosting.co.za> Message-ID: <1442657687.69.0.338426357275.issue25175@psf.upfronthosting.co.za> Martin Panter added the comment: The problem here is you have quoted the Python 3 documentation (see in the title, or the version switcher at the top), when you are presumably using Python 2. The module changed name to lowercase in Python 3. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 12:17:02 2015 From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=) Date: Sat, 19 Sep 2015 10:17:02 +0000 Subject: [issue25176] Link to urllib.parse.parse_qsl, not parse_qs, from cgi.parse_qsl doc Message-ID: <1442657822.78.0.00192788068763.issue25176@psf.upfronthosting.co.za> New submission from Ville Skytt?: The docs for cgi.parse_qsl should link to urllib.parse.parse_qsl instead of urllib.parse.parse_qs, patch attached. ---------- assignee: docs at python components: Documentation files: cgi.parse_qsl.doc.patch keywords: patch messages: 251072 nosy: docs at python, scop priority: normal severity: normal status: open title: Link to urllib.parse.parse_qsl, not parse_qs, from cgi.parse_qsl doc type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file40514/cgi.parse_qsl.doc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 12:49:42 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 19 Sep 2015 10:49:42 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442659782.17.0.525887844968.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: I changed the generated code to call: format(x [, spec]) instead of: x.__format__(spec) The reason is that the correct way to call __format__ is actually: type(x).__format__(x, spec) That is, the __format__ lookup is done on the type, not the instance. From the earlier example, the disassembled code is now: >>> dis.dis("f'a={a}'") 1 0 LOAD_CONST 0 ('') 3 LOAD_ATTR 0 (join) 6 LOAD_CONST 1 ('a=') 9 LOAD_GLOBAL 1 (format) 12 LOAD_NAME 2 (a) 15 CALL_FUNCTION 1 (1 positional, 0 keyword pair) 18 BUILD_LIST 2 21 CALL_FUNCTION 1 (1 positional, 0 keyword pair) 24 RETURN_VALUE The simplest way to make the lookup correctly is just to call format() itself, which does the right thing. I still have a concept of adding opcodes to handle FormattedValue and JoinedStr nodes, but that's an optimization for later, if ever. ---------- Added file: http://bugs.python.org/file40515/pep-498-10.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 13:34:42 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 19 Sep 2015 11:34:42 +0000 Subject: [issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x) In-Reply-To: <1442656805.36.0.353393507984.issue25084@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: "The balancing fix has 3 main problems imo:" Oh by the way, I don't want to apply it to Python 2.7 upstream for a similar reason: it's a new feature which would be added to a Python 2.7 minor version. We try to avoid that, even if Python 2.7 is special. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 13:39:02 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Sep 2015 11:39:02 +0000 Subject: [issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x) In-Reply-To: <1442151642.39.0.456899707142.issue25084@psf.upfronthosting.co.za> Message-ID: <1442662742.05.0.267270121624.issue25084@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, let's close it then. ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 13:40:40 2015 From: report at bugs.python.org (David MacIver) Date: Sat, 19 Sep 2015 11:40:40 +0000 Subject: [issue25177] OverflowError in statistics.mean when summing large floats Message-ID: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za> New submission from David MacIver: The following code produces an OverflowError: import statistics statistics.mean([8.988465674311579e+307, 8.98846567431158e+307]) The error is: File "/home/david/.pyenv/versions/3.5.0/lib/python3.5/statistics.py", line 293, in mean return _sum(data)/n File "/home/david/.pyenv/versions/3.5.0/lib/python3.5/statistics.py", line 184, in _sum return T(total) File "/home/david/.pyenv/versions/3.5.0/lib/python3.5/numbers.py", line 291, in __float__ return self.numerator / self.denominator OverflowError: integer division result too large for a float If this is intended behaviour then it is not documented: https://docs.python.org/3/library/statistics.html#statistics.mean only specifies that it may raise StatisticsError. ---------- components: Library (Lib) messages: 251076 nosy: David MacIver priority: normal severity: normal status: open title: OverflowError in statistics.mean when summing large floats versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 13:41:11 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 19 Sep 2015 11:41:11 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <20150919114108.82646.77188@psf.io> Roundup Robot added the comment: New changeset 21076e24cd8a by Victor Stinner in branch '3.5': Issue #24999: In longobject.c, use two shifts instead of ">> 2*PyLong_SHIFT" to https://hg.python.org/cpython/rev/21076e24cd8a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 13:43:29 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 19 Sep 2015 11:43:29 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1442663009.75.0.508990011584.issue24999@psf.upfronthosting.co.za> STINNER Victor added the comment: > This variant look overcomplicated to me. Ok fine. I pushed pylong_digits.patch, but I also modified a similar code a few lines below. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 14:09:04 2015 From: report at bugs.python.org (Jakub Wilk) Date: Sat, 19 Sep 2015 12:09:04 +0000 Subject: [issue9253] argparse: optional subparsers In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za> Message-ID: <1442664544.65.0.403016756512.issue9253@psf.upfronthosting.co.za> Changes by Jakub Wilk : ---------- nosy: +jwilk _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 14:09:31 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 19 Sep 2015 12:09:31 +0000 Subject: [issue25177] OverflowError in statistics.mean when summing large floats In-Reply-To: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za> Message-ID: <1442664571.37.0.720206540723.issue25177@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 15:08:40 2015 From: report at bugs.python.org (Carol Willing) Date: Sat, 19 Sep 2015 13:08:40 +0000 Subject: [issue25175] Documentation-Tkinter Clarify module spelling change in Python 3 docs In-Reply-To: <1442656864.32.0.801468754438.issue25175@psf.upfronthosting.co.za> Message-ID: <1442668120.97.0.769525267797.issue25175@psf.upfronthosting.co.za> Carol Willing added the comment: Although the documentation for Python 3 and Python 2 is correct as Martin shared, adding a note about capitalization in the Python 3 docs would be helpful for beginners for two reasons: 1) the name of the Tkinter project does start with a capital 'T' and 2) the python module name changed from Python 2 to 3. Adding a note that the spelling of the module changed in version 3 to 'tkinter' from version 2's 'Tkinter' would be helpful for new users (especially since Tkinter is often used in educational applications). I have updated the issue title, issue type, stage, and keywords to reflect that this issue is not a documentation error but a helpful, user friendly documentation enhancement. ---------- keywords: +easy nosy: +willingc stage: -> needs patch title: Documentation-Tkinter wrong statement -> Documentation-Tkinter Clarify module spelling change in Python 3 docs type: compile error -> enhancement versions: +Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 15:23:21 2015 From: report at bugs.python.org (Bar Harel) Date: Sat, 19 Sep 2015 13:23:21 +0000 Subject: [issue25177] OverflowError in statistics.mean when summing large floats In-Reply-To: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za> Message-ID: <1442669001.54.0.513485246346.issue25177@psf.upfronthosting.co.za> Bar Harel added the comment: I believe it's an intended behavior as python's float has a limit after all. It's hard to reach it but definitely possible. A workaround is to internally use Decimal (also take the advantage that it's implementation is now way faster) but it will cause a precision loss, and somewhat unexpected behavior. Last thing we can do is catch that OverflowError and raise StatisticsError from exc. I believe catching and re-raising as Statistics or just writing that it may also cause an Overflow error are the most viable ways. Either way, I'd like another opinion before implementing either method as a patch. ---------- nosy: +bar.harel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 15:58:54 2015 From: report at bugs.python.org (David MacIver) Date: Sat, 19 Sep 2015 13:58:54 +0000 Subject: [issue25177] OverflowError in statistics.mean when summing large floats In-Reply-To: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za> Message-ID: <1442671134.19.0.649793467403.issue25177@psf.upfronthosting.co.za> David MacIver added the comment: I'm not sure what you mean by float having a limit here. It's certainly finite precision, but there is still a representable value with that finite precision closest to the mean. As an example where there is an obvious correct answer that will trigger this error: statistics.mean([sys.float_info.max, sys.float_info.max]), this should return sys.float_info.max (which is definitely representable!), but instead raises this overflow error. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 16:59:07 2015 From: report at bugs.python.org (Donald Stufft) Date: Sat, 19 Sep 2015 14:59:07 +0000 Subject: [issue22559] [backport] ssl.MemoryBIO In-Reply-To: <1412540756.02.0.793381062078.issue22559@psf.upfronthosting.co.za> Message-ID: <1442674747.15.0.388799284185.issue22559@psf.upfronthosting.co.za> Donald Stufft added the comment: Now that 3.5 is out, does that mean we can sync 2.7 with the 3.5 ssl again and land this patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 17:00:16 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Sat, 19 Sep 2015 15:00:16 +0000 Subject: [issue12885] distutils.filelist.findall() fails on broken symlink in Py2.x In-Reply-To: <1314971843.03.0.797964996491.issue12885@psf.upfronthosting.co.za> Message-ID: <1442674816.61.0.550890248514.issue12885@psf.upfronthosting.co.za> Jason R. Coombs added the comment: Although the code was ported from setuptools, it wasn't ported from the long stable implementation, but was ported following the recent refactor, which had a [regression](https://bitbucket.org/pypa/setuptools/issues/425/odd-failure-on-183-missing-files-but-they) revealing that the [docstring no longer matched the implementation](https://bitbucket.org/pypa/setuptools/commits/72ec36bea07c7dd1cf48e20894864e8a4e1b480f). The latest implementation provides [a more elegant approach](https://bitbucket.org/pypa/setuptools/src/738b139f3016a05084c9f34c6364d7d20b3aac9d/setuptools/__init__.py?fileviewer=file-view-default#__init__.py-154), but continues to maintain the expectation of the setuptools implementation. I still need to address Eric's question about what filelists are affected, but also now update the patch to ensure that the disparity between findall('.') and findall(anything_else) is captured. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 17:08:45 2015 From: report at bugs.python.org (Bar Harel) Date: Sat, 19 Sep 2015 15:08:45 +0000 Subject: [issue25177] OverflowError in statistics.mean when summing large floats In-Reply-To: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za> Message-ID: <1442675325.32.0.978351904792.issue25177@psf.upfronthosting.co.za> Bar Harel added the comment: Whoop! I see the reason for it now. By limit I don't mean the precision limit, I mean the top limit in which float converts to "inf". Seems like this bug is due to the change of python 3's division operator. Under numbers it states: "It's important that this conversion use the integer's "true" division rather than casting one side to float before dividing so that ratios of huge integers convert without overflowing." It is meant to not to overflow but the "/" operator is now "//". Lemme patch it up and see if it fixes the problem. If it states the integer's "true" division, I believe this small fix will be sufficient as it has been tested before. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 17:25:32 2015 From: report at bugs.python.org (Bar Harel) Date: Sat, 19 Sep 2015 15:25:32 +0000 Subject: [issue25177] OverflowError in statistics.mean when summing large floats In-Reply-To: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za> Message-ID: <1442676332.15.0.321543136812.issue25177@psf.upfronthosting.co.za> Bar Harel added the comment: Yup, it indeed fixes the problem. Sorry for thinking it's intended. Seems like it's a small problem but it does affects all the uses of Integral or Rational. I'll test it with the suite hoping it has a sufficient coverage. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 17:29:43 2015 From: report at bugs.python.org (Mark Roseman) Date: Sat, 19 Sep 2015 15:29:43 +0000 Subject: [issue25173] IDLE - several common dialogs don't have correct parent set In-Reply-To: <1442629608.18.0.497476300551.issue25173@psf.upfronthosting.co.za> Message-ID: <1442676583.8.0.939427049461.issue25173@psf.upfronthosting.co.za> Mark Roseman added the comment: No comment on state of Tkinter documentation. ;-) I'll have a go through the uses of 'master' in IDLE and see which others should be changed, and put together a patch. Plus double-check with all the other dialogs in lib/tkinter to see if there are any other gotchas to be aware of. The 'detail' option appears to be 8.5 only, added in 2004 (http://www.tcl.tk/cgi-bin/tct/tip/152.html). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 17:51:44 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Sep 2015 15:51:44 +0000 Subject: [issue22559] [backport] ssl.MemoryBIO In-Reply-To: <1412540756.02.0.793381062078.issue22559@psf.upfronthosting.co.za> Message-ID: <1442677904.34.0.720720263071.issue22559@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I don't know or remember what the whole PEP says. In doubt, I suggest floating it by python-dev to get a more informed answer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 18:11:48 2015 From: report at bugs.python.org (Bar Harel) Date: Sat, 19 Sep 2015 16:11:48 +0000 Subject: [issue25177] OverflowError in statistics.mean when summing large floats In-Reply-To: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za> Message-ID: <1442679108.14.0.552744966858.issue25177@psf.upfronthosting.co.za> Bar Harel added the comment: Alright, Seems like the problem is bigger than I thought. PEP 238 (https://www.python.org/dev/peps/pep-0238/) mentions that problem. Using the new division, // will cause a floor while / will cause an OverflowError. An ugly way around it involves type checking or reverting back to the classic division. ---------- nosy: +benjamin.peterson, mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 18:22:03 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Sat, 19 Sep 2015 16:22:03 +0000 Subject: [issue12885] distutils.filelist.findall() fails on broken symlink in Py2.x In-Reply-To: <1314971843.03.0.797964996491.issue12885@psf.upfronthosting.co.za> Message-ID: <1442679723.44.0.69120024421.issue12885@psf.upfronthosting.co.za> Changes by Jason R. Coombs : Added file: http://bugs.python.org/file40516/3da42b593e1f.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 18:28:47 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Sat, 19 Sep 2015 16:28:47 +0000 Subject: [issue12885] distutils.filelist.findall() fails on broken symlink in Py2.x In-Reply-To: <1314971843.03.0.797964996491.issue12885@psf.upfronthosting.co.za> Message-ID: <1442680127.91.0.266385838849.issue12885@psf.upfronthosting.co.za> Jason R. Coombs added the comment: After porting the latest released Setuptools version, I discovered yet another regression in the Setuptools implementation, specifically around its handling for this issue, so I've created yet another release of Setuptools (18.3.2) to include tests and fixes for the expected behavior on this issue. Rebasing those changes, the patch 3da42b593e1f now reflects my latest proposal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 20:18:45 2015 From: report at bugs.python.org (Brett Cannon) Date: Sat, 19 Sep 2015 18:18:45 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1442686725.59.0.941329720738.issue24915@psf.upfronthosting.co.za> Brett Cannon added the comment: It didn't break gcc, the buildbot simply wasn't patient enough for the PGO run of the test suite to complete: http://buildbot.python.org/all/builders/AMD64%20Debian%20PGO%203.5/builds/274/steps/compile/logs/stdio . It takes a good amount of time to run the test suite serially with an instrumented interpreter and 20 minutes is not enough time. And I don't want to add output back simply to appease the buildbot as the output means nothing to a user who is doing the build themselves. So either that buildbot needs to allow for a longer time without output, someone needs to come up with a way to simply emit some output that simply shows stuff is running (but without letting error condition stuff show up), or the buildbot just won't work with PGO. ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 20:20:20 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Sep 2015 18:20:20 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1442686725.59.0.941329720738.issue24915@psf.upfronthosting.co.za> Message-ID: <55FDA761.1060800@free.fr> Antoine Pitrou added the comment: Le 19/09/2015 20:18, Brett Cannon a ?crit : > > And I don't want to add output back simply to appease the buildbot as the output means nothing to a user who is doing the build themselves. The output is actually a good indication of progress, so I don't think it's not as silly to add it back as you seem to think it is :-) ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 20:23:30 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 19 Sep 2015 18:23:30 +0000 Subject: [issue16701] Docs missing the behavior of += (in-place add) for lists. In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za> Message-ID: <1442687010.78.0.843993810305.issue16701@psf.upfronthosting.co.za> R. David Murray added the comment: I suggested updating the library reference in my first reply on this issue. No one has proposed a patch yet, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 20:30:16 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 19 Sep 2015 18:30:16 +0000 Subject: [issue25170] 3.5.0 documentation archives missing In-Reply-To: <1442601694.39.0.291720811899.issue25170@psf.upfronthosting.co.za> Message-ID: <1442687416.0.0.853742559008.issue25170@psf.upfronthosting.co.za> R. David Murray added the comment: I'm not sure there's no bug here, though there certainly doesn't seem to be any bug in your execution of the release process. I think we should ask Georg's opinion at least. ---------- nosy: +georg.brandl, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 20:32:35 2015 From: report at bugs.python.org (Mark Roseman) Date: Sat, 19 Sep 2015 18:32:35 +0000 Subject: [issue25173] IDLE - several common dialogs don't have correct parent set In-Reply-To: <1442629608.18.0.497476300551.issue25173@psf.upfronthosting.co.za> Message-ID: <1442687555.27.0.15714726692.issue25173@psf.upfronthosting.co.za> Mark Roseman added the comment: I think both master and parent are needed, for the likely rare case when you don't want a dialog attached to any window, but it needs a Tk window handle to build the dialog from. Ran across that in SearchEngine, which has a root window just for the purpose of creating dialogs, but the search engine doesn't know what search dialog is invoking it (a bad example, as in this case, the dialogs should be the ones display the error, not the search engine). Anyway, have attached masterparent.patch for default branch which updates those message and file dialogs that make sense to use parent instead of master. ---------- keywords: +patch Added file: http://bugs.python.org/file40517/masterparent.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 20:33:00 2015 From: report at bugs.python.org (Mark Roseman) Date: Sat, 19 Sep 2015 18:33:00 +0000 Subject: [issue25173] IDLE - several common dialogs don't have correct parent set In-Reply-To: <1442629608.18.0.497476300551.issue25173@psf.upfronthosting.co.za> Message-ID: <1442687580.2.0.876167125637.issue25173@psf.upfronthosting.co.za> Mark Roseman added the comment: Attached masterparent27.patch, same thing for 2.7 branch ---------- Added file: http://bugs.python.org/file40518/masterparent27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 20:34:05 2015 From: report at bugs.python.org (Brett Cannon) Date: Sat, 19 Sep 2015 18:34:05 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1442687645.87.0.21807371708.issue24915@psf.upfronthosting.co.za> Brett Cannon added the comment: The problem with the output is that error cases are unimportant and yet it fooled Skip into temporarily caring until he finally noticed the warning message. So my worry is that someone doesn't notice the "NOTE: ignore errors as they don't affect anything" and then glances at the output to notice an error and then worries that their PGO run failed. It people really want to add output back in, though, they will need to patch both the Makefile to have a big NOTE in it as well as the README to say that any errors during the test suite run are unimportant and do not affect the outcome of the profile-guided optimizations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 20:34:41 2015 From: report at bugs.python.org (Mark Roseman) Date: Sat, 19 Sep 2015 18:34:41 +0000 Subject: [issue25178] IDLE: search regex errors should be in/attached to search dialog Message-ID: <1442687681.31.0.813309084762.issue25178@psf.upfronthosting.co.za> New submission from Mark Roseman: Follow-on to #25173, any regex errors are displayed by SearchEngine but they should be shown by the dialog where the user is typing the error. Either as a modal tkMessageBox attached to the dialog, or as an inline error in the dialog itself. ---------- components: IDLE messages: 251097 nosy: kbk, markroseman, roger.serwy, terry.reedy priority: normal severity: normal status: open title: IDLE: search regex errors should be in/attached to search dialog type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 20:34:55 2015 From: report at bugs.python.org (Petr Prikryl) Date: Sat, 19 Sep 2015 18:34:55 +0000 Subject: [issue16322] time.tzname on Python 3.3.0 for Windows is decoded by wrong encoding In-Reply-To: <1351166210.69.0.0993824857313.issue16322@psf.upfronthosting.co.za> Message-ID: <1442687695.57.0.898543521385.issue16322@psf.upfronthosting.co.za> Petr Prikryl added the comment: I have worked around a bit differently -- the snippet from the code: result = time.tzname[0] # simplified version of the original code. # Because of the bug in Windows libraries, Python 3.3 tried to work around # some issues. However, the shit hit the fan, and the bug bubbled here. # The `time.tzname` elements are (unicode) strings; however, they were # filled with bad content. See https://bugs.python.org/issue16322 for details. # Actually, wrong characters were passed instead of the good ones. # This code should be skipped later by versions of Python that will fix # the issue. import platform if platform.system() == 'Windows': # The concrete example for Czech locale: # - cp1250 (windows-1250) is used as native encoding # - the time.tzname[0] should start with 'St?edn? Evropa' # - the ascii('St?edn? Evropa') should return "'St\u0159edn\xed Evropa'" # - because of the bug it returns "'St\xf8edn\xed Evropa'" # # The '?' character has unicode code point `\u0159` (that is hex) # and the `\xF8` code in cp1250. The `\xF8` was wrongly used # as a Unicode code point `\u00F8` -- this is for the Unicode # character '?' that is observed in the string. # # To fix it, the `result` string must be reinterpreted with a different # encoding. When working with Python 3 strings, it can probably # done only through the string representation and `eval()`. Here # the `eval()` is not very dangerous because the string was obtained # from the OS library, and the values are limited to certain subset. # # The `ascii()` literal is prefixed by `binary` type prefix character, # `eval`uated, and the binary result is decoded to the correct string. local_encoding = locale.getdefaultlocale()[1] b = eval('b' + ascii(result)) result = b.decode(local_encoding) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 20:41:00 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 19 Sep 2015 18:41:00 +0000 Subject: [issue24999] Segfault in test_re.test_sre_character_class_literals() when Python is compiled by ICC In-Reply-To: <1441362190.45.0.409936717424.issue24999@psf.upfronthosting.co.za> Message-ID: <1442688060.63.0.417766216451.issue24999@psf.upfronthosting.co.za> Changes by Mark Dickinson : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 20:45:03 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 19 Sep 2015 18:45:03 +0000 Subject: [issue21264] test_compileall fails to build in the installed location In-Reply-To: <1397674780.07.0.532661626869.issue21264@psf.upfronthosting.co.za> Message-ID: <1442688303.32.0.767621461553.issue21264@psf.upfronthosting.co.za> R. David Murray added the comment: Yes the point is to test compilation of the path. If I run python3 -m compilelall on my installed python, it works fine (zero return code). I can't really investigate this further right now, but it isn't obvious to me what the answer is from the information in the issue so far, except that it doesn't *look* like it should be necessary to skip the tests unless the installation directories are read only *and* the .pyc files in them are non-existent or out of date. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 20:52:03 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 19 Sep 2015 18:52:03 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <20150919185200.9943.37380@psf.io> Roundup Robot added the comment: New changeset a10d37f04569 by Eric V. Smith in branch 'default': Issue #24965: Implement PEP 498 "Literal String Interpolation". Documentation is still needed, I'll open an issue for that. https://hg.python.org/cpython/rev/a10d37f04569 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 20:55:18 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 19 Sep 2015 18:55:18 +0000 Subject: [issue25179] PEP 498 f-strings need to be documented Message-ID: <1442688918.61.0.173837832796.issue25179@psf.upfronthosting.co.za> New submission from Eric V. Smith: Issue 24965 add f-strings (see PEP 498). They need to be documented. ---------- assignee: docs at python components: Documentation messages: 251101 nosy: docs at python, eric.smith priority: normal severity: normal stage: needs patch status: open title: PEP 498 f-strings need to be documented versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 20:57:44 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 19 Sep 2015 18:57:44 +0000 Subject: [issue24965] Implement PEP 498: Literal String Formatting In-Reply-To: <1440956820.84.0.785923951406.issue24965@psf.upfronthosting.co.za> Message-ID: <1442689064.36.0.108990385312.issue24965@psf.upfronthosting.co.za> Eric V. Smith added the comment: Documentation task added as issue #25179. Thanks to Martin for the great code reviews. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 20:58:01 2015 From: report at bugs.python.org (Bar Harel) Date: Sat, 19 Sep 2015 18:58:01 +0000 Subject: [issue25177] OverflowError in statistics.mean when summing large floats In-Reply-To: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za> Message-ID: <1442689081.67.0.0965303522939.issue25177@psf.upfronthosting.co.za> Bar Harel added the comment: Seems like this is the only viable option. It fixes the OverflowError but comes at the cost of precision and time. Another option would be to try/except the overflow error and only then return the slower method. Regarding the data [8.988465674311579e+307, 8.98846567431158e+307], float has lesser precision than other types like Decimal so the patched method would return 8.98846567431158e+307. A dataset to test the fix is [8.99e+307, 8.989e+307] which gives a correct result. ---------- keywords: +patch Added file: http://bugs.python.org/file40519/issue25177.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 20:58:56 2015 From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=) Date: Sat, 19 Sep 2015 18:58:56 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1442689136.47.0.609237951263.issue23883@psf.upfronthosting.co.za> Jacek Ko?odziej added the comment: Does anyone have strong preference towards one of the propositions above? TestCase subclass looks reasonable IMHO, but I'd not add that to the scope of this issue (I'd be happy to implement it later, though). Any suggestions? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 21:08:34 2015 From: report at bugs.python.org (Georg Brandl) Date: Sat, 19 Sep 2015 19:08:34 +0000 Subject: [issue25170] 3.5.0 documentation archives missing In-Reply-To: <1442601694.39.0.291720811899.issue25170@psf.upfronthosting.co.za> Message-ID: <1442689714.75.0.605998750954.issue25170@psf.upfronthosting.co.za> Georg Brandl added the comment: This is still in PEP 101: ___ If this is a final release: Move the doc zips and tarballs to /srv/www.python.org/ftp/python/doc/X.Y.Z, creating the directory if necessary, and adapt the "current" symlink in .../doc to point to that directory. Note though that if you're releasing a maintenance release for an older version, don't change the current link. https://docs.python.org/3.5/archives/ will have the *continuously rebuilt* versions, so it's not the same. ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 21:17:23 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 19 Sep 2015 19:17:23 +0000 Subject: [issue25180] Tools/parser/unparse.py needs to be updated for f-strings Message-ID: <1442690243.97.0.917526078175.issue25180@psf.upfronthosting.co.za> New submission from Eric V. Smith: test_unparse.py occasionally fails if it picks a module that uses f-strings. ---------- assignee: eric.smith keywords: easy messages: 251106 nosy: eric.smith priority: normal severity: normal stage: needs patch status: open title: Tools/parser/unparse.py needs to be updated for f-strings type: behavior versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 21:21:31 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 19 Sep 2015 19:21:31 +0000 Subject: [issue25180] Tools/parser/unparse.py needs to be updated for f-strings In-Reply-To: <1442690243.97.0.917526078175.issue25180@psf.upfronthosting.co.za> Message-ID: <1442690491.23.0.997197415106.issue25180@psf.upfronthosting.co.za> Eric V. Smith added the comment: And it always fails with "-u cpu", which the buildbots use. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 21:29:15 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sat, 19 Sep 2015 19:29:15 +0000 Subject: [issue25177] OverflowError in statistics.mean when summing large floats In-Reply-To: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za> Message-ID: <1442690955.44.0.771600760834.issue25177@psf.upfronthosting.co.za> Mark Dickinson added the comment: That patch doesn't really help, I'm afraid, since it introduces problems at the other end of the floating-point range: for example, `mean([5e-324, 5e-324])` would give `0.0` with that patch (instead of the `5e-324` it currently gives). So currently, when computing the mean of a sequence of floats (possibly mixed with ints), the code: 1. Computes the sum as a Fraction. 2. Converts that Fraction to a float. 3. Divides the result by the number of elements. Reversing steps 2 and 3 here would solve the issue, but would require some refactoring. It's really up to Steven whether he thinks that that refactoring is worth it for these corner cases at the extremes of the floating-point range. (It's difficult to imagine that such numbers would turn up frequently in practical applications.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 21:34:47 2015 From: report at bugs.python.org (Bar Harel) Date: Sat, 19 Sep 2015 19:34:47 +0000 Subject: [issue25175] Documentation-Tkinter Clarify module spelling change in Python 3 docs In-Reply-To: <1442656864.32.0.801468754438.issue25175@psf.upfronthosting.co.za> Message-ID: <1442691287.91.0.372452639656.issue25175@psf.upfronthosting.co.za> Bar Harel added the comment: Is this good? :-) ---------- keywords: +patch nosy: +bar.harel Added file: http://bugs.python.org/file40520/Issue25175.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 21:43:23 2015 From: report at bugs.python.org (Skip Montanaro) Date: Sat, 19 Sep 2015 19:43:23 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1442687645.87.0.21807371708.issue24915@psf.upfronthosting.co.za> Message-ID: Skip Montanaro added the comment: Would it be possible to grep out the warning messages, but let everything else through? On Sep 19, 2015 1:34 PM, "Brett Cannon" wrote: > > Brett Cannon added the comment: > > The problem with the output is that error cases are unimportant and yet it > fooled Skip into temporarily caring until he finally noticed the warning > message. So my worry is that someone doesn't notice the "NOTE: ignore > errors as they don't affect anything" and then glances at the output to > notice an error and then worries that their PGO run failed. > > It people really want to add output back in, though, they will need to > patch both the Makefile to have a big NOTE in it as well as the README to > say that any errors during the test suite run are unimportant and do not > affect the outcome of the profile-guided optimizations. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 21:50:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 19 Sep 2015 19:50:12 +0000 Subject: [issue25180] Tools/parser/unparse.py needs to be updated for f-strings In-Reply-To: <1442690243.97.0.917526078175.issue25180@psf.upfronthosting.co.za> Message-ID: <20150919195008.3656.48312@psf.io> Roundup Robot added the comment: New changeset 37d3b95a289b by Eric V. Smith in branch 'default': Temporary hack for issue #25180: exclude test_fstring.py from the unparse round-tripping, while I figure out how to properly fix it. https://hg.python.org/cpython/rev/37d3b95a289b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 21:50:12 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Sat, 19 Sep 2015 19:50:12 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1442692212.83.0.705338740036.issue24915@psf.upfronthosting.co.za> Alecsandru Patrascu added the comment: Thank you for upstreaming this in both branches of Python! Do you think that a different version of regrtest.py, that will be used only for PGO training, should be better in this case? I mean, by implementing a custom version, I think we can control better the output and errors shown on screen. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 22:21:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 19 Sep 2015 20:21:35 +0000 Subject: [issue25181] Tests failed in nondecodable directory Message-ID: <1442694095.16.0.133026836681.issue25181@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: A number of tests are failed or skipped when run in directory with a name that contains non-decodable characters. Attached output of following command: ./python -m test.regrtest -uall -v test_cgitb test_cmd_line test_gdb test_inspect test_multiprocessin_fork test_multiprocessing_forkserver test_multiprocessing_spawn test_pdb test_pydoc test_pyexpat test_sax test_site test_subprocess test_tk test_venv test_xml_etree test_xml_etree_c test_logging just hangs. Locale is en_US.utf8. ---------- components: Tests files: tests.log messages: 251113 nosy: serhiy.storchaka priority: normal severity: normal status: open title: Tests failed in nondecodable directory type: behavior versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40521/tests.log _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 22:37:10 2015 From: report at bugs.python.org (Optimal BPM) Date: Sat, 19 Sep 2015 20:37:10 +0000 Subject: [issue25079] Tokenize generates NL instead of NEWLINE for comments In-Reply-To: <1442051359.49.0.451935650182.issue25079@psf.upfronthosting.co.za> Message-ID: <1442695030.59.0.419698792893.issue25079@psf.upfronthosting.co.za> Optimal BPM added the comment: OK. But just to make me understand, would that explain why an else statement gets its DEDENT before the else, instead of before an dedented comment just before it? Even if the comment is visually dedented as the else? Example where tokenize returns the DEDENT in a separate place than where it is visually: if a=b: statement # Comment else: other statement In the above case, the DEDENT is reportet before the else, instead of before the comment. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 22:48:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 19 Sep 2015 20:48:46 +0000 Subject: [issue25182] python -v crashes in nonencodable directory Message-ID: <1442695726.04.0.992972651572.issue25182@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: $ pwd /home/serhiy/py/cpy?thon-3.5 $ ./python -v import _frozen_importlib # frozen import _imp # builtin import sys # builtin import '_warnings' # import '_thread' # import '_weakref' # import '_frozen_importlib_external' # import '_io' # import 'marshal' # import 'posix' # import _thread # previously loaded ('_thread') import '_thread' # import _weakref # previously loaded ('_weakref') import '_weakref' # # installing zipimport hook import 'zipimport' # # installed zipimport hook Fatal Python error: Py_Initialize: Unable to get the locale encoding Traceback (most recent call last): File "", line 969, in _find_and_load # destroy io File "", line 958, in _find_and_load_unlocked # destroy io File "", line 673, in _load_unlocked # destroy io File "", line 658, in exec_module # destroy io File "", line 759, in get_code # destroy io File "", line 368, in _verbose_message # destroy io UnicodeEncodeError: 'utf-8' codec can't encode character '\udcff' in position 21: surrogates not allowed # destroy encodings Aborted (core dumped) ---------- messages: 251115 nosy: brett.cannon, eric.snow, ncoghlan, serhiy.storchaka priority: normal severity: normal status: open title: python -v crashes in nonencodable directory type: crash versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 22:57:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 19 Sep 2015 20:57:40 +0000 Subject: [issue25183] python -m inspect --details fails in nondecodable directory Message-ID: <1442696260.6.0.26315436798.issue25183@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: $ pwd /home/serhiy/py/cpy?thon-3.5 $ ./python -m inspect --details unittest Target: unittest Traceback (most recent call last): File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/inspect.py", line 3050, in _main() File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/inspect.py", line 3030, in _main print('Origin: {}'.format(getsourcefile(module))) UnicodeEncodeError: 'utf-8' codec can't encode character '\udcff' in position 27: surrogates not allowed ---------- components: Library (Lib) messages: 251116 nosy: serhiy.storchaka, yselivanov priority: normal severity: normal status: open title: python -m inspect --details fails in nondecodable directory type: behavior versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 23:07:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 19 Sep 2015 21:07:25 +0000 Subject: [issue25184] "python -m pydoc -w" fails in nondecodable directory Message-ID: <1442696845.13.0.851195404942.issue25184@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: $ pwd /home/serhiy/py/cpy?thon-3.5 $ ./python -m pydoc -w pydoc Traceback (most recent call last): File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/pydoc.py", line 2648, in cli() File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/pydoc.py", line 2611, in cli writedoc(arg) File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/pydoc.py", line 1642, in writedoc page = html.page(describe(object), html.document(object, name)) File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/pydoc.py", line 370, in document if inspect.ismodule(object): return self.docmodule(*args) File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/pydoc.py", line 651, in docmodule url = urllib.parse.quote(path) File "/home/serhiy/py/cpy\udcffthon-3.5/Lib/urllib/parse.py", line 706, in quote string = string.encode(encoding, errors) UnicodeEncodeError: 'utf-8' codec can't encode character '\udcff' in position 19: surrogates not allowed ---------- components: Library (Lib) messages: 251117 nosy: orsenthil, serhiy.storchaka priority: normal severity: normal status: open title: "python -m pydoc -w" fails in nondecodable directory type: behavior versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 23:13:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 19 Sep 2015 21:13:23 +0000 Subject: [issue25181] Tests failed in nondecodable directory In-Reply-To: <1442694095.16.0.133026836681.issue25181@psf.upfronthosting.co.za> Message-ID: <1442697203.76.0.840165762481.issue25181@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +"python -m pydoc -w" fails in nondecodable directory, python -m inspect --details fails in nondecodable directory, python -v crashes in nonencodable directory _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 23:14:44 2015 From: report at bugs.python.org (Mark Roseman) Date: Sat, 19 Sep 2015 21:14:44 +0000 Subject: [issue25146] IDLE debugger could better visualize program execution In-Reply-To: <1442440221.76.0.764553903841.issue25146@psf.upfronthosting.co.za> Message-ID: <1442697284.84.0.502907077651.issue25146@psf.upfronthosting.co.za> Mark Roseman added the comment: Regarding the nested loops, what's happening is: - IDLE tells interpreter to run program - Interpreter now has control and is running program, start to end - Because execution is being traced, before every statement we get a callback If we didn't use the nested loop and just returned back immediately after we're called, the program would go onto the next statement, and the next one, etc. (it's in control). Instead, we block to force the program to wait until we do something, at which point it continues to the next statement, after possibly modifying the conditions under which the execution traces fire. If instead, we tell the execution tracing to actually stop on every statement (rather than running through start to end), we'll get a callback for each statement (to update our display), but can decide to stay stopped, or immediately continue on, based on whether we last did single-step, in/out, go, etc. That way it is more event-based: we don't need the nested event loop to 'block' the program from running. Totally agree on your suggestions (speed setting, and whether or not to show where we are outside our own code). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 23:29:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 19 Sep 2015 21:29:19 +0000 Subject: [issue25185] Inconsistency between venv and site Message-ID: <1442698159.95.0.304023821424.issue25185@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: venv writes pyvenv.cfg with utf-8 encoding, but site reads it with locale encoding. ---------- components: Library (Lib) messages: 251119 nosy: serhiy.storchaka priority: normal severity: normal status: open title: Inconsistency between venv and site type: behavior versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Sep 19 23:29:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 19 Sep 2015 21:29:54 +0000 Subject: [issue25185] Inconsistency between venv and site In-Reply-To: <1442698159.95.0.304023821424.issue25185@psf.upfronthosting.co.za> Message-ID: <1442698194.64.0.97761475343.issue25185@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 00:04:09 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sat, 19 Sep 2015 22:04:09 +0000 Subject: [issue25180] Tools/parser/unparse.py needs to be updated for f-strings In-Reply-To: <1442690243.97.0.917526078175.issue25180@psf.upfronthosting.co.za> Message-ID: <1442700249.7.0.713276047157.issue25180@psf.upfronthosting.co.za> Eric V. Smith added the comment: This task is actually pretty difficult, and is going to require some major surgery to unparse.py. Unfortunately, until it's fixed, you can't use f-strings in the stdlib or in stdlib tests. Particularly challenging are nested f-strings like: f'{f"{0}"*3}' Getting the quoting right will be hard, and will likely require passing another parameter around to all of the dispatch functions. Or maybe just some local state, similar to the indent level (_indent) which is already being tracked. ---------- components: +Demos and Tools nosy: -python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 00:06:24 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 19 Sep 2015 22:06:24 +0000 Subject: [issue25175] Documentation-Tkinter Clarify module spelling change in Python 3 docs In-Reply-To: <1442656864.32.0.801468754438.issue25175@psf.upfronthosting.co.za> Message-ID: <1442700384.52.0.389435217004.issue25175@psf.upfronthosting.co.za> Martin Panter added the comment: Normally the documentation doesn?t mention changes from Python 2. But in this case one often has to rely on other sources of documentation, which are often about Python 2, so I think the notice might be reasonable. ---------- components: +Tkinter stage: needs patch -> patch review versions: +Python 3.4 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 00:10:41 2015 From: report at bugs.python.org (Brett Cannon) Date: Sat, 19 Sep 2015 22:10:41 +0000 Subject: [issue25182] python -v crashes in nonencodable directory In-Reply-To: <1442695726.04.0.992972651572.issue25182@psf.upfronthosting.co.za> Message-ID: <1442700641.75.0.151685562432.issue25182@psf.upfronthosting.co.za> Brett Cannon added the comment: And what happens if you leave -v off? Since the failure is in Py_Initialize I want to know if that Py_FatalError trigger is avoided without -v. A possible fix to test is to simply modify importlib._bootstrap._verbose_message to catch UnicodeDecodeError and then print some message saying that there was some undecodable string and just swallow the exception. I just don't know if this is in the right place to prevent Py_Initialize from erroring out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 00:15:20 2015 From: report at bugs.python.org (Jelle Zijlstra) Date: Sat, 19 Sep 2015 22:15:20 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442700920.38.0.89539391674.issue25106@psf.upfronthosting.co.za> Changes by Jelle Zijlstra : ---------- nosy: +Jelle Zijlstra status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 00:40:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 19 Sep 2015 22:40:19 +0000 Subject: [issue25182] python -v crashes in nonencodable directory In-Reply-To: <1442695726.04.0.992972651572.issue25182@psf.upfronthosting.co.za> Message-ID: <1442702419.9.0.256043181486.issue25182@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: python without -v is not failed. If wrap message in _bootstrap_external._verbose_message with '!%a'% and in _bootstrap._verbose_message with '%a'% (why _verbose_message is duplicated in _bootstrap and _bootstrap_external?), the output is: ... # installing zipimport hook @"import 'zipimport' # " # installed zipimport hook !'# /home/serhiy/py/cpy\udcffthon-3.5/Lib/encodings/__pycache__/__init__.cpython-35.pyc matches /home/serhiy/py/cpy\udcffthon-3.5/Lib/encodings/__init__.py' !"# code object from '/home/serhiy/py/cpy\\udcffthon-3.5/Lib/encodings/__pycache__/__init__.cpython-35.pyc'" !'# /home/serhiy/py/cpy\udcffthon-3.5/Lib/__pycache__/codecs.cpython-35.pyc matches /home/serhiy/py/cpy\udcffthon-3.5/Lib/codecs.py' !"# code object from '/home/serhiy/py/cpy\\udcffthon-3.5/Lib/__pycache__/codecs.cpython-35.pyc'" @"import '_codecs' # " @"import 'codecs' # <_frozen_importlib_external.SourceFileLoader object at 0xb70b9aac>" !'# /home/serhiy/py/cpy\udcffthon-3.5/Lib/encodings/__pycache__/aliases.cpython-35.pyc matches /home/serhiy/py/cpy\udcffthon-3.5/Lib/encodings/aliases.py' !"# code object from '/home/serhiy/py/cpy\\udcffthon-3.5/Lib/encodings/__pycache__/aliases.cpython-35.pyc'" @"import 'encodings.aliases' # <_frozen_importlib_external.SourceFileLoader object at 0xb70c81ac>" @"import 'encodings' # <_frozen_importlib_external.SourceFileLoader object at 0xb70b96cc>" !'# /home/serhiy/py/cpy\udcffthon-3.5/Lib/encodings/__pycache__/utf_8.cpython-35.pyc matches /home/serhiy/py/cpy\udcffthon-3.5/Lib/encodings/utf_8.py' !"# code object from '/home/serhiy/py/cpy\\udcffthon-3.5/Lib/encodings/__pycache__/utf_8.cpython-35.pyc'" @"import 'encodings.utf_8' # <_frozen_importlib_external.SourceFileLoader object at 0xb70ccd2c>" @"import '_signal' # " !'# /home/serhiy/py/cpy\udcffthon-3.5/Lib/encodings/__pycache__/latin_1.cpython-35.pyc matches /home/serhiy/py/cpy\udcffthon-3.5/Lib/encodings/latin_1.py' !"# code object from '/home/serhiy/py/cpy\\udcffthon-3.5/Lib/encodings/__pycache__/latin_1.cpython-35.pyc'" @"import 'encodings.latin_1' # <_frozen_importlib_external.SourceFileLoader object at 0xb70cf54c>" !'# /home/serhiy/py/cpy\udcffthon-3.5/Lib/__pycache__/io.cpython-35.pyc matches /home/serhiy/py/cpy\udcffthon-3.5/Lib/io.py' !"# code object from '/home/serhiy/py/cpy\\udcffthon-3.5/Lib/__pycache__/io.cpython-35.pyc'" ... Verbose non-ascii message is written before importing codecs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 01:02:12 2015 From: report at bugs.python.org (Brett Cannon) Date: Sat, 19 Sep 2015 23:02:12 +0000 Subject: [issue25186] Don't duplicate _verbose_message in importlib._bootstrap and _bootstrap_external Message-ID: <1442703732.01.0.764614399851.issue25186@psf.upfronthosting.co.za> New submission from Brett Cannon: For some reason _verbose_message() is defined in both _bootstrap and _bootstrap_external. Probably should only have it in _bootstrap, unless Eric has a reason he duplicated the code. ---------- components: Library (Lib) messages: 251124 nosy: brett.cannon, eric.snow priority: normal severity: normal status: open title: Don't duplicate _verbose_message in importlib._bootstrap and _bootstrap_external type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 01:04:48 2015 From: report at bugs.python.org (Brett Cannon) Date: Sat, 19 Sep 2015 23:04:48 +0000 Subject: [issue25106] Hash computation speedup for {buffer, string, unicode}object In-Reply-To: <1442215768.28.0.950322315319.issue25106@psf.upfronthosting.co.za> Message-ID: <1442703888.58.0.714989149562.issue25106@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 01:20:32 2015 From: report at bugs.python.org (Brett Cannon) Date: Sat, 19 Sep 2015 23:20:32 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1442704832.93.0.577593375481.issue24915@psf.upfronthosting.co.za> Brett Cannon added the comment: I gave the custom test runner a try using unittest's discovery facility, but it started to execute the whole test suite again, so it's a bit more complicated than you might think (I guess it imported regrtest or something?). ---------- Added file: http://bugs.python.org/file40522/pgo.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 01:26:24 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 19 Sep 2015 23:26:24 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1442705184.61.0.457857758291.issue24915@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Instead of writing a custom test runner from scratch, I would suggest adding a hidden --option to regrtest that would disable reporting errors. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 01:58:12 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Sat, 19 Sep 2015 23:58:12 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1442707092.58.0.0302211541348.issue24915@psf.upfronthosting.co.za> Alecsandru Patrascu added the comment: I can work on modifying the existing regrtest and adding a distinct flag, --pgo for example, as Antoine suggested. Indeed, it will not be trivial as regrtest has a dual approach (single process and multi process), but I will give it a try and post a patch as soon as possible. I also suggest that I open a new issue for this case as it is somehow a distinct implementation than pure PGO and definitively will be some iterations on regrtest.py for both versions of Python until we reach a common ground. It is ok for everyone? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 02:13:27 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 20 Sep 2015 00:13:27 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1442707092.58.0.0302211541348.issue24915@psf.upfronthosting.co.za> Message-ID: <55FDFA24.50008@free.fr> Antoine Pitrou added the comment: I think the --pgo flag needs only work in single process mode, since multi-process would probably not write out the profiling data properly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 02:25:25 2015 From: report at bugs.python.org (Brett Cannon) Date: Sun, 20 Sep 2015 00:25:25 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1442708725.65.0.289995920933.issue24915@psf.upfronthosting.co.za> Brett Cannon added the comment: A separate issue is fine, Alecsandru, since we can make it a dependency of this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 02:30:40 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 20 Sep 2015 00:30:40 +0000 Subject: [issue25176] Link to urllib.parse.parse_qsl, not parse_qs, from cgi.parse_qsl doc In-Reply-To: <1442657822.78.0.00192788068763.issue25176@psf.upfronthosting.co.za> Message-ID: <1442709040.33.0.296382667365.issue25176@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for the patch. This only applies to the Python 3 doc; Python 2 does not have the error. ---------- assignee: docs at python -> martin.panter nosy: +berker.peksag, martin.panter stage: -> commit review versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 02:37:37 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 20 Sep 2015 00:37:37 +0000 Subject: [issue25175] Documentation-Tkinter Clarify module spelling change in Python 3 docs In-Reply-To: <1442656864.32.0.801468754438.issue25175@psf.upfronthosting.co.za> Message-ID: <1442709457.24.0.187159624436.issue25175@psf.upfronthosting.co.za> Mark Lawrence added the comment: Does this open a can of worms? "You did it for Tkinter, why not do it for everything that was changed by PEP3108"? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 02:57:55 2015 From: report at bugs.python.org (Mark Roseman) Date: Sun, 20 Sep 2015 00:57:55 +0000 Subject: [issue25146] IDLE debugger could better visualize program execution In-Reply-To: <1442440221.76.0.764553903841.issue25146@psf.upfronthosting.co.za> Message-ID: <1442710675.32.0.398016226729.issue25146@psf.upfronthosting.co.za> Mark Roseman added the comment: Ok, I lied. The program runs through start to finish regardless, and all the 'stopping' and breakpoints is really just very selectively deciding which subset of execution tracing events to pass back to the debugger. So you really do need to 'block' in those callbacks. Doing this in the remote debugger is relatively easy with just a small tweak (turning a synchronous call into an async one, so we control when the callback 'completes'). Doing so in the 'run without subprocess' scenario would be tougher, and we'd need to either keep the nested loops or do some funky thing with threads. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 03:19:34 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Sep 2015 01:19:34 +0000 Subject: [issue25176] Link to urllib.parse.parse_qsl, not parse_qs, from cgi.parse_qsl doc In-Reply-To: <1442657822.78.0.00192788068763.issue25176@psf.upfronthosting.co.za> Message-ID: <20150920011931.31205.48967@psf.io> Roundup Robot added the comment: New changeset 3ed2427758cf by Martin Panter in branch '3.4': Issue #25176: Correct link for cgi.parse_qsl; patch from Ville Skytt? https://hg.python.org/cpython/rev/3ed2427758cf New changeset 138bbb7cf612 by Martin Panter in branch '3.5': Issue #25176: Merge cgi.parse_qsl link from 3.4 into 3.5 https://hg.python.org/cpython/rev/138bbb7cf612 New changeset f08d56387982 by Martin Panter in branch 'default': Issue #25176: Merge cgi.parse_qsl link from 3.5 https://hg.python.org/cpython/rev/f08d56387982 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 03:23:43 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 20 Sep 2015 01:23:43 +0000 Subject: [issue25175] Documentation-Tkinter Clarify module spelling change in Python 3 docs In-Reply-To: <1442656864.32.0.801468754438.issue25175@psf.upfronthosting.co.za> Message-ID: <1442712223.33.0.305271000011.issue25175@psf.upfronthosting.co.za> Martin Panter added the comment: Perhaps it would be better to add the notice inside the big ?See also? box at the top. In particular I occasionally find myself looking at the NMT ?Tkinter reference: a GUI for Python? and Effbot sites as a substitute for the missing built-in documentation, and both these are written for Python 2. On the other hand, the TkDocs site is also useful, and seem to use Python 3. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 03:47:28 2015 From: report at bugs.python.org (Carol Willing) Date: Sun, 20 Sep 2015 01:47:28 +0000 Subject: [issue25175] Documentation-Tkinter Clarify module spelling change in Python 3 docs In-Reply-To: <1442656864.32.0.801468754438.issue25175@psf.upfronthosting.co.za> Message-ID: <1442713648.52.0.233766420299.issue25175@psf.upfronthosting.co.za> Carol Willing added the comment: Thank you Bar Harel for submitting a patch. Ultimately, I believe that the wording should be what is most helpful for the end users. If you wish to avoid mentioning Python 2, then a simple note cautioning the user to take care that the case of the module should match the user's Python version. "Note: Python 3 uses all lowercase for the 'tkinter' module. Earlier versions of Python used 'Tkinter'. Please take care to use the correct module name that corresponds to the Python version being used." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 03:55:52 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 20 Sep 2015 01:55:52 +0000 Subject: [issue25176] Link to urllib.parse.parse_qsl, not parse_qs, from cgi.parse_qsl doc In-Reply-To: <1442657822.78.0.00192788068763.issue25176@psf.upfronthosting.co.za> Message-ID: <1442714152.33.0.231665864944.issue25176@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 04:12:36 2015 From: report at bugs.python.org (David Ward) Date: Sun, 20 Sep 2015 02:12:36 +0000 Subject: [issue25187] bdist_rpm fails due to wrong hardcoded assumption about RPM filename format Message-ID: <1442715156.03.0.0265256317041.issue25187@psf.upfronthosting.co.za> New submission from David Ward: bdist_rpm wrongly assumes a hard-coded format for the filename of the non-source RPM which is generated when it calls rpmbuild, specifically: "%{arch}/%{name}-%{version}-%{release}.%{arch}.rpm" The format used by rpmbuild is actually specified by the RPM macro %{_rpmfilename}. With the /usr/lib/rpm/macros file that is shipped with official releases of RPM (at http://rpm.org), %{_rpmfilename} evaluates to the value above. However this value cannot be assumed: the directory "%{arch}/" is dropped under the Mock chroot environment (https://fedoraproject.org/wiki/Mock). Mock is used to build all official Fedora Project packages (by Koji) as well as unofficial packages (by Copr). These two build systems also target Extra Packages for Enterprise Linux (EPEL) in addition to Fedora releases. As a result, bdist_rpm fails when trying to move the non-source RPM to the 'dist' folder after it is built by rpmbuild. The attached patch causes bdist_rpm to evaluate "%{_rpmfilename}" instead of relying on the hard-coded value. ---------- components: Distutils files: python-bdist_rpm-evaluate-_rpmfilename.patch keywords: patch messages: 251136 nosy: dpward, dstufft, eric.araujo priority: normal severity: normal status: open title: bdist_rpm fails due to wrong hardcoded assumption about RPM filename format type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40523/python-bdist_rpm-evaluate-_rpmfilename.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 06:39:45 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 20 Sep 2015 04:39:45 +0000 Subject: [issue25180] Tools/parser/unparse.py needs to be updated for f-strings In-Reply-To: <1442690243.97.0.917526078175.issue25180@psf.upfronthosting.co.za> Message-ID: <1442723985.11.0.446230415322.issue25180@psf.upfronthosting.co.za> Martin Panter added the comment: I think this patch should do it. No major surgery required, just a good dose of recursion :) def test_nested_fstrings(self): # Original code y = 5 self.assertEqual(f'{f"{0}"*3}', '000') self.assertEqual(f'{f"{y}"*3}', '555') self.assertEqual(f'{f"{\'x\'}"*3}', 'xxx') self.assertEqual(f"{r'x' f'{\"s\"}'}", 'xs') self.assertEqual(f"{r'x'rf'{\"s\"}'}", 'xs') def test_nested_fstrings(self): # Unparsed output y = 5 self.assertEqual(f"{(f'{0}' * 3)}", '000') self.assertEqual(f"{(f'{y}' * 3)}", '555') self.assertEqual(f'{(f"{\'x\'}" * 3)}', 'xxx') self.assertEqual(f'{f"x{\'s\'}"}', 'xs') self.assertEqual(f'{f"x{\'s\'}"}', 'xs') There was no problem getting the quoting right; repr() takes care of that, and then you slap the ?f? on the front. The most subtle thing was knowing that f"{ {...} }" cannot be unparsed as f"{{...}}". I unparse other expressions without adding spaces, but unparse that one as f"{ {...}}". Tested by running ./python -bWall -m test -u cpu test_tools ---------- keywords: +patch nosy: +martin.panter stage: needs patch -> patch review Added file: http://bugs.python.org/file40524/fstring-unparse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 07:10:09 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Sun, 20 Sep 2015 05:10:09 +0000 Subject: [issue25108] traceback.extract_stack() compatibility break in 3.5 In-Reply-To: <1442225623.41.0.830396346015.issue25108@psf.upfronthosting.co.za> Message-ID: <1442725809.36.0.815686014878.issue25108@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: > New changeset f6125114b55f by Serhiy Storchaka in branch '2.7': > Issue #25108: Backported tests for traceback functions print_stack(), > https://hg.python.org/cpython/rev/f6125114b55f The new tests fail on 2.7 branch when Lib/test/test_traceback.pyc is present, because __file__ can contain path to *.pyc files in Python 2. It is sufficient to run test_traceback twice to reproduce problem: $ LD_LIBRARY_PATH="$(pwd)" ./python -m test.regrtest -v test_traceback ... $ LD_LIBRARY_PATH="$(pwd)" ./python -m test.regrtest -v test_traceback == CPython 2.7.10+ (2.7:fe84898fbe98, Sep 20 2015, 06:52:14) [GCC 4.9.3] == Linux-4.1.7 little-endian == /tmp/cpython/build/test_python_24845 Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0) [1/1] test_traceback test_bad_indentation (test.test_traceback.TracebackCases) ... ok test_base_exception (test.test_traceback.TracebackCases) ... ok test_bug737473 (test.test_traceback.TracebackCases) ... ok test_caret (test.test_traceback.TracebackCases) ... ok test_format_exception_only_bad__str__ (test.test_traceback.TracebackCases) ... ok test_nocaret (test.test_traceback.TracebackCases) ... ok test_string_exception1 (test.test_traceback.TracebackCases) ... ok test_string_exception2 (test.test_traceback.TracebackCases) ... ok test_unicode (test.test_traceback.TracebackCases) ... ok test_without_exception (test.test_traceback.TracebackCases) ... ok test_format_stack (test.test_traceback.TracebackFormatTests) ... FAIL test_print_stack (test.test_traceback.TracebackFormatTests) ... FAIL test_traceback_format (test.test_traceback.TracebackFormatTests) ... ok test_extract_stack (test.test_traceback.MiscTracebackCases) ... FAIL ====================================================================== FAIL: test_format_stack (test.test_traceback.TracebackFormatTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/tmp/cpython/Lib/test/test_traceback.py", line 232, in test_format_stack ' return traceback.format_stack()\n' % (__file__, lineno+1), AssertionError: Lists differ: [' File "/tmp/cpython/Lib/tes... != [' File "/tmp/cpython/Lib/tes... First differing element 0: File "/tmp/cpython/Lib/test/test_traceback.py", line 226, in test_format_stack result = fmt() File "/tmp/cpython/Lib/test/test_traceback.pyc", line 226, in test_format_stack result = fmt() - [' File "/tmp/cpython/Lib/test/test_traceback.py", line 226, in test_format_stack\n result = fmt()\n', + [' File "/tmp/cpython/Lib/test/test_traceback.pyc", line 226, in test_format_stack\n result = fmt()\n', ? + - ' File "/tmp/cpython/Lib/test/test_traceback.py", line 225, in fmt\n return traceback.format_stack()\n'] + ' File "/tmp/cpython/Lib/test/test_traceback.pyc", line 225, in fmt\n return traceback.format_stack()\n'] ? + ====================================================================== FAIL: test_print_stack (test.test_traceback.TracebackFormatTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/tmp/cpython/Lib/test/test_traceback.py", line 220, in test_print_stack ' traceback.print_stack()', AssertionError: Lists differ: [' File "/tmp/cpython/Lib/tes... != [' File "/tmp/cpython/Lib/tes... First differing element 0: File "/tmp/cpython/Lib/test/test_traceback.py", line 214, in test_print_stack File "/tmp/cpython/Lib/test/test_traceback.pyc", line 214, in test_print_stack - [' File "/tmp/cpython/Lib/test/test_traceback.py", line 214, in test_print_stack', + [' File "/tmp/cpython/Lib/test/test_traceback.pyc", line 214, in test_print_stack', ? + ' prn()', - ' File "/tmp/cpython/Lib/test/test_traceback.py", line 212, in prn', + ' File "/tmp/cpython/Lib/test/test_traceback.pyc", line 212, in prn', ? + ' traceback.print_stack()'] ====================================================================== FAIL: test_extract_stack (test.test_traceback.MiscTracebackCases) ---------------------------------------------------------------------- Traceback (most recent call last): File "/tmp/cpython/Lib/test/test_traceback.py", line 248, in test_extract_stack (__file__, lineno+1, 'extract', 'return traceback.extract_stack()'), AssertionError: Lists differ: [('/tmp/cpython/Lib/test/test_... != [('/tmp/cpython/Lib/test/test_... First differing element 0: ('/tmp/cpython/Lib/test/test_traceback.py', 244, 'test_extract_stack', 'result = extract()') ('/tmp/cpython/Lib/test/test_traceback.pyc', 244, 'test_extract_stack', 'result = extract()') - [('/tmp/cpython/Lib/test/test_traceback.py', + [('/tmp/cpython/Lib/test/test_traceback.pyc', ? + 244, 'test_extract_stack', 'result = extract()'), - ('/tmp/cpython/Lib/test/test_traceback.py', + ('/tmp/cpython/Lib/test/test_traceback.pyc', ? + 243, 'extract', 'return traceback.extract_stack()')] ---------------------------------------------------------------------- Ran 14 tests in 4.029s FAILED (failures=3) test test_traceback failed -- multiple errors occurred 1 test failed: test_traceback ---------- nosy: +Arfrever resolution: fixed -> stage: resolved -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 07:13:28 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 20 Sep 2015 05:13:28 +0000 Subject: [issue23738] Clarify documentation of positional-only default values In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za> Message-ID: <1442726008.21.0.941248589807.issue23738@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- dependencies: +TypeError: truncate() takes no keyword arguments _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 07:24:31 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 20 Sep 2015 05:24:31 +0000 Subject: [issue14586] TypeError: truncate() takes no keyword arguments In-Reply-To: <1334455473.06.0.710562653974.issue14586@psf.upfronthosting.co.za> Message-ID: <1442726671.09.0.508142098577.issue14586@psf.upfronthosting.co.za> Martin Panter added the comment: I agree with Guy?s earlier comments and would prefer this be fixed in the documentation. Otherwise, we would end up with third party IOBase implementations that use the wrong keyword name, or that don?t accept keywords at all. These would no longer be compatible with the new API. Also the new patch competes with Issue 25057, also proposing keyword arguments for seek(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 07:26:22 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Sun, 20 Sep 2015 05:26:22 +0000 Subject: [issue25188] regrtest.py improvement for Profile Guided Optimization builds Message-ID: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za> New submission from Alecsandru Patrascu: This issue adds improved support for Profile Guided Optimization builds in the regression test suite. Mainly, we keep the visual progress status in this process and suppress errors or any other unnecessary output that can alarm users. ---------- components: Library (Lib) messages: 251140 nosy: alecsandru.patrascu priority: normal severity: normal status: open title: regrtest.py improvement for Profile Guided Optimization builds type: performance versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 07:26:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Sep 2015 05:26:39 +0000 Subject: [issue25185] Inconsistency between venv and site In-Reply-To: <1442698159.95.0.304023821424.issue25185@psf.upfronthosting.co.za> Message-ID: <1442726799.3.0.877950927173.issue25185@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Example: $ LC_ALL=ru_RU.cp1251 ./python -m venv ../vpy? $ LC_ALL=ru_RU.cp1251 ./python -m venv ../vpy? Error: 'charmap' codec can't encode character '\udc98' in position 617: character maps to The first command is successful, the latter command is failed. '?'.encode('utf-8') == b'\xc3\x98', and 0x98 is invalid code in CP1251. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 07:39:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Sep 2015 05:39:28 +0000 Subject: [issue25108] traceback.extract_stack() compatibility break in 3.5 In-Reply-To: <1442225623.41.0.830396346015.issue25108@psf.upfronthosting.co.za> Message-ID: <20150920053925.16599.6759@psf.io> Roundup Robot added the comment: New changeset 7e718bbf5152 by Serhiy Storchaka in branch '2.7': Issue #25108: Fixed test_traceback in the case when this test is run twice. https://hg.python.org/cpython/rev/7e718bbf5152 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 07:40:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Sep 2015 05:40:19 +0000 Subject: [issue25108] traceback.extract_stack() compatibility break in 3.5 In-Reply-To: <1442225623.41.0.830396346015.issue25108@psf.upfronthosting.co.za> Message-ID: <1442727619.55.0.934742002503.issue25108@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Arfrever. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 07:40:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Sep 2015 05:40:52 +0000 Subject: [issue25108] traceback.extract_stack() compatibility break in 3.5 In-Reply-To: <1442225623.41.0.830396346015.issue25108@psf.upfronthosting.co.za> Message-ID: <1442727652.83.0.289376581182.issue25108@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 07:41:22 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 20 Sep 2015 05:41:22 +0000 Subject: [issue25057] Make parameter of io.base to be positional and keyword In-Reply-To: <1441895516.87.0.702583727095.issue25057@psf.upfronthosting.co.za> Message-ID: <1442727682.33.0.364259547966.issue25057@psf.upfronthosting.co.za> Martin Panter added the comment: For an illustration of the problem that this would cause, I did a quick search through Python?s own source tree. It already has various keyword names: def seek(self, pos, whence=0): def seek(self, cookie, whence=0): def seek(self, offset, whence=0): def seek(self, position, whence=io.SEEK_SET): It is easy to imagine third party implementations also exist with a variety of keyword names. So I definitely think we should avoid changing the IOBase API because it will break backwards compatibility. And I think there is no good reason to add explicit keyword support to individual concrete classes like TextIOWrapper, in case it gives users the wrong impression about the general IOBase API. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 07:43:39 2015 From: report at bugs.python.org (yangyanbo) Date: Sun, 20 Sep 2015 05:43:39 +0000 Subject: [issue25189] An issue about os.acess Message-ID: <1442727819.59.0.648536077202.issue25189@psf.upfronthosting.co.za> New submission from yangyanbo: On Windows 10 . The telnet function is closed on Windows10, I open it and I can use it in WIN CMD. But when i start python shell?and import os module? I use the command os.acess(r"C:\Windows\System32\telnet.exe",os.X_OK) to check it is or not be executeable?And I got False. Why I use it because winpexpect moudle use it to check. I try this in three PCS,and i doubt it may be an issue ---------- components: Windows messages: 251145 nosy: berlinsaint, loewis, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: An issue about os.acess type: performance versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 07:44:32 2015 From: report at bugs.python.org (yangyanbo) Date: Sun, 20 Sep 2015 05:44:32 +0000 Subject: [issue25189] An issue about os.access In-Reply-To: <1442727819.59.0.648536077202.issue25189@psf.upfronthosting.co.za> Message-ID: <1442727872.94.0.382418233728.issue25189@psf.upfronthosting.co.za> Changes by yangyanbo : ---------- title: An issue about os.acess -> An issue about os.access _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 07:49:27 2015 From: report at bugs.python.org (yangyanbo) Date: Sun, 20 Sep 2015 05:49:27 +0000 Subject: [issue25189] An issue about os.access In-Reply-To: <1442727819.59.0.648536077202.issue25189@psf.upfronthosting.co.za> Message-ID: <1442728167.35.0.576616135031.issue25189@psf.upfronthosting.co.za> yangyanbo added the comment: I wrote error ,it should be os.access, and the issue is really exist ---------- Added file: http://bugs.python.org/file40525/1.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 07:56:01 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 20 Sep 2015 05:56:01 +0000 Subject: [issue25146] IDLE debugger could better visualize program execution In-Reply-To: <1442440221.76.0.764553903841.issue25146@psf.upfronthosting.co.za> Message-ID: <1442728561.64.0.302474196031.issue25146@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I had a wild idea, possible a result of too much ignorance. Run the main debugger in the user process, with a separate root and event loop. Add to the communication protocol options to send a list of breakpoints and modules to be traced into and to send (module, lineno) pairs back, for highlighting in the editor. I am willing for a revised debugger to not work with -n. We want that to go away anyway. Roger Serwy sent some of us a prototype pipe implementation a year ago when I was busy with GSOC, and I did not pursue it yet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 08:05:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Sep 2015 06:05:56 +0000 Subject: [issue25189] An issue about os.access In-Reply-To: <1442727819.59.0.648536077202.issue25189@psf.upfronthosting.co.za> Message-ID: <1442729156.75.0.69061432632.issue25189@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This looks as a duplicate of issue2528. ---------- nosy: +serhiy.storchaka resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Change os.access to check ACLs under Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 08:15:13 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 20 Sep 2015 06:15:13 +0000 Subject: [issue25190] Define StringIO seek offset as code point offset Message-ID: <1442729712.98.0.451356431809.issue25190@psf.upfronthosting.co.za> New submission from Martin Panter: This follows from Issue 12922. When no newline translation is being done, it would be useful to define the seek() offset as the code point offset into the underlying string, allowing stuff like: s = StringIO() print("line", file=s) # Some inflexible API with an unwanted newline s.seek(-1, SEEK_CUR) # Undo the trailing newline s.truncate() In general, relative seeks are not allowed for text streams, and absolute offsets have arbitrary values. But when no encoding is actually going on, these restrictions are annoying. I guess the biggest problem is what to do when newline translation is enabled. But I think this is a rarely-used feature of StringIO. I suggest to say that offsets in that case remain arbitrary, and let the code do whatever it happens to do (probably jumping to the wrong character, chopping CRLFs in half, etc, as long as it won?t crash). ---------- components: IO messages: 251149 nosy: martin.panter priority: normal severity: normal status: open title: Define StringIO seek offset as code point offset type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 08:17:30 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 20 Sep 2015 06:17:30 +0000 Subject: [issue12922] StringIO and seek() In-Reply-To: <1315342130.67.0.227650351498.issue12922@psf.upfronthosting.co.za> Message-ID: <1442729850.03.0.556686135061.issue12922@psf.upfronthosting.co.za> Martin Panter added the comment: Opened Issue 25190 about the enhancing StringIO side of this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 08:35:10 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Sep 2015 06:35:10 +0000 Subject: [issue24199] Idle: remove idlelib.idlever.py and its use in About dialog In-Reply-To: <1431650285.59.0.600694723613.issue24199@psf.upfronthosting.co.za> Message-ID: <20150920063507.94121.26782@psf.io> Roundup Robot added the comment: New changeset 3c39413d277f by Terry Jan Reedy in branch '2.7': Issue #24199: Add stacklevel to deprecation warning call. https://hg.python.org/cpython/rev/3c39413d277f New changeset 048fce602bcd by Terry Jan Reedy in branch '3.4': Issue #24199: Add stacklevel to deprecation warning call. https://hg.python.org/cpython/rev/048fce602bcd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 08:36:04 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 20 Sep 2015 06:36:04 +0000 Subject: [issue24199] Idle: remove idlelib.idlever.py and its use in About dialog In-Reply-To: <1431650285.59.0.600694723613.issue24199@psf.upfronthosting.co.za> Message-ID: <1442730964.32.0.979347846776.issue24199@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 08:47:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Sep 2015 06:47:42 +0000 Subject: [issue25190] Define StringIO seek offset as code point offset In-Reply-To: <1442729712.98.0.451356431809.issue25190@psf.upfronthosting.co.za> Message-ID: <1442731662.23.0.258186575921.issue25190@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I suspect it would be not easy to do for Python implementation. ---------- nosy: +benjamin.peterson, pitrou, serhiy.storchaka, stutzbach _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 10:31:18 2015 From: report at bugs.python.org (Remi Pointel) Date: Sun, 20 Sep 2015 08:31:18 +0000 Subject: [issue25191] test_getsetlocale_issue1813 failed on OpenBSD Message-ID: <1442737878.41.0.0154038500687.issue25191@psf.upfronthosting.co.za> New submission from Remi Pointel: Hi, the test test_getsetlocale_issue1813 in ./Lib/test/test_locale.py failed on OpenBSD: ====================================================================== ...........s....ss..................testing with ('tr_TR', 'ISO8859-9') E....ss ERROR: test_getsetlocale_issue1813 (__main__.TestMiscellaneous) ---------------------------------------------------------------------- Traceback (most recent call last): File "./Lib/test/test_locale.py.orig", line 515, in test_getsetlocale_issue1813 locale.setlocale(locale.LC_CTYPE, loc) File "/usr/ports/pobj/Python-3.5.0/Python-3.5.0/Lib/locale.py", line 595, in setlocale return _setlocale(category, locale) locale.Error: unsupported locale setting ---------------------------------------------------------------------- Ran 38 tests in 0.040s FAILED (errors=1, skipped=5) The first setlocale(locale.LC_CTYPE, 'tr_TR') works fine, but loc = locale.getlocale(locale.LC_CTYPE) then locale.setlocale(locale.LC_CTYPE, loc) does not work. Attached is a patch to skip the second part if it does not work, is it correct? Thanks, Remi. ---------- components: Library (Lib), Tests files: patch-Lib_test_test_locale_py messages: 251153 nosy: rpointel priority: normal severity: normal status: open title: test_getsetlocale_issue1813 failed on OpenBSD versions: Python 3.5 Added file: http://bugs.python.org/file40526/patch-Lib_test_test_locale_py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 10:36:22 2015 From: report at bugs.python.org (Alun Champion) Date: Sun, 20 Sep 2015 08:36:22 +0000 Subject: [issue25192] deque append and appendleft should return value if maxlen set Message-ID: <1442738182.66.0.606955570535.issue25192@psf.upfronthosting.co.za> New submission from Alun Champion: Currently if you append or appendleft when len(deque) == maxlen item from the other end of the deque is discarded. These should return the discarded value to allow you to write: x = deque.append(y) vs if len(deque) == deque.maxlen(): x = deque.pop() deque.append(y) It should return None if len(deque) < maxlen or maxlen is not set. ---------- components: Library (Lib) messages: 251154 nosy: Alun Champion priority: normal severity: normal status: open title: deque append and appendleft should return value if maxlen set _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 10:46:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Sep 2015 08:46:35 +0000 Subject: [issue25192] deque append and appendleft should return value if maxlen set In-Reply-To: <1442738182.66.0.606955570535.issue25192@psf.upfronthosting.co.za> Message-ID: <1442738795.1.0.362858663918.issue25192@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> rhettinger nosy: +rhettinger type: -> enhancement versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 10:46:40 2015 From: report at bugs.python.org (Alun Champion) Date: Sun, 20 Sep 2015 08:46:40 +0000 Subject: [issue25193] itertools.accumlate should have an optional initializer argument Message-ID: <1442738800.12.0.18115193144.issue25193@psf.upfronthosting.co.za> New submission from Alun Champion: itertools.accumulate should have an initializer with the same semantics as functools.reduce. These two functions are closely related, reduce only providing you the end result accumulate providing an iterator over all the intermediate results. However, if you want all the intermediate results to this reduce: functools.reduce(operator.mul, range(1, 4), 10) You currently need to do: itertools.accumulate(itertools.chain([10], range(1,4), operator.mul) Adding an optional initialiser argument would avoid this. ---------- components: Library (Lib) messages: 251155 nosy: Alun Champion priority: normal severity: normal status: open title: itertools.accumlate should have an optional initializer argument versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 10:47:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Sep 2015 08:47:56 +0000 Subject: [issue25191] test_getsetlocale_issue1813 failed on OpenBSD In-Reply-To: <1442737878.41.0.0154038500687.issue25191@psf.upfronthosting.co.za> Message-ID: <1442738876.95.0.0703039812631.issue25191@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +lemburg, loewis, serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 10:51:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Sep 2015 08:51:59 +0000 Subject: [issue25193] itertools.accumlate should have an optional initializer argument In-Reply-To: <1442738800.12.0.18115193144.issue25193@psf.upfronthosting.co.za> Message-ID: <1442739119.36.0.313936789752.issue25193@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> rhettinger nosy: +rhettinger type: -> enhancement versions: -Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 10:54:24 2015 From: report at bugs.python.org (Alexander Heger) Date: Sun, 20 Sep 2015 08:54:24 +0000 Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5) In-Reply-To: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za> Message-ID: <1442739264.86.0.308451055557.issue25150@psf.upfronthosting.co.za> Alexander Heger added the comment: Dear Victor, yes, you patch seems to fix the yt install. Thank you very much! I hope this can be included in 3.5.1. Best wishes, Alexander ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 11:17:48 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 20 Sep 2015 09:17:48 +0000 Subject: [issue25194] Register of Financial Interests for core contributors Message-ID: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za> New submission from Nick Coghlan: As suggested at https://mail.python.org/pipermail/python-committers/2015-September/003556.html, this is a draft patch for a new section in the developer guide that allows core contributors to declare our major financial interest (if any) in the core development process. In addition to adding a paragraph suggesting new core developers consider filling in the register, I also rephrased the section regarding respecting people's time to reflect the fact that we're not all volunteers these days. Based on the discussion in the python-committers thread, I made the disclosure of commercial interests potentially impacting Python's design & development the main aim of the register, with the creation of a public list of the core developers available for contract and consulting work as a positive side benefit. ---------- assignee: ncoghlan components: Devguide files: register-of-interests.diff keywords: patch messages: 251158 nosy: ezio.melotti, ncoghlan, willingc priority: normal severity: normal stage: patch review status: open title: Register of Financial Interests for core contributors type: enhancement Added file: http://bugs.python.org/file40527/register-of-interests.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 11:30:17 2015 From: report at bugs.python.org (Petr Viktorin) Date: Sun, 20 Sep 2015 09:30:17 +0000 Subject: [issue25079] Tokenize generates NL instead of NEWLINE for comments In-Reply-To: <1442051359.49.0.451935650182.issue25079@psf.upfronthosting.co.za> Message-ID: <1442741417.25.0.458920686327.issue25079@psf.upfronthosting.co.za> Petr Viktorin added the comment: As it says in the docs, a "logical line that contains only spaces, tabs, formfeeds and possibly a comment, is ignored." If you write: if a=b: statement # Comment another statement both statements belong to the "if" block. In your example, the comment is similarly part of the "if" block, so the dedent comes after it. ---------- nosy: +encukou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 11:33:39 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 20 Sep 2015 09:33:39 +0000 Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5) In-Reply-To: <1442739264.86.0.308451055557.issue25150@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Yes my fix will be part of Python 3.5.1 release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 11:58:31 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sun, 20 Sep 2015 09:58:31 +0000 Subject: [issue25180] Tools/parser/unparse.py needs to be updated for f-strings In-Reply-To: <1442690243.97.0.917526078175.issue25180@psf.upfronthosting.co.za> Message-ID: <1442743111.32.0.0839154902374.issue25180@psf.upfronthosting.co.za> Eric V. Smith added the comment: That's awesome, thanks! Definitely simpler than where I was going. I'm not in front of my dev machine right now, so I can't run it. But if it works, it works. I suggest adding the test cases to test_unparse.py's UnparseTestCase. That way, any problems with this are caught earlier. The comment there says "Tests for specific bugs found in earlier versions of unparse", which this qualifies for! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 12:27:20 2015 From: report at bugs.python.org (Felix Yan) Date: Sun, 20 Sep 2015 10:27:20 +0000 Subject: [issue25195] mock.ANY doesn't match mock.MagicMock() object Message-ID: <1442744840.41.0.232215932607.issue25195@psf.upfronthosting.co.za> New submission from Felix Yan: Since Python 3.5.0 mock.MagicMock() object seems not matched by mock.ANY. This behavior looks weird and breaks tests of boto. Minimized example: In Python 3.4.3: >>> from unittest import mock >>> m = mock.MagicMock() >>> m(mock.MagicMock()) >>> m.assert_called_with(mock.ANY) >>> In Python 3.5.0: >>> from unittest import mock >>> m = mock.MagicMock() >>> m(mock.MagicMock()) >>> m.assert_called_with(mock.ANY) Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.5/unittest/mock.py", line 792, in assert_called_with raise AssertionError(_error_message()) from cause AssertionError: Expected call: mock() Actual call: mock() ---------- components: Library (Lib) messages: 251162 nosy: felixonmars priority: normal severity: normal status: open title: mock.ANY doesn't match mock.MagicMock() object versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 12:27:28 2015 From: report at bugs.python.org (Felix Yan) Date: Sun, 20 Sep 2015 10:27:28 +0000 Subject: [issue25195] mock.ANY doesn't match mock.MagicMock() object In-Reply-To: <1442744840.41.0.232215932607.issue25195@psf.upfronthosting.co.za> Message-ID: <1442744848.23.0.135736789017.issue25195@psf.upfronthosting.co.za> Changes by Felix Yan : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 13:32:10 2015 From: report at bugs.python.org (eryksun) Date: Sun, 20 Sep 2015 11:32:10 +0000 Subject: [issue25189] An issue about os.access In-Reply-To: <1442727819.59.0.648536077202.issue25189@psf.upfronthosting.co.za> Message-ID: <1442748730.78.0.846324786122.issue25189@psf.upfronthosting.co.za> eryksun added the comment: > This looks as a duplicate of issue2528. No, yangyanbo's problem is unrelated to the file's security descriptor, and it's not a bug. telnet.exe is manually installed via "Programs and Features", which only installs a 64-bit version into System32 (despite the 32 in its name, this directory has native 64-bit executables). But yangyanbo is running 32-bit Python, so accessing "System32" gets redirected to SysWOW64 (despite the 64 in its name, this directory has 32-bit executables that run in the "Windows 32-bit on Windows 64-bit" system). >From a 32-bit app the real System32 directory is available as "SysNative", e.g.: os.access(r'C:\Windows\SysNative\telnet.exe', os.X_OK) ---------- nosy: +eryksun resolution: duplicate -> not a bug superseder: Change os.access to check ACLs under Windows -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 13:33:11 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 20 Sep 2015 11:33:11 +0000 Subject: [issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x) In-Reply-To: <1442151642.39.0.456899707142.issue25084@psf.upfronthosting.co.za> Message-ID: <1442748791.49.0.866497957454.issue25084@psf.upfronthosting.co.za> Nick Coghlan added the comment: +1 - after the further discussion, addressing this downstream as a patch specifically to the pthread backend sounds good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 13:38:40 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 20 Sep 2015 11:38:40 +0000 Subject: [issue22559] [backport] ssl.MemoryBIO In-Reply-To: <1412540756.02.0.793381062078.issue22559@psf.upfronthosting.co.za> Message-ID: <1442749120.38.0.396843827504.issue22559@psf.upfronthosting.co.za> Nick Coghlan added the comment: Guido specifically asked for a new PEP for each resync that explicitly enumerated the changes being backported, after earlier drafts of PEP 466 requested blanket future permission for network security related backports. That approach actually turns out to be better from a documentation and backport management perspective - I organised the "New features in maintenance releases" section of the Python 2.7 What's New by PEP number, and "we backported PEP 466" nicely describes the changes that were backport to RHEL 7.2. A new PEP for resyncing with Python 3.5 can be a lot simpler than PEP 466 was, though - the basic rationale doesn't need to be repeated, and the PEP 466 backport already brought the implementations much closer together. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 13:47:07 2015 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 20 Sep 2015 11:47:07 +0000 Subject: [issue25194] Register of Financial Interests for core contributors In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za> Message-ID: <1442749627.39.0.781531537452.issue25194@psf.upfronthosting.co.za> Ezio Melotti added the comment: The "Consultants and Freelance Developers" seems to cover two different aspects: 1) list devs that are consultants or freelance developers for a living; 2) list devs that are available and can be hired to work on short term projects; The second aspect seems orthogonal to the rest of the section (I could be working as educator/trainer, but also be available for short term projects). IIUC the main goal here is to disclose who are we working for (if any). However, unless I'm misunderstanding, you also want to have a list of core developers that might be available to do paid work. ISTM that this paid work could cover at least 3 different categories: 1) work that won't directly benefit CPython (e.g. a company can hire me as a consultant for one of their project); 2) work that will benefit CPython (e.g. a company can pay me to add an approved feature/bugfix to CPython); 3) work on CPython paid by the PSF (e.g. the PSF can pay me to implement a PEP or to work on the infrastructure); I'm not sure if this was your intention, but if it was, I would put it in a separate section. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 15:38:07 2015 From: report at bugs.python.org (Remi Pointel) Date: Sun, 20 Sep 2015 13:38:07 +0000 Subject: [issue23177] test_ssl: failures on OpenBSD with LibreSSL In-Reply-To: <1420541656.17.0.750310163886.issue23177@psf.upfronthosting.co.za> Message-ID: <1442756287.51.0.603322091104.issue23177@psf.upfronthosting.co.za> Remi Pointel added the comment: Hi, maybe we should add the LIBRESSL_ information available in opensslv.h (as it has be done for OpenSSL): $ grep LIBRESSL /usr/include/ssl/opensslv.h #define LIBRESSL_VERSION_NUMBER 0x20030000L #define LIBRESSL_VERSION_TEXT "LibreSSL 2.3.0" #define OPENSSL_VERSION_TEXT LIBRESSL_VERSION_TEXT What do you think about that? Remi. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 17:37:49 2015 From: report at bugs.python.org (Mark Roseman) Date: Sun, 20 Sep 2015 15:37:49 +0000 Subject: [issue25146] IDLE debugger could better visualize program execution In-Reply-To: <1442440221.76.0.764553903841.issue25146@psf.upfronthosting.co.za> Message-ID: <1442763469.3.0.101283295752.issue25146@psf.upfronthosting.co.za> Mark Roseman added the comment: Frighteningly, your wild idea is close to how it actually works now, as per the ASCII art at the top of RemoteDebugger.py. :-) The authors of RemoteDebugger and rpc.py went to fantastic lengths to make this transparent so that everything looks local. If in my previous life I didn't develop groupware infrastructure I'd have been screwed trying to follow what was actually going on! If you want to be impressed, turn on debugging in rpc.py (at start of RPCHandler class), uncomment the print statements in RemoteDebugger.py, start IDLE, open up the debugger, and type "1+1" into the shell. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 18:40:06 2015 From: report at bugs.python.org (yangyanbo) Date: Sun, 20 Sep 2015 16:40:06 +0000 Subject: [issue25189] An issue about os.access In-Reply-To: <1442727819.59.0.648536077202.issue25189@psf.upfronthosting.co.za> Message-ID: <1442767206.92.0.560821488259.issue25189@psf.upfronthosting.co.za> yangyanbo added the comment: Thanks for eryksun a lot. Yes,it did solve my problem. And Find this Sysnative directory doesnt exsit,And I searched the msdn then find that it is a Windows Mechanism. All in all , it does prove you are right. Thanks a lot Again ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 19:04:48 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 20 Sep 2015 17:04:48 +0000 Subject: [issue12885] distutils.filelist.findall() fails on broken symlink in Py2.x In-Reply-To: <1314971843.03.0.797964996491.issue12885@psf.upfronthosting.co.za> Message-ID: <1442768688.51.0.844797532603.issue12885@psf.upfronthosting.co.za> Jason R. Coombs added the comment: > Does the patch change the behaviour for the handling of the MANIFEST file (not MANIFEST.in)? My previous message mentions that the docs say that one can include symlinks in MANIFEST. This change will not affect the content of MANIFEST.in (template) nor MANIFEST. Previously, if a broken symlink was provided, it would raise an error. With the patch, under that condition the process will not fail but will instead ignore those broken symlinks as if they do not exist (and omit them from MANIFEST). Non-broken symlinks (those that resolve to directories or files) will continue to be treated exactly as if their targets exist in that place. To my knowledge, there is no special handling of symlinks (such as with tarfiles that store the underlying symbolic link details). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 19:32:40 2015 From: report at bugs.python.org (Prashant Tyagi) Date: Sun, 20 Sep 2015 17:32:40 +0000 Subject: [issue24894] iso-8859-11 missing from codecs table In-Reply-To: <1439964625.02.0.805508700241.issue24894@psf.upfronthosting.co.za> Message-ID: <1442770360.31.0.352079085828.issue24894@psf.upfronthosting.co.za> Prashant Tyagi added the comment: As it is cleary stated itself into the wipikedia https://en.wikipedia.org/wiki/ISO/IEC_8859#The_Parts_of_ISO.2FIEC_8859. "The work in making a part of 8859 for Devanagari was officially abandoned in 1997. ISCII and Unicode/ISO/IEC 10646 cover Devanagari." so actually i dont think it should be a part of 8859_12. However 8859_11 is virtually identical to TIS 620 so it might be needed. ---------- nosy: +tyagi221295 versions: -Python 2.7, Python 3.3, Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 20:19:17 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Sep 2015 18:19:17 +0000 Subject: [issue25145] urllib how-to should be updated to remove PyGoogle In-Reply-To: <1442439158.29.0.495500663722.issue25145@psf.upfronthosting.co.za> Message-ID: <20150920181914.31195.49238@psf.io> Roundup Robot added the comment: New changeset 1fcdca298be9 by Benjamin Peterson in branch '3.4': use a more modern UA (#25145) https://hg.python.org/cpython/rev/1fcdca298be9 New changeset 2efd269b3eb8 by Benjamin Peterson in branch '3.4': remove reference to PyGoogle (#25145) https://hg.python.org/cpython/rev/2efd269b3eb8 New changeset 9b7bc13aed4e by Benjamin Peterson in branch '2.7': remove reference to PyGoogle (#25145) https://hg.python.org/cpython/rev/9b7bc13aed4e New changeset 96eff21fc47e by Benjamin Peterson in branch '2.7': use a more modern UA (#25145) https://hg.python.org/cpython/rev/96eff21fc47e New changeset 7f76c7d853be by Benjamin Peterson in branch '3.5': merge 3.4 (#25145) https://hg.python.org/cpython/rev/7f76c7d853be New changeset 54ea36ce6eab by Benjamin Peterson in branch 'default': merge 3.5 (#25145) https://hg.python.org/cpython/rev/54ea36ce6eab ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 20:28:13 2015 From: report at bugs.python.org (Brett Cannon) Date: Sun, 20 Sep 2015 18:28:13 +0000 Subject: [issue25188] regrtest.py improvement for Profile Guided Optimization builds In-Reply-To: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za> Message-ID: <1442773693.06.0.346540395409.issue25188@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 20:29:13 2015 From: report at bugs.python.org (Brett Cannon) Date: Sun, 20 Sep 2015 18:29:13 +0000 Subject: [issue24915] Profile Guided Optimization improvements (better training, llvm support, etc) In-Reply-To: <1440254502.45.0.903388921484.issue24915@psf.upfronthosting.co.za> Message-ID: <1442773753.86.0.887851503523.issue24915@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- dependencies: +regrtest.py improvement for Profile Guided Optimization builds _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 20:35:49 2015 From: report at bugs.python.org (Prashant Tyagi) Date: Sun, 20 Sep 2015 18:35:49 +0000 Subject: [issue24894] iso-8859-11 missing from codecs table In-Reply-To: <1439964625.02.0.805508700241.issue24894@psf.upfronthosting.co.za> Message-ID: <1442774149.08.0.768692931617.issue24894@psf.upfronthosting.co.za> Prashant Tyagi added the comment: Here is my patch which includes iso8859_11 to the docs. ---------- keywords: +patch Added file: http://bugs.python.org/file40528/Issue24894.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 20:48:33 2015 From: report at bugs.python.org (Abdullah Hilson) Date: Sun, 20 Sep 2015 18:48:33 +0000 Subject: [issue25196] Installer>Install in user folder by default when you check: for all users Message-ID: <1442774913.98.0.448713689083.issue25196@psf.upfronthosting.co.za> New submission from Abdullah Hilson: Hello Just downloaded : https://www.python.org/ftp/python/3.5.0/python-3.5.0-amd64.exe And I launch the install, I check checkbox to install for all users And folder for installation stay at: C:\Users\myusername\AppData\Local\Programs\Python\Python35\ I have to change it manually Well, I don't want it in that folder when I install globally. Thanks ---------- components: Windows messages: 251174 nosy: Abdullah Hilson, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Installer>Install in user folder by default when you check: for all users type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 20:51:27 2015 From: report at bugs.python.org (Abdullah Hilson) Date: Sun, 20 Sep 2015 18:51:27 +0000 Subject: [issue25196] Installer>Install in user folder by default when you check: for all users In-Reply-To: <1442774913.98.0.448713689083.issue25196@psf.upfronthosting.co.za> Message-ID: <1442775087.9.0.266404721346.issue25196@psf.upfronthosting.co.za> Abdullah Hilson added the comment: I am using windows 10, latests updates. Another problem with the installer: It don' t set environnement variable even when checked ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 21:09:34 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 20 Sep 2015 19:09:34 +0000 Subject: [issue25180] Tools/parser/unparse.py needs to be updated for f-strings In-Reply-To: <1442690243.97.0.917526078175.issue25180@psf.upfronthosting.co.za> Message-ID: <20150920190930.94109.42884@psf.io> Roundup Robot added the comment: New changeset 2fcd2540ab97 by Eric V. Smith in branch 'default': Issue 25180: Fix Tools/parser/unparse.py for f-strings. Patch by Martin Panter. https://hg.python.org/cpython/rev/2fcd2540ab97 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 21:10:18 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sun, 20 Sep 2015 19:10:18 +0000 Subject: [issue25180] Tools/parser/unparse.py needs to be updated for f-strings In-Reply-To: <1442690243.97.0.917526078175.issue25180@psf.upfronthosting.co.za> Message-ID: <1442776218.09.0.15546263306.issue25180@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 22:14:52 2015 From: report at bugs.python.org (Matthias Bussonnier) Date: Sun, 20 Sep 2015 20:14:52 +0000 Subject: [issue25197] Allow documentation switcher to change url to /3/ and /dev/ Message-ID: <1442780092.62.0.798906880968.issue25197@psf.upfronthosting.co.za> New submission from Matthias Bussonnier: The current documentation version switcher does not allow to get back to the `python.org/3/..` and `python.org/dev/...` url who permanently track the stable/developement release of Python the attached patch allows that and should permit in the long term less link on the internet to be out of date. ---------- assignee: docs at python components: Documentation files: docp.patch keywords: patch messages: 251177 nosy: docs at python, mbussonn priority: normal severity: normal status: open title: Allow documentation switcher to change url to /3/ and /dev/ type: enhancement Added file: http://bugs.python.org/file40529/docp.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 22:20:14 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 20 Sep 2015 20:20:14 +0000 Subject: [issue25145] urllib how-to should be updated to remove PyGoogle In-Reply-To: <1442439158.29.0.495500663722.issue25145@psf.upfronthosting.co.za> Message-ID: <1442780414.15.0.0552998633837.issue25145@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 22:52:45 2015 From: report at bugs.python.org (Davin Potts) Date: Sun, 20 Sep 2015 20:52:45 +0000 Subject: [issue25169] multiprocess documentation In-Reply-To: <1442588076.4.0.907099744388.issue25169@psf.upfronthosting.co.za> Message-ID: <1442782365.32.0.150338744326.issue25169@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- stage: -> patch review type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 23:22:53 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 20 Sep 2015 21:22:53 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1442784173.79.0.591380759202.issue18967@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Sep 20 23:27:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 20 Sep 2015 21:27:53 +0000 Subject: [issue20525] Got compiler warning when compiling readline module In-Reply-To: <1391673492.51.0.068271536657.issue20525@psf.upfronthosting.co.za> Message-ID: <1442784473.2.0.269446253777.issue20525@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 00:21:08 2015 From: report at bugs.python.org (Davin Potts) Date: Sun, 20 Sep 2015 22:21:08 +0000 Subject: [issue22872] multiprocessing.Queue raises AssertionError In-Reply-To: <1415986488.54.0.734820295311.issue22872@psf.upfronthosting.co.za> Message-ID: <1442787668.04.0.553404775853.issue22872@psf.upfronthosting.co.za> Davin Potts added the comment: The proposed patch would potentially break existing code which anticipates the current behavior. The potential negative impact means this particular proposed patch is not viable. Choices forward include: (1) better documenting the existing, established implementation behavior (perhaps having the assert provide a more informative message), or (2) altering the behavior in a new release version (perhaps 3.6 when it comes) and documenting that change appropriately there. As to what sort of exception we should expect in this situation, unfortunately comparing to the queue module's Queue does not help guide expectations much since it does not have need of a close(). Of the two above options, I'm more inclined towards the first. Does @Joseph.Siddall have other motivations that helped motivate this suggested improvement? ---------- stage: patch review -> type: behavior -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 00:27:32 2015 From: report at bugs.python.org (Davin Potts) Date: Sun, 20 Sep 2015 22:27:32 +0000 Subject: [issue18620] multiprocessing page leaves out important part of Pool example In-Reply-To: <1375389044.82.0.349700607179.issue18620@psf.upfronthosting.co.za> Message-ID: <1442788052.83.0.633206630375.issue18620@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 00:30:06 2015 From: report at bugs.python.org (Davin Potts) Date: Sun, 20 Sep 2015 22:30:06 +0000 Subject: [issue25169] multiprocess documentation In-Reply-To: <1442588076.4.0.907099744388.issue25169@psf.upfronthosting.co.za> Message-ID: <1442788206.92.0.193516752222.issue25169@psf.upfronthosting.co.za> Davin Potts added the comment: Good catch and agreed this should be cleaned up. Patch looks good to me and given its nature is probably all we need although it's probably worth combining this minor documentation update so that it gets applied with some other documentation patch(es) at the same time. ---------- nosy: +davin versions: +Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 00:31:22 2015 From: report at bugs.python.org (Davin Potts) Date: Sun, 20 Sep 2015 22:31:22 +0000 Subject: [issue25169] multiprocessing docs example still refs os.getppid as unix-only In-Reply-To: <1442588076.4.0.907099744388.issue25169@psf.upfronthosting.co.za> Message-ID: <1442788282.21.0.273057187718.issue25169@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- title: multiprocess documentation -> multiprocessing docs example still refs os.getppid as unix-only _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 00:42:16 2015 From: report at bugs.python.org (Eric V. Smith) Date: Sun, 20 Sep 2015 22:42:16 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442788936.05.0.405715000461.issue25092@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 00:52:50 2015 From: report at bugs.python.org (Zachary Ware) Date: Sun, 20 Sep 2015 22:52:50 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442789570.36.0.951025997771.issue25092@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- keywords: +3.5regression _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 01:46:01 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 20 Sep 2015 23:46:01 +0000 Subject: [issue25145] urllib how-to should be updated to remove PyGoogle In-Reply-To: <1442439158.29.0.495500663722.issue25145@psf.upfronthosting.co.za> Message-ID: <1442792761.07.0.880979404518.issue25145@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 02:06:17 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 00:06:17 +0000 Subject: [issue16893] Generate Idle help from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <20150921000612.94109.81188@psf.io> Roundup Robot added the comment: New changeset 4038508240a1 by Terry Jan Reedy in branch '2.7': Issue #16893: Replace help.txt with idle.html for Idle doc display. https://hg.python.org/cpython/rev/4038508240a1 New changeset 52510bc368f8 by Terry Jan Reedy in branch '2.7': Issue #16893: include new files https://hg.python.org/cpython/rev/52510bc368f8 New changeset 2d808b72996d by Terry Jan Reedy in branch '3.4': Issue #16893: Replace help.txt with idle.html for Idle doc display. https://hg.python.org/cpython/rev/2d808b72996d New changeset e66fbfa282c6 by Terry Jan Reedy in branch '2.7': Issue #16893: whitespace in idle.html. https://hg.python.org/cpython/rev/e66fbfa282c6 New changeset 9b79a4901069 by Terry Jan Reedy in branch '3.4': Issue #16893: whitespace in idle.html. https://hg.python.org/cpython/rev/9b79a4901069 New changeset 1107e3ee6103 by Terry Jan Reedy in branch '2.7': Issue #16893: whitespace in help.py. https://hg.python.org/cpython/rev/1107e3ee6103 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 02:07:47 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 21 Sep 2015 00:07:47 +0000 Subject: [issue25198] Idle: improve idle.html help viewer. Message-ID: <1442794067.12.0.0580996406415.issue25198@psf.upfronthosting.co.za> New submission from Terry J. Reedy: I just pushed the new viewer as part of #16893. Possible improvements: * Font size should initially reflect user's size choice. Possibly change with control-mousewheel. (Possible same for edit windows.) * Make within-file links work. * Make Find ^F work, even without menu entry. * Possible immediate bug fixes. ---------- assignee: terry.reedy messages: 251181 nosy: markroseman, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle: improve idle.html help viewer. type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 03:02:14 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 21 Sep 2015 01:02:14 +0000 Subject: [issue16893] Generate Idle help from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1442797334.79.0.700201879686.issue16893@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I committed a patch that works well enough for release as it. I attached the diff for changed files in case anyone wants to view in Rietveld. Still to do for this issue: * Automate getting the 2.7 and earliest 3.x idle.html copied to idlelib and whitespace-normalized. (Commit/push should stay manual.) Several lines have 1 to many blanks at the end, while the file lacks a final \n. See e66fbfa282c6. (These anomalies come from Sphinx; idle.rst has been normalized to be checked in.) I have a .bat file that builds any and copies as needed. I will to add a pass through Idle's trailing-whitespace deleter, which did just what was needed to commit. (Patchcheck.normalize_docs_whitespace does a here unneeded comparision (always unequal), creates an unwanted and nuisance .bak, and does not appear to work when the last list has no '\n'.) When I have automation working for me, I would like to add make targets for others to use (Zach's patch 4). * Edit idle.rst I will push NEWS and idlelib.NEWS entries separately, along with others for Idle. I opened new issue #25198 for further viewer improvements (and bug fixes, if any). ---------- Added file: http://bugs.python.org/file40530/htmlhelp.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 03:04:45 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 21 Sep 2015 01:04:45 +0000 Subject: [issue25199] Idle: add cross-references from and to macosxSupport Message-ID: <1442797485.62.0.138053002868.issue25199@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: terry.reedy nosy: markroseman, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle: add cross-references from and to macosxSupport type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 03:18:56 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 21 Sep 2015 01:18:56 +0000 Subject: [issue25192] deque append and appendleft should return value if maxlen set In-Reply-To: <1442738182.66.0.606955570535.issue25192@psf.upfronthosting.co.za> Message-ID: <1442798336.27.0.484233878683.issue25192@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Sorry, Alun but I going to decline this feature request. It has been considered before and that path wasn't taken for several reasons. 1) with the current api, it isn't hard to fetch the first value before appending, 2) in possible use cases such as a moving average computation it didn't make the code better (i.e. x==d[0]; d.append(y)), 3) list.append append is well known to alway return None (Guido considers that to be very informative about how the language works) so having deque.append return a value just looks weird to experienced Python programmers, and 4) it isn't entirely clear what the semantics should be if the deque hasn't yet reached its maximum length (it would be incorrect to assign None to x because that is a possible legitimate element of a deque and the alternative or raising an exception is also awkward, making it necessary to wrap append calls in a try/except). ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 03:25:22 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 21 Sep 2015 01:25:22 +0000 Subject: [issue25199] Idle: add cross-references from and to macosxSupport Message-ID: <1442798722.75.0.48115840252.issue25199@psf.upfronthosting.co.za> New submission from Terry J. Reedy: After changing EditorWindow.EditorWindow.help_dialog for #16893, I forgot, until remined by Mark, to make the corresponding change in macosxSupport..help_dialog. After doing so, I added to the former file # edit maxosxSupport.overrideRootMenu.help_dialog to match This issue is to put a revised message # Synchronize with . in each member of all pairs that need to by synchronized. There are at least two others, ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 03:28:33 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 21 Sep 2015 01:28:33 +0000 Subject: [issue25193] itertools.accumlate should have an optional initializer argument In-Reply-To: <1442738800.12.0.18115193144.issue25193@psf.upfronthosting.co.za> Message-ID: <1442798913.17.0.522621229578.issue25193@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I know this was considered at the beginning but I am not immediately remembering what the reason was for not doing it (however, I do remember looking to APL to see what was done for their well thought-out implementation of accumulate). AFAIK, the case you sketched-out (computing running totals for four factorial starting from an initial product of 10) just doesn't come-up in the real-world. I'm reluctant to have API feature-creep without strong use cases (it just makes the tool more complicated to learn, remember, and use). When I get a chance, I'll go to github and run a code search to see whether people are routinely have to do a chain() operation to prepend a starting point; if it isn't rare, then there would be a better case for API expansion; if it is rate, then it goes in the it-isn't-worth it category. ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 03:37:52 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 21 Sep 2015 01:37:52 +0000 Subject: [issue25194] Register of Financial Interests for core contributors In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za> Message-ID: <1442799472.06.0.64276819385.issue25194@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, I think this is bad idea and opens a can of worms. Occasionally, I'm consulting and under NDA or my clients don't want they're doing disclosed. Also, I feel this is a transgression into my personal life. My financial affairs are my own business and I want my contributions to be evaluated on their merits rather than on who I taught a Python course to or a commercial project that I may have participated in. I'm already sensitive to this. As a Certified Public Accountant, the state I'm live in thinks that "in the public interest" I am required to have my home address listed on a public website and that my fingerprints be kept on file in the U.S. criminal database. I would sooner quit being a core developer that be required by you to register my financial interests. That is too personal and I won't do it. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 03:46:04 2015 From: report at bugs.python.org (Diego Palharini) Date: Mon, 21 Sep 2015 01:46:04 +0000 Subject: [issue25200] bug on re.search using the char ,-: Message-ID: <1442799964.46.0.602494976102.issue25200@psf.upfronthosting.co.za> New submission from Diego Palharini: Using the packet re for regular expressions I found a strange behavior with the following command: re.search("[,-:]","89") it returns that one of those chars exists into the string "89" or whatever number you may use. ---------- components: IDLE messages: 251187 nosy: DPalharini priority: normal severity: normal status: open title: bug on re.search using the char ,-: versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 04:49:40 2015 From: report at bugs.python.org (Davin Potts) Date: Mon, 21 Sep 2015 02:49:40 +0000 Subject: [issue24153] threading/multiprocessing tests fail on chromebook under crouton generated chroots In-Reply-To: <1431212811.34.0.300169078652.issue24153@psf.upfronthosting.co.za> Message-ID: <1442803780.1.0.20772184504.issue24153@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 04:55:56 2015 From: report at bugs.python.org (Davin Potts) Date: Mon, 21 Sep 2015 02:55:56 +0000 Subject: [issue21162] code in multiprocessing.pool freeze if inside some code from scikit-learn (and probably liblinear) executed on ubuntu 12.04 64 Bit In-Reply-To: <1396716060.12.0.828109902525.issue21162@psf.upfronthosting.co.za> Message-ID: <1442804156.93.0.149749317225.issue21162@psf.upfronthosting.co.za> Davin Potts added the comment: This appears to be highly dependent upon particular versions of operating systems and specific versions of various libraries, some built with certain options. It does not appear to be an issue in multiprocessing itself. @Ivan.K: Unless there is a clear example of how this issue can be reproduced with multiprocessing, I think the appropriate thing to do is close this issue as not a bug with multiprocessing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 04:56:26 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 02:56:26 +0000 Subject: [issue25199] Idle: add cross-references from and to macosxSupport In-Reply-To: <1442798722.75.0.48115840252.issue25199@psf.upfronthosting.co.za> Message-ID: <20150921025623.81631.97607@psf.io> Roundup Robot added the comment: New changeset 884f15dc26f0 by Terry Jan Reedy in branch '2.7': Issue #25199: Idle: add synchronization comments for future maintainers. https://hg.python.org/cpython/rev/884f15dc26f0 New changeset a2e782188db6 by Terry Jan Reedy in branch '3.4': Issue #25199: Idle: add synchronization comments for future maintainers. https://hg.python.org/cpython/rev/a2e782188db6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 04:58:15 2015 From: report at bugs.python.org (Davin Potts) Date: Mon, 21 Sep 2015 02:58:15 +0000 Subject: [issue21345] multiprocessing.Pool._handle_workers sleeps too long In-Reply-To: <1398355364.53.0.447682013962.issue21345@psf.upfronthosting.co.za> Message-ID: <1442804295.46.0.391262713828.issue21345@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 05:00:59 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 21 Sep 2015 03:00:59 +0000 Subject: [issue25199] Idle: add cross-references from and to macosxSupport In-Reply-To: <1442798722.75.0.48115840252.issue25199@psf.upfronthosting.co.za> Message-ID: <1442804459.59.0.356401142413.issue25199@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I did not find anything other function pairs. If either of you think of any similar comments to add, reopen this or open a new issue. ---------- keywords: +patch resolution: -> fixed stage: needs patch -> resolved status: open -> closed Added file: http://bugs.python.org/file40531/mac-cross-ref.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 05:05:11 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 21 Sep 2015 03:05:11 +0000 Subject: [issue25194] Register of Financial Interests for core contributors In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za> Message-ID: <1442804711.57.0.231113319863.issue25194@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- Removed message: http://bugs.python.org/msg251186 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 05:06:16 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 03:06:16 +0000 Subject: [issue16893] Generate Idle help from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <20150921030612.82638.37811@psf.io> Roundup Robot added the comment: New changeset e749080fa0f9 by Terry Jan Reedy in branch '2.7': Issue #16893: finish deprecation. https://hg.python.org/cpython/rev/e749080fa0f9 New changeset ff0270e9bdfb by Terry Jan Reedy in branch '3.4': Issue #16893: finish deprecation. https://hg.python.org/cpython/rev/ff0270e9bdfb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 05:06:49 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 21 Sep 2015 03:06:49 +0000 Subject: [issue25194] Register of Financial Interests for core contributors In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za> Message-ID: <1442804809.05.0.767487920806.issue25194@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I would object to any new requirement to disclose any information that I consider to be private or personal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 05:11:26 2015 From: report at bugs.python.org (Davin Potts) Date: Mon, 21 Sep 2015 03:11:26 +0000 Subject: [issue24427] subclass of multiprocessing Connection segfault upon attribute acces In-Reply-To: <1433964415.99.0.226244144163.issue24427@psf.upfronthosting.co.za> Message-ID: <1442805086.35.0.315897952031.issue24427@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 05:13:35 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 03:13:35 +0000 Subject: [issue25169] multiprocessing docs example still refs os.getppid as unix-only In-Reply-To: <1442588076.4.0.907099744388.issue25169@psf.upfronthosting.co.za> Message-ID: <20150921031332.3644.44864@psf.io> Roundup Robot added the comment: New changeset 60b0bc23c69e by Berker Peksag in branch '3.4': Issue #25169: os.getppid() is available on Windows since Python 3.2. https://hg.python.org/cpython/rev/60b0bc23c69e New changeset c6ccef432dc2 by Berker Peksag in branch '3.5': Issue #25169: os.getppid() is available on Windows since Python 3.2. https://hg.python.org/cpython/rev/c6ccef432dc2 New changeset 71a6d4c7cd01 by Berker Peksag in branch 'default': Issue #25169: os.getppid() is available on Windows since Python 3.2. https://hg.python.org/cpython/rev/71a6d4c7cd01 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 05:16:04 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 21 Sep 2015 03:16:04 +0000 Subject: [issue25169] multiprocessing docs example still refs os.getppid as unix-only In-Reply-To: <1442588076.4.0.907099744388.issue25169@psf.upfronthosting.co.za> Message-ID: <1442805364.66.0.985526739189.issue25169@psf.upfronthosting.co.za> Berker Peksag added the comment: Fixed in 3.4, 3.5 and 3.6. Thanks all! ---------- nosy: +berker.peksag resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 05:18:47 2015 From: report at bugs.python.org (Davin Potts) Date: Mon, 21 Sep 2015 03:18:47 +0000 Subject: [issue23979] Multiprocessing Pool.map pickles arguments passed to workers In-Reply-To: <1429226049.08.0.139422751174.issue23979@psf.upfronthosting.co.za> Message-ID: <1442805527.72.0.905553862694.issue23979@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 05:52:10 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 03:52:10 +0000 Subject: [issue23484] SemLock acquire() keyword arg 'blocking' is invalid In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za> Message-ID: <20150921035207.115438.19650@psf.io> Roundup Robot added the comment: New changeset f3faf0f355e0 by Berker Peksag in branch '3.4': Issue #23484: Document differences between synchronization primitives of https://hg.python.org/cpython/rev/f3faf0f355e0 New changeset 6cd030099966 by Berker Peksag in branch '3.5': Issue #23484: Document differences between synchronization primitives of https://hg.python.org/cpython/rev/6cd030099966 New changeset 020377a15708 by Berker Peksag in branch 'default': Issue #23484: Document differences between synchronization primitives of https://hg.python.org/cpython/rev/020377a15708 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 06:05:21 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 21 Sep 2015 04:05:21 +0000 Subject: [issue25201] lock of multiprocessing.Value is not a keyword-only argument Message-ID: <1442808321.25.0.819772413422.issue25201@psf.upfronthosting.co.za> New submission from Berker Peksag: >From https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Value Note that lock is a keyword-only argument. But the signature of Value (in Lib/multiprocessing/context.py) def Value(self, typecode_or_type, *args, lock=True): and (in Lib/multiprocessing/sharedctypes.py) def Value(typecode_or_type, *args, lock=True, ctx=None): I'd suggest to remove that part of the documentation in 3.4+. We can also make it a keyword-only argument in Python 3.6. That will make the API more similar with https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Array ---------- assignee: docs at python components: Documentation messages: 251196 nosy: berker.peksag, davin, docs at python, sbt priority: normal severity: normal stage: needs patch status: open title: lock of multiprocessing.Value is not a keyword-only argument type: behavior versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 06:15:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 04:15:49 +0000 Subject: [issue23484] SemLock acquire() keyword arg 'blocking' is invalid In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za> Message-ID: <20150921041546.11704.7230@psf.io> Roundup Robot added the comment: New changeset 92350a2a8b08 by Berker Peksag in branch '2.7': Issue #23484: Document differences between synchronization primitives of https://hg.python.org/cpython/rev/92350a2a8b08 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 06:17:00 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 21 Sep 2015 04:17:00 +0000 Subject: [issue23484] SemLock acquire() keyword arg 'blocking' is invalid In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za> Message-ID: <1442809020.46.0.723669311651.issue23484@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks, Teodor and Davin! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 06:25:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Sep 2015 04:25:28 +0000 Subject: [issue25200] bug on re.search using the char ,-: In-Reply-To: <1442799964.46.0.602494976102.issue25200@psf.upfronthosting.co.za> Message-ID: <1442809528.43.0.795043898318.issue25200@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is how regular expressions work. https://docs.python.org/3/library/re.html#regular-expression-syntax Ranges of characters can be indicated by giving two characters and separating them by a '-', for example [a-z] will match any lowercase ASCII letter, [0-5][0-9] will match all the two-digits numbers from 00 to 59, and [0-9A-Fa-f] will match any hexadecimal digit. If - is escaped (e.g. [a\-z]) or if it?s placed as the first or last character (e.g. [a-]), it will match a literal '-'. ---------- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 06:56:10 2015 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 21 Sep 2015 04:56:10 +0000 Subject: [issue25194] Register of Financial Interests for core contributors In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za> Message-ID: <1442811370.64.0.38122211795.issue25194@psf.upfronthosting.co.za> Ezio Melotti added the comment: This is not a requirement though: +CPython core contributors are encouraged, but not required, to disclose the +means by which they fund their ability to contribute time to CPython core +development. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 07:14:58 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 21 Sep 2015 05:14:58 +0000 Subject: [issue25193] itertools.accumlate should have an optional initializer argument In-Reply-To: <1442738800.12.0.18115193144.issue25193@psf.upfronthosting.co.za> Message-ID: <1442812498.97.0.311974541533.issue25193@psf.upfronthosting.co.za> Raymond Hettinger added the comment: AFAICT other implementations of accumulators do not have an initializer. See: * http://docs.scipy.org/doc/numpy/reference/generated/numpy.ufunc.accumulate.html * https://stat.ethz.ch/R-manual/R-devel/library/base/html/cumsum.html * http://microapl.com/apl/apl_concepts_chapter5.html \+ 1 2 3 4 5 1 3 6 10 15 * https://reference.wolfram.com/language/ref/Accumulate.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 07:23:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Sep 2015 05:23:37 +0000 Subject: [issue25193] itertools.accumulate should have an optional initializer argument In-Reply-To: <1442738800.12.0.18115193144.issue25193@psf.upfronthosting.co.za> Message-ID: <1442813017.88.0.72654681937.issue25193@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- title: itertools.accumlate should have an optional initializer argument -> itertools.accumulate should have an optional initializer argument _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 07:44:50 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 05:44:50 +0000 Subject: [issue24861] deprecate importing components of IDLE In-Reply-To: <1439500309.93.0.862265399846.issue24861@psf.upfronthosting.co.za> Message-ID: <20150921054447.115366.56395@psf.io> Roundup Robot added the comment: New changeset b7bbb2c1e1f9 by Terry Jan Reedy in branch '2.7': Issue #24861: Add docstring to idlelib.__init__ with 'private' warning. https://hg.python.org/cpython/rev/b7bbb2c1e1f9 New changeset 084a8813f05f by Terry Jan Reedy in branch '3.4': Issue #24861: Add docstring to idlelib.__init__ with 'private' warning. https://hg.python.org/cpython/rev/084a8813f05f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 07:48:38 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 21 Sep 2015 05:48:38 +0000 Subject: [issue25138] test_socket: socket.EAI_NODATA doesn't exist on FreeBSD In-Reply-To: <1442386365.65.0.414098178984.issue25138@psf.upfronthosting.co.za> Message-ID: <1442814518.45.0.650566329915.issue25138@psf.upfronthosting.co.za> Martin Panter added the comment: Looking at this more closely, the check seems to be there just to check if basic DNS lookups are working. It was added for Issue 12804. One option might be to replace it with a support.transient_internet() handler: # Check for internet access before running test (issue #12804). with support.transient_internet('python.org'): socket.gethostbyname('python.org') # these should all be successful ... According to the socket module source code, gethostbyname() calls the OS-level getaddrinfo() rather gethostbyname(), hence the ?gaierror? handling. The error codes that get raised seem to be a platform-dependent mess, but transient_internet() looks like it catches EAI_NONAME, _FAIL, _NODATA and WSANO_DATA (among others). EAI_NODATA seems to have been removed from RFC 3493 and current Posix, but was apparently originally meant to be for looking up records that did exist but (say) did not have any IP v4 addresses. ---------- nosy: +nadeem.vawda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 07:50:59 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 21 Sep 2015 05:50:59 +0000 Subject: [issue24861] deprecate importing components of IDLE In-Reply-To: <1439500309.93.0.862265399846.issue24861@psf.upfronthosting.co.za> Message-ID: <1442814659.63.0.318547804355.issue24861@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Individual files will be handled in separate issues. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 08:00:06 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 21 Sep 2015 06:00:06 +0000 Subject: [issue25201] lock of multiprocessing.Value is not a keyword-only argument In-Reply-To: <1442808321.25.0.819772413422.issue25201@psf.upfronthosting.co.za> Message-ID: <1442815206.39.0.250714584878.issue25201@psf.upfronthosting.co.za> Martin Panter added the comment: I?m not familiar with this module, but I believe ?lock? is indeed keyword-only. If you were to try a positional argument, it would be picked up as part of *args: >>> multiprocessing.Value("I") # Default to 0, lock=True >>> multiprocessing.Value("I", False) # False == 0, still lock=True >>> multiprocessing.Value("I", lock=False) c_uint(0) ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 08:52:13 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 21 Sep 2015 06:52:13 +0000 Subject: [issue25190] Define StringIO seek offset as code point offset In-Reply-To: <1442729712.98.0.451356431809.issue25190@psf.upfronthosting.co.za> Message-ID: <1442818333.87.0.949020098574.issue25190@psf.upfronthosting.co.za> Martin Panter added the comment: I see the _pyio implementation wraps BytesIO with UTF-8 encoding. Perhaps it would be okay to change to UTF-32 encoding (a fixed-length Unicode encoding). That would use more memory, but the C implementation seems to use a Py_UCS4 buffer already. Then you could reimplement seek(), tell(), and truncate() by detaching and rebuilding the TextIOWrapper over the top. Not super efficient, but perhaps that does not matter for the _pyio implementation. The fact that it is so hard to do this (random write access to a large Unicode buffer) in native Python could be another argument to support this in the default StringIO implementation :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 08:55:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Sep 2015 06:55:04 +0000 Subject: [issue25084] remove semi-busy loop in py2.7 threading.Condition.wait(timeout=x) In-Reply-To: <1442748791.49.0.866497957454.issue25084@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Nick Coghlan added the comment: > +1 - after the further discussion, addressing this downstream as a patch specifically to the pthread backend sounds good to me. Cool, I like when we agree :-) @Flavio Grossi: Sorry for you, but it's time to upgrade to Python 3. Twisted made great progress on Python 3 support. For Apache Thrift, maybe you can help them to port the library to Python 3? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 08:59:15 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Sep 2015 06:59:15 +0000 Subject: [issue23177] test_ssl: failures on OpenBSD with LibreSSL In-Reply-To: <1420541656.17.0.750310163886.issue23177@psf.upfronthosting.co.za> Message-ID: <1442818755.88.0.17865258864.issue23177@psf.upfronthosting.co.za> STINNER Victor added the comment: I don't care so much of issues introduced by LibreSSL, I don't understand why they broke the API. For me, it doesn't seem right to have a version different if it's a number or if it's a string: OPENSSL_VERSION_NUMBER should be consistent with OPENSSL_VERSION_INFO. If you propose a patch for Python and it fixes test_ssl, I will apply it :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 09:09:04 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 07:09:04 +0000 Subject: [issue25138] test_socket: socket.EAI_NODATA doesn't exist on FreeBSD In-Reply-To: <1442386365.65.0.414098178984.issue25138@psf.upfronthosting.co.za> Message-ID: <20150921070901.81641.11041@psf.io> Roundup Robot added the comment: New changeset f13a5b5a2824 by Victor Stinner in branch '3.4': Issue #25138: test_socket.test_idna() uses support.transient_internet() instead https://hg.python.org/cpython/rev/f13a5b5a2824 New changeset a7baccf0b1c2 by Victor Stinner in branch '3.5': Merge 3.4 (test_socket, issue #25138) https://hg.python.org/cpython/rev/a7baccf0b1c2 New changeset d8dd06ab00e4 by Victor Stinner in branch 'default': Merge 3.5 (test_socket, issue #25138) https://hg.python.org/cpython/rev/d8dd06ab00e4 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 09:12:31 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Sep 2015 07:12:31 +0000 Subject: [issue25138] test_socket: socket.EAI_NODATA doesn't exist on FreeBSD In-Reply-To: <1442386365.65.0.414098178984.issue25138@psf.upfronthosting.co.za> Message-ID: <1442819551.31.0.937634344084.issue25138@psf.upfronthosting.co.za> STINNER Victor added the comment: > Looking at this more closely, the check seems to be there just to check if basic DNS lookups are working. It was added for Issue 12804. One option might be to replace it with a support.transient_internet() handler: (...) Oh good idea. This context manager sets also a timeout to 30 seconds which can help to skip the test only platforms with flacky internet connections. By the way, I also saw the test failing randomly on the Windows 8.1 buildbot. I hope that support.transient_internet() will also skip the tes on this case. I close the issue since the initial issue is fixed. Thanks Martin for the hint ;) ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 09:14:49 2015 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 21 Sep 2015 07:14:49 +0000 Subject: [issue25047] xml.etree.ElementTree encoding declaration should be capital ('UTF-8') rather than lowercase ('utf-8') In-Reply-To: <1441827818.89.0.928682692456.issue25047@psf.upfronthosting.co.za> Message-ID: <1442819689.3.0.259515502545.issue25047@psf.upfronthosting.co.za> Stefan Behnel added the comment: LGTM ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 09:18:47 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Sep 2015 07:18:47 +0000 Subject: [issue25118] OSError in os.waitpid() on Windows [3.5.0 regression] In-Reply-To: <1442296331.17.0.794192242028.issue25118@psf.upfronthosting.co.za> Message-ID: <1442819927.68.0.627625854855.issue25118@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- keywords: +3.5regression _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 09:18:51 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Sep 2015 07:18:51 +0000 Subject: [issue25155] Windows: datetime.datetime.now() raises an OverflowError for date after year 2038 In-Reply-To: <1442517940.02.0.585598680273.issue25155@psf.upfronthosting.co.za> Message-ID: <1442819931.04.0.894032698524.issue25155@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- keywords: +3.5regression _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 09:18:56 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Sep 2015 07:18:56 +0000 Subject: [issue25150] 3.5: Include/pyatomic.h is incompatible with OpenMP (compilation of the third-party yt module fails on Python 3.5) In-Reply-To: <1442494739.31.0.584117765088.issue25150@psf.upfronthosting.co.za> Message-ID: <1442819936.69.0.239314840499.issue25150@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- keywords: +3.5regression _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 09:19:13 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Sep 2015 07:19:13 +0000 Subject: [issue25095] test_httpservers hangs on 3.5.0, win 7 In-Reply-To: <1442202993.28.0.395084299366.issue25095@psf.upfronthosting.co.za> Message-ID: <1442819953.4.0.332954890976.issue25095@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- keywords: +3.5regression _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 09:19:18 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Sep 2015 07:19:18 +0000 Subject: [issue25114] asynico: add ssl_object extra info In-Reply-To: <1442268047.01.0.688232314675.issue25114@psf.upfronthosting.co.za> Message-ID: <1442819958.08.0.305068372748.issue25114@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- keywords: +3.5regression _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 09:50:32 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 21 Sep 2015 07:50:32 +0000 Subject: [issue25184] "python -m pydoc -w" fails in nondecodable directory In-Reply-To: <1442696845.13.0.851195404942.issue25184@psf.upfronthosting.co.za> Message-ID: <1442821832.94.0.0020049348319.issue25184@psf.upfronthosting.co.za> Martin Panter added the comment: Seems to be caused by the Python directory being non-decodable; the current working directory does not matter. What is going on is ?pydoc? is trying to make a link to a module?s source code, such as /usr/lib/python3.4/pydoc.py For non-decodable paths, the following would work in Firefox: /home/serhiy/py/cpy?thon-3.5/Lib/pydoc.py but since URL percent encoding already uses UTF-8, this scheme isn?t foolproof (e.g. a UTF-8 sequence when the locale is ASCII would be ambiguous). A simpler and more consistent way forward would be an error handler substituting something like this, decoding the surrogate escape code with the ?replace? handler, with the HTML link suppressed: /home/serhiy/py/cpy?thon-3.5/Lib/pydoc.py (invalid filename encoding) ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 10:00:28 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Sep 2015 08:00:28 +0000 Subject: [issue25184] "python -m pydoc -w" fails in nondecodable directory In-Reply-To: <1442696845.13.0.851195404942.issue25184@psf.upfronthosting.co.za> Message-ID: <1442822428.23.0.777401882603.issue25184@psf.upfronthosting.co.za> STINNER Victor added the comment: Technically, I think that it's possible to put bytes in an URL using %HH format. I didn't check if we can retrieve the "raw bytes". ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 11:03:10 2015 From: report at bugs.python.org (Cosimo Lupo) Date: Mon, 21 Sep 2015 09:03:10 +0000 Subject: [issue6331] Add unicode script info to the unicode database In-Reply-To: <1245790259.44.0.08771310344.issue6331@psf.upfronthosting.co.za> Message-ID: <1442826190.81.0.388166407141.issue6331@psf.upfronthosting.co.za> Cosimo Lupo added the comment: I would very much like a `script()` function to be added to the built-in unicodedata module. What's the current status of this issue? Thanks. Cosimo ---------- nosy: +Cosimo Lupo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 11:20:26 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 21 Sep 2015 09:20:26 +0000 Subject: [issue25188] regrtest.py improvement for Profile Guided Optimization builds In-Reply-To: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za> Message-ID: <1442827226.58.0.688657209944.issue25188@psf.upfronthosting.co.za> Changes by Alecsandru Patrascu : ---------- keywords: +patch Added file: http://bugs.python.org/file40532/regrtest_27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 11:20:34 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 21 Sep 2015 09:20:34 +0000 Subject: [issue25188] regrtest.py improvement for Profile Guided Optimization builds In-Reply-To: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za> Message-ID: <1442827234.48.0.78048091647.issue25188@psf.upfronthosting.co.za> Changes by Alecsandru Patrascu : Added file: http://bugs.python.org/file40533/regrtest_36.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 11:23:40 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 21 Sep 2015 09:23:40 +0000 Subject: [issue25188] regrtest.py improvement for Profile Guided Optimization builds In-Reply-To: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za> Message-ID: <1442827420.86.0.870807796788.issue25188@psf.upfronthosting.co.za> Alecsandru Patrascu added the comment: I've added the patches for Python default and 2.7. To apply them please use the command "hg import --no-commit". PGO flag is implemented for both variants (single and multi process). Default in profile-opt will be single process. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 11:38:18 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Mon, 21 Sep 2015 09:38:18 +0000 Subject: [issue25194] Register of Financial Interests for core contributors In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za> Message-ID: <1442828298.64.0.765080356097.issue25194@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: I like the idea, but the phrasings "disclosure" and "financial interests" sound too negative, IMO. Wouldn't it be better to put the emphasis on a) core devs who do this in their free time, b) core devs who would be available for hired work, and c) showing off which companies indirectly support Python via employing core devs and giving them time to do core dev work as part of their job ? Essentially replacing "disclosure" and "financial interests" with "motivation" and "support". See e.g. the list of supporting companies we have for infrastructure (https://www.python.org/psf/league/) as example in a different area. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 11:44:58 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 21 Sep 2015 09:44:58 +0000 Subject: [issue6331] Add unicode script info to the unicode database In-Reply-To: <1245790259.44.0.08771310344.issue6331@psf.upfronthosting.co.za> Message-ID: <1442828698.82.0.600920257109.issue6331@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- versions: +Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 11:48:22 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 21 Sep 2015 09:48:22 +0000 Subject: [issue6331] Add unicode script info to the unicode database In-Reply-To: <1245790259.44.0.08771310344.issue6331@psf.upfronthosting.co.za> Message-ID: <1442828902.25.0.502374220409.issue6331@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 12:35:01 2015 From: report at bugs.python.org (Ezio Melotti) Date: Mon, 21 Sep 2015 10:35:01 +0000 Subject: [issue25194] Register of Financial Interests for core contributors In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za> Message-ID: <1442831701.75.0.832580522703.issue25194@psf.upfronthosting.co.za> Ezio Melotti added the comment: > Wouldn't it be better to put the emphasis on a) core devs who do this > in their free time, b) core devs who would be available for hired work, > and c) showing off which companies indirectly support Python via > employing core devs and giving them time to do core dev work as part of > their job ? I still think that a) and c) should be separate from b). Core devs might be contributing in their free time (i.e. a) or as part as their job (i.e. c), and on top of this they might or might not be available for hired work (i.e. b). > Essentially replacing "disclosure" and "financial interests" with > "motivation" and "support". Agreed. Perhaps even "affiliation" could be used, even though that doesn't imply that the affiliated company supports CPython. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 13:04:53 2015 From: report at bugs.python.org (Ben Mather) Date: Mon, 21 Sep 2015 11:04:53 +0000 Subject: [issue22729] `wait` and `as_completed` depend on private api In-Reply-To: <1414269700.02.0.917285833698.issue22729@psf.upfronthosting.co.za> Message-ID: <1442833493.92.0.692200542506.issue22729@psf.upfronthosting.co.za> Ben Mather added the comment: Sorry for slow response. I completely missed your reply. I was working on a project that used a concurrent.futures thread pool but also needed to listen to responses from a chip-and-pin card reader. Payment sessions operated in three phases: - check with card reader that payment is possible - save payment to database as if it has happened (always best to undercharge in the case of an error) - ask the payment provider to commit the payment Up until confirmation is received, it is entirely possible to cancel the session. Once confirmation is received the session starts trying to commit and you can only really wait for it to finish and then roll back (or break everything). This maps pretty well to the interface of future (though with very different plumbing and with work happening before cancellation stops working) and it made sense to try to write it so that it could interoperate with futures representing tasks running on the thread pool. I tried to add a method which returned a plain concurrent.futures.Future object but couldn't find a way to hook into the cancel method without introducing loads of race conditions. Really it just seemed wrong that I had an object that quacked like a duck but wasn't a duck because real ducks communicated over a hidden side channel. The card reader library is open source and mostly functional. The class is in: https://github.com/bwhmather/python-payment-terminal/blob/develop/payment_terminal/drivers/bbs/payment_session.py I'm sure there are other places where this sort of interoperability would be useful. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 14:02:37 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 21 Sep 2015 12:02:37 +0000 Subject: [issue25181] Tests failed in nondecodable directory In-Reply-To: <1442694095.16.0.133026836681.issue25181@psf.upfronthosting.co.za> Message-ID: <1442836957.46.0.57664792797.issue25181@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 14:02:51 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 21 Sep 2015 12:02:51 +0000 Subject: [issue25182] python -v crashes in nonencodable directory In-Reply-To: <1442695726.04.0.992972651572.issue25182@psf.upfronthosting.co.za> Message-ID: <1442836971.84.0.928938920608.issue25182@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 14:03:02 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 21 Sep 2015 12:03:02 +0000 Subject: [issue25183] python -m inspect --details fails in nondecodable directory In-Reply-To: <1442696260.6.0.26315436798.issue25183@psf.upfronthosting.co.za> Message-ID: <1442836982.75.0.091679754992.issue25183@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 14:03:14 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 21 Sep 2015 12:03:14 +0000 Subject: [issue25184] "python -m pydoc -w" fails in nondecodable directory In-Reply-To: <1442696845.13.0.851195404942.issue25184@psf.upfronthosting.co.za> Message-ID: <1442836994.62.0.960571332071.issue25184@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 14:04:55 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 21 Sep 2015 12:04:55 +0000 Subject: [issue25185] Inconsistency between venv and site In-Reply-To: <1442698159.95.0.304023821424.issue25185@psf.upfronthosting.co.za> Message-ID: <1442837095.33.0.833198779364.issue25185@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 14:05:27 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 12:05:27 +0000 Subject: [issue25122] test_eintr randomly fails on FreeBSD In-Reply-To: <1442311779.01.0.43728096223.issue25122@psf.upfronthosting.co.za> Message-ID: <20150921120524.11696.11936@psf.io> Roundup Robot added the comment: New changeset 3184c43627f5 by Victor Stinner in branch '3.5': Issue #25122: test_eintr: the FreeBSD fix will be released in FreeBSD 10.3 https://hg.python.org/cpython/rev/3184c43627f5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 14:06:00 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 21 Sep 2015 12:06:00 +0000 Subject: [issue25186] Don't duplicate _verbose_message in importlib._bootstrap and _bootstrap_external In-Reply-To: <1442703732.01.0.764614399851.issue25186@psf.upfronthosting.co.za> Message-ID: <1442837160.73.0.279575137516.issue25186@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 14:09:07 2015 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 21 Sep 2015 12:09:07 +0000 Subject: [issue25193] itertools.accumulate should have an optional initializer argument In-Reply-To: <1442738800.12.0.18115193144.issue25193@psf.upfronthosting.co.za> Message-ID: <1442837347.6.0.593968404253.issue25193@psf.upfronthosting.co.za> Mark Dickinson added the comment: A couple of observations: 1. Haskell's (rough) equivalents would be `mapAccumL` and `mapAccumR`, which do take an initializer [1]. The signature for both functions is something like: (acc -> b -> (acc, c)) -> acc -> [b] -> (acc, [c]). 2. In the particular case of NumPy, I've found np.cumsum a pain to use on multiple occasions because of the missing left-hand point in the result. Grepping through a couple of recent (real-world) projects produces code like: summed_widths = cumsum(hstack(([0], widths[:-1]))) and cumulative_segments = np.insert(np.cumsum(segment_lengths), 0, 0.0) where that extra missing value is having to be inserted either in the input list or the output list. OTOH, none of those projects is natural fit for itertools, so changing itertools wouldn't help them directly. [1] https://www.haskell.org/hoogle/?hoogle=mapAccumL ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 14:13:00 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Sep 2015 12:13:00 +0000 Subject: [issue24520] Stop using deprecated floating-point environment functions on FreeBSD In-Reply-To: <1435417703.06.0.0329828025601.issue24520@psf.upfronthosting.co.za> Message-ID: <1442837580.12.0.692350306335.issue24520@psf.upfronthosting.co.za> STINNER Victor added the comment: It looks like fpsetmask() was deprecated since many years, and that fedisableexcept() is available since FreeBSD 5.3. Since we try to support FreeBSD 9, it's fine to drop support of FreeBSD < 5.3. I'm concerned by the "CAVEATS" section below. Should we put "#pragma STDC FENV_ACCESS ON" in all .c file using a C double? @skrah: I saw this pragma in Modules/_decimal/libmpdec/mpdecimal.c. Any idea if applying this patch is fine? Maybe we can start by applying it to the default branch? If this patch is required to support arm64, I think that it's ok to apply it to 2.7, 3.4 and 3.5 since we still accept changes to fix platform compatibility issues. http://www.unix.com/man-page/freebsd/3/fpsetmask/ --- DESCRIPTION The routines described herein are deprecated. New code should use the functionality provided by fenv(3). --- http://www.unix.com/man-page/freebsd/3/fenv/ --- HISTORY The header first appeared in FreeBSD 5.3. It supersedes the non-standard routines defined in and documented in fpgetround(3). CAVEATS The FENV_ACCESS pragma can be enabled with #pragma STDC FENV_ACCESS ON --- ---------- nosy: +haypo, skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 14:16:41 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 21 Sep 2015 12:16:41 +0000 Subject: [issue25047] xml.etree.ElementTree encoding declaration should be capital ('UTF-8') rather than lowercase ('utf-8') In-Reply-To: <1441827818.89.0.928682692456.issue25047@psf.upfronthosting.co.za> Message-ID: <1442837801.25.0.355682579216.issue25047@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 14:19:01 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 21 Sep 2015 12:19:01 +0000 Subject: [issue24520] Stop using deprecated floating-point environment functions on FreeBSD In-Reply-To: <1435417703.06.0.0329828025601.issue24520@psf.upfronthosting.co.za> Message-ID: <1442837941.58.0.510094447414.issue24520@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 14:54:27 2015 From: report at bugs.python.org (takayuki) Date: Mon, 21 Sep 2015 12:54:27 +0000 Subject: [issue24657] CGIHTTPServer module discard continuous '/' letters from params given by GET method. In-Reply-To: <1437187776.37.0.855244973055.issue24657@psf.upfronthosting.co.za> Message-ID: <1442840067.26.0.494438114407.issue24657@psf.upfronthosting.co.za> takayuki added the comment: This bug seems to remain in Python 3.5.0. How to reproduce: 1. Save the attached cgitest.py into cgi-bin directory and changed it to executable file by "chmod +x cgitest.py" 2. Run CGIHTTPRequestHandler [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import http.server >>> http.server.test(HandlerClass=http.server.CGIHTTPRequestHandler) 3. Visit http://localhost:8000/cgi-bin/cgitest.py by any browser. 4. Input "a/b/c//d//e///f///g" to form named "p". 5. The continuous slash letters are trimed and "a/b/c/d/e/f/g" is given to cgitest.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 15:00:15 2015 From: report at bugs.python.org (Simeon Warner) Date: Mon, 21 Sep 2015 13:00:15 +0000 Subject: [issue25047] xml.etree.ElementTree encoding declaration should be capital ('UTF-8') rather than lowercase ('utf-8') In-Reply-To: <1441827818.89.0.928682692456.issue25047@psf.upfronthosting.co.za> Message-ID: <1442840415.93.0.819353813681.issue25047@psf.upfronthosting.co.za> Simeon Warner added the comment: Path looks fine and seems to work as expected -- Simeon ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 15:00:35 2015 From: report at bugs.python.org (Simeon Warner) Date: Mon, 21 Sep 2015 13:00:35 +0000 Subject: [issue25047] xml.etree.ElementTree encoding declaration should be capital ('UTF-8') rather than lowercase ('utf-8') In-Reply-To: <1441827818.89.0.928682692456.issue25047@psf.upfronthosting.co.za> Message-ID: <1442840435.33.0.588829065432.issue25047@psf.upfronthosting.co.za> Simeon Warner added the comment: s/Path/Patch/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 15:17:04 2015 From: report at bugs.python.org (Lauri Kajan) Date: Mon, 21 Sep 2015 13:17:04 +0000 Subject: [issue25202] with-statement doesn't release file handle after exception Message-ID: <1442841424.93.0.271808876405.issue25202@psf.upfronthosting.co.za> New submission from Lauri Kajan: Hi all, I found out that handle to a file opened with with-statement is not released in all cases. I'm trying to delete a file when space on a disk is filled (0 bit left) by writing this file. I catch the IOError 28 to figure this out. I write the file within the with-statement that is wrapped with try except. In the except block I try to delete the file but the handle to the file is not released. In the following code fill-file can't be deleted because the file is still open. I have described the problem also in stackoverflow [1]. # I recommend filling the disk almost full with some better tool. import os import errno fill = 'J:/fill.txt' try: with open(fill, 'wb') as f: while True: n = f.write(b"\0") except IOError as e: if e.errno == errno.ENOSPC: os.remove(fill) This gives the following traceback: Traceback (most recent call last): File "nospacelef.py", line 8, in n = f.write(b"\0") IOError: [Errno 28] No space left on device During handling of the above exception, another exception occurred: Traceback (most recent call last): File "nospacelef.py", line 8, in n = f.write(b"\0") IOError: [Errno 28] No space left on device During handling of the above exception, another exception occurred: Traceback (most recent call last): File "nospacelef.py", line 11, in os.remove(fill) WindowsError: [Error 32] The process cannot access the file because it is being used by another process: 'J:/fill.txt' [1] http://stackoverflow.com/questions/32690018/cant-delete-a-file-after-no-space-left-on-device ---------- components: IO messages: 251225 nosy: Lauri Kajan priority: normal severity: normal status: open title: with-statement doesn't release file handle after exception type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 15:19:36 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Sep 2015 13:19:36 +0000 Subject: [issue25202] Windows: with-statement doesn't release file handle after exception on "No space left on device" error In-Reply-To: <1442841424.93.0.271808876405.issue25202@psf.upfronthosting.co.za> Message-ID: <1442841576.01.0.853062963793.issue25202@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: with-statement doesn't release file handle after exception -> Windows: with-statement doesn't release file handle after exception on "No space left on device" error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 15:19:43 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Sep 2015 13:19:43 +0000 Subject: [issue25202] Windows: with-statement doesn't release file handle after exception on "No space left on device" error In-Reply-To: <1442841424.93.0.271808876405.issue25202@psf.upfronthosting.co.za> Message-ID: <1442841583.05.0.392018166958.issue25202@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 15:37:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Sep 2015 13:37:36 +0000 Subject: [issue25184] "python -m pydoc -w" fails in nondecodable directory In-Reply-To: <1442696845.13.0.851195404942.issue25184@psf.upfronthosting.co.za> Message-ID: <1442842656.34.0.749769588877.issue25184@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: We could use url = urllib.parse.quote_from_bytes(os.fsencode(path)) on Posix systems, but I heart that on Windows os.fsencode() can irreversible spoil file names (replace unencodable characters with '?'). On other side, I'm not sure that Windows unicode path can't contain lone surrogates. In this case we should use the 'surrogatepass' error handler (at least it allow to restore the path in principle). Here is a patch that tries to handle undecodable and unencodable paths. Need to test it on Windows. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file40534/pydoc_undecodabple_path.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 15:44:56 2015 From: report at bugs.python.org (Lauri Kajan) Date: Mon, 21 Sep 2015 13:44:56 +0000 Subject: [issue25202] Windows: with-statement doesn't release file handle after exception on "No space left on device" error In-Reply-To: <1442841424.93.0.271808876405.issue25202@psf.upfronthosting.co.za> Message-ID: <1442843096.07.0.343896162583.issue25202@psf.upfronthosting.co.za> Changes by Lauri Kajan : ---------- versions: +Python 3.2 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 16:14:24 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 21 Sep 2015 14:14:24 +0000 Subject: [issue25124] No single .msi available for 3.5 release In-Reply-To: <1442315365.32.0.493745807723.issue25124@psf.upfronthosting.co.za> Message-ID: <1442844864.76.0.335042424456.issue25124@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +loewis, skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 16:42:49 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 21 Sep 2015 14:42:49 +0000 Subject: [issue24520] Stop using deprecated floating-point environment functions on FreeBSD In-Reply-To: <1435417703.06.0.0329828025601.issue24520@psf.upfronthosting.co.za> Message-ID: <1442846569.9.0.0985151677741.issue24520@psf.upfronthosting.co.za> Stefan Krah added the comment: In theory we should set FENV_ACCESS whenever the control word is changed (C99): "If part of a program tests floating-point status flags, sets floating-point control modes, or runs under non-default mode settings, but was translated with the state for the FENV_ACCESS pragma "off", the behavior is undefined." In practice gcc ignores the pragma, icc and cl.exe use it, not sure about clang. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 16:53:20 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Sep 2015 14:53:20 +0000 Subject: [issue24520] Stop using deprecated floating-point environment functions on FreeBSD In-Reply-To: <1435417703.06.0.0329828025601.issue24520@psf.upfronthosting.co.za> Message-ID: <1442847200.74.0.392006639658.issue24520@psf.upfronthosting.co.za> STINNER Victor added the comment: FYI in Python/pytime.c, I put a lot of "volatile double" when tests started to fail on some platforms. It's inefficient, but it's easier than teaching how to disable optimizations on each different compiler :-p ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 16:57:46 2015 From: report at bugs.python.org (eryksun) Date: Mon, 21 Sep 2015 14:57:46 +0000 Subject: [issue25202] Windows: with-statement doesn't release file handle after exception on "No space left on device" error In-Reply-To: <1442841424.93.0.271808876405.issue25202@psf.upfronthosting.co.za> Message-ID: <1442847466.3.0.714824927414.issue25202@psf.upfronthosting.co.za> eryksun added the comment: See issue 16597. This wasn't fixed for 3.2, so it won't close the file if flush() fails. You'll either have to work around this or upgrade to 3.3+. ---------- nosy: +eryksun resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 16:58:15 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 21 Sep 2015 14:58:15 +0000 Subject: [issue24520] Stop using deprecated floating-point environment functions on FreeBSD In-Reply-To: <1435417703.06.0.0329828025601.issue24520@psf.upfronthosting.co.za> Message-ID: <1442847495.65.0.983431268953.issue24520@psf.upfronthosting.co.za> Stefan Krah added the comment: Ok, clang does not support it either: https://llvm.org/bugs/show_bug.cgi?id=10409 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 17:03:28 2015 From: report at bugs.python.org (Zachary Ware) Date: Mon, 21 Sep 2015 15:03:28 +0000 Subject: [issue25202] Windows: with-statement doesn't release file handle after exception on "No space left on device" error In-Reply-To: <1442841424.93.0.271808876405.issue25202@psf.upfronthosting.co.za> Message-ID: <1442847808.18.0.0898973311617.issue25202@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- superseder: -> file descriptor not being closed with context manager on IOError when device is full _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 17:20:06 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 21 Sep 2015 15:20:06 +0000 Subject: [issue24520] Stop using deprecated floating-point environment functions on FreeBSD In-Reply-To: <1435417703.06.0.0329828025601.issue24520@psf.upfronthosting.co.za> Message-ID: <1442848806.58.0.957704267582.issue24520@psf.upfronthosting.co.za> Stefan Krah added the comment: Regarding volatile: gcc/clang seem to honor *some* changes to the control word. At least in libmpdec both compilers have always left the settings 80bit-prec/ROUND_CHOP intact, even though it's not the default. Let's rewrite Python in asm to avoid these issues. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 17:22:40 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Sep 2015 15:22:40 +0000 Subject: [issue25202] Windows: with-statement doesn't release file handle after exception on "No space left on device" error In-Reply-To: <1442841424.93.0.271808876405.issue25202@psf.upfronthosting.co.za> Message-ID: <1442848960.48.0.768220845198.issue25202@psf.upfronthosting.co.za> STINNER Victor added the comment: @Lauri: What is your Python version? Can you retry your test with Python 3.5? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 17:23:23 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 21 Sep 2015 15:23:23 +0000 Subject: [issue25114] asynico: add ssl_object extra info In-Reply-To: <1442268047.01.0.688232314675.issue25114@psf.upfronthosting.co.za> Message-ID: <1442849003.01.0.458233080193.issue25114@psf.upfronthosting.co.za> Yury Selivanov added the comment: the patch lgtm ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 17:54:38 2015 From: report at bugs.python.org (eryksun) Date: Mon, 21 Sep 2015 15:54:38 +0000 Subject: [issue25202] Windows: with-statement doesn't release file handle after exception on "No space left on device" error In-Reply-To: <1442841424.93.0.271808876405.issue25202@psf.upfronthosting.co.za> Message-ID: <1442850878.59.0.539219655723.issue25202@psf.upfronthosting.co.za> eryksun added the comment: Lauri changed the version from 3.4 to 3.2, and I was able to reproduce the problem in 3.2.5: C:\Temp>py -3.2 --version Python 3.2.5 C:\Temp>py -3.2 nospace.py removing fill.txt Traceback (most recent call last): File "nospace.py", line 8, in n = f.write(b"\0") IOError: [Errno 28] No space left on device During handling of the above exception, another exception occurred: Traceback (most recent call last): File "nospace.py", line 8, in n = f.write(b"\0") IOError: [Errno 28] No space left on device During handling of the above exception, another exception occurred: Traceback (most recent call last): File "nospace.py", line 12, in os.remove(fill) WindowsError: [Error 32] The process cannot access the file because it is being used by another process: 'T:\\fill.txt' It's a sharing violation, since the file handle isn't closed and wasn't opened with FILE_SHARE_DELETE. There's no problem in 3.4 or 3.5 since it properly closes the file handle even if flush() fails: C:\Temp>py -3.4 --version Python 3.4.3 C:\Temp>py -3.4 nospace.py removing fill.txt C:\Temp>py -3.5 --version Python 3.5.0 C:\Temp>py -3.5 nospace.py removing fill.txt ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 18:09:16 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 21 Sep 2015 16:09:16 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1442851756.61.0.590854401612.issue18967@psf.upfronthosting.co.za> Brett Cannon added the comment: It should be mentioned in this issue that the core-workflow mailing list decided on having NEWS entries being attached to the related issue in the issue tracker. This was then presented to python-committers and no one objected to the idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 18:09:39 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 16:09:39 +0000 Subject: [issue25114] asynico: add ssl_object extra info In-Reply-To: <1442268047.01.0.688232314675.issue25114@psf.upfronthosting.co.za> Message-ID: <20150921160934.81627.54948@psf.io> Roundup Robot added the comment: New changeset d7859e7e7071 by Victor Stinner in branch '3.4': Issue #25114, asyncio: add ssl_object extra info to SSL transports https://hg.python.org/cpython/rev/d7859e7e7071 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 18:18:38 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 21 Sep 2015 16:18:38 +0000 Subject: [issue25114] asyncio: add ssl_object extra info In-Reply-To: <1442268047.01.0.688232314675.issue25114@psf.upfronthosting.co.za> Message-ID: <1442852318.28.0.144822493669.issue25114@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- title: asynico: add ssl_object extra info -> asyncio: add ssl_object extra info _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 18:28:17 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 16:28:17 +0000 Subject: [issue25114] asyncio: add ssl_object extra info In-Reply-To: <1442268047.01.0.688232314675.issue25114@psf.upfronthosting.co.za> Message-ID: <20150921162810.81641.55898@psf.io> Roundup Robot added the comment: New changeset 2f451651038c by Victor Stinner in branch '3.5': Issue #25114: Adjust versionchanged in the doc https://hg.python.org/cpython/rev/2f451651038c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 18:29:13 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Sep 2015 16:29:13 +0000 Subject: [issue25114] asyncio: add ssl_object extra info In-Reply-To: <1442268047.01.0.688232314675.issue25114@psf.upfronthosting.co.za> Message-ID: <1442852953.53.0.551772545695.issue25114@psf.upfronthosting.co.za> STINNER Victor added the comment: I pushed my change to Python 3.4, 3.6 and 3.6 and Github. The strange thing is the put a different "versionchanged" tag in the doc: version 3.4.4 in the 3.4 branch, version 3.5.1 in the 3.5 and default branches. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 18:30:47 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Sep 2015 16:30:47 +0000 Subject: [issue25203] Incorrect handling MemoryError in readline.set_completer_delims Message-ID: <1442853047.02.0.107801341655.issue25203@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: MemoryError raised in readline.set_completer_delims() turns the readline library to incorrect state. $ (ulimit -v 200000; ./python;) Python 3.6.0a0 (default:e33b4c18af59+, Sep 17 2015, 17:05:17) [GCC 4.8.4] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import readline >>> readline.get_completer_delims() ' \t\n`~!@#$%^&*()-=+[{]}\\|;:\'",<>/?' >>> readline.set_completer_delims(' '*10**8) Traceback (most recent call last): File "", line 1, in MemoryError >>> readline.get_completer_delims() Traceback (most recent call last): File "", line 1, in UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe4 in position 1: invalid continuation byte Proposed patch fixes the issue. ---------- components: Extension Modules files: readline_set_completer_delims.patch keywords: patch messages: 251239 nosy: serhiy.storchaka, twouters priority: normal severity: normal stage: patch review status: open title: Incorrect handling MemoryError in readline.set_completer_delims type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40535/readline_set_completer_delims.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 18:42:42 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 16:42:42 +0000 Subject: [issue23630] support multiple hosts in create_server/start_server In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za> Message-ID: <20150921164235.82660.56993@psf.io> Roundup Robot added the comment: New changeset 682623e3e793 by Victor Stinner in branch '3.4': Issue #23630, asyncio: host parameter of loop.create_server() can now be a https://hg.python.org/cpython/rev/682623e3e793 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 18:45:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Sep 2015 16:45:49 +0000 Subject: [issue23630] support multiple hosts in create_server/start_server In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za> Message-ID: <1442853949.03.0.346993981593.issue23630@psf.upfronthosting.co.za> STINNER Victor added the comment: I pushed the change to Python 3.4, 3.5, 3.6 and asyncio at Github. Thanks Yann for your nice enhancement of asyncio! It put your name in CPython "acks" and asyncio author list. I modified the patch a little bit (3 lines), how the hosts variable was initialized. That's all :-) ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 18:48:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Sep 2015 16:48:17 +0000 Subject: [issue23972] Asyncio reuseport In-Reply-To: <1429185135.77.0.485030290106.issue23972@psf.upfronthosting.co.za> Message-ID: <1442854097.98.0.351584185942.issue23972@psf.upfronthosting.co.za> STINNER Victor added the comment: Hum, the latest patch was not reviewed yet :-( ---------- nosy: +ysionneau _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 19:29:13 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 21 Sep 2015 17:29:13 +0000 Subject: [issue25188] regrtest.py improvement for Profile Guided Optimization builds In-Reply-To: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za> Message-ID: <1442856553.89.0.918944484261.issue25188@psf.upfronthosting.co.za> Brett Cannon added the comment: I left some comments on the Python 3.6 version of the patch. I don't know if we should apply such a change to Python 2.7 or 3.5, though, as it is a new feature of regrtest and thus runs the risk of breaking stuff. Then again, we have said that anything in the test package has not backwards-compatibility guarantees. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 19:36:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 17:36:19 +0000 Subject: [issue24779] Python/ast.c: decode_unicode is never called with rawmode=True In-Reply-To: <1438533157.42.0.19611866983.issue24779@psf.upfronthosting.co.za> Message-ID: <20150921173615.11694.11938@psf.io> Roundup Robot added the comment: New changeset 5230115de64d by Eric V. Smith in branch 'default': Issue #24779: Remove unused rawmode parameter to unicode_decode. https://hg.python.org/cpython/rev/5230115de64d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 19:37:25 2015 From: report at bugs.python.org (Eric V. Smith) Date: Mon, 21 Sep 2015 17:37:25 +0000 Subject: [issue24779] Python/ast.c: decode_unicode is never called with rawmode=True In-Reply-To: <1438533157.42.0.19611866983.issue24779@psf.upfronthosting.co.za> Message-ID: <1442857045.76.0.932323539219.issue24779@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 20:02:55 2015 From: report at bugs.python.org (Lauri Kajan) Date: Mon, 21 Sep 2015 18:02:55 +0000 Subject: [issue25202] Windows: with-statement doesn't release file handle after exception on "No space left on device" error In-Reply-To: <1442841424.93.0.271808876405.issue25202@psf.upfronthosting.co.za> Message-ID: <1442858575.5.0.821124341973.issue25202@psf.upfronthosting.co.za> Lauri Kajan added the comment: Thanks for these. I'll see what I could do to upgrade our python version. Sorry for not finding the old issue. Didn't find the right search terms. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 20:16:17 2015 From: report at bugs.python.org (desbma) Date: Mon, 21 Sep 2015 18:16:17 +0000 Subject: [issue25156] shutil.copyfile should internally use os.sendfile when possible In-Reply-To: <1442520485.03.0.419427125487.issue25156@psf.upfronthosting.co.za> Message-ID: <1442859377.15.0.337686492513.issue25156@psf.upfronthosting.co.za> desbma added the comment: Additional advantage of calling sendfile from shutil.copyfile: other fonctions in shutil module would automatically benefit from the use of senfile because they call copyfile directly (copy, copy2) or indirectly (copytree). So for example, the performance of shutil.copytree should be improved for free for directory trees containing big files. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 20:22:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Sep 2015 18:22:01 +0000 Subject: [issue25204] Confusing (?) warning when run deprecated module as script Message-ID: <1442859720.94.0.332591501975.issue25204@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: $ ./python -Wa Lib/imp.py sys:1: PendingDeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses "sys:1:" is output when the stacklevel argument is larger then the deep of the stack. Following patch stops raising just below the surface. $ ./python -Wa Lib/imp.py Lib/imp.py:33: PendingDeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses PendingDeprecationWarning, stacklevel=2) However I'm not sure that the current behavior is incorrect. ---------- components: Extension Modules, Library (Lib) files: warnings_surface.patch keywords: patch messages: 251247 nosy: brett.cannon, eric.snow, haypo, ncoghlan, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Confusing (?) warning when run deprecated module as script Added file: http://bugs.python.org/file40536/warnings_surface.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 20:42:02 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 21 Sep 2015 18:42:02 +0000 Subject: [issue25204] Confusing (?) warning when run deprecated module as script In-Reply-To: <1442859720.94.0.332591501975.issue25204@psf.upfronthosting.co.za> Message-ID: <1442860922.59.0.72864725037.issue25204@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 20:59:20 2015 From: report at bugs.python.org (W deW) Date: Mon, 21 Sep 2015 18:59:20 +0000 Subject: [issue25205] setattr accepts invalid identifiers Message-ID: <1442861960.51.0.201067879836.issue25205@psf.upfronthosting.co.za> New submission from W deW: An identifier is defined by identifier ::= (letter|"_") (letter | digit | "_")* setattr accepts identifiers that do not meet this criterion: 
Python 2.7.8 (default, Jun 30 2014, 16:08:48) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class C(object): pass
...
>>> o=C()
>>> setattr(o, "$$$", True)
>>>  dir(o)
['$$$', '__class__', '__delattr__', '__dict__', '__doc__', '__format__', '__getattribute__', '__hash__', '__in
module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__su
__', '__weakref__']
>>> o.$$$
  File "", line 1
    o.$$$
      ^
SyntaxError: invalid syntax
>>>
---------- components: Interpreter Core messages: 251248 nosy: W deW priority: normal severity: normal status: open title: setattr accepts invalid identifiers type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 21:30:54 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Mon, 21 Sep 2015 19:30:54 +0000 Subject: [issue25188] regrtest.py improvement for Profile Guided Optimization builds In-Reply-To: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za> Message-ID: <1442863854.14.0.794056649486.issue25188@psf.upfronthosting.co.za> Alecsandru Patrascu added the comment: The patch does not display dots, as they are not that intuitive and users cannot make an estimate of the time left or the position in the training phase. Instead, the regrtest.py, will display the progress as [X/Y], like the default version, but without any warnings, failed tests, skipped tests. Also the start and end report are suppressed. I don't understand what do you mean by "keyword-only parameter". I added a new flag (-P/--pgo) and propagated it along all the functions that need it. Another approach would have been to use a global variable, lets say "pgo" and use it directly. This is closer to what you had in mind? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 21:57:01 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 21 Sep 2015 19:57:01 +0000 Subject: [issue25206] PEP 498: Minor mistakes/outdateness Message-ID: <1442865421.08.0.715266193748.issue25206@psf.upfronthosting.co.za> New submission from Arfrever Frehtes Taifersar Arahesis: """ For example, this code: f'abc{expr1:spec1}{expr2!r:spec2}def{expr3:!s}ghi' Might be be evaluated as: 'abc' + format(expr1, spec1) + format(repr(expr2)) + 'def' + format(str(expr3)) + 'ghi' """ format(repr(expr2)) should be format(repr(expr2), spec2) """ >>> f'x={x' File "", line 1 SyntaxError: missing '}' in format string expression """ Actually implemented exception message is: SyntaxError: f-string: expecting '}' """ >>> f'x={!x}' File "", line 1 !x ^ SyntaxError: invalid syntax """ Actually implemented exception message is: SyntaxError: f-string: invalid conversion character: expected 's', 'r', or 'a' ---------- assignee: eric.smith messages: 251250 nosy: Arfrever, eric.smith priority: normal severity: normal status: open title: PEP 498: Minor mistakes/outdateness _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 22:22:27 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 20:22:27 +0000 Subject: [issue25114] asyncio: add ssl_object extra info In-Reply-To: <1442268047.01.0.688232314675.issue25114@psf.upfronthosting.co.za> Message-ID: <20150921202224.31185.905@psf.io> Roundup Robot added the comment: New changeset 32e3a9e46f70 by Victor Stinner in branch '3.4': Issue #25114: Fix test_asyncio https://hg.python.org/cpython/rev/32e3a9e46f70 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 22:32:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 20:32:28 +0000 Subject: [issue23630] support multiple hosts in create_server/start_server In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za> Message-ID: <20150921203225.16573.37324@psf.io> Roundup Robot added the comment: New changeset 42e7334e0e4c by Victor Stinner in branch '3.4': Issue #23630: Fix test_asyncio on Windows https://hg.python.org/cpython/rev/42e7334e0e4c New changeset 840942a3f6aa by Victor Stinner in branch '3.5': Merge 3.4 (Issue #23630, fix test_asyncio) https://hg.python.org/cpython/rev/840942a3f6aa New changeset 1f979a573f8d by Victor Stinner in branch 'default': Merge 3.5 (Issue #23630, fix test_asyncio) https://hg.python.org/cpython/rev/1f979a573f8d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 22:36:38 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Sep 2015 20:36:38 +0000 Subject: [issue25207] ICC compiler warnings Message-ID: <1442867798.75.0.456459463931.issue25207@psf.upfronthosting.co.za> New submission from STINNER Victor: http://buildbot.python.org/all/builders/x86-64%20Windows%20Server%202012R2%20ICC%203.x/builds/109/steps/compile/logs/warnings%20%2832%29 2>C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj(418,5): warning : Toolset Intel C++ Compiler 16.0 is not used for official builds. Your build may have errors or incompatibilities. 2>..\Modules\posixmodule.c(4612): warning #3199: "defined" is always false in a macro expansion in Microsoft mode [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj] 2>..\Modules\posixmodule.c(4612): warning #3199: "defined" is always false in a macro expansion in Microsoft mode [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj] 2>..\Modules\posixmodule.c(4774): warning #3199: "defined" is always false in a macro expansion in Microsoft mode [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj] 2>..\Modules\posixmodule.c(4774): warning #3199: "defined" is always false in a macro expansion in Microsoft mode [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj] 2>..\Modules\_winapi.c(1083): warning #1478: function "GetVersion" (declared at line 110 of "C:\Program Files (x86)\Windows Kits\8.1\Include\um\sysinfoapi.h") was declared deprecated [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj] 2>..\Objects\obmalloc.c(841): warning #170: pointer points outside of underlying object [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj] 2>..\Objects\obmalloc.c(841): warning #170: pointer points outside of underlying object [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj] 2>..\PC\winreg.c(885): warning #810: conversion from "void *" to "DWORD={unsigned long}" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj] 2>..\PC\msvcrtmodule.c(544): warning #592: variable "st" is used before its value is set [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj] 2>..\Python\sysmodule.c(830): warning #1478: function "GetVersionExA" (declared at line 433 of "C:\Program Files (x86)\Windows Kits\8.1\Include\um\sysinfoapi.h") was declared deprecated [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj] 19>..\PC\_msi.c(1035): warning #810: conversion from "LPCTSTR={LPCSTR={const CHAR={char} *}}" to "int" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\_msi.vcxproj] 19>..\PC\_msi.c(1036): warning #810: conversion from "LPCTSTR={LPCSTR={const CHAR={char} *}}" to "int" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\_msi.vcxproj] 19>..\PC\_msi.c(1037): warning #810: conversion from "LPCTSTR={LPCSTR={const CHAR={char} *}}" to "int" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\_msi.vcxproj] 19>..\PC\_msi.c(1038): warning #810: conversion from "LPCTSTR={LPCSTR={const CHAR={char} *}}" to "int" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\_msi.vcxproj] 19>..\PC\_msi.c(1039): warning #810: conversion from "LPCTSTR={LPCSTR={const CHAR={char} *}}" to "int" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\_msi.vcxproj] C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj(418,5): warning : Toolset Intel C++ Compiler 16.0 is not used for official builds. Your build may have errors or incompatibilities. ..\Modules\posixmodule.c(4612): warning #3199: "defined" is always false in a macro expansion in Microsoft mode [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj] ..\Modules\posixmodule.c(4612): warning #3199: "defined" is always false in a macro expansion in Microsoft mode [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj] ..\Modules\posixmodule.c(4774): warning #3199: "defined" is always false in a macro expansion in Microsoft mode [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj] ..\Modules\posixmodule.c(4774): warning #3199: "defined" is always false in a macro expansion in Microsoft mode [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj] ..\Modules\_winapi.c(1083): warning #1478: function "GetVersion" (declared at line 110 of "C:\Program Files (x86)\Windows Kits\8.1\Include\um\sysinfoapi.h") was declared deprecated [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj] ..\Objects\obmalloc.c(841): warning #170: pointer points outside of underlying object [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj] ..\Objects\obmalloc.c(841): warning #170: pointer points outside of underlying object [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj] ..\PC\winreg.c(885): warning #810: conversion from "void *" to "DWORD={unsigned long}" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj] ..\PC\msvcrtmodule.c(544): warning #592: variable "st" is used before its value is set [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj] ..\Python\sysmodule.c(830): warning #1478: function "GetVersionExA" (declared at line 433 of "C:\Program Files (x86)\Windows Kits\8.1\Include\um\sysinfoapi.h") was declared deprecated [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\pythoncore.vcxproj] ..\PC\_msi.c(1035): warning #810: conversion from "LPCTSTR={LPCSTR={const CHAR={char} *}}" to "int" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\_msi.vcxproj] ..\PC\_msi.c(1036): warning #810: conversion from "LPCTSTR={LPCSTR={const CHAR={char} *}}" to "int" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\_msi.vcxproj] ..\PC\_msi.c(1037): warning #810: conversion from "LPCTSTR={LPCSTR={const CHAR={char} *}}" to "int" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\_msi.vcxproj] ..\PC\_msi.c(1038): warning #810: conversion from "LPCTSTR={LPCSTR={const CHAR={char} *}}" to "int" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\_msi.vcxproj] ..\PC\_msi.c(1039): warning #810: conversion from "LPCTSTR={LPCSTR={const CHAR={char} *}}" to "int" may lose significant bits [C:\Users\buildbot\buildarea\3.x.intel-windows-icc\build\PCbuild\_msi.vcxproj] ---------- messages: 251253 nosy: haypo priority: normal severity: normal status: open title: ICC compiler warnings versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 22:38:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 20:38:00 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <20150921203756.9943.62956@psf.io> Roundup Robot added the comment: New changeset a138a1131bae by Victor Stinner in branch 'default': Issue #25207, #14626: Fix ICC compiler warnings in posixmodule.c https://hg.python.org/cpython/rev/a138a1131bae ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 22:38:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 20:38:00 +0000 Subject: [issue25207] ICC compiler warnings In-Reply-To: <1442867798.75.0.456459463931.issue25207@psf.upfronthosting.co.za> Message-ID: <20150921203756.9943.19846@psf.io> Roundup Robot added the comment: New changeset a138a1131bae by Victor Stinner in branch 'default': Issue #25207, #14626: Fix ICC compiler warnings in posixmodule.c https://hg.python.org/cpython/rev/a138a1131bae ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 22:45:17 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 20:45:17 +0000 Subject: [issue25207] ICC compiler warnings In-Reply-To: <1442867798.75.0.456459463931.issue25207@psf.upfronthosting.co.za> Message-ID: <20150921204513.82648.94796@psf.io> Roundup Robot added the comment: New changeset 73867bf953e6 by Victor Stinner in branch 'default': ssue #25207: fix ICC compiler warning in msvcrtmodule.c https://hg.python.org/cpython/rev/73867bf953e6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 22:46:44 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Sep 2015 20:46:44 +0000 Subject: [issue25205] setattr accepts invalid identifiers In-Reply-To: <1442861960.51.0.201067879836.issue25205@psf.upfronthosting.co.za> Message-ID: <1442868404.23.0.532688156578.issue25205@psf.upfronthosting.co.za> STINNER Victor added the comment: Even if it's not well document, it's legit and supported by CPython, but it may not be supported by other Python implementation (ex: PyPy). ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 22:48:05 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Sep 2015 20:48:05 +0000 Subject: [issue24520] Stop using deprecated floating-point environment functions on FreeBSD In-Reply-To: <1435417703.06.0.0329828025601.issue24520@psf.upfronthosting.co.za> Message-ID: <1442868485.81.0.734053140684.issue24520@psf.upfronthosting.co.za> STINNER Victor added the comment: Sorry, I don't understand if we should apply or not the patch :-/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 22:49:45 2015 From: report at bugs.python.org (eryksun) Date: Mon, 21 Sep 2015 20:49:45 +0000 Subject: [issue16322] time.tzname on Python 3.3.0 for Windows is decoded by wrong encoding In-Reply-To: <1351166210.69.0.0993824857313.issue16322@psf.upfronthosting.co.za> Message-ID: <1442868585.23.0.356333355896.issue16322@psf.upfronthosting.co.za> eryksun added the comment: > local_encoding = locale.getdefaultlocale()[1] Use locale.getpreferredencoding(). > b = eval('b' + ascii(result)) > result = b.decode(local_encoding) It's simpler and more reliable to use 'latin-1' and 'mbcs' (ANSI). For example: result = result.encode('latin-1').decode('mbcs') If setlocale(LC_CTYPE, "") is called before importing the time module, then tzname is already correct. In this case, the above is either harmless or raises a UnicodeEncodeError that can be handled. OTOH, your approach silently corrupts the value: >>> result = 'St?edn? Evropa (b??n? ?as)' >>> b = eval('b' + ascii(result)) >>> b.decode('1251') 'St\\u0159edn? Evropa (b\\u011b\\u017en? \\u010das)' Back to the issue. In review, on initial import of the time module, if the CRT is using the default "C" locale, we have this inconsistency in which the time functions encode/decode tzname as ANSI and mbstowcs decodes tzname as Latin-1. (Plus strftime in the new CRT calls wcsftime, which adds another transcoding layer to compound the mojibake goodness.) If time.tzset is implemented on Windows, then at startup an application can set the locale (specifically LC_CTYPE for tzname, and LC_TIME for strftime) and then call time.tzset(). Example with Russian system locale: Initially we're in the "C" locale and the CRT's tzname is in ANSI. time.tzname incorrectly decodes this as Latin-1 since that's what mbstowcs uses in the "C" locale: >>> time.tzname[0] '\xc2\xf0\xe5\xec\xff \xe2 \xf4\xee\xf0\xec\xe0\xf2\xe5 UTC' The way the CRT's strftime is implemented compounds the problem: >>> time.strftime('%Z') 'A?aiy a oi?iaoa UTC' It's implemented by calling the wide-character function, wcsftime. Just like Python, this gets a wide-character string by calling mbstowcs on the ANSI tzname. Then the CRT's strftime encodes the wide-character string back as a best-fit ANSI string, and finally time.strftime decodes the result as Latin-1 via mbstowcs. The result is mutated mojibake: >>> time.tzname[0].encode('mbcs', 'replace').decode('latin-1') 'A?aiy a oi?iaoa UTC' Ironically, Python stopped calling wcsftime on Windows because of these problems, but changes to the code since then, plus the new CRT, have brought the problem back, and worse. See my comment in issue 10653, msg243660. Fix this by setting the locale and calling _tzset: >>> import ctypes, locale >>> locale.setlocale(locale.LC_ALL, '') 'Russian_Russia.1251' >>> ctypes.cdll.ucrtbase._tzset() 0 >>> time.strftime('%Z') '????? ? ??????? UTC' If time.tzset were implemented on Windows, calling it would reload the time.tzname tuple. ---------- versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 22:59:47 2015 From: report at bugs.python.org (Benjamin Hodgson) Date: Mon, 21 Sep 2015 20:59:47 +0000 Subject: [issue25208] improvements to the asyncio documentation Message-ID: <1442869187.79.0.516080462087.issue25208@psf.upfronthosting.co.za> New submission from Benjamin Hodgson: I spotted some grammatical errors in the "Develop with asyncio" page, so I improved the wording a bit. I also added a more explicit link to BaseEventLoop.set_debug(). ---------- assignee: docs at python components: Documentation files: asynciodocs.patch keywords: patch messages: 251260 nosy: Benjamin Hodgson, docs at python priority: normal severity: normal status: open title: improvements to the asyncio documentation versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file40537/asynciodocs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 23:01:34 2015 From: report at bugs.python.org (Benjamin Hodgson) Date: Mon, 21 Sep 2015 21:01:34 +0000 Subject: [issue25208] improvements to the asyncio documentation In-Reply-To: <1442869187.79.0.516080462087.issue25208@psf.upfronthosting.co.za> Message-ID: <1442869294.94.0.335948102806.issue25208@psf.upfronthosting.co.za> Changes by Benjamin Hodgson : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 23:16:35 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 21:16:35 +0000 Subject: [issue25206] PEP 498: Minor mistakes/outdateness In-Reply-To: <1442865421.08.0.715266193748.issue25206@psf.upfronthosting.co.za> Message-ID: <20150921211632.31185.76606@psf.io> Roundup Robot added the comment: New changeset 831276834e4b by Eric V. Smith in branch 'default': Partial fix for issue 25206: Fixed format() call. https://hg.python.org/peps/rev/831276834e4b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 23:25:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 21 Sep 2015 21:25:14 +0000 Subject: [issue25209] Append space after completed keywords Message-ID: <1442870714.02.0.814978155097.issue25209@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Open parenthesis ('(') is appended after completed callable globals and attributes. I propose to add a space after completed keyword. In most cases a space is either required after the keyword, or recommended by PEP8. Attached patch implements this. ---------- components: Extension Modules files: rlcompleter_keyword_space.patch keywords: patch messages: 251262 nosy: pitrou, r.david.murray, serhiy.storchaka, twouters priority: normal severity: normal stage: patch review status: open title: Append space after completed keywords type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file40538/rlcompleter_keyword_space.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 23:41:18 2015 From: report at bugs.python.org (eryksun) Date: Mon, 21 Sep 2015 21:41:18 +0000 Subject: [issue25205] setattr accepts invalid identifiers In-Reply-To: <1442861960.51.0.201067879836.issue25205@psf.upfronthosting.co.za> Message-ID: <1442871678.23.0.401485661448.issue25205@psf.upfronthosting.co.za> eryksun added the comment: The name can be any str/unicode string, including language keywords: >>> setattr(o, 'def', 'allowed') >>> getattr(o, 'def') 'allowed' >>> o.def File "", line 1 o.def ^ SyntaxError: invalid syntax and even an empty string: >>> setattr(o, '', 'mu') >>> getattr(o, '') 'mu' This includes instances of str and unicode subclasses, at least in CPython. ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python, eryksun priority: normal -> low versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 23:43:01 2015 From: report at bugs.python.org (Petr Prikryl) Date: Mon, 21 Sep 2015 21:43:01 +0000 Subject: [issue16322] time.tzname on Python 3.3.0 for Windows is decoded by wrong encoding In-Reply-To: <1351166210.69.0.0993824857313.issue16322@psf.upfronthosting.co.za> Message-ID: <1442871781.84.0.153894268157.issue16322@psf.upfronthosting.co.za> Petr Prikryl added the comment: @eryksun: I see. In my case, I can set the locale before importing the time module. However, the code (asciidoc3.py) will be used as a module, and I cannot know if the user imported the time module or not. Instead of your suggestion result = result.encode('latin-1').decode('mbcs') I was thinking to create a module say wordaround16322.py like this: --------------- import locale locale.setlocale(locale.LC_ALL, '') import importlib import time importlib.reload(time) --------------- I thought that reloading the time module would be the same as importing is later, after setting locale. If that worked, the module could be simply imported wherever it was needed. However, it does not work when imported after importing time. What is the reason? Does reload() work only for modules coded as Python sources? Is there any other approach that would implement the workaroundXXX.py module? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 23:51:15 2015 From: report at bugs.python.org (eryksun) Date: Mon, 21 Sep 2015 21:51:15 +0000 Subject: [issue25205] setattr accepts invalid identifiers In-Reply-To: <1442861960.51.0.201067879836.issue25205@psf.upfronthosting.co.za> Message-ID: <1442872275.04.0.0848136476822.issue25205@psf.upfronthosting.co.za> eryksun added the comment: To clarify using a unicode name in 2.x, it has to be encodable using the default encoding, sys.getdefaultencoding(). Normally this is ASCII. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Sep 21 23:56:08 2015 From: report at bugs.python.org (Josh Rosenberg) Date: Mon, 21 Sep 2015 21:56:08 +0000 Subject: [issue25201] lock of multiprocessing.Value is not a keyword-only argument In-Reply-To: <1442808321.25.0.819772413422.issue25201@psf.upfronthosting.co.za> Message-ID: <1442872568.64.0.302550439021.issue25201@psf.upfronthosting.co.za> Josh Rosenberg added the comment: Agreed. Having a named positional varargs argument makes subsequently defined arguments keyword only automatically. ---------- nosy: +josh.r _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 00:02:38 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 21 Sep 2015 22:02:38 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1442872958.71.0.0361521581294.issue18967@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Is that something that might happen 'soon' or only when the whole workflow is redone? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 00:06:32 2015 From: report at bugs.python.org (Vitaly) Date: Mon, 21 Sep 2015 22:06:32 +0000 Subject: [issue1731717] race condition in subprocess module Message-ID: <1442873192.29.0.360903610522.issue1731717@psf.upfronthosting.co.za> Vitaly added the comment: Is this issue fixed in python 2.7.10? I am experiencing strange race conditions in code that combines threads with multiprocessing pool, whereby a thread is spawned by each pool worker. Running on latest Mac OS X. ---------- nosy: +vitaly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 00:11:20 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 22:11:20 +0000 Subject: [issue24870] Optimize coding with surrogateescape and surrogatepass error handlers In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za> Message-ID: <20150921221114.82656.60453@psf.io> Roundup Robot added the comment: New changeset 3c430259873e by Victor Stinner in branch 'default': Issue #24870: Optimize the ASCII decoder for error handlers: surrogateescape, https://hg.python.org/cpython/rev/3c430259873e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 00:13:03 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Sep 2015 22:13:03 +0000 Subject: [issue24870] Optimize coding with surrogateescape and surrogatepass error handlers In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za> Message-ID: <1442873583.23.0.419362021884.issue24870@psf.upfronthosting.co.za> STINNER Victor added the comment: I pushed a change to optimize the ASCII decoder. Attached bench.py script: microbenchmark on the ASCII decoder. My results follows. Common platform: Platform: Linux-4.1.5-200.fc22.x86_64-x86_64-with-fedora-22-Twenty_Two Bits: int=32, long=64, long long=64, size_t=64, void*=64 Timer: time.perf_counter CFLAGS: -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes CPU model: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz Python unicode implementation: PEP 393 Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09) Platform of campaign before: Timer precision: 57 ns Date: 2015-09-21 23:48:00 SCM: hg revision=73867bf953e6 branch=default date="2015-09-21 22:40 +0200" Python version: 3.6.0a0 (default:73867bf953e6, Sep 21 2015, 23:47:35) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] Platform of campaign after: Timer precision: 55 ns Date: 2015-09-21 23:52:55 Python version: 3.6.0a0 (default:bb0f55f1ec22+, Sep 21 2015, 23:52:43) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] SCM: hg revision=bb0f55f1ec22+ tag=tip branch=default date="2015-09-21 23:06 +0200" ------------------+-------------+--------------- ignore | before | after ------------------+-------------+--------------- 256 x 10**1 bytes | 314 us (*) | 5.25 us (-98%) 256 x 10**3 bytes | 31.9 ms (*) | 509 us (-98%) 256 x 10**2 bytes | 3.13 ms (*) | 50.2 us (-98%) 256 x 10**4 bytes | 315 ms (*) | 5.12 ms (-98%) ------------------+-------------+--------------- Total | 351 ms (*) | 5.69 ms (-98%) ------------------+-------------+--------------- ------------------+-------------+--------------- replace | before | after ------------------+-------------+--------------- 256 x 10**1 bytes | 352 us (*) | 6.32 us (-98%) 256 x 10**3 bytes | 35.2 ms (*) | 608 us (-98%) 256 x 10**2 bytes | 3.52 ms (*) | 60.9 us (-98%) 256 x 10**4 bytes | 354 ms (*) | 6.19 ms (-98%) ------------------+-------------+--------------- Total | 393 ms (*) | 6.87 ms (-98%) ------------------+-------------+--------------- ------------------+-------------+--------------- surrogateescape | before | after ------------------+-------------+--------------- 256 x 10**1 bytes | 369 us (*) | 5.92 us (-98%) 256 x 10**3 bytes | 36.8 ms (*) | 570 us (-98%) 256 x 10**2 bytes | 3.69 ms (*) | 56.9 us (-98%) 256 x 10**4 bytes | 371 ms (*) | 5.79 ms (-98%) ------------------+-------------+--------------- Total | 412 ms (*) | 6.43 ms (-98%) ------------------+-------------+--------------- ------------------+-------------+-------- backslashreplace | before | after ------------------+-------------+-------- 256 x 10**1 bytes | 357 us (*) | 361 us 256 x 10**3 bytes | 35.1 ms (*) | 36.1 ms 256 x 10**2 bytes | 3.52 ms (*) | 3.59 ms 256 x 10**4 bytes | 357 ms (*) | 365 ms ------------------+-------------+-------- Total | 396 ms (*) | 405 ms ------------------+-------------+-------- -----------------+--------------+--------------- Summary | before | after -----------------+--------------+--------------- ignore | 351 ms (*) | 5.69 ms (-98%) replace | 393 ms (*) | 6.87 ms (-98%) surrogateescape | 412 ms (*) | 6.43 ms (-98%) backslashreplace | 396 ms (*) | 405 ms -----------------+--------------+--------------- Total | 1.55 sec (*) | 424 ms (-73%) -----------------+--------------+--------------- ---------- Added file: http://bugs.python.org/file40539/bench.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 00:31:22 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 21 Sep 2015 22:31:22 +0000 Subject: [issue25184] "python -m pydoc -w" fails in nondecodable directory In-Reply-To: <1442696845.13.0.851195404942.issue25184@psf.upfronthosting.co.za> Message-ID: <1442874682.77.0.0262967864815.issue25184@psf.upfronthosting.co.za> Martin Panter added the comment: Serhiy?s patch essentially uses the local filesystem encoding and then percent encoding, rather than the current behaviour of strict UTF-8 encoding and percent encoding. This is similar to what the ?pathlib? make_uri() methods do, so maybe we could let ?pathlib? do the work instead. This draft RFC discusses encoding ?file:? URLs: https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-03#section-4 It suggests leaving Unicode characters alone (in IRIs) if possible, or using UTF-8 and percent encoding even if the filesystem uses a non-UTF-8 encoding. Perhaps we could leave the filename in the HTML as Unicode characters without percent encoding, and only percent encode the undecodable (surrogate-escaped) bytes. This ?IRI? scheme is also recommended by , which says on Windows, ?in file URIs, percent-encoded octets are interpreted as a byte in the user?s current codepage?. This contradicts the draft RFC and the ?pathlib? implementation, which both use UTF-8. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 00:32:01 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 21 Sep 2015 22:32:01 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1442874721.39.0.18885952103.issue18967@psf.upfronthosting.co.za> Brett Cannon added the comment: As soon as someone finds the time to make the change we can switch. While this is a necessary requirement to change the workflow it isn't gated by it either. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 00:33:30 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 21 Sep 2015 22:33:30 +0000 Subject: [issue25188] regrtest.py improvement for Profile Guided Optimization builds In-Reply-To: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za> Message-ID: <1442874809.99.0.205160397641.issue25188@psf.upfronthosting.co.za> Brett Cannon added the comment: Ah, OK. As I said I had not run it so I wasn't sure of the actual outcome. =) As for keyword-only arguments/parameters, see https://www.python.org/dev/peps/pep-3102/ . They are a Python 3 feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 00:45:47 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 21 Sep 2015 22:45:47 +0000 Subject: [issue25206] PEP 498: Minor mistakes/outdateness In-Reply-To: <1442865421.08.0.715266193748.issue25206@psf.upfronthosting.co.za> Message-ID: <1442875547.43.0.316637474973.issue25206@psf.upfronthosting.co.za> Martin Panter added the comment: Also in the first example, the colon (format specifier) and exclamation mark (conversion) are in the wrong order. It should either be f"{expr3:!s}" ? format(expr3, "!s") or f"{expr3!s:}" ? format(str(expr3), "") ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 00:49:59 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 21 Sep 2015 22:49:59 +0000 Subject: [issue25205] setattr accepts invalid identifiers In-Reply-To: <1442861960.51.0.201067879836.issue25205@psf.upfronthosting.co.za> Message-ID: <1442875799.46.0.981451424568.issue25205@psf.upfronthosting.co.za> Martin Panter added the comment: Previous report: Issue 14029 ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 01:00:08 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 23:00:08 +0000 Subject: [issue24870] Optimize coding with surrogateescape and surrogatepass error handlers In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za> Message-ID: <20150921230002.11690.70455@psf.io> Roundup Robot added the comment: New changeset 2cf85e2834c2 by Victor Stinner in branch 'default': Issue #24870: Reuse the new _Py_error_handler enum https://hg.python.org/cpython/rev/2cf85e2834c2 New changeset aa247150a8b1 by Victor Stinner in branch 'default': Issue #24870: Add _PyUnicodeWriter_PrepareKind() macro https://hg.python.org/cpython/rev/aa247150a8b1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 01:06:41 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 21 Sep 2015 23:06:41 +0000 Subject: [issue24870] Optimize coding with surrogateescape and surrogatepass error handlers In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za> Message-ID: <1442876801.03.0.644526553464.issue24870@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, I prepared the code for the UTF-8 optimization. @Serhiy: would you like to rebase your patch faster_surrogates_hadling.patch? Attached utf8.patch is a less optimal implementation which only changes PyUnicode_DecodeUTF8Stateful(). Maybe it's enough? I would like to see a benchmark here to choose the good compromise between performance and code complexity. ---------- Added file: http://bugs.python.org/file40540/utf8.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 01:29:46 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 23:29:46 +0000 Subject: [issue14626] os module: use keyword-only arguments for dir_fd and nofollow to reduce function count In-Reply-To: <1334879559.02.0.192331437376.issue14626@psf.upfronthosting.co.za> Message-ID: <20150921232942.98360.72354@psf.io> Roundup Robot added the comment: New changeset 170cd0104267 by Victor Stinner in branch 'default': Issue #25207, #14626: Fix my commit. https://hg.python.org/cpython/rev/170cd0104267 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 01:29:45 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 23:29:45 +0000 Subject: [issue25207] ICC compiler warnings In-Reply-To: <1442867798.75.0.456459463931.issue25207@psf.upfronthosting.co.za> Message-ID: <20150921232942.98360.51789@psf.io> Roundup Robot added the comment: New changeset 170cd0104267 by Victor Stinner in branch 'default': Issue #25207, #14626: Fix my commit. https://hg.python.org/cpython/rev/170cd0104267 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 01:36:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 21 Sep 2015 23:36:12 +0000 Subject: [issue24861] deprecate importing components of IDLE In-Reply-To: <1439500309.93.0.862265399846.issue24861@psf.upfronthosting.co.za> Message-ID: <20150921233609.81649.32052@psf.io> Roundup Robot added the comment: New changeset e9edb95ca8b6 by Terry Jan Reedy in branch '2.7': Issue #24861: add Idle news items and correct previous errors. https://hg.python.org/cpython/rev/e9edb95ca8b6 New changeset 5087ca9e6002 by Terry Jan Reedy in branch '3.4': Issue #24861: add Idle news item and correct previous errors. https://hg.python.org/cpython/rev/5087ca9e6002 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 02:49:33 2015 From: report at bugs.python.org (Davin Potts) Date: Tue, 22 Sep 2015 00:49:33 +0000 Subject: [issue25201] lock of multiprocessing.Value is not a keyword-only argument In-Reply-To: <1442808321.25.0.819772413422.issue25201@psf.upfronthosting.co.za> Message-ID: <1442882973.61.0.127575152905.issue25201@psf.upfronthosting.co.za> Davin Potts added the comment: Berker: It looks to me like the docs are indeed in sync with the code on Value in that lock really is a keyword-only argument. It looks like it's been that way since at least 2.7 (I didn't look at earlier). There are enough other things in the multiprocessing.sharedctypes, maybe it was one of the others that caught your attention instead? I wished that block/blocking had turned out to be a keyword-only argument in multiprocessing.Lock as part of issue23484, which I immediately thought of when reading this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 03:41:47 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 22 Sep 2015 01:41:47 +0000 Subject: [issue25209] Append space after completed keywords In-Reply-To: <1442870714.02.0.814978155097.issue25209@psf.upfronthosting.co.za> Message-ID: <1442886107.67.0.845653717724.issue25209@psf.upfronthosting.co.za> Martin Panter added the comment: I agree with adding a space in some cases, but not others. E.g. "pass" would only need a space if you wanted to add a comment, "return" often takes no argument, "lambda" may need an immediate colon (lambda: x). See for a whitelist of keywords that I thought should always have spaces, but beware this list may not be up to date (no ?await? nor ?async? for instance). BTW I don?t agree with the default of forcing an open bracket ?(? for callables; consider decorators, subclassing, deferred function calls, etc, where that bracket may not be wanted. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 04:04:16 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 22 Sep 2015 02:04:16 +0000 Subject: [issue24657] CGIHTTPServer module discard continuous '/' letters from params given by GET method. In-Reply-To: <1437187776.37.0.855244973055.issue24657@psf.upfronthosting.co.za> Message-ID: <1442887456.91.0.79007251209.issue24657@psf.upfronthosting.co.za> Martin Panter added the comment: Yes it also seems to apply to Python 3. Perhaps you forgot your test script, so I made my own. After running python3 -m http.server --cgi The response from the following URL has no double slashes to be seen: http://localhost:8000/cgi-bin/test.py//x//y//?k=aa%2F%2Fbb&//q//p//=//a//b// I am not a CGI expert, but I suspect the query string bits should have double slashes, but maybe the PATH_INFO is right not to (see RFC 3875). ---------- nosy: +martin.panter stage: -> needs patch type: -> behavior versions: +Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40541/test.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 04:43:21 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Sep 2015 02:43:21 +0000 Subject: [issue16893] Generate Idle help from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <20150922024318.9953.95175@psf.io> Roundup Robot added the comment: New changeset 855484b55da3 by Terry Jan Reedy in branch '2.7': Issue #16893: Add idlelib.help.copy_strip() to copy-rstrip Doc/.../idle.html. https://hg.python.org/cpython/rev/855484b55da3 New changeset df987a0bc350 by Terry Jan Reedy in branch '3.4': Issue #16893: Add idlelib.help.copy_strip() to copy-rstrip Doc/.../idle.html. https://hg.python.org/cpython/rev/df987a0bc350 New changeset f08437278049 by Terry Jan Reedy in branch '3.5': Issue #16893: Add idlelib.help.copy_strip() to copy-rstrip Doc/.../idle.html. https://hg.python.org/cpython/rev/f08437278049 New changeset 09ebed6a8cb8 by Terry Jan Reedy in branch 'default': Issue #16893: Add idlelib.help.copy_strip() to copy-rstrip Doc/.../idle.html. https://hg.python.org/cpython/rev/09ebed6a8cb8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 04:52:38 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 22 Sep 2015 02:52:38 +0000 Subject: [issue16893] Generate Idle help from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1442890358.26.0.450226769375.issue16893@psf.upfronthosting.co.za> Terry J. Reedy added the comment: NEWS entries are done. I added a function, copy_strip, to help.py to rstrip (in bytes mode) idle.html as it copies to help.html. (I changed the name to better remember which is which.) In my .bat file, with Doc as current directory, I use ..\pcbuild\python_d.exe -c "from idlelib.help import copy_strip; copy_strip()" I could change the if __name__ block so that ..\pcbuild\python_d.exe -m idlelib.help copy_strip would work. Either way, I would like to add 'idlehelp' to makefiles. But not tonight. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 05:32:30 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 22 Sep 2015 03:32:30 +0000 Subject: [issue25201] lock of multiprocessing.Value is not a keyword-only argument In-Reply-To: <1442808321.25.0.819772413422.issue25201@psf.upfronthosting.co.za> Message-ID: <1442892750.46.0.357416752934.issue25201@psf.upfronthosting.co.za> Berker Peksag added the comment: I didn't test it carefully. It was a mistake on my part :) But I think the function signature could be clearer by changing that part to "*, lock=True". ---------- resolution: -> not a bug stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 06:31:37 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 22 Sep 2015 04:31:37 +0000 Subject: [issue24841] Some test_ssl network tests fail if svn.python.org is not accessible. In-Reply-To: <1439252941.43.0.787973342114.issue24841@psf.upfronthosting.co.za> Message-ID: <1442896297.95.0.868789998153.issue24841@psf.upfronthosting.co.za> Berker Peksag added the comment: The attached patch should fix the test failures. ---------- keywords: +patch stage: needs patch -> patch review type: -> behavior Added file: http://bugs.python.org/file40542/issue24841.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 07:48:47 2015 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 22 Sep 2015 05:48:47 +0000 Subject: [issue25210] Special-case NoneType() in do_richcompare() Message-ID: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za> New submission from Ezio Melotti: do_richcompare() has a comment (at Objects/object.c:689) that reads: /* XXX Special-case None so it doesn't show as NoneType() */ This refers to the following error message: >>> 3 < None Traceback (most recent call last): File "", line 1, in TypeError: unorderable types: int() < NoneType() This is a common error that comes up while ordering/sorting, and NoneType() is potentially confusing, so I find the request reasonable. If the consensus is favourable, it should be implemented, if not, the comment should be removed. ---------- components: Interpreter Core keywords: easy messages: 251288 nosy: ezio.melotti priority: low severity: normal stage: test needed status: open title: Special-case NoneType() in do_richcompare() type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 08:07:23 2015 From: report at bugs.python.org (eryksun) Date: Tue, 22 Sep 2015 06:07:23 +0000 Subject: [issue16322] time.tzname on Python 3.3.0 for Windows is decoded by wrong encoding In-Reply-To: <1351166210.69.0.0993824857313.issue16322@psf.upfronthosting.co.za> Message-ID: <1442902043.78.0.905413862596.issue16322@psf.upfronthosting.co.za> eryksun added the comment: > import locale > locale.setlocale(locale.LC_ALL, '') > > import importlib > import time > importlib.reload(time) > > it does not work when imported after importing time. > What is the reason? Does reload() work only for > modules coded as Python sources? The import system won't reinitialize a builtin or dynamic extension module. Reloading just returns a reference to the existing module. It won't even reload a PEP 489 multi-phase extension module. (But you can create and exec a new instance of a multi-phase extension module.) > Is there any other approach that would implement the > workaroundXXX.py module? If the user's default locale and the current thread's preferred language are compatible with the system ANSI encoding [1], then you don't actually need to call _tzset nor worry about time.tzname. Call setlocale(LC_CTYPE, ''), and then call time.strftime('%Z') to get the timezone name. If you use Win32 directly instead of the CRT, then none of this ANSI business is an issue. Just call GetTimeZoneInformation to get the standard and daylight names as wide-character strings. You have that option via ctypes. [1]: A user can select a default locale (language) that's unrelated to the system ANSI locale (the ANSI setting is per machine, located under Region->Administrative). Also, the preferred language can be selected dynamically by calling SetThreadPreferredUILanguages or SetProcessPreferredUILanguages. All three could be incompatible with each other, in which case you have to explicitly set the locale (e.g. "ru-RU" instead of an empty string) and call _tzset. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 08:16:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Sep 2015 06:16:13 +0000 Subject: [issue25210] Special-case NoneType() in do_richcompare() In-Reply-To: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za> Message-ID: <1442902573.89.0.17195832457.issue25210@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I find the request reasonable too. ---------- nosy: +serhiy.storchaka stage: test needed -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 09:52:15 2015 From: report at bugs.python.org (s-wakaba) Date: Tue, 22 Sep 2015 07:52:15 +0000 Subject: [issue25211] Error message formatting errors in int object unit-test script Message-ID: <1442908335.62.0.971755787432.issue25211@psf.upfronthosting.co.za> New submission from s-wakaba: I've found some parts there are illegal message formatting in int object unit test script "Lib/test/test_long.py" when hacking the interpreter. because they were an easy problem, I already fixed them to promote my work. Therefore, the patch has been attacked. thanks ---------- components: Tests files: test_long.py.patch keywords: patch messages: 251291 nosy: s-wakaba priority: normal severity: normal status: open title: Error message formatting errors in int object unit-test script type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file40543/test_long.py.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 10:21:49 2015 From: report at bugs.python.org (Vinay Sajip) Date: Tue, 22 Sep 2015 08:21:49 +0000 Subject: [issue25185] Inconsistency between venv and site In-Reply-To: <1442698159.95.0.304023821424.issue25185@psf.upfronthosting.co.za> Message-ID: <1442910109.5.0.754830521464.issue25185@psf.upfronthosting.co.za> Vinay Sajip added the comment: Seems like the right fix would be to change site.py to read it using UTF-8. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 10:35:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Sep 2015 08:35:49 +0000 Subject: [issue24295] Backport of #17086 causes regression in setup.py In-Reply-To: <1432723014.0.0.831198232873.issue24295@psf.upfronthosting.co.za> Message-ID: <1442910949.91.0.921186266155.issue24295@psf.upfronthosting.co.za> STINNER Victor added the comment: doko wrote: "I'll look at this in June." @doko: ping? :-) @moritzs: Does Python 3.5 have the same issue? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 10:50:15 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Sep 2015 08:50:15 +0000 Subject: [issue24870] Optimize coding with surrogateescape and surrogatepass error handlers In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za> Message-ID: <20150922084723.82644.65137@psf.io> Roundup Robot added the comment: New changeset 8317796ca004 by Victor Stinner in branch 'default': Issue #24870: revert unwanted change https://hg.python.org/cpython/rev/8317796ca004 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 11:02:19 2015 From: report at bugs.python.org (Nick Coghlan) Date: Tue, 22 Sep 2015 09:02:19 +0000 Subject: [issue25194] Register of Financial Interests for core contributors In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za> Message-ID: <1442912539.9.0.456132803826.issue25194@psf.upfronthosting.co.za> Nick Coghlan added the comment: Ezio's right I ended up mixing together a few different objectives here, which is an artifact of how the idea came about: * my starting point was wanting a list of folks that already have commit access (and hence are demonstrably familiar to the core development community) that the PSF can either contract with directly for work on the toolchain (and perhaps for devoting time to the tracker patch backlog), or else refer companies to. At the moment we do this based on personal knowledge, which means there are going to be missed opportunities to make connections with folks the current Board of Directors don't know personally. * in the ensuing discussion, I realised the "we're all volunteers here" disclaimer isn't true at the moment, and is unlikely to ever be true again, and that's something that would be good to disclose to help folks understand the sustaining engineering model that has emerged around CPython The draft patch ended up being framed as the latter, while still covering the former, which I agree is confusing. As a result, I like the idea of making the page title "Motivations and Affiliations" to focus on the "Why are we here?" aspect. At the end, we can then have a section "Availability for PSF Referrals" and ask core developers that are potentially able to take on contract and freelance work to let the PSF Board know. We can then maintain that list in confidence, rather than requiring people to broadcast their availability for contract work to the entire internet. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 11:06:57 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Sep 2015 09:06:57 +0000 Subject: [issue24870] Optimize coding with surrogateescape and surrogatepass error handlers In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za> Message-ID: <1442912816.99.0.362017837896.issue24870@psf.upfronthosting.co.za> STINNER Victor added the comment: I pushed utf8.patch by mistake :-/ The advantage is that buildbots found bugs. Attached utf8-2.patch fixed bugs. The bug was how the "s" variable was set in the error handler. It's now set with: s = starts + endinpos; Bugs found by the buildbots: ====================================================================== FAIL: test_invalid_cb_for_3bytes_seq (test.test_unicode.UnicodeTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_unicode.py", line 1897, in test_invalid_cb_for_3bytes_seq 'invalid continuation byte') File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_unicode.py", line 1772, in assertCorrectUTF8Decoding self.assertEqual(seq.decode('utf-8', 'replace'), res) AssertionError: '??\x00' != '?\x00' - ?? ? - + ? ====================================================================== FAIL: test_unquote_with_unicode (test.test_urllib.UnquotingTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/opt/python/3.x.langa-ubuntu/build/Lib/test/test_urllib.py", line 1016, in test_unquote_with_unicode "using unquote(): %r != %r" % (expect, result)) AssertionError: '?' != '??' - ? + ?? ? + : using unquote(): '?' != '??' ---------- Added file: http://bugs.python.org/file40544/utf8-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 11:11:04 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 22 Sep 2015 09:11:04 +0000 Subject: [issue25211] Error message formatting errors in int object unit-test script In-Reply-To: <1442908335.62.0.971755787432.issue25211@psf.upfronthosting.co.za> Message-ID: <1442913064.03.0.769248058306.issue25211@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for the patch, it looks correct. The Frm class takes a variable number of *args, and then returns ?format % args?. It should at least be applied to the 2.7 branch. For 3.4+, perhaps we can eliminate the need for the Frm class altogether, by using TestCase.subTest(): def check_bitop_identities_1(self, x): eq = self.assertEqual with self.subTest(x=x): eq(x & 0, 0) ... for n in range(2*SHIFT): p2 = 2 ** n with self.subTest(n=n, p2=p2): eq(x << n >> n, x) ... eq(x & -p2, x & ~(p2 - 1)) ---------- nosy: +martin.panter stage: -> patch review versions: +Python 2.7, Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 11:26:26 2015 From: report at bugs.python.org (Mark Shannon) Date: Tue, 22 Sep 2015 09:26:26 +0000 Subject: [issue25210] Special-case NoneType() in do_richcompare() In-Reply-To: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za> Message-ID: <1442913986.23.0.93063735056.issue25210@psf.upfronthosting.co.za> Mark Shannon added the comment: +1 for special casing None. ---------- nosy: +Mark.Shannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 11:37:01 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Sep 2015 09:37:01 +0000 Subject: [issue24870] Optimize coding with surrogateescape and surrogatepass error handlers In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za> Message-ID: <1442914621.21.0.895939680938.issue24870@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, here is a patch which optimizes surrogatepass too. Result of bench_utf8.py. Common platform: CFLAGS: -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09) CPU model: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz Bits: int=32, long=64, long long=64, size_t=64, void*=64 Timer: time.perf_counter Platform: Linux-4.1.6-200.fc22.x86_64-x86_64-with-fedora-22-Twenty_Two Python unicode implementation: PEP 393 Platform of campaign before: SCM: hg revision=8317796ca004 tag=tip branch=default date="2015-09-22 10:46 +0200" Python version: 3.6.0a0 (default:8317796ca004, Sep 22 2015, 11:33:04) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] Date: 2015-09-22 11:33:12 Timer precision: 73 ns Platform of campaign after: SCM: hg revision=8317796ca004+ tag=tip branch=default date="2015-09-22 10:46 +0200" Python version: 3.6.0a0 (default:8317796ca004+, Sep 22 2015, 11:31:04) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] Date: 2015-09-22 11:31:58 Timer precision: 54 ns ------------------+-------------+--------------- ignore | before | after ------------------+-------------+--------------- 100 x 10**1 bytes | 8.85 us (*) | 857 ns (-90%) 100 x 10**3 bytes | 780 us (*) | 45.5 us (-94%) 100 x 10**2 bytes | 78.7 us (*) | 4.81 us (-94%) 100 x 10**4 bytes | 8.13 ms (*) | 456 us (-94%) ------------------+-------------+--------------- Total | 9 ms (*) | 507 us (-94%) ------------------+-------------+--------------- ------------------+-------------+--------------- replace | before | after ------------------+-------------+--------------- 100 x 10**1 bytes | 10 us (*) | 939 ns (-91%) 100 x 10**3 bytes | 898 us (*) | 54.1 us (-94%) 100 x 10**2 bytes | 90.5 us (*) | 5.72 us (-94%) 100 x 10**4 bytes | 9.55 ms (*) | 536 us (-94%) ------------------+-------------+--------------- Total | 10.6 ms (*) | 597 us (-94%) ------------------+-------------+--------------- ------------------+-------------+--------------- surrogateescape | before | after ------------------+-------------+--------------- 100 x 10**1 bytes | 10.4 us (*) | 919 ns (-91%) 100 x 10**3 bytes | 930 us (*) | 55.2 us (-94%) 100 x 10**2 bytes | 93.1 us (*) | 5.84 us (-94%) 100 x 10**4 bytes | 9.85 ms (*) | 552 us (-94%) ------------------+-------------+--------------- Total | 10.9 ms (*) | 614 us (-94%) ------------------+-------------+--------------- ------------------+-------------+--------------- surrogatepass | before | after ------------------+-------------+--------------- 100 x 10**1 bytes | 4.83 us (*) | 963 ns (-80%) 100 x 10**3 bytes | 353 us (*) | 42.6 us (-88%) 100 x 10**2 bytes | 36.5 us (*) | 4.69 us (-87%) 100 x 10**4 bytes | 4.17 ms (*) | 424 us (-90%) ------------------+-------------+--------------- Total | 4.56 ms (*) | 472 us (-90%) ------------------+-------------+--------------- ------------------+-------------+-------------- backslashreplace | before | after ------------------+-------------+-------------- 100 x 10**1 bytes | 10.9 us (*) | 10.1 us (-7%) 100 x 10**3 bytes | 944 us (*) | 853 us (-10%) 100 x 10**2 bytes | 93.8 us (*) | 87.5 us (-7%) 100 x 10**4 bytes | 9.92 ms (*) | 9.04 ms (-9%) ------------------+-------------+-------------- Total | 11 ms (*) | 9.99 ms (-9%) ------------------+-------------+-------------- -----------------+-------------+--------------- Summary | before | after -----------------+-------------+--------------- ignore | 9 ms (*) | 507 us (-94%) replace | 10.6 ms (*) | 597 us (-94%) surrogateescape | 10.9 ms (*) | 614 us (-94%) surrogatepass | 4.56 ms (*) | 472 us (-90%) backslashreplace | 11 ms (*) | 9.99 ms (-9%) -----------------+-------------+--------------- Total | 46 ms (*) | 12.2 ms (-73%) -----------------+-------------+--------------- ---------- Added file: http://bugs.python.org/file40545/utf8-3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 11:37:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Sep 2015 09:37:17 +0000 Subject: [issue24870] Optimize coding with surrogateescape and surrogatepass error handlers In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za> Message-ID: <1442914637.23.0.915920187664.issue24870@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file40546/bench_utf8.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 12:09:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Sep 2015 10:09:12 +0000 Subject: [issue25137] Behavioral change / regression? with nested functools.partial In-Reply-To: <1442367392.37.0.924790344603.issue25137@psf.upfronthosting.co.za> Message-ID: <20150922100848.115545.90305@psf.io> Roundup Robot added the comment: New changeset fa766b6f12b5 by Berker Peksag in branch '3.5': Issue #25137: Add a note to whatsnew/3.5.rst for nested functools.partial calls https://hg.python.org/cpython/rev/fa766b6f12b5 New changeset ed694938c61a by Berker Peksag in branch 'default': Issue #25137: Add a note to whatsnew/3.5.rst for nested functools.partial calls https://hg.python.org/cpython/rev/ed694938c61a ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 12:10:38 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 22 Sep 2015 10:10:38 +0000 Subject: [issue25137] Behavioral change / regression? with nested functools.partial In-Reply-To: <1442367392.37.0.924790344603.issue25137@psf.upfronthosting.co.za> Message-ID: <1442916638.88.0.126543593155.issue25137@psf.upfronthosting.co.za> Berker Peksag added the comment: Added a note to Doc/whatsnew/3.5.rst. ---------- nosy: +berker.peksag stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 12:16:48 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Sep 2015 10:16:48 +0000 Subject: [issue25210] Special-case NoneType() in do_richcompare() In-Reply-To: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za> Message-ID: <1442917008.26.0.42217112438.issue25210@psf.upfronthosting.co.za> STINNER Victor added the comment: > TypeError: unorderable types: int() < NoneType() The error message looks good to me: NoneType is the type of the None singleton: >>> type(None) >>> x=type(None)() >>> x is None True Do you propose to use the message "TypeError: unorderable types: int() < None"? This message looks wrong to me, None is not a type. The strange thing is the trailing parenthesis!? Why not "int < NoneType"? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 12:27:09 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Sep 2015 10:27:09 +0000 Subject: [issue25159] Regression in time to import a module In-Reply-To: <1442556606.15.0.522584302018.issue25159@psf.upfronthosting.co.za> Message-ID: <1442917629.25.0.157399535916.issue25159@psf.upfronthosting.co.za> STINNER Victor added the comment: I tested on Linux. (1) for i in `seq 5`; do ./python -I -m timeit -n1 -r1 -s "import sys; sys.modules.clear()" -- "import enum"; done (shortest timing) Python 3.4: 6.93 msec Python 3.6: 7.05 msec (+2%) (2) for i in `seq 5`; do ./python -I -m timeit "import enum"; done Python 3.4: 0.331 usec Python 3.6: 0.341 usec (+%3) These numbers are nanoseconds, it's too short to run a real benchmark. (3) for i in `seq 5`; do ./python -I -m timeit -n1 -r1 "import enum"; done Python 3.4: 801 usec Python 3.6: 774 usec (-3%) Sorry, I don't see major differences like you showed. Can you explain exactly how to reproduce them? Exact Python version? OS? I used the development branches (branch 3.4 and branch default). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 12:28:13 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Sep 2015 10:28:13 +0000 Subject: [issue17781] optimize compilation options In-Reply-To: <1366224008.41.0.60101315886.issue17781@psf.upfronthosting.co.za> Message-ID: <1442917693.9.0.994770178974.issue17781@psf.upfronthosting.co.za> STINNER Victor added the comment: > For the record, the gain for LTO+PGO (with "-flto -O3") over PGO alone seems to be between 0% and 10% for most benchmarks. Hum, does it make sense to enable LTO without PGO? ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 12:31:19 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Sep 2015 10:31:19 +0000 Subject: [issue17781] optimize compilation options In-Reply-To: <1366224008.41.0.60101315886.issue17781@psf.upfronthosting.co.za> Message-ID: <1442917879.37.0.211703225282.issue17781@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Hum, does it make sense to enable LTO without PGO? Probably not. By the way, I now have a small ARM system to play with, and there the gain of LTO+PGO over PGO alone is around 10%. Also note LTO can make compilation times much longer (it's the linking step actually, which can take minutes). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 12:31:21 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Sep 2015 10:31:21 +0000 Subject: [issue24165] Free list for single-digits ints In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za> Message-ID: <1442917881.0.0.208083441312.issue24165@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 12:34:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Sep 2015 10:34:04 +0000 Subject: [issue25137] Behavioral change / regression? with nested functools.partial In-Reply-To: <1442916638.88.0.126543593155.issue25137@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Thanks for the doc Berker :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 13:10:34 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Tue, 22 Sep 2015 11:10:34 +0000 Subject: [issue25188] regrtest.py improvement for Profile Guided Optimization builds In-Reply-To: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za> Message-ID: <1442920234.05.0.976509000433.issue25188@psf.upfronthosting.co.za> Changes by Alecsandru Patrascu : Added file: http://bugs.python.org/file40547/regrtest_36_v02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 13:11:39 2015 From: report at bugs.python.org (Alecsandru Patrascu) Date: Tue, 22 Sep 2015 11:11:39 +0000 Subject: [issue25188] regrtest.py improvement for Profile Guided Optimization builds In-Reply-To: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za> Message-ID: <1442920299.5.0.877708180093.issue25188@psf.upfronthosting.co.za> Alecsandru Patrascu added the comment: Thank you for the link. I modified regrtest.py for Python3 according to the specifications. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 13:30:54 2015 From: report at bugs.python.org (Petr Prikryl) Date: Tue, 22 Sep 2015 11:30:54 +0000 Subject: [issue16322] time.tzname on Python 3.3.0 for Windows is decoded by wrong encoding In-Reply-To: <1351166210.69.0.0993824857313.issue16322@psf.upfronthosting.co.za> Message-ID: <1442921454.35.0.924658370483.issue16322@psf.upfronthosting.co.za> Petr Prikryl added the comment: @eryksun: Thanks for your help. I have finaly ended with your... "Call setlocale(LC_CTYPE, ''), and then call time.strftime('%Z') to get the timezone name." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 14:00:08 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 22 Sep 2015 12:00:08 +0000 Subject: [issue25186] Don't duplicate _verbose_message in importlib._bootstrap and _bootstrap_external In-Reply-To: <1442703732.01.0.764614399851.issue25186@psf.upfronthosting.co.za> Message-ID: Eric Snow added the comment: I'm fairly sure this was just an oversight on my part. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 14:18:18 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 22 Sep 2015 12:18:18 +0000 Subject: [issue25212] Remove the double spaces in the C-API Intro Message-ID: <1442924296.56.0.832273606217.issue25212@psf.upfronthosting.co.za> New submission from St?phane Wirtel: Remove the double spaces in the C-API intro in the documentation. ---------- assignee: docs at python components: Documentation files: remove_double_space_capi.patch keywords: patch messages: 251310 nosy: docs at python, matrixise priority: normal severity: normal status: open title: Remove the double spaces in the C-API Intro versions: Python 3.6 Added file: http://bugs.python.org/file40548/remove_double_space_capi.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 14:25:38 2015 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 22 Sep 2015 12:25:38 +0000 Subject: [issue25212] Remove the double spaces in the C-API Intro In-Reply-To: <1442924296.56.0.832273606217.issue25212@psf.upfronthosting.co.za> Message-ID: <1442924738.43.0.50899264257.issue25212@psf.upfronthosting.co.za> Ezio Melotti added the comment: Thanks for your contribution, however double spaces after a full stop should be kept, since they are intentional (they make the .rst source more readable). Your patch also seems to include other instances that are not after a full stop. In theory those could be kept, but I'm not sure if it's worth spending time preparing and applying a new patch. ---------- nosy: +ezio.melotti priority: normal -> low status: open -> pending type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 14:32:45 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 22 Sep 2015 12:32:45 +0000 Subject: [issue25212] Remove the double spaces in the C-API Intro In-Reply-To: <1442924296.56.0.832273606217.issue25212@psf.upfronthosting.co.za> Message-ID: <1442925165.71.0.638810720181.issue25212@psf.upfronthosting.co.za> St?phane Wirtel added the comment: Hi Ezio, What's a full stop ? Thanks ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 14:34:17 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 22 Sep 2015 12:34:17 +0000 Subject: [issue25212] Remove the double spaces in the C-API Intro In-Reply-To: <1442924296.56.0.832273606217.issue25212@psf.upfronthosting.co.za> Message-ID: <1442925257.41.0.143086369629.issue25212@psf.upfronthosting.co.za> St?phane Wirtel added the comment: ok, found: http://www.edufind.com/english-grammar/period-full-stop-or-point/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 14:36:25 2015 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 22 Sep 2015 12:36:25 +0000 Subject: [issue25212] Remove the double spaces in the C-API Intro In-Reply-To: <1442924296.56.0.832273606217.issue25212@psf.upfronthosting.co.za> Message-ID: <1442925385.04.0.653946132686.issue25212@psf.upfronthosting.co.za> Ezio Melotti added the comment: The `.` at the end of a sentence. In the following example, the double space between "is" and "an" could be fixed (even though is not a big problem), whereas the one between "example." and "This" is OK and should be kept: This is an example. This too. ^^ ^^ Not OK OK ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 15:02:46 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 22 Sep 2015 13:02:46 +0000 Subject: [issue25212] Remove the double spaces in the C-API Intro In-Reply-To: <1442925385.04.0.653946132686.issue25212@psf.upfronthosting.co.za> Message-ID: St?phane Wirtel added the comment: And in this case: ?This is an example. This too? will become ?This is an example. This too? Is it right? Stef On 22 Sep 2015, at 14:36, Ezio Melotti wrote: > Ezio Melotti added the comment: > > The `.` at the end of a sentence. > > In the following example, the double space between "is" and "an" could > be fixed (even though is not a big problem), whereas the one between > "example." and "This" is OK and should be kept: > > This is an example. This too. > ^^ ^^ > Not OK OK > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 15:06:30 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Sep 2015 13:06:30 +0000 Subject: [issue25212] Remove the double spaces in the C-API Intro In-Reply-To: <1442924296.56.0.832273606217.issue25212@psf.upfronthosting.co.za> Message-ID: <1442927190.94.0.611129099049.issue25212@psf.upfronthosting.co.za> STINNER Victor added the comment: The vim editor *adds* two spaces between a full stop and the beginning of a new sentence. As a french, I was always distributed by this, but it's correct in english :-) As Ezio wrote, it may even be better to have two spaces than one, for readability. Well well well, this issue is really border line because users don't read the .rst files but the HTML output which uses a single space. Seriously, why really cares? Just close the issue as WONTFIX and try to enhance the doc differently ;-) ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 15:07:29 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Sep 2015 13:07:29 +0000 Subject: [issue25212] Remove the double spaces in the C-API Intro In-Reply-To: <1442924296.56.0.832273606217.issue25212@psf.upfronthosting.co.za> Message-ID: <1442927249.94.0.166879321388.issue25212@psf.upfronthosting.co.za> STINNER Victor added the comment: If you would like to contribute to the Python doc, please help to make the asyncio doc simpler for new comers. Maybe add a few more examples. Or explain better asyncio concepts like tasks, coroutines and futures. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 15:25:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Sep 2015 13:25:10 +0000 Subject: [issue25212] Remove the double spaces in the C-API Intro In-Reply-To: <1442924296.56.0.832273606217.issue25212@psf.upfronthosting.co.za> Message-ID: <1442928310.81.0.74501471654.issue25212@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: PEP 8: You should use two spaces after a sentence-ending period. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 15:29:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Sep 2015 13:29:03 +0000 Subject: [issue25212] Remove the double spaces in the C-API Intro In-Reply-To: <1442924296.56.0.832273606217.issue25212@psf.upfronthosting.co.za> Message-ID: <1442928543.74.0.249287526813.issue25212@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: PEP 9: You must adhere to the Emacs convention of adding two spaces at the end of every sentence. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 15:32:07 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 22 Sep 2015 13:32:07 +0000 Subject: [issue25212] Remove the double spaces in the C-API Intro In-Reply-To: <1442924296.56.0.832273606217.issue25212@psf.upfronthosting.co.za> Message-ID: <1442928727.32.0.050120914447.issue25212@psf.upfronthosting.co.za> St?phane Wirtel added the comment: ok, can I close this useless issue ? Thank you for the details about the emacs convention and the rest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 15:48:23 2015 From: report at bugs.python.org (Bernard Spil) Date: Tue, 22 Sep 2015 13:48:23 +0000 Subject: [issue23329] _ssl cannot be compiled with LibreSSL anymore (on OpenBSD 5.5) because of ALPN In-Reply-To: <1422353692.3.0.280216678648.issue23329@psf.upfronthosting.co.za> Message-ID: <1442929703.65.0.553121028906.issue23329@psf.upfronthosting.co.za> Bernard Spil added the comment: ALPN was removed originally but added again later http://marc.info/?l=openbsd-announce&m=142193407304782 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 15:48:40 2015 From: report at bugs.python.org (Nick Evans) Date: Tue, 22 Sep 2015 13:48:40 +0000 Subject: [issue25213] Regression: Python 3.5.0 shutil.copy2 doesn't raise PermissionError on Windows 7 Message-ID: <1442929720.2.0.722583571486.issue25213@psf.upfronthosting.co.za> New submission from Nick Evans: Python 3.5.0 shutil.copy2 doesn't raise PermissionError when it does not have permission to copy a file (tested on Windows 7): C:\Users\X\Desktop>C:\Users\X\AppData\Local\Programs\Python\Python35-32\python.exe Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:16:59) [MSC v.1900 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import shutil >>> shutil.copy2("test.txt", "/") '/test.txt' >>> shutil.copy2("test.txt", "C:\\") 'C:\\test.txt' NB: The file is not copied. Python 3.4.3 does raise PermissionError: C:\Users\X\Desktop>C:\Python34\python.exe Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import shutil >>> shutil.copy2("test.txt", "/") Traceback (most recent call last): File "", line 1, in File "C:\Python34\lib\shutil.py", line 245, in copy2 copyfile(src, dst, follow_symlinks=follow_symlinks) File "C:\Python34\lib\shutil.py", line 109, in copyfile with open(dst, 'wb') as fdst: PermissionError: [Errno 13] Permission denied: '/test.txt' >>> shutil.copy2("test.txt", "C:\\") Traceback (most recent call last): File "", line 1, in File "C:\Python34\lib\shutil.py", line 245, in copy2 copyfile(src, dst, follow_symlinks=follow_symlinks) File "C:\Python34\lib\shutil.py", line 109, in copyfile with open(dst, 'wb') as fdst: PermissionError: [Errno 13] Permission denied: 'C:\\test.txt' ---------- components: Library (Lib) messages: 251322 nosy: nre3976 priority: normal severity: normal status: open title: Regression: Python 3.5.0 shutil.copy2 doesn't raise PermissionError on Windows 7 versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 16:16:37 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 22 Sep 2015 14:16:37 +0000 Subject: [issue25214] asyncio ssl transport regression Message-ID: <1442931397.2.0.469066320907.issue25214@psf.upfronthosting.co.za> New submission from Andrew Svetlov: Before using SSL BIO (which is great itself BTW) I has a way to access peers certificate by `ssl_transp.get_extra_info('socket').getpeercert()` call. Now socket is a regular socket without `.getpeercert()` method. I use hack like `ssl_transp._ssl_protocol._sslpipe.ssl_object.getpeercert()` as workaround but really interesting in the proper way to do this using public API only. I suggest adding 'ssl_object' key to `ssl_proto` for BIO-based SSL. Thoughts? P.S. See aiohttp commit for workaround bugfix: https://github.com/KeepSafe/aiohttp/commit/e286d4f9fb1993de2438bdca40712cf1660faf9e ---------- components: asyncio keywords: 3.5regression messages: 251323 nosy: asvetlov, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio ssl transport regression type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 16:16:44 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Tue, 22 Sep 2015 14:16:44 +0000 Subject: [issue25212] Remove the double spaces in the C-API Intro In-Reply-To: <1442924296.56.0.832273606217.issue25212@psf.upfronthosting.co.za> Message-ID: <1442931404.32.0.700242291205.issue25212@psf.upfronthosting.co.za> Changes by St?phane Wirtel : ---------- resolution: -> wont fix status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 16:25:04 2015 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 22 Sep 2015 14:25:04 +0000 Subject: [issue25212] Remove the double spaces in the C-API Intro In-Reply-To: <1442924296.56.0.832273606217.issue25212@psf.upfronthosting.co.za> Message-ID: <1442931904.41.0.0934292495226.issue25212@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 17:08:36 2015 From: report at bugs.python.org (Jurjen N.E. Bos) Date: Tue, 22 Sep 2015 15:08:36 +0000 Subject: [issue25215] Simple extension to iter(): iter() returns empty generator Message-ID: <1442934516.43.0.38615635977.issue25215@psf.upfronthosting.co.za> New submission from Jurjen N.E. Bos: When looking for a "neat" way to create an empty generator, I saw on stackOverflow that the crowd wasn't sure what was the "least ugly" way to do it. Proposals where: def emptyIter(): return; yield or def emptyIter(): return iter([]) Then it struck me that a trivial extension to the iter() built-in would be to allow to call it without arguments, thus giving a simple to understand empty iterator, and allowing: def emptyIter(): return iter() (And, of course, this function would not need to exist in any reasonable program in that case.) The implementation would be trivial, I assume. ---------- components: Library (Lib) messages: 251324 nosy: jneb priority: normal severity: normal status: open title: Simple extension to iter(): iter() returns empty generator type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 17:16:48 2015 From: report at bugs.python.org (Zachary Ware) Date: Tue, 22 Sep 2015 15:16:48 +0000 Subject: [issue25215] Simple extension to iter(): iter() returns empty generator In-Reply-To: <1442934516.43.0.38615635977.issue25215@psf.upfronthosting.co.za> Message-ID: <1442935008.55.0.711871328917.issue25215@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 17:27:54 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 22 Sep 2015 15:27:54 +0000 Subject: [issue25206] PEP 498: Minor mistakes/outdateness In-Reply-To: <1442865421.08.0.715266193748.issue25206@psf.upfronthosting.co.za> Message-ID: <20150922152748.9955.26044@psf.io> Roundup Robot added the comment: New changeset df19ba9217e4 by Eric V. Smith in branch 'default': More on issue 25206: typo. https://hg.python.org/peps/rev/df19ba9217e4 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 17:34:10 2015 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 22 Sep 2015 15:34:10 +0000 Subject: [issue25206] PEP 498: Minor mistakes/outdateness In-Reply-To: <1442865421.08.0.715266193748.issue25206@psf.upfronthosting.co.za> Message-ID: <1442936050.6.0.795697651842.issue25206@psf.upfronthosting.co.za> Eric V. Smith added the comment: Thanks for the feedback. On the f"{expr3!s}" ? format(str(expr3)) issue, I'm trying to show the 1 argument version of format (which is what the code generator actually calls). Although I realize that's not a great example, since the string conversion is implicit in format(). Maybe I'll have the !r example be the 1 argument format() call. I'll fix the exceptions, eventually. But I don't want the PEP to become a exact specification of what the exception text will actually be. On this one: f'x={!x}' I'll probably change it to be an error with the empty expression, not with the invalid conversion character. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 17:35:59 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 22 Sep 2015 15:35:59 +0000 Subject: [issue25215] Simple extension to iter(): iter() returns empty generator In-Reply-To: <1442934516.43.0.38615635977.issue25215@psf.upfronthosting.co.za> Message-ID: <1442936159.9.0.124298197156.issue25215@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I'm not sure that python needs a neater way to make an empty generator. It isn't a common use case and there isn't anything wrong with iter([]). There are downsides to expanding an API. It creates yet another thing to learn and remember. Even now, few developers know about the two-argument form of iter(). ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 17:47:00 2015 From: report at bugs.python.org (Jim Jewett) Date: Tue, 22 Sep 2015 15:47:00 +0000 Subject: [issue25216] Warnings stacklevel frames to skip Message-ID: <1442936820.56.0.704192147978.issue25216@psf.upfronthosting.co.za> New submission from Jim Jewett: warnings.warn(stacklevel=2) is a longstanding idiom. It broke in 3.3 because python itself added some additional infrastructure frames in between; now stacklevel should be 8 or 10 in some releases. issue24305 adds a workaround for 3.5, to ignore internal frames -- defined as those which contain both 'importlib' and '_bootstrap' in filename. I would prefer to see a supported hook, so that either the caller or the program setup could list other modules or packages to ignore when counting frames. That way, I could write mycall(otherlib(foo)) and otherlib could ensure that the warning pointed to mycall, rather than to something internal to otherlib, even if otherlib were refactored to a different stack depth. Ignoring just the import machinery would of course be a good default. ---------- components: Library (Lib) messages: 251328 nosy: Jim.Jewett priority: normal severity: normal status: open title: Warnings stacklevel frames to skip type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 17:50:33 2015 From: report at bugs.python.org (Jim Jewett) Date: Tue, 22 Sep 2015 15:50:33 +0000 Subject: [issue25216] Warnings stacklevel frames to skip In-Reply-To: <1442936820.56.0.704192147978.issue25216@psf.upfronthosting.co.za> Message-ID: <1442937033.21.0.299219452926.issue25216@psf.upfronthosting.co.za> Changes by Jim Jewett : ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 18:14:00 2015 From: report at bugs.python.org (Brett Cannon) Date: Tue, 22 Sep 2015 16:14:00 +0000 Subject: [issue25215] Simple extension to iter(): iter() returns empty generator In-Reply-To: <1442934516.43.0.38615635977.issue25215@psf.upfronthosting.co.za> Message-ID: <1442938440.77.0.753014956404.issue25215@psf.upfronthosting.co.za> Brett Cannon added the comment: I agree with Raymond. Allowing a non-argument iter() runs the risk of someone messing up and forgetting the arguments and yet having no error that they did so. And considering how easy it is to get an iterator of an empty list or tuple I don't see a benefit. Thanks for the suggestion, Jurjen, but I'm closing this as rejected. ---------- nosy: +brett.cannon resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 18:48:59 2015 From: report at bugs.python.org (Shirshendu Bhowmick) Date: Tue, 22 Sep 2015 16:48:59 +0000 Subject: [issue25157] Installing Python 3.5.0 32bit on Windows 8.1 64bit system gives Error 0x80240017 In-Reply-To: <1442526643.4.0.412457342038.issue25157@psf.upfronthosting.co.za> Message-ID: <1442940539.88.0.118437371788.issue25157@psf.upfronthosting.co.za> Shirshendu Bhowmick added the comment: I am the person with this problem, i have tired the installation on another Windows 8.1 machine but faced the same error. Is there any update on this issue. ---------- nosy: +Shirshendu Bhowmick _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 18:58:44 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Tue, 22 Sep 2015 16:58:44 +0000 Subject: [issue25177] OverflowError in statistics.mean when summing large floats In-Reply-To: <1442690955.44.0.771600760834.issue25177@psf.upfronthosting.co.za> Message-ID: <20150922165839.GQ31152@ando.pearwood.info> Steven D'Aprano added the comment: Bar, thanks for the time you put into diagnosing this error, it is definitely a bug. The intention is for mean([huge, huge]) to return huge, not raise OverflowError. I'm reluctant to say that mean() will *never* raise OverflowError, but it certainly shouldn't do so for this case if it can be avoided. I think Mark's diagnosis is probably correct that refactoring the code will fix this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 19:21:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Sep 2015 17:21:21 +0000 Subject: [issue25209] Append space after completed keywords In-Reply-To: <1442870714.02.0.814978155097.issue25209@psf.upfronthosting.co.za> Message-ID: <1442942481.35.0.192137309053.issue25209@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Good catch Martin. Indeed, "pass", "break" and "continue" don't need a space, and "True", "False" and "None" need a space only in rare cases like "None in collection". Some keywords ("else", "finally", "try") need a colon. But while "return" and "lambda" not always need a space, I think that needing a space is more common case, and in any case the redundant space doesn't make a harm. Here is revised patch that doesn't add a space in some cases and instead adds a colon in some cases. ---------- Added file: http://bugs.python.org/file40549/rlcompleter_keyword_space_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 19:23:36 2015 From: report at bugs.python.org (Georg Brandl) Date: Tue, 22 Sep 2015 17:23:36 +0000 Subject: [issue25212] Remove the double spaces in the C-API Intro In-Reply-To: <1442924296.56.0.832273606217.issue25212@psf.upfronthosting.co.za> Message-ID: <1442942616.08.0.0180999561163.issue25212@psf.upfronthosting.co.za> Georg Brandl added the comment: > As a french, I was always distributed by this, but it's correct in english :-) You know what you have to tell LaTeX to not put extra space after all full stops? \frenchspacing :) ---------- nosy: +georg.brandl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 19:38:53 2015 From: report at bugs.python.org (W deW) Date: Tue, 22 Sep 2015 17:38:53 +0000 Subject: [issue25205] setattr accepts invalid identifiers In-Reply-To: <1442861960.51.0.201067879836.issue25205@psf.upfronthosting.co.za> Message-ID: <1442943533.45.0.708595790602.issue25205@psf.upfronthosting.co.za> W deW added the comment: Thanks for the ref to issue14029. I think I see how it works. As long as the object's __dict__ accepts the attributeName as a key, it needs not be a valid string nor a string at all. Though the latter *is* checked for, and that in turn can be circumvented by adding the attribute to the __dict__ directly. An object can be made attribute to itself. However, the documentation falls short here. So far, I haven't found where it defines "attribute". Is there any point in defining an attribute that cannot be addressed as an attribute if the parser doesn't allow it? It seems to me that in order to catch programing errors early, the default behaviour should include checking the valid syntax of the attribute's name. ---------- components: -Documentation versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 19:44:41 2015 From: report at bugs.python.org (Matthias Klose) Date: Tue, 22 Sep 2015 17:44:41 +0000 Subject: [issue17781] optimize compilation options In-Reply-To: <1442917879.37.0.211703225282.issue17781@psf.upfronthosting.co.za> Message-ID: <5601937C.2000602@debian.org> Matthias Klose added the comment: On 22.09.2015 12:31, Antoine Pitrou wrote: > Also note LTO can make compilation times much longer (it's the linking step actually, which can take minutes). use -flto=jobserver ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 19:56:16 2015 From: report at bugs.python.org (eryksun) Date: Tue, 22 Sep 2015 17:56:16 +0000 Subject: [issue25213] Regression: Python 3.5.0 shutil.copy2 doesn't raise PermissionError on Windows 7 In-Reply-To: <1442929720.2.0.722583571486.issue25213@psf.upfronthosting.co.za> Message-ID: <1442944576.81.0.0377096859468.issue25213@psf.upfronthosting.co.za> eryksun added the comment: This issue doesn't pertain to the 64-bit version. C:\Temp>py -3.5 Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import shutil >>> shutil.copy2('test.txt', 'C:\\') Traceback (most recent call last): File "", line 1, in File "C:\Program Files\Python 3.5\lib\shutil.py", line 251, in copy2 copyfile(src, dst, follow_symlinks=follow_symlinks) File "C:\Program Files\Python 3.5\lib\shutil.py", line 115, in copyfile with open(dst, 'wb') as fdst: PermissionError: [Errno 13] Permission denied: 'C:\\test.txt' In the 32-bit version, creating a file in the system root directory gets virtualized when the user doesn't have write access. It's not specific to shutil.copy2. C:\Temp>py -3.5-32 Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:16:59) [MSC v.1900 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> open('C:\\test.txt', 'w').close() >>> import pathlib >>> pathlib.Path('C:\\test.txt').resolve() WindowsPath('C:/Users/usradm/AppData/Local/VirtualStore/test.txt') You can verify in the task manager's details tab that UAC Virtualization is enabled for 32-bit python.exe and disabled for 64-bit python.exe. The problem is that the manifest is missing the requestedExecutionLevel, which should be present and set to "asInvoker". This is discussed in the MSDN article [New UAC Technologies for Windows Vista][1]. >>> os.system('sigcheck -q -m "%s"' % sys.executable) c:\users\usradm\appdata\local\programs\python\python35-32\python.exe: Verified: Signed Signing date: 2:17 AM 9/13/2015 Publisher: Python Software Foundation Description: Python Product: Python Prod version: 3.5.0 File version: 3.5.0 MachineType: 32-bit Manifest: 3.4's manifest sets the requestedExecutionLevel: C:\Temp>py -3.4-32 Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:43:06) [MSC v.1600 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os, sys >>> os.system('sigcheck -q -m "%s"' % sys.executable) c:\users\usradm\appdata\local\programs\python\python34-32\python.exe: Verified: Unsigned Link date: 9:43 PM 2/24/2015 Publisher: n/a Description: n/a Product: n/a Prod version: n/a File version: n/a MachineType: 32-bit Manifest: [1]: https://msdn.microsoft.com/en-us/library/bb756960 ---------- components: +Windows -Library (Lib) keywords: +3.5regression nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 20:08:44 2015 From: report at bugs.python.org (eryksun) Date: Tue, 22 Sep 2015 18:08:44 +0000 Subject: [issue25205] setattr accepts invalid identifiers In-Reply-To: <1442861960.51.0.201067879836.issue25205@psf.upfronthosting.co.za> Message-ID: <1442945324.2.0.959058688889.issue25205@psf.upfronthosting.co.za> eryksun added the comment: This is a documentation issue and not specific to a particular version of Python. What's the rule on version tagging in this case? ---------- components: +Documentation _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 20:31:16 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Sep 2015 18:31:16 +0000 Subject: [issue25214] asyncio ssl transport regression In-Reply-To: <1442931397.2.0.469066320907.issue25214@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: The specific case of getpeercert(), there is an extra info. For other info, did you notice that I just added ssl_object to extra info? :-) http://bugs.python.org/issue25114 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 20:31:47 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Sep 2015 18:31:47 +0000 Subject: [issue23513] Add support for classes/object model in multiprocessing/pickle In-Reply-To: <1424797303.36.0.545069200968.issue23513@psf.upfronthosting.co.za> Message-ID: <1442946707.84.0.790411798694.issue23513@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 20:38:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Sep 2015 18:38:10 +0000 Subject: [issue10717] Multiprocessing module cannot call instance methods across processes In-Reply-To: <1292508539.32.0.622447898726.issue10717@psf.upfronthosting.co.za> Message-ID: <1442947090.41.0.922534517377.issue10717@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> wont fix stage: needs patch -> resolved status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 20:48:59 2015 From: report at bugs.python.org (Remi Pointel) Date: Tue, 22 Sep 2015 18:48:59 +0000 Subject: [issue23329] _ssl cannot be compiled with LibreSSL anymore (on OpenBSD 5.5) because of ALPN In-Reply-To: <1422353692.3.0.280216678648.issue23329@psf.upfronthosting.co.za> Message-ID: <1442947739.73.0.752258990694.issue23329@psf.upfronthosting.co.za> Remi Pointel added the comment: Maybe we could check if the functionality is available instead of checking a version? What do you think about that? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 20:52:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Sep 2015 18:52:22 +0000 Subject: [issue16251] pickle special methods are looked up on the instance rather than the type In-Reply-To: <1350411894.01.0.763638555345.issue16251@psf.upfronthosting.co.za> Message-ID: <1442947942.44.0.18665474598.issue16251@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Is this issue fixed? ---------- nosy: +serhiy.storchaka status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 20:59:11 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 22 Sep 2015 18:59:11 +0000 Subject: [issue25217] Method cache can crash at shutdown in _PyType_Lookup Message-ID: <1442948351.56.0.970630575285.issue25217@psf.upfronthosting.co.za> New submission from Antoine Pitrou: In the following gdb backtrace you'll see that if Python code is executed from the PyInterpreterState_Clear() step in Py_Finalize() (apparently when clearing the builtins), _PyType_Lookup() can be executed and crash on a NULL entry in the method cache. Note the reason this happens is that we set a weakref callback on the global print() function, and for some reason the weakref is able to survive longer than the global print() function. We don't have the crash on previous versions of Python (< 3.5). Here is the backtrace: #0 0x00007fc17dba90cf in _PyType_Lookup (type=type at entry=0x291e0d8, name=name at entry='_globals') at Objects/typeobject.c:2913 #1 0x00007fc17db90346 in _PyObject_GenericGetAttrWithDict (obj= , attributes={<_TypeMetaclass(_abc_negative_cache_version=30, __module__='numba.types', _abc_registry=, data=set()) at remote 0x7fc175c366d8>, __doc__=None, __abstractmethods__=frozenset(), _abc_negative_cache=, data=set()) at remote 0x7fc175c36878>, _abc_cache=, data=set()) at remote 0x7fc175c367a8>) at remote 0x2809e18>: ) at remote 0x7fc1741c2948>, <_TypeMetaclass(_abc_negative_cache_version=30, _abc_cache=, data=set()) at remote 0x7fc175c286d8>, key=, __init__=, can_convert_to=, name=) at Objects/object.c:1119 #3 0x00007fc17db8e3c4 in PyObject_GetAttr ( v=v at entry=, attributes={<_TypeMetaclass(_abc_negative_cache_version=30, __module__='numba.types', _abc_registry=, data=set()) at remote 0x7fc175c366d8>, __doc__=None, __abstractmethods__=frozenset(), _abc_negative_cache=, data=set()) at remote 0x7fc175c36878>, _abc_cache=, data=set()) at remote 0x7fc175c367a8>) at remote 0x2809e18>: ) at remote 0x7fc1741c2948>, <_TypeMetaclass(_abc_negative_cache_version=30, _abc_cache=, data=set()) at remote 0x7fc175c286d8>, key=, __init__=, can_convert_to=) at Objects/object.c:889 #4 0x00007fc17dc37e9d in PyEval_EvalFrameEx ( f=f at entry=Frame 0x7fc17c7887f8, for file /home/antoine/numba/numba/typing/context.py, line 238, in on_disposal (wr=), throwflag=throwflag at entry=0) at Python/ceval.c:2688 #5 0x00007fc17dc3c56c in _PyEval_EvalCodeWithName (_co=, globals=, locals=locals at entry=0x0, args=args at entry=0x7fc174b5e428, argcount=1, kws=kws at entry=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=(,), name=0x0, qualname=0x0) at Python/ceval.c:3962 #6 0x00007fc17dc3c659 in PyEval_EvalCodeEx (_co=, globals=, locals=locals at entry=0x0, args=args at entry=0x7fc174b5e428, argcount=, kws=kws at entry=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=(,)) at Python/ceval.c:3983 #7 0x00007fc17db66f08 in function_call (func=, arg=(,), kw=0x0) at Objects/funcobject.c:632 #8 0x00007fc17db30ce1 in PyObject_Call (func=func at entry=, arg=arg at entry=(,), kw=kw at entry=0x0) at Objects/abstract.c:2147 #9 0x00007fc17db318e8 in PyObject_CallFunctionObjArgs (callable=callable at entry=) at Objects/abstract.c:2427 #10 0x00007fc17dc04228 in handle_callback (ref=ref at entry=0x7fc1741bd2d8, callback=callback at entry=) at Objects/weakrefobject.c:868 #11 0x00007fc17dc047aa in PyObject_ClearWeakRefs (object=object at entry=) at Objects/weakrefobject.c:913 #12 0x00007fc17db8b57c in meth_dealloc (m=m at entry=0x7fc17e1b2d00) at Objects/methodobject.c:155 #13 0x00007fc17db8ee49 in _Py_Dealloc (op=) at Objects/object.c:1786 #14 0x00007fc17db79ca0 in free_keys_object (keys=keys at entry=0x221cef0) at Objects/dictobject.c:354 #15 0x00007fc17db7bb63 in dict_dealloc (mp=mp at entry=0x7fc17e1d62f8) at Objects/dictobject.c:1567 #16 0x00007fc17db8ee49 in _Py_Dealloc ( op={'FileExistsError': , 'NotImplementedError': , 'eval': , 'SystemError': , 'max': , 'repr': , 'sum': , 'ValueError': , 'Ellipsis': , 'next': , 'tuple': , 'StopIteration': , 'ReferenceError': , 'OverflowError': , 'RuntimeWarning': , 'issubclass': , 'range': , filename at entry=0x7fc17e152550 "numba/pycc/pycc", closeit=closeit at entry=1, flags=flags at entry=0x7ffc35eb0970) at Python/pythonrun.c:401 #24 0x00007fc17dc6900c in PyRun_AnyFileExFlags (fp=fp at entry=0x22bce90, filename=0x7fc17e152550 "numba/pycc/pycc", closeit=closeit at entry=1, flags=flags at entry=0x7ffc35eb0970) at Python/pythonrun.c:80 #25 0x00007fc17dc83e57 in run_file (fp=fp at entry=0x22bce90, filename=filename at entry=0x21f4300 L"numba/pycc/pycc", p_cf=p_cf at entry=0x7ffc35eb0970) at Modules/main.c:318 #26 0x00007fc17dc84a9b in Py_Main (argc=argc at entry=3, argv=argv at entry=0x21f3020) at Modules/main.c:769 #27 0x0000000000400bea in main (argc=3, argv=0x7ffc35eb0b88) at ./Programs/python.c:69 Some inspection of local variables at the crash point: (gdb) p type $1 = (PyTypeObject *) 0x291e0d8 (gdb) p type->tp_flags $2 = 808449 (gdb) p type->tp_version_tag $3 = 1769 (gdb) p method_cache $4 = {{version = 0, name = 0x0, value = 0x0} , {version = 1769, name = 0x0, value = 0x0}, {version = 0, name = 0x0, value = 0x0} } (gdb) p method_cache[h] $5 = {version = 1769, name = 0x0, value = 0x0} ---------- components: Interpreter Core messages: 251341 nosy: pitrou priority: normal severity: normal status: open title: Method cache can crash at shutdown in _PyType_Lookup type: crash versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 21:08:02 2015 From: report at bugs.python.org (Mark Shannon) Date: Tue, 22 Sep 2015 19:08:02 +0000 Subject: [issue25217] Method cache can crash at shutdown in _PyType_Lookup In-Reply-To: <1442948351.56.0.970630575285.issue25217@psf.upfronthosting.co.za> Message-ID: <1442948882.99.0.0304375331708.issue25217@psf.upfronthosting.co.za> Changes by Mark Shannon : ---------- nosy: +Mark.Shannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 21:16:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Sep 2015 19:16:14 +0000 Subject: [issue9051] Improve pickle format for timezone aware datetime instances In-Reply-To: <1277151308.95.0.331220838487.issue9051@psf.upfronthosting.co.za> Message-ID: <1442949374.12.0.131814120665.issue9051@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For stability it is better to use public name 'timezone.utc' instead of '_utc'. Dotted names now are supported with all protocols. > but there is still room for improvement: Don't worry about this. When you pickle a number of datetime objects with the same timezone, the timezone is pickled only once and for all other datetime objects only a reference is used. ---------- nosy: +serhiy.storchaka type: behavior -> enhancement versions: +Python 3.6 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 21:19:01 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 22 Sep 2015 19:19:01 +0000 Subject: [issue16251] pickle special methods are looked up on the instance rather than the type In-Reply-To: <1442947942.44.0.18665474598.issue16251@psf.upfronthosting.co.za> Message-ID: <1442949538.3257174.390782001.558E9509@webmail.messagingengine.com> Benjamin Peterson added the comment: I don't think so. On Tue, Sep 22, 2015, at 11:52, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > Is this issue fixed? > > ---------- > nosy: +serhiy.storchaka > status: open -> pending > > _______________________________________ > Python tracker > > _______________________________________ ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 21:49:06 2015 From: report at bugs.python.org (Moritz Sichert) Date: Tue, 22 Sep 2015 19:49:06 +0000 Subject: [issue24295] Backport of #17086 causes regression in setup.py In-Reply-To: <1432723014.0.0.831198232873.issue24295@psf.upfronthosting.co.za> Message-ID: <1442951346.96.0.494758608709.issue24295@psf.upfronthosting.co.za> Moritz Sichert added the comment: No this isn't an issue in Python 3.5. It was caused by the backport that was diffed against an older version that didn't include 7955d769fdf5 and thus reverted that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 23:32:48 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 22 Sep 2015 21:32:48 +0000 Subject: [issue25205] setattr accepts invalid identifiers In-Reply-To: <1442861960.51.0.201067879836.issue25205@psf.upfronthosting.co.za> Message-ID: <1442957568.17.0.32200077735.issue25205@psf.upfronthosting.co.za> Martin Panter added the comment: Eryksun: If you mean tagging the bug report, I think we usually tag all the applicable open branches that are due for another release. I?m not sure anything needs to be documented regarding setattr(). At best it is an implementation detail that should not be relied on, although making the implementation stricter could be a compatibility problem. There are other places where troublesome names are allowed. One that caught my eye recently is os.sendfile(in=..., ...) is a syntax error, but you can still pass the ?in? keyword via os.sendfile(**{"in": ...}, ...). ---------- versions: +Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 23:34:30 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 22 Sep 2015 21:34:30 +0000 Subject: [issue25213] Regression: Python 3.5.0 shutil.copy2 doesn't raise PermissionError on Windows 7 In-Reply-To: <1442929720.2.0.722583571486.issue25213@psf.upfronthosting.co.za> Message-ID: <1442957670.5.0.0401537628549.issue25213@psf.upfronthosting.co.za> Steve Dower added the comment: Confirmed. I have a trivial fix coming to restore the requestedExecutionLevel. ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 23:44:08 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 22 Sep 2015 21:44:08 +0000 Subject: [issue25209] Append space after completed keywords In-Reply-To: <1442870714.02.0.814978155097.issue25209@psf.upfronthosting.co.za> Message-ID: <1442958248.04.0.358963566673.issue25209@psf.upfronthosting.co.za> Martin Panter added the comment: ?Else? doesn?t always use a colon. Consider ?1 if x else 2?. Again, if Python started adding unwanted spaces and colons I imagine users could be annoyed and think Python is being too smart and complicated for its own good. But maybe see what others say. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 23:44:54 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 22 Sep 2015 21:44:54 +0000 Subject: [issue20519] Replace uuid ctypes usage with an extension module. In-Reply-To: <1391601143.27.0.910101155735.issue20519@psf.upfronthosting.co.za> Message-ID: <1442958294.44.0.106919021073.issue20519@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 23:47:58 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 22 Sep 2015 21:47:58 +0000 Subject: [issue25124] No single .msi available for 3.5 release In-Reply-To: <1442315365.32.0.493745807723.issue25124@psf.upfronthosting.co.za> Message-ID: <1442958478.63.0.607358318851.issue25124@psf.upfronthosting.co.za> Steve Dower added the comment: The decision cannot reasonably be reversed now - this sort of passionate feedback was really needed during the alphas to have any impact. I'm sorry you didn't feel the need to participate in Python's development, as this extra feedback would have been useful. For most users who are installing Python for themselves, the bundle launcher provides a much better experience. As well as CRT detection, it also allows true per-user installation as well as decoupling tasks such as precompiling .pyc files from installing components and enabling the web installers. There is also a more reliable upgrade mechanism that retains previous settings and the launcher is now correctly reference counted (though there will be conflicts with the 2.7 and 3.4 installer...). After discussions at PyCon US in April, I chose to make the per-user installation the default as it best fits the user segment we (as a development team) are most concerned about. Administrators who are deploying across a network do now need to work harder than before, which we considered a fair tradeoff for non-admin users to be able to install and use Python. If you much prefer MSIs, you can pass the /layout option to the wrapper and obtain the raw MSIs and install them individually (passing "TARGETPATH=location" as a property). However, I think the documentation for the launcher options (https://docs.python.org/3.5/using/windows.html) is much better than anything we had in the past (I had nothing to do with the old installer, but had to regularly decompile it to diagnose installation issues). So thankyou for the feedback, but on balance between administrators and individual users we've decided to help save individual users from having to read documentation, at the expense of needing administrators to refer to the instructions to do automated installation. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 23:49:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 22 Sep 2015 21:49:25 +0000 Subject: [issue25159] Regression in time to import a module In-Reply-To: <1442556606.15.0.522584302018.issue25159@psf.upfronthosting.co.za> Message-ID: <1442958565.64.0.66398046692.issue25159@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I just have rebuilt my Python's in development brances after made distclean to avoid possible effects of incremental building, and got the same results. (1) for i in `seq 5`; do ./python -I -m timeit -n1 -r1 -s "import sys; sys.modules.clear()" -- "import enum"; done Python 3.4: 29 msec Python 3.5: 43.4 msec (+50%) Python 3.6: 44.4 msec (+2%, +53%) (2) for i in `seq 5`; do ./python -I -m timeit "import enum"; done Python 3.4: 3.02 usec Python 3.5: 3.14 usec (+4%) Python 3.6: 3.34 usec (+6%, +10%) (3) for i in `seq 5`; do ./python -I -m timeit -n1 -r1 "import enum"; done Python 3.4: 3.49 msec Python 3.5: 4.19 msec (+20%) Python 3.6: 4.45 msec (+6%, +28%) 32-bit Ubuntu 14.04, Linux 3.16, gcc 4.8.4, Intel(R) Atom(TM) CPU N570 @ 1.66GH. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 23:49:50 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 22 Sep 2015 21:49:50 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442958590.44.0.419700451029.issue25092@psf.upfronthosting.co.za> Steve Dower added the comment: Arguably it's because of the platforms that don't reliably set errno. (I don't know exactly which those are, but I'm not about to enable it everywhere right now. If someone else wants to do it and deal with the fallout they're welcome.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 23:51:48 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 22 Sep 2015 21:51:48 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442958708.14.0.364860717279.issue25092@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Sep 22 23:59:40 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 22 Sep 2015 21:59:40 +0000 Subject: [issue25116] It failed to install Py3.5 on win2008R2 In-Reply-To: <1442289223.22.0.363627873073.issue25116@psf.upfronthosting.co.za> Message-ID: <1442959180.34.0.077711990499.issue25116@psf.upfronthosting.co.za> Steve Dower added the comment: If you could provide more information, that would be helpful. In particular, there may be some entries in the Event Log around the time you were trying to install 3.5, if nothing popped up at all. There may also be log files in your %TEMP% directory. ---------- components: +Windows nosy: +paul.moore, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 00:06:25 2015 From: report at bugs.python.org (Yann Sionneau) Date: Tue, 22 Sep 2015 22:06:25 +0000 Subject: [issue23630] support multiple hosts in create_server/start_server In-Reply-To: <1426011521.84.0.690218000796.issue23630@psf.upfronthosting.co.za> Message-ID: <1442959585.11.0.447847230114.issue23630@psf.upfronthosting.co.za> Yann Sionneau added the comment: Thanks a lot Victor for your numerous reviews and your help on this! Also thanks for all other who commented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 00:07:29 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 22 Sep 2015 22:07:29 +0000 Subject: [issue25086] Windows x86-64 embeddable zip file, lot of big EXE files in distuils In-Reply-To: <1442152268.71.0.790140517875.issue25086@psf.upfronthosting.co.za> Message-ID: <1442959649.66.0.936200462136.issue25086@psf.upfronthosting.co.za> Steve Dower added the comment: Good catch, none of the bdist_wininst command is really needed. I'll drop it. ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 00:10:00 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 22 Sep 2015 22:10:00 +0000 Subject: [issue25085] Windows x86-64 embeddable zip file contains test directorys In-Reply-To: <1442151945.16.0.782887699168.issue25085@psf.upfronthosting.co.za> Message-ID: <1442959800.48.0.196932389632.issue25085@psf.upfronthosting.co.za> Steve Dower added the comment: True, those files aren't needed in the embeddable distro. Terry - you're right, if someone chooses to install Tcl/Tk/idle then they'll get the tests for them as well, regardless of their test suite selection. Since we're not really talking about a lot of files, I'd rather leave them this way (which I think is what you're also suggesting?) than deal with the cross-installer dependencies that would exist otherwise. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 00:10:08 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 22 Sep 2015 22:10:08 +0000 Subject: [issue25085] Windows x86-64 embeddable zip file contains test directorys In-Reply-To: <1442151945.16.0.782887699168.issue25085@psf.upfronthosting.co.za> Message-ID: <1442959808.11.0.575089578259.issue25085@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 00:12:26 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 22 Sep 2015 22:12:26 +0000 Subject: [issue25103] 3.5.0 installed standard library on Windows has LF line endings In-Reply-To: <1442208824.41.0.568116526355.issue25103@psf.upfronthosting.co.za> Message-ID: <1442959946.27.0.59563789483.issue25103@psf.upfronthosting.co.za> Steve Dower added the comment: Yeah, this was just me forgetting to enable eol when I last recreated my build machine. It's on now, so the next release will be fine. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 00:17:50 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 22 Sep 2015 22:17:50 +0000 Subject: [issue25112] Windows installer assigns non-existent icons to Python file types In-Reply-To: <1442253725.07.0.74818964148.issue25112@psf.upfronthosting.co.za> Message-ID: <1442960270.91.0.820577104828.issue25112@psf.upfronthosting.co.za> Steve Dower added the comment: The file associations are actually part of the launcher, which *technically* is independent of the Python install it is bundled with. So it doesn't have any references to the Python install directory, and double-clicking Python files with shebang lines will work properly. For 3.5.1 I'm considering making the launcher an independent uninstall item (in response to another issue), so if you install 3.5.1 and then remove it, you can keep the launcher. For this to work, it has to be independent of the main install, so it can't refer to the DLLs directory. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 00:19:48 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 22 Sep 2015 22:19:48 +0000 Subject: [issue25126] Non-web installer fails without a connection when doing debug install In-Reply-To: <1442320100.9.0.744175303386.issue25126@psf.upfronthosting.co.za> Message-ID: <1442960388.89.0.459067096446.issue25126@psf.upfronthosting.co.za> Steve Dower added the comment: Yeah, changing the item description is a good suggestion. It basically doubles the size of the download to include everything all at once. ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 00:26:53 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 22 Sep 2015 22:26:53 +0000 Subject: [issue25148] Windows registry PythonCore key changed inconsistent with other releases In-Reply-To: <1442481151.22.0.29783958187.issue25148@psf.upfronthosting.co.za> Message-ID: <1442960813.62.0.0909340221267.issue25148@psf.upfronthosting.co.za> Steve Dower added the comment: It was changed to be consistent with the PEP 397 launcher (and the launcher was actually updated to match the registry key directly, rather than special-casing the "-32" suffix). The original naming ("3.5") can't be used because you can't simultaneously install 32-bit and 64-bit per-user Pythons with the same key name. (Previously it would "work", but you couldn't find both of them through the registry. Now, because of other changes, it will have more serious issues.) Changing to "3.5-64" and "3.5-32" and not use "3.5" anymore was inconsistent with the launcher, but that's a fairly weak reason. There just didn't seem to be a stronger reason to change. (I don't consider this a bug, so I'm closing, but if Barry or someone else wants to argue that it should be changed then I'm willing to consider it for 3.6. I don't think changing it for 3.5.1 is a good move at this point.) ---------- components: +Windows nosy: +paul.moore, tim.golden, zach.ware resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 00:42:02 2015 From: report at bugs.python.org (Mark Roseman) Date: Tue, 22 Sep 2015 22:42:02 +0000 Subject: [issue15347] IDLE - does not close if the debugger was active In-Reply-To: <1342207963.58.0.539607447258.issue15347@psf.upfronthosting.co.za> Message-ID: <1442961722.15.0.766414132685.issue15347@psf.upfronthosting.co.za> Mark Roseman added the comment: Figured out the cause of this hang, it was to do with the nested event loops. It turns out that mainloop() really should just be for the mainloop. Or at least quit() should only be used to quit the outer loop, as it relies on setting a static variable, so is not reentrant, i.e. does not handle nested event loops. I changed the nested loop to use a different mechanism to start the nested event loop (vwait, which waits for a tcl variable to be set) and terminate the nested loop (setting that variable). Have attached fix-nested-mainloop.patch. Fixes the problem here, and in #15348, and another case I was using (start, enable debugger, open module, run module, quit). The one in #24455 is something different, I'll look into it. ---------- keywords: +patch Added file: http://bugs.python.org/file40550/fix-nested-mainloop.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 01:34:15 2015 From: report at bugs.python.org (Mark Roseman) Date: Tue, 22 Sep 2015 23:34:15 +0000 Subject: [issue17942] IDLE Debugger: Improve GUI In-Reply-To: <1368076818.55.0.00268388045116.issue17942@psf.upfronthosting.co.za> Message-ID: <1442964855.81.0.833016932872.issue17942@psf.upfronthosting.co.za> Mark Roseman added the comment: Have attached debugger-ui.patch, which greatly updates the user interface for the existing debugger. This also relies on some images that should be downloaded and unpacked into the 'Icons' directory: http://www.tkdocs.com/images/debugicons.zip Summary of changes: * works with both Tk 8.4 and 8.5+ * paned window separates left and right, allowing adjusting relative sizes * on left, toolbar with graphical/text buttons, plus message, and stack * on right, local and global variables of selected stack frame * running program can be interrupted via 'stop' button * stack and variables use listbox (8.4) or tree (with resizable columns) * removed locals, globals, and stack 'view' options * source option changed to auto-open windows to see source * can always view source by double-clicking or context menu in stack * full value of variable can be seen via tooltip in variable list In future, this will also replace the 'stack viewer' feature for displaying exceptions, but this has not yet been integrated. ---------- keywords: +patch Added file: http://bugs.python.org/file40551/debugger-ui.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 01:36:46 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 22 Sep 2015 23:36:46 +0000 Subject: [issue25081] Windows installer Upgrade->Customize->Back goes to Install page In-Reply-To: <1442113636.61.0.345920202816.issue25081@psf.upfronthosting.co.za> Message-ID: <1442965006.09.0.352903939944.issue25081@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 01:53:43 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 22 Sep 2015 23:53:43 +0000 Subject: [issue25125] "Edit with IDLE" does not work for shortcuts In-Reply-To: <1442318370.13.0.116980940121.issue25125@psf.upfronthosting.co.za> Message-ID: <1442966023.79.0.495484487491.issue25125@psf.upfronthosting.co.za> Steve Dower added the comment: Can you try executing the following command (fix the paths as necessary, but leave all the quotes where they are): "C:\Program Files (x86)\Python 3.5\python.exe" -m idlelib "C:\test.py" That's what should be launched by the menu, with a minor change to use python.exe instead of pythonw.exe to show up any errors you are hitting. I couldn't reproduce the issue on Windows 10, but when I'm back at work I'll try with some other OS versions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 01:53:50 2015 From: report at bugs.python.org (Steve Dower) Date: Tue, 22 Sep 2015 23:53:50 +0000 Subject: [issue25125] "Edit with IDLE" does not work for shortcuts In-Reply-To: <1442318370.13.0.116980940121.issue25125@psf.upfronthosting.co.za> Message-ID: <1442966030.2.0.559080820797.issue25125@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 02:01:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Sep 2015 00:01:49 +0000 Subject: [issue25126] Non-web installer fails without a connection when doing debug install In-Reply-To: <1442320100.9.0.744175303386.issue25126@psf.upfronthosting.co.za> Message-ID: <20150923000146.31189.89591@psf.io> Roundup Robot added the comment: New changeset 4e98c622ab20 by Steve Dower in branch '3.5': Issue #25126: Clarifies that the non-web installer will download some components. https://hg.python.org/cpython/rev/4e98c622ab20 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 02:01:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Sep 2015 00:01:49 +0000 Subject: [issue25086] Windows x86-64 embeddable zip file, lot of big EXE files in distuils In-Reply-To: <1442152268.71.0.790140517875.issue25086@psf.upfronthosting.co.za> Message-ID: <20150923000146.31189.79283@psf.io> Roundup Robot added the comment: New changeset 812e30f67d6e by Steve Dower in branch '3.5': Closes #25085 and #25086: Exclude distutils and test directories from embeddable distro. https://hg.python.org/cpython/rev/812e30f67d6e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 02:01:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Sep 2015 00:01:51 +0000 Subject: [issue25213] Regression: Python 3.5.0 shutil.copy2 doesn't raise PermissionError on Windows 7 In-Reply-To: <1442929720.2.0.722583571486.issue25213@psf.upfronthosting.co.za> Message-ID: <20150923000146.31189.8080@psf.io> Roundup Robot added the comment: New changeset b7f0f1d1e923 by Steve Dower in branch '3.5': Issue #25213: Restores requestedExecutionLevel to manifest to disable UAC virtualization. https://hg.python.org/cpython/rev/b7f0f1d1e923 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 02:01:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Sep 2015 00:01:51 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <20150923000146.31189.98822@psf.io> Roundup Robot added the comment: New changeset aa6b9205c120 by Steve Dower in branch '3.5': Issue #25092: Fix datetime.strftime() failure when errno was already set to EINVAL. https://hg.python.org/cpython/rev/aa6b9205c120 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 02:01:52 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Sep 2015 00:01:52 +0000 Subject: [issue25081] Windows installer Upgrade->Customize->Back goes to Install page In-Reply-To: <1442113636.61.0.345920202816.issue25081@psf.upfronthosting.co.za> Message-ID: <20150923000146.31189.27438@psf.io> Roundup Robot added the comment: New changeset 94ea3e05817f by Steve Dower in branch '3.5': Issue #25081: Makes Back button in installer go back to upgrade page when upgrading. https://hg.python.org/cpython/rev/94ea3e05817f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 02:01:52 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Sep 2015 00:01:52 +0000 Subject: [issue25102] Windows installer: 'precompile standard library' option should pre-compile with -O and -OO In-Reply-To: <1442206876.09.0.966951912645.issue25102@psf.upfronthosting.co.za> Message-ID: <20150923000146.31189.62356@psf.io> Roundup Robot added the comment: New changeset 31b230e5517e by Steve Dower in branch '3.5': Issue #25102: Windows installer does not precompile for -O or -OO. https://hg.python.org/cpython/rev/31b230e5517e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 02:01:53 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Sep 2015 00:01:53 +0000 Subject: [issue25085] Windows x86-64 embeddable zip file contains test directorys In-Reply-To: <1442151945.16.0.782887699168.issue25085@psf.upfronthosting.co.za> Message-ID: <20150923000146.31189.14736@psf.io> Roundup Robot added the comment: New changeset 812e30f67d6e by Steve Dower in branch '3.5': Closes #25085 and #25086: Exclude distutils and test directories from embeddable distro. https://hg.python.org/cpython/rev/812e30f67d6e ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 02:01:53 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Sep 2015 00:01:53 +0000 Subject: [issue25091] Windows Installer uses small font In-Reply-To: <1442194665.29.0.878710305111.issue25091@psf.upfronthosting.co.za> Message-ID: <20150923000146.31189.26086@psf.io> Roundup Robot added the comment: New changeset 07a3d804c6ea by Steve Dower in branch '3.5': Issue #25091: Increases font size of the installer. https://hg.python.org/cpython/rev/07a3d804c6ea ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 02:26:11 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Sep 2015 00:26:11 +0000 Subject: [issue19143] Finding the Windows version getting messier (detect windows 8.1?) In-Reply-To: <1380675004.25.0.239416620624.issue19143@psf.upfronthosting.co.za> Message-ID: <20150923002607.81649.58494@psf.io> Roundup Robot added the comment: New changeset d8453733cc0c by Steve Dower in branch '2.7': Issue #19143: platform module now reads Windows version from kernel32.dll to avoid compatibility shims. https://hg.python.org/cpython/rev/d8453733cc0c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 02:27:10 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Sep 2015 00:27:10 +0000 Subject: [issue19143] Finding the Windows version getting messier (detect windows 8.1?) In-Reply-To: <1380675004.25.0.239416620624.issue19143@psf.upfronthosting.co.za> Message-ID: <20150923002707.82662.3640@psf.io> Roundup Robot added the comment: New changeset fa869ccf9368 by Steve Dower in branch '3.5': Issue #19143: platform module now reads Windows version from kernel32.dll to avoid compatibility shims. https://hg.python.org/cpython/rev/fa869ccf9368 New changeset 2f55d73e5ad6 by Steve Dower in branch 'default': Issue #19143: platform module now reads Windows version from kernel32.dll to avoid compatibility shims. https://hg.python.org/cpython/rev/2f55d73e5ad6 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 02:32:09 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Sep 2015 00:32:09 +0000 Subject: [issue19143] Finding the Windows version getting messier (detect windows 8.1?) In-Reply-To: <1380675004.25.0.239416620624.issue19143@psf.upfronthosting.co.za> Message-ID: <20150923003206.9947.50664@psf.io> Roundup Robot added the comment: New changeset 2f57270374f7 by Steve Dower in branch '3.4': Issue #19143: platform module now reads Windows version from kernel32.dll to avoid compatibility shims. https://hg.python.org/cpython/rev/2f57270374f7 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 02:33:33 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Sep 2015 00:33:33 +0000 Subject: [issue19143] Finding the Windows version getting messier (detect windows 8.1?) In-Reply-To: <1380675004.25.0.239416620624.issue19143@psf.upfronthosting.co.za> Message-ID: <1442968413.22.0.243976471368.issue19143@psf.upfronthosting.co.za> Steve Dower added the comment: Done. As this is (meant to be) a purely informational/diagnostic module, seems like a good idea to fix every version we're supporting in any way. ---------- assignee: -> steve.dower resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 02:50:58 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Sep 2015 00:50:58 +0000 Subject: [issue25117] Windows installer: precompiling stdlib fails with missing DLL errors In-Reply-To: <1442294819.71.0.839651529049.issue25117@psf.upfronthosting.co.za> Message-ID: <1442969458.23.0.66668516618.issue25117@psf.upfronthosting.co.za> Steve Dower added the comment: The problem here is probably that installing the CRT update required a restart (see the line below from the log), but we didn't interrupt installation to make you restart before continuing. >From the first log file: [0A68:0EC8][2015-09-14T05:54:24]i319: Applied execute package: crt_14.0_v6.2_x64, result: 0x0, restart: Required Handling this nicely could be some work. We would want to force the restart immediately if the user is installing pip or precompiling the stdlib, but otherwise they can finish installation and then restart. I'll try and look into this soon, but I don't think it needs to hold up a 3.5.1. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:00:46 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Sep 2015 01:00:46 +0000 Subject: [issue25144] 3.5 Win install fails with "TARGETDIR" In-Reply-To: <1442424932.17.0.0389991499722.issue25144@psf.upfronthosting.co.za> Message-ID: <1442970046.66.0.164193693518.issue25144@psf.upfronthosting.co.za> Steve Dower added the comment: Well, I made this happen once, but not a second time. That's better than most setup issues I get to deal with :) Still working on it - will post when I figure it out. ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:03:12 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Sep 2015 01:03:12 +0000 Subject: [issue25143] 3.5 install fails poorly on Windows XP In-Reply-To: <1442420286.68.0.457975935538.issue25143@psf.upfronthosting.co.za> Message-ID: <1442970192.48.0.543317191007.issue25143@psf.upfronthosting.co.za> Steve Dower added the comment: I don't have any XP machines handy, but I'll see if I can at least get an early termination from the installer rather than broken UI. IIRC, Larry was against having prominent warnings about unsupported platforms on the download page, but with python.org being the official source of Windows binaries and XP still having an overly large market share, maybe it needs to be there? (Though it probably won't ever be prominent *enough*, and we'll still have people miss it.) ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:07:11 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Sep 2015 01:07:11 +0000 Subject: [issue25165] Windows uninstallation should not remove launcher if other versions remain In-Reply-To: <1442566984.06.0.904088337084.issue25165@psf.upfronthosting.co.za> Message-ID: <1442970431.89.0.0402297438003.issue25165@psf.upfronthosting.co.za> Steve Dower added the comment: I'm going to look into having the launcher's MSI stay behind when the bundle is removed, so it will have to be uninstalled separately. It can already be installed separately, though there isn't a really easy way to get the installer so you can do that. (Because prior versions of Python did not always use the same component ID for the launcher, we have to have a break here. However, we now have a single MSI that is identical for all future versions, so the problem should not arise again.) ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:07:23 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 23 Sep 2015 01:07:23 +0000 Subject: [issue16701] Docs missing the behavior of += (in-place add) for lists. In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za> Message-ID: <1442970443.95.0.788827814438.issue16701@psf.upfronthosting.co.za> Martin Panter added the comment: Here is a patch documenting the += and *= mutable sequence operations. Please review my wording. These operations already seem to be tested, at least on the basic mutable sequences: see /Lib/test/list_tests.py, test_array, test_collections, test_bytes (tests bytearray). The only other places that I thought might be missing augmented assignment were for sets, but there is no problem there: . However, there are other operations that I think may be missing from this page of the documentation. But it might be better to handle those in a separate bug report. Some of this could build off the work in Issue 12067. * Equality comparisons (mentioned for range and dict, but apparently not tuple, set, strings, etc) * Ordering comparisons (not supported for range) * min() and max() don?t really belong; maybe substitute with iter() ---------- keywords: +patch nosy: +martin.panter stage: needs patch -> patch review versions: +Python 3.6 Added file: http://bugs.python.org/file40552/seq-inplace.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:08:15 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Sep 2015 01:08:15 +0000 Subject: [issue25162] Windows installation does not appear in list of installed applications In-Reply-To: <1442563581.64.0.527655601006.issue25162@psf.upfronthosting.co.za> Message-ID: <1442970495.03.0.321623924657.issue25162@psf.upfronthosting.co.za> Steve Dower added the comment: This is caused by the same configuration as issue 25166, so I'm closing this one as a duplicate. ---------- resolution: -> duplicate status: open -> closed superseder: -> Windows AllUsers installation places uninstaller in user profile _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:14:18 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Sep 2015 01:14:18 +0000 Subject: [issue24570] IDLE Autocomplete and Call Tips Do Not Pop Up on OS X with ActiveTcl 8.5.18 In-Reply-To: <1436129307.64.0.192936457067.issue24570@psf.upfronthosting.co.za> Message-ID: <20150923011414.9929.20389@psf.io> Roundup Robot added the comment: New changeset b79dd0d7dc98 by Terry Jan Reedy in branch '2.7': Issue #24570: Right-click for context menus now work on Mac Aqual also. https://hg.python.org/cpython/rev/b79dd0d7dc98 New changeset 51b2b1a821b7 by Terry Jan Reedy in branch '3.4': Issue #24570: Right-click for context menus now work on Mac Aqual also. https://hg.python.org/cpython/rev/51b2b1a821b7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:14:34 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Sep 2015 01:14:34 +0000 Subject: [issue25163] Windows installer in AllUsers mode presents wrong installation path In-Reply-To: <1442564000.23.0.122739262623.issue25163@psf.upfronthosting.co.za> Message-ID: <1442970874.8.0.825392556415.issue25163@psf.upfronthosting.co.za> Steve Dower added the comment: Just an incorrect variable reference in the localization file. Should be easy enough to fix (if the variable is initialized at the start of installation...) ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:15:33 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Sep 2015 01:15:33 +0000 Subject: [issue25164] Windows default installation path is inconsistent between per-user and system-wide installation In-Reply-To: <1442564482.39.0.225945260969.issue25164@psf.upfronthosting.co.za> Message-ID: <1442970933.34.0.295451320946.issue25164@psf.upfronthosting.co.za> Steve Dower added the comment: Might be too much of a breaking change for 3.5.1 - what do the other Windows guys think about making them both "Python 3.5" (or "Python 3.5-32" in the per-user case, to avoid conflicting with a 64-bit install)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:16:13 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 23 Sep 2015 01:16:13 +0000 Subject: [issue10404] IDLE on OS X popup menus do not work: cannot set/clear breakpoints In-Reply-To: <1289637563.28.0.230524563263.issue10404@psf.upfronthosting.co.za> Message-ID: <1442970973.88.0.59976396905.issue10404@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Right click for context menu in Mac Aqua is fixed in ##24570. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:16:32 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Sep 2015 01:16:32 +0000 Subject: [issue25166] Windows AllUsers installation places uninstaller in user profile In-Reply-To: <1442575090.58.0.314641407957.issue25166@psf.upfronthosting.co.za> Message-ID: <1442970992.28.0.033934392543.issue25166@psf.upfronthosting.co.za> Steve Dower added the comment: Burn is always started in the per-user scope so that we can do per-user installs without elevating, but it looks like we need to manually change this once we know it's an all-users install. ---------- assignee: -> steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:19:24 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 23 Sep 2015 01:19:24 +0000 Subject: [issue10404] IDLE on OS X popup menus do not work: cannot set/clear breakpoints In-Reply-To: <1289637563.28.0.230524563263.issue10404@psf.upfronthosting.co.za> Message-ID: <1442971164.41.0.340144104787.issue10404@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Sorry, #24801. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:19:57 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 23 Sep 2015 01:19:57 +0000 Subject: [issue24570] IDLE Autocomplete and Call Tips Do Not Pop Up on OS X with ActiveTcl 8.5.18 In-Reply-To: <1436129307.64.0.192936457067.issue24570@psf.upfronthosting.co.za> Message-ID: <1442971197.39.0.393074122579.issue24570@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- Removed message: http://bugs.python.org/msg251380 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:21:42 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Sep 2015 01:21:42 +0000 Subject: [issue25112] Windows installer assigns non-existent icons to Python file types In-Reply-To: <1442253725.07.0.74818964148.issue25112@psf.upfronthosting.co.za> Message-ID: <20150923012139.115507.20284@psf.io> Roundup Robot added the comment: New changeset 4d0d987bf6a8 by Steve Dower in branch '3.5': Issues #25112: py.exe launcher is missing icons https://hg.python.org/cpython/rev/4d0d987bf6a8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:22:03 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Sep 2015 01:22:03 +0000 Subject: [issue25112] Windows installer assigns non-existent icons to Python file types In-Reply-To: <1442253725.07.0.74818964148.issue25112@psf.upfronthosting.co.za> Message-ID: <1442971323.0.0.398540868435.issue25112@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:22:33 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 23 Sep 2015 01:22:33 +0000 Subject: [issue24801] right-mouse click in IDLE on Mac doesn't work In-Reply-To: <1438824963.67.0.330802461274.issue24801@psf.upfronthosting.co.za> Message-ID: <1442971353.77.0.865972651463.issue24801@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Serhiy, thanks for the review. I bungled the issue number on the commit message, so here are the commit notices. Will correct for NEWS. New changeset b79dd0d7dc98 by Terry Jan Reedy in branch '2.7': Issue #24570: Right-click for context menus now work on Mac Aqual also. https://hg.python.org/cpython/rev/b79dd0d7dc98 New changeset 51b2b1a821b7 by Terry Jan Reedy in branch '3.4': Issue #24570: Right-click for context menus now work on Mac Aqual also. https://hg.python.org/cpython/rev/51b2b1a821b7 ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:23:21 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Sep 2015 01:23:21 +0000 Subject: [issue25196] Installer>Install in user folder by default when you check: for all users In-Reply-To: <1442774913.98.0.448713689083.issue25196@psf.upfronthosting.co.za> Message-ID: <1442971401.88.0.461095144959.issue25196@psf.upfronthosting.co.za> Steve Dower added the comment: Did you check the checkbox on the front page? The checkbox that says "Install launcher for all users" only installs the launcher for all users, which is recommended for compatibility with Python 3.4 or 2.7 (which would otherwise override the launcher with one that doesn't work). To install Python itself for all users you need to go through Customize and select it on the second page. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:23:44 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Sep 2015 01:23:44 +0000 Subject: [issue25092] Regression: test_datetime fails on 3.5, Win 7, works on 3.4 In-Reply-To: <1442199258.72.0.864492928918.issue25092@psf.upfronthosting.co.za> Message-ID: <1442971424.68.0.37333575214.issue25092@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:24:05 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Sep 2015 01:24:05 +0000 Subject: [issue25213] Regression: Python 3.5.0 shutil.copy2 doesn't raise PermissionError on Windows 7 In-Reply-To: <1442929720.2.0.722583571486.issue25213@psf.upfronthosting.co.za> Message-ID: <1442971445.75.0.449290974846.issue25213@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:24:51 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Sep 2015 01:24:51 +0000 Subject: [issue25102] Windows installer: 'precompile standard library' option should pre-compile with -O and -OO In-Reply-To: <1442206876.09.0.966951912645.issue25102@psf.upfronthosting.co.za> Message-ID: <1442971491.95.0.973767610016.issue25102@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:25:04 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Sep 2015 01:25:04 +0000 Subject: [issue25081] Windows installer Upgrade->Customize->Back goes to Install page In-Reply-To: <1442113636.61.0.345920202816.issue25081@psf.upfronthosting.co.za> Message-ID: <1442971504.27.0.21764539235.issue25081@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:25:19 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Sep 2015 01:25:19 +0000 Subject: [issue25086] Windows x86-64 embeddable zip file, lot of big EXE files in distuils In-Reply-To: <1442152268.71.0.790140517875.issue25086@psf.upfronthosting.co.za> Message-ID: <1442971519.21.0.365459917839.issue25086@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:25:41 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Sep 2015 01:25:41 +0000 Subject: [issue25126] Non-web installer fails without a connection when doing debug install In-Reply-To: <1442320100.9.0.744175303386.issue25126@psf.upfronthosting.co.za> Message-ID: <1442971541.38.0.800415116169.issue25126@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:30:58 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 23 Sep 2015 01:30:58 +0000 Subject: [issue16893] Generate Idle help from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1442971858.24.0.518036288399.issue16893@psf.upfronthosting.co.za> Martin Panter added the comment: The tests seem to have grown a new Deprecation Warning (triggered when run with python -bWall). Looks like this may be a side effect of revision 2d808b72996d. [160/392] test_idle /media/disk/home/proj/python/cpython/Lib/idlelib/EditorWindow.py:88: DeprecationWarning: EditorWindow.HelpDialog is no longer used by Idle. It will be removed in 3.6 or later. It has been replaced by private help.HelpWindow helpDialog = HelpDialog() # singleton instance, no longer used ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:53:20 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 23 Sep 2015 01:53:20 +0000 Subject: [issue25085] Windows x86-64 embeddable zip file contains test directorys In-Reply-To: <1442151945.16.0.782887699168.issue25085@psf.upfronthosting.co.za> Message-ID: <1442973200.48.0.11759692671.issue25085@psf.upfronthosting.co.za> Terry J. Reedy added the comment: If the Tcl/Tk/Idle bundle is installed, then I prefer that /idle-test be included, even if '[ ] include tests' is left blank, as I may someday make part of it runnable from the help menu. IE, the status quo. I do not care about any of the other package test directories. If I understand the patch correctly, you already excluded the tkinter bundle from the embeddable zip. The change I see is elimination of site-packages (#?????) and *.exe (#26086). It appears that you rejected the proposal in this issue, so the resolution should say so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 03:57:50 2015 From: report at bugs.python.org (eryksun) Date: Wed, 23 Sep 2015 01:57:50 +0000 Subject: [issue25117] Windows installer: precompiling stdlib fails with missing DLL errors In-Reply-To: <1442294819.71.0.839651529049.issue25117@psf.upfronthosting.co.za> Message-ID: <1442973470.89.0.408304783873.issue25117@psf.upfronthosting.co.za> eryksun added the comment: > The problem here is probably that installing the CRT update > required a restart I saw that, but it didn't make any sense to me that the DLL isn't available immediately after wusa.exe exits. Is it in limbo until the system is restarted? I know in Windows 10 these api-ms-win-crt* DLLs are actually virtual API sets managed by the loader (i.e. they all have the same module handle, that of ucrtbase.dll). How does this relate to what's going on with Windows 8/Server 2012, if at all? Marius reports that "Python seems to work", but doesn't mention whether or not a reboot was necessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 04:07:47 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 23 Sep 2015 02:07:47 +0000 Subject: [issue25047] xml.etree.ElementTree encoding declaration should be capital ('UTF-8') rather than lowercase ('utf-8') In-Reply-To: <1441827818.89.0.928682692456.issue25047@psf.upfronthosting.co.za> Message-ID: <1442974067.31.0.732965350508.issue25047@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- assignee: -> martin.panter nosy: +berker.peksag stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 04:08:32 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Sep 2015 02:08:32 +0000 Subject: [issue25047] xml.etree.ElementTree encoding declaration should be capital ('UTF-8') rather than lowercase ('utf-8') In-Reply-To: <1441827818.89.0.928682692456.issue25047@psf.upfronthosting.co.za> Message-ID: <20150923020827.115182.16436@psf.io> Roundup Robot added the comment: New changeset ff7aba08ada6 by Martin Panter in branch '3.4': Issue #25047: Respect case writing XML encoding declarations https://hg.python.org/cpython/rev/ff7aba08ada6 New changeset 9c248233754c by Martin Panter in branch '3.5': Issue #25047: Merge Element Tree encoding from 3.4 into 3.5 https://hg.python.org/cpython/rev/9c248233754c New changeset 409bab2181d3 by Martin Panter in branch 'default': Issue #25047: Merge Element Tree encoding from 3.5 https://hg.python.org/cpython/rev/409bab2181d3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 04:12:17 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Sep 2015 02:12:17 +0000 Subject: [issue25085] Windows x86-64 embeddable zip file contains test directorys In-Reply-To: <1442151945.16.0.782887699168.issue25085@psf.upfronthosting.co.za> Message-ID: <1442974337.69.0.462194647508.issue25085@psf.upfronthosting.co.za> Steve Dower added the comment: The change is for two issues. I now filter out "Lib\*\test" and "Lib\*\tests" for this one, and bdist_wininst.py and *.exe for #25086. I believe that's what the suggestions were - the regular installer (that we've been discussing) wasn't mentioned in the original post. (Adding site-packages to the set is a bit of tidying that I noticed while fixing the others. It doesn't have an issue anywhere.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 04:14:46 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 23 Sep 2015 02:14:46 +0000 Subject: [issue25047] xml.etree.ElementTree encoding declaration should be capital ('UTF-8') rather than lowercase ('utf-8') In-Reply-To: <1441827818.89.0.928682692456.issue25047@psf.upfronthosting.co.za> Message-ID: <1442974486.86.0.648072139428.issue25047@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 04:15:40 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Sep 2015 02:15:40 +0000 Subject: [issue25117] Windows installer: precompiling stdlib fails with missing DLL errors In-Reply-To: <1442294819.71.0.839651529049.issue25117@psf.upfronthosting.co.za> Message-ID: <1442974540.95.0.17515809858.issue25117@psf.upfronthosting.co.za> Steve Dower added the comment: Windows Updates may do something different here. I'd guess it's added to a queue and will be installed on next restart, probably based on something it detected as being in use, or maybe just because it's a server OS (or possibly both - typically a reboot isn't required to install the UCRT for the first time, but maybe an early prerelease version was there?). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 04:17:13 2015 From: report at bugs.python.org (eryksun) Date: Wed, 23 Sep 2015 02:17:13 +0000 Subject: [issue25166] Windows AllUsers installation places uninstaller in user profile In-Reply-To: <1442575090.58.0.314641407957.issue25166@psf.upfronthosting.co.za> Message-ID: <1442974633.03.0.862296970043.issue25166@psf.upfronthosting.co.za> eryksun added the comment: Where is the API documented to change the install scope dynamically? I see where it's apparently defined in the burn manifest (extracted from the executable) as PerMachine="no": <....> ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 04:23:20 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 23 Sep 2015 02:23:20 +0000 Subject: [issue25166] Windows AllUsers installation places uninstaller in user profile In-Reply-To: <1442575090.58.0.314641407957.issue25166@psf.upfronthosting.co.za> Message-ID: <1442975000.62.0.310310367367.issue25166@psf.upfronthosting.co.za> Steve Dower added the comment: Not sure yet :) There are a lot of undocumented (or not-yet-documented) APIs accessible from the bootstrap app and I haven't gone through them yet - see https://github.com/wixtoolset/wix3/tree/develop/src/libs, probably dutil. It may also be something that we have to request or contribute to WiX. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 04:40:03 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 23 Sep 2015 02:40:03 +0000 Subject: [issue22052] Comparison operators called in reverse order for subclasses with no override. In-Reply-To: <1406149410.09.0.756154064568.issue22052@psf.upfronthosting.co.za> Message-ID: <1442976003.58.0.474172525266.issue22052@psf.upfronthosting.co.za> Martin Panter added the comment: Does anyone know enough about Python 2 to propose a fix? I don?t know enough about object classes versus ?instance? classes, and potential interference of the __cmp__() method. In Python 2 the order seems to depend on the class type: (<__main__.A instance at 0x7f730d37f5f0>, <__main__.B instance at 0x7f730d37f518>) (<__main__.B object at 0x7f730d37dc10>, <__main__.A object at 0x7f730d37d110>) Or perhaps we should just close this now and forget about Python 2 ;) ---------- stage: -> needs patch versions: -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 05:00:30 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Sep 2015 03:00:30 +0000 Subject: [issue16893] Generate Idle help from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <20150923030026.115182.26561@psf.io> Roundup Robot added the comment: New changeset 26e819909891 by Terry Jan Reedy in branch '2.7': Issue #16893: Move idlelib.EditorWindow.HelpDialog deprecation warning https://hg.python.org/cpython/rev/26e819909891 New changeset c607004a98bf by Terry Jan Reedy in branch '3.4': Issue #16893: Move idlelib.EditorWindow.HelpDialog deprecation warning https://hg.python.org/cpython/rev/c607004a98bf ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 05:19:28 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 23 Sep 2015 03:19:28 +0000 Subject: [issue16893] Generate Idle help from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1442978368.25.0.341975302224.issue16893@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thank you for reporting this. My general problem is that idlelib was only informally private until PEP434 and I only started adding 'private' and 'deprecated' to the code a week ago. So I am trying to make changes in existing versions while not breaking even unlikely uses of the current API. The specific problem is the the class init method *is* used -- to create an unused instance -- on import. helpDialog = HelpDialog() # singleton instance, no longer used The patch fixes the problem by moving the deprecation to the show method, which Idle really does not now call. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 05:41:17 2015 From: report at bugs.python.org (Mark Roseman) Date: Wed, 23 Sep 2015 03:41:17 +0000 Subject: [issue24455] IDLE debugger causes crash if not quitted properly before next run In-Reply-To: <1434383850.99.0.136251358232.issue24455@psf.upfronthosting.co.za> Message-ID: <1442979677.95.0.913033690276.issue24455@psf.upfronthosting.co.za> Mark Roseman added the comment: Like #15347 and #15348, this was also caused by nested event loops, though the exact problem is slightly different. I've attached fix-mainloop2.patch which has a lengthy comment explaining the problem and how the patch solves it. This patch also includes the changes from fix-nested-mainloop.patch. ---------- keywords: +patch Added file: http://bugs.python.org/file40553/fix-mainloop2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 05:42:21 2015 From: report at bugs.python.org (Mark Roseman) Date: Wed, 23 Sep 2015 03:42:21 +0000 Subject: [issue15347] IDLE - does not close if the debugger was active In-Reply-To: <1342207963.58.0.539607447258.issue15347@psf.upfronthosting.co.za> Message-ID: <1442979741.56.0.160517645941.issue15347@psf.upfronthosting.co.za> Mark Roseman added the comment: See #24455 for a patch that includes the changes from this one as well as some additional changes that fixes that bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 05:42:35 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 23 Sep 2015 03:42:35 +0000 Subject: [issue25218] Automate creation of idlelib/help.html from Doc/.../idle.html Message-ID: <1442979755.02.0.25591432423.issue25218@psf.upfronthosting.co.za> New submission from Terry J. Reedy: This continues #16893, which replaced help.txt with help.html for the Idle doc display. It also replaced the display classes with new classes in help.py. I currently create help.html in a .bat file. With Doc as current directory, it uses ..\pcbuild\python_d.exe -c "from idlelib.help import copy_strip; copy_strip()" With a change to the help.py if __name__ block so that ..\pcbuild\python_d.exe -m idlelib.help copy_strip would work. This issue is first about revising Zack Ware's makefile patch, https://bugs.python.org/file36975/issue16893-v4.diff, which adds an 'idledoc' target. It is attached to #16893. It needs 'copy' replaced by 'copy, strip, and rename'. The command above requires finding a compatible python.exe, and I do not know if that is a problem. In normal use, 'idledoc' should only be invoked for the earliest 3.x getting maintenance patches, and the result merged forward. If this is resolved, it would be nice if the new 'idledoc' target were built as apart of the release process, and any changes checked in. But the latter should currently still be done for all 3.x branches ---------- assignee: terry.reedy messages: 251402 nosy: terry.reedy, zach.ware priority: normal severity: normal stage: needs patch status: open title: Automate creation of idlelib/help.html from Doc/.../idle.html type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 06:10:23 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 23 Sep 2015 04:10:23 +0000 Subject: [issue16893] Generate Idle help from Doc/library/idle.rst In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za> Message-ID: <1442981423.19.0.0018101034034.issue16893@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Through the contributions of several people, Zack's key idea, that Idle documentation should have a single source, idle.rst, has come to fruition. So I think it time to close this. I already mentioned #25198 for improving the tkinter viewer. I also opened #25218 for revising Zack's patch and possibly using an 'idledoc' target in the release process. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 06:42:08 2015 From: report at bugs.python.org (Christopher Meng) Date: Wed, 23 Sep 2015 04:42:08 +0000 Subject: [issue22834] Unexpected FileNotFoundError when current directory is removed In-Reply-To: <1415591819.35.0.141928158863.issue22834@psf.upfronthosting.co.za> Message-ID: <1442983328.26.0.073710033929.issue22834@psf.upfronthosting.co.za> Changes by Christopher Meng : ---------- nosy: +Christopher Meng _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 07:16:49 2015 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 23 Sep 2015 05:16:49 +0000 Subject: [issue22555] Tracking issue for adjustments to binary/text boundary handling In-Reply-To: <1412481703.35.0.528069461639.issue22555@psf.upfronthosting.co.za> Message-ID: <1442985409.77.0.65585752675.issue22555@psf.upfronthosting.co.za> Nick Coghlan added the comment: The Fedora RFE at https://bugzilla.redhat.com/show_bug.cgi?id=902094 to provide a C.UTF-8 locale by default has been addressed for Fedora 24 (the current Fedora Rawhide). This means the "LANG=C.UTF-8 python3" replacement for the ASCII-centric "LANG=C python3" will become more widely available over the course of 2016. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 07:53:38 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Sep 2015 05:53:38 +0000 Subject: [issue12067] Doc: remove errors about mixed-type comparisons. In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za> Message-ID: <20150923055335.16569.41613@psf.io> Roundup Robot added the comment: New changeset 1fc049e5ec14 by Martin Panter in branch '3.4': Issue #12067: Rewrite Comparisons section in the language reference https://hg.python.org/cpython/rev/1fc049e5ec14 New changeset b6698c00265b by Martin Panter in branch '3.5': Issue #12067: Merge comparisons doc from 3.4 into 3.5 https://hg.python.org/cpython/rev/b6698c00265b New changeset 294b8a7957e9 by Martin Panter in branch 'default': Issue #12067: Merge comparisons doc from 3.5 https://hg.python.org/cpython/rev/294b8a7957e9 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 08:00:06 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 23 Sep 2015 06:00:06 +0000 Subject: [issue12067] Doc: remove errors about mixed-type comparisons. In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za> Message-ID: <1442988006.28.0.99892229294.issue12067@psf.upfronthosting.co.za> Martin Panter added the comment: I committed the changes to expressions.rst for 3.4+. That still leaves the changes to test_compare.py, and possibly changes for 2.7. Andy: In msg229721 you mentioned a potential 2.7 patch. Did you get anywhere with that? Even if it is only half finished, someone else may be able to keep working on it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 08:34:44 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 23 Sep 2015 06:34:44 +0000 Subject: [issue25219] Update doc for Idle command line argument. Message-ID: <1442990084.65.0.133912466016.issue25219@psf.upfronthosting.co.za> New submission from Terry J. Reedy: idle.rst is either wrong or obsolete. Some options are missing and the notes are not now correct. I am editing so it matches code and help message in PyShell.py. I believe there is a mismatch between code and help message with respect to interaction with configuration settings. But I need to do some tests to be sure. ---------- messages: 251407 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Update doc for Idle command line argument. type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 08:59:31 2015 From: report at bugs.python.org (Bernard Spil) Date: Wed, 23 Sep 2015 06:59:31 +0000 Subject: [issue23329] _ssl cannot be compiled with LibreSSL anymore (on OpenBSD 5.5) because of ALPN In-Reply-To: <1422353692.3.0.280216678648.issue23329@psf.upfronthosting.co.za> Message-ID: <1442991571.13.0.618826650615.issue23329@psf.upfronthosting.co.za> Bernard Spil added the comment: Checking if the method is actually defined is the smart way to go >From include/openssl/tls1.h # define TLSEXT_TYPE_application_layer_protocol_negotiation So #ifdef TLSEXT_TYPE_application_layer_protocol_negotiation would show you if the feature is available regardless of the implementation (Open|Boring|Libre)SSL ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 09:01:52 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 23 Sep 2015 07:01:52 +0000 Subject: [issue25198] Idle: improve idle.html help viewer. In-Reply-To: <1442794067.12.0.0580996406415.issue25198@psf.upfronthosting.co.za> Message-ID: <1442991712.6.0.820886903405.issue25198@psf.upfronthosting.co.za> Terry J. Reedy added the comment: List indent glitch: In the command line section, after the box, idle.rst has If there are arguments: #. If ``-``, ``-c``, or ``r`` is used, all arguments are placed in ``sys.argv[1:...]`` and ``sys.argv[0]`` is set to ``''``, ``'-c'``, or ``'-r'``. No editor window is opened, even if that is the default set in the Options dialog. Firefox shows this as (but does not allow copying of '1. ') If there are arguments: 1. If -, -c, or r is used, all arguments are placed in sys.argv[1:...] and sys.argv[0] is set to '', '-c', or '-r'. No editor window is opened, even if that is the default set in the Options dialog. The help window shows this, for example, (but not copy indent) as If there are arguments: * If -, -c, or r is used, all arguments are placed in sys.argv[1:...] and sys.argv[0] is set to '', '-c', or '-r'. No editor window is opened, even if that is the default set in the Options dialog. The point is not '1. ' versus '* ', this being the only place where idle.rst uses '#' for a list (and I changed this). The problem is the dedent of the second line. This only occurs if the second line starts with a font change. If I narrow the window so it begins with 'to', the line is indented properly. Narrow further so it begins with 'sys', no ident. I am pretty sure I have not touched your indent code. Any ideas on how to fix? or a tk glitch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 09:02:07 2015 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 23 Sep 2015 07:02:07 +0000 Subject: [issue22052] Comparison operators called in reverse order for subclasses with no override. In-Reply-To: <1406149410.09.0.756154064568.issue22052@psf.upfronthosting.co.za> Message-ID: <1442991727.6.0.822100554615.issue22052@psf.upfronthosting.co.za> Mark Dickinson added the comment: For Python 2, I think the most we should do is document the behaviour somewhere; changing it in a bugfix release seems both unnecessary and potentially risky. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 09:04:05 2015 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 23 Sep 2015 07:04:05 +0000 Subject: [issue22052] Comparison operators called in reverse order for subclasses with no override. In-Reply-To: <1406149410.09.0.756154064568.issue22052@psf.upfronthosting.co.za> Message-ID: <1442991845.56.0.809441584278.issue22052@psf.upfronthosting.co.za> Mark Dickinson added the comment: > the most we should do is document the behaviour somewhere And indeed, perhaps this issue counts as sufficient documentation... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 09:09:00 2015 From: report at bugs.python.org (Marius Gedminas) Date: Wed, 23 Sep 2015 07:09:00 +0000 Subject: [issue25117] Windows installer: precompiling stdlib fails with missing DLL errors In-Reply-To: <1442294819.71.0.839651529049.issue25117@psf.upfronthosting.co.za> Message-ID: <1442992140.0.0.628515246531.issue25117@psf.upfronthosting.co.za> Marius Gedminas added the comment: For the record, I rebooted once, after installing both 32-bit and 64-bit versions of Python 3.5. (Also, it seems that the Python 3.5 installer didn't install pip for me, which could be fallout from this bug? I had to run python -m ensurepip to get it.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 09:33:25 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 23 Sep 2015 07:33:25 +0000 Subject: [issue19143] Finding the Windows version getting messier (detect windows 8.1?) In-Reply-To: <1442968413.22.0.243976471368.issue19143@psf.upfronthosting.co.za> Message-ID: <560255BF.10403@egenix.com> Marc-Andre Lemburg added the comment: On 23.09.2015 02:33, Steve Dower wrote: > > Done. Thanks. > As this is (meant to be) a purely informational/diagnostic module, seems like a good idea to fix every version we're supporting in any way. Yep, that's the intention behind the platform module. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 09:53:13 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Sep 2015 07:53:13 +0000 Subject: [issue25219] Update doc for Idle command line argument. In-Reply-To: <1442990084.65.0.133912466016.issue25219@psf.upfronthosting.co.za> Message-ID: <20150923075309.9929.55713@psf.io> Roundup Robot added the comment: New changeset 80e92eba23e0 by Terry Jan Reedy in branch '2.7': Issue #25219: Update doc for Idle command line options. https://hg.python.org/cpython/rev/80e92eba23e0 New changeset 97f3d7749d3f by Terry Jan Reedy in branch '3.4': Issue #25219: Update doc for Idle command line options. https://hg.python.org/cpython/rev/97f3d7749d3f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 09:55:37 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 23 Sep 2015 07:55:37 +0000 Subject: [issue25219] Update doc for Idle command line arguments. In-Reply-To: <1442990084.65.0.133912466016.issue25219@psf.upfronthosting.co.za> Message-ID: <1442994937.85.0.516241622867.issue25219@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- title: Update doc for Idle command line argument. -> Update doc for Idle command line arguments. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 09:55:53 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 23 Sep 2015 07:55:53 +0000 Subject: [issue25219] Update doc for Idle command line arguments. In-Reply-To: <1442990084.65.0.133912466016.issue25219@psf.upfronthosting.co.za> Message-ID: <1442994953.34.0.797443632162.issue25219@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- assignee: -> terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 09:57:08 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 23 Sep 2015 07:57:08 +0000 Subject: [issue25219] Update doc for Idle command line options. In-Reply-To: <1442990084.65.0.133912466016.issue25219@psf.upfronthosting.co.za> Message-ID: <1442995028.2.0.413709644671.issue25219@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- title: Update doc for Idle command line arguments. -> Update doc for Idle command line options. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 10:16:46 2015 From: report at bugs.python.org (Roman Valls) Date: Wed, 23 Sep 2015 08:16:46 +0000 Subject: [issue9928] weird oddity with bz2 context manager In-Reply-To: <1285263860.75.0.0295269513822.issue9928@psf.upfronthosting.co.za> Message-ID: <1442996206.9.0.469521459279.issue9928@psf.upfronthosting.co.za> Roman Valls added the comment: It still seems to be failing with Python 2.7.10... or am I doing sth wrong? :/ $ ipython Python 2.7.10 |Anaconda 2.2.0 (x86_64)| (default, May 28 2015, 17:04:42) Type "copyright", "credits" or "license" for more information. IPython 4.0.0 -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object', use 'object??' for extra details. In [1]: import bz2 In [2]: import pandas as pd In [3]: import numpy as np In [4]: import matplotlib as plt In [5]: import seaborn as sns In [6]: import cPickle as pickle In [7]: with open("./collectl_info.pickle.bz2", "rb") as comp: ...: with bz2.decompress(comp.read()) as decomp: ...: data, hardware, steps = pickle.load(decomp) ...: --------------------------------------------------------------------------- AttributeError Traceback (most recent call last) in () 1 with open("./collectl_info.pickle.bz2", "rb") as comp: ----> 2 with bz2.decompress(comp.read()) as decomp: 3 data, hardware, steps = pickle.load(decomp) 4 AttributeError: __exit__ ---------- nosy: +Roman Valls versions: -Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 10:43:05 2015 From: report at bugs.python.org (Barry Scott) Date: Wed, 23 Sep 2015 08:43:05 +0000 Subject: [issue25148] Windows registry PythonCore key changed inconsistent with other releases In-Reply-To: <1442481151.22.0.29783958187.issue25148@psf.upfronthosting.co.za> Message-ID: <1442997785.19.0.544885695288.issue25148@psf.upfronthosting.co.za> Barry Scott added the comment: To clarify: 3.5 means 3.5 64 bit 3.5-32 means 3.5 32 bit You do not add the -64 as it is the default. However: this change should have been in the "What's New" as it breaks Windows installation code for extensions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 10:50:02 2015 From: report at bugs.python.org (RuixiaZhang) Date: Wed, 23 Sep 2015 08:50:02 +0000 Subject: [issue1401] urllib2 302 POST In-Reply-To: <1194471779.09.0.301126280852.issue1401@psf.upfronthosting.co.za> Message-ID: <1442998202.39.0.245839117567.issue1401@psf.upfronthosting.co.za> RuixiaZhang added the comment: I am using python 2.7,the same ,come to 302 lost cookies, I try add the code : req.headers.pop('content-length') to urllib2.py:536 but, have another error: KeyError: 'content-length' So, I want to ask is there any better method to solver this error? ---------- components: +Windows -XML nosy: +paul.moore, steve.dower, tim.golden, zach.ware, zhangruixia0108 versions: +Python 2.7 -Python 2.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 10:54:54 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 23 Sep 2015 08:54:54 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1442998494.51.0.904749377221.issue18967@psf.upfronthosting.co.za> Larry Hastings added the comment: Okay. I got tired of the constant Misc/NEWS merge conflicts, so I wrote a tool to fix the problem. It's checked in to Bitbucket here: https://bitbucket.org/larry/mergenews/ There's a readme, which you'll see rendered on that page. I don't know what you mean by "attach Misc/NEWS entries to the issue tracker". I figure, the Misc/NEWS entry is used as the checkin comment, so Roundup Robot already adds it for you, so maybe that's good enough. Can we maybe switch to this for 3.6? Should we consider switching all 3.x branches under active development to use this approach? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 12:12:35 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Sep 2015 10:12:35 +0000 Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py to a package) Message-ID: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za> New submission from STINNER Victor: The Lib/test/regrtest.py file became a monster. It's very long, it uses a lot of global variables. It's hard to review and hard to maintain. I propose to: - split single file regrtest.py into multiple files in a new Lib/test/regrtest/ package - refactor the test runner as a class to avoid global variables - refactor the multiprocessing test runner as a class in a separated file Attached patch implements this idea. The following commands still work: ./python -m test [options] [args] ./python -m test.regrtest [options] [args] But the following command doesn't work anymore: ./python Lib/test/regrtest.py [options] [args] If regrtest.py is executed directly on buildbots, these buildbots should be modified first. The "./python -m test.regrtest" command should work on all Python versions (Python 2 and Python 3) and so should be preferred. The "./python -m test" command only works on Python 3 (thanks to the new __main__.py feature). The change adds a new feature: it now displays name of concurrent tests running since 30 seconds or longer when the multiprocessing test runner is used (-j command line option). Example: ... [240/399] test_uu [241/399] test_urllib_response [242/399] test_struct [243/399] test_descrtut [244/399] test_threadedtempfile [245/399] test_tracemalloc -- running: test_concurrent_futures (30 sec) [246/399] test_dbm_dumb -- running: test_concurrent_futures (30 sec) [247/399] test_codeop -- running: test_concurrent_futures (30 sec) ... [395/399/1] test_asyncio -- running: test_multiprocessing_fork (40 sec), test_multiprocessing_spawn (44 sec) [396/399/1] test_faulthandler -- running: test_multiprocessing_fork (50 sec), test_multiprocessing_spawn (54 sec) [397/399/1] test_multiprocessing_fork (52 sec) -- running: test_multiprocessing_spawn (56 sec) [398/399/1] test_multiprocessing_spawn (68 sec) -- running: test_multiprocessing_forkserver (39 sec) [399/399/1] test_multiprocessing_forkserver (50 sec) I want this feature to analysis why more and more buildbots fail with a timeout without saying which test was running (well, I suspect multiprocessing tests...). Note: faulthandler can show where regrtest is blocked, but not when the multiprocessing test runner is used. And sometimes the process is killed by the buildbot, not by faulthandler :-/ Another minor new feature: on CTRL+c, it shows which tests are running when the multiprocessing test runner is used. Example: [ 38/399] test_dummy_thread [ 39/399] test_codecmaps_jp [ 40/399] test_future5 ^C Waiting for test_scope, test_decimal, test_memoryview, test_heapq, test_unicodedata, test_trace, test_threadsignals, test_cgitb, test_runpy, test_cmd_line_script Other changes: * Show test timing when a test runs longer than 30 seconds * Don't make __file__ absolute, findtestdir() calls os.path.abspath() instead. Remove these lines: __file__ = os.path.abspath(__file__) assert __file__ == os.path.abspath(sys.argv[0]) * print() is now called wih flush=True (it didn't check all calls, only the major calls), remove sys.stdout.flush() and sys.stdout.flush() * A lot of refactoring. Sorry, I didn't take notes for each change. I fear that test_regrtest has a small code coverage. I only tested major options, I didn't test -R for example. Note: I don't understand how the --single option works when regrtest is not run from the Python source code directory. A temporary directory, so the pynexttest file is removed after its creation, no? If it doesn't make sense to use --single outside Python directory, maybe an error should be raised? ---------- components: Tests files: regrtest_package.patch keywords: patch messages: 251419 nosy: ezio.melotti, haypo, serhiy.storchaka priority: normal severity: normal status: open title: Enhance and refactor test.regrtest (convert regrtest.py to a package) versions: Python 3.6 Added file: http://bugs.python.org/file40554/regrtest_package.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 12:23:20 2015 From: report at bugs.python.org (Jeremy Kloth) Date: Wed, 23 Sep 2015 10:23:20 +0000 Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py to a package) In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za> Message-ID: <1443003800.53.0.953907979656.issue25220@psf.upfronthosting.co.za> Changes by Jeremy Kloth : ---------- nosy: +jkloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 13:06:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 23 Sep 2015 11:06:39 +0000 Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py to a package) In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za> Message-ID: <5267913.9xKx59uMj6@raxxla> Serhiy Storchaka added the comment: ??????, 23-???-2015 10:12:35 STINNER Victor ????????: > New submission from STINNER Victor: > > The Lib/test/regrtest.py file became a monster. It's very long, it uses a > lot of global variables. It's hard to review and hard to maintain. I > propose to: > > - split single file regrtest.py into multiple files in a new > Lib/test/regrtest/ package You can just mover parts of the code into utility files (or to the test.support package) without converting regrtest.py to a package. This preserves compatibility with running Lib/test/regrtest.py as a script. > - refactor the test runner as a class to avoid global variables Global variables are not evil in a script. Are there other reasons besides aesthetic? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 13:09:41 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 23 Sep 2015 11:09:41 +0000 Subject: [issue25131] The AST for dict and set displays has the lineno of the first value In-Reply-To: <1442341705.94.0.0242549644551.issue25131@psf.upfronthosting.co.za> Message-ID: <1443006581.18.0.494494169102.issue25131@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +3.5regression _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 13:32:06 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 23 Sep 2015 11:32:06 +0000 Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py to a package) In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za> Message-ID: <1443007926.56.0.0302218350796.issue25220@psf.upfronthosting.co.za> Martin Panter added the comment: I never used --single, but quickly looking at the code, it looks like the pynexttest file got stored in /tmp or similar, via tempfile.gettempdir(), so it should usually survive. However it looks like your patch now creates ?pynexttest? in a temporary directory that gets removed at the end? Left another comment on Rietveld about out of date stuff in __main__. ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 13:36:22 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 23 Sep 2015 11:36:22 +0000 Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py to a package) In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za> Message-ID: <1443008182.73.0.0102449754716.issue25220@psf.upfronthosting.co.za> Berker Peksag added the comment: I like the new features, but I think we should take a look at issue 10967 before converting it to a package or refactoring it. The buildbot part is also a bit complicated. For example, support.verbose doesn't work correctly on builtbots: issue 23235. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 13:57:35 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Sep 2015 11:57:35 +0000 Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py to a package) In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za> Message-ID: <1443009455.49.0.125713671872.issue25220@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy Storchaka wrote: """ You can just mover parts of the code into utility files (or to the test.support package) without converting regrtest.py to a package. This preserves compatibility with running Lib/test/regrtest.py as a script. """ Does it really matter? Who runs directly Lib/test/regrtest.py? It's simple to replace Lib/test/regrtest.py with -m test (or -m test.regrtest), no? Serhiy Storchaka wrote: "Global variables are not evil in a script. Are there other reasons besides aesthetic?" It's much easier to split a long function using multiple small functions when no global variable is used. I also like OOP, so I created a class. Should I understand that you don't like classes and would prefer to keep flat functions? Martin Panter wrote: "I never used --single, but quickly looking at the code, it looks like the pynexttest file got stored in /tmp or similar, via tempfile.gettempdir(), so it should usually survive. However it looks like your patch now creates ?pynexttest? in a temporary directory that gets removed at the end?" Ah ok, it's /tmp. I misunderstood the code. I understand that it creates a temporary subdirectory and write into the temporary subdirectory which will be removed. Berker Peksag: "I like the new features, but I think we should take a look at issue 10967 before converting it to a package or refactoring it." Even if we move some features to unittest, I don't think that regrtest.py will be reduced to fewer than 100 lines of code. By the way, most reusable code is in test.support. test.regrtest is much more specific to the CPython test suite, no? Berker Peksag: "The buildbot part is also a bit complicated. For example, support.verbose doesn't work correctly on builtbots: issue 23235." Sorry, I don't see the link with this issue. How are these two issues related? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 14:00:42 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 23 Sep 2015 12:00:42 +0000 Subject: [issue25214] asyncio ssl transport regression In-Reply-To: <1442931397.2.0.469066320907.issue25214@psf.upfronthosting.co.za> Message-ID: <1443009642.33.0.498415139079.issue25214@psf.upfronthosting.co.za> Andrew Svetlov added the comment: I've missed your patch, sorry. Everything is fixed by http://bugs.python.org/issue25114 ---------- resolution: -> duplicate stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 14:03:14 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Sep 2015 12:03:14 +0000 Subject: [issue25214] asyncio ssl transport regression In-Reply-To: <1442931397.2.0.469066320907.issue25214@psf.upfronthosting.co.za> Message-ID: <1443009794.05.0.980789713651.issue25214@psf.upfronthosting.co.za> STINNER Victor added the comment: > I've missed your patch, sorry. There is no need to be sorry :-) > Everything is fixed by http://bugs.python.org/issue25114 Wow, great :-) Thanks again Mathieu Pasquet who reported the issue #22768. ---------- status: open -> closed superseder: -> asyncio: add ssl_object extra info _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 14:06:25 2015 From: report at bugs.python.org (=?utf-8?q?Luiz_Francisco_Artigas_de_Pr=C3=A1?=) Date: Wed, 23 Sep 2015 12:06:25 +0000 Subject: [issue19084] No way to use TLS-PSK from python ssl In-Reply-To: <1380036748.95.0.439028811791.issue19084@psf.upfronthosting.co.za> Message-ID: <1443009985.87.0.531442288032.issue19084@psf.upfronthosting.co.za> Changes by Luiz Francisco Artigas de Pr? : ---------- nosy: +Luiz Francisco Artigas de Pr? _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 14:30:45 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Wed, 23 Sep 2015 12:30:45 +0000 Subject: [issue25214] asyncio ssl transport regression In-Reply-To: <1442931397.2.0.469066320907.issue25214@psf.upfronthosting.co.za> Message-ID: <1443011445.44.0.881042302504.issue25214@psf.upfronthosting.co.za> Andrew Svetlov added the comment: BTW for fingerprint check for self-signed certs I need binary form of certificate `ssl_obj.getpeercert(binary_form=True)` but `transp.get_extra_info('peercert')` returns a dict-based form. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 14:42:13 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Sep 2015 12:42:13 +0000 Subject: [issue25214] asyncio ssl transport regression In-Reply-To: <1442931397.2.0.469066320907.issue25214@psf.upfronthosting.co.za> Message-ID: <1443012133.52.0.316449602006.issue25214@psf.upfronthosting.co.za> STINNER Victor added the comment: >> Thanks again Mathieu Pasquet who reported the issue #22768. > BTW for fingerprint check for self-signed certs I need binary form of certificate `ssl_obj.getpeercert(binary_form=True)` but `transp.get_extra_info('peercert')` returns a dict-based form. Yes, it's exactly the use case described in #22768 ;-) But ssl_object extra info is more generic, it gives access to all SSL methods. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 15:27:43 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Sep 2015 13:27:43 +0000 Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py to a package) In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za> Message-ID: <1443014863.44.0.578637123681.issue25220@psf.upfronthosting.co.za> STINNER Victor added the comment: "I want this feature to analysis why more and more buildbots fail with a timeout without saying which test was running (well, I suspect multiprocessing tests...)." Recent example: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.x/builds/3389/steps/test/logs/stdio ... [395/399] test_pep352 [396/399] test_ioctl [397/399] test_multiprocessing_fork [398/399] test_multiprocessing_forkserver command timed out: 3900 seconds without output running ['make', 'buildbottest', 'TESTOPTS= -j4', 'TESTPYTHONOPTS=', 'TESTTIMEOUT=3600'], attempting to kill process killed by signal 9 program finished with exit code -1 elapsedTime=4949.196279 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 15:52:29 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Sep 2015 13:52:29 +0000 Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py to a package) In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za> Message-ID: <1443016349.09.0.0698314247912.issue25220@psf.upfronthosting.co.za> STINNER Victor added the comment: Another recent example: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/6712/steps/test/logs/stdio ... [395/399] test_asyncio [396/399] test_email [397/399] test_threaded_import [398/399] test_tools command timed out: 3900 seconds without output, attempting to kill program finished with exit code 1 elapsedTime=4958.515000 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 16:43:13 2015 From: report at bugs.python.org (Armin Rigo) Date: Wed, 23 Sep 2015 14:43:13 +0000 Subject: [issue9928] weird oddity with bz2 context manager In-Reply-To: <1285263860.75.0.0295269513822.issue9928@psf.upfronthosting.co.za> Message-ID: <1443019393.97.0.737576261234.issue9928@psf.upfronthosting.co.za> Armin Rigo added the comment: Roman: bz2.decompress(comp.read()) returns a string, so you can't use "with" on it. This bug was about using "with bz2.BZ2File(...) as f:". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 16:51:53 2015 From: report at bugs.python.org (Roman Valls) Date: Wed, 23 Sep 2015 14:51:53 +0000 Subject: [issue9928] weird oddity with bz2 context manager In-Reply-To: <1443019393.97.0.737576261234.issue9928@psf.upfronthosting.co.za> Message-ID: Roman Valls added the comment: Gotcha, sorry about that :-S On Wed, Sep 23, 2015 at 4:43 PM, Armin Rigo wrote: > > Armin Rigo added the comment: > > Roman: bz2.decompress(comp.read()) returns a string, so you can't use "with" on it. This bug was about using "with bz2.BZ2File(...) as f:". > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 17:12:11 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 23 Sep 2015 15:12:11 +0000 Subject: [issue25194] Register of Financial Interests for core contributors In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za> Message-ID: <1443021131.94.0.804394948568.issue25194@psf.upfronthosting.co.za> R. David Murray added the comment: What about those of us who would *like* to broadcast our availability? :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 17:57:17 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 23 Sep 2015 15:57:17 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1443023837.19.0.329910213135.issue18967@psf.upfronthosting.co.za> Larry Hastings added the comment: In case you're too lazy to go visit the link to my "mergenews" repository and read the readme... mergenews has three tools: * splitnews, which splits the existing Misc/NEWS file into hundreds of individual files, * mergenews, which merges the hundreds of individual files back into a single coherent Misc/NEWS file, and * pyci, a front-end for "hg ci" which automatically writes out the checkin comment as a new news entry into the right spot so mergenews will see it. It's all basically working already. pyci limits you in what command-line options it supports, other than that I think it all does what you want. Can we use it please? ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 19:16:11 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 23 Sep 2015 17:16:11 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1443028571.5.0.365420581878.issue18967@psf.upfronthosting.co.za> Brett Cannon added the comment: What I mean by "attach Misc/NEWS entries to the issue tracker" is there will literally be a field in the issue tracker to enter the entry for the change log and Misc/NEWS will simply be auto-generated from the issue tracker. You can't use the commit message for what to put in the change log because too many people are against that solution (trust me, I tried to convince them otherwise). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 19:16:45 2015 From: report at bugs.python.org (tzickel) Date: Wed, 23 Sep 2015 17:16:45 +0000 Subject: [issue25083] Python can sometimes create incorrect .pyc files In-Reply-To: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za> Message-ID: <1443028605.78.0.310728300642.issue25083@psf.upfronthosting.co.za> tzickel added the comment: Although I haven't reviewed python 3.5 code, I've put an breakpoint on calling "ferror" in the debugger, and it seems that python 3 does not check the file status on import as well... ---------- nosy: +eric.snow, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 19:23:52 2015 From: report at bugs.python.org (s-wakaba) Date: Wed, 23 Sep 2015 17:23:52 +0000 Subject: [issue25221] PyLong_FromLong() potentially returns irregular object when small_ints[] isn't used Message-ID: <1443029032.54.0.224615984306.issue25221@psf.upfronthosting.co.za> New submission from s-wakaba: When compiling cpython with specifying NSMALLPOSINTS and NSMALLNEGINTS macros as zero to skip making small_ints[] array, like following command, process couldn't finish. $ ./configure CPPFLAGS='-DNSMALLPOSINTS=0 -DNSMALLNEGINTS=0' $ make The reason looks a problem that PyLong_FromLong(0) returns irregular int object: Py_SIZE(zero_int) must be 0, but it becomes 1. maybe this problem never appears in actual cases, but in "longobject.c", it still looks supported to compile without small_ints[]. I don't know it should be fixed or not. but, as a result, I could compile cpython after addition of one line like attached patch. Could you confirm this point? Thanks. ---------- components: Interpreter Core files: longobject.c.patch keywords: patch messages: 251436 nosy: s-wakaba priority: normal severity: normal status: open title: PyLong_FromLong() potentially returns irregular object when small_ints[] isn't used type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file40555/longobject.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 20:10:41 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 23 Sep 2015 18:10:41 +0000 Subject: [issue25205] setattr accepts invalid identifiers In-Reply-To: <1442861960.51.0.201067879836.issue25205@psf.upfronthosting.co.za> Message-ID: <1443031841.83.0.446173190096.issue25205@psf.upfronthosting.co.za> R. David Murray added the comment: I wouldn't call the sendfile case troublesome. 'in' is a keyword, so if you want to use it in function arguments, you have to pass it as a string. Perfectly logical :) IIRC pypy uses an optimized dictionary if there are no non-identifier keywords in the attribute __dict__. I *think* it supports non-identifiers by falling back to a slower implementation, but I could be wrong. I seem to remember a discussion where it was ruled that the fact that CPython's default __dict__ accepts non-identifiers is a CPython implementation detail and code should not rely on it working...but of course some code does, so we can't "fix" it :). If I'm remembering right, and if __dict__'s permissiveness is not noted as a CPython implementation detail in the language reference, it should be, but I would expect that it is since that discussion was one of the ones that triggered the introduction such documentation notes. But, as MvL pointed out, setattr does *not* have this restriction, even if the python implementation rejects it for default __dicts__, because an object can do anything it wants during in its __setattr__ method, and this is an important (and used in the wild!) feature of the language. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 20:48:56 2015 From: report at bugs.python.org (eryksun) Date: Wed, 23 Sep 2015 18:48:56 +0000 Subject: [issue25205] setattr accepts invalid identifiers In-Reply-To: <1442861960.51.0.201067879836.issue25205@psf.upfronthosting.co.za> Message-ID: <1443034136.44.0.890263561932.issue25205@psf.upfronthosting.co.za> eryksun added the comment: Even MvL appears to slip up when he states "some may accept non-strings as attribute names". That would be pointless in a __setattr__ method since setattr / PyObject_SetAttr reject non-string values as 'names'. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 21:05:47 2015 From: report at bugs.python.org (Remi Pointel) Date: Wed, 23 Sep 2015 19:05:47 +0000 Subject: [issue23329] _ssl cannot be compiled with LibreSSL anymore (on OpenBSD 5.5) because of ALPN In-Reply-To: <1422353692.3.0.280216678648.issue23329@psf.upfronthosting.co.za> Message-ID: <1443035147.72.0.199052702058.issue23329@psf.upfronthosting.co.za> Remi Pointel added the comment: With this patch it works fine on OpenBSD with LibreSSL. Could you test on a Linux machine with OpenSSL supporting ALPN please? Thanks spil@ for the idea. ---------- keywords: +patch Added file: http://bugs.python.org/file40556/python_have_alpn.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 21:23:30 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 23 Sep 2015 19:23:30 +0000 Subject: [issue25210] Special-case NoneType() in do_richcompare() In-Reply-To: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za> Message-ID: <1443036210.89.0.981127680414.issue25210@psf.upfronthosting.co.za> R. David Murray added the comment: There are other places NoneType shows up (eg: attribute error). Why should this case be special? Do we want to fix them all? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 21:49:00 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 23 Sep 2015 19:49:00 +0000 Subject: [issue16701] Docs missing the behavior of += (in-place add) for lists. In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za> Message-ID: <1443037740.26.0.259092687884.issue16701@psf.upfronthosting.co.za> R. David Murray added the comment: Wording looks ok...except that technically it is not that 'n' is an integer, it's that 'n' can play the role of an integer (ie: it has an __index__ method). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 21:57:07 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Sep 2015 19:57:07 +0000 Subject: [issue23329] _ssl cannot be compiled with LibreSSL anymore (on OpenBSD 5.5) because of ALPN In-Reply-To: <1422353692.3.0.280216678648.issue23329@psf.upfronthosting.co.za> Message-ID: <1443038227.52.0.27692342561.issue23329@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 22:01:34 2015 From: report at bugs.python.org (Tim Golden) Date: Wed, 23 Sep 2015 20:01:34 +0000 Subject: [issue25143] 3.5 install fails poorly on Windows XP In-Reply-To: <1442970192.48.0.543317191007.issue25143@psf.upfronthosting.co.za> Message-ID: <56030563.4000306@timgolden.me.uk> Tim Golden added the comment: I'd just bail as early as poss. from the installer. If it's possible to detect Windows versions, stick something like "The last version to support WinXP is 3.4". If that's too tricky, perhaps something "Your system may be unsupported. Please try an earlier version of Python" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 22:02:43 2015 From: report at bugs.python.org (Tim Golden) Date: Wed, 23 Sep 2015 20:02:43 +0000 Subject: [issue25164] Windows default installation path is inconsistent between per-user and system-wide installation In-Reply-To: <1442970933.34.0.295451320946.issue25164@psf.upfronthosting.co.za> Message-ID: <560305A7.6000204@timgolden.me.uk> Tim Golden added the comment: I don't feel that strongly, but my preference would be "python35[-whatever]" rather than the version with the spaces & the dots. Both for ease of use and for some kind of continuity with the c:\pythonxy we've had for many years. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 22:11:55 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 23 Sep 2015 20:11:55 +0000 Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py to a package) In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za> Message-ID: <1443039115.72.0.769101595376.issue25220@psf.upfronthosting.co.za> R. David Murray added the comment: This may be opening a can of worms, but I wonder if what we should really do is re-engineer regrtest from the ground up, keeping the existing regrtest around until we are satisfied with its replacement...and maybe some of the options wouldn't make the transition. (I've used --single, but it's been a long time, and I think it may have only been when I was testing regrtest after modifying it...) We could then shift buildbots over to the new command gradually (or, do a few first, and then all the rest). Then when we're satisfied we could change -m test to use the new interface, but keep regrtest around, unmaintained, for a couple of releases for those who are still using it. I haven't looked at Victor's code to see if I like his re-engineering, but I'm really talking about starting the re-engineering from the API, and only then thinking about the code to implement it. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 22:18:59 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Sep 2015 20:18:59 +0000 Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py to a package) In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za> Message-ID: <1443039539.0.0.256643727229.issue25220@psf.upfronthosting.co.za> STINNER Victor added the comment: "This may be opening a can of worms, but I wonder if what we should really do is re-engineer regrtest from the ground up," It's not a full reengineering. My patch takes the current code and split it into smaller files. It's not a new implementation or anything like that. "keeping the existing regrtest around until we are satisfied with its replacement..." why are you saying "replacement"? Replaced by what? "(I've used --single, but it's been a long time, and I think it may have only been when I was testing regrtest after modifying it...)" You can propose to remove this option if you think that it's useless. I don't want to touch options, I don't know how regrtest is used, and regrtest works right? (If it works, don't touch it :-)) "I haven't looked at Victor's code to see if I like his re-engineering, but I'm really talking about starting the re-engineering from the API, and only then thinking about the code to implement it." Sorry, but writing a new regrtest project is a full new project. Please open a new issue if you want to invest time on that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 22:23:43 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Sep 2015 20:23:43 +0000 Subject: [issue25210] Special-case NoneType() in do_richcompare() In-Reply-To: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za> Message-ID: <1443039823.34.0.153965185143.issue25210@psf.upfronthosting.co.za> STINNER Victor added the comment: R. David Murray wrote: "There are other places NoneType shows up (eg: attribute error). Why should this case be special? Do we want to fix them all?" I think you missed the last sentence of the initial message :-) We are simply discussing a comment :-D Ezio wrote: "if not, the comment should be removed." Come on, just remove the comment, that's all ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 22:27:03 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 23 Sep 2015 20:27:03 +0000 Subject: [issue25205] setattr accepts invalid identifiers In-Reply-To: <1442861960.51.0.201067879836.issue25205@psf.upfronthosting.co.za> Message-ID: <1443040023.04.0.640859374485.issue25205@psf.upfronthosting.co.za> R. David Murray added the comment: I did however make the same mistake without checking the docs or the behavior. But the fact that I didn't look at it doesn't make the current documentation wrong :) What change is it that you think would be beneficial? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 22:27:59 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 23 Sep 2015 20:27:59 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1443040079.35.0.964864708143.issue18967@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Larry: commit messages are for other developers, which news entries are ultimately for users. Some developers want (insist on) the freedom to make the two different, with different details. I am using that for Idle patches since NEWS entries become 'What New for Idle' in each release. Brett, I presume that you mean a new NEWS box like this Comment box, maybe with 3 lines and a new Section: box like Components. Question: Is it impossible to put labels above a box rather than to the right? We could allow that news section to be (initially) filled out by someone other than the committer. Latter could (optionally) copy and paste as (initial draft of) commit message. Having message visible on issue might result in typos being corrected sooner, and would make it much easier to edit news message later (But editing after close should be limited to core devs). Larry, a commit hook would be better that a separate pyci since TortoiseHG [Commit] button would still work. With Brett's solution, a commit hook could email commit message to tracker as NEWS message (if empty). And yes, change should apply to all versions. Otherwise, NEWS commits to older versions would have to be null-merged. ---------- components: +2to3 (2.x to 3.x conversion tool) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 22:41:27 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 23 Sep 2015 20:41:27 +0000 Subject: [issue25194] Register of Financial Interests for core contributors In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za> Message-ID: <1443040887.4.0.492670196253.issue25194@psf.upfronthosting.co.za> Antoine Pitrou added the comment: What would be the rules for how to fill this up? For example, I work for Continuum, which develops Conda and Anaconda, but I'm not paid to work on CPython (I work on Numba). However, perhaps someone might want to ask for CPython work that aligns with Continuum's interests, and then I'd obviously be in the loop for the actual work. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 22:53:20 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 23 Sep 2015 20:53:20 +0000 Subject: [issue25085] Windows x86-64 embeddable zip file contains test directorys In-Reply-To: <1442151945.16.0.782887699168.issue25085@psf.upfronthosting.co.za> Message-ID: <1443041600.25.0.752815604483.issue25085@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Thanks, re-reading I see the new exclusion test for this issue: if name in {'test', 'tests'} and p.parts[-3].lower() == 'lib': ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 22:55:08 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 23 Sep 2015 20:55:08 +0000 Subject: [issue25194] Register of Financial Interests for core contributors In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za> Message-ID: <1443041708.24.0.67268935961.issue25194@psf.upfronthosting.co.za> R. David Murray added the comment: Antoine: think that's exactly what Nick has in mind, exposing that kind of information. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 22:55:41 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 23 Sep 2015 20:55:41 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1443041741.8.0.784337253776.issue18967@psf.upfronthosting.co.za> Brett Cannon added the comment: Yes, a text box or something along those lines. I assume the selection label question is to specify a section of the change log for something to go into. That's actually not necessary as the proper section is implied by the Components label. And we could allow people to initially fill it in if desired, but I think worrying about whether to open it up or not is premature optimization; I'm fine with starting with it for only people with Developer privileges on the issue tracker. ---------- components: -2to3 (2.x to 3.x conversion tool) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 22:58:54 2015 From: report at bugs.python.org (Bernie Hackett) Date: Wed, 23 Sep 2015 20:58:54 +0000 Subject: [issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow Message-ID: <1443041934.39.0.663904562199.issue25222@psf.upfronthosting.co.za> New submission from Bernie Hackett: While running PyMongo's test suite against python 3.5.0 the interpreter inconsistently aborts when we test encoding a recursive data structure like: evil = {} evil['evil'] = evil The test that triggers this was added to test the use of Py_EnterRecursiveCall in PyMongo's C extensions and passes without issues on all previous CPython releases back to 2.4.x (the oldest version PyMongo supports). The interesting thing about this abort is that it only occurs when testing PyMongo *without* its C extensions. The stacktrace looks like this: test_bad_encode (test_bson.TestBSON) ... Exception ignored in: > RecursionError: maximum recursion depth exceeded while calling a Python object Fatal Python error: Cannot recover from stack overflow. Thread 0x00000b6c (most recent call first): File "C:\10gen\mongo-python-driver\pymongo\periodic_executor.py", line 105 in _run File "C:\Python35\lib\threading.py", line 871 in run File "C:\Python35\lib\threading.py", line 923 in _bootstrap_inner File "C:\Python35\lib\threading.py", line 891 in _bootstrap Thread 0x00000690 (most recent call first): File "C:\Python35\lib\threading.py", line 297 in wait File "C:\10gen\mongo-python-driver\pymongo\thread_util.py", line 199 in wait File "C:\10gen\mongo-python-driver\pymongo\periodic_executor.py", line 110 in _run File "C:\Python35\lib\threading.py", line 871 in run File "C:\Python35\lib\threading.py", line 923 in _bootstrap_inner File "C:\Python35\lib\threading.py", line 891 in _bootstrap Thread 0x00000900 (most recent call first): File "C:\Python35\lib\threading.py", line 297 in wait File "C:\10gen\mongo-python-driver\pymongo\thread_util.py", line 199 in wait File "C:\10gen\mongo-python-driver\pymongo\periodic_executor.py", line 110 in _run File "C:\Python35\lib\threading.py", line 871 in run File "C:\Python35\lib\threading.py", line 923 in _bootstrap_inner File "C:\Python35\lib\threading.py", line 891 in _bootstrap Current thread 0x00000a20 (most recent call first): File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 462 in _encode_list File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson My current working theory is if RecursionError is raised during a thread switch the recursion depth is deemed too great to recover from. Maybe the GIL is no longer being held during some call to _Py_CheckRecursiveCall? This failure looks suspiciously similar to issue22971 given that, in that ticket, the failure occurs while or immediately after running test_thread. The failure has been observed on 64 and 32bit Windows 7 VMs as well as a 64bit Amazon Linux instance. Sadly, I haven't yet been able to devise a reproduction that doesn't involve running PyMongo's test suite. ---------- components: Interpreter Core messages: 251453 nosy: behackett priority: normal severity: normal status: open title: 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 23:00:00 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Sep 2015 21:00:00 +0000 Subject: [issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow In-Reply-To: <1443041934.39.0.663904562199.issue25222@psf.upfronthosting.co.za> Message-ID: <1443042000.75.0.039836949034.issue25222@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 23:01:38 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 23 Sep 2015 21:01:38 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1443042098.28.0.350369390209.issue18967@psf.upfronthosting.co.za> R. David Murray added the comment: I believe auto-filling it from the commit message (for those who don't put in the effort to treat the two audiences differently :) was something we discussed, but it would be a separate enhancement after the news box is added to the tracker. Which I might get to next month or I might not... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 23:10:20 2015 From: report at bugs.python.org (A. Jesse Jiryu Davis) Date: Wed, 23 Sep 2015 21:10:20 +0000 Subject: [issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow In-Reply-To: <1443041934.39.0.663904562199.issue25222@psf.upfronthosting.co.za> Message-ID: <1443042620.09.0.308281101554.issue25222@psf.upfronthosting.co.za> Changes by A. Jesse Jiryu Davis : ---------- nosy: +emptysquare _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 23:11:52 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Sep 2015 21:11:52 +0000 Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py to a package) In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za> Message-ID: <20150923211149.3656.49683@psf.io> Roundup Robot added the comment: New changeset eaf9a99b6bb8 by Victor Stinner in branch 'default': Issue #25220: Create Lib/test/libregrtest/ https://hg.python.org/cpython/rev/eaf9a99b6bb8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 23:12:20 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 23 Sep 2015 21:12:20 +0000 Subject: [issue25210] Special-case NoneType() in do_richcompare() In-Reply-To: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za> Message-ID: <1443042740.62.0.58908247531.issue25210@psf.upfronthosting.co.za> R. David Murray added the comment: I was agreeing with you, I think the comment should just be dropped. My point was the alternative is really to change it everywhere, not just here :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 23:16:57 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 23 Sep 2015 21:16:57 +0000 Subject: [issue25154] Drop the pyvenv script In-Reply-To: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za> Message-ID: <1443043017.33.0.8619543296.issue25154@psf.upfronthosting.co.za> Brett Cannon added the comment: python-dev did not seem to object to the idea. ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 23:17:04 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 23 Sep 2015 21:17:04 +0000 Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py to a package) In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za> Message-ID: <20150923211701.3666.32032@psf.io> Roundup Robot added the comment: New changeset c92d893fd3c8 by Victor Stinner in branch 'default': Issue #25220: Backed out changeset eaf9a99b6bb8 https://hg.python.org/cpython/rev/c92d893fd3c8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 23:26:36 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Sep 2015 21:26:36 +0000 Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py to a package) In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za> Message-ID: <1443043596.98.0.0360104168032.issue25220@psf.upfronthosting.co.za> STINNER Victor added the comment: I pushed the changeset eaf9a99b6bb8, but R. David Murray asked me to wait for a review before pushing changes. So I reverted my change. I checked if Lib/test/regrtest.py is called directly. The answer is yes: it's called inside Python in various places, but also in scripts to build Python packages. Even if "python -m test" works (and "python -m test.regrtest" works on all Python versions), I prefer to keep Lib/test/regrest.py to not force users to have to modify their script. So I propose to simply move regrtest.py code to smaller files in Lib/test/libregrtest/, as I did in attached regrtest_package.patch. In the changeset eaf9a99b6bb8, I started with cmdline.py because it's the only part of regrtest.py which has real unit tests. I created Lib/test/libregrtest/cmdline.py with "hg cp" to keep Mercurial history. I checked which moved symbols are used: _parse_args() and RESOURCE_NAMES. I exported them in test.libregrtest. I had to modify Lib/test/test_regrtest.py. For next changes, I will try to add a few new unit tests to Lib/test/test_regrtest.py. -- Berker wrote: "I like the new features, but I think we should take a look at issue 10967 before converting it to a package or refactoring it." IMHO it will be easier to enhance regrtest to reuse unit test features, make the code smaller, fix bugs, etc. if regrtest.py is splitted into smaller files. Moving code to a new test.libregrtest submodule should help to implement the issue #10967 & friends (ex: #16748) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 23:36:25 2015 From: report at bugs.python.org (Nikita Klimov) Date: Wed, 23 Sep 2015 21:36:25 +0000 Subject: [issue13253] 2to3 fix_renames renames sys.maxint only in imports In-Reply-To: <1319437552.82.0.780264952493.issue13253@psf.upfronthosting.co.za> Message-ID: <1443044184.99.0.957234501341.issue13253@psf.upfronthosting.co.za> Nikita Klimov added the comment: I'm close to solution, but I need another 1 week. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 23:40:01 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Sep 2015 21:40:01 +0000 Subject: [issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow In-Reply-To: <1443041934.39.0.663904562199.issue25222@psf.upfronthosting.co.za> Message-ID: <1443044401.04.0.71942669291.issue25222@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm not sure that I understood the bug. You are testing a function which enters an unlimited loop. You expect to get a RecursionError, but Python does crash. Well, Python has no perfect protection again stack overflow. It's only best effect. You should change sys.setrecursionlimit() to a lower limit to try to limit the risk of a crash. It's hard to predict how the stack will be used. FYI the error message comes from Python/ceval.c: if (tstate->overflowed) { if (tstate->recursion_depth > recursion_limit + 50) { /* Overflowing while handling an overflow. Give up. */ Py_FatalError("Cannot recover from stack overflow."); } return 0; } I suggest you to use sys.setrecursionlimit() in your test, or remove the test. Maybe there is a real bug, but if it's the case, it will probably be hard to investigate it. You need to dig into gdb. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 23:51:31 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 23 Sep 2015 21:51:31 +0000 Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py to a package) In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za> Message-ID: <1443045091.0.0.702560058753.issue25220@psf.upfronthosting.co.za> R. David Murray added the comment: Victor and I have been discussing this on IRC. We agreed that importing from regrtest and running regrtest as a script needs to keep working. Summary of my disagreements: I'm leery of wholesale changes to regrtest because we have gotten bug reports when we've broken things before. Obviously it's not in the same problem-class as breaking Python, but I'd rather see us start a new command that drops the cruft and just does the things we really use, and stop maintaining regrtest. However, I'm not in a position to do that work, and Victor has no interest in it. So, I'm -0.5 on a big refactoring of regrtest (but have no objection to the new features :). I won't block the change, I'd just prefer a cleaner solution...but don't have the time to implement it myself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 23:52:16 2015 From: report at bugs.python.org (acx01bc) Date: Wed, 23 Sep 2015 21:52:16 +0000 Subject: [issue25223] Statically or dynamically linked to the VC++runtime ? or how Python install fails o Vista despite the VC redist packages - api-ms-win-crt-runtime-l1-1-0.dll Message-ID: <1443045136.66.0.653550157365.issue25223@psf.upfronthosting.co.za> New submission from acx01bc: I think you should build Python.exe with the option to be statically linked to the VC++-runtime. This way, the executable is a little bigger, but you ensure nobody will have troubles with some VC-runtime different Dll versions. DETAILS : (I posted it also there http://stackoverflow.com/questions/32748932/python-3-4-3-works-on-windows-vista-but-not-3-5-0-because-of-vc-redist-package ) I am on Windows Vista 32bits. I downloaded Python 3.5.0 but I got the famous api-ms-win-crt-runtime-l1-1-0.dll problem. Then I installed many Visual C++ Redistributable Packages (I tried the 2015's one, then 2013, and 2012) but none of these packages installed any .dll of the correct name. Then, I tried to download a previous version of Python, the 3.3.2 win32 release, I got the same problem ! ----> Then, I downloaded the Python 3.4.3 Win32 release, and this-one worked immediately. I suspect that version to have been statically linked with the VC-runtime. This clearly lacks of coherence, some Python releases work, while others don't. So I hope some of the Python developers will see that message and will be able to build some binaries compatible with Windows Vista and the VC-redist-packages. Question : did anyone understand where that api-ms-win-crt-runtime-l1-1-0.dll comes from ? I suppose it is related to the VC++ compiler options used when building Python.exe (on my VS2010 I have the options code generation/runtime library/multi-threaded, static or dynamic and general/platform_toolset, V100, V110, V120 or V140) ? ---------- components: Installation messages: 251463 nosy: acx01bc priority: normal severity: normal status: open title: Statically or dynamically linked to the VC++runtime ? or how Python install fails o Vista despite the VC redist packages - api-ms-win-crt-runtime-l1-1-0.dll type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 23:53:20 2015 From: report at bugs.python.org (acx01bc) Date: Wed, 23 Sep 2015 21:53:20 +0000 Subject: [issue25223] Statically or dynamically linked to the VC++runtime ? or how Python install fails on Vista despite the VC redist packages - api-ms-win-crt-runtime-l1-1-0.dll In-Reply-To: <1443045136.66.0.653550157365.issue25223@psf.upfronthosting.co.za> Message-ID: <1443045200.74.0.330767695904.issue25223@psf.upfronthosting.co.za> Changes by acx01bc : ---------- title: Statically or dynamically linked to the VC++runtime ? or how Python install fails o Vista despite the VC redist packages - api-ms-win-crt-runtime-l1-1-0.dll -> Statically or dynamically linked to the VC++runtime ? or how Python install fails on Vista despite the VC redist packages - api-ms-win-crt-runtime-l1-1-0.dll _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Sep 23 23:56:49 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 23 Sep 2015 21:56:49 +0000 Subject: [issue25224] Replace Idle's README.txt with annotated file list Message-ID: <1443045409.48.0.261448310489.issue25224@psf.upfronthosting.co.za> New submission from Terry J. Reedy: idlelib currently has user information that belongs in either the Idle reference idle.rst or possibly a separate Idle howto #17583. This information should be removed and replaced with an annotated list of files in idlelib. The latter would help people working of Idle, and even people just browsing. ---------- assignee: terry.reedy components: IDLE messages: 251464 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Replace Idle's README.txt with annotated file list type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 00:10:35 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 23 Sep 2015 22:10:35 +0000 Subject: [issue24894] iso-8859-11 missing from codecs table In-Reply-To: <1439964625.02.0.805508700241.issue24894@psf.upfronthosting.co.za> Message-ID: <1443046235.73.0.963044105182.issue24894@psf.upfronthosting.co.za> STINNER Victor added the comment: Issue24894.patch is wrong: latin is an alias to ISO 8859-1, not to ISO 8859-11. >>> codecs.lookup('latin').name 'iso8859-1' iso8859_11 has 3 aliases: thai, iso_8859_11, iso_8859_11_2001. You can mention iso-8859-11 and thai in the doc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 00:21:46 2015 From: report at bugs.python.org (Bernie Hackett) Date: Wed, 23 Sep 2015 22:21:46 +0000 Subject: [issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow In-Reply-To: <1443041934.39.0.663904562199.issue25222@psf.upfronthosting.co.za> Message-ID: <1443046906.73.0.659197514662.issue25222@psf.upfronthosting.co.za> Bernie Hackett added the comment: > Well, Python has no perfect protection again stack overflow. It's only best effect. That's interesting. I thought there was a stronger contract, and it appeared that way in all previous cpython releases back to 2.4. Again, this failure is new with 3.5.0. > You should change sys.setrecursionlimit() to a lower limit to try to limit the risk of a crash. That's a great suggestion and it appears to work around the issue, thanks. Feel free to close this won't fix, but given that this appears to be the second report of this issue for 3.5 (see issue22971) someone who understands interpreter internals may want to look into the problem a bit more first. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 00:29:49 2015 From: report at bugs.python.org (Prashant Tyagi) Date: Wed, 23 Sep 2015 22:29:49 +0000 Subject: [issue24894] iso-8859-11 missing from codecs table In-Reply-To: <1439964625.02.0.805508700241.issue24894@psf.upfronthosting.co.za> Message-ID: <1443047389.93.0.666907650633.issue24894@psf.upfronthosting.co.za> Prashant Tyagi added the comment: That was mistake in previous patch,so here is new patch for the same. ---------- Added file: http://bugs.python.org/file40557/issue_24894.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 01:11:41 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 23 Sep 2015 23:11:41 +0000 Subject: [issue25225] Idle doc: redo Syntax Colors section Message-ID: <1443049901.66.0.834655906435.issue25225@psf.upfronthosting.co.za> New submission from Terry J. Reedy: I plan to make the following changes to the Syntax colors section: * Change name to Text and syntax colors, as not all colors are code-syntax related. * Make it a subsection of the previous Editing and navigation section, which is about editor and shell windows, which are what get colored. Begin by stating that both window types get colored. * Greatly reduce excessive white space. Put item and default color on one line, such as * Strings: green, and single space lines. * Add missing item: color pairs * Correct instruction on how to change defaults. ---------- assignee: terry.reedy messages: 251468 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle doc: redo Syntax Colors section type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 01:33:37 2015 From: report at bugs.python.org (Bernie Hackett) Date: Wed, 23 Sep 2015 23:33:37 +0000 Subject: [issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow In-Reply-To: <1443041934.39.0.663904562199.issue25222@psf.upfronthosting.co.za> Message-ID: <1443051217.5.0.675358166812.issue25222@psf.upfronthosting.co.za> Bernie Hackett added the comment: I used sys.setrecursionlimit(250) - the default appears to be 1000 on all my test machines - and that reduced the occurrence of the abort but didn't completely solve the problem. There must be something more going on here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 01:47:36 2015 From: report at bugs.python.org (Mark Lawrence) Date: Wed, 23 Sep 2015 23:47:36 +0000 Subject: [issue25223] Statically or dynamically linked to the VC++runtime ? or how Python install fails on Vista despite the VC redist packages - api-ms-win-crt-runtime-l1-1-0.dll In-Reply-To: <1443045136.66.0.653550157365.issue25223@psf.upfronthosting.co.za> Message-ID: <1443052056.31.0.482988622331.issue25223@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 02:02:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 24 Sep 2015 00:02:51 +0000 Subject: [issue25224] Replace Idle's README.txt with annotated file list In-Reply-To: <1443045409.48.0.261448310489.issue25224@psf.upfronthosting.co.za> Message-ID: <20150924000246.115545.45676@psf.io> Roundup Robot added the comment: New changeset 5a60fdd9af8c by Terry Jan Reedy in branch '2.7': Issue 25224: Augment Idle doc feature list and no-subprocess section https://hg.python.org/cpython/rev/5a60fdd9af8c New changeset 0f20f3fe7ab4 by Terry Jan Reedy in branch '3.4': Issue 25224: Augment Idle doc feature list and no-subprocess section https://hg.python.org/cpython/rev/0f20f3fe7ab4 New changeset b5c8a40d4240 by Terry Jan Reedy in branch '2.7': Issue 25224: Augment Idle doc feature list and no-subprocess section https://hg.python.org/cpython/rev/b5c8a40d4240 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 02:22:33 2015 From: report at bugs.python.org (acx01bc) Date: Thu, 24 Sep 2015 00:22:33 +0000 Subject: [issue25223] Statically or dynamically linked to the VC++runtime ? or how Python install fails on Vista despite the VC redist packages - api-ms-win-crt-runtime-l1-1-0.dll In-Reply-To: <1443045136.66.0.653550157365.issue25223@psf.upfronthosting.co.za> Message-ID: <1443054153.05.0.184430789436.issue25223@psf.upfronthosting.co.za> acx01bc added the comment: With dependency walker I see that : - in 3.4.3, Python34.exe and also Python.34.dll have been dynamically linked with msvcr100.dll (platform target : v100 in Visual C++ project properties), - while in 3.5.0 (the one you download on python.org main page) Python35.exe and Python35.dll have been dynamically linked with msvcr140.dll and many other dlls (platform v140). ---------- Added file: http://bugs.python.org/file40558/python_dll_problem.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 02:37:43 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 24 Sep 2015 00:37:43 +0000 Subject: [issue25211] Error message formatting errors in int object unit-test script In-Reply-To: <1442908335.62.0.971755787432.issue25211@psf.upfronthosting.co.za> Message-ID: <1443055063.44.0.892478253066.issue25211@psf.upfronthosting.co.za> Martin Panter added the comment: I will commit your patch to 2.7. Here is a my alternative proposal for 3.4+, dropping the Frm class and using subTest() instead. I kept some error messages where I thought they added clarity, but dropped most because I thought they were redundant with the test code and subTest() parameters. The test file takes a bit longer to run as a consequence of my patch (was 6.3 s, now 7.3 s). However I think the simpler and more maintainable code outweighs this. ---------- nosy: +berker.peksag Added file: http://bugs.python.org/file40559/subTest-long.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 02:39:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 24 Sep 2015 00:39:00 +0000 Subject: [issue25211] Error message formatting errors in int object unit-test script In-Reply-To: <1442908335.62.0.971755787432.issue25211@psf.upfronthosting.co.za> Message-ID: <20150924003856.81627.19850@psf.io> Roundup Robot added the comment: New changeset e2f1f69d0618 by Martin Panter in branch '2.7': Issue #25211: Fix error message code in test_long; patch from s-wakaba https://hg.python.org/cpython/rev/e2f1f69d0618 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 02:42:13 2015 From: report at bugs.python.org (eryksun) Date: Thu, 24 Sep 2015 00:42:13 +0000 Subject: [issue25164] Windows default installation path is inconsistent between per-user and system-wide installation In-Reply-To: <1442564482.39.0.225945260969.issue25164@psf.upfronthosting.co.za> Message-ID: <1443055333.96.0.975461763122.issue25164@psf.upfronthosting.co.za> eryksun added the comment: Also, why does the per-user install path have a seemingly pointless "Python" base directory? I expected it to install directly into FOLDERID_UserProgramFiles, to be consistent with installing to FOLDERID_ProgramFiles. Also, I doubt anyone cares, but the roaming "user scheme" is still using the name "Python35" without appending a -32 suffix. So 32-bit and 64-bit --user installs are still competing for the same site-packages directory. I know, hardly anyone seems to use this. I doubt Jane User wants large packages such as PyQt4 and SciPy in her roaming profile. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 03:23:50 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 24 Sep 2015 01:23:50 +0000 Subject: [issue16701] Docs missing the behavior of += (in-place add) for lists. In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za> Message-ID: <1443057830.9.0.784113050659.issue16701@psf.upfronthosting.co.za> Martin Panter added the comment: New patch mentioning __index__() ---------- Added file: http://bugs.python.org/file40560/seq-inplace.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 03:43:06 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 24 Sep 2015 01:43:06 +0000 Subject: [issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow In-Reply-To: <1443041934.39.0.663904562199.issue25222@psf.upfronthosting.co.za> Message-ID: <1443058986.94.0.453193077626.issue25222@psf.upfronthosting.co.za> Martin Panter added the comment: I saw this error recently on some 3.4 builtbots: http://buildbot.python.org/all/builders/AMD64%20Windows10%203.4/builds/74/steps/test/logs/stdio (failed last 4/5 builds) [306/390] test_json Fatal Python error: Cannot recover from stack overflow. Current thread 0x00000fd8 (most recent call first): File "D:\buildarea\3.4.bolen-windows10\build\lib\json\encoder.py", line 250 in iterencode File "D:\buildarea\3.4.bolen-windows10\build\lib\json\encoder.py", line 192 in encode File "D:\buildarea\3.4.bolen-windows10\build\lib\test\test_json\test_recursion.py", line 96 in test_endless_recursion http://buildbot.python.org/all/builders/x86%20XP-4%203.4/builds/1224/steps/test/logs/stdio (only failed 1/5 builds, stack trace essentially the same) ---------- nosy: +martin.panter _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 04:15:16 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 24 Sep 2015 02:15:16 +0000 Subject: [issue25223] Statically or dynamically linked to the VC++runtime ? or how Python install fails on Vista despite the VC redist packages - api-ms-win-crt-runtime-l1-1-0.dll In-Reply-To: <1443045136.66.0.653550157365.issue25223@psf.upfronthosting.co.za> Message-ID: <1443060916.06.0.319594357621.issue25223@psf.upfronthosting.co.za> Steve Dower added the comment: None of them are statically linked, and we looked into that for 3.5 and it had other issues, so we went fully dynamically linked. This is either an issue specific to your machine, or a Vista issue (we didn't get a lot of testing done on Vista). Installing the VC 2015 redistributable from http://www.microsoft.com/en-us/download/details.aspx?id=48145 should include the files you need (as should installing Python 3.5.0 itself, but apparently that didn't work). The DLL should be under C:\Windows\System32. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 04:21:48 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 24 Sep 2015 02:21:48 +0000 Subject: [issue25164] Windows default installation path is inconsistent between per-user and system-wide installation In-Reply-To: <1442564482.39.0.225945260969.issue25164@psf.upfronthosting.co.za> Message-ID: <1443061308.89.0.0757410613357.issue25164@psf.upfronthosting.co.za> Steve Dower added the comment: Good question on the extra "Python" directory - I don't recall exactly why that was there, but I suspect it was for consistency with something - probably {userbase} from sysconfig. Also, thanks for catching the user scheme difference. We shouldn't really be installing any packages into the Roaming profile at all, but as this is a highly underused feature it's not a big deal. (And since we add platform tags to .pyd files now it can actually be used successfully, but I suspect that involves more care.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 05:03:06 2015 From: report at bugs.python.org (Xiang Zhang) Date: Thu, 24 Sep 2015 03:03:06 +0000 Subject: [issue24657] CGIHTTPServer module discard continuous '/' letters from params given by GET method. In-Reply-To: <1437187776.37.0.855244973055.issue24657@psf.upfronthosting.co.za> Message-ID: <1443063786.17.0.351119792753.issue24657@psf.upfronthosting.co.za> Xiang Zhang added the comment: I think this is a bug. According to the rfcs, "/" is a reserved character in query component and continuous "/" in query component may be invalid and how to deal with it depends on the server. But encoded "/", %2F, acts as data and should be preserved. And from rfc3875, QUERY_STRING must be passed encoded. I tested in apache2.4 with martin's script, query string is: ('QUERY_STRING', 'k=aa%2F%2Fbb&//q//p//=//a//b//') In python's CGI server, it is: ('QUERY_STRING', 'k=aa/bb&/q/p/=/a/b/'), ---------- nosy: +xiang.zhang _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 05:38:33 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 24 Sep 2015 03:38:33 +0000 Subject: [issue25225] Idle doc: redo Syntax Colors section In-Reply-To: <1443049901.66.0.834655906435.issue25225@psf.upfronthosting.co.za> Message-ID: <1443065913.56.0.432876251105.issue25225@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Current: 3. Syntax colors The coloring is applied in a background ?thread,? so you may occasionally see uncolorized text. To change the color scheme, edit the [Colors] section in config.txt. Python syntax colors: Keywords orange Strings green Comments red Definitions blue Shell colors: Console output brown stdout blue stderr dark green stdin black ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 05:47:37 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 24 Sep 2015 03:47:37 +0000 Subject: [issue25225] Idle doc: redo Syntax Colors section In-Reply-To: <1443049901.66.0.834655906435.issue25225@psf.upfronthosting.co.za> Message-ID: <1443066457.16.0.264545846404.issue25225@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Possible alternative, with additions and corrections: -------------------- 3. Syntax colors The coloring is applied in a background ?thread,? so you may occasionally see uncolorized text. To change the color scheme, edit the [Colors] section in config.txt. Python syntax colors: Keywords: orange Builtins: purple Definitions: blue Strings: green Comments: red Shell colors: Console output: brown Console error: black on red stdin: black stdout: blue stderr: red Other colors: Cursor: black Selected: black on gray Found: white on black ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 06:29:25 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 24 Sep 2015 04:29:25 +0000 Subject: [issue25225] Idle doc: redo Syntax Colors section In-Reply-To: <1443049901.66.0.834655906435.issue25225@psf.upfronthosting.co.za> Message-ID: <1443068965.22.0.204881504336.issue25225@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The alternative above matches the format of help.txt, except that the latter has the colors lined up. The excessive addition of whitespace here was an argument against replacing help.txt with help.html (#16893). I consider the proposed condensation to be most of a fix of a regression. This sentence, "To change the color scheme, edit the [Colors] section in config.txt.", is strange in that it for help.txt, it was changed in 2002-12-11 to refer to the Highlights tab of the Configure dialog. In any case, the color list was added before that tab, but not seems not necessary. As a 'repeat', it is subject to obsolescence if not updated, which it has not been. So I think we should either drop the section or drop the colors and replace with a better description of what is being replaced. 2.4. Text and Syntax colors Text is both editor and shell windows get color coded. The coloring is applied in the background, so you may occasionally see uncolor text. To change the color scheme, use the Configure IDLE dialog, Highlighting tab. Colors can be set for the follow types of text. Python syntax in both editor and shell: normal code, keywords, builtin class and function names, user-defined class and function names, strings, and comments. Shell output: console output, console error text, user output, and user error output and tracebacks. Other text: cursor, selected text, and text found by search. Debugger breakpoint lines in the editor are indicated by a dark yellow background (not configurable). ---- Note: I believe the marking of found text is OS dependent and know that it is the subject of discussion in other issues, so this part needs elaboration. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 06:34:16 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 24 Sep 2015 04:34:16 +0000 Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za> Message-ID: <1443069256.82.0.525112626041.issue18967@psf.upfronthosting.co.za> Nick Coghlan added the comment: I think Larry's "split news" and "merge news" ideas are still useful as a bridging mechanism to help us get from the status quo to a tracker based solution. It would just mean that, at some point in the future, the commit hook would change to be a post-commit hook that pushed to the issue tracker, rather than a pre-commit hook writing to a file in the source repo, and "merge news" would start pulling from the tracker, rather than from the source repo. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 07:17:25 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 24 Sep 2015 05:17:25 +0000 Subject: [issue25194] Register of Financial Interests for core contributors In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za> Message-ID: <1443071845.12.0.0945611666423.issue25194@psf.upfronthosting.co.za> Nick Coghlan added the comment: Right, I'm in a similar situation at Red Hat to the one Antoine's in at Continuum Analytics - I'm not personally part of Red Hat's Python maintenance team (I used to work on internal Engineering tools, and now work on Fedora's overall developer experience), but I do sometimes spend work time helping our Python maintainers negotiate the upstream contribution and collaboration process. I also have quite a bit of leeway when it comes to getting sidetracked on upstream activities related to CPython, distutils-sig or the PSF. Disclosing that affiliation aims to address a few things: * it lets other community members know that Red Hat's interests are something I'm considering in community discussions - core development isn't a purely volunteer activity for me any more (and hasn't been for a number of years) * it lets other Red Hatters know they have at least one colleague that may be able to help them out if they need particular CPython issues looked at more closely * it (hopefully) helps nudge other commercial organisations towards the notion of either paying commercial redistributors or hiring current core developers to address their Python support needs, rather than expecting community volunteers to support their business activities for free * inverting that last motivation, I'm hoping to help encourage commercial redistributors and other folks with a vested interest in the long term sustainability of CPython core development to engage professionally with current core contributors, and also allow their existing staff to spend work time on *becoming* core contributors As far as more specific guidelines go, I'm thinking it may be worth including some notes on "Why might a core contributor want to publicly disclose their affiliations?" and "Why might a core contributor want to preserve their privacy?". I'm not sure exactly what that would look like yet, but I'll come up with something for the next draft. For the final section on availability for consulting, training, and contract work, I think David makes a good point regarding folks potentially *wanting* to broadcast their availability, so I'll draft that such that "Contact via the PSF" is an option that core contributors can choose to take up. That way folks can choose between "available for direct contact" and "available for screened PSF referrals". I'll aim to put that next draft together this coming Sunday. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 07:40:30 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 24 Sep 2015 05:40:30 +0000 Subject: [issue22820] RESTART line with no output In-Reply-To: <1415445819.89.0.337025555913.issue22820@psf.upfronthosting.co.za> Message-ID: <20150924054026.16599.25527@psf.io> Roundup Robot added the comment: New changeset e7bf0727f7df by Terry Jan Reedy in branch '2.7': Issue #22820: Explain need for *print* when running file from Idle editor. https://hg.python.org/cpython/rev/e7bf0727f7df New changeset 824cb25448ab by Terry Jan Reedy in branch '3.4': Issue #22820: Explain need for *print* when running file from Idle editor. https://hg.python.org/cpython/rev/824cb25448ab ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 07:42:59 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 24 Sep 2015 05:42:59 +0000 Subject: [issue22820] RESTART line with no output In-Reply-To: <1415445819.89.0.337025555913.issue22820@psf.upfronthosting.co.za> Message-ID: <1443073379.6.0.0856357461928.issue22820@psf.upfronthosting.co.za> Terry J. Reedy added the comment: For anyone who reads the doc, the added explanation should help. ---------- assignee: docs at python -> terry.reedy resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 08:07:04 2015 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 24 Sep 2015 06:07:04 +0000 Subject: [issue25210] Special-case NoneType() in do_richcompare() In-Reply-To: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za> Message-ID: <1443074824.75.0.402143377912.issue25210@psf.upfronthosting.co.za> Ezio Melotti added the comment: This case is different from most of the others though, because while it talks about unorderable types, it provides an example showing two instances (hence the parentheses). In these NoneType is correct: >>> int(None) TypeError: int() argument must be a string or a number, not 'NoneType' >>> abs(None) TypeError: bad operand type for abs(): 'NoneType' >>> [][None] TypeError: list indices must be integers, not NoneType In this NoneType() is equivalent to the None singleton (and int() is a not-better-specified instance of int): >>> 3 < None TypeError: unorderable types: int() < NoneType() So I would either special-case None, remove the () and the comment, or show both the types and the repr() of the two objects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 09:00:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Sep 2015 07:00:06 +0000 Subject: [issue25210] Special-case NoneType() in do_richcompare() In-Reply-To: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za> Message-ID: <1443078006.55.0.880532201273.issue25210@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And this is the only case where type name followed with '()' is occurred in error message. The repr() shouldn't be used in error message because it can be too long (imagine 'x'*10**9 < None) and can raise an exception. IMHO more correct would be message "unorderable types: int and NoneType", but it lose the information about operation. Yet one option is to follow the template for other binary operators: >>> 1 + None Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for +: 'int' and 'NoneType' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 09:03:47 2015 From: report at bugs.python.org (Robert Kuska) Date: Thu, 24 Sep 2015 07:03:47 +0000 Subject: [issue22032] Use __qualname__ together with __module__ In-Reply-To: <1406019756.34.0.140996851672.issue22032@psf.upfronthosting.co.za> Message-ID: <1443078227.75.0.00640341216041.issue22032@psf.upfronthosting.co.za> Robert Kuska added the comment: FYI This also broke nosetests tests which relies on exact output. https://github.com/nose-devs/nose/issues/928 ---------- nosy: +rkuska _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 09:05:39 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 24 Sep 2015 07:05:39 +0000 Subject: [issue24894] iso-8859-11 missing from codecs table In-Reply-To: <1439964625.02.0.805508700241.issue24894@psf.upfronthosting.co.za> Message-ID: <20150924070536.11700.99775@psf.io> Roundup Robot added the comment: New changeset aa9e0dcbbcc2 by Victor Stinner in branch '3.4': Issue #24894: Document the codec iso8859_11 https://hg.python.org/cpython/rev/aa9e0dcbbcc2 New changeset 84a918335fe5 by Victor Stinner in branch '3.5': Merge 3.4 (codecs, issue #24894) https://hg.python.org/cpython/rev/84a918335fe5 New changeset 97842831c635 by Victor Stinner in branch 'default': Merge 3.5 (codecs, issue #24894) https://hg.python.org/cpython/rev/97842831c635 New changeset ad560409c7d6 by Victor Stinner in branch '2.7': Issue #24894: Document the codec iso8859_11 https://hg.python.org/cpython/rev/ad560409c7d6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 09:07:42 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Sep 2015 07:07:42 +0000 Subject: [issue24894] iso-8859-11 missing from codecs table In-Reply-To: <1439964625.02.0.805508700241.issue24894@psf.upfronthosting.co.za> Message-ID: <1443078462.7.0.709796923311.issue24894@psf.upfronthosting.co.za> STINNER Victor added the comment: > That was mistake in previous patch,so here is new patch for the same. Don't be sorry, that's why we have reviews :-) +| iso8859_11 | iso-8856-11, iso-8859-11-2001, | Thai languages | +| | thai | | I checked other ISO 8859 codecs: they also have an alias with the year, but it's not documented. So I prefer to not document iso-8859-11-2001 neither. There was a typo in "iso-8856-11": it's 8859. I fixed it and pushed your change. Thanks for your first contribution Prashant ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 09:10:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 24 Sep 2015 07:10:28 +0000 Subject: [issue21995] Idle: pseudofiles have no buffer attribute. In-Reply-To: <1405550850.77.0.279876996055.issue21995@psf.upfronthosting.co.za> Message-ID: <20150924071025.82664.74592@psf.io> Roundup Robot added the comment: New changeset ac6ade0c5927 by Terry Jan Reedy in branch '2.7': Issue 21995: Explain some differences between IDLE and console Python. https://hg.python.org/cpython/rev/ac6ade0c5927 New changeset ca6c9cc77c20 by Terry Jan Reedy in branch '3.4': Issue 21995: Explain some differences between IDLE and console Python. https://hg.python.org/cpython/rev/ca6c9cc77c20 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 09:11:03 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Sep 2015 07:11:03 +0000 Subject: [issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow In-Reply-To: <1443041934.39.0.663904562199.issue25222@psf.upfronthosting.co.za> Message-ID: <1443078663.5.0.218093244905.issue25222@psf.upfronthosting.co.za> STINNER Victor added the comment: Bernie Hackett wrote: "Feel free to close this won't fix, but given that this appears to be the second report of this issue for 3.5 (see issue22971) ..." It's not because you get the same error message that the root cause is the same. Martin Panter wrote: "I saw this error recently on some 3.4 builtbots: (...) AMD64 Windows10 3.4" Again, the root cause can be very different. If you want to work on this crash, please open a separated issue for this specific crash on test_json. The code on Windows can be a little bit different, and ceval.c evolved between Python 3.4 and 3.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 09:11:44 2015 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 24 Sep 2015 07:11:44 +0000 Subject: [issue24894] iso-8859-11 missing from codecs table In-Reply-To: <1439964625.02.0.805508700241.issue24894@psf.upfronthosting.co.za> Message-ID: <1443078704.33.0.629166474011.issue24894@psf.upfronthosting.co.za> Ezio Melotti added the comment: Thanks Prashant for the patch and Victor for taking care of it! ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed versions: +Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 09:23:20 2015 From: report at bugs.python.org (Prashant Tyagi) Date: Thu, 24 Sep 2015 07:23:20 +0000 Subject: [issue24894] iso-8859-11 missing from codecs table In-Reply-To: <1443078462.7.0.709796923311.issue24894@psf.upfronthosting.co.za> Message-ID: Prashant Tyagi added the comment: Typo error is very silly,because i am new to this developement of python foundation .next time i will try my best. On Thu, Sep 24, 2015 at 12:37 PM, STINNER Victor wrote: > > STINNER Victor added the comment: > > > That was mistake in previous patch,so here is new patch for the same. > > Don't be sorry, that's why we have reviews :-) > > > +| iso8859_11 | iso-8856-11, iso-8859-11-2001, | Thai languages > | > +| | thai | > | > > I checked other ISO 8859 codecs: they also have an alias with the year, > but it's not documented. So I prefer to not document iso-8859-11-2001 > neither. > > There was a typo in "iso-8856-11": it's 8859. I fixed it and pushed your > change. > > Thanks for your first contribution Prashant ;-) > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 09:24:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Sep 2015 07:24:22 +0000 Subject: [issue21995] Idle: pseudofiles have no buffer attribute. In-Reply-To: <1405550850.77.0.279876996055.issue21995@psf.upfronthosting.co.za> Message-ID: <1443079462.57.0.681185762606.issue21995@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: https://docs.python.org/3/library/io.html#io.TextIOBase.buffer """buffer The underlying binary buffer (a BufferedIOBase instance) that TextIOBase deals with. This is not part of the TextIOBase API and may not exist in some implementations.""" It is common to replace standard streams with StringIO. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 09:30:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Sep 2015 07:30:59 +0000 Subject: [issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow In-Reply-To: <1443041934.39.0.663904562199.issue25222@psf.upfronthosting.co.za> Message-ID: <1443079859.44.0.0582839410324.issue25222@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The json code was almost not changed, so it can be related to changes in import machinery or in ceval.c if they consume more stack than previous. Yet one suspect is Argument Clinic that adds additional wrappers. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 09:52:14 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Sep 2015 07:52:14 +0000 Subject: [issue25210] Special-case NoneType() in do_richcompare() In-Reply-To: <1443078006.55.0.880532201273.issue25210@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: +1 to remove parenthesis from type names in the error message. But from all types, not only NoneType. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 09:53:44 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Sep 2015 07:53:44 +0000 Subject: [issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow In-Reply-To: <1443041934.39.0.663904562199.issue25222@psf.upfronthosting.co.za> Message-ID: <1443081224.63.0.490793684065.issue25222@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm unable to reproduce the issue on Linux. I tried system python 3.4.2 and the development version of Python 3.6. First I tried with no MongoDB server running. Then I tried with a MongoDB server running. I also ran the pymongo test suite on Windows 8.1 with Python development version (3.6) with no MongoDB server. With no MongoDB server running, I don't see threads running pymongo/periodic_executor.py. Any hint to try to reproduce the crash? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 09:58:00 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Sep 2015 07:58:00 +0000 Subject: [issue22032] Use __qualname__ together with __module__ In-Reply-To: <1406019756.34.0.140996851672.issue22032@psf.upfronthosting.co.za> Message-ID: <1443081480.09.0.28802282295.issue22032@psf.upfronthosting.co.za> STINNER Victor added the comment: Barry, Robert: I'm sorry that the change broke tests, but tests should not rely on the exact representation. They can test type(obj).__name__ for example. Barry: "people should be aware that this can break doctests" Some years ago, I was a big fan of doctest. But with the release of Python 3, I now think that it's a big mess. It's very hard to write reliable doctests. Most doctests rely on the exact representation of objects and subtle details which break on minor Python releases. IHMO it's better to write classic unittest tests and use functions like assertEqual(). By the way, the unittest made great progress last years, it shows better error message when a test fails. Maybe we should document better such changes in the https://docs.python.org/dev/whatsnew/3.5.html#porting-to-python-3-5 section ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 09:59:00 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Sep 2015 07:59:00 +0000 Subject: [issue22032] Use __qualname__ together with __module__ In-Reply-To: <1406019756.34.0.140996851672.issue22032@psf.upfronthosting.co.za> Message-ID: <1443081540.98.0.152988299614.issue22032@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh by the way, this issue is closed, what do you expect Barry and Robert? If you consider that it's a bug, please open a new issue and describe what you want :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 10:08:31 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Sep 2015 08:08:31 +0000 Subject: [issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow In-Reply-To: <1443041934.39.0.663904562199.issue25222@psf.upfronthosting.co.za> Message-ID: <1443082111.92.0.548787813334.issue25222@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy Storchaka added the comment: > The json code was almost not changed, so it can be related to changes in import machinery or in ceval.c if they consume more stack than previous. > > Yet one suspect is Argument Clinic that adds additional wrappers. This issue is about the number of Python frames, right? Argument Clinic may use a little bit more bytes on the C stack, but it doesn't create Python frames. Right? -- Current thread 0x00000a20 (most recent call first): File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 692 in _element_to_bson File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in File "C:\10gen\mongo-python-driver\bson\__init__.py", line 433 in _encode_mapping File "C:\10gen\mongo-python-driver\bson\__init__.py", line 653 in _name_value_to_bson ... The "Fatal Python error: Cannot recover from stack overflow" occurs when Python already raised a RecursionError (RuntimeError on Python < 3.5) in the current Python thread, but the recursion limit was reached again, even with 50 more frames than when the RecursionError was raised. Since a RecursionError exception was raised, I would expect the program to crash in an except block, but it's not the case. _name_value_to_bson:653: I don't have exactly the same version (I'm reading pymongo 3.0.3 source), but I only see a try/except KeyError here. No bare "except: pass" or "except Exception: ...". _element_to_bson:692: Ditto, only a try/except AttributeError. -- @Bernie: Would you be able to get a C backtrace using gdb on such crash? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 11:34:38 2015 From: report at bugs.python.org (NobilisVir) Date: Thu, 24 Sep 2015 09:34:38 +0000 Subject: [issue25226] "suffix" attribute not documented in logging.TimedRotatingFileHandler Message-ID: <1443087278.13.0.950277021973.issue25226@psf.upfronthosting.co.za> New submission from NobilisVir: The suffix attribute that controls the timestamp portion that gets appended to the file name is not documented (but it would be very useful to be). The documentation is here - https://docs.python.org/2/library/logging.handlers.html#timedrotatingfilehandler I learned about this attribute from an SO answer after searching for a solution to how to control the file name (this answer - http://stackoverflow.com/a/338566/1006955). ---------- assignee: docs at python components: Documentation messages: 251503 nosy: NobilisVir, docs at python priority: normal severity: normal status: open title: "suffix" attribute not documented in logging.TimedRotatingFileHandler type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 11:58:03 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 24 Sep 2015 09:58:03 +0000 Subject: [issue25211] Error message formatting errors in int object unit-test script In-Reply-To: <1442908335.62.0.971755787432.issue25211@psf.upfronthosting.co.za> Message-ID: <1443088683.72.0.603240203427.issue25211@psf.upfronthosting.co.za> Berker Peksag added the comment: subTest-long.patch looks good to me. Thanks! ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 12:39:50 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 24 Sep 2015 10:39:50 +0000 Subject: [issue21995] Idle: pseudofiles have no buffer attribute. In-Reply-To: <1405550850.77.0.279876996055.issue21995@psf.upfronthosting.co.za> Message-ID: <1443091190.38.0.923181932406.issue21995@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I believe this issue was derived from another were someone complained about something else being missing. I will just look into the other two and see if they are supposed to be there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 13:24:18 2015 From: report at bugs.python.org (acx01bc) Date: Thu, 24 Sep 2015 11:24:18 +0000 Subject: [issue25223] Statically or dynamically linked to the VC++runtime ? or how Python install fails on Vista despite the VC redist packages - api-ms-win-crt-runtime-l1-1-0.dll In-Reply-To: <1443045136.66.0.653550157365.issue25223@psf.upfronthosting.co.za> Message-ID: <1443093858.6.0.40238128376.issue25223@psf.upfronthosting.co.za> acx01bc added the comment: On Vista32bits, the VC++2015 redist package does install msvcr140.dll but none of the api-ms-win-crt-***-l1-1-0.dll, thus (that's why I opened this discussion at first) it is impossible to make many of the Python releases working, at least on Vista 32bits. There are many compiler options about the msvcr***.dll (platform V100,V110,V120,V140.., statically or dynamically linked to the C runtime, multi-threaded or not...) and obviously the settings used to build Python 3.4.3 work fine on Vista (platform V100), while the settings used to build Python 3.5.0 don't (platform V140). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 13:34:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 24 Sep 2015 11:34:31 +0000 Subject: [issue25208] improvements to the asyncio documentation In-Reply-To: <1442869187.79.0.516080462087.issue25208@psf.upfronthosting.co.za> Message-ID: <20150924113427.82638.79738@psf.io> Roundup Robot added the comment: New changeset 3909d29d29fc by Andrew Svetlov in branch '3.4': Fix #25208: Improve "Develop with asyncio" doc page. https://hg.python.org/cpython/rev/3909d29d29fc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 13:36:38 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Thu, 24 Sep 2015 11:36:38 +0000 Subject: [issue25208] improvements to the asyncio documentation In-Reply-To: <1442869187.79.0.516080462087.issue25208@psf.upfronthosting.co.za> Message-ID: <1443094598.1.0.786162050173.issue25208@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Fixed. Thanks! ---------- nosy: +asvetlov resolution: -> fixed stage: -> resolved status: open -> closed versions: +Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 13:38:18 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Sep 2015 11:38:18 +0000 Subject: [issue20519] Replace uuid ctypes usage with an extension module. In-Reply-To: <1391601143.27.0.910101155735.issue20519@psf.upfronthosting.co.za> Message-ID: <1443094698.49.0.226923932479.issue20519@psf.upfronthosting.co.za> STINNER Victor added the comment: In the Python stdlib, we try to avoid ctypes to use instead a C extension module. So I like the idea of a new optional _uuid module. I reviewed the attached patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 13:38:45 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Sep 2015 11:38:45 +0000 Subject: [issue20519] Replace uuid ctypes usage with an extension module. In-Reply-To: <1391601143.27.0.910101155735.issue20519@psf.upfronthosting.co.za> Message-ID: <1443094725.16.0.450489595039.issue20519@psf.upfronthosting.co.za> STINNER Victor added the comment: @Gustavo: Can you please take my remarks in account and rebase your change on the default branch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 13:46:27 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Sep 2015 11:46:27 +0000 Subject: [issue25209] Append space after completed keywords In-Reply-To: <1442870714.02.0.814978155097.issue25209@psf.upfronthosting.co.za> Message-ID: <1443095187.46.0.136886934522.issue25209@psf.upfronthosting.co.za> STINNER Victor added the comment: I tested the patch. "wi" displays "with " (space)., but "fo" displays "for" (no space). I don't understand why. Well, it's not a big issue, anyway the patch looks good to me. IMHO you should apply it to Python 3.4-3.6 (not only 3.6). ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 13:47:51 2015 From: report at bugs.python.org (Robert Kuska) Date: Thu, 24 Sep 2015 11:47:51 +0000 Subject: [issue22032] Use __qualname__ together with __module__ In-Reply-To: <1406019756.34.0.140996851672.issue22032@psf.upfronthosting.co.za> Message-ID: <1443095271.35.0.0410148099508.issue22032@psf.upfronthosting.co.za> Robert Kuska added the comment: I agree with you Victor that tests shouldn't rely on the exact representation and I also understand why such change was introduced therefore I don't think there is any bug to report, my comment was just pure 'FYI' for anyone who will come across it (as I did). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 13:55:10 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 24 Sep 2015 11:55:10 +0000 Subject: [issue25209] Append space after completed keywords In-Reply-To: <1442870714.02.0.814978155097.issue25209@psf.upfronthosting.co.za> Message-ID: <1443095710.82.0.099338091242.issue25209@psf.upfronthosting.co.za> Martin Panter added the comment: Victor, maybe because ?for? also stands for ?format?? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 14:18:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Sep 2015 12:18:36 +0000 Subject: [issue25209] Append space after completed keywords In-Reply-To: <1442870714.02.0.814978155097.issue25209@psf.upfronthosting.co.za> Message-ID: <1443097116.81.0.302544344997.issue25209@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > ?Else? doesn?t always use a colon. Consider ?1 if x else 2?. Good catch Martin. Unfortunately the completer doesn't take context into account. "else" with a colon is a common case, but unwanted colon could be annoyed. I agree that it would be safe to not append a colon after "else". At least unless we make the completer context aware. However I don't think that unwanted space would be so annoyed. Here is updated patch. I see that your code does an autocompletion for module names in "import", Martin. This was my next idea. Do you want to provide a patch for including this in CPython? > I tested the patch. "wi" displays "with " (space)., but "fo" displays "for" (no space). I don't understand why. Because there is "format(". > IMHO you should apply it to Python 3.4-3.6 (not only 3.6). This is definitely a new feature. And there is a risk to break something (if standard completer is used programmatic). ---------- Added file: http://bugs.python.org/file40561/rlcompleter_keyword_space_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 14:21:40 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Sep 2015 12:21:40 +0000 Subject: [issue25209] Append space after completed keywords In-Reply-To: <1442870714.02.0.814978155097.issue25209@psf.upfronthosting.co.za> Message-ID: <1443097300.45.0.0262703614697.issue25209@psf.upfronthosting.co.za> STINNER Victor added the comment: > This is definitely a new feature. And there is a risk to break something (if standard completer is used programmatic). Ok, it's up to you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 14:48:03 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Sep 2015 12:48:03 +0000 Subject: [issue25227] Optimize ASCII/latin1 encoder with surrogateescape error handlers Message-ID: <1443098883.44.0.854905908837.issue25227@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch is based on faster_surrogates_hadling.patch written by Serhiy Storchaka for the issue #24870. It optimizes str.encode('ascii', 'surrogateescape') and str.encode('ascii', 'latin1'). ---------- messages: 251516 nosy: haypo priority: normal severity: normal status: open title: Optimize ASCII/latin1 encoder with surrogateescape error handlers type: performance versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 14:51:30 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Sep 2015 12:51:30 +0000 Subject: [issue24870] Optimize coding with surrogateescape and surrogatepass error handlers In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za> Message-ID: <1443099090.71.0.534825186905.issue24870@psf.upfronthosting.co.za> STINNER Victor added the comment: I created the issue #25227 to optimize the ASCII and Latin1 *encoders* for surrogateescape. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 14:54:23 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 24 Sep 2015 12:54:23 +0000 Subject: [issue25227] Optimize ASCII/latin1 encoder with surrogateescape error handlers In-Reply-To: <1443098883.44.0.854905908837.issue25227@psf.upfronthosting.co.za> Message-ID: <20150924125420.31183.24658@psf.io> Roundup Robot added the comment: New changeset fa65c32d7134 by Victor Stinner in branch 'default': Issue #25227: Cleanup unicode_encode_ucs1() error handler https://hg.python.org/cpython/rev/fa65c32d7134 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 14:56:00 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Sep 2015 12:56:00 +0000 Subject: [issue25227] Optimize ASCII/latin1 encoder with surrogateescape error handlers In-Reply-To: <1443098883.44.0.854905908837.issue25227@psf.upfronthosting.co.za> Message-ID: <1443099360.59.0.221229077979.issue25227@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- keywords: +patch Added file: http://bugs.python.org/file40562/encode_ucs1_surrogateescape.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 15:01:18 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 24 Sep 2015 13:01:18 +0000 Subject: [issue25206] PEP 498: Minor mistakes/outdateness In-Reply-To: <1442865421.08.0.715266193748.issue25206@psf.upfronthosting.co.za> Message-ID: <20150924125420.16587.85775@psf.io> Roundup Robot added the comment: New changeset 7e32da8da58e by Eric V. Smith in branch 'default': Issue 25206: fix f-string exceptions to match the code. https://hg.python.org/peps/rev/7e32da8da58e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 15:01:44 2015 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 24 Sep 2015 13:01:44 +0000 Subject: [issue25206] PEP 498: Minor mistakes/outdateness In-Reply-To: <1442865421.08.0.715266193748.issue25206@psf.upfronthosting.co.za> Message-ID: <1443099704.47.0.203810528327.issue25206@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 15:06:00 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 24 Sep 2015 13:06:00 +0000 Subject: [issue25223] Statically or dynamically linked to the VC++runtime ? or how Python install fails on Vista despite the VC redist packages - api-ms-win-crt-runtime-l1-1-0.dll In-Reply-To: <1443045136.66.0.653550157365.issue25223@psf.upfronthosting.co.za> Message-ID: <1443099960.09.0.64575003242.issue25223@psf.upfronthosting.co.za> Steve Dower added the comment: msvcr140.dll does not exist and was never released. I'm not sure what you've installed, but it seems to be the wrong thing. I'm familiar with the compiler options and we are using the correct ones. If you want to change them, you should build your own copy. To help me help you with your installation issue, could you attach a list of all the DLLs in your System32 folder? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 15:11:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Sep 2015 13:11:05 +0000 Subject: [issue24870] Optimize coding with surrogateescape and surrogatepass error handlers In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za> Message-ID: <1443100265.5.0.23399866069.issue24870@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I worked on UTF-16 and UTF-32 encoders, but now I'm off my developing computer. I'll provide updated patch soon. I think that only "surrogateescape" and "surrogatepass" error handlers have need in optimization, because they are used to interpolate with other programs, including old Python versions. "strict" stops processing, an optimization is not needed here. All other error handlers lose information and can't be used per se for transcoding bytes as string or string as bytes. They are used together with other slow code (for example for encoding string in XML or HTML you first need to escape '&', '<' and quotes). It is easy to add fast handling for 'ignore' and 'replace', but these error handlers are used largely for produce human-readable output, and adding it can slow down common case (no errors). That is why I limit my patch for "surrogateescape" and "surrogatepass" only. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 15:35:33 2015 From: report at bugs.python.org (Radek Novacek) Date: Thu, 24 Sep 2015 13:35:33 +0000 Subject: [issue21295] Python 3.4 gives wrong col_offset for Call nodes returned from ast.parse In-Reply-To: <1397818180.59.0.739018200129.issue21295@psf.upfronthosting.co.za> Message-ID: <1443101733.1.0.239815446079.issue21295@psf.upfronthosting.co.za> Radek Novacek added the comment: I've ran the tests from first and second comment using python 3.5.0 and it seems it produces correct results: >>> import ast >>> tree = ast.parse("sin(0.5)") >>> first_stmt = tree.body[0] >>> call = first_stmt.value >>> print("col_offset of call expression:", call.col_offset) col_offset of call expression: 0 >>> print("col_offset of func of the call:", call.func.col_offset) col_offset of func of the call: 0 >>> tree = ast.parse("(sin\n(0.5))") >>> first_stmt = tree.body[0] >>> call = first_stmt.value >>> print("col_offset of call expression:", call.col_offset) col_offset of call expression: 1 >>> print("col_offset of func of the call:", call.func.col_offset) col_offset of func of the call: 1 >>> print("lineno of call expression:", call.lineno) lineno of call expression: 1 >>> print("lineno of func of the call:", call.lineno) lineno of func of the call: 1 ---------- nosy: +rnovacek _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 15:45:01 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 24 Sep 2015 13:45:01 +0000 Subject: [issue16701] Docs missing the behavior of += (in-place add) for lists. In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za> Message-ID: <1443102301.26.0.713776641698.issue16701@psf.upfronthosting.co.za> R. David Murray added the comment: Something I missed on the first review: why did you change "the same as" to "usually the same as"? When is it different? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 15:57:46 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 24 Sep 2015 13:57:46 +0000 Subject: [issue25210] Special-case NoneType() in do_richcompare() In-Reply-To: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za> Message-ID: <1443103066.74.0.0513576591216.issue25210@psf.upfronthosting.co.za> R. David Murray added the comment: See issue 20077. IMO it should still say int < NoneType, to be consistent. I still don't see a reason to special case None here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 16:04:01 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Sep 2015 14:04:01 +0000 Subject: [issue25210] Fix do_richcompare() error message: remove parenthesis from type names In-Reply-To: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za> Message-ID: <1443103441.32.0.124924217718.issue25210@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Special-case NoneType() in do_richcompare() -> Fix do_richcompare() error message: remove parenthesis from type names _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 16:15:38 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Sep 2015 14:15:38 +0000 Subject: [issue25227] Optimize ASCII/latin1 encoder with surrogateescape error handlers In-Reply-To: <1443098883.44.0.854905908837.issue25227@psf.upfronthosting.co.za> Message-ID: <1443104138.95.0.819447513261.issue25227@psf.upfronthosting.co.za> STINNER Victor added the comment: Updated test now with more unit tests. ---------- Added file: http://bugs.python.org/file40563/encode_ucs1_surrogateescape-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 16:16:18 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Sep 2015 14:16:18 +0000 Subject: [issue25227] Optimize ASCII/latin1 encoder with surrogateescape error handlers In-Reply-To: <1443098883.44.0.854905908837.issue25227@psf.upfronthosting.co.za> Message-ID: <1443104178.32.0.644151928609.issue25227@psf.upfronthosting.co.za> STINNER Victor added the comment: Result of a micro-benchmark with encode_ucs1_surrogateescape-2.patch. Common platform: Timer info: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09) Timer: time.perf_counter CPU model: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz Python unicode implementation: PEP 393 Platform: Linux-4.1.6-200.fc22.x86_64-x86_64-with-fedora-22-Twenty_Two CFLAGS: -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes Bits: int=32, long=64, long long=64, size_t=64, void*=64 Platform of campaign before: Date: 2015-09-24 16:12:35 Timer precision: 54 ns Python version: 3.6.0a0 (default:fa65c32d7134, Sep 24 2015, 16:11:44) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] SCM: hg revision=fa65c32d7134 tag=tip branch=default date="2015-09-24 14:45 +0200" Platform of campaign after: Python version: 3.6.0a0 (default:fa65c32d7134+, Sep 24 2015, 16:13:20) [GCC 5.1.1 20150618 (Red Hat 5.1.1-4)] Timer precision: 55 ns SCM: hg revision=fa65c32d7134+ tag=tip branch=default date="2015-09-24 14:45 +0200" Date: 2015-09-24 16:13:21 -----------------------+-------------+--------------- ascii | before | after -----------------------+-------------+--------------- 100 x 10**1 characters | 6.65 us (*) | 1.93 us (-71%) 100 x 10**3 characters | 512 us (*) | 158 us (-69%) 100 x 10**2 characters | 52.2 us (*) | 16.2 us (-69%) 100 x 10**4 characters | 5.09 ms (*) | 1.59 ms (-69%) -----------------------+-------------+--------------- Total | 5.66 ms (*) | 1.77 ms (-69%) -----------------------+-------------+--------------- -----------------------+-------------+--------------- latin1 | before | after -----------------------+-------------+--------------- 100 x 10**1 characters | 6.24 us (*) | 1.89 us (-70%) 100 x 10**3 characters | 500 us (*) | 160 us (-68%) 100 x 10**2 characters | 51 us (*) | 16.3 us (-68%) 100 x 10**4 characters | 5 ms (*) | 1.59 ms (-68%) -----------------------+-------------+--------------- Total | 5.56 ms (*) | 1.77 ms (-68%) -----------------------+-------------+--------------- --------+-------------+--------------- Summary | before | after --------+-------------+--------------- ascii | 5.66 ms (*) | 1.77 ms (-69%) latin1 | 5.56 ms (*) | 1.77 ms (-68%) --------+-------------+--------------- Total | 11.2 ms (*) | 3.53 ms (-69%) --------+-------------+--------------- ---------- Added file: http://bugs.python.org/file40564/bench.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 16:16:44 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Thu, 24 Sep 2015 14:16:44 +0000 Subject: [issue22032] Use __qualname__ together with __module__ In-Reply-To: <1406019756.34.0.140996851672.issue22032@psf.upfronthosting.co.za> Message-ID: <1443104204.46.0.632206953448.issue22032@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: I'm not expecting a change either, I was also just documenting observed breakages. Given that I've ported a *ton* of code to 3.5 and only seen a handful of failures related to this issue, I agree that it's better just to provide information and let packages fix their code. I am keeping a running document of such issues here: https://wiki.python.org/moin/PortingToPy3k/34to35 As for the larger question of doctests, we can discuss elsewhere. Probably not appropriate for *this* issue . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 16:18:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Sep 2015 14:18:10 +0000 Subject: [issue24870] Optimize ascii and latin1 decoder with surrogateescape and surrogatepass error handlers In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za> Message-ID: <1443104290.46.0.58820910623.issue24870@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Optimize coding with surrogateescape and surrogatepass error handlers -> Optimize ascii and latin1 decoder with surrogateescape and surrogatepass error handlers _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 16:24:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Sep 2015 14:24:54 +0000 Subject: [issue25210] Special-case NoneType() in do_richcompare() In-Reply-To: <1443103066.74.0.0513576591216.issue25210@psf.upfronthosting.co.za> Message-ID: <2728131.cihTAhQ0Oy@raxxla> Serhiy Storchaka added the comment: int < NoneType is not the same as int() < None. ---------- title: Fix do_richcompare() error message: remove parenthesis from type names -> Special-case NoneType() in do_richcompare() _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 16:26:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Sep 2015 14:26:49 +0000 Subject: [issue24870] Optimize ascii and latin1 decoder with surrogateescape and surrogatepass error handlers In-Reply-To: <1439608124.5.0.0773186444318.issue24870@psf.upfronthosting.co.za> Message-ID: <1443104809.07.0.136340877996.issue24870@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy wrote: "All other error handlers lose information and can't be used per se for transcoding bytes as string or string as bytes." Well, it was very simple to implement replace and ignore in decoders. I believe that the error handlers are commonly used. "(...) adding it can slow down common case (no errors). That is why I limit my patch for "surrogateescape" and "surrogatepass" only." We can start with benchmarks and see if modifying Objects/stringlib/ has a real impact on performances, or if modifying the "slower" decoder in Objects/unicodeobject.c is enough. IMHO it's fine to implement many error handlers in Objects/unicodeobject.c: it's the "slow" path when at least one error occurred, so it doesn't impact the path to decode valid UTF-8 strings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 16:28:23 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Sep 2015 14:28:23 +0000 Subject: [issue22032] Use __qualname__ together with __module__ In-Reply-To: <1443104204.46.0.632206953448.issue22032@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Ok, anyway, thanks for your feedback. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 16:28:56 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 24 Sep 2015 14:28:56 +0000 Subject: [issue25210] Special-case NoneType() in do_richcompare() In-Reply-To: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za> Message-ID: <1443104936.38.0.242259109924.issue25210@psf.upfronthosting.co.za> STINNER Victor added the comment: Stupid email interface, it restored the the previous title. I tried to change the title to: "Fix do_richcompare() error message: remove parenthesis from type names" ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 16:33:44 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 24 Sep 2015 14:33:44 +0000 Subject: [issue25210] Special-case NoneType() in do_richcompare() In-Reply-To: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za> Message-ID: <1443105224.39.0.368786880601.issue25210@psf.upfronthosting.co.za> R. David Murray added the comment: Serhiy: it's not the same, but the both are correct and parallel, and int < NoneType is *consistent* with the rest of the message, whereas having the parenthesis in there is not (since in that case you are referring to instances, not types). Changing the message format to be more like the other binary op messages might be better, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 17:15:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Sep 2015 15:15:59 +0000 Subject: [issue25210] Special-case NoneType() in do_richcompare() In-Reply-To: <1443105224.39.0.368786880601.issue25210@psf.upfronthosting.co.za> Message-ID: <1714406.QaXxgCbNGh@raxxla> Serhiy Storchaka added the comment: It makes the error message just non-relevant (or misleading) to the error. It refers to int < NoneType, but actually the exception is raised when you compare an int instance with a NoneType instance, not two types theirself. Comparing *any two types* raises an exception, but comparing instances of two types can return a result. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 17:19:21 2015 From: report at bugs.python.org (Mark Roseman) Date: Thu, 24 Sep 2015 15:19:21 +0000 Subject: [issue25198] Idle: improve idle.html help viewer. In-Reply-To: <1442794067.12.0.0580996406415.issue25198@psf.upfronthosting.co.za> Message-ID: <1443107961.19.0.291229018466.issue25198@psf.upfronthosting.co.za> Mark Roseman added the comment: Have attached help-indent-fix.patch. Basically the parser is very fragile when it comes to combining tags, so the handling of the 'span .pre' was stomping on the indent tag. Separated out handling of character level tags (e.g. italic) from block level tags (e.g. lists, headings). ---------- keywords: +patch Added file: http://bugs.python.org/file40565/help-indent-fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 17:36:01 2015 From: report at bugs.python.org (Mark Roseman) Date: Thu, 24 Sep 2015 15:36:01 +0000 Subject: [issue25225] Idle doc: redo Syntax Colors section In-Reply-To: <1443049901.66.0.834655906435.issue25225@psf.upfronthosting.co.za> Message-ID: <1443108961.08.0.610770167954.issue25225@psf.upfronthosting.co.za> Mark Roseman added the comment: I'd suggest that there is no reason to include the list of what elements can be coloured, as it's there in the dialog for anyone who wants to muck with it. Just the first paragraph (two sentences) would be sufficient I think. Even dropping it from the document entirely wouldn't be a bad thing. ---------- nosy: +markroseman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 17:45:31 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 24 Sep 2015 15:45:31 +0000 Subject: [issue25210] Special-case NoneType() in do_richcompare() In-Reply-To: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za> Message-ID: <1443109531.05.0.494153944673.issue25210@psf.upfronthosting.co.za> R. David Murray added the comment: That's why I said that making it like the other binary op messages might be better. Currently the error message says that the error is that two types were compared ("unorderable types"), which as you point is not quite accurate. It is, however, fairly parallel to the message used for binary operations: TypeError: unsupported operand type(s) for +: 'int' and 'NoneType' I think it would be good to change the existing message to match: TypeError: unsupported operand type(s) for '<': 'int' and 'NoneType' The *best* change would be something like: TypeError: '<' does not support comparison of operands whose types are 'int' and 'NoneType' TypeError: '+' does not support addition of operands whose types are 'int' and 'NoneType' But that might be much harder to implement depending on how the binary op error message(s) are implemented. Leave out "addition of" and "comparison of" in the above messages and they might still be better than the status quo, but probably not enough to warrant doing it if doing it is hard. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 18:38:00 2015 From: report at bugs.python.org (eryksun) Date: Thu, 24 Sep 2015 16:38:00 +0000 Subject: [issue25223] Statically or dynamically linked to the VC++runtime ? or how Python install fails on Vista despite the VC redist packages - api-ms-win-crt-runtime-l1-1-0.dll In-Reply-To: <1443045136.66.0.653550157365.issue25223@psf.upfronthosting.co.za> Message-ID: <1443112680.08.0.841570071534.issue25223@psf.upfronthosting.co.za> eryksun added the comment: Try directly installing the Universal CRT update, [Windows6.0-KB2999226-x86.msu][1]. Run it with the /log option, e.g. Windows6.0-KB2999226-x86.msu /log:kb2999226.evtx You can view this log in the Windows event viewer, or convert it to text XML on the command line as follows: wevtutil qe kb2999226.evtx /lf:true /f:XML /e:MSULog > kb2999226.xml If the update fails, please attach the XML log to this issue. Steve, since these updates require an up-to-date Windows installation, maybe you should test for SP2 on Vista, SP1 on Windows 7, and S14 on Windows 8.1. Display a warning if the OS is outdated, including Windows XP, but let the install proceed. [1]: http://www.microsoft.com/en-us/download/details.aspx?id=48234 ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 18:57:56 2015 From: report at bugs.python.org (Tim Graham) Date: Thu, 24 Sep 2015 16:57:56 +0000 Subject: [issue25228] Regression in cookie parsing with brackets and quotes Message-ID: <1443113876.69.0.763546669405.issue25228@psf.upfronthosting.co.za> New submission from Tim Graham: Regression in https://hg.python.org/cpython/rev/9e765e65e5cb (affects 2.7 and 3.2+), similar to issue22931 where inserting an invalid cookie value can cause the rest of the cookie to be ignored. A test is attached, and here's a quick demo: Old: >>> from http.cookies import SimpleCookie >>> SimpleCookie('a=b; messages=[\"\"]; c=d;') {'a': 'b', 'c': 'd', 'messages': ''} New: >>> SimpleCookie('a=b; messages=[\"\"]; c=d;') {'a': 'b'} Reported in Django's tracker, but Django simply delegates to SimpleCookie: https://code.djangoproject.com/ticket/25458 ---------- components: Library (Lib) files: cookie-bracket-quotes-test.diff keywords: patch messages: 251538 nosy: Tim.Graham priority: normal severity: normal status: open title: Regression in cookie parsing with brackets and quotes type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40566/cookie-bracket-quotes-test.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 19:10:20 2015 From: report at bugs.python.org (Bernie Hackett) Date: Thu, 24 Sep 2015 17:10:20 +0000 Subject: [issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow In-Reply-To: <1443041934.39.0.663904562199.issue25222@psf.upfronthosting.co.za> Message-ID: <1443114620.7.0.430476486823.issue25222@psf.upfronthosting.co.za> Bernie Hackett added the comment: > File "D:\buildarea\3.4.bolen-windows10\build\lib\test\test_json\test_recursion.py", line 96 in test_endless_recursion That test (and reason for existence) is almost exactly the same as the PyMongo test that causes abort reported in this ticket. I'm not surprised it is also failing. test_pickle appears to have a similar issue. For test_json see here: https://hg.python.org/cpython/rev/a21f5af476cb And PyMongo's equivalent test: https://github.com/mongodb/mongo-python-driver/blob/4bbe2133a14df716b1dffe8ab7957ed67149b2cd/test/test_bson.py#L538-L543 > I'm unable to reproduce the issue on Linux. The abort is very rare for me on Linux, so much so that I originally thought it only occurred on Windows. I can't reproduce it on a local Linux machine, but it has happened inconsistently in our Jenkins cluster. For example (note that this run includes a commit that uses sys.setrecursionlimit(250) and still aborts): https://jenkins.mongodb.com/view/Python/job/mongo-python-driver/404/extensions=without-extensions,label=linux64,mongodb_configuration=single_server,mongodb_option=noauth,mongodb_server=26-release,python_language_version=3.5/console > First I tried with no MongoDB server running. Then I tried with a MongoDB server running. The problem only occurs for me when testing with a MongoDB instance running. Running background threads seem to be a key requirement for reproduction. Note also that this problem does not reproduce when using PyMongo's C extensions, only when using the pure python BSON encoder. You can run the tests like this from a clean git checkout: python3.5 setup.py --no_ext test > I don't have exactly the same version (I'm reading pymongo 3.0.3 source) Clone master from github: https://github.com/mongodb/mongo-python-driver > @Bernie: Would you be able to get a C backtrace using gdb on such crash? Not likely, since I can't reproduce it under Linux locally. But I *can* reproduce it consistently on a Windows 7 machine that has VS2015. I'll see what I can get out of the Visual Studio debugger and report back. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 19:33:22 2015 From: report at bugs.python.org (Bernie Hackett) Date: Thu, 24 Sep 2015 17:33:22 +0000 Subject: [issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow In-Reply-To: <1443041934.39.0.663904562199.issue25222@psf.upfronthosting.co.za> Message-ID: <1443116002.07.0.0418360099363.issue25222@psf.upfronthosting.co.za> Bernie Hackett added the comment: > Clone master from github: You'll also have to git checkout 4bbe2133a14df716b1dffe8ab7957ed67149b2cd to roll back the setrecursionlimit change I added to work around this issue. Using 100 seems to have permanently vanquished the abort, but there's no way the stack is overflowing with such a low setting and Py_EnterRecursiveCall shouldn't cause python to abort all by itself. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 20:42:02 2015 From: report at bugs.python.org (Bernie Hackett) Date: Thu, 24 Sep 2015 18:42:02 +0000 Subject: [issue25222] 3.5.0 regression - Fatal Python error: Cannot recover from stack overflow In-Reply-To: <1443041934.39.0.663904562199.issue25222@psf.upfronthosting.co.za> Message-ID: <1443120122.05.0.9619148187.issue25222@psf.upfronthosting.co.za> Bernie Hackett added the comment: Here's a chunk of the call stack from the Visual Studio debugger using the debug build. Py_FatalError seems to be called multiple times: > ucrtbased.dll!72d27f30() Unknown [Frames below may be incorrect and/or missing, no symbols loaded for ucrtbased.dll] [External Code] python35_d.dll!Py_FatalError(const char * msg) Line 1375 C python35_d.dll!_Py_CheckRecursiveCall(const char * where) Line 733 C python35_d.dll!PyObject_Call(_object * func, _object * arg, _object * kw) Line 2144 C python35_d.dll!call_function_tail(_object * callable, _object * args) Line 2173 C python35_d.dll!callmethod(_object * func, const char * format, char * va, int is_size_t) Line 2242 C python35_d.dll!_PyObject_CallMethodId(_object * o, _Py_Identifier * name, const char * format, ...) Line 2287 C python35_d.dll!flush_std_files() Line 488 C python35_d.dll!Py_FatalError(const char * msg) Line 1354 C python35_d.dll!_Py_CheckRecursiveCall(const char * where) Line 733 C python35_d.dll!PyObject_Call(_object * func, _object * arg, _object * kw) Line 2144 C python35_d.dll!do_call(_object * func, _object * * * pp_stack, int na, int nk) Line 4883 C python35_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4679 C python35_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3183 C python35_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4751 C python35_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4677 C python35_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3183 C python35_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4751 C python35_d.dll!call_function(_object * * * pp_stack, int oparg) Line 4677 C python35_d.dll!PyEval_EvalFrameEx(_frame * f, int throwflag) Line 3183 C python35_d.dll!_PyEval_EvalCodeWithName(_object * _co, _object * globals, _object * locals, _object * * args, int argcount, _object * * kws, int kwcount, _object * * defs, int defcount, _object * kwdefs, _object * closure, _object * name, _object * qualname) Line 3962 C python35_d.dll!fast_function(_object * func, _object * * * pp_stack, int n, int na, int nk) Line 4760 C ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 21:22:40 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 24 Sep 2015 19:22:40 +0000 Subject: [issue18787] Misleading error from getspnam function of spwd module In-Reply-To: <1376971981.98.0.467831293927.issue18787@psf.upfronthosting.co.za> Message-ID: <1443122560.08.0.631662537234.issue18787@psf.upfronthosting.co.za> Berker Peksag added the comment: Here is a patch with a test. ---------- nosy: +berker.peksag stage: needs patch -> patch review versions: +Python 3.6 -Python 3.4 Added file: http://bugs.python.org/file40567/issue18787.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 21:26:19 2015 From: report at bugs.python.org (Remi Pointel) Date: Thu, 24 Sep 2015 19:26:19 +0000 Subject: [issue25154] Drop the pyvenv script In-Reply-To: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za> Message-ID: <1443122779.4.0.809836250695.issue25154@psf.upfronthosting.co.za> Remi Pointel added the comment: I would prefer to keep this script with the version referring to the version of python used (pyvenv-3.4, pyvenv-3.5, ...). ---------- nosy: +rpointel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 22:03:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 24 Sep 2015 20:03:11 +0000 Subject: [issue18787] Misleading error from getspnam function of spwd module In-Reply-To: <1376971981.98.0.467831293927.issue18787@psf.upfronthosting.co.za> Message-ID: <1443124990.99.0.586927530656.issue18787@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: As far as this change breaks compatibility. please add a note in the "Porting to Python 3.6" section in What's New. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 23:20:53 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 24 Sep 2015 21:20:53 +0000 Subject: [issue16701] Docs missing the behavior of += (in-place add) for lists. In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za> Message-ID: <1443129653.4.0.0651421714502.issue16701@psf.upfronthosting.co.za> Martin Panter added the comment: The ?s += t? operation assigns the result back to s. So it could involve an extra __setattr__()/__setitem__() call, or an exception trying to modify a tuple item, etc. The extend() and slice assignment versions don?t have this extra stage. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 23:32:11 2015 From: report at bugs.python.org (Calvin Walton) Date: Thu, 24 Sep 2015 21:32:11 +0000 Subject: [issue25229] distutils doesn't add "-Wl, " prefix to "-R" on Linux if the C compiler isn't named 'gcc' Message-ID: <1443130331.16.0.912755488197.issue25229@psf.upfronthosting.co.za> New submission from Calvin Walton: On Exherbo, the main C/C++ compilers are named e.g. "x86_64-pc-linux-gnu-cc" and "x86_64-pc-linux-gnu-c++", and they are symlinks to either (usually) gcc or (rarely) clang. Since distutils (in unixccompiler.py) is checking for the substring "gcc" or "g++" in the compiler name, this does not match our compiler - and the "-Wl," prefix is missing, resulting in link errors in some cases. (We are particularly noticing this when doing gobject-introspection builds via cmake, where giscanner uses distutils to build the link command) As far as I know, all major compilers on Linux require the -Wl, option to pass through linker options - clang actually interprets -R without -Wl, to mean something completely different. We are planning to locally patch distutils to have an additional condition to the gcc check, `sys.platform[:5] == "linux" or self._is_gcc(compiler):` in our distribution to work around the issue. I'll attach patches once they're prepared, but I'd appreciate feedback about the problem. ---------- components: Distutils messages: 251546 nosy: Calvin Walton, dstufft, eric.araujo priority: normal severity: normal status: open title: distutils doesn't add "-Wl," prefix to "-R" on Linux if the C compiler isn't named 'gcc' versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Sep 24 23:33:15 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 24 Sep 2015 21:33:15 +0000 Subject: [issue25198] Idle: improve idle.html help viewer. In-Reply-To: <1442794067.12.0.0580996406415.issue25198@psf.upfronthosting.co.za> Message-ID: <20150924213311.94107.45484@psf.io> Roundup Robot added the comment: New changeset 8b3dc527a62c by Terry Jan Reedy in branch '2.7': Issue #25198: In Idle doc viewer, fix indent of fixed-pitch 
 text
https://hg.python.org/cpython/rev/8b3dc527a62c

New changeset 1d0f4b94066b by Terry Jan Reedy in branch '3.4':
Issue #25198: In Idle doc viewer, fix indent of fixed-pitch 
 text
https://hg.python.org/cpython/rev/1d0f4b94066b

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Thu Sep 24 23:51:05 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 24 Sep 2015 21:51:05 +0000
Subject: [issue16701] Docs missing the behavior of += (in-place add) for lists.
In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za>
Message-ID: <1443131465.75.0.793610907389.issue16701@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, good point.  I'd say something like "for the most part" then instead of "usually", since what you describe always happens.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 00:11:28 2015
From: report at bugs.python.org (Calvin Walton)
Date: Thu, 24 Sep 2015 22:11:28 +0000
Subject: [issue25229] distutils doesn't add "-Wl,
 " prefix to "-R" on Linux if the C compiler  isn't named 'gcc'
In-Reply-To: <1443130331.16.0.912755488197.issue25229@psf.upfronthosting.co.za>
Message-ID: <1443132688.01.0.735525401186.issue25229@psf.upfronthosting.co.za>


Changes by Calvin Walton :


----------
keywords: +patch
Added file: http://bugs.python.org/file40568/distutils-compiler-name.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 00:11:55 2015
From: report at bugs.python.org (Calvin Walton)
Date: Thu, 24 Sep 2015 22:11:55 +0000
Subject: [issue25229] distutils doesn't add "-Wl,
 " prefix to "-R" on Linux if the C compiler  isn't named 'gcc'
In-Reply-To: <1443130331.16.0.912755488197.issue25229@psf.upfronthosting.co.za>
Message-ID: <1443132715.23.0.615246925592.issue25229@psf.upfronthosting.co.za>


Changes by Calvin Walton :


Added file: http://bugs.python.org/file40569/distutils-compiler-name.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 00:14:21 2015
From: report at bugs.python.org (rb)
Date: Thu, 24 Sep 2015 22:14:21 +0000
Subject: [issue25230] Unix datagram sockets not supported
Message-ID: <1443132861.89.0.286854164453.issue25230@psf.upfronthosting.co.za>


New submission from rb:

AF_UNIX, SOCK_DGRAM sockets are valid, but asyncio doesn't appear to support them.

I've tried combinations of create_connection, create_datagram_endpoint and create_unix_connection, creating a socket myself and passing in sock, and equivalent methods at the server end. There seem to be implicit assumptions about addresses being 2-tuples (instead of strings) and transports being hardcoded to be constructed as either stream or datagram transports. create_unix_connection makes the assumption that it will be a stream, and create_datagram_endpoint that it will be AF_INET or AF_INET6 with (host, port) addressing.

I used 3.4.3, but looking at the docs it doesn't look like this was addressed in 3.5 either.

I'd like this because message boundaries are preserved (unlike in SOCK_STREAM), which if it Just Worked would make local system IPC (eg. with JSON-RPC) extremely trivial to implement in asyncio.

----------
components: asyncio
messages: 251549
nosy: gvanrossum, haypo, rb, yselivanov
priority: normal
severity: normal
status: open
title: Unix datagram sockets not supported
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 00:19:28 2015
From: report at bugs.python.org (Mark Roseman)
Date: Thu, 24 Sep 2015 22:19:28 +0000
Subject: [issue24820] IDLE themes for light on dark
In-Reply-To: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>
Message-ID: <1443133168.29.0.476842830485.issue24820@psf.upfronthosting.co.za>


Mark Roseman added the comment:

I wrote a short utility that parses TextMate XML-based theme files (which are also used by Sublime) and converts them into something IDLE can use. It's not a perfect match, because IDLE's themes are more restrictive, but it's not bad.

I'm attaching the output of the script (config-highlight.cfg), which was able to translate 17 themes. A few are kind of yucky, and they all need some tweaking for selection and shell colors, but it's not a bad place to start...

----------
Added file: http://bugs.python.org/file40570/config-highlight.cfg

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 00:26:04 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 24 Sep 2015 22:26:04 +0000
Subject: [issue25230] Unix datagram sockets not supported
In-Reply-To: <1443132861.89.0.286854164453.issue25230@psf.upfronthosting.co.za>
Message-ID: <1443133564.57.0.917468218238.issue25230@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

The simplest fix for this IMO is to add a sock parameter to create_datagram_endpoint(). I've filed an issue for this in the upstream asyncio project: https://github.com/python/asyncio/issues/266

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 00:28:22 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 24 Sep 2015 22:28:22 +0000
Subject: [issue21506] Windows MSI installer should mklink (symlink) python.exe
 to python2.7.exe
In-Reply-To: <1400067370.68.0.607872004364.issue21506@psf.upfronthosting.co.za>
Message-ID: <1443133702.72.0.242372707324.issue21506@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I've changed the version to 3.6 only as I just can't see this happening for any other.  For all I know this might have been sorted in 3.5, I'll leave that decision to our Windows gurus.

----------
nosy: +BreamoreBoy
versions: +Python 3.6 -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 00:31:38 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 24 Sep 2015 22:31:38 +0000
Subject: [issue4918] Windows installer created with Python X.Y does not work
 with Python X.Y+1
In-Reply-To: <1231738106.14.0.212121765754.issue4918@psf.upfronthosting.co.za>
Message-ID: <1443133898.5.0.190554353557.issue4918@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Can this be closed as history with so many changes having been made to the installer for 3.5?

----------
nosy: +BreamoreBoy, paul.moore, steve.dower, tim.golden, zach.ware
versions: +Python 3.6 -Python 2.7, Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 00:37:09 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 24 Sep 2015 22:37:09 +0000
Subject: [issue8304] time.strftime() and Unicode characters on Windows
In-Reply-To: <1270307324.04.0.0348018847246.issue8304@psf.upfronthosting.co.za>
Message-ID: <1443134229.38.0.0665795594258.issue8304@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Alexander what is you take on this please?  I can confirm that it is still a problem on Windows in 3.5.0.

----------
nosy: +belopolsky

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 00:58:06 2015
From: report at bugs.python.org (Bernie Hackett)
Date: Thu, 24 Sep 2015 22:58:06 +0000
Subject: [issue25222] 3.5.0 regression - Fatal Python error: Cannot recover
 from stack overflow
In-Reply-To: <1443041934.39.0.663904562199.issue25222@psf.upfronthosting.co.za>
Message-ID: <1443135486.37.0.914783137379.issue25222@psf.upfronthosting.co.za>


Bernie Hackett added the comment:

On second thought, _Py_CheckRecursiveCall may be being called recursively through Py_FatalError.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 01:16:00 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 24 Sep 2015 23:16:00 +0000
Subject: [issue25198] Idle: improve idle.html help viewer.
In-Reply-To: <1442794067.12.0.0580996406415.issue25198@psf.upfronthosting.co.za>
Message-ID: <1443136560.78.0.148949470838.issue25198@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Fixed.  I added a light background as with Sphinx html. I am delighted with how well this is working so far.  I like the little always-there [TOC] button better than the browser sidebar.  Besides making it easy to verify the look of doc changes, I think it looks better. I like the appearance of the tk version, without the down arrow, a bit better than the ttk version with an arrow, but would switch, when possible, if there were functional reason (see below).

To improve the button: I want to add an activebackground (or foreground) so when moused over, the button is more obviously a live button to be pushed.  Any particular suggestion?  Is there a standard?  Or do I worry too much? Idle buttons don't change when moused over, but they have relief to convey 'push me'.

So that people can navigate without mouse, I tested adding takefocus=True to toc creation, takefocus=False to text, and toc.focus_set().  (and ), , and  work as expected. However the tk Menubutton (but not ttk version) seems to have a bug (at least here, ).  After , it is left in a 'pressed' state, with a black outline, while the menu is displayed, and after.  (With  the outline and menu appear on button-press and the outline disappears on button-release, while the menu remains.) A click on the button is required to reset it and remove the outline.  Then either  or  work as before.  I tried an expanded command function to reset toc,
           def cmd(mark=tag):
                toc['state'] = 'disabled'
                toc['state'] = 'normal'
                text.see(mark)
but this does not work.  If this bug windows-only or general? Do you know of any other workaround to make the tk version work right?  Since click-to-reset is not obvious, and defeats keyboard-only use, I will not enable focus when click-reset is needed.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 01:21:47 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 24 Sep 2015 23:21:47 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1443136907.74.0.966269954937.issue9566@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I've got the latest output with all of the warnings but I'm not sure where I should attach it as #18295 and #18407 also apply.  There are also multiple deprecation warnings but I'm sure they've been discussed before.  Can somebody please advise, thanks.

----------
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 02:22:24 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Sep 2015 00:22:24 +0000
Subject: [issue8304] time.strftime() and Unicode characters on Windows
In-Reply-To: <1270307324.04.0.0348018847246.issue8304@psf.upfronthosting.co.za>
Message-ID: <1443140544.7.0.344300914948.issue8304@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Mark, I am no expert on Windows.  I believe Victor is most knowledgable in this area.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 02:52:27 2015
From: report at bugs.python.org (eryksun)
Date: Fri, 25 Sep 2015 00:52:27 +0000
Subject: [issue21506] Windows MSI installer should mklink (symlink) python.exe
 to python2.7.exe
In-Reply-To: <1400067370.68.0.607872004364.issue21506@psf.upfronthosting.co.za>
Message-ID: <1443142347.4.0.654656515569.issue21506@psf.upfronthosting.co.za>


eryksun added the comment:

Creating a symbolic link can't be relied on for a per-user installation. Administrators have to elevate to create symbolic links, and most regular users also lack this privilege.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 03:05:09 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 25 Sep 2015 01:05:09 +0000
Subject: [issue8304] time.strftime() and Unicode characters on Windows
In-Reply-To: <1270307324.04.0.0348018847246.issue8304@psf.upfronthosting.co.za>
Message-ID: <1443143109.54.0.202397357299.issue8304@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

The problem is definitely that:
format = PyUnicode_EncodeLocale(format_arg, "surrogateescape");
fails on Windows.

Windows is using strftime, not wcsftime. It's not using wcsftime because of issue 10653.

If I force Windows to use wcsftime, this particular example works:
>>> time.strftime("%d\u200F%A", time.gmtime())
'25\u200fFriday'

I haven't looked at issue 10653 enough to understand if it's still a problem with the new Visual C++. Maybe it is: I only tested with my default US locale.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 03:39:31 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Sep 2015 01:39:31 +0000
Subject: [issue25194] Register of Financial Interests for core contributors
In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za>
Message-ID: <1443145171.76.0.726922956966.issue25194@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Please make it clear that any listings are optional.  No core developer is required to write anything about themselves that they don't want to make public.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 03:58:46 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Sep 2015 01:58:46 +0000
Subject: [issue7949] IDLE: problems with dark GTK or KDE color schemes
In-Reply-To: <1266372113.11.0.0197701157976.issue7949@psf.upfronthosting.co.za>
Message-ID: <1443146326.13.0.321646371244.issue7949@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Problem as I understand it: various tk widgets and Idle popups and dialogs mix, for instance, a hard-coded background (white) with a sometimes incompatible (no or low contrast) system-default foreground, which is also white when the system background is black.  Hence the sad screenshot for #16984: https://bugs.python.org/file28755/snapshot-idle.png.

Some of this may be tk's fault for not anticipating reversed graphics screen, some may be Idle's (I doubt tkinter gets involved).  In any case, a solution is for Idle to set the colors for *every* widget it creates.  The colors could be fixed in particular cases, but we could instead use one of the currently 13 user settings*.  #24820 is about adding a light on dark theme to Idle.  When we start using ttk widgets (within a month), I believe this will be possible by setting an explicit default color pair for each class.

* I am thinking I might try using the new dark theme on my white-background system, but I cannot know that I would want all the dialogs to use it.  We might want to allow separate tagged text themes (what the current highlights are for) and widget themes.  This will take some experimentation.

----------
assignee:  -> terry.reedy
nosy: +markroseman
stage:  -> needs patch
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 04:15:11 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Sep 2015 02:15:11 +0000
Subject: [issue24820] IDLE themes for light on dark
In-Reply-To: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>
Message-ID: <1443147311.09.0.265223243816.issue24820@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I re-read #7949 and read the problem as mixing a hard-coded (by tk or Idle is not clear) background (white) with a system-default foreground, which is also white when the system background is black.  Hence the screenshot in duplicate #16984.  In any case, that issue is complementary to this one, about user-configured tagged text colors.

Parsing an existing format is an interesting idea.  Most of the variations seem pointless, but I like the cobalt one as a basis for a dark theme.  I plan to improve it, using current Idle (Classic and New seem the same, so why two?), with my changes.  I will upload when I have something I like.

The change I made is to color the backgrounds of 'shell', 'stdout', and 'stderr' light yellow, light blue, and light red.  These changes work so well for me, at least, that I have thought of adding them to an 'Idle New' that is really new and different.  But transitions are hard.  The main other thing I don't like in 'Idle ???' is the orange for keywords, as too 'different' from the purple and blue of builtings and defined. But green is semi standard for strings and that does not leave room for three colors on the blue side.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 04:48:34 2015
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 25 Sep 2015 02:48:34 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1443149314.22.0.14491571052.issue18967@psf.upfronthosting.co.za>


Larry Hastings added the comment:

> [...] commit messages are for other developers, which news entries are
> ultimately for users.  Some developers want (insist on) the freedom to
> make the two different, with different details.

That's easy enough to accommodate.  I updated "MergeNEWS" with this feature.  Well, a similar feature:

The file you edit at checkin time starts with "Issue #:".  You fill that out and that becomes your Misc/NEWS item, and the top of your checkin comment.

There's also a commented-out line of dashes below there.  Anything you put there is appended to *the checkin comment only*.

So, you get the user summary as per Misc/NEWS at the top, then you can elaborate in all the technical and flowery language you like.  Also, each section is optional (though obviously you have to fill out *one* of them).

It'd be easy to make the two comments completely separate.  I just figured, the Misc/NEWS entry is presumably a nice high-level summary of the solution, why not leave that there and save the developer from having to summarize it twice.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 04:53:04 2015
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 25 Sep 2015 02:53:04 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1443149584.24.0.267321216447.issue9566@psf.upfronthosting.co.za>


Changes by Brian Curtin :


----------
nosy:  -brian.curtin

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 05:14:40 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 25 Sep 2015 03:14:40 +0000
Subject: [issue25225] Idle doc: redo Syntax Colors section
In-Reply-To: <1443049901.66.0.834655906435.issue25225@psf.upfronthosting.co.za>
Message-ID: <20150925031435.82652.80118@psf.io>


Roundup Robot added the comment:

New changeset 2f6aa20c05b3 by Terry Jan Reedy in branch '2.7':
Issue #25225: Condense and rewrite Idle doc section on text colors.
https://hg.python.org/cpython/rev/2f6aa20c05b3

New changeset f5502ff7ae2d by Terry Jan Reedy in branch '3.4':
Issue #25225: Condense and rewrite Idle doc section on text colors.
https://hg.python.org/cpython/rev/f5502ff7ae2d

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 05:15:07 2015
From: report at bugs.python.org (eryksun)
Date: Fri, 25 Sep 2015 03:15:07 +0000
Subject: [issue4918] Windows installer created with Python X.Y does not work
 with Python X.Y+1
In-Reply-To: <1231738106.14.0.212121765754.issue4918@psf.upfronthosting.co.za>
Message-ID: <1443150907.74.0.253824439464.issue4918@psf.upfronthosting.co.za>


eryksun added the comment:

There haven't been any fundamental changes to bdist_wininst in years, and bdist_wheel has mostly replaced it nowadays. 

I'm fairly certain this issue was fixed by Mark Hammond's fix for issue 4566. Just to be certain, I updated the code to use print as a function and used 3.4 to build "Simple-Python 3.4.3.win-amd64.exe". I installed this to 3.5, and the post-install script ran successfully. So I'm re-tagging this issue for versions 2.7 and 3.2 and closing it as a duplicate.

In summary, Python built with VS 2008 needs an activation context for the CRT assembly, which is required to load msvcr90.dll. Normally this comes from the application executable, such as python.exe. But when Python is embedded, it may be the case that the application lacks the required activation context (e.g. a bdist_wininst installer created by Python 2.5). Mark Hammond's fix works around this problem by saving and reusing the activation context from when the Python DLL was loaded. This activation context is based on the DLL's resource #2 manifest, which includes the CRT assembly.

One remaining problem for embedding Python 2.7 is accessing msvcr90.dll via ctypes. But it's ctypes! Just dynamically create an activation context.

----------
nosy: +eryksun
resolution:  -> duplicate
status: open -> closed
superseder:  -> 2.6.1 breaks many applications that embed Python on Windows
versions: +Python 2.7, Python 3.2 -Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 05:19:45 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 25 Sep 2015 03:19:45 +0000
Subject: [issue25225] Idle doc: redo Syntax Colors section
In-Reply-To: <1443049901.66.0.834655906435.issue25225@psf.upfronthosting.co.za>
Message-ID: <20150925031941.115327.17876@psf.io>


Roundup Robot added the comment:

New changeset 36095aa6dd5e by Terry Jan Reedy in branch '2.7':
Issue #25225: add revised .html.
https://hg.python.org/cpython/rev/36095aa6dd5e

New changeset a43d79b2434c by Terry Jan Reedy in branch '3.4':
Issue #25225: add revised .html.
https://hg.python.org/cpython/rev/a43d79b2434c

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 05:29:04 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Sep 2015 03:29:04 +0000
Subject: [issue25225] Idle doc: redo Syntax Colors section
In-Reply-To: <1443049901.66.0.834655906435.issue25225@psf.upfronthosting.co.za>
Message-ID: <1443151744.79.0.502032941739.issue25225@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I decided to keep a further condensed subsection.  I think there is a bit of extra info, and we may need or want to say more after other changes, such as for #7949, and the addition of a dark theme. The reference manual documents our current promises.

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 05:41:56 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 25 Sep 2015 03:41:56 +0000
Subject: [issue25210] Special-case NoneType() in do_richcompare()
In-Reply-To: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za>
Message-ID: <1443152516.81.0.465684616126.issue25210@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

TypeError: '<' not supported between instances of 'int' and 'NoneType'

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 05:52:20 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 25 Sep 2015 03:52:20 +0000
Subject: [issue22413] Bizarre StringIO(newline="\r\n") translation
In-Reply-To: <1410750243.44.0.979805676788.issue22413@psf.upfronthosting.co.za>
Message-ID: <1443153140.08.0.651382517064.issue22413@psf.upfronthosting.co.za>


Martin Panter added the comment:

According to  Serhiy and Antoine both seem to agree this behaviour is a bug. The reason why newline="\r\n" and newline="\r" cause these funny translations is that __init__() internally passes the initial buffer value through write(). So I propose to set the buffer directly without using write().

However, doing this would have another effect. In the C implementation, write() also does universal newline decoding. The Python implementation had similar decoding added in getvalue() to compensate (Issue 20435). I propose to revert the getvalue() decoding, and to move the universal decoding from write() to read() in the C implementation.

I anticipate the combined effect of these changes would be:

1. StringIO("\n", newline="\r\n") no longer encodes the newline to CRLF in the internal buffer, so reading or getvalue() will return "\n" unencoded

2. StringIO("\r\n", newline=None).getvalue() returns "\r\n" undecoded, rather than universal decoding changing it to "\n"

3. s = StringIO(newline=None); s.write("\r\n"); s.getvalue() also returns "\r\n" undecoded. It is undocumented, but StringIO intentionally does not encode to os.linesep (yet another bug IMO).

4. StringIO.newlines would only get updated during reading, rather than during construction and writing, since newline decoding will only take place during reading.

There is another bug where the universal newline decoding does not anticipate split CRLF sequences. This would hopefully be fixed at the same time.

>>> s = io.StringIO(newline=None)
>>> s.write("\r\n" "\r")
3
>>> s.write("\n")  # Complete second CRLF
1
>>> s.getvalue()  # Should be "\r\n\r\n", at least when os.linesep == "\n"
'\n\n\n'

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 06:07:25 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Sep 2015 04:07:25 +0000
Subject: [issue25198] Idle: improve idle.html help viewer.
In-Reply-To: <1442794067.12.0.0580996406415.issue25198@psf.upfronthosting.co.za>
Message-ID: <1443154045.7.0.614948145019.issue25198@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Another minor glitch: in a browser, each press of up or down arrow, when there is no cursor (after clicking outside of an entry box like this one), moves text up or down.  (3 lines for me in FF, even though wheel click moved more) In an editor, each press moves the *cursor* up or down one line, and text only moves when the cursor is at the top or bottom of the window.  The read-only text has an invisible cursor, which one must invisibly move to top or bottom before anything happens.

Some of the code with #17535 might help, but not looking now.

Another enhancement: use user set Initial Window size.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 06:40:11 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 25 Sep 2015 04:40:11 +0000
Subject: [issue25194] Register of Financial Interests for core contributors
In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za>
Message-ID: <1443156011.58.0.0590509270186.issue25194@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I think the change in tone that MAL suggested will go a long way towards clarifying the opt-in nature of the idea - my initial draft took too much of its phrasing from contexts where disclosure is required rather than optional.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 06:50:08 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 25 Sep 2015 04:50:08 +0000
Subject: [issue25198] Idle: improve idle.html help viewer.
In-Reply-To: <1442794067.12.0.0580996406415.issue25198@psf.upfronthosting.co.za>
Message-ID: <20150925045004.115080.66005@psf.io>


Roundup Robot added the comment:

New changeset c1eccae07977 by Terry Jan Reedy in branch '2.7':
Issue #25198: Idle doc viewer now uses user width and height setting.
https://hg.python.org/cpython/rev/c1eccae07977

New changeset 1c119da20663 by Terry Jan Reedy in branch '3.4':
Issue #25198: Idle doc viewer now uses user width and height setting.
https://hg.python.org/cpython/rev/1c119da20663

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 06:56:23 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Sep 2015 04:56:23 +0000
Subject: [issue25198] Idle: improve idle.html help viewer.
In-Reply-To: <1442794067.12.0.0580996406415.issue25198@psf.upfronthosting.co.za>
Message-ID: <1443156983.61.0.394621011876.issue25198@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Had to adjust number of line by 3/4 because average 4/3 as high as in editor due to taller header lines and extra interline spacing.  Net result for me, using 12 pitch in editor also, is box size within 5%.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 07:56:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Sep 2015 05:56:23 +0000
Subject: [issue22413] Bizarre StringIO(newline="\r\n") translation
In-Reply-To: <1410750243.44.0.979805676788.issue22413@psf.upfronthosting.co.za>
Message-ID: <1443160583.25.0.505003445911.issue22413@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I agree with you, but I think that Antoine disagrees.

My half-baked patch for issue20435 did a half of the work. It initialized the buffer directly in __init__. Here is the rebased version. There is a difference between C and Python implementations for universal newlines and test_newline_none fails.

----------
keywords: +patch
Added file: http://bugs.python.org/file40571/stringio_newline_2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 09:58:59 2015
From: report at bugs.python.org (Wolfgang Langner)
Date: Fri, 25 Sep 2015 07:58:59 +0000
Subject: [issue25223] Statically or dynamically linked to the VC++runtime ? or
 how Python install fails on Vista despite the VC redist packages -
 api-ms-win-crt-runtime-l1-1-0.dll
In-Reply-To: <1443045136.66.0.653550157365.issue25223@psf.upfronthosting.co.za>
Message-ID: <1443167939.47.0.575284651565.issue25223@psf.upfronthosting.co.za>


Wolfgang Langner added the comment:

As a note, I had problems installing Python 3.5 on a computer at work.
The redist package could not install with access denied error.

But the workaround installing the Universal CRT update helped.
After this I was able to install Python 3.5 without problems.

----------
nosy: +tds333

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 10:31:09 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Sep 2015 08:31:09 +0000
Subject: [issue25135] Deques to adopt the standard clearing procedure for
 mutable objects
In-Reply-To: <1442358776.69.0.0875538895398.issue25135@psf.upfronthosting.co.za>
Message-ID: <1443169869.55.0.175504616786.issue25135@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Victor, I was thinking of switching to PyMem_RawMalloc instead of PyMem_Malloc.  The advantages are that there are guaranteed to be no side-effects, the GIL doesn't need to be held, and there is less overhead.  Are there any disadvantage I should know about?

Serhiy, I'm still considering your patch.  I have a strong aversion to putting a big block on the stack and don't like having to do a full block memcpy every time a deque is cleared on deallocation.  If you don't see an actual bug in patch 2, I'm inclined to use that approach (especially since the popping fallback approach will likely never be called in practice).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 11:03:25 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Sep 2015 09:03:25 +0000
Subject: [issue25135] Deques to adopt the standard clearing procedure for
 mutable objects
In-Reply-To: <1442358776.69.0.0875538895398.issue25135@psf.upfronthosting.co.za>
Message-ID: <1443171805.85.0.357110562053.issue25135@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"Victor, I was thinking of switching to PyMem_RawMalloc instead of PyMem_Malloc.  The advantages are that there are guaranteed to be no side-effects, the GIL doesn't need to be held, and there is less overhead.  Are there any disadvantage I should know about?"

For me, PyMem_Malloc() can be faster than PyMem_RawMalloc() because the GIL is held. In practice... both function are very thin wrapper to malloc(), so it's exactly the same :-) In Objects/obmalloc.c, you have:

#define PYRAW_FUNCS _PyMem_RawMalloc, _PyMem_RawCalloc, _PyMem_RawRealloc, _PyMem_RawFree
...
#define PYMEM_FUNCS PYRAW_FUNCS

So PyMem_Malloc() and PyMem_RawMalloc() are *currently* exactly the same.

I'm not sure that you understand what you are trying to do. If you expect better performances, you should try to use PyObject_Malloc() instead, to benefit from the fast Python allocator for small allocations (512 bytes and less).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 11:10:13 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Sep 2015 09:10:13 +0000
Subject: [issue25135] Deques to adopt the standard clearing procedure for
 mutable objects
In-Reply-To: <1442358776.69.0.0875538895398.issue25135@psf.upfronthosting.co.za>
Message-ID: <1443172213.27.0.53505427053.issue25135@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch that copies only used part of the block.

I don't see an actual bug in patch 2 besides that it fallbacks to current popping behavior.

----------
Added file: http://bugs.python.org/file40572/deque_nonreentrant_clear4.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 13:53:57 2015
From: report at bugs.python.org (=?utf-8?q?Ond=C5=99ej_Profant?=)
Date: Fri, 25 Sep 2015 11:53:57 +0000
Subject: [issue25231] Argparse module and escape sequence (special symbols) in
 argument value
Message-ID: <1443182037.79.0.167999689484.issue25231@psf.upfronthosting.co.za>


New submission from Ond?ej Profant:

I am trying to put tabulator '\t' into argument value. 

Minimal working example:


#!/usr/bin/env python3

import argparse

def main():
        parser = argparse.ArgumentParser()
        parser.add_argument('-f', '--foo', default="test", help="test")
        args = parser.parse_args()

        print("Argument foo is: " + args.foo + "|")
        print("Tabulator usage: |\t|")

if __name__ == '__main__':
        main()


My attempts:
./test.py -f \t
./test.py -f '\t'
./test.py -f "\t"

But this is not functional. Is there way to put special characters into argument?
~

----------
components: Library (Lib)
messages: 251580
nosy: Ond?ej Profant
priority: normal
severity: normal
status: open
title: Argparse module and escape sequence (special symbols) in argument value
type: behavior
versions: Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 14:20:04 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 25 Sep 2015 12:20:04 +0000
Subject: [issue25231] Argparse module and escape sequence (special symbols) in
 argument value
In-Reply-To: <1443182037.79.0.167999689484.issue25231@psf.upfronthosting.co.za>
Message-ID: <1443183604.16.0.210278888324.issue25231@psf.upfronthosting.co.za>


Martin Panter added the comment:

As far as I know ?argparse? takes arguments straight from the command line without interpreting any escape sequences. Perhaps you should look up how to pass a literal tab on the command line, but this is nothing specific to do with Python. E.g. in the Bash shell the following might work:

$ echo $'a\tb'  # Bash specific syntax
a	b
$ echo "$(printf 'a\tb')"  # Any Posix shell
a	b
$ echo "a	b"  # Ctrl+V, Tab for literal tab to bypass completion
a	b

----------
nosy: +martin.panter
resolution:  -> third party
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 17:09:01 2015
From: report at bugs.python.org (acx01bc)
Date: Fri, 25 Sep 2015 15:09:01 +0000
Subject: [issue25223] Statically or dynamically linked to the VC++runtime ? or
 how Python install fails on Vista despite the VC redist packages -
 api-ms-win-crt-runtime-l1-1-0.dll
In-Reply-To: <1443045136.66.0.653550157365.issue25223@psf.upfronthosting.co.za>
Message-ID: <1443193741.05.0.867278370028.issue25223@psf.upfronthosting.co.za>


acx01bc added the comment:

@steve.dower : the vc_redist packages doesn't list the files it installs, I'm not sure of the names of the files, but who cares, please look at my screenshot of dependency walker, it shows how different versions of Python win32 releases that I downloaded on python.org (3.5.0, 3.4.3,3.3.x) used different vc-runtime settings, and how some of them don't work on Vista.

@Wolfgang Langner : "this update doesn't apply to you system" :-)

So what I'm saying is : please be careful with the compiler options if you want you executables to be compatible with vista/7/8/10

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 17:09:14 2015
From: report at bugs.python.org (acx01bc)
Date: Fri, 25 Sep 2015 15:09:14 +0000
Subject: [issue25223] Statically or dynamically linked to the VC++runtime ? or
 how Python install fails on Vista despite the VC redist packages -
 api-ms-win-crt-runtime-l1-1-0.dll
In-Reply-To: <1443045136.66.0.653550157365.issue25223@psf.upfronthosting.co.za>
Message-ID: <1443193754.2.0.249568919438.issue25223@psf.upfronthosting.co.za>


Changes by acx01bc :


----------
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 17:24:13 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 25 Sep 2015 15:24:13 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1443194653.79.0.842364150227.issue18967@psf.upfronthosting.co.za>


R. David Murray added the comment:

Because the two summaries should be *different* in most cases.  The first line of the checkin should ideally be a single sentence of less than 80 characters, while the NEWS item will almost always be longer.  The NEWS item should be a complete summary, while the first checkin line is a 'summary in context' (ie: it can assume the reader knows the files that were changed, since log -v will show you that).  This obviously requires that the succeeding paragraphs expand on that minimal summary (in most cases) in a way that doesn't look like a NEWS entry.

Now, this is obviously my preferred style and others may have different styles and/or disagree, but I'd like that style to be supported.

Note also that a big part of putting the NEWS entries in the tracker is so that they can be *edited*.  Populating them initially from the checkin message is OK, but I predict that the actual workflow will be to create the NEWS entry in the tracker as part of getting the patch to the 'commit ready' point, which means that having a tool that pre-populates the commit message from the tracker NEWS entry will probably be more useful to most people.  (And yeah, I'm sure that means a lot of commits will just have the NEWS entry as the commit message, which will make me sad, but oh well :)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 17:26:40 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 25 Sep 2015 15:26:40 +0000
Subject: [issue24657] CGIHTTPServer module discard continuous '/' letters from
 params given by GET method.
In-Reply-To: <1437187776.37.0.855244973055.issue24657@psf.upfronthosting.co.za>
Message-ID: <1443194800.2.0.474275713254.issue24657@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

The path with query component are unquoted entirely and then pass into
_url_collapse_path.
I think this behaviour is wrong and according to rfc3875 query component
should be left encoded in QUERY_STRING.
This patch seems to solve the problem. It passes the tests and with
martin's script, it gets:

('QUERY_STRING', 'k=aa%2F%2Fbb&//q//p//=//a//b//')

has the same behaviour with apache.

----------
keywords: +patch
Added file: http://bugs.python.org/file40573/cgihandler.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 17:26:53 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 25 Sep 2015 15:26:53 +0000
Subject: [issue25210] Special-case NoneType() in do_richcompare()
In-Reply-To: <1442900927.33.0.98928488186.issue25210@psf.upfronthosting.co.za>
Message-ID: <1443194813.43.0.172247841083.issue25210@psf.upfronthosting.co.za>


R. David Murray added the comment:

As I said to Ezio on irc, I like his formulation.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 17:44:41 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 25 Sep 2015 15:44:41 +0000
Subject: [issue25232] CGIRequestHandler behave incorrectly with query
 component consisting mutliple ?
Message-ID: <1443195881.69.0.030953923686.issue25232@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

According to rfc3986, section 3.4:

 The query component is indicated by the first question
 mark ("?") character and terminated by a number sign ("#") character
 or by the end of the URI.

 The characters slash ("/") and question mark ("?") may represent data
 within the query component.

But for CGIRequestHandler, it uses the content after the last ? as
query component. For uri http://localhost:8000/cgi-bin/test.py?a=b?c=d,
the QUERY_STRING is c=d.

----------
files: multiple?.diff
keywords: patch
messages: 251586
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: CGIRequestHandler behave incorrectly with query component consisting mutliple ?
Added file: http://bugs.python.org/file40574/multiple?.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 17:45:15 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 25 Sep 2015 15:45:15 +0000
Subject: [issue25232] CGIRequestHandler behave incorrectly with query
 component consisting mutliple ?
In-Reply-To: <1443195881.69.0.030953923686.issue25232@psf.upfronthosting.co.za>
Message-ID: <1443195915.83.0.0866615698082.issue25232@psf.upfronthosting.co.za>


Changes by Xiang Zhang <18518281186 at 126.com>:


----------
type:  -> behavior
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 17:49:20 2015
From: report at bugs.python.org (Steve Dower)
Date: Fri, 25 Sep 2015 15:49:20 +0000
Subject: [issue25223] Statically or dynamically linked to the VC++runtime ? or
 how Python install fails on Vista despite the VC redist packages -
 api-ms-win-crt-runtime-l1-1-0.dll
In-Reply-To: <1443045136.66.0.653550157365.issue25223@psf.upfronthosting.co.za>
Message-ID: <1443196160.71.0.381023209361.issue25223@psf.upfronthosting.co.za>


Steve Dower added the comment:

In your original post you refer to the "famous api-ms-win-crt-runtime-l1-1-0.dll problem" - I am not aware of this problem, so you will need to provide more context on what is actually not working for you.

Dependency Walker doesn't know how to resolve those DLLs on any platform - Win10 looks exactly the same. A limitation of a diagnostic tool that hasn't been updated in years does not qualify as something "not working".

But since you've closed the issue I have to assume that it isn't really an issue.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 18:06:18 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 25 Sep 2015 16:06:18 +0000
Subject: [issue24820] IDLE themes for light on dark
In-Reply-To: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>
Message-ID: <1443197178.89.0.812827433978.issue24820@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Sounds good. I agree picking a few and tweaking them would be a good way forward (and incidentally, the 'Cobalt' theme is the one I use in my regular editor!)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 18:45:17 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 25 Sep 2015 16:45:17 +0000
Subject: [issue25230] Unix datagram sockets not supported
In-Reply-To: <1443132861.89.0.286854164453.issue25230@psf.upfronthosting.co.za>
Message-ID: <1443199517.58.0.00823864913258.issue25230@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

See https://github.com/python/asyncio/pull/267. Can you patch that in and see if you can make it work?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 19:27:20 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 25 Sep 2015 17:27:20 +0000
Subject: [issue25233] AssertionError from asyncio Queue get
Message-ID: <1443202040.86.0.857467079978.issue25233@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

See https://github.com/python/asyncio/issues/265 and https://github.com/python/asyncio/issues/268. This looks like an important regression and we should fix it before 3.5.1 goes out.

The symptom is "AssertionError: queue non-empty, why are getters waiting?" from Queue.get or Queue.get_nowait. The first issue discusses the cause and a possible hack to fix it.

----------
components: asyncio
keywords: 3.5regression
messages: 251590
nosy: gvanrossum, haypo, yselivanov
priority: release blocker
severity: normal
status: open
title: AssertionError from asyncio Queue get
type: behavior
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 20:12:02 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 25 Sep 2015 18:12:02 +0000
Subject: [issue25233] AssertionError from asyncio Queue get
In-Reply-To: <1443202040.86.0.857467079978.issue25233@psf.upfronthosting.co.za>
Message-ID: <1443204722.73.0.459268010499.issue25233@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> This looks like an important regression and we should fix it before 3.5.1 goes out.

I agree.  Any ETA on 3.5.1?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 20:15:10 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Sep 2015 18:15:10 +0000
Subject: [issue25135] Deques to adopt the standard clearing procedure for
 mutable objects
In-Reply-To: <1442358776.69.0.0875538895398.issue25135@psf.upfronthosting.co.za>
Message-ID: <1443204910.97.0.772289076274.issue25135@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> I'm not sure that you understand what you are trying to do.

The goal is to avoid possible re-entrancy both now and in the future.  Since PyMem_RawMalloc is thread-safe and doesn't require the GIL to be held, it is guaranteed that there won't be a callback into regular Python that could mutate any of the data structures.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 20:25:05 2015
From: report at bugs.python.org (eryksun)
Date: Fri, 25 Sep 2015 18:25:05 +0000
Subject: [issue25223] Statically or dynamically linked to the VC++runtime ? or
 how Python install fails on Vista despite the VC redist packages -
 api-ms-win-crt-runtime-l1-1-0.dll
In-Reply-To: <1443045136.66.0.653550157365.issue25223@psf.upfronthosting.co.za>
Message-ID: <1443205505.42.0.387342261128.issue25223@psf.upfronthosting.co.za>


eryksun added the comment:

> this update doesn't apply to you system

Was that Windows6.0-KB2999226-x86.msu? Open a command prompt and enter the following:

    wmic os get Version, OSArchitecture

Windows Vista SP 2 is version 6.0.6002, and the OS architecture should be 32-bit.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 20:38:58 2015
From: report at bugs.python.org (eryksun)
Date: Fri, 25 Sep 2015 18:38:58 +0000
Subject: [issue25223] Statically or dynamically linked to the VC++runtime ? or
 how Python install fails on Vista despite the VC redist packages -
 api-ms-win-crt-runtime-l1-1-0.dll
In-Reply-To: <1443045136.66.0.653550157365.issue25223@psf.upfronthosting.co.za>
Message-ID: <1443206338.99.0.909115974531.issue25223@psf.upfronthosting.co.za>


eryksun added the comment:

> Dependency Walker doesn't know how to resolve those DLLs on 
> any platform - Win10 looks exactly the same. 

On older systems the api-ms-win-crt-* DLLs should be physically installed in System32, so Dependency Walker should find them if they exist. For example, on a Windows 7 box:

    >dir /b C:\Windows\System32\api-ms-win-crt*.dll
    api-ms-win-crt-conio-l1-1-0.dll
    api-ms-win-crt-convert-l1-1-0.dll
    api-ms-win-crt-environment-l1-1-0.dll
    api-ms-win-crt-filesystem-l1-1-0.dll
    api-ms-win-crt-heap-l1-1-0.dll
    api-ms-win-crt-locale-l1-1-0.dll
    api-ms-win-crt-math-l1-1-0.dll
    api-ms-win-crt-multibyte-l1-1-0.dll
    api-ms-win-crt-private-l1-1-0.dll
    api-ms-win-crt-process-l1-1-0.dll
    api-ms-win-crt-runtime-l1-1-0.dll
    api-ms-win-crt-stdio-l1-1-0.dll
    api-ms-win-crt-string-l1-1-0.dll
    api-ms-win-crt-time-l1-1-0.dll
    api-ms-win-crt-utility-l1-1-0.dll

In Windows 10 these DLLs are an API Set contract; they don't actually exist in the filesystem. For example, on Windows 10 GetModuleHandle for all of these DLLs returns a handle to ucrtbase.dll, whereas on Windows 7 each is a uniquely loaded module.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 20:51:34 2015
From: report at bugs.python.org (Tim Peters)
Date: Fri, 25 Sep 2015 18:51:34 +0000
Subject: [issue25135] Deques to adopt the standard clearing procedure for
 mutable objects
In-Reply-To: <1442358776.69.0.0875538895398.issue25135@psf.upfronthosting.co.za>
Message-ID: <1443207094.69.0.554253945394.issue25135@psf.upfronthosting.co.za>


Tim Peters added the comment:

The only way to be certain you're never going to face re-entrancy issues in the future is to call malloc() directly - and hope nobody redefines that too with some goofy macro ;-)

In the meantime, stick to PyMem_Malloc().  That's the intended way for code holding the GIL to do lowest-level memory allocation.  Uses of PyMem_RawMalloc() should be extremely rare, typically only in contexts where Python internals _know_ the GIL isn't being held, and can't reasonably try to acquire the GIL.  It's already being used in a few contexts where it probably shouldn't be, and each such use needlessly complicates future changes.

If PyMem_Malloc() does grow re-entrancy issues in the future, deques will be the least of our problems.  I'd strongly oppose it before then.  It's _intended_ to be as low level as possible (it was created to begin with just to worm around cross-platform insanity when called with a 0 argument).

----------
nosy: +tim.peters

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 21:30:56 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Sep 2015 19:30:56 +0000
Subject: [issue25135] Deques to adopt the standard clearing procedure for
 mutable objects
In-Reply-To: <1442358776.69.0.0875538895398.issue25135@psf.upfronthosting.co.za>
Message-ID: <1443209456.97.0.870181924942.issue25135@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks Timmy!

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 21:41:19 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 25 Sep 2015 19:41:19 +0000
Subject: [issue25234] test_einter.test_os_open hangs under Xcode 7
Message-ID: <1443210079.4.0.780575467942.issue25234@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Specifically:
Apple LLVM version 7.0.0 (clang-700.0.72)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

I'm assuming this is a Mac issue since none of the buildbots are having a similar issue.

----------
components: Macintosh
messages: 251597
nosy: brett.cannon, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: test_einter.test_os_open hangs under Xcode 7
type: behavior
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 21:43:09 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Fri, 25 Sep 2015 19:43:09 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1443210189.97.0.765966570168.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

Still battling this bus error issue.  Recompiling gdb --with-python did not help; I still cannot get any useful info out of it. I suspect it may be due to this error:

setpgrp failed in child: No such process

but I'm not sure.

At this point I'm going to try downloading the Google-patched version...hopefully it is patched such that the setpgrp bug is resolved.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 21:43:29 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 25 Sep 2015 19:43:29 +0000
Subject: [issue25188] regrtest.py improvement for Profile Guided Optimization
 builds
In-Reply-To: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za>
Message-ID: <1443210209.51.0.97498400596.issue25188@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Here is a tweaked 3.6 patch so that --pgo doesn't even emit the failure count so you really can't tell what is going on unless some error info from the test spews out on to the shell (which I can't seem to stop since 2>/dev/null causes a test failure).

----------
Added file: http://bugs.python.org/file40575/issue25188.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 21:47:28 2015
From: report at bugs.python.org (Kai Groner)
Date: Fri, 25 Sep 2015 19:47:28 +0000
Subject: [issue25235] EmailMessage.add_attachment() creates parts with
 spurious MIME-Version header.
Message-ID: <1443210448.87.0.407287169878.issue25235@psf.upfronthosting.co.za>


New submission from Kai Groner:

Because MIMEPart.add_attachment() creates parts using type(self), EmailMessage.add_attachment() creates parts of type EmailMessage.  This results in a MIME-Version header being added to parts where it isn't needed.

https://tools.ietf.org/html/rfc2045#section-4

----------
components: email
files: test_add_attachment_does_not_add_MIME_Version_in_attachment.patch
keywords: patch
messages: 251600
nosy: barry, groner, r.david.murray
priority: normal
severity: normal
status: open
title: EmailMessage.add_attachment() creates parts with spurious MIME-Version header.
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file40576/test_add_attachment_does_not_add_MIME_Version_in_attachment.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 22:05:04 2015
From: report at bugs.python.org (Kai Groner)
Date: Fri, 25 Sep 2015 20:05:04 +0000
Subject: [issue25235] EmailMessage.add_attachment() creates parts with
 spurious MIME-Version header.
In-Reply-To: <1443210448.87.0.407287169878.issue25235@psf.upfronthosting.co.za>
Message-ID: <1443211504.77.0.356394470374.issue25235@psf.upfronthosting.co.za>


Kai Groner added the comment:

Relatedly EmailMessage.make_mixed(), etc don't set MIME-Version on the multipart (it is only set on the part).  Additional tests attached.

----------
Added file: http://bugs.python.org/file40577/test_add_attachment_does_not_add_MIME_Version_in_attachment.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 22:05:21 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 25 Sep 2015 20:05:21 +0000
Subject: [issue25186] Don't duplicate _verbose_message in importlib._bootstrap
 and _bootstrap_external
In-Reply-To: <1442703732.01.0.764614399851.issue25186@psf.upfronthosting.co.za>
Message-ID: <20150925200518.11688.86917@psf.io>


Roundup Robot added the comment:

New changeset 1266e98fd04c by Brett Cannon in branch 'default':
Issue #25186: Remove duplicated function from importlib._bootstrap_external
https://hg.python.org/cpython/rev/1266e98fd04c

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 22:05:38 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 25 Sep 2015 20:05:38 +0000
Subject: [issue25186] Don't duplicate _verbose_message in importlib._bootstrap
 and _bootstrap_external
In-Reply-To: <1442703732.01.0.764614399851.issue25186@psf.upfronthosting.co.za>
Message-ID: <1443211538.62.0.378001841678.issue25186@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 22:07:39 2015
From: report at bugs.python.org (Kai Groner)
Date: Fri, 25 Sep 2015 20:07:39 +0000
Subject: [issue25235] EmailMessage.add_attachment() creates parts with
 spurious MIME-Version header.
In-Reply-To: <1443210448.87.0.407287169878.issue25235@psf.upfronthosting.co.za>
Message-ID: <1443211659.33.0.966091590235.issue25235@psf.upfronthosting.co.za>


Changes by Kai Groner :


Added file: http://bugs.python.org/file40578/test_MIME_Version.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 22:10:38 2015
From: report at bugs.python.org (Brian O'Neill)
Date: Fri, 25 Sep 2015 20:10:38 +0000
Subject: [issue25236] str.maketrans wrong description for optional 3rd
 parameter
Message-ID: <1443211838.26.0.822902603996.issue25236@psf.upfronthosting.co.za>


New submission from Brian O'Neill:

The doc says "If there is a third argument, it must be a string, whose characters will be mapped to None in the result." The characters of the optional third argument get mapped to '', of course, not to None.

----------
assignee: docs at python
components: Documentation
messages: 251603
nosy: BrianO, docs at python
priority: normal
severity: normal
status: open
title: str.maketrans wrong description for optional 3rd parameter
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 22:10:40 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Sep 2015 20:10:40 +0000
Subject: [issue25233] AssertionError from asyncio Queue get
In-Reply-To: <1443204722.73.0.459268010499.issue25233@psf.upfronthosting.co.za>
Message-ID: 


STINNER Victor added the comment:

2015-09-25 20:12 GMT+02:00 Yury Selivanov :
>> This looks like an important regression and we should fix it before 3.5.1 goes out.
>
> I agree.  Any ETA on 3.5.1?

See https://mail.python.org/pipermail/python-dev/2015-September/141705.html

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 22:12:34 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 25 Sep 2015 20:12:34 +0000
Subject: [issue25154] Drop the pyvenv script
In-Reply-To: <1442514921.37.0.255858283829.issue25154@psf.upfronthosting.co.za>
Message-ID: <1443211954.49.0.754200435176.issue25154@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Here is a patch that adds a message to stderr about the deprecation.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file40579/issue25154.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 22:14:48 2015
From: report at bugs.python.org (Brian O'Neill)
Date: Fri, 25 Sep 2015 20:14:48 +0000
Subject: [issue25236] str.maketrans wrong description for optional 3rd
 parameter
In-Reply-To: <1443211838.26.0.822902603996.issue25236@psf.upfronthosting.co.za>
Message-ID: <1443212088.55.0.980422900611.issue25236@psf.upfronthosting.co.za>


Brian O'Neill added the comment:

Closed as this is a actually true of maketrans.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 22:19:52 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Sep 2015 20:19:52 +0000
Subject: [issue24820] IDLE themes for light on dark
In-Reply-To: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>
Message-ID: <1443212392.08.0.296083519684.issue24820@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

For me, Idle comes with one light theme, under 2 names. I don't know what happens on Mac.  Let us add one dark theme as Idle Dark, before 3.4.4 if possible.

We can later consider whether to add more light and dark built-in themes. But I think more important would be to add the ability to change at once the background of all elements that use the default (normal) background. I believe you have mentioned that one might want to change white to an off-white.  Cobalt is an off-black, but someone might prefer black black, or the slightly bluer background of Windows Power Shell.  We should not have multiple themes just for background variations.

----------
versions: +Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 22:21:16 2015
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 25 Sep 2015 20:21:16 +0000
Subject: [issue25236] str.maketrans wrong description for optional 3rd
 parameter
In-Reply-To: <1443211838.26.0.822902603996.issue25236@psf.upfronthosting.co.za>
Message-ID: <1443212476.77.0.401056812817.issue25236@psf.upfronthosting.co.za>


Changes by Zachary Ware :


----------
stage:  -> resolved

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 22:26:52 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Sep 2015 20:26:52 +0000
Subject: [issue17781] optimize compilation options
In-Reply-To: <1366224008.41.0.60101315886.issue17781@psf.upfronthosting.co.za>
Message-ID: <1443212812.82.0.637614686485.issue17781@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

#24915 is about adding pgo and has a slew of patches.

----------
nosy: +terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 22:52:46 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 25 Sep 2015 20:52:46 +0000
Subject: [issue25099] test_compileall fails when run by unprivileged user on
 installed Python
In-Reply-To: <1442205173.06.0.618332067063.issue25099@psf.upfronthosting.co.za>
Message-ID: <1443214366.96.0.627141066271.issue25099@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Here is a patch that should work. Can someone who has had the problem test it? It works in my limited testing but I want to make sure this solves it before I commit it.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file40580/issue25099.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 22:53:54 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 25 Sep 2015 20:53:54 +0000
Subject: [issue21264] test_compileall fails to build in the installed location
In-Reply-To: <1397674780.07.0.532661626869.issue21264@psf.upfronthosting.co.za>
Message-ID: <1443214434.31.0.914771643561.issue21264@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Issue #25099 seems to also be related to a similar issue. A proposed fix can be found over there.

----------
nosy: +brett.cannon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 22:54:01 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 25 Sep 2015 20:54:01 +0000
Subject: [issue21264] test_compileall fails to build in the installed location
In-Reply-To: <1397674780.07.0.532661626869.issue21264@psf.upfronthosting.co.za>
Message-ID: <1443214441.79.0.292187618663.issue21264@psf.upfronthosting.co.za>


Changes by Brett Cannon :


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 22:55:53 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 25 Sep 2015 20:55:53 +0000
Subject: [issue25188] regrtest.py improvement for Profile Guided Optimization
 builds
In-Reply-To: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za>
Message-ID: <1443214553.14.0.271823285742.issue25188@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I should mention I would have committed my patch but test_einter is hanging for me, so if someone else wants to test the patch and verify it works then I can commit it.

----------
assignee:  -> brett.cannon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 23:00:34 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 25 Sep 2015 21:00:34 +0000
Subject: [issue23447] Import fails when doing a circular import involving an
 `import *`
In-Reply-To: <1423679925.56.0.995999383567.issue23447@psf.upfronthosting.co.za>
Message-ID: <1443214834.53.0.517027657977.issue23447@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Just so Steven knows, I'm still thinking about whether I want to accept the patch (and waiting to see if anyone else has an opinion =). I did realize that the patch as it stands does not add the found module as an attribute on the package which is potentially one way the semantics subtly shift with this patch.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 23:06:22 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 25 Sep 2015 21:06:22 +0000
Subject: [issue15347] IDLE - does not close if the debugger was active
In-Reply-To: <1342207963.58.0.539607447258.issue15347@psf.upfronthosting.co.za>
Message-ID: <1443215182.58.0.627007728603.issue15347@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Doing some testing using "-n". Various close/quit scenarios are either disallowed or broken as it turns out. I found that removing the "interacting" check on close improved the matter quite substantially, so that I could quit when the debugger was sitting waiting for input, without hangs etc.

Have attached remove-interacting-debugger.patch (which can be applied on top of fix-mainloop2.patch (from #24455, which includes the changes in fix-nested-mainloop.patch for this bug).

----------
Added file: http://bugs.python.org/file40581/remove-interacting-debugger.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 23:20:04 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 25 Sep 2015 21:20:04 +0000
Subject: [issue24820] IDLE themes for light on dark
In-Reply-To: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>
Message-ID: <1443216004.47.0.860268091804.issue24820@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Ok, do you want to add the dark theme in then?  I'll add some code to the ttk based preferences dialog (for when that gets in) to give the user the option of applying the new background color to all the other elements which had the same original background color.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 23:21:45 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Sep 2015 21:21:45 +0000
Subject: [issue25175] Documentation-Tkinter Clarify module spelling change in
 Python 3 docs
In-Reply-To: <1442656864.32.0.801468754438.issue25175@psf.upfronthosting.co.za>
Message-ID: <1443216105.03.0.56708995312.issue25175@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Martin> Normally the documentation doesn?t mention changes from Python 2

Right: forward notes in 2.7 doc, no backward notes in 3.x doc. The 2.7 doc has near the top "Note: Tkinter has been renamed to tkinter in Python 3. The 2to3 tool will automatically adapt imports when converting your sources to Python 3."  Perhaps this should be expanded to mention the other tkinter imports.

We collectively agreed that adding backward notes in 3.x docs is not needed for beginners who start with 3.x, and would actively confuse them with information most do not need. I think breaking this rule requires agreement of more than the nosy list here: at minimum, Georg Brandl and Serhiy Storchaka, but better pydev.

There are still occasional issues about removing 2.x mentions or, more likely now, revising leftover 2.x examples.  The OP is complaining about an example that was properly revised.  If a new 2.x note were added, someone might come along and remove it.

I agree with
Mark> Does this open a can of worms?
Just for tkinter, there is also "import tkFont" (2.x) versus "import tkinter.font" (3.x) and similar for other stuff in the 'tkinter' package.  Consequently, the proposed note is incomplete.

Carol> the Tkinter project does start with a capital 'T'
I am not aware of a 'Tkinter project' separate from the tkinter module in the stdlib, maintained by various people, though current mostly by Serhiy.  In any case, the Python project starts with 'P' while the python binaries start with 'p'.

The OP simply made a mistake; there is no bug in the 3.x doc.  The tkinter package (unlike idlelib) follows 3.x rules.  I think the issue should have been closed immediately as 'not a bug', and should be so closed now.

----------
nosy: +terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Fri Sep 25 23:45:52 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 25 Sep 2015 21:45:52 +0000
Subject: [issue24781] Improve UX of IDLE Highlighting configuration tab
In-Reply-To: <1438549335.27.0.888518387308.issue24781@psf.upfronthosting.co.za>
Message-ID: <1443217552.14.0.839306742452.issue24781@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Have added the 'apply changes to other elements with same background?' feature in my private copy. To save constantly uploading new versions on every tweak, when we're ready to evaluate/integrate, I'll pass it along.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 00:07:06 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 25 Sep 2015 22:07:06 +0000
Subject: [issue25232] CGIRequestHandler behave incorrectly with query
 component consisting mutliple ?
In-Reply-To: <1443195881.69.0.030953923686.issue25232@psf.upfronthosting.co.za>
Message-ID: <1443218826.39.0.238647921777.issue25232@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the report and patch. Would you be interested in making a new regression test for this bug?

While we are fixing this code, we might as well simplify that whole ?if? block to

[rest, query] = rest.partition("?")

----------
components: +Library (Lib)
nosy: +martin.panter
stage:  -> patch review
versions: +Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 00:10:18 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 25 Sep 2015 22:10:18 +0000
Subject: [issue24657] CGIHTTPServer module discard continuous '/' letters from
 params given by GET method.
In-Reply-To: <1437187776.37.0.855244973055.issue24657@psf.upfronthosting.co.za>
Message-ID: <1443219018.7.0.38626112637.issue24657@psf.upfronthosting.co.za>


Martin Panter added the comment:

It would be good to have a regression test case for this one too.

----------
stage: needs patch -> patch review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 00:13:41 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Sep 2015 22:13:41 +0000
Subject: [issue25194] Register of Financial Interests for core contributors
In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za>
Message-ID: <1443219221.17.0.291526671266.issue25194@psf.upfronthosting.co.za>


Changes by Terry J. Reedy :


----------
nosy: +terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 00:34:59 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Sep 2015 22:34:59 +0000
Subject: [issue24781] Improve UX of IDLE Highlighting configuration tab
In-Reply-To: <1438549335.27.0.888518387308.issue24781@psf.upfronthosting.co.za>
Message-ID: <1443220499.79.0.204374504594.issue24781@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

OK, will ask before review.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 01:08:34 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 25 Sep 2015 23:08:34 +0000
Subject: [issue23329] _ssl cannot be compiled with LibreSSL anymore (on
 OpenBSD 5.5) because of ALPN
In-Reply-To: <1422353692.3.0.280216678648.issue23329@psf.upfronthosting.co.za>
Message-ID: <1443222514.46.0.723098922837.issue23329@psf.upfronthosting.co.za>


Martin Panter added the comment:

I just tested your patch on Arch Linux with the default 3.6 Python branch. The test suite passed happily and all seems to be well:

Python 3.6.0a0 (python_have_alpn.diff qbase qtip tip:eb8ee60ace13, Sep 25 2015, 22:53:15) 
[GCC 5.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
>>> ssl.HAS_ALPN
True
>>> ssl.OPENSSL_VERSION
'OpenSSL 1.0.2d 9 Jul 2015'

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 01:14:13 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Sep 2015 23:14:13 +0000
Subject: [issue24820] IDLE themes for light on dark
In-Reply-To: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>
Message-ID: <1443222853.09.0.382437481333.issue24820@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Here is an Idle Dark theme that is the near-inverse of the standard Idle theme, with foreground colors tweaked just a bit to account for the background switch and its blue tint.  It otherwise retains the current color mapping.  What do you think?

----------
Added file: http://bugs.python.org/file40582/idle-dark.cfg

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 01:23:53 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 25 Sep 2015 23:23:53 +0000
Subject: [issue25171] does not build on OpenBSD with no value defined for
 PY_GETENTROPY
In-Reply-To: <1442618175.28.0.599214895418.issue25171@psf.upfronthosting.co.za>
Message-ID: <1443223433.83.0.686730537843.issue25171@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch looks sensible to me, although I notice the rest of that module tends to prefer the #elif defined(PY_GETENTROPY) style. It looks like this might be introduced with Issue 25003.

----------
nosy: +haypo, martin.panter
stage:  -> patch review
type:  -> compile error

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 01:55:34 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 25 Sep 2015 23:55:34 +0000
Subject: [issue23218] Modernize the IDLE Find/Replace/Find in Files dialogs
In-Reply-To: <1420884051.8.0.416866319984.issue23218@psf.upfronthosting.co.za>
Message-ID: <1443225334.42.0.713835962914.issue23218@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Have attached find-dialogs.patch, which does some cosmetic tweaks to the existing dialogs, as per the previous screenshot. It uses ttk widgets if available, and standard Tk widgets if not.

Relies on the ui.py module (not attached, as it is changing often).

----------
Added file: http://bugs.python.org/file40583/find-dialogs.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 01:59:32 2015
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 25 Sep 2015 23:59:32 +0000
Subject: [issue24820] IDLE themes for light on dark
In-Reply-To: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>
Message-ID: <1443225572.94.0.980412656993.issue24820@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Looks good to me!

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 02:13:03 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 26 Sep 2015 00:13:03 +0000
Subject: [issue25211] Error message formatting errors in int object unit-test
 script
In-Reply-To: <1442908335.62.0.971755787432.issue25211@psf.upfronthosting.co.za>
Message-ID: <20150926001257.31177.86154@psf.io>


Roundup Robot added the comment:

New changeset 697781ff3b49 by Martin Panter in branch '3.4':
Issue #25211: Eliminate lazy error message class by using subTest
https://hg.python.org/cpython/rev/697781ff3b49

New changeset 6e11708dcb3b by Martin Panter in branch '3.5':
Issue #25211: Merge test_long from 3.4 into 3.5
https://hg.python.org/cpython/rev/6e11708dcb3b

New changeset 11ad44d4177f by Martin Panter in branch 'default':
Issue #25211: Merge test_long from 3.5
https://hg.python.org/cpython/rev/11ad44d4177f

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 02:14:59 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 26 Sep 2015 00:14:59 +0000
Subject: [issue25211] Error message formatting errors in int object unit-test
 script
In-Reply-To: <1442908335.62.0.971755787432.issue25211@psf.upfronthosting.co.za>
Message-ID: <1443226499.02.0.248013486371.issue25211@psf.upfronthosting.co.za>


Changes by Martin Panter :


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 02:15:17 2015
From: report at bugs.python.org (Thijs van Dien)
Date: Sat, 26 Sep 2015 00:15:17 +0000
Subject: [issue25125] "Edit with IDLE" does not work for shortcuts
In-Reply-To: <1442318370.13.0.116980940121.issue25125@psf.upfronthosting.co.za>
Message-ID: <1443226517.97.0.458599300736.issue25125@psf.upfronthosting.co.za>


Thijs van Dien added the comment:

That works fine, but then again the ticket only concerns the context menu of _shortcuts_ to Python files. Opening Python files directly, either via "Edit with IDLE" in context menu or directly via the CLI, has worked from the beginning.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 04:23:58 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 26 Sep 2015 02:23:58 +0000
Subject: [issue25173] IDLE - several common dialogs don't have correct parent
 set
In-Reply-To: <1442629608.18.0.497476300551.issue25173@psf.upfronthosting.co.za>
Message-ID: <20150926022354.16583.86438@psf.io>


Roundup Robot added the comment:

New changeset e406d62014f7 by Terry Jan Reedy in branch '2.7':
Issue #25173: Replace 'master' with 'parent' in tkinter.messagebox calls.
https://hg.python.org/cpython/rev/e406d62014f7

New changeset e494316a9291 by Terry Jan Reedy in branch '3.4':
Issue #25173: Replace 'master' with 'parent' in tkinter.messagebox calls.
https://hg.python.org/cpython/rev/e494316a9291

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 04:24:00 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 26 Sep 2015 02:24:00 +0000
Subject: [issue25209] Append space after completed keywords
In-Reply-To: <1442870714.02.0.814978155097.issue25209@psf.upfronthosting.co.za>
Message-ID: <1443234240.58.0.211841395866.issue25209@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yes I am interesting in making a patch for auto-completing module names. I?ll leave it on my to-do list, but don?t expect it overnight. :) My code does some rough parsing of Python syntax, but maybe that is not needed for ?import x?, though it might be needed to support module attributes for ?from x import y?.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 04:49:46 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Sep 2015 02:49:46 +0000
Subject: [issue12219] tkinter.filedialog.askopenfilename XT dialog on Windows 7
In-Reply-To: <1306788881.55.0.171400893605.issue12219@psf.upfronthosting.co.za>
Message-ID: <1443235786.68.0.275119028268.issue12219@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am closing this because for 3.4.3 and 3.5.0 on Win 7, both of which use tk 8.6.x, the file open dialog works as in the 'correct' png, with a navigation pane.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 05:03:32 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Sep 2015 03:03:32 +0000
Subject: [issue25237] Add doc for tkinter commondialog.Dialog and subclasses
Message-ID: <1443236612.77.0.515516122635.issue25237@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

As noted in #15346, several modules are not documented except in the code.  Having just had to do that for #25173, I would like there to be a page for commondialog.Dialog and its subclasses, messagebox.Message and colorchooser.Chooser, and the associated module functions.  I hope to submit a .rst file for review if no one else does so.  My plan is to copy from web pages produced by the pydoc server, add markup, and edit.

----------
messages: 251630
nosy: serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Add doc for tkinter commondialog.Dialog and subclasses
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 05:04:59 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Sep 2015 03:04:59 +0000
Subject: [issue15346] Tkinter extention modules have no documentation
In-Reply-To: <1342198047.2.0.619885102312.issue15346@psf.upfronthosting.co.za>
Message-ID: <1443236699.95.0.594322119132.issue15346@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I opened #25237 for commondialog, messagebox, and colorchooser.

----------
dependencies: +Add doc for tkinter commondialog.Dialog and subclasses
nosy: +terry.reedy
versions: +Python 3.5, Python 3.6 -Python 2.6, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 05:34:04 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 26 Sep 2015 03:34:04 +0000
Subject: [issue25232] CGIRequestHandler behave incorrectly with query
 component consisting mutliple ?
In-Reply-To: <1443195881.69.0.030953923686.issue25232@psf.upfronthosting.co.za>
Message-ID: <1443238444.88.0.0743600037356.issue25232@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I add a testcase but I worry it's not in the right format. Please review it. Partition is a good choice here.

----------
Added file: http://bugs.python.org/file40584/multiple?.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 05:42:47 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Sep 2015 03:42:47 +0000
Subject: [issue25237] Add doc for tkinter commondialog.Dialog and subclasses
In-Reply-To: <1443236612.77.0.515516122635.issue25237@psf.upfronthosting.co.za>
Message-ID: <1443238967.21.0.607203124317.issue25237@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Side issue: Dialog has this:
        # we need a dummy widget to properly process the options
        # (at least as long as we use Tkinter 1.63)
        w = Frame(self.master)

Do you know what 'Tkinter 1.63' refers to?  In 2.7, Tkinter.__version__ is '$Revision: 81008 $'.  If self.master is not None, I would expect that it can be used in
            s = w.tk.call(self.command, *w._options(self.options))
            s = self._fixresult(w, s)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 05:44:01 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Sep 2015 03:44:01 +0000
Subject: [issue25173] IDLE - several common dialogs don't have correct parent
 set
In-Reply-To: <1442629608.18.0.497476300551.issue25173@psf.upfronthosting.co.za>
Message-ID: <1443239041.65.0.5427619922.issue25173@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Opened #25237 about Dialog+subclass docs.

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 05:47:52 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 26 Sep 2015 03:47:52 +0000
Subject: [issue24657] CGIHTTPServer module discard continuous '/' letters from
 params given by GET method.
In-Reply-To: <1437187776.37.0.855244973055.issue24657@psf.upfronthosting.co.za>
Message-ID: <1443239272.86.0.478496491781.issue24657@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Add the testcase and use str.partition.

----------
Added file: http://bugs.python.org/file40585/cgihander.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 07:46:24 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 26 Sep 2015 05:46:24 +0000
Subject: [issue25131] The AST for dict and set displays has the lineno of the
 first value
In-Reply-To: <1442341705.94.0.0242549644551.issue25131@psf.upfronthosting.co.za>
Message-ID: <20150926054621.115327.5597@psf.io>


Roundup Robot added the comment:

New changeset 4f14afc959df by Benjamin Peterson in branch '3.5':
make opening brace of container literals and comprehensions correspond to the line number and col offset of the AST node (closes #25131)
https://hg.python.org/cpython/rev/4f14afc959df

New changeset 9d895c09c08a by Benjamin Peterson in branch 'default':
merge 3.5 (#25131)
https://hg.python.org/cpython/rev/9d895c09c08a

----------
nosy: +python-dev
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 09:10:51 2015
From: report at bugs.python.org (Steve Dower)
Date: Sat, 26 Sep 2015 07:10:51 +0000
Subject: [issue25125] "Edit with IDLE" does not work for shortcuts
In-Reply-To: <1442318370.13.0.116980940121.issue25125@psf.upfronthosting.co.za>
Message-ID: <1443251451.21.0.558143874383.issue25125@psf.upfronthosting.co.za>


Steve Dower added the comment:

Ah, I misread that part. Will have to look deeper, but I'm not actually sure that shortcuts are supposed to support the same operations (though if it shows up, I guess it should work).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 09:16:16 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 26 Sep 2015 07:16:16 +0000
Subject: [issue25135] Deques to adopt the standard clearing procedure for
 mutable objects
In-Reply-To: <1442358776.69.0.0875538895398.issue25135@psf.upfronthosting.co.za>
Message-ID: <20150926071612.94129.19750@psf.io>


Roundup Robot added the comment:

New changeset 005590a4a005 by Raymond Hettinger in branch '3.5':
Issue #25135: Avoid possible reentrancy issues in deque_clear.
https://hg.python.org/cpython/rev/005590a4a005

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 09:44:54 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 26 Sep 2015 07:44:54 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <20150926074451.16585.88615@psf.io>


Roundup Robot added the comment:

New changeset 40667f456c6f by Victor Stinner in branch 'default':
Issue #25220: Create Lib/test/libregrtest/
https://hg.python.org/cpython/rev/40667f456c6f

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 09:53:04 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 26 Sep 2015 07:53:04 +0000
Subject: [issue25135] Deques to adopt the standard clearing procedure for
 mutable objects
In-Reply-To: <1442358776.69.0.0875538895398.issue25135@psf.upfronthosting.co.za>
Message-ID: <20150926075302.3654.21145@psf.io>


Roundup Robot added the comment:

New changeset fc6d62db8d42 by Raymond Hettinger in branch '2.7':
Issue #25135: Avoid possible reentrancy issues in deque_clear.
https://hg.python.org/cpython/rev/fc6d62db8d42

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 09:54:18 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 26 Sep 2015 07:54:18 +0000
Subject: [issue25135] Deques to adopt the standard clearing procedure for
 mutable objects
In-Reply-To: <1442358776.69.0.0875538895398.issue25135@psf.upfronthosting.co.za>
Message-ID: <1443254058.76.0.268115433517.issue25135@psf.upfronthosting.co.za>


Changes by Raymond Hettinger :


----------
resolution:  -> fixed
status: open -> closed
type:  -> behavior
versions: +Python 2.7, Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 10:05:14 2015
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Sat, 26 Sep 2015 08:05:14 +0000
Subject: [issue25188] regrtest.py improvement for Profile Guided Optimization
 builds
In-Reply-To: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za>
Message-ID: <1443254714.15.0.835172969219.issue25188@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

Thank you for the tweaks. I tested the patch and it is all working fine. Without failure count the PGO run is even more transparent to the user. 

I tested your final version of the patch on several Linux server and regular desktop distributions and software configurations and I saw that test_eintr does not block and the entire PGO build finishes in good conditions every time.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 11:25:51 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 26 Sep 2015 09:25:51 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <20150926092548.9941.39855@psf.io>


Roundup Robot added the comment:

New changeset 4a9418ed0d0c by Victor Stinner in branch 'default':
Issue #25220: Move most regrtest.py code to libregrtest
https://hg.python.org/cpython/rev/4a9418ed0d0c

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 11:29:17 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Sep 2015 09:29:17 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <1443259757.34.0.706089194512.issue25220@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ok, I started simply by *moving* code, without additionnal changes. I will watch for buildbots to ensure that no regression was added. The Lib/test/regrtest.py is kept to not break any existing tool. It looks like Lib/test/regrtest.py is very important in Python, much more than what I expected. It's used for PGO compilation, it's used by various scripts for different platforms, it's used in scripts to build Linux packages,etc.

I used "hg cp" to create new files to ensure that the history is not lost.

I will write new patches for the real refactoring work described in the first message. It will be much easier to review changes written after the code was moved. So we can discuss controversal changes like the creation of a class for libregrtest/main.py ;-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 13:57:42 2015
From: report at bugs.python.org (desbma)
Date: Sat, 26 Sep 2015 11:57:42 +0000
Subject: [issue25238] Version added of context parameter for
 xmlrpc.client.ServerProxy incorrect
Message-ID: <1443268662.53.0.0661786105223.issue25238@psf.upfronthosting.co.za>


New submission from desbma:

Doc of 3.4 branch says the context parameter for xmlrpc.client.ServerProxy was added at version 3.4.3: https://docs.python.org/3.4/library/xmlrpc.client.html?highlight=xmlrpc.client#module-xmlrpc.client

Although doc of 3.5 branch says the context parameter for xmlrpc.client.ServerProxy was added at version 3.5: https://docs.python.org/3/library/xmlrpc.client.html?highlight=xmlrpc.client#module-xmlrpc.client

See issue22960 for original issue and patch.

----------
components: Library (Lib)
messages: 251644
nosy: desbma
priority: normal
severity: normal
status: open
title: Version added of context parameter for xmlrpc.client.ServerProxy incorrect
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 14:11:55 2015
From: report at bugs.python.org (Anand Krishnakumar)
Date: Sat, 26 Sep 2015 12:11:55 +0000
Subject: [issue24820] IDLE themes for light on dark
In-Reply-To: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>
Message-ID: <1443269515.08.0.307955677368.issue24820@psf.upfronthosting.co.za>


Anand Krishnakumar added the comment:

Hi!
I'm a 14 year old who wants to start developing for Python. I absolutely adore this enhancement and I would love to contribute towards this.
So please let me know if I can help, and if yes, how?

----------
nosy: +Anand Krishnakumar

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 14:54:55 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Sep 2015 12:54:55 +0000
Subject: [issue24820] IDLE themes for light on dark
In-Reply-To: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>
Message-ID: <1443272095.33.0.401085318417.issue24820@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

My only question right now is whether I should apply as is or with minor adjustments.  Thanks for the encouragements either way.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 15:26:02 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 26 Sep 2015 13:26:02 +0000
Subject: [issue25234] test_eintr.test_os_open hangs under Xcode 7
In-Reply-To: <1443210079.4.0.780575467942.issue25234@psf.upfronthosting.co.za>
Message-ID: <1443273962.31.0.751423127893.issue25234@psf.upfronthosting.co.za>


Ned Deily added the comment:

Brett, was this on OS X 10.10.x or a 10.11 pre-release?  test_eintr does not fail fail for me on either using the most recent Xcode 7.

----------
title: test_einter.test_os_open hangs under Xcode 7 -> test_eintr.test_os_open hangs under Xcode 7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 16:10:50 2015
From: report at bugs.python.org (Cyd Haselton)
Date: Sat, 26 Sep 2015 14:10:50 +0000
Subject: [issue23496] Steps for Android Native Build of Python 3.4.2
In-Reply-To: <1424551617.0.0.291471450783.issue23496@psf.upfronthosting.co.za>
Message-ID: <1443276650.27.0.78104977329.issue23496@psf.upfronthosting.co.za>


Cyd Haselton added the comment:

UPDATE: Before downloading/building Google gdb source I ran test_gdb.py, which failed completely.  Details of those tests are attached.

----------
Added file: http://bugs.python.org/file40586/test_gdb.log

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 17:10:29 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 26 Sep 2015 15:10:29 +0000
Subject: [issue25233] AssertionError from asyncio Queue get
In-Reply-To: <1443202040.86.0.857467079978.issue25233@psf.upfronthosting.co.za>
Message-ID: <1443280229.19.0.262347299135.issue25233@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I have a fix pending here: https://github.com/python/asyncio/pull/269

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 17:13:37 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 26 Sep 2015 15:13:37 +0000
Subject: [issue25234] test_eintr.test_os_open hangs under Xcode 7
In-Reply-To: <1443210079.4.0.780575467942.issue25234@psf.upfronthosting.co.za>
Message-ID: <1443280417.95.0.23548130195.issue25234@psf.upfronthosting.co.za>


Brett Cannon added the comment:

It is 10.10, but apparently a reboot fixed it (software, am I right? =/ ).

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 17:16:43 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 26 Sep 2015 15:16:43 +0000
Subject: [issue25188] regrtest.py improvement for Profile Guided Optimization
 builds
In-Reply-To: <1442726782.64.0.586742420801.issue25188@psf.upfronthosting.co.za>
Message-ID: <1443280603.37.0.757609197973.issue25188@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I fixed my test_eintr problem, but now https://hg.python.org/cpython/rev/4a9418ed0d0c landed in 3.6/default and broke the patch. Since missing getting this in before the aforementioned change was my fault, I'll personally handle making the patch apply cleanly in default.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 17:17:15 2015
From: report at bugs.python.org (Remi Pointel)
Date: Sat, 26 Sep 2015 15:17:15 +0000
Subject: [issue23329] _ssl cannot be compiled with LibreSSL anymore (on
 OpenBSD 5.5) because of ALPN
In-Reply-To: <1422353692.3.0.280216678648.issue23329@psf.upfronthosting.co.za>
Message-ID: <1443280635.64.0.011910733084.issue23329@psf.upfronthosting.co.za>


Remi Pointel added the comment:

Good, I think we should test on a machine with a version of openssl that does not support ALPN to be sure.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 18:12:50 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 26 Sep 2015 16:12:50 +0000
Subject: [issue747320] rfc2822 formatdate functionality duplication
Message-ID: <1443283970.58.0.594438444455.issue747320@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Here is an updated patch (including tests and documentation updates).

----------
components:  -email
nosy: +berker.peksag
stage: needs patch -> patch review
type: performance -> enhancement
versions: +Python 3.6 -Python 3.5
Added file: http://bugs.python.org/file40587/issue747320.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 18:46:39 2015
From: report at bugs.python.org (Sean Liu)
Date: Sat, 26 Sep 2015 16:46:39 +0000
Subject: [issue25239] HTMLParser handle_starttag replaces entity references in
 attribute value even without semicolon
Message-ID: <1443285999.33.0.0508878437802.issue25239@psf.upfronthosting.co.za>


New submission from Sean Liu:

In the document of HTMLParser.handle_starttag, it states "All entity references from html.entities are replaced in the attribute values." However it will replace the string if it matches ampersand followed by the entity name without the semicolon.

For example foo will produce "t=buy?cy=usd" as the value of href attribute due to "curren" is the entity name for the currency sign.

----------
components: Library (Lib)
files: parserentity.py
messages: 251654
nosy: Sean Liu
priority: normal
severity: normal
status: open
title: HTMLParser handle_starttag replaces entity references in attribute value even without semicolon
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file40588/parserentity.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 18:47:58 2015
From: report at bugs.python.org (Ceridwen)
Date: Sat, 26 Sep 2015 16:47:58 +0000
Subject: [issue25240] Stack overflow in reprlib causes a core dump
Message-ID: <1443286078.54.0.18490843262.issue25240@psf.upfronthosting.co.za>


New submission from Ceridwen:

I have a linked list implementation made of nested tuples with a custom repr:

    def __repr__(self):
        return 'LinkedList(' + ', '.join(repr(v) for v in self) + ')'

(Iterating over a LinkedList returns just its contents.)

When using Raymond Hettinger's recipe for finding the size in memory of an object, https://code.activestate.com/recipes/577504-compute-memory-footprint-of-an-object-and-its-cont/?in=user-178123 , when I set verbose=True and exceed the recursion limit with reprlib.repr, I get the following error:

Fatal Python error: Cannot recover from stack overflow.

Current thread 0x00007fa24200d700 (most recent call first):
  File ".py", line 327 in __repr__
  File "/usr/lib/python3.4/reprlib.py", line 135 in repr_instance
  File "/usr/lib/python3.4/reprlib.py", line 64 in repr1
  File "/usr/lib/python3.4/reprlib.py", line 54 in repr
  File "recipe.py", line 46 in sizeof
  [many instances of the above line repeated]
  ...
Aborted (core dumped)

The line in the recipe it fails when recursing on is:

            print(s, type(o), repr(o), file=stderr)

On 2.7 it fails with a RuntimeError as I'd expect.

----------
components: Library (Lib)
messages: 251655
nosy: ceridwen
priority: normal
severity: normal
status: open
title: Stack overflow in reprlib causes a core dump
type: crash
versions: Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 18:53:56 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 26 Sep 2015 16:53:56 +0000
Subject: [issue19884] Importing readline produces erroneous output
In-Reply-To: <1386158776.45.0.265770743985.issue19884@psf.upfronthosting.co.za>
Message-ID: <1443286436.73.0.750131879758.issue19884@psf.upfronthosting.co.za>


Berker Peksag added the comment:

The version check doesn't work because 0ed1801bf4bd added #ifndef __APPLE__ to guard the code, so if you're using readline on OS X, that rl_variable_bind workaround won't work.

There are two alternatives:

1) convert ifndef to ifdef and add a check for the ``using_libedit_emulation`` variable.

    #ifdef __APPLE__
        if (using_libedit_emulation) {
            ...
    ...

looks like a common idiom in readline.c.


2) just skip the test if _READLINE_VERSION < 0x0603

----------
nosy: +berker.peksag

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 18:57:29 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Sep 2015 16:57:29 +0000
Subject: [issue25240] Stack overflow in reprlib causes a core dump
In-Reply-To: <1443286078.54.0.18490843262.issue25240@psf.upfronthosting.co.za>
Message-ID: <1443286649.36.0.730607570541.issue25240@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
nosy: +rhettinger

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 18:59:49 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Sep 2015 16:59:49 +0000
Subject: [issue25239] HTMLParser handle_starttag replaces entity references in
 attribute value even without semicolon
In-Reply-To: <1443285999.33.0.0508878437802.issue25239@psf.upfronthosting.co.za>
Message-ID: <1443286789.39.0.0510096178745.issue25239@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 19:06:12 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 26 Sep 2015 17:06:12 +0000
Subject: [issue25239] HTMLParser handle_starttag replaces entity references in
 attribute value even without semicolon
In-Reply-To: <1443285999.33.0.0508878437802.issue25239@psf.upfronthosting.co.za>
Message-ID: <1443287172.45.0.594852727462.issue25239@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

This seems indeed to be a bug.  The relevant bit seems to be at http://www.w3.org/TR/html5/syntax.html#consume-a-character-reference :

"""
If the character reference is being consumed as part of an attribute, and the last character matched is not a ";" (U+003B) character, and the next character is either a "=" (U+003D) character or an alphanumeric ASCII character, then, for historical reasons, all the characters that were matched after the U+0026 AMPERSAND character (&) must be unconsumed, and nothing is returned. However, if this next character is in fact a "=" (U+003D) character, then this is a parse error, because some legacy user agents will misinterpret the markup in those cases.
"""

Off the top of my head, this paragraph is not implemented in HTMLParser (and it should).
Also note that foo is not valid HTML and the & should have been escaped with &.

----------
assignee:  -> ezio.melotti
stage:  -> test needed
versions: +Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 19:29:11 2015
From: report at bugs.python.org (Dum Dum)
Date: Sat, 26 Sep 2015 17:29:11 +0000
Subject: [issue25241] ctypes: access violation reading
Message-ID: <1443288551.09.0.384343854167.issue25241@psf.upfronthosting.co.za>


New submission from Dum Dum:

On Windows 8.1 64-bit, using a fresh installation of Python 3.5.150.0 64-bit, `error_script.py` crashes, while Python 3.4.3150 and 2.7.10150 (both 64-bit) run the script properly.

Here is a traceback: https://bpaste.net/show/3ecfbf93b96e

----------
files: error_script.py
messages: 251658
nosy: Dum.Dum
priority: normal
severity: normal
status: open
title: ctypes: access violation reading
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file40589/error_script.py

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 20:57:37 2015
From: report at bugs.python.org (Open Genomes)
Date: Sat, 26 Sep 2015 18:57:37 +0000
Subject: [issue25242] Failed tests for Python 3.5.0 on shared virtual host
Message-ID: <1443293857.94.0.352020564349.issue25242@psf.upfronthosting.co.za>


New submission from Open Genomes:

Several tests for Python 3.5.0 failed. 
The install is a local one on a shared virtual server from bluehost.com
This is a local user install, with a prefix in $HOME/python directory. 
Output of uname -a:
Linux box874.bluehost.com 3.12.35.1418868052 #1 SMP Wed Dec 17 20:04:02 CST 2014 x86_64 x86_64 x86_64 GNU/Linux

It would seem that there are no permissions to spawn() a new process, and to write temporary files to /tmp

The tests should be able to work on a virtual server, or the test should check if there are permissions to fork a process and write to a system-wide temporary directory. Of course many installations use Python on virtual hosts and often the system-wide default installation on Linux systems is 2.7.0. The tests need to fail gracefully or accommodate the lack of permissions for to fork new processes and write to system-wide temporary directories.

----------
components: Tests
files: tests.out
messages: 251659
nosy: Open Genomes
priority: normal
severity: normal
status: open
title: Failed tests for Python 3.5.0 on shared virtual host
type: compile error
versions: Python 3.5
Added file: http://bugs.python.org/file40590/tests.out

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 21:10:42 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 26 Sep 2015 19:10:42 +0000
Subject: [issue25241] ctypes: access violation reading
In-Reply-To: <1443288551.09.0.384343854167.issue25241@psf.upfronthosting.co.za>
Message-ID: <1443294642.65.0.354568407027.issue25241@psf.upfronthosting.co.za>


eryksun added the comment:

The default function pointer restype is c_int, and the default integer argument conversion is also c_int. However, the handle returned by FindFirstVolume is a pointer to a private structure that it uses for the volume enumeration, so you must set restype to a pointer type. Similarly, if restype is a simple type that gets converted to a Python integer (e.g. wintypes.HANDLE), then you must either set FindNextVolumeW.argtypes or manually wrap the handle value (e.g. vhandle = wintypes.HANDLE(vhandle)). The default c_int conversions will only work if the address happens to fit in a 32-bit int. 

Don't forget to call FindVolumeClose if the process is expected to continue. Otherwise you're leaking memory.

Also, if you're defining function pointer prototypes for a library, please do not use ctypes.cdll or ctypes.windll. The loaders are global to ctypes and by design cache the loaded library, which by design caches function pointers. Projects such as pyreadline and colorama have demonstrated the problems that this creates due to inconsistent prototype definitions, especially for commonly used Win32 APIs.

Here is one way to rewrite your code to have it work more reliably:

    import ctypes
    from ctypes import wintypes

    kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)

    kernel32.FindFirstVolumeW.restype = wintypes.HANDLE
    kernel32.FindNextVolumeW.argtypes = (wintypes.HANDLE,
                                         wintypes.LPWSTR,
                                         wintypes.DWORD)
    kernel32.FindVolumeClose.argtypes = (wintypes.HANDLE,)

    INVALID_HANDLE_VALUE = wintypes.HANDLE(-1).value
    ERROR_NO_MORE_FILES = 18

    def list_volumes():
        vname = ctypes.create_unicode_buffer(wintypes.MAX_PATH)
        vhandle = kernel32.FindFirstVolumeW(vname, len(vname))
        if vhandle == INVALID_HANDLE_VALUE:
            raise ctypes.WinError(ctypes.get_last_error())
        volumes = []
        try:
            while True:
                volumes.append(vname.value)
                if not kernel32.FindNextVolumeW(vhandle, vname, len(vname)):
                    last_error = ctypes.get_last_error()
                    if last_error == ERROR_NO_MORE_FILES:
                        break
                    else:
                        raise ctypes.WinError(last_error)
        finally:
            if not kernel32.FindVolumeClose(vhandle):
                raise ctypes.WinError(ctypes.get_last_error())
        return volumes

    if __name__ == '__main__':
        for volume in list_volumes():
            print(volume)

----------
nosy: +eryksun
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 21:34:01 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 26 Sep 2015 19:34:01 +0000
Subject: [issue25242] Failed tests for Python 3.5.0 on shared virtual host
In-Reply-To: <1443293857.94.0.352020564349.issue25242@psf.upfronthosting.co.za>
Message-ID: <1443296041.09.0.653499406596.issue25242@psf.upfronthosting.co.za>


R. David Murray added the comment:

I've only scanned the first couple of test failures in your attachment, but they don't seem to have anything to do with spawn or /tmp.

----------
nosy: +r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 22:34:57 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 26 Sep 2015 20:34:57 +0000
Subject: [issue25125] "Edit with IDLE" does not work for shortcuts
In-Reply-To: <1442318370.13.0.116980940121.issue25125@psf.upfronthosting.co.za>
Message-ID: <1443299697.11.0.397010388447.issue25125@psf.upfronthosting.co.za>


eryksun added the comment:

> Ah, I misread that part. Will have to look deeper, but I'm not
> actually sure that shortcuts are supposed to support the same 
> operations (though if it shows up, I guess it should work).

A LNK shortcut should support the same commands (e.g. open, edit) as its target. This works for me in Windows 10. 

BTW, I don't see how to ShellExecute a subcommand documented on MSDN. One way is to just pass the subkey path as the 'verb', e.g. r"editwithidle\shell\edit35". Probably it's just passed along to RegOpenKeyEx as the subkey, so this shouldn't be used in practice. Could the installer create a simple "edit" command? It doesn't have to be smart about it. Just overwrite the current value, and let a per-user install take precedence.

----------
nosy: +eryksun

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sat Sep 26 23:25:55 2015
From: report at bugs.python.org (eryksun)
Date: Sat, 26 Sep 2015 21:25:55 +0000
Subject: [issue25241] ctypes: access violation reading
In-Reply-To: <1443288551.09.0.384343854167.issue25241@psf.upfronthosting.co.za>
Message-ID: <1443302755.33.0.151427230329.issue25241@psf.upfronthosting.co.za>


eryksun added the comment:

Here's a rewrite with a cleaner while loop, at least to me:

    def list_volumes():
        vname = ctypes.create_unicode_buffer(wintypes.MAX_PATH)
        vhandle = kernel32.FindFirstVolumeW(vname, len(vname))
        if vhandle == INVALID_HANDLE_VALUE:
            raise ctypes.WinError(ctypes.get_last_error())
        volumes = [vname.value]
        try:
            while kernel32.FindNextVolumeW(vhandle, vname, len(vname)):
                volumes.append(vname.value)
            last_error = ctypes.get_last_error()
            if last_error != ERROR_NO_MORE_FILES:        
                raise ctypes.WinError(last_error)
        finally:
            if not kernel32.FindVolumeClose(vhandle):
                raise ctypes.WinError(ctypes.get_last_error())
        return volumes

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 00:40:20 2015
From: report at bugs.python.org (Joshua Bronson)
Date: Sat, 26 Sep 2015 22:40:20 +0000
Subject: [issue25243] decouple string-to-boolean logic from
 ConfigParser.getboolean and offer as separate function
Message-ID: <1443307220.16.0.776749230814.issue25243@psf.upfronthosting.co.za>


New submission from Joshua Bronson:

ConfigParser.getboolean[1] has logic to convert strings like '0' and 'False' to False. This logic is generally useful in other contexts and need not be coupled to ConfigParser. Would you consider accepting a patch that factored this string-to-boolean logic out of ConfigParser into a standalone function, and changed ConfigParser.getboolean internally to call that?

Thanks for your consideration.

[1] https://docs.python.org/3/library/configparser.html#configparser.ConfigParser.getboolean

----------
messages: 251664
nosy: jab
priority: normal
severity: normal
status: open
title: decouple string-to-boolean logic from ConfigParser.getboolean and offer as separate function
type: enhancement

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 00:44:01 2015
From: report at bugs.python.org (Dum Dum)
Date: Sat, 26 Sep 2015 22:44:01 +0000
Subject: [issue25241] ctypes: access violation reading
In-Reply-To: <1443288551.09.0.384343854167.issue25241@psf.upfronthosting.co.za>
Message-ID: <1443307441.79.0.933135102691.issue25241@psf.upfronthosting.co.za>


Dum Dum added the comment:

I rewrote the code following your suggestions and it appears the error was indeed on my side. I somewhat expected that, but found it weird that it only seemed to occur on 3.5. Thank you!

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 00:47:15 2015
From: report at bugs.python.org (Joshua Bronson)
Date: Sat, 26 Sep 2015 22:47:15 +0000
Subject: [issue25243] decouple string-to-boolean logic from
 ConfigParser.getboolean and offer as separate function
In-Reply-To: <1443307220.16.0.776749230814.issue25243@psf.upfronthosting.co.za>
Message-ID: <1443307635.04.0.80429098321.issue25243@psf.upfronthosting.co.za>


Joshua Bronson added the comment:

One way this could be offered is as a new static method on bool (something like bool.parse_str?), but I of course defer to the better judgment of the Python core developers. I'd be happy to take a crack at a patch adding it wherever you like, if you like.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 00:51:28 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 26 Sep 2015 22:51:28 +0000
Subject: [issue24988] IDLE: debugger context menus not working on Mac
In-Reply-To: <1441235411.2.0.839528084251.issue24988@psf.upfronthosting.co.za>
Message-ID: <20150926225125.82638.58167@psf.io>


Roundup Robot added the comment:

New changeset bf11034f0291 by Terry Jan Reedy in branch '2.7':
Issue #24988: Idle ScrolledList context menus (used in debugger)
https://hg.python.org/cpython/rev/bf11034f0291

New changeset 85a4c95ad02f by Terry Jan Reedy in branch '3.4':
Issue #24988: Idle ScrolledList context menus (used in debugger)
https://hg.python.org/cpython/rev/85a4c95ad02f

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 00:54:31 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Sep 2015 22:54:31 +0000
Subject: [issue9051] Improve pickle format for timezone aware datetime
 instances
In-Reply-To: <1277151308.95.0.331220838487.issue9051@psf.upfronthosting.co.za>
Message-ID: <1443308071.48.0.25538424177.issue9051@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> For stability it is better to use public name 'timezone.utc' instead of '_utc'.

Can you elaborate on the "stability" consideration?

I would like to revisit this issue since we will have some changes made to datetime pickles in the context of PEP 495.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 01:12:19 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Sep 2015 23:12:19 +0000
Subject: [issue25244] Idle: refine right-click behavior
Message-ID: <1443309139.01.0.264782757887.issue25244@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Spinoff from #24988, where I noted "The standard on Windows is to bring up a context menu on right-button-release, not on r-b-press." and asked "What about linux and mac?"

The question is relevant for 'Go to File/Line'.  Look at text where pressed or where released?

Current code in multiple places is
        if macosxSupport.isAquaTk():
            listbox.bind("", self.popup_event)
            listbox.bind("", self.popup_event)
        else:
            listbox.bind("", self.popup_event)

Also for paste: where insert?

Thunderbird and Notepad++ move the insertion cursor on rb-press, That is the paste position even if the mouse is moved before release. Notepad does not move the insert cursor. MS Word is confusing, erasing the cursor when the menu is displayed and moving it when the menu goes away.

Additional note: Testing with my middle button, a press and release act the same as left click to move the insertion cursor to the mouse cursor. Moving my mouse while holding the middle button down moves the text pane within the text window. The insertion cursor is not moved. This is pretty much redundant with using the scroll wheel or scroll bar.

----------
assignee: terry.reedy
messages: 251669
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Idle: refine right-click behavior
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 01:16:39 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Sep 2015 23:16:39 +0000
Subject: [issue24988] IDLE: debugger context menus not working on Mac
In-Reply-To: <1441235411.2.0.839528084251.issue24988@psf.upfronthosting.co.za>
Message-ID: <1443309399.47.0.19551323091.issue24988@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Opened #25244 to consider changing exact right-click behavior.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 01:16:50 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Sep 2015 23:16:50 +0000
Subject: [issue24988] IDLE: debugger context menus not working on Mac
In-Reply-To: <1441235411.2.0.839528084251.issue24988@psf.upfronthosting.co.za>
Message-ID: <1443309410.06.0.765818479389.issue24988@psf.upfronthosting.co.za>


Changes by Terry J. Reedy :


----------
assignee:  -> terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 01:36:02 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 26 Sep 2015 23:36:02 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1443310562.41.0.131352510812.issue18967@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Just noting a potential practical benefit of the "NEWS entry first" approach that David suggests: I believe it will help encourage the creation of a succinct answer to "Why are we making this change?" as part of the patch review process.

That's then useful both during the patch review itself (since there's a shared understanding between reviewers and implementors of the goal to be achieved), as well as when the change is released (since there's hopefully a user centric explanation of *why* something changed, rather than merely *what* changed)

However, the key trap I'd like us to avoid falling into is letting the fact a particular approach falls short of our ideal approach deter the introduction of interim improvements. We're going to need the checked in filesystem database anyway to backfill historical NEWS entries after switching to a generated NEWS file, so it seems harmless to me to switch to it early and then incrementally add to it until a tracker based solution is available.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 01:46:16 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Sep 2015 23:46:16 +0000
Subject: [issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0,
 DstOffset=1
In-Reply-To: <1425688983.27.0.949503850992.issue23600@psf.upfronthosting.co.za>
Message-ID: <1443311176.31.0.119428182978.issue23600@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky :


----------
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 01:52:58 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Sep 2015 23:52:58 +0000
Subject: [issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0,
 DstOffset=1
In-Reply-To: <1425688983.27.0.949503850992.issue23600@psf.upfronthosting.co.za>
Message-ID: <1443311578.98.0.168873460149.issue23600@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I am afraid you misunderstand how fromutc() method works.  Note that you rarely need to call it directly: use astimezone() method to convert between timezones.

----------
nosy: +tim.peters

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 02:04:52 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 27 Sep 2015 00:04:52 +0000
Subject: [issue24570] IDLE Autocomplete and Call Tips Do Not Pop Up on OS X
 with ActiveTcl 8.5.18
In-Reply-To: <1436129307.64.0.192936457067.issue24570@psf.upfronthosting.co.za>
Message-ID: <20150927000448.11708.30783@psf.io>


Roundup Robot added the comment:

New changeset b5bc7e9dab77 by Terry Jan Reedy in branch '2.7':
Issue #24570: Idle: make calltip and completion boxes appear on Macs
https://hg.python.org/cpython/rev/b5bc7e9dab77

New changeset 6687630e201a by Terry Jan Reedy in branch '3.4':
Issue #24570: Idle: make calltip and completion boxes appear on Macs
https://hg.python.org/cpython/rev/6687630e201a

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 02:19:20 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 27 Sep 2015 00:19:20 +0000
Subject: [issue24570] IDLE Autocomplete and Call Tips Do Not Pop Up on OS X
 with ActiveTcl 8.5.18
In-Reply-To: <1436129307.64.0.192936457067.issue24570@psf.upfronthosting.co.za>
Message-ID: <1443313160.57.0.135027900845.issue24570@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Added equivalent completion window patch.  Would have preferred confirmation that Idle versions work, but 3.4.4rc1 is only a week away and I think having bug confirmed and fixed in tcl is enough to go with.

----------
assignee:  -> terry.reedy
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 02:19:33 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 27 Sep 2015 00:19:33 +0000
Subject: [issue24570] IDLE Autocomplete and Call Tips Do Not Pop Up on OS X
 with ActiveTcl 8.5.18
In-Reply-To: <1436129307.64.0.192936457067.issue24570@psf.upfronthosting.co.za>
Message-ID: <1443313173.93.0.771499276243.issue24570@psf.upfronthosting.co.za>


Changes by Terry J. Reedy :


----------
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 05:04:08 2015
From: report at bugs.python.org (Tim Peters)
Date: Sun, 27 Sep 2015 03:04:08 +0000
Subject: [issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0,
 DstOffset=1
In-Reply-To: <1425688983.27.0.949503850992.issue23600@psf.upfronthosting.co.za>
Message-ID: <1443323048.57.0.677714200193.issue23600@psf.upfronthosting.co.za>


Tim Peters added the comment:

I expect Peter is correct:  the C fromutc() doesn't match the logic of the Python fromutc(), and there are no comments explaining why the C version changed the logic.

The last 4 lines of his `time_issues.py` show the difference.  The simplified UKSummerTime tzinfo always says the total UTC offset and the DST offset are +1:00:00.  The Python .fromutc() adds that hour to the datetime passed in, but the C .fromutc() does not.  That's because they implement different functions, not because Peter is using .fromutc() ;-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 05:09:16 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 27 Sep 2015 03:09:16 +0000
Subject: [issue25194] Register of Financial Interests for core contributors
In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za>
Message-ID: <1443323356.61.0.593159466013.issue25194@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Posting an alternate draft that takes the approach MAL suggested, emphasising the personal motivation side of things.

This one doesn't attempt to pre-categories the list of contributors - instead, I'd expect us to do that based on analysis of the raw text.

The opening section also makes it clear that we're not shifting the goal posts on becoming a core contributor - the only required disclosure remains that which is needed to sign the CLA and submit the signed copy to the PSF.

I like this version a lot better then the previous draft, but am still open to suggestions for improving both the formatting and the content.

----------
Added file: http://bugs.python.org/file40591/motives.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 05:12:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 03:12:50 +0000
Subject: [issue9051] Improve pickle format for timezone aware datetime
 instances
In-Reply-To: <1277151308.95.0.331220838487.issue9051@psf.upfronthosting.co.za>
Message-ID: <1443323570.16.0.393269119244.issue9051@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

For now "_utc" is not a part of API. When use it in pickling, you implicitly make it a part of API, and should support it forever (and force other Python implementations to support it). As far as it looks as implementation detail, there is a risk that the "_utc" variable can be renamed and this will break pickle compatibility.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 05:24:53 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 03:24:53 +0000
Subject: [issue25242] Failed tests for Python 3.5.0 on shared virtual host
In-Reply-To: <1443293857.94.0.352020564349.issue25242@psf.upfronthosting.co.za>
Message-ID: <1443324293.73.0.264362906838.issue25242@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be /tmp is mounted on a filesystem that forbids setting the execution bit.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 05:30:24 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 27 Sep 2015 03:30:24 +0000
Subject: [issue24972] IDLE: revisit text highlighting for inactive windows on
 win32
In-Reply-To: <1441047261.05.0.292381389884.issue24972@psf.upfronthosting.co.za>
Message-ID: <1443324624.16.0.477606288546.issue24972@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I verified that inactiveselectbackground exists and starts as ''.  Since it should match the active selectbackground on all systems, as set by the current theme. I will try adding a line where selection colors are set: EditorWindow.ResetColorizer:
        self.text.config(
            ...
            selectforeground=select_colors['foreground'],
            selectbackground=select_colors['background'],
            inactiveselectbackground=select_colors['background']
            )
I believe this is the only place where this is needed.  The select colors are used for a different widget in TreeWidget. The use in ParenMatch for 'paren' tag should be temporary.

We will need to reconsider the 'found' highlight and the select versus found usage after this change.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 07:00:34 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 27 Sep 2015 05:00:34 +0000
Subject: [issue18814] Add utilities to "clean" surrogate code points from
 strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1443330034.45.0.632463225898.issue18814@psf.upfronthosting.co.za>


Martin Panter added the comment:

[padding]

I think my suggested colours for the bikeshed would be handle_surrogates() and handle_surrogateescape(). ?Rehandle? seems awkward and too assuming to me. And I agree with Serhiy that surrogates are a Unicode thing, not just related to the ?surrogatepass? handler.

Adding them to ?codecs? makes sense to me. The most important one, handle_surrogateescape() or equivalent, is closely related to the error handler of that module.

Having handle_surrogateescape or equivalent would probably be useful for Issue 25184 (displaying an arbitrary file path in a UTF-8 HTML file).

----------
nosy: +martin.panter

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 07:34:59 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 05:34:59 +0000
Subject: [issue25245] Compile warnings in _pickle.c
Message-ID: <1443332099.92.0.290485605256.issue25245@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Changeset 88d98f6c2d7d causes compile warnings in Modules/_pickle.c.

/home/serhiy/py/cpython/Modules/_pickle.c: In function ?load_counted_long?:
/home/serhiy/py/cpython/Modules/_pickle.c:4752:15: warning: ?pdata? may be used uninitialized in this function [-Wmaybe-uninitialized]
         value = _PyLong_FromByteArray((unsigned char *)pdata, (size_t)size,
               ^
/home/serhiy/py/cpython/Modules/_pickle.c: In function ?load?:
/home/serhiy/py/cpython/Modules/_pickle.c:5534:24: warning: ?s? may be used uninitialized in this function [-Wmaybe-uninitialized]
     idx = Py_CHARMASK(s[0]);
                        ^
/home/serhiy/py/cpython/Modules/_pickle.c:5529:11: note: ?s? was declared here
     char *s;
           ^
/home/serhiy/py/cpython/Modules/_pickle.c:4800:7: warning: ?s? may be used uninitialized in this function [-Wmaybe-uninitialized]
     x = _PyFloat_Unpack8((unsigned char *)s, 0);
       ^
/home/serhiy/py/cpython/Modules/_pickle.c:4795:11: note: ?s? was declared here
     char *s;
           ^

----------
components: Extension Modules
messages: 251683
nosy: benjamin.peterson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Compile warnings in _pickle.c
type: compile error
versions: Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 08:33:36 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 06:33:36 +0000
Subject: [issue25245] Compile warnings in _pickle.c
In-Reply-To: <1443332099.92.0.290485605256.issue25245@psf.upfronthosting.co.za>
Message-ID: <1443335616.28.0.176733217536.issue25245@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here are two alternative solutions.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file40592/issue25245_1.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 08:34:11 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 06:34:11 +0000
Subject: [issue25245] Compile warnings in _pickle.c
In-Reply-To: <1443332099.92.0.290485605256.issue25245@psf.upfronthosting.co.za>
Message-ID: <1443335651.38.0.744308416258.issue25245@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file40593/issue25245_2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 09:09:17 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 27 Sep 2015 07:09:17 +0000
Subject: [issue23329] _ssl cannot be compiled with LibreSSL anymore (on
 OpenBSD 5.5) because of ALPN
In-Reply-To: <1422353692.3.0.280216678648.issue23329@psf.upfronthosting.co.za>
Message-ID: <20150927070913.16575.20515@psf.io>


Roundup Robot added the comment:

New changeset 38a5b0f6531b by Benjamin Peterson in branch '3.5':
detect alpn by feature flag not openssl version (closes #23329)
https://hg.python.org/cpython/rev/38a5b0f6531b

New changeset 747996431c7e by Benjamin Peterson in branch 'default':
merge 3.5 (#23329)
https://hg.python.org/cpython/rev/747996431c7e

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 09:24:44 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 27 Sep 2015 07:24:44 +0000
Subject: [issue25243] decouple string-to-boolean logic from
 ConfigParser.getboolean and offer as separate function
In-Reply-To: <1443307220.16.0.776749230814.issue25243@psf.upfronthosting.co.za>
Message-ID: <1443338684.45.0.248497828063.issue25243@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
nosy: +lukasz.langa

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 09:36:21 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 27 Sep 2015 07:36:21 +0000
Subject: [issue25245] Compile warnings in _pickle.c
In-Reply-To: <1443332099.92.0.290485605256.issue25245@psf.upfronthosting.co.za>
Message-ID: <1443339381.05.0.444994792824.issue25245@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Why not just initially set *s to NULL in _Unpickler_Read?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 09:51:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 07:51:23 +0000
Subject: [issue25245] Compile warnings in _pickle.c
In-Reply-To: <1443339381.05.0.444994792824.issue25245@psf.upfronthosting.co.za>
Message-ID: <4945412.rqGIWtJ9h1@raxxla>


Serhiy Storchaka added the comment:

> Why not just initially set *s to NULL in _Unpickler_Read?

It would be the third variant.

The fourth variant is to change the signature of _Unpickler_Read() and return 
char * (NULL on error). All these variants work, I examined them.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 10:16:30 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 27 Sep 2015 08:16:30 +0000
Subject: [issue25245] Compile warnings in _pickle.c
In-Reply-To: <1443332099.92.0.290485605256.issue25245@psf.upfronthosting.co.za>
Message-ID: <20150927081627.82652.79623@psf.io>


Roundup Robot added the comment:

New changeset f0dcf7599517 by Benjamin Peterson in branch '3.4':
initialize return value to NULL to avoid compiler compliants (closes #25245)
https://hg.python.org/cpython/rev/f0dcf7599517

New changeset ef3b833b98c2 by Benjamin Peterson in branch '3.5':
merge 3.4 (#25245)
https://hg.python.org/cpython/rev/ef3b833b98c2

New changeset 4d23598f1428 by Benjamin Peterson in branch 'default':
merge 3.5 (#25245)
https://hg.python.org/cpython/rev/4d23598f1428

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 10:17:17 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 27 Sep 2015 08:17:17 +0000
Subject: [issue25245] Compile warnings in _pickle.c
In-Reply-To: <1443332099.92.0.290485605256.issue25245@psf.upfronthosting.co.za>
Message-ID: <1443341837.31.0.526355892828.issue25245@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Okay, I think it might make more sense for |s| to be a return value, but that change probably isn't appropriate for bugfix releases.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 10:40:51 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 27 Sep 2015 08:40:51 +0000
Subject: [issue25198] Idle: improve idle.html help viewer.
In-Reply-To: <1442794067.12.0.0580996406415.issue25198@psf.upfronthosting.co.za>
Message-ID: <20150927084048.9947.65149@psf.io>


Roundup Robot added the comment:

New changeset 40bab637295d by Terry Jan Reedy in branch '2.7':
Issue #25198: When using the Idle dov TOC menu, put the section title at the
https://hg.python.org/cpython/rev/40bab637295d

New changeset 5b635a3ca3d5 by Terry Jan Reedy in branch '3.4':
Issue #25198: When using the Idle dov TOC menu, put the section title at the
https://hg.python.org/cpython/rev/5b635a3ca3d5

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 10:43:41 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 27 Sep 2015 08:43:41 +0000
Subject: [issue25246] Alternative algorithm for deque_remove()
Message-ID: <1443343421.14.0.18683145075.issue25246@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The current algorithm for remove() rotates the deque one-by-one until a match is found, pops it off the deque and does single mass rotate to undo the 1-step rotates.

An alternative approach is to use deque_index() to locate the value of interest and use deque_del_item() to remove it.  

If not value is found, the alternative is better because it never moves the data in the deque.  If the value is found, the alternative removes it using two mass rotations.  The advantage in that case is the mass rotates are faster than many 1-step rotates.  The disadvantage is that we go through the pointer chain twice (the first time visiting and comparing every element and the second time only following the chain of links).

If the deque mutates during the search, a RuntimeError is raised.  This is a behavior change, formerly it raised an IndexError.

----------
assignee: rhettinger
files: deque_better_remove.diff
keywords: patch
messages: 251691
nosy: rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Alternative algorithm for deque_remove()
versions: Python 3.6
Added file: http://bugs.python.org/file40594/deque_better_remove.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 10:55:30 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 27 Sep 2015 08:55:30 +0000
Subject: [issue25198] Idle: improve idle.html help viewer.
In-Reply-To: <1442794067.12.0.0580996406415.issue25198@psf.upfronthosting.co.za>
Message-ID: <1443344130.93.0.630721356319.issue25198@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

By reading http://www.tcl.tk/man/tcl8.6/TkCmd/text.htm I discovered that Text.yview(index) puts the line with index at the top of the windows, given enough line below to fill the window.  This fixes another glitch.

Still left: the original 3 items (msg251181), navigating the text with up and down arrow (msg251571), and operating TOC button with keyboard (msg251556).

----------
Added file: http://bugs.python.org/file40595/top-of-window.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 10:55:47 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 27 Sep 2015 08:55:47 +0000
Subject: [issue18814] Add utilities to "clean" surrogate code points from
 strings
In-Reply-To: <1443330034.45.0.632463225898.issue18814@psf.upfronthosting.co.za>
Message-ID: 


STINNER Victor added the comment:

Hum, I suggest to put these functions in a package on PyPI, or recipes on a
website like stackoverfkow., and close the issue.

I'm still not convinced that these functions are useful . Usually we take a
function from an existing project used in applications to put it in the
stdlib. Here the use case still looks artifical. For example which
application requires to escape non-BMP character? How does it handle them
currently?

Threre are too many ways to handle surrogate characters. The common ways to
show undecodable bytes are not supported by functions proposed by Serhiy.
Example: %80 on Mac OS X. Gnome uses something else.

It was said that one reason to add new functions is performance. I'm not
convinced neither that such function is the bottleneck on any application.

I prefer to wait until users experiment with their own implementation and
see if a common function can be extracted from this to put it in the stdlib.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 11:30:58 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 27 Sep 2015 09:30:58 +0000
Subject: [issue18814] Add utilities to "clean" surrogate code points from
 strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1443346258.51.0.297563428023.issue18814@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I think moving this forward mainly needs someone with the time and energy wrangle a python-ideas/dev discussion to get some additional feedback on the API design. As I see it, there are 2 main questions to be resolved:

1. Where to expose these functions

The default location would be the codecs module, as they're closely related to the error handlers in that module, and the main reasons for needing to clean data at all are handling dirty data produced by an interface that uses surrogatepass or surrogateescape when decoding (handle_surrogates, handle_surrogateescape), or encoding data for use in a context which doesn't correctly handle code points outside the basic multilingual plane (handle_astrals).

If added to the codecs module, they could be documented in new sections on "Postprocessing decoded text" and "Preprocessing text for encoding".

The main argument against that would be Stephen's one, which is that these aren't themselves encoding or decoding operations, but rather internal state manipulations on Python strings.

2. The exact function set to be provided.

The three potential data cleaning cases currently being considered:

* process_surrogates: reprocessing all surrogates in the string, including lone surrogates and valid surrogate pairs. Such strings may be produced by using the "surrogatepass" handler when decoding, or by decomposing astral characters to surrogate pairs.
* process_surrogateescape: reprocessing only lone surrogates in the U+DC80 to U+DCFF range, with other surrogate pairs or lone surrogates triggering UnicodeTranslateError. Such strings may be produced by using the "surrogateescape" error handler when decoding.
* process_astrals: reprocessing all code points in the astral plane.

These seem to cover the essentials to me, and I changed the proposed prefix to "process_*" based on the idea of documentating them as preprocessing and postprocessing steps for encoding and decoding.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 11:40:16 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 27 Sep 2015 09:40:16 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <20150927094012.94123.23598@psf.io>


Roundup Robot added the comment:

New changeset 892b4f029ac6 by Victor Stinner in branch 'default':
Issue #25220: Fix Lib/test/autotest.py
https://hg.python.org/cpython/rev/892b4f029ac6

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 11:41:16 2015
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 27 Sep 2015 09:41:16 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <1443346876.92.0.363580237332.issue25220@psf.upfronthosting.co.za>


STINNER Victor added the comment:

test_regrtest.patch: add tests for the 8 (!) ways to run the Python test suite.

TODO:
* try test on Windows
* maybe test also PCbuild/rt.bat on Windows

----------
Added file: http://bugs.python.org/file40596/test_regrtest.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 12:38:41 2015
From: report at bugs.python.org (Bar Harel)
Date: Sun, 27 Sep 2015 10:38:41 +0000
Subject: [issue25177] OverflowError in statistics.mean when summing large
 floats
In-Reply-To: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za>
Message-ID: <1443350321.44.0.865788319729.issue25177@psf.upfronthosting.co.za>


Bar Harel added the comment:

Alright, I issued a fix, now testing it

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 12:44:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 27 Sep 2015 10:44:55 +0000
Subject: [issue25209] Append space after completed keywords
In-Reply-To: <1442870714.02.0.814978155097.issue25209@psf.upfronthosting.co.za>
Message-ID: <20150927104452.3670.1256@psf.io>


Roundup Robot added the comment:

New changeset f64ec4aac935 by Serhiy Storchaka in branch 'default':
Issue #25209: rlcomplete now can add a space or a colon after completed keyword.
https://hg.python.org/cpython/rev/f64ec4aac935

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 12:44:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 27 Sep 2015 10:44:55 +0000
Subject: [issue25011] Smarter rl complete: hide private and special names
In-Reply-To: <1441488567.65.0.369817501077.issue25011@psf.upfronthosting.co.za>
Message-ID: <20150927104452.3670.37096@psf.io>


Roundup Robot added the comment:

New changeset 4dbb315fe667 by Serhiy Storchaka in branch 'default':
Issue #25011: rlcomplete now omits private and special attribute names unless
https://hg.python.org/cpython/rev/4dbb315fe667

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 12:47:57 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 10:47:57 +0000
Subject: [issue25209] Append space after completed keywords
In-Reply-To: <1442870714.02.0.814978155097.issue25209@psf.upfronthosting.co.za>
Message-ID: <1443350877.4.0.113474363639.issue25209@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your review Martin. Hope to see your patch for completing import statement.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 12:48:14 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 10:48:14 +0000
Subject: [issue25011] Smarter rl complete: hide private and special names
In-Reply-To: <1441488567.65.0.369817501077.issue25011@psf.upfronthosting.co.za>
Message-ID: <1443350894.2.0.699843978067.issue25011@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 14:32:15 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 27 Sep 2015 12:32:15 +0000
Subject: [issue18814] Add utilities to "clean" surrogate code points from
 strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1443357135.73.0.275136223562.issue18814@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

As far as the rationale for adding the functions at all goes, my main interest is still in having somewhere in the codecs module documentation to *define the problem*, and to my mind that entails also offering a simple way to do the relevant pre-/post-processing.

The nice aspect of building any related capabilities atop the standard error handlers is that it also means that third party modules can provide custom error handlers to support further escaping techniques, and those will also be available for use in decoding and encoding operations, rather than being specific to pre-/post-processing of the data.

However, it's also the case that we're generally going to be talking about the combination of encoding misconfiguration *and* processing data that gets potentially corrupted by the misconfiguration *and* doing something with it that isn't already handled by a surrogateescape round-trip, which is why I suspect in practice most applications are going to be able to get away with ignoring the problem entirely (especially with C.UTF-8 support coming to Fedora 24, so the Fedora/RHEL/CentOS ecosystem will be joining the Debian/Ubuntu ecosystem in offering that by default)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 16:03:55 2015
From: report at bugs.python.org (Bar Harel)
Date: Sun, 27 Sep 2015 14:03:55 +0000
Subject: [issue25177] OverflowError in statistics.mean when summing large
 floats
In-Reply-To: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za>
Message-ID: <1443362635.92.0.273196997428.issue25177@psf.upfronthosting.co.za>


Bar Harel added the comment:

Alright, this patch passed all tests.
I've changed the function sum to include a new parameter called fraction which decides whether to return a fraction or not. It might be useful in more scenarios due to the fact fractions are more accurate.
I'm still unsure why not to support mixed types, as we can just again, return a mixed type as fraction but I left it like this in order not to cause unexpected behavior. I still think however that supporting mixed types should be fine as the bottleneck regarding precision is fraction, which is used as the base for conversion anyway.
I've added a few doctests on the way including the float max and min, which did not previously pass on the current implementation, and changed the unittest to match.

----------
Added file: http://bugs.python.org/file40597/Issue25177_rev2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 16:09:16 2015
From: report at bugs.python.org (Abrantes Araujo Silva Filho)
Date: Sun, 27 Sep 2015 14:09:16 +0000
Subject: [issue25247] Tkinter modules built successfully but removed because
 they could not be imported
Message-ID: <1443362955.97.0.479963022327.issue25247@psf.upfronthosting.co.za>


New submission from Abrantes Araujo Silva Filho:

I'm trying to compile Python 3.5 on a CentOS 7.1, with TCL 8.6.4, but make always give me the following message:

*** WARNING: renaming "_tkinter" since importing it failed: build/lib.linux-x86_64-3.5/_tkinter.cpython-35m-x86_64-linux-gnu.so: undefined symbol: Tcl_GetCharLength

Following modules built successfully but were removed because they could not be imported:
_tkinter


The configure command was the following (both, Tcl and Tk are installed under /usr/local/lib/tcl8.6.4):

CXX=g++ ./configure --prefix=/usr/local/python3 --enable-shared --enable-loadable-sqlite-extensions --enable-ipv6 --with-tcltk-includes="-I/usr/local/lib/tcl8.6.4/include" --with-tcltk-libs="-L/usr/local/lib/tcl8.6.4/lib"

I could not found a solution for this issue, and I do not know if this is a bug.

----------
components: Tkinter
messages: 251703
nosy: abrantesasf
priority: normal
severity: normal
status: open
title: Tkinter modules built successfully but removed because they could not be imported
type: compile error
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 16:24:28 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 14:24:28 +0000
Subject: [issue25247] Tkinter modules built successfully but removed because
 they could not be imported
In-Reply-To: <1443362955.97.0.479963022327.issue25247@psf.upfronthosting.co.za>
Message-ID: <1443363868.4.0.317012327857.issue25247@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Do you have other Tcl versions in 8.6 branch installed? Try to set

export LD_LIBRARY_PATH=/usr/local/lib/tcl8.6.4/lib

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 17:23:57 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 15:23:57 +0000
Subject: [issue25248] Discrepancy in unpickling integers with protocol 0
Message-ID: <1443367436.97.0.896349138795.issue25248@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There are discrepancies between Python 2 and Python 3, Python and C implementations, INT and LONG opcodes when unpickle integer with protocol 0.

Python 2.7:

>>> import pickle, cPickle
>>> pickle.loads(b'I010\n.')
10
>>> cPickle.loads(b'I010\n.')
8
>>> pickle.loads(b'L010\n.')
8L
>>> cPickle.loads(b'L010\n.')
8L

Python 3.6:

>>> import pickle
>>> pickle.loads(b'I010\n.')
8
>>> pickle._loads(b'I010\n.')
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/serhiy/py/cpython/Lib/pickle.py", line 1557, in _loads
    encoding=encoding, errors=errors).load()
  File "/home/serhiy/py/cpython/Lib/pickle.py", line 1039, in load
    dispatch[key[0]](self)
  File "/home/serhiy/py/cpython/Lib/pickle.py", line 1106, in load_int
    val = int(data, 0)
ValueError: invalid literal for int() with base 0: b'010\n'
>>> pickle.loads(b'L010\n.')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: invalid literal for int() with base 0: '010\n'
>>> pickle._loads(b'L010\n.')
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/serhiy/py/cpython/Lib/pickle.py", line 1557, in _loads
    encoding=encoding, errors=errors).load()
  File "/home/serhiy/py/cpython/Lib/pickle.py", line 1039, in load
    dispatch[key[0]](self)
  File "/home/serhiy/py/cpython/Lib/pickle.py", line 1126, in load_long
    self.append(int(val, 0))
ValueError: invalid literal for int() with base 0: b'010'

----------
components: Extension Modules, Library (Lib)
messages: 251705
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Discrepancy in unpickling integers with protocol 0
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 17:34:38 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 27 Sep 2015 15:34:38 +0000
Subject: [issue25248] Discrepancy in unpickling integers with protocol 0
In-Reply-To: <1443367436.97.0.896349138795.issue25248@psf.upfronthosting.co.za>
Message-ID: <1443368078.31.0.367202101192.issue25248@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Is b'I010\n.' actually produced by the pickler, or is it something you contructed yourself?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 18:04:05 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 27 Sep 2015 16:04:05 +0000
Subject: [issue25011] Smarter rl complete: hide private and special names
In-Reply-To: <1441488567.65.0.369817501077.issue25011@psf.upfronthosting.co.za>
Message-ID: <1443369845.46.0.725081171019.issue25011@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
stage: patch review -> resolved

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 18:10:33 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 27 Sep 2015 16:10:33 +0000
Subject: [issue25242] Failed tests for Python 3.5.0 on shared virtual host
In-Reply-To: <1443293857.94.0.352020564349.issue25242@psf.upfronthosting.co.za>
Message-ID: <1443370233.14.0.980785339978.issue25242@psf.upfronthosting.co.za>


R. David Murray added the comment:

That's an interesting possibility regardless of this issue.  That's probably something the test suite *should* take into account, since as people get more careful about security that's something we could see happening more often.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 18:17:44 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 27 Sep 2015 16:17:44 +0000
Subject: [issue18814] Add utilities to "clean" surrogate code points from
 strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1443370664.91.0.0888069203759.issue18814@psf.upfronthosting.co.za>


R. David Murray added the comment:

I also want "detect if there are any surrogates".

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 19:42:37 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 17:42:37 +0000
Subject: [issue25248] Discrepancy in unpickling integers with protocol 0
In-Reply-To: <1443368078.31.0.367202101192.issue25248@psf.upfronthosting.co.za>
Message-ID: <1578203.746zKiEKOp@raxxla>


Serhiy Storchaka added the comment:

No, it is never produced by standard pickler. I'm just interesting, could we 
do something with this, and should we do anything?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 19:53:03 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 27 Sep 2015 17:53:03 +0000
Subject: [issue25248] Discrepancy in unpickling integers with protocol 0
In-Reply-To: <1443367436.97.0.896349138795.issue25248@psf.upfronthosting.co.za>
Message-ID: <1443376383.32.0.42889911506.issue25248@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

If it's not produced in any case, I don't think we should care about it. The only thing we must be careful about is not to crash or open any vulnerabilities.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 20:20:54 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 18:20:54 +0000
Subject: [issue25242] Failed tests for Python 3.5.0 on shared virtual host
In-Reply-To: <1443293857.94.0.352020564349.issue25242@psf.upfronthosting.co.za>
Message-ID: <1443378054.6.0.418417433157.issue25242@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Classification of test failures:

1. test_distutils, test_httpservers, test_shutil, test_subprocess - unable to run an executable or load a library from /tmp. This is likely testing issue, not a bug. We should just detect this situation and skip tests.

2. test_fcntl - likely a restriction of /tmp filesystem (if the test is passed in non-restricted environment). In this case we should just skip the test.

3. test_readline - readline initialization issue (issue19884). This is real bug that already was reported. We trying to fix it (unsuccessfully).

----------
nosy: +ezio.melotti, michael.foord, pitrou
type: compile error -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 20:38:24 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 27 Sep 2015 18:38:24 +0000
Subject: [issue22798] time.mktime doesn't update time.tzname
In-Reply-To: <1415189548.18.0.514821385606.issue22798@psf.upfronthosting.co.za>
Message-ID: <1443379104.48.0.514745125973.issue22798@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Akira,

Would issue22798.diff patch address your issue?

----------
assignee:  -> belopolsky
resolution: not a bug -> 
stage: resolved -> patch review
Added file: http://bugs.python.org/file40598/issue22798.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 20:43:52 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 18:43:52 +0000
Subject: [issue25248] Discrepancy in unpickling integers with protocol 0
In-Reply-To: <1443367436.97.0.896349138795.issue25248@psf.upfronthosting.co.za>
Message-ID: <1443379432.44.0.836564838325.issue25248@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

One funny thing is that the same data can produce different result when unpickled with pickle and cPickle in 2.x. But unlikely it is larger vulnerability than using unpickling at all.

Just FYI:

PyPy 2.2.1:
>>>> import pickle, cPickle
>>>> pickle.loads(b'I010\n.')
10
>>>> cPickle.loads(b'I010\n.')
10
>>>> pickle.loads(b'L010\n.')
8L
>>>> cPickle.loads(b'L010\n.')
8L

Jython 2.5.3:
>>> import pickle, cPickle
>>> pickle.loads('I010\n.')
10
>>> cPickle.loads('I010\n.')
10
>>> pickle.loads('L010L\n.')
8L
>>> cPickle.loads('L010L\n.')
10L

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 20:45:45 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 27 Sep 2015 18:45:45 +0000
Subject: [issue22798] time.mktime doesn't update time.tzname
In-Reply-To: <1415189548.18.0.514821385606.issue22798@psf.upfronthosting.co.za>
Message-ID: <1443379545.18.0.280146142406.issue22798@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Is there any platform where mktime resets global tzname but does not provide tm_zone?  If not, OP's issue is largely theoretical, but I still like MAL's suggestion of using strftime("%Z") as a fall-back.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 20:49:31 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 27 Sep 2015 18:49:31 +0000
Subject: [issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0,
 DstOffset=1
In-Reply-To: <1425688983.27.0.949503850992.issue23600@psf.upfronthosting.co.za>
Message-ID: <1443379771.72.0.415697999502.issue23600@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky :


----------
assignee:  -> belopolsky
stage:  -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 20:59:04 2015
From: report at bugs.python.org (Mark Roseman)
Date: Sun, 27 Sep 2015 18:59:04 +0000
Subject: [issue25198] Idle: improve idle.html help viewer.
In-Reply-To: <1442794067.12.0.0580996406415.issue25198@psf.upfronthosting.co.za>
Message-ID: <1443380344.13.0.0316682985449.issue25198@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Good catch about yview for text widgets!

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 20:59:14 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 18:59:14 +0000
Subject: [issue25099] test_compileall fails when run by unprivileged user on
 installed Python
In-Reply-To: <1442205173.06.0.618332067063.issue25099@psf.upfronthosting.co.za>
Message-ID: <1443380354.15.0.127873779383.issue25099@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added comments on Rietveld.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 21:01:21 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 27 Sep 2015 19:01:21 +0000
Subject: [issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0,
 DstOffset=1
In-Reply-To: <1425688983.27.0.949503850992.issue23600@psf.upfronthosting.co.za>
Message-ID: <1443380481.11.0.970165341618.issue23600@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

It looks like I introduced this bug ~ 5 years ago when I made a switch from integer minutes offset to an arbitrary timedelta.  It's rather amazing that it took so long to discover it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 21:04:27 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 27 Sep 2015 19:04:27 +0000
Subject: [issue22413] Bizarre StringIO(newline="\r\n") translation
In-Reply-To: <1410750243.44.0.979805676788.issue22413@psf.upfronthosting.co.za>
Message-ID: <1443380667.83.0.583769364795.issue22413@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

At this point in time, I don't think it's a good idea to change the semantics at all. Some people might unknowingly rely on the current semantics, and the consequences of a change in 3.6 might be hard to debug.

The larger issue here is that the newline translation layer is meant as an adaptation layer between Python (where a newline is always "\n") and the outside world (where newlines are system-dependent or even file-dependent). But what is the "outside world" with StringIO? The data always comes from and goes to Python. So there is no obviously right decision except, perhaps, the decision not to have newline translation at all.

So I'd just recommend closing this as won't fix.

----------
nosy: +gvanrossum

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 21:35:12 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 19:35:12 +0000
Subject: [issue25203] Incorrect handling MemoryError in
 readline.set_completer_delims
In-Reply-To: <1442853047.02.0.107801341655.issue25203@psf.upfronthosting.co.za>
Message-ID: <1443382512.1.0.130619834999.issue25203@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 21:39:53 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 27 Sep 2015 19:39:53 +0000
Subject: [issue25203] Incorrect handling MemoryError in
 readline.set_completer_delims
In-Reply-To: <1442853047.02.0.107801341655.issue25203@psf.upfronthosting.co.za>
Message-ID: <20150927193950.82662.9705@psf.io>


Roundup Robot added the comment:

New changeset 46aaff5e8945 by Serhiy Storchaka in branch '3.4':
Issue #25203: Failed readline.set_completer_delims() no longer left the
https://hg.python.org/cpython/rev/46aaff5e8945

New changeset d867ca794bdb by Serhiy Storchaka in branch '2.7':
Issue #25203: Failed readline.set_completer_delims() no longer left the
https://hg.python.org/cpython/rev/d867ca794bdb

New changeset 0d3b64bbc82c by Serhiy Storchaka in branch '3.5':
Issue #25203: Failed readline.set_completer_delims() no longer left the
https://hg.python.org/cpython/rev/0d3b64bbc82c

New changeset 48943533965e by Serhiy Storchaka in branch 'default':
Issue #25203: Failed readline.set_completer_delims() no longer left the
https://hg.python.org/cpython/rev/48943533965e

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 21:40:34 2015
From: report at bugs.python.org (Nir Soffer)
Date: Sun, 27 Sep 2015 19:40:34 +0000
Subject: [issue25249] Unneeded and unsafe mkstemp replacement in
 test_subprocess.py
Message-ID: <1443382834.49.0.136619109846.issue25249@psf.upfronthosting.co.za>


New submission from Nir Soffer:

The module define unsafe replacement if tempfile.mkstemp is not available.

This function is available in both master and 2.7 branches.

----------
components: Tests
files: 0001-Remove-unneeded-and-unsafe-mkstemp-replacement.patch
keywords: patch
messages: 251720
nosy: nirs
priority: normal
severity: normal
status: open
title: Unneeded and unsafe mkstemp replacement in test_subprocess.py
versions: Python 2.7, Python 3.6
Added file: http://bugs.python.org/file40599/0001-Remove-unneeded-and-unsafe-mkstemp-replacement.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 21:56:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 19:56:00 +0000
Subject: [issue25184] "python -m pydoc -w" fails in nondecodable directory
In-Reply-To: <1442696845.13.0.851195404942.issue25184@psf.upfronthosting.co.za>
Message-ID: <1443383760.65.0.879722181921.issue25184@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, perhaps using pathlib is more correct. Updated patch uses pathlib. Can you please test it on Windows?

Can filenames on Windows contain lone surrogates?

----------
Added file: http://bugs.python.org/file40600/pydoc_undecodabple_path_2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 21:57:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 19:57:00 +0000
Subject: [issue25203] Incorrect handling MemoryError in
 readline.set_completer_delims
In-Reply-To: <1442853047.02.0.107801341655.issue25203@psf.upfronthosting.co.za>
Message-ID: <1443383820.69.0.0689501955324.issue25203@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 21:57:17 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 19:57:17 +0000
Subject: [issue25184] "python -m pydoc -w" fails in nondecodable directory
In-Reply-To: <1442696845.13.0.851195404942.issue25184@psf.upfronthosting.co.za>
Message-ID: <1443383837.8.0.0903488624126.issue25184@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
nosy: +pitrou

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 22:02:54 2015
From: report at bugs.python.org (Nir Soffer)
Date: Sun, 27 Sep 2015 20:02:54 +0000
Subject: [issue25249] Unneeded and unsafe mkstemp replacement in
 test_subprocess.py
In-Reply-To: <1443382834.49.0.136619109846.issue25249@psf.upfronthosting.co.za>
Message-ID: <1443384174.59.0.87983721572.issue25249@psf.upfronthosting.co.za>


Changes by Nir Soffer :


Added file: http://bugs.python.org/file40601/0001-Remove-unneeded-and-unsafe-mkstemp-replacement-2.7.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 22:10:27 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 20:10:27 +0000
Subject: [issue25093] New 3.5.0 failure in test_tcl on win7
In-Reply-To: <1442200639.15.0.127298727385.issue25093@psf.upfronthosting.co.za>
Message-ID: <1443384627.34.0.430817224766.issue25093@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file40602/testLoadWithUNC_2.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 22:11:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 20:11:09 +0000
Subject: [issue25111] Broken compatibility in FrameSummary equality
In-Reply-To: <1442252923.78.0.0672158797601.issue25111@psf.upfronthosting.co.za>
Message-ID: <1443384669.72.0.613837122482.issue25111@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 22:16:11 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 20:16:11 +0000
Subject: [issue22995] Restrict default pickleability
In-Reply-To: <1417699003.47.0.104663960497.issue22995@psf.upfronthosting.co.za>
Message-ID: <1443384971.09.0.625500288829.issue22995@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could anyone please make a review?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 22:24:54 2015
From: report at bugs.python.org (Matt Hickford)
Date: Sun, 27 Sep 2015 20:24:54 +0000
Subject: [issue25250] AttributeError: 'MSVCCompiler' object has no attribute
 '_MSVCCompiler__version'
Message-ID: <1443385494.46.0.0275925380659.issue25250@psf.upfronthosting.co.za>


New submission from Matt Hickford:

Hi distutils. I wrote a setup.py that conditions on compiler type, following the guide at [1]. I needed to add an extra include when the compiler is an msvc version older than 9.0 (infamously missing stdint.h [2])

Anyway the code I wrote to do this was:

if self.compiler.compiler_type == "msvc" and int(self.compiler._MSVCCompiler__version) <= 9:

Which worked fine on all Python versions (tested 2.7 through 3.4) UNTIL the recent release of Python 3.5. On Python 3.5 I get the error:

AttributeError: 'MSVCCompiler' object has no attribute '_MSVCCompiler__version'

Oh no. My fault I suppose for relying on a private variable. Can you suggest a more reliable way to test "compiler is msvc <= 9.0"? The test should be compatible all Python versions 2.7 through 3.5 so it can safely go in a setup.py

Can you help?

[1] http://stackoverflow.com/a/5192738/284795
[2] https://stackoverflow.com/questions/126279/c99-stdint-h-header-and-ms-visual-studio

----------
components: Distutils
messages: 251724
nosy: Matt.Hickford, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: AttributeError: 'MSVCCompiler' object has no attribute '_MSVCCompiler__version'
type: crash
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 22:53:21 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 27 Sep 2015 20:53:21 +0000
Subject: [issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0,
 DstOffset=1
In-Reply-To: <1425688983.27.0.949503850992.issue23600@psf.upfronthosting.co.za>
Message-ID: <1443387201.67.0.571693121979.issue23600@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Attaching a patch that should fix the issue.

----------
keywords: +patch
stage: needs patch -> commit review
versions: +Python 3.4, Python 3.5
Added file: http://bugs.python.org/file40603/issue23600.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 22:56:48 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 27 Sep 2015 20:56:48 +0000
Subject: [issue22413] Bizarre StringIO(newline="\r\n") translation
In-Reply-To: <1410750243.44.0.979805676788.issue22413@psf.upfronthosting.co.za>
Message-ID: <1443387408.1.0.988656646417.issue22413@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Agreed we shouldn't change this. It looks like the behavior is consistent if you consider `a = StringIO(stuff, newline=...)` merely a shorthand for `a = StringIO(newline=...); a.write(stuff)`.

I understand you would like to have a way to set the internal buffer directly, without newline translation; to support that we'd have to add a new argument. Although really, it's probably better to just do the \r\n translation in your app anyway.

You're very unlikely to ever need \r translation -- that was last seen on MacOS 9, which has been dead for 14 years now. Fighting \r\n or pretending it's a Windows-only thing is pretty hopeless -- most text-based internet protocols (like HTTP) require it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 23:00:57 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 27 Sep 2015 21:00:57 +0000
Subject: [issue22413] Bizarre StringIO(newline="\r\n") translation
In-Reply-To: <1410750243.44.0.979805676788.issue22413@psf.upfronthosting.co.za>
Message-ID: <1443387657.04.0.851184307961.issue22413@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ok, I'm closing, then.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Sun Sep 27 23:52:06 2015
From: report at bugs.python.org (Abrantes Araujo Silva Filho)
Date: Sun, 27 Sep 2015 21:52:06 +0000
Subject: [issue25247] Tkinter modules built successfully but removed because
 they could not be imported
In-Reply-To: <1443362955.97.0.479963022327.issue25247@psf.upfronthosting.co.za>
Message-ID: <1443390726.35.0.31195376485.issue25247@psf.upfronthosting.co.za>


Abrantes Araujo Silva Filho added the comment:

No, I do not have any other Tcl version on my system, and my LD_LIBRARY_PATH alredy points to Tcl directory.

The problem with tkinter persist even if I explicity export LD_LIBRARY_PATH before the compilation.

Any other ideas?

Thanks!

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 00:14:23 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 22:14:23 +0000
Subject: [issue24848] Warts in UTF-7 error handling
In-Reply-To: <1439364965.73.0.526700604341.issue24848@psf.upfronthosting.co.za>
Message-ID: <1443392063.78.0.628256710878.issue24848@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch fixes also a bug in _PyUnicodeWriter. Other affected encoding is "unicode-escape":

>>> br'\u;'.decode('unicode-escape', 'replace')
'?;'

----------
Added file: http://bugs.python.org/file40604/utf7_error_handling-2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 00:15:20 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Sep 2015 22:15:20 +0000
Subject: [issue24848] Warts in UTF-7 error handling
In-Reply-To: <1439364965.73.0.526700604341.issue24848@psf.upfronthosting.co.za>
Message-ID: <1443392120.91.0.970720223266.issue24848@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
nosy: +pitrou

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 00:17:44 2015
From: report at bugs.python.org (Matt Hickford)
Date: Sun, 27 Sep 2015 22:17:44 +0000
Subject: [issue25251] Unknown MS Compiler version 1900
Message-ID: <1443392264.43.0.443478210283.issue25251@psf.upfronthosting.co.za>


New submission from Matt Hickford:

Hi distutils. I previously used compiler=mingw32 with success. Today I installed Visual Studio 2015. Now compiler=mingw32 gives me an error

File "c:\python35\lib\distutils\cygwinccompiler.py", line 86, in get_msvcr
    raise ValueError("Unknown MS Compiler version %s " % msc_ver)
ValueError: Unknown MS Compiler version 1900

Any ideas? I don't understand why what msvc I have installed affects build with mingw32

----------
components: Distutils
messages: 251730
nosy: Matt.Hickford, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: Unknown MS Compiler version 1900
type: crash
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 00:26:29 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 27 Sep 2015 22:26:29 +0000
Subject: [issue25184] "python -m pydoc -w" fails in nondecodable directory
In-Reply-To: <1442696845.13.0.851195404942.issue25184@psf.upfronthosting.co.za>
Message-ID: <1443392789.68.0.377916580939.issue25184@psf.upfronthosting.co.za>


Martin Panter added the comment:

I don?t have much to do with Windows, but I understand we don?t support surrogate-escaped bytes there. E.g. see  and sys.getfilesystemencoding(). However I suspect your first patch would have failed on Windows doing os.fsencode(TESTFN_UNENCODABLE); apparently it cannot represent all possible file names in bytes. The second patch doesn?t call fsencode() so this shouldn?t be a problem.

Your tests do not test that the output is valid Unicode without surrogates. With your first patch applied, when pydoc wrote the HTML to a UTF-8 disk file, I got the error:

  File "/media/disk/home/proj/python/cpy\udcffthon/Lib/pydoc.py", line 2626, in cli
    writedoc(arg)
  File "/media/disk/home/proj/python/cpy\udcffthon/Lib/pydoc.py", line 1659, in writedoc
    file.write(page)
UnicodeEncodeError: 'utf-8' codec can't encode character '\udcff' in position 674: surrogates not allowed

I have been working on an alternative patch using my IRI (Unicode URLs) proposal for ?file:? links, and ?surrogatepass? for HTTP links. But I am also trying to fix some related problems with the built-in HTTP server, and the unit tests are a bit tricky.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 00:34:35 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 27 Sep 2015 22:34:35 +0000
Subject: [issue25252] Hard-coded line ending in
 asyncio.streams.StreamReader.readline
Message-ID: <1443393275.12.0.244806076878.issue25252@psf.upfronthosting.co.za>


New submission from Eric V. Smith:

A group of us (all added as nosy) spent part of the day working on issue 25008 (write an smtpd with asyncio).

We came across some code that contained a copy of StreamReader.readline, but it used b'\r\n' instead of b'\n' for a line ending character. In StreamReader.readline, '\n' is hard coded.

I'd like to propose that the line ending be passed in to readline, with a default of b'\n', and that multi-byte line ending sequences be explicitly supported.

Further, I'm hoping we can treat this as a bug and not a feature request, so that it can go in to 3.4 and 3.5. Adding a default parameter will be backward compatible.

----------
components: asyncio
messages: 251732
nosy: akuchling, barry, eric.smith, gvanrossum, haypo, jason.coombs, r.david.murray, yselivanov
priority: normal
severity: normal
status: open
title: Hard-coded line ending in asyncio.streams.StreamReader.readline
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 01:26:02 2015
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 27 Sep 2015 23:26:02 +0000
Subject: [issue25250] AttributeError: 'MSVCCompiler' object has no attribute
 '_MSVCCompiler__version'
In-Reply-To: <1443385494.46.0.0275925380659.issue25250@psf.upfronthosting.co.za>
Message-ID: <1443396362.18.0.523236645873.issue25250@psf.upfronthosting.co.za>


Changes by Zachary Ware :


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 01:29:22 2015
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 27 Sep 2015 23:29:22 +0000
Subject: [issue25251] Unknown MS Compiler version 1900
In-Reply-To: <1443392264.43.0.443478210283.issue25251@psf.upfronthosting.co.za>
Message-ID: <1443396562.34.0.582645287989.issue25251@psf.upfronthosting.co.za>


Changes by Zachary Ware :


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
type: crash -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 01:33:03 2015
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 27 Sep 2015 23:33:03 +0000
Subject: [issue25250] AttributeError: 'MSVCCompiler' object has no attribute
 '_MSVCCompiler__version'
In-Reply-To: <1443385494.46.0.0275925380659.issue25250@psf.upfronthosting.co.za>
Message-ID: <1443396783.58.0.00220452364706.issue25250@psf.upfronthosting.co.za>


Changes by Zachary Ware :


----------
type: crash -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 01:34:00 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 27 Sep 2015 23:34:00 +0000
Subject: [issue25252] Hard-coded line ending in
 asyncio.streams.StreamReader.readline
In-Reply-To: <1443393275.12.0.244806076878.issue25252@psf.upfronthosting.co.za>
Message-ID: <1443396840.68.0.133668118083.issue25252@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Hm... Since \r\n ends with \n, what exactly would it help to pass in \r\n as the desired line ending? In either case the entire line (including the \r\n) would be returned.

Unless you have a need for treating foo\nbar\r\n as a single line? (But why would you?)  I'm guessing I'm missing something?

No worries about the bug/feature distinction, for asyncio we can do whatever we want (it's still provisional in 3.5).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 02:10:32 2015
From: report at bugs.python.org (Tim Peters)
Date: Mon, 28 Sep 2015 00:10:32 +0000
Subject: [issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0,
 DstOffset=1
In-Reply-To: <1425688983.27.0.949503850992.issue23600@psf.upfronthosting.co.za>
Message-ID: <1443399032.55.0.344069717474.issue23600@psf.upfronthosting.co.za>


Tim Peters added the comment:

Patch looks good to me!  Thanks :-)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 02:17:01 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Sep 2015 00:17:01 +0000
Subject: [issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0,
 DstOffset=1
In-Reply-To: <1425688983.27.0.949503850992.issue23600@psf.upfronthosting.co.za>
Message-ID: <1443399421.3.0.0670475292076.issue23600@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Thanks, Tim.  Now I need to figure out how to commit to multiple branches.  This goes to 3.4 through 3.6, right? or just to 3.5 and 3.6.

----------
components: +Extension Modules -Library (Lib)

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 02:28:14 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Sep 2015 00:28:14 +0000
Subject: [issue25008] Deprecate smtpd (based on deprecated asyncore/asynchat):
 write a new smtp server with asyncio
In-Reply-To: <1441472893.95.0.412611892234.issue25008@psf.upfronthosting.co.za>
Message-ID: <1443400094.57.0.00802293185928.issue25008@psf.upfronthosting.co.za>


R. David Murray added the comment:

Here is a proof of concept port of smtpd to asyncio.  Obviously I'm not suggesting we commit this patch (it isn't complete...the tests don't run).  Instead I'm posting it as an outgrowth the of the sprint that was conducted today.  The DC team took a different tack, so I'm not submitting this as a patch to their repo, and since it is useful to look at the diff against default, it seems appropriate to post it here.

The advantage of this port is that it uses the existing smtpd protocol code, which is the "field tested" code.  Of course, I did have to change how the data is turned from bytes into lines, so I may have introduced some bugs.

As discussed, *using* an asyncio based smtpd has a different calling API than using the asynchat one.  However, the *pattern* is similar, so it may not be crazy to replace smtpd with the cleaned up version of this patch, exactly because the number of places this is used is relatively small and mostly in test code.  IMO it's a better option than deleting smtpd from the stdlib.

The code as is can be run using its CLI.  I tested it via telnet using the DebuggingServer and hand coding an email...for some reason I can't currently import smtplib (Enum errors in socket), so I didn't test it with smtplib, but it should work.

----------
keywords: +patch
Added file: http://bugs.python.org/file40605/aiosmtpd.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 02:41:20 2015
From: report at bugs.python.org (Tim Peters)
Date: Mon, 28 Sep 2015 00:41:20 +0000
Subject: [issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0,
 DstOffset=1
In-Reply-To: <1425688983.27.0.949503850992.issue23600@psf.upfronthosting.co.za>
Message-ID: <1443400880.65.0.464177908645.issue23600@psf.upfronthosting.co.za>


Tim Peters added the comment:

Afraid that's a question for python-dev - I lost track of the active branches over year ago :-(

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 02:59:36 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 28 Sep 2015 00:59:36 +0000
Subject: [issue25252] Hard-coded line ending in
 asyncio.streams.StreamReader.readline
In-Reply-To: <1443393275.12.0.244806076878.issue25252@psf.upfronthosting.co.za>
Message-ID: <1443401976.61.0.962493893977.issue25252@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Good point. I quick test of our sample code shows that calling regular readline to read up to '\n' does in fact work correctly. Let me do some more testing, then I'll likely close this.

Thanks!

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 03:14:00 2015
From: report at bugs.python.org (paul j3)
Date: Mon, 28 Sep 2015 01:14:00 +0000
Subject: [issue19462] Add remove_argument() method to argparse.ArgumentParser
In-Reply-To: <1383240778.45.0.779487488351.issue19462@psf.upfronthosting.co.za>
Message-ID: <1443402840.2.0.353991821351.issue19462@psf.upfronthosting.co.za>


paul j3 added the comment:

I realized while answering a Stackoverflow question that the resolve method has the pieces for removing an Action from the parser.  It removes an existing Action so that the new, conflicting one, can replace it.

It's meant to be used with flagged arguments.  If `arg1` is an action with one option_string, it can be removed with:

    parser._handle_conflict_resolve(None, [('--arg1', arg1)])

If it is a positional, this call seems to be sufficient:

    arg1.container._remove_action(arg1)

http://stackoverflow.com/a/32809642/901925

Beyond answering this question I haven't tested the idea.  If there's more interest I could explore it more.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 04:23:56 2015
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 28 Sep 2015 02:23:56 +0000
Subject: [issue18814] Add utilities to "clean" surrogate code points from
 strings
In-Reply-To: <1443370664.91.0.0888069203759.issue18814@psf.upfronthosting.co.za>
Message-ID: <20150928022344.GL23642@ando.pearwood.info>


Steven D'Aprano added the comment:

On Sun, Sep 27, 2015 at 04:17:45PM +0000, R. David Murray wrote:
> 
> I also want "detect if there are any surrogates".

I think that's useful enough it should be a str method. Here's a 
pure-Python implementation:

def is_surrogate(s):
    return any(0xD800 <= ord(c) <= 0xDFFF for c in s)

The actual Flexible String Representation implementation can be even 
more efficient. All-ASCII and all-Latin1 strings cannot possibly include 
surrogates, so is_surrogate will be a constant-time operation.

(If we care about making this a constant-time operation for all 
strings, the constructor could set a flag on the string object. Since 
the constructor has to walk the string anyway, I don't think that will 
cost much time-wise.)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 04:24:20 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Sep 2015 02:24:20 +0000
Subject: [issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0,
 DstOffset=1
In-Reply-To: <1425688983.27.0.949503850992.issue23600@psf.upfronthosting.co.za>
Message-ID: <1443407060.64.0.833432682226.issue23600@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I give up. Somehow my changes conflict with 

parent:      98335:0d3b64bbc82c
user:        Serhiy Storchaka 
date:        Sun Sep 27 22:38:33 2015 +0300
summary:     Issue #25203: Failed readline.set_completer_delims() no longer left the

and my knowledge of hg is not enough to get out.  When are we switching to git?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 04:26:34 2015
From: report at bugs.python.org (Tony)
Date: Mon, 28 Sep 2015 02:26:34 +0000
Subject: [issue25253] AttributeError: 'Weather' object has no attribute 'dom'
Message-ID: <1443407194.23.0.284487454334.issue25253@psf.upfronthosting.co.za>


New submission from Tony:

The source code for ctw (CurseTheWeather) can be found here: https://github.com/tdy/ctw

Running `ctw USCA0987` or `ctw --nometric USCA0987` (happens regardless of location) results in an attribute error with Python 3.4.3. Running `ctw` by itself does print a *Welcome to "Curse the Weather" Version 0.6* message.

Traceback (most recent call last):
  File "/usr/bin/ctw", line 378, in 
    curses.wrapper(main)
  File "/usr/lib/python3.4/curses/__init__.py", line 94, in wrapper
    return func(stdscr, *args, **kwds)
  File "/usr/bin/ctw", line 283, in main
    update(stdscr)
  File "/usr/bin/ctw", line 250, in update
    weather = weatherfeed.Weather(location, metric)
  File "/usr/lib/python3.4/weatherfeed.py", line 40, in __init__
    self.dom = parseString(self._getData())
  File "/usr/lib/python3.4/xml/dom/minidom.py", line 1970, in parseString
    return expatbuilder.parseString(string)
  File "/usr/lib/python3.4/xml/dom/expatbuilder.py", line 925, in parseString
    return builder.parseString(string)
  File "/usr/lib/python3.4/xml/dom/expatbuilder.py", line 223, in parseString
    parser.Parse(string, True)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 64, column 26
Exception ignored in: >
Traceback (most recent call last):
  File "/usr/lib/python3.4/weatherfeed.py", line 44, in __del__
    self.dom.unlink()
AttributeError: 'Weather' object has no attribute 'dom'

I did notice the API URL in weatherfeed.py gives a Bad Request error for:

urlHandle = urllib.request.urlopen('http://xoap.weather.com/weather/local/%s?cc=1&dayf=5&prod=xoap&link=xoap&unit=%s&par=1003666583&key=4128909340a9b2fc'

I also noticed the weather.com API now redirects to wunderground.com so I registered a new API and updated the URL in weatherfeed.py only to still get the same AttributeError. 

The new API is something like http://api.wunderground.com/api/APIKEY/conditions/q/CA/San_Francisco.json

----------
components: Library (Lib), XML
messages: 251742
nosy: tc
priority: normal
severity: normal
status: open
title: AttributeError: 'Weather' object has no attribute 'dom'
type: crash
versions: Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 04:35:34 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 28 Sep 2015 02:35:34 +0000
Subject: [issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0,
 DstOffset=1
In-Reply-To: <1425688983.27.0.949503850992.issue23600@psf.upfronthosting.co.za>
Message-ID: <20150928023531.81639.76925@psf.io>


Roundup Robot added the comment:

New changeset ff68705c56a8 by Alexander Belopolsky in branch '3.4':
Closes issue #23600: Wrong results from tzinfo.fromutc().
https://hg.python.org/cpython/rev/ff68705c56a8

New changeset c706c062f545 by Alexander Belopolsky in branch '3.5':
Closes issue #23600: Wrong results from tzinfo.fromutc().
https://hg.python.org/cpython/rev/c706c062f545

New changeset 4879c10ce982 by Alexander Belopolsky in branch 'default':
Closes issue #23600: Wrong results from tzinfo.fromutc().
https://hg.python.org/cpython/rev/4879c10ce982

New changeset cbcf82f92c25 by Alexander Belopolsky in branch '3.4':
Closes issue #23600: Wrong results from tzinfo.fromutc().
https://hg.python.org/cpython/rev/cbcf82f92c25

New changeset 848d665bc312 by Alexander Belopolsky in branch '3.5':
Closes issue #23600: Wrong results from tzinfo.fromutc().
https://hg.python.org/cpython/rev/848d665bc312

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 04:39:30 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Sep 2015 02:39:30 +0000
Subject: [issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0,
 DstOffset=1
In-Reply-To: <1425688983.27.0.949503850992.issue23600@psf.upfronthosting.co.za>
Message-ID: <1443407970.62.0.324344118052.issue23600@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

OK, I have no idea how I managed to create two commits in 3.4 and 3.5 and loose the NEWS entry in the end.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 04:51:52 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 28 Sep 2015 02:51:52 +0000
Subject: [issue24972] IDLE: revisit text highlighting for inactive windows on
 win32
In-Reply-To: <1441047261.05.0.292381389884.issue24972@psf.upfronthosting.co.za>
Message-ID: <20150928025149.31201.56143@psf.io>


Roundup Robot added the comment:

New changeset 4b3356f1a261 by Terry Jan Reedy in branch '2.7':
Issue #24972: Inactive selection background now matches active selection
https://hg.python.org/cpython/rev/4b3356f1a261

New changeset 70c01dd35100 by Terry Jan Reedy in branch '3.4':
Issue #24972: Inactive selection background now matches active selection
https://hg.python.org/cpython/rev/70c01dd35100

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 05:16:01 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 28 Sep 2015 03:16:01 +0000
Subject: [issue25254] Idle: debugger source line highlighting fails again
Message-ID: <1443410161.14.0.45288371975.issue25254@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Re-occurrence of #14146. On that issue, msg225380, 2014-08-15, I said "Debugger source line highlighting works fine." I am really sure it was true when I posted previously, 2013-05-29.  In 3.4.3, Feb 24 2015, it is not working.  Ditto for 2.7.10 and 3.5.0, released subsequently, and repository versions of 2.7 and 3.4,  The problem is not the fix in #14146, which I tested separately before replacing it in #24972.

----------
components: IDLE
messages: 251746
nosy: markroseman, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Idle: debugger source line highlighting fails again
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 05:25:15 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 28 Sep 2015 03:25:15 +0000
Subject: [issue24972] IDLE: revisit text highlighting for inactive windows on
 win32
In-Reply-To: <1441047261.05.0.292381389884.issue24972@psf.upfronthosting.co.za>
Message-ID: <1443410715.3.0.225082790084.issue24972@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I first testing the workaround by selecting text and then clicking on another window, and the highlight stayed.  I commented out "self._highlight_workaround()", quit, started again, tested again, and the highlight disappeared.  I added the new line above, retested, and the hightlight stayed.

Debugger source highlighting again does not work for me on Win7 in any installed or repository version, before or after the patch. See #25254. The patch does immediately fix at least part of the find issue. I will review them later.

While the report above implies that I committed to 3.4 and merged forward, there is a screw-up in the repository that prevented merging, so I backed out the 3.4 patch before pushing.  So only 2.7 is patched and this issue is not done.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 05:30:17 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 28 Sep 2015 03:30:17 +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: <1443411017.79.0.22584897101.issue14146@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The workaround function added in this issue is replaced in #24972 with the Text widget inactiveselectbackground option.  In the course of testing, I discovered that while the function still works, debugger source highlighting no longer does, at least not on my machine.  I opened new issue #25254.  On the other hand, find seems to be working better.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 08:48:24 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 28 Sep 2015 06:48:24 +0000
Subject: [issue25253] AttributeError: 'Weather' object has no attribute 'dom'
In-Reply-To: <1443407194.23.0.284487454334.issue25253@psf.upfronthosting.co.za>
Message-ID: <1443422904.72.0.418613836853.issue25253@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I don't think this is a bug of Python. You should check your own
application to make sure you are parsing the right XML.

I run your code with the old uri and get the same traceback. The
cause is you are using xml parser to parse a html document which
is error prone, since the api is out-of-date and return a html
document.

I don't know what happens about the new api since I have no KEY
and can not do the experiment. But from the api you give,
what you will retrieve is a json. Surly parse it with a xml parse
leads to error and the attribute dom won't be created.

----------
nosy: +xiang.zhang

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 09:21:22 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 28 Sep 2015 07:21:22 +0000
Subject: [issue23640] int.from_bytes() is broken for subclasses
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1443424882.86.0.103758083754.issue23640@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are similar issues with Decimal.from_float() (C implementation only), chain.from_iterable(), epoll.fromfd() and kqueue.fromfd(). All these alternative constructors don't call __new__ or __init__.

But float.fromhex() calls the constructor.

>>> import enum
>>> class M(float, enum.Enum):
...     PI = 3.14
... 
>>> M.PI

>>> M.fromhex((3.14).hex())

>>> M.fromhex((2.72).hex())
Traceback (most recent call last):
File "", line 1, in 
File "/home/serhiy/py/cpython/Lib/enum.py", line 241, in __call__
    return cls.__new__(cls, value)
File "/home/serhiy/py/cpython/Lib/enum.py", line 476, in __new__
    raise ValueError("%r is not a valid %s" % (value, cls.__name__))
ValueError: 2.72 is not a valid M

And this behavior looks correct to me.

----------
nosy: +facundobatista, mark.dickinson, rhettinger, skrah

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 09:26:06 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 28 Sep 2015 07:26:06 +0000
Subject: [issue23640] int.from_bytes() is broken for subclasses
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1443425166.9.0.896572193588.issue23640@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is simplified Bruno's patch with additional tests for float, int, bool and enum. But I'm not sure that correct solution is so simple.

----------
Added file: http://bugs.python.org/file40606/0002-int.from_bytes-calls-constructor-for-subclasses.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 09:30:20 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Sep 2015 07:30:20 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <1443425420.22.0.237440919588.issue25220@psf.upfronthosting.co.za>


STINNER Victor added the comment:

test_regrtest-2.patch: add tests for -u, -r, --randseed and --fromfile command line options.

----------
Added file: http://bugs.python.org/file40607/test_regrtest-2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 10:05:18 2015
From: report at bugs.python.org (phelix bitcoin)
Date: Mon, 28 Sep 2015 08:05:18 +0000
Subject: [issue25255] Security of CPython Builds
Message-ID: <1443427518.11.0.403449402832.issue25255@psf.upfronthosting.co.za>


New submission from phelix bitcoin:

A description of the build and release process for CPython binaries (e.g. for Windows) would be great. Maybe I am missing something? I could not find any information other than the 14 years old PEP 101 which says: "Notify the experts that they can start building binaries." 

E.g. how is it ensured there are no backdoors in the binaries?

Background: For the Namecoin project we are currently discussing the potential necessity of reproducible builds.

----------
assignee: docs at python
components: Build, Devguide, Documentation, Windows
messages: 251753
nosy: docs at python, ezio.melotti, paul.moore, phelix bitcoin, steve.dower, tim.golden, willingc, zach.ware
priority: normal
severity: normal
status: open
title: Security of CPython Builds
type: enhancement

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 10:17:14 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 28 Sep 2015 08:17:14 +0000
Subject: [issue24972] IDLE: revisit text highlighting for inactive windows on
 win32
In-Reply-To: <1441047261.05.0.292381389884.issue24972@psf.upfronthosting.co.za>
Message-ID: <20150928081711.11684.17646@psf.io>


Roundup Robot added the comment:

New changeset 2445750029df by Terry Jan Reedy in branch '3.4':
Issue #24972: Inactive selection background now matches active selection
https://hg.python.org/cpython/rev/2445750029df

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 10:19:34 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 28 Sep 2015 08:19:34 +0000
Subject: [issue24972] IDLE: revisit text highlighting for inactive windows on
 win32
In-Reply-To: <1441047261.05.0.292381389884.issue24972@psf.upfronthosting.co.za>
Message-ID: <1443428374.32.0.256295349817.issue24972@psf.upfronthosting.co.za>


Changes by Terry J. Reedy :


----------
assignee:  -> terry.reedy
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 10:53:31 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 28 Sep 2015 08:53:31 +0000
Subject: [issue24972] IDLE: revisit text highlighting for inactive windows on
 win32
In-Reply-To: <1441047261.05.0.292381389884.issue24972@psf.upfronthosting.co.za>
Message-ID: <20150928085328.3648.69268@psf.io>


Roundup Robot added the comment:

New changeset 45955adc2ed2 by Terry Jan Reedy in branch '2.7':
Issue #24972: New option is only valid in tk 8.5+.
https://hg.python.org/cpython/rev/45955adc2ed2

New changeset 460e6e6fb09a by Terry Jan Reedy in branch '3.4':
Issue #24972: New option is only valid in tk 8.5+.
https://hg.python.org/cpython/rev/460e6e6fb09a

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 12:03:36 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 28 Sep 2015 10:03:36 +0000
Subject: [issue25253] AttributeError: 'Weather' object has no attribute 'dom'
In-Reply-To: <1443407194.23.0.284487454334.issue25253@psf.upfronthosting.co.za>
Message-ID: <1443434616.46.0.229887219656.issue25253@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report, but this looks like a bug in the cfw project. Please report it to the ctw bug tracker.

----------
nosy: +berker.peksag
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 12:34:26 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 28 Sep 2015 10:34:26 +0000
Subject: [issue25249] Unneeded and unsafe mkstemp replacement in
 test_subprocess.py
In-Reply-To: <1443382834.49.0.136619109846.issue25249@psf.upfronthosting.co.za>
Message-ID: <20150928103419.98360.53655@psf.io>


Roundup Robot added the comment:

New changeset 23f4daf7a211 by Berker Peksag in branch '3.4':
Issue #25249: Remove unneeded mkstemp helper in test_subprocess
https://hg.python.org/cpython/rev/23f4daf7a211

New changeset 4cd3027ffc34 by Berker Peksag in branch '3.5':
Issue #25249: Remove unneeded mkstemp helper in test_subprocess
https://hg.python.org/cpython/rev/4cd3027ffc34

New changeset e863c8760501 by Berker Peksag in branch 'default':
Issue #25249: Remove unneeded mkstemp helper in test_subprocess
https://hg.python.org/cpython/rev/e863c8760501

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 12:35:05 2015
From: report at bugs.python.org (Matt Hickford)
Date: Mon, 28 Sep 2015 10:35:05 +0000
Subject: [issue25251] Unknown MS Compiler version 1900
In-Reply-To: <1443396562.37.0.949871528098.issue25251@psf.upfronthosting.co.za>
Message-ID: 


Matt Hickford added the comment:

Here's a patch that helped on my computer

On 28 September 2015 at 00:29, Zachary Ware  wrote:

>
> Changes by Zachary Ware :
>
>
> ----------
> components: +Windows
> nosy: +paul.moore, steve.dower, tim.golden, zach.ware
> type: crash -> behavior
>
> _______________________________________
> Python tracker 
> 
> _______________________________________
>

----------
keywords: +patch
Added file: http://bugs.python.org/file40608/patch.diff

_______________________________________
Python tracker 

_______________________________________
-------------- next part --------------
--- cygwinccompiler.py
+++ cygwinccompiler.py
@@ -82,7 +82,18 @@ def get_msvcr():
         elif msc_ver == '1600':
             # VS2010 / MSVC 10.0
             return ['msvcr100']
+        elif msc_ver == '1700':
+            # Visual Studio 2012 / Visual C++ 11.0
+            return ['msvcr110']
+        elif msc_ver == '1800':
+            # Visual Studio 2013 / Visual C++ 12.0
+            return ['msvcr120']
+        elif msc_ver == '1900':
+            # Visual Studio 2015 / Visual C++ 14.0
+            # "msvcr140.dll no longer exists" http://blogs.msdn.com/b/vcblog/archive/2014/06/03/visual-studio-14-ctp.aspx
+            return ['vcruntime140']
         else:
+            # to do: can we make this futureproof?
             raise ValueError("Unknown MS Compiler version %s " % msc_ver)
 
 

From report at bugs.python.org  Mon Sep 28 12:40:22 2015
From: report at bugs.python.org (eryksun)
Date: Mon, 28 Sep 2015 10:40:22 +0000
Subject: [issue23606] ctypes.util.find_library("c") no longer makes sense
In-Reply-To: <1425789670.0.0.736264667252.issue23606@psf.upfronthosting.co.za>
Message-ID: <1443436822.66.0.369277186067.issue23606@psf.upfronthosting.co.za>


eryksun added the comment:

> some code that uses it will need updating (due to API changes 
> since VC9/VC10)

For example, I discovered that the stdio exports don't include printf, etc. Using __stdio_common_vfprintf to implement printf relies on calling __acrt_iob_func to get stdout and (in general) dynamically building a va_list argument list. Of course, relying on either operation is a bad idea.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 13:19:13 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 28 Sep 2015 11:19:13 +0000
Subject: [issue25111] Broken compatibility in FrameSummary equality
In-Reply-To: <1442252923.78.0.0672158797601.issue25111@psf.upfronthosting.co.za>
Message-ID: <1443439153.65.0.794613229711.issue25111@psf.upfronthosting.co.za>


Berker Peksag added the comment:

LGTM

+        self.assertEqual(f, tuple(f))
+        self.assertEqual(tuple(f), f)

It would be good to add a comment to explain why we test both variants, but it's not really important.

----------
nosy: +berker.peksag
stage: patch review -> commit review

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 14:38:02 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 28 Sep 2015 12:38:02 +0000
Subject: [issue25249] Unneeded and unsafe mkstemp replacement in
 test_subprocess.py
In-Reply-To: <1443382834.49.0.136619109846.issue25249@psf.upfronthosting.co.za>
Message-ID: <20150928123758.81637.76414@psf.io>


Roundup Robot added the comment:

New changeset ea91991c7db5 by Berker Peksag in branch '2.7':
Issue #25249: Remove unneeded mkstemp helper in test_subprocess
https://hg.python.org/cpython/rev/ea91991c7db5

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 14:39:18 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 28 Sep 2015 12:39:18 +0000
Subject: [issue25249] Unneeded and unsafe mkstemp replacement in
 test_subprocess.py
In-Reply-To: <1443382834.49.0.136619109846.issue25249@psf.upfronthosting.co.za>
Message-ID: <1443443958.74.0.0566365891811.issue25249@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Nir. Just fixed a small typo(fd -> f) in the 2.7 patch.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.4, Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 14:48:35 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Sep 2015 12:48:35 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <1443444515.7.0.666885373488.issue25220@psf.upfronthosting.co.za>


STINNER Victor added the comment:

test_regrtest-3.patch: I added a test on PCbuild\rt.bat and fixed the test on Tools/buildbot/test.bat (Windows only tests).

----------
Added file: http://bugs.python.org/file40609/test_regrtest-3.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 15:04:31 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 28 Sep 2015 13:04:31 +0000
Subject: [issue25122] test_eintr randomly fails on FreeBSD
In-Reply-To: <1442311779.01.0.43728096223.issue25122@psf.upfronthosting.co.za>
Message-ID: <20150928130426.94135.47459@psf.io>


Roundup Robot added the comment:

New changeset e48ec5f5b82b by Victor Stinner in branch 'default':
Issue #25122: Remove verbose mode of test_eintr
https://hg.python.org/cpython/rev/e48ec5f5b82b

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 15:15:01 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Sep 2015 13:15:01 +0000
Subject: [issue25256] Add sys.is_debug_build() public function to check if
 Python was compiled in debug mode
Message-ID: <1443446100.69.0.307482207939.issue25256@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch adds the sys.is_debug_build() public function and replaces hasattr(sys, xxx) tests to check for debug mode with sys.is_debug_build().

+.. function:: is_debug_build()
+
+   Return :const:`True` if the Python executable was compiled in debug mode,
+   return :const:`False` if it was compiled in release mode.
+
+   The debug mode is enabled with ``#define Py_DEBUG``, or with
+   ``./configure --with-pydebug``.
+
+   .. versionadded:: 3.6

I would like to add an obvious way to check if Python was compiled in debug mode, instead of having hacks/tips to check it.

For example, 3 different checks are proposed on StackOverflow and only one looks portable:

http://stackoverflow.com/questions/646518/python-how-to-detect-debug-interpreter

I don't think that we need to mark the function as an implementation detail or specific to CPython. Other implementations of Python would probably benefit from such flag. If they don't care, they can simply return False.

Alternative: Add a new sys.implementation.debug_build flag.

Note: I chose the "is_debug_build" name using the existing sysconfig.is_python_build(). There is a sys.flags.debug flag, so "is_debug()" can be confusing. I prefer to attach the "build" suffix.

----------
components: Library (Lib)
files: is_debug_build.patch
keywords: patch
messages: 251765
nosy: haypo
priority: normal
severity: normal
status: open
title: Add sys.is_debug_build() public function to check if Python was compiled in debug mode
versions: Python 3.6
Added file: http://bugs.python.org/file40610/is_debug_build.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 15:15:41 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Sep 2015 13:15:41 +0000
Subject: [issue25256] Add sys.is_debug_build() public function to check if
 Python was compiled in debug mode
In-Reply-To: <1443446100.69.0.307482207939.issue25256@psf.upfronthosting.co.za>
Message-ID: <1443446141.53.0.469647734669.issue25256@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy: +alex, brett.cannon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 15:18:30 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Sep 2015 13:18:30 +0000
Subject: [issue25256] Add sys.is_debug_build() public function to check if
 Python was compiled in debug mode
In-Reply-To: <1443446100.69.0.307482207939.issue25256@psf.upfronthosting.co.za>
Message-ID: <1443446310.68.0.658024280182.issue25256@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I wrote this patch while working on new tests for Lib/test/regrtest.py: issue #25220. The Windows scripts PCbuild/rt.bat (and Tools/buildbot/test.bat) requires a "-d" command line option if the Python was compiled in debug mode. The flag is used to choose the name of the Python executable: python.exe or python_d.exe. In my patch, I used:

Py_DEBUG = hasattr(sys, 'getobjects')

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 15:28:08 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 28 Sep 2015 13:28:08 +0000
Subject: [issue25256] Add sys.is_debug_build() public function to check if
 Python was compiled in debug mode
In-Reply-To: <1443446100.69.0.307482207939.issue25256@psf.upfronthosting.co.za>
Message-ID: <1443446888.05.0.838954987722.issue25256@psf.upfronthosting.co.za>


St?phane Wirtel added the comment:

In your Python unittest, could you change the comment, it's ambiguous.

Thanks

----------
nosy: +matrixise

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 15:45:20 2015
From: report at bugs.python.org (Optimal BPM)
Date: Mon, 28 Sep 2015 13:45:20 +0000
Subject: [issue25079] Tokenize generates NL instead of NEWLINE for comments
In-Reply-To: <1442051359.49.0.451935650182.issue25079@psf.upfronthosting.co.za>
Message-ID: <1443447920.47.0.416368277622.issue25079@psf.upfronthosting.co.za>


Optimal BPM added the comment:

Ok, I'll work around that then. 
Thanks for your response!

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 15:46:44 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 28 Sep 2015 13:46:44 +0000
Subject: [issue25256] Add sys.is_debug_build() public function to check if
 Python was compiled in debug mode
In-Reply-To: <1443446100.69.0.307482207939.issue25256@psf.upfronthosting.co.za>
Message-ID: <1443448004.68.0.38306456921.issue25256@psf.upfronthosting.co.za>


St?phane Wirtel added the comment:

Victor, I have tested your patch with the default branch (3.6), works fine on OSX Yosemite. In release and debug modes.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 16:16:51 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 28 Sep 2015 14:16:51 +0000
Subject: [issue25256] Add sys.is_debug_build() public function to check if
 Python was compiled in debug mode
In-Reply-To: <1443446100.69.0.307482207939.issue25256@psf.upfronthosting.co.za>
Message-ID: <1443449811.64.0.63635998188.issue25256@psf.upfronthosting.co.za>


Changes by Ezio Melotti :


----------
nosy: +ezio.melotti
stage:  -> patch review
type:  -> enhancement

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 16:46:34 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 28 Sep 2015 14:46:34 +0000
Subject: [issue25233] AssertionError from asyncio Queue get
In-Reply-To: <1443202040.86.0.857467079978.issue25233@psf.upfronthosting.co.za>
Message-ID: <20150928144628.94121.9545@psf.io>


Roundup Robot added the comment:

New changeset 1ea306202d5d by Guido van Rossum in branch '3.4':
Issue #25233: Rewrite the guts of Queue to be more understandable and correct.
https://hg.python.org/cpython/rev/1ea306202d5d

New changeset a48d90049ae2 by Guido van Rossum in branch '3.5':
Issue #25233: Rewrite the guts of Queue to be more understandable and correct. (Merge 3.4->3.5.)
https://hg.python.org/cpython/rev/a48d90049ae2

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 17:34:39 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 28 Sep 2015 15:34:39 +0000
Subject: [issue23640] int.from_bytes() is broken for subclasses
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1443454479.63.0.715955412325.issue23640@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis :


----------
nosy: +Arfrever

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 17:36:17 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 28 Sep 2015 15:36:17 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <1443454577.78.0.109592419493.issue25220@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis :


----------
nosy: +Arfrever

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 18:28:58 2015
From: report at bugs.python.org (Arnon Yaari)
Date: Mon, 28 Sep 2015 16:28:58 +0000
Subject: [issue9917] resource max value represented as signed when should be
 unsigned
In-Reply-To: <1285119777.0.0.437398080007.issue9917@psf.upfronthosting.co.za>
Message-ID: <1443457738.4.0.278763848982.issue9917@psf.upfronthosting.co.za>


Arnon Yaari added the comment:

getrlimit still returns -1 as 'max' when limit is unlimited and for RLIM_INFINITY because rlim_t is considered signed.

The zshell project decides whether rlim_t is signed/unsigned (and also whether it is long or long long) in the configure step: https://github.com/zsh-users/zsh/blob/8b84419f45298ee564bd6fa2b531c8991b2a1983/configure.ac#L1859

On Linux, rlim_t is unisnged long long so the conversion should be done using PyLong_FromUnsignedLongLong (for RLIM_INFINITY) and using 'KK' instead of 'LL' in 'rlimit2py'.

IMHO the best way to fix this is to add configure steps like in zsh and then adding ifdefs to resource.c - in rlimit2py and near PyModule_AddObject of RLIM_INFINITY

----------
nosy: +wiggin15

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 18:37:21 2015
From: report at bugs.python.org (Arnon Yaari)
Date: Mon, 28 Sep 2015 16:37:21 +0000
Subject: [issue678264] test_resource fails when file size is limited
Message-ID: <1443458241.89.0.335076256612.issue678264@psf.upfronthosting.co.za>


Arnon Yaari added the comment:

This issue is still relevant and can be reproduced by running:

    ulimit -Hf 1000
    ./python Lib/test/test_resource.py

(On AIX, the default hard limit is not RLIM_INFINITY so it reproduces on that operating system without the first line)

The patch is still relevant and fixes the issue.
It looks like it's doing the right thing, but it can't be committed until #9917 will be fixed - otherwise the tests will break on Linux, where RLIM_INFINITY is -1 and not greater than 0.

----------
nosy: +wiggin15

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 18:52:22 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 28 Sep 2015 16:52:22 +0000
Subject: [issue25255] Security of CPython Builds
In-Reply-To: <1443427518.11.0.403449402832.issue25255@psf.upfronthosting.co.za>
Message-ID: <1443459142.6.0.414142531128.issue25255@psf.upfronthosting.co.za>


Steve Dower added the comment:

Basically through trusting the people who produce the builds.

You can also verify the hg changeset by looking at sys.version and matching it to the tagged release. If there are any differences between the tagged commit and the one used to build, there will be a "+" in the version (though honestly, there are ways to avoid showing that if someone really wants to hide it, so it isn't a guarantee).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 18:54:20 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 28 Sep 2015 16:54:20 +0000
Subject: [issue25255] Security of CPython Builds
In-Reply-To: <1443427518.11.0.403449402832.issue25255@psf.upfronthosting.co.za>
Message-ID: <1443459260.97.0.272007037214.issue25255@psf.upfronthosting.co.za>


Brett Cannon added the comment:

And just as an FYI, while PEP 101 was created 14 years ago, it has been updated regularly (last edit was 13 days ago): https://hg.python.org/peps/log/tip/pep-0101.txt

----------
nosy: +brett.cannon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 18:59:48 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 28 Sep 2015 16:59:48 +0000
Subject: [issue25255] Security of CPython Builds
In-Reply-To: <1443427518.11.0.403449402832.issue25255@psf.upfronthosting.co.za>
Message-ID: <1443459588.23.0.565474237022.issue25255@psf.upfronthosting.co.za>


Paul Moore added the comment:

Also, the Windows build process is documented in PCBuild/readme.txt - see https://hg.python.org/cpython/file/tip/PCbuild/readme.txt

More generally the devguide documents how to build CPython - https://docs.python.org/devguide/setup.html#compiling

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 19:07:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 28 Sep 2015 17:07:09 +0000
Subject: [issue25185] Inconsistency between venv and site
In-Reply-To: <1442698159.95.0.304023821424.issue25185@psf.upfronthosting.co.za>
Message-ID: <1443460029.18.0.701448571567.issue25185@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I suspect that this can break backward compatibility.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 19:10:46 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 28 Sep 2015 17:10:46 +0000
Subject: [issue24483] Avoid repeated hash calculation in C implementation of
 functools.lru_cache()
In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za>
Message-ID: <1443460246.39.0.728569308463.issue24483@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 19:12:54 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 28 Sep 2015 17:12:54 +0000
Subject: [issue22609] Constructors of some mapping classes don't accept `self`
 keyword argument
In-Reply-To: <1413029049.09.0.127316928921.issue22609@psf.upfronthosting.co.za>
Message-ID: <1443460374.6.0.984262315867.issue22609@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 19:13:53 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 28 Sep 2015 17:13:53 +0000
Subject: [issue24164] Support pickling objects with __new__ with keyword
 arguments with protocol 2+
In-Reply-To: <1431341390.51.0.0928642680419.issue24164@psf.upfronthosting.co.za>
Message-ID: <1443460433.09.0.371862847674.issue24164@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 19:14:37 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 28 Sep 2015 17:14:37 +0000
Subject: [issue25125] "Edit with IDLE" does not work for shortcuts
In-Reply-To: <1442318370.13.0.116980940121.issue25125@psf.upfronthosting.co.za>
Message-ID: <1443460477.08.0.987612017581.issue25125@psf.upfronthosting.co.za>


Steve Dower added the comment:

Creating a "dumb" item was discussed and rejected.

I don't see how passing the subkey is an issue if it works. The name of the verb is considered public API surface, so we can't easily change it anyway.

What may be the issue is the use of "%L", which I recall being told I should use at some point but I don't remember the exact reason. It may be that links are not resolved for %L while using another character (I don't believe %1 is necessarily correct here either, but maybe with %* it's redundant anyway).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 19:15:37 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Sep 2015 17:15:37 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <1443460537.82.0.0130143644858.issue25220@psf.upfronthosting.co.za>


STINNER Victor added the comment:

regrtest_class.patch: Convert the long and complex main() function into a new Regrtest class using attributes and methods.

* Convert main() variables to Regrtest attributes: see the __init__() method. I documented some attributes

* Convert accumulate_result() function to a method

* Create setup_python() and setup_regrtest() methods. Maybe both methods should be merged, but for the first change I preferred to keep almost the same instruction order (not move code too much).

* Import gc at top level: the --threshold command line option is now ignored if the gc module is missing.

* Move resource.setrlimit() and the code to make the module paths absolute into the new setup_python() method. So this code is no more executed when the module is imported, only when main() is executed. We have a better on when the setup is done.

* Move textwrap import from printlist() to the top level.

* Some other minor cleanup.

----------
Added file: http://bugs.python.org/file40611/regrtest_class.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 19:48:47 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Sep 2015 17:48:47 +0000
Subject: [issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0,
 DstOffset=1
In-Reply-To: <1425688983.27.0.949503850992.issue23600@psf.upfronthosting.co.za>
Message-ID: <1443462527.56.0.0142795713048.issue23600@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky :


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 19:57:10 2015
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 28 Sep 2015 17:57:10 +0000
Subject: [issue25185] Inconsistency between venv and site
In-Reply-To: <1442698159.95.0.304023821424.issue25185@psf.upfronthosting.co.za>
Message-ID: <1443463030.19.0.729060016006.issue25185@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

> I suspect that this can break backward compatibility.

But since venv writes it out as UTF-8 already, it should be read in UTF-8, and if it isn't, isn't that the cause of the error which led to this bug we're talking about?

If we now write it with locale encoding, anything that previously assumed we were writing it in UTF-8 might break. While I'm not aware of any specific software which reads pyvenv.cfg other than the site.py code, there could well be third party code which does so.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 20:19:52 2015
From: report at bugs.python.org (Bob Hossley)
Date: Mon, 28 Sep 2015 18:19:52 +0000
Subject: [issue25257] In subject line email library inserts unwanted space
 after a thousands comma in a number
Message-ID: <1443464392.64.0.380133301442.issue25257@psf.upfronthosting.co.za>


New submission from Bob Hossley:

In my function makeMsg(), there is:

    msg = email.mime.nonmultipart.MIMENonMultipart('text',
        'plain', charset='utf-8')
    msg['Subject'] = email.header.Header(subject, 'utf-8')

subject has no space after the thousands comma:

u'1,010 words - "The Blackmail Caucus, a.k.a. the Republican Party" By Paul Krugman'


But

msg['Subject'].__str__()

'1, 010 words - "The Blackmail Caucus,\n a.k.a. the Republican Party" By Paul Krugman'

has a space after the thousands comma and the email message later generated has a space after the thousands comma.

This is objectionable.

Note that the email library also inserts a newline after the comma that is followed by a space.  Since I see no effect of this newline on the email generated, I have no objection to the newline.

----------
components: email
messages: 251782
nosy: SegundoBob, barry, r.david.murray
priority: normal
severity: normal
status: open
title: In subject line email library inserts unwanted space after a thousands comma in a number
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 20:26:48 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 28 Sep 2015 18:26:48 +0000
Subject: [issue25185] Inconsistency between venv and site
In-Reply-To: <1442698159.95.0.304023821424.issue25185@psf.upfronthosting.co.za>
Message-ID: <1443464808.55.0.525362635814.issue25185@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I thought that pyvenv.cfg was used by venv's predecessor virtualenv. Now I see that I was wrong and your idea is right.

----------
stage:  -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 20:40:52 2015
From: report at bugs.python.org (kenorb)
Date: Mon, 28 Sep 2015 18:40:52 +0000
Subject: [issue21872] LZMA library sometimes fails to decompress a file
In-Reply-To: <1403720935.87.0.990494824612.issue21872@psf.upfronthosting.co.za>
Message-ID: <1443465652.38.0.133018047325.issue21872@psf.upfronthosting.co.za>


kenorb added the comment:

The same with this attached file. It fails with Python 3.5 (small buffers like 128, 255, 1023, etc.) , but it seems to work in Python 3.4 with lzma._BUFFER_SIZE = 1023. So it looks like something regressed.

----------
nosy: +kenorb
Added file: http://bugs.python.org/file40612/02h_ticks.bi5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 20:50:44 2015
From: report at bugs.python.org (Peter Law)
Date: Mon, 28 Sep 2015 18:50:44 +0000
Subject: [issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0,
 DstOffset=1
In-Reply-To: <1425688983.27.0.949503850992.issue23600@psf.upfronthosting.co.za>
Message-ID: <1443466244.17.0.59053196628.issue23600@psf.upfronthosting.co.za>


Peter Law added the comment:

Awesome, thanks for fixing this.

----------
nosy: +PeterJCLaw

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 20:53:23 2015
From: report at bugs.python.org (phelix)
Date: Mon, 28 Sep 2015 18:53:23 +0000
Subject: [issue25255] Security of CPython Builds
In-Reply-To: <1443427518.11.0.403449402832.issue25255@psf.upfronthosting.co.za>
Message-ID: <1443466403.53.0.210891042076.issue25255@psf.upfronthosting.co.za>


phelix added the comment:

@Brett: Thanks for the info, I had not noticed PEP 101 had been updated.

@Paul: Ah, I had not found PCBuild/readme.txt yet. I did look at the devguide but I got the impression it was mostly meant for debug builds.

> Basically through trusting the people who produce the builds.
I assume these builders are very experienced and well known developers (thanks btw I like Python very much). I would trust them a very long way.

But it is not their integrity that is in question. Python is so popular that there might be large monetary (and other) incentives to force builders into something. Just for Bitcoin alone probably millions of dollars.

I was only recently made aware about this from Namecoin team members (and this [1] video about reproducible builds from CCC14) but as far as I see it now there is a very valid core in their argumentation. 

Our well respected team member Joseph Bisch has looked into reproducible builds of CPython and concluded that it might a difficult thing to do with a project as large as Python [2]. But maybe there are other ways to make builds more secure? I realize it is a lot I am asking here but build security will certainly get more and more important with time. Could things be improved by getting several developers together to create a secure VM as a starting point that make reproducible builds easier?

[1] https://media.ccc.de/browse/congress/2014/31c3_-_6240_-_en_-_saal_g_-_201412271400_-_reproducible_builds_-_mike_perry_-_seth_schoen_-_hans_steiner.html#video&t=18
[2] https://forum.namecoin.info/viewtopic.php?p=15869#p15869

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 21:03:51 2015
From: report at bugs.python.org (eryksun)
Date: Mon, 28 Sep 2015 19:03:51 +0000
Subject: [issue25125] "Edit with IDLE" does not work for shortcuts
In-Reply-To: <1442318370.13.0.116980940121.issue25125@psf.upfronthosting.co.za>
Message-ID: <1443467031.78.0.794523116097.issue25125@psf.upfronthosting.co.za>


eryksun added the comment:

> I don't believe %1 is necessarily correct here either, but maybe 
> with %* it's redundant anyway

%0, %1, or %L is lpFile. On older systems "%L" guarantees using the long filename, but this is pointless nowadays. %* (i.e. %2 through %9) is lpParameters, which is unusual to have in an edit command. Here's the edit command for .bat files:

    C:\>reg query hklm\software\classes\batfile\shell\edit\command
    
    HKEY_LOCAL_MACHINE\software\classes\batfile\shell\edit\command
        (Default)    REG_EXPAND_SZ    %SystemRoot%\System32\NOTEPAD.EXE %1

It seems using quotes around "%1" is optional.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 21:06:16 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Sep 2015 19:06:16 +0000
Subject: [issue25257] In subject line email library inserts unwanted space
 after a thousands comma in a number
In-Reply-To: <1443464392.64.0.380133301442.issue25257@psf.upfronthosting.co.za>
Message-ID: <1443467176.83.0.228150162515.issue25257@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is fixed in Python3.  The fix was part of a large change to the header folding algorithm, and I'm not sure it is appropriate to backport it.  I'm guessing we would, though, if someone wants to do the work for the backport.  The relevant issue is issue 11492.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 21:08:00 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 28 Sep 2015 19:08:00 +0000
Subject: [issue25125] "Edit with IDLE" does not work for shortcuts
In-Reply-To: <1442318370.13.0.116980940121.issue25125@psf.upfronthosting.co.za>
Message-ID: <1443467280.35.0.669578645211.issue25125@psf.upfronthosting.co.za>


Steve Dower added the comment:

Does notepad handle clicking "edit" on a shortcut to a batch file? Maybe subcommands don't have exactly the same semantics as regular verbs...

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 21:16:50 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Sep 2015 19:16:50 +0000
Subject: [issue25255] Security of CPython Builds
In-Reply-To: <1443427518.11.0.403449402832.issue25255@psf.upfronthosting.co.za>
Message-ID: <1443467810.13.0.305332672157.issue25255@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, making the build process more automated would help us, so if someone wants to help make that kind of thing happen it will probably be well received.  The platform installer builds (OSX, Windows) are tricky things, though, and a fair amount of knowledge is unfortunately locked up (currently) in Steve and Ned's brains.  It would indeed be good to make that not so (bus factor, if nothing else), so support from additional people willing to put in effort on installer builds will (I'm assuming) be welcome. But, since anything along those lines would require additional time from Steve and Ned, it isn't obvious how best to go about it.

I haven't looked at your linked article, but there might be alternate pathways to your goal based on starting from the source and producing your own installers or embedded python installation.

----------
assignee: docs at python -> 
nosy: +ned.deily, r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 21:26:04 2015
From: report at bugs.python.org (Abrantes Araujo Silva Filho)
Date: Mon, 28 Sep 2015 19:26:04 +0000
Subject: [issue25247] Tkinter modules built successfully but removed because
 they could not be imported
In-Reply-To: <1443362955.97.0.479963022327.issue25247@psf.upfronthosting.co.za>
Message-ID: <1443468364.47.0.327999928286.issue25247@psf.upfronthosting.co.za>


Abrantes Araujo Silva Filho added the comment:

I tried with LD_RUN_PATH, but the same compile error still there.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 21:26:34 2015
From: report at bugs.python.org (Chenyun Yang)
Date: Mon, 28 Sep 2015 19:26:34 +0000
Subject: [issue25258] HtmlParser doesn't handle void element tags correctly
Message-ID: <1443468394.25.0.617953373069.issue25258@psf.upfronthosting.co.za>


New submission from Chenyun Yang:

For void elements such as (, ), there doesn't need to have xhtml empty end tag. HtmlParser which relies on the XHTML empty end syntax failed to handle this situation. 

from HTMLParser import HTMLParser

# create a subclass and override the handler methods
class MyHTMLParser(HTMLParser):
    def handle_starttag(self, tag, attrs):
        print "Encountered a start tag:", tag
    def handle_endtag(self, tag):
        print "Encountered an end tag :", tag
    def handle_data(self, data):
        print "Encountered some data  :", data

>>> parser.feed('')
Encountered a start tag: link
Encountered a start tag: img
>>> parser.feed('')
Encountered a start tag: link
Encountered an end tag : link
Encountered a start tag: img
Encountered an end tag : img


Reference:
https://github.com/python/cpython/blob/bdfb14c688b873567d179881fc5bb67363a6074c/Lib/html/parser.py
http://www.w3.org/TR/html5/syntax.html#void-elements

----------
components: Library (Lib)
messages: 251792
nosy: Chenyun Yang
priority: normal
severity: normal
status: open
title: HtmlParser doesn't handle void element tags correctly
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 21:29:41 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Sep 2015 19:29:41 +0000
Subject: [issue25258] HtmlParser doesn't handle void element tags correctly
In-Reply-To: <1443468394.25.0.617953373069.issue25258@psf.upfronthosting.co.za>
Message-ID: <1443468581.57.0.856934331166.issue25258@psf.upfronthosting.co.za>


Changes by R. David Murray :


----------
nosy: +ezio.melotti

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 21:30:39 2015
From: report at bugs.python.org (Tim Peters)
Date: Mon, 28 Sep 2015 19:30:39 +0000
Subject: [issue23600] tizinfo.fromutc changed for tzinfo wih StdOffset=0,
 DstOffset=1
In-Reply-To: <1425688983.27.0.949503850992.issue23600@psf.upfronthosting.co.za>
Message-ID: <1443468639.97.0.538967523243.issue23600@psf.upfronthosting.co.za>


Tim Peters added the comment:

Thank you for your persistence and patience, Peter!  It shouldn't have been this hard for you :-(

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 21:57:44 2015
From: report at bugs.python.org (eryksun)
Date: Mon, 28 Sep 2015 19:57:44 +0000
Subject: [issue25125] "Edit with IDLE" does not work for shortcuts
In-Reply-To: <1442318370.13.0.116980940121.issue25125@psf.upfronthosting.co.za>
Message-ID: <1443470264.84.0.545324725612.issue25125@psf.upfronthosting.co.za>


eryksun added the comment:

> Does notepad handle clicking "edit" on a shortcut to a batch file? 
> Maybe subcommands don't have exactly the same semantics as regular 
> verbs...

In Windows 7 SP1 a regular verb works fine from a shortcut, but apparently not a subcommand. OTOH, Windows 10 seems to have no problem with this.

I just tested the following subcommand for editing .bat files with notepad:

    reg add HKCU\Software\Classes\batfile\shell\editother\shell\editwithnotepad\command
    reg add HKCU\Software\Classes\batfile\shell\editother /v MUIVerb /d "Edit Other"
    reg add HKCU\Software\Classes\batfile\shell\editother /v Subcommands
    reg add HKCU\Software\Classes\batfile\shell\editother\shell\editwithnotepad /v MUIVerb /d "Edit With Notepad"
    reg add HKCU\Software\Classes\batfile\shell\editother\shell\editwithnotepad\command /ve /d "C:\Windows\notepad.exe %1"

When accessed from the file itself, this works fine in both Windows 7 SP1 and Windows 10 RTM. When accessed from a shortcut, the command works in Windows 10 but does nothing in Windows 7. This independently confirms the issue reported by Thijs as a Windows 7 bug/limitation.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 22:00:51 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 28 Sep 2015 20:00:51 +0000
Subject: [issue25255] Security of CPython Builds
In-Reply-To: <1443427518.11.0.403449402832.issue25255@psf.upfronthosting.co.za>
Message-ID: <1443470451.71.0.784637813429.issue25255@psf.upfronthosting.co.za>


Steve Dower added the comment:

I do need to contribute some PEP 101 updates at some point, since the Windows build no longer resembles what is described there, but it's mostly about configuration.

* Install x, y, z
* Obtain extra externals
* Install signing certificate
* Configure non-default settings
* Check out correct repo/branch
* Run tools/msi/buildrelease.cmd
(Optional: install x, configure SSH key, run tools/msi/uploadrelease.cmd)

Since I can't release the PSF signing key or my own GPG key, there's only so automated this configuration can be. The "correct repo/branch/changeset" varies depending on the RM, and not all of the build tests are automatically verified (high chance of false positives that require manual inspection).

Probably the first thing I should do is put the extra externals (binutils, gpg, htmlhelp, redist and wix) onto svn.python.org with the others and grab them automatically. I can add checks for configuration (things like the eol extension not being enabled, for example) and the default build doesn't need a signing certificate, so that's optional too.

But the overriding point is, these things aren't required for most people, and automating them is going to be pretty restrictive. For example, I would have to automate it by detecting VS 2015 and failing if it's not there - otherwise you don't have repeatability - and that's going to prevent people using earlier or later versions of VS for their own uses. HTML Help is basically stable (a.k.a. dead), but gpg and binutils are frequently updated and locking them down is also restrictive. Also, people may want to use their own MinGW or GPG installs, while I don't want to do that, so the model I use for building would be restrictive there too.

Finally, so few people actually want to produce builds that I can do plenty of work to make it easy, and there may be major issues that are never discovered because nobody else uses it.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 22:04:41 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 28 Sep 2015 20:04:41 +0000
Subject: [issue25255] Security of CPython Builds
In-Reply-To: <1443427518.11.0.403449402832.issue25255@psf.upfronthosting.co.za>
Message-ID: <1443470681.38.0.125675334572.issue25255@psf.upfronthosting.co.za>


Steve Dower added the comment:

Having read your link [2] above (at least briefly), it seems the aim is to compare hashes of builds from multiple people to verify that nobody maliciously modified the binaries.

That isn't going to work for Windows because we cryptographically sign the binaries. The only people who could produce bit-for-bit identical builds are those trusted by the PSF, and not independent people. So if you don't trust the PSF and implicitly the people trusted by the PSF, you can't actually do anything besides building your own version and using that.

However, the rest of the build is so automated that other personal variations will not occur. As I mentioned above, I have exactly one batch file to build the full span of releases for Windows, and I just run that. It's public and in the repo, so anyone else can also run it, they just won't get bit-for-bit identical builds because of timestamps, embedded paths, and certificates.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 22:13:52 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 28 Sep 2015 20:13:52 +0000
Subject: [issue25252] Hard-coded line ending in
 asyncio.streams.StreamReader.readline
In-Reply-To: <1443393275.12.0.244806076878.issue25252@psf.upfronthosting.co.za>
Message-ID: <1443471232.35.0.620386469559.issue25252@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I'm closing this as unneeded.

----------
resolution:  -> rejected
stage:  -> resolved

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 22:36:06 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 28 Sep 2015 20:36:06 +0000
Subject: [issue25233] AssertionError from asyncio Queue get
In-Reply-To: <1443202040.86.0.857467079978.issue25233@psf.upfronthosting.co.za>
Message-ID: <20150928203603.31177.84734@psf.io>


Roundup Robot added the comment:

New changeset 58695845e159 by Guido van Rossum in branch 'default':
Issue #25233: Rewrite the guts of Queue to be more understandable and correct. (Merge 3.5->default.)
https://hg.python.org/cpython/rev/58695845e159

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 22:46:19 2015
From: report at bugs.python.org (Bob Hossley)
Date: Mon, 28 Sep 2015 20:46:19 +0000
Subject: [issue25257] In subject line email library inserts unwanted space
 after a thousands comma in a number
In-Reply-To: <1443464392.64.0.380133301442.issue25257@psf.upfronthosting.co.za>
Message-ID: <1443473179.09.0.0316984433721.issue25257@psf.upfronthosting.co.za>


Bob Hossley added the comment:

Thank you R. David Murray.

I look forward to being able to move my application to Python 3.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 22:53:09 2015
From: report at bugs.python.org (Tim Chase)
Date: Mon, 28 Sep 2015 20:53:09 +0000
Subject: [issue25259] readline macros can segfault Python
Message-ID: <1443473589.61.0.823349470149.issue25259@psf.upfronthosting.co.za>


New submission from Tim Chase:

Attempting to use a readline macro (use "C-x (" to start recording, "C-x )" to stop recording, and "C-x e" to playback) with more than one newline in it will cause a segfault.  The behavior also presents in the [`rlwrap` tool](https://github.com/hanslub42/rlwrap/issues/36) but not in `bash`.  I've tested and reproduced with Python 2.[4-6] and 3.4, but I don't see any similar bug-reports that would suggest that the problem doesn't also exist in all 3.x series releases.  To reproduce, in a `readline`-enabled Python:

    $ python
    ?
    >>> import cmd
    >>> cmd.Cmd().cmdloop()  
    (Cmd) # do "C-x (   C-x ) C-x e" and it segfaults

The author of `rlwrap` is working to create a minimum working example, and I'm not sure whether this is a problem with the underlying `libreadline` or just how it's being used by `rlwrap` and Python.

----------
components: Library (Lib)
messages: 251800
nosy: gumnos
priority: normal
severity: normal
status: open
title: readline macros can segfault Python
type: crash
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 23:19:20 2015
From: report at bugs.python.org (phelix)
Date: Mon, 28 Sep 2015 21:19:20 +0000
Subject: [issue25255] Security of CPython Builds
In-Reply-To: <1443427518.11.0.403449402832.issue25255@psf.upfronthosting.co.za>
Message-ID: <1443475160.02.0.508071886047.issue25255@psf.upfronthosting.co.za>


phelix added the comment:

Thank you all for your responses.

> Having read your link [2] above (at least briefly), it seems the aim is to compare hashes of builds from multiple people to verify that nobody maliciously modified the binaries.
Exactly. Also it might protect the people actually doing the builds from extortion and accusations from backdoor victims (e.g. in case of hacked build system).

> That isn't going to work for Windows because we cryptographically sign the binaries. The only people who could produce bit-for-bit identical builds are those trusted by the PSF, and not independent people. So if you don't trust the PSF and implicitly the people trusted by the PSF, you can't actually do anything besides building your own version and using that.
Joseph tried just that but ran into issues.

> However, the rest of the build is so automated that other personal variations will not occur. As I mentioned above, I have exactly one batch file to build the full span of releases for Windows, and I just run that. It's public and in the repo, so anyone else can also run it, they just won't get bit-for-bit identical builds because of timestamps, embedded paths, and certificates.
Timestamps and paths should be handled by the Gitian secure build system (cross compile).

>From my point this issue can be closed as my questions are answered. We will take another look at building reproducibly. If we run into problems I will create another issue here in the hope you can help again. :)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 23:24:34 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Sep 2015 21:24:34 +0000
Subject: [issue25255] Security of CPython Builds
In-Reply-To: <1443427518.11.0.403449402832.issue25255@psf.upfronthosting.co.za>
Message-ID: <1443475474.86.0.116085049266.issue25255@psf.upfronthosting.co.za>


Changes by R. David Murray :


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Mon Sep 28 23:53:23 2015
From: report at bugs.python.org (Arnon Yaari)
Date: Mon, 28 Sep 2015 21:53:23 +0000
Subject: [issue9917] resource max value represented as signed when should be
 unsigned
In-Reply-To: <1285119777.0.0.437398080007.issue9917@psf.upfronthosting.co.za>
Message-ID: <1443477203.17.0.983007545126.issue9917@psf.upfronthosting.co.za>


Arnon Yaari added the comment:

I'm submitting a patch for review. I tested this and verified the values on Redhat and Unbuntu (both x86 and x64), Mac OS X (x64) and AIX (32-bit process on ppc64).
'configure' and 'pyconfig.h.in' were auto-generated with autoconf and autoheader, respectively.
A test for this patch (along with a fix for a different test failure) is in msg117130

----------
keywords: +patch
Added file: http://bugs.python.org/file40613/issue9917.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 00:19:12 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 28 Sep 2015 22:19:12 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <20150928221908.81641.90598@psf.io>


Roundup Robot added the comment:

New changeset 3393d86c3bb2 by Victor Stinner in branch 'default':
Issue #25220: Add functional tests to test_regrtest
https://hg.python.org/cpython/rev/3393d86c3bb2

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 00:20:02 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Sep 2015 22:20:02 +0000
Subject: [issue25260] python -m test --coverage doesn't work on Windows
Message-ID: <1443478802.75.0.02674996421.issue25260@psf.upfronthosting.co.za>


New submission from STINNER Victor:

"python -m test --coverage" doesn't work on Windows because the tracer ignores the root directory of Python source code.

The code works on Linux because sys.base_prefix and sys.base_exec_prefix don't point to the Python source code, but to /usr/local.

I'm not sure why sys.base_prefix and sys.base_exec_prefix are ignored.

----------
components: Tests, Windows
messages: 251804
nosy: haypo, paul.moore, r.david.murray, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: python -m test --coverage doesn't work on Windows
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 00:25:06 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Sep 2015 22:25:06 +0000
Subject: [issue25260] python -m test --coverage doesn't work on Windows
In-Reply-To: <1443478802.75.0.02674996421.issue25260@psf.upfronthosting.co.za>
Message-ID: <1443479106.64.0.541036038363.issue25260@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I added a new test for "-m test --coverage" in test_regrtest, but I skipped the test on Windows.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 01:10:36 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 28 Sep 2015 23:10:36 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <20150928231030.94133.51963@psf.io>


Roundup Robot added the comment:

New changeset a9fe8cd339b1 by Victor Stinner in branch 'default':
Fix test_regrtest.test_tools_buildbot_test()
https://hg.python.org/cpython/rev/a9fe8cd339b1

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 01:18:21 2015
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 28 Sep 2015 23:18:21 +0000
Subject: [issue25260] python -m test --coverage doesn't work on Windows
In-Reply-To: <1443478802.75.0.02674996421.issue25260@psf.upfronthosting.co.za>
Message-ID: <1443482301.84.0.054599437181.issue25260@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

What version of coverage.py is this?

----------
nosy: +nedbat

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 01:25:08 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Sep 2015 23:25:08 +0000
Subject: [issue25260] python -m test --coverage doesn't work on Windows
In-Reply-To: <1443478802.75.0.02674996421.issue25260@psf.upfronthosting.co.za>
Message-ID: <1443482708.68.0.188950311621.issue25260@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Changes on ignoredirs:

Changeset 294f8aeb4d4b: "Implemented PEP 405 (Python virtual environments)."

-        tracer = trace.Trace(ignoredirs=[sys.prefix, sys.exec_prefix, libpath],
-                             trace=0, count=1)
+        tracer = trace.Trace(ignoredirs=[sys.base_prefix, sys.base_exec_prefix,
+                             libpath], trace=0, count=1)


Changeset b43f14c103bb: "#5656: detect correct encoding of files when reporting coverage in trace.py, and ignore files in the temporary direct"

-        import trace
-        tracer = trace.Trace(ignoredirs=[sys.prefix, sys.exec_prefix],
+        import trace, tempfile
+        tracer = trace.Trace(ignoredirs=[sys.prefix, sys.exec_prefix,
+                                         tempfile.gettempdir()],

Changeset 308c193f51e3: "adds -T option for code coverage.  The implementation is a fairly simpleminded adaptation of Zope3's test.py -T flag."

+        tracer = trace.Trace(ignoredirs=[sys.prefix, sys.exec_prefix],
+                             trace=False, count=True)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 01:30:03 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Sep 2015 23:30:03 +0000
Subject: [issue25260] python -m test --coverage doesn't work on Windows
In-Reply-To: <1443478802.75.0.02674996421.issue25260@psf.upfronthosting.co.za>
Message-ID: <1443483003.99.0.141576322595.issue25260@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ooops, copy/paste failure. The right diff is:

Changeset 294f8aeb4d4b: "Implemented PEP 405 (Python virtual environments)."

-        tracer = trace.Trace(ignoredirs=[sys.prefix, sys.exec_prefix,
+        tracer = trace.Trace(ignoredirs=[sys.base_prefix, sys.base_exec_prefix,
                                          tempfile.gettempdir()],
                              trace=False, count=True)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 01:50:26 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Sep 2015 23:50:26 +0000
Subject: [issue25259] readline macros can segfault Python
In-Reply-To: <1443473589.61.0.823349470149.issue25259@psf.upfronthosting.co.za>
Message-ID: <1443484226.85.0.963817780646.issue25259@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Python uses an user handler "rlhandler()" which calls rl_callback_handler_remove(). Is it safe to call rl_callback_handler_remove() in an user handler?

Traceback on the crash:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) where
#0  0x0000000000000000 in ?? ()
#1  0x0000003d0c22d67e in rl_callback_read_char () at ../callback.c:238
#2  0x00007ffff149ce85 in readline_until_enter_or_signal (prompt=prompt at entry=0x7ffff17ef598 "(Cmd) ", signal=signal at entry=0x7fffffffd52c)
    at /home/haypo/prog/python/default/Modules/readline.c:1143
#3  0x00007ffff149cfaa in call_readline (sys_stdin=0x3cecfba8e0 <_IO_2_1_stdin_>, sys_stdout=0x3cecfbb620 <_IO_2_1_stdout_>, prompt=0x7ffff17ef598 "(Cmd) ")
    at /home/haypo/prog/python/default/Modules/readline.c:1231
#4  0x00000000005ae97a in PyOS_Readline (sys_stdin=0x3cecfba8e0 <_IO_2_1_stdin_>, sys_stdout=0x3cecfbb620 <_IO_2_1_stdout_>, prompt=0x7ffff17ef598 "(Cmd) ")
    at Parser/myreadline.c:211
#5  0x000000000052ec57 in builtin_input_impl (module=module at entry=0x7ffff189bc58, prompt=) at Python/bltinmodule.c:1924
#6  0x000000000052f054 in builtin_input (module=0x7ffff189bc58, args=) at Python/clinic/bltinmodule.c.h:546
(...)


Other trace with source code of readline:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
Missing separate debuginfos, use: dnf debuginfo-install ncurses-libs-5.9-18.20150214.fc22.x86_64
(gdb) up
#1  0x0000003d0c22d67e in rl_callback_read_char () at ../callback.c:238
238		  (*rl_linefunc) (line);
(gdb) print rl_linefunc
$1 = (rl_vcpfunc_t *) 0x0

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 03:53:34 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Sep 2015 01:53:34 +0000
Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation)
In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za>
Message-ID: <1443491614.03.0.532918800739.issue24773@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Changing the title to reference PEP 495.

----------
stage:  -> needs patch
title: Add local time disambiguation flag to datetime -> Implement PEP 495 (Local Time Disambiguation)

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 04:23:56 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Sep 2015 02:23:56 +0000
Subject: [issue9051] Improve pickle format for timezone aware datetime
 instances
In-Reply-To: <1277151308.95.0.331220838487.issue9051@psf.upfronthosting.co.za>
Message-ID: <1443493436.42.0.235187002683.issue9051@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> there is a risk that the "_utc" variable can be renamed
> and this will break pickle compatibility.

I think we will still need to maintain _utc global indefinitely to keep the old pickles readable.

On the other hand, it looks like support for qualnames is only available with pickle protocol 4, so I don't see any downside from from storing the full qualname other than an 8-byte increase in the size of the pickle.

I guess my position on this will be +0:  I'll accept a patch if someone will submit it, but I am unlikely to do it myself.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 04:24:12 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Sep 2015 02:24:12 +0000
Subject: [issue9051] Improve pickle format for timezone aware datetime
 instances
In-Reply-To: <1277151308.95.0.331220838487.issue9051@psf.upfronthosting.co.za>
Message-ID: <1443493452.17.0.600173435316.issue9051@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky :


----------
nosy: +tim.peters

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 04:44:39 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 29 Sep 2015 02:44:39 +0000
Subject: [issue25258] HtmlParser doesn't handle void element tags correctly
In-Reply-To: <1443468394.25.0.617953373069.issue25258@psf.upfronthosting.co.za>
Message-ID: <1443494679.91.0.881147842951.issue25258@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

The example for Parsing an element with a few attributes and a title:" in https://docs.python.org/2/library/htmlparser.html#examples demonstrates this as expected behavior, so I'm not sure it can be changed:

    >>> parser.feed('The Python logo')
    Start tag: img
         attr: ('src', 'python-logo.png')
         attr: ('alt', 'The Python logo')
    >>>
    >>> parser.feed('
Python
')
    Start tag: h1
    Data     : Python
    End tag  : h1

----------
nosy: +josh.r

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 04:58:17 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Sep 2015 02:58:17 +0000
Subject: [issue9051] Improve pickle format for timezone aware datetime
 instances
In-Reply-To: <1277151308.95.0.331220838487.issue9051@psf.upfronthosting.co.za>
Message-ID: <1443495497.51.0.693846000939.issue9051@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> I think we will still need to maintain _utc global indefinitely to keep the old pickles readable.

We have no need to maintain _utc global indefinitely if don't add it.

> On the other hand, it looks like support for qualnames is only available with pickle protocol 4,

No, support for qualnames now is available with all pickle protocols.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 05:28:52 2015
From: report at bugs.python.org (Memeplex)
Date: Tue, 29 Sep 2015 03:28:52 +0000
Subject: [issue9334] argparse does not accept options taking arguments
 beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1443497332.86.0.0189897901201.issue9334@psf.upfronthosting.co.za>


Memeplex added the comment:

What's missing for this patch to be applied? Can I help somehow?

----------
nosy: +memeplex

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 05:54:42 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Sep 2015 03:54:42 +0000
Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation)
In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za>
Message-ID: <1443498882.75.0.870186011446.issue24773@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky :


Added file: http://bugs.python.org/file40614/issue24773-s3.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 06:03:36 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 29 Sep 2015 04:03:36 +0000
Subject: [issue25233] AssertionError from asyncio Queue get
In-Reply-To: <1443202040.86.0.857467079978.issue25233@psf.upfronthosting.co.za>
Message-ID: <1443499416.5.0.29006078147.issue25233@psf.upfronthosting.co.za>


Changes by Guido van Rossum :


----------
assignee:  -> gvanrossum
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 06:05:54 2015
From: report at bugs.python.org (Sreenivasulu Saya)
Date: Tue, 29 Sep 2015 04:05:54 +0000
Subject: [issue25261] Incorrect Return Values for any() and all() Built-in
 Functions
Message-ID: <1443499554.6.0.480253610351.issue25261@psf.upfronthosting.co.za>


New submission from Sreenivasulu Saya:

The results displayed by the any() and all() is incorrect (differs from what is documented and what makes sense).

Here is the code:
-----------------
multiples_of_6 = (not (i % 6) for i in range(1, 10))

print("List: ", list(multiples_of_6 ), "\nAny: ", any(multiples_of_6),
        "\nAll: ", all(multiples_of_6))
---------------

The distribution in use is:
Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:27:37) [MSC v.1900 64 bit (AMD64)] on win32

Here is the output on Windows7:
-------------------------------
List:  [False, False, False, False, False, True, False, False, False]
Any:  False    <<<<< This should be True
All:  True     <<<<< This should be False

----------
components: Build
messages: 251816
nosy: Sreenivasulu Saya
priority: normal
severity: normal
status: open
title: Incorrect Return Values for any() and all() Built-in Functions
type: behavior
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 06:11:28 2015
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 29 Sep 2015 04:11:28 +0000
Subject: [issue25261] Incorrect Return Values for any() and all() Built-in
 Functions
In-Reply-To: <1443499554.6.0.480253610351.issue25261@psf.upfronthosting.co.za>
Message-ID: <20150929041123.GQ23642@ando.pearwood.info>


Steven D'Aprano added the comment:

Not a bug. You have used a generator expression, so it is exhausted once 
you have run over it once using list(). Then, you run over it again with 
any() and all(), but they don't see any values so return the default 
value.

Change the generator expression to a list comprehension [ ... ] and you 
will get the results you want.

----------
nosy: +steven.daprano

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 06:12:56 2015
From: report at bugs.python.org (Tim Peters)
Date: Tue, 29 Sep 2015 04:12:56 +0000
Subject: [issue25261] Incorrect Return Values for any() and all() Built-in
 Functions
In-Reply-To: <1443499554.6.0.480253610351.issue25261@psf.upfronthosting.co.za>
Message-ID: <1443499976.98.0.41772616826.issue25261@psf.upfronthosting.co.za>


Tim Peters added the comment:

You wholly consume the iterator after the first time you apply `list()` to it.  Therefore both `any()` and `all()` see an empty iterator, and return the results appropriate for an empty sequence:

>>> multiples_of_6 = (not (i % 6) for i in range(1, 10))
>>> list(multiples_of_6)
[False, False, False, False, False, True, False, False, False]
>>> list(multiples_of_6)  # note:  the iterator is exhausted!
[]
>>> any([])
False
>>> all([])
True

----------
nosy: +tim.peters
resolution:  -> not a bug
stage:  -> resolved

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 06:24:42 2015
From: report at bugs.python.org (Tim Peters)
Date: Tue, 29 Sep 2015 04:24:42 +0000
Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation)
In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za>
Message-ID: <1443500682.82.0.146968051855.issue24773@psf.upfronthosting.co.za>


Changes by Tim Peters :


----------
nosy: +tim.peters

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 06:27:35 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 29 Sep 2015 04:27:35 +0000
Subject: [issue25250] AttributeError: 'MSVCCompiler' object has no attribute
 '_MSVCCompiler__version'
In-Reply-To: <1443385494.46.0.0275925380659.issue25250@psf.upfronthosting.co.za>
Message-ID: <1443500855.88.0.858513242762.issue25250@psf.upfronthosting.co.za>


Steve Dower added the comment:

if sys.version_info[:2] >= (3, 3):
    # MSVC version is >= 9.0

Alternatively:

if sys.version_info[:2] >= (3, 5):
    # MSVC version is >= 14.0, or
    # _msvccompiler.MSVCCompiler does not have __version

or

if self.compiler.compiler_type == "msvc" and int(getattr(self.compiler, '_MSVCCompiler__version'), 10) <= 9:
    # MSVC version is >= 9.0

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 06:44:22 2015
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 29 Sep 2015 04:44:22 +0000
Subject: [issue25261] Incorrect Return Values for any() and all() Built-in
 Functions
In-Reply-To: <1443499554.6.0.480253610351.issue25261@psf.upfronthosting.co.za>
Message-ID: <1443501862.99.0.504024103925.issue25261@psf.upfronthosting.co.za>


Changes by Zachary Ware :


----------
components: +Library (Lib) -Build
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 06:48:48 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 29 Sep 2015 04:48:48 +0000
Subject: [issue21506] Windows MSI installer should mklink (symlink) python.exe
 to python2.7.exe
In-Reply-To: <1400067370.68.0.607872004364.issue21506@psf.upfronthosting.co.za>
Message-ID: <1443502128.39.0.983929559805.issue21506@psf.upfronthosting.co.za>


Steve Dower added the comment:

The file is so small that a second copy is just as cheap - literally everything is in the DLL. It could certainly be added to 3.6, and I'll probably get to it eventually, but right now I'm still focused on 3.5.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 06:49:14 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 29 Sep 2015 04:49:14 +0000
Subject: [issue25091] Windows Installer uses small font
In-Reply-To: <1442194665.29.0.878710305111.issue25091@psf.upfronthosting.co.za>
Message-ID: <1443502154.17.0.872497863486.issue25091@psf.upfronthosting.co.za>


Changes by Steve Dower :


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 07:22:59 2015
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 29 Sep 2015 05:22:59 +0000
Subject: [issue25258] HtmlParser doesn't handle void element tags correctly
In-Reply-To: <1443468394.25.0.617953373069.issue25258@psf.upfronthosting.co.za>
Message-ID: <1443504179.0.0.506815167012.issue25258@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

>From the specification, void element has no end tag, so I think this
behaviour can not be called incorrect. For void element, only
handle_starttag is called.

And for start tag ends with '/>', actually HTMLParser calls
handle_startendtag, which invokes handle_starttag and
handle_endtag.

I think there are two solutions, filter void elements in the library
and then invoke handle_startendtag, or filter void elements in the
application in handle_starttag and then invoke handle_endtag.

----------
nosy: +xiang.zhang

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 07:57:15 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Sep 2015 05:57:15 +0000
Subject: [issue24028] Idle: add doc subsection on calltips
In-Reply-To: <1429721880.11.0.245757615571.issue24028@psf.upfronthosting.co.za>
Message-ID: <20150929055712.94127.95022@psf.io>


Roundup Robot added the comment:

New changeset 395d363e34e1 by Terry Jan Reedy in branch '2.7':
Issue #24028: Add subsection about Idle calltips.
https://hg.python.org/cpython/rev/395d363e34e1

New changeset 8103dadb9ef7 by Terry Jan Reedy in branch '3.4':
Issue #24028: Add subsection about Idle calltips.
https://hg.python.org/cpython/rev/8103dadb9ef7

New changeset 3481c466926a by Terry Jan Reedy in branch '3.5':
Merge with 3.4, Issue #24028: Add subsection about Idle calltips.
https://hg.python.org/cpython/rev/3481c466926a

New changeset e025bdffd71c by Terry Jan Reedy in branch 'default':
Merge with 3.5, Issue #24028: Add subsection about Idle calltips.
https://hg.python.org/cpython/rev/e025bdffd71c

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 07:58:07 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 29 Sep 2015 05:58:07 +0000
Subject: [issue24028] Idle: add doc subsection on calltips
In-Reply-To: <1429721880.11.0.245757615571.issue24028@psf.upfronthosting.co.za>
Message-ID: <1443506287.79.0.965188569451.issue24028@psf.upfronthosting.co.za>


Changes by Terry J. Reedy :


----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 08:14:22 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Sep 2015 06:14:22 +0000
Subject: [issue25262] Issues with BINUNICODE8 and BINBYTES8 opcodes in pickle
Message-ID: <1443507262.81.0.140687476176.issue25262@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There are issues with BINUNICODE8 and BINBYTES8 opcodes in pickle.

1. Unpickling BINBYTES8 is not implemented in Python implementation.

2. Highest 32 bits of 64-bit size are silently ignored in C implementation on 32-bit platforms.

3. There are no tests for BINUNICODE8 and BINBYTES8.

Proposed patch fixes these issues.

----------
assignee: serhiy.storchaka
components: Extension Modules, Library (Lib), Tests
files: pickle_binbytes8.patch
keywords: patch
messages: 251823
nosy: alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Issues with BINUNICODE8 and BINBYTES8 opcodes in pickle
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40615/pickle_binbytes8.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 08:43:12 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 29 Sep 2015 06:43:12 +0000
Subject: [issue21995] Idle: pseudofiles have no buffer attribute.
In-Reply-To: <1405550850.77.0.279876996055.issue21995@psf.upfronthosting.co.za>
Message-ID: <1443508992.85.0.861830934321.issue21995@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Related #23220 has draft of part of what pushed.  I want to do more on the subject.

----------
assignee: docs at python -> terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 08:51:54 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 29 Sep 2015 06:51:54 +0000
Subject: [issue23220] Documents input/output effects of how IDLE runs user code
In-Reply-To: <1420937687.17.0.885670059147.issue23220@psf.upfronthosting.co.za>
Message-ID: <1443509514.72.0.667459337756.issue23220@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Issue #21995 discussed same issue from cause side, as opposed to result. The new section is partly based on what I wrote above.  I am not satisfied with it yet.

New changeset ac6ade0c5927 by Terry Jan Reedy in branch '2.7':
Issue 21995: Explain some differences between IDLE and console Python.
https://hg.python.org/cpython/rev/ac6ade0c5927

New changeset ca6c9cc77c20 by Terry Jan Reedy in branch '3.4':
Issue 21995: Explain some differences between IDLE and console Python.
https://hg.python.org/cpython/rev/ca6c9cc77c20

----------
assignee: docs at python -> terry.reedy
stage: patch review -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 09:25:18 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 07:25:18 +0000
Subject: [issue25262] Issues with BINUNICODE8 and BINBYTES8 opcodes in pickle
In-Reply-To: <1443507262.81.0.140687476176.issue25262@psf.upfronthosting.co.za>
Message-ID: <1443511518.66.0.757000511678.issue25262@psf.upfronthosting.co.za>


STINNER Victor added the comment:

To access an array item, the type of the index variable must be size_t (or a type with the same size), otherwise the compiler produce less efficient machine code:
http://www.viva64.com/en/a/0050/

=> please keep Py_ssize_t type for i

(I didn't check for the specific case of Py_ssize_t: it's signed. Does GCC emit the most efficient machine code for it?)

diff -r 16c8278c03f6 Modules/_pickle.c
--- a/Modules/_pickle.c
+++ b/Modules/_pickle.c
@@ -4606,10 +4606,17 @@ static Py_ssize_t
 calc_binsize(char *bytes, int nbytes)
 {
     unsigned char *s = (unsigned char *)bytes;
-    Py_ssize_t i;
+    int i;
     size_t x = 0;
 
-    for (i = 0; i < nbytes && (size_t)i < sizeof(size_t); i++) {
+    if (nbytes > (int)sizeof(size_t)) {
+        for (i = (int)sizeof(size_t); i < nbytes; i++) {
+            if (s[i])
+                return -1;
+        }
+        nbytes = (int)sizeof(size_t);
+    }

Please add a comment here to explain that the first loop check for integer overflow, it's not obvious at the first read.

Does the Python implementation of pickle produce BINBYTES8? If not: why not?

Note: the patch is probably based on a private Mercurial revision, so it didn't get the [Review] button.

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 09:54:14 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 07:54:14 +0000
Subject: [issue25263] test_tkinter fails randomly on the buildbots "AMD64
 Windows10" (3.4, 3.5, 3.x)
Message-ID: <1443513254.01.0.657938826089.issue25263@psf.upfronthosting.co.za>


New submission from STINNER Victor:

http://buildbot.python.org/all/builders/AMD64%20Windows10%203.x/builds/203/steps/test/logs/stdio

======================================================================
ERROR: setUpClass (tkinter.test.test_tkinter.test_font.FontTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildarea\3.x.bolen-windows10\build\lib\tkinter\test\test_tkinter\test_font.py", line 17, in setUpClass
    cls.font = font.Font(root=cls.root, name=fontname, exists=True)
  File "D:\buildarea\3.x.bolen-windows10\build\lib\tkinter\font.py", line 71, in __init__
    root = tkinter._default_root
AttributeError: module 'tkinter' has no attribute '_default_root'

======================================================================
ERROR: test_use (tkinter.test.test_tkinter.test_widgets.ToplevelTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildarea\3.x.bolen-windows10\build\lib\tkinter\test\test_tkinter\test_widgets.py", line 95, in test_use
    widget2 = self.create(use=wid)
  File "D:\buildarea\3.x.bolen-windows10\build\lib\tkinter\test\test_tkinter\test_widgets.py", line 70, in create
    return tkinter.Toplevel(self.root, **kwargs)
  File "D:\buildarea\3.x.bolen-windows10\build\lib\tkinter\__init__.py", line 2181, in __init__
    BaseWidget.__init__(self, master, 'toplevel', cnf, {}, extra)
  File "D:\buildarea\3.x.bolen-windows10\build\lib\tkinter\__init__.py", line 2138, in __init__
    (widgetName, self._w) + extra + self._options(cnf))
_tkinter.TclError: integer value too large to represent

----------
messages: 251827
nosy: haypo
priority: normal
severity: normal
status: open
title: test_tkinter fails randomly on the buildbots "AMD64 Windows10" (3.4, 3.5, 3.x)
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 09:54:24 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 07:54:24 +0000
Subject: [issue25263] test_tkinter fails randomly on the buildbots "AMD64
 Windows10" (3.4, 3.5, 3.x)
In-Reply-To: <1443513254.01.0.657938826089.issue25263@psf.upfronthosting.co.za>
Message-ID: <1443513264.45.0.128326444452.issue25263@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
components: +Tests, Tkinter, Windows
nosy: +paul.moore, serhiy.storchaka, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 10:01:48 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 08:01:48 +0000
Subject: [issue25264] test_marshal always crashs on "AMD64 Windows10 2.7"
 buildbot
Message-ID: <1443513708.82.0.964856310612.issue25264@psf.upfronthosting.co.za>


New submission from STINNER Victor:

test_marshal crash on Windows AMD64 since the first build of the "AMD64 Windows10 2.7" buildbot:

http://buildbot.python.org/all/builders/AMD64%20Windows10%202.7/builds/1/steps/test/logs/stdio

It crashs since this build of the "AMD64 Windows8 2.7" buildbot:

http://buildbot.python.org/all/builders/AMD64%20Windows8%202.7/builds/368/steps/test/logs/stdio

Blamelist:

    Change #43682
    Category 	None
    Changed by 	Zachary Ware 
    Changed at 	Thu 16 Jul 2015 05:42:04
    Branch 	2.7
    Revision 	ca78b9449e040abf313659ea00ddcb6b20a68830
    Comments

    Close #24508: Backport the 3.5 MSBuild project files.

    The old project files move to PC/VS9.0 and remain supported.

    VS2008 is still required to build 2.7; VS2010 (or later, plus Windows SDK 7.1)
    is *also* required to use the new project files.

Between builds 367 and 368, the number of warnings doubled: 404 warnings => 796 warnings.


Recent build:

http://buildbot.python.org/all/builders/AMD64%20Windows10%202.7/builds/76/steps/test/logs/stdio

...
[ 53/401] test_marshal
program finished with exit code -1073741571

----------
components: Tests, Windows
messages: 251828
nosy: haypo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: test_marshal always crashs on "AMD64 Windows10 2.7" buildbot
type: crash
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 11:31:23 2015
From: report at bugs.python.org (Akira Li)
Date: Tue, 29 Sep 2015 09:31:23 +0000
Subject: [issue22798] time.mktime doesn't update time.tzname
In-Reply-To: <1415189548.18.0.514821385606.issue22798@psf.upfronthosting.co.za>
Message-ID: <1443519083.61.0.0632559858489.issue22798@psf.upfronthosting.co.za>


Akira Li added the comment:

> Would issue22798.diff patch address your issue?

No. The issue is that C mktime() may update C tzname on some platforms
but time.mktime() does not update time.tzname on these platforms while 
the time module docs suggest that it might be expected e.g.:

  Most of the functions defined in this module call platform C library
  functions with the same name. It may sometimes be helpful to consult
  the platform documentation, because the semantics of these functions 
  varies among platforms.

---

Unrelated: time.strftime('%Z') and
time.strftime('%Z', time.localtime(time.time())) can differ on some 
platforms and python versions
  http://stackoverflow.com/questions/32353015/python-time-strftime-z-is-always-zero-instead-of-timezone-offset

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 11:33:08 2015
From: report at bugs.python.org (Akira Li)
Date: Tue, 29 Sep 2015 09:33:08 +0000
Subject: [issue24773] Implement PEP 495 (Local Time Disambiguation)
In-Reply-To: <1438456647.64.0.191464539374.issue24773@psf.upfronthosting.co.za>
Message-ID: <1443519188.72.0.163978529422.issue24773@psf.upfronthosting.co.za>


Changes by Akira Li <4kir4.1i at gmail.com>:


----------
nosy: +akira

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 11:37:52 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 09:37:52 +0000
Subject: [issue24164] Support pickling objects with __new__ with keyword
 arguments with protocol 2+
In-Reply-To: <1431341390.51.0.0928642680419.issue24164@psf.upfronthosting.co.za>
Message-ID: <1443519472.03.0.137006441915.issue24164@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"Pickling of objects of classes whose __new__ mandates the use of keyword-only arguments is supported with protocol 4 (using a new opcode NEWOBJ_EX)."

Hum, can you please write a short example of such class which can only be pickled by the protocol 4 currently? Just for my information.

I understand that some objects cannot be serialized by pickle with protocol lower than 4, whereas your change makes possible to serialize them on Python 3, and it will be possible to deserialize them on Python 2 and Python 3.

If I understood correctly, the change makes sense.

I reviewed the patch, it looks good to me.

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 11:41:01 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 09:41:01 +0000
Subject: [issue22609] Constructors of some mapping classes don't accept `self`
 keyword argument
In-Reply-To: <1413029049.09.0.127316928921.issue22609@psf.upfronthosting.co.za>
Message-ID: <1443519661.94.0.471458525307.issue22609@psf.upfronthosting.co.za>


STINNER Victor added the comment:

UserDict_self_and_dict_keywords_3.patch looks good to me.

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 11:43:44 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 09:43:44 +0000
Subject: [issue24483] Avoid repeated hash calculation in C implementation of
 functools.lru_cache()
In-Reply-To: <1434890042.2.0.0991345110525.issue24483@psf.upfronthosting.co.za>
Message-ID: <1443519824.6.0.615917197599.issue24483@psf.upfronthosting.co.za>


STINNER Victor added the comment:

clru_cache_known_hash_5.larry.patch looks good to me. Python 3.5 has no more restriction to push patches, go ahead Serhiy, push it to 3.5 & 3.6.

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 11:46:57 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 09:46:57 +0000
Subject: [issue23640] int.from_bytes() is broken for subclasses
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1443520017.62.0.367535243047.issue23640@psf.upfronthosting.co.za>


STINNER Victor added the comment:

0002-int.from_bytes-calls-constructor-for-subclasses.patch looks good to me, but see my review on Rietveld for 2 minor comments.

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 11:49:21 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 09:49:21 +0000
Subject: [issue25111] Broken compatibility in FrameSummary equality
In-Reply-To: <1442252923.78.0.0672158797601.issue25111@psf.upfronthosting.co.za>
Message-ID: <1443520161.13.0.279566874365.issue25111@psf.upfronthosting.co.za>


STINNER Victor added the comment:

traceback_FrameSummary_equality_2.patch looks good to me, but I have the same remark than Berker (see the review).

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 11:51:29 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 29 Sep 2015 09:51:29 +0000
Subject: [issue25111] Broken compatibility in FrameSummary equality
In-Reply-To: <1442252923.78.0.0672158797601.issue25111@psf.upfronthosting.co.za>
Message-ID: <1443520289.23.0.282941771892.issue25111@psf.upfronthosting.co.za>


Robert Collins added the comment:

LGTM too.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 11:52:34 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 09:52:34 +0000
Subject: [issue18814] Add utilities to "clean" surrogate code points from
 strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1443520354.21.0.723669385973.issue18814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I also want "detect if there are any surrogates".

Could you please open a separated issue for this function/method?

I believe that it's very different than other proposed functions/methods.

It was proposed before to add methods like "is_ascii()" but the request was rejected because other Python implementations don't implement Unicode using the PEP 393 and so the method would be less efficient than expected, depending on the implementation of Python.

Well, I don't know if we should add methods relying on the PEP 393 or not. It's probably better to discuss such "political" question on python-dev.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 11:53:23 2015
From: report at bugs.python.org (chris laws)
Date: Tue, 29 Sep 2015 09:53:23 +0000
Subject: [issue23972] Asyncio reuseport
In-Reply-To: <1429185135.77.0.485030290106.issue23972@psf.upfronthosting.co.za>
Message-ID: <1443520403.02.0.135154708365.issue23972@psf.upfronthosting.co.za>


chris laws added the comment:

Rebase patch onto current master.

----------
Added file: http://bugs.python.org/file40616/23972_cjl_v003.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 12:00:24 2015
From: report at bugs.python.org (Rahil Khurshid)
Date: Tue, 29 Sep 2015 10:00:24 +0000
Subject: [issue25265] Python install failed windows 8.1- Error 0x80240017:
 Failed to execute MSU package
Message-ID: <1443520824.73.0.137010188648.issue25265@psf.upfronthosting.co.za>


New submission from Rahil Khurshid:

Just downloaded and try to install the Python 3.5.0 .exe installer on Windows 8.1 Pro, which unexpectedly failed to install and crash on this error
Error 0x80240017: Failed to execute MSU package (according to the logs)
Then tried the older 3.4.3 .msi installer which worked for me. My guess it's about the new .exe installer.

----------
components: Installation, Windows
messages: 251838
nosy: Rahil Khurshid, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python install failed windows 8.1- Error 0x80240017: Failed to execute MSU package
type: crash
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 12:02:58 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 10:02:58 +0000
Subject: [issue25265] Python install failed windows 8.1- Error 0x80240017:
 Failed to execute MSU package
In-Reply-To: <1443520824.73.0.137010188648.issue25265@psf.upfronthosting.co.za>
Message-ID: <1443520978.74.0.993336346604.issue25265@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Duplicate of bug #25157.

----------
nosy: +haypo
resolution:  -> duplicate
status: open -> closed
superseder:  -> Installing Python 3.5.0 32bit on Windows 8.1 64bit system gives Error 0x80240017

_______________________________________
Python tracker 

_______________________________________

From mal at egenix.com  Tue Sep 29 12:20:26 2015
From: mal at egenix.com (M.-A. Lemburg)
Date: Tue, 29 Sep 2015 12:20:26 +0200
Subject: [issue22798] time.mktime doesn't update time.tzname
In-Reply-To: <1443519083.61.0.0632559858489.issue22798@psf.upfronthosting.co.za>
References: <1443519083.61.0.0632559858489.issue22798@psf.upfronthosting.co.za>
Message-ID: <560A65EA.2020106@egenix.com>

On 29.09.2015 11:31, Akira Li wrote:
> 
> Akira Li added the comment:
> 
>> Would issue22798.diff patch address your issue?
> 
> No. The issue is that C mktime() may update C tzname on some platforms
> but time.mktime() does not update time.tzname on these platforms while 
> the time module docs suggest that it might be expected e.g.:
> 
>   Most of the functions defined in this module call platform C library
>   functions with the same name. It may sometimes be helpful to consult
>   the platform documentation, because the semantics of these functions 
>   varies among platforms.

tzname is set when the module is being loaded and not updated
afterwards (unless you call tzset()). I can't really see why you
would expect a module global in Python to follow the semantics
of a C global, unless this is explicitly documented.

Note: The fact that tzset() does update the module globals is
not documented.

> ---
> 
> Unrelated: time.strftime('%Z') and
> time.strftime('%Z', time.localtime(time.time())) can differ on some 
> platforms and python versions
>   http://stackoverflow.com/questions/32353015/python-time-strftime-z-is-always-zero-instead-of-timezone-offset

The StackOverflow discussion targets %z (lower case z),
not %Z (with capital Z).

I think this is just a documentation bug.

Overall, I think that relying on those module globals is
not a good idea. They are not threadsafe and their values
can only be trusted right after module import. It's much
safer to access the resp. values by using struct_time values
or strftime().

-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Tue Sep 29 12:20:40 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Sep 2015 10:20:40 +0000
Subject: [issue22798] time.mktime doesn't update time.tzname
In-Reply-To: <1443519083.61.0.0632559858489.issue22798@psf.upfronthosting.co.za>
Message-ID: <560A65EA.2020106@egenix.com>


Marc-Andre Lemburg added the comment:

On 29.09.2015 11:31, Akira Li wrote:
> 
> Akira Li added the comment:
> 
>> Would issue22798.diff patch address your issue?
> 
> No. The issue is that C mktime() may update C tzname on some platforms
> but time.mktime() does not update time.tzname on these platforms while 
> the time module docs suggest that it might be expected e.g.:
> 
>   Most of the functions defined in this module call platform C library
>   functions with the same name. It may sometimes be helpful to consult
>   the platform documentation, because the semantics of these functions 
>   varies among platforms.

tzname is set when the module is being loaded and not updated
afterwards (unless you call tzset()). I can't really see why you
would expect a module global in Python to follow the semantics
of a C global, unless this is explicitly documented.

Note: The fact that tzset() does update the module globals is
not documented.

> ---
> 
> Unrelated: time.strftime('%Z') and
> time.strftime('%Z', time.localtime(time.time())) can differ on some 
> platforms and python versions
>   http://stackoverflow.com/questions/32353015/python-time-strftime-z-is-always-zero-instead-of-timezone-offset

The StackOverflow discussion targets %z (lower case z),
not %Z (with capital Z).

I think this is just a documentation bug.

Overall, I think that relying on those module globals is
not a good idea. They are not threadsafe and their values
can only be trusted right after module import. It's much
safer to access the resp. values by using struct_time values
or strftime().

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 12:35:12 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Sep 2015 10:35:12 +0000
Subject: [issue25227] Optimize ASCII/latin1 encoder with surrogateescape error
 handlers
In-Reply-To: <1443098883.44.0.854905908837.issue25227@psf.upfronthosting.co.za>
Message-ID: <20150929103508.82658.51256@psf.io>


Roundup Robot added the comment:

New changeset 128a3f03ddeb by Victor Stinner in branch 'default':
Optimize ascii/latin1+surrogateescape encoders
https://hg.python.org/cpython/rev/128a3f03ddeb

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 12:37:07 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 10:37:07 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <1443523027.62.0.301139403454.issue25220@psf.upfronthosting.co.za>


STINNER Victor added the comment:

regrtest_class-2.patch: rebased path to try to get the [review] link.

----------
Added file: http://bugs.python.org/file40617/regrtest_class-2.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 12:39:51 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 10:39:51 +0000
Subject: [issue25227] Optimize ASCII/latin1 encoder with surrogateescape error
 handlers
In-Reply-To: <1443098883.44.0.854905908837.issue25227@psf.upfronthosting.co.za>
Message-ID: <1443523191.88.0.281110961883.issue25227@psf.upfronthosting.co.za>


STINNER Victor added the comment:

INADA Naoki: The ASCII and latin1 encoders are now up to 3 times as fast when the surrogateescape error handler is used in Python 3.6.

----------
nosy: +naoki, serhiy.storchaka
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 13:21:01 2015
From: report at bugs.python.org (Florin Papa)
Date: Tue, 29 Sep 2015 11:21:01 +0000
Subject: [issue25266] mako benchmark not working in Python 3.6
Message-ID: <1443525661.77.0.371661807917.issue25266@psf.upfronthosting.co.za>


New submission from Florin Papa:

Hi All,

My name is Florin Papa and I work in the Server Languages Optimizations Team at Intel Corporation.

I would like to submit a patch that deprecates the mako benchmark for Python 3.6 and above. The mako benchmark uses inspect.getargspec(), which is deprecated and was removed in Python 3.6. Therefore, it crashes with the message "AttributeError: module 'inspect' has no attribute 'getargspec'" when using the latest version of Python on the default branch.

The patch limits the version range of the mako benchmark to Python 3.5 and below.

To apply the patch please follow these steps:

hg clone https://hg.python.org/benchmarks
cd benchmarks/
copy mako_deprecation.patch to the current directory
hg import --no-commit mako_deprecation.patch
 
Regards,
Florin

----------
components: Benchmarks
files: mako_deprecation.patch
keywords: patch
messages: 251844
nosy: brett.cannon, florin.papa, pitrou
priority: normal
severity: normal
status: open
title: mako benchmark not working in Python 3.6
type: crash
versions: Python 3.6
Added file: http://bugs.python.org/file40618/mako_deprecation.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 13:30:34 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 11:30:34 +0000
Subject: [issue25267] Optimize UTF-8 encoder with error handlers
Message-ID: <1443526234.91.0.845116536507.issue25267@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch optimizes the UTF-8 encoder for error handlers: ignore, replace, surrogateescape, surrogatepass. It is based on the patch  faster_surrogates_hadling.patch written by Serhiy Storchaka in the issue #24870.

It also modifies unicode_encode_ucs1() to use memset() for the replace error handler. It should be faster for long sequences of unencodable characters, but it may be slower for short sequences of unencodable characters.

The patch adds new unit tests and fix unit tests to ensure that utf-8-sig codec is also well tested.

TODO: write a benchmark.

See also the issue #25227 which optimized ASCII and latin1 encoders with the surrogateescape error handlers.

----------
components: Unicode
files: utf8_encoder_errors.patch
keywords: patch
messages: 251845
nosy: ezio.melotti, haypo, naoki, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Optimize UTF-8 encoder with error handlers
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file40619/utf8_encoder_errors.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 13:45:20 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 11:45:20 +0000
Subject: [issue25266] mako benchmark not working in Python 3.6
In-Reply-To: <1443525661.77.0.371661807917.issue25266@psf.upfronthosting.co.za>
Message-ID: <1443527120.13.0.797770278783.issue25266@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hum, it would be nice to patch the mako benchmark to replace inspect.getargspec() with inspect.signature() (available since Python 3.3).

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 13:49:39 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 11:49:39 +0000
Subject: [issue25260] python -m test --coverage doesn't work on Windows
In-Reply-To: <1443478802.75.0.02674996421.issue25260@psf.upfronthosting.co.za>
Message-ID: <1443527379.46.0.0197909524279.issue25260@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Attached patch simply removes the list of ignored directories. It fixes test_regrtest.test_coverage() on Windows.

----------
keywords: +patch
nosy: +barry, georg.brandl, vinay.sajip
Added file: http://bugs.python.org/file40620/regrtest_coverage.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 13:53:51 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 11:53:51 +0000
Subject: [issue25001] Make --nowindows argument to regrtest propagate when
 running with -j
In-Reply-To: <1441399617.05.0.891415993838.issue25001@psf.upfronthosting.co.za>
Message-ID: <1443527631.98.0.165333643521.issue25001@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 13:53:52 2015
From: report at bugs.python.org (Matt Hickford)
Date: Tue, 29 Sep 2015 11:53:52 +0000
Subject: [issue25250] AttributeError: 'MSVCCompiler' object has no attribute
 '_MSVCCompiler__version'
In-Reply-To: <1443500855.88.0.858513242762.issue25250@psf.upfronthosting.co.za>
Message-ID: 


Matt Hickford added the comment:

Hi Steve. Thanks for your reply. In the end I went with your something
similar to your third suggestion. It's important I wanted to condition on
what compiler distutils is using *now* to the build the extension on my
computer, rather than what compiler was originally used to build Python
(which needn't match).

On 29 September 2015 at 05:27, Steve Dower  wrote:

>
> Steve Dower added the comment:
>
> if sys.version_info[:2] >= (3, 3):
>     # MSVC version is >= 9.0
>
> Alternatively:
>
> if sys.version_info[:2] >= (3, 5):
>     # MSVC version is >= 14.0, or
>     # _msvccompiler.MSVCCompiler does not have __version
>
> or
>
> if self.compiler.compiler_type == "msvc" and int(getattr(self.compiler,
> '_MSVCCompiler__version'), 10) <= 9:
>     # MSVC version is >= 9.0
>
> ----------
>
> _______________________________________
> Python tracker 
> 
> _______________________________________
>

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 14:00:14 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Sep 2015 12:00:14 +0000
Subject: [issue18174] Make regrtest with --huntrleaks check for fd leaks
In-Reply-To: <1370807273.91.0.83033499223.issue18174@psf.upfronthosting.co.za>
Message-ID: <20150929120007.11710.52209@psf.io>


Roundup Robot added the comment:

New changeset 0e7d71a3bf0d by Victor Stinner in branch 'default':
Issue #18174: Explain why is_valid_fd() uses dup() instead of fstat()
https://hg.python.org/cpython/rev/0e7d71a3bf0d

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 14:19:10 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Sep 2015 12:19:10 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <20150929121904.3664.66932@psf.io>


Roundup Robot added the comment:

New changeset e5165dcae942 by Victor Stinner in branch 'default':
Issue #25220: Add test for --wait in test_regrtest
https://hg.python.org/cpython/rev/e5165dcae942

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 14:45:32 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 29 Sep 2015 12:45:32 +0000
Subject: [issue25268] Support pointing frozen modules to the corresponding
 source files, if available.
Message-ID: <1443530732.6.0.47195880813.issue25268@psf.upfronthosting.co.za>


New submission from Eric Snow:

(a generalization of issue #21335)

One way or another, we should be able to record the appropriate path in the resulting data when a module is frozen.  Keeping track of the source location is useful when debugging, especially with tracebacks.  Also see a related conversation on python-dev. [1]

If the original filename for a frozen module is preserved, several possibilities open up:

* the `get_source` method of `importlib._bootstrap.FrozenImporter` could return the original source
* the traceback module could work around the co_filename issue pointed out in #21335
* the filename could be incorporated into the value set for co_filename and __file__
* frozen modules could be optionally reloaded from source

Given that the filename would (likely) be available only through loading the module, it *might* not make sense to store it on the module's spec.  However, it might also make sense to store the filename in a way that it can be exposed during the "find" stage of import.  In that case it would arguably *belong* on the module's spec.

Note that there's a chance that the original filename for a frozen module is no longer available.  That shouldn't be much of a problem, though.


[1] https://mail.python.org/pipermail/python-dev/2014-April/134097.html

----------
components: Library (Lib)
messages: 251851
nosy: brett.cannon, eric.snow, ncoghlan
priority: low
severity: normal
stage: needs patch
status: open
title: Support pointing frozen modules to the corresponding source files, if available.
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 14:47:25 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 29 Sep 2015 12:47:25 +0000
Subject: [issue21335] Update importlib.__init__ to reset _frozen_importlib's
 loader to SourceFileLoader
In-Reply-To: <1398265311.8.0.131352279084.issue21335@psf.upfronthosting.co.za>
Message-ID: <1443530845.98.0.161000011827.issue21335@psf.upfronthosting.co.za>


Eric Snow added the comment:

The underlying issue extends to all frozen modules.  I've opened #25268 to consider how we might address it.

----------
nosy: +eric.snow

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 14:48:03 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Sep 2015 12:48:03 +0000
Subject: [issue25269] Add method to detect if a string contains surrogates
Message-ID: <1443530883.35.0.305082154526.issue25269@psf.upfronthosting.co.za>


New submission from R. David Murray:

Because surrogates are in several contexts used to "smuggle" bytes through string APIs using surrogateescape, it is very useful to be able to determine if a given string contains surrogates.  The email package, for example, uses different logic to handle strings that contain smuggled bytes and strings that don't when serializing a Message object.  Currently it uses x.encode() and checks for an exception (we determined that for CPython this was the most efficient method to check).  It would be better, I think, to have a dedicated method on str for this, among other reasons so that different python implementations could optimize it appropriately.

(Note that another aspect of dealing with surrogateescaped strings is discussed in issue 18814.)

----------
components: Interpreter Core
messages: 251853
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: Add method to detect if a string contains surrogates
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 14:48:04 2015
From: report at bugs.python.org (Eric Snow)
Date: Tue, 29 Sep 2015 12:48:04 +0000
Subject: [issue25268] Support pointing frozen modules to the corresponding
 source files, if available.
In-Reply-To: <1443530732.6.0.47195880813.issue25268@psf.upfronthosting.co.za>
Message-ID: <1443530884.71.0.0716746902975.issue25268@psf.upfronthosting.co.za>


Changes by Eric Snow :


----------
nosy: +lemburg

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 14:48:38 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Sep 2015 12:48:38 +0000
Subject: [issue18814] Add utilities to "clean" surrogate code points from
 strings
In-Reply-To: <1377230552.02.0.907422956718.issue18814@psf.upfronthosting.co.za>
Message-ID: <1443530918.86.0.299738857839.issue18814@psf.upfronthosting.co.za>


R. David Murray added the comment:

Done: issue 25269.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 15:05:02 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 13:05:02 +0000
Subject: [issue25269] Add method to detect if a string contains surrogates
In-Reply-To: <1443530883.35.0.305082154526.issue25269@psf.upfronthosting.co.za>
Message-ID: <1443531902.99.0.733014204778.issue25269@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
components: +Unicode
nosy: +ezio.melotti, haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 15:05:40 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 29 Sep 2015 13:05:40 +0000
Subject: [issue25250] AttributeError: 'MSVCCompiler' object has no attribute
 '_MSVCCompiler__version'
In-Reply-To: <1443385494.46.0.0275925380659.issue25250@psf.upfronthosting.co.za>
Message-ID: <1443531940.92.0.291244848619.issue25250@psf.upfronthosting.co.za>


Steve Dower added the comment:

Well __version is determined by looking at sys.version to see what version was used to build Python, so you aren't really getting the "actual" one, though in practice it doesn't matter.

For Python 3.5 and later you could get different versions from the one that was used to build, but it will always be at least 14.0 and there's deliberately no way for people to depend on that information other than in C source code.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 15:10:10 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 29 Sep 2015 13:10:10 +0000
Subject: [issue25157] Installing Python 3.5.0 32bit on Windows 8.1 64bit
 system gives Error 0x80240017
In-Reply-To: <1442526643.4.0.412457342038.issue25157@psf.upfronthosting.co.za>
Message-ID: <1443532210.25.0.99319886161.issue25157@psf.upfronthosting.co.za>


Changes by Steve Dower :


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 15:14:31 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Sep 2015 13:14:31 +0000
Subject: [issue25262] Issues with BINUNICODE8 and BINBYTES8 opcodes in pickle
In-Reply-To: <1443511518.66.0.757000511678.issue25262@psf.upfronthosting.co.za>
Message-ID: <1792414.VdrpBogoOr@raxxla>


Serhiy Storchaka added the comment:

> To access an array item, the type of the index variable must be size_t (or a
> type with the same size), otherwise the compiler produce less efficient
> machine code: http://www.viva64.com/en/a/0050/
> 
> => please keep Py_ssize_t type for i

i is small integer between 0 and 8. I don't think that this article is 
related. Py_ssize_t is signed, and i is compared with int in a loop. And isn't 
Viva64 work only with Visual C++?  At least I found statements that can be not 
correct on platforms not supported by Microsoft.

> Please add a comment here to explain that the first loop check for integer
> overflow, it's not obvious at the first read.

Done.

> Does the Python implementation of pickle produce BINBYTES8? If not: why not?

Yes, it produces BINBYTES8 on 64-bit platform.

> Note: the patch is probably based on a private Mercurial revision, so it
> didn't get the [Review] button.

Yes, I had made some refactoring for unpickling tests and forgot to push they. 
Here is rebased patch.

----------
Added file: http://bugs.python.org/file40621/pickle_binbytes8_2.patch

_______________________________________
Python tracker 

_______________________________________
-------------- next part --------------
diff -r 377f200ad521 Lib/pickle.py
--- a/Lib/pickle.py	Tue Sep 29 15:51:02 2015 +0300
+++ b/Lib/pickle.py	Tue Sep 29 16:03:38 2015 +0300
@@ -1205,6 +1205,14 @@ class _Unpickler:
         self.append(str(self.read(len), 'utf-8', 'surrogatepass'))
     dispatch[BINUNICODE8[0]] = load_binunicode8
 
+    def load_binbytes8(self):
+        len, = unpack(' maxsize:
+            raise UnpicklingError("BINBYTES8 exceeds system's maximum size "
+                                  "of %d bytes" % maxsize)
+        self.append(self.read(len))
+    dispatch[BINBYTES8[0]] = load_binbytes8
+
     def load_short_binstring(self):
         len = self.read(1)[0]
         data = self.read(len)
diff -r 377f200ad521 Lib/test/pickletester.py
--- a/Lib/test/pickletester.py	Tue Sep 29 15:51:02 2015 +0300
+++ b/Lib/test/pickletester.py	Tue Sep 29 16:03:38 2015 +0300
@@ -857,6 +857,26 @@ class AbstractUnpickleTests(unittest.Tes
         self.assert_is_copy([(100,), (100,)],
                             self.loads(b'((Kdtp0\nh\x00l.))'))
 
+    def test_binbytes8(self):
+        dumped = b'\x80\x04\x8e\4\0\0\0\0\0\0\0\xe2\x82\xac\x00.'
+        self.assertEqual(self.loads(dumped), b'\xe2\x82\xac\x00')
+
+    def test_binunicode8(self):
+        dumped = b'\x80\x04\x8d\4\0\0\0\0\0\0\0\xe2\x82\xac\x00.'
+        self.assertEqual(self.loads(dumped), '\u20ac\x00')
+
+    @requires_32b
+    def test_large_32b_binbytes8(self):
+        dumped = b'\x80\x04\x8e\4\0\0\0\1\0\0\0\xe2\x82\xac\x00.'
+        with self.assertRaises((pickle.UnpicklingError, OverflowError)):
+            self.loads(dumped)
+
+    @requires_32b
+    def test_large_32b_binunicode8(self):
+        dumped = b'\x80\x04\x8d\4\0\0\0\1\0\0\0\xe2\x82\xac\x00.'
+        with self.assertRaises((pickle.UnpicklingError, OverflowError)):
+            self.loads(dumped)
+
     def test_get(self):
         pickled = b'((lp100000\ng100000\nt.'
         unpickled = self.loads(pickled)
diff -r 377f200ad521 Lib/test/test_pickle.py
--- a/Lib/test/test_pickle.py	Tue Sep 29 15:51:02 2015 +0300
+++ b/Lib/test/test_pickle.py	Tue Sep 29 16:03:38 2015 +0300
@@ -39,6 +39,16 @@ class PyUnpicklerTests(AbstractUnpickleT
         return u.load()
 
 
+class PyUnpicklerTests(AbstractUnpickleTests):
+
+    unpickler = pickle._Unpickler
+
+    def loads(self, buf, **kwds):
+        f = io.BytesIO(buf)
+        u = self.unpickler(f, **kwds)
+        return u.load()
+
+
 class PyPicklerTests(AbstractPickleTests):
 
     pickler = pickle._Pickler
diff -r 377f200ad521 Modules/_pickle.c
--- a/Modules/_pickle.c	Tue Sep 29 15:51:02 2015 +0300
+++ b/Modules/_pickle.c	Tue Sep 29 16:03:38 2015 +0300
@@ -4606,10 +4606,20 @@ static Py_ssize_t
 calc_binsize(char *bytes, int nbytes)
 {
     unsigned char *s = (unsigned char *)bytes;
-    Py_ssize_t i;
+    int i;
     size_t x = 0;
 
-    for (i = 0; i < nbytes && (size_t)i < sizeof(size_t); i++) {
+    if (nbytes > (int)sizeof(size_t)) {
+        /* Check for integer overflow.  BINBYTES8 and BINUNICODE8 opcodes
+         * have 64-bit size that can't be represented on 32-bit platform.
+         */
+        for (i = (int)sizeof(size_t); i < nbytes; i++) {
+            if (s[i])
+                return -1;
+        }
+        nbytes = (int)sizeof(size_t);
+    }
+    for (i = 0; i < nbytes; i++) {
         x |= (size_t) s[i] << (8 * i);
     }
 

From report at bugs.python.org  Tue Sep 29 15:30:34 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Sep 2015 13:30:34 +0000
Subject: [issue24164] Support pickling objects with __new__ with keyword
 arguments with protocol 2+
In-Reply-To: <1431341390.51.0.0928642680419.issue24164@psf.upfronthosting.co.za>
Message-ID: <1443533434.54.0.895486247047.issue24164@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Hum, can you please write a short example of such class which can only be pickled by the protocol 4 currently? Just for my information.

For now there are no such classes in the stdlib. No one implements __getnewargs_ex__. But an alternative implementation of pickling for methodcaller could use it (I implemented methodcaller pickling in issue22955 in different way, via __reduce_ex__, but used the same trick for passing keyword arguments to constructor).

Note that multiprocessing uses default protocol 3 (issue23403), and this is not configurable.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 15:40:30 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 13:40:30 +0000
Subject: [issue23403] Use pickle protocol 4 by default?
In-Reply-To: <1423258098.35.0.366066771775.issue23403@psf.upfronthosting.co.za>
Message-ID: <1443534030.78.0.97626918324.issue23403@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Can't we "negociate" the protocol automatically?

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 16:21:40 2015
From: report at bugs.python.org (Matt Hickford)
Date: Tue, 29 Sep 2015 14:21:40 +0000
Subject: [issue25250] AttributeError: 'MSVCCompiler' object has no attribute
 '_MSVCCompiler__version'
In-Reply-To: <1443531940.92.0.291244848619.issue25250@psf.upfronthosting.co.za>
Message-ID: 


Matt Hickford added the comment:

It matters if you're trying to write a library that builds reliably

1. On Linux
2. On Windows compiler=msvc
3. On Windows compiler=mingw32 (many people set this in distutils.cfg [1])

...for all Python versions 2.6 through 3.5 (24 combinations!) Anyway I
think I've got everything working simultaneously now. Thanks for your help.

Yes I saw that blog post?your blog post?about compiler independence [2]
from msvc 14.0 on. That's great news. Let me go study it.

[1] http://stackoverflow.com/q/3297254/284795
[2] http://stevedower.id.au/blog/building-for-python-3-5-part-two/

On 29 September 2015 at 14:05, Steve Dower  wrote:

>
> Steve Dower added the comment:
>
> Well __version is determined by looking at sys.version to see what version
> was used to build Python, so you aren't really getting the "actual" one,
> though in practice it doesn't matter.
>
> For Python 3.5 and later you could get different versions from the one
> that was used to build, but it will always be at least 14.0 and there's
> deliberately no way for people to depend on that information other than in
> C source code.
>
> ----------
>
> _______________________________________
> Python tracker 
> 
> _______________________________________
>

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 16:31:09 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Sep 2015 14:31:09 +0000
Subject: [issue25034] string.Formatter accepts empty fields but displays wrong
 when nested
In-Reply-To: <1441740193.79.0.679577096269.issue25034@psf.upfronthosting.co.za>
Message-ID: <20150929143104.16571.1735@psf.io>


Roundup Robot added the comment:

New changeset 9eae18e8af66 by Eric V. Smith in branch '3.4':
Fixed issue #25034: Fix string.Formatter problem with auto-numbering
https://hg.python.org/cpython/rev/9eae18e8af66

New changeset 65d7b4fd0332 by Eric V. Smith in branch '3.5':
Issue #25034: Merge from 3.4.
https://hg.python.org/cpython/rev/65d7b4fd0332

New changeset aef6365294c8 by Eric V. Smith in branch 'default':
Issue #25034: Merge from 3.5.
https://hg.python.org/cpython/rev/aef6365294c8

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 16:34:36 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 29 Sep 2015 14:34:36 +0000
Subject: [issue25034] string.Formatter accepts empty fields but displays wrong
 when nested
In-Reply-To: <1441740193.79.0.679577096269.issue25034@psf.upfronthosting.co.za>
Message-ID: <1443537276.23.0.0788647149636.issue25034@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Fixed in 3.4, 3.5, and 3.6. Thanks for the bug report and patch! I added you to the Misc/ACKS file.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 16:41:48 2015
From: report at bugs.python.org (Memeplex)
Date: Tue, 29 Sep 2015 14:41:48 +0000
Subject: [issue9334] argparse does not accept options taking arguments
 beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1443537708.07.0.611654544942.issue9334@psf.upfronthosting.co.za>


Memeplex added the comment:

Here is another manifestation of this problem: http://bugs.python.org/issue17050

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 17:14:06 2015
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 29 Sep 2015 15:14:06 +0000
Subject: [issue23640] int.from_bytes() is broken for subclasses
In-Reply-To: <1443424882.86.0.103758083754.issue23640@psf.upfronthosting.co.za>
Message-ID: <20150929151348.GA11929@bytereef.org>


Stefan Krah added the comment:

> There are similar issues with Decimal.from_float() (C implementation only), chain.from_iterable(), epoll.fromfd() and kqueue.fromfd(). All these alternative constructors don't call __new__ or __init__.

Could you create new issues? I need a summary. :)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 17:24:21 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 29 Sep 2015 15:24:21 +0000
Subject: [issue25250] AttributeError: 'MSVCCompiler' object has no attribute
 '_MSVCCompiler__version'
In-Reply-To: <1443385494.46.0.0275925380659.issue25250@psf.upfronthosting.co.za>
Message-ID: <1443540261.1.0.644462443691.issue25250@psf.upfronthosting.co.za>


Steve Dower added the comment:

Once you've established that MSVC is being used, you can infer the version from the Python version, is what I meant by "it doesn't matter". The version attribute on the compiler instance is never going to differ pre-3.5, and post-3.5 it doesn't even exist.

Generally, I'd say you're safer to detect and check _MSC_VER in your C code if it's relevant, as that will also handle builds that don't go via your setup.py.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 17:45:39 2015
From: report at bugs.python.org (Arnon Yaari)
Date: Tue, 29 Sep 2015 15:45:39 +0000
Subject: [issue11215] test_fileio error on AIX
In-Reply-To: <1297705150.47.0.994582308795.issue11215@psf.upfronthosting.co.za>
Message-ID: <1443541539.4.0.212319450175.issue11215@psf.upfronthosting.co.za>


Arnon Yaari added the comment:

Some AIX systems have seekable /dev/tty, as is the case here and in msg90762, and on my system too.
There is already an exemption in test_fileio.py for systems that have a seekable /dev/tty. AIX just needs to be exempt too. (from my experience, AIX and Solaris behave similarly in many cases, so it makes sense to add aix next to sunos).
I'm submitting a patch to fix this test case on AIX.

----------
keywords: +patch
nosy: +wiggin15
Added file: http://bugs.python.org/file40622/issue11215.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 17:48:32 2015
From: report at bugs.python.org (Arnon Yaari)
Date: Tue, 29 Sep 2015 15:48:32 +0000
Subject: [issue19006] UnitTest docs should have a single list of assertions
In-Reply-To: <1378914335.13.0.0543263347661.issue19006@psf.upfronthosting.co.za>
Message-ID: <1443541712.56.0.570301777777.issue19006@psf.upfronthosting.co.za>


Changes by Arnon Yaari :


----------
nosy: +wiggin15

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 17:58:21 2015
From: report at bugs.python.org (Matt Hickford)
Date: Tue, 29 Sep 2015 15:58:21 +0000
Subject: [issue25250] AttributeError: 'MSVCCompiler' object has no attribute
 '_MSVCCompiler__version'
In-Reply-To: <1443540261.1.0.644462443691.issue25250@psf.upfronthosting.co.za>
Message-ID: 


Matt Hickford added the comment:

Yes you're right. My setup.py if you're curious
https://github.com/hickford/primesieve-python/blob/master/setup.py

Separately, I think compiler=mingw32 is broken in Python 3.5 on computers
with Visual Studio 2015 installed.  http://bugs.python.org/issue25251 if
that interests you

On 29 September 2015 at 16:24, Steve Dower  wrote:

>
> Steve Dower added the comment:
>
> Once you've established that MSVC is being used, you can infer the version
> from the Python version, is what I meant by "it doesn't matter". The
> version attribute on the compiler instance is never going to differ
> pre-3.5, and post-3.5 it doesn't even exist.
>
> Generally, I'd say you're safer to detect and check _MSC_VER in your C
> code if it's relevant, as that will also handle builds that don't go via
> your setup.py.
>
> ----------
> resolution:  -> not a bug
> status: open -> closed
>
> _______________________________________
> Python tracker 
> 
> _______________________________________
>

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 18:02:43 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Sep 2015 16:02:43 +0000
Subject: [issue25268] Support pointing frozen modules to the corresponding
 source files, if available.
In-Reply-To: <1443530732.6.0.47195880813.issue25268@psf.upfronthosting.co.za>
Message-ID: <1443542563.0.0.915963711918.issue25268@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

I'm not sure which kind of use for frozen modules you have in mind.

The freeze tool allows you to replace paths in source path prefixes using the -r option. We use this in eGenix PyRun to set the prefix to "" since at run-time, the source files won't be available anyway and we want the users to see "this file is built into pyrun".

A traceback looks like this:
      ...
      File "/configparser.py", line 773, in get
      File "/configparser.py", line 374, in before_get
      File "/configparser.py", line 423, in _interpolate_some
    configparser.InterpolationSyntaxError: '%' must be followed by '%' or '(', found: '%12345'

which is quite readable, IMO.

Without -r, the original file path is added, so you must be looking at some other use case.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 18:05:58 2015
From: report at bugs.python.org (Paul Kehrer)
Date: Tue, 29 Sep 2015 16:05:58 +0000
Subject: [issue25270] codecs.escape_encode systemerror on empty byte string
Message-ID: <1443542758.27.0.114315188103.issue25270@psf.upfronthosting.co.za>


New submission from Paul Kehrer:

Python 3.5.0 (default, Sep 13 2015, 10:33:07) 
[GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import codecs
>>> codecs.escape_encode(b'')
Traceback (most recent call last):
  File "", line 1, in 
SystemError: Objects/bytesobject.c:3553: bad argument to internal function


I've tested this on Python 3.2 through 3.5.

----------
components: Interpreter Core
messages: 251868
nosy: reaperhulk
priority: normal
severity: normal
status: open
title: codecs.escape_encode systemerror on empty byte string
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 18:23:20 2015
From: report at bugs.python.org (Florian Bruhin)
Date: Tue, 29 Sep 2015 16:23:20 +0000
Subject: [issue25271] SystemError when doing codecs.escape_encode(b'')
Message-ID: <1443543800.33.0.489853899894.issue25271@psf.upfronthosting.co.za>


New submission from Florian Bruhin:

I can reproduce this with 3.4.3 and 3.5.0:

>>> import codecs
>>> codecs.escape_encode(b'')
Traceback (most recent call last):
  File "", line 1, in 
SystemError: Objects/bytesobject.c:3553: bad argument to internal function

----------
components: Interpreter Core
messages: 251869
nosy: The Compiler, doerwalter, lemburg
priority: normal
severity: normal
status: open
title: SystemError when doing codecs.escape_encode(b'')
type: behavior
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 18:30:24 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Sep 2015 16:30:24 +0000
Subject: [issue5288] tzinfo objects with sub-minute offsets are not supported
 (e.g. UTC+05:53:28)
In-Reply-To: <1234845206.93.0.372909555036.issue5288@psf.upfronthosting.co.za>
Message-ID: <1443544224.73.0.396560090505.issue5288@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

In my PEP 495 work (see issue 24773,) I relaxed the offset checks to allow any integer number of *seconds*.  This was necessary to support all timezones in the Olson database.

With respect to string representation of such offset, I would like to bring up issue 24954.  We don't even have support for printing regular offsets in ISO format.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 18:30:56 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Sep 2015 16:30:56 +0000
Subject: [issue24954] No way to generate or parse timezone as produced by
 datetime.isoformat()
In-Reply-To: <1440801281.72.0.545558404714.issue24954@psf.upfronthosting.co.za>
Message-ID: <1443544256.94.0.648241262073.issue24954@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky :


----------
assignee:  -> belopolsky
keywords: +easy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 18:31:29 2015
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 29 Sep 2015 16:31:29 +0000
Subject: [issue25271] SystemError when doing codecs.escape_encode(b'')
In-Reply-To: <1443543800.33.0.489853899894.issue25271@psf.upfronthosting.co.za>
Message-ID: <1443544289.42.0.623953012734.issue25271@psf.upfronthosting.co.za>


Changes by Zachary Ware :


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> codecs.escape_encode systemerror on empty byte string

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 18:31:48 2015
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 29 Sep 2015 16:31:48 +0000
Subject: [issue25270] codecs.escape_encode systemerror on empty byte string
In-Reply-To: <1443542758.27.0.114315188103.issue25270@psf.upfronthosting.co.za>
Message-ID: <1443544308.48.0.705028555655.issue25270@psf.upfronthosting.co.za>


Changes by Zachary Ware :


----------
nosy: +The Compiler, doerwalter, lemburg
stage:  -> needs patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 18:52:40 2015
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 29 Sep 2015 16:52:40 +0000
Subject: [issue25266] mako benchmark not working in Python 3.6
In-Reply-To: <1443525661.77.0.371661807917.issue25266@psf.upfronthosting.co.za>
Message-ID: <1443545560.55.0.35114320516.issue25266@psf.upfronthosting.co.za>


Brett Cannon added the comment:

We should also see if Mako 1.0.2 uses inspect.getargspec() and create a mako2 benchmark that does the right thing.

As for Victor's suggestion to simply change the code, we have historically avoided modifying library code that we use in a benchmark as it changes performance and thus invalidates past measurements for comparison purposes. At worst we can duplicate the code, make the change, and still create a new benchmark.

----------
assignee:  -> brett.cannon

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 18:52:45 2015
From: report at bugs.python.org (Sreenivasulu Saya)
Date: Tue, 29 Sep 2015 16:52:45 +0000
Subject: [issue25261] Incorrect Return Values for any() and all() Built-in
 Functions
In-Reply-To: <1443499554.6.0.480253610351.issue25261@psf.upfronthosting.co.za>
Message-ID: <1443545565.33.0.482007980579.issue25261@psf.upfronthosting.co.za>


Sreenivasulu Saya added the comment:

Thanks Steven and Tim for the comments. Today, I learnt something about Python.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 20:13:31 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Sep 2015 18:13:31 +0000
Subject: [issue10381] Add timezone support to datetime C API
In-Reply-To: <1289415057.12.0.111170767809.issue10381@psf.upfronthosting.co.za>
Message-ID: <1443550411.8.0.769459819373.issue10381@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Since issue 24773 (PEP 495 implementation) will touch on CAPI, maybe it is time to implement this as well.

----------
nosy: +tim.peters
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 20:34:15 2015
From: report at bugs.python.org (Florin Papa)
Date: Tue, 29 Sep 2015 18:34:15 +0000
Subject: [issue25266] mako benchmark not working in Python 3.6
In-Reply-To: <1443525661.77.0.371661807917.issue25266@psf.upfronthosting.co.za>
Message-ID: <1443551655.87.0.894243377166.issue25266@psf.upfronthosting.co.za>


Florin Papa added the comment:

There is already a mako_v2 benchmark in the Grand Unified Python Benchmarks, which does not use inspect.getargspec() and does not crash when using Python 3.6.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 20:59:11 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 29 Sep 2015 18:59:11 +0000
Subject: [issue25272] asyncio tests are getting noisy
Message-ID: <1443553151.38.0.791479091232.issue25272@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

In 3.5 and up the asyncio test are pretty chatty with warnings. E.g. a recent run gave me this in 3.5:

./python.exe -m test.test_asyncio
.........................................................................................................../Users/guido/src/cpython/Lib/asyncio/selector_events.py:574: ResourceWarning: unclosed transport <_SelectorSslTransport closing fd=27>
  warnings.warn("unclosed transport %r" % self, ResourceWarning)
Task was destroyed but it is pending!
task:  wait_for=>
.........................................................................Task was destroyed but it is pending!
task:  wait_for=>
/Users/guido/src/cpython/Lib/asyncio/selector_events.py:574: ResourceWarning: unclosed transport <_SelectorSocketTransport closing fd=26>
  warnings.warn("unclosed transport %r" % self, ResourceWarning)
...............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................returning true from eof_received() has no effect when using ssl
...returning true from eof_received() has no effect when using ssl
...................................................................................................................................................................................................................................................................ss
----------------------------------------------------------------------
Ran 939 tests in 25.032s

OK (skipped=2)

----------
components: asyncio
messages: 251875
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio tests are getting noisy
type: resource usage
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 21:14:27 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Sep 2015 19:14:27 +0000
Subject: [issue25262] Issues with BINUNICODE8 and BINBYTES8 opcodes in pickle
In-Reply-To: <1443507262.81.0.140687476176.issue25262@psf.upfronthosting.co.za>
Message-ID: <20150929191424.3668.65544@psf.io>


Roundup Robot added the comment:

New changeset d4f8316d0860 by Serhiy Storchaka in branch '3.4':
Issue #25262. Added support for BINBYTES8 opcode in Python implementation of
https://hg.python.org/cpython/rev/d4f8316d0860

New changeset da9ad20dd470 by Serhiy Storchaka in branch '3.5':
Issue #25262. Added support for BINBYTES8 opcode in Python implementation of
https://hg.python.org/cpython/rev/da9ad20dd470

New changeset 8de1967edfdb by Serhiy Storchaka in branch 'default':
Issue #25262. Added support for BINBYTES8 opcode in Python implementation of
https://hg.python.org/cpython/rev/8de1967edfdb

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 21:15:57 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Sep 2015 19:15:57 +0000
Subject: [issue25262] Issues with BINUNICODE8 and BINBYTES8 opcodes in pickle
In-Reply-To: <1443507262.81.0.140687476176.issue25262@psf.upfronthosting.co.za>
Message-ID: <1443554157.78.0.129333577195.issue25262@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Victor and Antoine for your reviews.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 21:26:32 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 29 Sep 2015 19:26:32 +0000
Subject: [issue25166] Windows AllUsers installation places uninstaller in user
 profile
In-Reply-To: <1442575090.58.0.314641407957.issue25166@psf.upfronthosting.co.za>
Message-ID: <1443554792.23.0.141571855728.issue25166@psf.upfronthosting.co.za>


Steve Dower added the comment:

After discussing it on the WiX mailing list, this definitely requires a change to WiX.

Currently, as soon as you include any per-user packages in your bundle the entire registration is forced to per-user regardless of whether or not they are ever installed.

I'm going to propose a change where the bootstrap application can assert that the bundle should be registered for the whole machine, so that when we start installing we can correct it. Can't be sure it'll be available for 3.5.1, but some time in 3.5's lifetime we should get this fixed.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 21:33:40 2015
From: report at bugs.python.org (Vladislav Ignatenko)
Date: Tue, 29 Sep 2015 19:33:40 +0000
Subject: [issue25273] Console interpreter holds a hard link on last displayed
 object
Message-ID: <1443555220.63.0.97010949652.issue25273@psf.upfronthosting.co.za>


Changes by Vladislav Ignatenko :


----------
components: Interpreter Core
nosy: GPCracker
priority: normal
severity: normal
status: open
title: Console interpreter holds a hard link on last displayed object
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 21:34:22 2015
From: report at bugs.python.org (Vladislav Ignatenko)
Date: Tue, 29 Sep 2015 19:34:22 +0000
Subject: [issue25273] Console interpreter holds a hard link on last displayed
 object
Message-ID: <1443555261.99.0.870150181244.issue25273@psf.upfronthosting.co.za>


New submission from Vladislav Ignatenko:

Hi everyone,
I've faced with python interpreter behavior I didn't expected when I was using code.InteractiveConsole in my remote python console.
I have also detected this behavior on local python interpreter.

Python 2.7.10 (default, May 23 2015, 09:40:32) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> a = 'test string A'
>>> b = 'test string B'
>>> print sys.getrefcount(a) - 1, sys.getrefcount(b) - 1
1 1
>>> a
'test string A'
>>> print sys.getrefcount(a) - 1, sys.getrefcount(b) - 1
2 1
>>> b
'test string B'
>>> print sys.getrefcount(a) - 1, sys.getrefcount(b) - 1
1 2
>>> print a, b
test string A test string B
>>> print sys.getrefcount(a) - 1, sys.getrefcount(b) - 1
1 2
>>> (a, b)
('test string A', 'test string B')
>>> print sys.getrefcount(a) - 1, sys.getrefcount(b) - 1
2 2
>>> sys

>>> print sys.getrefcount(a) - 1, sys.getrefcount(b) - 1
1 1

When I used python interactive console to display variable value on it's own (no print usage), it holds a hard link on last object, blocking it's destruction sometimes, if there were no other links to this object. When user perform an 'eval' calculation, result is displayed, and interpreter holds a hard link to it, however user can not access it.

1. Is this behavior normal?
2. Is there any way to clean this link directly?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 21:36:33 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Sep 2015 19:36:33 +0000
Subject: [issue25111] Broken compatibility in FrameSummary equality
In-Reply-To: <1442252923.78.0.0672158797601.issue25111@psf.upfronthosting.co.za>
Message-ID: <20150929193630.9945.81384@psf.io>


Roundup Robot added the comment:

New changeset 2ecb7d4d9e0b by Serhiy Storchaka in branch '3.5':
Issue #25111: Fixed comparison of traceback.FrameSummary.
https://hg.python.org/cpython/rev/2ecb7d4d9e0b

New changeset f043182a81d7 by Serhiy Storchaka in branch 'default':
Issue #25111: Fixed comparison of traceback.FrameSummary.
https://hg.python.org/cpython/rev/f043182a81d7

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 21:37:09 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Sep 2015 19:37:09 +0000
Subject: [issue25111] Broken compatibility in FrameSummary equality
In-Reply-To: <1442252923.78.0.0672158797601.issue25111@psf.upfronthosting.co.za>
Message-ID: <1443555429.24.0.59775454424.issue25111@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 21:55:47 2015
From: report at bugs.python.org (eryksun)
Date: Tue, 29 Sep 2015 19:55:47 +0000
Subject: [issue25273] Console interpreter holds a hard link on last displayed
 object
In-Reply-To: <1443555261.99.0.870150181244.issue25273@psf.upfronthosting.co.za>
Message-ID: <1443556547.09.0.0620033415031.issue25273@psf.upfronthosting.co.za>


eryksun added the comment:

In interactive mode the extra reference is held by the "_" built-in variable. 

    >>> a
    'test string A'
    >>> del __builtin__._; sys.getrefcount(a) - 1
    1

Look at the following disassembled code, compiled in the 'single' interactive mode:

    >>> dis.dis(compile('a', '', 'single'))
      1           0 LOAD_NAME                0 (a)
                  3 PRINT_EXPR          
                  4 LOAD_CONST               0 (None)
                  7 RETURN_VALUE  

[PRINT_EXPR][1] calls [sys.displayhook][2]. The default display hook prints a non-None value and sets it as __builtin__._. You can replace this with your own display hook. The original function is always available as sys.__displayhook__.

[1]: https://hg.python.org/cpython/file/v2.7.10/Python/ceval.c#l1727
[2]: https://docs.python.org/2/library/sys.html#sys.displayhook

----------
nosy: +eryksun
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 21:58:09 2015
From: report at bugs.python.org (Steve Dower)
Date: Tue, 29 Sep 2015 19:58:09 +0000
Subject: [issue25166] Windows AllUsers installation places uninstaller in user
 profile
In-Reply-To: <1442575090.58.0.314641407957.issue25166@psf.upfronthosting.co.za>
Message-ID: <1443556689.84.0.261035596478.issue25166@psf.upfronthosting.co.za>


Steve Dower added the comment:

WiX issue is http://wixtoolset.org/issues/4914/

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 22:27:04 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 29 Sep 2015 20:27:04 +0000
Subject: [issue25258] HtmlParser doesn't handle void element tags correctly
In-Reply-To: <1443468394.25.0.617953373069.issue25258@psf.upfronthosting.co.za>
Message-ID: <1443558424.19.0.0653133053759.issue25258@psf.upfronthosting.co.za>


Martin Panter added the comment:

Also applies to Python 3, though I?m not sure I would consider it a bug.

----------
nosy: +martin.panter
versions: +Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 22:47:03 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 29 Sep 2015 20:47:03 +0000
Subject: [issue23972] Asyncio reuseport
In-Reply-To: <1429185135.77.0.485030290106.issue23972@psf.upfronthosting.co.za>
Message-ID: <1443559623.72.0.507139407373.issue23972@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I added a whole bunch of review comments. Please send a new patch!

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 22:54:28 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Sep 2015 20:54:28 +0000
Subject: [issue22958] Constructors of weakref mapping classes don't accept
 "self" and "dict" keyword arguments
In-Reply-To: <1417104803.61.0.896440563309.issue22958@psf.upfronthosting.co.za>
Message-ID: <20150929205423.94123.92173@psf.io>


Roundup Robot added the comment:

New changeset 8274fc521e69 by Serhiy Storchaka in branch '2.7':
Issue #22958: Constructor and update method of weakref.WeakValueDictionary
https://hg.python.org/cpython/rev/8274fc521e69

New changeset 01c79072d671 by Serhiy Storchaka in branch '3.4':
Issue #22958: Constructor and update method of weakref.WeakValueDictionary
https://hg.python.org/cpython/rev/01c79072d671

New changeset 73b6b88ac28a by Serhiy Storchaka in branch '3.5':
Issue #22958: Constructor and update method of weakref.WeakValueDictionary
https://hg.python.org/cpython/rev/73b6b88ac28a

New changeset 815bb6a2d69e by Serhiy Storchaka in branch 'default':
Issue #22958: Constructor and update method of weakref.WeakValueDictionary
https://hg.python.org/cpython/rev/815bb6a2d69e

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 22:54:28 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Sep 2015 20:54:28 +0000
Subject: [issue22609] Constructors of some mapping classes don't accept `self`
 keyword argument
In-Reply-To: <1413029049.09.0.127316928921.issue22609@psf.upfronthosting.co.za>
Message-ID: <20150929205423.94123.65675@psf.io>


Roundup Robot added the comment:

New changeset 4c5407e1b0ec by Serhiy Storchaka in branch '2.7':
Issue #22609: Constructor and the update method of collections.UserDict now
https://hg.python.org/cpython/rev/4c5407e1b0ec

New changeset 1869f5625392 by Serhiy Storchaka in branch '3.4':
Issue #22609: Constructor of collections.UserDict now accepts the self keyword
https://hg.python.org/cpython/rev/1869f5625392

New changeset ab7e3f1f9f88 by Serhiy Storchaka in branch '3.5':
Issue #22609: Constructor of collections.UserDict now accepts the self keyword
https://hg.python.org/cpython/rev/ab7e3f1f9f88

New changeset 901964295066 by Serhiy Storchaka in branch 'default':
Issue #22609: Constructor of collections.UserDict now accepts the self keyword
https://hg.python.org/cpython/rev/901964295066

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 22:57:30 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Sep 2015 20:57:30 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <20150929205723.115438.12108@psf.io>


Roundup Robot added the comment:

New changeset 817e25bd34d0 by Victor Stinner in branch 'default':
Issue #25220: Split the huge main() function of libregrtest.main into a class
https://hg.python.org/cpython/rev/817e25bd34d0

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 22:59:53 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Sep 2015 20:59:53 +0000
Subject: [issue22609] Constructors of some mapping classes don't accept `self`
 keyword argument
In-Reply-To: <1413029049.09.0.127316928921.issue22609@psf.upfronthosting.co.za>
Message-ID: <1443560393.94.0.838927516392.issue22609@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you all for your reviews.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 23:00:08 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Sep 2015 21:00:08 +0000
Subject: [issue22958] Constructors of weakref mapping classes don't accept
 "self" and "dict" keyword arguments
In-Reply-To: <1417104803.61.0.896440563309.issue22958@psf.upfronthosting.co.za>
Message-ID: <1443560408.03.0.701360221926.issue22958@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka :


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 23:07:05 2015
From: report at bugs.python.org (Akira Li)
Date: Tue, 29 Sep 2015 21:07:05 +0000
Subject: [issue22798] time.mktime doesn't update time.tzname
In-Reply-To: <560A65EA.2020106@egenix.com> (Marc-Andre Lemburg's message of
 "Tue, 29 Sep 2015 10:20:40 +0000")
Message-ID: <87eghhj5o8.fsf@gmail.com>


Akira Li added the comment:

Marc-Andre Lemburg  writes:
...
> tzname is set when the module is being loaded and not updated
> afterwards (unless you call tzset()). I can't really see why you
> would expect a module global in Python to follow the semantics
> of a C global, unless this is explicitly documented.

Python docs recommend reading platform docs.
Platform docs say that mktime() may change tzname.
Python docs do not contradict.

Why wouldn't I assume that mktime() may change tzname?

> Note: The fact that tzset() does update the module globals is
> not documented.

It is documented e.g., I see: "These will be propagated into
time.tzname" in tzset() docs.

Though tzset() has nothing to do with the issue (TZ envvar hasn't been
changed).

>> Unrelated: time.strftime('%Z') and
>> time.strftime('%Z', time.localtime(time.time())) can differ on some 
>> platforms and python versions
>>   http://stackoverflow.com/questions/32353015/python-time-strftime-z-is-always-zero-instead-of-timezone-offset
>
> The StackOverflow discussion targets %z (lower case z),
> not %Z (with capital Z).

Look at the answers. The examples clearly shows both %Z and %z.

> I think this is just a documentation bug.
>
> Overall, I think that relying on those module globals is
> not a good idea. They are not threadsafe and their values
> can only be trusted right after module import. It's much
> safer to access the resp. values by using struct_time values
> or strftime().
>

Agree. Moreover, you can't trust them even "right after module import"
sometimes.

Though, some predictability in the behavior such as "time.tzname is
whatever C tzname is -- consult the platform docs" would be nice.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 23:25:05 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Sep 2015 21:25:05 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <20150929212502.82650.62902@psf.io>


Roundup Robot added the comment:

New changeset 12c666eea556 by Victor Stinner in branch 'default':
Issue #25220: Create libregrtest/runtest_mp.py
https://hg.python.org/cpython/rev/12c666eea556

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 23:35:43 2015
From: report at bugs.python.org (Chenyun Yang)
Date: Tue, 29 Sep 2015 21:35:43 +0000
Subject: [issue25258] HtmlParser doesn't handle void element tags correctly
In-Reply-To: <1443558424.19.0.0653133053759.issue25258@psf.upfronthosting.co.za>
Message-ID: 


Chenyun Yang added the comment:

I think the bug is mostly about inconsistent behavior:  and 
shouldn't be parsed differently.

This causes problem in the case that the parser won't be able to know
consistently whether it has ended the visit of  tag.

I propose one fix which will be: in the `parse_internal' method call, check
for void elements and call `handle_startendtag'

On Tue, Sep 29, 2015 at 1:27 PM, Martin Panter 
wrote:

>
> Martin Panter added the comment:
>
> Also applies to Python 3, though I?m not sure I would consider it a bug.
>
> ----------
> nosy: +martin.panter
> versions: +Python 3.4, Python 3.5, Python 3.6
>
> _______________________________________
> Python tracker 
> 
> _______________________________________
>

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 23:37:20 2015
From: report at bugs.python.org (Thijs van Dien)
Date: Tue, 29 Sep 2015 21:37:20 +0000
Subject: [issue25125] "Edit with IDLE" does not work for shortcuts
In-Reply-To: <1442318370.13.0.116980940121.issue25125@psf.upfronthosting.co.za>
Message-ID: <1443562640.29.0.906961884862.issue25125@psf.upfronthosting.co.za>


Thijs van Dien added the comment:

If this turns out to be a Windows problem, I'd insist not to close it as such but to find away around that. After all, in Python 3.4 there was no subcommand, and all was fine. Do we really need that second level menu? I found it to be less user-friendly as well. How many users want to make a conscious choice between editing in the 32-bit version of IDLE or in the 64-bit version, when both are installed? Does it make any difference at all? Would it matter to add both at top level context menu options, without grouping, considering that probably most users will have only one install anyway?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 23:37:54 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Sep 2015 21:37:54 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <20150929213748.94117.46946@psf.io>


Roundup Robot added the comment:

New changeset 281ab7954d7c by Victor Stinner in branch 'default':
Issue #25220: Enhance regrtest --coverage
https://hg.python.org/cpython/rev/281ab7954d7c

New changeset 45c43b9d50c5 by Victor Stinner in branch 'default':
Issue #25220: regrtest setups Python after parsing command line options
https://hg.python.org/cpython/rev/45c43b9d50c5

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 23:38:58 2015
From: report at bugs.python.org (Bruno Oliveira)
Date: Tue, 29 Sep 2015 21:38:58 +0000
Subject: [issue25270] codecs.escape_encode systemerror on empty byte string
In-Reply-To: <1443542758.27.0.114315188103.issue25270@psf.upfronthosting.co.za>
Message-ID: <1443562738.99.0.856174814015.issue25270@psf.upfronthosting.co.za>


Changes by Bruno Oliveira :


----------
nosy: +Bruno Oliveira

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Tue Sep 29 23:56:33 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Sep 2015 21:56:33 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <20150929215629.31177.35335@psf.io>


Roundup Robot added the comment:

New changeset e6b48bfd6d8e by Victor Stinner in branch 'default':
Issue #25220: truncate some long lines in libregrtest/*.py
https://hg.python.org/cpython/rev/e6b48bfd6d8e

New changeset 2c53c8dcde3f by Victor Stinner in branch 'default':
Issue #25220, libregrtest: Remove unused import
https://hg.python.org/cpython/rev/2c53c8dcde3f

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 00:14:47 2015
From: report at bugs.python.org (Daniel Shahaf)
Date: Tue, 29 Sep 2015 22:14:47 +0000
Subject: [issue17050] argparse.REMAINDER doesn't work as first argument
In-Reply-To: <1359276661.57.0.274871702559.issue17050@psf.upfronthosting.co.za>
Message-ID: <1443564887.61.0.210278648341.issue17050@psf.upfronthosting.co.za>


Changes by Daniel Shahaf :


----------
nosy: +danielsh

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 00:41:24 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 29 Sep 2015 22:41:24 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <20150929224121.82658.92634@psf.io>


Roundup Robot added the comment:

New changeset 8bd9422ef41e by Victor Stinner in branch 'default':
Issue #25220: Enhance regrtest -jN
https://hg.python.org/cpython/rev/8bd9422ef41e

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 00:48:45 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 29 Sep 2015 22:48:45 +0000
Subject: [issue16023] IDLE freezes on ^5 or ^6 (Un-)Tabify Region with OS X
 Cocoa Tk 8.5
In-Reply-To: <1348500115.21.0.649772246938.issue16023@psf.upfronthosting.co.za>
Message-ID: <1443566925.91.0.682596559579.issue16023@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Is this still current?  Mark, any ideas on a fix for this one?

----------
nosy: +markroseman, terry.reedy

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 01:45:48 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 23:45:48 +0000
Subject: [issue25274] "./python -m test -R 3:3: test_sys": Fatal Python error:
 Cannot recover from stack overflow
Message-ID: <1443570348.5.0.971307491137.issue25274@psf.upfronthosting.co.za>


New submission from STINNER Victor:

haypo at selma$ ./python -m test -R 3:3: test_sys 
[1/1] test_sys
Fatal Python error: Cannot recover from stack overflow.

Current thread 0x00007f1921854700 (most recent call first):
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/unittest/case.py", line 176 in handle
  File "/home/haypo/prog/python/default/Lib/unittest/case.py", line 727 in assertRaises
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 215 in test_recursionlimit_recovery
  File "/home/haypo/prog/python/default/Lib/unittest/case.py", line 600 in run
  File "/home/haypo/prog/python/default/Lib/unittest/case.py", line 648 in __call__
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 122 in run
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 84 in __call__
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 122 in run
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 84 in __call__
  File "/home/haypo/prog/python/default/Lib/test/support/__init__.py", line 1674 in run
  File "/home/haypo/prog/python/default/Lib/test/support/__init__.py", line 1775 in _run_suite
  File "/home/haypo/prog/python/default/Lib/test/support/__init__.py", line 1809 in run_unittest
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 1098 in test_main
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/runtest.py", line 165 in runtest_inner
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/runtest.py", line 129 in runtest
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/runtest.py", line 60 in runtest_ns
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 271 in run_test
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 293 in run_tests_sequential
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 336 in run_tests
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 367 in main
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 405 in main
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 427 in main_in_temp_cwd
  File "/home/haypo/prog/python/default/Lib/test/__main__.py", line 3 in 
  File "/home/haypo/prog/python/default/Lib/runpy.py", line 85 in _run_code
  File "/home/haypo/prog/python/default/Lib/runpy.py", line 170 in _run_module_as_main
Fatal Python error: Aborted

Current thread 0x00007f1921854700 (most recent call first):
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 209 in f
  File "/home/haypo/prog/python/default/Lib/unittest/case.py", line 176 in handle
  File "/home/haypo/prog/python/default/Lib/unittest/case.py", line 727 in assertRaises
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 215 in test_recursionlimit_recovery
  File "/home/haypo/prog/python/default/Lib/unittest/case.py", line 600 in run
  File "/home/haypo/prog/python/default/Lib/unittest/case.py", line 648 in __call__
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 122 in run
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 84 in __call__
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 122 in run
  File "/home/haypo/prog/python/default/Lib/unittest/suite.py", line 84 in __call__
  File "/home/haypo/prog/python/default/Lib/test/support/__init__.py", line 1674 in run
  File "/home/haypo/prog/python/default/Lib/test/support/__init__.py", line 1775 in _run_suite
  File "/home/haypo/prog/python/default/Lib/test/support/__init__.py", line 1809 in run_unittest
  File "/home/haypo/prog/python/default/Lib/test/test_sys.py", line 1098 in test_main
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/runtest.py", line 165 in runtest_inner
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/runtest.py", line 129 in runtest
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/runtest.py", line 60 in runtest_ns
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 271 in run_test
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 293 in run_tests_sequential
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 336 in run_tests
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 367 in main
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 405 in main
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/main.py", line 427 in main_in_temp_cwd
  File "/home/haypo/prog/python/default/Lib/test/__main__.py", line 3 in 
  File "/home/haypo/prog/python/default/Lib/runpy.py", line 85 in _run_code
  File "/home/haypo/prog/python/default/Lib/runpy.py", line 170 in _run_module_as_main
Abandon (core dumped)

----------
messages: 251897
nosy: haypo
priority: normal
severity: normal
status: open
title: "./python -m test -R 3:3: test_sys": Fatal Python error: Cannot recover from stack overflow
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 01:53:50 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 29 Sep 2015 23:53:50 +0000
Subject: [issue25270] codecs.escape_encode systemerror on empty byte string
In-Reply-To: <1443542758.27.0.114315188103.issue25270@psf.upfronthosting.co.za>
Message-ID: <1443570830.06.0.873090102702.issue25270@psf.upfronthosting.co.za>


Changes by Berker Peksag :


----------
components: +Extension Modules -Interpreter Core
keywords: +patch
nosy: +berker.peksag
stage: needs patch -> patch review
versions: +Python 3.6 -Python 3.2, Python 3.3
Added file: http://bugs.python.org/file40623/issue25270.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 01:57:30 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Sep 2015 23:57:30 +0000
Subject: [issue25274] "./python -m test test_sys": Fatal Python error: Cannot
 recover from stack overflow
In-Reply-To: <1443570348.5.0.971307491137.issue25274@psf.upfronthosting.co.za>
Message-ID: <1443571050.82.0.321642503798.issue25274@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, it's even worse: "./python -m test test_sys" is enough to reproduce the crash. It looks like the crashs was introduced by the following change which (indirectly) adds one more Python frame in the code to execute test_sys.

changeset:   98417:281ab7954d7c
user:        Victor Stinner 
date:        Tue Sep 29 23:36:27 2015 +0200
files:       Lib/test/libregrtest/main.py
description:
Issue #25220: Enhance regrtest --coverage

Add a new Regrtest.run_test() method to ensure that --coverage pass the same
options to the runtest() function.

----------
title: "./python -m test -R 3:3: test_sys": Fatal Python error: Cannot recover from stack overflow -> "./python -m test test_sys": Fatal Python error: Cannot recover from stack overflow

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 02:05:13 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 30 Sep 2015 00:05:13 +0000
Subject: [issue25274] "./python -m test test_sys": Fatal Python error: Cannot
 recover from stack overflow
In-Reply-To: <1443570348.5.0.971307491137.issue25274@psf.upfronthosting.co.za>
Message-ID: <20150930000509.11696.76211@psf.io>


Roundup Robot added the comment:

New changeset 00c1cd1f0131 by Victor Stinner in branch 'default':
Issue #25274: Workaround test_sys crash just to keep buildbots usable
https://hg.python.org/cpython/rev/00c1cd1f0131

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 02:05:13 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 30 Sep 2015 00:05:13 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <20150930000509.11696.45947@psf.io>


Roundup Robot added the comment:

New changeset 7e07c51d8fc6 by Victor Stinner in branch 'default':
Issue #25220: Use print(flush=True) in libregrtest
https://hg.python.org/cpython/rev/7e07c51d8fc6

New changeset e2ed6e9163d5 by Victor Stinner in branch 'default':
Issue #25220, libregrtest: Cleanup setup code
https://hg.python.org/cpython/rev/e2ed6e9163d5

New changeset b7d27c3c9e65 by Victor Stinner in branch 'default':
Issue #25220, libregrtest: Move setup_python() to a new submodule
https://hg.python.org/cpython/rev/b7d27c3c9e65

New changeset ff012c1b8068 by Victor Stinner in branch 'default':
Issue #25220, libregrtest: Add runtest_ns() function
https://hg.python.org/cpython/rev/ff012c1b8068

New changeset b48ae54ed5be by Victor Stinner in branch 'default':
Issue #25220, libregrtest: Call setup_python(ns) in the slaves
https://hg.python.org/cpython/rev/b48ae54ed5be

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 02:11:32 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 30 Sep 2015 00:11:32 +0000
Subject: [issue16023] IDLE freezes on ^5 or ^6 (Un-)Tabify Region with OS X
 Cocoa Tk 8.5
In-Reply-To: <1348500115.21.0.649772246938.issue16023@psf.upfronthosting.co.za>
Message-ID: <1443571892.45.0.73539316796.issue16023@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Just tried and it seemed to work ok for me. I'm guessing it'll be a particular Tk version. Noting the timeline on the original bug report and subsequent comments, that was right when Tk 8.5 switched from Carbon to Cocoa, so it was probably something that got shaken out in later versions.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 02:32:08 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 30 Sep 2015 00:32:08 +0000
Subject: [issue15663] Investigate providing Tcl/Tk 8.5 with OS X installers
In-Reply-To: <1345022434.53.0.691858342769.issue15663@psf.upfronthosting.co.za>
Message-ID: <1443573128.05.0.778471520944.issue15663@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Ned, is there anything that I might be able to help with here? While I'm not a Mac installer guru, it doesn't look like we'd need anything too fancy here.

Installing an 8.6 variant (via the frameworks approach I mentioned in my previous message) would seem to have a less likely chance of stomping on things than previously, and hopefully shorten the time we have to live with 8.4 and buggy 8.5 releases.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 02:40:36 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 30 Sep 2015 00:40:36 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <20150930004029.3670.65324@psf.io>


Roundup Robot added the comment:

New changeset 6ec81abb8e6a by Victor Stinner in branch 'default':
Issue #25220, libregrtest: Set support.use_resources in setup_tests()
https://hg.python.org/cpython/rev/6ec81abb8e6a

New changeset e765b6c16e1c by Victor Stinner in branch 'default':
Issue #25220, libregrtest: Pass directly ns to runtest()
https://hg.python.org/cpython/rev/e765b6c16e1c

New changeset 8e985fb19724 by Victor Stinner in branch 'default':
Issue #25220, libregrtest: Cleanup
https://hg.python.org/cpython/rev/8e985fb19724

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 02:43:44 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Sep 2015 00:43:44 +0000
Subject: [issue25001] Make --nowindows argument to regrtest propagate when
 running with -j
In-Reply-To: <1441399617.05.0.891415993838.issue25001@psf.upfronthosting.co.za>
Message-ID: <1443573824.77.0.186678077756.issue25001@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This issue has been fixed by the following change:

changeset:   98427:b48ae54ed5be
user:        Victor Stinner 
date:        Wed Sep 30 01:39:28 2015 +0200
files:       Lib/test/libregrtest/cmdline.py Lib/test/libregrtest/main.py Lib/te
description:
Issue #25220, libregrtest: Call setup_python(ns) in the slaves

Slaves (child processes running tests for regrtest -jN) now inherit
--memlimit/-M, --threshold/-t and --nowindows/-n options.

* -M, -t and -n are now supported with -jN
* Factorize code to run tests.
* run_test_in_subprocess() now pass the whole "ns" namespace to the child
  process.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 02:48:25 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Sep 2015 00:48:25 +0000
Subject: [issue25001] Make --nowindows argument to regrtest propagate when
 running with -j
In-Reply-To: <1441399617.05.0.891415993838.issue25001@psf.upfronthosting.co.za>
Message-ID: <1443574105.67.0.343832873387.issue25001@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Steve wrote:
"I'd be happy to always disable assert dialogs/output in regrtest, and then use "-n" to enable stderr output. That way people simply testing their own debug builds don't think it's failed, and the buildbots keep all the output they currently have."

I would prefer to have a new option for that, to keep backward compatibility on regrtest parameters.

We may also always hide popups and deprecated --nowindows, but that's differrent.

What do you think?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 03:05:18 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 30 Sep 2015 01:05:18 +0000
Subject: [issue25001] Make --nowindows argument to regrtest propagate when
 running with -j
In-Reply-To: <1441399617.05.0.891415993838.issue25001@psf.upfronthosting.co.za>
Message-ID: <1443575118.36.0.06791416041.issue25001@psf.upfronthosting.co.za>


Steve Dower added the comment:

So basically what I said (-n becomes redundant) and a new option for logging asserts to stderr? I don't really mind, but it seems like more of a compatibility break.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 03:06:00 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 30 Sep 2015 01:06:00 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <20150930010556.11702.53865@psf.io>


Roundup Robot added the comment:

New changeset ed0734966dad by Victor Stinner in branch 'default':
Issue #25220, libregrtest: more verbose output for -jN
https://hg.python.org/cpython/rev/ed0734966dad

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 03:08:37 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Sep 2015 01:08:37 +0000
Subject: [issue25001] Make --nowindows argument to regrtest propagate when
 running with -j
In-Reply-To: <1443575118.36.0.06791416041.issue25001@psf.upfronthosting.co.za>
Message-ID: 


STINNER Victor added the comment:

Steve Dower added the comment:
> So basically what I said (-n becomes redundant)

ok

> and a new option for logging asserts to stderr?

Yes. Modify PCbuild/rt.bat and/or Tools/buildbot/test.bat to enable
the option on Windows buildbots.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 03:08:50 2015
From: report at bugs.python.org (Ned Deily)
Date: Wed, 30 Sep 2015 01:08:50 +0000
Subject: [issue15663] Investigate providing Tcl/Tk 8.6 with OS X installers
In-Reply-To: <1345022434.53.0.691858342769.issue15663@psf.upfronthosting.co.za>
Message-ID: <1443575330.34.0.316796842516.issue15663@psf.upfronthosting.co.za>


Ned Deily added the comment:

Due to our maintenance release compatibility guidelines, I don't think it is possible to change the Tcl/Tk versions for currently released Python versions (e.g 3.5.x, 3.4.x, and 2.7.x), or, at least, it is not possible to remove support for 8.5 in them.  To do so would break important existing third-party packages which supply binary distributions (as wheels or as binary installers).  So the target for shipping python.org OS X Pythons built with (and including) an 8.6 Tcl/Tk would be in the next feature release, 3.6.  There *might* be ways to include 8.6 as an option with future maintenance releases but it would have to be without breaking current 8.5 (or 8.4) binary support.  In any case, for 3.6 there will likely be major changes in how we ship pre-built Pythons for OS X.

----------
title: Investigate providing Tcl/Tk 8.5 with OS X installers -> Investigate providing Tcl/Tk 8.6 with OS X installers
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 03:10:24 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Sep 2015 01:10:24 +0000
Subject: [issue25001] Make --nowindows argument to regrtest propagate when
 running with -j
In-Reply-To: 
Message-ID: 


STINNER Victor added the comment:

> Yes. Modify PCbuild/rt.bat and/or Tools/buildbot/test.bat to enable
> the option on Windows buildbots.

Wait, I'm not sure that I understood. You want to hide warnings by
default, and add an options to show them? If it's the case, no,
PCbuild/rt.bat and Tools/buildbot/test.bat must not be modified.
Sorry.

For popups: would it be useful for a specific use case to get them?
(Should we add an option to *enable* popups, since they will be
disabled by default.)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 04:48:38 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 30 Sep 2015 02:48:38 +0000
Subject: [issue25001] Make --nowindows argument to regrtest propagate when
 running with -j
In-Reply-To: <1441399617.05.0.891415993838.issue25001@psf.upfronthosting.co.za>
Message-ID: <1443581318.42.0.931968728847.issue25001@psf.upfronthosting.co.za>


Steve Dower added the comment:

I was only going to disable them by default for regrtest. The only way users will see them is when using the debug binaries or in their own extensions built in debug mode. We just don't want them scaring users who have just built from source and don't know about -n when they run the tests.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 05:26:29 2015
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 30 Sep 2015 03:26:29 +0000
Subject: [issue25001] Make --nowindows argument to regrtest propagate when
 running with -j
In-Reply-To: <1441399617.05.0.891415993838.issue25001@psf.upfronthosting.co.za>
Message-ID: <1443583589.78.0.910512993134.issue25001@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Just to add my 0.02USD:

I think my preferred course of action would be to enable '-n' by default and deprecate/ignore the option.  For the assert output on stderr, I think it would be fine to hide it by default, but show it if verbose > i for some value of i (0 or 1, probably).  They really don't add much except spam in the buildbot logs.

Also, for the record, changes to how the buildbots are called isn't very hard; let me know if any are needed.  I'd like to eventually get rid of Tools/buildbot and just let the buildbots call the same things the same way users do.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 05:59:27 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 30 Sep 2015 03:59:27 +0000
Subject: [issue25224] Replace Idle's README.txt with annotated file list
In-Reply-To: <1443045409.48.0.261448310489.issue25224@psf.upfronthosting.co.za>
Message-ID: <1443585567.37.0.501905268449.issue25224@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I believe the previous patch finishes making the current README.txt obsolete and ready to be replaced.  Attached for review and comment is a mostly complete annotated listing of idlelib files and Idle menu items.  I intend to apply this or a revised version by Friday. I consider this important for keeping track of the changes we make.

----------
keywords: +patch
nosy: +markroseman
stage: needs patch -> patch review
Added file: http://bugs.python.org/file40624/@readme.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 06:35:58 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 30 Sep 2015 04:35:58 +0000
Subject: [issue25270] codecs.escape_encode systemerror on empty byte string
In-Reply-To: <1443542758.27.0.114315188103.issue25270@psf.upfronthosting.co.za>
Message-ID: <1443587758.76.0.326001713127.issue25270@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

IMO, the "if (size == 0)" logic should be moved down several lines to avoid introducing a redundant "PyBytes_FromStringAndSize" call.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 07:19:46 2015
From: report at bugs.python.org (Shreevatsa R)
Date: Wed, 30 Sep 2015 05:19:46 +0000
Subject: [issue25275] Documentation v/s behaviour mismatch wrt integer
 literals containing non-ASCII characters
Message-ID: <1443590385.97.0.810723896221.issue25275@psf.upfronthosting.co.za>


New submission from Shreevatsa R:

Summary: This is about int(u'????') == 1234.

At https://docs.python.org/2/library/functions.html and also https://docs.python.org/3/library/functions.html the documentation for 

     class int(x=0)
     class int(x, base=10)

says (respectively):

> If x is not a number or if base is given, then x must be a string or Unicode object representing an integer literal in radix base.

> If x is not a number or if base is given, then x must be a string, bytes, or bytearray instance representing an integer literal in radix base.

If you follow the definition of "integer literal" into the reference (https://docs.python.org/2/reference/lexical_analysis.html#integers and https://docs.python.org/3/reference/lexical_analysis.html#integers respectively), the definitions ultimately involve

     nonzerodigit   ::=  "1"..."9"
     octdigit       ::=  "0"..."7"
     bindigit       ::=  "0" | "1"
     digit          ::=  "0"..."9"

So it looks like whether the behaviour of int() conforms to its documentation hinges on what "representing" means. Apparently it is some definition under which u'????' represents the integer literal 1234, but it would be great to either clarify the documentation of int() or change its behaviour.

----------
assignee: docs at python
components: Documentation, Interpreter Core, Unicode
messages: 251915
nosy: docs at python, ezio.melotti, haypo, shreevatsa
priority: normal
severity: normal
status: open
title: Documentation v/s behaviour mismatch wrt integer literals containing non-ASCII characters

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 07:20:42 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 30 Sep 2015 05:20:42 +0000
Subject: [issue25194] Opt-in motivations & affiliations page for core
 contributors
In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za>
Message-ID: <1443590442.1.0.555992303658.issue25194@psf.upfronthosting.co.za>


Changes by Nick Coghlan :


----------
title: Register of Financial Interests for core contributors -> Opt-in motivations & affiliations page for core contributors

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 07:25:37 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 30 Sep 2015 05:25:37 +0000
Subject: [issue25194] Opt-in motivations & affiliations page for core
 contributors
In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za>
Message-ID: <1443590737.66.0.168414080221.issue25194@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I updated the patch descriptions to indicate motives.diff is the current draft while still keeping the initial iteration available.

I'll ping python-committers again to give folks another chance to comment on the second draft, and then look to merge it into the developer guide this coming weekend (incorporating any further feedback received in the interim).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 10:05:57 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 30 Sep 2015 08:05:57 +0000
Subject: [issue25194] Opt-in motivations & affiliations page for core
 contributors
In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za>
Message-ID: <1443600357.58.0.994289770969.issue25194@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

Thanks, Nick. The second version looks much better.

A few minor nits, which you may want to address:

 * Order in the section should probably be alphabetic rather than
   random time based (makes it easier to search for entries once the
   list gets longer)

 * If someone is available for paid work, should we flag this in a
   generic way or simply mention this in the descriptive text ?

 * How should contact information be added to the sections ?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 11:23:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 30 Sep 2015 09:23:00 +0000
Subject: [issue25182] python -v crashes in nonencodable directory
In-Reply-To: <1442695726.04.0.992972651572.issue25182@psf.upfronthosting.co.za>
Message-ID: <1443604980.71.0.715174953757.issue25182@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Before importing the io module sys.stderr is stdprinter. It always encodes written string to UTF-8. Proposed patch makes it to use the backslashreplace error handler.

In future perhaps we could implement stdprinter in Python.

----------
components: +Interpreter Core
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file40625/stdprinter_backslashreplace.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 11:26:06 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Sep 2015 09:26:06 +0000
Subject: [issue25276] test_decimal sometimes crash on PPC64 AIX 3.x
Message-ID: <1443605165.97.0.433720501229.issue25276@psf.upfronthosting.co.za>


New submission from STINNER Victor:

This buildbot has low free memory. Maybe some part of _decimal doesn't handle an allocation failure?

http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/4173/steps/test/logs/stdio

...
[307/399/10] test_decimal
Fatal Python error: Segmentation fault

Current thread 0x00000001 (most recent call first):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_decimal.py", line 444 in eval_equation
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_decimal.py", line 321 in eval_line
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_decimal.py", line 299 in eval_file
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_decimal.py", line 5591 in 
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/case.py", line 600 in run
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/case.py", line 648 in __call__
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 122 in run
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 122 in run
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/runner.py", line 176 in run
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/support/__init__.py", line 1775 in _run_suite
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/support/__init__.py", line 1809 in run_unittest
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_decimal.py", line 5598 in test_main
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/runtest.py", line 160 in runtest_inner
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/runtest.py", line 113 in runtest
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/main.py", line 292 in run_tests_sequential
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/main.py", line 334 in run_tests
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/main.py", line 365 in main
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/main.py", line 407 in main
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/libregrtest/main.py", line 429 in main_in_temp_cwd
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/__main__.py", line 3 in 
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/runpy.py", line 85 in _run_code
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/runpy.py", line 170 in _run_module_as_main
make: *** [buildbottest] Segmentation fault (core dumped)

----------
messages: 251919
nosy: haypo
priority: normal
severity: normal
status: open
title: test_decimal sometimes crash on PPC64 AIX 3.x
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 11:32:48 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Sep 2015 09:32:48 +0000
Subject: [issue25277] test_eintr hangs on randomly on "AMD64 FreeBSD 9.x 3.x"
Message-ID: <1443605568.0.0.865946740877.issue25277@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Too bad, the test test_eintr hangs sometimes on "AMD64 FreeBSD 9.x 3.x".

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.x/builds/3442/steps/test/logs/stdio

[397/399] test_traceback -- running: test_eintr (254 sec), test_subprocess (62 sec)
[398/399] test_subprocess (71 sec) -- running: test_eintr (264 sec)
running: test_eintr (324 sec)
running: test_eintr (384 sec)
running: test_eintr (444 sec)
running: test_eintr (504 sec)
...

running: test_eintr (3505 sec)
running: test_eintr (3565 sec)
[399/399] test_eintr
Timeout (1:00:00)!
Thread 0x0000000801807400 (most recent call first):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/selectors.py", line 375 in select
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/subprocess.py", line 1698 in _communicate
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/subprocess.py", line 1068 in communicate
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/script_helper.py", line 86 in run_python_until_end
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/script_helper.py", line 96 in _assert_python
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/script_helper.py", line 135 in assert_python_ok
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_eintr.py", line 19 in test_all
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/case.py", line 600 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/case.py", line 648 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/unittest/runner.py", line 176 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/__init__.py", line 1775 in _run_suite
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/support/__init__.py", line 1809 in run_unittest
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/runtest.py", line 159 in test_runner
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/runtest.py", line 160 in runtest_inner
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/runtest.py", line 113 in runtest
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/runtest_mp.py", line 68 in run_tests_slave
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 357 in main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 407 in main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 429 in main_in_temp_cwd
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/regrtest.py", line 39 in 
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 85 in _run_code
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 170 in _run_module_as_main
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/__main__.py", line 3, in 
    regrtest.main_in_temp_cwd()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 429, in main_in_temp_cwd
    main()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 407, in main
    Regrtest().main(tests=tests, **kwargs)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 365, in main
    self.run_tests()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/main.py", line 332, in run_tests
    run_tests_multiprocess(self)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/libregrtest/runtest_mp.py", line 210, in run_tests_multiprocess
    raise Exception(msg)
Exception: Child error on test_eintr: Exit code 1
*** [buildbottest] Error code 1

----------
messages: 251920
nosy: haypo
priority: normal
severity: normal
status: open
title: test_eintr hangs on randomly on "AMD64 FreeBSD 9.x 3.x"
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 12:07:31 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Sep 2015 10:07:31 +0000
Subject: [issue25182] python -v crashes in nonencodable directory
In-Reply-To: <1442695726.04.0.992972651572.issue25182@psf.upfronthosting.co.za>
Message-ID: <1443607651.6.0.166078361525.issue25182@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Before importing the io module sys.stderr is stdprinter. It always encodes written string to UTF-8. Proposed patch makes it to use the backslashreplace error handler.

I like this solution. stdprinter is supposed to be replaced quickly.

But we may need something else to escape non-encodable characters in the filename when sys.stdout is a TextIOWrapper using the strict error handler.

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 12:35:24 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 30 Sep 2015 10:35:24 +0000
Subject: [issue25270] codecs.escape_encode systemerror on empty byte string
In-Reply-To: <1443542758.27.0.114315188103.issue25270@psf.upfronthosting.co.za>
Message-ID: <1443609324.89.0.754319653808.issue25270@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

The patch looks fine to me, but I still wonder how p - PyBytes_AS_STRING(v) can be negative when size == 0...

Ah, now I get it: the new size is 0, but the refcount is not 1, since the nullstring is shared. This causes the exception.

>From _PyBytes_Resize():

    if (!PyBytes_Check(v) || Py_REFCNT(v) != 1 || newsize < 0) {
        *pv = 0;
        Py_DECREF(v);
        PyErr_BadInternalCall();
        return -1;
    }

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 14:30:08 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 30 Sep 2015 12:30:08 +0000
Subject: [issue25220] Enhance and refactor test.regrtest (convert regrtest.py
 to a package)
In-Reply-To: <1443003154.43.0.463395539822.issue25220@psf.upfronthosting.co.za>
Message-ID: <20150930123004.98378.35599@psf.io>


Roundup Robot added the comment:

New changeset ec02ccffd1dc by Victor Stinner in branch 'default':
Issue #25220: Fix "-m test --forever"
https://hg.python.org/cpython/rev/ec02ccffd1dc

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 14:52:41 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 30 Sep 2015 12:52:41 +0000
Subject: [issue25182] python -v crashes in nonencodable directory
In-Reply-To: <1442695726.04.0.992972651572.issue25182@psf.upfronthosting.co.za>
Message-ID: <20150930125137.94113.20615@psf.io>


Roundup Robot added the comment:

New changeset 6347b154dd67 by Serhiy Storchaka in branch '3.4':
Issue #25182: The stdprinter (used as sys.stderr before the io module is
https://hg.python.org/cpython/rev/6347b154dd67

New changeset e8b6c6c433a4 by Serhiy Storchaka in branch '3.5':
Issue #25182: The stdprinter (used as sys.stderr before the io module is
https://hg.python.org/cpython/rev/e8b6c6c433a4

New changeset 0b0945c8de36 by Serhiy Storchaka in branch 'default':
Issue #25182: The stdprinter (used as sys.stderr before the io module is
https://hg.python.org/cpython/rev/0b0945c8de36

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 14:54:21 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 30 Sep 2015 12:54:21 +0000
Subject: [issue25182] python -v crashes in nonencodable directory
In-Reply-To: <1442695726.04.0.992972651572.issue25182@psf.upfronthosting.co.za>
Message-ID: <1443617661.85.0.642857849453.issue25182@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for the review Victor.

> But we may need something else to escape non-encodable characters in the filename when sys.stdout is a TextIOWrapper using the strict error handler.

This is not related to this issue. sys.stderr uses backslashreplace.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 14:59:05 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Sep 2015 12:59:05 +0000
Subject: [issue25182] python -v crashes in nonencodable directory
In-Reply-To: <1442695726.04.0.992972651572.issue25182@psf.upfronthosting.co.za>
Message-ID: <1443617945.15.0.669560483564.issue25182@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> This is not related to this issue. sys.stderr uses backslashreplace.

Ok, fine.

---
+    _errno = errno;
     Py_END_ALLOW_THREADS
+    Py_XDECREF(bytes);

     if (n < 0) {
-        if (errno == EAGAIN)
+        if (_errno == EAGAIN)
             Py_RETURN_NONE;
         PyErr_SetFromErrno(PyExc_IOError);
---

Hum, if you expect that _errno can be modified by Py_XDECREF(bytes), you must restore the previous errno value before calling PyErr_SetFromErrno(). This strategy is used in Python/fileutils.c.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 15:04:28 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 30 Sep 2015 13:04:28 +0000
Subject: [issue25182] python -v crashes in nonencodable directory
In-Reply-To: <1442695726.04.0.992972651572.issue25182@psf.upfronthosting.co.za>
Message-ID: <20150930130423.16583.19603@psf.io>


Roundup Robot added the comment:

New changeset 2652c1798f7d by Victor Stinner in branch '3.4':
Issue #25182: Fix compilation on Windows
https://hg.python.org/cpython/rev/2652c1798f7d

New changeset 0eb26a4d5ffa by Victor Stinner in branch '3.5':
(Merge 3.4) Issue #25182: Fix compilation on Windows
https://hg.python.org/cpython/rev/0eb26a4d5ffa

New changeset d1090d733d39 by Victor Stinner in branch 'default':
(Merge 3.5) Issue #25182: Fix compilation on Windows
https://hg.python.org/cpython/rev/d1090d733d39

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 15:07:33 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Sep 2015 13:07:33 +0000
Subject: [issue25182] python -v crashes in nonencodable directory
In-Reply-To: <1442695726.04.0.992972651572.issue25182@psf.upfronthosting.co.za>
Message-ID: <1443618453.38.0.20066568974.issue25182@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hum, the code didn't compile anymore on Windows. I took the opportunity to fix the errno issue that I saw.

Note: In fact, Python/fileutils.c is a a little bit different. Functions like _Py_write() save errno to restore it later because the caller expects errno to be set.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 15:11:26 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 30 Sep 2015 13:11:26 +0000
Subject: [issue25270] codecs.escape_encode systemerror on empty byte string
In-Reply-To: <1443542758.27.0.114315188103.issue25270@psf.upfronthosting.co.za>
Message-ID: <1443618686.96.0.686852832064.issue25270@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be better to test a condition "size > 0" before calling _PyBytes_Resize(), as in many other case where _PyBytes_Resize() is used.

Or accept shared objects in _PyBytes_Resize() if new size is equal to old size. This will allow to getrid of additional tests before calling _PyBytes_Resize().

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 15:16:34 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Sep 2015 13:16:34 +0000
Subject: [issue25275] Documentation v/s behaviour mismatch wrt integer
 literals containing non-ASCII characters
In-Reply-To: <1443590385.97.0.810723896221.issue25275@psf.upfronthosting.co.za>
Message-ID: <1443618994.4.0.699857306819.issue25275@psf.upfronthosting.co.za>


R. David Murray added the comment:

Apparently that documentation is simply wrong.  The actual definition of what 'int' handles is *different* from what the parser handles.  I think that difference must constitute a bug (not just a doc bug), but I'm not sure if it is something that we want to fix (changing the parser).

I think the *operational* definition of int conversion for both is the same as for isdigit in python3 (https://docs.python.org/3/library/stdtypes.html#str.isdigit).  (The python2 docs just say '8 bit strings may be locale dependent', which means the same thing but is less precise).

>>> ????
  File "", line 1
    ????
       ^
SyntaxError: invalid character in identifier
>>> int('????')
1234
>>> '????'.isdigit()
True

The above behavior discrepancy doesn't apply to python2, since in python2 you can't use unicode in integer literals.

So, this is a bit of a mess :(.

The doc fix is simple: just replace the mention of integer literal with a link to isdigit, and fix the python2 isdigit docs to match python3's.

----------
nosy: +r.david.murray
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 15:18:15 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Sep 2015 13:18:15 +0000
Subject: [issue25275] Documentation v/s behaviour mismatch wrt integer
 literals containing non-ASCII characters
In-Reply-To: <1443590385.97.0.810723896221.issue25275@psf.upfronthosting.co.za>
Message-ID: <1443619095.86.0.786752806906.issue25275@psf.upfronthosting.co.za>


R. David Murray added the comment:

I mean, in python2 you can use unicode in python code, only in strings, as opposed to python3 where unicode is valid in identifiers (but not integer literals, obviously).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 15:18:48 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Sep 2015 13:18:48 +0000
Subject: [issue25275] Documentation v/s behaviour mismatch wrt integer
 literals containing non-ASCII characters
In-Reply-To: <1443590385.97.0.810723896221.issue25275@psf.upfronthosting.co.za>
Message-ID: <1443619128.81.0.8281287769.issue25275@psf.upfronthosting.co.za>


R. David Murray added the comment:

I mean, in python2 you can't use unicode in python code, only in strings, as opposed to python3 where unicode is valid in identifiers (but not integer literals, obviously).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 15:18:58 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Sep 2015 13:18:58 +0000
Subject: [issue25275] Documentation v/s behaviour mismatch wrt integer
 literals containing non-ASCII characters
In-Reply-To: <1443590385.97.0.810723896221.issue25275@psf.upfronthosting.co.za>
Message-ID: <1443619138.25.0.998205278634.issue25275@psf.upfronthosting.co.za>


Changes by R. David Murray :


----------
Removed message: http://bugs.python.org/msg251931

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 15:20:44 2015
From: report at bugs.python.org (Blanquier)
Date: Wed, 30 Sep 2015 13:20:44 +0000
Subject: [issue25278] Unexpected socket exception on SFTP 'STOR' command
Message-ID: <1443619244.64.0.188831758146.issue25278@psf.upfronthosting.co.za>


New submission from Blanquier:

With Filezilla Server 0.9.53, SFTP activated (force SSL on login, allow explicit FTP over TLS). From the FTP client point of view: when I use ftp_id.storbinary( 'STOR file_name'...), a socket.error exception arrive sometime. It's a socket.error exception and the errno record value is 0 (zero). The full message is b'[Errno 0] Error'. If I want to obtain the real server answer, I MUST call ftp_id.getresp().
It looks like a desynchronisation between the command and the answer.

Could you correct it please ?

Best regards.

----------
components: Library (Lib)
messages: 251933
nosy: blanquier
priority: normal
severity: normal
status: open
title: Unexpected socket exception on SFTP 'STOR' command
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 15:26:33 2015
From: report at bugs.python.org (Blanquier)
Date: Wed, 30 Sep 2015 13:26:33 +0000
Subject: [issue25279] Unexpected ftplib.error_xxx exception on SFTP 'STOR'
 command
Message-ID: <1443619593.75.0.232169259081.issue25279@psf.upfronthosting.co.za>


New submission from Blanquier:

activated (force SSL on login, allow explicit FTP over TLS). From the FTP client point of view: when I use ftp_id.storbinary( 'STOR file_name'...), a ftplib.error_xxx exception arrive someting. 

On the windows server:
(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> STOR Handle.exe
(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> 150 Opening data channel for file upload to server of "/Handle.exe"
(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> 550 can't access file.
(000336)30/09/2015 08:57:29 - nemo_pyc (135.238.179.15)> TYPE I
(000336)30/09/2015 08:57:29 - nemo_pyc (135.238.179.15)> 200 Type set to I
(000336)30/09/2015 08:57:59 - nemo_pyc (135.238.179.15)>  ?3DG?}
(000336)30/09/2015 08:58:04 - nemo_pyc (135.238.179.15)> 'Y'jQ?~.
?0??? ?3DG?~
(000336)30/09/2015 08:58:04 - nemo_pyc (135.238.179.15)> 500 Syntax error, command unrecognized.
(000336)30/09/2015 08:58:09 - nemo_pyc (135.238.179.15)> ???!x?d???A?:?\ ?3DG?
...

could you fix the bug please ?
Best regards,

----------
components: Library (Lib)
messages: 251934
nosy: blanquier
priority: normal
severity: normal
status: open
title: Unexpected ftplib.error_xxx exception on SFTP 'STOR' command
type: behavior
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 15:27:41 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Sep 2015 13:27:41 +0000
Subject: [issue25194] Opt-in motivations & affiliations page for core
 contributors
In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za>
Message-ID: <1443619661.71.0.369721770239.issue25194@psf.upfronthosting.co.za>


R. David Murray added the comment:

After the "are especially encouraged" bullet list, I think you should add a paragraph about the motivations for that special encouragement (that you've previously articulated, such as colleagues being able to learn they have a coworker they can turn to as a resource).

Other than that it looks good to me.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 15:30:29 2015
From: report at bugs.python.org (Blanquier)
Date: Wed, 30 Sep 2015 13:30:29 +0000
Subject: [issue25279] Unexpected ftplib.error_xxx exception on SFTP 'STOR'
 command
In-Reply-To: <1443619593.75.0.232169259081.issue25279@psf.upfronthosting.co.za>
Message-ID: <1443619829.03.0.447298373286.issue25279@psf.upfronthosting.co.za>


Blanquier added the comment:

With Filezilla Server 0.9.53, SFTP activated (force SSL on login, allow explicit FTP over TLS). From the FTP client point of view: when I use ftp_id.storbinary( 'STOR file_name'...), a ftplib.error_xxx exception arrive someting. 

On the windows server:
(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> STOR Handle.exe
(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> 150 Opening data channel for file upload to server of "/Handle.exe"
(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> 550 can't access file.
(000336)30/09/2015 08:57:29 - nemo_pyc (135.238.179.15)> TYPE I
(000336)30/09/2015 08:57:29 - nemo_pyc (135.238.179.15)> 200 Type set to I
(000336)30/09/2015 08:57:59 - nemo_pyc (135.238.179.15)>  ?3DG?}
(000336)30/09/2015 08:58:04 - nemo_pyc (135.238.179.15)> 'Y'jQ?~.
?0??? ?3DG?~
(000336)30/09/2015 08:58:04 - nemo_pyc (135.238.179.15)> 500 Syntax error, command unrecognized.
(000336)30/09/2015 08:58:09 - nemo_pyc (135.238.179.15)> ???!x?d???A?:?\ ?3DG?
...

Could you fix the bug please ?
Best regards,

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 15:32:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 30 Sep 2015 13:32:18 +0000
Subject: [issue25280] Message can be formatted twice in importlib
Message-ID: <1443619937.76.0.139042721481.issue25280@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In importlib a verbose message can be formatted twice, the first time before passing it to _verbose_message(), and the second time in _verbose_message(), Example:

$ python -v
...
>>> open('{0}.pyc', 'wb').close()
>>> __import__('{0}')
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 969, in _find_and_load
  File "", line 958, in _find_and_load_unlocked
  File "", line 673, in _load_unlocked
  File "", line 658, in exec_module
  File "", line 869, in get_code
  File "", line 440, in _validate_bytecode_header
  File "", line 368, in _verbose_message
IndexError: tuple index out of range

Proposed patch fixes the issue.

----------
components: Library (Lib)
files: importlib_format_verbose_message.patch
keywords: patch
messages: 251937
nosy: brett.cannon, eric.snow, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Message can be formatted twice in importlib
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file40626/importlib_format_verbose_message.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 15:33:24 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Sep 2015 13:33:24 +0000
Subject: [issue25278] Unexpected socket exception on SFTP 'STOR' command
In-Reply-To: <1443619244.64.0.188831758146.issue25278@psf.upfronthosting.co.za>
Message-ID: <1443620004.42.0.916747148224.issue25278@psf.upfronthosting.co.za>


R. David Murray added the comment:

Does this have anything to do with python itself and its standard library?  From your description this sounds like a problem with filezilla and should be reported to them.

----------
nosy: +r.david.murray
resolution:  -> third party
stage:  -> resolved
status: open -> pending

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 15:34:28 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Sep 2015 13:34:28 +0000
Subject: [issue25279] Unexpected ftplib.error_xxx exception on SFTP 'STOR'
 command
In-Reply-To: <1443619593.75.0.232169259081.issue25279@psf.upfronthosting.co.za>
Message-ID: <1443620068.03.0.807281918954.issue25279@psf.upfronthosting.co.za>


Changes by R. David Murray :


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Unexpected socket exception on SFTP 'STOR' command

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 15:35:49 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Sep 2015 13:35:49 +0000
Subject: [issue25278] Unexpected socket exception on SFTP 'STOR' command
In-Reply-To: <1443619244.64.0.188831758146.issue25278@psf.upfronthosting.co.za>
Message-ID: <1443620149.79.0.68473104953.issue25278@psf.upfronthosting.co.za>


R. David Murray added the comment:

(Note: issue 25278 with a small amount of additional info closed as a duplicate of this one).

----------
status: pending -> open

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 15:36:00 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Sep 2015 13:36:00 +0000
Subject: [issue25278] Unexpected socket exception on SFTP 'STOR' command
In-Reply-To: <1443619244.64.0.188831758146.issue25278@psf.upfronthosting.co.za>
Message-ID: <1443620160.59.0.710767064776.issue25278@psf.upfronthosting.co.za>


Changes by R. David Murray :


----------
status: open -> pending

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 15:36:15 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 30 Sep 2015 13:36:15 +0000
Subject: [issue25182] python -v crashes in nonencodable directory
In-Reply-To: <1443618453.38.0.20066568974.issue25182@psf.upfronthosting.co.za>
Message-ID: <1620246.C6vRTrOgsJ@raxxla>


Serhiy Storchaka added the comment:

> Hum, the code didn't compile anymore on Windows. I took the opportunity to
> fix the errno issue that I saw.

Thank you Victor.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 15:45:42 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 30 Sep 2015 13:45:42 +0000
Subject: [issue25278] Unexpected socket exception on SFTP 'STOR' command
In-Reply-To: <1443619244.64.0.188831758146.issue25278@psf.upfronthosting.co.za>
Message-ID: <1443620742.7.0.260850902062.issue25278@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

>From the info in issue 25279, I'd say it's an error in your code.

But to make sure it's not an error in the stdlib, can you show us your code? Without that, it's not possible to diagnose this any further.

----------
nosy: +eric.smith
status: pending -> open

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 15:45:48 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 30 Sep 2015 13:45:48 +0000
Subject: [issue25278] Unexpected socket exception on SFTP 'STOR' command
In-Reply-To: <1443619244.64.0.188831758146.issue25278@psf.upfronthosting.co.za>
Message-ID: <1443620748.67.0.558333814659.issue25278@psf.upfronthosting.co.za>


Changes by Eric V. Smith :


----------
status: open -> pending

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 16:21:47 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 30 Sep 2015 14:21:47 +0000
Subject: [issue25224] Replace Idle's README.txt with annotated file list
In-Reply-To: <1443045409.48.0.261448310489.issue25224@psf.upfronthosting.co.za>
Message-ID: <1443622907.03.0.159164814262.issue25224@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Good start... would have been very helpful for me a couple of months back!

Have attached a patch to your patch, breaking the main implementation into a few categories, and fixing a few typos.

----------
Added file: http://bugs.python.org/file40629/README2.diff

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 16:43:34 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Sep 2015 14:43:34 +0000
Subject: [issue25278] Unexpected socket exception on SFTP 'STOR' command
In-Reply-To: <1443619244.64.0.188831758146.issue25278@psf.upfronthosting.co.za>
Message-ID: <1443624214.91.0.437180786554.issue25278@psf.upfronthosting.co.za>


R. David Murray added the comment:

As Eric said, we really can't diagnose this unless you show is your python code (as code, not as a partial screenshot).

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 16:48:44 2015
From: report at bugs.python.org (Vitaly Belman)
Date: Wed, 30 Sep 2015 14:48:44 +0000
Subject: [issue25281] Incorrect enum behavior during json.dumps serialization
Message-ID: <1443624524.13.0.988046915141.issue25281@psf.upfronthosting.co.za>


New submission from Vitaly Belman:

Possibly related to: http://bugs.python.org/issue18264


The following code:

>>> import IntEnum from enum
>>> from enum import IntEnum
>>> class a(IntEnum): a=0
>>> json.loads(json.dumps({"x": a.a}))

Produces:

ValueError: No JSON object could be decoded

Which makes sense because the json dumps function produces is: {"x": a.a}

----------
messages: 251945
nosy: Vitaly Belman
priority: normal
severity: normal
status: open
title: Incorrect enum behavior during json.dumps serialization
versions: Python 2.7

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 16:49:36 2015
From: report at bugs.python.org (Vitaly Belman)
Date: Wed, 30 Sep 2015 14:49:36 +0000
Subject: [issue25281] Incorrect enum behavior during json.dumps serialization
In-Reply-To: <1443624524.13.0.988046915141.issue25281@psf.upfronthosting.co.za>
Message-ID: <1443624576.56.0.232887684742.issue25281@psf.upfronthosting.co.za>


Vitaly Belman added the comment:

Note: Using pip library enum34

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 16:51:15 2015
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 30 Sep 2015 14:51:15 +0000
Subject: [issue25194] Opt-in motivations & affiliations page for core
 contributors
In-Reply-To: <1442740668.12.0.539568285088.issue25194@psf.upfronthosting.co.za>
Message-ID: <1443624675.79.0.253577421492.issue25194@psf.upfronthosting.co.za>


Changes by Zachary Ware :


----------
nosy: +zach.ware

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 17:05:50 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Sep 2015 15:05:50 +0000
Subject: [issue25281] Incorrect enum behavior during json.dumps serialization
In-Reply-To: <1443624524.13.0.988046915141.issue25281@psf.upfronthosting.co.za>
Message-ID: <1443625550.87.0.668027279644.issue25281@psf.upfronthosting.co.za>


R. David Murray added the comment:

As indicated by the issue you referenced and the fact that you are using enum34, this is not a bug in the python or its standard library.  I believe the correct place to report this is https://bitbucket.org/stoneleaf/enum34/issues?status=new&status=open.

----------
nosy: +ethan.furman, r.david.murray
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 17:15:14 2015
From: report at bugs.python.org (Mark Roseman)
Date: Wed, 30 Sep 2015 15:15:14 +0000
Subject: [issue15663] Investigate providing Tcl/Tk 8.6 with OS X installers
In-Reply-To: <1345022434.53.0.691858342769.issue15663@psf.upfronthosting.co.za>
Message-ID: <1443626114.6.0.564246756463.issue15663@psf.upfronthosting.co.za>


Mark Roseman added the comment:

Thanks Ned. 

A couple of things. First, you probably know about this, but for future reference in case it might be useful, the install_name_tool lets you point a shared library at a different dependent shared library than the one it was originally compiled to link against (see end of http://www.tkdocs.com/tutorial/fonts.html). This can be sometimes helpful in resolving compatibility issues. 

Secondly, we may want to consider adding something post-install (in IDLE?) where it would detect at least simpler cases of greatly out-of-date Tcl/Tk and offer to download and install a new one. If it were in IDLE, this would have the advantage of not affecting everyone who installs Python, but only (a subset of) those who would benefit. Plus, not being a "you must decide now" like an installer, it could be deferred if people weren't sure. And it would offer to provide a bit more active assistance rather than only "go read a web page".

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 17:46:44 2015
From: report at bugs.python.org (Ned Deily)
Date: Wed, 30 Sep 2015 15:46:44 +0000
Subject: [issue15663] Investigate providing Tcl/Tk 8.6 with OS X installers
In-Reply-To: <1345022434.53.0.691858342769.issue15663@psf.upfronthosting.co.za>
Message-ID: <1443628004.29.0.745431263803.issue15663@psf.upfronthosting.co.za>


Ned Deily added the comment:

"the install_name_tool lets you point a shared library at a different dependent shared library than the one it was originally compiled to link against"

Yes, but I'm not sure how we can take advantage of that.  First, keep in mind that there is only one version of _tkinter.so per Python installation and that is used by all tkinter applications, not just IDLE.  Second, the install_name_tool is not part of the base OS X system; it is included with either Xcode.app or the Command Line Tools package.  So we can't assume it will be available on users' systems.  And, third, changing the Tk library path may still break other third-party Python packages that also link directly with Tk and expect it to be in {/System}/Library/Frameworks.

"Secondly, we may want to consider adding something post-install (in IDLE?) where it would detect at least simpler cases of greatly out-of-date Tcl/Tk and offer to download and install a new one." 

That could be a useful addition and one that we could probably do in the context of a maintenance release.  The main problem I see with that is what to offer to install.  Since there is no truly open-source compatible option, I think we would need to provide our own Tcl/Tk 8.5.x package to install.  It's something to consider.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 17:47:13 2015
From: report at bugs.python.org (Sworddragon)
Date: Wed, 30 Sep 2015 15:47:13 +0000
Subject: [issue25282] Support for recursive patterns
Message-ID: <1443628033.35.0.583237537087.issue25282@psf.upfronthosting.co.za>


New submission from Sworddragon:

It seems Python's own regular expressions aren't able of handling nested structures so maybe this can be enhanced like it is done with PCRE's recursive patterns.

----------
components: Library (Lib)
messages: 251951
nosy: Sworddragon
priority: normal
severity: normal
status: open
title: Support for recursive patterns
type: enhancement
versions: Python 3.4

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 18:07:28 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Sep 2015 16:07:28 +0000
Subject: [issue25282] Support for recursive patterns
In-Reply-To: <1443628033.35.0.583237537087.issue25282@psf.upfronthosting.co.za>
Message-ID: <1443629248.51.0.417921894283.issue25282@psf.upfronthosting.co.za>


R. David Murray added the comment:

According to this:

   http://www.rexegg.com/regex-recursion.html

regex supports recursive regex, so the thing to do would be to help work toward getting regex into the standard library (what we need for that, from what I understand, is code reviews).

----------
nosy: +r.david.murray

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 18:19:19 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Sep 2015 16:19:19 +0000
Subject: [issue25282] regex: Support for recursive patterns
In-Reply-To: <1443628033.35.0.583237537087.issue25282@psf.upfronthosting.co.za>
Message-ID: <1443629959.03.0.927571904684.issue25282@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
title: Support for recursive patterns -> regex: Support for recursive patterns

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 18:43:40 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Sep 2015 16:43:40 +0000
Subject: [issue11215] test_fileio error on AIX
In-Reply-To: <1297705150.47.0.994582308795.issue11215@psf.upfronthosting.co.za>
Message-ID: <1443631420.19.0.0213170377141.issue11215@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I see that the test pass on AIX, on Python 2.7 and Python 3.6 buildbots, so I close the issue.

This issue was opened 4 years ago. The test is now skipped on many platforms:

            if sys.platform != "win32":
                try:
                    f = self.FileIO("/dev/tty", "a")
                except OSError:
                    # When run in a cron job there just aren't any
                    # ttys, so skip the test.  This also handles other
                    # OS'es that don't support /dev/tty.
                    pass
                else:
                    self.assertEqual(f.readable(), False)
                    self.assertEqual(f.writable(), True)
                    if sys.platform != "darwin" and \
                       'bsd' not in sys.platform and \
                       not sys.platform.startswith('sunos'):
                        # Somehow /dev/tty appears seekable on some BSDs
                        self.assertEqual(f.seekable(), False)
                    self.assertEqual(f.isatty(), True)
                    f.close()

(I'm not 100% sure that the line was this f.seekable() check.)

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 18:43:46 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Sep 2015 16:43:46 +0000
Subject: [issue11215] test_fileio error on AIX
In-Reply-To: <1297705150.47.0.994582308795.issue11215@psf.upfronthosting.co.za>
Message-ID: <1443631426.86.0.569284578659.issue11215@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 18:53:39 2015
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 30 Sep 2015 16:53:39 +0000
Subject: [issue25283] Make tm_gmtoff and tm_zone available on all platforms
Message-ID: <1443632019.41.0.93426740001.issue25283@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

See datetime-sig thread [1] for details.

[1]: https://mail.python.org/pipermail/datetime-sig/2015-September/000955.html

----------
assignee: belopolsky
messages: 251954
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Make tm_gmtoff and tm_zone available on all platforms
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 19:21:24 2015
From: report at bugs.python.org (Jack Aidley)
Date: Wed, 30 Sep 2015 17:21:24 +0000
Subject: [issue1602378] Incorrect docs for bisect_left
Message-ID: <1443633684.61.0.868727911675.issue1602378@psf.upfronthosting.co.za>


Jack Aidley added the comment:

This is still an issue in the latest version of the documentation.

It states "The returned insertion point i partitions the array a into two halves so that all(val < x for val in a[lo:i]) for the left side and all(val >= x for val in a[i:hi]) for the right side."

But this is not true, the returned value DOES NOT meet these criteria.

----------
nosy: +JackAidley
versions: +Python 3.6 -Python 2.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 19:32:21 2015
From: report at bugs.python.org (Tim Peters)
Date: Wed, 30 Sep 2015 17:32:21 +0000
Subject: [issue1602378] Incorrect docs for bisect_left
Message-ID: <1443634341.53.0.0292320028403.issue1602378@psf.upfronthosting.co.za>


Tim Peters added the comment:

What's your objection?  Here's your original example:

>>> from bisect import *
>>> L = [1,2,3,3,3,4,5]
>>> x = 3
>>> i = bisect_left(L, x)
>>> i
2
>>> all(val < x for val in L[:i])
True
>>> all(val >= x for val in L[i:])
True

Which criteria are not met?

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 19:45:29 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 30 Sep 2015 17:45:29 +0000
Subject: [issue25182] python -v crashes in nonencodable directory
In-Reply-To: <1443617945.15.0.669560483564.issue25182@psf.upfronthosting.co.za>
Message-ID: <1779339.XrIogYSZhh@raxxla>


Serhiy Storchaka added the comment:

> > This is not related to this issue. sys.stderr uses backslashreplace.
> Ok, fine.

But is related to issue25183.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 16:15:13 2015
From: report at bugs.python.org (Blanquier)
Date: Wed, 30 Sep 2015 14:15:13 +0000
Subject: [issue25278] Unexpected socket exception on SFTP 'STOR' command
In-Reply-To: <1443620004.42.0.916747148224.issue25278@psf.upfronthosting.co.za>
Message-ID: <560BEE6A.3060704@alcatel-lucent.com>


Blanquier added the comment:

Hi,

If I use the Python FTP instead of Python SFTP, there is no problem. The 
Python library works fine as well as the Filezilla server.
The exception occures inside ssl.py file (line 791) when running 
self.sslobj.shutdown() instruction.

I understand that the problem could be due to Filezilla server as well 
as Python ftplib code and it's difficult to say who is wrong.

I have done 2 snapshots: one on the client side and the second on the 
sever side (see attached document).
On the client side, we can see that the problem occure with the 
/tnr_nemo_dico.pyc/ file.
On the server size, the last line indicates that the transfert is 
succesfull.
It's the reason why I think that the Python FTP lib could have a bug 
when SFTP is in usage. It's a random problem because previous uploads 
have been OK.
Are you agree with me or do I make a mistake ?

Best regards,

Philippe Blanquier

Le 30/09/2015 15:33, R. David Murray a ?crit :
> R. David Murray added the comment:
>
> Does this have anything to do with python itself and its standard library?  From your description this sounds like a problem with filezilla and should be reported to them.
>
> ----------
> nosy: +r.david.murray
> resolution:  -> third party
> stage:  -> resolved
> status: open -> pending
>
> _______________________________________
> Python tracker 
> 
> _______________________________________
>

----------
status: pending -> open
Added file: http://bugs.python.org/file40627/ftp_client.jpg
Added file: http://bugs.python.org/file40628/ftp_server.jpg

_______________________________________
Python tracker 

_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ftp_client.jpg
Type: image/jpeg
Size: 717115 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ftp_server.jpg
Type: image/jpeg
Size: 845410 bytes
Desc: not available
URL: 

From report at bugs.python.org  Wed Sep 30 17:10:36 2015
From: report at bugs.python.org (Blanquier)
Date: Wed, 30 Sep 2015 15:10:36 +0000
Subject: [issue25278] Unexpected socket exception on SFTP 'STOR' command
In-Reply-To: <1443624214.91.0.437180786554.issue25278@psf.upfronthosting.co.za>
Message-ID: <560BFB59.5080600@alcatel-lucent.com>


Blanquier added the comment:

Hi,

I send you the file as attached document.
I use the test_sftp_upload() as entry point.

Le 30/09/2015 16:43, R. David Murray a ?crit :
> R. David Murray added the comment:
>
> As Eric said, we really can't diagnose this unless you show is your python code (as code, not as a partial screenshot).
>
> ----------
>
> _______________________________________
> Python tracker 
> 
> _______________________________________
>

----------
Added file: http://bugs.python.org/file40630/gui_ftp.py

_______________________________________
Python tracker 

_______________________________________
-------------- next part --------------
# -*- coding: iso-8859-1 -*-
# -----------------------------------------------------------------------
__file__ = "gui_ftp.py"
__doc__= "FTP functions for ul/downloading one or several server in parallele with multiple connections."
__author__ = "Philippe Blanquier"
__version__ = "v0.1"
__date__ = "24/06/2011"
__copyright__ = "Alcatel-Lucent"
__contact__ = "philippe.blanquier at alcatel-lucent.com"
# -----------------------------------------------------------------------

# Python include
import os,sys,ftplib,glob,time,threading,socket,copy

# Private include
import gui_common,gui_scenario_manager,gui_user

### ------------ ###
### Private data ###
### ------------ ###
_ftps_certificate_file_name = "C:"+os.sep+"Nemo_Pyc"+os.sep+"sftp_certificate.crt"  #: FTPS certificate for labo servers

_ftp_error_tag = "FTP"
_ftp_block_size = 64*gui_common.kilo_unit #: Maximum chunk size to read/write on the low-level socket object created to do the actual transfer
_ftp_repeat_nb = 10 #: Maximal command repeatition number before saying 'KO'...
_ftp_repeat_waiting_delay = 30.0 #: Delay between 2 repetition when a failure is detected

_upload_cmd   = "Upload"
_download_cmd = "Download"

_file_size_tag = "File size"

_ftp_posix_separator = '/' #: Normalized FTP directory separator ( UNIX POSIX !)
_ftp_dir_size = -1 #: Dummy FTP directory size

_ftp_create_dir_mutex = gui_common.nice_mutex( this_name = "FTP_Dir_Mutex") #: Internal directory creation protection

# see: http://en.wikipedia.org/wiki/List_of_FTP_server_return_codes
#
# FTP server return codes always have three digits, and each digit has a special meaning.
#
# The first digit denotes whether the response is good, bad or incomplete:
#	1xx 	Positive Preliminary reply
#	2xx 	Positive Completion reply
#	3xx 	Positive Intermediate reply
#	4xx 	Transient Negative Completion reply
#	5xx 	Permanent Negative Completion reply
#	6xx 	Protected reply
# The second digit is a grouping digit and encodes the following information:
#	x0x 	Syntax
#	x1x 	Information
#	x2x 	Connections
#	x3x 	Authentication and accounting
#	x4x 	Unspecified as of RFC 959.
#	x5x 	File system
### The requested action is being taken. Expect a reply before proceeding with a new command.
# 100 	Series: The requested action is being initiated, expect another reply before proceeding with a new command.
# 110 	Restart marker replay . In this case, the text is exact and not left to the particular implementation;
#     	it must read: MARK yyyy = mmmm where yyyy is User-process data stream marker, and mmmm server's equivalent marker (note the spaces between markers and "=").
# 120 	Service ready in nnn minutes.
# 125 	Data connection already open; transfer starting.
# 150 	File status okay; about to open data connection.
### The requested action has been successfully completed.
# 200 	Command okay.
# 202 	Command not implemented, superfluous at this site.
# 211 	System status, or system help reply.
# 212 	Directory status.
# 213 	File status.
# 214 	Help message.On how to use the server or the meaning of a particular non-standard command. This reply is useful only to the human user.
# 215 	NAME system type. Where NAME is an official system name from the registry kept by IANA.
# 220 	Service ready for new user.
# 221 	Service closing control connection.
# 225 	Data connection open; no transfer in progress.
# 226 	Closing data connection. Requested file action successful (for example, file transfer or file abort).
# 227 	Entering Passive Mode (h1,h2,h3,h4,p1,p2).
# 228 	Entering Long Passive Mode (long address, port).
# 229 	Entering Extended Passive Mode (|||port|).
# 230 	User logged in, proceed. Logged out if appropriate.
# 231 	User logged out; service terminated.
# 232 	Logout command noted, will complete when transfer done.
# 250 	Requested file action okay, completed.
# 257 	"PATHNAME" created.
### The command has been accepted, but the requested action is being held pending receipt of further information.
# 331 	User name okay, need password.
# 332 	Need account for login.
# 350 	Requested file action pending further information
### <<>> 400...499
### The command was not accepted and the requested action did not take place.
### The error condition is temporary, however, and the action may be requested again.
# 421 	Service not available, closing control connection.
# 421 	Connection timed out
# 425 	Can't open data connection.
# 426 	Connection closed; transfer aborted.
# 430 	Invalid username or password
# 434 	Requested host unavailable.
# 450 	Requested file action not taken.
# 451 	Requested action aborted. Local error in processing.
# 452 	Requested action not taken. Insufficient storage space in system.File unavailable (e.g., file busy).
### <<>> 500...599
### The command was not accepted and the requested action did not take place.
# 500 	Syntax error, command unrecognized. This may include errors such as command line too long.
# 501 	Syntax error in parameters or arguments.
# 502 	Command not implemented.
# 503 	Bad sequence of commands.
# 504 	Command not implemented for that parameter.
# 530 	Not logged in.
# 532 	Need account for storing files.
# 550 	Requested action not taken. File unavailable (e.g., file not found, no access).
# 551 	Requested action aborted. Page type unknown.
# 552 	Requested file action aborted. Exceeded storage allocation (for current directory or dataset).
# 553 	Requested action not taken. File name not allowed.
# 631 	Integrity protected reply.
# 632 	Confidentiality and integrity protected reply.
# 633 	Confidentiality protected reply.
### Common Winsock Error Codes (full error: http://kb.globalscape.com/KnowledgebaseArticle10140.aspx)
#10054 	Connection reset by peer. The connection was forcibly closed by the remote host. (Informational)
#10060 	Cannot connect to remote server. Generally a time-out error. Try switching from PASV to PORT mode, or try increasing the time-out value.
#10061 	Cannot connect to remote server. The connection is actively refused by the server. Try switching the connection port.
#10066 	Directory not empty. The server will not delete this directory while there are files/folders in it. If you want to remove the directory, first archive or delete the files in it.
#10068 	Too many users, server is full. Try logging in at another time.

# The following are the FTP commands (see RFC 959):
#   ABOR 
#   ACCT   
#   ALLO  
#       [ R  ] 
#   APPE   
#   CDUP 
#   CWD    
#   DELE   
#   HELP [ ] 
#   LIST [ ] 
#   MODE   
#   MKD    
#   NLST [ ] 
#   NOOP 
#   PASS   
#   PASV 
#   PORT   
#   PWD  
#   QUIT 
#   REIN 
#   REST   
#   RETR   
#   RMD    
#   RNFR   
#   RNTO   
#   SITE   
#   SMNT   
#   STAT [ ] 
#   STOR   
#   STOU 
#   STRU   
#   SYST 
#   TYPE   
#   USER   

### ----------------- ###
### Private functions ###
### ----------------- ###

# ------------------------------------------
# Private Function : _ftp_close_connection()
# ------------------------------------------
def _ftp_close_connection( this_ftp_id = None):
	"""
	Close the FTP connection.
	@param this_ftp_id: FTP connection ident
	@type this_ftp_id: ftplib object
	@note:
		- use 'quit()'command first: this is the ?polite? way to close a connection
		- if 'quit()' fails, use 'close()' command
	@return: None
	@see: https://docs.python.org/release/2.6.9/library/ftplib.html
	"""
	if this_ftp_id is not None:
		# Stop current transfert (if any)
		#try:
		#	this_ftp_id.abort()
		#except:
		#	pass
		# Be polite with the remote host to quit and close the connection.
		try:
			this_ftp_id.quit()
		except:
			# Oops ! Close the connection unilaterally !
			try:
				this_ftp_id.close()
			except:
				# Ignore the error
				pass
	return

# --------------------------------------------
# Private Function : _ftp_get_max_connection()
# --------------------------------------------
def _ftp_get_max_connection( this_address = "0.0.0.0"):
	"""
	Determine the maximal connection in regard of the remote server adress IP.
		- 4 for intranet or VPN to Labo server: speed up for end user
		- 1 for other situation
	@param this_address: server IP address
	@type this_address: ascii string
	@note: the values MUST be compatible with the Filezilla server preferences running on the remote servers !
	"""
	if gui_common.valid_labo_ip_addr( this_ip_addr = this_address
	                                , this_all_server = True
	                                ) is True:
		answer = 4
	else:
		# Unknown
		answer = 1
	return answer

# ---------------------
# _ftp_repeat_command()
# ---------------------
def _ftp_repeat_command( this_err_msg = None):
		"""
		Try to detect FTP errors whose commands could be repeated (i.e: 'beyond help').
		Some errors are only taken into account at present for repetitions:
			- 421 User limit reached.
			- 421 Max connections reached.
			- 421 Too many users are connected, please try again later.
			- 421 Connection timed out
			- 425 Can't open data connection (*)
			- 426 Connection closed; transfer aborted (*)
			- 450 Requested file action not taken.
			- 451 Requested action aborted. Local error in processing.
			- 550 can't access file. (on SFTP 'STOR' command) (*)
			- SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC
			- EOF occurred in violation of protocol
		@param this_err_msg: full FTP error
		@type this_err_msg: ascii string
		@return: True = repeat allowed, False = no repeatition
		@rtype: boolean
		@note: The errors (*) 425 & 426 could occure during upload...
		"""
		if this_err_msg is None:
			return False
		beyond_help_error_list = [ "User limit reached"
		                         , "Max connections reached"
		                         , "Too many users are connected"
		                         , "Connection timed out"
		                         , _file_size_tag
		                         # <<>>
		                         # [Errno 10013] An attempt was made to access a socket in a way forbidden by its access permissions.
		                         , "Errno 10013"
		                         # [Errno 10060] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
		                         , "Errno 10060"
		                         # "426 Connection closed; transfer aborted. May occure during transfert. Try to work around using activ/passif mode... see: http://support.isotools.fr/ticket/Customer/KBArticle.aspx?articleid=217
		                         , "transfer aborted"
		                         # 425 Can't open data connection
		                         , "Can't open data connection"
		                         # 450 Requested file action not taken.
		                         , "Requested file action not taken"
		                         # 450 TLS session of data connection has not resumed or the session does not match the control connection
		                         , "TLS session of data connection has not resumed"
		                         # 451 Requested action aborted. Local error in processing.
		                         , "Local error in processing"
		                         # 550 can't access file.
		                         , "can't access file"
		                         # SSL errors
		                         , "DECRYPTION_FAILED_OR_BAD_RECORD_MAC"
		                         , "EOF occurred in violation of protocol"
		                         ]
		answer = False
		for code_idx in beyond_help_error_list:
			if code_idx in this_err_msg:
				# Found !
				answer = True
				break
			# Next code_idx
			continue
		return answer

# --------------------------
# Private Class : _ftp_mutex
# --------------------------
class _ftp_mutex(gui_common.Singleton):
	"""
	Manage only one acces to each remote host when a remote directory has to be created
	"""
	ip_mutex_dico = {}
	# ---------------------
	# _ftp_mutex.__init__()
	# ---------------------
	def __init__( self
	            , this_ip_addr
	            ):
		if _ftp_mutex.ip_mutex_dico.get(this_ip_addr, None) is None:
			_ftp_mutex.ip_mutex_dico[this_ip_addr] = gui_common.nice_mutex( this_name = "FTP_Dir_Mutex_%s"%(this_ip_addr)) #: Internal directory creation protection
		return
	# ------------------
	# _ftp_mutex.error()
	# ------------------
	def error( self
	         , this_msg
	         ):
		"""
		Shortcut access to display an error
		@param this_msg: input message describing the error
		@type this_msg: ascii string
		@return: None
		"""
		gui_common.save_error( this_msg = this_msg
		                     , this_object_class = self
		                     , this_file_name = __file__
		                     , this_mail_subject = _ftp_error_tag+" Mutex"
		                     )
	# ----------------
	# _ftp_mutex.get()
	# ----------------
	def get( self
	       , this_ip_addr
	       ):
		local_mutex = _ftp_mutex.ip_mutex_dico.get(this_ip_addr, None)
		if local_mutex is None:
			# Oops !
			self.error( this_msg = "No mutex for %s"%(this_ip_addr))
		else:
			local_mutex.get()
		return
	# --------------------
	# _ftp_mutex.release()
	# --------------------
	def release( self
	           , this_ip_addr
	           ):
		local_mutex = _ftp_mutex.ip_mutex_dico.get(this_ip_addr, None)
		if local_mutex is None:
			# Oops !
			self.error( this_msg = "No mutex for %s"%(this_ip_addr))
		else:
			local_mutex.release()
		return

# ----------------------------------
# Private Class : _ftp_slave_thread
# ---------------------------------
class _ftp_slave_thread( threading.Thread):
	"""
	Independant FPT thread to upload or download in parallele on a dedicated server.
	@note: A file size check is done to prevent a 'null file size' on the tranfered file (ftplib bug ?)
	@note: see: http://support.microsoft.com/kb/466868/fr
	@sort: _*,a*,b*,c*,d*,e*,f*,g*,h*,i*,j*,k*,l*,m*,n*,o*,p*,q*,r*,s*,t*,u*,v*,w*,x*,y*,z*
	"""
	# ----------------------------
	# _ftp_slave_thread.__init__()
	# ----------------------------
	def __init__( self
	            , this_ftp_id_id = None
	            , this_server_ip_address = None
	            , this_file_manager_id = None
	            , this_upload = True
	            , this_user_remote_dir = _ftp_posix_separator
	            , this_user_local_dir = "."
	            , this_debug_mode = False
	            , this_start_time = 0
	            , this_check_size = True
	            ):
		"""
		Elementary thread to manage one FTP connection.
		@param this_ftp_id_id: FTP connection ident
		@type this_ftp_id_id: FTP object
		@param this_server_ip_address: remote IP address (for error)
		@type this_server_ip_address: ascii string
		@param this_file_manager_id: file manager ident returned by _ftp_open_many_connection()
		@type this_file_manager_id: gui_scenario_manager object
		@param this_upload: True = connection for an upload, False = connection for an download
		@type this_upload: boolean
		@param this_user_remote_dir: user remote directory
		@type this_user_remote_dir: ascii string
		@param this_debug_mode: True = display debug information, False = run silently
		@type this_debug_mode: boolean
		@param this_start_time: start time of the FTP transfert (seconds since the epoch)
		@type this_start_time: float
		@param this_check_size: True = Check sent and downloaded file size, False = No check
		@type this_check_size: boolean
		@return: None
		"""
		threading.Thread.__init__(self)
		self.ftp_id = this_ftp_id_id #: FTP connection to be used
		self.server_ip_address = this_server_ip_address #: Server IP address
		self.file_manager_id = this_file_manager_id #: File manager
		self.debug_mode = this_debug_mode #: Flag for debug purpose
		self.result = True #: private result/error
		self.dbg_check_size = this_check_size #: for debug purpose
		self.start_time = this_start_time #: Keep in mind start time
		self.last_remote_dir = ""
		self.ftp_dir_mutex = _ftp_mutex(this_ip_addr = self.server_ip_address)
		self.user_local_dir = this_user_local_dir #: Current host directory name
		if (this_user_remote_dir is None) or (this_user_remote_dir == _ftp_posix_separator):
			self.user_remote_dir = self.ftp_id.pwd() # Use the default user directory
		else:
			# Use the POSIX separator for remote directory !
			self.user_remote_dir = this_user_remote_dir.replace(os.sep,_ftp_posix_separator) #: User directory on the server
		self.do_upload = this_upload
		return
	# ---------------------------
	# _ftp_slave_thread.__del__()
	# ---------------------------
	def __del__(self):
		"""
		For debug purpose
		@return: None
		"""
		self.close_connection()
		return
	# -------------------------
	# _ftp_slave_thread.error()
	# -------------------------
	def error( self
	         , this_msg
	         ):
		"""
		Shortcut access to display an error
		@param this_msg: input message describing the error
		@type this_msg: ascii string
		@return: None
		"""
		# Add elapsed running time (for server timer delay purpose)
		this_msg += "\nRunning time %s"%(gui_common.elapsed_time_ascii( this_start_time = self.start_time))
		if self.debug_mode is False:
			gui_common.save_error( this_msg = this_msg
			                     , this_object_class = self
			                     , this_file_name = __file__
			                     , this_mail_subject = _ftp_error_tag
			                     )
		else:
			gui_common.display_error( this_msg = this_msg
			                        , this_object_class = self
			                        , this_file_name = __file__
			                        )
		self.result = False
		return
	# ---------------------------
	# _ftp_slave_thread.warning()
	# ---------------------------
	def warning( self
	           , this_msg
	           ):
		"""
		Shortcut access to display a warning
		@param this_msg: input message describing the error
		@type this_msg: ascii string
		@return: None
		"""
		# Add elapsed running time (for server timer delay purpose)
		this_msg += "\nRunning time %s"%(gui_common.elapsed_time_ascii( this_start_time = self.start_time))
		if self.debug_mode is False:
			gui_common.save_warning( this_msg = this_msg
			                       , this_object_class = self
			                       , this_file_name = __file__
			                       , this_caller_name = gui_common.get_caller_name()
			                       )
		else:
			gui_common.display_warning( this_msg = this_msg
			                          , this_object_class = self
			                          , this_file_name = __file__
			                          , this_caller_name = gui_common.get_caller_name()
			                          )
		return
	# ------------------------------------
	# _ftp_slave_thread.close_connection()
	# ------------------------------------
	def close_connection( self ):
		"""
		Close the FTP connection.
		@return: None
		"""
		_ftp_close_connection( this_ftp_id = self.ftp_id)
		self.ftp_id = None
		return
	# -------------------------------------
	# _ftp_slave_thread.change_remote_dir()
	# -------------------------------------
	def change_remote_dir( self
	                     , this_new_dir = os.curdir
	                     ):
		"""
		Change the remote directory.
		@param this_new_dir: new remote POSIX directory
		@type this_new_dir: ascii string
		@return: True = done, False = error detected
		@rtype: boolean
		@note:
			- the directory MUST have been created previously.
			- the remote directory has the POSIX standard format
		"""
		# Force the absolute remote path
		if this_new_dir == "":
			# default remote directory
			this_new_dir = _ftp_posix_separator
		else:
			if this_new_dir[0] != _ftp_posix_separator:
				this_new_dir = _ftp_posix_separator+this_new_dir
		if self.last_remote_dir == this_new_dir:
			# Nothing to do !
			return True
		# Be carefull when multiple clients are connected on the same remote host and want to create a new directory...
		self.ftp_dir_mutex.get(this_ip_addr = self.server_ip_address)
		err_msg = None
		try:
			self.ftp_id.cwd( this_new_dir )
		except ftplib.error_temp, e:
			if "500 can't access directory" in e.args[0]:
				err_msg = e.args[0]
		except ftplib.error_reply, e:
			err_msg = e.args[0]
		except (ftplib.error_perm,ftplib.error_proto), e:
			err_msg = e.args[0]
		except socket.timeout,msg:
			err_msg = gui_common.get_socket_error_msg( this_error = msg)
		except socket.error, msg:
			err_msg = gui_common.get_socket_error_msg( this_error = msg)
		except gui_common.runing_errors,why:
			err_msg = str(why)
		except:
			err_msg = "ERROR"
		if err_msg is None:
			# Yeap !
			self.last_remote_dir = this_new_dir
		else:
			# Oops !
			if ("550 CWD failed" in err_msg) and ("directory not found" in err_msg):
				# The directory must be created
				try:
					self.ftp_id.mkd( dirname = this_new_dir)
				except (ftplib.error_temp,ftplib.error_reply,ftplib.error_perm,ftplib.error_proto), e:
					err_msg = e.args[0]
				except socket.error, msg:
					err_msg = gui_common.get_socket_error_msg( this_error = msg)
				except gui_common.runing_errors,why:
					err_msg = str(why)
				except:
					err_msg = "ERROR"
				else:
					err_msg = None
				if err_msg is not None:
					err_msg = "mkd('%s') on %s: %s"%( this_new_dir
					                                , self.server_ip_address
					                                , err_msg
					                                )
					self.error( this_msg = err_msg)
				else:
					# Same player shoots again !
					try:
						self.ftp_id.cwd( this_new_dir )
					except ftplib.error_temp, e:
						if "500 can't access file" in e.args[0]:
							err_msg = e.args[0]
					except ftplib.error_reply, e:
						err_msg = e.args[0]
					except (ftplib.error_perm,ftplib.error_proto), e:
						err_msg = e.args[0]
					except socket.timeout,msg:
						err_msg = gui_common.get_socket_error_msg( this_error = msg)
					except socket.error, msg:
						err_msg = gui_common.get_socket_error_msg( this_error = msg)
					except gui_common.runing_errors,why:
						err_msg = str(why)
					except:
						err_msg = "ERROR"
					if err_msg is None:
						# Yeap !
						self.last_remote_dir = this_new_dir
					else:
						err_msg = "cwd('%s') on %s: %s"%( this_new_dir
						                                , self.server_ip_address
						                                , err_msg
						                                )
						self.error( this_msg = err_msg)
			else:
				err_msg = "cwd('%s') on %s: %s"%( this_new_dir
				                                , self.server_ip_address
				                                , err_msg
				                                )
				self.error( this_msg = err_msg)
		# Remote host directory creation should be successful
		self.ftp_dir_mutex.release(this_ip_addr = self.server_ip_address)
		return err_msg is None
	# --------------------------
	# _ftp_slave_thread.upload()
	# --------------------------
	def upload( self
	          , this_full_src_file
	          , this_full_dest_file
	          , this_size
	          ):
		"""
		FTP upload one file.
		@param this_full_src_file: full file name on the local host
		@type this_full_src_file: ascii string
		@param this_full_dest_file: full file name on the server
		@type this_full_dest_file: ascii string
		@param this_size: file size (in bytes)
		@type this_size: integer
		@return: True = Done, False = Error detected
		@rtype: boolean
		@warning: The ftplib.storbinary() should use socket.MSG_WAITALL when data are sent over the socket.
		          Unfortunatly, this parameter does not exist on Windows.
		          So, sent file may have erroneous size on the destination host...
		@note: If an error occured during the data transfert, the waiting delay is doubled for each new try.
		"""
		if self.debug_mode is True:
			msg = "%s %s --> %s"%( gui_common.ftp_upload_marker
			                     , this_full_src_file
			                     , this_full_dest_file
			                     )
			gui_common.display_screen( this_msg = msg
			                         , this_object_class = self
			                         , this_file_name = __file__
			                         , this_caller_name = None
			                         , this_user_name = None
			                         )
		# Extract remote parameters (UNIX path format...)
		path_list = this_full_dest_file.split(_ftp_posix_separator)
		remote_dir = _ftp_posix_separator.join(path_list[:-1])
		remote_file = path_list[-1]
		# And then, go on to the remote directory (if not already done)
		if self.change_remote_dir( this_new_dir = remote_dir) is not True:
			return False
		# Sometimes,the FTPlib could miss the answer, or the answer could be lost in the network...
		attempt_number = _ftp_repeat_nb
		while attempt_number > 0:
			attempt_number -= 1
			err_msg = None
			# Open the local file
			try:
				src_file_id = open( this_full_src_file, 'rb', gui_common.open_buffer_option)
			except gui_common.runing_errors,why:
				err_msg = "%s\n%s"%( str(why)
				                   , gui_common.which_process_uses_it( this_file = this_full_src_file)
				                   )
				self.error( this_msg = err_msg)
				return False
			except:
				err_msg = "open(%s,'rb')\n%s"%( this_full_src_file
				                              , gui_common.which_process_uses_it( this_file = this_full_src_file)
				                              )
				self.error( this_msg = err_msg)
				return False
			# Upload first
			try:
				# Use binary transfert for ASCII and binary files  ;-)
				self.ftp_id.storbinary( cmd = 'STOR %s'%(remote_file)
				                      , fp = src_file_id
				                      , blocksize = _ftp_block_size
				                      )
			except socket.timeout,msg:
				err_msg = gui_common.get_socket_error_msg( this_error = msg)
			except socket.error,msg:
				if msg.errno == 0:
					# <<>>
					#  b'[Errno 0] Error' occures sometime...
					#  so the "226 Successfully transferred "/nemo_tmp/dst_dir/fzs-2015-09-22.log" is ignored !!
					#  and will be treated later whence an error is forseen (incorrect response treatement) ...
					try:
						missed_answer = self.ftp_id.getresp() # pop the answer server !
					except:
						# Nothing on the line...
						err_msg = None
					else:
						if missed_answer[0] == '2':
							err_msg = None
						else:
							# It's an error
							err_msg = missed_answer
							#print "*** %s *** %s STOR %s --> socket.error '%s'"%(self.name,self.server_ip_address,remote_file,str(msg))
				else:
					# Real error
					err_msg = gui_common.get_socket_error_msg( this_error = msg)
			except (ftplib.error_temp, ftplib.error_reply, ftplib.error_perm, ftplib.error_proto),e:
				# <<>>
				#---  on server
				# (000346)30/09/2015 11:27:18 - nemo_pyc (135.238.179.15)> TYPE I
				# (000346)30/09/2015 11:27:18 - nemo_pyc (135.238.179.15)> 200 Type set to I
				# (000346)30/09/2015 11:27:48 - nemo_pyc (135.238.179.15)> TYPE I
				# (000346)30/09/2015 11:27:48 - nemo_pyc (135.238.179.15)> 200 Type set to I
				# (000346)30/09/2015 11:27:48 - nemo_pyc (135.238.179.15)> PASV
				# (000346)30/09/2015 11:27:48 - nemo_pyc (135.238.179.15)> 227 Entering Passive Mode (135,120,162,6,202,181)
				# (000346)30/09/2015 11:27:48 - nemo_pyc (135.238.179.15)> SIZE Handle.exe
				# (000346)30/09/2015 11:27:48 - nemo_pyc (135.238.179.15)> 213 536256
				# (000346)30/09/2015 11:27:48 - nemo_pyc (135.238.179.15)> QUIT
				# (000346)30/09/2015 11:27:48 - nemo_pyc (135.238.179.15)> 221 Goodbye
				# (000346)30/09/2015 11:27:48 - nemo_pyc (135.238.179.15)> disconnected.
				#--- on client:
				# *** FTP_135.120.162.6_Upload_1 *** 135.120.162.6 STOR Handle.exe --> ftplib.error '550 can't access file.'
				# *** FTP_135.120.162.6_Upload_1 *** 135.120.162.6 STOR Handle.exe --> ftplib.error '200 Type set to I'
				# *** FTP_135.120.162.6_Upload_1 *** 135.120.162.6 STOR Handle.exe OK
				missed_answer = e.args[0] # or e.message
				for tag_idx in [ "Type set to I"
				               , "Opening data channel"
				               , "SSL connection for data connection established"
				               ]:
					if tag_idx in missed_answer:
						# Ignore the current message and take the next pending one (if any)
						try:
							missed_answer = self.ftp_id.getresp() # pop the answer server !
						except:
							# Nothing on the line...
							missed_answer = '2xx'
						break
					# Next tag_idx
					continue
				if missed_answer[0] == '2':
					err_msg = None
					#print "*** %s *** %s STOR %s --> ftplib.error '%s'"%(self.name,self.server_ip_address,remote_file,str(e))
				else:
					# It's an error
					err_msg = missed_answer
			except gui_common.runing_errors,why:
				err_msg = str(why)
			except:
				err_msg = "storbinary()"
			else:
				err_msg = None
			# Done with this file
			try:
				src_file_id.close()
			except:
				pass
			if _ftp_repeat_command( this_err_msg = err_msg) is False:
				break
			# while attempt_number
			time.sleep(_ftp_repeat_waiting_delay)
			continue
		if err_msg is not None:
			# Oops !
			full_err_msg = "%s %s: STOR '%s' --> '%s': %s"%( gui_common.ftp_upload_marker
			                                               , self.server_ip_address
			                                               , this_full_src_file
			                                               , remote_file
			                                               , err_msg
			                                               )
			self.error( this_msg = full_err_msg)
		else:
			# The FTP upload has been done
			if self.dbg_check_size is True:
				# Get the remote file size
				remote_file_size = 0
				# Because the Windows OS may take a while to update its internal buffers, we must be carrefull...
				attempt_number = _ftp_repeat_nb
				while attempt_number > 0:
					attempt_number -= 1
					try:
						remote_file_size = self.ftp_id.size(remote_file)
					except (socket.timeout,socket.error),msg:
						err_msg = gui_common.get_socket_error_msg( this_error = msg)
						if err_msg == "":
							err_msg = None
					except (ftplib.error_temp,ftplib.error_reply,ftplib.error_perm,ftplib.error_proto),e:
						err_msg = e.args[0]
						if err_msg == "":
							err_msg = None
					except gui_common.runing_errors,why:
						err_msg = str(why)
					except:
						err_msg = "ftp.size(%s)"%(remote_file)
					else:
						# We have read a remote size...
						if this_size != remote_file_size:
							# Different file sizes...
							err_msg = "%s: local '%s' = %d, remote '%s' = %d"%( _file_size_tag
							                                                  , this_full_src_file, this_size
							                                                  , remote_file, remote_file_size
							                                                  )
						else:
							# Yeap !
							err_msg = None
							break
					if _ftp_repeat_command( this_err_msg = err_msg) is False:
						break
					# while attempt_number
					time.sleep(_ftp_repeat_waiting_delay)
					continue
				# The result is...
				if err_msg is not None:
					# Oops !
					full_err_msg = "%s %s: SIZE '%s': %s"%( gui_common.ftp_upload_marker
					                                      , self.server_ip_address
					                                      , remote_file
					                                      , err_msg
					                                      )
					self.error( this_msg = full_err_msg)
		return err_msg is None
	# ----------------------------
	# _ftp_slave_thread.download()
	# ----------------------------
	def download( self
	            , this_full_src_file
	            , this_full_dest_file
	            , this_size
	            ):
		"""
		FTP download one file.
		@param this_full_src_file: full file name on the server
		@type this_full_src_file: ascii string
		@param this_full_dest_file: full file name on the local host
		@type this_full_dest_file: ascii string
		@param this_size: file size (in bytes)
		@type this_size: integer
		@return: True = Done, False = Error detected
		@rtype: boolean
		@note: If an error occured during the data transfert, the waiting delay is doubled for each new try.
		"""
		if self.debug_mode is True:
			msg = "%s %s --> %s"%( gui_common.ftp_download_marker
			                     , this_full_src_file
			                     , this_full_dest_file
			                     )
			gui_common.display_screen( this_msg = msg
			                         , this_object_class = self
			                         , this_file_name = __file__
			                         , this_caller_name = None
			                         , this_user_name = None
			                         )
		if this_size == _ftp_dir_size:
			# Local directory has been already created
			return True
		if this_size == 0:
			# Ignore empty remote file for downloading
			return True
		# Extract remote parameters (UNIX path format...)
		path_list = this_full_src_file.split(_ftp_posix_separator)
		remote_dir = _ftp_posix_separator.join(path_list[:-1])
		remote_file = path_list[-1]
		if remote_dir != "":
			# And then, go on to the remote directory (if not already done)
			if self.change_remote_dir( this_new_dir = remote_dir) is not True:
				return False
		# Get remote file
		err_msg = None
		dst_file_id = None
		dst_dir = os.path.dirname(this_full_dest_file)
		if os.path.isdir(dst_dir) is False:
			# Create the local directory
			if gui_common.build_directories( this_directory_list = [dst_dir,]) is False:
				err_msg = "Can't create '%s' directory"%(dst_dir)
				self.error( this_msg = err_msg)
				return False
		# Sometimes,the FTPlib could miss the answer, or the answer could be lost in the network...
		attempt_number = 0
		while attempt_number < _ftp_repeat_nb:
			attempt_number += 1
			err_msg = None
			# Open the destination file to store its content
			try:
				dst_file_id = open( this_full_dest_file, 'wb', gui_common.open_buffer_option)
			except gui_common.runing_errors,why:
				err_msg = "%s\n%s"%( str(why)
				                   , gui_common.which_process_uses_it( this_file = this_full_dest_file)
				                   )
				if "[Errno 2]" in err_msg:
					# Should never occur
					err_msg += gui_common.test_path( this_path = this_full_dest_file
					                               , this_directory_only = True
					                               )
			except:
				err_msg = "open(%s, 'wb')\n%s"%( this_full_dest_file
				                               , gui_common.which_process_uses_it( this_file = this_full_dest_file)
				                               )
			if err_msg is not None:
				# Oops ! Can't open a file for writting on my host...
				full_err_msg = "%s from %s: %s"%( gui_common.ftp_download_marker
				                                , self.server_ip_address
				                                , err_msg
				                                )
				self.error( this_msg = full_err_msg)
				break
			# Retreive back the remote file content
			timeout_occures = False
			try:
				# Use binary transfert for ASCII and binary files  ;-)
				self.ftp_id.retrbinary( cmd = 'RETR %s'%(remote_file)
				                      , callback = dst_file_id.write
				                      , blocksize = _ftp_block_size
				                      )
			except socket.timeout,msg:
				err_msg = gui_common.get_socket_error_msg( this_error = msg)
				timeout_occures = True
			except socket.error, msg:
				err_msg = gui_common.get_socket_error_msg( this_error = msg)
			except (ftplib.error_temp,ftplib.error_reply,ftplib.error_perm,ftplib.error_proto), e:
				# The error "550 can't access file" can occure when we try to download a file which is already opened for writing by an another process
				err_msg = e.args[0]
				if "550" in err_msg:
					err_msg += ". The file is maybe opened for writing by an another process..."
			except gui_common.runing_errors,why:
				err_msg = str(why)
			except:
				err_msg = "ftp.retrbinary()"
			else:
				err_msg = None
			# Close the file before threating the error  ;-)
			gui_common.force_file_synchro( this_file_id = dst_file_id)
			try :
				dst_file_id.close()
			except:
				pass
			# The result is...
			if timeout_occures is not True:
				if err_msg is None:
					break
			if _ftp_repeat_command( this_err_msg = err_msg) is False:
				break
			# while attempt_number
			time.sleep(_ftp_repeat_waiting_delay)
			continue
		if err_msg is not None:
			# Oops !
			full_err_msg = "%s %s: '%s' --> RETR '%s': %s"%( gui_common.ftp_download_marker
			                                               , self.server_ip_address
			                                               , this_full_src_file
			                                               , this_full_dest_file
			                                               , err_msg
			                                               )
			self.error( this_msg = full_err_msg)
		else:
			# Download done, no error !
			if self.dbg_check_size is True:
				# Get host file size
				try:
					file_host_size = os.path.getsize(this_full_dest_file)
				except gui_common.runing_errors,why:
					# Should never occure
					err_msg = str(why)
				except:
					# Idem !
					err_msg = "os.path.getsize(%s)"%(this_full_dest_file)
				else:
					if file_host_size != this_size:
						err_msg = "%s: host %s = %d, remote %s = %d"%( _file_size_tag
						                                             , this_full_dest_file, file_host_size
						                                             , this_full_src_file, this_size
						                                             )
				if err_msg is not None:
					full_err_msg = "%s %s: SIZE: %s"%( gui_common.ftp_download_marker
					                                 , self.server_ip_address
					                                 , err_msg
					                                 )
					self.error( this_msg = full_err_msg)
		return err_msg is None
	# -----------------------
	# _ftp_slave_thread.run()
	# -----------------------
	def run(self):
		"""
		Main body of the thread dedicated to a FTP elementary transfert.
		"""
		file_to_transfert_info = self.file_manager_id.get_waiting()
		while file_to_transfert_info is not None:
			# I have a file to transfert
			(full_src_file, full_dest_file, file_size) = file_to_transfert_info
			# Go, go, go !
			if self.do_upload is True:
				# Upload wanted
				tranfert_result = self.upload( this_full_src_file = full_src_file
				                             , this_full_dest_file = full_dest_file
				                             , this_size = file_size
				                             )
			else:
				# Download wanted
				tranfert_result = self.download( this_full_src_file = full_src_file
				                               , this_full_dest_file = full_dest_file
				                               , this_size = file_size
				                               )
			if tranfert_result is False:
				# Can't transfert. Mark it as 'running' again. It's craps... I know  :-(
				self.file_manager_id.add_running( this_scenario_name = file_to_transfert_info)
				# Pray for a succes by an another thread
				break
			else:
				# Forever loop until all files have been transfered
				file_to_transfert_info = self.file_manager_id.get_waiting()
				# while file_to_transfert_info
				continue
		# Close the FTP connection
		self.close_connection()
		return

# ----------------------------------------------
# Private Function : _ftp_open_many_connection()
# ----------------------------------------------
def _ftp_open_many_connection( this_address
                             , this_login
                             , this_password
                             , this_timeout = gui_common.ftp_timeout_s
                             , this_upload = True
                             , this_user_remote_dir = _ftp_posix_separator
                             , this_max_connection = 2
                             , this_debug_mode = False
                             , this_nickname = None
                             , this_check_size = True
                             , this_use_sftp = False
                             ):
	"""
	Open at most some connections on a dedicated serveur and associated a thread to manage each.
	@param this_address: remote IP address
	@type this_address: ascii string
	@param this_login: user login
	@type this_login: ascii string
	@param this_password: user password
	@type this_password: ascii string
	@param this_timeout: maximal timeout in seconds for blocking operations like the connection attempt
	@type this_timeout: int
	@param this_upload: True = connection for an upload, False = connection for an download
	@type this_upload: boolean
	@param this_user_remote_dir: remote user directory
	@type this_user_remote_dir: ascii string
	@param this_max_connection: number of connections to speed up the transfert
	@type this_max_connection: integer
	@param this_debug_mode: True = display debug information, False = run silently
	@type this_debug_mode: boolean
	@param this_nickname: connection nickname
	@type this_nickname: ascii string
	@param this_check_size: True = Check sent and downloaded file size, False = No check
	@type this_check_size: boolean
	@param this_use_sftp: True = use FTPS, False = use normal FTP
	@type this_use_sftp: boolean
	@return: (file manager ident, ftp thread ident) tuple
	@rtype: list of tuple
	@note: the number of connection may be less than the one expected on detected remote error.
	"""
	answer = []
	file_manager_id = gui_scenario_manager.scenario_manager( this_debug_mode = this_debug_mode)
	# Be sure to have an integer
	this_timeout = int(this_timeout)
	# Increase timeout if neccessary
	if gui_common.vpn_ip_addr() is True:
		# When running with VPN
		this_timeout *= 2
	start_time = time.time()
	cnx_idx = 0
	if this_upload is True:
		ud = "Upload"
	else:
		ud = "Download"
	while this_max_connection > 0:
		this_max_connection -= 1
		err_msg = None
		attempt_number = _ftp_repeat_nb
		# Be carefull: the server may be temporarily full
		while attempt_number > 0:
			attempt_number -= 1
			# Open a connection on the server
			try:
				if this_use_sftp is True:
					# FTPS
					ftp_id = ftplib.FTP_TLS( host   = this_address
					                       , user   = this_login
					                       , passwd = this_password
					                       , keyfile  = None
					                       , certfile = _ftps_certificate_file_name
					                       , timeout  = this_timeout
					                       )
				else:
					# Default FTP
					ftp_id = ftplib.FTP( host   = this_address
					                   , user   = this_login
					                   , passwd = this_password
					                   , timeout = this_timeout
					                   )
			except (ftplib.error_temp,ftplib.error_reply,ftplib.error_perm,ftplib.error_proto), e:
				err_msg = e.args[0]
			except socket.error, msg:
				err_msg = gui_common.get_socket_error_msg( this_error = msg)
			except gui_common.runing_errors,why:
				err_msg = str(why)
			except:
				err_msg = "ftplib.FTP()"
			else:
				# Yes !
				err_msg = None
				break
			if _ftp_repeat_command( this_err_msg = err_msg) is False:
				break
			# while attempt_number
			time.sleep(_ftp_repeat_waiting_delay)
			continue
		if err_msg is not None:
			# Oops ! No FTP connection...
			msg = "Unable to open FTP connection (addr: %s, login: %s, password: %s, timeout: %ds)\n| %s"%( this_address
			                                                                                              , this_login
			                                                                                              , this_password
			                                                                                              , this_timeout
			                                                                                              , err_msg
			                                                                                              )
			gui_common.save_error( this_msg = msg
			                     , this_object_class = None
			                     , this_file_name = __file__
			                     , this_mail_subject = "%s %s: %s"%(_ftp_error_tag,this_address,err_msg)
			                     )
			# We can not open as many connection as we would like... Run whith the openned ones as 'fail-soft' mode  ;-)
			return answer
		else:
			if this_use_sftp is True:
				# Switch ON secure data connection
				ftp_id.prot_p()
			# Set FTP socket options
			if gui_common.set_socket_options( this_socket_id = ftp_id.sock
			                                , this_timeout_s = this_timeout
			                                , this_device = gui_common.io_device_ethernet0
			                                , this_server_purpose = False
			                                , this_debug = this_debug_mode
			                                , this_mtu = gui_common.ip_mtu
			                                ) is False:
				_ftp_close_connection( this_ftp_id = ftp_id)
				return answer
			# Set FTP debug trace level
			#   0: no debugging output (default)
			#   1: print commands and responses but not body text etc.
			#   2: also print raw lines read and sent before stripping CR/LF
			if this_debug_mode is True:
				ftp_id.set_debuglevel( level = 1 )
			else:
				ftp_id.set_debuglevel( level = 0 )
			# Force 'passive mode'
			ftp_id.set_pasv( True )
			# Create a dedicated thread which manage the transfert. It will be launched later by the caller.
			ftp_thread_id = _ftp_slave_thread( this_ftp_id_id = ftp_id
			                                 , this_server_ip_address = this_address
			                                 , this_file_manager_id = file_manager_id
			                                 , this_upload = this_upload
			                                 , this_user_remote_dir = this_user_remote_dir
			                                 , this_start_time = start_time
			                                 , this_debug_mode = this_debug_mode
			                                 , this_check_size = this_check_size
			                                 )
			cnx_idx += 1
			if this_nickname is None:
				thread_name = "FTP_%s_%s_%d"%( this_address
				                             , ud
				                             , cnx_idx
				                             )
			else:
				thread_name = "FTP_%s_%s_%s_%d"%( this_address
				                                , this_nickname
				                                , ud
				                                , cnx_idx
				                                )
			ftp_thread_id.setName(thread_name)
			info = (file_manager_id, ftp_id, ftp_thread_id)
			answer.append(info)
		# While this_max_connection
		continue
	return answer

# -----------------------------------------------
# Private Function : _ftp_close_connection_list()
# -----------------------------------------------
def _ftp_close_connection_list( this_list ):
	"""
	Close opened FTP connection thanks to _ftp_open_many_connection()
	@param this_list: (file manager ident, ftp thread ident) tuple
	@type this_list: list of tuples comming from _ftp_open_many_connection()
	"""
	for ftp_cnx_info in this_list :
		(file_manager_id, ftp_id, ftp_thread_id) = ftp_cnx_info
		_ftp_close_connection( this_ftp_id = ftp_id)
		# Next ftp_cnx_info
		continue
	return

# --------------------------------------
# Function : _ftp_get_directory_detail()
# --------------------------------------
def _ftp_get_directory_detail( this_ftp_id = None
                             , this_dir = None
                             ):
	"""
	Get detailed remote directory info (Filezilla Server)
	@param this_ftp_id: open FTP connection
	@type this_ftp_id: ftplib object
	@param this_ftp_id: remote directory. if None, the current one is used
	@type this_ftp_id: ascii string
	@return
	"""
	# Go to the given directory
	if this_dir is not None:
		this_ftp_id.cwd( this_dir )
	# Ask information
	file_list = []
	this_ftp_id.dir(file_list.append)
	# The Filezilla Server answer format looks like:
	# -rw-r--r-- 1 ftp ftp    1608780 Aug 29  2012 FileZilla Server.log
	# -rw-r--r-- 1 ftp ftp    2634337 Mar 10 17:17 fzs-2015-03-10.log
	# -rw-r--r-- 1 ftp ftp    7296369 Mar 11 17:39 fzs-2015-03-11.log
	current_year = int(time.strftime("%Y", time.gmtime()))
	answer = []
	for info_idx in file_list:
		splitted_line = info_idx.split()
		user_group_other_rights = splitted_line[0]
		directory_flag = user_group_other_rights[0] # 'd' or '-'
		user_group_other_rights = user_group_other_rights[1:]
		inode_number = splitted_line[1]
		user_name = splitted_line[2]
		group_name  = splitted_line[3]
		size = int(splitted_line[4])
		month = splitted_line[5]
		date = int(splitted_line[6])
		if ':' in splitted_line[7]:
			# Hour only
			hour_minute = splitted_line[7]
			year = current_year
		else:
			# Year only
			hour_minute = "00:00"
			year = int(splitted_line[7])
		file = " ".join(splitted_line[8:])
		element = (directory_flag, size, year, month, date, hour_minute, file)
		answer.append(element)
		# Next info_idx
		continue
	return answer

# ---------------------------------
# Function : _ftp_get_server_info()
# ---------------------------------
def _ftp_get_server_info( this_ftp_id ):
	"""
	Return the FTP server information like name and features
	@param this_ftp_id: open FTP connection
	@type this_ftp_id: ftplib object
	@return: remote FTP server name and features
	@rtype: ascii string
	"""
	err_msg = None
	try:
		system_info = this_ftp_id.sendcmd( cmd = 'SYST')
	except (ftplib.error_temp,ftplib.error_reply,ftplib.error_perm,ftplib.error_proto), e:
		err_msg = e.args[0]
	except socket.error, msg:
		err_msg = gui_common.get_socket_error_msg( this_error = msg)
	else:
		expected_answer = "215 "
		if system_info.startswith(expected_answer) is True:
			# Yeap ! We have the offical system name like '215 UNIX emulated by FileZilla', ignore the number...
			system_info = system_info[len(expected_answer):]
	if err_msg is not None:
		gui_common.save_error( this_msg = "sendcmd('SYST') : %s"%(err_msg)
		                     , this_object_class = this_ftp_id
		                     , this_file_name = __file__
		                     , this_mail_subject = "%s: %s"%(_ftp_error_tag,err_msg)
		                     )
		system_info = "Unknown system"
	# Feature Negotiation... [RFC2389]
	feature_list = []
	try:
		response = this_ftp_id.sendcmd('FEAT')
	except:
		# Command not supported ! Snif
		pass
	else:
		# The Filezilla server answer looks like: b'211-Features:\n MDTM\n REST STREAM\n SIZE\n MLST type*;size*;modify*;\n MLSD\n UTF8\n CLNT\n MFMT\n211 End'
		expected_answer = "211"
		if response.startswith(expected_answer) is True:
			# Yeap ! ignore the number and the 'End'...
			feature_list = [idx for idx in response.split(':')[1].split('\n')[:-1] if idx != ""]
			# ---------------------------------------------
			# <<>>
			# Synopsis
			#    The OPTS command is a required command if the FEAT command is also implemented.
			#    The OPTS command is used to provide additional information for extended features supported by the FTP server.
			# Description
			#    The OPTS command will be followed by the name of the command requiring additional information.
			#    Following the command being configured will be additional parameters that have meaning only in the context of the command being configured.
			#    FTP Voyager currently issues the OPTS command under two circumstances:
			#       MODE - FTP Voyager will issue an OPTS MODE command to servers to configure extended options for a given transfer mode. Most commonly MODE is implemented in the "MODE Z LEVEL X" command for supporting on-the-fly compression to configure the level of compression to use for the session where 'X' is a number between 1 (fastest, least compression) and 10 (slowest, most compression). FTP Voyager uses a default value of 6.
			#       MLST - FTP Voyager may issue an OPTS MLST command to servers supporting the MLST command in order to configure the amount of information sent by the server in response to the MLST command. It is issued in the format OPTS MLST Info1;Info2;Info3 etc, with each type of information separated by a semicolon. Information types can include Type (filetype), Size (filesize), Modify (last modification date), Create (date of file creation), and more. The information types the server supports are sent to the client as part of the server's response to the FEAT command, and used to determine the contents of the OPTS MLST command issued to the server.
			#       UTF8 - Configures the server to enable (ON) or disable (OFF) UTF-8 encoding which is useful for non-ANSI character sets. This is very useful for Asian file names and paths.
			#
			#   COMMAND:> OPTS MLST Type;Size;Modify;UNIX.mode;UNIX.owner;UNIX.group;
			#   200 MLST OPTS Type;Size;Modify;UNIX.mode;UNIX.owner;UNIX.group;
			# ---------------------------------------------
			# <<>>
			# Synopsis
			#    The MFMT command is used to modify a file or folder's last modified date and time information. MFMT duplicates similar functionality implemented by the MDTM command.
			# Description
			#    Traditionally, when a file or folder is uploaded to an FTP server, the last modified date and time of the file or folder is set to the transfer date and time.
			#    Using MFMT, FTP clients can inform supporting FTP servers of the proper last modified date and time to use for the file or folder.
			#    The format of the command is MFMT YYYYMMDDHHMMSS path, where:
			#         YYYY - the 4-digit year
			#         MM - the 2-digit month
			#         DD - the 2-digit day of the month
			#         HH - the hour in 24-hour format
			#         MM - the minute
			#         SS - the seconds
			# All times are represented in GMT/UTC.
			# ---------------------------------------------
			# <<>>
			# Synopsis
			#    The MDTM command implemented by FTP is used to preserve a file's original date and time information after file transfer.
			# Description
			#    Traditionally, when a file is uploaded to an FTP server, the date/time of the file is set to the transfer date/time.
			#    Using MDTM, FTP Voyager can inform supporting FTP servers of the proper date/time to use for the file.
			#    The format of the command is MDTM YYYYMMDDHHMMSS, where:
			#        YYYY - the 4-digit year
			#        MM - the 2-digit month
			#        DD - the 2-digit day of the month
			#        HH - the hour in 24-hour format
			#        MM - the minute
			#        SS - the seconds
			# ---------------------------------------------
	answer = (system_info, feature_list)
	return answer

# -----------------------------------------
# Private Function : _ftp_get_remote_info()
# -----------------------------------------
def _ftp_get_remote_info( this_ftp_id = None
                        , this_ftp_tag = None
                        , this_tag_selector = []
                        , this_remote_directory_flag = None
                        ):
	"""
	Return the listing of a remote file / directory
	@param this_ftp_id: open FTP connection
	@type this_ftp_id: ftplib object
	@param this_ftp_tag: target directory or file to list
	@type this_ftp_tag: ascii string
	@param this_tag_selector: optional tag selector
	@type this_tag_selector: list of ascii string
	@param this_remote_directory_flag: False = remote file, True = remote directory, None = to be determined
	@type this_remote_directory_flag: boolean
	@return: list of (full remote path name, is_directory, file_size)
	@rtype: list of tuple (ascii string, boolean, integer)
	@note:
		- use the standard MLSD command instead of LIST (result os dependant)
		- NLST returns the file names without any type  :-(
		- The MLST command only provides detailed information about a single file or folder
		  while the MLSD can provide information about multiple files and folders.
	"""
	callback_answer_list = []
	# ---------------------------------
	# Private: ftp_mlsd_mlst_callback()
	# ---------------------------------
	def ftp_mlsd_mlst_callback( this_input ):
		"""
		Analyse the standard MLSD & MLST answer (local function for recursivity)
		Update 'answer' in relation with the incoming data
		The FTP MLSD answer should looks like:
			- type=dir;modify=20100114090849; Lib
			- type=file;modify=20100114090849;size=1190652; swig.exe
		the MLST answer should looks like:
			- type=file;size=386456;modify=20150317130322; /AGERMANE.3.zip
		"""
		# Be carefull: if the command has been sent with retbinary we have all result in one answer with '\n\r' as separator !
		for input_idx in this_input.split(gui_common.char_crlf):
			if input_idx == "":
				# Ignore it !
				continue
			# For each record element
			full_splitted = [element_idx.strip() for element_idx in input_idx.split(';')]
			# Get name and apply a filter
			name = full_splitted[-1].strip()
			if name[0] == _ftp_posix_separator:
				name = name[1:]
			match = True
			for tag_idx in this_tag_selector:
				if tag_idx not in name:
					# Discard it !
					match = False
					break
				# Next tag_idx
				continue
			if match is True:
				# Get 'type' info: file or directory
				splitted_record = full_splitted[0].split('=')
				if splitted_record[0] != "type":
					gui_common.save_error( this_msg = "unexpected format: %s"%(this_input)
					                     , this_object_class = this_ftp_id
					                     , this_file_name = __file__
					                     , this_mail_subject = _ftp_error_tag
					                     )
					return
				is_a_directory = (splitted_record[1] == "dir")
				# Get file size (not available for directory)
				file_size = 0
				if is_a_directory is False:
					# !!! 'size' & 'modify' parameters are inverted between MLST & MLSD results !!!
					for idx in range(1,len(full_splitted)-1):
						splitted_record = full_splitted[idx].split('=')
						if splitted_record[0] == "size":
							# Yeap !
							file_size = int(splitted_record[1])
							break
						# Next idx
						continue
				# The result is...
				result = (name, is_a_directory, file_size)
				callback_answer_list.append(result)
				# Next input_idx
				continue
		return
	# -------------------------------
	# Private: sort_callback_result()
	# -------------------------------
	def sort_callback_result(tag1,tag2):
		(name1, is_a_directory1, file_size1) = tag1
		(name2, is_a_directory2, file_size2) = tag2
		if is_a_directory1 is True:
			if is_a_directory2 is True:
				# 2 directories --> sort by directory name
				if name1 < name2:
					return -1
				else:
					return 1
			else:
				# Dir 1, file 2
				return 1
		else:
			if is_a_directory2 is True:
				# File 1, dir 2
				return -1
			else:
				# 2 files --> sort by by file name
				if name1 < name2:
					return -1
				else:
					return 1
		return 0
	#
	# Body: _ftp_get_remote_info()
	#
	answer = []
	err_msg = None
	# Do some checks
	if this_ftp_tag is None:
		# All default directory content
		this_ftp_tag = _ftp_posix_separator
		remote_directory = _ftp_posix_separator
	# FTP or SFTP ?
	try:
		sftp_in_use = this_ftp_id._prot_p
	except:
		sftp_in_use = False
	# What is the remote target ?
	if this_remote_directory_flag is None:
		# Verify if it's a remote file or a remote directory
		try:
			remote_file_size = this_ftp_id.size( this_ftp_tag)
		except ftplib.error_perm, e:
			# It's a directory
			this_remote_directory_flag = True
		else:
			# It's a file. Ask remote file information
			this_remote_directory_flag = False
	# Get remote information
	if this_remote_directory_flag is True:
		remote_directory = this_ftp_tag+_ftp_posix_separator
		# Go to the selected directory
		try:
			this_ftp_id.cwd( dirname = this_ftp_tag)
		except (ftplib.error_temp,ftplib.error_reply,ftplib.error_perm,ftplib.error_proto), e:
			err_msg = e.args[0]
		except socket.error, msg:
			err_msg = gui_common.get_socket_error_msg( this_error = msg)
		else:
			# Ask remote directory information
			try:
				if sftp_in_use is True:
					result = this_ftp_id.retrbinary( cmd = 'MLSD'
					                               , callback = ftp_mlsd_mlst_callback
					                               )
				else:
					result = this_ftp_id.retrlines( cmd = 'MLSD'
					                              , callback = ftp_mlsd_mlst_callback
					                              )
			except (ftplib.error_temp,ftplib.error_reply,ftplib.error_perm,ftplib.error_proto), e:
				err_msg = e.args[0]
			except socket.error, msg:
				err_msg = gui_common.get_socket_error_msg( this_error = msg)
			if err_msg is not None:
				gui_common.save_error( this_msg = "retrlines('MLSD'): %s"%(err_msg)
				                     , this_object_class = this_ftp_id
				                     , this_file_name = __file__
				                     , this_mail_subject = "%s: %s"%(_ftp_error_tag,err_msg)
				                     )
				return answer
	else:
		remote_directory = ""
		# Obtain remote file information
		try:
			result = this_ftp_id.sendcmd( cmd = 'MLST '+this_ftp_tag)
		except (ftplib.error_temp,ftplib.error_reply,ftplib.error_perm,ftplib.error_proto), e:
			err_msg = e.args[0]
		except socket.error, msg:
			err_msg = gui_common.get_socket_error_msg( this_error = msg)
		else:
			# The MLST answer looks like: b'250-Listing /AGERMANE.3.zip\n type=file;size=386456;modify=20150317130322; /AGERMANE.3.zip\n250 End'
			splitted_answer = result.split('\n')
			if '250' in splitted_answer[0]:
				# Yeap !
				this_remote_directory_flag = False
				ftp_mlsd_mlst_callback ( this_input = splitted_answer[1])
			else:
				err_msg = "Unexpected answer: '%s'"%(result)
		if err_msg is not None:
			gui_common.save_error( this_msg = "sendcmd('MLST'): %s"%(err_msg)
			                     , this_object_class = ftp_id
			                     , this_file_name = __file__
			                     , this_mail_subject = "%s: %s"%(_ftp_error_tag,err_msg)
			                     )
			return answer
	# Analyse the result of the file or of the current directory...
	for remote_info_idx in callback_answer_list:
		try:
			(name, is_directory, file_size) = remote_info_idx
		except gui_common.runing_errors,why:
			err_msg = "Unexpected 'local_info_idx' format: %s - '%s'"%(str(why), str(remote_info_idx))
			gui_common.save_error( this_msg = err_msg
			                     , this_object_class = this_ftp_id
			                     , this_file_name = __file__
			                     , this_mail_subject = "%s: %s"%(_ftp_error_tag,err_msg)
			                     )
			return answer
		if is_directory is True:
			# It's a directory, go on recursively
			if this_ftp_tag is None:
				new_dir = _ftp_posix_separator+name
			else:
				new_dir = name
			answer2 = _ftp_get_remote_info( this_ftp_id = this_ftp_id
			                              , this_ftp_tag = new_dir
			                              , this_tag_selector = this_tag_selector
			                              , this_remote_directory_flag = is_directory
			                              )
			# Build a full path answer
			for remote_info_jdx in answer2:
				try:
					(name2, is_directory2, file_size2) = remote_info_jdx
				except gui_common.runing_errors,why:
					err_msg = "Unexpected 'remote_info_jdx' format: %s - '%s'"%(str(why), str(remote_info_jdx))
					gui_common.save_error( this_msg = err_msg
					                     , this_object_class = this_ftp_id
					                     , this_file_name = __file__
					                     , this_mail_subject = "%s: %s"%(_ftp_error_tag,err_msg)
					                     )
					return answer
				remote_info_jdx = (this_ftp_tag+_ftp_posix_separator+name2, is_directory2, file_size2)
				answer.append(remote_info_jdx)
				# Next remote_info_jdx
				continue
			# Return to the parent directory
			try:
				result = this_ftp_id.sendcmd( cmd = 'CDUP')
			except (ftplib.error_temp,ftplib.error_reply,ftplib.error_perm,ftplib.error_proto), e:
				err_msg = e.args[0]
			except socket.error, msg:
				err_msg = gui_common.get_socket_error_msg( this_error = msg)
			if err_msg is not None:
				gui_common.save_error( this_msg = "sendcmd(CDUP): %s"%(err_msg)
				                     , this_object_class = this_ftp_id
				                     , this_file_name = __file__
				                     , this_mail_subject = "%s: %s"%(_ftp_error_tag,err_msg)
				                     )
				return answer
			# Do a difference between directory size and empty file size
			file_size = _ftp_dir_size
		# Answer with full path name
		remote_info_idx = (remote_directory+name, is_directory, file_size)
		answer.append(remote_info_idx)
		# Next remote_info_idx
		continue
	return answer

# ---------------------------
# Private Class : _ftp_thread
# ---------------------------
class _ftp_thread( threading.Thread):
	"""
	Independant FPT thread to upload or download several host in parallele
	@sort: _*,a*,b*,c*,d*,e*,f*,g*,h*,i*,j*,k*,l*,m*,n*,o*,p*,q*,r*,s*,t*,u*,v*,w*,x*,y*,z*
	"""
	# ----------------------
	# _ftp_thread.__init__()
	# ----------------------
	def __init__( self
	            , this_address  = "1.2.3.4"
	            , this_login    = "dummy_login"
	            , this_password = "dumthr_password"
	            , this_timeout = gui_common.ftp_timeout_s
	            , this_src_path = None
	            , this_dst_path = None
	            , this_direction= _upload_cmd
	            , this_cleanup_flag = False
	            , this_debug_mode = False
	            ):
		"""
		FTP thread initialisation
		@param this_address: address of the server
		@type this_address: ascii
		@param this_login: remote user login
		@type this_login: ascii
		@param this_password: remote user password
		@type this_password: ascii
		@param this_timeout: timeout in seconds for blocking operations like the connection attempt
		@type this_timeout: real
		@param this_src_path: source path name (file or directory). A wildcard '*' is allowed.
		@type this_src_path: ascii string
		@param this_dst_path: server destination path name
		@type this_dst_path: ascii string
		@param this_direction: 'Upload' or 'Download' transfert direction
		@type this_direction: ascii string
		@param this_cleanup_flag: force to clean up the destination directory (True) or not (False)
		@type this_cleanup_flag: boolean
		@param this_debug_mode: True = with debug mode, False = silent
		@type this_debug_mode: boolean
		@return: None
		 """
		# Initialise my thread
		self.thread_id = threading.Thread.__init__(self)
		self.result = True
		self.cleanup_flag = this_cleanup_flag
		# Save input parameters
		self.address = this_address
		self.login = this_login
		self.timeout = this_timeout
		self.src_path = this_src_path
		self.dst_path = this_dst_path
		self.direction = this_direction
		self.debug_mode = this_debug_mode
		# Force the Lab server password if possible
		if this_login == gui_common.main_login:
			self.password = gui_common.get_root_password( this_ip_address = self.address)
			if self.password is None:
				# It's an another host, use the given password
				self.password = this_password
		else:
			# Use the given password
			self.password = this_password
		return
	# -------------------
	# _ftp_thread.error()
	# -------------------
	def error( self
	         , this_msg
	         ):
		"""
		Shortcut access to display an error
		@param this_msg: input message describing the error
		@type this_msg: ascii string
		@return: None
		"""
		gui_common.save_error( this_msg = this_msg
		                     , this_object_class = self
		                     , this_file_name = __file__
		                     , this_mail_subject = _ftp_error_tag
		                     )
		self.result = False
		return
	# ------------------------
	# _ftp_thread.save_trace()
	# ------------------------
	def save_trace( self
	              , this_msg
	              , this_caller_name
	              ):
		"""
		Shortcut access to display an error
		@param this_msg: input message describing the error
		@type this_msg: ascii string
		@param this_caller_name: caller function name
		@type this_caller_name: ascii string
		@return: None
		"""
		gui_common.save_trace( this_msg = this_msg
		                     , this_object_class = self
		                     , this_file_name = __file__
		                     , this_caller_name = this_caller_name
		                     )
		return
	# -----------------
	# _ftp_thread.run()
	# -----------------
	def run(self):
		"""
		FTP thread body
		@return: None
		"""
		if self.direction == _upload_cmd:
			# Upload wanted
			if self.cleanup_flag is True:
				# Clean Up wanted on the remote host
				if self.debug_mode is True:
					self.save_trace( this_msg = "Try to remove server directory %s : %s"%(self.address,self.dst_path)
					               , this_caller_name = "run()"
					               )
				self.result = ftp_remove( this_address  = self.address
				                        , this_login    = self.login
				                        , this_password = self.password
				                        , this_timeout  = self.timeout
				                        , this_dst_path = self.dst_path
				                        )
				if self.result is not True:
					self.error( this_msg = "Remove server directory %s : %s"%(self.address,self.dst_path))
				else:
					if self.debug_mode is True:
						self.save_trace( this_msg = "Remove server directory %s done : %s"%(self.address,self.dst_path)
						               , this_caller_name = "run()"
						               )
			# And then upload !
			self.result = ftp_upload( this_address    = self.address
			                        , this_login      = self.login
			                        , this_password   = self.password
			                        , this_timeout    = self.timeout
			                        , this_src_path   = self.src_path
			                        , this_dst_path   = self.dst_path
			                        )
			if self.result is True:
				if self.debug_mode is True:
					self.save_trace( this_msg = "Upload server %s done"%(self.address)
					               , this_caller_name = "run()"
					               )
			return
		if self.direction == _download_cmd:
			if self.cleanup_flag is True:
				# Clean Up wanted on the running host
				if os.path.isdir(self.dst_path) is True:
					# And the directory already exists
					self.result = gui_common.remove_directory( this_target = self.dst_path+os.sep+"*")
					if self.result is not True:
						# Oops !
						return
			# Retreive back all files and directories
			self.result = ftp_download( this_address    = self.address
			                          , this_login      = self.login
			                          , this_password   = self.password
			                          , this_timeout    = self.timeout
			                          , this_src_path   = self.src_path
			                          , this_dst_path   = self.dst_path
			                          )
			if self.result is not True:
				self.error( this_msg = "Download server %s with %s"%(self.address,self.src_path))
			else:
				if self.debug_mode is True:
					self.save_trace( this_msg = "Download from server %s done"%(self.address)
					               , this_caller_name = "run()"
					               )
			return
		# Should never occure
		self.error( this_msg = "Unknown command: %s"%(self.direction))
		return

### ---------------- ###
### Public functions ###
### ---------------- ###

# -----------------------
# Function : ftp_remove()
# -----------------------
def ftp_remove( this_address  = "1.2.3.4"
              , this_login    = "dummy_login"
              , this_password = "dummy_password"
              , this_timeout = gui_common.ftp_timeout_s
              , this_dst_path = None
              , this_debug_mode = False
              , this_use_sftp = False
              ):
	"""
	FTP Remove recursivly file(s) and directory(ies). Use recursivity when a directory is found.
	@param this_address: address of the server
	@type this_address: ascii
	@param this_login: remote user login
	@type this_login: ascii
	@param this_password: remote user password
	@type this_password: ascii
	@param this_timeout: timeout in seconds for blocking operations like the connection attempt
	@type this_timeout: real
	@param this_dst_path: local destination directory
	@type this_dst_path: ascii string
	@param this_debug_mode: current debug mode
	@param this_use_sftp: True = use FTPS, False = use normal FTP
	@type this_use_sftp: boolean
	@type this_debug_mode: boolean
	@return: True : transfert done / False : error
	@rtype: boolean
	"""
	#-------------------------------
	# local function for recursivity
	#-------------------------------
	def recursive_ftp_remove( this_dst_path
	                        , this_is_a_directory = False
	                        ):
		"""
		local function for recursivity calls
		@param this_src_path: server source directory
		@type this_src_path: ascii string
		@param this_is_a_directory: private parameter: True = directory, False = file (could not exist !)
		@type this_is_a_directory: boolean
		"""
		answer = True
		# Be careful with the first call...  ;-)*
		dst_dir_list = []
		err_msg = None
		if this_is_a_directory is False:
			# Determine if it's a file or a directory
			try:
				# Is 'file' file or directory ?
				remote_file_size = ftp_id.size(this_dst_path)
				# If here : it's a file and it exists
				dst_dir_list.append(this_dst_path)
			except ftplib.error_perm, e:
				# It's a directory or the file does not exist !
				recursive_ftp_remove( this_dst_path = this_dst_path
				                    , this_is_a_directory = True
				                    )
			except (ftplib.error_temp,ftplib.error_reply,ftplib.error_proto), e:
				err_msg = e.args[0]
			except socket.error, msg:
				err_msg = gui_common.get_socket_error_msg( this_error = msg)
			except gui_common.runing_errors,why:
				err_msg = str(why)
			if err_msg is not None:
				gui_common.save_error( this_msg = "delete(%s) on %s : %s"%(this_dst_path,this_address,err_msg)
				                     , this_object_class = ftp_id
				                     , this_file_name = __file__
				                     , this_mail_subject = "%s: %s"%(_ftp_error_tag,err_msg)
				                     )
				return False
		else:
			# It's a directory or the file does not exist !
			try:
				dst_dir_list = ftp_id.nlst(this_dst_path)
			except (ftplib.error_temp,ftplib.error_reply,ftplib.error_perm,ftplib.error_proto), e:
				# Be careful with '550 Directory not found'
				err_msg = str(e.args[0])
				if '550' in err_msg:
					# The file does not exist ! It wasn't a directory...
					return True
			except socket.error, msg:
				err_msg = gui_common.get_socket_error_msg( this_error = msg)
			except gui_common.runing_errors,why:
				err_msg = str(why)
			if err_msg is not None:
				gui_common.save_error( this_msg = "nlst(%s) on %s : %s"%(this_dst_path,this_address,err_msg)
				                     , this_object_class = ftp_id
				                     , this_file_name = __file__
				                     , this_mail_subject = "%s: %s"%(_ftp_error_tag,err_msg)
				                     )
				return False
		# Exam the result list
		for dst_file in dst_dir_list:
			# Display debug information (if wanted)
			if this_debug_mode is True:
				gui_common.save_trace( this_msg = "recursive_ftp_remove(%s) : %s"%(this_address,dst_file)
				                     , this_object_class = None
				                     , this_file_name = None
				                     , this_caller_name = "recursive_ftp_remove()"
				                     )
			# Is it a file or a directory ?
			try:
				remote_file_size = ftp_id.size(dst_file)
				# If here : it's a file. Remove it.
				attempt_number = _ftp_repeat_nb
				while attempt_number > 0:
					attempt_number -= 1
					try:
						ftp_id.delete(dst_file)
					except (ftplib.error_temp,ftplib.error_reply,ftplib.error_perm,ftplib.error_proto), e:
						err_msg = e.args[0]
					except socket.error, msg:
						err_msg = gui_common.get_socket_error_msg( this_error = msg)
					except gui_common.runing_errors,why:
						err_msg = str(why)
					else:
						err_msg = None
						break
					if _ftp_repeat_command( this_err_msg = err_msg) is False:
						break
					# while attempt_number
					time.sleep(_ftp_repeat_waiting_delay)
					continue
				if err_msg is not None:
					gui_common.save_error( this_msg = "recursive_ftp_remove(%s) -> delete(%s) %d bytes: %s"%(this_address,this_dst_path,remote_file_size,err_msg)
					                     , this_object_class = ftp_id
					                     , this_file_name = __file__
					                     , this_mail_subject = "%s: %s"%(_ftp_error_tag,err_msg)
					                     )
					return False
			except ftplib.error_perm, e:
				# 5xx errors, It's may be a directory or it does not exist...
				if recursive_ftp_remove( dst_file
				                       , this_is_a_directory = True
				                       ) is not True:
					return False
				# Remove the directory
				attempt_number = _ftp_repeat_nb
				while attempt_number > 0:
					attempt_number -= 1
					try:
						ftp_id.rmd(dst_file)
					except ftplib.all_errors, e:
						err_msg = e.args[0]
					except socket.error, msg:
						err_msg = gui_common.get_socket_error_msg( this_error = msg)
					except gui_common.runing_errors,why:
						err_msg = str(why)
					else:
						err_msg = None
						break
					# Do a last control... in case of '550 Directory not found'
					if "Directory not found" in err_msg:
						# The error is normal in this case ! It should occure during the first call  ;-)
						err_msg = None
						break
					if _ftp_repeat_command( this_err_msg = err_msg) is False:
						break
					# while attempt_number
					time.sleep(_ftp_repeat_waiting_delay)
					continue
				if err_msg is not None:
					gui_common.save_error( this_msg = "recursive_ftp_remove(%s) -> rmd(%s) : %s"%(this_address,this_dst_path,err_msg)
					                     , this_object_class = ftp_id
					                     , this_file_name = __file__
					                     , this_mail_subject = "%s: %s"%(_ftp_error_tag,err_msg)
					                     )
					return False
			except (ftplib.error_temp,ftplib.error_reply,ftplib.error_proto), e:
				err_msg = e.args[0]
			except socket.error, msg:
				err_msg = gui_common.get_socket_error_msg( this_error = msg)
			except gui_common.runing_errors,why:
				err_msg = str(why)
			except :
				err_msg = "???"
			if err_msg is not None:
				gui_common.save_error( this_msg = "recursive_ftp_remove(%s) -> delete(%s) : %s"%(this_address,this_dst_path,err_msg)
				                     , this_object_class = ftp_id
				                     , this_file_name = __file__
				                     , this_mail_subject = "%s: %s"%(_ftp_error_tag,err_msg)
				                     )
				return False
			# Next dst_file
			continue
		return True
	#
	# Main body of ftp_remove()
	#
	if this_debug_mode is True:
		gui_common.save_trace( this_msg = "ftp_remove(%s) destination path %s, login: %s, pass: %s"%(this_address,this_dst_path,this_login,this_password)
		                     , this_object_class = None
		                     , this_file_name = __file__
		                     , this_caller_name = "ftp_remove()"
		                     )
	err_msg = None
	# Open the FTP connection
	try:
		if this_use_sftp is True:
			# FTPS
			ftp_id = ftplib.FTP_TLS( host   = this_address
			                       , user   = this_login
			                       , passwd = this_password
			                       , keyfile  = None
			                       , certfile = _ftps_certificate_file_name
			                       , timeout  = this_timeout
			                       )
		else:
			# Default FTP
			ftp_id = ftplib.FTP( host   = this_address
			                   , user   = this_login
			                   , passwd = this_password
			                   , timeout = this_timeout
			                   )
	except (ftplib.error_temp,ftplib.error_reply,ftplib.error_perm,ftplib.error_proto), e:
		err_msg = e.args[0]
	except socket.error, msg:
		err_msg = gui_common.get_socket_error_msg( this_error = msg)
	except gui_common.runing_errors,why:
		err_msg = str(why)
	if err_msg is not None:
		gui_common.save_error( this_msg = "ftp_remove(%s) : Unable to open a FTP connection (login: %s, password: %s) : %s"%(this_address,this_login,this_password,err_msg)
		                     , this_file_name = __file__
		                     , this_mail_subject = "%s: %s"%(_ftp_error_tag,err_msg)
		                     )
		return False
	if this_debug_mode is True:
		# Set FTP debug trace level
		# 0: no debugging output (default)
		# 1: print commands and responses but not body text etc.
		# 2: also print raw lines read and sent before stripping CR/LF
		ftp_id.set_debuglevel( level = 1 )
	else:
		# The default value
		ftp_id.set_debuglevel( level = 0 )
	# Go on
	if this_dst_path is None :
		# Take the current remote directory as default one
		try:
			this_dst_path = ftp_id.pwd()
		except:
			gui_common.save_error( this_msg = "ftp_remove(%s) : Unable to obtain the current FTP remote directory"%(this_address)
			                     , this_object_class = ftp_id
			                     , this_file_name = __file__
			                     , this_mail_subject = _ftp_error_tag
			                     )
			return False
	# Go
	result = recursive_ftp_remove(this_dst_path)
	# Close the FTP connection
	_ftp_close_connection( this_ftp_id = ftp_id)
	# Done
	return result

# -------------------------
# Function : ftp_download()
# -------------------------
def ftp_download( this_address  = "1.2.3.4"
                , this_login    = "dummy_login"
                , this_password = "dummy_down_password"
                , this_timeout = gui_common.ftp_timeout_s
                , this_src_path = None
                , this_dst_path = None
                , this_nickname = None
                , this_check_size = False
                , this_max_connection = None
                , this_remote_directory_flag = None
                , this_debug_mode = False
                ):
	"""
	Download FTP a file or a directory and its content. Use recursivity when a directory is found.
	@param this_address: address of the server
	@type this_address: ascii
	@param this_login: remote user login
	@type this_login: ascii
	@param this_password: remote user password
	@type this_password: ascii
	@param this_timeout: timeout in seconds for blocking operations like the connection attempt
	@type this_timeout: real
	@param this_src_path: server source directory or file path. Wildcard '*' is allowed on the basename.
	@type this_src_path: ascii string
	@param this_dst_path: local destination directory
	@type this_dst_path: ascii string
	@param this_user_conf: user configuration
	@type this_user_conf: gui_user.configuration ident
	@param this_check_size: True = Check sent and downloaded file size, False = No check
	@type this_check_size: boolean
	@param this_max_connection: [optional] max connection number
	@type this_max_connection: integer
	@param this_remote_directory_flag: False = remote file, True = remote directory, None = to be determined
	@type this_remote_directory_flag: boolean
	@return: True : transfert done / False : error
	@rtype: boolean
	"""
	if this_debug_mode is True:
		msg = "ftp_download(%s) : from %s to %s, login: %s, pass: %s"%(this_address,this_src_path,this_dst_path,this_login,this_password)
		gui_common.save_trace( this_msg = msg
		                     , this_object_class = None
		                     , this_file_name = __file__
		                     )
	err_msg = None
	dummy = os.path.basename(this_src_path)
	if "*" in dummy:
		# It's a file or a directory with a wildcard
		tag_list = [tag_idx for tag_idx in dummy.split("*") if tag_idx != ""]
		src_path = os.path.dirname(this_src_path)
		if src_path == "":
			# No directory path, use the current one !
			src_path = os.curdir
	else:
		# It should be a directory name or a file name
		tag_list = []
		src_path = this_src_path
	# FTP or SFTP ?
	sftp_in_use = gui_common.get_sftp_usage( this_ip_address = this_address)
	if this_max_connection is None:
		# Get the maximal allowed connection number
		max_expected_connections_number = _ftp_get_max_connection( this_address = this_address)
	else:
		# Use the wanted user connection number
		max_expected_connections_number = this_max_connection
	ftp_cnx_info_list = _ftp_open_many_connection( this_address = this_address
	                                             , this_login = this_login
	                                             , this_password = this_password
	                                             , this_timeout = this_timeout
	                                             , this_upload = False
	                                             , this_max_connection = max_expected_connections_number
	                                             , this_user_remote_dir = src_path
	                                             , this_nickname = this_nickname
	                                             , this_check_size = this_check_size
	                                             , this_use_sftp = gui_common.get_sftp_usage( this_ip_address = this_address)
	                                             , this_debug_mode = this_debug_mode
	                                             )
	if ftp_cnx_info_list == []:
		# No opened connection on this server
		return False
	# Use the first connection for me. It will be closed by the slave thread.
	(file_manager_id, ftp_id, _ftp_thread_id) = ftp_cnx_info_list[0]
	# Go down to work !
	if this_dst_path is None :
		# Take the current source directory as default one
		this_dst_path = os.getcwd()
	if this_src_path is None :
		# Take the current remote directory as default one   ;-)
		try:
			this_src_path = ftp_id.pwd()
		except (ftplib.error_temp,ftplib.error_reply,ftplib.error_perm,ftplib.error_proto), e:
			err_msg = e.args[0]
		except socket.error, msg:
			err_msg = gui_common.get_socket_error_msg( this_error = msg)
		except:
			err_msg = "Unable to obtain the current FTP remote directory"
		if err_msg is not None:
			gui_common.save_error( this_msg = err_msg
			                     , this_object_class = ftp_id
			                     , this_file_name = __file__
			                     , this_mail_subject = _ftp_error_tag
			                     )
			# Close the FTP connections
			_ftp_close_connection_list( this_list = ftp_cnx_info_list)
			del file_manager_idx
			return False
	else:
		# Use POSIX name format
		this_src_path = this_src_path.replace(os.sep,_ftp_posix_separator)
	# Get remote files & directories
	remote_file_list = _ftp_get_remote_info( this_ftp_id = ftp_id
	                                       , this_ftp_tag = this_src_path
	                                       , this_tag_selector = tag_list
	                                       )
	if remote_file_list == []:
		# Nothing to transfert
		_ftp_close_connection_list( this_list = ftp_cnx_info_list)
		del ftp_cnx_info_list
		gui_common.garbage_collector_start()
		return True
	# Determine the src&dest files & directories
	local_dir_list = []
	for file_info_idx in remote_file_list:
		try:
			(remote_file_name, is_directory, file_size) = file_info_idx
		except gui_common.runing_errors,why:
			gui_common.save_error( this_msg = "unexpected file_info_idx format: %s, %s"%(str(file_info_idx),str(why))
			                     , this_file_name = __file__
			                     , this_mail_subject = _ftp_error_tag
			                     )
			_ftp_close_connection_list( this_list = ftp_cnx_info_list)
			gui_common.garbage_collector_start()
			return False
		real_dst_path = this_dst_path+os.sep+remote_file_name
		# FTP format: Linux --> Windows
		real_dst_path = real_dst_path.replace('/',os.sep)
		if is_directory is True:
			# Remote directory
			local_dir_list.append(real_dst_path)
		else:
			# Remote File
			file_info = (remote_file_name, real_dst_path, file_size)
			file_manager_id.add_waiting( this_scenario_name = file_info
			                           , this_ignore_duplication_warning = True
			                           )
		# Next file_info_idx
		continue
	if local_dir_list != []:
		# Build local directories
		gui_common.build_directories( this_directory_list = local_dir_list)
	# Retreive back the files now !
	for ftp_cnx_info in ftp_cnx_info_list:
		(file_manager_id, ftp_id, ftp_thread_id) = ftp_cnx_info
		ftp_thread_id.start()
		# Next ftp_cnx_info
		continue
	# Wait end of transfert
	result = True
	for ftp_cnx_info in ftp_cnx_info_list:
		(file_manager_id, ftp_id, ftp_thread_id) = ftp_cnx_info
		ftp_thread_id.join()
		result = result and ftp_thread_id.result
		# Next ftp_cnx_info
		continue
	_ftp_close_connection_list( this_list = ftp_cnx_info_list)
	del ftp_cnx_info_list
	# Check if the transfert has been done correctly
	remaining_file_list = file_manager_id.get_running_list(this_name_only = True)
	if remaining_file_list != []:
		# Some files have not been transfered
		subject = "%s Some files have not been downloaded to %s from %s"%( gui_common.ftp_download_marker
		                                                                 , gui_common.get_ip_address()
		                                                                 , this_address
		                                                                 )
		file_list  = [this_src_path,]
		file_list += [os.path.basename(full_src_file) for full_src_file in remaining_file_list if isinstance(full_src_file,(str,unicode)) is True]
		gui_common.send_mail( this_subject = subject
		                    , this_content = gui_common.char_line_feed.join([src_file for (src_file, dest_file, file_size) in remaining_file_list])
		                    , this_receiver_email_addr = gui_common.administrator_email
		                    )
	# Done
	gui_common.garbage_collector_start()
	return result

# -----------------------
# Function : ftp_upload()
# -----------------------
def ftp_upload( this_address  = "1.2.3.4"
              , this_login    = "dummy_up_login"
              , this_password = "dummy_up_password"
              , this_timeout = gui_common.ftp_timeout_s
              , this_src_path = None
              , this_dst_path = None
              , this_unwanted_tag_list = [gui_common.svn_dir_name,]
              , this_nickname = None
              , this_check_size = True
              , this_max_connection = None
              , this_debug_mode = False
              ):
	"""
	Upload FTP a file or a directory and its content. Use recursivity when a directory is found.
	@param this_address: address of the server
	@type this_address: ascii
	@param this_login: remote user login
	@type this_login: ascii
	@param this_password: remote user password
	@type this_password: ascii
	@param this_timeout: timeout in seconds for blocking operations like the connection attempt
	@type this_timeout: real
	@param this_src_path: source path name (file or directory). A wildcard '*' is allowed inside a file name (not the directory one).
	@type this_src_path: ascii string
	@param this_dst_path: server destination path name
	@type this_dst_path: ascii string
	@param this_unwanted_tag_list: do not upload files/directory whose name is present
	@type this_unwanted_tag_list: list of ascii string
	@param this_debug_mode: True = with debug mode, False = silent
	@type this_debug_mode: boolean
	@return: True : transfert done / False : error
	@rtype: boolean
	@note:
		- It is not possible to create a new remote directory whose name is different from the local one.
	"""
	# --------------------------------------
	# Private: recursive_build_upload_list()
	# --------------------------------------
	def recursive_build_upload_list( this_src_path
	                               , this_dst_path
	                               , this_unwanted_tag_list
	                               , this_recursiv_call = False
	                               ):
		"""
		local function for recursivity upload calls
		@param this_src_path: source path name (file or directory).
		@type this_src_path: ascii string
		@param this_dst_path: server destination directory
		@type this_dst_path: ascii string
		@param this_recursiv_call: True = recursiv call, the directory is already taken into account, False = first call
		@type this_recursiv_call: boolean
		@return: True : transfert done / False : error
		@rtype: boolean
		Note: Use binary transfert for ASCII and binary files tranfert  ;-)
		"""
		dst_path = copy.copy(this_dst_path)
		err_msg = None
		# Be careful with the first call...  ;-)
		if os.path.isdir(this_src_path) is True:
			if this_recursiv_call is False:
				base_name = os.path.basename(this_src_path)
				# Use the POSIX separator for remote files !
				dst_path += os.sep+base_name
				dst_path = dst_path.replace(os.sep,_ftp_posix_separator)
			# Get the directory list
			src_dir_list = os.listdir(this_src_path)
		else:
			if os.path.isfile(this_src_path) is True:
				# Only one file to upload
				src_dir_list = [os.path.basename(this_src_path),]
				this_src_path = os.path.dirname(this_src_path)
			else:
				# Do not follow links, ignore it
				return True
		# Exam the result list
		for src_file in src_dir_list:
			keep_file = True
			for unwanted_tag_idx in this_unwanted_tag_list:
				if unwanted_tag_idx in src_file:
					# Not wanted !
					keep_file = False
					break
				# Next unwanted_tag_idx
				continue
			if keep_file is False:
				# Next !
				continue
			full_src_file = this_src_path+os.sep+src_file
			# Use the POSIX separator for remote files !
			full_dest_file = dst_path+os.sep+src_file
			full_dest_file = full_dest_file.replace(os.sep,_ftp_posix_separator)
			if os.path.isfile(full_src_file) is True:
				# Add the file for transfert
				try:
					file_host_size = os.path.getsize(full_src_file)
				except gui_common.runing_errors,why:
					# Should never occure
					err_msg = str(why)
				except:
					# Idem !
					err_msg = "os.path.getsize(%s)"%(full_src_file)
				else:
					info = (full_src_file, full_dest_file, file_host_size)
					file_manager_id.add_waiting( this_scenario_name = info)
				if err_msg is not None:
					gui_common.save_warning( this_msg = "os.path.getsize(%s): %s"%(full_src_file,err_msg)
					                       , this_object_class = ftp_id
					                       , this_file_name = __file__
					                       , this_caller_name = "recursive_build_upload_list()"
					                       )
					return False
			else:
				if os.path.isdir(full_src_file) is True:
					new_dst_path = dst_path+_ftp_posix_separator+os.path.basename(full_src_file)
					# Do a recursive call
					if recursive_build_upload_list( this_src_path = full_src_file
					                              , this_dst_path = new_dst_path
					                              , this_unwanted_tag_list = this_unwanted_tag_list
					                              , this_recursiv_call = True
					                              ) is False:
						return False
			# Next src file
			continue
		return True
	#
	# Main body of ftp_upload()
	#
	if isinstance(this_dst_path,(str,unicode)) is False:
		subject = "%s Dest path is not an ASCII string '%s'"%( gui_common.ftp_upload_marker
		                                                     , str(this_dst_path)
		                                                     )
		current_thread_id = threading.currentThread()
		content = "%s\n%s"%(str(current_thread_id),gui_common.get_thread_stack())
		gui_common.send_mail( this_subject = subject
		                    , this_content = content
		                    , this_receiver_email_addr = gui_common.administrator_email
		                    )
		return False
	if isinstance(this_src_path,(str,unicode)) is False:
		subject = "%s Src path is not an ASCII string '%s'"%( gui_common.ftp_upload_marker
		                                                    , str(this_src_path)
		                                                    )
		current_thread_id = threading.currentThread()
		content = "%s\n%s"%(str(current_thread_id),gui_common.get_thread_stack())
		gui_common.send_mail( this_subject = subject
		                    , this_content = content
		                    , this_receiver_email_addr = gui_common.administrator_email
		                    )
		return False
	if this_debug_mode is True:
		gui_common.save_trace( this_msg = "ftp_upload(%s) from %s to %s, login: %s, pass: %s"%(this_address,this_src_path,this_dst_path,this_login,this_password)
		                     , this_object_class = None
		                     , this_file_name = __file__
		                     , this_caller_name = "ftp_upload()"
		                     )
	# FTP or SFTP ?
	sftp_in_use = gui_common.get_sftp_usage( this_ip_address = this_address)
	# Be carreful when transmiting one file
	if os.path.isfile(this_src_path) is True:
		# Extract remote parameters (UNIX path format...)
		path_list = this_dst_path.replace(os.sep,_ftp_posix_separator).split(_ftp_posix_separator)
		user_remote_dir = _ftp_posix_separator.join(path_list[:-1])
		# One file , one upload needed
		max_expected_connections_number = 1
	else:
		# The dst path is a POSIX directory
		user_remote_dir = this_dst_path.replace(os.sep,_ftp_posix_separator)
		if this_max_connection is None:
			max_expected_connections_number = _ftp_get_max_connection( this_address = this_address)
		else:
			max_expected_connections_number = this_max_connection
	# Open FTP connections
	ftp_cnx_info_list = _ftp_open_many_connection( this_address = this_address
	                                             , this_login = this_login
	                                             , this_password = this_password
	                                             , this_timeout = this_timeout
	                                             , this_upload = True
	                                             , this_user_remote_dir = this_dst_path
	                                             , this_max_connection =  max_expected_connections_number
	                                             , this_debug_mode = this_debug_mode
	                                             , this_nickname = this_nickname
	                                             , this_check_size = this_check_size
	                                             , this_use_sftp = sftp_in_use
	                                             )
	if ftp_cnx_info_list == []:
		# No open connection on this server
		return False
	# Use the first connection to obtain file names. It will be closed by the slave thread.
	(file_manager_id, ftp_id, _ftp_thread_id) = ftp_cnx_info_list[0]
	err_msg = None
	# Go on
	src_directory_with_wildcard = '*' in this_src_path
	if this_dst_path is None:
		# Use the default one
		this_dst_path = _ftp_thread_id.user_remote_dir
	# This_dst_path may be as well as a file or a directory name.
	if src_directory_with_wildcard is True:
		# A wildcard has been given, Take the remote path as is !
		# Multiple targets
		target_list = glob.glob(this_src_path)
	else:
		# No Wildcard: only one target
		target_list = [this_src_path,]
	# Avoid to have // directory inside recursive_build_upload_list() function
	if user_remote_dir == _ftp_posix_separator:
		user_remote_dir = ""
	# Check if the remote base directory exists or not
	if src_directory_with_wildcard is True:
		src_initial_path = this_src_path.split("*")[0]
	else:
		src_initial_path = this_src_path
	# Run my hen !
	for target_file in target_list:
		if recursive_build_upload_list( this_src_path = target_file
		                              , this_dst_path = user_remote_dir
		                              , this_unwanted_tag_list = this_unwanted_tag_list
		                              ) is not True:
			_ftp_close_connection_list( this_list = ftp_cnx_info_list)
			del ftp_cnx_info_list
			gui_common.garbage_collector_start()
			return False
		# Next target_file
		continue
	# Start the file transferts now !
	for ftp_cnx_info in ftp_cnx_info_list:
		(file_manager_idx, ftp_idx, ftp_thread_idx) = ftp_cnx_info
		ftp_thread_idx.start()
		# Next ftp_cnx_info
		continue
	# Wait end of transfert
	for ftp_cnx_info in ftp_cnx_info_list:
		(file_manager_idx, ftp_idx, ftp_thread_idx) = ftp_cnx_info
		ftp_thread_idx.join()
		# Next ftp_cnx_info
		continue
	# Check if the transfert has been done correctly
	remaining_file_list = file_manager_id.get_running_list(this_name_only = True)
	result = (remaining_file_list == [])
	if result is False:
		# Some files have not been transfered
		subject = "%s Some files have not been uploaded to %s"%( gui_common.ftp_upload_marker
		                                                       , this_address
		                                                       )
		#
		file_list = ["Files not uploaded:\n",]
		for file_to_transfert_info in remaining_file_list:
			try:
				(full_src_file, full_dest_file, file_size) = file_to_transfert_info
			except:
				dummy = "<<>> "+str(file_to_transfert_info)
			else:
				dummy = "full_src_file: %s\nfull_dest_file: %s\nfile_size: %d\n"%file_to_transfert_info
			file_list.append(dummy)
			continue
		gui_common.send_mail( this_subject = subject
		                    , this_content = gui_common.char_line_feed.join(file_list)
		                    , this_receiver_email_addr = gui_common.administrator_email
		                    )
	# Done
	_ftp_close_connection_list( this_list = ftp_cnx_info_list)
	del ftp_cnx_info_list
	gui_common.garbage_collector_start()
	return result

# --------------------------------
# Function : ftp_parallel_upload()
# --------------------------------
def ftp_parallel_upload( this_address_list  = []
                       , this_login    = "dummy_login"
                       , this_password = "dummy_par_up_password"
                       , this_timeout  = gui_common.ftp_timeout_s
                       , this_src_path = None
                       , this_dst_path = None
                       , this_cleanup_flag = False
                       , this_debug_mode = False
                       ):
	"""
	Upload FTP simultaneously on miscellaneous remote servers.
	@param this_address_list: list of remote address
	@type this_address_list: list
	@param this_login: remote user login
	@type this_login: ascii
	@param this_password: remote user password
	@type this_password: ascii
	@param this_timeout: timeout in seconds for blocking operations like the connection attempt
	@type this_timeout: real
	@param this_src_path: local source directory
	@type this_src_path: ascii string
	@param this_dst_path: server destination directory
	@type this_dst_path: ascii string
	@param this_cleanup_flag: force to clean up the destination directory (True) or not (False)
	@type this_cleanup_flag: boolean
	@param this_debug_mode: current debug mode
	@type this_debug_mode: boolean
	@return: updated server list without any error
	@rtype: list
	"""
	if isinstance(this_dst_path,(str,unicode)) is False:
		subject = "%s Dest path is not an ASCII string '%s'"%( gui_common.ftp_upload_marker
		                                                     , str(this_dst_path)
		                                                     )
		current_thread_id = threading.currentThread()
		content = "%s\n%s"%(str(current_thread_id),gui_common.get_thread_stack())
		gui_common.send_mail( this_subject = subject
		                    , this_content = content
		                    , this_receiver_email_addr = gui_common.administrator_email
		                    )
		return False
	if isinstance(this_src_path,(str,unicode)) is False:
		subject = "%s Src path is not an ASCII string '%s'"%( gui_common.ftp_upload_marker
		                                                    , str(this_src_path)
		                                                    )
		current_thread_id = threading.currentThread()
		content = "%s\n%s"%(str(current_thread_id),gui_common.get_thread_stack())
		gui_common.send_mail( this_subject = subject
		                    , this_content = content
		                    , this_receiver_email_addr = gui_common.administrator_email
		                    )
		return False
	updated_server_list = []
	son_id_list = []
	ip_address = gui_common.get_ip_address()
	for host_address in this_address_list:
		if host_address != ip_address:
			# Update this server
			son_name = "FTP_Upload_"+host_address
			son_id = _ftp_thread( this_address  = host_address
			                    , this_login    = this_login
			                    , this_password = this_password
			                    , this_timeout  = this_timeout
			                    , this_src_path = this_src_path
			                    , this_dst_path = this_dst_path
			                    , this_direction= _upload_cmd
			                    , this_cleanup_flag = this_cleanup_flag
			                    , this_debug_mode = this_debug_mode
			                    )
			son_id_list.append(son_id)
			son_id.setName(son_name)
			son_id.start()
		# Next host_address
		continue
	# Wait the end of my sons
	for son_id in son_id_list:
		son_id.join()
		if son_id.result is True:
			updated_server_list.append(son_id.address)
		# Next son_id
		continue
	# Done
	del son_id_list
	gui_common.garbage_collector_start()
	return updated_server_list

# ----------------------------------
# Function : ftp_parallel_download()
# ----------------------------------
def ftp_parallel_download( this_address_list  = []
                         , this_login    = "dummy_login"
                         , this_password = "dummy_par_down_password"
                         , this_timeout = gui_common.ftp_timeout_s
                         , this_src_path = None
                         , this_dst_path = None
                         , this_debug_mode = False
                         ):
	"""
	Download FTP simultaneously from miscellaneous remote servers.
	@param this_address_list: list of remote address
	@type this_address_list: list
	@param this_login: remote user login
	@type this_login: ascii
	@param this_password: remote user password
	@type this_password: ascii
	@param this_timeout: timeout in seconds for blocking operations like the connection attempt
	@type this_timeout: real
	@param this_src_path: local source directory
	@type this_src_path: ascii string
	@param this_dst_path: server destination directory
	@type this_dst_path: ascii string
	@param this_debug_mode: current debug mode
	@type this_debug_mode: boolean
	@return: downloaded server list without any error
	@rtype: list
	"""
	downloaded_server_list,son_id_list = [],[]
	ip_address = gui_common.get_ip_address()
	for host_address in this_address_list:
		if host_address != ip_address:
			# Download from this server
			son_name = "FTP_Download_"+host_address
			son_id = _ftp_thread( this_address  = host_address
			                    , this_login    = this_login
			                    , this_password = this_password
			                    , this_timeout  = this_timeout
			                    , this_src_path = this_src_path
			                    , this_dst_path = this_dst_path
			                    , this_direction= _download_cmd
			                    , this_cleanup_flag = False
			                    , this_debug_mode = this_debug_mode
			                    )
			son_id_list.append(son_id)
			son_id.setName(son_name)
			son_id.start()
		# Next host_address
		continue
	# Wait the end of my sons
	for son_id in son_id_list:
		son_id.join()
		if son_id.result is True:
			downloaded_server_list.append(son_id.address)
		# Next son_id
		continue
	del son_id_list
	gui_common.garbage_collector_start()
	return downloaded_server_list

# ----------------------------------------------------
# If the module is run alone (i.e. for debug) : Main()
# ----------------------------------------------------
if __name__ == '__main__':
	#
	# Unitary Test
	#
	# --------------------------------
	# SFTP upload error ON server side
	# previous upload Ok
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> TYPE I
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> 200 Type set to I
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> PASV
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> 227 Entering Passive Mode (135,120,162,6,213,254)
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> STOR Introduction_PUCch_F2_Model.tex
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> 150 Opening data channel for file upload to server of "/Introduction_PUCch_F2_Model.tex"
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> SSL connection for data connection established
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> 226 Successfully transferred "/Introduction_PUCch_F2_Model.tex"
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> SIZE Introduction_PUCch_F2_Model.tex
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> 213 3155
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> TYPE I
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> 200 Type set to I
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> PASV
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> 227 Entering Passive Mode (135,120,162,6,236,58)
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> STOR Introduction_PUCch_F1_Model.tex
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> 150 Opening data channel for file upload to server of "/Introduction_PUCch_F1_Model.tex"
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> SSL connection for data connection established
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> 226 Successfully transferred "/Introduction_PUCch_F1_Model.tex"
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> SIZE Introduction_PUCch_F1_Model.tex
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> 213 3148
	# until here, it's ok ! Same player shoots again...
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> TYPE I
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> 200 Type set to I
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> PASV
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> 227 Entering Passive Mode (135,120,162,6,200,16)
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> STOR Handle.exe
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> 150 Opening data channel for file upload to server of "/Handle.exe"
	# the problem is comming...
	#	(000336)30/09/2015 08:56:59 - nemo_pyc (135.238.179.15)> 550 can't access file.  <<<<<< Instead of: "SSL connection for data connection established"
	#	(000336)30/09/2015 08:57:29 - nemo_pyc (135.238.179.15)> TYPE I
	#	(000336)30/09/2015 08:57:29 - nemo_pyc (135.238.179.15)> 200 Type set to I
	#	(000336)30/09/2015 08:57:59 - nemo_pyc (135.238.179.15)>  ?3DG?}
	#	(000336)30/09/2015 08:58:04 - nemo_pyc (135.238.179.15)> 'Y'jQ?~.
	#	?0??? ?3DG?~
	#	(000336)30/09/2015 08:58:04 - nemo_pyc (135.238.179.15)> 500 Syntax error, command unrecognized.
	#	(000336)30/09/2015 08:58:09 - nemo_pyc (135.238.179.15)> ???!x?d???A?:?\ ?3DG?
	#	(000336)30/09/2015 08:58:09 - nemo_pyc (135.238.179.15)> 500 Syntax error, command unrecognized.
	#	(000336)30/09/2015 08:58:09 - nemo_pyc (135.238.179.15)> ?L.?_8;
	#	(000336)30/09/2015 08:58:09 - nemo_pyc (135.238.179.15)> 500 Syntax error, command unrecognized.
	#	(000336)30/09/2015 08:58:09 - nemo_pyc (135.238.179.15)> P??zR??
	#	(000336)30/09/2015 08:58:09 - nemo_pyc (135.238.179.15)> 500 Syntax error, command unrecognized.
	#	(000336)30/09/2015 08:58:14 - nemo_pyc (135.238.179.15)>  ?3DG??
	#	(000336)30/09/2015 08:58:18 - nemo_pyc (135.238.179.15)> ?????_?S?
?Y?S? ?3DG??
	#	(000336)30/09/2015 08:58:18 - nemo_pyc (135.238.179.15)> 500 Syntax error, command unrecognized.
	#	(000336)30/09/2015 08:58:23 - nemo_pyc (135.238.179.15)> l	8]???kj?????? ?3DG??
	#	(000336)30/09/2015 08:58:23 - nemo_pyc (135.238.179.15)> 500 Syntax error, command unrecognized.
	#	(000336)30/09/2015 08:58:27 - nemo_pyc (135.238.179.15)> ??X?#???Vb]$??? ?3DG??
	#	(000336)30/09/2015 08:58:27 - nemo_pyc (135.238.179.15)> 500 Syntax error, command unrecognized.
	#	(000336)30/09/2015 08:58:32 - nemo_pyc (135.238.179.15)> ??^b?VY?????"?7 ?3DG??
	#	(000336)30/09/2015 08:58:32 - nemo_pyc (135.238.179.15)> 500 Syntax error, command unrecognized.
	#	(000336)30/09/2015 08:58:37 - nemo_pyc (135.238.179.15)> nBgI?? 'Im&FP ?3DG??
	#	(000336)30/09/2015 08:58:37 - nemo_pyc (135.238.179.15)> 500 Syntax error, command unrecognized.
	#	(000336)30/09/2015 08:58:41 - nemo_pyc (135.238.179.15)> ?O??rm??Z?Q?}? ?3DG??
	#	(000336)30/09/2015 08:58:41 - nemo_pyc (135.238.179.15)> 500 Syntax error, command unrecognized.
	#	(000336)30/09/2015 08:58:41 - nemo_pyc (135.238.179.15)> +?Y|?????AIw
	#	(000336)30/09/2015 08:58:41 - nemo_pyc (135.238.179.15)> 500 Syntax error, command unrecognized.
	# --------------------------------
	# SFTP upload OK ON Client side
	# 	+--- 135.238.179.15 - Wed Sep 30 09:07:27 2015 - FRVILN0H300423
	# | Process : <_MainProcess(MainProcess, started)>
	# | Thread  : <_ftp_slave_thread(FTP_135.120.162.9_Upload_1, started 3752)>
	# | File    : gui_ftp.py
	# | Comment : <<>> C:\Nemo_Pyc\Handle.exe --> nemo_tmp/dst_dir/Nemo_Pyc/Handle.exe
	# +---
	# *cmd* 'TYPE I'
	# *resp* '200 Type set to I'
	# *cmd* 'PASV'
	# *resp* '227 Entering Passive Mode (135,120,162,9,226,12)'
	# *cmd* 'STOR Handle.exe'
	# *resp* '150 Opening data channel for file upload to server of "/nemo_tmp/dst_dir/Nemo_Pyc/Handle.exe"'
	# *resp* '226 Successfully transferred "/nemo_tmp/dst_dir/Nemo_Pyc/Handle.exe"'
	# *cmd* 'SIZE Handle.exe'
	# *resp* '213 536256'
	# ----------------------------------
	def test_ftp_upload():
		user_conf = gui_user.configuration()
		user_conf.debug_mode = False
		test_dst_dir = "Nemo_Tmp/up"
		if gui_common.get_ip_address() == user_conf.get_selected_dispatcher():
			# Test dispatcher - labo
			remote_ip = "135.120.162.1"
			src_dir = "C:\\Nemo_Tmp\\up"
			# Send one dir
			print "=== ftp_upload: to %s ==="%(remote_ip)
			ftp_upload( this_address    = remote_ip
			          , this_login      = gui_common.main_login
			          , this_password   = gui_common.main_passwd_default
			          , this_timeout    = gui_common.ftp_timeout_s
			          , this_src_path   = src_dir
			          , this_dst_path   = test_dst_dir
			          , this_debug_mode = user_conf.debug_mode
			          )
			print "=== ftp_upload: one dir/* to %s ==="%(remote_ip)
			dir_name = src_dir+os.sep+"*"
			ftp_upload( this_address    = remote_ip
			          , this_login      = gui_common.main_login
			          , this_password   = gui_common.main_passwd_default
			          , this_timeout    = gui_common.ftp_timeout_s
			          , this_src_path   = dir_name
			          , this_dst_path   = test_dst_dir
			          , this_debug_mode = user_conf.debug_mode
			          )
		else:
			# Test laptop - labo
			server_list = [ "135.120.162.1"
			              , "135.120.162.2"
			              , "135.120.162.3"
			              , "135.120.162.4"
			              , "135.120.162.5"
			              , "135.120.162.6"
			              , "135.120.162.7"
			              , "135.120.162.8"
			              , "135.120.162.9"
			              ]
			remote_ip = user_conf.get_selected_dispatcher()
			src_dir = "C:\\Nemo_Tests\\BLANQUI1.3\\Nemo2\\python\\sce"
			# Send in parallel
			print "=== ftp_parallel_upload: %s to servers ==="%(src_dir)
			ftp_parallel_upload( this_address_list  = server_list
			                   , this_login    = gui_common.main_login
			                   , this_password = gui_common.main_passwd_new
			                   , this_timeout  = gui_common.ftp_timeout_s
			                   , this_src_path = src_dir
			                   , this_dst_path = test_dst_dir
			                   , this_cleanup_flag = True
			                   , this_debug_mode = False
			                   )
			# Send some directories
			print "=== ftp_upload: %s/* to %s ==="%(src_dir, remote_ip)
			ftp_upload( this_address    = remote_ip
			          , this_login      = gui_common.main_login
			          , this_password   = gui_common.main_passwd_default
			          , this_timeout    = gui_common.ftp_timeout_s
			          , this_src_path   = src_dir+os.sep+"*"
			          , this_dst_path   = test_dst_dir
			          , this_debug_mode = user_conf.debug_mode
			          )
			# Send one file
			file_name = user_conf.ftp_pyc_directory+os.sep+"gui_ftp.pyc"
			print "=== ftp_upload: %s to %s ==="%(file_name,remote_ip)
			ftp_upload( this_address    = remote_ip
			          , this_login      = gui_common.main_login
			          , this_password   = gui_common.main_passwd_default
			          , this_timeout    = gui_common.ftp_timeout_s
			          , this_src_path   = file_name
			          , this_dst_path   = test_dst_dir
			          , this_debug_mode = user_conf.debug_mode
			          )
			# Send one dir
			dir_name = user_conf.ftp_pyc_directory+os.sep+"*"
			print "=== ftp_upload: one dir to %s ==="%(remote_ip)
			ftp_upload( this_address    = remote_ip
			          , this_login      = gui_common.main_login
			          , this_password   = gui_common.main_passwd_default
			          , this_timeout    = gui_common.ftp_timeout_s
			          , this_src_path   = dir_name
			          , this_dst_path   = test_dst_dir
			          , this_debug_mode = user_conf.debug_mode
			          )
		return
	# ----------------------------------
	def test_ftp_download():
		# Download test
		user_conf = gui_user.configuration()
		user_conf.debug_mode = False
		user_remote_dir = "BLANQUI1.3"
		if gui_common.get_ip_address() == user_conf.get_selected_dispatcher():
			# Test dispatcher - labo
			remote_ip = "135.120.162.1"
			src_dir = "Nemo_Tmp\\up"
			dest_dir = "c:\\Nemo_Tmp\\up1"
			try:
				os.mkdir(dest_dir)
			except:
				pass
			print "=== ftp_download ==="
			ftp_download( this_address  = dest_ip_addr
			            , this_login    = user_conf.ftp_login
			            , this_password = user_conf.ftp_password
			            , this_timeout  = gui_common.ftp_timeout_s
			            , this_src_path = user_remote_dir
			            , this_dst_path = dest_dir
			            , this_debug_mode = user_conf.debug_mode
			            )
		else:
			# Test laptop - labo
			dest_dir = "Z:"+os.sep+"ftp_down"
			dest_ip_addr = user_conf.get_selected_dispatcher()
			if os.path.exists(dest_dir) is True:
				if gui_common.remove_directory( this_target = dest_dir) is not True:
					print "ERROR"
			print "=== ftp_parallel_download ==="
			server_list = [ "135.120.162.1"
			              , "135.120.162.2"
			              , "135.120.162.3"
			              , "135.120.162.4"
			              , "135.120.162.5"
			              , "135.120.162.6"
			              , "135.120.162.7"
			              , "135.120.162.8"
			              , "135.120.162.9"
			              ]
			ftp_parallel_download( this_address_list  = server_list
			                     , this_login    = gui_common.main_login
			                     , this_password = gui_common.main_passwd_new
			                     , this_timeout  = gui_common.ftp_timeout_s
			                     , this_src_path = user_remote_dir
			                     , this_dst_path = dest_dir
			                     , this_debug_mode = False
			                     )
			print "=== ftp_download ==="
			ftp_download( this_address  = dest_ip_addr
			            , this_login    = user_conf.ftp_login
			            , this_password = user_conf.ftp_password
			            , this_timeout  = gui_common.ftp_timeout_s
			            , this_src_path = user_remote_dir
			            , this_dst_path = dest_dir
			            , this_debug_mode = user_conf.debug_mode
			            )
		return
	# ----------------------------------
	def test_system_info():
		dest_dir= "D:\\dummy\\Logs"
		user_conf = gui_user.configuration()
		user_conf.debug_mode = False
		ip_address = user_conf.get_selected_dispatcher()
		ftp_cnx_info_list = _ftp_open_many_connection( this_address = ip_address
		                                             , this_login = gui_common.main_login
		                                             , this_password = gui_common.main_passwd_default
		                                             , this_timeout = 10.0
		                                             , this_upload = False
		                                             , this_user_remote_dir = None
		                                             , this_max_connection =  1
		                                             , this_check_size = False
		                                             , this_use_sftp = gui_common.get_sftp_usage( this_ip_address = ip_address)
		                                             )
		(file_manager_id, ftp_id, _ftp_thread_id) = ftp_cnx_info_list[0]
		# Get remote server info (Filezilla Server)
		answer = _ftp_get_server_info( this_ftp_id = ftp_id)
		(system_info, feature_list) = answer
		print "System :" + system_info
		print "Feature:"
		for feature_idx in feature_list:
			print "  "+feature_idx
			continue
		# Get detailed remote directory info (Filezilla Server)
		answer = _ftp_get_directory_detail( this_ftp_id = ftp_id
		                                  , this_dir = "Nemo_Tests"
		                                  )
		for idx in answer:
			(directory_flag, size, year, month, date, hour_minute, file) = idx
			msg = "%s %8d %d.%s.%02d.%s %s"%idx
			print msg
			continue
		_ftp_close_connection( this_ftp_id = ftp_id)
		return
	# ----------------------------------
	def test_sftp_download( this_address = "135.120.162.9"
	                      , this_login = gui_common.main_login
	                      , this_password = gui_common.main_passwd_default
	                      , this_timeout = 6000.0 # 100 mn for debugging !
	                      ):
		ftp_download( this_address  = this_address
		            , this_login    = gui_common.main_login
		            , this_password = gui_common.main_passwd_default
		            , this_timeout = this_timeout
		            , this_src_path = "nemo_pyc"
		            , this_dst_path = gui_common.nemo_all_result_directory
		            , this_check_size = True
		            , this_max_connection = None
		            , this_debug_mode = False # True
		            )
		return
	# ----------------------------------
	def test_sftp_upload( this_address = "135.120.162.9"
	                    , this_login = gui_common.main_login
	                    , this_password = gui_common.main_passwd_default
	                    , this_timeout = 6000.0 # 100 mn for debugging !
	                    ):
		src_dir = "D:\\z_Code\\NEMO2_2015_03_24_EXTENDEDCP_UPDATES_3062\\main\\Automatic_Launcher"
		src_dir = "C:\\Nemo_Pyc"
		ftp_upload( this_address  = this_address
		          , this_login    = gui_common.main_login
		          , this_password = gui_common.main_passwd_default
		          , this_timeout = this_timeout
		          , this_src_path = src_dir
		          , this_dst_path = "nemo_tmp\\dst_dir"
		          , this_check_size = True
		          , this_max_connection = None
		          , this_debug_mode = False # True
		          )
		return
	# ----------------------------------
	start_time = time.time()
	test_sftp_upload()
	#test_sftp_download()
	#test_ftp_upload()
	#test_ftp_download()
	#test_system_info()
	msg = " elapsed time: %s"%(gui_common.elapsed_time_ascii( this_start_time = start_time))
	gui_common.wait_CR_pressed( this_message = msg)
	#improve_software_pref()

From report at bugs.python.org  Wed Sep 30 21:17:07 2015
From: report at bugs.python.org (Remi Pointel)
Date: Wed, 30 Sep 2015 19:17:07 +0000
Subject: [issue25171] does not build on OpenBSD with no value defined for
 PY_GETENTROPY
In-Reply-To: <1442618175.28.0.599214895418.issue25171@psf.upfronthosting.co.za>
Message-ID: <1443640627.69.0.374506111344.issue25171@psf.upfronthosting.co.za>


Remi Pointel added the comment:

Attached is the diff to use defined(PY_GETENTROPY) instead of #define PY_GETENTROPY 1.

----------
Added file: http://bugs.python.org/file40631/Python_random_c

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 22:08:05 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 30 Sep 2015 20:08:05 +0000
Subject: [issue25171] does not build on OpenBSD with no value defined for
 PY_GETENTROPY
In-Reply-To: <1442618175.28.0.599214895418.issue25171@psf.upfronthosting.co.za>
Message-ID: <20150930200757.16569.96960@psf.io>


Roundup Robot added the comment:

New changeset e4ac5a899657 by Victor Stinner in branch 'default':
Issue #25171: Fix compilation issue on OpenBSD in random.c
https://hg.python.org/cpython/rev/e4ac5a899657

----------
nosy: +python-dev

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 22:20:57 2015
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 30 Sep 2015 20:20:57 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1443644457.85.0.816879539384.issue18967@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I don't agree that in all cases the Misc/NEWS entry and the checkin comment must be wholly different.  While I concur that that's called for now and again, I believe this to be rare.  Most checkins are small changes, and a single-line summary for both Misc/NEWS and the first line of the checkin comment will suffice.

However, clearly the tool should *support* making them wholly separate.  But that's easy to support.  pyci now supports a "-n" or "--newsonly" flag, which instructs it to only add the Misc/NEWS item and to not check in.  This is presumably also nicer for folks used to shell-integrated hg tools (TortoiseHG etc).

I think it's important that this *not* be the default behavior, as it's going to be hard enough to get the core dev community to adopt this tool, and I would prefer it make the experience nicer rather than clunkier.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 22:26:47 2015
From: report at bugs.python.org (Andrej A Antonov)
Date: Wed, 30 Sep 2015 20:26:47 +0000
Subject: [issue24755] asyncio.wrap_future undocumented
In-Reply-To: <1438250618.09.0.00442439827356.issue24755@psf.upfronthosting.co.za>
Message-ID: <1443644807.09.0.967756437618.issue24755@psf.upfronthosting.co.za>


Changes by Andrej A Antonov :


----------
nosy: +polymorphm

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 22:33:57 2015
From: report at bugs.python.org (Yaroslav Admin)
Date: Wed, 30 Sep 2015 20:33:57 +0000
Subject: [issue25284] Docs for BaseEventLoop.run_in_executor(executor, callback,
 *args) is outdated in documentation
Message-ID: <1443645237.96.0.144397118323.issue25284@psf.upfronthosting.co.za>


New submission from Yaroslav Admin:

Parameter for BaseEventLoop.run_in_executor(executor, callback, *args) was renamed from callback to func in 3.5.0 release, but it's not reflected in the docs.

Commit with change: https://github.com/python/cpython/commit/111610562141a46f1eaac64d497d79fe13290847#diff-08afa52ab2b1511bee8527814ad44d80L468
Documentation: https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.BaseEventLoop.run_in_executor

----------
components: asyncio
messages: 251961
nosy: Yaroslav Admin, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Docs for BaseEventLoop.run_in_executor(executor, callback, *args) is outdated in documentation
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 22:35:02 2015
From: report at bugs.python.org (Yaroslav Admin)
Date: Wed, 30 Sep 2015 20:35:02 +0000
Subject: [issue25284] Spec for BaseEventLoop.run_in_executor(executor, callback,
 *args) is outdated in documentation
In-Reply-To: <1443645237.96.0.144397118323.issue25284@psf.upfronthosting.co.za>
Message-ID: <1443645302.16.0.487730148893.issue25284@psf.upfronthosting.co.za>


Changes by Yaroslav Admin :


----------
title: Docs for BaseEventLoop.run_in_executor(executor, callback, *args) is outdated in documentation -> Spec for BaseEventLoop.run_in_executor(executor, callback, *args) is outdated in documentation

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 22:36:02 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Sep 2015 20:36:02 +0000
Subject: [issue25285] regrtest: run tests in subprocesses with -j1 on buildbots
Message-ID: <1443645362.81.0.234212686686.issue25285@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Currently, regrtest ignores the -j1 parameter. For -jN, the multiprocess mode is only enabled for N != 1. I propose to modify regrtest to run tests in subprocesses when -j1 is used. It would solve the issue #18906.

I also want to run tests in subprocesses in buildbot to better isolate tests. Running all tests in the same process, sequentially, cause various issues:

* various kinds of side effects
* memory leaks
* random failures (unreliable tests)

"make buildbot" already runs regrtest with -j1. I propose to also modify Tools/buildbot/test.bat to use run tests with -j1 by default on Windows.

I fixed regrtest to setup tests using the same code for classic mode and multiprocess mode: slaves (child processes running tests for regrtest -jN) now inherit
--memlimit/-M, --threshold/-t and --nowindows/-n options.

Only 3 remaining functions are incompatible with -jN: --coverage/-T and --findleaks/-l.

Finally, the multiprocess mode of regrtest now displays the duration of tests which took longer than 30 seconds, and every minute, it displays the tests running since longer than 30 seconds. Example with multiple workers (-j4):
---
...
[395/399/1] test_mimetypes -- running: test_lzma (111 sec), test_multiprocessing_forkserver (224 sec)
[396/399/1] test_poplib -- running: test_lzma (111 sec), test_multiprocessing_forkserver (225 sec)
[397/399/1] test_lzma (111 sec) -- running: test_multiprocessing_forkserver (225 sec)
[398/399/1] test_range -- running: test_multiprocessing_forkserver (227 sec)
running: test_multiprocessing_forkserver (287 sec)
[399/399/1] test_multiprocessing_forkserver (340 sec)
378 tests OK.
---

Note: "python -m test -j1 -j4" uses 4 workers, only the last -jN parameter is used. Some buildbots add -jN to use more workers.

----------
components: Tests
messages: 251962
nosy: haypo
priority: normal
severity: normal
status: open
title: regrtest: run tests in subprocesses with -j1 on buildbots
versions: Python 3.6

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 22:36:29 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Sep 2015 20:36:29 +0000
Subject: [issue25285] regrtest: run tests in subprocesses with -j1 on buildbots
In-Reply-To: <1443645362.81.0.234212686686.issue25285@psf.upfronthosting.co.za>
Message-ID: <1443645389.53.0.192783281646.issue25285@psf.upfronthosting.co.za>


Changes by STINNER Victor :


----------
keywords: +patch
Added file: http://bugs.python.org/file40632/regrtest_run_in_subprocess.patch

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 22:39:05 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Sep 2015 20:39:05 +0000
Subject: [issue18906] Create a way to always run tests in subprocesses within
 regrtest
In-Reply-To: <1378142237.02.0.163660197957.issue18906@psf.upfronthosting.co.za>
Message-ID: <1443645545.07.0.291603273611.issue18906@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I created the issue #25285: "regrtest: run tests in subprocesses with -j1 on buildbots".

----------
nosy: +haypo

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 22:40:57 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Sep 2015 20:40:57 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1443645657.67.0.459730013921.issue18967@psf.upfronthosting.co.za>


R. David Murray added the comment:

I never said they always had to be different, and "wholly different" is certainly not the case, nor do I think I implied that.

So if your tool supports my scenario that's all I'm asking for :)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 22:45:10 2015
From: report at bugs.python.org (Shreevatsa R)
Date: Wed, 30 Sep 2015 20:45:10 +0000
Subject: [issue25275] Documentation v/s behaviour mismatch wrt integer
 literals containing non-ASCII characters
In-Reply-To: <1443590385.97.0.810723896221.issue25275@psf.upfronthosting.co.za>
Message-ID: <1443645910.44.0.490510591942.issue25275@psf.upfronthosting.co.za>


Shreevatsa R added the comment:

Minor difference, but the relevant function for int() is not quite isdigit(), e.g.:

    >>> import unicodedata
    >>> s = u'\u2460'
    >>> unicodedata.name(s)
    'CIRCLED DIGIT ONE'
    >>> print s
    ?
    >>> s.isdigit()
    True
    >>> s.isdecimal()
    False
    >>> int(s)
    Traceback (most recent call last):
      File "", line 1, in 
    UnicodeEncodeError: 'decimal' codec can't encode character u'\u2460' in position 0: invalid decimal Unicode string

It seems to be isdecimal(), plus if there are other digits in the string then many leading and trailing space-like characters are also allowed (e.g. 5760 OGHAM SPACE MARK or 8195 EM SPACE or 12288 IDEOGRAPHIC SPACE:

    >>> 987 == int(u'\u3000\n 987\u1680\t')
    True

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 22:48:47 2015
From: report at bugs.python.org (Shreevatsa R)
Date: Wed, 30 Sep 2015 20:48:47 +0000
Subject: [issue25275] Documentation v/s behaviour mismatch wrt integer
 literals containing non-ASCII characters
In-Reply-To: <1443590385.97.0.810723896221.issue25275@psf.upfronthosting.co.za>
Message-ID: <1443646127.83.0.989131166378.issue25275@psf.upfronthosting.co.za>


Shreevatsa R added the comment:

About the mismatch: of course it's probably not a good idea to change the parser (so that simply typing ???? in Python 3 code is like typing 1234), but how about changing the behaviour of int()? Not sure whether anyone should be relying on int(u'????') being 1234, given that it is not documented as such.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 22:54:42 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Sep 2015 20:54:42 +0000
Subject: [issue25275] Documentation v/s behaviour mismatch wrt integer
 literals containing non-ASCII characters
In-Reply-To: <1443590385.97.0.810723896221.issue25275@psf.upfronthosting.co.za>
Message-ID: <1443646482.81.0.18638309334.issue25275@psf.upfronthosting.co.za>


R. David Murray added the comment:

Good catch.  Yes, it is already documented that Int ignores leading and trailing whitespace.

But, even that isn't quite correct:

>>> 'A'.isdecimal()
False
>>> int('A', 16)
10

I seem to vaguely recall a discussion somewhere in this tracker about what "should" count as digits for larger-than-decimal radii, but I don't remember the outcome.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 22:56:09 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Sep 2015 20:56:09 +0000
Subject: [issue25275] Documentation v/s behaviour mismatch wrt integer
 literals containing non-ASCII characters
In-Reply-To: <1443590385.97.0.810723896221.issue25275@psf.upfronthosting.co.za>
Message-ID: <1443646569.3.0.183483292613.issue25275@psf.upfronthosting.co.za>


R. David Murray added the comment:

No, we can't make it stop working for int, that would be a backward compatibility break.  Doing so was discussed at one point and rejected (another issue somewhere in this tracker :)

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 22:57:21 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Sep 2015 20:57:21 +0000
Subject: [issue18967] Find a less conflict prone approach to Misc/NEWS
In-Reply-To: <1378605881.29.0.990351353386.issue18967@psf.upfronthosting.co.za>
Message-ID: <1443646641.82.0.359620990166.issue18967@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I sometimes put a bit more info in the commit message, but it's true that generally it's a copy/paste job as far as I'm concerned.

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 22:57:45 2015
From: report at bugs.python.org (Marc Paul Rubin)
Date: Wed, 30 Sep 2015 20:57:45 +0000
Subject: [issue24820] IDLE themes for light on dark
In-Reply-To: <1438923257.49.0.103520260228.issue24820@psf.upfronthosting.co.za>
Message-ID: <1443646665.55.0.138375342918.issue24820@psf.upfronthosting.co.za>


Marc Paul Rubin added the comment:

Greetings from an idle-dev 'lurker.' Has anyone tested the new dark
theme with a Set Breakpoint command? The dark theme is great for me
except for this quirk: breakpoints are invisible on my test box. Under
the Classic light scheme breakpoints appear on a bright yellow 
background. 
 
Appreciate all the interest and work going into idle these days. I'll
add any needed details on request. For starters I'm just wondering
whether breakpoints have yet to be tested with this dark theme.
 
Thanks, 
jayseye (Marc Paul Rubin)

----------
nosy: +jayseye

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 23:15:22 2015
From: report at bugs.python.org (Nicholas Chammas)
Date: Wed, 30 Sep 2015 21:15:22 +0000
Subject: [issue25284] Spec for BaseEventLoop.run_in_executor(executor, callback,
 *args) is outdated in documentation
In-Reply-To: <1443645237.96.0.144397118323.issue25284@psf.upfronthosting.co.za>
Message-ID: <1443647722.13.0.493512384889.issue25284@psf.upfronthosting.co.za>


Changes by Nicholas Chammas :


----------
nosy: +Nicholas Chammas

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 23:15:44 2015
From: report at bugs.python.org (Matt Hickford)
Date: Wed, 30 Sep 2015 21:15:44 +0000
Subject: [issue25251] Unknown MS Compiler version 1900
In-Reply-To: <1443392264.43.0.443478210283.issue25251@psf.upfronthosting.co.za>
Message-ID: <1443647744.89.0.488480102452.issue25251@psf.upfronthosting.co.za>


Matt Hickford added the comment:

I'm not sure what the correct analogue of msvcr100 is for Visual C++ 14.0. "msvcr140.dll no longer exists" http://blogs.msdn.com/b/vcblog/archive/2014/06/03/visual-studio-14-ctp.aspx

        elif msc_ver == '1600':
             # VS2010 / MSVC 10.0
             return ['msvcr100']
        elif msc_ver == '1900':

----------

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 23:17:48 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 30 Sep 2015 21:17:48 +0000
Subject: [issue25284] Spec for BaseEventLoop.run_in_executor(executor, callback,
 *args) is outdated in documentation
In-Reply-To: <1443645237.96.0.144397118323.issue25284@psf.upfronthosting.co.za>
Message-ID: <1443647868.49.0.00721609103051.issue25284@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Someone please submit a patch...

----------
assignee:  -> docs at python
components: +Documentation -asyncio
keywords: +easy
nosy: +docs at python

_______________________________________
Python tracker 

_______________________________________

From report at bugs.python.org  Wed Sep 30 23:57:22 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 30 Sep 2015 21:57:22 +0000
Subject: [issue25251] Unknown MS Compiler version 1900
In-Reply-To: <1443392264.43.0.443478210283.issue25251@psf.upfronthosting.co.za>
Message-ID: <1443650242.87.0.73914880304.issue25251@psf.upfronthosting.co.za>


Steve Dower added the comment:

There isn't one. MinGW doesn't support building with the UCRT yet, so you'll need to link to a different version of the library and hope that it works (or test/fix the extension).

----------

_______________________________________
Python tracker 

_______________________________________