From report at bugs.python.org Wed Apr 1 00:16:54 2015 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Tue, 31 Mar 2015 22:16:54 +0000 Subject: [issue21526] Support new booleans in Tkinter In-Reply-To: <1400445691.82.0.48051274053.issue21526@psf.upfronthosting.co.za> Message-ID: <1427840214.45.0.075809669165.issue21526@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Ah, the NULL case is indeed tested just above. So the current code works correctly. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 00:20:23 2015 From: report at bugs.python.org (paul j3) Date: Tue, 31 Mar 2015 22:20:23 +0000 Subject: [issue23814] argparse: Parser level defaults do not always override argument level defaults In-Reply-To: <1427740847.33.0.866518706982.issue23814@psf.upfronthosting.co.za> Message-ID: <1427840423.94.0.661205419068.issue23814@psf.upfronthosting.co.za> paul j3 added the comment: The handling of defaults is a bit complicated. Note that `set_defaults` both sets a `_defaults` attribute, and any actions with a matching `dest`. So it could change the `default` of 0, 1 or more actions. def set_defaults(self, **kwargs): self._defaults.update(kwargs) # if these defaults match any existing arguments, replace # the previous default on the object with the new one for action in self._actions: if action.dest in kwargs: action.default = kwargs[action.dest] `add_argument` gets `default` from the default parameter (kwarg), the container's `_defaults` or the parser `.argument_default`. The earliest in that list has priority. Finally, at the start of `parse_known_args`, each action's `default` is added to the namespace (IF it isn't already there), and values from `_defaults` are also add (also IF not already present). So here the priority is user supplied `namespace`, action `default`, parser `_defaults`. And finally, at the end of `_parse_known_args`, any string values in the namespace that match their action default are passed through `get_values`, which may convert them via the 'type'. I've skimmed over a couple of things: - defaults defined by the Action class (e.g. 'store_true' sets a False default) - how parent's `_defaults` are copied - when `_defaults` affects that final `get_values` action. - the relative priority of parser and subparsers _defaults (a current bug issue). So as you observed, `set_defaults` can change a previously defined argument's `default`, but it does not have priority over parameters supplied to new arguments. In my opinion, `set_default` is most useful as a way of setting Namespace values that do not have their own argument. The documentation has an example where each subparser sets its own 'func' attribute. parser_foo.set_defaults(func=foo) Maybe the documentation could be refined, though it might be tricky to do so without adding further confusion. Changing the priorities is probably not a good idea. The recent bug issues about parser and subparser `set_defaults` a cautionary tale. Even the earlier change in how 'get_values' is applied to defaults has potential pitfalls. ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 00:26:26 2015 From: report at bugs.python.org (Dan) Date: Tue, 31 Mar 2015 22:26:26 +0000 Subject: [issue23833] email.header.Header folding modifies headers that include semi-colons Message-ID: <1427840786.4.0.777280344269.issue23833@psf.upfronthosting.co.za> New submission from Dan: When adding or replacing a header with email.header.Header, folding of long lines will add a space after any semi-colon encountered in the string. Setting maxlinelen to something longer than the string (no folding required), no spaces are added after semi-colons. ---------- components: email messages: 239755 nosy: barry, dseg, r.david.murray priority: normal severity: normal status: open title: email.header.Header folding modifies headers that include semi-colons type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 00:26:42 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 31 Mar 2015 22:26:42 +0000 Subject: [issue19100] Use backslashreplace in pprint In-Reply-To: <1380279910.92.0.349060015388.issue19100@psf.upfronthosting.co.za> Message-ID: <1427840802.1.0.310263959389.issue19100@psf.upfronthosting.co.za> Martin Panter added the comment: Walter: the first line encoding with textio.errors is meant to handle the case where the output stream already has its own permissive error handler set. But anyway I was just trying to point out that it might be better to do the backslash escaping at the text level, and write the escaped text string to the original stream. Serhiy: thanks for pointing out IDLE?s stdout. It seems the encoding can be set to say ASCII by the locale, yet it still accepts non-ASCII text. But I guess that?s a separate issue. I haven?t tested the patch, but reading it, I think the there may be a couple of problems: * Newline handling will be wrong e.g. on windows, where CRLF would be expected. I am not aware of a proper way to determine the newline translation mode of a text stream in arbitrary cases. * The order of text written directly to stdout and via pprint would get messed up, because pprint would bypass the buffering in the original text stream. * For encodings that store state, such as ?utf-8-sig?, I think you may see an extra signature output, due to creating a new TextIOWrapper. With encoders whose state depends on the actual text, like the "hz" codec, multiplexing ASCII and GB2312 could be a more serious problem. Issue 15216 is slightly related, and has a patch apparently allowing the encoding and error handler to be changed on a text stream. But I guess it is no good here because you need backwards compatibility with other non-TextIOWrapper streams. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 00:33:09 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 31 Mar 2015 22:33:09 +0000 Subject: [issue19176] DeprecationWarning for doctype() method when subclassing _elementtree.XMLParser In-Reply-To: <1381041750.41.0.637077946349.issue19176@psf.upfronthosting.co.za> Message-ID: <1427841189.12.0.971104568622.issue19176@psf.upfronthosting.co.za> Berker Peksag added the comment: doctype-remove.v3.patch LGTM. ---------- nosy: +berker.peksag stage: patch review -> commit review versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 00:55:06 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 31 Mar 2015 22:55:06 +0000 Subject: [issue23834] socketmodule.c: add sock_call() to fix how the timeout is recomputed Message-ID: <1427842506.28.0.704301607448.issue23834@psf.upfronthosting.co.za> New submission from STINNER Victor: With the PEP 475, the BEGIN_SELECT_LOOP and END_SELECT_LOOP macros of Modules/socketmodule.c became complex. Moreover, they are misused to handle EINTR. Most functions currently reimplemented their own loop inside the existing "select loop", and so the timeout is not recomputed correctly. Attached patch replaces the two macros with a new sock_call() function which takes a function as a parameter. IMO, the new code (sock_xxx_impl functions) is simpler to read, understand and debug. I hate debugging code (especially in gdb) using complex macros. Copy of sock_call() documentation: /* Call a socket function. If the socket has a timeout, wait until the socket is ready before calling the function: wait until the socket is writable if writing is nonzero, wait until the socket received data otherwise. If the function is interrupted by a signal (failed with EINTR): retry the function, except if the signal handler raised an exception (PEP 475). When the function is retried, recompute the timeout using a monotonic clock. Raise an exception and return -1 on error, return 0 on success. */ I was surprised by the number of lines of code. It probably means that we are solving a non trivial problem: calling correctly socket functions with a timeout and retrying when interrupted by a signal. ---------- files: sock_call.patch keywords: patch messages: 239758 nosy: haypo, neologix, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: socketmodule.c: add sock_call() to fix how the timeout is recomputed versions: Python 3.5 Added file: http://bugs.python.org/file38769/sock_call.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 00:57:21 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 31 Mar 2015 22:57:21 +0000 Subject: [issue23834] socketmodule.c: add sock_call() to fix how the timeout is recomputed In-Reply-To: <1427842506.28.0.704301607448.issue23834@psf.upfronthosting.co.za> Message-ID: <1427842641.98.0.862113215057.issue23834@psf.upfronthosting.co.za> Changes by STINNER Victor : Removed file: http://bugs.python.org/file38769/sock_call.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 00:57:30 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 31 Mar 2015 22:57:30 +0000 Subject: [issue23834] socketmodule.c: add sock_call() to fix how the timeout is recomputed In-Reply-To: <1427842506.28.0.704301607448.issue23834@psf.upfronthosting.co.za> Message-ID: <1427842650.26.0.0335431785314.issue23834@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file38770/sock_call.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 01:02:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 31 Mar 2015 23:02:17 +0000 Subject: [issue23834] socketmodule.c: add sock_call() to fix how the timeout is recomputed In-Reply-To: <1427842506.28.0.704301607448.issue23834@psf.upfronthosting.co.za> Message-ID: <1427842937.45.0.38972293697.issue23834@psf.upfronthosting.co.za> STINNER Victor added the comment: By the way, socket.sendto() has a bug: it stores the result of sendto() into a C int. It must store the result into a Py_ssize_t. sock_call.patch already contains a fix for this. Attached sendto_ssizet.patch is the fix for Python 2.7 and 3.4. UDP packets cannot be larger than an ethernet frame which is smaller than 10,000 bytes. That's probabyl why nobody complained before. sendto() is only used for UDP, no? ---------- Added file: http://bugs.python.org/file38771/sendto_ssizet.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 01:05:58 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 31 Mar 2015 23:05:58 +0000 Subject: [issue23834] socketmodule.c: add sock_call() to fix how the timeout is recomputed In-Reply-To: <1427842506.28.0.704301607448.issue23834@psf.upfronthosting.co.za> Message-ID: <1427843158.23.0.00696001359031.issue23834@psf.upfronthosting.co.za> STINNER Victor added the comment: I chose to not modify yet socket.sendall(). I prefer to wait until this patch is merged to rework this method. Currently, this method never recomputes the timeout. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 01:16:59 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 31 Mar 2015 23:16:59 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1427843819.29.0.260313951263.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: I expect Antoine is trying to limit the scope of the change, which makes sense. In this case, though, once (if?) the patch lands I plan on using it in the interpreter, so the C-API bits will be necessary. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 01:28:19 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 31 Mar 2015 23:28:19 +0000 Subject: [issue23828] test_socket testCmsgTruncLen0 gets "received malformed or improperly-truncated ancillary data" warning under OS X In-Reply-To: <1427820936.86.0.258398348531.issue23828@psf.upfronthosting.co.za> Message-ID: <1427844499.46.0.00536585738832.issue23828@psf.upfronthosting.co.za> Ned Deily added the comment: Original title: "test_socket fails under -Werror" These are long-time, normally non-fatal warnings when running test_socket on OS X with Python 3 independent of -Werror, introduced with the socket sendmsg() and recvmsg() feature in the changes for Issue6560 and a followup in Issue12958. I guess we haven't followed up on them since. I note that there is now an open issue (Issue20669) about a set of test_socket failures under OpenBSD including this case. So perhaps this test behavior also has its origins in differences between BSD vs others, further complicated by subsequent divergence of the OS X network layer from its BSD origins. Interestingly, because the warning does not normally cause a test failure (that is, without the Python -Werror option as used in this issue), the warning messages do not show up in the OS X buildbot logs at all because the buildbot test runs use the -m test (test.regrtest) -W option (not to be confused with the Python -W option). Without -m test -W, the warnings do appear but, without Python -Werror, cause no failures. ---------- nosy: +ned.deily title: test_socket fails under -Werror -> test_socket testCmsgTruncLen0 gets "received malformed or improperly-truncated ancillary data" warning under OS X versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 01:31:11 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 31 Mar 2015 23:31:11 +0000 Subject: [issue12319] [http.client] HTTPConnection.putrequest not support "chunked" Transfer-Encodings to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1427844671.17.0.628319160762.issue12319@psf.upfronthosting.co.za> Changes by Demian Brecht : Added file: http://bugs.python.org/file38772/issue12319_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 01:42:59 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 31 Mar 2015 23:42:59 +0000 Subject: [issue23350] Content-length is incorrect when request body is a list or tuple In-Reply-To: <1422580362.11.0.520529959905.issue23350@psf.upfronthosting.co.za> Message-ID: <1427845379.97.0.8378987844.issue23350@psf.upfronthosting.co.za> Demian Brecht added the comment: The computation of Content-Length has also undergone some refactoring as part of #12319. Setting this as pending until #12319 has been accepted or rejected. If rejected, the implementation specific to generating Content-Length should be migrated here. ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 01:44:40 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 31 Mar 2015 23:44:40 +0000 Subject: [issue23350] Content-length is incorrect when request body is a list or tuple In-Reply-To: <1422580362.11.0.520529959905.issue23350@psf.upfronthosting.co.za> Message-ID: <1427845480.45.0.455338384503.issue23350@psf.upfronthosting.co.za> Demian Brecht added the comment: If #12319 is accepted, the implementation for Content-Length should also likely be migrated to this issue to be applied to maintenance branches as a bug fix. ---------- status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 01:53:33 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 31 Mar 2015 23:53:33 +0000 Subject: [issue2211] Cookie.Morsel interface needs update In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za> Message-ID: <1427846013.63.0.460578751936.issue2211@psf.upfronthosting.co.za> Demian Brecht added the comment: Set as closed, assuming there's no reason to keep this issue open. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 01:59:47 2015 From: report at bugs.python.org (Demian Brecht) Date: Tue, 31 Mar 2015 23:59:47 +0000 Subject: [issue22931] cookies with square brackets in value In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za> Message-ID: <1427846387.93.0.399454197379.issue22931@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 02:00:52 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 01 Apr 2015 00:00:52 +0000 Subject: [issue22931] cookies with square brackets in value In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za> Message-ID: <1427846452.37.0.572156296556.issue22931@psf.upfronthosting.co.za> Changes by Demian Brecht : Added file: http://bugs.python.org/file38773/issue22931_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 02:01:07 2015 From: report at bugs.python.org (Jethro) Date: Wed, 01 Apr 2015 00:01:07 +0000 Subject: [issue23824] in-place addition of a shadowed class field In-Reply-To: <1427810483.28.0.753445482899.issue23824@psf.upfronthosting.co.za> Message-ID: <1427846467.72.0.932262066828.issue23824@psf.upfronthosting.co.za> Jethro added the comment: I'm not confused. In my first report, I have already explained why python behaves that way. My point is, this is not the right way to go. Because the very same self.tot in the in-place operation self.tot+=a is first resolved to be the class field, then an instance field. This is against any sensible design of a language. If this is OK, then my second example should also be OK. In my second example, tot += x, the very same tot can be first resolved to the global variable tot, then the result is assigned to a local variable. ---------- resolution: not a bug -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 03:21:32 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Apr 2015 01:21:32 +0000 Subject: [issue12855] linebreak sequences should be better documented In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za> Message-ID: <20150401012128.1919.92809@psf.io> Roundup Robot added the comment: New changeset 6244a5dbaf84 by Benjamin Peterson in branch '3.4': document what exactly str.splitlines() splits on (closes #12855) https://hg.python.org/cpython/rev/6244a5dbaf84 New changeset 87af6deb5d26 by Benjamin Peterson in branch 'default': merge 3.4 (#12855) https://hg.python.org/cpython/rev/87af6deb5d26 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 06:23:08 2015 From: report at bugs.python.org (James Tocknell) Date: Wed, 01 Apr 2015 04:23:08 +0000 Subject: [issue23835] configparser does not convert defaults to strings Message-ID: <1427862188.44.0.00358189102447.issue23835@psf.upfronthosting.co.za> New submission from James Tocknell: ConfigParser(defaults={1:2.4}) and ConfigParser(defaults={"a":5.2}) cause an exception when configparser tries to perform string operations on 1 and 5.2. I didn't see it documented that defaults must only contain strings, and using ConfigParser['DEFAULT'] = {1:2.4} does the necessary string conversion, so it looks like there should be some conversion done to the defaults. ---------- components: Library (Lib) messages: 239768 nosy: aragilar priority: normal severity: normal status: open title: configparser does not convert defaults to strings type: crash versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 06:27:08 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 01 Apr 2015 04:27:08 +0000 Subject: [issue12319] [http.client] HTTPConnection.putrequest not support "chunked" Transfer-Encodings to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1427862428.33.0.815935430633.issue12319@psf.upfronthosting.co.za> Martin Panter added the comment: Perhaps you should make a table of some potential body object types, and figure out what the behaviour should be for request() with and without relevant headers, and endheaders() and send() with and without encode_chunked=True: * Add/don?t add Content-Length/Transfer-Encoding * Send with/without chunked encoding * Raise exception * Not supported or undefined behaviour Potential body types: * None with GET/POST request * bytes() * Latin-1/non Latin-1 str() * BytesIO/StringIO * Ordinary binary/Latin-1/other file object * File object reading a special file like a pipe (st_size == 0) * File object wrapping a pipe or similar that does not support fileno() (ESPIPE) * Custom file object not supporting fileno() nor seeking * File object at non-zero offset * GzipFile object, where fileno() corresponds to the compressed size * GzipFile not supporting fileno(), where seeking is possible but expensive * Iterator yielding bytes() and/or strings * Generator * File object considered as an iterable of lines * List/tuple of bytes/text * Other sequences of bytes/text * Other iterables of bytes/text, e.g. set(), OrderedDict.values() This list could go on and on. I would rather have a couple of simple rules, or explicit APIs for the various modes so you don?t have to guess which mode your particular body type will trigger. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 06:34:09 2015 From: report at bugs.python.org (Davin Potts) Date: Wed, 01 Apr 2015 04:34:09 +0000 Subject: [issue23484] SemLock acquire() keyword arg 'blocking' is invalid In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za> Message-ID: <1427862849.47.0.742602960391.issue23484@psf.upfronthosting.co.za> Davin Potts added the comment: @berker: I would have said this should not be marked an enhancement as the proposed solution (in the patch) is to correct the errors in the documentation to accurately describe the current implemented behavior. Does that make sense? Whatever label we give it, do you think my logic (described in my comments on this issue) for why it is best to fix it this way makes sense to you? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 07:24:32 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 01 Apr 2015 05:24:32 +0000 Subject: [issue12319] [http.client] HTTPConnection.putrequest not support "chunked" Transfer-Encodings to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1427865872.64.0.596919108165.issue12319@psf.upfronthosting.co.za> Demian Brecht added the comment: Agreed. However, I'm wondering if that should belong in a new issue geared towards further clarifying behaviour of request body types. The patch introduces the behaviour this specific issue was looking, with the largest change being that iterators may now result in chunked transfer encoding with the data currently handled by the library. I'd rather move forward with incremental improvements rather than keep building on each issue before the work's merged (there's still a /good/ amount of work to be done in this module). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 08:38:15 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Wed, 01 Apr 2015 06:38:15 +0000 Subject: [issue19176] DeprecationWarning for doctype() method when subclassing _elementtree.XMLParser In-Reply-To: <1381041750.41.0.637077946349.issue19176@psf.upfronthosting.co.za> Message-ID: <1427870295.18.0.658185534175.issue19176@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Also please apply inherit-doctype.v2.patch in 3.4 branch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 08:59:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Apr 2015 06:59:56 +0000 Subject: [issue23835] configparser does not convert defaults to strings In-Reply-To: <1427862188.44.0.00358189102447.issue23835@psf.upfronthosting.co.za> Message-ID: <1427871596.24.0.177220692577.issue23835@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +lukasz.langa type: crash -> behavior versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 10:39:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Apr 2015 08:39:57 +0000 Subject: [issue22035] Fatal error in dbm.gdbm In-Reply-To: <1406024440.03.0.44171364302.issue22035@psf.upfronthosting.co.za> Message-ID: <1427877597.13.0.217128680776.issue22035@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch for issue3999 was rejected because Python internal state may be corrupted when the SIGSEGV signal is raised. This is not the case of this issue. gdbm fatal function is called when Python is in consistent state. So we free to use any Python C-API. But internal state of concrete GDBM_FILE may be corrupted, so we shouldn't use it after handling fatal error. This cause a leak, but I think that a leak with an exception is better than just a crash. May be different type of exception should be raised. May be we need FatalError that inherits from BaseException. Other external libraries used by the stdlib also can crash, and perhaps crashes can be converted to exceptions. This issue is only first in the series. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 11:08:23 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 09:08:23 +0000 Subject: [issue23834] socketmodule.c: add sock_call() to fix how the timeout is recomputed In-Reply-To: <1427842506.28.0.704301607448.issue23834@psf.upfronthosting.co.za> Message-ID: <1427879303.58.0.126440229701.issue23834@psf.upfronthosting.co.za> STINNER Victor added the comment: sock_call-2.patch: add an inner looop in sock_call() to only retry func() when func() is interrupted by a signal. Limit also changes: try to only modify ctx around to call to sock_call(), move back some variables to the parent function. Rename the variable storing the result to "result". Add some more comments in sock_call(). ---------- Added file: http://bugs.python.org/file38774/sock_call-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 11:10:38 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Apr 2015 09:10:38 +0000 Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect) In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za> Message-ID: <20150401091035.1921.55406@psf.io> Roundup Robot added the comment: New changeset 8ec4acfdb851 by Victor Stinner in branch 'default': Issue #23618: Fix EINTR handling on Windows https://hg.python.org/cpython/rev/8ec4acfdb851 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 11:43:59 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 09:43:59 +0000 Subject: [issue23836] PEP 475: Enhance faulthandler to handle better reentrant calls Message-ID: <1427881439.29.0.554454019096.issue23836@psf.upfronthosting.co.za> New submission from STINNER Victor: While working on the PEP 475, I noticed that the faulthandler module doesn't handle well reentrant calls to its signal handlers. If a signal is received while faulthandler is displaying the traceback, faulthandler restarts to display a new traceback (and then finish to display the previous traceback). Moreover, faulthandler uses the C function write() to display the traceback and it ignores write() errors. It should retry write() if write() is interrupted by a signal (fails with EINTR). Attached py_write_noraise.patch: - Add a new _Py_write_noraise() function - Document functions releasing the GIL Attached traceback_eintr.patch: - Modify functions displaying traceback to use _Py_write_noraise() instead of write() Attached faulthandler_eintr.patch: - Add a reentrant flag to the two signal handlers of faulthandler - Modify faulthandler.dump_traceback() to call PyErr_CheckSignals(), to call the Python signal handler if a signal was received while faulthandler was displaying the traceback of all Python threads ---------- files: py_write_noraise.patch keywords: patch messages: 239776 nosy: haypo priority: normal severity: normal status: open title: PEP 475: Enhance faulthandler to handle better reentrant calls versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38775/py_write_noraise.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 11:44:06 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 09:44:06 +0000 Subject: [issue23836] PEP 475: Enhance faulthandler to handle better reentrant calls In-Reply-To: <1427881439.29.0.554454019096.issue23836@psf.upfronthosting.co.za> Message-ID: <1427881446.13.0.875155211918.issue23836@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file38776/traceback_eintr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 11:44:11 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 09:44:11 +0000 Subject: [issue23836] PEP 475: Enhance faulthandler to handle better reentrant calls In-Reply-To: <1427881439.29.0.554454019096.issue23836@psf.upfronthosting.co.za> Message-ID: <1427881451.88.0.663872154037.issue23836@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file38777/faulthandler_eintr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 11:44:40 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 09:44:40 +0000 Subject: [issue23648] PEP 475 meta issue In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za> Message-ID: <1427881480.19.0.771447911422.issue23648@psf.upfronthosting.co.za> STINNER Victor added the comment: New issue #23836: Enhance faulthandler to handle better reentrant calls. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 11:44:47 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 09:44:47 +0000 Subject: [issue23836] PEP 475: Enhance faulthandler to handle better reentrant calls In-Reply-To: <1427881439.29.0.554454019096.issue23836@psf.upfronthosting.co.za> Message-ID: <1427881487.8.0.150083685474.issue23836@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +neologix _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 11:45:05 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 09:45:05 +0000 Subject: [issue23648] PEP 475 meta issue In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za> Message-ID: <1427881505.23.0.532007006335.issue23648@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- dependencies: +PEP 475: Enhance faulthandler to handle better reentrant calls _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 11:47:12 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 09:47:12 +0000 Subject: [issue22035] Fatal error in dbm.gdbm In-Reply-To: <1427877597.13.0.217128680776.issue22035@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: 2015-04-01 10:39 GMT+02:00 Serhiy Storchaka : > Other external libraries used by the stdlib also can crash, and perhaps crashes can be converted to exceptions. This issue is only first in the series. I don't think that it's a good practice to try to workaround bugs. IMO it's better to modify libraries directly to allow users of the library to handle correctly errors. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 12:06:02 2015 From: report at bugs.python.org (=?utf-8?q?Mathias_Fr=C3=B6jdman?=) Date: Wed, 01 Apr 2015 10:06:02 +0000 Subject: [issue23837] read pipe transport tries to resume reading after loop is gone Message-ID: <1427882762.68.0.794378524046.issue23837@psf.upfronthosting.co.za> New submission from Mathias Fr?jdman: Script attached which reproduces the issue. Steps to reproduce: 0) Use python 3.4.3 on Linux. Does not repro with 3.4.0 or 3.4.2. 1) Create a child process with asyncio.create_child_exec and stdout=PIPE 2) loop yield from child.read(n) (i used n=2048, any other positive value < StreamRead._limit ought to work too) 3) Write >= StreamRead._limit * 2 + 1 (by default 2**17+1) bytes from child process and exit File referenced below: asyncio/streams.py feed_data is called when data arrives from the child process. Having more than 2 * self._limit bytes in self._buffer will lead to StreamReader pausing reading on line 372. feed_eof sets self._eof to True, but that value is not checked in relevant sections later. Child process exits, which will lead to self._loop = None being set apparently on line 405 of _UnixReadPipeTransport._call_connection_lost in asyncio/unix_events.py (could not find any other location where it would be set to None). After a number of read()s, self._maybe_resume_transport() is called when len(self._buffer) <= self._limit (ie. <= 64k left in buffer). self._paused will evaluate true too, so self._transport.resume_reading() is called on line 349. That will call self._loop.add_reader(self._fileno, self._read_ready) on line 364 of asyncio/unix_events.py. self._loop is None, so and AttributeError is raised when None has no add_reader attribute: Traceback (most recent call last): File "child_reader.py", line 29, in print('read {} bytes from child'.format(loop.run_until_complete(fail()))) File "/home/frojma/python-3.4.3/lib/python3.4/asyncio/base_events.py", line 316, in run_until_complete return future.result() File "/home/frojma/python-3.4.3/lib/python3.4/asyncio/futures.py", line 275, in result raise self._exception File "/home/frojma/python-3.4.3/lib/python3.4/asyncio/tasks.py", line 238, in _step result = next(coro) File "child_reader.py", line 15, in fail chunk = yield from child.stdout.read(2048) File "/home/frojma/python-3.4.3/lib/python3.4/asyncio/streams.py", line 478, in read self._maybe_resume_transport() File "/home/frojma/python-3.4.3/lib/python3.4/asyncio/streams.py", line 354, in _maybe_resume_transport self._transport.resume_reading() File "/home/frojma/python-3.4.3/lib/python3.4/asyncio/unix_events.py", line 364, in resume_reading self._loop.add_reader(self._fileno, self._read_ready) ---------- components: asyncio files: child_reader.py messages: 239779 nosy: gvanrossum, haypo, mwf, yselivanov priority: normal severity: normal status: open title: read pipe transport tries to resume reading after loop is gone type: crash versions: Python 3.4 Added file: http://bugs.python.org/file38778/child_reader.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 12:07:26 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Apr 2015 10:07:26 +0000 Subject: [issue23799] Join started threads in tests In-Reply-To: <1427573430.36.0.605750682641.issue23799@psf.upfronthosting.co.za> Message-ID: <20150401100719.2034.97412@psf.io> Roundup Robot added the comment: New changeset f8358f6e50e7 by Serhiy Storchaka in branch '2.7': Issue #23799: Added test.test_support.start_threads() for running and https://hg.python.org/cpython/rev/f8358f6e50e7 New changeset 8987218adc99 by Serhiy Storchaka in branch '3.4': Issue #23799: Added test.support.start_threads() for running and cleaning up https://hg.python.org/cpython/rev/8987218adc99 New changeset a2df4baa112b by Serhiy Storchaka in branch 'default': Issue #23799: Added test.support.start_threads() for running and cleaning up https://hg.python.org/cpython/rev/a2df4baa112b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 13:24:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Apr 2015 11:24:24 +0000 Subject: [issue23838] linecache and MemoryError Message-ID: <1427887464.14.0.986179672993.issue23838@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: When format a traceback of MemoryError, linecache tries to read all lines of source file and likely raises a MemoryError. For example: http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.x/builds/9712/steps/test/logs/stdio Traceback (most recent call last): File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/regrtest.py", line 1280, in runtest_inner test_runner() File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_socket.py", line 5340, in test_main support.run_unittest(*tests) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/support/__init__.py", line 1808, in run_unittest _run_suite(suite) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/support/__init__.py", line 1774, in _run_suite result = runner.run(suite) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/runner.py", line 176, in run test(result) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/suite.py", line 84, in __call__ return self.run(*args, **kwds) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/suite.py", line 122, in run test(result) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/suite.py", line 84, in __call__ return self.run(*args, **kwds) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/suite.py", line 122, in run test(result) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/case.py", line 625, in __call__ return self.run(*args, **kwds) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/case.py", line 585, in run self._feedErrorsToResult(result, outcome.errors) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/case.py", line 518, in _feedErrorsToResult result.addError(test, exc_info) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/runner.py", line 67, in addError super(TextTestResult, self).addError(test, err) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/result.py", line 17, in inner return method(self, *args, **kw) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/result.py", line 115, in addError self.errors.append((test, self._exc_info_to_string(err, test))) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/unittest/result.py", line 186, in _exc_info_to_string exctype, value, tb, limit=length, capture_locals=self.tb_locals) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/traceback.py", line 456, in __init__ capture_locals=capture_locals) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/traceback.py", line 341, in extract f.line File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/traceback.py", line 270, in line self._line = linecache.getline(self.filename, self.lineno).strip() File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/linecache.py", line 16, in getline lines = getlines(filename, module_globals) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/linecache.py", line 44, in getlines return updatecache(filename, module_globals) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/linecache.py", line 134, in updatecache lines = fp.readlines() MemoryError During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/regrtest.py", line 532, in main result = runtest(*args, **kwargs) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/regrtest.py", line 967, in runtest display_failure=False) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/regrtest.py", line 1304, in runtest_inner msg = traceback.format_exc() File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/traceback.py", line 161, in format_exc return "".join(format_exception(*sys.exc_info(), limit=limit, chain=chain)) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/traceback.py", line 115, in format_exception type(value), value, tb, limit=limit).format(chain=chain)) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/traceback.py", line 456, in __init__ capture_locals=capture_locals) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/traceback.py", line 341, in extract f.line File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/traceback.py", line 270, in line self._line = linecache.getline(self.filename, self.lineno).strip() File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/linecache.py", line 16, in getline lines = getlines(filename, module_globals) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/linecache.py", line 44, in getlines return updatecache(filename, module_globals) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/linecache.py", line 134, in updatecache lines = fp.readlines() File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/codecs.py", line 321, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) MemoryError Traceback (most recent call last): File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/runpy.py", line 170, in _run_module_as_main "__main__", mod_spec) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/runpy.py", line 85, in _run_code exec(code, run_globals) File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/__main__.py", line 3, in regrtest.main_in_temp_cwd() File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/regrtest.py", line 1564, in main_in_temp_cwd main() File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/regrtest.py", line 738, in main raise Exception("Child error on {}: {}".format(test, result[1])) Exception: Child error on test_socket: make: *** [buildbottest] Error 1 program finished with exit code 2 Proposed patch clears the cache and repeats an attempt to read source file, and returns empty result if the second attempt fails (as when the source file can't be read). I hesitate how to classify this issue. On one hand, it looks as new feature, on other hand it is related to testing on all versions. ---------- components: Library (Lib) files: linecache_memoryerror.patch keywords: patch messages: 239781 nosy: ezio.melotti, haypo, michael.foord, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: linecache and MemoryError Added file: http://bugs.python.org/file38779/linecache_memoryerror.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 13:30:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Apr 2015 11:30:41 +0000 Subject: [issue23839] Clear caches after every test Message-ID: <1427887841.84.0.393130432881.issue23839@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Some caches can grow unlimitedly during running the testsuite (in particular linecache). On some machines with limited resources this can cause multiple MemoryErrors. Many of these MemoryErrors can be avoided if clear caches between tests. Lib/test/regrtest.py already contains a code for cleaning caches, but it is used only with the -R option. ---------- components: Tests messages: 239782 nosy: ezio.melotti, haypo, michael.foord, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: Clear caches after every test type: resource usage versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 13:33:05 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 01 Apr 2015 11:33:05 +0000 Subject: [issue23756] Tighten definition of bytes-like objects In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za> Message-ID: <1427887985.65.0.322156397009.issue23756@psf.upfronthosting.co.za> Martin Panter added the comment: After doing a bit of reading and experimenting, I think we should at least restrict bytes-like objects to ?C-contiguous?. Any looser definition risks memoryview(byteslike).tobytes() returning the bytes in a different order than their true in-memory order. Fortran-style contiguous arrays aren?t enough: >>> import _testbuffer, sys >>> fortran = memoryview(_testbuffer.ndarray([11, 12, 21, 22], format="B", flags=0, shape=[2, 2], strides=[1, 2], offset=0)) >>> fortran.f_contiguous True >>> fortran.c_contiguous False >>> fortran.tolist() [[11, 21], [12, 22]] >>> tuple(bytes(fortran)) (11, 21, 12, 22) >>> sys.stdout.buffer.write(fortran) Traceback (most recent call last): File "", line 1, in BufferError: memoryview: underlying buffer is not C-contiguous So I am proposing a patch which: * Restricts the bytes-like object definition to C-contiguous buffers * Explains what I think is actually meant by ?contiguous? in the C API buffer protocol page. Turns out it is generally a more strict definition than I originally assumed. * Explains why memoryview.tobytes() is out of order for non C-contiguous buffers * Has a couple other fixes taking into acount memoryview.tolist() doesn?t work for zero dimensions, and is nested for more than one dimension ---------- keywords: +patch Added file: http://bugs.python.org/file38780/c-contig.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 13:44:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Apr 2015 11:44:28 +0000 Subject: [issue23756] Tighten definition of bytes-like objects In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za> Message-ID: <1427888668.13.0.771599570118.issue23756@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: +1 for the idea overall and the patch LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 13:47:52 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 11:47:52 +0000 Subject: [issue23838] linecache and MemoryError In-Reply-To: <1427887464.14.0.986179672993.issue23838@psf.upfronthosting.co.za> Message-ID: <1427888872.4.0.00800361691649.issue23838@psf.upfronthosting.co.za> STINNER Victor added the comment: > Proposed patch clears the cache and repeats an attempt to read source file, and returns empty result if the second attempt fails (as when the source file can't be read). IMO it's a bad idea. You should not retry an operation on MemoryError but only do you best to limit errors. I don't think that it's correct to return an empty list for getlines() on MemoryError. So you maybe chose the wrong module: you should handle MemoryError in the traceback module, not in the linecache module. It's just fine to return an empty string for FrameSummary.line. It's common to not being able to display a line: because the .py was removed (only the .pyc is available), invalid line number, invalid filename ("" or ""), etc. If you are motivated to make the traceback module more reliable, you should maybe also enhance _Py_DisplaySourceLine() in Python/traceback.c. You can probably ignore almost all errors in _Py_DisplaySourceLine() ("except (Exception, MemoryError): pass"). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 13:52:33 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 11:52:33 +0000 Subject: [issue23840] tokenize.open() leaks an open binary file on TextIOWrapper error Message-ID: <1427889153.26.0.649877902408.issue23840@psf.upfronthosting.co.za> New submission from STINNER Victor: If TextIOWrapper constructor fails in tokenize.open(), the open binary file is not closed and a ResourceWarning is emited. Try attached patch: $ python3 -Wd ~/tokenize_open_bug.py tokenize.open failed: unknown encoding for 'test.py': xxx /home/haypo/tokenize_open_bug.py:13: ResourceWarning: unclosed file <_io.BufferedReader name='test.py'> print("tokenize.open failed: %s" % err) The fix is quite simple: add "try: ... except: buffer.close(); raise". If someone wants to fix this issue, an unit test must be added, test based on my script and ensures that the buffer is closed (ex: mock tokenize._builtin_open and checks that close() was called). ---------- files: tokenize_open_bug.py keywords: easy messages: 239786 nosy: haypo priority: normal severity: normal status: open title: tokenize.open() leaks an open binary file on TextIOWrapper error versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38781/tokenize_open_bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 13:53:41 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 11:53:41 +0000 Subject: [issue23840] tokenize.open() leaks an open binary file on TextIOWrapper error In-Reply-To: <1427889153.26.0.649877902408.issue23840@psf.upfronthosting.co.za> Message-ID: <1427889221.57.0.0083049472161.issue23840@psf.upfronthosting.co.za> STINNER Victor added the comment: I sent an email to the python core mentorship mailing list to find a volunteer to fix this easy issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 13:56:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 11:56:04 +0000 Subject: [issue23838] linecache and MemoryError In-Reply-To: <1427887464.14.0.986179672993.issue23838@psf.upfronthosting.co.za> Message-ID: <1427889364.76.0.448824969784.issue23838@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy: you look to be interested in fixing Python to not fail badly under low memory condition. You may take a look at #19817 which proposes a function to arbitrary limit the memory allocated to Python. I fixed a lot of issues found by failmalloc, but they are still serious issues. For example, unit tests crash on subinterpreter tests with failmalloc, and there is also the memory allocation failure when raising MemoryError: see #19835. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 14:01:47 2015 From: report at bugs.python.org (sorin) Date: Wed, 01 Apr 2015 12:01:47 +0000 Subject: [issue23841] py34 OrderedDict is using weakref for root reference Message-ID: <1427889707.75.0.323875541647.issue23841@psf.upfronthosting.co.za> New submission from sorin: The standard library implementation of an OrderedDict (which is included in Python 3.4) uses a weakref for the root reference. https://hg.python.org/cpython/file/534b26837a13/Lib/collections/__init__.py#l74 This was reported initially on https://github.com/kennethreitz/requests/issues/2303 and at the moment there are no known workarounds. ---------- components: Library (Lib) messages: 239789 nosy: sorin priority: normal severity: normal status: open title: py34 OrderedDict is using weakref for root reference type: compile error versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 14:02:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Apr 2015 12:02:28 +0000 Subject: [issue23838] linecache and MemoryError In-Reply-To: <1427887464.14.0.986179672993.issue23838@psf.upfronthosting.co.za> Message-ID: <1427889748.89.0.966320062587.issue23838@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: getlines() already returns an empty list on OSError. Clearing the cache on MemoryError will help to avoid other MemoryErrors. And after this there is a large chance the repeated reading will be successful. In any case it wouldn't make worse. If don't change linecache, then we should patch all places where linecache is used: traceback, idlelib, warnings, trace, debugger, etc. I intentionally made the fix at the low level, so it fixes all issues in one place. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 14:05:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 12:05:04 +0000 Subject: [issue23839] Clear caches after every test In-Reply-To: <1427887841.84.0.393130432881.issue23839@psf.upfronthosting.co.za> Message-ID: <1427889904.27.0.622177946525.issue23839@psf.upfronthosting.co.za> STINNER Victor added the comment: Maybe tests known to fill caches should clear theirself caches at cleanup? Always clearing all caches may have an impact on performances and so makes tests longer. Caches are designed to speedup Python :-) We may add some helper functions in test.support for the most common caches, but not to clear *all* caches. By the way, forcing calls to gc.collect() may make tests more reliable. It would avoid to get warnings 4 lines after the test leaking a resource finished. But it's not easy to make this reliable, because unittest stores a lot of things. unittest.TestCase.run() stores exceptions which store a traceback which stores frames which store references to local variables. Instead of storing a whole sys.exc_info(), we can maybe use the new light traceback.TracebackException which only stores info required to format a traceback as text, without storing all these heavily objects creating reference cycles. (Hum, it becomes a little off-topic, sorry, we may open a new separated issue.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 14:05:11 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 12:05:11 +0000 Subject: [issue23839] Clear caches after every test In-Reply-To: <1427887841.84.0.393130432881.issue23839@psf.upfronthosting.co.za> Message-ID: <1427889911.74.0.877762883711.issue23839@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 14:05:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Apr 2015 12:05:36 +0000 Subject: [issue23841] py34 OrderedDict is using weakref for root reference In-Reply-To: <1427889707.75.0.323875541647.issue23841@psf.upfronthosting.co.za> Message-ID: <1427889936.12.0.417679949779.issue23841@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +rhettinger type: compile error -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 14:08:27 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 12:08:27 +0000 Subject: [issue23838] linecache and MemoryError In-Reply-To: <1427889748.89.0.966320062587.issue23838@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: 2015-04-01 14:02 GMT+02:00 Serhiy Storchaka : > getlines() already returns an empty list on OSError. Oh, I misread getlines(), you're right. > Clearing the cache on MemoryError will help to avoid other MemoryErrors. And after this there is a large chance I agree, but please avoid retrying on MemoryError. IMO clearing the cache and return [] is enough. > If don't change linecache, then we should patch all places where linecache is used: traceback, idlelib, warnings, trace, debugger, etc. I intentionally made the fix at the low level, so it fixes all issues in one place. I agree. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 14:11:15 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 01 Apr 2015 12:11:15 +0000 Subject: [issue12319] [http.client] HTTPConnection.putrequest not support "chunked" Transfer-Encodings to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1427890275.54.0.614005176678.issue12319@psf.upfronthosting.co.za> Martin Panter added the comment: The incremental improvement thing sounds good. Here are some things which I think are orthogonal to sensible chunked encoding: * Automagic seeking to determine Content-Length * Setting Content-Length for iterables that are neither strings, iterators nor files (Issue 23350) * Latin-1 encoding of iterated items ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 14:26:40 2015 From: report at bugs.python.org (Piotr Dobrogost) Date: Wed, 01 Apr 2015 12:26:40 +0000 Subject: [issue23841] py34 OrderedDict is using weakref for root reference In-Reply-To: <1427889707.75.0.323875541647.issue23841@psf.upfronthosting.co.za> Message-ID: <1427891200.58.0.350854204434.issue23841@psf.upfronthosting.co.za> Changes by Piotr Dobrogost : ---------- nosy: +piotr.dobrogost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 14:33:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Apr 2015 12:33:16 +0000 Subject: [issue23839] Clear caches after every test In-Reply-To: <1427887841.84.0.393130432881.issue23839@psf.upfronthosting.co.za> Message-ID: <1427891596.83.0.864746367293.issue23839@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: We should try to know how it impacts a performance. I suppose not too much, but may be my intuition lies me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 14:35:06 2015 From: report at bugs.python.org (Stefan Krah) Date: Wed, 01 Apr 2015 12:35:06 +0000 Subject: [issue23756] Tighten definition of bytes-like objects In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za> Message-ID: <1427891706.93.0.27620865359.issue23756@psf.upfronthosting.co.za> Stefan Krah added the comment: I have a somewhat general concern: In the last year or so, issues seem to expand far beyond the scope that's indicated by the issue title. For example, I don't particularly care about the definition of "bytes-like", but the patch contains changes to areas I *do* care about. I don't think all of the changes are an improvement: What is the "flattened length", why does C-contiguous have to be explained? ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 14:39:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 12:39:17 +0000 Subject: [issue23839] Clear caches after every test In-Reply-To: <1427887841.84.0.393130432881.issue23839@psf.upfronthosting.co.za> Message-ID: <1427891957.79.0.758712816241.issue23839@psf.upfronthosting.co.za> STINNER Victor added the comment: By the way, a workaround is also to run each test (file) in a new fresh process. It's a common way to work around memory fragmentation ;-) > On some machines with limited resources this can cause multiple MemoryErrors. Do you have an idea of the memory usage of the Python test suite? You may run it with tracemalloc to get the memory peak from tracemalloc.get_traced_memory()[1]. I mean, memory is cheap nowadays. If you get MemoryError, it's probably more a bug than tests leaking more and more memory, no? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 14:44:13 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 01 Apr 2015 12:44:13 +0000 Subject: [issue9232] Allow trailing comma in any function argument list. In-Reply-To: <1278945017.29.0.842296068848.issue9232@psf.upfronthosting.co.za> Message-ID: <1427892253.45.0.107099681544.issue9232@psf.upfronthosting.co.za> Martin Panter added the comment: Actual post by Raymond: Just noticed there are some arguments for trailing commas in the FAQ: ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 14:45:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Apr 2015 12:45:56 +0000 Subject: [issue23838] linecache and MemoryError In-Reply-To: <1427887464.14.0.986179672993.issue23838@psf.upfronthosting.co.za> Message-ID: <1427892356.82.0.701085611859.issue23838@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: OK, here is a patch that just clear the cache and returns an empty result. It is hard to write reliable test, but I think we will see the result on OpenIndiana buildbot. The question is left: should the patch be applied only on 3.5 or all versions? ---------- Added file: http://bugs.python.org/file38782/linecache_memoryerror_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 14:57:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Apr 2015 12:57:37 +0000 Subject: [issue23839] Clear caches after every test In-Reply-To: <1427887841.84.0.393130432881.issue23839@psf.upfronthosting.co.za> Message-ID: <1427893057.16.0.369060371399.issue23839@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: max_rss is a little larger 500 MB after ran all testsuite (except bigmem tests) on 32-bit Linux. Only few tests needs more than 200 MB. But may be some 64-bit only tests consume more memory. If a test consume more than 1GiB of memory and is not decorated with bigmemtest, it should be considered as a bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 15:02:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Apr 2015 13:02:46 +0000 Subject: [issue23840] tokenize.open() leaks an open binary file on TextIOWrapper error In-Reply-To: <1427889153.26.0.649877902408.issue23840@psf.upfronthosting.co.za> Message-ID: <1427893366.7.0.636463040408.issue23840@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- components: +Library (Lib) stage: -> needs patch type: -> resource usage _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 15:04:21 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 13:04:21 +0000 Subject: [issue23838] linecache and MemoryError In-Reply-To: <1427887464.14.0.986179672993.issue23838@psf.upfronthosting.co.za> Message-ID: <1427893461.09.0.205360316045.issue23838@psf.upfronthosting.co.za> STINNER Victor added the comment: > It is hard to write reliable test Ah? Why not using something like mock.patch('mock.updatecache', side_effect=MemoryError)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 15:07:51 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 13:07:51 +0000 Subject: [issue23838] linecache and MemoryError In-Reply-To: <1427887464.14.0.986179672993.issue23838@psf.upfronthosting.co.za> Message-ID: <1427893671.87.0.802650125834.issue23838@psf.upfronthosting.co.za> STINNER Victor added the comment: > The question is left: should the patch be applied only on 3.5 or all versions? linecache_memoryerror_2.patch looks good to me, but it would be better with an unit test. IMO Python 2.7 and 3.4 can be fixed too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 15:08:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Apr 2015 13:08:58 +0000 Subject: [issue23838] linecache and MemoryError In-Reply-To: <1427887464.14.0.986179672993.issue23838@psf.upfronthosting.co.za> Message-ID: <1427893738.36.0.376153256097.issue23838@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This test depends on implementation details. I prefer to avoid adding such tests for trivial changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 15:09:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Apr 2015 13:09:51 +0000 Subject: [issue23838] linecache and MemoryError In-Reply-To: <1427887464.14.0.986179672993.issue23838@psf.upfronthosting.co.za> Message-ID: <1427893791.03.0.499890003553.issue23838@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- type: -> resource usage versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 15:20:55 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 01 Apr 2015 13:20:55 +0000 Subject: [issue23779] imaplib authenticate raises TypeError if authenticator tries to abort In-Reply-To: <1427322083.72.0.863898159285.issue23779@psf.upfronthosting.co.za> Message-ID: <1427894455.29.0.402129580767.issue23779@psf.upfronthosting.co.za> R. David Murray added the comment: Looks good to me, thanks. ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 15:23:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Apr 2015 13:23:11 +0000 Subject: [issue23838] linecache and MemoryError In-Reply-To: <1427887464.14.0.986179672993.issue23838@psf.upfronthosting.co.za> Message-ID: <1427894591.47.0.107276370592.issue23838@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: On other side, linecache tests already use updatecache(). Here is a patch with a test. ---------- Added file: http://bugs.python.org/file38783/linecache_memoryerror_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 15:28:33 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 13:28:33 +0000 Subject: [issue23838] linecache and MemoryError In-Reply-To: <1427887464.14.0.986179672993.issue23838@psf.upfronthosting.co.za> Message-ID: <1427894913.72.0.700667230657.issue23838@psf.upfronthosting.co.za> STINNER Victor added the comment: linecache_memoryerror_3.patch reviewed (comments on Rietveld). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 15:31:18 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 01 Apr 2015 13:31:18 +0000 Subject: [issue23833] email.header.Header folding modifies headers that include semi-colons In-Reply-To: <1427840786.4.0.777280344269.issue23833@psf.upfronthosting.co.za> Message-ID: <1427895078.58.0.67011948095.issue23833@psf.upfronthosting.co.za> R. David Murray added the comment: The header folding algorithm is...not all that smart. There's a better one in the new policies in email in python3, which does not have this problem (it does have a few others, but the plan is to treat them as bugs and fix them :) IMO this isn't worth fixing in Python2, but if you want to propose a patch I'll review it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 15:34:25 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 01 Apr 2015 13:34:25 +0000 Subject: [issue2211] Cookie.Morsel interface needs update In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za> Message-ID: <1427895265.48.0.438182212583.issue2211@psf.upfronthosting.co.za> R. David Murray added the comment: Heh, I thought it was closed. I guess my eyes were distracted by the 'fixed' resolution. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 15:40:30 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 01 Apr 2015 13:40:30 +0000 Subject: [issue23824] in-place addition of a shadowed class field In-Reply-To: <1427810483.28.0.753445482899.issue23824@psf.upfronthosting.co.za> Message-ID: <1427895630.4.0.518146296976.issue23824@psf.upfronthosting.co.za> R. David Murray added the comment: And I'm telling you that *this is how Python is designed*, and it is not going to change. Class attributes are *special*, for a reason. Please do not reopen this issue again. If you wish to pursue this further, the language design discussion forum is the python-ideas mailing list. Guido participates in that list; so, you can talk directly to the language designer about this if you wish. You aren't going to get a very warm reception by saying it is broken, though, because there is lots and lots of Python code that makes use of how class attributes work. And like I said they are special, so suggesting that the way other scopes work be changed is also pretty much a non-starter, I'm pretty sure. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 15:46:40 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 01 Apr 2015 13:46:40 +0000 Subject: [issue23484] SemLock acquire() keyword arg 'blocking' is invalid In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za> Message-ID: <1427896000.53.0.812595438979.issue23484@psf.upfronthosting.co.za> R. David Murray added the comment: behavior vs enhancment for doc changes is really pretty meaningless/arbitrary, IMO. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 15:53:59 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 13:53:59 +0000 Subject: [issue23837] read pipe transport tries to resume reading after loop is gone In-Reply-To: <1427882762.68.0.794378524046.issue23837@psf.upfronthosting.co.za> Message-ID: <1427896439.44.0.796013621962.issue23837@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, it looks like all pause_reading() and resume_reading() methods of transports check the status the transport (especially the _closing attribute), except two transports: _UnixReadPipeTransport and _SSLProtocolTransport. For _SSLProtocolTransport, I don't think that it matters because this transport is not used directly, but through _SelectorSslTransport or _ProactorSocketTransport and these transports already check the status. Here is a patch for _UnixReadPipeTransport, without patch yet. ---------- keywords: +patch Added file: http://bugs.python.org/file38784/read_pipe_pause_reading.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 15:59:10 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Apr 2015 13:59:10 +0000 Subject: [issue23821] test_pdb fails under -O In-Reply-To: <1427817253.47.0.758333559242.issue23821@psf.upfronthosting.co.za> Message-ID: <20150401135906.1911.84341@psf.io> Roundup Robot added the comment: New changeset 26778732099d by Serhiy Storchaka in branch '3.4': Issue #23821: Fixed test_pdb failure under -O. https://hg.python.org/cpython/rev/26778732099d New changeset 23442d957793 by Serhiy Storchaka in branch 'default': Issue #23821: Fixed test_pdb failure under -O. https://hg.python.org/cpython/rev/23442d957793 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 15:59:10 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Apr 2015 13:59:10 +0000 Subject: [issue23838] linecache and MemoryError In-Reply-To: <1427887464.14.0.986179672993.issue23838@psf.upfronthosting.co.za> Message-ID: <20150401135906.1911.21638@psf.io> Roundup Robot added the comment: New changeset d444496e714a by Serhiy Storchaka in branch '2.7': Issue #23838: linecache now clears the cache and returns an empty result on https://hg.python.org/cpython/rev/d444496e714a New changeset 88a0e6cd93c3 by Serhiy Storchaka in branch '3.4': Issue #23838: linecache now clears the cache and returns an empty result on https://hg.python.org/cpython/rev/88a0e6cd93c3 New changeset ab2326c801c2 by Serhiy Storchaka in branch 'default': Issue #23838: linecache now clears the cache and returns an empty result on https://hg.python.org/cpython/rev/ab2326c801c2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 16:00:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Apr 2015 14:00:28 +0000 Subject: [issue23821] test_pdb fails under -O In-Reply-To: <1427817253.47.0.758333559242.issue23821@psf.upfronthosting.co.za> Message-ID: <1427896828.86.0.0320427131027.issue23821@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your review Xavier. ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 16:01:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Apr 2015 14:01:34 +0000 Subject: [issue23838] linecache and MemoryError In-Reply-To: <1427887464.14.0.986179672993.issue23838@psf.upfronthosting.co.za> Message-ID: <1427896894.28.0.540367545194.issue23838@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your review Victor. Will look on OpenIndiana buildbot. ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 16:01:45 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 01 Apr 2015 14:01:45 +0000 Subject: [issue23756] Tighten definition of bytes-like objects In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za> Message-ID: <1427896905.09.0.892062765857.issue23756@psf.upfronthosting.co.za> R. David Murray added the comment: I found the explanation of C-contiguous vs Fortran-contiguous helpful (and I've programmed in both of those languages, though granted not much :). However, based on that it is not obvious to me why having a fortran-contiguous buffer prevents it from being used in the bytes-like object contexts (though granted the order might be surprising to someone who is not thinking about the memory ordering and just assuming C). I don't have much of an opinion on the other non-glossary-entry changes, but at a quick read I'm not sure how much clarity they add, if any. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 16:05:23 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 01 Apr 2015 14:05:23 +0000 Subject: [issue23756] Tighten definition of bytes-like objects In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za> Message-ID: <1427897123.8.0.438778786875.issue23756@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, and about the general concern: I agree that this issue was apparently about the glossary entry, so making other changes is suspect and at a minimum requires adding relevant people from the experts list to nosy to get proper review of other proposed changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 16:24:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Apr 2015 14:24:00 +0000 Subject: [issue23756] Tighten definition of bytes-like objects In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za> Message-ID: <1427898240.35.0.622116650114.issue23756@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What people are needed? The patch looks as great improvement to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 16:43:23 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 01 Apr 2015 14:43:23 +0000 Subject: [issue23756] Tighten definition of bytes-like objects In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za> Message-ID: <1427899403.71.0.549792246507.issue23756@psf.upfronthosting.co.za> R. David Murray added the comment: Stefan, since he's the current maintainer of the memoryview implementation. Fortunately he spotted the issue :) Maybe Antoine, too; he's done work in this area. I'll add him. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 17:06:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Apr 2015 15:06:10 +0000 Subject: [issue23756] Tighten definition of bytes-like objects In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za> Message-ID: <1427900770.11.0.0136028589775.issue23756@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue23376. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 17:14:19 2015 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 01 Apr 2015 15:14:19 +0000 Subject: [issue23830] Add AF_IUCV support to sockets In-Reply-To: <1427828484.47.0.0998681334057.issue23830@psf.upfronthosting.co.za> Message-ID: <1427901259.87.0.485174766878.issue23830@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Hi, First, please fill and submit a Contribution Agreement: https://www.python.org/psf/contrib/ Then about the patch: - This is a patch against Python2.7, which is frozen for new developments. This change will only be applied to python 3.5 or later. - There are some tab characters in the diff - Names are limited to 8 characters, but there is no check. - Names must be padded with spaces. This is done automatically in connect(), but these extra spaces should be removed in makesockaddr() so that the same names are returned. ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 17:31:05 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 01 Apr 2015 15:31:05 +0000 Subject: [issue23484] SemLock acquire() keyword arg 'blocking' is invalid In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za> Message-ID: <1427902265.6.0.44528229016.issue23484@psf.upfronthosting.co.za> Berker Peksag added the comment: I use "enhancement" for non-trivial documentation patches. Also, quoting from https://docs.python.org/devguide/triaging.html#type "Also used for improvements in the documentation and test suite and for other refactorings." In this case, your patch fixes a documentation issue and improving current documentation by documenting {Lock,RLock}.acquire() and release() methods properly (documentation improvements can go into bugfix branches). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 17:51:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Apr 2015 15:51:12 +0000 Subject: [issue23485] PEP 475: handle EINTR in the select and selectors module In-Reply-To: <1424352775.64.0.420442648443.issue23485@psf.upfronthosting.co.za> Message-ID: <20150401155107.113189.55803@psf.io> Roundup Robot added the comment: New changeset 65ac8e587bb0 by Victor Stinner in branch 'default': Issue #22117, issue #23485: Fix _PyTime_AsMilliseconds() and https://hg.python.org/cpython/rev/65ac8e587bb0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 17:51:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Apr 2015 15:51:12 +0000 Subject: [issue22117] Rewrite pytime.h to work on nanoseconds In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za> Message-ID: <20150401155106.113189.69127@psf.io> Roundup Robot added the comment: New changeset 65ac8e587bb0 by Victor Stinner in branch 'default': Issue #22117, issue #23485: Fix _PyTime_AsMilliseconds() and https://hg.python.org/cpython/rev/65ac8e587bb0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 17:52:34 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 01 Apr 2015 15:52:34 +0000 Subject: [issue23731] Implement PEP 488 In-Reply-To: <1426944831.0.0.593089874415.issue23731@psf.upfronthosting.co.za> Message-ID: <1427903554.74.0.854781430557.issue23731@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- hgrepos: +303 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 17:53:36 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 01 Apr 2015 15:53:36 +0000 Subject: [issue23731] Implement PEP 488 In-Reply-To: <1426944831.0.0.593089874415.issue23731@psf.upfronthosting.co.za> Message-ID: <1427903616.01.0.859271074175.issue23731@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- keywords: +patch Added file: http://bugs.python.org/file38785/be7d966b660a.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 17:57:54 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 01 Apr 2015 15:57:54 +0000 Subject: [issue23731] Implement PEP 488 In-Reply-To: <1426944831.0.0.593089874415.issue23731@psf.upfronthosting.co.za> Message-ID: <1427903874.72.0.656029744878.issue23731@psf.upfronthosting.co.za> Changes by Brett Cannon : Added file: http://bugs.python.org/file38786/8ce8e9b1f3e7.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 17:59:15 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 01 Apr 2015 15:59:15 +0000 Subject: [issue23731] Implement PEP 488 In-Reply-To: <1426944831.0.0.593089874415.issue23731@psf.upfronthosting.co.za> Message-ID: <1427903955.74.0.180777771623.issue23731@psf.upfronthosting.co.za> Changes by Brett Cannon : Removed file: http://bugs.python.org/file38785/be7d966b660a.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 18:02:37 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 01 Apr 2015 16:02:37 +0000 Subject: [issue23731] Implement PEP 488 In-Reply-To: <1426944831.0.0.593089874415.issue23731@psf.upfronthosting.co.za> Message-ID: <1427904157.44.0.104410708363.issue23731@psf.upfronthosting.co.za> Brett Cannon added the comment: Here is a patch that implements PEP 488 **except** for Windows installer stuff. I don't think the Windows changes need to block this patch going in, but I will need someone on Windows to help fix up PC/, PCbuild/, Tools/msi, Lib/distutils/command/bdist_msi.py, and Lib/distutils/command/bdist_wininst.py (if you just search for [pyo] you will find what needs an update). Otherwise if someone wants to give the patch a review you can feel free, else I will commit it at PyCon (do be aware that if you run tests under -O and -OO there are several failures that have nothing to do with this patch). ---------- nosy: +paul.moore, steve.dower, tim.golden, zach.ware stage: test needed -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 18:09:29 2015 From: report at bugs.python.org (Neale Ferguson) Date: Wed, 01 Apr 2015 16:09:29 +0000 Subject: [issue23830] Add AF_IUCV support to sockets In-Reply-To: <1427901259.87.0.485174766878.issue23830@psf.upfronthosting.co.za> Message-ID: Neale Ferguson added the comment: Thanks. Question/responses in-line On 4/1/15, 11:14 AM, "Amaury Forgeot d'Arc" wrote: > >Amaury Forgeot d'Arc added the comment: > >Hi, >First, please fill and submit a Contribution Agreement: >https://www.python.org/psf/contrib/ Done but I never got the email confirmation - it was not in my spam fold either. >Then about the patch: >- This is a patch against Python2.7, which is frozen for new >developments. This change will only be applied to python 3.5 or later. Understood. >- There are some tab characters in the diff Will fix >- Names are limited to 8 characters, but there is no check. I truncate, but I will add a check to be more programmer friendly >- Names must be padded with spaces. This is done automatically in >connect(), but these extra spaces should be removed in makesockaddr() so >that the same names are returned. Will do, I was going to let the caller strip() but I will do it here instead. Is there an existing strip routine that I could call rather than writing my own (trivial) stripper? Do I resubmit the patch in the bug/enhancement report I had created? Neale ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 18:17:23 2015 From: report at bugs.python.org (Matthias Klose) Date: Wed, 01 Apr 2015 16:17:23 +0000 Subject: [issue23842] SystemError: ../Objects/longobject.c:998: bad argument to internal function Message-ID: <1427905043.2.0.434822440378.issue23842@psf.upfronthosting.co.za> New submission from Matthias Klose: an unreleased version of cinder fails a test when run with python 2.7 from the branch. I don't have a test case yet, but looking at the error message and list of fixed issues after the 2.7.9 release, the fix for issue #23098 could be the culprit. FAIL: cinder.tests.test_utils.GetBlkdevMajorMinorTestCase.test_get_blkdev_major_minor_file cinder.tests.test_utils.GetBlkdevMajorMinorTestCase.test_get_blkdev_major_minor_file ---------------------------------------------------------------------- _StringException: Traceback (most recent call last): File "/build/buildd/cinder-2015.1~b3/cinder/tests/test_utils.py", line 721, in test_get_blkdev_major_minor_file dev = self._test_get_blkdev_major_minor_file('/dev/made_up_disk1') File "/usr/lib/python2.7/dist-packages/mock.py", line 1210, in patched return func(*args, **keywargs) File "/build/buildd/cinder-2015.1~b3/cinder/tests/test_utils.py", line 712, in _test_get_blkdev_major_minor_file dev = utils.get_blkdev_major_minor(test_file) File "/build/buildd/cinder-2015.1~b3/cinder/utils.py", line 656, in get_blkdev_major_minor return get_blkdev_major_minor(devpath, False) File "/build/buildd/cinder-2015.1~b3/cinder/utils.py", line 645, in get_blkdev_major_minor return '%d:%d' % (os.major(st.st_rdev), os.minor(st.st_rdev)) SystemError: ../Objects/longobject.c:998: bad argument to internal function Traceback (most recent call last): _StringException: Empty attachments: stderr stdout ---------- components: Extension Modules messages: 239826 nosy: doko, serhiy.storchaka priority: normal severity: normal status: open title: SystemError: ../Objects/longobject.c:998: bad argument to internal function versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 18:25:43 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 01 Apr 2015 16:25:43 +0000 Subject: [issue23830] Add AF_IUCV support to sockets In-Reply-To: <1427828484.47.0.0998681334057.issue23830@psf.upfronthosting.co.za> Message-ID: <1427905543.45.0.296795496065.issue23830@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The CA ack is a * added after your name here. May take a week. If you are asking whether to submit a new patch against 3.5, with suggested fixes, yes, please do . ---------- nosy: +terry.reedy stage: -> patch review versions: +Python 3.5 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 18:29:55 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 16:29:55 +0000 Subject: [issue23842] SystemError: ../Objects/longobject.c:998: bad argument to internal function In-Reply-To: <1427905043.2.0.434822440378.issue23842@psf.upfronthosting.co.za> Message-ID: <1427905795.72.0.696312492504.issue23842@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 18:32:27 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 16:32:27 +0000 Subject: [issue23842] SystemError: ../Objects/longobject.c:998: bad argument to internal function In-Reply-To: <1427905043.2.0.434822440378.issue23842@psf.upfronthosting.co.za> Message-ID: <1427905947.47.0.866881886291.issue23842@psf.upfronthosting.co.za> STINNER Victor added the comment: > return '%d:%d' % (os.major(st.st_rdev), os.minor(st.st_rdev)) Can you check if the error comes from os.major() or os.minor(), and please provide the value of st_rdev? You can modify the unit test to catch SystemError and raise a new exception with more information. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 18:51:54 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Apr 2015 16:51:54 +0000 Subject: [issue23836] PEP 475: Enhance faulthandler to handle better reentrant calls In-Reply-To: <1427881439.29.0.554454019096.issue23836@psf.upfronthosting.co.za> Message-ID: <20150401165151.1924.99564@psf.io> Roundup Robot added the comment: New changeset 60e001ec141d by Victor Stinner in branch 'default': Issue #23836: Add _Py_write_noraise() function https://hg.python.org/cpython/rev/60e001ec141d New changeset d9b9e2a68e7c by Victor Stinner in branch 'default': Issue #23836: Document functions releasing the GIL in fileutils.c https://hg.python.org/cpython/rev/d9b9e2a68e7c New changeset 12e065efc821 by Victor Stinner in branch 'default': Issue #23836: Use _Py_write_noraise() to retry on EINTR in trip_signal() of https://hg.python.org/cpython/rev/12e065efc821 New changeset e3c97621d8b4 by Victor Stinner in branch 'default': Issue #23836: Use _Py_write_noraise() to retry on EINTR in child_exec() of https://hg.python.org/cpython/rev/e3c97621d8b4 New changeset 29ab05c5e9dc by Victor Stinner in branch 'default': Issue #23836: Use _Py_write_noraise() to retry on EINTR in _Py_DumpTraceback() https://hg.python.org/cpython/rev/29ab05c5e9dc New changeset f07b855afbb2 by Victor Stinner in branch 'default': Issue #23836: Fix the faulthandler module to handle reentrant calls https://hg.python.org/cpython/rev/f07b855afbb2 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 18:52:11 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 16:52:11 +0000 Subject: [issue23836] PEP 475: Enhance faulthandler to handle better reentrant calls In-Reply-To: <1427881439.29.0.554454019096.issue23836@psf.upfronthosting.co.za> Message-ID: <1427907131.86.0.623258951279.issue23836@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 19:47:47 2015 From: report at bugs.python.org (Matthias Klose) Date: Wed, 01 Apr 2015 17:47:47 +0000 Subject: [issue23842] SystemError: ../Objects/longobject.c:998: bad argument to internal function In-Reply-To: <1427905043.2.0.434822440378.issue23842@psf.upfronthosting.co.za> Message-ID: <1427910467.72.0.559977499751.issue23842@psf.upfronthosting.co.za> Matthias Klose added the comment: so the culprit is an "optimization": "Committed to 2.7 with small change: stat() and makedev() should return int instead of long if possible." the test case however expects a long. st_dev is now not always a long, but an int or long depending on the value. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 19:49:52 2015 From: report at bugs.python.org (John Hergenroeder) Date: Wed, 01 Apr 2015 17:49:52 +0000 Subject: [issue23796] BufferedReader.peek() crashes if closed In-Reply-To: <1427502590.02.0.665422119627.issue23796@psf.upfronthosting.co.za> Message-ID: <1427910592.51.0.431277891558.issue23796@psf.upfronthosting.co.za> John Hergenroeder added the comment: Thanks for the feedback, Berker! I've added a test case that closes a buffered reader and then attempts to both peek and read1 it. I tacked it onto the end of the BufferedReaderTest class in test_io, but let me know if there's a better place to put it. I've also added the check to read1 -- good catch. I opted to add it before the check that the argument to read1 is 0 -- my assumption is that a 0-length read on a closed BufferReader should fail, not return an empty bytestring. Thanks again for the feedback! ---------- Added file: http://bugs.python.org/file38787/23796_fix_with_tests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 19:57:27 2015 From: report at bugs.python.org (Matthias Klose) Date: Wed, 01 Apr 2015 17:57:27 +0000 Subject: [issue23842] SystemError: ../Objects/longobject.c:998: bad argument to internal function In-Reply-To: <1427905043.2.0.434822440378.issue23842@psf.upfronthosting.co.za> Message-ID: <1427911047.61.0.703674633488.issue23842@psf.upfronthosting.co.za> Matthias Klose added the comment: no, simpler: >>> import os >>> os.minor(os.makedev(8,65)) Traceback (most recent call last): File "", line 1, in SystemError: ../Objects/longobject.c:998: bad argument to internal function >>> os.major(os.makedev(8,65)) Traceback (most recent call last): File "", line 1, in SystemError: ../Objects/longobject.c:998: bad argument to internal function ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 19:59:17 2015 From: report at bugs.python.org (Matthias Klose) Date: Wed, 01 Apr 2015 17:59:17 +0000 Subject: [issue23842] SystemError: ../Objects/longobject.c:998: bad argument to internal function In-Reply-To: <1427905043.2.0.434822440378.issue23842@psf.upfronthosting.co.za> Message-ID: <1427911157.6.0.346838523495.issue23842@psf.upfronthosting.co.za> Matthias Klose added the comment: casting to a long works ... >>> os.major(long(os.makedev(8,65))) 8 so maybe revert that optimization for the released branches? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 20:07:55 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 01 Apr 2015 18:07:55 +0000 Subject: [issue23842] SystemError: ../Objects/longobject.c:998: bad argument to internal function In-Reply-To: <1427905043.2.0.434822440378.issue23842@psf.upfronthosting.co.za> Message-ID: <1427911675.64.0.0965888971478.issue23842@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 20:25:06 2015 From: report at bugs.python.org (Dan O'Reilly) Date: Wed, 01 Apr 2015 18:25:06 +0000 Subject: [issue6766] Cannot modify dictionaries inside dictionaries using Managers from multiprocessing In-Reply-To: <1251049590.58.0.809281249474.issue6766@psf.upfronthosting.co.za> Message-ID: <1427912706.86.0.58288700505.issue6766@psf.upfronthosting.co.za> Changes by Dan O'Reilly : ---------- nosy: +dan.oreilly versions: +Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 20:30:56 2015 From: report at bugs.python.org (Matthias Klose) Date: Wed, 01 Apr 2015 18:30:56 +0000 Subject: [issue23842] SystemError: ../Objects/longobject.c:998: bad argument to internal function In-Reply-To: <1427905043.2.0.434822440378.issue23842@psf.upfronthosting.co.za> Message-ID: <1427913056.71.0.21599001597.issue23842@psf.upfronthosting.co.za> Changes by Matthias Klose : ---------- nosy: +benjamin.peterson priority: normal -> release blocker _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 20:32:18 2015 From: report at bugs.python.org (John Nagle) Date: Wed, 01 Apr 2015 18:32:18 +0000 Subject: [issue23843] ssl.wrap_socket doesn't handle virtual TLS hosts Message-ID: <1427913138.81.0.946174755254.issue23843@psf.upfronthosting.co.za> New submission from John Nagle: ssl.wrap_socket() always uses the SSL certificate associated with the raw IP address, rather than using the server_host feature of TLS. Even when wrap_socket is used before calling "connect(port, host)", the "host" parameter isn't used by TLS. To get proper TLS behavior (which only works in recent Python versions), it's necessary to create an SSLContext, then use context.wrap_socket(sock, server_hostname="example.com") This behavior is backwards-compatible (the SSL module didn't talk TLS until very recently) but confusing. The documentation does not reflect this difference. There's a lot of old code and online advice which suggests using ssl.wrap_socket(). It works until you hit a virtual host with TLS support. Then you get the wrong server cert and an unexpected "wrong host" SSL error. Possible fixes: 1. Deprecate ssl.wrap_socket(), and modify the documentation to tell users to always use context.wrap_socket(). 2. Add a "server_hostname" parameter to ssl.wrap_socket(). It doesn't accept that parameter; only context.wrap_socket() does. Modify documentation accordingly. ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 239834 nosy: docs at python, nagle priority: normal severity: normal status: open title: ssl.wrap_socket doesn't handle virtual TLS hosts versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 20:41:40 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 01 Apr 2015 18:41:40 +0000 Subject: [issue23731] Implement PEP 488 In-Reply-To: <1426944831.0.0.593089874415.issue23731@psf.upfronthosting.co.za> Message-ID: <1427913700.88.0.165221164747.issue23731@psf.upfronthosting.co.za> Steve Dower added the comment: I don't actually see any essential changes. The bdist_wininst and bdist_msi changes are just for usage help, and presumably they'll go from "do not compile .py to .pyo (optimized)" to "do not compile .py to optimized .pyc". I'd prefer to leave the .pyo file association in the installer, since it will affect previous installations. The only change I see in PC/ is PC/getpathp.c, which is just removing a condition on "o" vs "c", and I don't see anything in PCBuild/ that really needs fixing. (Removing the cleanup code is unnecessary and leaving it in may help make sure the buildbots clean up any old .pyo files after we stop creating them.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 21:02:16 2015 From: report at bugs.python.org (Neale Ferguson) Date: Wed, 01 Apr 2015 19:02:16 +0000 Subject: [issue23830] Add AF_IUCV support to sockets In-Reply-To: <1427828484.47.0.0998681334057.issue23830@psf.upfronthosting.co.za> Message-ID: <1427914936.21.0.214867828475.issue23830@psf.upfronthosting.co.za> Neale Ferguson added the comment: Updated patch - Removes tabs - Strips name/user/node returned by connect - Checks lengths of name/user/node ---------- Added file: http://bugs.python.org/file38788/af_iucv.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 21:19:19 2015 From: report at bugs.python.org (John Nagle) Date: Wed, 01 Apr 2015 19:19:19 +0000 Subject: [issue23588] Errno conflicts in ssl.SSLError In-Reply-To: <1425528608.86.0.380656858337.issue23588@psf.upfronthosting.co.za> Message-ID: <1427915959.1.0.583214254583.issue23588@psf.upfronthosting.co.za> John Nagle added the comment: If SSL error reporting is getting some attention, something should be done to provide better text messages for the SSL errors. All certificate verify exceptions return the string "certificate verify failed (_ssl.c:581)". The line number in _ssl.c is not particularly useful to end users. OpenSSL has more specific messages, but they're not making it to the Python level. 'python ssl "certificate verify failed"' has 17,000 hits in Google, which indicates users need more help dealing with this class of error. ---------- nosy: +nagle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 21:21:35 2015 From: report at bugs.python.org (Neale Ferguson) Date: Wed, 01 Apr 2015 19:21:35 +0000 Subject: [issue23830] Add AF_IUCV support to sockets In-Reply-To: <1427828484.47.0.0998681334057.issue23830@psf.upfronthosting.co.za> Message-ID: <1427916095.4.0.053883399613.issue23830@psf.upfronthosting.co.za> Neale Ferguson added the comment: Corrected a length error in the strip routine Initialized the end of string indicator ---------- Added file: http://bugs.python.org/file38789/af_iucv.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 21:23:25 2015 From: report at bugs.python.org (Paul Moore) Date: Wed, 01 Apr 2015 19:23:25 +0000 Subject: [issue23731] Implement PEP 488 In-Reply-To: <1426944831.0.0.593089874415.issue23731@psf.upfronthosting.co.za> Message-ID: <1427916205.95.0.764889065888.issue23731@psf.upfronthosting.co.za> Paul Moore added the comment: A few minor review comments. Nothing substantial, tbh. Looks good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 21:43:32 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 19:43:32 +0000 Subject: [issue23796] BufferedReader.peek() crashes if closed In-Reply-To: <1427910592.51.0.431277891558.issue23796@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: John Hergenroeder added the comment: > my assumption is that a 0-length read on a closed BufferReader should fail, not return an empty bytestring. I agree. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 21:44:48 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 19:44:48 +0000 Subject: [issue23842] SystemError: ../Objects/longobject.c:998: bad argument to internal function In-Reply-To: <1427913056.75.0.413757284526.issue23842@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Obviously, an unit test is missing ;) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 22:08:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Apr 2015 20:08:04 +0000 Subject: [issue23842] SystemError: ../Objects/longobject.c:998: bad argument to internal function In-Reply-To: <1427905043.2.0.434822440378.issue23842@psf.upfronthosting.co.za> Message-ID: <1427918884.33.3.9753694137e-05.issue23842@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Oh, this is a catch when backport to 2.7. Here is a patch that makes dev_t converter to support int and int-like types. Added tests (surprisingly there were no tests for makedev/major/minor at all). > so maybe revert that optimization for the released branches? It is not an optimization, but required for backward compatibility. Third-party code can expect int and only int. ---------- keywords: +patch Added file: http://bugs.python.org/file38790/posix_dev_t_converter.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 22:08:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 01 Apr 2015 20:08:48 +0000 Subject: [issue23842] SystemError: ../Objects/longobject.c:998: bad argument to internal function In-Reply-To: <1427905043.2.0.434822440378.issue23842@psf.upfronthosting.co.za> Message-ID: <1427918928.65.0.915893995504.issue23842@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 22:14:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Apr 2015 20:14:51 +0000 Subject: [issue23834] socketmodule.c: add sock_call() to fix how the timeout is recomputed In-Reply-To: <1427842506.28.0.704301607448.issue23834@psf.upfronthosting.co.za> Message-ID: <20150401201448.19530.21212@psf.io> Roundup Robot added the comment: New changeset 358a2bcd0d0b by Victor Stinner in branch 'default': Issue #23834: Add sock_call() helper function https://hg.python.org/cpython/rev/358a2bcd0d0b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 22:30:15 2015 From: report at bugs.python.org (Robert Collins) Date: Wed, 01 Apr 2015 20:30:15 +0000 Subject: [issue23839] Clear caches after every test In-Reply-To: <1427887841.84.0.393130432881.issue23839@psf.upfronthosting.co.za> Message-ID: <1427920215.44.0.606013546455.issue23839@psf.upfronthosting.co.za> Robert Collins added the comment: I'd like to see a definite profile of a bloated stdlib test process before we assume we know the issue - the usual leak I see in test code is used test objects, and I'm not sure we've ported the usual fix for that into unittest yet (we should). As far as linecache is concerned, we shouldn't be triggering linecache population except when a traceback is actually rendered, and so on a passing test run there should be little hitting it at all outside of tests that actually test rendering of tracebacks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 22:31:47 2015 From: report at bugs.python.org (Robert Collins) Date: Wed, 01 Apr 2015 20:31:47 +0000 Subject: [issue23839] Clear caches after every test In-Reply-To: <1427887841.84.0.393130432881.issue23839@psf.upfronthosting.co.za> Message-ID: <1427920307.46.0.106977801514.issue23839@psf.upfronthosting.co.za> Robert Collins added the comment: +1 on moving to the summary classes rather than actual tracebacks in unittest. (Or perhaps even just serialised tracebacks like we do in testtools). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 22:53:33 2015 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Wed, 01 Apr 2015 20:53:33 +0000 Subject: [issue23844] test_ssl: fails on recent libressl version with BAD_DH_P_LENGTH Message-ID: <1427921613.92.0.742190312016.issue23844@psf.upfronthosting.co.za> New submission from C?dric Krier: Since [1], libressl fails if DH keys are too small (<1024). Here is a patch to increase the dh keys to 1024 for the tests. [1] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/src/ssl/s3_clnt.c?rev=1.108&content-type=text/x-cvsweb-markup ---------- files: dh1024.patch keywords: patch messages: 239846 nosy: ced priority: normal severity: normal status: open title: test_ssl: fails on recent libressl version with BAD_DH_P_LENGTH Added file: http://bugs.python.org/file38791/dh1024.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 22:54:10 2015 From: report at bugs.python.org (shiyao.ma) Date: Wed, 01 Apr 2015 20:54:10 +0000 Subject: [issue23840] tokenize.open() leaks an open binary file on TextIOWrapper error In-Reply-To: <1427889153.26.0.649877902408.issue23840@psf.upfronthosting.co.za> Message-ID: <1427921650.51.0.20123331914.issue23840@psf.upfronthosting.co.za> shiyao.ma added the comment: ITSM it's not the TextIOWrapper but the detect_encoding fails and throws an error. So I wrapped a try/catch block around that. ---------- keywords: +patch nosy: +introom Added file: http://bugs.python.org/file38792/tokenize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 23:20:05 2015 From: report at bugs.python.org (Matt Chung) Date: Wed, 01 Apr 2015 21:20:05 +0000 Subject: [issue23840] tokenize.open() leaks an open binary file on TextIOWrapper error In-Reply-To: <1427889153.26.0.649877902408.issue23840@psf.upfronthosting.co.za> Message-ID: <1427923205.35.0.923106304345.issue23840@psf.upfronthosting.co.za> Matt Chung added the comment: Comparing to introom. Any reason to not wrap the entire in a try? Attached patch. ---------- nosy: +itsmemattchung Added file: http://bugs.python.org/file38793/issue23840.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 23:23:24 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 01 Apr 2015 21:23:24 +0000 Subject: [issue23834] socketmodule.c: add sock_call() to fix how the timeout is recomputed In-Reply-To: <1427842506.28.0.704301607448.issue23834@psf.upfronthosting.co.za> Message-ID: <20150401212320.14209.92064@psf.io> Roundup Robot added the comment: New changeset b3c7ae99b8e0 by Victor Stinner in branch 'default': Issue #23834: Modify socket.sendall() to reuse sock_call() with https://hg.python.org/cpython/rev/b3c7ae99b8e0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 23:32:30 2015 From: report at bugs.python.org (Matt Chung) Date: Wed, 01 Apr 2015 21:32:30 +0000 Subject: [issue23840] tokenize.open() leaks an open binary file on TextIOWrapper error In-Reply-To: <1427889153.26.0.649877902408.issue23840@psf.upfronthosting.co.za> Message-ID: <1427923950.07.0.685476207127.issue23840@psf.upfronthosting.co.za> Matt Chung added the comment: Curious, @haypo, are you looking for a new unittest or a function within an existing unit test? Perhaps go under TestTokenize? 1227 def test_main(): 1228 from test import test_tokenize 1229 support.run_doctest(test_tokenize, True) 1230 support.run_unittest(TestTokenizerAdheresToPep0263) 1231 support.run_unittest(Test_Tokenize) 1232 support.run_unittest(TestDetectEncoding) 1233 support.run_unittest(TestTokenize) 1234 support.run_unittest(UntokenizeTest) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 23:37:20 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 01 Apr 2015 21:37:20 +0000 Subject: [issue23756] Tighten definition of bytes-like objects In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za> Message-ID: <1427924240.96.0.560182650627.issue23756@psf.upfronthosting.co.za> Martin Panter added the comment: I will to pull the stdtypes.rst changes out into a separate patch and issue, if that will make review easier. I think they are an improvement because the previous version was incorrect and misleading, but they are probably not necessary for people to understand what a C-contiguous bytes-like object is. I don?t think ?flattened length? is explicitly defined anywhere, but it is already used in the memoryview() documentation and elsewhere. I took it to mean the number of elements in the nested list, if you ignore the fact that it is nested; i.e. ignore the extra "[" and "]" delimiters in the repr(), and just count the other values inside them. The reason for defining C-contiguous was that I originally understood ?contiguous? to be much more general than what seems to be meant. I assumed both memoryview(contiguous)[::-1] and a 2?2?2 array with stride=[4, 1, 2] would be contiguous, although neither have the C or Fortran array layout. I think we need to define C-contiguous well enough for people to understand which standard Python objects are bytes-like objects. Maybe not Fortran-contiguous, because it doesn?t seem relevant to standard Python objects. Considering Serhiy asked if array.array() is always C-contiguous, I may not have done enough to explain that. (I think the answer is always yes.) David: If a Fortran array was allowed in a bytes-like context without memory copying, the order of the array elements would differ from the order returned by the meoryview.tobytes() method, which essentially is defined to copy them out in C-array or flattend-tolist() order. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 1 23:40:48 2015 From: report at bugs.python.org (Matt Chung) Date: Wed, 01 Apr 2015 21:40:48 +0000 Subject: [issue23840] tokenize.open() leaks an open binary file on TextIOWrapper error In-Reply-To: <1427889153.26.0.649877902408.issue23840@psf.upfronthosting.co.za> Message-ID: <1427924448.19.0.206433010858.issue23840@psf.upfronthosting.co.za> Matt Chung added the comment: I believe it goes here under the TestTokenize class. Going to give it a shot now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 00:16:19 2015 From: report at bugs.python.org (ddvento@ucar.edu) Date: Wed, 01 Apr 2015 22:16:19 +0000 Subject: [issue9026] argparse subcommands not printed in the same order they were added In-Reply-To: <1276856679.08.0.64136890627.issue9026@psf.upfronthosting.co.za> Message-ID: <1427926579.9.0.154640940821.issue9026@psf.upfronthosting.co.za> ddvento at ucar.edu added the comment: This problem is occurring again in python 2.7.7, can we open it again? ---------- nosy: +ddvento at ucar.edu _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 00:18:33 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 22:18:33 +0000 Subject: [issue23840] tokenize.open() leaks an open binary file on TextIOWrapper error In-Reply-To: <1427889153.26.0.649877902408.issue23840@psf.upfronthosting.co.za> Message-ID: <1427926713.32.0.983311581307.issue23840@psf.upfronthosting.co.za> STINNER Victor added the comment: > ITSM it's not the TextIOWrapper but the detect_encoding fails and throws an error. Oh, right. But TextIOWrapper can fail for differen reasons. For example, CTRL+c may send KeyboardInterrupt. Try for example: with unittest.mock.patch.object(tokenize, '_builtin_open') as mock_open: mock_file = mock_open.return_value mock_file.tell.side_effect = OSError mock_file.readline.return_value = b'' tokenize.open(fn) This example raises an OSError in TextIOWrapper on file.tell(), and file.close() is not called. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 00:19:13 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 01 Apr 2015 22:19:13 +0000 Subject: [issue23796] BufferedReader.peek() crashes if closed In-Reply-To: <1427502590.02.0.665422119627.issue23796@psf.upfronthosting.co.za> Message-ID: <1427926753.82.0.802551236111.issue23796@psf.upfronthosting.co.za> Martin Panter added the comment: New patch with tests looks good to me. The BufferedReaderTest class is a sensible place for the test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 00:21:02 2015 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Wed, 01 Apr 2015 22:21:02 +0000 Subject: [issue23845] test_ssl: fails on recent libressl with SSLV3_ALERT_HANDSHAKE_FAILURE Message-ID: <1427926862.2.0.277939784676.issue23845@psf.upfronthosting.co.za> New submission from C?dric Krier: SSLv3 has been deactivated by default [1], as stated in the commit message it can be reactivated by clearing the option. So here is a patch that reactivate it in the test when needed. [1] http://marc.info/?l=openbsd-cvs&m=141339479327258&w=2 ---------- files: sslv3.patch keywords: patch messages: 239856 nosy: ced priority: normal severity: normal status: open title: test_ssl: fails on recent libressl with SSLV3_ALERT_HANDSHAKE_FAILURE Added file: http://bugs.python.org/file38794/sslv3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 00:25:23 2015 From: report at bugs.python.org (shiyao.ma) Date: Wed, 01 Apr 2015 22:25:23 +0000 Subject: [issue23840] tokenize.open() leaks an open binary file on TextIOWrapper error In-Reply-To: <1427926713.32.0.983311581307.issue23840@psf.upfronthosting.co.za> Message-ID: shiyao.ma added the comment: On Wed, Apr 1, 2015 at 6:18 PM, STINNER Victor wrote: > Oh, right. But TextIOWrapper can fail for differen reasons. For example, CTRL+c may send KeyboardInterrupt. Yes. Any comment on the test? I wil update a second patch. Regards. -- ????????????????http://introo.me? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 00:26:40 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 22:26:40 +0000 Subject: [issue23840] tokenize.open() leaks an open binary file on TextIOWrapper error In-Reply-To: <1427889153.26.0.649877902408.issue23840@psf.upfronthosting.co.za> Message-ID: <1427927200.73.0.507960410361.issue23840@psf.upfronthosting.co.za> STINNER Victor added the comment: > Yes. Any comment on the test? Yes, as I wrote, I reviewed patches. You may get a notification by email. Anyway, it's here: http://bugs.python.org/review/23840/diff/14417/Lib/test/test_tokenize.py (I also commented tokenize.py) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 00:37:07 2015 From: report at bugs.python.org (STINNER Victor) Date: Wed, 01 Apr 2015 22:37:07 +0000 Subject: [issue23834] socketmodule.c: add sock_call() to fix how the timeout is recomputed In-Reply-To: <1427842506.28.0.704301607448.issue23834@psf.upfronthosting.co.za> Message-ID: <1427927827.7.0.949805053036.issue23834@psf.upfronthosting.co.za> STINNER Victor added the comment: Snow Leopard doesn't like me (or the opposite?), the changeset 358a2bcd0d0b introduced a regression. I'm unable to reproduce, I ran test_socket on Linux (3.18), Mac OS X (Yosemite, Mac OS X 10.10) and FreeBSD (10). I don't see a significant difference in sock_sendmsg() http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/2896/steps/test/logs/stdio ====================================================================== ERROR: testSendmsgTimeout (test.test_socket.SendmsgTCPTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_socket.py", line 266, in _tearDown raise exc File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_socket.py", line 278, in clientRun test_func() File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_socket.py", line 2224, in _testSendmsgTimeout self.sendmsgToServer([b"a"*512]) File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_socket.py", line 1913, in sendmsgToServer *(args + self.sendmsg_to_server_defaults[len(args):])) BrokenPipeError: [Errno 32] Broken pipe ====================================================================== FAIL: testSendmsgTimeout (test.test_socket.SendmsgTCPTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_socket.py", line 2217, in testSendmsgTimeout self.assertTrue(self.misc_event.wait(timeout=self.fail_timeout)) AssertionError: False is not true ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 00:46:39 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 01 Apr 2015 22:46:39 +0000 Subject: [issue23376] getargs.c: redundant C-contiguity check In-Reply-To: <1422879437.88.0.730176140595.issue23376@psf.upfronthosting.co.za> Message-ID: <1427928399.77.0.244057095634.issue23376@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 01:30:47 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 01 Apr 2015 23:30:47 +0000 Subject: [issue19511] lib2to3 Grammar file is no longer a Python 3 superset In-Reply-To: <1383742611.34.0.802324885429.issue19511@psf.upfronthosting.co.za> Message-ID: <1427931047.44.0.635960987381.issue19511@psf.upfronthosting.co.za> Gregory P. Smith added the comment: This is blocking Python auto formatters from working properly on Python 3 syntax code. For example: https://github.com/google/yapf/issues/61 ---------- assignee: -> gregory.p.smith nosy: +gregory.p.smith priority: low -> normal _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 01:31:30 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 01 Apr 2015 23:31:30 +0000 Subject: [issue19511] lib2to3 Grammar file is no longer a Python 3 superset In-Reply-To: <1383742611.34.0.802324885429.issue19511@psf.upfronthosting.co.za> Message-ID: <1427931090.58.0.931343787281.issue19511@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 01:31:44 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 01 Apr 2015 23:31:44 +0000 Subject: [issue19511] lib2to3 Grammar file is no longer a Python 3 superset In-Reply-To: <1383742611.34.0.802324885429.issue19511@psf.upfronthosting.co.za> Message-ID: <1427931104.89.0.869381719554.issue19511@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 01:39:37 2015 From: report at bugs.python.org (Matt Chung) Date: Wed, 01 Apr 2015 23:39:37 +0000 Subject: [issue23840] tokenize.open() leaks an open binary file on TextIOWrapper error In-Reply-To: <1427889153.26.0.649877902408.issue23840@psf.upfronthosting.co.za> Message-ID: <1427931577.04.0.535225037683.issue23840@psf.upfronthosting.co.za> Matt Chung added the comment: Updated patch based off of haypo's comment. Changed "except Exception as err:" -> "except" ---------- Added file: http://bugs.python.org/file38795/tokenize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 01:54:08 2015 From: report at bugs.python.org (shiyao.ma) Date: Wed, 01 Apr 2015 23:54:08 +0000 Subject: [issue23840] tokenize.open() leaks an open binary file on TextIOWrapper error In-Reply-To: <1427889153.26.0.649877902408.issue23840@psf.upfronthosting.co.za> Message-ID: <1427932448.39.0.975258031483.issue23840@psf.upfronthosting.co.za> shiyao.ma added the comment: Based upon the previous review. Catch the TextWrapper, move the test into a function. ---------- Added file: http://bugs.python.org/file38796/tokenizeV2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 01:56:39 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 01 Apr 2015 23:56:39 +0000 Subject: [issue12319] [http.client] HTTPConnection.putrequest not support "chunked" Transfer-Encodings to send data In-Reply-To: <1307875633.83.0.874379254828.issue12319@psf.upfronthosting.co.za> Message-ID: <1427932599.04.0.495686104656.issue12319@psf.upfronthosting.co.za> Changes by Demian Brecht : Added file: http://bugs.python.org/file38797/issue12319_5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 02:05:06 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 02 Apr 2015 00:05:06 +0000 Subject: [issue22671] Typo in class io.BufferedIOBase docs In-Reply-To: <1413711352.27.0.0253692424247.issue22671@psf.upfronthosting.co.za> Message-ID: <1427933106.54.0.730178038115.issue22671@psf.upfronthosting.co.za> Martin Panter added the comment: read-defaults.v3.patch: * Split off test_RawIOBase_readall() * Changed BufferedIOBase tests to matrix of tuples * Added tests for empty buffer * Test that unused part of buffer remains untouched ---------- Added file: http://bugs.python.org/file38798/read-defaults.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 02:09:46 2015 From: report at bugs.python.org (Matt Chung) Date: Thu, 02 Apr 2015 00:09:46 +0000 Subject: [issue23840] tokenize.open() leaks an open binary file on TextIOWrapper error In-Reply-To: <1427889153.26.0.649877902408.issue23840@psf.upfronthosting.co.za> Message-ID: <1427933386.71.0.457630733124.issue23840@psf.upfronthosting.co.za> Matt Chung added the comment: Based off of storchaka's comment, moving the ---------- Added file: http://bugs.python.org/file38799/tokenize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 02:47:57 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Apr 2015 00:47:57 +0000 Subject: [issue23844] test_ssl: fails on recent libressl version with BAD_DH_P_LENGTH In-Reply-To: <1427921613.92.0.742190312016.issue23844@psf.upfronthosting.co.za> Message-ID: <1427935677.53.0.818261280045.issue23844@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the patch. It should probably also remove the old file, unless it's also used somewhere else? ---------- nosy: +pitrou stage: -> patch review versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 02:52:16 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Apr 2015 00:52:16 +0000 Subject: [issue23843] ssl.wrap_socket doesn't handle virtual TLS hosts In-Reply-To: <1427913138.81.0.946174755254.issue23843@psf.upfronthosting.co.za> Message-ID: <1427935936.06.0.694167202105.issue23843@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Not sure why you're using wrap_socket() directly. Most of the time you should be using a higher-level library instead (for example a HTTP(S) library). In any case, the doc already mentions that "Starting from Python 3.2, it can be more flexible to use SSLContext.wrap_socket() instead". I leave this open in case other people feel positively about it. ---------- nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 03:13:42 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 02 Apr 2015 01:13:42 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1427937222.89.0.708222836537.issue16991@psf.upfronthosting.co.za> Antoine Pitrou added the comment: >From a cursory glance, I still think this is the wrong approach. There's a lot of complication due to the simple fact that it is subclassing from dict (and therefore trying to be ABI-compatible, kind of). The linked list scheme should be much simpler (perhaps it shouldn't be a linked list at all, actually: see Raymond's recent proposal). I understand a lot of work has gone into it, but I'm against the current proposal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 03:23:18 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Apr 2015 01:23:18 +0000 Subject: [issue23834] socketmodule.c: add sock_call() to fix how the timeout is recomputed In-Reply-To: <1427842506.28.0.704301607448.issue23834@psf.upfronthosting.co.za> Message-ID: <20150402012315.7496.49408@psf.io> Roundup Robot added the comment: New changeset 920b700d9509 by Victor Stinner in branch 'default': Issue #23834: Fix sock_call(), set deadline_initialized to recompute the timeout https://hg.python.org/cpython/rev/920b700d9509 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 03:32:51 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 02 Apr 2015 01:32:51 +0000 Subject: [issue23738] Clarify documentation of positional-only default values In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za> Message-ID: <1427938371.64.0.121359072322.issue23738@psf.upfronthosting.co.za> Martin Panter added the comment: pos-defaults.v2.patch includes the results of ?make clinic? to fix the doc strings. Is there a consensus to use PEP 457?s slash ?/? notation? At one point I think I saw Serhiy was concerned that it might be confusing. ---------- Added file: http://bugs.python.org/file38800/pos-defaults.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 04:10:05 2015 From: report at bugs.python.org (Wei Wu) Date: Thu, 02 Apr 2015 02:10:05 +0000 Subject: [issue23566] RFE: faulthandler.register() should support file descriptors In-Reply-To: <1425340815.09.0.0278934920259.issue23566@psf.upfronthosting.co.za> Message-ID: <1427940605.62.0.901846942516.issue23566@psf.upfronthosting.co.za> Wei Wu added the comment: @haypo, would you review issue23566_fd_tests_v2.patch? It's been a time since the last update of it. However I think the fd tests on windows is just fine to be skipped. So what's the next plan? Shall we continue to work on it or just resolve this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 04:12:05 2015 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Apr 2015 02:12:05 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1427940725.95.0.596580972468.issue16991@psf.upfronthosting.co.za> Eric Snow added the comment: Thanks for speaking up, Antoine. Keep in mind that a C implementation of OrderedDict has a strict compatibility requirement with the existing pure Python one. The Python implementation subclasses dict so the C implementation must as well. I agree that it would be simpler otherwise. It would have saved me a lot of headache! As to the linked list implementation, it does the job. I'm not trying to blaze any trails with this code. Furthermore, my implementation does not preclude a better one replacing it. I would welcome a better implementation. Until that appears, my implementation is what there is. :) Frankly, my interest does not lie in the a C OrderedDict, but in what I want to do one we have one. Since no one was willing to do that for me , I did it myself. That said, I feel like my implementation satisfies what is required and does so in a way that we can be satisfied with it indefinitely. It sounds like you feel it would be worse to land it than to not have a C implementation of OrderedDict. Obviously I don't feel the same way. :) Regardless, I think we both feel the same way that the amount of time I've spent on this shouldn't factor into determining that. Aside from subclassing dict and my linked list approach, do you have any other concerns? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 05:07:33 2015 From: report at bugs.python.org (xiaobing jiang) Date: Thu, 02 Apr 2015 03:07:33 +0000 Subject: [issue12849] Cannot override 'connection: close' in urllib2 headers In-Reply-To: <1314559168.55.0.630424901631.issue12849@psf.upfronthosting.co.za> Message-ID: <1427944053.16.0.782607665015.issue12849@psf.upfronthosting.co.za> Changes by xiaobing jiang : ---------- nosy: +s7v7nislands at gmail.com _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 06:00:18 2015 From: report at bugs.python.org (SeungHyun.Hwang) Date: Thu, 02 Apr 2015 04:00:18 +0000 Subject: [issue23846] asyncio : ProactorEventLoop raised BlockingIOError when ThreadPoolExecutor has many workers Message-ID: <1427947218.56.0.749215014794.issue23846@psf.upfronthosting.co.za> New submission from SeungHyun.Hwang: I tested on python3.4.2, windows 7 1. Only proactorEvent issued. 2. ThreadPoolExecutor has many workers (in the attached example file, worker count 20,000) 3. The loop does run_in_executor more call than worker count (in the attached example file, 40,000 calls) 4. After some random seconds, raise BlockingIOError BlockingIOError: [WinError 10035] A non-blocking socket operation could not be completed immediately. exception calling callback for Traceback (most recent call last): File "c:\Python342\Lib\concurrent\futures\_base.py", line 297, in _invoke_callbacks callback(self) File "c:\Python342\Lib\asyncio\futures.py", line 410, in new_future._copy_state, fut)) File "c:\Python342\Lib\asyncio\base_events.py", line 403, in call_soon_threadsafe self._write_to_self() File "c:\Python342\Lib\asyncio\proactor_events.py", line 449, in _write_to_self self._csock.send(b'\0') I guess that proactor's _write_to_self method misses exception handle. proactor_events.py def _write_to_self(self): self._csock.send(b'\0') selector_events.py def _write_to_self(self): # This may be called from a different thread, possibly after # _close_self_pipe() has been called or even while it is # running. Guard for self._csock being None or closed. When # a socket is closed, send() raises OSError (with errno set to # EBADF, but let's not rely on the exact error code). csock = self._csock if csock is not None: try: csock.send(b'\0') except OSError: if self._debug: logger.debug("Fail to write a null byte into the " "self-pipe socket", exc_info=True) Ps: It's my first publication. Hope you understand my poor comment.. ---------- components: asyncio files: example_thread_executor.py messages: 239872 nosy: gvanrossum, haypo, kernel0, yselivanov priority: normal severity: normal status: open title: asyncio : ProactorEventLoop raised BlockingIOError when ThreadPoolExecutor has many workers type: crash versions: Python 3.4 Added file: http://bugs.python.org/file38801/example_thread_executor.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 06:08:32 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Apr 2015 04:08:32 +0000 Subject: [issue23844] test_ssl: fails on recent libressl version with BAD_DH_P_LENGTH In-Reply-To: <1427921613.92.0.742190312016.issue23844@psf.upfronthosting.co.za> Message-ID: <20150402040818.19634.46653@psf.io> Roundup Robot added the comment: New changeset 1ad7c0253abe by Benjamin Peterson in branch '3.4': replace 512 bit dh key with a 2014 bit one (closes #23844) https://hg.python.org/cpython/rev/1ad7c0253abe New changeset 4f2391e86643 by Benjamin Peterson in branch '2.7': replace 512 bit dh key with a 2014 bit one (closes #23844) https://hg.python.org/cpython/rev/4f2391e86643 New changeset c27585e43e50 by Benjamin Peterson in branch 'default': merge 3.4 (#23844) https://hg.python.org/cpython/rev/c27585e43e50 ---------- nosy: +python-dev resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 06:30:01 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 02 Apr 2015 04:30:01 +0000 Subject: [issue22350] nntplib file write failure causes exception from QUIT command In-Reply-To: <1410061219.03.0.0230581897355.issue22350@psf.upfronthosting.co.za> Message-ID: <1427949001.88.0.398374025641.issue22350@psf.upfronthosting.co.za> Martin Panter added the comment: Serhiy, regarding _getresp() calling resp.decode(): You are probably right that a failure decoding the response line is recoverable in some circumstances, such a GROUP command. But in other cases, say an ARTICLE command, the response won?t have been fully drained, so the connection is no longer usable. I guess I could shift the error handling to a higher level if you think it is necessary. Regarding the workaround in my original post: It is not a good solution, because it is still trying to send a QUIT request and wait for a response in the error handler. If you are trying to interrupt a hanging network connection for example, you have to hit Ctrl+C twice, or wait a long time for the QUIT command to get some invalid data and raise its confusing protocol error. David: The error handling inside _getlongresp() is the main place that concerned me. But as I made the changes there I identified the other places I thought could raise unexpected exceptions (network errors) or block (therefore a KeyboardInterrupt is likely). Draining the response might be sensible for handling an error writing to the file in some cases. My /dev/full example was actually meant to be a simple example of more complicated exceptions, such as KeyboardInterrupt, network timeouts, or if the programmer wants to peek at the start of a large message and then abort the download. So it seems my simplified test case was misleading, because in these other cases, draining the response isn?t so appropriate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 06:42:32 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 02 Apr 2015 04:42:32 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message_on_Wine?= In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> Message-ID: <1427949752.79.0.366243595461.issue22977@psf.upfronthosting.co.za> Martin Panter added the comment: All the other occurrences of capitalized %X that I can find are not using Python?s string formatting functions. Please point them out if you can, but all I can see are some using a Microsoft vfwprintf_s() API, some calling standard C sprintf(), sscanf(), fprintf(), strftime() and strptime() APIs, and of course native Python 2-style string formatting, which I assume should all support %X. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 07:20:55 2015 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Apr 2015 05:20:55 +0000 Subject: [issue23731] Implement PEP 488 In-Reply-To: <1426944831.0.0.593089874415.issue23731@psf.upfronthosting.co.za> Message-ID: <1427952055.5.0.667386809271.issue23731@psf.upfronthosting.co.za> Eric Snow added the comment: Thanks for doing this, Brett. It's so simple a change yet such a great one. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 07:31:52 2015 From: report at bugs.python.org (SeungHyun.Hwang) Date: Thu, 02 Apr 2015 05:31:52 +0000 Subject: [issue23846] asyncio : ProactorEventLoop raised BlockingIOError when ThreadPoolExecutor has many workers In-Reply-To: <1427947218.56.0.749215014794.issue23846@psf.upfronthosting.co.za> Message-ID: <1427952712.33.0.0796042929852.issue23846@psf.upfronthosting.co.za> Changes by SeungHyun.Hwang : ---------- type: crash -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 08:14:38 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 02 Apr 2015 06:14:38 +0000 Subject: [issue6766] Cannot modify dictionaries inside dictionaries using Managers from multiprocessing In-Reply-To: <1251049590.58.0.809281249474.issue6766@psf.upfronthosting.co.za> Message-ID: <1427955278.76.0.397632377786.issue6766@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +davin, sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 08:39:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Apr 2015 06:39:42 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message_on_Wine?= In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> Message-ID: <1427956782.06.0.0833718800225.issue22977@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Yes, you are right. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 08:50:34 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Apr 2015 06:50:34 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message_on_Wine?= In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> Message-ID: <20150402065031.16507.86464@psf.io> Roundup Robot added the comment: New changeset 7907746baa0d by Serhiy Storchaka in branch '3.4': Issue #22977: Fixed formatting Windows error messages on Wine. https://hg.python.org/cpython/rev/7907746baa0d New changeset cf0cac11813d by Serhiy Storchaka in branch 'default': Issue #22977: Fixed formatting Windows error messages on Wine. https://hg.python.org/cpython/rev/cf0cac11813d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 08:51:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Apr 2015 06:51:04 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message_on_Wine?= In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> Message-ID: <1427957464.57.0.131549611622.issue22977@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 Apr 2 08:53:35 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 02 Apr 2015 06:53:35 +0000 Subject: [issue23841] py34 OrderedDict is using weakref for root reference In-Reply-To: <1427889707.75.0.323875541647.issue23841@psf.upfronthosting.co.za> Message-ID: <1427957615.05.0.114385123678.issue23841@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 08:55:37 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 02 Apr 2015 06:55:37 +0000 Subject: [issue23841] py34 OrderedDict is using weakref for root reference In-Reply-To: <1427889707.75.0.323875541647.issue23841@psf.upfronthosting.co.za> Message-ID: <1427957737.0.0.358276092359.issue23841@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 09:01:50 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 02 Apr 2015 07:01:50 +0000 Subject: [issue23847] Add xml pretty print option to ElementTree Message-ID: <1427958110.33.0.788273316254.issue23847@psf.upfronthosting.co.za> New submission from Raymond Hettinger: The xml.dom.minidom package has as a xml.toprettyxml() function that has the problem of altering the whitespace of the text of elements. The ElementTree module needs a prettify option that works better, perhaps something based of Effbot's code at: http://effbot.org/zone/element-lib.htm#prettyprint The lxml package also provides an API for this purpose: print(etree.tostring(root, pretty_print=True)) ---------- messages: 239879 nosy: rhettinger priority: normal severity: normal status: open title: Add xml pretty print option to ElementTree type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 09:02:41 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 02 Apr 2015 07:02:41 +0000 Subject: [issue23847] Add xml pretty print option to ElementTree In-Reply-To: <1427958110.33.0.788273316254.issue23847@psf.upfronthosting.co.za> Message-ID: <1427958161.57.0.125531456714.issue23847@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +eli.bendersky, scoder -rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 09:07:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Apr 2015 07:07:19 +0000 Subject: [issue21526] Support new booleans in Tkinter In-Reply-To: <1400445691.82.0.48051274053.issue21526@psf.upfronthosting.co.za> Message-ID: <1427958439.13.0.503021066731.issue21526@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: When I said this, I understood that the patch should be backported to maintained releases. Unpatched Python with Tcl 8.5: >>> import tkinter; tcl = tkinter.Tcl() >>> tcl.call('expr', 'false') >>> bool(tcl.call('expr', 'false')) True ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 09:08:34 2015 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 02 Apr 2015 07:08:34 +0000 Subject: [issue23847] Add xml pretty print option to ElementTree In-Reply-To: <1427958110.33.0.788273316254.issue23847@psf.upfronthosting.co.za> Message-ID: <1427958514.09.0.307930959024.issue23847@psf.upfronthosting.co.za> Stefan Behnel added the comment: duplicate of issue 14465 ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 09:08:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Apr 2015 07:08:43 +0000 Subject: [issue21526] Support new booleans in Tkinter In-Reply-To: <1400445691.82.0.48051274053.issue21526@psf.upfronthosting.co.za> Message-ID: <1427958523.21.0.86221315366.issue21526@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 09:35:35 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Apr 2015 07:35:35 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message_on_Wine?= In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> Message-ID: <1427960134.99.0.936696589779.issue22977@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm not sure that Windows appreciate your change :-) http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/6011/steps/test/logs/stdio [216/393] test_exceptions Traceback (most recent call last): File "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\..\lib\test\regrtest.py", line 1589, in main_in_temp_cwd() File "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\..\lib\test\regrtest.py", line 1564, in main_in_temp_cwd main() File "C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\..\lib\test\regrtest.py", line 738, in main raise Exception("Child error on {}: {}".format(test, result[1])) Exception: Child error on test_exceptions: Exit code 3765269347 ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 09:38:36 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Apr 2015 07:38:36 +0000 Subject: [issue23834] socketmodule.c: add sock_call() to fix how the timeout is recomputed In-Reply-To: <1427842506.28.0.704301607448.issue23834@psf.upfronthosting.co.za> Message-ID: <1427960316.13.0.681053473108.issue23834@psf.upfronthosting.co.za> STINNER Victor added the comment: The changeset 920b700d9509 fixed AMD64 Snow Leop 3.x, I close the issue. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 09:45:24 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 02 Apr 2015 07:45:24 +0000 Subject: [issue9026] argparse subcommands not printed in the same order they were added In-Reply-To: <1276856679.08.0.64136890627.issue9026@psf.upfronthosting.co.za> Message-ID: <1427960724.38.0.123995960715.issue9026@psf.upfronthosting.co.za> Ned Deily added the comment: @ddvento: This issue has been closed and the fixes for it released several years ago. Comments added here will likely be ignored. If you believe there is a problem with current releases (for Python 2, Python 2.7.9 is current), please open a new issue and document how to reproduce, including on what platform(s) and with which versions of Python. FWIW, the original test case in this issue works correctly with both a 2.7.6 and current 2.7.9 on the platforms I tried it with. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 09:46:29 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 02 Apr 2015 07:46:29 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message_on_Wine?= In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> Message-ID: <1427960789.19.0.934860326923.issue22977@psf.upfronthosting.co.za> Martin Panter added the comment: I don?t pretend to know what is going on, or the best way to fix it. That exit code is the same code that my test passes to RaiseException. Perhaps it would be best to disable the test until someone with more knowledge or a Windows compiler can investigate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 10:03:06 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Apr 2015 08:03:06 +0000 Subject: [issue21526] Support new booleans in Tkinter In-Reply-To: <1400445691.82.0.48051274053.issue21526@psf.upfronthosting.co.za> Message-ID: <20150402080254.59574.54620@psf.io> Roundup Robot added the comment: New changeset de3496cd609e by Serhiy Storchaka in branch '3.4': Issue #21526: Tkinter now supports new boolean type in Tcl 8.5. https://hg.python.org/cpython/rev/de3496cd609e New changeset b2413da7516f by Serhiy Storchaka in branch 'default': Issue #21526: Fixed support of new boolean type in Tcl 8.5. https://hg.python.org/cpython/rev/b2413da7516f New changeset d0554559de53 by Serhiy Storchaka in branch '2.7': Issue #21526: Tkinter now supports new boolean type in Tcl 8.5. https://hg.python.org/cpython/rev/d0554559de53 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 10:03:25 2015 From: report at bugs.python.org (John Nagle) Date: Thu, 02 Apr 2015 08:03:25 +0000 Subject: [issue23843] ssl.wrap_socket doesn't handle virtual TLS hosts In-Reply-To: <1427913138.81.0.946174755254.issue23843@psf.upfronthosting.co.za> Message-ID: <1427961805.42.0.87068424722.issue23843@psf.upfronthosting.co.za> John Nagle added the comment: I'm using wrap_socket because I want to read the details of a server's SSL certificate. "Starting from Python 3.2, it can be more flexible to use SSLContext.wrap_socket() instead" does not convey that ssl.wrap_socket() will fail to connect to some servers because it will silently check the wrong certificate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 10:04:27 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Apr 2015 08:04:27 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message_on_Wine?= In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> Message-ID: <1427961867.9.0.246079935806.issue22977@psf.upfronthosting.co.za> STINNER Victor added the comment: On Python 3.4, windll.kernel32.RaiseException(2, 0, 0, None) raised a FileNotFound error. On Python 3.5, it displays a popup and the program exit. It looks like the behaviour of RaiseException() changed in Python 3.5. I tested in debug and release mode. @Steve: Any idea? -- Instead of RaiseException, you can use ctypes.pythondll.PyErr_SetFromWindowsErr(code). > code = int.from_bytes(b"\xE0msc", "big") Why not writing directly code = 3765269347? The unit test should also check the exception message. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 10:10:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Apr 2015 08:10:55 +0000 Subject: [issue21526] Support new booleans in Tkinter In-Reply-To: <1400445691.82.0.48051274053.issue21526@psf.upfronthosting.co.za> Message-ID: <1427962255.7.0.916840258837.issue21526@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And indeed, "app->BooleanType" is NULL, because the "booleanString" type is not registered in Tcl. Thank you for pointing on it Amaury. Now it is fixed. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 10:15:59 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Apr 2015 08:15:59 +0000 Subject: [issue23848] faulthandler: setup an exception handler on Windows Message-ID: <1427962559.63.0.750474204561.issue23848@psf.upfronthosting.co.za> New submission from STINNER Victor: Attached patch setup an exception handler on Windows. I wrote it when investigating a failure of test_exceptions related to the issue #22977. faulthandler was not trigerred while the program crashed. I didn't test the patch yet (I tested a previous attempt, a little bit different). Maybe we can avoid setting signal handlers on Windows if an exception handler is set? ---------- components: Windows files: faulthandler_exc_handler.patch keywords: patch messages: 239890 nosy: haypo, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: faulthandler: setup an exception handler on Windows versions: Python 3.5 Added file: http://bugs.python.org/file38802/faulthandler_exc_handler.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 10:19:14 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Apr 2015 08:19:14 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message_on_Wine?= In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> Message-ID: <1427962753.99.0.498838785312.issue22977@psf.upfronthosting.co.za> STINNER Victor added the comment: Oh, and the ctypes module (import) must be optional, just skip the test if ctypes is missing. http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/9555/steps/test/logs/stdio test test_exceptions crashed -- Traceback (most recent call last): File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/regrtest.py", line 1267, in runtest_inner the_module = importlib.import_module(abstest) File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/importlib/__init__.py", line 109, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "", line 2222, in _gcd_import File "", line 2205, in _find_and_load File "", line 2194, in _find_and_load_unlocked File "", line 1153, in _load_unlocked File "", line 1431, in exec_module File "", line 321, in _call_with_frames_removed File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/test/test_exceptions.py", line 9, in import ctypes File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/ctypes/__init__.py", line 7, in from _ctypes import Union, Structure, Array ImportError: No module named '_ctypes' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 10:20:47 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Apr 2015 08:20:47 +0000 Subject: [issue23847] Add xml pretty print option to ElementTree In-Reply-To: <1427958110.33.0.788273316254.issue23847@psf.upfronthosting.co.za> Message-ID: <1427962847.27.0.584323020458.issue23847@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> xml.etree.ElementTree: add feature to prettify XML output _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 10:23:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Apr 2015 08:23:36 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message_on_Wine?= In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> Message-ID: <1427963016.12.0.791081480341.issue22977@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Could you provide a patch if you can test it Victor? ---------- assignee: serhiy.storchaka -> stage: resolved -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 10:48:25 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Apr 2015 08:48:25 +0000 Subject: [issue21526] Support new booleans in Tkinter In-Reply-To: <1400445691.82.0.48051274053.issue21526@psf.upfronthosting.co.za> Message-ID: <20150402084821.129129.19252@psf.io> Roundup Robot added the comment: New changeset 954e7e1d85f1 by Serhiy Storchaka in branch '2.7': Issue #21526: Fixed the test_booleans test for wantobjects = 0. https://hg.python.org/cpython/rev/954e7e1d85f1 New changeset 4255ca2f5314 by Serhiy Storchaka in branch '3.4': Issue #21526: Fixed the test_booleans test for wantobjects = 0. https://hg.python.org/cpython/rev/4255ca2f5314 New changeset bb0b5b6c13f3 by Serhiy Storchaka in branch 'default': Issue #21526: Fixed the test_booleans test for wantobjects = 0. https://hg.python.org/cpython/rev/bb0b5b6c13f3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 11:37:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Apr 2015 09:37:20 +0000 Subject: [issue23849] Leaks in test_deque Message-ID: <1427967440.19.0.462388571219.issue23849@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: $ ./python -m test.regrtest -R 3:3:reflog test_deque [1/1] test_deque beginning 6 repetitions 123456 ...... test_deque leaked [91, 91, 91] references, sum=273 test_deque leaked [21, 23, 23] memory blocks, sum=67 1 test failed: test_deque ---------- components: Tests messages: 239894 nosy: rhettinger, serhiy.storchaka priority: normal severity: normal status: open title: Leaks in test_deque type: resource usage versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 11:54:23 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Apr 2015 09:54:23 +0000 Subject: [issue23849] Leaks in test_deque In-Reply-To: <1427967440.19.0.462388571219.issue23849@psf.upfronthosting.co.za> Message-ID: <1427968463.02.0.139560120951.issue23849@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 12:09:33 2015 From: report at bugs.python.org (Giacomo Alzetta) Date: Thu, 02 Apr 2015 10:09:33 +0000 Subject: [issue23850] Missing documentation for Py_TPFLAGS_HAVE_NEWBUFFER Message-ID: <1427969373.72.0.801261679654.issue23850@psf.upfronthosting.co.za> New submission from Giacomo Alzetta: Python2.7 documentation is missing critical information regarding the backporting of the new-buffer protocol. There is no mention whatsoever of the Py_TPFLAGS_HAVE_NEWBUFFER flag which is required to implement it. The only way to discover it is by reading the sources of the built-ins or stdlib. ---------- messages: 239895 nosy: Giacomo.Alzetta priority: normal severity: normal status: open title: Missing documentation for Py_TPFLAGS_HAVE_NEWBUFFER _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 12:10:12 2015 From: report at bugs.python.org (Giacomo Alzetta) Date: Thu, 02 Apr 2015 10:10:12 +0000 Subject: [issue23850] Missing documentation for Py_TPFLAGS_HAVE_NEWBUFFER In-Reply-To: <1427969373.72.0.801261679654.issue23850@psf.upfronthosting.co.za> Message-ID: <1427969412.2.0.573103719413.issue23850@psf.upfronthosting.co.za> Changes by Giacomo Alzetta : ---------- assignee: -> docs at python components: +Documentation nosy: +docs at python type: -> enhancement versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 12:33:51 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Apr 2015 10:33:51 +0000 Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect) In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za> Message-ID: <1427970831.87.0.198745757554.issue23618@psf.upfronthosting.co.za> STINNER Victor added the comment: test_connnect_eintr.py: program to interrupt socket.connect() with signals. It looks like socket.connect() cannot be interrupted by signals: connect() only fails with WSAEINTR when WSACancelBlockingCall() is called, but WSACancelBlockingCall() "has been removed in compliance with the Windows Sockets 2 specification, revision 2.2.0": https://msdn.microsoft.com/en-us/library/windows/desktop/ms741547%28v=vs.85%29.aspx "Blocking hooks are generally used to keep a single-threaded GUI application responsive during calls to blocking functions. Instead of using blocking hooks, an applications should use a separate thread (separate from the main GUI thread) for network activity." ---------- Added file: http://bugs.python.org/file38803/test_connect_eintr.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 12:35:22 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 02 Apr 2015 10:35:22 +0000 Subject: [issue23830] Add AF_IUCV support to sockets In-Reply-To: <1427828484.47.0.0998681334057.issue23830@psf.upfronthosting.co.za> Message-ID: <1427970922.52.0.0556543117763.issue23830@psf.upfronthosting.co.za> Nick Coghlan added the comment: Slavek, there's an s390x patch here to add AF_IUCV support to the socket module. One interesting point to note is that s390x isn't an officially supported CPython architecture by the terms of PEP 11. While I can vouch for it working there (courtesy of beaker-project.org), I don't see any reasonable way we could provide an upstream buildbot for it. ---------- nosy: +bkabrda, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 12:42:47 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 02 Apr 2015 10:42:47 +0000 Subject: [issue23756] Tighten definition of bytes-like objects In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za> Message-ID: <1427971367.57.0.686990563765.issue23756@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- assignee: docs at python -> skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 12:54:17 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Apr 2015 10:54:17 +0000 Subject: [issue23839] Clear caches after every test In-Reply-To: <1427887841.84.0.393130432881.issue23839@psf.upfronthosting.co.za> Message-ID: <1427972057.15.0.328812494298.issue23839@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I ran all tests with and without clearing all caches. Unpatched (without clearing): real 31m23.694s user 16m10.340s sys 2m25.084s Patched (with clearing): real 29m28.859s user 16m19.048s sys 1m42.184s There is no significant difference (may be with the patch tests are even faster). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 12:54:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Apr 2015 10:54:49 +0000 Subject: [issue23839] Clear caches after every test In-Reply-To: <1427887841.84.0.393130432881.issue23839@psf.upfronthosting.co.za> Message-ID: <1427972089.66.0.302876992483.issue23839@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file38804/regrtest_clear_caches.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 12:57:37 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 02 Apr 2015 10:57:37 +0000 Subject: [issue23376] getargs.c: redundant C-contiguity check In-Reply-To: <1422879437.88.0.730176140595.issue23376@psf.upfronthosting.co.za> Message-ID: <1427972257.87.0.493432850529.issue23376@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- assignee: -> skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 12:57:54 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Apr 2015 10:57:54 +0000 Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect) In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za> Message-ID: <20150402105751.29533.18784@psf.io> Roundup Robot added the comment: New changeset aad52bfc816f by Victor Stinner in branch 'default': Issue #23618: Don't declare recvmsg/sendmsg helper functions on Windows https://hg.python.org/cpython/rev/aad52bfc816f New changeset f22188acc77d by Victor Stinner in branch 'default': Issue #23618: Document EINTR changes in socket documentation https://hg.python.org/cpython/rev/f22188acc77d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 12:59:09 2015 From: report at bugs.python.org (Neale Ferguson) Date: Thu, 02 Apr 2015 10:59:09 +0000 Subject: [issue23830] Add AF_IUCV support to sockets In-Reply-To: <1427970922.52.0.0556543117763.issue23830@psf.upfronthosting.co.za> Message-ID: Neale Ferguson added the comment: I can provide one if required. I have access to an s390x Linux Foundation machine where I have a couple of virtual machines that could be used. -------- Original message -------- From: Nick Coghlan Date:2015/04/02 06:35 (GMT-05:00) To: Neale Ferguson Subject: [issue23830] Add AF_IUCV support to sockets Nick Coghlan added the comment: Slavek, there's an s390x patch here to add AF_IUCV support to the socket module. One interesting point to note is that s390x isn't an officially supported CPython architecture by the terms of PEP 11. While I can vouch for it working there (courtesy of beaker-project.org), I don't see any reasonable way we could provide an upstream buildbot for it. ---------- nosy: +bkabrda, ncoghlan _______________________________________ Python tracker _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 13:10:07 2015 From: report at bugs.python.org (Stefan Krah) Date: Thu, 02 Apr 2015 11:10:07 +0000 Subject: [issue23756] Tighten definition of bytes-like objects In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za> Message-ID: <1427973007.84.0.26304379148.issue23756@psf.upfronthosting.co.za> Stefan Krah added the comment: If you think that the previous version was "incorrect and misleading", the bar for changes to be accepted seems pretty high for me. "grep -r" doesn't seem to find "flattened length" in Doc/*. "An object that supports the :ref:`bufferobject` and is C-contiguous, like :class:`bytes`, :class:`bytearray` or :class:`memoryview`." This implies that all memoryviews are C-contiguous. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 13:19:16 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Apr 2015 11:19:16 +0000 Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect) In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za> Message-ID: <1427973556.39.0.826629935538.issue23618@psf.upfronthosting.co.za> STINNER Victor added the comment: Hum, connect() does not always block with test_connect_eintr.py, and this program sometimes fail with ConnectionResetError on connect() on FreeBSD. New program which works on Linux and FreeBSD. It now ensures that connect() will block. ---------- Added file: http://bugs.python.org/file38805/test_connect_eintr2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 13:31:21 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Apr 2015 11:31:21 +0000 Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect) In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za> Message-ID: <1427974281.08.0.010848821903.issue23618@psf.upfronthosting.co.za> STINNER Victor added the comment: test_connect_eintr3.py: even better: - block signals in the server thread - count signals during connect() - display progress: "*" for signal received during connect(), "_" for signal received before/after connect(), "[" and "]" for the beginning and end of a connection, "#" for client connection reset Example of output on FreeBSD: Register SIGINT Register SIGALRM Register SIGWINCH Register SIGTERM Register SIGCHLD Send SIGALRM every 200.0 ms Run func() during 5.0 seconds Type CTRL+c, resize the window, etc. ___[]______[]_____[_*#]_____[#]__[#]________[#]____[#]_____[**]____[*#]______[__#]___[#]_____[#]____[*#]______[#]______[#]_____[*#]_____[#]_____[#]______[#]______[#]______[#]______[#]______[#]____[#]_______[#]_____[#]_______[#]_____[#]_____[#]______[#]_______[#]____[#]______[#]______[*#]_____[#]________[#]__ Test completed in 5.1 sec func() has been called 36 times Got 204 signals Got 7 signals during connect() ---------- Added file: http://bugs.python.org/file38806/test_connect_eintr3.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 13:33:52 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Apr 2015 11:33:52 +0000 Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect) In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za> Message-ID: <1427974432.91.0.378126568266.issue23618@psf.upfronthosting.co.za> STINNER Victor added the comment: Example of test_connect_eintr3.py output on Linux (3.18): Register SIGINT Register SIGALRM Register SIGWINCH Register SIGTERM Register SIGCHLD Send SIGALRM every 200.0 ms Run func() during 5.0 seconds Type CTRL+c, resize the window, etc. []_____[]_____[]_____[]_____[**********][**********][]______[**********][]_____[]____[**********][**********] Test completed in 5.4 sec func() has been called 12 times Got 85 signals Got 50 signals during connect() Example of test_connect_eintr3.py output on Mac OS X Yosemite (10.10): Register SIGINT Register SIGALRM Register SIGWINCH Register SIGTERM Register SIGCHLD Send SIGALRM every 200.0 ms Run func() during 5.0 seconds Type CTRL+c, resize the window, etc. []______[*********][***********][**********]_[********][***********] Test completed in 5.3 sec func() has been called 6 times Got 55 signals Got 49 signals during connect() ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 13:37:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Apr 2015 11:37:04 +0000 Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect) In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za> Message-ID: <1427974624.39.0.314328205997.issue23618@psf.upfronthosting.co.za> STINNER Victor added the comment: Example of test_connect_eintr3.py output on OpenIndiana: Register SIGINT Register SIGALRM Register SIGWINCH Register SIGTERM Register SIGCHLD Send SIGALRM every 200.0 ms Run func() during 5.0 seconds Type CTRL+c, resize the window, etc. ______[]____[]_____[******]______[]_______[*****]______[*****]______[] Test completed in 5.2 sec func() has been called 7 times Got 56 signals Got 16 signals during connect() Oh, and obviously, test_connect_eintr3.py fails with InterruptedError without the patch. Example on Linux: Register SIGINT Register SIGALRM Register SIGWINCH Register SIGTERM Register SIGCHLD Send SIGALRM every 200.0 ms Run func() during 5.0 seconds Type CTRL+c, resize the window, etc. []____[]_____[]_____[]____[******Traceback (most recent call last): File "test_connect_eintr.py", line 97, in func() File "test_connect_eintr.py", line 51, in func client.connect(server_addr) InterruptedError: [Errno 4] Interrupted system call ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 13:42:47 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Apr 2015 11:42:47 +0000 Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect) In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za> Message-ID: <20150402114243.14223.25332@psf.io> Roundup Robot added the comment: New changeset 75fcc7a3738a by Victor Stinner in branch 'default': Issue #23618: socket.socket.connect() now waits until the connection completes https://hg.python.org/cpython/rev/75fcc7a3738a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 13:54:34 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Apr 2015 11:54:34 +0000 Subject: [issue23851] PEP 475: _posixsubprocess retries close() on EINTR Message-ID: <1427975674.16.0.24545541866.issue23851@psf.upfronthosting.co.za> New submission from STINNER Victor: According to the PEP 475, the close() function must *not* be retried if it fails with EINTR: - http://alobbs.com/post/54503240599/close-and-eintr - http://lwn.net/Articles/576478/ - http://linux.derkeiler.com/Mailing-Lists/Kernel/2005-09/3000.html - http://alobbs.com/post/54503240599/close-and-eintr The _posixsubprocess retries close() when it fails with EINTR. Example: while (close(fd_num) < 0 && errno == EINTR); It should be fixed. ---------- messages: 239907 nosy: haypo priority: normal severity: normal status: open title: PEP 475: _posixsubprocess retries close() on EINTR versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 13:54:59 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Apr 2015 11:54:59 +0000 Subject: [issue23648] PEP 475 meta issue In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za> Message-ID: <1427975699.0.0.68388093695.issue23648@psf.upfronthosting.co.za> STINNER Victor added the comment: New issue #23851: _posixsubprocess retries close() on EINTR. ---------- dependencies: +PEP 475: _posixsubprocess retries close() on EINTR _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 13:56:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Apr 2015 11:56:49 +0000 Subject: [issue23648] PEP 475 meta issue In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za> Message-ID: <20150402115646.129131.37192@psf.io> Roundup Robot added the comment: New changeset 66e4ef9a7467 by Victor Stinner in branch 'default': Issue #23648: Complete the list of modified functions for the PEP 475 https://hg.python.org/cpython/rev/66e4ef9a7467 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 14:23:10 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Apr 2015 12:23:10 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message_on_Wine?= In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> Message-ID: <20150402122307.16521.53370@psf.io> Roundup Robot added the comment: New changeset dafae2b3c257 by Victor Stinner in branch '3.4': Issue #22977: Fix test_exceptions https://hg.python.org/cpython/rev/dafae2b3c257 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 14:25:36 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Apr 2015 12:25:36 +0000 Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect) In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za> Message-ID: <1427977536.07.0.348503557064.issue23618@psf.upfronthosting.co.za> STINNER Victor added the comment: http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/2904/steps/test/logs/stdio ====================================================================== FAIL: test_connect_ex_error (test.test_ssl.NetworkedTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_ssl.py", line 1441, in test_connect_ex_error self.assertIn(rc, (errno.ECONNREFUSED, errno.EWOULDBLOCK)) AssertionError: 36 not found in (61, 35) where 36 is errno.EINPROGRESS ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 14:38:14 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Apr 2015 12:38:14 +0000 Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect) In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za> Message-ID: <20150402123811.16507.37549@psf.io> Roundup Robot added the comment: New changeset 44adbb5eeb4b by Victor Stinner in branch 'default': Issue #23618: Fix sock_connect_impl(), set the socket error code https://hg.python.org/cpython/rev/44adbb5eeb4b ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 14:42:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Apr 2015 12:42:22 +0000 Subject: [issue10395] new os.path function to extract common prefix based on path components In-Reply-To: <1289574847.69.0.366708031395.issue10395@psf.upfronthosting.co.za> Message-ID: <1427978542.23.0.464522556196.issue10395@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 Thu Apr 2 14:42:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Apr 2015 12:42:55 +0000 Subject: [issue23803] str.partition() is broken in 3.4 In-Reply-To: <1427612567.08.0.637724736927.issue23803@psf.upfronthosting.co.za> Message-ID: <1427978575.85.0.707116263841.issue23803@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 Thu Apr 2 15:20:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Apr 2015 13:20:22 +0000 Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect) In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za> Message-ID: <20150402132018.14213.97016@psf.io> Roundup Robot added the comment: New changeset 09a4d5cc6afd by Victor Stinner in branch 'default': Issue #23618: Ooops, remove abort() added for debug purpose https://hg.python.org/cpython/rev/09a4d5cc6afd ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 15:46:50 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Apr 2015 13:46:50 +0000 Subject: [issue22350] nntplib file write failure causes exception from QUIT command In-Reply-To: <1410061219.03.0.0230581897355.issue22350@psf.upfronthosting.co.za> Message-ID: <1427982410.44.0.210687850496.issue22350@psf.upfronthosting.co.za> R. David Murray added the comment: That's fine, but you need to look at each case individually, and not try to deal with them as if they were all the same. This is because you want the correct error to percolate up. For example, in smtplib we have a case where the server may respond to a command by closing the connection (which is technically a violation of the RFC). It used to be that smtplib would raise a connection error at that point because it would try to send an RST command to the server over the closed connection. The original error message reported by the server was lost. The solution was to rewrite the error handling so that we had an internal send_RST that was different from the one that would be used by the application, and that internal RST send was wrapped in a try/except ignoring the connection error. That way the command the application called returned the received response, and then the application got the connection closed error the *next* time it tried to use the connection. nntplib presumably requires as a similar strategy if the network connection terminates unexpectedly: just ignoring the connection closed error when the quit is sent. The code already closes the connection after the QUIT attempt, so that should leave things in the correct state for all other errors. Other network errors may benefit from additional handling, but I don't know since I don't have examples here to think about :) As for the keyboard interrupt problem, it looks like what needs to happen is a custom response handler for the internal QUIT, that will recognize when it is not getting "its" response back and just return. This is more similar to the smptlib problem than I originally thought: it seems like the basic problem is that that internal QUIT needs custom handling that is different from the QUIT issued at the application level. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 15:56:55 2015 From: report at bugs.python.org (shiyao.ma) Date: Thu, 02 Apr 2015 13:56:55 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1427983015.3.0.32171965454.issue16991@psf.upfronthosting.co.za> Changes by shiyao.ma : ---------- nosy: +introom _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 16:16:49 2015 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Thu, 02 Apr 2015 14:16:49 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1427984209.51.0.0572649035568.issue19610@psf.upfronthosting.co.za> ?ric Araujo added the comment: Thanks, reviewed. When running a setup.py that uses a tuple for classifiers, is the error message in the terminal user-friendly, or do we get a full traceback? ---------- title: setup.py does not allow a tuple for classifiers -> Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 16:16:58 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Apr 2015 14:16:58 +0000 Subject: [issue21526] Support new booleans in Tkinter In-Reply-To: <1400445691.82.0.48051274053.issue21526@psf.upfronthosting.co.za> Message-ID: <1427984218.23.0.705969927221.issue21526@psf.upfronthosting.co.za> STINNER Victor added the comment: http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/9465/steps/test/logs/stdio ====================================================================== FAIL: test_booleans (test.test_tcl.TclTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_tcl.py", line 391, in test_booleans check('true', True) File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_tcl.py", line 386, in check self.assertEqual(result, expected) AssertionError: 'true' != True ---------- nosy: +haypo resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 16:17:55 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Apr 2015 14:17:55 +0000 Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect) In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za> Message-ID: <1427984275.27.0.416607302241.issue23618@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 16:24:30 2015 From: report at bugs.python.org (Peter) Date: Thu, 02 Apr 2015 14:24:30 +0000 Subject: [issue23786] test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... Fatal Python error: Bus error In-Reply-To: <1427377647.96.0.0955568014503.issue23786@psf.upfronthosting.co.za> Message-ID: <1427984670.18.0.896812494955.issue23786@psf.upfronthosting.co.za> Peter added the comment: So this morning I got around to rebuilding the tool chain using GCC 4.9.2 and I'm happy to report that this problem goes away (no patch required)! So it must be some sort of problem with the 4.6 GCC. I've still got the old tool chain around, and I'm happy to further patch / test if anyone at Python wants me to. $ gcc --verbose Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/sparc-sun-solaris2.11/4.9.2/lto-wrapper Target: sparc-sun-solaris2.11 Configured with: ../gcc-4.9.2/configure --prefix=/usr/local --enable-languages=c,c++ --disable-nls --with-gnu-as --with-gnu-ld --target=sparc-sun-solaris2.11 Thread model: posix gcc version 4.9.2 (GCC) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 16:26:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Apr 2015 14:26:33 +0000 Subject: [issue23851] PEP 475: _posixsubprocess retries close() on EINTR In-Reply-To: <1427975674.16.0.24545541866.issue23851@psf.upfronthosting.co.za> Message-ID: <20150402142630.29543.38096@psf.io> Roundup Robot added the comment: New changeset e54b23d7afa6 by Victor Stinner in branch '3.4': Issue #23851: close() must not be retried when it fails with EINTR https://hg.python.org/cpython/rev/e54b23d7afa6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 16:26:43 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Apr 2015 14:26:43 +0000 Subject: [issue23851] PEP 475: _posixsubprocess retries close() on EINTR In-Reply-To: <1427975674.16.0.24545541866.issue23851@psf.upfronthosting.co.za> Message-ID: <1427984803.48.0.988382548232.issue23851@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 16:31:43 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 02 Apr 2015 14:31:43 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1427985103.69.0.829352495098.issue3566@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 16:57:07 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Apr 2015 14:57:07 +0000 Subject: [issue23756] Tighten definition of bytes-like objects In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za> Message-ID: <1427986627.6.0.349481940994.issue23756@psf.upfronthosting.co.za> R. David Murray added the comment: > If a Fortran array was allowed in a bytes-like context without memory copying, the order of the array elements would differ from the order returned by the meoryview.tobytes() method, which essentially is defined to copy them out in C-array or flattend-tolist() order. I'm still not seeing how this would cause such an object to throw an error if used in a bytes-like context. I presume by the above that you mean that the results of passing the object directly to a bytes like context differs from the results of calling .tobytes() on it and passing *that* to the bytes like context. That's not what your suggested documentation change says, though. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 17:13:52 2015 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Thu, 02 Apr 2015 15:13:52 +0000 Subject: [issue23852] Wrong FD_DIR file name on OpenBSD Message-ID: <1427987632.4.0.790792340938.issue23852@psf.upfronthosting.co.za> New submission from C?dric Krier: The test_subprocess fails since issue21618 on OpenBSD because the FD_DIR is wrong (/dev/fd instead of /proc/self/fd). ---------- files: fd_dir.patch keywords: patch messages: 239920 nosy: ced priority: normal severity: normal status: open title: Wrong FD_DIR file name on OpenBSD Added file: http://bugs.python.org/file38807/fd_dir.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 17:14:57 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 02 Apr 2015 15:14:57 +0000 Subject: [issue22708] httplib/http.client in method _tunnel used HTTP/1.0 CONNECT method In-Reply-To: <1414045283.61.0.401738994501.issue22708@psf.upfronthosting.co.za> Message-ID: <1427987697.15.0.290528005274.issue22708@psf.upfronthosting.co.za> Demian Brecht added the comment: Thanks for the report and follow up Vova. I've come across this line and it puzzled me as well as to why it's hardcoded. Rather than the hardcoded approach in your patch, I've attached a patch that uses _http_vsn_str which is consistent with other areas of the library. Additionally, I noticed that a failure will occur if the destination address contains characters outside of ASCII range, so I've added support for IDN. I assume that the patch should be committed to tip and maintenance branches as both issues are bugs (there is IDN support elsewhere in the library). ---------- nosy: +demian.brecht stage: resolved -> patch review versions: -Python 3.2, Python 3.3 Added file: http://bugs.python.org/file38808/issue22708.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 17:20:00 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 02 Apr 2015 15:20:00 +0000 Subject: [issue23466] PEP 461: Inconsistency between str and bytes formatting of integers In-Reply-To: <1424024506.86.0.140677708328.issue23466@psf.upfronthosting.co.za> Message-ID: <1427988000.14.0.621515101907.issue23466@psf.upfronthosting.co.za> Ethan Furman added the comment: It's a new feature for 3.5 that is partly responsible for compatibility with 2.7 code. 2.7 raises Overflow error, so 3.5 should also (for out of range values -- wrong value types raise TypeError). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 17:22:08 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Apr 2015 15:22:08 +0000 Subject: [issue23834] socketmodule.c: add sock_call() to fix how the timeout is recomputed In-Reply-To: <1427842506.28.0.704301607448.issue23834@psf.upfronthosting.co.za> Message-ID: <20150402152204.29535.67851@psf.io> Roundup Robot added the comment: New changeset 29c32ca46652 by Victor Stinner in branch '2.7': Issue #23834: Fix socket.sendto(), use the C long type to store the result of https://hg.python.org/cpython/rev/29c32ca46652 New changeset 436bb7ad6349 by Victor Stinner in branch '3.4': Issue #23834: Fix socket.sendto(), use the C Py_ssize_t type to store the https://hg.python.org/cpython/rev/436bb7ad6349 New changeset a064abfd436c by Victor Stinner in branch 'default': (Merge 3.4) Issue #23834: Fix socket.sendto(), use the C Py_ssize_t type to https://hg.python.org/cpython/rev/a064abfd436c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 17:30:24 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Apr 2015 15:30:24 +0000 Subject: [issue23853] PEP 475: handle EINTR in the ssl module Message-ID: <1427988624.66.0.803600947043.issue23853@psf.upfronthosting.co.za> New submission from STINNER Victor: The _ssl module uses an helper function check_socket_and_wait_for_timeout() to poll until the socket is ready (got data or became writable). check_socket_and_wait_for_timeout() always uses the socket timeout. If select() or poll() is interrupted by a signal (fails with EINTR), check_socket_and_wait_for_timeout() is restarted with the same timeout, which doesn't respect the contract of the timeout: the operation must timeout if it takes more than timeout seconds. The code must be modified to recompute the timeout, as done in the new sock_call() function of Modules/socketmodule.c (issue #23618). At least, the timeout must decreases when select()/poll() fails with EINTR. Currently, the timeout is reset after each read/write/handshake operation. IMO the timeout must apply on the total duration of the ssl method, not be reset. But changing this may break backward compatibility :-/ Note: if the signal handler raises an exception, the ssl method fails with the exception. This issue is specific to signal handlers not raising an exception. ---------- messages: 239924 nosy: haypo priority: normal severity: normal status: open title: PEP 475: handle EINTR in the ssl module versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 17:30:56 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Apr 2015 15:30:56 +0000 Subject: [issue23648] PEP 475 meta issue In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za> Message-ID: <1427988656.59.0.776502080547.issue23648@psf.upfronthosting.co.za> STINNER Victor added the comment: New issue #23853: handle EINTR in the ssl module. ---------- dependencies: +PEP 475: handle EINTR in the ssl module _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 17:32:23 2015 From: report at bugs.python.org (Demian Brecht) Date: Thu, 02 Apr 2015 15:32:23 +0000 Subject: [issue8732] Should urrllib2.urlopen send an Accept-Encoding header? In-Reply-To: <1274021231.2.0.0953300031131.issue8732@psf.upfronthosting.co.za> Message-ID: <1427988743.21.0.599839101157.issue8732@psf.upfronthosting.co.za> Demian Brecht added the comment: This doesn't seem to be an issue in 3.4+, the following headers are injected in a call to urlopen(): GET / HTTP/1.1 Accept-Encoding: identity Host: example.com User-Agent: Python-urllib/3.4 Connection: close However, this is not the same behaviour in 2.7: GET / HTTP/1.0 Host: example.com User-Agent: Python-urllib/1.17 That said, I wouldn't see this as a bug but a feature request, so it should be invalid for 2.7. Setting this to pending to close unless anyone has any objections or further details. ---------- nosy: +demian.brecht status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 17:33:14 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 02 Apr 2015 15:33:14 +0000 Subject: [issue23853] PEP 475: handle EINTR in the ssl module In-Reply-To: <1427988624.66.0.803600947043.issue23853@psf.upfronthosting.co.za> Message-ID: <1427988794.93.0.849203032234.issue23853@psf.upfronthosting.co.za> STINNER Victor added the comment: test_ssl_bug.patch: Modify test_handshake_timeout() of test_ssl to show the bug: test_handshake_timeout() hangs with the patch (which sends a signal every millisecond). ---------- keywords: +patch Added file: http://bugs.python.org/file38809/test_ssl_bug.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 17:49:46 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Apr 2015 15:49:46 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <20150402154941.7478.24125@psf.io> Roundup Robot added the comment: New changeset 42a6449e577c by Serhiy Storchaka in branch '2.7': Issue #16840: Tkinter now supports 64-bit integers added in Tcl 8.4 and https://hg.python.org/cpython/rev/42a6449e577c New changeset a6f4d8fa7ab8 by Serhiy Storchaka in branch '3.4': Issue #16840: Tkinter now supports 64-bit integers added in Tcl 8.4 and https://hg.python.org/cpython/rev/a6f4d8fa7ab8 New changeset 9291b28157e1 by Serhiy Storchaka in branch 'default': Issue #16840: Tkinter now supports 64-bit integers added in Tcl 8.4 and https://hg.python.org/cpython/rev/9291b28157e1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 17:49:49 2015 From: report at bugs.python.org (Davin Potts) Date: Thu, 02 Apr 2015 15:49: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: <1427989789.03.0.165328084455.issue23484@psf.upfronthosting.co.za> Davin Potts added the comment: @berker: Sadly, I've read those descriptions in triaging.html more than once and that part apparently did not stick in my head. Hopefully it will now -- thanks. @r.david: Ok, cool -- I had been mentally associating more significance to one versus the other but that helps to understand. As Berker correctly suspected, I would not have expected something labelled "Enhancement" to be allowed into the 2.7 branch so the explanation definitely helps. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 17:54:34 2015 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Thu, 02 Apr 2015 15:54:34 +0000 Subject: [issue20669] OpenBSD: socket.recvmsg tests fail with OSError: [Errno 40] Message too long In-Reply-To: <1392712891.31.0.830541329801.issue20669@psf.upfronthosting.co.za> Message-ID: <1427990074.82.0.289378688861.issue20669@psf.upfronthosting.co.za> Changes by C?dric Krier : ---------- nosy: +ced _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 17:57:00 2015 From: report at bugs.python.org (Jean-Paul Calderone) Date: Thu, 02 Apr 2015 15:57:00 +0000 Subject: [issue20669] OpenBSD: socket.recvmsg tests fail with OSError: [Errno 40] Message too long In-Reply-To: <1392712891.31.0.830541329801.issue20669@psf.upfronthosting.co.za> Message-ID: <1427990220.4.0.0531503841031.issue20669@psf.upfronthosting.co.za> Changes by Jean-Paul Calderone : ---------- nosy: -exarkun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 18:03:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Apr 2015 16:03:41 +0000 Subject: [issue23786] test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... Fatal Python error: Bus error In-Reply-To: <1427377647.96.0.0955568014503.issue23786@psf.upfronthosting.co.za> Message-ID: <1427990621.2.0.855281811466.issue23786@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Just interesting, what is the result of str(memoryview(b'abcdefghijklmnopqrstuvwxyz')[1:], 'ascii') with old and new toolchains. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 18:09:12 2015 From: report at bugs.python.org (Davin Potts) Date: Thu, 02 Apr 2015 16:09:12 +0000 Subject: [issue23852] Wrong FD_DIR file name on OpenBSD In-Reply-To: <1427987632.4.0.790792340938.issue23852@psf.upfronthosting.co.za> Message-ID: <1427990952.75.0.49290593443.issue23852@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 19:08:11 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Apr 2015 17:08:11 +0000 Subject: [issue21526] Support new booleans in Tkinter In-Reply-To: <1400445691.82.0.48051274053.issue21526@psf.upfronthosting.co.za> Message-ID: <20150402170808.29521.9481@psf.io> Roundup Robot added the comment: New changeset 77e5623e22dd by Serhiy Storchaka in branch '2.7': Issue #21526: Skip test_booleans on Tcl < 8.5. https://hg.python.org/cpython/rev/77e5623e22dd New changeset 3b8039c37b37 by Serhiy Storchaka in branch '3.4': Issue #21526: Skip test_booleans on Tcl < 8.5. https://hg.python.org/cpython/rev/3b8039c37b37 New changeset 8ad98ade3f78 by Serhiy Storchaka in branch 'default': Issue #21526: Skip test_booleans on Tcl < 8.5. https://hg.python.org/cpython/rev/8ad98ade3f78 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 19:08:11 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Apr 2015 17:08:11 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <20150402170808.29521.28639@psf.io> Roundup Robot added the comment: New changeset 9905fb0b5885 by Serhiy Storchaka in branch '2.7': Issue #16840: Fixed test_tcl for Tcl < 8.5. https://hg.python.org/cpython/rev/9905fb0b5885 New changeset 1d2444273b3d by Serhiy Storchaka in branch '3.4': Issue #16840: Fixed test_tcl for Tcl < 8.5. https://hg.python.org/cpython/rev/1d2444273b3d New changeset 2398dba039f3 by Serhiy Storchaka in branch 'default': Issue #16840: Fixed test_tcl for Tcl < 8.5. https://hg.python.org/cpython/rev/2398dba039f3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 19:30:10 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 02 Apr 2015 17:30:10 +0000 Subject: [issue23466] PEP 461: Inconsistency between str and bytes formatting of integers In-Reply-To: <1424024506.86.0.140677708328.issue23466@psf.upfronthosting.co.za> Message-ID: <1427995810.63.0.944798131469.issue23466@psf.upfronthosting.co.za> Ethan Furman added the comment: b'%c' is still raising a TypeError. The error message is fine ("%c requires an integer in range(256) or a single byte") but it should be an OverflowError for backwards compatibility. ---------- resolution: fixed -> stage: resolved -> needs patch status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 19:49:29 2015 From: report at bugs.python.org (Joshua J Cogliati) Date: Thu, 02 Apr 2015 17:49:29 +0000 Subject: [issue8027] distutils fail to determine c++ linker with unixcompiler if using ccache In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za> Message-ID: <1427996969.51.0.0201883208751.issue8027@psf.upfronthosting.co.za> Joshua J Cogliati added the comment: Let me try and explain what is trying to be done in the original code, what the fix was, and then discuss some possible better solutions. Original code: if target_lang == "c++" and self.compiler_cxx: linker[0] = self.compiler_cxx[0] Current code: if target_lang == "c++" and self.compiler_cxx: i = 0 if os.path.basename(linker[0]) == "env": i = 1 while '=' in linker[i]: i += 1 linker[i] = self.compiler_cxx[i] Basically, what we have, is two variables, linker, and self.compiler_cxx. By default on my linux system these are: linker=['gcc', '-pthread', '-shared'] self.compiler_cxx=['g++', '-pthread'] So under the current code, since self.compiler_cxx[0] != "env" i=0 so linker[0] = self.compiler_cxx[0] so linker=['g++', '-pthread', '-shared'] So the goal is to switch the linker to something that works better with c++. In the original code: linker[0] = self.compiler_cxx[0] improves things if the first element in the linker variable is the linker executable, and the first element in compiler_cxx is a compiler executable, and the compiler executable works better at linking c++ code than the c linker executable. Next we switch to the current code. I am guessing that Ronald had something like this: linker=['env','BAR=FOO','gcc', '-pthread', '-shared'] self.compiler_cxx=['env','BAR=FOO','g++', '-pthread'] and so with the current code we end up with i=2, and the linker variable ends up with: linker=['env','BAR=FOO','g++', '-pthread', '-shared'] Now, what is the problem we are encountering with the current code? Basically, people want to use things like CXX="ccache g++" So if linker=['gcc', '-pthread', '-shared'] self.compiler_cxx=['ccache', 'g++'] we have i=0, linker[0]=self.compiler_cxx[0] = 'ccache' resulting in linker=['ccache', '-pthread', '-shared'] which will fail, because ccache expects the first argument to be the compiler executable (that is 'g++' not '-pthread') So, how can we fix this? If the linker can link c++ code, then the optimal solution is to do nothing, as in remove the entire if target_lang == "c++" and self.compiler_cxx: ... (The fix-distutils-* patches I have created do this solution) We could special case ccache: if target_lang == "c++" and self.compiler_cxx: if os.path.basename(self.compiler_cxx[0]) == "ccache": linker[0:1] = self.compiler_cxx[0:2] elif os.path.basename(linker[0]) == "env": ... We could hope that what we actually want is the entire compiler_cxx: if target_lang == "c++" and self.compiler_cxx: linker[0:1] = self.compiler_cxx[:] Maybe we could special case c++ a little earlier (since linker_exe is just cc by default): if target_desc == CCompiler.EXECUTABLE and target_lang == "c++" and self.compiler_cxx: linker = self.compiler_cxx[:] elif target_desc == CCompiler.EXECUTABLE: linker = self.linker_exe[:] else: linker = self.linker_so[:] None of these solutions make me feel awesome. The real problem is that we have no way to set the c++ linker. I don't see any variable listed like this Make's implicit variables section. A secondary problem is that we string concatenate the LDSHARED and LDFLAGS (in the line: ldshared = ldshared + ' ' + os.environ['LDFLAGS'] in sysconfig.py) Another secondary problem is that we don't look for a CXXFLAGS varible, and so people stuff parameters into CXX instead. If the two secondary issues did not exist we could reasonably reliably do something like linker = cxx + ldflags which might actually work for all the cases that are currently covered and work where cxx=['ccache','g++'] The current code is broken, how do we want to fix it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 19:50:06 2015 From: report at bugs.python.org (Ali Arar) Date: Thu, 02 Apr 2015 17:50:06 +0000 Subject: [issue23854] qtconsole and all windows based python have issues loading Message-ID: <1427997006.27.0.45801285354.issue23854@psf.upfronthosting.co.za> New submission from Ali Arar: All of the sudden, all windows based python stopped working. qtconsole and spyder. Also, conda, pip, and easy_setup are issuing error messages. Below is the feedback I am getting. I uninstalled and reinstalled the package that was working perfectly fine. Also, downloaded Anaconda-2.2.0-Windows-x86_64.exe. =================== ipython qtconsole: ------------------- Error in sys.excepthook: Traceback (most recent call last): File "D:\Anaconda\lib\site-packages\IPython\qt\console\qtconsoleapp.py", line 45, in gui_excepthook old_excepthook(exctype, value, tb) TypeError: 'NoneType' object is not callable Original exception was: Traceback (most recent call last): File "D:\Anaconda\Scripts\ipython-script.py", line 5, in sys.exit(start_ipython()) File "D:\Anaconda\lib\site-packages\IPython\__init__.py", line 120, in start_ipython return launch_new_instance(argv=argv, **kwargs) File "D:\Anaconda\lib\site-packages\IPython\config\application.py", line 573, in launch_instance app.initialize(argv) File "", line 2, in initialize File "D:\Anaconda\lib\site-packages\IPython\config\application.py", line 75, in catch_config_error return method(app, *args, **kwargs) File "D:\Anaconda\lib\site-packages\IPython\terminal\ipapp.py", line 321, in initialize super(TerminalIPythonApp, self).initialize(argv) File "", line 2, in initialize File "D:\Anaconda\lib\site-packages\IPython\config\application.py", line 75, in catch_config_error return method(app, *args, **kwargs) File "D:\Anaconda\lib\site-packages\IPython\core\application.py", line 369, in initialize self.parse_command_line(argv) File "D:\Anaconda\lib\site-packages\IPython\terminal\ipapp.py", line 316, in parse_command_line return super(TerminalIPythonApp, self).parse_command_line(argv) File "", line 2, in parse_command_line File "D:\Anaconda\lib\site-packages\IPython\config\application.py", line 75, in catch_config_error return method(app, *args, **kwargs) File "D:\Anaconda\lib\site-packages\IPython\config\application.py", line 471, in parse_command_line return self.initialize_subcommand(subc, subargv) File "", line 2, in initialize_subcommand File "D:\Anaconda\lib\site-packages\IPython\config\application.py", line 75, in catch_config_error return method(app, *args, **kwargs) File "D:\Anaconda\lib\site-packages\IPython\config\application.py", line 402, in initialize_subcommand subapp = import_item(subapp) File "D:\Anaconda\lib\site-packages\IPython\utils\importstring.py", line 42, in import_item module = __import__(package, fromlist=[obj]) File "D:\Anaconda\lib\site-packages\IPython\qt\console\qtconsoleapp.py", line 56, in from IPython.qt.console.ipython_widget import IPythonWidget File "D:\Anaconda\lib\site-packages\IPython\qt\console\ipython_widget.py", line 23, in from .frontend_widget import FrontendWidget File "D:\Anaconda\lib\site-packages\IPython\qt\console\frontend_widget.py", line 25, in from .pygments_highlighter import PygmentsHighlighter File "D:\Anaconda\lib\site-packages\IPython\qt\console\pygments_highlighter.py", line 3, in from pygments.formatters.html import HtmlFormatter File "D:\Anaconda\lib\site-packages\pygments\formatters\__init__.py", line 19, in from pygments.plugin import find_plugin_formatters File "D:\Anaconda\lib\site-packages\pygments\plugin.py", line 39, in import pkg_resources File "D:\Anaconda\lib\site-packages\setuptools-14.3-py2.7.egg\pkg_resources\__init__.py", line 1366, in File "D:\Anaconda\lib\site-packages\setuptools-14.3-py2.7.egg\pkg_resources\__init__.py", line 1370, in MarkerEvaluation AttributeError: 'module' object has no attribute 'python_version' =============================================== D:\>pip --------- Traceback (most recent call last): File "D:\Anaconda\Scripts\pip-script.py", line 3, in from pip import main File "D:\Anaconda\lib\site-packages\pip\__init__.py", line 13, in from pip.utils import get_installed_distributions, get_prog File "D:\Anaconda\lib\site-packages\pip\utils\__init__.py", line 22, in from pip._vendor import pkg_resources, six File "D:\Anaconda\lib\site-packages\pip\_vendor\__init__.py", line 61, in load_module __import__(name) File "D:\Anaconda\lib\site-packages\pip\_vendor\pkg_resources\__init__.py", line 1316, in class MarkerEvaluation(object): File "D:\Anaconda\lib\site-packages\pip\_vendor\pkg_resources\__init__.py", line 1320, in MarkerEvaluation 'python_full_version': platform.python_version, AttributeError: 'module' object has no attribute 'python_version' ======================================================== D:\>conda ---------- Traceback (most recent call last): File "D:\Anaconda\Scripts\conda-script.py", line 2, in from conda.cli import main File "D:\Anaconda\lib\site-packages\conda\cli\__init__.py", line 8, in from conda.cli.main import main File "D:\Anaconda\lib\site-packages\conda\cli\main.py", line 45, in from conda.cli import common File "D:\Anaconda\lib\site-packages\conda\cli\common.py", line 11, in import conda.config as config File "D:\Anaconda\lib\site-packages\conda\config.py", line 12, in from platform import machine ImportError: cannot import name machine ==================================================== D:\>spyder ---------- 'module' object has no attribute 'python_version' Traceback (most recent call last): File "D:\Anaconda\Scripts\spyder-script.py", line 1, in from spyderlib import start_app File "D:\Anaconda\lib\site-packages\spyderlib\start_app.py", line 14, in from spyderlib.config import CONF File "D:\Anaconda\lib\site-packages\spyderlib\config.py", line 22, in from spyderlib.utils import iofuncs, codeanalysis File "D:\Anaconda\lib\site-packages\spyderlib\utils\iofuncs.py", line 26, in import pandas as pd File "D:\Anaconda\lib\site-packages\pandas\__init__.py", line 7, in from . import hashtable, tslib, lib File "pandas\tslib.pyx", line 46, in init pandas.tslib (pandas\tslib.c:79899) File "D:\Anaconda\lib\site-packages\pytz\__init__.py", line 29, in from pkg_resources import resource_stream File "D:\Anaconda\lib\site-packages\setuptools-14.3-py2.7.egg\pkg_resources\__init__.py", line 1366, in File "D:\Anaconda\lib\site-packages\setuptools-14.3-py2.7.egg\pkg_resources\__init__.py", line 1370, in MarkerEvaluation AttributeError: 'module' object has no attribute 'python_version' ================================================================ ---------- components: Windows messages: 239935 nosy: a3arar, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: qtconsole and all windows based python have issues loading type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 20:01:02 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Apr 2015 18:01:02 +0000 Subject: [issue2175] Expat sax parser silently ignores the InputSource protocol In-Reply-To: <1203861783.69.0.636987169656.issue2175@psf.upfronthosting.co.za> Message-ID: <20150402180058.16244.1919@psf.io> Roundup Robot added the comment: New changeset 84d49ad9109b by Serhiy Storchaka in branch '2.7': Issue #2175: Added tests for xml.sax.saxutils.prepare_input_source(). https://hg.python.org/cpython/rev/84d49ad9109b New changeset fa47897e7889 by Serhiy Storchaka in branch '3.4': Issue #2175: Added tests for xml.sax.saxutils.prepare_input_source(). https://hg.python.org/cpython/rev/fa47897e7889 New changeset e0292b3ba245 by Serhiy Storchaka in branch 'default': Issue #2175: Added tests for xml.sax.saxutils.prepare_input_source(). https://hg.python.org/cpython/rev/e0292b3ba245 New changeset 407883c52bf3 by Serhiy Storchaka in branch 'default': Issue #2175: SAX parsers now support a character stream of InputSource object. https://hg.python.org/cpython/rev/407883c52bf3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 20:05:09 2015 From: report at bugs.python.org (ddvento@ucar.edu) Date: Thu, 02 Apr 2015 18:05:09 +0000 Subject: [issue9026] argparse subcommands not printed in the same order they were added In-Reply-To: <1427960724.38.0.123995960715.issue9026@psf.upfronthosting.co.za> Message-ID: ddvento at ucar.edu added the comment: You are right, this problem is not coming from python itself, but more from setuptools and its use by scoop. See https://github.com/soravux/scoop/issues/16 and http://stackoverflow.com/questions/29374044/ for details Regards, Davide Del Vento, NCAR Computational & Information Services Laboratory Consulting Services Software Engineer http://www2.cisl.ucar.edu/uss/csg/ SEA Chair http://sea.ucar.edu/ office: Mesa Lab, Room 55G phone: (303) 497-1233 On Thu, Apr 2, 2015 at 1:45 AM, Ned Deily wrote: > > Ned Deily added the comment: > > @ddvento: This issue has been closed and the fixes for it released several > years ago. Comments added here will likely be ignored. If you believe > there is a problem with current releases (for Python 2, Python 2.7.9 is > current), please open a new issue and document how to reproduce, including > on what platform(s) and with which versions of Python. FWIW, the original > test case in this issue works correctly with both a 2.7.6 and current 2.7.9 > on the platforms I tried it with. > > ---------- > nosy: +ned.deily > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 20:09:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Apr 2015 18:09:58 +0000 Subject: [issue1483] xml.sax.saxutils.prepare_input_source ignores character stream in InputSource In-Reply-To: <1195653795.8.0.542576278207.issue1483@psf.upfronthosting.co.za> Message-ID: <1427998198.61.0.365726017263.issue1483@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed in issue2175. ---------- resolution: -> out of date stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 20:12:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Apr 2015 18:12:48 +0000 Subject: [issue2174] xml.sax.xmlreader does not support the InputSource protocol In-Reply-To: <1203861152.32.0.18277152276.issue2174@psf.upfronthosting.co.za> Message-ID: <1427998368.36.0.891590386804.issue2174@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Fixed in issue2175 (in 3.5 only). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 20:25:39 2015 From: report at bugs.python.org (Tim Golden) Date: Thu, 02 Apr 2015 18:25:39 +0000 Subject: [issue21319] WindowsRegistryFinder never added to sys.meta_path In-Reply-To: <1398056666.81.0.531490496163.issue21319@psf.upfronthosting.co.za> Message-ID: <1427999139.9.0.761770424843.issue21319@psf.upfronthosting.co.za> Tim Golden added the comment: Turns out to be non-issue after all! I was working through the import code for other reasons and noticed that the WindowsRegistryFinder was there. I'll spare you the complications of debugging the _bootstrap part of import, but basically the code in _bootstrap.py:_setup loads the "nt" module directly instead of having it masquerade as "os" as it normally does. Therefore os.__name__ is indeed "nt" and the WindowsRegistryFinder is added to sys.meta_path ---------- resolution: -> works for me stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 20:30:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Apr 2015 18:30:35 +0000 Subject: [issue23466] PEP 461: Inconsistency between str and bytes formatting of integers In-Reply-To: <1424024506.86.0.140677708328.issue23466@psf.upfronthosting.co.za> Message-ID: <1427999435.42.0.302593216146.issue23466@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: OverflowError is for platform limitations (such as the size of machine word or addressed space). When limits are well defined and platform-independent, ValueError or may be TypeError are considered as better types. It would be better to change OverflowError to ValueError or TypeError in formatting. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 21:14:16 2015 From: report at bugs.python.org (J. Morton) Date: Thu, 02 Apr 2015 19:14:16 +0000 Subject: [issue22516] Windows Installer won't - even when using "just for me"option In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za> Message-ID: <1428002056.73.0.744161083256.issue22516@psf.upfronthosting.co.za> J. Morton added the comment: As the originator, I've noticed that the discussion (while illuminating - and a lot more than I expected!) seems to have gone off on several tangents. I'd like to remind everyone that this request is for an unrestricted Windows install (e.g. "binary") package of standard/basic python - nothing more. Not to dampen the discussion but I see side issues such as impact on other O/S's, use of other (non-CPython) distributions, etc. as being outside the scope of the request. While side issues may need to be considered while working on the request they should be raised as separate issues, not handled under this one. Also, issues related to how this request affects specific "plug ins", e.g. numpy, also seem to be out of scope for this request (since users add them after successful installation) and should be handled in a similar matter. My view anyway, YMMV ---------- components: -Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 21:39:12 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Apr 2015 19:39:12 +0000 Subject: [issue23854] qtconsole and all windows based python have issues loading In-Reply-To: <1427997006.27.0.45801285354.issue23854@psf.upfronthosting.co.za> Message-ID: <1428003552.27.0.0021575920742.issue23854@psf.upfronthosting.co.za> R. David Murray added the comment: This is very unlikely to be a core python bug. Please post your problem to the python-list mailing list, where you are more likely to get help in solving your problem. ---------- nosy: +r.david.murray resolution: -> third party stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 21:56:17 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 02 Apr 2015 19:56:17 +0000 Subject: [issue22516] Windows Installer won't - even when using "just for me"option In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za> Message-ID: <1428004577.63.0.116421702446.issue22516@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- components: +Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 22:08:11 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 02 Apr 2015 20:08:11 +0000 Subject: [issue22516] Windows Installer won't - even when using "just for me"option In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za> Message-ID: <1428005291.69.0.557354159131.issue22516@psf.upfronthosting.co.za> R. David Murray added the comment: I just reviewed this whole issue. Steve says that the original issue you raised will be resolved in 3.5 (I believe pretty much already has been?). So given the last couple of messages I'm going to re-close this, as a continuing discussion here seems to be contra-indicated :) ---------- components: -Windows resolution: later -> fixed status: languishing -> closed versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 22:22:10 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 02 Apr 2015 20:22:10 +0000 Subject: [issue10590] Parameter type error for xml.sax.parseString(string, ...) In-Reply-To: <1291145861.74.0.873169501029.issue10590@psf.upfronthosting.co.za> Message-ID: <20150402202207.27440.55847@psf.io> Roundup Robot added the comment: New changeset 3ac1b21fbb42 by Serhiy Storchaka in branch '2.7': Issue #10590: Added tests for xml.sax.parse() and xml.sax.parseString(). https://hg.python.org/cpython/rev/3ac1b21fbb42 New changeset ca8666310eb3 by Serhiy Storchaka in branch '3.4': Issue #10590: Added tests for xml.sax.parse() and xml.sax.parseString(). https://hg.python.org/cpython/rev/ca8666310eb3 New changeset 846c165cf643 by Serhiy Storchaka in branch 'default': Issue #10590: Added tests for xml.sax.parse() and xml.sax.parseString(). https://hg.python.org/cpython/rev/846c165cf643 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 22:25:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Apr 2015 20:25:07 +0000 Subject: [issue10590] Parameter type error for xml.sax.parseString(string, ...) In-Reply-To: <1291145861.74.0.873169501029.issue10590@psf.upfronthosting.co.za> Message-ID: <1428006307.35.0.0427155194838.issue10590@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: After resolving issue2175 and committing tests that works with current code, only minimum of changes are left. Here is a patch that adds support of string argument in xml.sax.parseString(). ---------- components: +Library (Lib) -Unicode stage: needs patch -> patch review versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 22:31:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Apr 2015 20:31:57 +0000 Subject: [issue2175] Expat sax parser silently ignores the InputSource protocol In-Reply-To: <1203861783.69.0.636987169656.issue2175@psf.upfronthosting.co.za> Message-ID: <1428006717.48.0.548762711734.issue2175@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 Thu Apr 2 22:36:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Apr 2015 20:36:02 +0000 Subject: [issue10590] Parameter type error for xml.sax.parseString(string, ...) In-Reply-To: <1291145861.74.0.873169501029.issue10590@psf.upfronthosting.co.za> Message-ID: <1428006962.81.0.0881258900419.issue10590@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file38810/sax_parse_3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 2 22:48:44 2015 From: report at bugs.python.org (Eric Snow) Date: Thu, 02 Apr 2015 20:48:44 +0000 Subject: [issue21319] WindowsRegistryFinder never added to sys.meta_path In-Reply-To: <1398056666.81.0.531490496163.issue21319@psf.upfronthosting.co.za> Message-ID: <1428007724.05.0.11329717858.issue21319@psf.upfronthosting.co.za> Eric Snow added the comment: Awesome. Thanks Tim. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 00:11:43 2015 From: report at bugs.python.org (Bill Parker) Date: Thu, 02 Apr 2015 22:11:43 +0000 Subject: [issue23855] Missing Sanity Check for malloc() in PC/_msi.c Message-ID: <1428012703.71.0.811050257631.issue23855@psf.upfronthosting.co.za> New submission from Bill Parker: Hello All, In reviewing code in Python-3.4.3/PC/_msi.c, I found a call to malloc() at line 326 in function 'static PyObject* msierror(int status)' in which the call is made and assigned to variable 'res', but no check for NULL, indicating failure is made afterwards. The patch below corrects this issue: --- _msi.c.orig 2015-04-02 15:01:02.882326352 -0700 +++ _msi.c 2015-04-02 15:02:43.382099357 -0700 @@ -324,6 +324,10 @@ code = MsiRecordGetInteger(err, 1); /* XXX code */ if (MsiFormatRecord(0, err, res, &size) == ERROR_MORE_DATA) { res = malloc(size+1); + if (res == NULL) /* malloc() failed, out of memory... */ + PyErr_SetString(MSIError, "out of memory"); + return NULL; + } MsiFormatRecord(0, err, res, &size); res[size]='\0'; } ---------- components: Windows files: _msi.c.patch keywords: patch messages: 239948 nosy: dogbert2, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Missing Sanity Check for malloc() in PC/_msi.c type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file38811/_msi.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 00:28:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Apr 2015 22:28:11 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <1428013691.12.0.243960735926.issue16840@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 Apr 3 00:28:32 2015 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Thu, 02 Apr 2015 22:28:32 +0000 Subject: [issue20718] OpenBSD/AIX: tests passing a file descriptor with sendmsg/recvmsg failures In-Reply-To: <1392974057.71.0.420386610945.issue20718@psf.upfronthosting.co.za> Message-ID: <1428013712.68.0.426279960671.issue20718@psf.upfronthosting.co.za> Changes by C?dric Krier : ---------- nosy: +ced _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 00:28:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 02 Apr 2015 22:28:46 +0000 Subject: [issue21526] Support new booleans in Tkinter In-Reply-To: <1400445691.82.0.48051274053.issue21526@psf.upfronthosting.co.za> Message-ID: <1428013726.7.0.873129023461.issue21526@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 01:32:18 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 02 Apr 2015 23:32:18 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message_on_Wine?= In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> Message-ID: <1428017538.47.0.226459570101.issue22977@psf.upfronthosting.co.za> Martin Panter added the comment: Thanks for fixing the test Victor. The ctypes.pythonapi trick looks like a much better way. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 02:16:01 2015 From: report at bugs.python.org (Jean-Paul Calderone) Date: Fri, 03 Apr 2015 00:16:01 +0000 Subject: [issue20718] OpenBSD/AIX: tests passing a file descriptor with sendmsg/recvmsg failures In-Reply-To: <1392974057.71.0.420386610945.issue20718@psf.upfronthosting.co.za> Message-ID: <1428020161.14.0.963138155097.issue20718@psf.upfronthosting.co.za> Changes by Jean-Paul Calderone : ---------- nosy: -exarkun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 02:22:30 2015 From: report at bugs.python.org (Jean-Paul Calderone) Date: Fri, 03 Apr 2015 00:22:30 +0000 Subject: [issue18629] future division breaks timedelta division by integer In-Reply-To: <1375456931.04.0.558889166858.issue18629@psf.upfronthosting.co.za> Message-ID: <1428020550.66.0.112701978258.issue18629@psf.upfronthosting.co.za> Changes by Jean-Paul Calderone : ---------- nosy: -exarkun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 02:23:17 2015 From: report at bugs.python.org (Jean-Paul Calderone) Date: Fri, 03 Apr 2015 00:23:17 +0000 Subject: [issue6377] distutils compiler switch ignored In-Reply-To: <1246299740.9.0.786372120366.issue6377@psf.upfronthosting.co.za> Message-ID: <1428020597.56.0.249757841776.issue6377@psf.upfronthosting.co.za> Changes by Jean-Paul Calderone : ---------- nosy: -exarkun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 02:25:31 2015 From: report at bugs.python.org (Jean-Paul Calderone) Date: Fri, 03 Apr 2015 00:25:31 +0000 Subject: [issue6555] distutils config file should have the same name on both platforms and all scopes In-Reply-To: <1248379635.87.0.00387112145543.issue6555@psf.upfronthosting.co.za> Message-ID: <1428020731.18.0.0218065741029.issue6555@psf.upfronthosting.co.za> Changes by Jean-Paul Calderone : ---------- nosy: -exarkun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 03:48:01 2015 From: report at bugs.python.org (koobs) Date: Fri, 03 Apr 2015 01:48:01 +0000 Subject: [issue23817] Consider FreeBSD like any other OS in SOVERSION In-Reply-To: <1427806007.43.0.118979455245.issue23817@psf.upfronthosting.co.za> Message-ID: <1428025681.56.0.303547537397.issue23817@psf.upfronthosting.co.za> koobs added the comment: @haypo, yes, absolutely and no We will backport to security-only branches ourselves. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 03:58:07 2015 From: report at bugs.python.org (koobs) Date: Fri, 03 Apr 2015 01:58:07 +0000 Subject: [issue7352] pythonx.y-config --ldflags out of /usr and missing -L In-Reply-To: <1258578467.08.0.137292547946.issue7352@psf.upfronthosting.co.za> Message-ID: <1428026287.13.0.309844509362.issue7352@psf.upfronthosting.co.za> koobs added the comment: @doko, as per the original report by Joel, the issue is: * Reproducible with --enable-shared (most downstream OS's / packages use this) Additionally: * in the python script, not the shell script (by default used by < 3.4) * Is reproducible in all branches (including default) See the following test matrix from 'default' ======================================================================== ./configure && make ======================================================================== LD_LIBRARY_PATH=. ./python python-config.py --ldflags -L/usr/local/lib/python3.5/config-3.5m -lpython3.5m -lutil -lm -Wl,--export-dynamic sh python-config --ldflags -LNONE/lib/python3.5/config-3.5m -L/mnt/home/user/repos/lib -lpython3.5m -lutil -lm -Wl,--export-dynamic ^--- hmm .. "NONE" ... what? ======================================================================== ./configure --prefix=/usr/local && make ======================================================================== LD_LIBRARY_PATH=. ./python python-config.py --ldflags -L/usr/local/lib/python3.5/config-3.5m -lpython3.5m -lutil -lm -Wl,--export-dynamic sh python-config --ldflags -L/mnt/home/user/repos/lib/python3.5/config-3.5m -L/mnt/home/user/repos/lib -lpython3.5m -lutil -lm -Wl,--export-dynamic ======================================================================== ./configure --enable-shared && make ======================================================================== LD_LIBRARY_PATH=. ./python python-config.py --ldflags -lpython3.5m -lutil -lm -Wl,--export-dynamic sh python-config --ldflags -L/mnt/home/user/repos/lib -lpython3.5m -lutil -lm -Wl,--export-dynamic ======================================================================== ./configure --enable-shared --prefix=/usr/local && make ======================================================================== LD_LIBRARY_PATH=. ./python python-config.py --ldflags -lpython3.5m -lutil -lm -Wl,--export-dynamic sh python-config --ldflags -L/mnt/home/user/repos/lib -lpython3.5m -lutil -lm -Wl,--export-dynamic While I'm here, update versions. Note: This issue was originally reported for 2.7, 3.2, 3.3 ---------- versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 04:50:10 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 03 Apr 2015 02:50:10 +0000 Subject: [issue22708] httplib/http.client in method _tunnel used HTTP/1.0 CONNECT method In-Reply-To: <1414045283.61.0.401738994501.issue22708@psf.upfronthosting.co.za> Message-ID: <1428029410.63.0.863659617307.issue22708@psf.upfronthosting.co.za> Martin Panter added the comment: Patch looks good to me. I?m not an expert on non-ASCII domain names, but enabling HTTP 1.1 should be okay, at least for new versions of Python. CONNECT for HTTP 1.1 is described at . Also, see the code review about removing an comment about HTTP 1.1 blessing. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 05:27:59 2015 From: report at bugs.python.org (Mark Mikofski) Date: Fri, 03 Apr 2015 03:27:59 +0000 Subject: [issue22516] Windows Installer won't - even when using "just for me"option In-Reply-To: <1412023007.96.0.578659583634.issue22516@psf.upfronthosting.co.za> Message-ID: <1428031679.0.0.412898602052.issue22516@psf.upfronthosting.co.za> Mark Mikofski added the comment: J. Morton and anyone else needing a Python-2.7.9 Windows release to use without admin rights or to embed in a personal application can see my blog to roll there own or download one of the versions from my dropbox http://poquitopicante.blogspot.com/2015/03/building-python-x64-on-windows-7-with.html https://www.dropbox.com/s/wc2x2or2477f4as/Python27-x86_asbuilt.zip?dl=0 https://www.dropbox.com/s/bcmh11kha9go8t6/Python27-x64_asbuilt.zip?dl=0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 07:14:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Apr 2015 05:14:28 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message_on_Wine?= In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> Message-ID: <1428038068.15.0.38033813181.issue22977@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 07:37:23 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Apr 2015 05:37:23 +0000 Subject: [issue23817] Consider FreeBSD like any other OS in SOVERSION In-Reply-To: <1428025681.56.0.303547537397.issue23817@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: Oh, I expected such change to break backward compatibility. If it doesn't, it's fine. Koobs, would you like to commit the patch? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 08:04:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Apr 2015 06:04:12 +0000 Subject: [issue23466] PEP 461: Inconsistency between str and bytes formatting of integers In-Reply-To: <1424024506.86.0.140677708328.issue23466@psf.upfronthosting.co.za> Message-ID: <1428041052.43.0.0801817892797.issue23466@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that makes bytes formatting raise an OverflowError if integer argument of %c is out of range. ---------- Added file: http://bugs.python.org/file38812/bytes_format_overflow.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 08:19:26 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Apr 2015 06:19:26 +0000 Subject: [issue22643] Integer overflow in case_operation In-Reply-To: <1413384630.17.0.213972312804.issue22643@psf.upfronthosting.co.za> Message-ID: <1428041966.38.0.589485058056.issue22643@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/3466/steps/test/logs/stdio ====================================================================== ERROR: test_case_operation_overflow (test.test_unicode.UnicodeTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_unicode.py", line 852, in test_case_operation_overflow self.assertRaises(OverflowError, ("?"*(2**32//12 + 1)).upper) MemoryError ---------------------------------------------------------------------- ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 10:33:46 2015 From: report at bugs.python.org (Tim Golden) Date: Fri, 03 Apr 2015 08:33:46 +0000 Subject: [issue23856] build.bat -e shouldn't also build Message-ID: <1428050026.69.0.479392405161.issue23856@psf.upfronthosting.co.za> New submission from Tim Golden: PCBuild\build.bat takes an argument of -e to pull in external libraries. Either by accident or by design the main build will run in addition. However if you'd run pcbuild -e simply to pull in externals, you might not have specified extra build params, such as -d or -p x64. The attached patch naively drops out after get_externals has been called; other possibilities might include carrying on if -e was not the only parameter. ---------- components: Windows files: build-externals.patch keywords: patch messages: 239957 nosy: steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: patch review status: open title: build.bat -e shouldn't also build type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file38813/build-externals.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 10:48:40 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Apr 2015 08:48:40 +0000 Subject: [issue23466] PEP 461: Inconsistency between str and bytes formatting of integers In-Reply-To: <1424024506.86.0.140677708328.issue23466@psf.upfronthosting.co.za> Message-ID: <1428050920.88.0.0515749300504.issue23466@psf.upfronthosting.co.za> STINNER Victor added the comment: > b'%c' is still raising a TypeError. The error message is fine ("%c requires an integer in range(256) or a single byte") but it should be an OverflowError for backwards compatibility. I don't understand why you care so much on the exact exception. It doesn't look right to me to rely on the *exact* exception raised by "%c" % arg. It's an obvious bug in the application. Sometimes, you may want to be extra safe and catch exception while formating a message. The logging module does this. But the logging doesn't care of the exact exception, it uses a generic "except Except:" in StreamHandler.emit(): def emit(self, record): try: msg = self.format(record) stream = self.stream stream.write(msg) stream.write(self.terminator) self.flush() except Exception: self.handleError(record) IMO b"%c" % int must raise ValueError, not OverflowError, if the value is not in the range 0..255. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 10:53:54 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Apr 2015 08:53:54 +0000 Subject: [issue22643] Integer overflow in case_operation In-Reply-To: <1413384630.17.0.213972312804.issue22643@psf.upfronthosting.co.za> Message-ID: <1428051234.96.0.38293469203.issue22643@psf.upfronthosting.co.za> STINNER Victor added the comment: > self.assertRaises(OverflowError, ("?"*(2**32//12 + 1)).upper) > MemoryError Hum, even with the PEP 393, this string is still large: 682 MB. $ python3 Python 3.4.1 (default, Nov 3 2014, 14:38:10) >>> sys.getsizeof("?"*(2**32//12 + 1)) / 1024.**2 682.6667385101318 I guess that Serhiy suggests to put a @bigmemtest decorator on test_case_operation_overflow(). The test expects that large_string.upper() raises immediatly an OverflowError, so I understand that a new string is not created. Hum, it's strange to have an OverflowError here. Integer overflow on memory allocation usually raises MemoryError, not OverflowError. It looks like unicodeobject.c is not consistent here. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 11:06:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Apr 2015 09:06:09 +0000 Subject: [issue22643] Integer overflow in case_operation In-Reply-To: <1413384630.17.0.213972312804.issue22643@psf.upfronthosting.co.za> Message-ID: <1428051969.32.0.0517182880661.issue22643@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It's strange to have "?" here. Should be "?". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 11:09:45 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Apr 2015 09:09:45 +0000 Subject: [issue22351] NNTP constructor exception leaves socket for garbage collector In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za> Message-ID: <20150403090941.75252.4707@psf.io> Roundup Robot added the comment: New changeset c3e7a670dda2 by Victor Stinner in branch '3.4': Issue #22351: Fix test_nntplib if the ssl module is missing https://hg.python.org/cpython/rev/c3e7a670dda2 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 11:10:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Apr 2015 09:10:56 +0000 Subject: [issue23466] PEP 461: Inconsistency between str and bytes formatting of integers In-Reply-To: <1424024506.86.0.140677708328.issue23466@psf.upfronthosting.co.za> Message-ID: <1428052256.51.0.345763397355.issue23466@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue18184. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 11:26:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Apr 2015 09:26:48 +0000 Subject: [issue22351] NNTP constructor exception leaves socket for garbage collector In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za> Message-ID: <1428053208.33.0.588656388664.issue22351@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Good catch. But may be better to report MockSslTests as skipped instead of silently omit them. ---------- Added file: http://bugs.python.org/file38814/issue22351_skip_MockSslTests.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 11:27:56 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Apr 2015 09:27:56 +0000 Subject: [issue22351] NNTP constructor exception leaves socket for garbage collector In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za> Message-ID: <1428053276.17.0.190279506387.issue22351@psf.upfronthosting.co.za> STINNER Victor added the comment: > Good catch. But may be better to report MockSslTests as skipped instead of silently omit them. I don't know how to do that. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 12:38:06 2015 From: report at bugs.python.org (Robert Kuska) Date: Fri, 03 Apr 2015 10:38:06 +0000 Subject: [issue23857] [RFE] Make certificate verification optionable Message-ID: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> New submission from Robert Kuska: Proposed patch adds possibility to opt-out certificate verification. Disclaimer: it is just proof of concept as the config value is hard-coded. How it works? This patch depends on existence of config file which holds information about the protocol settings. > $ cat cert-verification.conf [https] # each protocol affected by cert-verification got its own section verify=platform_default Possible values for verify are: enable - to enable certificate verification disable - to disable certificate verification platform_default - to use default (platform-specific) settings Why platform_default? This choice is for users who don't care about the security settings so they put the decision into their platform (distro) from which they get python. In rpm we can set package to not replace user edited configs when rpm is updated, so if user change the default value of config the config will remain the same. Python example: >>> import http.client >>> cn = http.client.HTTPSConnection('www.google.com') >>> cn._context.verify_mode 0L # CERT_NONE >>> # config changed to verify=enable, still same interpreter >>> cn2 = http.client.HTTPSConnection('www.google.com') >>> cn2._context.verify_mode 2L # CERT_REQUIRED This is how currently works patch attached, but I guess it would make more sense make this behave consistent within the same interpreter even when config is changed and the change will be propagated in the next interpreter run/service restart. Also the patch could be changed to instead of being protocol based to be module based, but this would need also patching the affected modules. I open the RFE mainly to see if there is a will to implement optionable certificate verification in upstream as it is in downstream [citation needed]. I've added some people to nosy list based on https://docs.python.org/devguide/experts.html ---------- components: Library (Lib) messages: 239965 nosy: alex, dstufft, haypo, janssen, ncoghlan, pitrou, rkuska priority: normal severity: normal status: open title: [RFE] Make certificate verification optionable type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 12:39:34 2015 From: report at bugs.python.org (Robert Kuska) Date: Fri, 03 Apr 2015 10:39:34 +0000 Subject: [issue23857] [RFE] Make certificate verification optionable In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428057574.18.0.515029021188.issue23857@psf.upfronthosting.co.za> Changes by Robert Kuska : ---------- nosy: +bkabrda _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 12:47:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Apr 2015 10:47:04 +0000 Subject: [issue22351] NNTP constructor exception leaves socket for garbage collector In-Reply-To: <1428053276.17.0.190279506387.issue22351@psf.upfronthosting.co.za> Message-ID: Serhiy Storchaka added the comment: See the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 13:37:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Apr 2015 11:37:00 +0000 Subject: [issue23834] socketmodule.c: add sock_call() to fix how the timeout is recomputed In-Reply-To: <1427842506.28.0.704301607448.issue23834@psf.upfronthosting.co.za> Message-ID: <20150403113657.16495.27907@psf.io> Roundup Robot added the comment: New changeset 7a9c49885cd3 by Victor Stinner in branch 'default': Issue #23834: Simplify timeout handling https://hg.python.org/cpython/rev/7a9c49885cd3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 13:37:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Apr 2015 11:37:00 +0000 Subject: [issue23853] PEP 475: handle EINTR in the ssl module In-Reply-To: <1427988624.66.0.803600947043.issue23853@psf.upfronthosting.co.za> Message-ID: <20150403113657.16495.41950@psf.io> Roundup Robot added the comment: New changeset 753233baf27e by Victor Stinner in branch 'default': Issue #23853: Cleanup _ssl.c https://hg.python.org/cpython/rev/753233baf27e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 13:37:01 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Apr 2015 11:37:01 +0000 Subject: [issue22117] Rewrite pytime.h to work on nanoseconds In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za> Message-ID: <20150403113657.16495.63184@psf.io> Roundup Robot added the comment: New changeset d976683671ba by Victor Stinner in branch 'default': Issue #22117: Add a new _PyTime_FromSeconds() function https://hg.python.org/cpython/rev/d976683671ba ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 13:37:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Apr 2015 11:37:10 +0000 Subject: [issue22643] Integer overflow in case_operation In-Reply-To: <1428051969.32.0.0517182880661.issue22643@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: > It's strange to have "?" here. Should be "?". Oh right, I saw "?" in the bug tracker and in the buildbot output. But it's a web browser issue, if you download the raw buildbout output, you will see "?". So the string takes less memory (1 byte per character, not 2). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 13:37:55 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 03 Apr 2015 11:37:55 +0000 Subject: [issue23756] Tighten definition of bytes-like objects In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za> Message-ID: <1428061075.23.0.897847253217.issue23756@psf.upfronthosting.co.za> Martin Panter added the comment: I?m sorry Stefan, I now realize my changes for len(view) were indeed wrong, and the original was much more correct. I still think the tobytes() and maybe tolist() documentation could be improved, but that is a separate issue to the bytes-like definition. I am posting c-contig.v2.patch. Hopefully you will find it is truer to my original scope :) * Removed changes to stdtypes.rst * Scaled back changes in buffer.rst to only explain ?C-contiguous? * Tweaked glossary definition. Not all memoryview() objects are applicable. David: The result of passing a Fortran array directly in a bytes-like context is typically BufferError. If this were relaxed, then we would get the inconsistency with tobytes(). >>> import _testbuffer, sys >>> layout = [11, 21, 12, 22] >>> fortran_array = _testbuffer.ndarray(layout, format="B", flags=0, shape=[2, 2], strides=[1, 2], offset=0) >>> sys.stdout.buffer.write(fortran_array) Traceback (most recent call last): File "", line 1, in BufferError: ndarray is not C-contiguous >>> list(memoryview(fortran_array).tobytes()) # C-contiguous order! [11, 12, 21, 22] ---------- Added file: http://bugs.python.org/file38815/c-contig.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 13:46:55 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 03 Apr 2015 11:46:55 +0000 Subject: [issue22351] NNTP constructor exception leaves socket for garbage collector In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za> Message-ID: <1428061615.23.0.112836701652.issue22351@psf.upfronthosting.co.za> Martin Panter added the comment: Serhiy?s patch looks like it should do the trick. Just get rid of the ?self? parameter to make it clearer, and watch out for the stray XML changes! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 13:48:11 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 03 Apr 2015 11:48:11 +0000 Subject: [issue22351] NNTP constructor exception leaves socket for garbage collector In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za> Message-ID: <1428061691.51.0.96504246579.issue22351@psf.upfronthosting.co.za> Martin Panter added the comment: Sorry, that self parameter is okay. I was just confused because it now means something different :S ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 13:56:02 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Apr 2015 11:56:02 +0000 Subject: [issue23857] [RFE] Make certificate verification optionable In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428062162.06.0.382918719625.issue23857@psf.upfronthosting.co.za> R. David Murray added the comment: 1) there is no patch attached 2) certificate verification is optional already, is it not? That is, it can be turned off in your code, it is just on by default. 3) what downstream are you talking about? Supposing there is sufficient utility here, the level of change proposed would need to go through python-ideas first, IMO. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 14:02:55 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Apr 2015 12:02:55 +0000 Subject: [issue1103213] Adding the missing socket.recvall() method Message-ID: <1428062575.5.0.529131609278.issue1103213@psf.upfronthosting.co.za> STINNER Victor added the comment: > - I've learned that MSG_WAITALL may be unreliable on certain systems, so any implementation of recvall depending on MSG_WAITALL may inexplicably fail on such systems Something else occurred since 5 years: the PEP 475 was accepted, it makes Python more reliable when it receives signals. If recv(WAIT_ALL) is interrupted by a signal and returns less bytes, we must call PyErr_CheckSignal(). If the signal handler raises an exception, drop read data and raises the exception. If the signal handler does not raise an exception, we now *must* retry recv(WAIT_ALL) (with a shorter length, to not read too much data). The IncompleteRead exception is still needed if the socket is closed before receiving the requested number of bytes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 14:03:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Apr 2015 12:03:57 +0000 Subject: [issue22351] NNTP constructor exception leaves socket for garbage collector In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za> Message-ID: <1428062637.07.0.959152472621.issue22351@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Agree, factory method can be staticmethod. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 14:03:57 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Apr 2015 12:03:57 +0000 Subject: [issue22351] NNTP constructor exception leaves socket for garbage collector In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za> Message-ID: <20150403120300.105426.48731@psf.io> Roundup Robot added the comment: New changeset 7a91363f31e1 by Serhiy Storchaka in branch '3.4': Issue #22351. MockSslTests tests in test_nntplib now are reported if skipped. https://hg.python.org/cpython/rev/7a91363f31e1 New changeset c935c1e1d001 by Serhiy Storchaka in branch 'default': Issue #22351. MockSslTests tests in test_nntplib now are reported if skipped. https://hg.python.org/cpython/rev/c935c1e1d001 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 14:05:36 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Apr 2015 12:05:36 +0000 Subject: [issue22351] NNTP constructor exception leaves socket for garbage collector In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za> Message-ID: <1428062736.36.0.280739536903.issue22351@psf.upfronthosting.co.za> STINNER Victor added the comment: > Serhiy?s patch looks like it should do the trick. Just get rid of the ?self? parameter to make it clearer, +class MockSslTests(MockSocketTests): + def nntp_class(self, *pos, **kw): Hum, you should use the @staticmethod decorator here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 14:06:50 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Apr 2015 12:06:50 +0000 Subject: [issue22351] NNTP constructor exception leaves socket for garbage collector In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za> Message-ID: <1428062810.72.0.199594600705.issue22351@psf.upfronthosting.co.za> STINNER Victor added the comment: Except of the self parameter/@staticmethod and the unrelated SAX changes, issue22351_skip_MockSslTests.patch looks good to me. ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 14:12:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Apr 2015 12:12:21 +0000 Subject: [issue22351] NNTP constructor exception leaves socket for garbage collector In-Reply-To: <1410062828.01.0.535616885323.issue22351@psf.upfronthosting.co.za> Message-ID: <1428063141.64.0.935919923552.issue22351@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Now you have used time machine in reverse mode. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 14:14:11 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Apr 2015 12:14:11 +0000 Subject: [issue23857] [RFE] Make certificate verification optionable In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428063251.76.0.896970539342.issue23857@psf.upfronthosting.co.za> STINNER Victor added the comment: This issue is related to the PEP 476 which made the SSL certification checks mandatory by default. The PEP contains a section to explain how to opt-out, but the solution is global: https://www.python.org/dev/peps/pep-0476/#opting-out I understand that Robert wants a finer grain. > [https] # each protocol affected by cert-verification got its own section I'm not sure that the configuration should be made on the protocol. We may configure it per Python module (if we choose to accept the enhancement, I'm not convinced that it's good idea). Maybe it's a stupid idea, for example urllib and httplib are both used for HTTPS. But what about xmlrpclib? Should it follow the same policy? > 2) certificate verification is optional already, is it not? That is, it can be turned off in your code, it is just on by default. It requires to modify applications. Robert wants something to keep the Python 2.7.8 behaviour on Python 2.7.9 and newer. (Python 2.7.9 made SSL check mandatory by default, or is it only scheduled for Python 2.7.10? I don't remember :-() > 3) what downstream are you talking about? Robert and me are working for Red Hat. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 14:17:25 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Apr 2015 12:17:25 +0000 Subject: [issue23853] PEP 475: handle EINTR in the ssl module In-Reply-To: <1427988624.66.0.803600947043.issue23853@psf.upfronthosting.co.za> Message-ID: <1428063445.34.0.12319550109.issue23853@psf.upfronthosting.co.za> STINNER Victor added the comment: Here is a patch to fix the issue: recompute the timeout. It's unclear to me if we should reset the timeout after each successful read/write, or if the timeout is "global" (total duration of the ssl method). I asked the question on the python-dev mailing list. https://mail.python.org/pipermail/python-dev/2015-April/139001.html My patch uses a global timeout (never reset the timeout), whereas socket.sendall() resets the timeout at each send() success. ---------- Added file: http://bugs.python.org/file38816/ssl_timeout.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 14:33:56 2015 From: report at bugs.python.org (Robert Kuska) Date: Fri, 03 Apr 2015 12:33:56 +0000 Subject: [issue23857] [RFE] Make certificate verification optionable In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428064436.18.0.57636086573.issue23857@psf.upfronthosting.co.za> Robert Kuska added the comment: 1) patch attached, dunno how I missed it, thank you. 3) I work for Red Hat additional interest for example here http://seclists.org/oss-sec/2015/q1/785 2) It exists but it is not system wide, I would like to provide users option to opt-in or opt-out without interfering with code. There are many of users who rely on python and not all of them are programmers. ---------- keywords: +patch Added file: http://bugs.python.org/file38817/custom-cert-verify.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 14:41:23 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Apr 2015 12:41:23 +0000 Subject: [issue23857] [RFE] Make certificate verification optionable In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428064883.53.0.43040643283.issue23857@psf.upfronthosting.co.za> STINNER Victor added the comment: > 2) It exists but it is not system wide, You can hack site.py to disable SSL checks system-wide. It was also discussed to support an optional "sslcustomize" module, but the idea was rejected if I remember correctly. Anyway, did you read the discussion on the PEP 476? Options to disable SSL checks have been discussed there. Examples: https://mail.python.org/pipermail/python-dev/2014-August/136034.html https://mail.python.org/pipermail/python-dev/2014-September/136102.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 14:46:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Apr 2015 12:46:07 +0000 Subject: [issue22643] Integer overflow in case_operation In-Reply-To: <1413384630.17.0.213972312804.issue22643@psf.upfronthosting.co.za> Message-ID: <1428065167.15.0.443358254003.issue22643@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Perhaps adding bigmemtest is not worth if memory requirements are less than 1 GiB. But I would separate the creating of long tested string and the calling of case converting method, so we will sure what operation is failed. Proposed patch skips the test if can't create needed string and clean locals, so failing test_case_operation_overflow no longer causes multiple MemoryErrors in following tests. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 14:46:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Apr 2015 12:46:44 +0000 Subject: [issue22643] Integer overflow in case_operation In-Reply-To: <1413384630.17.0.213972312804.issue22643@psf.upfronthosting.co.za> Message-ID: <1428065204.55.0.969088689909.issue22643@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch stage: resolved -> patch review versions: -Python 3.3 Added file: http://bugs.python.org/file38818/test_case_operation_overflow_memory_error.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 14:53:33 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Apr 2015 12:53:33 +0000 Subject: [issue22643] Integer overflow in case_operation In-Reply-To: <1413384630.17.0.213972312804.issue22643@psf.upfronthosting.co.za> Message-ID: <1428065613.93.0.79035719927.issue22643@psf.upfronthosting.co.za> STINNER Victor added the comment: > Perhaps adding bigmemtest is not worth if memory requirements are less than 1 GiB. What is the current limit if you don't pass -M option to regrtest? In @bigimemtest, I see "maxsize = 5147". Is it a number of bytes? 5 kB of memory? IMO it's interested to use @bigmemtest if a test uses 100 MB of memory or more, but regrtest should use tests using less than 500 MB by default (or maybe less than 1 GB by default). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 15:02:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Apr 2015 13:02:42 +0000 Subject: [issue22643] Integer overflow in case_operation In-Reply-To: <1413384630.17.0.213972312804.issue22643@psf.upfronthosting.co.za> Message-ID: <1428066162.06.0.746817268776.issue22643@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: bigimem tests are ran with dummy size = 5147 if dry_run = True (default) and skipped if dry_run = False. Almost always you need dry_run = False. The -M option doesn't work with less than 1 GiB. In this case likely the buildbot had enough memory at the start, but then some memory leaked in tests (perhaps mainly in tracebacks of failed tests). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 15:09:04 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 03 Apr 2015 13:09:04 +0000 Subject: [issue23857] [RFE] Make certificate verification optionable In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428066544.06.0.0837919095582.issue23857@psf.upfronthosting.co.za> Nick Coghlan added the comment: (capturing these details here for now, we should at least have a python-dev discussion before going ahead with any changes in this area) The additional background here is that we started looking closely at what would be involved in applying PEP 476 to systems where there are 3 parties involved and the aim is to tweak the system Python to require explicitly opting in to certificate verification (at least for the time being): * CPython upstream verifies certificates by default * Platform vendor configures Python to use legacy mode by default * System administrator responsible for the machine can easily opt in to global verification and have that setting persist through Python updates The opt out solution in PEP 476 works for the "direct consumption of upstream" case, as the system administrator responsible for the machine can opt out globally in sitecustomize.py. It turns out that solution *doesn't* work at the platform vendor level, as sitecustomize.py is intended for use by the system administrator responsible for the machine - providing it as a platform vendor would be the wrong thing to do from a packaging perspective, as that usage would conflict with the intended use case of local site customisation. We suspected this would be a problem when we were discussing PEP 476 (hence the discussions of configuration files that Victor linked), but decided to postpone further consideration until after the distros had had a chance to consider the problem in more detail. Patching httplib to have a different default from CPython upstream isn't desirable, as that would perpetuate the problem that PEP 476 was designed to fix with no clear migration path to more secure defaults as the platform level. The idea of this patch is to provide a middle ground where a configuration file can be provided with the system python package that preserves the pre-PEP-476 status quo by setting "verify=disable" for https verification. If the configuration file is missing entirely then the upstream default of verifying certificates would still be used. The "verify=enable" setting would then let system administrators explicitly opt in to certificate verification, while "verify=platform_default" would mean "verify=disable" while the default package configuration still did that, but would potentially switch to meaning "verify=enable" at some point in the future (the exact meaning of the "platform_default" setting would likely be controlled by a distro level patch anyway, so it could potentially be omitted from the upstream change proposal). >From an implementation perspective, the reason the proposal is for a global HTTPS switch rather than a fine-grained per-module setting is back the follow-up proposal would be to write a PEP to backport it to Python 2.7, so something that's closely aligned with the existing opt-out mechanism in PEP 476 is considered desirable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 15:12:13 2015 From: report at bugs.python.org (Robert Kuska) Date: Fri, 03 Apr 2015 13:12:13 +0000 Subject: [issue23857] [RFE] Make certificate verification optionable In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428066733.09.0.296960788623.issue23857@psf.upfronthosting.co.za> Robert Kuska added the comment: If you mean hack site.py to be sitecustomize I don't find it as a sufficient solution because users may use their own sitecustomize and this way we would replace theirs. Sslcustomize solution could be another option how to handle this but the config idea seems to me much more easier (also from the linux user POV). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 15:12:56 2015 From: report at bugs.python.org (Robert Kuska) Date: Fri, 03 Apr 2015 13:12:56 +0000 Subject: [issue23857] [RFE] Make certificate verification optionable In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428066776.71.0.469864270251.issue23857@psf.upfronthosting.co.za> Robert Kuska added the comment: ( ^ I was replying to Victor) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 15:14:49 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 03 Apr 2015 13:14:49 +0000 Subject: [issue23857] [RFE] Make certificate verification optionable In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428066889.17.0.647310474329.issue23857@psf.upfronthosting.co.za> Nick Coghlan added the comment: The other goal worth noting here is that we'd like to facilitate easy system auditing/monitoring such that machines that still have Python certificate verification off by default can easily be flagged by checks in tools like Nagios, as well as being easy to adjust using configuration management and system orchestration tools (Ansible, Salt, Chef, Puppet, etc). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 15:29:41 2015 From: report at bugs.python.org (Nick Coghlan) Date: Fri, 03 Apr 2015 13:29:41 +0000 Subject: [issue23857] [RFE] Make default HTTPS certificate verification setting configurable In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428067781.35.0.390950189108.issue23857@psf.upfronthosting.co.za> Nick Coghlan added the comment: Clarified the issue heading a bit, and cc'ed in the main Debian/Ubuntu folks. Matthias, Barry - the attached patch here is aimed at making PEP 476 a bit more distro friendly by moving the "opt out" to a configuration file rather than requiring monkeypatching in sitecustomize. For upstream, the key components of the proposal are to have a simple ini-style config file that makes it possible to toggle the behaviour of the "ssl._create_default_https_context" function: $ cat cert-verification.conf [https] verify=disable => ssl._create_default_https_context = ssl._create_unverified_context $ cat cert-verification.conf [https] verify=enable => ssl._create_default_https_context = ssl.create_default_context If the config file is missing entirely, there's no https section in the file, or the "verify" setting is missing, then it would default to verifying HTTPS certificates. As more protocols were moved over to verifying certificates by default, they could follow the same pattern of having a private helper function in the ssl module that referred to either _create_unverified_context() or create_default_context() based on whether certification verification was enabled or not. It would also be possible to define a true overall ssl/tls default behaviour using this scheme, but I think that's out of scope for this particular proposal. ---------- nosy: +barry, doko title: [RFE] Make certificate verification optionable -> [RFE] Make default HTTPS certificate verification setting configurable _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 15:41:34 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 03 Apr 2015 13:41:34 +0000 Subject: [issue23856] build.bat -e shouldn't also build In-Reply-To: <1428050026.69.0.479392405161.issue23856@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: > Either by accident or by design the main build will run in addition. By design; I intended get_externals.bat to be run explicitly if you just wanted to pull the externals. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 16:08:56 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Apr 2015 14:08:56 +0000 Subject: [issue23857] [RFE] Make default HTTPS certificate verification setting configurable In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428070136.58.0.0882870011605.issue23857@psf.upfronthosting.co.za> R. David Murray added the comment: I do not understand why the vendors want to re-introduce a security hole. I understand that it causes issues using legacy software to communicate with sites that don't verify, but I think that the correct solution to this is disabling verification on a per-transaction basis, similar to how wget and curl have command line options for. For Python I think this would mean an environment variable. I believe I suggested or supported this before and it was rejected (I don't particularly remember why). If you want to make it config file driven it ought to be keyed by site, not by protocol, IMO, and that seems like a suspect thing to put in a global configuration file. Introducing a global config file for Python is a significant architectural change, and merits a careful discussion (and probably a PEP). I don't think it is particularly useful to have this as a tracker issue at this stage. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 16:11:42 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 03 Apr 2015 14:11:42 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428070302.89.0.0779167445634.issue23857@psf.upfronthosting.co.za> R. David Murray added the comment: Changing the title to be specific to the proposed patch. ---------- title: [RFE] Make default HTTPS certificate verification setting configurable -> Make default HTTPS certificate verification setting configurable via global ini file _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 16:32:14 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 03 Apr 2015 14:32:14 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428071534.32.0.522602542958.issue23857@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: +1 for keyed by site There have been a number of issues over the years for which a configuration file (or files) would have been useful. I think a discussion over on python-ideas is the right way to move forward on this point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 16:36:42 2015 From: report at bugs.python.org (Simon Ye) Date: Fri, 03 Apr 2015 14:36:42 +0000 Subject: [issue23858] Look for local sqlite3 by parsing -I/-L flags in linux as well. Message-ID: <1428071802.53.0.603746125685.issue23858@psf.upfronthosting.co.za> New submission from Simon Ye: Based off of https://github.com/Homebrew/linuxbrew/pull/330. Currently building python on linux only looks for sqlite include paths in a hardcoded set of system paths, but if the user specifies -I/-L options during compilation, python setup.py looks there for sqlite3 as well, but only on OS X. This is problem for people who want to build python against a local version of sqlite3, and it is also inconsistent with the OS X behavior. Also the comments say that it should work on any unix-y OS! ---------- components: Build files: sqlite_patch.diff keywords: patch messages: 239997 nosy: yesimon priority: normal severity: normal status: open title: Look for local sqlite3 by parsing -I/-L flags in linux as well. versions: Python 3.6 Added file: http://bugs.python.org/file38819/sqlite_patch.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 16:52:23 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 03 Apr 2015 14:52:23 +0000 Subject: [issue23858] Look for local sqlite3 by parsing -I/-L flags in linux as well. In-Reply-To: <1428071802.53.0.603746125685.issue23858@psf.upfronthosting.co.za> Message-ID: <1428072743.56.0.456136693838.issue23858@psf.upfronthosting.co.za> Ned Deily added the comment: This is essentially a duplicate of Issue3467 and various other similar issues. While it may not be easy to justify the special case in setup.py for OS X (the reason was primarily for OS X installer builds), it would be even harder to justify adding another special case just for "Linux" systems. Why not all platforms and libs? The standard reply (in Issue3467 and elsewhere) to these kinds of requests has been to use one of the Modules/Setup files (like Setup.local) to customize extension module builds or to come up with a more general solution for the top-level setup.py third-party library configuration, rather than more special cases for each lib. ---------- nosy: +ned.deily resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> sqlite3 path is hard coded in setup.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 17:01:40 2015 From: report at bugs.python.org (Ned Deily) Date: Fri, 03 Apr 2015 15:01:40 +0000 Subject: [issue23858] Look for local sqlite3 by parsing -I/-L flags in linux as well. In-Reply-To: <1428071802.53.0.603746125685.issue23858@psf.upfronthosting.co.za> Message-ID: <1428073300.41.0.588809686737.issue23858@psf.upfronthosting.co.za> Ned Deily added the comment: My apologies, I replied a bit too hastily, thinking incorrectly that your suggested change was just for sqlite3. While the comments above still apply, there is already an open request for the more general feature (and more) under Issue21571. So I suggest further discussion be moved there. ---------- superseder: sqlite3 path is hard coded in setup.py -> Python build should check CPATH, C_INCLUDE_PATH for module dependencies _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 17:10:34 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Apr 2015 15:10:34 +0000 Subject: [issue23219] asyncio: cancelling wait_for(task, timeout) must also cancel the task In-Reply-To: <1420884133.75.0.926989519431.issue23219@psf.upfronthosting.co.za> Message-ID: <20150403151031.15195.15397@psf.io> Roundup Robot added the comment: New changeset c167b9f9aac8 by Victor Stinner in branch '3.4': Issue #23219: Update asyncio.wait_for() documentation https://hg.python.org/cpython/rev/c167b9f9aac8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 17:13:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Apr 2015 15:13:17 +0000 Subject: [issue23859] asyncio: document behaviour of wait() cancellation Message-ID: <1428073997.46.0.438809738394.issue23859@psf.upfronthosting.co.za> New submission from STINNER Victor: When wait(fs) is cancelled, futures of fs are not cancelled. This behaviour is not documented. It should be documented, and a warning should be added to the Cancellation section: https://docs.python.org/dev/library/asyncio-dev.html#cancellation See my message "Cancellation of asyncio.wait()": https://mail.google.com/mail/u/0/#label/Tulip/14b34f0a5d31114f ---------- components: asyncio messages: 240001 nosy: gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio: document behaviour of wait() cancellation versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 17:20:37 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 03 Apr 2015 15:20:37 +0000 Subject: [issue23765] Remove IsBadStringPtr calls in ctypes In-Reply-To: <1427222345.86.0.728447674961.issue23765@psf.upfronthosting.co.za> Message-ID: <1428074437.91.0.263535907007.issue23765@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 17:31:15 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 03 Apr 2015 15:31:15 +0000 Subject: [issue23852] Wrong FD_DIR file name on OpenBSD In-Reply-To: <1427987632.4.0.790792340938.issue23852@psf.upfronthosting.co.za> Message-ID: <1428075075.6.0.68223326618.issue23852@psf.upfronthosting.co.za> Stefan Krah added the comment: There's a comment in _posixsubprocess: "NetBSD and OpenBSD have a /proc fs available (though not necessarily mounted) and do not have fdescfs for /dev/fd." Is this still valid? ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 17:32:10 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 03 Apr 2015 15:32:10 +0000 Subject: [issue23852] Wrong FD_DIR file name on OpenBSD In-Reply-To: <1427987632.4.0.790792340938.issue23852@psf.upfronthosting.co.za> Message-ID: <1428075130.45.0.0630627546287.issue23852@psf.upfronthosting.co.za> Changes by Stefan Krah : ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 17:50:09 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 03 Apr 2015 15:50:09 +0000 Subject: [issue23668] Support os.ftruncate on Windows In-Reply-To: <1426383698.86.0.63017868488.issue23668@psf.upfronthosting.co.za> Message-ID: <1428076209.85.0.651273929854.issue23668@psf.upfronthosting.co.za> Steve Dower added the comment: I responded to Victor's suggestion about _Py_open instead of _open, but on rereading I see that it also handles EINTR. AFAICT (from https://msdn.microsoft.com/en-us/library/5814770t.aspx, mainly), Windows isn't ever going to return EINTR from the CRT. I don't especially want to have to modify _Py_open to take another parameter to suppress creating a new file, but if someone else does then I'm happy to use it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 17:51:28 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 03 Apr 2015 15:51:28 +0000 Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in posixmodule In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za> Message-ID: <1428076288.28.0.713547513756.issue23524@psf.upfronthosting.co.za> Steve Dower added the comment: Victor - can you take a look? I'm keen to get this out of my patch queue :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 17:53:15 2015 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Fri, 03 Apr 2015 15:53:15 +0000 Subject: [issue23852] Wrong FD_DIR file name on OpenBSD In-Reply-To: <1427987632.4.0.790792340938.issue23852@psf.upfronthosting.co.za> Message-ID: <1428076395.08.0.0820659282772.issue23852@psf.upfronthosting.co.za> C?dric Krier added the comment: At least on OpenBSD procfs have been removed: http://www.openbsd.org/faq/current.html#20140908 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 18:01:19 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Apr 2015 16:01:19 +0000 Subject: [issue23812] asyncio.Queue.put_nowait(), followed get() task cancellation leads to item being lost In-Reply-To: <1427723992.8.0.0858000383291.issue23812@psf.upfronthosting.co.za> Message-ID: <1428076879.7.0.731330144559.issue23812@psf.upfronthosting.co.za> STINNER Victor added the comment: queue_bug.py: script to reproduce the bug. I confirm that Queue.get() sometimes looses items when it is cancelled. The waiter contains the result, but the waiter is lost when get() is cancelled. Queue.get() waiter got a result, but Queue.get() wakeup is only *scheduled* yet. It may even be executed in the same iteration, or maybe in the next loop iteration. I didn't review patches yet. ---------- Added file: http://bugs.python.org/file38820/queue_bug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 18:09:45 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 03 Apr 2015 16:09:45 +0000 Subject: [issue23668] Support os.ftruncate on Windows In-Reply-To: <1426383698.86.0.63017868488.issue23668@psf.upfronthosting.co.za> Message-ID: <1428077385.17.0.776569859993.issue23668@psf.upfronthosting.co.za> STINNER Victor added the comment: Sorry, I still fail to see how _Py_open() or _Py_open_noraise() add the O_CREAT flag: they are thin wrapper to the underyling open() function. I cannot see O_CREAT in Python/fileutils.c. Could you please show me that the line number adding O_CREAT implictly? I don't understand. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 18:11:34 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 03 Apr 2015 16:11:34 +0000 Subject: [issue23500] Argument Clinic: multiple macro definition In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za> Message-ID: <1428077494.5.0.1008571163.issue23500@psf.upfronthosting.co.za> Larry Hastings added the comment: As promised, here's a cleaned-up version of the patch. The taxonomy of objects now makes sense: a Destination contains a BufferSeries object, rather than Destinations weirdly supporting __getitem__ to reference different objects. I tripped over myself a little with the "two-pass" destination / preset. It was an experiment long ago but nobody's using it. So rather than fix it I just turned it off. ---------- Added file: http://bugs.python.org/file38821/larry.ac_multiple_macro_definitions.diff.4.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 18:47:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Apr 2015 16:47:02 +0000 Subject: [issue23500] Argument Clinic: multiple macro definition In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za> Message-ID: <1428079622.64.0.492978463548.issue23500@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Looks as you didn't notice my comments on Rietveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 18:51:32 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 03 Apr 2015 16:51:32 +0000 Subject: [issue23500] Argument Clinic: multiple macro definition In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za> Message-ID: <1428079892.27.0.0810780938476.issue23500@psf.upfronthosting.co.za> Larry Hastings added the comment: I did, I just didn't respond. I'll do that now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 19:01:15 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 03 Apr 2015 17:01:15 +0000 Subject: [issue23466] PEP 461: Inconsistency between str and bytes formatting of integers In-Reply-To: <1424024506.86.0.140677708328.issue23466@psf.upfronthosting.co.za> Message-ID: <1428080475.86.0.72762504902.issue23466@psf.upfronthosting.co.za> Ethan Furman added the comment: Looks good, thanks Serhiy. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 19:12:00 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 03 Apr 2015 17:12:00 +0000 Subject: [issue23500] Argument Clinic: multiple macro definition In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za> Message-ID: <1428081120.63.0.0721635225284.issue23500@psf.upfronthosting.co.za> Larry Hastings added the comment: Updated patch, removed all references to two-pass. Also realized I needed to make the default behavior for methoddef_ifndef go to the end. And, finally, I forgot to merge the "only print each #ifndef block once" code I wrote before when I redid the patch, so that's in now. ---------- Added file: http://bugs.python.org/file38822/larry.ac_multiple_macro_definitions.diff.5.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 19:33:18 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 03 Apr 2015 17:33:18 +0000 Subject: [issue23852] Wrong FD_DIR file name on OpenBSD In-Reply-To: <1427987632.4.0.790792340938.issue23852@psf.upfronthosting.co.za> Message-ID: <1428082398.55.0.90878257126.issue23852@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I'm not going to bother setting up a VM with an esoteric OS in it myself, if someone knows the past and current state of various OpenBSD versions and what to do there, feel free to commit OpenBSD conditional compilation bits as you see fit to make this do the right thing. :) ---------- components: +Extension Modules stage: -> patch review type: -> behavior versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 19:38:56 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 03 Apr 2015 17:38:56 +0000 Subject: [issue23668] Support os.ftruncate on Windows In-Reply-To: <1426383698.86.0.63017868488.issue23668@psf.upfronthosting.co.za> Message-ID: <1428082736.94.0.648613713456.issue23668@psf.upfronthosting.co.za> Steve Dower added the comment: Sorry, _Py_open requires a double encoding (wchar->char->wchar), which is why I'm not going to use it. _Py_wfopen takes a mode string rather than _O_* flags, and so implicitly includes _O_CREAT. Guessing we should add _Py_wopen? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 19:44:00 2015 From: report at bugs.python.org (Bill Parker) Date: Fri, 03 Apr 2015 17:44:00 +0000 Subject: [issue23860] Failure to check return value from lseek() in Modules/mmapmodule.c Message-ID: <1428083040.47.0.668729418368.issue23860@psf.upfronthosting.co.za> New submission from Bill Parker: Hello All, In reviewing code in directory Python-3.4.3/Modules, file 'mmapmodule', I found a call to 'lseek()' without a check for a return value of -1, indicating failure. The patch file below corrects this issue (diff -u format): --- mmapmodule.c.orig 2015-04-02 19:05:30.380554538 -0700 +++ mmapmodule.c 2015-04-02 19:11:00.320488207 -0700 @@ -1335,7 +1335,11 @@ return NULL; } /* Win9x appears to need us seeked to zero */ - lseek(fileno, 0, SEEK_SET); + if (lseek(fileno, 0, SEEK_SET) == -1) { /* call to lseek() failed */ + PyErr_SetFromErrno(PyExc_OSError); + return NULL; + } + } m_obj = (mmap_object *)type->tp_alloc(type, 0); I am attaching the patch file to this bug report... ---------- components: Interpreter Core files: mmapmodule.c.patch keywords: patch messages: 240015 nosy: dogbert2 priority: normal severity: normal status: open title: Failure to check return value from lseek() in Modules/mmapmodule.c type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file38823/mmapmodule.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 19:46:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Apr 2015 17:46:36 +0000 Subject: [issue23500] Argument Clinic: multiple macro definition In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za> Message-ID: <1428083196.69.0.929578017422.issue23500@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: larry.ac_multiple_macro_definitions.diff.5.txt LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 19:50:56 2015 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Fri, 03 Apr 2015 17:50:56 +0000 Subject: [issue23852] Wrong FD_DIR file name on OpenBSD In-Reply-To: <1427987632.4.0.790792340938.issue23852@psf.upfronthosting.co.za> Message-ID: <1428083456.32.0.000234927457322.issue23852@psf.upfronthosting.co.za> C?dric Krier added the comment: Indeed, I think my patch is not right as /dev/fd on OpenBSD is static. I will continue to investigate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 19:54:11 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Apr 2015 17:54:11 +0000 Subject: [issue23466] PEP 461: Inconsistency between str and bytes formatting of integers In-Reply-To: <1424024506.86.0.140677708328.issue23466@psf.upfronthosting.co.za> Message-ID: <20150403175408.15215.12003@psf.io> Roundup Robot added the comment: New changeset 313fd1c819c5 by Serhiy Storchaka in branch 'default': Issue #23466: Raised OverflowError if %c argument is out of range. https://hg.python.org/cpython/rev/313fd1c819c5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 19:56:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Apr 2015 17:56:55 +0000 Subject: [issue23466] PEP 461: Inconsistency between str and bytes formatting of integers In-Reply-To: <1424024506.86.0.140677708328.issue23466@psf.upfronthosting.co.za> Message-ID: <1428083815.54.0.240426939491.issue23466@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 Apr 3 20:06:08 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 03 Apr 2015 18:06:08 +0000 Subject: [issue23794] http package should support HTTP/2 In-Reply-To: <1427479110.25.0.801999785412.issue23794@psf.upfronthosting.co.za> Message-ID: <1428084368.32.0.506202791157.issue23794@psf.upfronthosting.co.za> Demian Brecht added the comment: +1 to the adding the support for HTTP/2. I would personally like to see a few things happen before that though (which I've been putting some effort into as i can) + refactor http.client to cleanly separate transport from application protocol level + figure out some kind of adapter interface in order to facilitate swapping between 1.1 and 2 (This can start with a clean HTTP/1.1 interface) + full HTTP/1.1 support. Given (as i understand it) HTTP/2 is largely an extension of HTTP/1.1 it doesn't make much sense to me to implement the latter before the former. ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 20:11:17 2015 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Fri, 03 Apr 2015 18:11:17 +0000 Subject: [issue23852] Wrong FD_DIR file name on OpenBSD In-Reply-To: <1427987632.4.0.790792340938.issue23852@psf.upfronthosting.co.za> Message-ID: <1428084677.89.0.30867239019.issue23852@psf.upfronthosting.co.za> C?dric Krier added the comment: The problem comes from safe_get_max_fd which return a too low value because of a bug in sysconf on OpenBSD [1]: The value for _SC_STREAM_MAX is a minimum maximum, and required to be the same as ANSI C's FOPEN_MAX, so the returned value is a ridiculously small and misleading number. [1] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/sysconf.3 ---------- type: behavior -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 20:11:19 2015 From: report at bugs.python.org (Cory Benfield) Date: Fri, 03 Apr 2015 18:11:19 +0000 Subject: [issue23794] http package should support HTTP/2 In-Reply-To: <1427479110.25.0.801999785412.issue23794@psf.upfronthosting.co.za> Message-ID: <1428084679.58.0.292315189153.issue23794@psf.upfronthosting.co.za> Cory Benfield added the comment: > figure out some kind of adapter interface in order to facilitate swapping between 1.1 and 2 (This can start with a clean HTTP/1.1 interface) I've been thinking about this a lot with hyper, and I'm about to start work on it (having just finished an alpha implementation of HTTP/1.1). My current plan is to try out a proxy object pattern, but you should feel free to use the hyper code as a leaping-off point for some experiments into how to do the swapping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 20:11:38 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 03 Apr 2015 18:11:38 +0000 Subject: [issue23794] http package should support HTTP/2 In-Reply-To: <1427479110.25.0.801999785412.issue23794@psf.upfronthosting.co.za> Message-ID: <1428084698.98.0.423205552938.issue23794@psf.upfronthosting.co.za> Demian Brecht added the comment: @Cory: my own plan was to use your implementation as the baseline and add server support. If you take a crack at it that would be great! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 20:23:18 2015 From: report at bugs.python.org (Simon Ye) Date: Fri, 03 Apr 2015 18:23:18 +0000 Subject: [issue21571] Python build should check CPATH, C_INCLUDE_PATH for module dependencies In-Reply-To: <1400966978.12.0.900228617975.issue21571@psf.upfronthosting.co.za> Message-ID: <1428085398.98.0.93316734741.issue21571@psf.upfronthosting.co.za> Changes by Simon Ye : ---------- nosy: +yesimon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 20:24:09 2015 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Fri, 03 Apr 2015 18:24:09 +0000 Subject: [issue23852] Wrong FD_DIR file name on OpenBSD In-Reply-To: <1427987632.4.0.790792340938.issue23852@psf.upfronthosting.co.za> Message-ID: <1428085449.86.0.751988831918.issue23852@psf.upfronthosting.co.za> C?dric Krier added the comment: Here is a patch that uses getrlimit (that's works on OpenBSD) before using sysconf. ---------- Added file: http://bugs.python.org/file38824/max_fd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 20:31:15 2015 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Fri, 03 Apr 2015 18:31:15 +0000 Subject: [issue23852] Wrong FD_DIR file name on OpenBSD In-Reply-To: <1427987632.4.0.790792340938.issue23852@psf.upfronthosting.co.za> Message-ID: <1428085875.68.0.0393242121673.issue23852@psf.upfronthosting.co.za> Changes by C?dric Krier : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 20:41:01 2015 From: report at bugs.python.org (Tim Golden) Date: Fri, 03 Apr 2015 18:41:01 +0000 Subject: [issue23856] build.bat -e shouldn't also build In-Reply-To: <1428050026.69.0.479392405161.issue23856@psf.upfronthosting.co.za> Message-ID: <1428086461.75.0.904344373112.issue23856@psf.upfronthosting.co.za> Tim Golden added the comment: Fair enough ---------- resolution: -> not a bug stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 20:43:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Apr 2015 18:43:52 +0000 Subject: [issue23500] Argument Clinic: multiple macro definition In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za> Message-ID: <1428086632.43.0.0327938380303.issue23500@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> larry stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 20:55:50 2015 From: report at bugs.python.org (Steve Dower) Date: Fri, 03 Apr 2015 18:55:50 +0000 Subject: [issue23861] Make stdprinter use DebugOutputString when no stdout/stderr available Message-ID: <1428087350.41.0.355922680582.issue23861@psf.upfronthosting.co.za> New submission from Steve Dower: Currently we initialize stdprinter while initializing and terminate if we can't access std streams. We should always write to DebugOutputString on Windows (only does anything if a debugger is attached) and avoid terminating in this case. ---------- components: Windows messages: 240025 nosy: steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Make stdprinter use DebugOutputString when no stdout/stderr available versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 21:04:53 2015 From: report at bugs.python.org (rengine) Date: Fri, 03 Apr 2015 19:04:53 +0000 Subject: [issue23862] subprocess popen arguments using double quotes Message-ID: <1428087893.92.0.437670101484.issue23862@psf.upfronthosting.co.za> New submission from rengine: Using Python 2.7.9 Noticed when I run a subprocess Popen with an argument containing double quotes, it will have a different affect depending on my operating system. In Linux, if I run ./runme.py, it will call runme.sh which will append someargs.txt correctly without escaped quotations In Windows, if I run ./runme.py, it will call runme.bat which will append someargs.txt with escaped quotations Also in Windows, if I run runme.bat with an argument containing quotations it will append someargs.txt correctly without escaped quotations so this problem seems to be stemming from Python. ===================================== runme.py #!/usr/bin/python import sys import subprocess import shlex # works on Linux: #command_line = "./runme.sh --include=\"check\"" # fails on Windows: command_line = "runme.bat --include=\"check\"" #command_line = "runme.bat --include=\"check\"" arg = shlex.shlex(command_line) arg.quotes = '"' arg.whitespace_split = True arg.commenters = '' command_line_args = list(arg) print command_line_args command_line_process = subprocess.Popen( command_line_args, universal_newlines=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE ) line = "" while True: line = command_line_process.stdout.readline() if line: print line else: break ===================================== runme.bat echo %* echo %* >> someargs.txt ===================================== runme.sh #!/bin/bash echo $@ echo $@ >> someargs.txt ---------- messages: 240026 nosy: rengine priority: normal severity: normal status: open title: subprocess popen arguments using double quotes type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 21:39:35 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Apr 2015 19:39:35 +0000 Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za> Message-ID: <20150403193932.16511.75765@psf.io> Roundup Robot added the comment: New changeset 157b7055bb9d by Serhiy Storchaka in branch 'default': Issue #15582: inspect.getdoc() now follows inheritance chains. https://hg.python.org/cpython/rev/157b7055bb9d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 22:09:18 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Apr 2015 20:09:18 +0000 Subject: [issue23500] Argument Clinic: multiple macro definition In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za> Message-ID: <20150403200915.16262.70664@psf.io> Roundup Robot added the comment: New changeset 25eef0ecb9c1 by Larry Hastings in branch 'default': Issue #23500: Argument Clinic is now smarter about generating the "#ifndef" https://hg.python.org/cpython/rev/25eef0ecb9c1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 22:09:58 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 03 Apr 2015 20:09:58 +0000 Subject: [issue23500] Argument Clinic: multiple macro definition In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za> Message-ID: <1428091798.13.0.477398712859.issue23500@psf.upfronthosting.co.za> Larry Hastings added the comment: Does this really need a backport to 3.4? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 22:16:32 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Apr 2015 20:16:32 +0000 Subject: [issue23791] Identify Moved Lines with difflib In-Reply-To: <1427473520.44.0.514545586028.issue23791@psf.upfronthosting.co.za> Message-ID: <1428092191.99.0.799722696678.issue23791@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 22:16:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Apr 2015 20:16:55 +0000 Subject: [issue23500] Argument Clinic: multiple macro definition In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za> Message-ID: <1428092215.15.0.399830395618.issue23500@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think this is not needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 22:17:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Apr 2015 20:17:23 +0000 Subject: [issue23500] Argument Clinic: multiple macro definition In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za> Message-ID: <1428092243.01.0.15730477114.issue23500@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Larry. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 22:22:58 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Apr 2015 20:22:58 +0000 Subject: [issue23809] RFE: emit a warning when a module in a traceback shadows a stdlib module In-Reply-To: <1427677231.57.0.397201302545.issue23809@psf.upfronthosting.co.za> Message-ID: <1428092578.98.0.971576099133.issue23809@psf.upfronthosting.co.za> Terry J. Reedy added the comment: This is a fairly common newbie bug. random.py seems to be favorite name. ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 22:25:11 2015 From: report at bugs.python.org (Peter) Date: Fri, 03 Apr 2015 20:25:11 +0000 Subject: [issue23786] test_unaligned_buffers (test.test_hash.HashEqualityTestCase) ... Fatal Python error: Bus error In-Reply-To: <1427377647.96.0.0955568014503.issue23786@psf.upfronthosting.co.za> Message-ID: <1428092711.7.0.380617452608.issue23786@psf.upfronthosting.co.za> Peter added the comment: Test 1 Python 3.4.3 built by GCC 4.9.2 is: >>> str(memoryview(b'abcdefghijklmnopqrstuvwxyz')[1:], 'ascii') 'bcdefghijklmnopqrstuvwxyz' Test 2 Python 3.4.3 built by GCC 4.6.2 is (no patches applied) This build will core dump if I run -m test test_hash. >>> str(memoryview(b'abcdefghijklmnopqrstuvwxyz')[1:], 'ascii') 'bcdefghijklmnopqrstuvwxyz' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 22:26:47 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Apr 2015 20:26:47 +0000 Subject: [issue23815] Segmentation fault when create _tkinter objects In-Reply-To: <1427745415.01.0.962782500028.issue23815@psf.upfronthosting.co.za> Message-ID: <1428092807.29.0.669477082554.issue23815@psf.upfronthosting.co.za> Terry J. Reedy added the comment: With 3.4.3, I get the equivalent on Windows (a 'python has stopped working' box). ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 22:35:59 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 03 Apr 2015 20:35:59 +0000 Subject: [issue23500] Argument Clinic: multiple macro definition In-Reply-To: <1424601462.93.0.790792182733.issue23500@psf.upfronthosting.co.za> Message-ID: <1428093359.53.0.117542761961.issue23500@psf.upfronthosting.co.za> Larry Hastings added the comment: Removing 3.4 from the version list as I close the bug, then. If we decide we need it backported please reopen (or create a new bug, either is fine). ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 22:54:14 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Apr 2015 20:54:14 +0000 Subject: [issue23501] Argument Clinic: generate code into separate files by default In-Reply-To: <1424603088.54.0.245767727537.issue23501@psf.upfronthosting.co.za> Message-ID: <20150403205411.75254.83945@psf.io> Roundup Robot added the comment: New changeset aa88a18a4aa1 by Serhiy Storchaka in branch 'default': Issue #23501: Argumen Clinic now generates code into separate files by default. https://hg.python.org/cpython/rev/aa88a18a4aa1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 22:54:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Apr 2015 20:54:56 +0000 Subject: [issue23501] Argument Clinic: generate code into separate files by default In-Reply-To: <1424603088.54.0.245767727537.issue23501@psf.upfronthosting.co.za> Message-ID: <1428094496.74.0.952385321549.issue23501@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 Apr 3 22:56:25 2015 From: report at bugs.python.org (Larry Hastings) Date: Fri, 03 Apr 2015 20:56:25 +0000 Subject: [issue23501] Argument Clinic: generate code into separate files by default In-Reply-To: <1424603088.54.0.245767727537.issue23501@psf.upfronthosting.co.za> Message-ID: <1428094585.97.0.630624929811.issue23501@psf.upfronthosting.co.za> Larry Hastings added the comment: Thanks! I've been meaning to follow up on this. I think CPython should be consistent, one way or another. So I support this change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 23:08:35 2015 From: report at bugs.python.org (Masayuki Yamamoto) Date: Fri, 03 Apr 2015 21:08:35 +0000 Subject: [issue23338] PyErr_Format in ctypes uses invalid parameter In-Reply-To: <1422442371.36.0.968367348117.issue23338@psf.upfronthosting.co.za> Message-ID: <1428095315.33.0.428066976567.issue23338@psf.upfronthosting.co.za> Changes by Masayuki Yamamoto : ---------- nosy: +masamoto _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 23:12:35 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 03 Apr 2015 21:12:35 +0000 Subject: [issue23492] Argument Clinic: improve generated parser for 1-argument functions In-Reply-To: <1424443211.95.0.366719358355.issue23492@psf.upfronthosting.co.za> Message-ID: <20150403211231.16238.73275@psf.io> Roundup Robot added the comment: New changeset e10ad4d4d490 by Serhiy Storchaka in branch 'default': Issue #23492: Argument Clinic now generates argument parsing code with https://hg.python.org/cpython/rev/e10ad4d4d490 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 23:30:17 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Apr 2015 21:30:17 +0000 Subject: [issue23825] test_idle fails under -OO In-Reply-To: <1427815423.26.0.42756532266.issue23825@psf.upfronthosting.co.za> Message-ID: <1428096617.03.0.0124119998566.issue23825@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The relevant code in CallTips.py itself if isinstance(ob_call, types.MethodType): doc = ob_call.__doc__ else: doc = getattr(ob, "__doc__", "") if doc: equally ignores both None and '', but I forgot the None possibility in the tests. I cannot test the patch, but the fix looks right. Putting the doc conditional expression before the for loops works because if one .__doc__ is set to None, all are. For the same reason, doc could be defined as a global name, but if the patch makes test_idle pass, it is fine as it is. ---------- nosy: +terry.reedy stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 23:36:54 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Apr 2015 21:36:54 +0000 Subject: [issue23825] test_idle fails under -OO In-Reply-To: <1427815423.26.0.42756532266.issue23825@psf.upfronthosting.co.za> Message-ID: <1428097014.95.0.745097096403.issue23825@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Whatever you do with the other -OO patches, I would prefer that this be applied to 3.4. The 3.4/3.5 files should be identical. ---------- versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 23:38:43 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Apr 2015 21:38:43 +0000 Subject: [issue23831] tkinter canvas lacks of moveto method. In-Reply-To: <1427832932.11.0.38662420535.issue23831@psf.upfronthosting.co.za> Message-ID: <1428097123.88.0.599423500715.issue23831@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- nosy: +serhiy.storchaka, terry.reedy versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 23:38:51 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 03 Apr 2015 21:38:51 +0000 Subject: [issue23831] tkinter canvas lacks of moveto method. In-Reply-To: <1427832932.11.0.38662420535.issue23831@psf.upfronthosting.co.za> Message-ID: <1428097131.07.0.546950782587.issue23831@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 3 23:58:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Apr 2015 21:58:28 +0000 Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za> Message-ID: <1428098308.74.0.213331419429.issue15582@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Unfortunately this enhancement breaks test_enum. ====================================================================== FAIL: test_pydoc (test.test_enum.TestStdLib) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/serhiy/py/cpython/Lib/test/test_enum.py", line 1609, in test_pydoc self.assertEqual(result, expected_text) AssertionError: 'Help[68 chars]n | Generic enumeration.\n | \n | Derive fr[876 chars]ing.' != 'Help[68 chars]n | Method resolution order:\n | Color\n[782 chars]ing.' Help on class Color in module test.test_enum: class Color(enum.Enum) - | Generic enumeration. - | - | Derive from this class to define new enumerations. - | | Method resolution order: | Color | enum.Enum | builtins.object | | Data and other attributes defined here: | | blue = | | green = | | red = | | ---------------------------------------------------------------------- | Data descriptors inherited from enum.Enum: | | name | The name of the Enum member. | | value | The value of the Enum member. | | ---------------------------------------------------------------------- | Data descriptors inherited from enum.EnumMeta: | | __members__ | Returns a mapping of member name->value. | | This mapping lists all enum members, including aliases. Note that this | is a read-only view of the internal mapping. ---------------------------------------------------------------------- ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 00:00:38 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 03 Apr 2015 22:00:38 +0000 Subject: [issue23492] Argument Clinic: improve generated parser for 1-argument functions In-Reply-To: <1424443211.95.0.366719358355.issue23492@psf.upfronthosting.co.za> Message-ID: <1428098438.16.0.454768195981.issue23492@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 Apr 4 00:30:37 2015 From: report at bugs.python.org (Paul Moore) Date: Fri, 03 Apr 2015 22:30:37 +0000 Subject: [issue23862] subprocess popen arguments using double quotes In-Reply-To: <1428087893.92.0.437670101484.issue23862@psf.upfronthosting.co.za> Message-ID: <1428100237.61.0.79895679406.issue23862@psf.upfronthosting.co.za> Paul Moore added the comment: On Windows, subprocess.Popen has to convert an argument list to a command line (because that's what the OS expects for CreateProcess). It does so internally, using subprocess.list2cmdline, which follows the quoting rules for the MS C runtime (because that's what 99% of programs use). Unfortunately batfile argument parsing does *not* use these conventions, and you can find odd corner cases like this. Specifically, it's not possible on Windows to "correctly" quote all forms of argument without knowing what program you are calling (because programs do their own argument parsing, usually but not always via the C runtime). The subprocess module has to work for unknown executables, so it chooses to do the right thing for programs using the MS C runtime argument parser (which is most programs). ---------- nosy: +paul.moore resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 00:58:19 2015 From: report at bugs.python.org (Michael Schurter) Date: Fri, 03 Apr 2015 22:58:19 +0000 Subject: [issue20718] OpenBSD/AIX: tests passing a file descriptor with sendmsg/recvmsg failures In-Reply-To: <1392974057.71.0.420386610945.issue20718@psf.upfronthosting.co.za> Message-ID: <1428101899.26.0.107956690563.issue20718@psf.upfronthosting.co.za> Changes by Michael Schurter : ---------- nosy: -schmichael _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 01:28:34 2015 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 03 Apr 2015 23:28:34 +0000 Subject: [issue23861] Make stdprinter use DebugOutputString when no stdout/stderr available In-Reply-To: <1428087350.41.0.355922680582.issue23861@psf.upfronthosting.co.za> Message-ID: <1428103714.17.0.814630277462.issue23861@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 03:23:32 2015 From: report at bugs.python.org (Donald Stufft) Date: Sat, 04 Apr 2015 01:23:32 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428110612.96.0.166581029062.issue23857@psf.upfronthosting.co.za> Donald Stufft added the comment: I'd really rather not add this to Python itself. If downstream wants to patch their Pythons to do it that is their prerogative. There's some legacy at play here of course, however I don't think that Python upstream is the right place to deal with that. One particular problem with this, is it becomes a lot harder to figure out if accessing a https URL is going to be secured or not since you have to also figure out what additional settings have been put into place. It also feels like a really weird setting. You don't see this kind of thing in any other languages or tool that I'm aware of except for single purpose tools. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 04:51:25 2015 From: report at bugs.python.org (Jeff McNeil) Date: Sat, 04 Apr 2015 02:51:25 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 Message-ID: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> New submission from Jeff McNeil: There are a collection of places in the socket module that do not correctly retry on EINTR. Updated to wrap those calls in a retry loop. However, when fixing connect calls, I noticed that when EINTR is retried on a socket with a timeout specified, the retry fails with EALREADY.. so I fixed that. I was going to shy away from primitive calls on sockets as one expects these things when working at a lower level, however, due to the way socket timeouts were implemented, I handled it differently in internal_connect. The create_connection calls probably ought to shield users from retry. Python 2.7.6. ---------- files: socket_intr.py messages: 240044 nosy: mcjeff priority: normal severity: normal status: open title: Fix EINTR Socket Module issues in 2.7 versions: Python 2.7 Added file: http://bugs.python.org/file38825/socket_intr.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 04:58:32 2015 From: report at bugs.python.org (Jeff McNeil) Date: Sat, 04 Apr 2015 02:58:32 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1428116312.86.0.634122903262.issue23863@psf.upfronthosting.co.za> Jeff McNeil added the comment: mcjeff at mcjeff:~/cpython_clean$ hg summary parent: 95416:fe34dfea16b0 Escaped backslashes in docstrings. branch: 2.7 commit: 3 modified, 3 unknown update: (current) ---------- keywords: +patch nosy: +gregory.p.smith Added file: http://bugs.python.org/file38826/socket_eintr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 05:55:44 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 04 Apr 2015 03:55:44 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1428119744.87.0.941487995135.issue23863@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 08:50:41 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Apr 2015 06:50:41 +0000 Subject: [issue23825] test_idle fails under -OO In-Reply-To: <1427815423.26.0.42756532266.issue23825@psf.upfronthosting.co.za> Message-ID: <20150404065038.64737.36068@psf.io> Roundup Robot added the comment: New changeset 912719dd684f by Serhiy Storchaka in branch '2.7': Issue #23825: Fixed test_idle under -OO. https://hg.python.org/cpython/rev/912719dd684f New changeset 657ebef5b291 by Serhiy Storchaka in branch '3.4': Issue #23825: Fixed test_idle under -OO. https://hg.python.org/cpython/rev/657ebef5b291 New changeset e6654af0fc93 by Serhiy Storchaka in branch 'default': Issue #23825: Fixed test_idle under -OO. https://hg.python.org/cpython/rev/e6654af0fc93 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 08:53:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Apr 2015 06:53:34 +0000 Subject: [issue23799] Join started threads in tests In-Reply-To: <1427573430.36.0.605750682641.issue23799@psf.upfronthosting.co.za> Message-ID: <1428130414.64.0.22832480624.issue23799@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 08:54:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Apr 2015 06:54:05 +0000 Subject: [issue23825] test_idle fails under -OO In-Reply-To: <1427815423.26.0.42756532266.issue23825@psf.upfronthosting.co.za> Message-ID: <1428130445.78.0.842816964911.issue23825@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 Sat Apr 4 08:56:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Apr 2015 06:56:50 +0000 Subject: [issue23338] PyErr_Format in ctypes uses invalid parameter In-Reply-To: <1422442371.36.0.968367348117.issue23338@psf.upfronthosting.co.za> Message-ID: <1428130610.41.0.660345503856.issue23338@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka nosy: +serhiy.storchaka versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 09:07:46 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Apr 2015 07:07:46 +0000 Subject: [issue23338] PyErr_Format in ctypes uses invalid parameter In-Reply-To: <1422442371.36.0.968367348117.issue23338@psf.upfronthosting.co.za> Message-ID: <20150404070742.98386.35163@psf.io> Roundup Robot added the comment: New changeset 1f28c8cca671 by Serhiy Storchaka in branch '2.7': Issue #23338: Fixed formatting ctypes error messages on Cygwin. https://hg.python.org/cpython/rev/1f28c8cca671 New changeset 36eca0b259e2 by Serhiy Storchaka in branch '3.4': Issue #23338: Fixed formatting ctypes error messages on Cygwin. https://hg.python.org/cpython/rev/36eca0b259e2 New changeset 3eb3a6d45251 by Serhiy Storchaka in branch 'default': Issue #23338: Fixed formatting ctypes error messages on Cygwin. https://hg.python.org/cpython/rev/3eb3a6d45251 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 09:14:01 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Apr 2015 07:14:01 +0000 Subject: [issue10590] Parameter type error for xml.sax.parseString(string, ...) In-Reply-To: <1291145861.74.0.873169501029.issue10590@psf.upfronthosting.co.za> Message-ID: <20150404071358.75248.35088@psf.io> Roundup Robot added the comment: New changeset fca669149d8a by Serhiy Storchaka in branch 'default': Issue #10590: xml.sax.parseString() now supports string argument. https://hg.python.org/cpython/rev/fca669149d8a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 09:14:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Apr 2015 07:14:44 +0000 Subject: [issue10590] Parameter type error for xml.sax.parseString(string, ...) In-Reply-To: <1291145861.74.0.873169501029.issue10590@psf.upfronthosting.co.za> Message-ID: <1428131684.94.0.21137519391.issue10590@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 Apr 4 09:15:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Apr 2015 07:15:39 +0000 Subject: [issue23338] PyErr_Format in ctypes uses invalid parameter In-Reply-To: <1422442371.36.0.968367348117.issue23338@psf.upfronthosting.co.za> Message-ID: <1428131739.06.0.863897120595.issue23338@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your contribution Makoto. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 10:03:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Apr 2015 08:03:49 +0000 Subject: [issue22831] Use "with" to avoid possible fd leaks In-Reply-To: <1415560947.71.0.445590332058.issue22831@psf.upfronthosting.co.za> Message-ID: <20150404080346.16244.20767@psf.io> Roundup Robot added the comment: New changeset ea94f6c87f5d by Serhiy Storchaka in branch 'default': Issue #22831: Use "with" to avoid possible fd leaks. https://hg.python.org/cpython/rev/ea94f6c87f5d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 10:32:26 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 04 Apr 2015 08:32:26 +0000 Subject: [issue23860] Failure to check return value from lseek() in Modules/mmapmodule.c In-Reply-To: <1428083040.47.0.668729418368.issue23860@psf.upfronthosting.co.za> Message-ID: <1428136346.4.0.290504454405.issue23860@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Bill. If you want to work on similar issues see also issue 15948. ---------- components: +Extension Modules -Interpreter Core nosy: +berker.peksag, haypo, serhiy.storchaka stage: -> patch review versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 10:32:47 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 04 Apr 2015 08:32:47 +0000 Subject: [issue15948] Unchecked return value of I/O functions In-Reply-To: <1347722947.26.0.499070360065.issue15948@psf.upfronthosting.co.za> Message-ID: <1428136367.97.0.811239155052.issue15948@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- dependencies: +Failure to check return value from lseek() in Modules/mmapmodule.c _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 10:43:59 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 04 Apr 2015 08:43:59 +0000 Subject: [issue23849] Leaks in test_deque In-Reply-To: <1427967440.19.0.462388571219.issue23849@psf.upfronthosting.co.za> Message-ID: <1428137039.11.0.595749900117.issue23849@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Thanks, I'll take a look. ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 11:08:10 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 04 Apr 2015 09:08:10 +0000 Subject: [issue23640] Enum.from_bytes() is broken In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za> Message-ID: <1428138490.56.0.797061084185.issue23640@psf.upfronthosting.co.za> Ethan Furman added the comment: With the patch: --> import enum --> class Huh(enum.IntEnum): ... blah = 2 ... --> Huh.blah.from_bytes(b'\04', 'big') Traceback (most recent call last): File "", line 1, in File "/home/ethan/source/python/issue23640/Lib/enum.py", line 222, in __call__ return cls.__new__(cls, value) File "/home/ethan/source/python/issue23640/Lib/enum.py", line 457, in __new__ raise ValueError("%r is not a valid %s" % (value, cls.__name__)) ValueError: 4 is not a valid Huh This is not the correct behavior. An IntEnum should act like an int, and in cases where it can't and still be an IntEnum, it becomes an int. But this behavior is Enum specific, and I would not expect other int subclasses to need or want that behavior. Also, in cases where class methods are alternate constructors there is no requirement that they go through the main __new__/__init__ constructors to do their job. In other words, if IntEnum.from_bytes (which is inherited) is not behaving correctly, it is up to IntEnum to fix it -- it is not the job of int, and this is not a bug in int. ---------- assignee: -> ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 11:38:21 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 04 Apr 2015 09:38:21 +0000 Subject: [issue23027] test_warnings fails with -Werror In-Reply-To: <1418248295.01.0.00165630152899.issue23027@psf.upfronthosting.co.za> Message-ID: <1428140301.19.0.384947824106.issue23027@psf.upfronthosting.co.za> Berker Peksag added the comment: Here is a patch. ---------- assignee: -> berker.peksag keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file38827/issue23027.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 11:42:48 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 04 Apr 2015 09:42:48 +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: <1428140568.78.0.568854500843.issue18383@psf.upfronthosting.co.za> Berker Peksag added the comment: issue18383_remove_dups.patch looks good to me. A test would be nice. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 11:49:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Apr 2015 09:49:19 +0000 Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za> Message-ID: <20150404094916.105414.35580@psf.io> Roundup Robot added the comment: New changeset 47a61a1c97b3 by Serhiy Storchaka in branch 'default': Fixed test_enum for issue #15582. https://hg.python.org/cpython/rev/47a61a1c97b3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 11:49:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Apr 2015 09:49:19 +0000 Subject: [issue15133] tkinter.BooleanVar.get() behavior and docstring disagree In-Reply-To: <1340357266.8.0.524344970378.issue15133@psf.upfronthosting.co.za> Message-ID: <20150404094916.105414.23975@psf.io> Roundup Robot added the comment: New changeset dedf481ec2be by Serhiy Storchaka in branch '2.7': Issue #15133: _tkinter.tkapp.getboolean() now supports long and Tcl_Obj and https://hg.python.org/cpython/rev/dedf481ec2be New changeset 117f45749359 by Serhiy Storchaka in branch '3.4': Issue #15133: _tkinter.tkapp.getboolean() now supports Tcl_Obj and always https://hg.python.org/cpython/rev/117f45749359 New changeset 38747f32fa7b by Serhiy Storchaka in branch 'default': Issue #15133: _tkinter.tkapp.getboolean() now supports Tcl_Obj and always https://hg.python.org/cpython/rev/38747f32fa7b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 11:53:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Apr 2015 09:53:49 +0000 Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za> Message-ID: <1428141229.04.0.921796297228.issue15582@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Changed test_enum to make buildbots green, but perhaps the docstring of Enum should be changed, because it now is used for all Enum subclasses that doesn't define a docstring explicitly. An alternative solution is to set __doc__ of Enum subclasses to an empty string if the docstring is not defined explicitly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 12:02:00 2015 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Sat, 04 Apr 2015 10:02:00 +0000 Subject: [issue23852] Wrong computation of max_fd on OpenBSD In-Reply-To: <1427987632.4.0.790792340938.issue23852@psf.upfronthosting.co.za> Message-ID: <1428141720.72.0.0950500259757.issue23852@psf.upfronthosting.co.za> Changes by C?dric Krier : ---------- title: Wrong FD_DIR file name on OpenBSD -> Wrong computation of max_fd on OpenBSD Added file: http://bugs.python.org/file38828/max_fd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 12:02:12 2015 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Sat, 04 Apr 2015 10:02:12 +0000 Subject: [issue23852] Wrong computation of max_fd on OpenBSD In-Reply-To: <1427987632.4.0.790792340938.issue23852@psf.upfronthosting.co.za> Message-ID: <1428141732.43.0.153338649199.issue23852@psf.upfronthosting.co.za> Changes by C?dric Krier : Removed file: http://bugs.python.org/file38828/max_fd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 12:09:15 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Apr 2015 10:09:15 +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: <1428142155.97.0.743920212493.issue18383@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> berker.peksag stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 12:11:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Apr 2015 10:11:53 +0000 Subject: [issue23027] test_warnings fails with -Werror In-Reply-To: <1418248295.01.0.00165630152899.issue23027@psf.upfronthosting.co.za> Message-ID: <1428142313.46.0.923369856013.issue23027@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch fixes an error, but produces a warning about changed filters. The patch in issue18383 should fix it. The patch LGTM, but I left one question on Rietveld. ---------- dependencies: +test_warnings modifies warnings.filters when running with "-W default" stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 12:57:47 2015 From: report at bugs.python.org (Martijn Pieters) Date: Sat, 04 Apr 2015 10:57:47 +0000 Subject: [issue23864] issubclass without registration only works for "one-trick pony" collections ABCs. Message-ID: <1428145067.47.0.0726533343331.issue23864@psf.upfronthosting.co.za> New submission from Martijn Pieters: The collections.abc documentation implies that *any* of the container ABCs can be used in an issubclass test against a class that implements all abstract methods: > These ABCs allow us to ask classes or instances if they provide particular functionality [...] In reality this only applies to the "One Trick Ponies" (term from PEP 3119, things like Container and Iterable, those classes with one or two methods). It fails for the compound container ABCs: >>> from collections.abc import Sequence, Container, Sized >>> class MySequence(object): ... def __contains__(self, item): pass ... def __len__(self): pass ... def __iter__(self): pass ... def __getitem__(self, index): pass ... def __len__(self): pass ... >>> issubclass(MySequence, Container) True >>> issubclass(MySequence, Sized) True >>> issubclass(MySequence, Sequence) False That's because the One Trick Ponies implement a __subclasshook__ method that is locked to the specific class and returns NotImplemented for subclasses; for instance, the Iterable.__subclasshook__ implementation is: @classmethod def __subclasshook__(cls, C): if cls is Iterable: if any("__iter__" in B.__dict__ for B in C.__mro__): return True return NotImplemented The compound container classes build on top of the One Trick Ponies, so the class test will fail, NotImplemented is returned and the normal ABC tests for base classes that have been explicitly registered continues, but this won't include unregistered complete implementations. Either the compound classes need their own __subclasshook__ implementations, or the documentation needs to be updated to make it clear that without explicit registrations the issubclass() (and isinstance()) tests only apply to the One Trick Ponies. ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 240060 nosy: docs at python, mjpieters priority: normal severity: normal status: open title: issubclass without registration only works for "one-trick pony" collections ABCs. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 12:59:26 2015 From: report at bugs.python.org (Jon Clements) Date: Sat, 04 Apr 2015 10:59:26 +0000 Subject: [issue23864] issubclass without registration only works for "one-trick pony" collections ABCs. In-Reply-To: <1428145067.47.0.0726533343331.issue23864@psf.upfronthosting.co.za> Message-ID: <1428145166.63.0.0727817137663.issue23864@psf.upfronthosting.co.za> Changes by Jon Clements : ---------- nosy: +joncle _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 13:04:53 2015 From: report at bugs.python.org (Martijn Pieters) Date: Sat, 04 Apr 2015 11:04:53 +0000 Subject: [issue23864] issubclass without registration only works for "one-trick pony" collections ABCs. In-Reply-To: <1428145067.47.0.0726533343331.issue23864@psf.upfronthosting.co.za> Message-ID: <1428145493.4.0.271488472983.issue23864@psf.upfronthosting.co.za> Martijn Pieters added the comment: I should have added the mixin methods for the Sequence implementation; the more complete demonstration is: >>> from collections.abc import Sequence, Container, Sized >>> class MySequence(object): ... def __contains__(self, item): pass ... def __len__(self): pass ... def __iter__(self): pass ... def __getitem__(self, index): pass ... def __len__(self): pass ... def __reversed__(self): pass ... def index(self, item): pass ... def count(self, item): pass ... >>> issubclass(MySequence, Container) True >>> issubclass(MySequence, Sized) True >>> issubclass(MySequence, Sequence) False ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 13:08:32 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Apr 2015 11:08:32 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428145712.72.0.915835001396.issue23857@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I agree with Donald on all points. This shouldn't be done at the language level at all (why should it apply only to Python-written tools?). Having a centralized setting saying "I relinquish security on HTTPS accesses" sounds like a bad idea. And if this is solely for the "support legacy systems" business of some vendors, then it sounds like it may be close to Alex's post here :-) https://alexgaynor.net/2015/mar/30/red-hat-open-source-community/ It's already possible to disable HTTPS certificate checking by using the right SSLContext options, at least with urllib and http.client. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 13:13:00 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Apr 2015 11:13:00 +0000 Subject: [issue23865] Fix possible leaks in close methods Message-ID: <1428145980.2.0.463866688715.issue23865@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch fixes two related issues in a number of modules. 1. close() methods sometimes release multiple resources. Every closing operation can fail, but it shouldn't prevent releasing other resources. See for example issue21802. 2. close() should be idempotent. I.e. calling close() second times shouldn't have any effect. Even if close() failed, repeated call of close() (usually in __exit__(), in __del__(), or in finally block) shouldn't raise an exception. Many close() methods already satisfy these conditions, but not all. ---------- components: Library (Lib) files: close.patch keywords: patch messages: 240063 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Fix possible leaks in close methods type: resource usage versions: Python 2.7, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38829/close.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 13:18:53 2015 From: report at bugs.python.org (Tim Golden) Date: Sat, 04 Apr 2015 11:18:53 +0000 Subject: [issue23861] Make stdprinter use DebugOutputString when no stdout/stderr available In-Reply-To: <1428087350.41.0.355922680582.issue23861@psf.upfronthosting.co.za> Message-ID: <551FC898.2000306@timgolden.me.uk> Tim Golden added the comment: Are we talking about re-implementing StdPrinter in terms of OutputDebugString? (Either always, on Windows, or as a fallback?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 13:19:54 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Apr 2015 11:19:54 +0000 Subject: [issue23640] Enum.from_bytes() is broken In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za> Message-ID: <1428146394.11.0.4769096162.issue23640@psf.upfronthosting.co.za> Antoine Pitrou added the comment: The fact that derived_int.from_bytes() doesn't call the derived constructor clearly sounds like a bug to me, regardless of whether IntEnum also has its own bugs. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 13:30:16 2015 From: report at bugs.python.org (Antti Haapala) Date: Sat, 04 Apr 2015 11:30:16 +0000 Subject: [issue23864] issubclass without registration only works for "one-trick pony" collections ABCs. In-Reply-To: <1428145067.47.0.0726533343331.issue23864@psf.upfronthosting.co.za> Message-ID: <1428147016.7.0.0235755365437.issue23864@psf.upfronthosting.co.za> Antti Haapala added the comment: This does apply to all versions of Python from 2.6 up. Registering does work of course. I believe the reason for not having the __subclasshook__ is the following sentence in PEP 3119: "ABCs are intended to solve problems that don't have a good solution at all in Python 2, such as distinguishing between mappings and sequences." This used to be worse in <3.3 because there if you ever inherit from `Sequence` you will always end up having `__dict__`, even if you just want `__slots__`. (By the way, if Py2 documentation is fixed, it should also say that these ABCs are new as of 2.6, not since 2.4 like the rest of the collections module). ---------- nosy: +ztane _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 13:41:09 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 04 Apr 2015 11:41:09 +0000 Subject: [issue23866] array module broken Message-ID: <1428147669.14.0.904457263314.issue23866@psf.upfronthosting.co.za> New submission from Antoine Pitrou: The array.array constructor has stopped working. I feel like this may be due to the latest Argument Clinic changes. ====================================================================== ERROR: test_create_from_bytes (test.test_array.ByteTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/antoine/cpython/default/Lib/test/test_array.py", line 1016, in test_create_from_bytes a = array.array('H', b"1234") TypeError: a bytes-like object is required, not 'tuple' ---------- components: Library (Lib) messages: 240067 nosy: pitrou, serhiy.storchaka priority: release blocker severity: normal status: open title: array module broken type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 14:54:39 2015 From: report at bugs.python.org (Stefan Krah) Date: Sat, 04 Apr 2015 12:54:39 +0000 Subject: [issue23852] Wrong computation of max_fd on OpenBSD In-Reply-To: <1427987632.4.0.790792340938.issue23852@psf.upfronthosting.co.za> Message-ID: <1428152079.12.0.759455432121.issue23852@psf.upfronthosting.co.za> Stefan Krah added the comment: Unfortunately I don't have an OpenBSD install either. From the sysconf.c source ... http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/lib/libc/gen/sysconf.c?rev=1.22&content-type=text/plain ... it seems that sysconf(_SC_OPEN_MAX) also calls getrlimit(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 16:05:30 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 04 Apr 2015 14:05:30 +0000 Subject: [issue23861] Make stdprinter use DebugOutputString when no stdout/stderr available In-Reply-To: <1428087350.41.0.355922680582.issue23861@psf.upfronthosting.co.za> Message-ID: <1428156330.21.0.372193944538.issue23861@psf.upfronthosting.co.za> Steve Dower added the comment: There's just a couple of places to add calls to OutputDebugString, plus we need to make creation always succeed on Windows. Not a huge change - it'll still write to the standard stream if it's there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 16:07:05 2015 From: report at bugs.python.org (Wolfgang Maier) Date: Sat, 04 Apr 2015 14:07:05 +0000 Subject: [issue23466] PEP 461: Inconsistency between str and bytes formatting of integers In-Reply-To: <1424024506.86.0.140677708328.issue23466@psf.upfronthosting.co.za> Message-ID: <1428156425.48.0.721339746513.issue23466@psf.upfronthosting.co.za> Wolfgang Maier added the comment: the new test: test_exc('%x', '1', TypeError, "%x format: a number is required, not str") expects the wrong error message. python -m unittest -v test.test_format ... '%x' % '1' works? ... no Unexpected : '%x format: an integer is required, not str' ... -> it's "an integer", not "a number" ---------- nosy: +wolma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 16:07:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Apr 2015 14:07:58 +0000 Subject: [issue23492] Argument Clinic: improve generated parser for 1-argument functions In-Reply-To: <1424443211.95.0.366719358355.issue23492@psf.upfronthosting.co.za> Message-ID: <20150404140755.34661.98461@psf.io> Roundup Robot added the comment: New changeset 973c9ec53bbb by Serhiy Storchaka in branch 'default': Fixed the array module broken in issue #23492. https://hg.python.org/cpython/rev/973c9ec53bbb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 16:07:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Apr 2015 14:07:58 +0000 Subject: [issue23866] array module broken In-Reply-To: <1428147669.14.0.904457263314.issue23866@psf.upfronthosting.co.za> Message-ID: <20150404140755.34661.70251@psf.io> Roundup Robot added the comment: New changeset 973c9ec53bbb by Serhiy Storchaka in branch 'default': Fixed the array module broken in issue #23492. https://hg.python.org/cpython/rev/973c9ec53bbb ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 16:10:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Apr 2015 14:10:28 +0000 Subject: [issue23866] array module broken In-Reply-To: <1428147669.14.0.904457263314.issue23866@psf.upfronthosting.co.za> Message-ID: <1428156628.16.0.0787494759042.issue23866@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Antoine. Fixed. ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 16:24:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Apr 2015 14:24:37 +0000 Subject: [issue23867] Argument Clinic: inline parsing code for 1-argument functions Message-ID: <1428157476.28.0.0922120616231.issue23867@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch makes Argument Clinic to inline parsing code for most popular formats in functions with single positional argument. This makes parsing faster. ---------- components: Argument Clinic files: clinic_meth_o_inline.patch keywords: patch messages: 240074 nosy: larry, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Argument Clinic: inline parsing code for 1-argument functions type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file38830/clinic_meth_o_inline.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 16:24:43 2015 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Sat, 04 Apr 2015 14:24:43 +0000 Subject: [issue23852] Wrong computation of max_fd on OpenBSD In-Reply-To: <1427987632.4.0.790792340938.issue23852@psf.upfronthosting.co.za> Message-ID: <1428157483.83.0.37161572437.issue23852@psf.upfronthosting.co.za> C?dric Krier added the comment: But sysconf(_SC_OPEN_MAX) uses rlim_cur which is too low instead of rlim_max. My proposal is indeed describe in msg219477, it is not prefect but at least better than the current one for OpenBSD. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 16:25:52 2015 From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=) Date: Sat, 04 Apr 2015 14:25:52 +0000 Subject: [issue23852] Wrong computation of max_fd on OpenBSD In-Reply-To: <1427987632.4.0.790792340938.issue23852@psf.upfronthosting.co.za> Message-ID: <1428157552.84.0.288687867274.issue23852@psf.upfronthosting.co.za> C?dric Krier added the comment: Correctly cast to long instead of int. ---------- Added file: http://bugs.python.org/file38831/max_fd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 16:30:14 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Apr 2015 14:30:14 +0000 Subject: [issue23466] PEP 461: Inconsistency between str and bytes formatting of integers In-Reply-To: <1424024506.86.0.140677708328.issue23466@psf.upfronthosting.co.za> Message-ID: <20150404143011.34643.43388@psf.io> Roundup Robot added the comment: New changeset 11e6986c794d by Serhiy Storchaka in branch 'default': Issue #23466: Fixed expected error message in test_format. https://hg.python.org/cpython/rev/11e6986c794d ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 16:31:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Apr 2015 14:31:51 +0000 Subject: [issue23466] PEP 461: Inconsistency between str and bytes formatting of integers In-Reply-To: <1424024506.86.0.140677708328.issue23466@psf.upfronthosting.co.za> Message-ID: <1428157911.02.0.209016600761.issue23466@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Good catch, Wolfgang! Definitely we should make test_format more unittest compatible. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 17:00:34 2015 From: report at bugs.python.org (Hristo Venev) Date: Sat, 04 Apr 2015 15:00:34 +0000 Subject: [issue23868] Uninitialized objects are tracked by the garbage collector Message-ID: <1428159634.21.0.640344593113.issue23868@psf.upfronthosting.co.za> New submission from Hristo Venev: An object starts being tracked by the GC after being allocated, but before being initialized. If during initialization the GC runs, this may lead to tp_traverse being called on an uninitialized object. ---------- components: Interpreter Core messages: 240079 nosy: h.venev priority: normal severity: normal status: open title: Uninitialized objects are tracked by the garbage collector versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 17:03:22 2015 From: report at bugs.python.org (Hristo Venev) Date: Sat, 04 Apr 2015 15:03:22 +0000 Subject: [issue23869] Initialization is being done in PyType_GenericAlloc Message-ID: <1428159802.19.0.247308187517.issue23869@psf.upfronthosting.co.za> New submission from Hristo Venev: In PyType_GenericAlloc, the initialization is being done. Namely, the PyObject part of the object is initialized and it is tracked by the garbage collector. In the documentation it is stated that tp_alloc should do no initialization. ---------- messages: 240080 nosy: h.venev priority: normal severity: normal status: open title: Initialization is being done in PyType_GenericAlloc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 17:04:43 2015 From: report at bugs.python.org (Hristo Venev) Date: Sat, 04 Apr 2015 15:04:43 +0000 Subject: [issue23869] Initialization is being done in PyType_GenericAlloc In-Reply-To: <1428159802.19.0.247308187517.issue23869@psf.upfronthosting.co.za> Message-ID: <1428159883.41.0.0971150913049.issue23869@psf.upfronthosting.co.za> Changes by Hristo Venev : ---------- components: +Interpreter Core versions: +Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 18:05:05 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 04 Apr 2015 16:05:05 +0000 Subject: [issue23849] Leaks in test_deque In-Reply-To: <1427967440.19.0.462388571219.issue23849@psf.upfronthosting.co.za> Message-ID: <1428163505.44.0.392066452652.issue23849@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Hmm, I don't see this on my build (Mac OS/X 10.10.2 clang-600.0.57): $ ./python.exe -m test.regrtest -R 3:3:reflog test_deque [1/1] test_deque beginning 6 repetitions 123456 ...... 1 test OK. Nor do I see any flux using the test_deque's down repeat loop: $ ./python.exe Lib/test/test_deque.py [178999, 178999, 178999, 178999, 178999] doctest (test.test_deque) ... 32 tests with zero failures ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 18:09:56 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 04 Apr 2015 16:09:56 +0000 Subject: [issue23849] Leaks in test_deque In-Reply-To: <1427967440.19.0.462388571219.issue23849@psf.upfronthosting.co.za> Message-ID: <1428163796.41.0.653772874072.issue23849@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Looks like Benjamin had fixed this earlier today: https://mail.python.org/pipermail/python-checkins/2015-April/135444.html ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 18:37:41 2015 From: report at bugs.python.org (Jeff McNeil) Date: Sat, 04 Apr 2015 16:37:41 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1428165461.13.0.555530591164.issue23863@psf.upfronthosting.co.za> Jeff McNeil added the comment: Whoops. Accidentally attached the wrong patch that I generated during testing. ---------- Added file: http://bugs.python.org/file38832/socket_eintr.1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 19:19:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Apr 2015 17:19:36 +0000 Subject: [issue23870] pprint collections classes Message-ID: <1428167976.78.0.301380656754.issue23870@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch adds support of all collections classes (except namedtuple) in pprint. It uses undocumented unstable private API. After implementing issue7434 the code could be rewritten with using public stable well-designed API. One day in the womb of time. But for now this patch allows to grope requirements to future API. ---------- components: Library (Lib) files: pprint_collections.patch keywords: patch messages: 240084 nosy: rhettinger, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: pprint collections classes type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file38833/pprint_collections.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 19:31:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Apr 2015 17:31:25 +0000 Subject: [issue23640] Enum.from_bytes() is broken In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za> Message-ID: <1428168685.47.0.96774268335.issue23640@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This bug allows to create new bool instances. >>> false = bool.from_bytes(b'\0', 'big') >>> true = bool.from_bytes(b'\1', 'big') >>> bool(false) False >>> bool(true) True >>> false is False False >>> true is True False >>> false False >>> true False ---------- priority: normal -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 20:43:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Apr 2015 18:43:48 +0000 Subject: [issue20192] pprint chokes on set containing frozenset In-Reply-To: <1389202631.98.0.662803177988.issue20192@psf.upfronthosting.co.za> Message-ID: <1428173028.89.0.96623732751.issue20192@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is reproducible on 2.7 example: >>> import pprint, datetime, test.test_datetime >>> naive = datetime.datetime.utcnow() >>> aware = datetime.datetime.utcnow().replace(tzinfo=test.test_datetime.FixedOffset(-300, "EST", 1)) >>> pprint.pprint({naive, aware}) set([Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython2.7/Lib/pprint.py", line 59, in pprint printer.pprint(object) File "/home/serhiy/py/cpython2.7/Lib/pprint.py", line 117, in pprint self._format(object, self._stream, 0, 0, {}, 0) File "/home/serhiy/py/cpython2.7/Lib/pprint.py", line 199, in _format object = _sorted(object) File "/home/serhiy/py/cpython2.7/Lib/pprint.py", line 82, in _sorted return sorted(iterable) TypeError: can't compare offset-naive and offset-aware datetimes >>> pprint.pprint({naive: 'naive', aware: 'aware'}) Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython2.7/Lib/pprint.py", line 59, in pprint printer.pprint(object) File "/home/serhiy/py/cpython2.7/Lib/pprint.py", line 117, in pprint self._format(object, self._stream, 0, 0, {}, 0) File "/home/serhiy/py/cpython2.7/Lib/pprint.py", line 140, in _format rep = self._repr(object, context, level - 1) File "/home/serhiy/py/cpython2.7/Lib/pprint.py", line 226, in _repr self._depth, level) File "/home/serhiy/py/cpython2.7/Lib/pprint.py", line 238, in format return _safe_repr(object, context, maxlevels, level) File "/home/serhiy/py/cpython2.7/Lib/pprint.py", line 280, in _safe_repr for k, v in _sorted(object.items()): File "/home/serhiy/py/cpython2.7/Lib/pprint.py", line 82, in _sorted return sorted(iterable) TypeError: can't compare offset-naive and offset-aware datetimes ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 21:17:56 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Apr 2015 19:17:56 +0000 Subject: [issue23728] binascii.crc_hqx() can return negative integer In-Reply-To: <1426888370.18.0.244841446134.issue23728@psf.upfronthosting.co.za> Message-ID: <1428175076.19.0.362043680571.issue23728@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Nobody proposed a patch, so I do this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 21:18:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Apr 2015 19:18:25 +0000 Subject: [issue23728] binascii.crc_hqx() can return negative integer In-Reply-To: <1426888370.18.0.244841446134.issue23728@psf.upfronthosting.co.za> Message-ID: <1428175105.21.0.584374806713.issue23728@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka keywords: +patch stage: needs patch -> patch review versions: +Python 3.4 Added file: http://bugs.python.org/file38834/binascii_crc_hqx_empty_data.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 21:19:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Apr 2015 19:19:55 +0000 Subject: [issue23790] When xdrlib.Packer().pack_string() fails, the Packer is corrupted In-Reply-To: <1427461510.09.0.808726067558.issue23790@psf.upfronthosting.co.za> Message-ID: <1428175195.88.0.732699963067.issue23790@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 21:21:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Apr 2015 19:21:22 +0000 Subject: [issue15133] tkinter.BooleanVar.get() behavior and docstring disagree In-Reply-To: <1340357266.8.0.524344970378.issue15133@psf.upfronthosting.co.za> Message-ID: <1428175282.25.0.224496576814.issue15133@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 Apr 4 22:07:30 2015 From: report at bugs.python.org (Bill Parker) Date: Sat, 04 Apr 2015 20:07:30 +0000 Subject: [issue23860] Failure to check return value from lseek() in Modules/mmapmodule.c In-Reply-To: <1428136346.4.0.290504454405.issue23860@psf.upfronthosting.co.za> Message-ID: Bill Parker added the comment: I would check 23855 as well, since the malloc() missing a sanity check, which could be a more serious issue .. On Sat, Apr 4, 2015 at 1:32 AM, Berker Peksag wrote: > > Berker Peksag added the comment: > > Thanks for the patch, Bill. If you want to work on similar issues see also > issue 15948. > > ---------- > components: +Extension Modules -Interpreter Core > nosy: +berker.peksag, haypo, serhiy.storchaka > stage: -> patch review > versions: +Python 3.5 > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 22:12:40 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 04 Apr 2015 20:12:40 +0000 Subject: [issue23501] Argument Clinic: generate code into separate files by default In-Reply-To: <1424603088.54.0.245767727537.issue23501@psf.upfronthosting.co.za> Message-ID: <1428178360.76.0.26931438157.issue23501@psf.upfronthosting.co.za> Mark Lawrence added the comment: I think this change in association with that in #23500 is causing builds to fail on Windows. error C2065: 'OS_STAT_METHODDEF' : undeclared identifier C:\cpython\Modules\posixmodule.c line 12083 ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 22:36:25 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 04 Apr 2015 20:36:25 +0000 Subject: [issue23501] Argument Clinic: generate code into separate files by default In-Reply-To: <1424603088.54.0.245767727537.issue23501@psf.upfronthosting.co.za> Message-ID: <20150404203622.16503.26644@psf.io> Roundup Robot added the comment: New changeset 17eb29faebde by Serhiy Storchaka in branch 'default': Issue #23501: #include "clinic/posixmodule.c.h" was in the section skipped on Windows. https://hg.python.org/cpython/rev/17eb29faebde ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 22:37:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Apr 2015 20:37:12 +0000 Subject: [issue23501] Argument Clinic: generate code into separate files by default In-Reply-To: <1424603088.54.0.245767727537.issue23501@psf.upfronthosting.co.za> Message-ID: <1428179832.94.0.647794630872.issue23501@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you Mark. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 23:16:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 04 Apr 2015 21:16:41 +0000 Subject: [issue23330] h2py.py regular expression missing In-Reply-To: <1422357197.95.0.836847227653.issue23330@psf.upfronthosting.co.za> Message-ID: <1428182201.11.0.556331833572.issue23330@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 23:48:52 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sat, 04 Apr 2015 21:48:52 +0000 Subject: [issue23501] Argument Clinic: generate code into separate files by default In-Reply-To: <1424603088.54.0.245767727537.issue23501@psf.upfronthosting.co.za> Message-ID: <1428184131.98.0.965201913686.issue23501@psf.upfronthosting.co.za> Mark Lawrence added the comment: Serhiy, thank you for the quick fix :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 4 23:54:23 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 04 Apr 2015 21:54:23 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428165461.13.0.555530591164.issue23863@psf.upfronthosting.co.za> Message-ID: STINNER Victor added the comment: I have a very good news for you: this issue and more generally all EINTR issues will be solved in Python 3.5. See the PEP 475. I'm not really interested to fix Python 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 00:04:31 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 04 Apr 2015 22:04:31 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: Message-ID: Gregory P. Smith added the comment: You may not be, but I am. :). Jeff is aware of PEP 475. Thanks for the awesome work on the real cleanup of this stuff in 3.5. Sanity at last. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 00:26:33 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 04 Apr 2015 22:26:33 +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: <1428186393.32.0.650850930625.issue18383@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 00:51:35 2015 From: report at bugs.python.org (eryksun) Date: Sat, 04 Apr 2015 22:51:35 +0000 Subject: [issue23864] issubclass without registration only works for "one-trick pony" collections ABCs. In-Reply-To: <1428145067.47.0.0726533343331.issue23864@psf.upfronthosting.co.za> Message-ID: <1428187895.08.0.392287426434.issue23864@psf.upfronthosting.co.za> eryksun added the comment: Probably I'm overlooking something, but why isn't this hook defined cooperatively, with a terminating base class method that returns True? If the call chain progresses to the base, then all of the interfaces have been satisfied. Otherwise one of the bases returns NotImplemented. If it's implemented cooperatively, then the `cls is Iterable` check can be removed, because it returns super().__subclasshook__(C) instead of True. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 00:59:03 2015 From: report at bugs.python.org (Antony Lee) Date: Sat, 04 Apr 2015 22:59:03 +0000 Subject: [issue23871] turning itertools.{repeat, count} into indexable iterables Message-ID: <1428188343.49.1.91705834608e-05.issue23871@psf.upfronthosting.co.za> New submission from Antony Lee: itertools.repeat and itertools.count could be made into indexable iterables (rather than iterators), rather than iterators, like range is right now. ---------- components: Library (Lib) messages: 240096 nosy: Antony.Lee priority: normal severity: normal status: open title: turning itertools.{repeat,count} into indexable iterables versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 01:47:05 2015 From: report at bugs.python.org (Hoolean) Date: Sat, 04 Apr 2015 23:47:05 +0000 Subject: [issue23872] Typo in response in smtpd Message-ID: <1428191225.22.0.658176098333.issue23872@psf.upfronthosting.co.za> New submission from Hoolean: A spelling mistake is present: in all other instances in the class, the string is ' [SP ]', yet at this line it is [incorrectly] ' [SP ' character. I have attached a patch correcting this. ---------- components: Library (Lib) files: correction.patch keywords: patch messages: 240097 nosy: Hoolean priority: normal severity: normal status: open title: Typo in response in smtpd type: behavior Added file: http://bugs.python.org/file38835/correction.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 02:57:43 2015 From: report at bugs.python.org (Hoolean) Date: Sun, 05 Apr 2015 00:57:43 +0000 Subject: [issue23873] Removal of dead code in smtpd Message-ID: <1428195463.82.0.559504880721.issue23873@psf.upfronthosting.co.za> New submission from Hoolean: Code was present that checked conditions that had previous been checked and had returned the function prematurely if the condition was true. As the condition has not changed before the check is made again, the condition will always be false and the code inside the if-statement will never be evaluated. The attached patch removes unnecessary code. ---------- components: Library (Lib) files: correction.patch keywords: patch messages: 240098 nosy: Hoolean priority: normal severity: normal status: open title: Removal of dead code in smtpd type: performance Added file: http://bugs.python.org/file38836/correction.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 04:08:27 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 05 Apr 2015 02:08:27 +0000 Subject: [issue23874] Encrypted MSI fails to install with code 2755 Message-ID: <1428199707.15.0.13472678589.issue23874@psf.upfronthosting.co.za> New submission from Jason R. Coombs: When installing Python (3.4.3 or 2.7.9) from an EFS encrypted installer file, the installation proceeds normally through the target selection and feature selection, but then immediately reports "/!\ The system cannot open the device or file specified," and aborts the installation with "The installer has encountered an unexpected error installing this package. This may indicate a problem with the package. The error code is 2755." Other MSI products install fine when the MSI is encrypted (pandoc, MongoDB), so there appears to be something unique about the Python installer that's failing when the Trusted Installer cannot read the MSI itself. Decrypting the MSI before installing works around the issue. Environment: Windows 8.1 64-bit with Python 64-bit ---------- components: Installation, Windows messages: 240099 nosy: jason.coombs, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Encrypted MSI fails to install with code 2755 versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 04:13:59 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Sun, 05 Apr 2015 02:13:59 +0000 Subject: [issue23874] Encrypted MSI fails to install with code 2755 In-Reply-To: <1428199707.15.0.13472678589.issue23874@psf.upfronthosting.co.za> Message-ID: <1428200039.34.0.4502311163.issue23874@psf.upfronthosting.co.za> Jason R. Coombs added the comment: A search for "EFS error code 2755" reveals others who have encountered this issue with other packages, so it's not unique to Python, though it may be something that Python might be able to address or may be unable to solve due to the required operations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 05:09:27 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 05 Apr 2015 03:09:27 +0000 Subject: [issue23841] py34 OrderedDict is using weakref for root reference In-Reply-To: <1427889707.75.0.323875541647.issue23841@psf.upfronthosting.co.za> Message-ID: <1428203367.38.0.923934568645.issue23841@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Antoine, I could use a second pair of eyes to see what is going on there. It looks like an upstream __del__() method is trying to iterate over an OrderedDict that was already being shutdown (the hardroot link no longer exists). That said, I don't see how the OD can be partially shutdown if the upstream code still has a reference to the OD in the adapters. ---------- nosy: +eric.snow, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 05:56:19 2015 From: report at bugs.python.org (Arnon Sela) Date: Sun, 05 Apr 2015 03:56:19 +0000 Subject: [issue20353] Hanging bug with multiprocessing + sqlite3 + tkinter (OS X 10.9 only) In-Reply-To: <1390415067.55.0.719190169135.issue20353@psf.upfronthosting.co.za> Message-ID: <1428206179.37.0.273939257909.issue20353@psf.upfronthosting.co.za> Arnon Sela added the comment: I ran into similar issue on OSX. Multiprocessing system where processes issue sqlite3.connect(). Periodically it hangs. System is using Python 3.4.3 and sqlite3; it doesn't use tkinter Noticed the following: 1. This doesn't happen on Ubuntu 2. It happens even if URL is invalid - which means that it happens before referring to URL as DB. Workaround didn't solve the problem. But it seems to reduce the frequency. And unfortunately, the system is too large and complex for it to be sent. I tried to set my environment to debug, but with no luck yet :) Thanks, ---------- nosy: +PyAcrisel _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 06:25:27 2015 From: report at bugs.python.org (Ezio Melotti) Date: Sun, 05 Apr 2015 04:25:27 +0000 Subject: [issue23872] Typo in response in smtpd In-Reply-To: <1428191225.22.0.658176098333.issue23872@psf.upfronthosting.co.za> Message-ID: <1428207927.57.0.929891720188.issue23872@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- stage: -> commit review versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 06:51:58 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 05 Apr 2015 04:51:58 +0000 Subject: [issue20353] Hanging bug with multiprocessing + sqlite3 + tkinter (OS X 10.9 only) In-Reply-To: <1390415067.55.0.719190169135.issue20353@psf.upfronthosting.co.za> Message-ID: <1428209518.93.0.117439425534.issue20353@psf.upfronthosting.co.za> Ned Deily added the comment: Arnon, what version of sqlite3 is the Python linked with? Try: python3.4 -c "import sqlite3;print(sqlite3.sqlite_version)" What kind of database access is happening in your program, i.e. strictly multi-read, one writer many reads, multiple-writers? Also, regarding the workaround, if you do call sqlite3.connect in the main process, check that you keep a reference to it (by assigning the result to a variable) so that the open connection doesn't get garbage-collected. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 07:24:43 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Apr 2015 05:24:43 +0000 Subject: [issue19105] pprint doesn't use all width In-Reply-To: <1380289834.62.0.88627838079.issue19105@psf.upfronthosting.co.za> Message-ID: <20150405052440.64687.65282@psf.io> Roundup Robot added the comment: New changeset 6d9520e2223f by Serhiy Storchaka in branch 'default': Updated pprint examples in according to issue #19105. https://hg.python.org/cpython/rev/6d9520e2223f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 10:38:58 2015 From: report at bugs.python.org (Antti Haapala) Date: Sun, 05 Apr 2015 08:38:58 +0000 Subject: [issue23871] turning itertools.{repeat, count} into indexable iterables In-Reply-To: <1428188343.49.1.91705834608e-05.issue23871@psf.upfronthosting.co.za> Message-ID: <1428223138.87.0.57194474963.issue23871@psf.upfronthosting.co.za> Antti Haapala added the comment: well, they wouldn't and shouldn't behave like range. range is a sequence whereas count or repeat wouldn't necessarily be sequences. (they can be infinite and thus not having length). And the count shouldn't be *reiterable* because that is why it exists (otherwise we could just use range). For repeat, indexing hardly matters. ---------- nosy: +ztane _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 10:45:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Apr 2015 08:45:03 +0000 Subject: [issue23871] turning itertools.{repeat, count} into indexable iterables In-Reply-To: <1428188343.49.1.91705834608e-05.issue23871@psf.upfronthosting.co.za> Message-ID: <1428223503.31.0.664162507259.issue23871@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 11:53:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Apr 2015 09:53:32 +0000 Subject: [issue20159] Derby #7: Convert 51 sites to Argument Clinic across 3 files -> Derby: Convert the ElementTree module to use Argument Clinic In-Reply-To: <1389086966.47.0.33615845784.issue20159@psf.upfronthosting.co.za> Message-ID: <1428227612.46.0.601707502732.issue20159@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch. Converted __init__ methods and removed explicit declarations of self parameters. SubElement and Element.__init__ still are not converted, as they need the support of **kwargs. ---------- Added file: http://bugs.python.org/file38837/etree_clinic_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 12:25:23 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 05 Apr 2015 10:25:23 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428229523.09.0.753885245568.issue23857@psf.upfronthosting.co.za> Nick Coghlan added the comment: The discussion isn't on python-ideas yet because I wanted to get a better sense of what might be politically feasible before putting this question to a broader audience. I agree it needs to move there eventually (likely during or after PyCon), and will almost certainly lead to a PEP (3.5b1 is slated for late May, so we have 6-7 weeks to resolve the question in time for that if anything is going to change for 3.5) To be absolutely clear, nobody is thinking of reintroducing silent security failures anywhere - the ultimate aim of posting this draft patch is to start down the path to defining a new Python 3.5 feature that could then by pitched for a PEP 466 style backport to Python 2.7 to provide a potentially smoother upgrade path from the pre-PEP-476 status quo to the shiny new PEP 476 future for the benefits of folks that take both security concerns and backwards compatibility concerns at least as seriously as python-dev do, but are serving a very different audience and hence may need to make different trade-offs between these considerations. The "use sitecustomize.py to monkeypatch in the old behaviour" section in PEP 476 was *intended* to provide that upgrade path, but it turned out not to work as well as I hoped it would as it turns out that approach effectively requires forking the standard library to let a vendor manage the migration on behalf of their customers by offering a bridging "opt-in" period. Changing the standard library's behaviour to this degree would be a genuinely drastic option, so I consider it vastly superior to backport a supported behaviour from a later version of Python (along the lines of the network security backports in PEP 466) than it would be to invent something custom that has no upstream support. This does mean spending more time upfront coming up with a way of designing the feature that the core development community considers to be useful independently of backporting considerations (e.g. bringing the STARTTLS migration into the framework could be useful, as the sad state of email server certificate validity means that even upstream CPython is going to need to leave that off by default for the time being). That additional time investment is likely to be worthwhile when the pay-off is avoiding a long-lived behavioural fork. As for *why* such an opt-in bridging period might be needed by some organisations, one of the key issues to consider is the likely desire to do a global upgrade to an updated Python version as soon as possible, *without* risking breaking currently "working" services in an end-user visible way, and then handling the security configuration change on a service-by-service basis as a subsequent step, in conjunction with any necessary upgrades to the related security infrastructure. Splitting the two activities (Python upgrade, service network security upgrade) this way is potentially desirable even if you have control of all of the affected Python applications, but it may be absolutely essential if you're running a proprietary bytecode-only Python application in the system Python, or simply aren't authorised to make application level changes to an affected service. The rationale for introducing a configuration or marker file for this is to allow the *default* behaviour in the absence of such a file to be the standard PEP 476 behaviour. An opt-in bridging period can then be implemented by publishing a default configuration file that globally opts out, with system administrators selectively opting in. Eventually the default configuration can potentially be changed or removed such that certificates are verified by default, by which time services that genuinely need to be opted out should already have the appropriate configuration settings set. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 12:31:56 2015 From: report at bugs.python.org (Armin Rigo) Date: Sun, 05 Apr 2015 10:31:56 +0000 Subject: [issue23830] Add AF_IUCV support to sockets In-Reply-To: <1427828484.47.0.0998681334057.issue23830@psf.upfronthosting.co.za> Message-ID: <1428229916.39.0.28434872658.issue23830@psf.upfronthosting.co.za> Armin Rigo added the comment: The PyArg_ParseTuple() size arguments should be of type "Py_ssize_t" instead of "int". ---------- nosy: +arigo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 12:32:26 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 05 Apr 2015 10:32:26 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428229946.62.0.471648994912.issue23857@psf.upfronthosting.co.za> Nick Coghlan added the comment: As far as Alex's post goes, it's simply wrong, and I wish he had spoken to me about his frustrations with the significant challenges of infrastructure maintenance in large established organisations before posting it. Red Hat's been fighting the battle for better enterprise infrastructure management for 20 years at this point (including in the US public sector: https://www.redhat.com/en/technologies/industries/government), but like almost all institutional reform, it's very slow going. We offer plenty of options for folks to upgrade faster, and it's much easier for us when they do: http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html So if you care about getting security enhancements rolled out in a way that means people responsible for infrastructure management in large organisations will actually adopt them, rather than dismissing them out of hand as "too risky", please take a moment to consider that we might have some idea what we're talking about. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 12:49:33 2015 From: report at bugs.python.org (Donald Stufft) Date: Sun, 05 Apr 2015 10:49:33 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428230973.06.0.131371064733.issue23857@psf.upfronthosting.co.za> Donald Stufft added the comment: On it's own I think this switch is a bad idea because it's too big of a hammer. Someone shouldn't accidentally disable TLS verification in pip for instance because they wanted to disable TLS verification for some random tool that only hit internal TLS but which didn't have it's own off switch written into it. A lot of tools are written in Python and it's hard for a user to really know what the full extent of toggling this switch on their system will be, especially given that they may have no idea which other tools are incidentally written in python (pip is not a good example of this, but there are lots of tools that are written in Python but which the fact they are written in Python isn't important or maybe even obvious). I think keyed by site is wrong too, again because the scope is wrong. Opting out of security at the Python level filters down into tons of random applications that the end user may or may not be aware is even written in Python. Part of the benefit of the current "opt out" mechanism is that it feels a little dirty to opt in in that fashion, and it should because globally opting out is breaking the security expectations that any application has now with the latest versions of Python, and adding a "cleaner" way of doing this is essentially giving people a nicer footgun (in the long term). Now, I recognize that there is legacy systems at play here that are going to be around for a long time and that who this proposal is really being aimed to helping. My question would be, why can't those downstreams simply carry this patch? The attached patch is relatively tiny so it shouldn't be a very large burden, the largest being documenting and making people aware that such a thing exists on that platform. If there's enough downstreams who would reasonably have a reason to apply said patch maybe an addendum (or a new PEP) can be added suggesting that downstreams should apply said patch. The tl;dr of my opinion is that if it weren't for legacy systems, I don't think anyone would propose this feature, and given the security sensitive nature of it I think it's best to treat this feature as a quirk of those legacy systems rather than a fully supported API of Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 13:05:48 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 Apr 2015 11:05:48 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428229523.09.0.753885245568.issue23857@psf.upfronthosting.co.za> Message-ID: <55211708.10508@free.fr> Antoine Pitrou added the comment: Le 05/04/2015 12:25, Nick Coghlan a ?crit : > > This does mean spending more time upfront coming up with a way of > designing the feature that the core development community considers to > be useful independently of backporting considerations (e.g. bringing the > STARTTLS migration into the framework could be useful, as the sad state > of email server certificate validity means that even upstream CPython is > going to need to leave that off by default for the time being). I'm curious about statistics about e-mail servers, even though unrelated to this issue. > Splitting the two activities (Python upgrade, service network > security > upgrade) this way is potentially desirable even if you have control of > all of the affected Python applications, but it may be absolutely > essential if you're running a proprietary bytecode-only Python > application in the system Python, or simply aren't authorised to make > application level changes to an affected service. True, but this is a repeat of the PEP 476 discussion. Something has changed in the meantime: PEP 476 was accepted and its code has shipped in an official release. There hasn't been any major (or even minor) outcry. Speaking as someone who opposed PEP 476, I now support us moving forward instead of trying to eschew the PEP's deliberate effects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 13:07:23 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 Apr 2015 11:07:23 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428232043.98.0.783031134916.issue23857@psf.upfronthosting.co.za> Antoine Pitrou added the comment: By the way, if a vendor wants vendor-specific behaviour, forking the standard library is a normal price to pay. (in this case, the diff wouldn't be large, and it's made against an extremely stable upstream branch) ---------- _______________________________________ Python tracker _______________________________________ From mal at egenix.com Sun Apr 5 13:26:41 2015 From: mal at egenix.com (M.-A. Lemburg) Date: Sun, 05 Apr 2015 13:26:41 +0200 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428230973.06.0.131371064733.issue23857@psf.upfronthosting.co.za> References: <1428230973.06.0.131371064733.issue23857@psf.upfronthosting.co.za> Message-ID: <55211BF1.70400@egenix.com> FWIW: I just ran into a situation where the new approach resulted in pip, setuptools and zc.buildout not working anymore. This was on an AIX system which did come with CA root certificates at all. Now, I knew how to fix this, but the solution was not an obvious one. I had to use truss to figure out where OpenSSL was looking for certificates and the added the Mozilla cert bundle from our egenix-pyopenssl package to make things work again. This was on a system where Python 2.7.3 had been installed previously. After the upgrade to Python 2.7.9 nothing worked anymore. Again: Please let the users decide what level of security they want to apply. We can point users to solutions, but in the end have to respect their own decisions. Note that staying with Python 2.7.8 is a much worse approach than disabling the checks. -- Marc-Andre Lemburg eGenix.com From report at bugs.python.org Sun Apr 5 13:26:42 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sun, 05 Apr 2015 11:26:42 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428230973.06.0.131371064733.issue23857@psf.upfronthosting.co.za> Message-ID: <55211BF1.70400@egenix.com> Marc-Andre Lemburg added the comment: FWIW: I just ran into a situation where the new approach resulted in pip, setuptools and zc.buildout not working anymore. This was on an AIX system which did come with CA root certificates at all. Now, I knew how to fix this, but the solution was not an obvious one. I had to use truss to figure out where OpenSSL was looking for certificates and the added the Mozilla cert bundle from our egenix-pyopenssl package to make things work again. This was on a system where Python 2.7.3 had been installed previously. After the upgrade to Python 2.7.9 nothing worked anymore. Again: Please let the users decide what level of security they want to apply. We can point users to solutions, but in the end have to respect their own decisions. Note that staying with Python 2.7.8 is a much worse approach than disabling the checks. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 13:40:00 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 Apr 2015 11:40:00 +0000 Subject: [issue23841] py34 OrderedDict is using weakref for root reference In-Reply-To: <1427889707.75.0.323875541647.issue23841@psf.upfronthosting.co.za> Message-ID: <1428234000.27.0.911578646636.issue23841@psf.upfronthosting.co.za> Antoine Pitrou added the comment: weakrefs are traditionally cleared by the cyclic GC before calling any __del__ method. This used to be mandatory to eschew situations where a weakref callback could see cleared objects, but produces the side effect that __del__ methods can see dead weakrefs. This is also true pre-3.4, by the way, but perhaps the OP's __del__ wasn't called at all (if it was part of the cycle, the object would end up in gc.garbage instead)? We could perhaps reverse the order, but then weakref callbacks may see __del__'ed objects. Hard to say which one is better, and keeping the traditional behaviour means less compatibility hassles. Some of this is discussed in Modules/gc_weakref.txt. In general, __del__ methods may see strange errors. For example, at interpreter shutdown, your __del__ method can be called while some modules have started unloading. Python 3.4 definitely tries to improve on all this, but there's no perfect solution, and some of the improvements might also backfire in some rare cases :-) ---------- nosy: +tim.peters versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 13:42:09 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 Apr 2015 11:42:09 +0000 Subject: [issue23841] py34 OrderedDict is using weakref for root reference In-Reply-To: <1427889707.75.0.323875541647.issue23841@psf.upfronthosting.co.za> Message-ID: <1428234129.21.0.580128435271.issue23841@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Concretely, the possible workarounds are: - don't do anything complex in your __del__ - be prepared to deal with unexpected errors in your __del__ - starting from Python 3.4, don't define __del__ and use weakref.finalize() instead: https://docs.python.org/3/library/weakref.html#weakref.finalize ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 13:44:48 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 Apr 2015 11:44:48 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428234288.76.0.935755613725.issue23857@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > This was on a system where Python 2.7.3 had been installed > previously. After the upgrade to Python 2.7.9 nothing worked > anymore. Who did the upgrade and with which binaries? If you're compiling Python from source, especially for an exotic system, well, you're supposed to read the release notes :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 15:08:08 2015 From: report at bugs.python.org (Cyd Haselton) Date: Sun, 05 Apr 2015 13:08:08 +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: <1428239288.45.0.742807335017.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Hey Ryan, Just now patching downloaded/unzipped tip and was wondering if there was an order in which patches should be applied. I ask because i'm getting the following when applying the android_segfault_fix.patch /bld/python/cpython-3.4/cpython-3.4/Python $ patch < android_segfault_fix.patch patching file frozenmain.c Hunk 3 FAILED 53/56. } setlocale(LC_ALL, ""); +#endif for (i = 0; i < argc; i++) { argv_copy[i] = Py_DecodeLocale(argv[i], NULL); argv_copy2[i] = argv_copy[i]; patching file pylifecycle.c patch: can't open 'pylifecycle.c': No such file or directory Thoughts? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 15:14:33 2015 From: report at bugs.python.org (Cyd Haselton) Date: Sun, 05 Apr 2015 13:14:33 +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: <1428239673.71.0.830820790058.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: UPDATE: I found the file in github, under master, in Python/. It's not in the 3.4 or origin/3.4 branches...aren't we working on those? Or does it not matter? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 15:25:50 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Sun, 05 Apr 2015 13:25: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: <1428240350.01.0.058301327039.issue23496@psf.upfronthosting.co.za> Ryan Gonzalez added the comment: I thought this was for the tip, i.e. the 3.5 dev...? But I created the patches in the order that I wrote the descriptions in the comment. So you might want to use that order. If that fails, I can figure out the revision I was at when I created the patches. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 15:53:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 05 Apr 2015 13:53:20 +0000 Subject: [issue20173] Derby #4: Convert 53 sites to Argument Clinic across 5 files In-Reply-To: <1389138393.36.0.783793973134.issue20173@psf.upfronthosting.co.za> Message-ID: <1428242000.77.0.0476107850154.issue20173@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is reworked patch for the _codecs module. No optional groups are used, all parameters have sensible defaults. Default encoding is "utf-8", default errors is "strict" or None (if function accepts None), default mapping is None. Unified names and coding style, improved docstrings. ---------- nosy: +serhiy.storchaka stage: needs patch -> patch review Added file: http://bugs.python.org/file38838/codecs_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 16:03:02 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 05 Apr 2015 14:03:02 +0000 Subject: [issue23872] Typo in response in smtpd In-Reply-To: <1428191225.22.0.658176098333.issue23872@psf.upfronthosting.co.za> Message-ID: <1428242582.38.0.749381036572.issue23872@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 16:03:31 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Apr 2015 14:03:31 +0000 Subject: [issue23872] Typo in response in smtpd In-Reply-To: <1428191225.22.0.658176098333.issue23872@psf.upfronthosting.co.za> Message-ID: <20150405140327.16262.4247@psf.io> Roundup Robot added the comment: New changeset cc2c7aa2d7a6 by Benjamin Peterson in branch '3.4': fix extended command syntax (closes #23872) https://hg.python.org/cpython/rev/cc2c7aa2d7a6 New changeset 2c89c1c34e19 by Benjamin Peterson in branch 'default': merge 3.4 (#23872) https://hg.python.org/cpython/rev/2c89c1c34e19 ---------- nosy: +python-dev resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 16:25:40 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 05 Apr 2015 14:25:40 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428243940.43.0.152891153688.issue23857@psf.upfronthosting.co.za> Nick Coghlan added the comment: PEP 476 *has* a mechanism in it that was supposed to deal with this problem, thus leaving *end users* in full control of the decision on when they upgrade their security infrastructure rather than having that decision arbitrarily imposed on them by a vendor or an upstream community project regardless of whether or not it's appropriate for their particular situation. Unfortunately, it turned out I was wrong about the viability of the approach in PEP 476, hence this suggestion to revisit the question. There is *no* suggestion of changing the default behaviour away from that defined in PEP 476, the part I would like to revisit is merely the section on configurability, where the goal is to be able to deploy "All of PEP 476 *except* the change in default certificate verification behaviour". The approach in the PEP works for folks deploying upstream Python directly, and I *thought* it would work for the redistributor case as well. It's the latter point I was wrong about. This is a level of consideration of their needs that folks are willing to pay for, but it's also an expensive one to provide, so it doesn't make sense for upstream to provide it for free. Rather, I am asking the upstream development community to work with commercial redistributors to come to an accommodation that actually meets end users upgrade needs, rather than leaving them stuck on a legacy Python version with no viable path forward to more secure infrastructure. (Telling end users "just upgrade anyway" when complex systems and large scale deployments are involved doesn't work - this is why Microsoft ended up having to support Windows XP for 12 years) I thought proposing a useful new feature for Python 3.5 and then proposing a subsequent backport would be the easiest path forward, but I now suspect a PEP specifically targeting an improved network security transition plan for the benefit of folks managing infrastructure upgrades in the 2.7.x series may be a better option. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 17:57:38 2015 From: report at bugs.python.org (Tom Tanner) Date: Sun, 05 Apr 2015 15:57:38 +0000 Subject: [issue21114] wsgiref.simple_server doesn't handle multi-line headers correctly In-Reply-To: <1396285351.75.0.166007035179.issue21114@psf.upfronthosting.co.za> Message-ID: <1428249458.0.0.953872428504.issue21114@psf.upfronthosting.co.za> Tom Tanner added the comment: Any chance to get this into 2.7.10? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 17:58:12 2015 From: report at bugs.python.org (Tom Tanner) Date: Sun, 05 Apr 2015 15:58:12 +0000 Subject: [issue21718] sqlite3 cursor.description seems to rely on incomplete statement parsing for detection In-Reply-To: <1402492269.75.0.610341668437.issue21718@psf.upfronthosting.co.za> Message-ID: <1428249492.1.0.875621214134.issue21718@psf.upfronthosting.co.za> Tom Tanner added the comment: Are you going to merge it into 2.7.10? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 18:00:10 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 05 Apr 2015 16:00:10 +0000 Subject: [issue19511] lib2to3 Grammar file is no longer a Python 3 superset In-Reply-To: <1383742611.34.0.802324885429.issue19511@psf.upfronthosting.co.za> Message-ID: <1428249610.55.0.0964751085746.issue19511@psf.upfronthosting.co.za> Gregory P. Smith added the comment: This was fixed in 3.4.1: https://hg.python.org/cpython/log/094615256a54/Lib/lib2to3/Grammar.txt i'm leaving this open to update the devguide. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 18:28:03 2015 From: report at bugs.python.org (Donald Stufft) Date: Sun, 05 Apr 2015 16:28:03 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428251283.38.0.373458677455.issue23857@psf.upfronthosting.co.za> Donald Stufft added the comment: > Now, I knew how to fix this, but the solution was not > an obvious one. I had to use truss to figure out where OpenSSL > was looking for certificates and the added the Mozilla cert > bundle from our egenix-pyopenssl package to make things work > again. You also could have passed the --cert flag to pip to tel pip specifically where to look for them (also available via environment variable and config file) though I'm guessing it wasn't actually pip itself that had a problem because we ship our own CA file and we don't actually rely on the stdlib to have validated TLS. Unless you were using an old pip I guess. > Again: Please let the users decide what level of security they > want to apply. We can point users to solutions, but in the end > have to respect their own decisions. Note that staying with > Python 2.7.8 is a much worse approach than disabling the checks. Sure, and nobody has ever advocated to make it impossible to disable the TLS verification. For me it's entirely about the scope of the setting. I don't think that a Python wide setting is the right scope. That's a knob that has an extremely large scope of which end users are most likely not going to be completely aware of the total impact of adjusting that knob. This isn't even something that they could reasonably audit their system with _today_ and then say "OK I've looked at everything that uses Python and I'm happy for it not to verify" because if they every install anything else that uses Python (whether they know it uses Python or not) they have to re-evaluate that decision they made all over again, but with no indicator that they need to do that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 19:42:34 2015 From: report at bugs.python.org (Cyd Haselton) Date: Sun, 05 Apr 2015 17:42:34 +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: <1428255754.61.0.979819208689.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: >From previous post: ********************** How does this sound? * I'll clone the fork of the 3.4 branch I made in github, build and patch. * Ryan will (as best as he can) grab said patches, regenerate them for the bug tracker or forward port them to 3.5 (in github? to Mercurial) ********************** For some reason I was thinking that the 3.4 branch I cloned was a dev branch. I'll start again with a download of 3.5 dev. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 21:26:24 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sun, 05 Apr 2015 19:26:24 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428251283.38.0.373458677455.issue23857@psf.upfronthosting.co.za> Message-ID: <55218C5F.8000409@egenix.com> Marc-Andre Lemburg added the comment: On 05.04.2015 18:28, Donald Stufft wrote: > > Donald Stufft added the comment: > >> Now, I knew how to fix this, but the solution was not >> an obvious one. I had to use truss to figure out where OpenSSL >> was looking for certificates and the added the Mozilla cert >> bundle from our egenix-pyopenssl package to make things work >> again. > > You also could have passed the --cert flag to pip to tel pip specifically where > to look for them (also available via environment variable and config file) > though I'm guessing it wasn't actually pip itself that had a problem because > we ship our own CA file and we don't actually rely on the stdlib to have > validated TLS. Unless you were using an old pip I guess. I was working on a Zope installation using zc.buildout, so basically setuptools, and yes, it was an older version as well. But this is only an example of an application not working anymore because the system's OpenSSL could not verify certificates. In this case, no root CA certs were available. On older systems with proper root CA certs, it's likely that the newer CA certs needed to verify the PyPI certificates are not installed... and yes: those system do exist and are in active use, simply because they cannot be upgraded for other reasons :-) >> Again: Please let the users decide what level of security they >> want to apply. We can point users to solutions, but in the end >> have to respect their own decisions. Note that staying with >> Python 2.7.8 is a much worse approach than disabling the checks. > > Sure, and nobody has ever advocated to make it impossible to disable the TLS > verification. For me it's entirely about the scope of the setting. I don't > think that a Python wide setting is the right scope. That's a knob that has > an extremely large scope of which end users are most likely not going to be > completely aware of the total impact of adjusting that knob. This isn't even > something that they could reasonably audit their system with _today_ and then > say "OK I've looked at everything that uses Python and I'm happy for it not to > verify" because if they every install anything else that uses Python (whether > they know it uses Python or not) they have to re-evaluate that decision they > made all over again, but with no indicator that they need to do that. I'd be fine with having a knob that says: don't check the certificates but warn me about instances where the certificates are not checked (using the warning framework). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 21:36:19 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 05 Apr 2015 19:36:19 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <55218C5F.8000409@egenix.com> Message-ID: <55218EAF.6060205@free.fr> Antoine Pitrou added the comment: Le 05/04/2015 21:26, Marc-Andre Lemburg a ?crit : > > But this is only an example of an application not working anymore > because the system's OpenSSL could not verify certificates. > In this case, no root CA certs were available. On older systems > with proper root CA certs, it's likely that the newer CA certs > needed to verify the PyPI certificates are not installed... > and yes: those system do exist and are in active use, simply because > they cannot be upgraded for other reasons :-) Let's sum it up: - the machine can't be upgraded, but you are upgrading Python by hand (hand-compiled?) - OpenSSL is installed but there are no root CA certs (?!) - the machine probably isn't ever doing a single verified HTTPS access, for the previous reason, and nobody cares about it - you want to be able to use unauthenticated HTTPS to download and install software from the Internet And, since this is an AIX machine, I'm presuming this isn't a hobbyist's setup, but an enterprise system with paid-for support and licenses, right? And you want the python-dev community to care for that broken situation by bearing the cost of additional maintenance and security risk in implementing the new configuration options? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 21:45:51 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sun, 05 Apr 2015 19:45:51 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <55218EAF.6060205@free.fr> Message-ID: <552190EE.1080102@egenix.com> Marc-Andre Lemburg added the comment: On 05.04.2015 21:36, Antoine Pitrou wrote: > > And you want the python-dev community to care for that broken > situation by bearing the cost of additional maintenance and security > risk in implementing the new configuration options? No, I want to be able to easily disable the newly added checks in 2.7.9+ to get systems such as these behave the same as with 2.7.8, since without this option, people using these system are going to be forced to stick with buggy 2.7.8 systems. It's rather unusual that a patch level release completely breaks an existing setup. I understand why this was done, but in the light of backwards compatibility, it's a huge issue for people. PS: Python installations in Zope systems are often custom installs, not system installs of Python. The AIX system I'm referencing here still has Python 2.6 as system Python version. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 21:48:44 2015 From: report at bugs.python.org (Donald Stufft) Date: Sun, 05 Apr 2015 19:48:44 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428263324.51.0.759551760573.issue23857@psf.upfronthosting.co.za> Donald Stufft added the comment: > No, I want to be able to easily disable the newly added > checks in 2.7.9+ to get systems such as these behave the > same as with 2.7.8, since without this option, people > using these system are going to be forced to stick with > buggy 2.7.8 systems. Why is the monkeypatch in sitecustomize.py unacceptable? I understand why it's unacceptable to Nick and rkuska, they are a vendor and they don't want to write sitecustomize.py when the machine operator may want to use that file, however you're the machine operator in this case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 22:03:42 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 05 Apr 2015 20:03:42 +0000 Subject: [issue23871] turning itertools.{repeat, count} into indexable iterables In-Reply-To: <1428188343.49.1.91705834608e-05.issue23871@psf.upfronthosting.co.za> Message-ID: <1428264222.7.0.966647612035.issue23871@psf.upfronthosting.co.za> R. David Murray added the comment: I agree with Antti. If Raymond disagrees he can reopen :) (There is a reason it is called *iter*tools. As Antti says, range is documented as being a *sequence* type.) ---------- nosy: +r.david.murray resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 22:06:26 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sun, 05 Apr 2015 20:06:26 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428263324.51.0.759551760573.issue23857@psf.upfronthosting.co.za> Message-ID: <552195C0.3050207@egenix.com> Marc-Andre Lemburg added the comment: On 05.04.2015 21:48, Donald Stufft wrote: > > Donald Stufft added the comment: > >> No, I want to be able to easily disable the newly added >> checks in 2.7.9+ to get systems such as these behave the >> same as with 2.7.8, since without this option, people >> using these system are going to be forced to stick with >> buggy 2.7.8 systems. > > Why is the monkeypatch in sitecustomize.py unacceptable? I understand why it's > unacceptable to Nick and rkuska, they are a vendor and they don't want to write > sitecustomize.py when the machine operator may want to use that file, however > you're the machine operator in this case. I don't consider monkey patching a proper way to configure a Python installation. I could simply patch the Python installation directly, but this is just me. I'm talking about sys admins out there who don't know enough about Python to be able to patch Python or write a sitecutomize.py which uses monkey patching to fix the issue. I also cannot recommend to our customers to monkey patch Python just to get it running again. This is not what folks expect from a production quality system :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 22:33:50 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 05 Apr 2015 20:33:50 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428266030.53.0.48177218073.issue23857@psf.upfronthosting.co.za> R. David Murray added the comment: Really these arguments make it sound like 2.7.9 never should have happened. Given that it did, Nick has not addressed the question of why the vendors maintaining this simple patch (given that it addresses what he sees as their need) is not a viable option. I do *not* see the proposed patch as an acceptable "feature" for 3.5, and I think I'm far from alone, so I suspect that it is a non-starter for following Nick's proposed "path". Could there be a related feature that would be both acceptable and worthwhile? Yes. But someone will have to figure out what it is and propose it :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 22:39:22 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 05 Apr 2015 20:39:22 +0000 Subject: [issue21718] sqlite3 cursor.description seems to rely on incomplete statement parsing for detection In-Reply-To: <1402492269.75.0.610341668437.issue21718@psf.upfronthosting.co.za> Message-ID: <1428266362.01.0.949277359604.issue21718@psf.upfronthosting.co.za> R. David Murray added the comment: It looks to me like a patch that could be merged as a bug fix. ---------- stage: -> commit review versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 22:49:56 2015 From: report at bugs.python.org (Donald Stufft) Date: Sun, 05 Apr 2015 20:49:56 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428266996.97.0.837153991354.issue23857@psf.upfronthosting.co.za> Donald Stufft added the comment: > I don't consider monkey patching a proper way to configure a Python > installation. The point is that that TLS validation on/off isn't conceptually a Python level configuration option, that's going to be a per application configuration option. The monkeypatching is simply an escape hatch to give people time to update their applications (or pressure whoever wrote the application) to support the configuration option that really belongs at the application level. It *should* feel improper because the entire concept of a Python level on/off switch isn't proper and making it feel more proper by adding an official API or config file for doing it is only giving footguns out to people. ---------- _______________________________________ Python tracker _______________________________________ From mal at egenix.com Sun Apr 5 23:15:23 2015 From: mal at egenix.com (M.-A. Lemburg) Date: Sun, 05 Apr 2015 23:15:23 +0200 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428266996.97.0.837153991354.issue23857@psf.upfronthosting.co.za> References: <1428266996.97.0.837153991354.issue23857@psf.upfronthosting.co.za> Message-ID: <5521A5EB.1050705@egenix.com> On 05.04.2015 22:49, Donald Stufft wrote: > > Donald Stufft added the comment: > >> I don't consider monkey patching a proper way to configure a Python >> installation. > > The point is that that TLS validation on/off isn't conceptually a Python level > configuration option, that's going to be a per application configuration > option. The monkeypatching is simply an escape hatch to give people time to > update their applications (or pressure whoever wrote the application) to > support the configuration option that really belongs at the application > level. It *should* feel improper because the entire concept of a Python level > on/off switch isn't proper and making it feel more proper by adding an official > API or config file for doing it is only giving footguns out to people. People upgrading to a new patch level Python release will *not* expect or want to have to change their application to adapt to it. That's simply not within the scope of a patch level release. Furthermore, old applications such as Zope will (most likely) not receive such updates. Please accept that there's a whole universe out there where people don't continually update their applications, but still want to benefit from bug fixes to their underlying libs and tools. The world is full of legacy systems, regardless of whether we like it or not. There's no good or bad about this. It's just a fact of life. What I'm arguing for is a way for admins of such older systems to be able to receive bug fixes for Python 2.7.x *without* having to change the applications. Using an environment setting and adding that to the application's user account settings is an easy way to resolve the issue in situations where other options are not feasible or simply not deemed needed (Zope has been working without any egg verification for years). -- Marc-Andre Lemburg eGenix.com From report at bugs.python.org Sun Apr 5 23:15:24 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sun, 05 Apr 2015 21:15:24 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428266996.97.0.837153991354.issue23857@psf.upfronthosting.co.za> Message-ID: <5521A5EB.1050705@egenix.com> Marc-Andre Lemburg added the comment: On 05.04.2015 22:49, Donald Stufft wrote: > > Donald Stufft added the comment: > >> I don't consider monkey patching a proper way to configure a Python >> installation. > > The point is that that TLS validation on/off isn't conceptually a Python level > configuration option, that's going to be a per application configuration > option. The monkeypatching is simply an escape hatch to give people time to > update their applications (or pressure whoever wrote the application) to > support the configuration option that really belongs at the application > level. It *should* feel improper because the entire concept of a Python level > on/off switch isn't proper and making it feel more proper by adding an official > API or config file for doing it is only giving footguns out to people. People upgrading to a new patch level Python release will *not* expect or want to have to change their application to adapt to it. That's simply not within the scope of a patch level release. Furthermore, old applications such as Zope will (most likely) not receive such updates. Please accept that there's a whole universe out there where people don't continually update their applications, but still want to benefit from bug fixes to their underlying libs and tools. The world is full of legacy systems, regardless of whether we like it or not. There's no good or bad about this. It's just a fact of life. What I'm arguing for is a way for admins of such older systems to be able to receive bug fixes for Python 2.7.x *without* having to change the applications. Using an environment setting and adding that to the application's user account settings is an easy way to resolve the issue in situations where other options are not feasible or simply not deemed needed (Zope has been working without any egg verification for years). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 23:25:30 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 05 Apr 2015 21:25:30 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428269130.28.0.315027459375.issue23857@psf.upfronthosting.co.za> R. David Murray added the comment: MAL: then what you are arguing for is that the SSL changes in 2.7.9 should not have happened. Which is an argument that Antoine and I at least are sympathetic to.... :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 23:39:50 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 05 Apr 2015 21:39:50 +0000 Subject: [issue18704] IDLE: Integrate external code analysis tools In-Reply-To: <1376173040.43.0.790205199961.issue18704@psf.upfronthosting.co.za> Message-ID: <1428269990.0.0.937199969076.issue18704@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- superseder: -> IDLE: Ability to run 3rd party code checkers _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 5 23:58:07 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sun, 05 Apr 2015 21:58:07 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428269130.28.0.315027459375.issue23857@psf.upfronthosting.co.za> Message-ID: <5521AFEF.4020904@egenix.com> Marc-Andre Lemburg added the comment: On 05.04.2015 23:25, R. David Murray wrote: > > MAL: then what you are arguing for is that the SSL changes in 2.7.9 should not have happened. Which is an argument that Antoine and I at least are sympathetic to.... :) I think those changes were probably fine for many Python users, just not all of them. I'm only arguing to get some easy way to disable these enforced checks which doesn't require patching Python. (So I guess I'm kind of standing in the middle between Antoine and you on one side and Donald on the other side ;-)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 00:43:00 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 05 Apr 2015 22:43:00 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428273780.66.0.768593619856.issue23857@psf.upfronthosting.co.za> R. David Murray added the comment: Actually I was in favor of an environment variable (or something like that) from the start, because it could be set per-process (making it as close to per-application as we can get from upstream). But a global config file I think is a bad idea (at least in the form so far suggested). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 01:28:23 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 05 Apr 2015 23:28:23 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <20150405232820.29523.49138@psf.io> Roundup Robot added the comment: New changeset eba80326ba53 by R David Murray in branch 'default': #3566: Clean up handling of remote server disconnects. https://hg.python.org/cpython/rev/eba80326ba53 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 01:34:38 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 05 Apr 2015 23:34:38 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1428276878.07.0.686464062122.issue3566@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks, Martin and Demian. I tweaked the patch slightly before commit, so I've uploaded the diff. After thinking about it I decided that it does indeed make sense that the new exception subclass both ConnectionResetError and BadStatusLine, exactly because it *isn't* a pure ConnectionError, it is a synthetic one based on getting a '' response when we are expecting a status line. So I tweaked the language to not mention backward compatibility. I also tweaked the language of the docs, comments and error message to make it clear that the issue is that the server closed the connection (I understand why you changed it to 'shut down', but I think 'the server closed the connection' is both precise enough and more intuitive). If you have any issues with the changes I made, let me know. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed Added file: http://bugs.python.org/file38839/RemoteDisconnected.v6.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 03:30:17 2015 From: report at bugs.python.org (Cyd Haselton) Date: Mon, 06 Apr 2015 01:30:17 +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: <1428283817.6.0.0984894797893.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: issue_20306.patch won't install; attempting to do so yields the following: patching file configure.ac Hunk 56 FAILED 4944/4944. AC_MSG_RESULT($ENSUREPIP) AC_SUBST(ENSUREPIP) +AC_CHECK_MEMBER([struct passwd.pw_gecos], + [AC_DEFINE(HAVE_PASSWD_GECOS_FIELD, 1, [Define if defines field passwd.pw_gecos])], + [], + [[#include ]]) + # generate output files AC_CONFIG_FILES(Makefile.pre Modules/Setup.config Misc/python.pc Misc/python-config.sh) AC_CONFIG_FILES([Modules/ld_so_aix], [chmod +x Modules/ld_so_aix]) For the time being I'll just use --without-ensurepip when configuring. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 04:10:36 2015 From: report at bugs.python.org (Cyd Haselton) Date: Mon, 06 Apr 2015 02:10:36 +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: <1428286236.84.0.881265967887.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Latest error: gcc --sysroot=/usr/gcc-4.9.2/sysroot -c -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I. -IInclude -I./Include -DPy_BUILD_CORE -o Objects/unicodeobject.o Objects/unicodeobject.c Objects/unicodeobject.c:45:23: fatal error: androidfn.h: No such file or directory #include "androidfn.h" ^ compilation terminated. make: *** [Objects/unicodeobject.o] Error 1 No idea what androidfn.h is, but will troubleshoot in the AM ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 06:48:01 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 06 Apr 2015 04:48:01 +0000 Subject: [issue18553] os.isatty() is not Unix only In-Reply-To: <1374752779.81.0.230915084667.issue18553@psf.upfronthosting.co.za> Message-ID: <1428295681.32.0.541599429182.issue18553@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 07:37:58 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 06 Apr 2015 05:37:58 +0000 Subject: [issue23870] pprint collections classes In-Reply-To: <1428167976.78.0.301380656754.issue23870@psf.upfronthosting.co.za> Message-ID: <1428298678.82.0.784680944834.issue23870@psf.upfronthosting.co.za> Raymond Hettinger added the comment: This seems like a reasonable intermediate step. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 10:13:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Apr 2015 08:13:10 +0000 Subject: [issue20175] Derby #6: Convert 50 sites to Argument Clinic across 8 files In-Reply-To: <1389138499.96.0.517173661563.issue20175@psf.upfronthosting.co.za> Message-ID: <1428307990.09.0.303746902269.issue20175@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch converts the _io module to Argument Clinic. Total 86 methods are converted. ---------- keywords: +patch nosy: +benjamin.peterson, pitrou, serhiy.storchaka, stutzbach stage: needs patch -> patch review Added file: http://bugs.python.org/file38840/io_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 12:24:40 2015 From: report at bugs.python.org (Alex Shkop) Date: Mon, 06 Apr 2015 10:24:40 +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: <1428315880.01.0.761646239623.issue18383@psf.upfronthosting.co.za> Alex Shkop added the comment: When caller adds duplicate filter maybe we should promote his filter to the beginning of filters list? This feels more correct to me. So if user adds duplicate filter everything will work as if we added it. ---------- Added file: http://bugs.python.org/file38841/issue18383_remove_dups_and_test.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 13:29:43 2015 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 06 Apr 2015 11:29:43 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428319783.85.0.398793719784.issue23857@psf.upfronthosting.co.za> Nick Coghlan added the comment: The change in 2.7.9 upstream was *absolutely* the right thing for the upstream CPython community to do. The problem was real, it needed to be fixed, and the community fixed it in a way that works just fine for folks in the earlier parts of the technology adoption curve. Change management for the folks in the latter half of the technology adoption curve is a key part of what commercial redistributors get paid for. Delaying PEP 476 while we figured out the details of how that was going to work would have been a bad plan from a community perspective, so I took a speculative shot at providing a very simple solution for the redistributor case and unfortunately missed the target. The reason I still want to negotiate the technical details of the feature upstream (despite missing the mark in PEP 476 itself) is so that all of us that need this functionality can provide the *same* behaviour to our respective customers, rather than having Red Hat do one thing, Suse another, Canonical a third, and then cross-platform Python redistributors like eGenix and ActiveState also needing to figure out their own scheme. It's akin to the problem faced by Linux redistributors that independently provide stable ABI guarantees, but also aim to collaborate on backporting fixes to the *same* stable ABI to reduce duplicated effort: http://crunchtools.com/deep-dive-rebase-vs-backport/#Brief_History So while this isn't a feature upstream itself needs, it's one potentially needed by multiple *downstreams*, so in my view it makes sense for us to work with upstream to come up with the "one obvious way" for redistributors to handle the problem (now that we know that my initial attempt at providing such a way doesn't work in practice). Probably the closest precedents to this idea are PEP 394 (regarding management of the unqualified python symlink) and the section with recommendations for downstream redistributors in PEP 453 (bundling pip). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 13:46:35 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Apr 2015 11:46:35 +0000 Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za> Message-ID: <1428320795.18.0.936661235678.issue20179@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Proposed patch converts the _ssl module to Argument Clinic. Total 39 methods converted. ---------- keywords: +needs review nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou, serhiy.storchaka stage: needs patch -> patch review Added file: http://bugs.python.org/file38842/ssl_clinic.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 13:47:56 2015 From: report at bugs.python.org (Alex Gaynor) Date: Mon, 06 Apr 2015 11:47:56 +0000 Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za> Message-ID: <1428320876.86.0.360955344033.issue20179@psf.upfronthosting.co.za> Alex Gaynor added the comment: I'm concerned the _ssl changes will make security backports significantly more difficult. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 14:01:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Apr 2015 12:01:52 +0000 Subject: [issue23875] Incorrect argument parsing in _ssl Message-ID: <1428321712.11.0.166628574781.issue23875@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Argument parsing code for functions _ssl.enum_certificates() and _ssl.enum_crls() look not correct. if (!PyArg_ParseTupleAndKeywords(args, kwds, "s|s:enum_certificates", kwlist, &store_name)) { return NULL; } The format contains codes for two string arguments. But only one address (&store_name) is passed. And kwlist contains only one member, "store_name". These functions are provided only on Windows, so I can't check what happen if call them with two string arguments. May be crash or memory corruption. ---------- components: Extension Modules messages: 240151 nosy: alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou, serhiy.storchaka priority: normal severity: normal status: open title: Incorrect argument parsing in _ssl type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 14:04:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Apr 2015 12:04:59 +0000 Subject: [issue20179] Derby #10: Convert 50 sites to Argument Clinic across 4 files In-Reply-To: <1389140120.63.0.492860390436.issue20179@psf.upfronthosting.co.za> Message-ID: <1428321899.36.0.163733754462.issue20179@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: _ssl.enum_certificates() and _ssl.enum_crls() is not converted because their parsing code look incorrect (issue23875). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 14:41:15 2015 From: report at bugs.python.org (Jeffrey Armstrong) Date: Mon, 06 Apr 2015 12:41:15 +0000 Subject: [issue23876] Fix mkdir() call for Watcom compilers on UNIX-like platforms Message-ID: <1428324075.5.0.672514551353.issue23876@psf.upfronthosting.co.za> New submission from Jeffrey Armstrong: Within Modules/posixmodule.c:4914 (in 3.5.0a3), the preprocessor checks for compiler macros as such: #if ( defined(__WATCOMC__) || defined(PYCC_VACPP) ) && !defined(__QNX__) result = mkdir(path->narrow); #else result = mkdir(path->narrow, mode); #endif The purpose of the code was to detect if we're compiling using Watcom, but not on QNX, or VisualAge as our compiler, where mkdir() wouldn't accept a mode. However, Watcom supports Linux as well and properly implements the mode argument, causing the compilation to fail. The proper check, rather than looking for "!defined(__QNX__)" would be "!defined(__UNIX__)," which would allow the code to properly compile using Watcom on either Linux or QNX: #if ( defined(__WATCOMC__) || defined(PYCC_VACPP) ) && !defined(__UNIX__) result = mkdir(path->narrow); #else result = mkdir(path->narrow, mode); #endif FYI, in Watcom, the __UNIX__ macro is defined on both Linux and QNX, so this change will not break code for people who are still using Watcom to build Python for QNX (which is probably nobody at all). There are two other places where the __QNX__ macro should be replaced in Modules/posixmodule.c, and the attached patch fixes both. ---------- components: Interpreter Core files: watcom_qnx_to_unix-3.5.0a3.patch keywords: patch messages: 240153 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: Fix mkdir() call for Watcom compilers on UNIX-like platforms type: compile error versions: Python 3.5 Added file: http://bugs.python.org/file38843/watcom_qnx_to_unix-3.5.0a3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 14:48:51 2015 From: report at bugs.python.org (Jeffrey Armstrong) Date: Mon, 06 Apr 2015 12:48:51 +0000 Subject: [issue23877] Build fails when threads are disabled during configure step Message-ID: <1428324531.94.0.57917377486.issue23877@psf.upfronthosting.co.za> New submission from Jeffrey Armstrong: If threads are disabled, either via --disable-threads or using a compiler/standard library that doesn't support threads, the build will fail when linking the Python interpreter because the following is undefined: PyGILState_GetThisThreadState The error is caused by a change since 3.5.0a1 that uses a call to this function in Python/pylifecycle.c:1303 without first checking if the WITH_THREADS macro is defined. If WITH_THREADS is undefined, the function PyGILState_GetThisThreadState is not built. I've attached a simple patch correcting the issue, but it should be trivial to add a simple macro check around the call. ---------- components: Interpreter Core files: pylifecycle-threads-3.5.0a3.patch keywords: patch messages: 240154 nosy: Jeffrey.Armstrong priority: normal severity: normal status: open title: Build fails when threads are disabled during configure step type: compile error versions: Python 3.5 Added file: http://bugs.python.org/file38844/pylifecycle-threads-3.5.0a3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 15:59:32 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Apr 2015 13:59:32 +0000 Subject: [issue23877] Build fails when threads are disabled during configure step In-Reply-To: <1428324531.94.0.57917377486.issue23877@psf.upfronthosting.co.za> Message-ID: <20150406135929.29543.54990@psf.io> Roundup Robot added the comment: New changeset 29f51c4ae11a by Benjamin Peterson in branch 'default': fix building without threads (closes #23877) https://hg.python.org/cpython/rev/29f51c4ae11a ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 17:36:13 2015 From: report at bugs.python.org (Neale Ferguson) Date: Mon, 06 Apr 2015 15:36:13 +0000 Subject: [issue23830] Add AF_IUCV support to sockets In-Reply-To: <1427828484.47.0.0998681334057.issue23830@psf.upfronthosting.co.za> Message-ID: <1428334573.69.0.493935656985.issue23830@psf.upfronthosting.co.za> Neale Ferguson added the comment: Corrected declaration of args to PyArg_ParseTuple() from int to Py_ssize_t. ---------- Added file: http://bugs.python.org/file38845/af_iucv.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 18:19:23 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Mon, 06 Apr 2015 16:19:23 +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: <1428337163.18.0.0139997957022.issue23496@psf.upfronthosting.co.za> Ryan Gonzalez added the comment: Ah, crud. androidfn.h was a header I added but forgot to put the patch for. I just attached the patch for that now. The commit I based the patches on was by Alexander Belopolsky and was named "merge". Committed on February 28. ---------- Added file: http://bugs.python.org/file38846/androidfn.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 18:34:23 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 06 Apr 2015 16:34:23 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428319783.85.0.398793719784.issue23857@psf.upfronthosting.co.za> Message-ID: <5522B58B.3070108@free.fr> Antoine Pitrou added the comment: Le 06/04/2015 13:29, Nick Coghlan a ?crit : > > So while this isn't a feature upstream itself needs, it's one potentially needed by multiple *downstreams*, so in my view it makes sense for us to work with upstream to come up with the "one obvious way" for redistributors to handle the problem (now that we know that my initial attempt at providing such a way doesn't work in practice). So would it be possible for the actual implementation to be done outside of CPython? (in a dedicated fork, for example) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 18:44:43 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 06 Apr 2015 16:44:43 +0000 Subject: [issue19817] tracemalloc add a memory limit feature In-Reply-To: <1385575392.84.0.858805099832.issue19817@psf.upfronthosting.co.za> Message-ID: <1428338683.63.0.040087417156.issue19817@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 18:58:35 2015 From: report at bugs.python.org (Bill Parker) Date: Mon, 06 Apr 2015 16:58:35 +0000 Subject: [issue23855] Missing Sanity Check for malloc() in PC/_msi.c In-Reply-To: <1428012703.71.0.811050257631.issue23855@psf.upfronthosting.co.za> Message-ID: <1428339515.45.0.911525412797.issue23855@psf.upfronthosting.co.za> Bill Parker added the comment: In directory 'PC', file '_msi.c', I found another call to malloc() which was not checked for a return value of NULL which would indicate failure. The new patch file is below: --- _msi.c.orig 2015-04-02 15:01:02.882326352 -0700 +++ _msi.c 2015-04-04 16:36:56.919605881 -0700 @@ -324,6 +324,10 @@ code = MsiRecordGetInteger(err, 1); /* XXX code */ if (MsiFormatRecord(0, err, res, &size) == ERROR_MORE_DATA) { res = malloc(size+1); + if (res == NULL) /* malloc() failed, out of memory... */ + PyErr_SetString(MSIError, "out of memory"); + return NULL; + } MsiFormatRecord(0, err, res, &size); res[size]='\0'; } @@ -547,6 +551,10 @@ &fval, sval, &ssize); if (status == ERROR_MORE_DATA) { sval = malloc(ssize); + if (sval == NULL) { /* malloc() failed, out of memory... */ + PyErr_SetString(MSIError, "out of memory"); + return NULL; + } status = MsiSummaryInfoGetProperty(si->h, field, &type, &ival, &fval, sval, &ssize); } ---------- Added file: http://bugs.python.org/file38847/_msi.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 19:00:27 2015 From: report at bugs.python.org (Bill Parker) Date: Mon, 06 Apr 2015 17:00:27 +0000 Subject: [issue23878] Missing sanity checks for various C library function calls... Message-ID: <1428339627.31.0.628073381935.issue23878@psf.upfronthosting.co.za> New submission from Bill Parker: Hello All, In reviewing code for Python-3.4.3 in directory 'Modules/_ctypes/libffi/src/arm', file 'ffi.c', I found a pair of calls to calloc() which do not test for a return value of NULL, indicating failure. The patch file below corrects this issue: --- ffi.c.orig 2015-04-04 15:43:19.662709073 -0700 +++ ffi.c 2015-04-04 15:51:27.142665269 -0700 @@ -629,12 +629,21 @@ /* We have valid trampoline and config pages */ table = calloc (1, sizeof(ffi_trampoline_table)); + if (table == NULL) { /* oops, calloc() failed, now what??? */ + fprintf(stderr, "vm calloc() failure: %d at %s:%d\n", kt, __FILE__, __LINE__); + return NULL; /* go home??? */ + } table->free_count = FFI_TRAMPOLINE_COUNT; table->config_page = config_page; table->trampoline_page = trampoline_page; /* Create and initialize the free list */ table->free_list_pool = calloc(FFI_TRAMPOLINE_COUNT, sizeof(ffi_trampoline_table_entry)); + if (table->free_list_pool == NULL) { /* oops, calloc() failed, now what */ + fprintf(stderr, "vm calloc() failure: %d at %s:%d\n", kt, __FILE__, __LINE__); + free(table); /* free table (from previos calloc() call) */ + return NULL; /* go home??? * + } uint16_t i; for (i = 0; i < table->free_count; i++) { In directory 'Modules', file 'getpath.c', I found a call to fseek() which is not checked for a return value < 0, indicating failure. The patch file below corrects this issue: --- getpath.c.orig 2015-04-04 16:07:25.540472702 -0700 +++ getpath.c 2015-04-04 16:09:30.988416490 -0700 @@ -265,7 +265,9 @@ int result = 0; /* meaning not found */ char buffer[MAXPATHLEN*2+1]; /* allow extra for key, '=', etc. */ - fseek(env_file, 0, SEEK_SET); + if (fseek(env_file, 0, SEEK_SET) < 0) + return result; + while (!feof(env_file)) { char * p = fgets(buffer, MAXPATHLEN*2, env_file); wchar_t tmpbuffer[MAXPATHLEN*2+1]; I am attaching the patch file(s) to this bug report... Bill Parker (wp02855 at gmail dot com) ---------- components: Interpreter Core files: getpath.c.patch keywords: patch messages: 240160 nosy: dogbert2 priority: normal severity: normal status: open title: Missing sanity checks for various C library function calls... type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file38848/getpath.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 19:01:00 2015 From: report at bugs.python.org (Bill Parker) Date: Mon, 06 Apr 2015 17:01:00 +0000 Subject: [issue23878] Missing sanity checks for various C library function calls... In-Reply-To: <1428339627.31.0.628073381935.issue23878@psf.upfronthosting.co.za> Message-ID: <1428339660.15.0.734797954012.issue23878@psf.upfronthosting.co.za> Bill Parker added the comment: Addition of file 'ffi.c.patch'... ---------- Added file: http://bugs.python.org/file38849/ffi.c.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 19:05:20 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Mon, 06 Apr 2015 17:05:20 +0000 Subject: [issue23875] Incorrect argument parsing in _ssl In-Reply-To: <1428321712.11.0.166628574781.issue23875@psf.upfronthosting.co.za> Message-ID: <1428339920.24.0.039850738961.issue23875@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Good catch. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 19:06:45 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Apr 2015 17:06:45 +0000 Subject: [issue23875] Incorrect argument parsing in _ssl In-Reply-To: <1428321712.11.0.166628574781.issue23875@psf.upfronthosting.co.za> Message-ID: <20150406170634.16505.28175@psf.io> Roundup Robot added the comment: New changeset e0ba8d3bed7e by Benjamin Peterson in branch '3.4': remove extra arguments in arg parsing format codes (closes #23875) https://hg.python.org/cpython/rev/e0ba8d3bed7e New changeset 5f27e13faae2 by Benjamin Peterson in branch '2.7': remove extra arguments in arg parsing format codes (closes #23875) https://hg.python.org/cpython/rev/5f27e13faae2 New changeset c9b9fb86d3fa by Benjamin Peterson in branch 'default': merge 3.4 (#23875) https://hg.python.org/cpython/rev/c9b9fb86d3fa ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 19:13:10 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 06 Apr 2015 17:13:10 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message_on_Wine?= In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> Message-ID: <1428340390.19.0.118354587737.issue22977@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: Unconditional 'import ctypes' in Lib/test/test_exceptions.py was not yet deleted. ---------- nosy: +Arfrever resolution: fixed -> stage: resolved -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 19:28:15 2015 From: report at bugs.python.org (Neale Ferguson) Date: Mon, 06 Apr 2015 17:28:15 +0000 Subject: [issue23830] Add AF_IUCV support to sockets In-Reply-To: <1427828484.47.0.0998681334057.issue23830@psf.upfronthosting.co.za> Message-ID: <1428341295.48.0.693983121614.issue23830@psf.upfronthosting.co.za> Neale Ferguson added the comment: Attaching a patch based off 3.5.0a3. Note, for Py_ssize_t I had to add: #ifdef PY_SSIZE_T_CLEAN Py_ssize_t lNode, lUser, lName; #else int lNode, lUser, lName; #endif As if I did not, the values I got back were garbage. Is this because of some configuration parameter I failed to use? However, the patch builds on s390x and x86_64 and the test passes on the former and is skipped on the latter. ---------- Added file: http://bugs.python.org/file38850/af_iucv.patch35 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 19:37:56 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Apr 2015 17:37:56 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message_on_Wine?= In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> Message-ID: <20150406173753.105414.90974@psf.io> Roundup Robot added the comment: New changeset 5cc0a090829a by Serhiy Storchaka in branch '3.4': Issue #22977: Remove unconditional import of ctypes. https://hg.python.org/cpython/rev/5cc0a090829a New changeset f46454229cf5 by Serhiy Storchaka in branch 'default': Issue #22977: Remove unconditional import of ctypes. https://hg.python.org/cpython/rev/f46454229cf5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 19:39:22 2015 From: report at bugs.python.org (Jeffrey Armstrong) Date: Mon, 06 Apr 2015 17:39:22 +0000 Subject: [issue23877] Build fails when threads are disabled during configure step In-Reply-To: <1428324531.94.0.57917377486.issue23877@psf.upfronthosting.co.za> Message-ID: <1428341962.73.0.988233980382.issue23877@psf.upfronthosting.co.za> Jeffrey Armstrong added the comment: Oops, I meant WITH_THREAD. Thanks for the quick fix! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 19:40:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Apr 2015 17:40:25 +0000 Subject: =?utf-8?q?=5Bissue22977=5D_Unformatted_=E2=80=9CWindows_Error_0x=25X?= =?utf-8?q?=E2=80=9D_exception_message_on_Wine?= In-Reply-To: <1417519184.51.0.0584067383509.issue22977@psf.upfronthosting.co.za> Message-ID: <1428342025.4.0.256348921047.issue22977@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks for your outsight Arfrever. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 20:36:12 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 06 Apr 2015 18:36:12 +0000 Subject: [issue23648] PEP 475 meta issue In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za> Message-ID: <1428345372.93.0.361614113629.issue23648@psf.upfronthosting.co.za> Arfrever Frehtes Taifersar Arahesis added the comment: > New changeset 66e4ef9a7467 by Victor Stinner in branch 'default': > Issue #23648: Complete the list of modified functions for the PEP 475 > https://hg.python.org/cpython/rev/66e4ef9a7467 > > + * special cases: :func:`os.close` and :func:`os.dup2` now ignore > + :py:data:`~errno.EINTR` error, the syscall is not retried (see the PEP > + for the rationale) But os.dup2 is not mentioned in PEP 475. ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 20:58:08 2015 From: report at bugs.python.org (Paul Moore) Date: Mon, 06 Apr 2015 18:58:08 +0000 Subject: [issue22343] Install bash activate script on Windows when using venv In-Reply-To: <1409948648.7.0.892236136888.issue22343@psf.upfronthosting.co.za> Message-ID: <1428346688.54.0.958207264574.issue22343@psf.upfronthosting.co.za> Paul Moore added the comment: Presumably this would just be a case of moving "activate" from venv/scripts/posix to venv/scripts/common? I don't think including csh or fish scripts on Windows is worthwhile... Attached is a patch on that basis. I didn't see any tests for which scripts were installed, so I don't think there's anything to change there. ---------- keywords: +patch nosy: +paul.moore Added file: http://bugs.python.org/file38851/activate.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 21:18:26 2015 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Mon, 06 Apr 2015 19:18:26 +0000 Subject: [issue2174] xml.sax.xmlreader does not support the InputSource protocol In-Reply-To: <1203861152.32.0.18277152276.issue2174@psf.upfronthosting.co.za> Message-ID: <1428347906.68.0.773595036904.issue2174@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: Given that this has languished this long, patching historical releases seems pointless. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 21:26:19 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 06 Apr 2015 19:26:19 +0000 Subject: [issue2174] xml.sax.xmlreader does not support the InputSource protocol In-Reply-To: <1203861152.32.0.18277152276.issue2174@psf.upfronthosting.co.za> Message-ID: <1428348379.01.0.983097710538.issue2174@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- components: +Library (Lib) -Documentation, XML resolution: -> fixed stage: -> resolved versions: +Python 3.5 -Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 21:27:13 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Mon, 06 Apr 2015 19:27:13 +0000 Subject: [issue2174] xml.sax.xmlreader does not support the InputSource protocol In-Reply-To: <1203861152.32.0.18277152276.issue2174@psf.upfronthosting.co.za> Message-ID: <1428348433.81.0.0554525752644.issue2174@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- components: +XML _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 21:28:00 2015 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Mon, 06 Apr 2015 19:28:00 +0000 Subject: [issue22721] pprint output for sets and dicts is not stable In-Reply-To: <1414170050.02.0.186594262536.issue22721@psf.upfronthosting.co.za> Message-ID: <1428348480.79.0.96734839163.issue22721@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: Sorry for the delay. pprint_safe_key.patch looks good to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 21:50:17 2015 From: report at bugs.python.org (Neale Ferguson) Date: Mon, 06 Apr 2015 19:50:17 +0000 Subject: [issue23830] Add AF_IUCV support to sockets In-Reply-To: <1427828484.47.0.0998681334057.issue23830@psf.upfronthosting.co.za> Message-ID: <1428349817.46.0.120644349512.issue23830@psf.upfronthosting.co.za> Neale Ferguson added the comment: Removed two debug statements ---------- Added file: http://bugs.python.org/file38852/af_iucv.patch35 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 21:53:08 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Apr 2015 19:53:08 +0000 Subject: [issue22721] pprint output for sets and dicts is not stable In-Reply-To: <1414170050.02.0.186594262536.issue22721@psf.upfronthosting.co.za> Message-ID: <20150406195305.16517.88483@psf.io> Roundup Robot added the comment: New changeset c8815035116b by Serhiy Storchaka in branch 'default': Issue #22721: An order of multiline pprint output of set or dict containing https://hg.python.org/cpython/rev/c8815035116b ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 21:54:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Apr 2015 19:54:20 +0000 Subject: [issue22721] pprint output for sets and dicts is not stable In-Reply-To: <1414170050.02.0.186594262536.issue22721@psf.upfronthosting.co.za> Message-ID: <1428350060.24.0.71365643185.issue22721@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your review Fred. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 22:07:30 2015 From: report at bugs.python.org (Cyd Haselton) Date: Mon, 06 Apr 2015 20:07:30 +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: <1428350850.97.0.311319663522.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Thanks Ryan, the patch worked. Latest error (when building Modules/pwdmodule.c:) ^ ./Modules/pwdmodule.c:86:2: error: stray '#' in program +#endif ^ ./Modules/pwdmodule.c:86:3: error: 'endif' undeclared (first use in this function) +#endif ^ ./Modules/pwdmodule.c:86:3: note: each undeclared identifier is reported only once for each function it appears in ./Modules/pwdmodule.c:75:21: error: expected ';' before 'sets' #define SETS(i,val) sets(v, i, val) ^ ./Modules/pwdmodule.c:87:5: note: in expansion of macro 'SETS' SETS(setIndex++, p->pw_dir); ^ ./Modules/pwdmodule.c: At top level: ./Modules/pwdmodule.c:81:0: error: unterminated #else #ifdef HAVE_PASSWD_GECOS_FIELD ^ make: *** [Modules/pwdmodule.o] Error 1 /bld/python/cpython-master $ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 22:08:37 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 06 Apr 2015 20:08:37 +0000 Subject: [issue10838] subprocess __all__ is incomplete In-Reply-To: <1294260769.5.0.0970426129524.issue10838@psf.upfronthosting.co.za> Message-ID: <1428350917.12.0.664052878596.issue10838@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For now there are three non-underscored names in subprocess that are missed in __all__: SubprocessError, TimeoutExpired, and list2cmdline. SubprocessError and TimeoutExpired are documented. ---------- nosy: +serhiy.storchaka stage: -> needs patch versions: +Python 3.5 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 22:21:58 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Mon, 06 Apr 2015 20:21:58 +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: <1428351718.57.0.713506714914.issue23496@psf.upfronthosting.co.za> Ryan Gonzalez added the comment: Remove the + at the beginning of line 87. I re-uploaded issue_20306.patch to fix that issue. ---------- Added file: http://bugs.python.org/file38853/issue_20306.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 22:22:44 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Mon, 06 Apr 2015 20:22:44 +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: <1428351764.31.0.0283806761841.issue23496@psf.upfronthosting.co.za> Changes by Ryan Gonzalez : Removed file: http://bugs.python.org/file38579/issue_20306.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 22:30:15 2015 From: report at bugs.python.org (Piotr Dobrogost) Date: Mon, 06 Apr 2015 20:30:15 +0000 Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++ Compiler for Python In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za> Message-ID: <1428352215.08.0.528157569239.issue23246@psf.upfronthosting.co.za> Changes by Piotr Dobrogost : ---------- nosy: +piotr.dobrogost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 22:34:02 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 06 Apr 2015 20:34:02 +0000 Subject: [issue23878] Missing sanity checks for various C library function calls... In-Reply-To: <1428339627.31.0.628073381935.issue23878@psf.upfronthosting.co.za> Message-ID: <1428352442.19.0.571242741632.issue23878@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the patches. For future reference, it would be better to open separate issues for problems found in different areas of Python as there may be different reviewers and dependencies. For example, libffi is a separate project, mirrored with some patches in the Python source repo. You should report your proposed arm/ffi.c patch upstream: https://sourceware.org/libffi/ ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 22:41:51 2015 From: report at bugs.python.org (Bill Parker) Date: Mon, 06 Apr 2015 20:41:51 +0000 Subject: [issue23878] Missing sanity checks for various C library function calls... In-Reply-To: <1428339627.31.0.628073381935.issue23878@psf.upfronthosting.co.za> Message-ID: <1428352911.3.0.487994217025.issue23878@psf.upfronthosting.co.za> Bill Parker added the comment: Per Ned Deily, I did send 'ffi.c.patch' to the guys upstream at: https://sourceware.org/libffi/ So hopefully they can review and fix it in the next release :)... Given that Python is spread out, perhaps when a component is selected, it could display source directories and/or files (just a suggestion here)... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 23:25:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Apr 2015 21:25:12 +0000 Subject: [issue22117] Rewrite pytime.h to work on nanoseconds In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za> Message-ID: <20150406212509.16264.70900@psf.io> Roundup Robot added the comment: New changeset af664f48b9b8 by Victor Stinner in branch 'default': Issue #22117: Fix sock_call_ex() for non-blocking socket https://hg.python.org/cpython/rev/af664f48b9b8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 23:25:12 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Apr 2015 21:25:12 +0000 Subject: [issue23853] PEP 475: handle EINTR in the ssl module In-Reply-To: <1427988624.66.0.803600947043.issue23853@psf.upfronthosting.co.za> Message-ID: <20150406212509.16264.86414@psf.io> Roundup Robot added the comment: New changeset cdc83da0b0f8 by Victor Stinner in branch 'default': Issue #23853: socket.socket.sendall() does no more reset the socket timeout https://hg.python.org/cpython/rev/cdc83da0b0f8 New changeset 5983f3fdacdb by Victor Stinner in branch 'default': Issue #23853: Methods of SSL socket don't reset the socket timeout anymore each https://hg.python.org/cpython/rev/5983f3fdacdb ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 23:25:13 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Apr 2015 21:25:13 +0000 Subject: [issue23834] socketmodule.c: add sock_call() to fix how the timeout is recomputed In-Reply-To: <1427842506.28.0.704301607448.issue23834@psf.upfronthosting.co.za> Message-ID: <20150406212509.16264.97021@psf.io> Roundup Robot added the comment: New changeset 7f54676348d3 by Victor Stinner in branch 'default': Issue #23834: Fix initial value of the socket timeout https://hg.python.org/cpython/rev/7f54676348d3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 23:30:18 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Apr 2015 21:30:18 +0000 Subject: [issue23648] PEP 475 meta issue In-Reply-To: <1426175486.94.0.959996728749.issue23648@psf.upfronthosting.co.za> Message-ID: <1428355818.23.0.124823993188.issue23648@psf.upfronthosting.co.za> STINNER Victor added the comment: > But os.dup2 is not mentioned in PEP 475. Currently, What's in Python 3.5 is more complete than the PEP 475. Another example, the PEP doesn't mention signal.sigtimedwait(). The PEP should be updated when the implementation will be finished. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 23:30:56 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Apr 2015 21:30:56 +0000 Subject: [issue23571] Raise SystemError if a function returns a result with an exception set In-Reply-To: <1425383921.42.0.283584513916.issue23571@psf.upfronthosting.co.za> Message-ID: <1428355856.06.0.326603453852.issue23571@psf.upfronthosting.co.za> STINNER Victor added the comment: I close the issue. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 23:31:29 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Apr 2015 21:31:29 +0000 Subject: [issue23570] Change "with subprocess.Popen():" (context manager) to ignore broken pipe error In-Reply-To: <1425376156.84.0.317071254674.issue23570@psf.upfronthosting.co.za> Message-ID: <1428355889.0.0.583753546817.issue23570@psf.upfronthosting.co.za> STINNER Victor added the comment: No consensus was found, I close the issue. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 23:34:37 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Apr 2015 21:34:37 +0000 Subject: [issue23566] RFE: faulthandler.register() should support file descriptors In-Reply-To: <1425340815.09.0.0278934920259.issue23566@psf.upfronthosting.co.za> Message-ID: <1428356077.7.0.12156928298.issue23566@psf.upfronthosting.co.za> STINNER Victor added the comment: > However I think the fd tests on windows is just fine to be skipped. So what's the next plan? Shall we continue to work on it or just resolve this issue? issue23566_fd_tests_v2.patch makes test_faulthandler.py a little more complex. It's maybe better to just skip tests on Windows, the code is already well tested on other platforms, and faulthandler.c doesn't contain code specific to Windows when handling file descriptors. I close the issue, thanks for your patches Wei Wu! ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 23:36:11 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Apr 2015 21:36:11 +0000 Subject: [issue23459] Linux: expose the new execveat() syscall In-Reply-To: <1423830759.75.0.255479243543.issue23459@psf.upfronthosting.co.za> Message-ID: <1428356171.73.0.104746470582.issue23459@psf.upfronthosting.co.za> STINNER Victor added the comment: I'm not more interested to work on this issue, so I just close it. I'm not convinced that there is a real need for it in Python, and it's not obvious how it should be exposed. Open a new issue or reopen this issue if you want to work the issue. ---------- resolution: -> later status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 23:41:23 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 06 Apr 2015 21:41:23 +0000 Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX) In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za> Message-ID: <20150406214120.105414.61453@psf.io> Roundup Robot added the comment: New changeset 1b509a7e3b99 by Victor Stinner in branch '2.7': Issue #23458: Remove test_os.test_urandom_fd_non_inheritable() https://hg.python.org/cpython/rev/1b509a7e3b99 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 23:41:49 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Apr 2015 21:41:49 +0000 Subject: [issue23458] [2.7] random: make the file descriptor non-inheritable (on POSIX) In-Reply-To: <1423816306.11.0.133617972899.issue23458@psf.upfronthosting.co.za> Message-ID: <1428356509.59.0.514901320041.issue23458@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 23:43:02 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Apr 2015 21:43:02 +0000 Subject: [issue22649] Use _PyUnicodeWriter in case_operation() In-Reply-To: <1413405045.21.0.992047718976.issue22649@psf.upfronthosting.co.za> Message-ID: <1428356582.91.0.665472466267.issue22649@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 23:47:34 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 06 Apr 2015 21:47:34 +0000 Subject: [issue22176] update internal libffi copy to 3.1, introducing AArch64 and POWER ELF ABIv2 In-Reply-To: <1407614032.19.0.619633143282.issue22176@psf.upfronthosting.co.za> Message-ID: <1428356854.93.0.456421006725.issue22176@psf.upfronthosting.co.za> Mark Lawrence added the comment: Can this be closed as there are ongoing discussions about libffi, particularly with respect to bring it into the Windows external build system? I've tried to find the relevant issue numbers but have failed, sorry :( ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 6 23:54:29 2015 From: report at bugs.python.org (Yassine ABOUKIR) Date: Mon, 06 Apr 2015 21:54:29 +0000 Subject: [issue23505] Urlparse insufficient validation leads to open redirect In-Reply-To: <1424736713.95.0.74935935546.issue23505@psf.upfronthosting.co.za> Message-ID: <1428357269.9.0.3374129522.issue23505@psf.upfronthosting.co.za> Yassine ABOUKIR added the comment: Any updates concerning this issue ? is it going to be fixed or at least modify the documentation in order to warn developers about this behaviour ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 01:10:31 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Apr 2015 23:10:31 +0000 Subject: [issue23853] PEP 475: handle EINTR in the ssl module In-Reply-To: <1427988624.66.0.803600947043.issue23853@psf.upfronthosting.co.za> Message-ID: <1428361831.87.0.0703300035266.issue23853@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 01:36:15 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Apr 2015 23:36:15 +0000 Subject: [issue23840] tokenize.open() leaks an open binary file on TextIOWrapper error In-Reply-To: <1427889153.26.0.649877902408.issue23840@psf.upfronthosting.co.za> Message-ID: <1428363375.48.0.452656455916.issue23840@psf.upfronthosting.co.za> STINNER Victor added the comment: tokenize.patch is wrong: you should not call buffer.close() if TextIOWrapper() was created successfully. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 01:38:35 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Apr 2015 23:38:35 +0000 Subject: [issue23752] Cleanup io.FileIO In-Reply-To: <1427129465.77.0.24572480634.issue23752@psf.upfronthosting.co.za> Message-ID: <1428363515.79.0.939057236228.issue23752@psf.upfronthosting.co.za> STINNER Victor added the comment: Buildbot issues were unrelated and have been fixed. I close the issue. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 01:39:51 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Apr 2015 23:39:51 +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: <1428363591.83.0.0621858794112.issue23496@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: -haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 01:53:42 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 06 Apr 2015 23:53:42 +0000 Subject: [issue20611] socket.create_connection() doesn't handle EINTR properly In-Reply-To: <1392218032.12.0.645790882431.issue20611@psf.upfronthosting.co.za> Message-ID: <1428364422.48.0.241999852299.issue20611@psf.upfronthosting.co.za> STINNER Victor added the comment: This issue was fixed in Python 3.5 as part of the PEP 475: see issue #23618 which modified socket.socket.connect() to handle EINTR. It's not as simple as retrying connect() in a loop. You must respect the socket timeout (it's better to have a monotonic clock here, it's now always the case in Python 3.5). When connect() returns EINTR, the connection runs asynchronously, you have to call select() to wait until the connection completes or fails. Then you have to call getsockopt() to get the socket error code. In Python 3.5, socket.socket.connect() still raises InterruptedError if the socket is non-blocking: https://docs.python.org/dev/library/socket.html#socket.socket.connect issue20611-connect-eintr-gps01.diff calls again connect() if connect() failed with EINTR. According to the issue #23618, it might work on some platforms, but it's not portable. For Python 2.7 and 3.4, instead of fixing socket.socket.connect(), which requires complex code, we may only workaround the issue in create_connection(). If connect() raises OSError(EINTR), drop the socket and retry with a fresh connection in a loop until the connection completes or raises a different exception. (And do that for each address.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 10:23:09 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Apr 2015 08:23:09 +0000 Subject: [issue23879] asyncio: SelectorEventLoop.sock_connect() must not retry connect() on InterruptedError Message-ID: <1428394989.42.0.151918238179.issue23879@psf.upfronthosting.co.za> New submission from STINNER Victor: According to the issue #23618, when connect() fails with EINTR, retrying connect() may only work on some platforms. To have a reliable behaviour on all platforms, we should wait until the socket becomes writable because the connection runs asynchronously in background. When the socket becomes writable, we have to gets its error code (getsockopt(SO_ERROR)) to check if the connection succeeded or failed. Attached patch fixes SelectorEventLoop.sock_connect(). ---------- components: asyncio files: connect_eintr.patch keywords: patch messages: 240195 nosy: gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio: SelectorEventLoop.sock_connect() must not retry connect() on InterruptedError versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38854/connect_eintr.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 10:41:04 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Apr 2015 08:41:04 +0000 Subject: [issue23880] Tkinter: getint and getdouble should support Tcl_Obj Message-ID: <1428396064.01.0.00215215635093.issue23880@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: getint, getdouble and getboolean were thin wrappers around Tcl functions that converted string result of Tcl call to specified Python type. Since 2.3 _tkinter can return not only string, but int, float, etc and Tcl_Obj (if wantobject is True). getXXX methods was updated to work with respective automatically converted types (getint with int, etc), but they don't work with general Tcl_Obj, so can't be applied to the result of _tkinter call in general case. As a workaround you should use int(str(value)) or like. Support of Tcl_Obj in getbool was added in issue15133. Proposed patch adds support of Tcl_Obj in getint and getdouble and int in getdouble. It also restores the use of getint and getdouble in Tkinter. ---------- components: Extension Modules, Tkinter files: tkinter_getxxx_tclobj.patch keywords: patch messages: 240196 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Tkinter: getint and getdouble should support Tcl_Obj type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file38855/tkinter_getxxx_tclobj.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 10:41:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Apr 2015 08:41:34 +0000 Subject: [issue23880] Tkinter: getint and getdouble should support Tcl_Obj In-Reply-To: <1428396064.01.0.00215215635093.issue23880@psf.upfronthosting.co.za> Message-ID: <1428396094.83.0.427337714339.issue23880@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 11:09:10 2015 From: report at bugs.python.org (Robert Kuska) Date: Tue, 07 Apr 2015 09:09:10 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428397750.69.0.744965299295.issue23857@psf.upfronthosting.co.za> Robert Kuska added the comment: >Le 06/04/2015 13:29, Nick Coghlan a ?crit : >> >> So while this isn't a feature upstream itself needs, it's one potentially needed by multiple *downstreams*, so in my view it makes sense for us to work with upstream to come up with the "one obvious way" for redistributors to handle the problem (now that we know that my initial attempt at providing such a way doesn't work in practice). > >So would it be possible for the actual implementation to be done outside of CPython? (in a dedicated fork, for example) Yes it would and most likely will be, but as Nick pointed out, it is important to come up with the "one obvious way". I understand why my patch is not acceptable for the upstream, it was my first shot (yet suitable for us) to start a discussion about cert verification. >From the proposed solutions mentioned I favour the ENV variable which would address also Donald concerns, using ENV variable per application to enable/disable cert verification instead of global enable/disable, (yet it could be also `export`ed for global settings), are there any real disadvantages of using this method? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 11:25:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Apr 2015 09:25:20 +0000 Subject: [issue15227] Fatal Python error: PyEval_RestoreThread: NULL tstate on example script.. In-Reply-To: <1341030356.65.0.710942348238.issue15227@psf.upfronthosting.co.za> Message-ID: <1428398720.75.0.119136439744.issue15227@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 12:18:50 2015 From: report at bugs.python.org (Neil Girdhar) Date: Tue, 07 Apr 2015 10:18:50 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1428401930.92.0.944630961848.issue2292@psf.upfronthosting.co.za> Changes by Neil Girdhar : Added file: http://bugs.python.org/file38856/starunpack40.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 12:43:02 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Apr 2015 10:43:02 +0000 Subject: [issue23881] test_urllib2net: issues with ftp://gatekeeper.research.compaq.com/ and ftp://ftp.mirror.nl/ Message-ID: <1428403382.55.0.763005294099.issue23881@psf.upfronthosting.co.za> New submission from STINNER Victor: test_urllib2net uses multiple public FTP servers. Since yesterday, there are issues with 2 FTP servers: (1) ftp://gatekeeper.research.compaq.com/pub/DEC/SRC/research-reports/00README-Legal-Rules-Regs => DNS server error $ host gatekeeper.research.compaq.com 8.8.8.8 Host gatekeeper.research.compaq.com not found: 2(SERVFAIL) $ host gatekeeper.research.compaq.com 212.27.40.240 Host gatekeeper.research.compaq.com not found: 2(SERVFAIL) (2) ftp://ftp.mirror.nl/pub/gnu/ * The FTP connection succeeded * Changing the directory to /pub/gnu succeeded * but listing the content of /pub/gnu/ takes forever... In Firefox, I get the error "425 Failed to establish connection". ---------- messages: 240198 nosy: haypo priority: normal severity: normal status: open title: test_urllib2net: issues with ftp://gatekeeper.research.compaq.com/ and ftp://ftp.mirror.nl/ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 12:50:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Apr 2015 10:50:51 +0000 Subject: [issue23881] test_urllib2net: issues with ftp://gatekeeper.research.compaq.com/ and ftp://ftp.mirror.nl/ In-Reply-To: <1428403382.55.0.763005294099.issue23881@psf.upfronthosting.co.za> Message-ID: <20150407105047.80899.43455@psf.io> Roundup Robot added the comment: New changeset 69d4e199b88e by Victor Stinner in branch '2.7': Issue #23881: urllib.ftpwrapper constructor now closes the socket if the FTP https://hg.python.org/cpython/rev/69d4e199b88e New changeset 7b168db16e67 by Victor Stinner in branch '3.4': Issue #23881: urllib.request.ftpwrapper constructor now closes the socket if https://hg.python.org/cpython/rev/7b168db16e67 New changeset 1a72c0a1a50f by Victor Stinner in branch 'default': (Merge 3.4) Issue #23881: urllib.request.ftpwrapper constructor now closes the https://hg.python.org/cpython/rev/1a72c0a1a50f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 13:00:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Apr 2015 11:00:28 +0000 Subject: [issue23881] test_urllib2net: issues with ftp://gatekeeper.research.compaq.com/ and ftp://ftp.mirror.nl/ In-Reply-To: <1428403382.55.0.763005294099.issue23881@psf.upfronthosting.co.za> Message-ID: <20150407110024.80889.1888@psf.io> Roundup Robot added the comment: New changeset 40ddcd785f7b by Victor Stinner in branch '3.4': Issue #23881: ftp://gatekeeper.research.compaq.com/ and ftp://ftp.debian.org/ https://hg.python.org/cpython/rev/40ddcd785f7b New changeset 225be6be3893 by Victor Stinner in branch '2.7': ssue #23881: ftp://gatekeeper.research.compaq.com/ and ftp://ftp.debian.org/ https://hg.python.org/cpython/rev/225be6be3893 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 13:03:32 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Apr 2015 11:03:32 +0000 Subject: [issue23881] test_urllib2net: issues with ftp://gatekeeper.research.compaq.com/, ftp://ftp.mirror.nl/ and ftp://ftp.kernel.org/ In-Reply-To: <1428403382.55.0.763005294099.issue23881@psf.upfronthosting.co.za> Message-ID: <1428404612.81.0.782719001944.issue23881@psf.upfronthosting.co.za> STINNER Victor added the comment: Python 2.7 used ftp://ftp.kernel.org/pub/linux/kernel/README whereas Python 3.4/3.6 uses ftp://ftp.debian.org/debian/README. Right now, ftp://ftp.kernel.org/pub/linux/kernel/README doesn't respond. So I also modified Python 2.7 to uses ftp.debian.org as Python 3.4/3.5. Is there a FTP vulnerability in the wild and some public FTP servers are down because of that? Or is it a network connectivity issue? ---------- title: test_urllib2net: issues with ftp://gatekeeper.research.compaq.com/ and ftp://ftp.mirror.nl/ -> test_urllib2net: issues with ftp://gatekeeper.research.compaq.com/, ftp://ftp.mirror.nl/ and ftp://ftp.kernel.org/ _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 13:03:39 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Apr 2015 11:03:39 +0000 Subject: [issue23881] test_urllib2net: issues with ftp://gatekeeper.research.compaq.com/, ftp://ftp.mirror.nl/ and ftp://ftp.kernel.org/ In-Reply-To: <1428403382.55.0.763005294099.issue23881@psf.upfronthosting.co.za> Message-ID: <1428404619.45.0.977566109015.issue23881@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- components: +Tests versions: +Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 13:09:01 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Apr 2015 11:09:01 +0000 Subject: [issue23881] test_urllib2net: issues with ftp://gatekeeper.research.compaq.com/, ftp://ftp.mirror.nl/ and ftp://ftp.kernel.org/ In-Reply-To: <1428403382.55.0.763005294099.issue23881@psf.upfronthosting.co.za> Message-ID: <1428404941.37.0.916018545985.issue23881@psf.upfronthosting.co.za> STINNER Victor added the comment: For ftp.kernel.org, it may be related to a FS data corruption bug: 2015-02-03: FTP limited on mirrors.kernel.org https://www.kernel.org/ftp-limited-on-mirrorskernelorg.html "We've had to temporarily limit FTP access to mirrors.kernel.org due to high IO load." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 13:11:21 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Apr 2015 11:11:21 +0000 Subject: [issue23881] test_urllib2net: issues with ftp://gatekeeper.research.compaq.com/, ftp://ftp.mirror.nl/ and ftp://ftp.kernel.org/ In-Reply-To: <1428403382.55.0.763005294099.issue23881@psf.upfronthosting.co.za> Message-ID: <1428405081.62.0.300218068666.issue23881@psf.upfronthosting.co.za> STINNER Victor added the comment: > $ host gatekeeper.research.compaq.com 212.27.40.240 > Host gatekeeper.research.compaq.com not found: 2(SERVFAIL) "What happened to gatekeeper.dec.com?" http://gatekeeper.dec.com/what-happened-to-gatekeeper.html Maybe we should use ftp://apotheca.hpl.hp.com/ instead? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 13:17:37 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Apr 2015 11:17:37 +0000 Subject: [issue23881] test_urllib2net: issues with ftp://gatekeeper.research.compaq.com/, ftp://ftp.mirror.nl/ and ftp://ftp.kernel.org/ In-Reply-To: <1428403382.55.0.763005294099.issue23881@psf.upfronthosting.co.za> Message-ID: <1428405457.97.0.0807411694495.issue23881@psf.upfronthosting.co.za> STINNER Victor added the comment: > (2) ftp://ftp.mirror.nl/pub/gnu/ DNS resolution: $ host ftp.mirror.nl ftp.mirror.nl is an alias for download.xs4all.nl. download.xs4all.nl is an alias for dl.xs4all.nl. dl.xs4all.nl has address 194.109.21.66 dl.xs4all.nl has IPv6 address 2001:888:0:25:194:109:21:66 http://dl.xs4all.nl/ works well, but this site has no /pub/ directory. Is it related? See also "Dead mirror: ftp.demon.nl" https://lists.gnupg.org/pipermail/gnupg-devel/2014-November/029113.html (but it doesn't look to be related) xs4all hosted python.org, I don't know if it still host the new CDN of python.org. https://en.wikipedia.org/wiki/XS4ALL#Corporate_culture "XS4ALL also sponsors and hosts the sites of many free software projects, like Python, Squirrelmail and Debian." ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 13:36:36 2015 From: report at bugs.python.org (Florian Apolloner) Date: Tue, 07 Apr 2015 11:36:36 +0000 Subject: [issue23882] unittest discovery and namespaced packages Message-ID: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za> New submission from Florian Apolloner: Unittest discovery does not seem to work if the tests package is a namespace package. The attached file should have all details to reproduce, as soon as I readd an __init__.py everything works fine. Test was done using python3.4.2 and 3.4.3 ---------- files: console_log.txt messages: 240205 nosy: Florian.Apolloner priority: normal severity: normal status: open title: unittest discovery and namespaced packages versions: Python 3.4 Added file: http://bugs.python.org/file38857/console_log.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 13:43:33 2015 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 07 Apr 2015 11:43:33 +0000 Subject: [issue23882] unittest discovery and namespaced packages In-Reply-To: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za> Message-ID: <1428407013.34.0.411371246956.issue23882@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, michael.foord, rbcollins type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 15:10:28 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 07 Apr 2015 13:10:28 +0000 Subject: [issue10838] subprocess __all__ is incomplete In-Reply-To: <1294260769.5.0.0970426129524.issue10838@psf.upfronthosting.co.za> Message-ID: <1428412228.76.0.546154403868.issue10838@psf.upfronthosting.co.za> Martin Panter added the comment: IMO the two documented exceptions should definitely be added to __all__. Not so sure, but list2cmdline() should probably be left out, with a comment explaining the decision. It is not mentioned in the main documentation that I can find, but it is mentioned in the doc string of the ?subprocess? module. If it is only meant to be an internal detail, it shouldn?t be mentioned by name. If it is an external API (which I doubt), it should be documented better and added to __all__. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 15:18:19 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 07 Apr 2015 13:18:19 +0000 Subject: [issue23505] Urlparse insufficient validation leads to open redirect In-Reply-To: <1424736713.95.0.74935935546.issue23505@psf.upfronthosting.co.za> Message-ID: <1428412699.34.0.152452857888.issue23505@psf.upfronthosting.co.za> Martin Panter added the comment: FYI I posted a patch at Issue 22852 to retain the empty netloc ?//? when appropriate. But even if there is interest in that patch, I guess it can still only be applied to the next version of Python (3.5 or whatever), being a new feature. Maybe you could suggest some wording or a patch to the documentation that could be applied to bugfix releases as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 15:20:39 2015 From: report at bugs.python.org (Cyd Haselton) Date: Tue, 07 Apr 2015 13:20:39 +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: <1428412839.32.0.510953214699.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Will do, re: removing the '+'. Also, attempted to apply the updated patch and got the following: /bld/python/cpython-master $ patch -p1 < issue_20306\ \(1\).patch patching file Modules/pwdmodule.c Possibly reversed hunk 1 at 244 Hunk 1 FAILED 79/79. SETS(setIndex++, p->pw_passwd); PyStructSequence_SET_ITEM(v, setIndex++, _PyLong_FromUid(p->pw_uid)); PyStructSequence_SET_ITEM(v, setIndex++, _PyLong_FromGid(p->pw_gid)); +#ifdef HAVE_PASSWD_GECOS_FIELD SETS(setIndex++, p->pw_gecos); +#else + SETS(setIndex++, Py_None); + Py_INCREF(Py_None); +#endif SETS(setIndex++, p->pw_dir); SETS(setIndex++, p->pw_shell); patching file configure.ac Hunk 56 FAILED 4944/4944. AC_MSG_RESULT($ENSUREPIP) AC_SUBST(ENSUREPIP) +AC_CHECK_MEMBER([struct passwd.pw_gecos], + [AC_DEFINE(HAVE_PASSWD_GECOS_FIELD, 1, [Define if defines field passwd.pw_gecos])], + [], + [[#include ]]) + # generate output files AC_CONFIG_FILES(Makefile.pre Modules/Setup.config Misc/python.pc Misc/python-config.sh) AC_CONFIG_FILES([Modules/ld_so_aix], [chmod +x Modules/ld_so_aix]) /bld/python/cpython-master $ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 15:22:37 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Apr 2015 13:22:37 +0000 Subject: [issue23881] test_urllib2net: issues with ftp://gatekeeper.research.compaq.com/, ftp://ftp.mirror.nl/ and ftp://ftp.kernel.org/ In-Reply-To: <1428403382.55.0.763005294099.issue23881@psf.upfronthosting.co.za> Message-ID: <1428412957.17.0.447795286627.issue23881@psf.upfronthosting.co.za> STINNER Victor added the comment: test_urllib2net looks to pass on enough buildbots, I close the issue. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 15:26:29 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Apr 2015 13:26:29 +0000 Subject: [issue23772] pymonotonic() gone backward on "AMD64 Debian root 3.x" buildbot In-Reply-To: <1427251882.59.0.116696625299.issue23772@psf.upfronthosting.co.za> Message-ID: <1428413189.08.0.62779918787.issue23772@psf.upfronthosting.co.za> STINNER Victor added the comment: I only saw the issue once, I close the bug. ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 15:29:30 2015 From: report at bugs.python.org (Alex Shkop) Date: Tue, 07 Apr 2015 13:29:30 +0000 Subject: [issue23811] Python py_compile error message inconsistent and missing newline In-Reply-To: <1427716738.06.0.245811504272.issue23811@psf.upfronthosting.co.za> Message-ID: <1428413370.88.0.601736368512.issue23811@psf.upfronthosting.co.za> Alex Shkop added the comment: This patch adds new line symbol. For some reason py_compile module prints only SyntaxErrors with traceback. All other exceptions are printed with "Sorry:" and in one line. ---------- keywords: +patch nosy: +ashkop Added file: http://bugs.python.org/file38858/issue23811.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 15:42:59 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 Apr 2015 13:42:59 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428414179.41.0.829074141652.issue23857@psf.upfronthosting.co.za> R. David Murray added the comment: I believe the original objection was that it made it too easy to globally (and in a not-obvious-to-the-end-user way) disable validation. That argument seems to apply equally well to the proposed patch, so an environment var at least isn't worse; but it does make it less likely that it will be accepted as a 3.5 feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 15:50:26 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 Apr 2015 13:50:26 +0000 Subject: [issue10838] subprocess __all__ is incomplete In-Reply-To: <1294260769.5.0.0970426129524.issue10838@psf.upfronthosting.co.za> Message-ID: <1428414626.51.0.726696512576.issue10838@psf.upfronthosting.co.za> R. David Murray added the comment: I believe it is and should remain internal. I agree that the mention should be deleted from the docstring. We removed it from the docs a while back but I guess we forgot the docstring. (If there were an external API for doing what list2cmdline does, it would belong in the windows equivalent of the shlex module, something that has been discussed (and I think there is an issue in the tracker) but no one has stepped forward to write it :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 16:54:53 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 07 Apr 2015 14:54:53 +0000 Subject: [issue23882] unittest discovery and namespaced packages In-Reply-To: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za> Message-ID: <1428418493.39.0.992848875636.issue23882@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 17:45:22 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 07 Apr 2015 15:45:22 +0000 Subject: [issue23879] asyncio: SelectorEventLoop.sock_connect() must not retry connect() on InterruptedError In-Reply-To: <1428394989.42.0.151918238179.issue23879@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: LGTM. On Apr 7, 2015 1:23 AM, "STINNER Victor" wrote: > > New submission from STINNER Victor: > > According to the issue #23618, when connect() fails with EINTR, retrying > connect() may only work on some platforms. To have a reliable behaviour on > all platforms, we should wait until the socket becomes writable because the > connection runs asynchronously in background. When the socket becomes > writable, we have to gets its error code (getsockopt(SO_ERROR)) to check if > the connection succeeded or failed. > > Attached patch fixes SelectorEventLoop.sock_connect(). > > ---------- > components: asyncio > files: connect_eintr.patch > keywords: patch > messages: 240195 > nosy: gvanrossum, haypo, yselivanov > priority: normal > severity: normal > status: open > title: asyncio: SelectorEventLoop.sock_connect() must not retry connect() > on InterruptedError > versions: Python 3.4, Python 3.5 > Added file: http://bugs.python.org/file38854/connect_eintr.patch > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 17:58:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Apr 2015 15:58:43 +0000 Subject: [issue23411] Update urllib.parse.__all__ In-Reply-To: <1423395526.83.0.535584531827.issue23411@psf.upfronthosting.co.za> Message-ID: <1428422323.89.0.747696952073.issue23411@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 18:00:46 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Apr 2015 16:00:46 +0000 Subject: [issue23873] Removal of dead code in smtpd In-Reply-To: <1428195463.82.0.559504880721.issue23873@psf.upfronthosting.co.za> Message-ID: <20150407160040.80913.68323@psf.io> Roundup Robot added the comment: New changeset 81ce9d412a4c by Benjamin Peterson in branch '3.4': remove smtpd dead code (closes #23873) https://hg.python.org/cpython/rev/81ce9d412a4c New changeset ea21b99d002e by Benjamin Peterson in branch 'default': merge 3.4 (#23873) https://hg.python.org/cpython/rev/ea21b99d002e ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 18:09:30 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Apr 2015 16:09:30 +0000 Subject: [issue23411] Update urllib.parse.__all__ In-Reply-To: <1423395526.83.0.535584531827.issue23411@psf.upfronthosting.co.za> Message-ID: <20150407160926.16236.84767@psf.io> Roundup Robot added the comment: New changeset a48e76252952 by Serhiy Storchaka in branch 'default': Issue #23411: Added DefragResult, ParseResult, SplitResult, DefragResultBytes, https://hg.python.org/cpython/rev/a48e76252952 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 18:09:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Apr 2015 16:09:57 +0000 Subject: [issue23411] Update urllib.parse.__all__ In-Reply-To: <1423395526.83.0.535584531827.issue23411@psf.upfronthosting.co.za> Message-ID: <1428422997.26.0.809616927913.issue23411@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 Tue Apr 7 18:23:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Apr 2015 16:23:10 +0000 Subject: [issue23883] __all__ lists are incomplete Message-ID: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Here is a (perhaps incomplete) list of documented names absent in __all__ lists of respective modules. Perhaps some of them (but not all) are worth to be added to __all__ lists. calendar.Calendar calendar.HTMLCalendar calendar.TextCalendar cgi.test configparser.Error csv.unix_dialect doctest.DocFileCase doctest.DocTestCase enum.EnumMeta fileinput.fileno ftplib.Error ftplib.error_perm ftplib.error_reply gettext.bind_textdomain_codeset gettext.lgettext gettext.lngettext http.client.HTTPMessage http.cookies.Morsel http.server.test logging.shutdown mailbox.Error mailbox.ExternalClashError mailbox.NoSuchMailboxError mailbox.NotEmptyError mimetypes.MimeTypes optparse.check_choice pickletools.OpcodeInfo plistlib.InvalidFileException pydoc.doc smtpd.SMTPChannel subprocess.SubprocessError subprocess.TimeoutExpired tarfile.CompressionError tarfile.HeaderError tarfile.ReadError tarfile.open threading.BrokenBarrierError tkinter.ttk.Widget tokenize.open traceback.FrameSummary traceback.StackSummary traceback.TracebackException traceback.walk_stack traceback.walk_tb wave.Wave_read wave.Wave_write xml.etree.ElementTree.XMLPullParser ---------- components: Library (Lib) messages: 240217 nosy: r.david.murray, serhiy.storchaka, vadmium priority: normal severity: normal status: open title: __all__ lists are incomplete type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 18:23:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Apr 2015 16:23:31 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1428423811.68.0.5960155854.issue23883@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +subprocess __all__ is incomplete _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 18:42:58 2015 From: report at bugs.python.org (Cyd Haselton) Date: Tue, 07 Apr 2015 16:42:58 +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: <1428424978.81.0.491471408402.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Update: Removing the random '+' on line 87 of pwdmodule.c allowed the build to continue but it failed again with the following during or soon after linking: Objects/unicodeobject.o: In function `PyUnicode_EncodeLocale': /bld/python/cpython-master/Objects/unicodeobject.c:3236: undefined reference to `android_wcstombs' /bld/python/cpython-master/Objects/unicodeobject.c:3248: undefined reference to `android_wcstombs' Objects/unicodeobject.o: In function `wcstombs_errorpos': /bld/python/cpython-master/Objects/unicodeobject.c:3154: undefined reference to `android_wcstombs' Objects/unicodeobject.o: In function `PyUnicode_DecodeLocaleAndSize': /bld/python/cpython-master/Objects/unicodeobject.c:3518: undefined reference to `android_mbstowcs' /bld/python/cpython-master/Objects/unicodeobject.c:3518: undefined reference to `android_mbstowcs' Objects/complexobject.o: In function `_Py_c_pow': /bld/python/cpython-master/Objects/complexobject.c:129: undefined reference to `sincos' Python/fileutils.o: In function `Py_DecodeLocale': /bld/python/cpython-master/Python/fileutils.c:322: undefined reference to `android_mbstowcs' Python/fileutils.o: In function `Py_EncodeLocale': /bld/python/cpython-master/Python/fileutils.c:487: undefined reference to `android_wcstombs' /bld/python/cpython-master/Python/fileutils.c:489: undefined reference to `android_wcstombs' Python/fileutils.o: In function `_Py_wfopen': /bld/python/cpython-master/Python/fileutils.c:1008: undefined reference to `android_wcstombs' collect2: error: ld returned 1 exit status make: *** [Programs/_freeze_importlib] Error 1 Maybe the androidfn.h wasn't added to the files above? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 18:50:42 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 07 Apr 2015 16:50:42 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428425442.35.0.11437047473.issue23857@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Environment variables are hidden state. It makes them rather dangerous from a security POV (even more so than a root-modifiable configuration file, since it is less well-defined who can set an environment variable that will be inherited by some process). As long as the solution that is decided on isn't part of vanilla Python, I care a bit less, of course :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 19:29:13 2015 From: report at bugs.python.org (Peter Marsh) Date: Tue, 07 Apr 2015 17:29:13 +0000 Subject: [issue23884] New DateType for argparse (like FileType but for dates) Message-ID: <1428427753.85.0.794213637884.issue23884@psf.upfronthosting.co.za> New submission from Peter Marsh: Hello, Reasonably frequently I find myself needing to pass a date as a command line argument to a Python script I've written. Currently, argparse does not have a built support for dates - this adds a new class to argparse (much like the existing FileType) that parses arguments to datetime.date instances. Example: >>> parser = argparse.ArgumentParser() >>> parser.add_argument('--start', type=argparse.DateType('%d/%m/%Y)) >>> parser.add_argument('end', type=argparse.DateType()) >>> parser.parse_args(['--start', '01/02/2015', '2015-01-03']) Namespace(end=datetime.date(2015, 1, 3), start=datetime.date(2015, 1, 2)) I think this would be a useful addition to the standard library, a quick Google shows that many people roll their own version of this anyway. Support for datetime.datetime and perhaps even datetime.timedeltas might be good too, but date/times get a bit more complicated (timezones in general and varying support for the '%z' format string which is required to default to an ISO8601 date time). Cheers, Pete ---------- components: Library (Lib) files: argparse_datetype.patch keywords: patch messages: 240220 nosy: petedmarsh priority: normal severity: normal status: open title: New DateType for argparse (like FileType but for dates) type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file38859/argparse_datetype.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 19:37:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Apr 2015 17:37:33 +0000 Subject: [issue6650] sre_parse contains a confusing generic error message In-Reply-To: <1249492479.55.0.250174703511.issue6650@psf.upfronthosting.co.za> Message-ID: <1428428253.51.0.0507414677196.issue6650@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> out of date stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 19:53:23 2015 From: report at bugs.python.org (SilentGhost) Date: Tue, 07 Apr 2015 17:53:23 +0000 Subject: [issue23884] New DateType for argparse (like FileType but for dates) In-Reply-To: <1428427753.85.0.794213637884.issue23884@psf.upfronthosting.co.za> Message-ID: <1428429203.84.0.577535652803.issue23884@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- nosy: +bethard _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 20:09:05 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Tue, 07 Apr 2015 18:09:05 +0000 Subject: [issue23880] Tkinter: getint and getdouble should support Tcl_Obj In-Reply-To: <1428396064.01.0.00215215635093.issue23880@psf.upfronthosting.co.za> Message-ID: <1428430145.97.0.176581246752.issue23880@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I don't quite understand this, but I think I should. Here are preliminary questions. 0. It seems that this pushes conversions from python code (app.py, tkinter.py) to C (_tkinter.py). Correct? What is being gained from a user viewpoint? 1. "getint, getdouble and getboolean were thin wrappers around Tcl functions that converted string result of Tcl call to specified Python type." How does this match getint and getdouble being synonyms for builtins? - getint = int - getdouble = float Or were 'int' and 'float' overriden before this? 2. Does the change break existing code? In particular, is the idlelib change necessary or optional? 3. Should there be a doc change, at least in docstrings? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 20:21:29 2015 From: report at bugs.python.org (Steve Dougherty) Date: Tue, 07 Apr 2015 18:21:29 +0000 Subject: [issue11205] Evaluation order of dictionary display is different from reference manual. In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za> Message-ID: <1428430889.34.0.458752996662.issue11205@psf.upfronthosting.co.za> Steve Dougherty added the comment: Any word on either changing the documentation to match the behaviour or fixing this as a bug? ---------- nosy: +sdougherty _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 20:57:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Apr 2015 18:57:40 +0000 Subject: [issue23880] Tkinter: getint and getdouble should support Tcl_Obj In-Reply-To: <1428396064.01.0.00215215635093.issue23880@psf.upfronthosting.co.za> Message-ID: <1428433060.72.0.27114219099.issue23880@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > 0. It seems that this pushes conversions from python code (app.py, tkinter.py) to C (_tkinter.py). Correct? What is being gained from a user viewpoint? The benefit is that widget.tk.getint(widget.tk.call(...)) (and widget.getint(widget.call(...))) always works when it makes sense. Currently it works for integers and strings. If the result of Tcl call becomes some specific type in new Tcl version, this needs a workaround with converting to str, as you can see in IDLE code. User code with this patch will become more robust against future Tcl/Tk changes. And actually against changes that already happen in recent Tcl versions. Many user code that worked with 8.3 or 8.4 needed an update to work with 8.5 or 8.6. With this patch they perhaps need less changes. > 2. Does the change break existing code? Usually not. > In particular, is the idlelib change necessary or optional? It is optional. It is is just a demonstration how the code can be made simpler and more robust. > How does this match getint and getdouble being synonyms for builtins? > - getint = int > - getdouble = float > Or were 'int' and 'float' overridden before this? There are different functions on different levels. There are tkapp methods in _tkinter.c. There are Misc methods in tkinter.py (added in changesets 73dd2a979857 and 273451892327). They originally was wrappers around tkapp methods. There are module-level functions in tkinter.py. They were converted to aliases of int and float in 34cca832a4af. > 3. Should there be a doc change, at least in docstrings? Unfortunately all these functions are not documented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 21:31:45 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Apr 2015 19:31:45 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <1428435105.98.0.213059374787.issue16840@psf.upfronthosting.co.za> STINNER Victor added the comment: test_expr_bignum() should tolerate the long type: http://buildbot.python.org/all/builders/x86%20Tiger%202.7/builds/3007/steps/test/logs/stdio ====================================================================== FAIL: test_expr_bignum (test.test_tcl.TclTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/db3l/buildarea/2.7.bolen-tiger/build/Lib/test/test_tcl.py", line 443, in test_expr_bignum self.assertIsInstance(result, type(int(result))) AssertionError: -2147483648L is not an instance of In fact, I don't understand the test self.assertIsInstance(result, type(int(result))). What do you expect from type(int(x)): int or long depending on the value of x? The problem is that an intermediate result may be a long and so tcl.call('expr', ..) returns a long even if it may fit into a small int. I suggest to simply drop the test self.assertIsInstance(result, type(int(result))). ---------- nosy: +haypo resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 21:33:47 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 07 Apr 2015 19:33:47 +0000 Subject: [issue11205] Evaluation order of dictionary display is different from reference manual. In-Reply-To: <1428430889.34.0.458752996662.issue11205@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: This needs a code patch. But it can only be fixed for 3.5. On Apr 7, 2015 11:21 AM, "Steve Dougherty" wrote: > > Steve Dougherty added the comment: > > Any word on either changing the documentation to match the behaviour or > fixing this as a bug? > > ---------- > nosy: +sdougherty > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 21:40:45 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Apr 2015 19:40:45 +0000 Subject: [issue23879] asyncio: SelectorEventLoop.sock_connect() must not retry connect() on InterruptedError In-Reply-To: <1428394989.42.0.151918238179.issue23879@psf.upfronthosting.co.za> Message-ID: <20150407194042.105293.64721@psf.io> Roundup Robot added the comment: New changeset eca51493c770 by Victor Stinner in branch '3.4': Issue #23879, asyncio: SelectorEventLoop.sock_connect() must not call connect() https://hg.python.org/cpython/rev/eca51493c770 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 21:41:02 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Apr 2015 19:41:02 +0000 Subject: [issue23879] asyncio: SelectorEventLoop.sock_connect() must not retry connect() on InterruptedError In-Reply-To: <1428394989.42.0.151918238179.issue23879@psf.upfronthosting.co.za> Message-ID: <1428435662.27.0.159556365494.issue23879@psf.upfronthosting.co.za> STINNER Victor added the comment: > LGTM. Thanks for the review. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 22:16:47 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 07 Apr 2015 20:16:47 +0000 Subject: [issue23884] New DateType for argparse (like FileType but for dates) In-Reply-To: <1428427753.85.0.794213637884.issue23884@psf.upfronthosting.co.za> Message-ID: <1428437807.68.0.915185875065.issue23884@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 22:20:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 07 Apr 2015 20:20:50 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <1428438050.23.0.973350816426.issue16840@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It is important that the result is an int at least for small ints. So I prefer to keep limited test. - self.assertIsInstance(result, type(int(result))) + if abs(result) < 2**31: + self.assertIsInstance(result, int) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 22:42:53 2015 From: report at bugs.python.org (STINNER Victor) Date: Tue, 07 Apr 2015 20:42:53 +0000 Subject: [issue23848] faulthandler: setup an exception handler on Windows In-Reply-To: <1427962559.63.0.750474204561.issue23848@psf.upfronthosting.co.za> Message-ID: <1428439373.38.0.979565229743.issue23848@psf.upfronthosting.co.za> STINNER Victor added the comment: More complete (and working) patch. Most unit tests pass, but two unit tests must be updated to match the new error message. ---------- Added file: http://bugs.python.org/file38860/faulthandler_exc_handler-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 23:10:15 2015 From: report at bugs.python.org (=?utf-8?q?Marcin_Ko=C5=9Bcielnicki?=) Date: Tue, 07 Apr 2015 21:10:15 +0000 Subject: [issue23885] urllib.quote horribly mishandles unicode as second parameter Message-ID: <1428441015.17.0.142718858432.issue23885@psf.upfronthosting.co.za> New submission from Marcin Ko?cielnicki: All hell breaks loose when unicode is passed as the second argument to urllib.quote in Python 2: >>> import urllib >>> urllib.quote('\xce\x91', u'') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/urllib.py", line 1292, in quote if not s.rstrip(safe): UnicodeDecodeError: 'ascii' codec can't decode byte 0xce in position 0: ordinal not in range(128) This on its own wouldn't be that bad - just another Python 2 unicode wonkiness. However, coupled with caching done by the quote function (quoters are cached based on the second parameter, and u'' == ''), it means that a random preceding call to quote from an entirely different place in the application can break your code: $ python2 Python 2.7.9 (default, Dec 11 2014, 04:42:00) [GCC 4.9.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import urllib >>> urllib.quote('\xce\x91', '') '%CE%91' >>> $ python2 Python 2.7.9 (default, Dec 11 2014, 04:42:00) [GCC 4.9.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import urllib >>> urllib.quote('a', u'') 'a' >>> urllib.quote('\xce\x91', '') Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.7/urllib.py", line 1292, in quote if not s.rstrip(safe): UnicodeDecodeError: 'ascii' codec can't decode byte 0xce in position 0: ordinal not in range(128) Good luck debugging that. So, one of two things needs to happen: - a TypeError when unicode is passed as the second parameter, or - a cast of the second parameter to str ---------- components: Library (Lib) messages: 240230 nosy: koriakin priority: normal severity: normal status: open title: urllib.quote horribly mishandles unicode as second parameter versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 7 23:12:54 2015 From: report at bugs.python.org (Ezio Melotti) Date: Tue, 07 Apr 2015 21:12:54 +0000 Subject: [issue23885] urllib.quote horribly mishandles unicode as second parameter In-Reply-To: <1428441015.17.0.142718858432.issue23885@psf.upfronthosting.co.za> Message-ID: <1428441174.31.0.0332775072761.issue23885@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, orsenthil type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 00:07:18 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 07 Apr 2015 22:07:18 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1428444438.03.0.462616070334.issue23883@psf.upfronthosting.co.za> Martin Panter added the comment: http.client.HTTPMessage: See Issue 23439. There was resistance to adding this (and the status code constants), though IMO they should be added, since they are documented public APIs. http.server.test(): In Issue 23418, I consciously left this function out. It is only mentioned as a place to look for sample code, as far as I can tell. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 00:13:36 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 07 Apr 2015 22:13:36 +0000 Subject: [issue20611] socket.create_connection() doesn't handle EINTR properly In-Reply-To: <1392218032.12.0.645790882431.issue20611@psf.upfronthosting.co.za> Message-ID: <1428444816.52.0.617901409273.issue20611@psf.upfronthosting.co.za> Gregory P. Smith added the comment: i'm moving this to the more recent issue as i like the patch in that one better. ---------- superseder: -> Fix EINTR Socket Module issues in 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 00:13:49 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 07 Apr 2015 22:13:49 +0000 Subject: [issue20611] socket.create_connection() doesn't handle EINTR properly In-Reply-To: <1392218032.12.0.645790882431.issue20611@psf.upfronthosting.co.za> Message-ID: <1428444829.15.0.309150037495.issue20611@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- resolution: -> duplicate status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 00:19:30 2015 From: report at bugs.python.org (paul j3) Date: Tue, 07 Apr 2015 22:19:30 +0000 Subject: [issue23884] New DateType for argparse (like FileType but for dates) In-Reply-To: <1428427753.85.0.794213637884.issue23884@psf.upfronthosting.co.za> Message-ID: <1428445170.65.0.370207323247.issue23884@psf.upfronthosting.co.za> paul j3 added the comment: It's a possible addition, but I don't have sense of the demand for it. I wonder, what does the class offer that a function like this doesn't? def adate(date_string): return datetime.datetime.strptime(date_string,'%Y-%m-%d').date() I'd be hesitant to add FileType if wasn't already present. It hasn't aged very well. We've had bug issues related to v3 binary files, and contexts. The main feature that FileType (beyond verifying that the file actually does exist) adds is the recognition of '-' as stdin/out. By analogy I'm lukewarm about adding a DateType class. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 00:48:17 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 07 Apr 2015 22:48:17 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1428446897.8.0.345598803132.issue23863@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I like the socketmodule.c part of socket_eintr.1.patch, but it appears to still have the issue haypo describes in https://bugs.python.org/issue20611#msg240194 where connect() cannot be called more than once. The kernel carries on with the connect without our process waiting for it, we have to monitor it to know when it has succeeded or failed. See https://hg.python.org/cpython/file/85a5265909cb/Modules/socketmodule.c#l2610 and issue23618 from Python 3.5. [code review done at 35,000ft, thanks chromebook gogo free wifi pass!] ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 00:57:34 2015 From: report at bugs.python.org (paul j3) Date: Tue, 07 Apr 2015 22:57:34 +0000 Subject: [issue23884] New DateType for argparse (like FileType but for dates) In-Reply-To: <1428427753.85.0.794213637884.issue23884@psf.upfronthosting.co.za> Message-ID: <1428447454.3.0.165359164527.issue23884@psf.upfronthosting.co.za> paul j3 added the comment: Examples of datetime types from Stackoverflow: http://stackoverflow.com/questions/21437258/defining-python-argparse-arguments The suggested answer (but not accepted) is 'type=lambda s: datetime.datetime.strptime(s, '%Y-%m-%d')' another http://stackoverflow.com/questions/12462074/python-argparse-create-timedelta-object-from-argument which references https://gist.github.com/jnothman/4057689 'timedeltatype.py: An argparse type factory that produces datetime.timedelta objects' and http://stackoverflow.com/questions/25470844/specify-format-for-input-arguments-argparse-python with a type function ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 00:58:09 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Apr 2015 22:58:09 +0000 Subject: [issue10838] subprocess __all__ is incomplete In-Reply-To: <1294260769.5.0.0970426129524.issue10838@psf.upfronthosting.co.za> Message-ID: <20150407225806.80917.46187@psf.io> Roundup Robot added the comment: New changeset 10b0a8076be8 by Gregory P. Smith in branch 'default': Addresses Issue #10838: The subprocess now module includes https://hg.python.org/cpython/rev/10b0a8076be8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 01:00:46 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 07 Apr 2015 23:00:46 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1428447646.92.0.931963559769.issue23863@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- assignee: -> gregory.p.smith keywords: +needs review stage: -> patch review type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 01:02:21 2015 From: report at bugs.python.org (Paul McMillan) Date: Tue, 07 Apr 2015 23:02:21 +0000 Subject: [issue23505] Urlparse insufficient validation leads to open redirect In-Reply-To: <1428412699.34.0.152452857888.issue23505@psf.upfronthosting.co.za> Message-ID: Paul McMillan added the comment: As Martin said, backporting a change for this wouldn't be appropriate for Python 2.7. The 2.7 docs could certainly be updated to make this clearer, but we can't introduce a breaking change like that to the stable release. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 01:04:42 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 07 Apr 2015 23:04:42 +0000 Subject: [issue10838] subprocess __all__ is incomplete In-Reply-To: <1294260769.5.0.0970426129524.issue10838@psf.upfronthosting.co.za> Message-ID: <1428447882.95.0.280372610192.issue10838@psf.upfronthosting.co.za> Gregory P. Smith added the comment: the things left to to before closing this are to rename mswindows and MAXFD as those shouldn't be exported... and to wait for the windows buildbots to tell me if i missed adding anything to the intentionally_excluded list in the unittest. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 01:11:45 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 07 Apr 2015 23:11:45 +0000 Subject: [issue10838] subprocess __all__ is incomplete In-Reply-To: <1294260769.5.0.0970426129524.issue10838@psf.upfronthosting.co.za> Message-ID: <20150407231142.117469.62097@psf.io> Roundup Robot added the comment: New changeset 4c14afc3f931 by Gregory P. Smith in branch 'default': issue10838: Rename the subprocess.mswindows internal global to _mswindows. https://hg.python.org/cpython/rev/4c14afc3f931 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 01:12:49 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Tue, 07 Apr 2015 23:12:49 +0000 Subject: [issue10838] subprocess __all__ is incomplete In-Reply-To: <1294260769.5.0.0970426129524.issue10838@psf.upfronthosting.co.za> Message-ID: <1428448369.38.0.666930340342.issue10838@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Done. MAXFD was already gone in 3.5 (yay). ---------- assignee: -> gregory.p.smith resolution: -> fixed stage: needs patch -> commit review status: open -> closed type: -> behavior versions: +Python 3.2 -Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 01:49:27 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 Apr 2015 23:49:27 +0000 Subject: [issue23884] New DateType for argparse (like FileType but for dates) In-Reply-To: <1428427753.85.0.794213637884.issue23884@psf.upfronthosting.co.za> Message-ID: <1428450567.03.0.985938901565.issue23884@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, I think this is a case where it is better for the application to define exactly what it needs rather than try to define a general solution that won't satisfy everyone :) FileType's purpose is actually, I think, to give you an *open* file. Which is also where a number of the problems came from :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 01:56:56 2015 From: report at bugs.python.org (R. David Murray) Date: Tue, 07 Apr 2015 23:56:56 +0000 Subject: [issue23885] urllib.quote horribly mishandles unicode as second parameter In-Reply-To: <1428441015.17.0.142718858432.issue23885@psf.upfronthosting.co.za> Message-ID: <1428451016.51.0.489126964015.issue23885@psf.upfronthosting.co.za> R. David Murray added the comment: The typerror isn't going to happen for backward compatibility reasons. A fix isn't likely to happen because python2 doesn't really support unicode in urllib, to my understanding (if I'm wrong about that the answser changes). I'm not sure whether casting to string would have backward compatibility issues or not (I suspect it would; somneone would have to investigate that question as a first step). ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 04:29:51 2015 From: report at bugs.python.org (Steve) Date: Wed, 08 Apr 2015 02:29:51 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za> Message-ID: <1428460191.66.0.01839586818.issue15443@psf.upfronthosting.co.za> Steve added the comment: Hi, This issue is causing my organization problems. We are using python 2.7.9 with pyodbc 3.0.7 The application DB is SQL Server and they have started using Datetime2 (see: https://msdn.microsoft.com/en-us/library/bb677335.aspx?f=255&MSPPError=-2147217396) They did this to ensure that transactions timestamps are more unique, specially when data is bulk uploaded into the DB. Datetime2 supports to seven places. Our application is now getting timestamps that are truncated to 6 places, making them useless when comparing a timestamp >= to others in the db. This is a real world issue and we really need a fix. We are not able to migrate at the moment to python 3 due to other constraints. Any chance someone can take Matthieu's patch and retro fit it to 2.7.9 (if that makes sense)? ---------- nosy: +scoobydoo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 04:37:42 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 08 Apr 2015 02:37:42 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za> Message-ID: <1428460662.94.0.631129303124.issue15443@psf.upfronthosting.co.za> R. David Murray added the comment: Unfortunately no, that would be a new feature and so can't go into 2.7. Maybe someone could backport the work that has been done in this area so people could patch locally, but I don't think it is a small job and I'm pretty sure no one on the core team is interested. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 04:38:15 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Apr 2015 02:38:15 +0000 Subject: [issue23865] Fix possible leaks in close methods In-Reply-To: <1428145980.2.0.463866688715.issue23865@psf.upfronthosting.co.za> Message-ID: <1428460695.77.0.690414000321.issue23865@psf.upfronthosting.co.za> Martin Panter added the comment: The change to aifc shouldn?t be needed, unless the underlying file object?s close() is not idempotent. And if that is the case, you?re fixing the bug in the wrong place :) Most of the other changes look good from a rough review, though I was only familiar enough with the gzip and HTTP modules to review them thoroughly. I left a few comments on Reitveld. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 04:50:14 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Apr 2015 02:50:14 +0000 Subject: [issue12808] Coverage of codecs.py In-Reply-To: <1313983372.14.0.793098723033.issue12808@psf.upfronthosting.co.za> Message-ID: <1428461414.15.0.911107613632.issue12808@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 05:11:08 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 08 Apr 2015 03:11:08 +0000 Subject: [issue23841] py34 OrderedDict is using weakref for root reference In-Reply-To: <1427889707.75.0.323875541647.issue23841@psf.upfronthosting.co.za> Message-ID: <1428462668.86.0.0753449594128.issue23841@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Closing as not-a-bug. It seems that the __del__ method in requests needs to make one of the adjustments suggested by Antoine. ---------- priority: high -> normal resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 05:34:20 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Apr 2015 03:34:20 +0000 Subject: [issue12053] Add prefetch() for Buffered IO (experiment) In-Reply-To: <1305056245.15.0.0737815347229.issue12053@psf.upfronthosting.co.za> Message-ID: <1428464060.98.0.57196964756.issue12053@psf.upfronthosting.co.za> Martin Panter added the comment: Sounds like this might be more appropriate for the BufferedReader and related classes, and less so for the writer and abstract base class. The proposed API seems strange to me. Is there an illustration of how it might be used? I suspect it wouldn?t be all that useful, and could more or less be implemented with the existing methods: def prefetch(buffered_reader, buffer, skip, minread): buffered_reader.read(skip) consumed = buffered_reader.readinto(buffer[:minread]) if consumed < minread: return consumed spare = len(buffer) - consumed extra = buffered_reader.peek(spare)[:spare] total = consumed + len(extra) buffer[consumed:total] = extra return total Maybe it would be better to focus on clarifying or redefining the existing peek() method (Issue 5811), rather than making a brand new do-everything method which only seems to do what the other methods already do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 06:05:32 2015 From: report at bugs.python.org (William Woodall) Date: Wed, 08 Apr 2015 04:05:32 +0000 Subject: [issue23548] TypeError in event loop finalizer, new in Python 3.4.3 In-Reply-To: <1425139981.48.0.523334940185.issue23548@psf.upfronthosting.co.za> Message-ID: <1428465932.34.0.706098937065.issue23548@psf.upfronthosting.co.za> William Woodall added the comment: I was getting the same error as the OP in my application. I did something like this to work around the problem: import asyncio import atexit def close_asyncio_loop(): loop = None try: loop = asyncio.get_event_loop() except AttributeError: pass if loop is not None: loop.close() atexit.register(close_asyncio_loop) Is this an appropriate work around? Why is it up to the application to close the loop explicitly? Put another way, in what scenario would I want to close the loop outside of the application shutting down since it is irreversible? Thanks in advance for your time. ---------- nosy: +wjwwood _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 06:13:13 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 08 Apr 2015 04:13:13 +0000 Subject: [issue10838] subprocess __all__ is incomplete In-Reply-To: <1294260769.5.0.0970426129524.issue10838@psf.upfronthosting.co.za> Message-ID: <1428466393.27.0.94239771939.issue10838@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: commit review -> resolved versions: +Python 3.5 -Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 07:26:55 2015 From: report at bugs.python.org (James Tocknell) Date: Wed, 08 Apr 2015 05:26:55 +0000 Subject: [issue23835] configparser does not convert defaults to strings In-Reply-To: <1427862188.44.0.00358189102447.issue23835@psf.upfronthosting.co.za> Message-ID: <1428470815.74.0.286728981275.issue23835@psf.upfronthosting.co.za> James Tocknell added the comment: Here's a patch for 2.7 (based of the head of the 2.7 branch), something similar could be done for 3.4 (I wasn't sure what branch I was supposed to base the patch off, since 3.4 is inactive). The string requirement was already noted in the docstring of the configparser module, but that's not mentioned in the main docs. Also, I wasn't sure where to put a test in because there was not test_configparser.py located in Lib/test. ---------- keywords: +patch Added file: http://bugs.python.org/file38861/py27-config-fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 08:15:31 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 08 Apr 2015 06:15:31 +0000 Subject: [issue19610] Give clear error messages for invalid types used for setup.py params (e.g. tuple for classifiers) In-Reply-To: <1384514692.62.0.115546674646.issue19610@psf.upfronthosting.co.za> Message-ID: <1428473731.15.0.997360561112.issue19610@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the review, ?ric. New patch attached. > When running a setup.py that uses a tuple for classifiers, is the error message in the terminal user-friendly, or do we get a full traceback? A full traceback: Traceback (most recent call last): File "setup.py", line 37, in platforms=('Windows', 'Any'), File "/home/berker/projects/cpython/default/Lib/distutils/core.py", line 108, in setup _setup_distribution = dist = klass(attrs) File "/home/berker/projects/cpython/default/Lib/distutils/dist.py", line 253, in __init__ getattr(self.metadata, "set_" + key)(val) File "/home/berker/projects/cpython/default/Lib/distutils/dist.py", line 1212, in set_platforms raise TypeError(msg % type(value).__name__) TypeError: 'platforms' should be a 'list', not 'tuple' ---------- Added file: http://bugs.python.org/file38862/issue19610_v4.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 08:19:16 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 08 Apr 2015 06:19:16 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1428473956.66.0.785819234211.issue23883@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 08:47:01 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Apr 2015 06:47:01 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <20150408064657.84811.14388@psf.io> Roundup Robot added the comment: New changeset ebf3e6332a44 by Berker Peksag in branch 'default': Issue #23883: Add missing entries to traceback.__all__. https://hg.python.org/cpython/rev/ebf3e6332a44 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 10:03:04 2015 From: report at bugs.python.org (Albert Zeyer) Date: Wed, 08 Apr 2015 08:03:04 +0000 Subject: [issue23886] faulthandler_user should use _PyThreadState_Current Message-ID: <1428480184.73.0.0889790949933.issue23886@psf.upfronthosting.co.za> New submission from Albert Zeyer: SIGUSR1/2 will get delivered to any running thread. The current thread of the signal doesn't give any useful information. Try to get the current Python thread which holds the GIL instead, or use NULL. I have patched this for the external faulthandler module here: https://github.com/haypo/faulthandler/pull/12 https://github.com/albertz/faulthandler/commit/dc92265 ---------- components: Library (Lib) messages: 240252 nosy: Albert.Zeyer priority: normal severity: normal status: open title: faulthandler_user should use _PyThreadState_Current type: behavior versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 10:07:09 2015 From: report at bugs.python.org (Alex Shkop) Date: Wed, 08 Apr 2015 08:07:09 +0000 Subject: [issue23577] Add tests for wsgiref.validate In-Reply-To: <1425401935.54.0.320750128573.issue23577@psf.upfronthosting.co.za> Message-ID: <1428480429.87.0.367687760091.issue23577@psf.upfronthosting.co.za> Alex Shkop added the comment: *ping* ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 11:34:38 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 08 Apr 2015 09:34:38 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1428485678.5.0.658692440019.issue23883@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +easy stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 11:57:53 2015 From: report at bugs.python.org (Alex Shkop) Date: Wed, 08 Apr 2015 09:57:53 +0000 Subject: [issue23882] unittest discovery and namespaced packages In-Reply-To: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za> Message-ID: <1428487073.51.0.512112062359.issue23882@psf.upfronthosting.co.za> Alex Shkop added the comment: Spent some time looking into this one. Looks like the problem is in TestLoader.discover() method. There are couple of issues I found in it, all caused by same assumption. Documentation [1] states that all test modules found by discover() method should be importable from top_level_dir. Whenever this method finds a subdirectory of start_dir it checks for __init__.py file. If there's no __init__.py then finder assumes that files within this package is not importable and stops recursion. This kind of 'importablity' check is not valid since we have namespace packages. I'm not sure what should be done to fix this issue. We can change documentation to state that only regular packages with tests will be discovered. Or we can fix 'importability' checks, which will mean that all tests in all subdirectories will be discovered. [1] https://docs.python.org/3.4/library/unittest.html#unittest.TestLoader.discover ---------- nosy: +ashkop _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 12:44:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Apr 2015 10:44:59 +0000 Subject: [issue23865] Fix possible leaks in close methods In-Reply-To: <1428145980.2.0.463866688715.issue23865@psf.upfronthosting.co.za> Message-ID: <1428489899.44.0.0595864360872.issue23865@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ah, yet one purpose of the patch is to make close() methods more robust when called at shutdown. Objects can be partially deconstructed at that time, attributes can be set to None to break reference loops. That is why I use None as signaling value and always check some attribute for None. The changes to aifc make sense. close() is called from __exit__(). When context manager is used in a generator, it creates a reference loop. So self.file is None in this case and self.file.close() will raise an AttributeError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 12:46:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Apr 2015 10:46:55 +0000 Subject: [issue16314] Support xz compression in distutils In-Reply-To: <1351114378.64.0.718374634123.issue16314@psf.upfronthosting.co.za> Message-ID: <1428490015.28.0.505411100958.issue16314@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ping. ---------- assignee: -> eric.araujo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 12:48:03 2015 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 08 Apr 2015 10:48:03 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1428490083.08.0.843784649004.issue23857@psf.upfronthosting.co.za> Nick Coghlan added the comment: I like the idea of a separate "2.7-redistributor" branch to capture changes like this, as that would almost *exactly* duplicate the kernel maintenance model. That approach would also mean that we don't have to figure out sensible upstream documentation for features like this that only make sense in the context of a redistributor that is responsible for ensuring they're used appropriately. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 12:51:01 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 08 Apr 2015 10:51:01 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1428490261.14.0.955238902578.issue23883@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: May be makes sense to add a helper in test.support that implements a test similar to the one in issue23411, and add tests for __all__ in multiple modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 12:52:05 2015 From: report at bugs.python.org (Peter Marsh) Date: Wed, 08 Apr 2015 10:52:05 +0000 Subject: [issue23884] New DateType for argparse (like FileType but for dates) In-Reply-To: <1428427753.85.0.794213637884.issue23884@psf.upfronthosting.co.za> Message-ID: <1428490325.02.0.946573177472.issue23884@psf.upfronthosting.co.za> Peter Marsh added the comment: The consensus seems to be that this is simple enough for people to implement themselves (if they need it) and it's probably not worth adding to argparse, so I've closed this :) ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 13:01:44 2015 From: report at bugs.python.org (Milap Bhojak) Date: Wed, 08 Apr 2015 11:01:44 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1428490904.01.0.359133357956.issue23883@psf.upfronthosting.co.za> Milap Bhojak added the comment: I working on these three. calendar.Calendar calendar.HTMLCalendar calendar.TextCalendar Changes would be the same as https://hg.python.org/cpython/rev/ebf3e6332a44/ for every module? ---------- nosy: +milap.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 13:25:39 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Apr 2015 11:25:39 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1428492339.38.0.64511364592.issue23883@psf.upfronthosting.co.za> Martin Panter added the comment: Serhiy: Yes I was also thinking it might be time for a common helper function. Milap: I think changes like you mentioned (originally by me) would be fine. Another variation was done for Issue 10838: revision 10b0a8076be8, which expects each object that is not a module object (e.g. not from ?import sys?), rather than expecting each object that is a function or class defined in the module. It might depend on the particular circumstance which technique is superior. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 13:44:13 2015 From: report at bugs.python.org (Facundo Batista) Date: Wed, 08 Apr 2015 11:44:13 +0000 Subject: [issue23887] HTTPError doesn't have a good "repr" representation Message-ID: <1428493453.93.0.931112960505.issue23887@psf.upfronthosting.co.za> New submission from Facundo Batista: I normally print(repr()) the exception I got, for debugging purposes. I use repr() because for builtin exceptions, str() will print only the message, and not the exception type. But for HTTPError, the repr() of it is "HTTPError()", without further explanation... ---------- messages: 240262 nosy: facundobatista priority: normal severity: normal status: open title: HTTPError doesn't have a good "repr" representation versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 14:35:21 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 08 Apr 2015 12:35:21 +0000 Subject: [issue23887] HTTPError doesn't have a good "repr" representation In-Reply-To: <1428493453.93.0.931112960505.issue23887@psf.upfronthosting.co.za> Message-ID: <1428496521.46.0.78047710313.issue23887@psf.upfronthosting.co.za> Berker Peksag added the comment: HTTPError.__str__ already provides useful information: ``'HTTP Error %s: %s' % (self.code, self.msg)``, but since the change is minimal and useful, here is a patch. ---------- components: +Library (Lib) keywords: +patch nosy: +berker.peksag stage: -> patch review type: -> enhancement versions: +Python 3.5 -Python 3.4 Added file: http://bugs.python.org/file38863/issue23887.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 15:00:44 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 08 Apr 2015 13:00:44 +0000 Subject: [issue23882] unittest discovery and namespaced packages In-Reply-To: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za> Message-ID: <1428498044.97.0.905931314911.issue23882@psf.upfronthosting.co.za> Eric Snow added the comment: Is there any reason for unittest to not use pkgutil.iter_modules or pkgutil.walk_packages? Either should work. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 16:17:39 2015 From: report at bugs.python.org (ssh) Date: Wed, 08 Apr 2015 14:17:39 +0000 Subject: [issue23888] Fixing fractional expiry time bug in cookiejar Message-ID: <1428502659.33.0.324281998086.issue23888@psf.upfronthosting.co.za> New submission from ssh: If the FileCookieJar reads a cookie whose expiry time is a decimal fraction, it crashes. Chrome extensions "cookies.txt" and "EdiThisCookie" export the expiry time as decimal fractions. This is accepted by wget and curl, but not by the FileCookieJar which ends up crashing. I made a StackOverflow question checking if fractional decimal expiry times were even allowed (if it was a bug in the extensions), but didn't get a response: https://stackoverflow.com/questions/29502672/can-the-cookie-expires-field-be-a-decimal-value At any rate, this patch should make the library more robust. ---------- components: Library (Lib) files: mywork.patch keywords: patch messages: 240265 nosy: serhiy.storchaka, ssh priority: normal severity: normal status: open title: Fixing fractional expiry time bug in cookiejar type: crash versions: Python 3.5 Added file: http://bugs.python.org/file38864/mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 16:38:51 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Apr 2015 14:38:51 +0000 Subject: [issue23027] test_warnings fails with -Werror In-Reply-To: <1418248295.01.0.00165630152899.issue23027@psf.upfronthosting.co.za> Message-ID: <20150408143821.16260.46392@psf.io> Roundup Robot added the comment: New changeset e64197dad303 by Berker Peksag in branch 'default': Issue #23027: test_warnings now passes all tests when run it with -Werror. https://hg.python.org/cpython/rev/e64197dad303 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 16:42:29 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 08 Apr 2015 14:42:29 +0000 Subject: [issue23027] test_warnings fails with -Werror In-Reply-To: <1418248295.01.0.00165630152899.issue23027@psf.upfronthosting.co.za> Message-ID: <1428504149.97.0.337922839398.issue23027@psf.upfronthosting.co.za> Berker Peksag added the comment: Removing issue 18383 from dependencies since the bug is also reproducible on the 3.4 branch. This issue only applies to the default branch. ---------- dependencies: -test_warnings modifies warnings.filters when running with "-W default" resolution: -> fixed stage: commit review -> resolved status: open -> closed versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 16:57:06 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 08 Apr 2015 14:57:06 +0000 Subject: [issue23888] Fixing fractional expiry time bug in cookiejar In-Reply-To: <1428502659.33.0.324281998086.issue23888@psf.upfronthosting.co.za> Message-ID: <1428505026.41.0.113488522026.issue23888@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 16:57:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Apr 2015 14:57:33 +0000 Subject: [issue23400] Inconsistent behaviour of multiprocessing.Queue() if sem_open is not implemented In-Reply-To: <1423213399.39.0.868704647623.issue23400@psf.upfronthosting.co.za> Message-ID: <20150408145730.15223.22066@psf.io> Roundup Robot added the comment: New changeset 749fd043de95 by Berker Peksag in branch '3.4': Issue #23400: Raise same exception on both Python 2 and 3 if sem_open is not available. https://hg.python.org/cpython/rev/749fd043de95 New changeset a49737bd6086 by Berker Peksag in branch 'default': Issue #23400: Raise same exception on both Python 2 and 3 if sem_open is not available. https://hg.python.org/cpython/rev/a49737bd6086 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 17:01:29 2015 From: report at bugs.python.org (Demian Brecht) Date: Wed, 08 Apr 2015 15:01:29 +0000 Subject: [issue23887] HTTPError doesn't have a good "repr" representation In-Reply-To: <1428493453.93.0.931112960505.issue23887@psf.upfronthosting.co.za> Message-ID: <1428505289.3.0.533957369899.issue23887@psf.upfronthosting.co.za> Demian Brecht added the comment: A test really should be added for this. Otherwise, LGTM. ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 17:12:43 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 08 Apr 2015 15:12:43 +0000 Subject: [issue23400] Inconsistent behaviour of multiprocessing.Queue() if sem_open is not implemented In-Reply-To: <1423213399.39.0.868704647623.issue23400@psf.upfronthosting.co.za> Message-ID: <20150408151240.16238.6076@psf.io> Roundup Robot added the comment: New changeset c2f6b3677630 by Berker Peksag in branch '2.7': Issue #23400: Add notes about the sem_open support of the host OS to https://hg.python.org/cpython/rev/c2f6b3677630 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 17:15:17 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 08 Apr 2015 15:15:17 +0000 Subject: [issue23400] Inconsistent behaviour of multiprocessing.Queue() if sem_open is not implemented In-Reply-To: <1423213399.39.0.868704647623.issue23400@psf.upfronthosting.co.za> Message-ID: <1428506117.37.0.293070592195.issue23400@psf.upfronthosting.co.za> Berker Peksag added the comment: Fixed. Thank you all (and sorry for my late commit, Davin). ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 17:21:40 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 08 Apr 2015 15:21:40 +0000 Subject: [issue23021] Get rid of references to PyString in Modules/ In-Reply-To: <1418141104.02.0.91056311182.issue23021@psf.upfronthosting.co.za> Message-ID: <1428506500.26.0.346611699413.issue23021@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> out of date stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 17:24:47 2015 From: report at bugs.python.org (Jeff McNeil) Date: Wed, 08 Apr 2015 15:24:47 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1428506687.08.0.321265323249.issue23863@psf.upfronthosting.co.za> Jeff McNeil added the comment: Missed check on _ex func. ---------- Added file: http://bugs.python.org/file38865/socket_eintr.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 17:26:23 2015 From: report at bugs.python.org (Jeff McNeil) Date: Wed, 08 Apr 2015 15:26:23 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1428506783.96.0.365286476065.issue23863@psf.upfronthosting.co.za> Jeff McNeil added the comment: So, yeah, that's right. In the attached patch, I'm closing the file descriptor if the timeout/error happens on a non-blocking call. It fails with an EBADF on reconnect at that point, but it doesn't potentially leave an FD in the proc's file table. Should be no more EINTR's coming out of the select call. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 17:32:13 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Wed, 08 Apr 2015 15:32:13 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1428507133.15.0.269538215625.issue23342@psf.upfronthosting.co.za> Thomas Kluyver added the comment: I am still keen for this to move forwards. I am at PyCon if anyone wants to discuss it in person. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 17:36:52 2015 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 08 Apr 2015 15:36:52 +0000 Subject: [issue23815] Segmentation fault when create _tkinter objects In-Reply-To: <1427745415.01.0.962782500028.issue23815@psf.upfronthosting.co.za> Message-ID: <1428507412.4.0.431411814018.issue23815@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: Probably a PyType_Ready() missing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 17:42:50 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 08 Apr 2015 15:42:50 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1428507770.08.0.31574139403.issue23342@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I'm at pycon as well, we can get this taken care of here. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 17:47:40 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Wed, 08 Apr 2015 15:47:40 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1428508060.58.0.365252980931.issue23342@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Great! I'm free after my IPython tutorial this afternoon, all of tomorrow, and I'm around for the sprints. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 18:47:26 2015 From: report at bugs.python.org (David Coles) Date: Wed, 08 Apr 2015 16:47:26 +0000 Subject: [issue22970] Cancelling wait() after notification leaves Condition in an inconsistent state In-Reply-To: <1417404582.01.0.276361050449.issue22970@psf.upfronthosting.co.za> Message-ID: <1428511646.0.0.787647052031.issue22970@psf.upfronthosting.co.za> David Coles added the comment: This issue can still be reproduced on Python 3.5.0a1. (Triggers a "RuntimeError: Lock is not acquired" on cond.release()) Please let me know if there's any further steps you'd like me to take here. ---------- versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 19:37:50 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 08 Apr 2015 17:37:50 +0000 Subject: [issue23889] Speedup inspect.Signature.bind Message-ID: <1428514670.65.0.478019521392.issue23889@psf.upfronthosting.co.za> New submission from Yury Selivanov: Right now the implementation of Signature.bind is very complex, which leads to a subpar performance. The only way to significantly speed it up is to employ code generation and cache (the other way it to rewrite it in C, but that's something I'd like to avoid). I'll upload an initial implementation soon. ---------- assignee: yselivanov components: Library (Lib) messages: 240279 nosy: asvetlov, brett.cannon, larry, ncoghlan, yselivanov priority: normal severity: normal status: open title: Speedup inspect.Signature.bind versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 19:38:20 2015 From: report at bugs.python.org (Yury Selivanov) Date: Wed, 08 Apr 2015 17:38:20 +0000 Subject: [issue23889] Speedup inspect.Signature.bind In-Reply-To: <1428514670.65.0.478019521392.issue23889@psf.upfronthosting.co.za> Message-ID: <1428514700.98.0.621215665048.issue23889@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- stage: -> needs patch type: -> performance _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 20:37:05 2015 From: report at bugs.python.org (Vjacheslav Fyodorov) Date: Wed, 08 Apr 2015 18:37:05 +0000 Subject: [issue23890] assertRaises increases reference counter Message-ID: <1428518225.53.0.665360255509.issue23890@psf.upfronthosting.co.za> New submission from Vjacheslav Fyodorov: Sometimes unittest's assertRaises increases reference counter of callable. This can break tests in tricky cases. Not seen in 2.X version. Demo file attached. ---------- components: Library (Lib) files: test_assertRaises.py messages: 240280 nosy: Vjacheslav.Fyodorov priority: normal severity: normal status: open title: assertRaises increases reference counter type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file38866/test_assertRaises.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 21:30:10 2015 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 08 Apr 2015 19:30:10 +0000 Subject: [issue23891] Tutorial doesn't mention either pip or virtualenv Message-ID: <1428521410.44.0.984619918633.issue23891@psf.upfronthosting.co.za> New submission from A.M. Kuchling: (from discussion at the 2015 Python Language Summit) Current versions of Python make it relatively easy to install third-party packages such as requests. New users may not realize this, though, and continue using libraries such as urllib/urllib2 because they're in the stdlib. The Python tutorial doesn't seem to mention either virtualenv or pip. It should, describing how to create a virtualenv, install packages, and manage them in basic ways (removing, 'pip freeze', requirements.txt.) ---------- assignee: akuchling components: Documentation messages: 240281 nosy: akuchling priority: normal severity: normal status: open title: Tutorial doesn't mention either pip or virtualenv type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 21:31:34 2015 From: report at bugs.python.org (Thana Annis) Date: Wed, 08 Apr 2015 19:31:34 +0000 Subject: [issue23807] Improved test coverage for calendar.py command line In-Reply-To: <1427643739.5.0.155189832451.issue23807@psf.upfronthosting.co.za> Message-ID: <1428521494.14.0.959628834256.issue23807@psf.upfronthosting.co.za> Thana Annis added the comment: Thanks for the quick response. You're right that this is already being tested for, so I will close the issue. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 21:34:16 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 08 Apr 2015 19:34:16 +0000 Subject: [issue23807] Improved test coverage for calendar.py command line In-Reply-To: <1427643739.5.0.155189832451.issue23807@psf.upfronthosting.co.za> Message-ID: <1428521656.99.0.54782601749.issue23807@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 22:27:54 2015 From: report at bugs.python.org (Davin Potts) Date: Wed, 08 Apr 2015 20:27:54 +0000 Subject: [issue23484] SemLock acquire() keyword arg 'blocking' is invalid In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za> Message-ID: <1428524873.99.0.0969132446405.issue23484@psf.upfronthosting.co.za> Davin Potts added the comment: Updating patch for default/3.5 and 3.4 branches to remove versionchanged message on {Lock,RLock}.acquire per feedback from @berker. ---------- Added file: http://bugs.python.org/file38867/issue_23484_doc_locks_py35_and_py34_noverchange.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 22:28:24 2015 From: report at bugs.python.org (Davin Potts) Date: Wed, 08 Apr 2015 20:28:24 +0000 Subject: [issue23484] SemLock acquire() keyword arg 'blocking' is invalid In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za> Message-ID: <1428524904.75.0.93261819158.issue23484@psf.upfronthosting.co.za> Davin Potts added the comment: Same for 2.7 branch. ---------- Added file: http://bugs.python.org/file38868/issue_23484_doc_locks_py27_noverchange.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 22:39:36 2015 From: report at bugs.python.org (Davin Potts) Date: Wed, 08 Apr 2015 20:39:36 +0000 Subject: [issue23713] intermittent failure of multiprocessing unit test test_imap_unordered_handle_iterable_exception In-Reply-To: <1426795503.26.0.283860442544.issue23713@psf.upfronthosting.co.za> Message-ID: <1428525576.03.0.758506059393.issue23713@psf.upfronthosting.co.za> Davin Potts added the comment: Serhiy: If I understand correctly what you suggest, calling sorted(it) or list(it) would run the iterator all the way until it raises the SayWhenError exception, triggering the self.assertRaises before it ever actually gets to call the self.assertEqual or self.assertCountEqual you suggest. It would indeed test the raising of the exception but would never test individual values returned by the iterator to see that they belong. Or were you suggesting something different? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 23:41:44 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 08 Apr 2015 21:41:44 +0000 Subject: [issue23892] Introduce sys.implementation.opt_levels ? Message-ID: <1428529304.36.0.272921433795.issue23892@psf.upfronthosting.co.za> New submission from Brett Cannon: Eric suggested in a code review for issue #23731 that maybe we should have the possible optimization levels listed somewhere. ---------- components: Library (Lib) messages: 240286 nosy: brett.cannon, eric.snow priority: low severity: normal stage: test needed status: open title: Introduce sys.implementation.opt_levels ? type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 23:41:58 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 08 Apr 2015 21:41:58 +0000 Subject: [issue23892] Introduce sys.implementation.opt_levels In-Reply-To: <1428529304.36.0.272921433795.issue23892@psf.upfronthosting.co.za> Message-ID: <1428529318.35.0.636087032588.issue23892@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- dependencies: +Implement PEP 488 title: Introduce sys.implementation.opt_levels ? -> Introduce sys.implementation.opt_levels _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 23:45:45 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 08 Apr 2015 21:45:45 +0000 Subject: [issue23731] Implement PEP 488 In-Reply-To: <1426944831.0.0.593089874415.issue23731@psf.upfronthosting.co.za> Message-ID: <1428529545.49.0.375056999581.issue23731@psf.upfronthosting.co.za> Changes by Brett Cannon : Added file: http://bugs.python.org/file38869/d4fde2493736.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 23:53:40 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 08 Apr 2015 21:53:40 +0000 Subject: [issue23893] Forward-port future_builtins Message-ID: <1428530020.25.0.529453311381.issue23893@psf.upfronthosting.co.za> New submission from Brett Cannon: future_builtins exists in Python 2.7, but not Python 3 which is annoying for code that wants to rely on it in Python 2.7 but not 2to3 (who is the primary user of the module for rewrite rules). ---------- components: Library (Lib) messages: 240287 nosy: brett.cannon priority: normal severity: normal stage: test needed status: open title: Forward-port future_builtins type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 8 23:53:45 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 08 Apr 2015 21:53:45 +0000 Subject: [issue23893] Forward-port future_builtins In-Reply-To: <1428530020.25.0.529453311381.issue23893@psf.upfronthosting.co.za> Message-ID: <1428530025.99.0.949018396101.issue23893@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: -> brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 00:08:13 2015 From: report at bugs.python.org (Joshua J Cogliati) Date: Wed, 08 Apr 2015 22:08:13 +0000 Subject: [issue8027] distutils fail to determine c++ linker with unixcompiler if using ccache In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za> Message-ID: <1428530893.29.0.813371738012.issue8027@psf.upfronthosting.co.za> Joshua J Cogliati added the comment: I looked and the autoconf variable for the c++ linker is CXXLINK, so I think the proper way to fix this would be to change sysconfig.py to look at both CXXFLAGS and CXXLINK, and create those and use it to define a cxxlink variable, and only if they are missing should we actually try to do some of the magic that is currently used. Also, my patches (fix-distutils-*.patch) do not always work, because sometimes the c compiler cannot link the c++ code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 00:11:18 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 08 Apr 2015 22:11:18 +0000 Subject: [issue23865] Fix possible leaks in close methods In-Reply-To: <1428145980.2.0.463866688715.issue23865@psf.upfronthosting.co.za> Message-ID: <1428531078.7.0.486140462795.issue23865@psf.upfronthosting.co.za> Martin Panter added the comment: Okay, I think I get it. You are setting some attributes to None, in case they happen to be causing a reference cycle. When close() is called, they are no longer needed, so it might help to breaking potential reference cycles. I have often wondered why this was done. I always assumed it was a carry-over from old code relying on the garbage collector to automatically close files, etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 01:24:57 2015 From: report at bugs.python.org (Steve) Date: Wed, 08 Apr 2015 23:24:57 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za> Message-ID: <1428535497.79.0.38129246513.issue15443@psf.upfronthosting.co.za> Steve added the comment: Although I don't know what I am doing (patching python), if someone could point me to the relevant files in 2.7.9 that need to be patched, I'm willing to see if I can do it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 01:54:03 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Wed, 08 Apr 2015 23:54:03 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za> Message-ID: <1428537243.68.0.946607931307.issue15443@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Python 2 line is closed for new features, but you can start with the main line Lib/datetime.py which will probably work with python 2.7.9 after some minor tweaks. You should be able to publish the result on PyPI. Note that many new in 3.x modules are provided for 2.x this way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 02:06:22 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 09 Apr 2015 00:06:22 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za> Message-ID: <1428537982.31.0.21711269861.issue15443@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Matthieu, I don't see you adding nanoseconds to timedelta in your patch. Doesn't this mean that you would loose nanoseconds when you subtract one datetime from another? To anyone who wants to contribute to this effort, I would recommend starting with pure python implementation in Lib/datetime.py . ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 02:17:33 2015 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 09 Apr 2015 00:17:33 +0000 Subject: [issue16991] Add OrderedDict written in C In-Reply-To: <1358482110.59.0.347859163753.issue16991@psf.upfronthosting.co.za> Message-ID: <1428538653.37.0.80939966448.issue16991@psf.upfronthosting.co.za> Changes by Eric V. Smith : ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 02:18:42 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 00:18:42 +0000 Subject: [issue23890] assertRaises increases reference counter In-Reply-To: <1428518225.53.0.665360255509.issue23890@psf.upfronthosting.co.za> Message-ID: <1428538722.84.0.20283238584.issue23890@psf.upfronthosting.co.za> R. David Murray added the comment: This is presumably a result of the exception object being saved on the context manager object and there being a circular reference chain that doesn't immediately get GCed. This is just how python works. I don't know if it would be sensible/useful to use the new lightweight traceback stuff in assertRaises. If so it would probably have to be optional for backward compatibility reasons. ---------- nosy: +r.david.murray type: behavior -> enhancement versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 03:30:02 2015 From: report at bugs.python.org (mdcb) Date: Thu, 09 Apr 2015 01:30:02 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za> Message-ID: <1428543002.88.0.329041533309.issue15443@psf.upfronthosting.co.za> mdcb added the comment: Alexander, The initial patch is indeed minimal. If it gains momentum and some level of acceptation, I'd be happy to do more amends and fixes as needed and recommended. As for 2.7.9 - I'm not sure it makes much sense going PyPI patch if it's not going to happen on 3.x? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 03:32:37 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 09 Apr 2015 01:32:37 +0000 Subject: [issue23893] Forward-port future_builtins In-Reply-To: <1428530020.25.0.529453311381.issue23893@psf.upfronthosting.co.za> Message-ID: <1428543156.99.0.44619175827.issue23893@psf.upfronthosting.co.za> Brett Cannon added the comment: Since the module is literally `from builtins import ascii, filter, hex, map, oct, zip`, I have attached the test file (which is also ridiculously simple). ---------- nosy: +eric.smith stage: test needed -> patch review Added file: http://bugs.python.org/file38870/test_future_builtins.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 03:33:09 2015 From: report at bugs.python.org (John Beck) Date: Thu, 09 Apr 2015 01:33:09 +0000 Subject: [issue19561] request to reopen Issue837046 - pyport.h redeclares gethostname() if SOLARIS is defined In-Reply-To: <1384267181.39.0.791538142123.issue19561@psf.upfronthosting.co.za> Message-ID: <1428543189.17.0.881777518646.issue19561@psf.upfronthosting.co.za> John Beck added the comment: We (Solaris engineering) have hit this issue after migrating from 2.6 being our default version of Python to 2.7 being the default. The specific component that broke was vim (version 7.4), trying to compile if_python.c: "/usr/include/python2.7/pyport.h", line 645: identifier redeclared: gethostname current : function(pointer to char, int) returning int previous: function(pointer to char, unsigned long) returning int : "/usr/include/unistd.h", line 412 We had this patched out in Python 2.6's Include/pyport.h: -#ifdef SOLARIS -/* Unchecked */ -extern int gethostname(char *, int); -#endif but for some reason that patch was not propagated to our 2.7 line. Until today, that is; I will be applying that patch shortly to both 2.7 and 3.4. ---------- nosy: +jbeck _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 03:42:36 2015 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 09 Apr 2015 01:42:36 +0000 Subject: [issue23893] Forward-port future_builtins In-Reply-To: <1428530020.25.0.529453311381.issue23893@psf.upfronthosting.co.za> Message-ID: <1428543756.07.0.118753253236.issue23893@psf.upfronthosting.co.za> Eric V. Smith added the comment: Looks good to me. I realize it's trivial, but is it worth putting this on PyPI for older 3.x's? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 03:45:44 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 09 Apr 2015 01:45:44 +0000 Subject: [issue23893] Forward-port future_builtins In-Reply-To: <1428530020.25.0.529453311381.issue23893@psf.upfronthosting.co.za> Message-ID: <1428543944.15.0.750981561712.issue23893@psf.upfronthosting.co.za> Brett Cannon added the comment: I now have a patch that contains everything, including docs. ---------- keywords: +patch Added file: http://bugs.python.org/file38871/future_builtins.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 03:47:48 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 09 Apr 2015 01:47:48 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za> Message-ID: <1428544068.55.0.714563541738.issue15443@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I have no doubt this will get into 3.x once we have a working patch and backward compatibility issues are addressed. Given the amount of effort Victor has recently put in #22117 to rework CPython internal time handling to support nanoseconds, it will be odd not to support nanoseconds in datetime. On the substance, in your patch you have chosen to add nanoseconds as a separate field instead of changing microseconds to nanoseconds. I don't think this is the right approach. See msg223082. Once you get to implementing timedelta arithmetics, you will see that carrying two subsecond fields will unnecessarily complicate the code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 03:48:12 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 09 Apr 2015 01:48:12 +0000 Subject: [issue21411] Enable Treat Warning as Error on 32-bit Windows In-Reply-To: <1398976216.25.0.391009605761.issue21411@psf.upfronthosting.co.za> Message-ID: <1428544092.12.0.0728019129879.issue21411@psf.upfronthosting.co.za> Zachary Ware added the comment: This has been complicated by the migration to VS2015, which added a bunch of new warnings. Obviously we can't enable this now without either fixing all the warnings (unlikely, I think; most of them are just about shadowing vars) or disabling particular ones. So at this point, fix, disable, or reject? ---------- nosy: +paul.moore, steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 03:48:32 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 09 Apr 2015 01:48:32 +0000 Subject: [issue23893] Forward-port future_builtins In-Reply-To: <1428530020.25.0.529453311381.issue23893@psf.upfronthosting.co.za> Message-ID: <1428544112.7.0.203416087353.issue23893@psf.upfronthosting.co.za> Brett Cannon added the comment: It could go on PyPI if I make sure it doesn't shadow the module in Python 3.5 or 2.6/2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 03:57:25 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 09 Apr 2015 01:57:25 +0000 Subject: [issue23199] libpython27.a in amd64 release is 32-bit In-Reply-To: <1420764337.42.0.255694319213.issue23199@psf.upfronthosting.co.za> Message-ID: <1428544645.1.0.85380800231.issue23199@psf.upfronthosting.co.za> Zachary Ware added the comment: Steve: is this fixed and ready for next time? ---------- resolution: -> fixed stage: -> resolved status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 03:58:26 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 09 Apr 2015 01:58:26 +0000 Subject: [issue3566] httplib persistent connections violate MUST in RFC2616 sec 8.1.4. In-Reply-To: <1218901279.9.0.954545383172.issue3566@psf.upfronthosting.co.za> Message-ID: <1428544706.72.0.359822825031.issue3566@psf.upfronthosting.co.za> Martin Panter added the comment: Your tweaks look fine. Thanks everyone for working through this one. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 04:05:25 2015 From: report at bugs.python.org (George Jenkins) Date: Thu, 09 Apr 2015 02:05:25 +0000 Subject: [issue1182143] making builtin exceptions more informative Message-ID: <1428545125.88.0.866850413445.issue1182143@psf.upfronthosting.co.za> George Jenkins added the comment: Add patch generated via mercurial ---------- Added file: http://bugs.python.org/file38872/Issue1182143_1hg.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 04:18:18 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 02:18:18 +0000 Subject: [issue9517] Make test.script_helper more comprehensive, and use it in the test suite In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za> Message-ID: <1428545898.76.0.548742685543.issue9517@psf.upfronthosting.co.za> R. David Murray added the comment: Script helpers has been "made more discoverable" by moving it into the test.support namespace, but it has not been documented in the test.support docs. I can no longer remember if this is intentional or not. Regardless, this issue is still valid insofar as there are probably a number of places in the test suite where script_helpers can be used that they aren't being used. We probably don't want a multi-module changeset, though, so this could become a meta issue for new issues for converting particular test files to use script_helpers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 04:25:56 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 09 Apr 2015 02:25:56 +0000 Subject: [issue11205] Evaluation order of dictionary display is different from reference manual. In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za> Message-ID: <1428546356.56.0.707693165302.issue11205@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- priority: low -> high _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 05:28:39 2015 From: report at bugs.python.org (John Hergenroeder) Date: Thu, 09 Apr 2015 03:28:39 +0000 Subject: [issue23796] BufferedReader.peek() crashes if closed In-Reply-To: <1427502590.02.0.665422119627.issue23796@psf.upfronthosting.co.za> Message-ID: <1428550119.66.0.31429996196.issue23796@psf.upfronthosting.co.za> John Hergenroeder added the comment: Thanks! I submitted my contributor agreement form last week -- is there anything I can do to improve this patch while I wait for that to process? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 07:24:34 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 09 Apr 2015 05:24:34 +0000 Subject: [issue23886] faulthandler_user should use _PyThreadState_Current In-Reply-To: <1428480184.73.0.0889790949933.issue23886@psf.upfronthosting.co.za> Message-ID: <1428557074.37.0.40100786099.issue23886@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 07:29:21 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 09 Apr 2015 05:29:21 +0000 Subject: [issue23670] Modifications to support iOS as a cross-compilation target In-Reply-To: <1426400747.11.0.0527548590348.issue23670@psf.upfronthosting.co.za> Message-ID: <1428557361.46.0.082578671195.issue23670@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- assignee: -> ned.deily stage: -> patch review versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 07:46:19 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 09 Apr 2015 05:46:19 +0000 Subject: [issue23670] Modifications to support iOS as a cross-compilation target In-Reply-To: <1426400747.11.0.0527548590348.issue23670@psf.upfronthosting.co.za> Message-ID: <1428558379.36.0.134565161816.issue23670@psf.upfronthosting.co.za> Ned Deily added the comment: Russell, we talked a bit about this topic at the Python Language Summit today (after watching your excellent video). I think there was general agreement there that having iOS support would be "a good thing" along with the recognition that the requirements for support of a mobile platform like iOS differ in some significant ways from most traditional platforms that Python has supported. I agreed to shepherd this issue. I have some initial thoughts but will write up something more detailed shortly. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 08:16:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Apr 2015 06:16:53 +0000 Subject: [issue23893] Forward-port future_builtins In-Reply-To: <1428530020.25.0.529453311381.issue23893@psf.upfronthosting.co.za> Message-ID: <1428560213.96.0.927682223113.issue23893@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: try: from future_builtins import ascii, filter, hex, map, oct, zip except ImportError: pass ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 09:09:47 2015 From: report at bugs.python.org (Vjacheslav Fyodorov) Date: Thu, 09 Apr 2015 07:09:47 +0000 Subject: [issue23890] assertRaises increases reference counter In-Reply-To: <1428518225.53.0.665360255509.issue23890@psf.upfronthosting.co.za> Message-ID: <1428563387.45.0.498615996576.issue23890@psf.upfronthosting.co.za> Vjacheslav Fyodorov added the comment: It seems, as a minimum it must be noticed in docs. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 09:17:02 2015 From: report at bugs.python.org (Ezio Melotti) Date: Thu, 09 Apr 2015 07:17:02 +0000 Subject: [issue23890] assertRaises increases reference counter In-Reply-To: <1428518225.53.0.665360255509.issue23890@psf.upfronthosting.co.za> Message-ID: <1428563822.11.0.36007923548.issue23890@psf.upfronthosting.co.za> Changes by Ezio Melotti : ---------- nosy: +ezio.melotti, michael.foord, rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 10:32:21 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Apr 2015 08:32:21 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1428568341.01.0.429085182418.issue23863@psf.upfronthosting.co.za> STINNER Victor added the comment: Ok, since you look to want to fix Python 2.7, I can help you to handle EINTR in socket.connect() since I fixed Python 3.5. If Python 2.7 is fixed, Python 3.4 should also be fixed. connect_eintr-py27.patch: Patch for Python 2.7 to handle EINTR in socket.connect() for blocking socket or socket with a timeout. The patch calls select() to wait until the connection completes or fails. Use attached test_connect_eintr4.py to test it. I only tested my patch on Linux yet. ---------- Added file: http://bugs.python.org/file38873/connect_eintr-py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 10:32:32 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Apr 2015 08:32:32 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1428568352.01.0.432747586913.issue23863@psf.upfronthosting.co.za> Changes by STINNER Victor : Added file: http://bugs.python.org/file38874/test_connect_eintr4.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 10:32:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Apr 2015 08:32:58 +0000 Subject: [issue23618] PEP 475: handle EINTR in the socket module (connect) In-Reply-To: <1425892113.2.0.561654455596.issue23618@psf.upfronthosting.co.za> Message-ID: <20150409083255.3091.66518@psf.io> Roundup Robot added the comment: New changeset bff88c866886 by Victor Stinner in branch 'default': Issue #23618: Fix internal_select() for negative timeout (blocking socket) when https://hg.python.org/cpython/rev/bff88c866886 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 10:32:58 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Apr 2015 08:32:58 +0000 Subject: [issue23834] socketmodule.c: add sock_call() to fix how the timeout is recomputed In-Reply-To: <1427842506.28.0.704301607448.issue23834@psf.upfronthosting.co.za> Message-ID: <20150409083255.3091.16597@psf.io> Roundup Robot added the comment: New changeset 462680f4e8af by Victor Stinner in branch 'default': Issue #23834: Fix the default socket timeout https://hg.python.org/cpython/rev/462680f4e8af ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 10:44:08 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Apr 2015 08:44:08 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1428569048.04.0.297612251682.issue23863@psf.upfronthosting.co.za> STINNER Victor added the comment: socket_eintr.2.patch has an issue with timeout. socket_eintr.2.patch retries a socket method when it is interrupted, but it doesn't recompute the timeout. If a program is interrupted every second by a signal, the signal handler doesn't raise an exception and the socket has a timeout longer than 1 second, the socket method will "hang". Internally, socket method uses select() using the socket timeout. I had to modify deeply the socket module to handle correctly EINTR and respect the timeout in Python 3.5. By the way, I changed the behaviour of socket.sendall(), the timeout is now more strict (it's now the maximum total duration, the timeout is no reset each time some bytes are sent). Since Python applications of the last 20 years already had to handle EINTR theirself, it's maybe safer to leave Python 2.7 with its bugs and let application developers workaround them? Anyway, if you have to handle EINTR in your application, you will have to handle EINTR explicitly to support Python 2.7.9 and older, no? It's hard to require an exact minor version on all platforms. The PEP 475 is wider than just the socket module: https://docs.python.org/dev/whatsnew/3.5.html#changes-in-the-python-api Impacted Python modules: io, os, select, socket, time. (Python 2.7 don't have faulthandler and don't have signal.sigtimedwait() nor signal.sigwaitinfo() functions, so faulthandler and signal are not impacted in Python 2.7.) Do you want to fix all these modules? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 11:14:45 2015 From: report at bugs.python.org (Carol Willing) Date: Thu, 09 Apr 2015 09:14:45 +0000 Subject: [issue14218] include rendered output in addition to markup In-Reply-To: <1331111194.08.0.943407781198.issue14218@psf.upfronthosting.co.za> Message-ID: <1428570885.9.0.992180399316.issue14218@psf.upfronthosting.co.za> Changes by Carol Willing : ---------- nosy: +willingc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 11:22:24 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 09 Apr 2015 09:22:24 +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: <1428571344.37.0.817513851627.issue18383@psf.upfronthosting.co.za> Martin Panter added the comment: I tried issue18383_remove_dups_and_test.patch, but it doesn?t seem to fix the problem, and causes new test failures and warnings. Let me know if you want more info. Existing messages that I thought this was meant to fix: [372/393/5] test_warnings /media/disk/home/proj/python/cpython/Lib/test/test_warnings.py:100: UserWarning: FilterTests.test_ignore_after_default self.module.warn(message, UserWarning) /media/disk/home/proj/python/cpython/Lib/test/test_warnings.py:100: UserWarning: FilterTests.test_ignore_after_default self.module.warn(message, UserWarning) Warning -- warnings.filters was modified by test_warnings [. . .] 1 test altered the execution environment: test_warnings Three new failures: [ 12/393/1] test___all__ test test___all__ failed -- Traceback (most recent call last): File "/media/disk/home/proj/python/cpython/Lib/test/test___all__.py", line 105, in test_all self.check_all(modname) File "/media/disk/home/proj/python/cpython/Lib/test/test___all__.py", line 28, in check_all raise FailedImport(modname) File "/media/disk/home/proj/python/cpython/Lib/contextlib.py", line 66, in __exit__ next(self.gen) File "/media/disk/home/proj/python/cpython/Lib/test/support/__init__.py", line 1124, in _filterwarnings raise AssertionError("unhandled warning %s" % reraise[0]) AssertionError: unhandled warning {message : DeprecationWarning('stat_float_times() is deprecated',), category : 'DeprecationWarning', filename : '/media/disk/home/proj/python/cpython/Lib/test/test_os.py', lineno : 75, line : None} [. . .] [147/393/3] test_global test test_global failed -- multiple errors occurred; run in verbose mode for details [. . .] [240/393/5] test_pkgutil test test_pkgutil failed -- Traceback (most recent call last): File "/media/disk/home/proj/python/cpython/Lib/test/test_pkgutil.py", line 327, in test_importer_deprecated x = pkgutil.ImpImporter("") File "/media/disk/home/proj/python/cpython/Lib/contextlib.py", line 66, in __exit__ next(self.gen) File "/media/disk/home/proj/python/cpython/Lib/test/support/__init__.py", line 1124, in _filterwarnings raise AssertionError("unhandled warning %s" % reraise[0]) AssertionError: unhandled warning {message : PendingDeprecationWarning("the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses",), category : 'PendingDeprecationWarning', filename : '/media/disk/home/proj/python/cpython/Lib/importlib/_bootstrap.py', lineno : 321, line : None} [. . .] 5 tests failed: test___all__ test_distutils test_gdb test_global test_pkgutil (Ignore distutils and GDB; they normally fail for me.) New warnings, though I suspect they may be a side effect and not entirely the fault of the patch: [ 18/393/1] test_unittest [163/393/4] test_imp [169/393/4] test_importlib [205/393/4] test_modulefinder [220/393/4] test_os [241/393/5] test_platform [329/393/5] test_threaded_import [354/393/5] test_unicode ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 11:24:30 2015 From: report at bugs.python.org (Martin Panter) Date: Thu, 09 Apr 2015 09:24:30 +0000 Subject: [issue23377] HTTPResponse may drop buffer holding next response In-Reply-To: <1422881776.12.0.998068930599.issue23377@psf.upfronthosting.co.za> Message-ID: <1428571470.35.0.721474958836.issue23377@psf.upfronthosting.co.za> Martin Panter added the comment: http-buffer.v2.patch: * Merged with recent changes * Made the changes to the test suite slightly less intrusive. Unfortunately there are still a lot of changes left where mock sockets were being sent into the HTTPResponse constructor. ---------- Added file: http://bugs.python.org/file38875/http-buffer.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 12:46:12 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 09 Apr 2015 10:46:12 +0000 Subject: [issue23199] libpython27.a in amd64 release is 32-bit In-Reply-To: <1420764337.42.0.255694319213.issue23199@psf.upfronthosting.co.za> Message-ID: <1428576372.95.0.230847485941.issue23199@psf.upfronthosting.co.za> Steve Dower added the comment: Yep ---------- status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 12:50:31 2015 From: report at bugs.python.org (Steve Dower) Date: Thu, 09 Apr 2015 10:50:31 +0000 Subject: [issue21411] Enable Treat Warning as Error on 32-bit Windows In-Reply-To: <1398976216.25.0.391009605761.issue21411@psf.upfronthosting.co.za> Message-ID: <1428576631.18.0.453965054644.issue21411@psf.upfronthosting.co.za> Steve Dower added the comment: I think we should fix all the warnings, but turning this on is a great way to make the build bots red often. I believe they already go yellow for warnings, so people are somewhat informed, but I don't think we want to be more aggressive than that. Also, I know someone who has a patch coming that fixes most of these, so we can ignore this for a bit more and just get the fix that way if we want. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 12:51:34 2015 From: report at bugs.python.org (Tim Golden) Date: Thu, 09 Apr 2015 10:51:34 +0000 Subject: [issue21411] Enable Treat Warning as Error on 32-bit Windows In-Reply-To: <1428576631.18.0.453965054644.issue21411@psf.upfronthosting.co.za> Message-ID: <552659B2.5070907@timgolden.me.uk> Tim Golden added the comment: Sounds good to me. It's really a question as to the point where practicality beats purity... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 13:14:54 2015 From: report at bugs.python.org (koobs) Date: Thu, 09 Apr 2015 11:14:54 +0000 Subject: [issue23817] Consider FreeBSD like any other OS in SOVERSION In-Reply-To: <1427806007.43.0.118979455245.issue23817@psf.upfronthosting.co.za> Message-ID: <1428578094.14.0.0307031894507.issue23817@psf.upfronthosting.co.za> koobs added the comment: @haypo, if you could take care of the change in default, 3.4 and 2.7, we can backport the rest downstream. Thank you :) @bapt, can you create a separate issue to cover the "create foo.so.X' symlink" request, so python@ (freebsd team) can work to patch locally with an upstream reference ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 15:06:24 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 09 Apr 2015 13:06:24 +0000 Subject: [issue21411] Enable Treat Warning as Error on 32-bit Windows In-Reply-To: <1428576631.18.0.453965054644.issue21411@psf.upfronthosting.co.za> Message-ID: Zachary Ware added the comment: Steve Dower added the comment: > I think we should fix all the warnings, but turning this on is a great way to make the build bots red often. That is the obvious downside. On the other hand, we do have a very old open issue (though I don't have the number handy) in which Guido made clear that a build with no warnings on every possible platform would be ideal and is desired, and this would help make sure we stay there when we reach that point. > I believe they already go yellow for warnings, so people are somewhat informed, but I don't think we want to be more aggressive than that. The individual step is colored yellow, but not the whole build. So if you're just looking at the headings on the waterfall page, you'll never notice. I'm not sure if we can change that setting, but that might be a nicer solution. > Also, I know someone who has a patch coming that fixes most of these, so we can ignore this for a bit more and just get the fix that way if we want. Ok, that sounds good. When that issue opens, would you mind linking it as a dependency of this one? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 15:09:43 2015 From: report at bugs.python.org (Brett Cannon) Date: Thu, 09 Apr 2015 13:09:43 +0000 Subject: [issue23893] Forward-port future_builtins In-Reply-To: <1428530020.25.0.529453311381.issue23893@psf.upfronthosting.co.za> Message-ID: <1428584983.71.0.409638785784.issue23893@psf.upfronthosting.co.za> Brett Cannon added the comment: There's no need for the ImportError catch. If a builtin is missing then there is something seriously wrong and it shouldn't be made silent. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 15:18:15 2015 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 09 Apr 2015 13:18:15 +0000 Subject: [issue23894] lib2to3 doesn't recognize rb'...' as a raw byte string in Python 3 Message-ID: <1428585495.21.0.103830054834.issue23894@psf.upfronthosting.co.za> New submission from Eli Bendersky: lib2to3 tokenizes br'abc' as a single STRING token, but rb'abc' as two separate tokens (NAME "rb" and STRING 'abc') This is because pgen2/tokenize.py doesn't list rb'' as a viable prefix for a string, even though according to https://docs.python.org/3/reference/lexical_analysis.html it is ---------- keywords: easy messages: 240322 nosy: benjamin.peterson, eli.bendersky priority: normal severity: normal status: open title: lib2to3 doesn't recognize rb'...' as a raw byte string in Python 3 versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 15:20:48 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 13:20:48 +0000 Subject: [issue12082] Python/import.c still references fstat even with DONT_HAVE_FSTAT/!HAVE_FSTAT In-Reply-To: <1305503118.99.0.0671211382341.issue12082@psf.upfronthosting.co.za> Message-ID: <1428585648.33.0.628330768726.issue12082@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> resolved status: open -> closed superseder: -> Drop HAVE_FSTAT: require fstat() to compile/use Python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 15:23:27 2015 From: report at bugs.python.org (Eric V. Smith) Date: Thu, 09 Apr 2015 13:23:27 +0000 Subject: [issue23893] Forward-port future_builtins In-Reply-To: <1428530020.25.0.529453311381.issue23893@psf.upfronthosting.co.za> Message-ID: <1428585807.57.0.430369062769.issue23893@psf.upfronthosting.co.za> Eric V. Smith added the comment: I think Serhiy is saying that you don't need to implement future_builtins in 3.x, if your 2.7 and 3.x compatible code catches the ImportError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 15:34:35 2015 From: report at bugs.python.org (Alex Shkop) Date: Thu, 09 Apr 2015 13:34:35 +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: <1428586475.19.0.232324818792.issue18383@psf.upfronthosting.co.za> Alex Shkop added the comment: So, there are actually two issues, both of them causing the original warning. First issue was pointed out by Florent Xicluna. warnings.filterwarnings() method can create duplicates in warnings.filters. Second issue is that assertWarns() works incorrectly in test_warnings.py due to use of import_fresh_module(). This produced original warning even without -Wd flag. I attached a patch that fixes both issues for review. It includes a fix of previous patch, so no new warnings are produced. But perhaps we should separate these issues and create two patches. ---------- Added file: http://bugs.python.org/file38876/issue18383_assert_warns_and_dups.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 15:43:05 2015 From: report at bugs.python.org (Andrew Stormont) Date: Thu, 09 Apr 2015 13:43:05 +0000 Subject: [issue23895] PATCH: python socket module fails to build on Solaris when -zignore is in LDFLAGS Message-ID: <1428586985.69.0.885305793504.issue23895@psf.upfronthosting.co.za> New submission from Andrew Stormont: The socket module fails to build when -zignore is in LDFLAGS. This option changes the linker behaviour so it will only resolve against the libraries linked in explicitly instead of doing resolution recursively against their dependencies too. ---------- components: Build files: solaris-socket-zignore.diff keywords: patch messages: 240325 nosy: andy_js priority: normal severity: normal status: open title: PATCH: python socket module fails to build on Solaris when -zignore is in LDFLAGS type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file38877/solaris-socket-zignore.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 15:49:42 2015 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 09 Apr 2015 13:49:42 +0000 Subject: [issue23896] lib2to3 doesn't provide a grammar where exec is a function Message-ID: <1428587382.51.0.855590572872.issue23896@psf.upfronthosting.co.za> New submission from Eli Bendersky: lib2to3 helpfully provides pygram.python_grammar_no_print_statement for parsing Python 3 ('print' has the semantics of an identifier, not a keyword) However, the same courtesy is not extended to 'exec', which also turns from a statement to an identifier in Python 3. I'd propose adding something like python_grammar_no_print_and_exec_statement The name's a handful, but it's explicit and I can't think of anything else, given that we don't want to change the lib2to3 API at this time to rename these grammars using some other convention. ---------- components: Library (Lib) messages: 240326 nosy: eli.bendersky priority: normal severity: normal stage: needs patch status: open title: lib2to3 doesn't provide a grammar where exec is a function type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 15:49:58 2015 From: report at bugs.python.org (Eli Bendersky) Date: Thu, 09 Apr 2015 13:49:58 +0000 Subject: [issue23894] lib2to3 doesn't recognize rb'...' as a raw byte string in Python 3 In-Reply-To: <1428585495.21.0.103830054834.issue23894@psf.upfronthosting.co.za> Message-ID: <1428587398.67.0.248350155944.issue23894@psf.upfronthosting.co.za> Changes by Eli Bendersky : ---------- stage: -> needs patch type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 15:52:51 2015 From: report at bugs.python.org (Eric Snow) Date: Thu, 09 Apr 2015 13:52:51 +0000 Subject: [issue23731] Implement PEP 488 In-Reply-To: <1426944831.0.0.593089874415.issue23731@psf.upfronthosting.co.za> Message-ID: <1428587571.9.0.0790305548661.issue23731@psf.upfronthosting.co.za> Eric Snow added the comment: LGTM ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 16:15:35 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Apr 2015 14:15:35 +0000 Subject: [issue23897] Update Python 3 extension module porting guide Message-ID: <1428588935.72.0.479238222018.issue23897@psf.upfronthosting.co.za> New submission from Nick Coghlan: The extension module porting guide at https://docs.python.org/dev/howto/cporting.html should be updated with Linux distro porting experience. Barry's notes: https://wiki.python.org/moin/PortingToPy3k/BilingualQuickRef#Python_extension_modules Petr's compatibility helper tools: https://py3c.readthedocs.org ---------- assignee: barry messages: 240328 nosy: barry, bkabrda, doko, encukou, kushal.das, ncoghlan priority: normal severity: normal status: open title: Update Python 3 extension module porting guide _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 16:23:52 2015 From: report at bugs.python.org (Cyd Haselton) Date: Thu, 09 Apr 2015 14:23:52 +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: <1428589432.06.0.356491923913.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: FYI, running 'make clean' && make does not resolve the last reported issue. Trying 'make distclean' && ./configure && make. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 16:32:31 2015 From: report at bugs.python.org (Simon Hoinkis) Date: Thu, 09 Apr 2015 14:32:31 +0000 Subject: [issue23575] MIPS64 needs ffi's n32.S In-Reply-To: <1425400037.86.0.872792301422.issue23575@psf.upfronthosting.co.za> Message-ID: <1428589951.63.0.889446773061.issue23575@psf.upfronthosting.co.za> Simon Hoinkis added the comment: Could someone review this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 16:34:46 2015 From: report at bugs.python.org (mike bayer) Date: Thu, 09 Apr 2015 14:34:46 +0000 Subject: [issue23898] inspect() changes in Python3.4 are not compatible with objects that implement special __bool__, __eq__ Message-ID: <1428590086.18.0.0932223784087.issue23898@psf.upfronthosting.co.za> New submission from mike bayer: this bug appeared in Python 3.4. The inspect.classify_class_attrs compares the identity objects of unknown type using the `==` operator unnecessarily and also evaluates objects of unknown type assuming they return `True` for a straight boolean evaluation. This breaks among other things the ability to use the help() function with SQLAlchemy mapped objects. Demo: class MySpecialObject(object): def __eq__(self, other): return MySpecialObject() def __bool__(self): raise NotImplementedError( "This object does not specify a boolean value") class MyClass(object): some_thing = MySpecialObject() import inspect print(inspect.classify_class_attrs(MyClass)) # ultimate goal: help(MyClass) A patch here would be to compare unknown objects for identity using the `is` operator as well as using `is not None` when asserting that an object of unknown type is non-None. This patch resolves: --- inspect_orig.py 2015-04-09 10:28:46.000000000 -0400 +++ inspect.py 2015-04-09 10:29:37.000000000 -0400 @@ -380,7 +380,7 @@ # first look in the classes for srch_cls in class_bases: srch_obj = getattr(srch_cls, name, None) - if srch_obj == get_obj: + if srch_obj is get_obj: last_cls = srch_cls # then check the metaclasses for srch_cls in metamro: @@ -388,7 +388,7 @@ srch_obj = srch_cls.__getattr__(cls, name) except AttributeError: continue - if srch_obj == get_obj: + if srch_obj is get_obj: last_cls = srch_cls if last_cls is not None: homecls = last_cls @@ -402,7 +402,7 @@ # unable to locate the attribute anywhere, most likely due to # buggy custom __dir__; discard and move on continue - obj = get_obj or dict_obj + obj = get_obj if get_obj is not None else dict_obj # Classify the object or its descriptor. if isinstance(dict_obj, staticmethod): kind = "static method" ---------- components: Library (Lib) messages: 240331 nosy: zzzeek priority: normal severity: normal status: open title: inspect() changes in Python3.4 are not compatible with objects that implement special __bool__, __eq__ versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 16:39:59 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 09 Apr 2015 14:39:59 +0000 Subject: [issue23898] inspect() changes in Python3.4 are not compatible with objects that implement special __bool__, __eq__ In-Reply-To: <1428590086.18.0.0932223784087.issue23898@psf.upfronthosting.co.za> Message-ID: <1428590399.32.0.235559226158.issue23898@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 16:47:20 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 14:47:20 +0000 Subject: [issue22144] ellipsis needs better display in lexer documentation In-Reply-To: <1407256210.06.0.54083612565.issue22144@psf.upfronthosting.co.za> Message-ID: <1428590840.41.0.832542692515.issue22144@psf.upfronthosting.co.za> R. David Murray added the comment: I agree that there is nothing to do here. The ... does not belong in the table, since as Martin says it is a literal, not a delimiter. In theory you could create a whole new section named 'elipsis literal' above the delmiiters section, but that hardly seems worthwhile, specially since the mention of the special elipsis literal makes more *sense* exactly where it is, after one learns that the period is a delimiter. ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 16:54:57 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 14:54:57 +0000 Subject: [issue8841] getopt errors should be specialized In-Reply-To: <1275007450.32.0.944656023036.issue8841@psf.upfronthosting.co.za> Message-ID: <1428591297.75.0.0983895706234.issue8841@psf.upfronthosting.co.za> R. David Murray added the comment: A python-ideas discussion was requested, but none has been linked to. So let's close this as uneeded. It can always be reopened if there is renewed interest. ---------- nosy: +r.david.murray resolution: -> rejected stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 16:59:12 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Apr 2015 14:59:12 +0000 Subject: [issue19247] Describe surrogateescape algorithm in the Library Reference In-Reply-To: <1381673577.83.0.634006615694.issue19247@psf.upfronthosting.co.za> Message-ID: <1428591552.15.0.584964236743.issue19247@psf.upfronthosting.co.za> Nick Coghlan added the comment: The last round of updates to the codecs module docs covered the relevant details in the new error handlers section: https://docs.python.org/3/library/codecs.html#error-handlers ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 17:05:14 2015 From: report at bugs.python.org (Joshua Bronson) Date: Thu, 09 Apr 2015 15:05:14 +0000 Subject: [issue23894] lib2to3 doesn't recognize rb'...' as a raw byte string in Python 3 In-Reply-To: <1428585495.21.0.103830054834.issue23894@psf.upfronthosting.co.za> Message-ID: <1428591914.33.0.842230359859.issue23894@psf.upfronthosting.co.za> Changes by Joshua Bronson : ---------- nosy: +jab _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 17:20:43 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 15:20:43 +0000 Subject: [issue23898] inspect() changes in Python3.4 are not compatible with objects that implement special __bool__, __eq__ In-Reply-To: <1428590086.18.0.0932223784087.issue23898@psf.upfronthosting.co.za> Message-ID: <1428592843.91.0.761380720485.issue23898@psf.upfronthosting.co.za> R. David Murray added the comment: This looks reasonable to me. It would be great if the patch could be attached to the issue as a patch file, including some tests. ---------- nosy: +r.david.murray stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 17:21:59 2015 From: report at bugs.python.org (Matthew Gamble) Date: Thu, 09 Apr 2015 15:21:59 +0000 Subject: [issue6818] remove/delete method for zipfile/tarfile objects In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za> Message-ID: <1428592919.73.0.650964401403.issue6818@psf.upfronthosting.co.za> Matthew Gamble added the comment: Hi, I've recently been working on a Python module for the Adobe universal container format (UCF) which extends the zip specification - as part of this I wanted to be able to remove and rename files in an archive. I discovered this issue when writing the module so realised there wasn't currently a solution - so I went down the rabbit hole. I've attached a patch which supports the removal and renaming of files in a zip archive. You can also look at this python module in a git-repo which is a the same code but separated out into a class that extends ZipFile: https://github.com/gambl/zipextended. The patch provides 4 main new "public" functions for the zipfile library: - remove(self, zinfo_or_arcname): - rename(self, zinfo_or_arcname, filename): - commit(self): - clone(self, file, filenames_or_infolist=None, ignore_hidden_files=False) The patch is in part modelled on the rubyzip solution. Remove and rename will initially only update the ZipFile's infolist. Changes are then persisted via a commit function which can be called manually - or will be called automatically upon close. Commit will then clone the zipfile with the necessary changes to a temporary file and replace the original file when that operation has completed successfully. An alternative to remove files without modifying the original is via the clone method directly. This is in the spirit of Serhiy's suggestion of filtering the content and not modifying the original. You can pass a list of filenames or fileinfos of the files to be included in the clone. So that clone can be performed without decompressing and then recompressing the files in the archive I have added two functions write_compressed and read_compressed. I have also attempted to address Serhiy's concern with respect to the tricky.zip - "hidden files" in between members of the archive. The clone method will by default retain any hidden files and maintain the same relative order in the archive. You can also elect to ignore the hidden files, and clone with just the files listed in the central directory. I did have to modify the tricky.zip attached to this issue manually as the CRC of file two (with file three embedded) was incorrect - and would therefore fail testzip(). I'm not actually sure how one would create such an archive - but I think that it's valid according to the zip spec. I've actually included the modified version in the patch for a few of the tests. I appreciate that this is a large-ish patch and may take some time to review - but as suggested in the comments - this wasn't as straight forward as is seems! Look forward to your comments. The signatures of the main functions are described below: remove(self, zinfo_or_arcname): Remove a member from the archive. Args: zinfo_or_arcname (ZipInfo, str) ZipInfo object or filename of the member. Raises: RuntimeError: If attempting to modify an Zip archive that is closed. --- rename(self, zinfo_or_arcname, filename): Rename a member in the archive. Args: zinfo_or_arcname (ZipInfo, str): ZipInfo object or filename of the member. filename (str): the new name for the member. Raises: RuntimeError: If attempting to modify an Zip archive that is closed. clone(self, file, filenames_or_infolist=None, ignore_hidden_files=False): Clone the a zip file using the given file (filename or filepointer). Args: file (File, str): file-like object or filename of file to write the new zip file to. filenames_or_infolist (list(str), list(ZipInfo), optional): list of members from this zip file to include in the new zip file. ignore_hidden_files (boolean): flag to indicate wether hidden files (data inbetween managed memebers of the archive) should be included. Returns: A new ZipFile object of the cloned zipfile open in append mode. If copying hidden files then clone will attempt to maintain the relative order between the files and members in the archive commit(self): Commit any inline modifications (removal and rename) to the zip archive. This makes use of a temporary file to create a new zip archive with the required modifications and then replaces the original. This therefore requires write access to either the directory where the original zipfile lives, or to python's default tempfile location. ---------- nosy: +gambl Added file: http://bugs.python.org/file38878/zipfile.remove_rename.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 17:23:41 2015 From: report at bugs.python.org (mike bayer) Date: Thu, 09 Apr 2015 15:23:41 +0000 Subject: [issue23898] inspect() changes in Python3.4 are not compatible with objects that implement special __bool__, __eq__ In-Reply-To: <1428590086.18.0.0932223784087.issue23898@psf.upfronthosting.co.za> Message-ID: <1428593021.97.0.259128335128.issue23898@psf.upfronthosting.co.za> mike bayer added the comment: > It would be great if the patch could be attached to the issue as a patch file, including some tests. the mantra we all share. I'll take a look. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 17:23:42 2015 From: report at bugs.python.org (Matthew Gamble) Date: Thu, 09 Apr 2015 15:23:42 +0000 Subject: [issue6818] remove/delete method for zipfile/tarfile objects In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za> Message-ID: <1428593022.52.0.43217274117.issue6818@psf.upfronthosting.co.za> Changes by Matthew Gamble : Added file: http://bugs.python.org/file38879/zip_hiddenfiles.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 17:24:24 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Thu, 09 Apr 2015 15:24:24 +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: <1428593064.92.0.98114013383.issue23496@psf.upfronthosting.co.za> Ryan Gonzalez added the comment: Ack...I feel smart. Attached is kind of a "part 2" to the rjmatthews patch. Apply and the errors shall be solved. :) ---------- Added file: http://bugs.python.org/file38880/rjmatthews64_fixes2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 17:33:02 2015 From: report at bugs.python.org (Cyd Haselton) Date: Thu, 09 Apr 2015 15:33:02 +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: <1428593582.32.0.386675673119.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Thanks Ryan. (Probably should remove original androidfn.h patch; patch complains with 'file already exists' if I don't delete Include/androidfn.h before applying the latest patch) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 17:36:07 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 15:36:07 +0000 Subject: [issue19835] Add a MemoryError singleton to fix an unlimited loop when the memory is exhausted In-Reply-To: <1385745842.98.0.409110544048.issue19835@psf.upfronthosting.co.za> Message-ID: <1428593767.02.0.977584376652.issue19835@psf.upfronthosting.co.za> R. David Murray added the comment: Victor, do you still want to champion this, or shall we close it? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 17:36:23 2015 From: report at bugs.python.org (Jason R. Coombs) Date: Thu, 09 Apr 2015 15:36:23 +0000 Subject: [issue23899] HTTP regression in distutils uploads to chishop Message-ID: <1428593783.07.0.14236214587.issue23899@psf.upfronthosting.co.za> New submission from Jason R. Coombs: Beginning with Python 2.7.9 and 3.4.3, distutils uploads to chishop (https://pypi.python.org/pypi/chishop) now fail with a 501 NOT IMPLEMENTED. This error looks very similar to the error that Twine triggered in https://github.com/pypa/twine/issues/27. I acknowledge that chishop is old and probably abandoned, but I also expect that a minor update (such as 3.4.2 to 3.4.3) should not break. I understand that 2.7.9 may have special consideration in this regard, so I'll focus on 3.4.3. I expect these changes in protocol may also affect other HTTP services, though it may be isolated to distutils uploads. Donald, can you speak to changes in Python 3.4.3 that might have behavior in common with Twine that would have affected distutils uploads? ---------- components: Distutils keywords: 3.4regression messages: 240341 nosy: dstufft, eric.araujo, jason.coombs priority: normal severity: normal status: open title: HTTP regression in distutils uploads to chishop versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 17:38:29 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Thu, 09 Apr 2015 15:38:29 +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: <1428593909.75.0.906938403138.issue23496@psf.upfronthosting.co.za> Ryan Gonzalez added the comment: Whoops. Updated the patch. ---------- Added file: http://bugs.python.org/file38881/rjmatthews64_fixes2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 17:41:58 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 15:41:58 +0000 Subject: [issue20660] Starting a second multiprocessing.Manager causes INCREF on all object created by the first one. In-Reply-To: <1392652025.76.0.144236203024.issue20660@psf.upfronthosting.co.za> Message-ID: <1428594118.34.0.957834071334.issue20660@psf.upfronthosting.co.za> R. David Murray added the comment: Based on Richard's comments I'm closing this won't fix. If someone comes up with a clever solution, we can reopen. ---------- nosy: +r.david.murray resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 17:42:56 2015 From: report at bugs.python.org (mike bayer) Date: Thu, 09 Apr 2015 15:42:56 +0000 Subject: [issue23898] inspect() changes in Python3.4 are not compatible with objects that implement special __bool__, __eq__ In-Reply-To: <1428590086.18.0.0932223784087.issue23898@psf.upfronthosting.co.za> Message-ID: <1428594176.18.0.676891311085.issue23898@psf.upfronthosting.co.za> mike bayer added the comment: patch w/ test ---------- keywords: +patch Added file: http://bugs.python.org/file38882/issue23898.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 17:49:50 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Thu, 09 Apr 2015 15:49:50 +0000 Subject: [issue6818] remove/delete method for zipfile/tarfile objects In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za> Message-ID: <1428594590.06.0.237601099686.issue6818@psf.upfronthosting.co.za> Terry J. Reedy added the comment: All of you who have or might submit patches -- Victorlee, Troy, Mathew, or anyone else, please sign a PSF contributor agreement. We should not even look at a patch from you before you do. Info: https://www.python.org/psf/contrib/ Form: https://www.python.org/psf/contrib/contrib-form/ Receipt is official when a * appears after your name. This usually takes about a week. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 17:57:34 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 15:57:34 +0000 Subject: [issue13238] Add shell command helpers to subprocess module In-Reply-To: <1319176813.33.0.203455355645.issue13238@psf.upfronthosting.co.za> Message-ID: <1428595054.03.0.011496447827.issue13238@psf.upfronthosting.co.za> R. David Murray added the comment: Having reviewed this issue, I don't see any point to leaving it open. If any additional shell command helpers are added to the stdlib, it should be an ab-initio discussion based on what exists in the field, and start on python-ideas. But given current sentiments about the stdlib, I doubt this is something we are likely to do in any case. ---------- resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 18:20:01 2015 From: report at bugs.python.org (Jeff McNeil) Date: Thu, 09 Apr 2015 16:20:01 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1428596401.08.0.416709523669.issue23863@psf.upfronthosting.co.za> Jeff McNeil added the comment: Updated to recalculate timeout at Python level. The current module already works this way on recv() calls. See attached. I'd be happy to churn through and fix the other modules (using the 3.5 work as a guide), though I think only addressing the higher level abstractions makes sense (I think that's been noted elsewhere). For example, the _fileobject wrappers, but not the recv from sock_recv_guts. ---------- Added file: http://bugs.python.org/file38883/socket_eintr.3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 18:24:32 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 16:24:32 +0000 Subject: [issue23898] inspect() changes in Python3.4 are not compatible with objects that implement special __bool__, __eq__ In-Reply-To: <1428590086.18.0.0932223784087.issue23898@psf.upfronthosting.co.za> Message-ID: <1428596672.62.0.932358168404.issue23898@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 18:42:37 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Apr 2015 16:42:37 +0000 Subject: [issue23900] Add a default docstring to Enum subclasses Message-ID: <1428597757.76.0.767487050149.issue23900@psf.upfronthosting.co.za> New submission from Nick Coghlan: Issue #15582 added docstring inheritance to the inspect module. This means that Enum subclasses without their own docstring now inherit the generic docstring from the base class definition: >>> import enum, inspect >>> class MyEnum(enum.Enum): ... a = 1 ... >>> inspect.getdoc(MyEnum) 'Generic enumeration.\n\nDerive from this class to define new enumerations.' Perhaps the metaclass could automatically derive a more suitable docstring if the subclass doesn't set one of its own? ---------- messages: 240348 nosy: barry, eli.bendersky, ethan.furman, ncoghlan, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Add a default docstring to Enum subclasses type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 18:43:59 2015 From: report at bugs.python.org (Nick Coghlan) Date: Thu, 09 Apr 2015 16:43:59 +0000 Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za> Message-ID: <1428597839.24.0.892251640769.issue15582@psf.upfronthosting.co.za> Nick Coghlan added the comment: I filed issue #23900 to consider the question of the default docstring for Enum subclasses. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 18:56:06 2015 From: report at bugs.python.org (Cyd Haselton) Date: Thu, 09 Apr 2015 16:56:06 +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: <1428598566.04.0.439913284238.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Hello Ryan, Error from latest patch: Python/pythonrun.c:44:8: error: conflicting types for 'android_mbstowcs' size_t android_mbstowcs(wchar_t *dest, char * in, int maxlen) { ^ In file included from Python/pythonrun.c:18:0: Include/androidfn.h:10:8: note: previous declaration of 'android_mbstowcs' was here size_t android_mbstowcs(wchar_t *dest, const char * source, int maxlen); ^ Python/pythonrun.c:61:8: error: conflicting types for 'android_wcstombs' size_t android_wcstombs(char * dest, wchar_t *source, int maxlen) ^ In file included from Python/pythonrun.c:18:0: Include/androidfn.h:9:8: note: previous declaration of 'android_wcstombs' was here size_t android_wcstombs(char * dest, const wchar_t *source, int maxlen); ^ Python/pythonrun.c: In function 'android_wcstombs': Python/pythonrun.c:68:5: error: expected ';' before 'if' if (c >= 0xdc800 && c <= 0xdcff) ^ Python/pythonrun.c:63:11: warning: variable 'c' set but not used [-Wunused-but-set-variable] wchar_t c; ^ make: *** [Python/pythonrun.o] Error 1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 19:02:56 2015 From: report at bugs.python.org (Cyd Haselton) Date: Thu, 09 Apr 2015 17:02:56 +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: <1428598976.38.0.0726205173093.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Perhaps the 'include androidfn.h' should be removed from pythonrun.c? Or the function definition added to the androidfn.h? (IANACC) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 19:07:28 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Thu, 09 Apr 2015 17:07:28 +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: <1428599248.06.0.843115856264.issue23496@psf.upfronthosting.co.za> Ryan Gonzalez added the comment: ARGH! Fixed. Re-apply rjmatthews64_fixes2.patch. ---------- Added file: http://bugs.python.org/file38884/rjmatthews64_fixes2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 19:07:35 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Apr 2015 17:07:35 +0000 Subject: [issue19835] Add a MemoryError singleton to fix an unlimited loop when the memory is exhausted In-Reply-To: <1385745842.98.0.409110544048.issue19835@psf.upfronthosting.co.za> Message-ID: <1428599255.73.0.897448508465.issue19835@psf.upfronthosting.co.za> STINNER Victor added the comment: Serhiy recently worked on MemoryError, maybe he wants to work on this issue? I'm no more interested to work on this issue. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 19:22:37 2015 From: report at bugs.python.org (Paul Moore) Date: Thu, 09 Apr 2015 17:22:37 +0000 Subject: [issue23901] Force console stdout to use UTF8 on Windows Message-ID: <1428600157.62.0.0673126456323.issue23901@psf.upfronthosting.co.za> New submission from Paul Moore: Console code page issues are a consistent source of problems on Windows. It would be nice, given that the Windows console has Unicode support, if Python could write the full range of Unicode to the console by default. The MSVC runtime appears to have a flag that can be set via _setmode(), _O_U8TEXT, which "enables Unicode mode" (see https://msdn.microsoft.com/en-us/library/tw4k6df8%28v=vs.100%29.aspx?f=255&MSPPError=-2147217396, in particular the second example). It seems as if Python could set U8TEXT mode on sys.stdout on startup (assuming it's a console) and set the encoding to UTF8, and then Unicode output would "just work". I don't have code that implements this yet, but if I can get my head round the IO stack and the Python startup code, I'll give it a go. Steve - any comments on whether this might work? I've never seen any real-world code using U8TEXT which makes me wonder if it's reliable (doing msvcrt.setmode(sys.stdout.fileno(), 0x40000) in Python 3.4 causes Python to crash, which is worrying, but it works in 3.5...). ---------- assignee: paul.moore components: Windows messages: 240354 nosy: paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Force console stdout to use UTF8 on Windows versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 19:26:41 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 17:26:41 +0000 Subject: [issue5885] uuid.uuid1() is too slow In-Reply-To: <1241086416.5.0.850110966894.issue5885@psf.upfronthosting.co.za> Message-ID: <1428600401.12.0.839282202021.issue5885@psf.upfronthosting.co.za> R. David Murray added the comment: The original report says the ctypes call is slower than the python code used as a fallback. Would it not, then, be a performance improvement just to drop the ctypes call, without creating a new C module? Creating a C module would then be a separate enhancement issue if someone thought the performance improvement was enough to justify the module. Or maybe it could live in the os module? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 19:28:31 2015 From: report at bugs.python.org (Cyd Haselton) Date: Thu, 09 Apr 2015 17:28:31 +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: <1428600511.41.0.299454867107.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Hmmmm. That patch failed to apply: Possibly reversed hunk 1 at 1582 Hunk 1 failed 35/35 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 19:34:35 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Thu, 09 Apr 2015 17:34:35 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1428600511.41.0.299454867107.issue23496@psf.upfronthosting.co.za> Message-ID: Ryan Gonzalez added the comment: Maybe it's conflicted with the last one... Try: git checkout Python/pythonrun.c git apply rjmatthews... On Thu, Apr 9, 2015 at 12:28 PM, Cyd Haselton wrote: > > Cyd Haselton added the comment: > > Hmmmm. That patch failed to apply: > > Possibly reversed hunk 1 at 1582 > Hunk 1 failed 35/35 > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 19:34:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Apr 2015 17:34:59 +0000 Subject: [issue5885] uuid.uuid1() is too slow In-Reply-To: <1241086416.5.0.850110966894.issue5885@psf.upfronthosting.co.za> Message-ID: <1428600899.21.0.573754557375.issue5885@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue11063 and issue20519. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 19:38:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Apr 2015 17:38:49 +0000 Subject: [issue5885] uuid.uuid1() is too slow In-Reply-To: <1241086416.5.0.850110966894.issue5885@psf.upfronthosting.co.za> Message-ID: <1428601129.35.0.257532644032.issue5885@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And issue15206. Python implementation has a drawback. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 19:40:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Apr 2015 17:40:12 +0000 Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za> Message-ID: <1428601212.14.0.104464370677.issue15582@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 Thu Apr 9 19:41:38 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 17:41:38 +0000 Subject: [issue2276] distutils out-of-date for runtime_library_dirs flag on OS X In-Reply-To: <1205290203.53.0.517851484238.issue2276@psf.upfronthosting.co.za> Message-ID: <1428601298.07.0.750346544811.issue2276@psf.upfronthosting.co.za> R. David Murray added the comment: Since no example was forthcomming, let's close this. ---------- nosy: +r.david.murray resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 19:44:25 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 17:44:25 +0000 Subject: [issue18965] 2to3 can produce illegal bytes literals In-Reply-To: <1378598799.8.0.0499553446902.issue18965@psf.upfronthosting.co.za> Message-ID: <1428601465.15.0.469807555641.issue18965@psf.upfronthosting.co.za> R. David Murray added the comment: Does the addition of the warning in python3 make the fixer obsolete? In other words, should we close this issue? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 20:06:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Apr 2015 18:06:08 +0000 Subject: [issue18965] 2to3 can produce illegal bytes literals In-Reply-To: <1378598799.8.0.0499553446902.issue18965@psf.upfronthosting.co.za> Message-ID: <1428602768.33.0.0324020651265.issue18965@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The addition of the warning in python3 is not related to this issue, because produced code even is not compiled in Python 3. But the addition of the warning in Python 2 made this issue less important. ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 20:51:15 2015 From: report at bugs.python.org (Cyd Haselton) Date: Thu, 09 Apr 2015 18:51:15 +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: <1428605475.51.0.011628142903.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Done, but got this error: Python/pythonrun.c: In function 'android_wcstombs': Python/pythonrun.c:67:5: error: expected ';' before 'if' if (c >= 0xdc800 && c <= 0xdcff) ^ Python/pythonrun.c:62:11: warning: variable 'c' set but not used [-Wunused-but-set-variable] wchar_t c; ^ make: *** [Python/pythonrun.o] Error 1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 21:09:36 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 19:09:36 +0000 Subject: [issue9248] multiprocessing.pool: Proposal: "waitforslot" In-Reply-To: <1279028823.93.0.963356654708.issue9248@psf.upfronthosting.co.za> Message-ID: <1428606576.62.0.822264150706.issue9248@psf.upfronthosting.co.za> R. David Murray added the comment: Closed per OP's request. ---------- nosy: +r.david.murray resolution: -> out of date stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 21:12:08 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 19:12:08 +0000 Subject: [issue15011] Change Scripts to bin on Windows In-Reply-To: <1338952995.87.0.980800482386.issue15011@psf.upfronthosting.co.za> Message-ID: <1428606728.22.0.362714503952.issue15011@psf.upfronthosting.co.za> R. David Murray added the comment: Per Steve, closing as rejected. (Rejecting this patch, any change would be part of a larger patch dealing also with other issues). ---------- nosy: +r.david.murray resolution: -> rejected stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 21:13:08 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Thu, 09 Apr 2015 19:13:08 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1428605475.51.0.011628142903.issue23496@psf.upfronthosting.co.za> Message-ID: Ryan Gonzalez added the comment: I put a fix in the patch; I don't know why the heck it didn't apply. Just go to Python/pythonrun.c, line 66 and put a semicolon (;) at the end of the line. On Thu, Apr 9, 2015 at 1:51 PM, Cyd Haselton wrote: > > Cyd Haselton added the comment: > > Done, but got this error: > > Python/pythonrun.c: In function 'android_wcstombs': > Python/pythonrun.c:67:5: error: expected ';' before 'if' > if (c >= 0xdc800 && c <= 0xdcff) > ^ > Python/pythonrun.c:62:11: warning: variable 'c' set but not used > [-Wunused-but-set-variable] > wchar_t c; > ^ > make: *** [Python/pythonrun.o] Error 1 > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 21:24:12 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 19:24:12 +0000 Subject: [issue7159] Urllib2 authentication memory. In-Reply-To: <1255793559.46.0.185389780208.issue7159@psf.upfronthosting.co.za> Message-ID: <1428607452.76.0.105841755983.issue7159@psf.upfronthosting.co.za> R. David Murray added the comment: See also issue 19494. I think this would be a new feature, and it may be that it should leverge the feature added in issue 19494. The difference here is that we are proposing to allow it to happen automatically after the initial 401, whereas in 19494 we send it pre-emptively even on the first call. ---------- nosy: +r.david.murray stage: -> needs patch type: resource usage -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 21:25:33 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 09 Apr 2015 19:25:33 +0000 Subject: [issue7511] msvc9compiler.py: ValueError when trying to compile with VC Express In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za> Message-ID: <1428607533.79.0.721643719299.issue7511@psf.upfronthosting.co.za> Zachary Ware added the comment: Considering the consensus somewhere in the middle of this discussion that this is not a Python bug, the unavailability of VS2008 Express, and the availability of the Visual C++ Compiler for Python 2.7 package, I'm closing this as 'wont fix'. If anyone just absolutely can't be satisfied by Visual C++ Compiler for Python 2.7, you can reopen. ---------- resolution: -> wont fix stage: patch review -> resolved status: open -> closed versions: -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 21:36:19 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 09 Apr 2015 19:36:19 +0000 Subject: [issue23893] Forward-port future_builtins In-Reply-To: <1428530020.25.0.529453311381.issue23893@psf.upfronthosting.co.za> Message-ID: <1428608179.67.0.424602118373.issue23893@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Already exists on PyPI: https://pypi.python.org/pypi/future/ ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 21:45:42 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 09 Apr 2015 19:45:42 +0000 Subject: [issue23898] inspect() changes in Python3.4 are not compatible with objects that implement special __bool__, __eq__ In-Reply-To: <1428590086.18.0.0932223784087.issue23898@psf.upfronthosting.co.za> Message-ID: <1428608742.54.0.308763530107.issue23898@psf.upfronthosting.co.za> Yury Selivanov added the comment: The patch looks good, Mike. Could you please sign PSF Contributor Agreement? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 21:46:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Apr 2015 19:46:33 +0000 Subject: [issue23686] Update Windows and OS X installer OpenSSL to 1.0.2a In-Reply-To: <1426591782.15.0.995555672449.issue23686@psf.upfronthosting.co.za> Message-ID: <20150409194629.8631.6261@psf.io> Roundup Robot added the comment: New changeset 05a502da108f by Zachary Ware in branch '2.7': Issue #23686: Update Windows build to use OpenSSL 1.0.2a https://hg.python.org/cpython/rev/05a502da108f New changeset 404e4adf492c by Zachary Ware in branch '3.4': Issue #23686: Update Windows build to use OpenSSL 1.0.2a. https://hg.python.org/cpython/rev/404e4adf492c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 21:48:58 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 09 Apr 2015 19:48:58 +0000 Subject: [issue23686] Update Windows and OS X installer OpenSSL to 1.0.2a In-Reply-To: <1426591782.15.0.995555672449.issue23686@psf.upfronthosting.co.za> Message-ID: <1428608938.64.0.711218167169.issue23686@psf.upfronthosting.co.za> Zachary Ware added the comment: I've updated 2.7 and 3.4, but 3.5 is a different matter. Steve, I'll want to take a look at it with you at the sprints; 1.0.2 changed enough that the projects you wrote for OpenSSL broke. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 21:54:40 2015 From: report at bugs.python.org (mike bayer) Date: Thu, 09 Apr 2015 19:54:40 +0000 Subject: [issue23898] inspect() changes in Python3.4 are not compatible with objects that implement special __bool__, __eq__ In-Reply-To: <1428590086.18.0.0932223784087.issue23898@psf.upfronthosting.co.za> Message-ID: <1428609280.44.0.477866796745.issue23898@psf.upfronthosting.co.za> mike bayer added the comment: hi Yury - I did sign it earlier today. It should have been sent off to the person that manages that, at least that's what the email receipt said. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 21:56:23 2015 From: report at bugs.python.org (Yury Selivanov) Date: Thu, 09 Apr 2015 19:56:23 +0000 Subject: [issue23898] inspect() changes in Python3.4 are not compatible with objects that implement special __bool__, __eq__ In-Reply-To: <1428590086.18.0.0932223784087.issue23898@psf.upfronthosting.co.za> Message-ID: <1428609383.75.0.541390834394.issue23898@psf.upfronthosting.co.za> Yury Selivanov added the comment: Mike, please ping me when they process it. I'll commit your patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 22:10:51 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 20:10:51 +0000 Subject: [issue23901] Force console stdout to use UTF8 on Windows In-Reply-To: <1428600157.62.0.0673126456323.issue23901@psf.upfronthosting.co.za> Message-ID: <1428610251.65.0.393323646458.issue23901@psf.upfronthosting.co.za> R. David Murray added the comment: There are a lot of issues in this tracker (for some definition of a lot) that indicate that the console does *not* support unicode. So if you are writing utf-8 I wouldn't expect this to work. (If it were an API taking unicode directly, that might be a different story). But the amount I know about windows is pretty small, so I sure hope you are right ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 22:14:13 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 20:14:13 +0000 Subject: [issue18965] 2to3 can produce illegal bytes literals In-Reply-To: <1378598799.8.0.0499553446902.issue18965@psf.upfronthosting.co.za> Message-ID: <1428610453.96.0.473646358768.issue18965@psf.upfronthosting.co.za> R. David Murray added the comment: Sorry, I meant the addition of the -3 warning. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 22:18:28 2015 From: report at bugs.python.org (Travis Everett) Date: Thu, 09 Apr 2015 20:18:28 +0000 Subject: [issue23902] let exception react to being raised or the setting of magic properties (like __cause__) within Python Message-ID: <1428610708.13.0.662863454956.issue23902@psf.upfronthosting.co.za> New submission from Travis Everett: I've been working on a testing tool which raises its own exceptions from those thrown by code under test. The tool's exceptions do some analysis to categorize and add additional information to the underlying exceptions, and they need access to the __cause__ property in order to build this information. Unfortunately, because the __cause__ property isn't available on the exception objects at init time, some number of workarounds must be employed which make the exception harder to use properly and code handling it less intuitive. While the workarounds are fine at the moment, it would be ideal if the exceptions could be notified instead of burdening the site of each use with workarounds. It seems sufficient to call a magic method on the exception immediately after these the traceback/cause/context parameters have been set while it is being raised, allowing the exception to perform any essential work. A bells-and-whistles implementation might be a magic method called at raise time with all of these properties as arguments (and the responsibility to deal with them)--but I assume there are reasons exception objects don't already have this level of control. ---------- messages: 240377 nosy: abathur priority: normal severity: normal status: open title: let exception react to being raised or the setting of magic properties (like __cause__) within Python type: enhancement versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 22:21:54 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Apr 2015 20:21:54 +0000 Subject: [issue23901] Force console stdout to use UTF8 on Windows In-Reply-To: <1428600157.62.0.0673126456323.issue23901@psf.upfronthosting.co.za> Message-ID: <1428610914.23.0.413833632192.issue23901@psf.upfronthosting.co.za> STINNER Victor added the comment: > There are a lot of issues in this tracker (for some definition of a lot) that indicate that the console does *not* support unicode. The main issue is the issue #1602. ---------- nosy: +haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 22:22:34 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 20:22:34 +0000 Subject: [issue23902] let exception react to being raised or the setting of magic properties (like __cause__) within Python In-Reply-To: <1428610708.13.0.662863454956.issue23902@psf.upfronthosting.co.za> Message-ID: <1428610954.96.0.732761437379.issue23902@psf.upfronthosting.co.za> R. David Murray added the comment: Can't you use a __setattr__ hook? Your use case seems pretty specialized. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 22:24:17 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Apr 2015 20:24:17 +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: <1428611057.82.0.812261598383.issue22970@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Cancelling wait() after notification leaves Condition in an inconsistent state -> asyncio: Cancelling wait() after notification leaves Condition in an inconsistent state _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 22:30:02 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 09 Apr 2015 20:30:02 +0000 Subject: [issue23817] Consider FreeBSD like any other OS in SOVERSION In-Reply-To: <1427806007.43.0.118979455245.issue23817@psf.upfronthosting.co.za> Message-ID: <20150409202959.21283.72079@psf.io> Roundup Robot added the comment: New changeset 7444ac6d93c3 by Victor Stinner in branch 'default': Issue #23817: FreeBSD now uses "1.0" the the SOVERSION as other operating https://hg.python.org/cpython/rev/7444ac6d93c3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 22:31:53 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Apr 2015 20:31:53 +0000 Subject: [issue23817] Consider FreeBSD like any other OS in SOVERSION In-Reply-To: <1427806007.43.0.118979455245.issue23817@psf.upfronthosting.co.za> Message-ID: <1428611513.81.0.168515375173.issue23817@psf.upfronthosting.co.za> STINNER Victor added the comment: > Let's just do it for next python Ok. I don't understand the purpose of SOVERSION, nor why it is an issue to not use dots on FreeBSD. So I don't want to change it in minor Python relases (2.7.x, 3.4.y). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 22:34:05 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Apr 2015 20:34:05 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1428611645.8.0.144581841133.issue23863@psf.upfronthosting.co.za> STINNER Victor added the comment: > I'd be happy to churn through and fix the other modules (using the 3.5 work as a guide), It is risky to modify so much code. The PEP 475 also has an impact on backward compatibility: https://www.python.org/dev/peps/pep-0475/#backward-compatibility IMO it must be discussed on python-dev. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 22:34:20 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 20:34:20 +0000 Subject: [issue12160] codecs doc: what is StreamCodec? In-Reply-To: <1306166137.72.0.066960808058.issue12160@psf.upfronthosting.co.za> Message-ID: <1428611660.96.0.673534192351.issue12160@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 22:35:39 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Apr 2015 20:35:39 +0000 Subject: [issue23860] Failure to check return value from lseek() in Modules/mmapmodule.c In-Reply-To: <1428083040.47.0.668729418368.issue23860@psf.upfronthosting.co.za> Message-ID: <1428611739.82.0.188298851332.issue23860@psf.upfronthosting.co.za> STINNER Victor added the comment: > /* Win9x appears to need us seeked to zero */ > lseek(fileno, 0, SEEK_SET); Hum, is it still needed in 2015 with Python 3.5? We even dropped support for Windows XP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 22:37:57 2015 From: report at bugs.python.org (Bill Parker) Date: Thu, 09 Apr 2015 20:37:57 +0000 Subject: [issue23860] Failure to check return value from lseek() in Modules/mmapmodule.c In-Reply-To: <1428611739.82.0.188298851332.issue23860@psf.upfronthosting.co.za> Message-ID: Bill Parker added the comment: At the moment, I'm not sure if it's needed or not, but if it's only an issue with XP, then it might not be worth fixing...:) On Thu, Apr 9, 2015 at 1:35 PM, STINNER Victor wrote: > > STINNER Victor added the comment: > > > /* Win9x appears to need us seeked to zero */ > > lseek(fileno, 0, SEEK_SET); > > Hum, is it still needed in 2015 with Python 3.5? We even dropped support > for Windows XP. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 22:43:46 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Apr 2015 20:43:46 +0000 Subject: [issue23668] Support os.ftruncate on Windows In-Reply-To: <1426383698.86.0.63017868488.issue23668@psf.upfronthosting.co.za> Message-ID: <1428612226.67.0.93131364493.issue23668@psf.upfronthosting.co.za> STINNER Victor added the comment: 23668_3.patch looks good to me. I agree that handling EINTR is not needed on Windows, and so there is no need for an helper function like _Py_open_noraise(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 22:44:32 2015 From: report at bugs.python.org (Paul Moore) Date: Thu, 09 Apr 2015 20:44:32 +0000 Subject: [issue23901] Force console stdout to use UTF8 on Windows In-Reply-To: <1428600157.62.0.0673126456323.issue23901@psf.upfronthosting.co.za> Message-ID: <1428612272.94.0.497417303255.issue23901@psf.upfronthosting.co.za> Paul Moore added the comment: Generally, my understanding is that the console does pretty badly at supporting Unicode via the normal WriteFile APIs and the "code page" support (mainly because support for the UTF8 code page is rubbish). But the WriteConsole API does, I believe, have pretty solid Unicode support (it's what Powershell uses, for example). Typically, attempts to support Unicode for Python console output (e.g., win_unicode_console on PyPI) deal with this by making a file-like object that calls WriteConsole under the hood, and replaces sys.stdout with this. The problem with this approach is that it isn't a "normal" text stream object (there's no underlying raw bytes buffer), so the result isn't seamless (although win_unicode_console is pretty good). What I noticed is that the C runtime supports an _O_U8TEXT mode for console file descriptors, at the (bytes) write() level. So that could be seamlessly integrated into the bytes IO layer of the Python IO stack. As far as I can tell from the description, the way it works is to treat a block of bytes written via write() as a UTF8 string, encode it to Unicode and write it to the console via WriteConsole(). (I haven't checked the CRT source, but that seems like the most likely implementation). Code speaks louder than words, obviously, and I do intend to produce a trial implementation. But that'll take a bit of time because I need to understand how the IO stack hangs together first. An alternative approach would be a RawIOBase implementation that wrote bytes to the console by (re-)decoding them from UTF8 and using WriteConsole, then wrapping that in the usual buffered IO and text IO layers (with the text IO layer using UTF8 encoding). That may well be implementable in pure Python, and make a good prototype implementation. Hmm... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 22:49:18 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 20:49:18 +0000 Subject: [issue20021] "modernize" makeopcodetargets.py In-Reply-To: <1387426285.76.0.769422966502.issue20021@psf.upfronthosting.co.za> Message-ID: <1428612558.31.0.751946405961.issue20021@psf.upfronthosting.co.za> R. David Murray added the comment: The comment about staying compatibler with 2.3 is now clearly out of date :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 22:51:15 2015 From: report at bugs.python.org (Paul Moore) Date: Thu, 09 Apr 2015 20:51:15 +0000 Subject: [issue23901] Force console stdout to use UTF8 on Windows In-Reply-To: <1428600157.62.0.0673126456323.issue23901@psf.upfronthosting.co.za> Message-ID: <1428612675.94.0.294388598372.issue23901@psf.upfronthosting.co.za> Paul Moore added the comment: Doh. That latter approach (a RawIOBase implementation) is *precisely* what win_unicode_console does for stdout (using utf16le rather than utf8 as that's the native Windows encoding used by WriteConsole). So (a) yes it would work, and (b) it has already demonstrated in the wild that the approach is viable. (Actually, a C implementation of this approach might be a better way of implementing this anyway, rather than relying on a relatively obscure C runtime feature). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 22:59:03 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 20:59:03 +0000 Subject: [issue21795] smtpd.SMTPServer should announce 8BITMIME when supported and accept SMTPUTF8 without it In-Reply-To: <1403033401.43.0.395080659803.issue21795@psf.upfronthosting.co.za> Message-ID: <1428613143.8.0.710374134825.issue21795@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 23:00:03 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Apr 2015 21:00:03 +0000 Subject: [issue23524] Use _set_thread_local_invalid_parameter_handler in posixmodule In-Reply-To: <1424930057.56.0.00430774738557.issue23524@psf.upfronthosting.co.za> Message-ID: <1428613203.71.0.975806485386.issue23524@psf.upfronthosting.co.za> STINNER Victor added the comment: I reviewed 23524_5.patch, I made some comments, but I now agree with the overall change (disable temporary the validation of invalid fd, set errno to EBADF instead). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 23:03:09 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Apr 2015 21:03:09 +0000 Subject: [issue21859] Add Python implementation of FileIO In-Reply-To: <1403608013.94.0.257739188668.issue21859@psf.upfronthosting.co.za> Message-ID: <1428613389.54.0.351408121318.issue21859@psf.upfronthosting.co.za> STINNER Victor added the comment: What's the status of the patch? Is it ready to be commited? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 23:04:55 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 21:04:55 +0000 Subject: [issue12932] filecmp.dircmp does not allow non-shallow comparisons In-Reply-To: <1315411296.33.0.213336425163.issue12932@psf.upfronthosting.co.za> Message-ID: <1428613495.91.0.964495983494.issue12932@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 23:08:28 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 21:08:28 +0000 Subject: [issue17247] int and float should detect inconsistent format strings In-Reply-To: <1361312693.56.0.943767612751.issue17247@psf.upfronthosting.co.za> Message-ID: <1428613708.46.0.850031678439.issue17247@psf.upfronthosting.co.za> R. David Murray added the comment: This would need a deprecation preriod if we want to do it. ---------- nosy: +r.david.murray versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 23:17:37 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 21:17:37 +0000 Subject: [issue19738] pytime.c loses precision under Windows In-Reply-To: <1385227632.17.0.4146549909.issue19738@psf.upfronthosting.co.za> Message-ID: <1428614257.3.0.726657877713.issue19738@psf.upfronthosting.co.za> R. David Murray added the comment: Victor, is this issue still relevant given your recent work on time? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 23:32:12 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 09 Apr 2015 21:32:12 +0000 Subject: [issue20021] "modernize" makeopcodetargets.py In-Reply-To: <1387426285.76.0.769422966502.issue20021@psf.upfronthosting.co.za> Message-ID: <1428615132.18.0.576035777376.issue20021@psf.upfronthosting.co.za> Berker Peksag added the comment: I think makeopcodetargets.py should still be compatible with Python 2 (2.6 or 2.7 at least) since it uses the system Python. I'd suggest closing this as "rejected" (or just commit the ``with open(...):`` part of the patch and update the outdated comment). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 23:38:31 2015 From: report at bugs.python.org (Matthew Gamble) Date: Thu, 09 Apr 2015 21:38:31 +0000 Subject: [issue6818] remove/delete method for zipfile/tarfile objects In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za> Message-ID: <1428615511.55.0.356245161844.issue6818@psf.upfronthosting.co.za> Matthew Gamble added the comment: Thanks Terry - apologies - I meant to sign before I submitted the patch. I have signed the CLA now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 23:50:28 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 21:50:28 +0000 Subject: [issue18544] subprocess.Popen support for redirection of arbitrary file descriptors In-Reply-To: <1374674400.76.0.00470955001934.issue18544@psf.upfronthosting.co.za> Message-ID: <1428616228.55.0.956121119105.issue18544@psf.upfronthosting.co.za> R. David Murray added the comment: I can't figure out what this code is doing that pass_fds doesn't cover, so I'm closing it. ---------- nosy: +r.david.murray resolution: -> works for me stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 9 23:54:07 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 09 Apr 2015 21:54:07 +0000 Subject: [issue9624] Error 2755, "failure to find drive" when installing Python In-Reply-To: <1282001795.13.0.196803574469.issue9624@psf.upfronthosting.co.za> Message-ID: <1428616447.22.0.212255301927.issue9624@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> works for me stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 00:02:20 2015 From: report at bugs.python.org (Zachary Ware) Date: Thu, 09 Apr 2015 22:02:20 +0000 Subject: [issue23686] Update Windows and OS X installer OpenSSL to 1.0.2a In-Reply-To: <1426591782.15.0.995555672449.issue23686@psf.upfronthosting.co.za> Message-ID: <1428616940.12.0.159670047156.issue23686@psf.upfronthosting.co.za> Zachary Ware added the comment: It looks like this killed the AMD64 Windows 7 bots, but everything else is fine (including the 64bit build on my 8.1 box). I'm suspicious of the version of NASM installed on the bot; Jeremy, can you tell me what version is on there, or if there's anything wonky with externals\openssl-1.0.2a\tmp64\x86_64-mont.asm:866? If NASM is any older than 2.11.06, it would be best to just uninstall it and let the build use the version it pulls from svn.python.org. ---------- nosy: +jeremy.kloth _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 00:02:58 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Apr 2015 22:02:58 +0000 Subject: [issue19738] pytime.c loses precision under Windows In-Reply-To: <1385227632.17.0.4146549909.issue19738@psf.upfronthosting.co.za> Message-ID: <1428616978.66.0.816825169518.issue19738@psf.upfronthosting.co.za> STINNER Victor added the comment: > Victor, is this issue still relevant given your recent work on time? In Python 3.3, I modified time.time() to use GetSystemTimeAsFileTime() instead of gettimeofday(). In Python 3.5, I replaced _PyTime_gettimeofday(_PyTime_timeval *tp) (resolution of 1 us) with _PyTime_t _PyTime_GetSystemClock(void) (resolution of 1 ns). Moreover, most Python functions now use internally a monotonic clock (_PyTime_GetMonotonicClock) instead of the system clock (_PyTime_GetSystemClock), especially to compute timeout. Python 3.5 now ensures that a monotonic clock is available, it checks once at runtime (during Python startup). The initial issue "pytime.c loses precision under Windows" has been fixed in the issue #22117 which introduced the _PyTime_t type. The resolution of _PyTime_t is no more hardcoded in the API. Currently, it uses a resolution of 1 nanosecond, but it may be worse if we get compilation issues (no 64 bits signed integer type, too bad) or better (ex: if a compiler supports 128 bits signed integer type, I didn't try __int128 of GCC). The resolution is only handled in pytime.c, not in the users of the API. > Martin: I think the best choice would be a decimal object--which, now that we have decimal in C, is probably sufficiently performant for serious consideration. This change has been discussed in the PEP 410 which has been rejected. datetime.datetime.now() now uses _PyTime_GetSystemClock() and so indirectly GetSystemTimeAsFileTime() on Windows. Since the datetime type may get nanosecond resolution (issue #15443), it will be possible to get the current time with nanosecond resolution ;-) I now close the issue. ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 00:07:24 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Apr 2015 22:07:24 +0000 Subject: [issue15443] datetime module has no support for nanoseconds In-Reply-To: <1343158610.62.0.806232279741.issue15443@psf.upfronthosting.co.za> Message-ID: <1428617244.29.0.263581262725.issue15443@psf.upfronthosting.co.za> STINNER Victor added the comment: > My patch for the issue #22043 adds nanosecond precision to get the system clock. In fact, nanosecond resolution was added by the issue #22117. In Python 3.5, datetime.datetime.now() calls _PyTime_GetSystemClock() which has now a resolution of 1 nanosecond. The C type has a resolution of 1 nanosecond, the effictive resolution depends on the platform. For example, Windows provides GetSystemTimeAsFileTime() which has a resolution of 100 ns (and the effective accuracy is closer to 15 ms: see issue #13845). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 00:10:51 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 09 Apr 2015 22:10:51 +0000 Subject: [issue19738] pytime.c loses precision under Windows In-Reply-To: <1385227632.17.0.4146549909.issue19738@psf.upfronthosting.co.za> Message-ID: <1428617451.84.0.478374799534.issue19738@psf.upfronthosting.co.za> STINNER Victor added the comment: > Perhaps we need a time_ns() method? (returning an integer timestamp in nanoseconds) Oh, I missed this message. The current trend in Python (os.stat) is to use a number of nanoseconds to store a timestamp. If we continue this trend in the datetime module, maybe with a new total_nanoseconds() method for example, it may make sense to add a new time.time_ns() function. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 00:24:52 2015 From: report at bugs.python.org (mike bayer) Date: Thu, 09 Apr 2015 22:24:52 +0000 Subject: [issue23898] inspect() changes in Python3.4 are not compatible with objects that implement special __bool__, __eq__ In-Reply-To: <1428590086.18.0.0932223784087.issue23898@psf.upfronthosting.co.za> Message-ID: <1428618292.48.0.0471993204631.issue23898@psf.upfronthosting.co.za> mike bayer added the comment: hi Yury - I have a confirmation including a PDF attachment of the agreement, the message reads: " Python Contributor Agreement Form between Python Software Foundation and Michael Bayer is Signed and Filed! From: Ewa Jodlowska (Python Software Foundation) To: Ewa Jodlowska and Michael Bayer " can I forward that to you? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 01:12:54 2015 From: report at bugs.python.org (Cyd Haselton) Date: Thu, 09 Apr 2015 23:12:54 +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: <1428621174.74.0.702903084853.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Done. Unfortunately: ./python -E -S -m sysconfig --generate-posix-vars ;\ if test $? -ne 0 ; then \ echo "generate-posix-vars failed" ; \ rm -f ./pybuilddir.txt ; \ exit 1 ; \ fi Segmentation fault generate-posix-vars failed make: *** [pybuilddir.txt] Error 1 /bld/python/cpython-master $ I'll break out logcat and addr2line...hopefully it's something that was just overlooked ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 01:44:31 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 09 Apr 2015 23:44:31 +0000 Subject: [issue21859] Add Python implementation of FileIO In-Reply-To: <1403608013.94.0.257739188668.issue21859@psf.upfronthosting.co.za> Message-ID: <1428623071.72.0.701017018452.issue21859@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Removed redundant fstat() call (as in issue23752). Slightly corrected docstrings (but for larger changes C and Python implementations should be changed consistently). I wait only for your approval Victor. ---------- Added file: http://bugs.python.org/file38885/pyio_fileio_9.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 02:37:09 2015 From: report at bugs.python.org (Cyd Haselton) Date: Fri, 10 Apr 2015 00:37: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: <1428626229.13.0.017631296472.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: FYI, Here's the addr2line output LD_LIBRARY_PATH=/bld/python/cpython-master:/data/data/jackpal.androidterm/kbox2/lib ./python -E -S -m sysconfig --generate-posix-vars ;\ if test $? -ne 0 ; then \ echo "generate-posix-vars failed" ; \ rm -f ./pybuilddir.txt ; \ exit 1 ; \ fi Segmentation fault generate-posix-vars failed make: *** [pybuilddir.txt] Error 1 /bld/python/cpython-master $ addr2line -C -f -e /lib/libpython3.5m.so.1.0 0008f1a4 _PyMem_RawStrdup /bld/python/cpython-master/Objects/obmalloc.c:358 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 02:53:21 2015 From: report at bugs.python.org (Cyd Haselton) Date: Fri, 10 Apr 2015 00:53:21 +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: <1428627201.08.0.618318885381.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: FYI, I think this is the culprit. In Python/pylifecycle.c: static char* get_codec_name(const char *encoding) { char *name_utf8, *name_str; PyObject *codec, *name = NULL; codec = _PyCodec_Lookup(encoding); if (!codec) goto error; name = _PyObject_GetAttrId(codec, &PyId_name); Py_CLEAR(codec); if (!name) goto error; name_utf8 = _PyUnicode_AsString(name); if (name_utf8 == NULL) goto error; name_str = _PyMem_RawStrdup(name_utf8); Py_DECREF(name); if (name_str == NULL) { PyErr_NoMemory(); return NULL; } return name_str; error: Py_XDECREF(codec); Py_XDECREF(name); return NULL; } If I figure out a working patch I'll post it here ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 03:05:20 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 10 Apr 2015 01:05:20 +0000 Subject: [issue14812] Change file associations to not be a default installer feature In-Reply-To: <1337057086.06.0.157566935456.issue14812@psf.upfronthosting.co.za> Message-ID: <1428627920.86.0.0402917415585.issue14812@psf.upfronthosting.co.za> R. David Murray added the comment: There has been a lot of water under this bridge, and I'm sure Steve has thought this through for the new installer, so I'm closing this as out of date. ---------- nosy: +r.david.murray, steve.dower resolution: -> out of date stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 03:10:22 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Fri, 10 Apr 2015 01:10:22 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1428627201.08.0.618318885381.issue23496@psf.upfronthosting.co.za> Message-ID: Ryan Gonzalez added the comment: I think it was the same issue as before, but, for some reason, it didn't applu or something...? Will look into it tomorrow. Cyd Haselton wrote: > >Cyd Haselton added the comment: > >FYI, I think this is the culprit. >In Python/pylifecycle.c: > >static char* >get_codec_name(const char *encoding) >{ > char *name_utf8, *name_str; > PyObject *codec, *name = NULL; > > codec = _PyCodec_Lookup(encoding); > if (!codec) > goto error; > > name = _PyObject_GetAttrId(codec, &PyId_name); > Py_CLEAR(codec); > if (!name) > goto error; > > name_utf8 = _PyUnicode_AsString(name); > if (name_utf8 == NULL) > goto error; > name_str = _PyMem_RawStrdup(name_utf8); > Py_DECREF(name); > if (name_str == NULL) { > PyErr_NoMemory(); > return NULL; > } > return name_str; > >error: > Py_XDECREF(codec); > Py_XDECREF(name); > return NULL; >} > >If I figure out a working patch I'll post it here > >---------- > >_______________________________________ >Python tracker > >_______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 05:04:36 2015 From: report at bugs.python.org (Jeff McNeil) Date: Fri, 10 Apr 2015 03:04:36 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1428635076.52.0.569573924279.issue23863@psf.upfronthosting.co.za> Jeff McNeil added the comment: Sure, to be clear --- the intention wouldn't be to create any backwards incompatible changes. Rather, as a means to identify what needs to be addressed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 05:49:09 2015 From: report at bugs.python.org (Mark Lawrence) Date: Fri, 10 Apr 2015 03:49:09 +0000 Subject: [issue18402] Finding perl64 In-Reply-To: <1373261873.64.0.61453379281.issue18402@psf.upfronthosting.co.za> Message-ID: <1428637749.31.0.191255574395.issue18402@psf.upfronthosting.co.za> Mark Lawrence added the comment: There is no longer a build_ssl.py file in the PCBuild directory so can this be closed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 05:49:21 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 10 Apr 2015 03:49:21 +0000 Subject: [issue23903] Generate PC/python3.def by scraping headers Message-ID: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za> New submission from Zachary Ware: The attached patch adds a script that can scrape header files to pick out PyAPI_DATA and PyAPI_FUNCs to generate PC/python3.def. It's not complete and is not integrated into the build at all yet. I'm planning to work on this further at the PyCon sprints. Running this and comparing output to the current checked-in python3.def shows that we're not keeping it up-to-date well at all. ---------- assignee: zach.ware components: Build, Windows files: add_python3defgen.diff keywords: patch messages: 240409 nosy: steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: Generate PC/python3.def by scraping headers type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file38886/add_python3defgen.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 05:56:09 2015 From: report at bugs.python.org (Zachary Ware) Date: Fri, 10 Apr 2015 03:56:09 +0000 Subject: [issue18402] Finding perl64 In-Reply-To: <1373261873.64.0.61453379281.issue18402@psf.upfronthosting.co.za> Message-ID: <1428638169.88.0.462982800386.issue18402@psf.upfronthosting.co.za> Zachary Ware added the comment: build_ssl.py is now prepare_ssl.py, the patch still applies to 2.7 and 3.4 as well. ---------- versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 09:17:20 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Apr 2015 07:17:20 +0000 Subject: [issue16314] Support xz compression in distutils In-Reply-To: <1351114378.64.0.718374634123.issue16314@psf.upfronthosting.co.za> Message-ID: <1428650240.85.0.277284456292.issue16314@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch addresses Antoines comments: refactores tests and corrects docs. ---------- Added file: http://bugs.python.org/file38887/distutils-lzma_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 09:52:08 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Apr 2015 07:52:08 +0000 Subject: [issue21859] Add Python implementation of FileIO In-Reply-To: <1403608013.94.0.257739188668.issue21859@psf.upfronthosting.co.za> Message-ID: <1428652328.52.0.362436936208.issue21859@psf.upfronthosting.co.za> STINNER Victor added the comment: > Slightly corrected docstrings (but for larger changes C and Python implementations should be changed consistently). I reviewed pyio_fileio_9.patch. The main issue is that I don't understand how self._fd is set to None. In the C implemented, it's set to -1 even if closefd is False. For comments on docstrings which also concern the C code, can you maybe open a new issue with a reference to this issue or maybe even a link to my review, if you don't want to modify them in this issue? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 10:24:13 2015 From: report at bugs.python.org (Piotr Dobrogost) Date: Fri, 10 Apr 2015 08:24:13 +0000 Subject: [issue1602] windows console doesn't print or input Unicode In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za> Message-ID: <1428654253.76.0.229515250287.issue1602@psf.upfronthosting.co.za> Changes by Piotr Dobrogost : ---------- nosy: +piotr.dobrogost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 10:33:51 2015 From: report at bugs.python.org (Piotr Dobrogost) Date: Fri, 10 Apr 2015 08:33:51 +0000 Subject: [issue23901] Force console stdout to use UTF8 on Windows In-Reply-To: <1428600157.62.0.0673126456323.issue23901@psf.upfronthosting.co.za> Message-ID: <1428654831.21.0.642863684407.issue23901@psf.upfronthosting.co.za> Changes by Piotr Dobrogost : ---------- nosy: +piotr.dobrogost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 12:30:56 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Apr 2015 10:30:56 +0000 Subject: [issue23865] Fix possible leaks in close methods In-Reply-To: <1428145980.2.0.463866688715.issue23865@psf.upfronthosting.co.za> Message-ID: <20150410103053.8617.27218@psf.io> Roundup Robot added the comment: New changeset f7ddec2e9e93 by Serhiy Storchaka in branch '2.7': Issue #23865: close() methods in multiple modules now are idempotent and more https://hg.python.org/cpython/rev/f7ddec2e9e93 New changeset e826940911c8 by Serhiy Storchaka in branch '3.4': Issue #23865: close() methods in multiple modules now are idempotent and more https://hg.python.org/cpython/rev/e826940911c8 New changeset 4ddec11b5faf by Serhiy Storchaka in branch 'default': Issue #23865: close() methods in multiple modules now are idempotent and more https://hg.python.org/cpython/rev/4ddec11b5faf ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 13:11:22 2015 From: report at bugs.python.org (Bruno Cauet) Date: Fri, 10 Apr 2015 11:11:22 +0000 Subject: [issue23904] pathlib.PurePath does not accept bytes components Message-ID: <1428664281.99.0.802237757059.issue23904@psf.upfronthosting.co.za> New submission from Bruno Cauet: At https://docs.python.org/3/library/pathlib.html#pure-paths one can read > Each element of pathsegments can be either a string or bytes object representing a path segment; it can also be another path object: which is a lie: >>> pathlib.PurePath(b"/foo") Traceback (most recent call last): File "", line 1, in File "/home/bru/code/cpython/Lib/pathlib.py", line 609, in __new__ return cls._from_parts(args) File "/home/bru/code/cpython/Lib/pathlib.py", line 638, in _from_parts drv, root, parts = self._parse_args(args) File "/home/bru/code/cpython/Lib/pathlib.py", line 630, in _parse_args % type(a)) TypeError: argument should be a path or str object, not So either (1) the doc is wrong (2) PathLib path management fails: it should decode bytes parts with os.fsdecode() I doubt I tagged both components. I'll be happy to provide a fix once you decide what is the right solution. I take this opportunity to share an itch: filesystem encoding on Unix cannot be reliably determined. sys.getfilesystemencoding() is only a preference and there is no guarantee that an arbitrary file will respect it. This is extensively discussed in the following thread: https://mail.python.org/pipermail/python-dev/2014-August/135873.html What is the right way to deal with those? If I use "surrogateescape" (see PEP383) how can I display the fake-unicode path to the user? `print()` does seems to use strict encoding. Should I encode it with "surrogateescape" or "ignore" myself beforehand? ---------- assignee: docs at python components: Documentation, Library (Lib) messages: 240414 nosy: bru, docs at python priority: normal severity: normal status: open title: pathlib.PurePath does not accept bytes components versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 13:36:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Apr 2015 11:36:41 +0000 Subject: [issue21859] Add Python implementation of FileIO In-Reply-To: <1403608013.94.0.257739188668.issue21859@psf.upfronthosting.co.za> Message-ID: <1428665801.65.0.962548853592.issue21859@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated patch addresses Victor's and Berker's comments. ---------- Added file: http://bugs.python.org/file38888/pyio_fileio_10.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 13:51:36 2015 From: report at bugs.python.org (Piotr Dobrogost) Date: Fri, 10 Apr 2015 11:51:36 +0000 Subject: [issue19829] _pyio.BufferedReader and _pyio.TextIOWrapper destructor don't emit ResourceWarning if the file is not closed In-Reply-To: <1385721421.95.0.384748799117.issue19829@psf.upfronthosting.co.za> Message-ID: <1428666696.26.0.65344141227.issue19829@psf.upfronthosting.co.za> Changes by Piotr Dobrogost : ---------- nosy: +piotr.dobrogost _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 14:21:25 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Apr 2015 12:21:25 +0000 Subject: [issue21859] Add Python implementation of FileIO In-Reply-To: <1403608013.94.0.257739188668.issue21859@psf.upfronthosting.co.za> Message-ID: <1428668485.54.0.58551661462.issue21859@psf.upfronthosting.co.za> STINNER Victor added the comment: pyio_fileio_10.patch looks good to me. Great job. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 15:11:21 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Apr 2015 13:11:21 +0000 Subject: [issue23062] test_argparse --version test cases In-Reply-To: <1418706736.64.0.85644160224.issue23062@psf.upfronthosting.co.za> Message-ID: <20150410131117.21303.36097@psf.io> Roundup Robot added the comment: New changeset 5b728310edac by Berker Peksag in branch '3.4': Issue #23062: Add a test for suppressing --version with argparse.SUPPRESS. https://hg.python.org/cpython/rev/5b728310edac New changeset 157b59609cbd by Berker Peksag in branch 'default': Issue #23062: Add a test for suppressing --version with argparse.SUPPRESS. https://hg.python.org/cpython/rev/157b59609cbd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 15:12:01 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Apr 2015 13:12:01 +0000 Subject: [issue23062] test_argparse --version test cases In-Reply-To: <1418706736.64.0.85644160224.issue23062@psf.upfronthosting.co.za> Message-ID: <1428671521.26.0.300368907276.issue23062@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 15:19:26 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Apr 2015 13:19:26 +0000 Subject: [issue23025] ssl.RAND_bytes docs should mention os.urandom In-Reply-To: <1418235366.16.0.20927959194.issue23025@psf.upfronthosting.co.za> Message-ID: <20150410131917.62497.29940@psf.io> Roundup Robot added the comment: New changeset f85ac33b12a1 by Berker Peksag in branch '3.4': Issue #23025: Add a mention of os.urandom to RAND_bytes and RAND_pseudo_bytes docs. https://hg.python.org/cpython/rev/f85ac33b12a1 New changeset 7aa42cea8968 by Berker Peksag in branch 'default': Issue #23025: Add a mention of os.urandom to RAND_bytes and RAND_pseudo_bytes docs. https://hg.python.org/cpython/rev/7aa42cea8968 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 15:20:10 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 10 Apr 2015 13:20:10 +0000 Subject: [issue23025] ssl.RAND_bytes docs should mention os.urandom In-Reply-To: <1418235366.16.0.20927959194.issue23025@psf.upfronthosting.co.za> Message-ID: <1428672010.53.0.0555950872335.issue23025@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Alex. ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 15:26:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Apr 2015 13:26:50 +0000 Subject: [issue21859] Add Python implementation of FileIO In-Reply-To: <1403608013.94.0.257739188668.issue21859@psf.upfronthosting.co.za> Message-ID: <1428672410.71.0.936702900928.issue21859@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thank you for your review Victor and others. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 15:27:25 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Apr 2015 13:27:25 +0000 Subject: [issue21859] Add Python implementation of FileIO In-Reply-To: <1403608013.94.0.257739188668.issue21859@psf.upfronthosting.co.za> Message-ID: <20150410132308.62509.15919@psf.io> Roundup Robot added the comment: New changeset 0db36098b908 by Serhiy Storchaka in branch '2.7': Issue #21859: Corrected FileIO docstrings. https://hg.python.org/cpython/rev/0db36098b908 New changeset d080f5ecdcd3 by Serhiy Storchaka in branch '3.4': Issue #21859: Corrected FileIO docstrings. https://hg.python.org/cpython/rev/d080f5ecdcd3 New changeset 330910697e23 by Serhiy Storchaka in branch 'default': Issue #21859: Corrected FileIO docstrings. https://hg.python.org/cpython/rev/330910697e23 New changeset 9ef5765d56b7 by Serhiy Storchaka in branch 'default': Issue #21859: Added Python implementation of io.FileIO. https://hg.python.org/cpython/rev/9ef5765d56b7 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 15:45:34 2015 From: report at bugs.python.org (Matthew Gamble) Date: Fri, 10 Apr 2015 13:45:34 +0000 Subject: [issue6818] remove/delete method for zipfile/tarfile objects In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za> Message-ID: <1428673534.67.0.0295160545271.issue6818@psf.upfronthosting.co.za> Changes by Matthew Gamble : Removed file: http://bugs.python.org/file38878/zipfile.remove_rename.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 15:45:46 2015 From: report at bugs.python.org (Matthew Gamble) Date: Fri, 10 Apr 2015 13:45:46 +0000 Subject: [issue6818] remove/delete method for zipfile/tarfile objects In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za> Message-ID: <1428673546.23.0.196151165124.issue6818@psf.upfronthosting.co.za> Changes by Matthew Gamble : Removed file: http://bugs.python.org/file38879/zip_hiddenfiles.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 15:52:44 2015 From: report at bugs.python.org (Matthew Gamble) Date: Fri, 10 Apr 2015 13:52:44 +0000 Subject: [issue6818] remove/delete method for zipfile/tarfile objects In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za> Message-ID: <1428673964.19.0.218761858164.issue6818@psf.upfronthosting.co.za> Matthew Gamble added the comment: Hi all, Apologies again, I've had to pull the patch just temporarily whilst I check with my employer (The University of Manchester) that everything is OK with me contributing this. Everything should be OK - but I just wanted to do things correctly. I'll re-submit the patch for review when I get the OK. - Matthew ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 16:52:43 2015 From: report at bugs.python.org (Cyd Haselton) Date: Fri, 10 Apr 2015 14:52:43 +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: <1428677563.38.0.11630682622.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: I think the android_segfault_fix patch doesn't include main.c and python.c...which use _PyMem_RawStrdup and also need patching... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 17:18:51 2015 From: report at bugs.python.org (Ezequiel Gonzalez) Date: Fri, 10 Apr 2015 15:18:51 +0000 Subject: [issue23905] Python here maing CPU g to 100% Message-ID: <1428679131.49.0.72023198194.issue23905@psf.upfronthosting.co.za> New submission from Ezequiel Gonzalez: So I wanted to start on Python! Downloaded from this site. long with it came poweliks. What gives? It toasted my laptop to the point i had to replace the HD. ---------- messages: 240424 nosy: zekescript priority: normal severity: normal status: open title: Python here maing CPU g to 100% type: resource usage versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 17:19:39 2015 From: report at bugs.python.org (Ezequiel Gonzalez) Date: Fri, 10 Apr 2015 15:19:39 +0000 Subject: [issue23905] Python here making CPU go to 100% In-Reply-To: <1428679131.49.0.72023198194.issue23905@psf.upfronthosting.co.za> Message-ID: <1428679179.75.0.23883673802.issue23905@psf.upfronthosting.co.za> Changes by Ezequiel Gonzalez : ---------- title: Python here maing CPU g to 100% -> Python here making CPU go to 100% _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 17:26:33 2015 From: report at bugs.python.org (Guillermo Narvaja) Date: Fri, 10 Apr 2015 15:26:33 +0000 Subject: [issue23906] poplib maxline behaviour may be wrong Message-ID: <1428679593.1.0.415911204922.issue23906@psf.upfronthosting.co.za> New submission from Guillermo Narvaja: After #16041 was fixed, Python started to validate that lines coming from the POP server should be under 2048 bytes. This breaks the mail retrieval from at least dovecot servers, as this mail server does not breaks responses in 512 o 2048 sized lines. On dovecot's side, they said there is a misunderstood of the RFC on the Python side, that the RFC 1939 "is talking about POP3 responses themselves - not about the actual email message body". You can see here the related mail thread: http://dovecot.org/pipermail/dovecot/2015-April/100475.html I'm not sure Who is right, but I think it's a problem (at least it was for me). ---------- components: Library (Lib) messages: 240425 nosy: berker.peksag, christian.heimes, doko, gnarvaja priority: normal severity: normal status: open title: poplib maxline behaviour may be wrong type: behavior versions: Python 2.7, Python 3.2 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 17:38:56 2015 From: report at bugs.python.org (Travis Everett) Date: Fri, 10 Apr 2015 15:38:56 +0000 Subject: [issue23902] let exception react to being raised or the setting of magic properties (like __cause__) within Python In-Reply-To: <1428610708.13.0.662863454956.issue23902@psf.upfronthosting.co.za> Message-ID: <1428680336.5.0.635108869352.issue23902@psf.upfronthosting.co.za> Travis Everett added the comment: I attempted to intercept the set with both a property setter and __setattr__ with no luck. I agree the use-case feels pretty specialized (at least to me). I'm not familiar with Python's source, but as best as I can tell these magic properties get set in the C source in such a way that the changes can't be observed through the typical Python interfaces. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 17:49:38 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 10 Apr 2015 15:49:38 +0000 Subject: [issue23905] Python here making CPU go to 100% In-Reply-To: <1428679131.49.0.72023198194.issue23905@psf.upfronthosting.co.za> Message-ID: <1428680978.57.0.777842833496.issue23905@psf.upfronthosting.co.za> R. David Murray added the comment: You are better off posting to the python-list mailing list to get help in figuring out what your problem is. This bug tracker is for reporting bugs in python, and suffice it to say that unless someone writes a program in python that has an infinite loop in it of soem sort, python does not normally use 100% cpu. So there must be somehing wrong with your install, and python-list is a good place to get help on figuring out what the problem is. ---------- nosy: +r.david.murray resolution: -> works for me stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 17:57:16 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 10 Apr 2015 15:57:16 +0000 Subject: [issue23902] let exception react to being raised or the setting of magic properties (like __cause__) within Python In-Reply-To: <1428610708.13.0.662863454956.issue23902@psf.upfronthosting.co.za> Message-ID: <1428681436.69.0.483711363614.issue23902@psf.upfronthosting.co.za> R. David Murray added the comment: oh, yes, that makes sense. I think you'd need to bring this up on python-ideas to see if people think it is a worthwhile feature, but I suspect the answer is going to be no, it is too specialized. On the other hand, the asyncio folks have run into some limitations in python exception handling, so it is possible there might be some cross-fertilization there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 18:01:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Apr 2015 16:01:24 +0000 Subject: [issue21859] Add Python implementation of FileIO In-Reply-To: <1403608013.94.0.257739188668.issue21859@psf.upfronthosting.co.za> Message-ID: <1428681684.57.0.538634850887.issue21859@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There are test failures on Windows: http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/6073/steps/test/logs/stdio 1. ValueError is not raised if file name contains a null character. 2. os.ftruncate doesn't exist on Windows. Here is a patch that adds explicit check for null character and skips tests with not implemented truncate. ---------- resolution: fixed -> stage: resolved -> patch review status: closed -> open Added file: http://bugs.python.org/file38889/pyio_fileio_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 18:14:25 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 10 Apr 2015 16:14:25 +0000 Subject: [issue21859] Add Python implementation of FileIO In-Reply-To: <1403608013.94.0.257739188668.issue21859@psf.upfronthosting.co.za> Message-ID: <1428682465.92.0.00997229125938.issue21859@psf.upfronthosting.co.za> STINNER Victor added the comment: > 2. os.ftruncate doesn't exist on Windows. Steve Dower wrote a patch and the latest version looks good to me: https://bugs.python.org/issue23668#msg240385 + if 0 in os.fsencode(file): + raise ValueError('embedded null character') IMO the check must be implemented in os.open() (in path_converter). It doesn't look right to have a differen behaviour on UNIX and Windows. path_converter() calls PyUnicode_FSConverter() on UNIX and this function checks for embedded null bytes. So I would prefer to see the issue #23668 fixed and path_converter() fixed, instead of pushing pyio_fileio_fix.patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 18:20:13 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Fri, 10 Apr 2015 16:20:13 +0000 Subject: [issue23905] Python here making CPU go to 100% In-Reply-To: <1428679131.49.0.72023198194.issue23905@psf.upfronthosting.co.za> Message-ID: <1428682813.16.0.103092001195.issue23905@psf.upfronthosting.co.za> Steven D'Aprano added the comment: Poweliks is a Windows trojan: http://www.google.com.au/search?q=poweliks If you are claiming that poweliks was included in the Python download, you will need to give more details, and others will have to reproduce the problem. Otherwise it is more likely that you got infected elsewhere, and only noticed it after Python was installed. According to Symantic, Poweliks is most likely to have been installed by a fake Word or Excel document. If you still believe that the Python download contained the Poweliks trojan, please tell us the EXACT url you used to download. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 18:24:29 2015 From: report at bugs.python.org (Ezequiel Gonzalez) Date: Fri, 10 Apr 2015 16:24:29 +0000 Subject: [issue23905] Python here making CPU go to 100% In-Reply-To: <1428682813.16.0.103092001195.issue23905@psf.upfronthosting.co.za> Message-ID: <0FB7EF9F-8CDB-45BF-959F-CFDB7468326F@me.com> Ezequiel Gonzalez added the comment: No. Clean PC. Nothing on it. Eradicated Windows. I've got several MS bills that thy attempted to root out Poweliks but where unable. Not to be an azz but you could pay one of them off and see what you think. Apple side is unaffected. I threw 8 antivirus/ malware at it and it survived damaged but came back. Used Apple side to crush Poweliks. Sent from my iPhone > On Apr 10, 2015, at 11:20 AM, Steven D'Aprano wrote: > > > Steven D'Aprano added the comment: > > Poweliks is a Windows trojan: > > http://www.google.com.au/search?q=poweliks > > If you are claiming that poweliks was included in the Python download, you will need to give more details, and others will have to reproduce the problem. Otherwise it is more likely that you got infected elsewhere, and only noticed it after Python was installed. According to Symantic, Poweliks is most likely to have been installed by a fake Word or Excel document. > > If you still believe that the Python download contained the Poweliks trojan, please tell us the EXACT url you used to download. > > ---------- > nosy: +steven.daprano > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 18:25:34 2015 From: report at bugs.python.org (Ezequiel Gonzalez) Date: Fri, 10 Apr 2015 16:25:34 +0000 Subject: [issue23905] Python here making CPU go to 100% In-Reply-To: <1428682813.16.0.103092001195.issue23905@psf.upfronthosting.co.za> Message-ID: <84804DAF-FE0D-4B7D-BC98-DD9F2511B11A@me.com> Ezequiel Gonzalez added the comment: Ezequiel Gonzalez added the comment: No. Clean PC. Nothing on it. Eradicated Windows. I've got several MS bills that thy attempted to root out Poweliks but where unable. Not to be an azz but you could pay one of them off and see what you think. Apple side is unaffected. I threw 8 antivirus/ malware at it and it survived damaged but came back. Used Apple side to crush Poweliks. Sent from my iPhone Sent from my iPhone > On Apr 10, 2015, at 11:20 AM, Steven D'Aprano wrote: > > > Steven D'Aprano added the comment: > > Poweliks is a Windows trojan: > > http://www.google.com.au/search?q=poweliks > > If you are claiming that poweliks was included in the Python download, you will need to give more details, and others will have to reproduce the problem. Otherwise it is more likely that you got infected elsewhere, and only noticed it after Python was installed. According to Symantic, Poweliks is most likely to have been installed by a fake Word or Excel document. > > If you still believe that the Python download contained the Poweliks trojan, please tell us the EXACT url you used to download. > > ---------- > nosy: +steven.daprano > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 18:27:12 2015 From: report at bugs.python.org (Ezequiel Gonzalez) Date: Fri, 10 Apr 2015 16:27:12 +0000 Subject: [issue23907] Python Message-ID: <4652150F-F3B4-471A-B3E6-17356544D635@me.com> New submission from Ezequiel Gonzalez: Ezequiel Gonzalez added the comment: No. Clean PC. Nothing on it. Eradicated Windows. I've got several MS bills that thy attempted to root out Poweliks but where unable. Not to be an azz but you could pay one of them off and see what you think. Apple side is unaffected. I threw 8 antivirus/ malware at it and it survived damaged but came back. Used Apple side to crush Poweliks. Sent from my iPhone Sent from my iPhone ---------- messages: 240434 nosy: zekescript priority: normal severity: normal status: open title: Python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 18:38:25 2015 From: report at bugs.python.org (R. David Murray) Date: Fri, 10 Apr 2015 16:38:25 +0000 Subject: [issue23907] Python In-Reply-To: <4652150F-F3B4-471A-B3E6-17356544D635@me.com> Message-ID: <1428683905.93.0.957537254633.issue23907@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Python here making CPU go to 100% _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 18:43:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Apr 2015 16:43:52 +0000 Subject: [issue23908] Check path arguments of os functions for null character Message-ID: <1428684232.77.0.530667773352.issue23908@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch adds checks for null character in unicode path arguments of os functions on Windows. Null character is already tested on Unix, in bytes paths on Windows, and in unicode argument of _io.FileIO. Removed private function _PyUnicode_HasNULChars(), because it is used only in two places and inlined code is simpler and more efficient. The patch doesn't contain tests because I can't test them. But they should be simple, just pass a path with null character to os function. ---------- components: Extension Modules files: path_converter_null_char.patch keywords: patch messages: 240435 nosy: haypo, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Check path arguments of os functions for null character type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file38890/path_converter_null_char.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 18:44:40 2015 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 10 Apr 2015 16:44:40 +0000 Subject: [issue23899] HTTP regression in distutils uploads to chishop In-Reply-To: <1428593783.07.0.14236214587.issue23899@psf.upfronthosting.co.za> Message-ID: <1428684280.07.0.251360425529.issue23899@psf.upfronthosting.co.za> ?ric Araujo added the comment: Can we have more information from the chishop logs? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 18:44:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Apr 2015 16:44:48 +0000 Subject: [issue21859] Add Python implementation of FileIO In-Reply-To: <1403608013.94.0.257739188668.issue21859@psf.upfronthosting.co.za> Message-ID: <1428684288.51.0.376597412386.issue21859@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Check path arguments of os functions for null character, Support os.ftruncate on Windows _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 18:46:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Apr 2015 16:46:33 +0000 Subject: [issue21859] Add Python implementation of FileIO In-Reply-To: <1403608013.94.0.257739188668.issue21859@psf.upfronthosting.co.za> Message-ID: <1428684393.12.0.353108618248.issue21859@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Opened issue23908 for null characters in paths. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 18:47:11 2015 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Fri, 10 Apr 2015 16:47:11 +0000 Subject: [issue23891] Tutorial doesn't mention either pip or virtualenv In-Reply-To: <1428521410.44.0.984619918633.issue23891@psf.upfronthosting.co.za> Message-ID: <1428684431.41.0.911395215735.issue23891@psf.upfronthosting.co.za> Changes by ?ric Araujo : ---------- nosy: +eric.araujo versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 18:52:32 2015 From: report at bugs.python.org (Neale Ferguson) Date: Fri, 10 Apr 2015 16:52:32 +0000 Subject: [issue23830] Add AF_IUCV support to sockets In-Reply-To: <1427828484.47.0.0998681334057.issue23830@psf.upfronthosting.co.za> Message-ID: <1428684752.04.0.103796603641.issue23830@psf.upfronthosting.co.za> Neale Ferguson added the comment: Do you need any more information from me? As I said I may be able to provide a s390x buildbot slave if required. I have a CentOS 6.5 system on a linux foundation virtual machine that I can use for that purpose. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 19:15:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Apr 2015 17:15:50 +0000 Subject: [issue23865] Fix possible leaks in close methods In-Reply-To: <1428145980.2.0.463866688715.issue23865@psf.upfronthosting.co.za> Message-ID: <1428686150.03.0.679499805139.issue23865@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 Apr 10 19:51:26 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 10 Apr 2015 17:51:26 +0000 Subject: [issue23878] Missing sanity checks for various C library function calls... In-Reply-To: <1428339627.31.0.628073381935.issue23878@psf.upfronthosting.co.za> Message-ID: <1428688286.35.0.137708621856.issue23878@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Bill, please sign the PSF Contributor Agreement. Info: https://www.python.org/psf/contrib/ Form: https://www.python.org/psf/contrib/contrib-form/ * appears after your name when process is completed in PSF office (a few days) ---------- nosy: +terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 20:01:52 2015 From: report at bugs.python.org (Bill Parker) Date: Fri, 10 Apr 2015 18:01:52 +0000 Subject: [issue23878] Missing sanity checks for various C library function calls... In-Reply-To: <1428688286.35.0.137708621856.issue23878@psf.upfronthosting.co.za> Message-ID: Bill Parker added the comment: I signed and confirmed the form returned via E-Mail...:) On Fri, Apr 10, 2015 at 10:51 AM, Terry J. Reedy wrote: > > Terry J. Reedy added the comment: > > Bill, please sign the PSF Contributor Agreement. > Info: https://www.python.org/psf/contrib/ > Form: https://www.python.org/psf/contrib/contrib-form/ > * appears after your name when process is completed in PSF office (a few > days) > > ---------- > nosy: +terry.reedy > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 20:08:51 2015 From: report at bugs.python.org (Jeff McNeil) Date: Fri, 10 Apr 2015 18:08:51 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1428689331.17.0.167302131553.issue23863@psf.upfronthosting.co.za> Jeff McNeil added the comment: I went and added the timeout modification per loop and the docs. The thought crossed my mind initially (as did adding a new field to the socket structure), but I wasn't sure what the implications might be for use cases I' not aware of. ---------- Added file: http://bugs.python.org/file38891/socket_eintr.4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 20:10:54 2015 From: report at bugs.python.org (Mikhail Korobov) Date: Fri, 10 Apr 2015 18:10:54 +0000 Subject: [issue14373] C implementation of functools.lru_cache In-Reply-To: <1332250846.11.0.753199667334.issue14373@psf.upfronthosting.co.za> Message-ID: <1428689454.67.0.467117218423.issue14373@psf.upfronthosting.co.za> Changes by Mikhail Korobov : ---------- nosy: +kmike _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 20:13:50 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Apr 2015 18:13:50 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <20150410181346.129714.78830@psf.io> Roundup Robot added the comment: New changeset 350c78a92046 by Serhiy Storchaka in branch '2.7': Issue #16840: Fixed Tcl test on 2.7 with Tcl 8.4.19. https://hg.python.org/cpython/rev/350c78a92046 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 20:14:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Apr 2015 18:14:54 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <1428689694.32.0.863919603036.issue16840@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 20:17:36 2015 From: report at bugs.python.org (Mark Mikofski) Date: Fri, 10 Apr 2015 18:17:36 +0000 Subject: [issue23909] highlight query string does not work on docs.python.org/2 Message-ID: <1428689856.01.0.985094593971.issue23909@psf.upfronthosting.co.za> New submission from Mark Mikofski: expected: using Sphinx search in docs, search keyword is usually highlighted on resulting pages. observerd: query string ?highligh= does nothing on http://docs.python.org/2 although it actually does work for 2.6 and all 3.x docs. Doesn't appear to be a function of Sphinx version as 3.x docs and 2.7.x docs all use Sphinx-1.2.3 examples: works: https://docs.python.org/3/tutorial/appetite.html?highlight=indent does'nt: https://docs.python.org/2/tutorial/appetite.html?highlight=indent platform: works? chrome: no firefox: no ---------- assignee: docs at python components: Documentation messages: 240443 nosy: bwanamarko, docs at python priority: normal severity: normal status: open title: highlight query string does not work on docs.python.org/2 versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 20:23:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 10 Apr 2015 18:23:46 +0000 Subject: [issue23894] lib2to3 doesn't recognize rb'...' as a raw byte string in Python 3 In-Reply-To: <1428585495.21.0.103830054834.issue23894@psf.upfronthosting.co.za> Message-ID: <1428690226.61.0.412618243275.issue23894@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Should it? >>> rb'abc' File "", line 1 rb'abc' ^ SyntaxError: invalid syntax According to https://docs.python.org/2/reference/lexical_analysis.html#string-literals "rb" is not valid string prefix. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 20:44:20 2015 From: report at bugs.python.org (Eli Bendersky) Date: Fri, 10 Apr 2015 18:44:20 +0000 Subject: [issue23894] lib2to3 doesn't recognize rb'...' as a raw byte string in Python 3 In-Reply-To: <1428585495.21.0.103830054834.issue23894@psf.upfronthosting.co.za> Message-ID: <1428691460.33.0.640277550109.issue23894@psf.upfronthosting.co.za> Eli Bendersky added the comment: Serhiy, AFAIK lib2to3 has been repurposed to parse Python 3 as well - it has certainly gained quite a bit of support for that. rb'...' is valid in Python 3: $ python3 Python 3.4.0 (default, Apr 11 2014, 13:05:11) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> rb'abc' b'abc' >>> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 21:48:37 2015 From: report at bugs.python.org (Donald Stufft) Date: Fri, 10 Apr 2015 19:48:37 +0000 Subject: [issue23899] HTTP regression in distutils uploads to chishop In-Reply-To: <1428593783.07.0.14236214587.issue23899@psf.upfronthosting.co.za> Message-ID: <1428695317.75.0.864213617873.issue23899@psf.upfronthosting.co.za> Donald Stufft added the comment: I wonder if it's this? https://github.com/python/cpython/commit/453f86c6977bab18fe4a9c58a4155253375adc8e#diff-ff7dba04c5ad252aa440598d6c88067a ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 22:10:38 2015 From: report at bugs.python.org (Joe Jevnik) Date: Fri, 10 Apr 2015 20:10:38 +0000 Subject: [issue23910] C implementation of namedtuple (WIP) Message-ID: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> New submission from Joe Jevnik: I am working on implementing nameduple in C; I am almost there; however, on the path of moving to full compatibility, I ran into a refcount issue somewhere. Hopefully someone can help me work this out. To describe the issue, When I run the collections tests I most frequently segfault in a non namedtuple test; however, sometimes it runs (and passes) however that probably means I am using an unowned obect somewhere. I am new to the CPython API so I would love to go through this with someone to learn more about how it all works. I am currently at PyCon and would absolutly love to speak to someone in person. I will be at CPython sprints for at least one day. ---------- components: Extension Modules files: namedtuple.patch keywords: patch messages: 240447 nosy: llllllllll priority: normal severity: normal status: open title: C implementation of namedtuple (WIP) type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file38892/namedtuple.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 22:44:10 2015 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 10 Apr 2015 20:44:10 +0000 Subject: [issue23910] C implementation of namedtuple (WIP) In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1428698650.72.0.0103073606793.issue23910@psf.upfronthosting.co.za> Eric V. Smith added the comment: What's the motivating use case for this? ---------- nosy: +eric.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 23:20:33 2015 From: report at bugs.python.org (Joe Jevnik) Date: Fri, 10 Apr 2015 21:20:33 +0000 Subject: [issue23910] C implementation of namedtuple (WIP) In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1428700833.48.0.300972992459.issue23910@psf.upfronthosting.co.za> Joe Jevnik added the comment: Ideally, namedtuple is used to make your code cleaner, using "magic" indecies is less clear than using a named index in a lot of cases. Because namedtuple is mainly to make the code more readable, I don't think that it should have an impact on the runtime performance of the code. This means that namedtuple should be a very thin wrapper around tuple. Currently, namedtuple named item access is much slower than elementwise access. I have this as a standalone package (there are some changes in the diff I posted to acheive full backwards compat) here https://pypi.python.org/pypi/cnamedtuple/0.1.5 that show some profiling runs of this code. The notable one to me is named item access being around twice as fast. Another issue we ran into at work is that we found ways to get the exec call in nametuple to execute arbitrary code; while this would not be a concern for most people by the nature of the way we got this to happen, we wanted to look at other ways of writing namedtuple. I looked through some older discussion and found that non-exec solutions were rejected in the past for perfomance reasons. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 23:29:37 2015 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 10 Apr 2015 21:29:37 +0000 Subject: [issue23910] C implementation of namedtuple (WIP) In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1428701377.42.0.266995143757.issue23910@psf.upfronthosting.co.za> Eric V. Smith added the comment: Have you thought of just exposing Object/structseq.c? Before you put much time into this, I'd get Raymond's acceptance of whatever approach you want to take. It might be best to raise it on python-ideas. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 23:48:37 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Fri, 10 Apr 2015 21:48:37 +0000 Subject: [issue23910] C implementation of namedtuple (WIP) In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1428702517.51.0.63424788177.issue23910@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 10 23:54:44 2015 From: report at bugs.python.org (Joe Jevnik) Date: Fri, 10 Apr 2015 21:54:44 +0000 Subject: [issue23910] C implementation of namedtuple (WIP) In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1428702884.14.0.22651531508.issue23910@psf.upfronthosting.co.za> Joe Jevnik added the comment: would the idea be to deprecate namedtuple in favor of a public structseq that is exposed through collections, or change structseq to fit the namedtuple API? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 00:19:29 2015 From: report at bugs.python.org (Martin Panter) Date: Fri, 10 Apr 2015 22:19:29 +0000 Subject: [issue21859] Add Python implementation of FileIO In-Reply-To: <1403608013.94.0.257739188668.issue21859@psf.upfronthosting.co.za> Message-ID: <1428704369.34.0.657342190887.issue21859@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 00:25:34 2015 From: report at bugs.python.org (Eric V. Smith) Date: Fri, 10 Apr 2015 22:25:34 +0000 Subject: [issue23910] C implementation of namedtuple (WIP) In-Reply-To: <1428702884.14.0.22651531508.issue23910@psf.upfronthosting.co.za> Message-ID: <4E12E9EF-F12A-499D-8210-861516AC9CD0@trueblade.com> Eric V. Smith added the comment: I haven't seen thought it through, just that it seems very similar to a C namedtuple. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 00:31:32 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 10 Apr 2015 22:31:32 +0000 Subject: [issue23528] Limit decompressed data when reading from GzipFile In-Reply-To: <1424946126.98.0.486244279604.issue23528@psf.upfronthosting.co.za> Message-ID: <1428705092.74.0.676632728913.issue23528@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -> Limit decompressed data when reading from LZMAFile and BZ2File _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 00:33:07 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Apr 2015 22:33:07 +0000 Subject: [issue23529] Limit decompressed data when reading from LZMAFile and BZ2File In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za> Message-ID: <20150410223304.129698.71274@psf.io> Roundup Robot added the comment: New changeset 62723172412c by Antoine Pitrou in branch 'default': Issue #23529: Limit the size of decompressed data when reading from https://hg.python.org/cpython/rev/62723172412c ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 00:33:50 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Fri, 10 Apr 2015 22:33:50 +0000 Subject: [issue23529] Limit decompressed data when reading from LZMAFile and BZ2File In-Reply-To: <1424948786.21.0.575757839036.issue23529@psf.upfronthosting.co.za> Message-ID: <1428705230.41.0.875762724168.issue23529@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thank you very much for being so perseverant! The patch is now pushed into the default branch. ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 00:40:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 10 Apr 2015 22:40:33 +0000 Subject: [issue23909] highlight query string does not work on docs.python.org/2 In-Reply-To: <1428689856.01.0.985094593971.issue23909@psf.upfronthosting.co.za> Message-ID: <20150410224029.62499.80424@psf.io> Roundup Robot added the comment: New changeset 89d47911209b by Benjamin Peterson in branch '2.7': highlight is now highlighted (closes #23909) https://hg.python.org/cpython/rev/89d47911209b ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 01:44:57 2015 From: report at bugs.python.org (Eric Snow) Date: Fri, 10 Apr 2015 23:44:57 +0000 Subject: [issue23910] C implementation of namedtuple (WIP) In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1428709497.65.0.948770336617.issue23910@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 03:29:02 2015 From: report at bugs.python.org (Zachary Ware) Date: Sat, 11 Apr 2015 01:29:02 +0000 Subject: [issue20693] Sidebar scrolls down 2x as fast as page content In-Reply-To: <1392854470.16.0.730014647108.issue20693@psf.upfronthosting.co.za> Message-ID: <1428715742.81.0.0692901335912.issue20693@psf.upfronthosting.co.za> Zachary Ware added the comment: Is this still a problem? I haven't noticed it on docs.python.org in quite some time. Ezio, can you still reproduce? ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 03:29:39 2015 From: report at bugs.python.org (Eric Snow) Date: Sat, 11 Apr 2015 01:29:39 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. Message-ID: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> New submission from Eric Snow: The bootstrap code has a clear division between the core import functionality and the path-based import machinery. The attached patch makes that division explicit by moving the latter into its own module. The module is also frozen, necessarily. In addition to clearly distinguishing the two parts, this division will help with some later work that I'd like to do later with an encapsulated import system abstraction. The patch uses the name "pathy" throughout, which I'll change to something more descriptive later. I'll also add the news entry then. ---------- assignee: eric.snow components: Interpreter Core files: path-based-importlib.diff keywords: patch messages: 240457 nosy: brett.cannon, eric.snow, ncoghlan priority: normal severity: normal stage: patch review status: open title: Move path-based bootstrap code to a separate frozen file. type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file38893/path-based-importlib.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 04:07:43 2015 From: report at bugs.python.org (Zachary Ware) Date: Sat, 11 Apr 2015 02:07:43 +0000 Subject: [issue21416] argparse should accept bytes arguments as originally passed In-Reply-To: <1399050639.0.0.425035380654.issue21416@psf.upfronthosting.co.za> Message-ID: <1428718063.94.0.0347466221768.issue21416@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 04:15:46 2015 From: report at bugs.python.org (James Edwards) Date: Sat, 11 Apr 2015 02:15:46 +0000 Subject: [issue23912] Inconsistent whitespace/formatting in docs/reference/datamodel/Special Method Lookup Message-ID: <1428718546.88.0.646269142708.issue23912@psf.upfronthosting.co.za> New submission from James Edwards: There's inconsistent leading whitespace between the two classes in the 4th code snippet of the "Special Method Lookup" section. https://docs.python.org/3/reference/datamodel.html#special-method-lookup The (very substantial :) included patch makes both classes use consistent leading whitespace, that is PEP-8 conformant. (This issue also exists in the Python 2 documentation[1], but since other things have changed -- e.g. print statement -> function, metaclass declaration -- the same patch won't apply cleanly.) [1] https://docs.python.org/2/reference/datamodel.html#special-method-lookup-for-new-style-classes ---------- assignee: docs at python components: Documentation files: datamodel.rst.diff keywords: patch messages: 240458 nosy: docs at python, jedwards priority: normal severity: normal status: open title: Inconsistent whitespace/formatting in docs/reference/datamodel/Special Method Lookup versions: Python 3.6 Added file: http://bugs.python.org/file38894/datamodel.rst.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 04:53:59 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 11 Apr 2015 02:53:59 +0000 Subject: [issue9740] Client support for HTTP 1.1 persistent connections throughout the standard library In-Reply-To: <1283428611.84.0.131704513964.issue9740@psf.upfronthosting.co.za> Message-ID: <1428720839.79.0.955224952345.issue9740@psf.upfronthosting.co.za> Martin Panter added the comment: Tweaking the title to exclude servers. Persistent connections have apparently been supported in the low-level server for ages, since Issue 430706, and now that the close_connection flag is documented (Issue 23410), someone implementing a server should be able to use that to implement HTTP 1.0 keep-alive connections, etc as well. For the client aspect, this bug is rather vague about exactly what should be added. Issue 3566 has been committed and closed, meaning now we should have an easier way to detect when a persistent connection has been dropped by the server. Here is a list of other things that come to mind: 1. Allow a way of polling for an unsolicited disconnection or 408 response without sending a request, either by: * exposing the sock attribute or adding a fileno() method, so that select() can be called, or * adding a new poll_response() or similar method 2. Poll if disconnected before sending a request, to avoid in 99% of cases the problem with non-idempotent requests (like POST) where you do not know if they were accepted or not 3. Change urlopen() to reuse the same connection when retrying a request (e.g. for redirects, authentication) 4. A urllib.request.PersistentConnectionHandler class or other urlopen() level API where the caller can reuse the same connection for multiple requests to the same host. Like HTTPConnection mainly does, but with the extra redirect, error, etc handling of urlopen(). I think the first point is important to do, because I have had to work around this by relying on the undocumented ?HTTPConnection.sock? attribute. Once point 1 is done, point 2 might be easy to do in user code. The last two points I currently don?t have so much personal interest in seeing in the standard library, unless others also want something like them. ---------- title: Support for HTTP 1.1 persistent connections throughout the standard library -> Client support for HTTP 1.1 persistent connections throughout the standard library _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 06:19:08 2015 From: report at bugs.python.org (Zachary Ware) Date: Sat, 11 Apr 2015 04:19:08 +0000 Subject: [issue23452] Build errors using VS Express 2013 in win32 mode In-Reply-To: <1423723559.86.0.395515662536.issue23452@psf.upfronthosting.co.za> Message-ID: <1428725948.3.0.087402067663.issue23452@psf.upfronthosting.co.za> Zachary Ware added the comment: Unfortunately, I don't have any ideas. Mark, is this still happening? If so, I think your real solution is going to be to install VS2015 CTP 6 (and later the real thing, in whatever the free flavor is). Same for #23449. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 06:32:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Apr 2015 04:32:57 +0000 Subject: [issue23910] C implementation of namedtuple (WIP) In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1428726777.76.0.93319502785.issue23910@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 06:53:34 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Apr 2015 04:53:34 +0000 Subject: [issue20175] Derby #6: Convert 50 sites to Argument Clinic across 8 files In-Reply-To: <1389138499.96.0.517173661563.issue20175@psf.upfronthosting.co.za> Message-ID: <1428728014.63.0.288173148752.issue20175@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Updated to the tip. ---------- Added file: http://bugs.python.org/file38895/io_clinic_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 07:36:23 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 11 Apr 2015 05:36:23 +0000 Subject: [issue23887] HTTPError doesn't have a good "repr" representation In-Reply-To: <1428493453.93.0.931112960505.issue23887@psf.upfronthosting.co.za> Message-ID: <1428730583.08.0.609195783114.issue23887@psf.upfronthosting.co.za> Martin Panter added the comment: Perhaps it would be more appropriate to set the BaseException.args attribute, or chain to its __init__() method, then you wouldn?t need a custom __repr__(). ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 07:59:50 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 11 Apr 2015 05:59:50 +0000 Subject: [issue23910] C implementation of namedtuple (WIP) In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1428731990.29.0.712164703221.issue23910@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 08:33:59 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 11 Apr 2015 06:33:59 +0000 Subject: [issue14767] urllib.request.HTTPRedirectHandler raises HTTPError when Location header is relative In-Reply-To: <1336613288.44.0.609842734336.issue14767@psf.upfronthosting.co.za> Message-ID: <1428734039.56.0.900210743774.issue14767@psf.upfronthosting.co.za> Martin Panter added the comment: Looks like this was a 3.2 regression, but was fixed in Issue 13696. ---------- nosy: +vadmium resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> [urllib.request.HTTPRedirectHandler.http_error_302] Relative Redirect issue _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 08:35:18 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 11 Apr 2015 06:35:18 +0000 Subject: [issue12275] urllib.request.HTTPRedirectHandler won't redirect to a URL with only path but not domain In-Reply-To: <1307430618.09.0.225442782299.issue12275@psf.upfronthosting.co.za> Message-ID: <1428734118.93.0.0922251578414.issue12275@psf.upfronthosting.co.za> Martin Panter added the comment: Already fixed in 3.2 it seems ---------- nosy: +vadmium resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> [urllib.request.HTTPRedirectHandler.http_error_302] Relative Redirect issue versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 09:11:10 2015 From: report at bugs.python.org (Joe Jevnik) Date: Sat, 11 Apr 2015 07:11:10 +0000 Subject: [issue23910] C implementation of namedtuple (WIP) In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1428736270.06.0.775260171621.issue23910@psf.upfronthosting.co.za> Joe Jevnik added the comment: I stripped down the patch to only the descriptor like we had discussed. ---------- Added file: http://bugs.python.org/file38896/namedtuple.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 10:04:00 2015 From: report at bugs.python.org (Boyd Blackwell) Date: Sat, 11 Apr 2015 08:04:00 +0000 Subject: [issue23913] error in some byte sizes of docs in array module Message-ID: <1428739439.99.0.273745755962.issue23913@psf.upfronthosting.co.za> New submission from Boyd Blackwell: See 8.6. array ? Efficient arrays of numeric values? I think these two table entries should list 4 instead of 2, at least for 64 python. The error is currently in 2.710rc0, but also in previous versions. also in 3.4.3, presumably some previous versions it might also be argued that the column heading should not but minimum size but simply Element Size (bytes) 'i' signed int int 2 'I' unsigned int long 2 code: import array a = array.array('I') a.fromstring('\x01\x02\x03\x04') print(a) #array('I', [67305985L]) # one element as expected (4 bytes, 4 bytes/elt) a = array.array('H') a.fromstring('\x01\x02\x03\x04') print(a) #array('H', [513, 1027]) # two elements as expected (4 bytes, 2 bytes/elt) ---------- assignee: docs at python components: Documentation files: arraydocbug.py messages: 240466 nosy: bdb112, docs at python priority: normal severity: normal status: open title: error in some byte sizes of docs in array module versions: Python 2.7 Added file: http://bugs.python.org/file38897/arraydocbug.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 10:31:36 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 11 Apr 2015 08:31:36 +0000 Subject: [issue23913] error in some byte sizes of docs in array module In-Reply-To: <1428739439.99.0.273745755962.issue23913@psf.upfronthosting.co.za> Message-ID: <1428741096.84.0.774163902512.issue23913@psf.upfronthosting.co.za> Stefan Behnel added the comment: As noted below the table, the exact size is platform specific, so the current documentation is correct in stating a "minimum size in bytes" of "2" for int. https://en.wikipedia.org/wiki/C_data_types IMHO, close as "not a bug" as it works as documented. ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 12:56:55 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 11 Apr 2015 10:56:55 +0000 Subject: [issue22450] urllib doesn't put Accept: */* in the headers In-Reply-To: <1411257032.38.0.526589346468.issue22450@psf.upfronthosting.co.za> Message-ID: <1428749815.07.0.643448528089.issue22450@psf.upfronthosting.co.za> Martin Panter added the comment: The RFC says ?A request without any Accept header field implies that the user agent will accept any media type in response?, which sounds the same as ?Accept: */*?. I don?t understand why adding it should make a real difference. If you really desire only application/json, you should probably include ?Accept: application/json? in the request. Otherwise, it would probably be more robust to make your program accept both types. I have come across the same deal with application/atom+xml vs text/xml vs application/xml. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 13:26:14 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 11 Apr 2015 11:26:14 +0000 Subject: [issue15267] tempfile.TemporaryFile and httplib incompatibility In-Reply-To: <1341620675.47.0.0551988049302.issue15267@psf.upfronthosting.co.za> Message-ID: <1428751574.42.0.718273507638.issue15267@psf.upfronthosting.co.za> Martin Panter added the comment: See also Issue 23740, about cleaning up the types for computing Content-Length in 3.5. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 13:46:45 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Apr 2015 11:46:45 +0000 Subject: [issue15267] tempfile.TemporaryFile and httplib incompatibility In-Reply-To: <1341620675.47.0.0551988049302.issue15267@psf.upfronthosting.co.za> Message-ID: <1428752805.76.0.345527330089.issue15267@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: More general and simple solution is to make tempfile.NamedTemporaryFile new-style class. Old-style class: >>> import tempfile >>> f = tempfile.NamedTemporaryFile() >>> len(f) Traceback (most recent call last): File "", line 1, in File "/home/serhiy/py/cpython-2.7/Lib/tempfile.py", line 391, in __getattr__ a = getattr(file, name) AttributeError: 'file' object has no attribute '__len__' New-style class: >>> import tempfile >>> f = tempfile.NamedTemporaryFile() >>> len(f) Traceback (most recent call last): File "", line 1, in TypeError: object of type '_TemporaryFileWrapper' has no len() ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 13:52:05 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 11 Apr 2015 11:52:05 +0000 Subject: [issue8823] urllib2 does not catch httplib.BadStatusLine In-Reply-To: <1274881450.55.0.827580135846.issue8823@psf.upfronthosting.co.za> Message-ID: <1428753125.09.0.188301192347.issue8823@psf.upfronthosting.co.za> Martin Panter added the comment: See also Issue 22797, about documenting that non-URLError exceptions may be raised. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 13:58:11 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 11 Apr 2015 11:58:11 +0000 Subject: [issue22248] urllib.request.urlopen raises exception when 30X-redirect url contains non-ascii chars In-Reply-To: <1408697883.93.0.665294573507.issue22248@psf.upfronthosting.co.za> Message-ID: <1428753491.53.0.50766550493.issue22248@psf.upfronthosting.co.za> Martin Panter added the comment: Same as Issue 17214 ---------- nosy: +vadmium resolution: -> duplicate status: open -> closed superseder: -> http.client.HTTPConnection.putrequest encode error _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 13:59:23 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Apr 2015 11:59:23 +0000 Subject: [issue23912] Inconsistent whitespace/formatting in docs/reference/datamodel/Special Method Lookup In-Reply-To: <1428718546.88.0.646269142708.issue23912@psf.upfronthosting.co.za> Message-ID: <20150411115919.129684.25098@psf.io> Roundup Robot added the comment: New changeset 714b7b684610 by Berker Peksag in branch '3.4': Issue #23912: Fix code formatting in datamodel.rst. https://hg.python.org/cpython/rev/714b7b684610 New changeset 5cd072882051 by Berker Peksag in branch 'default': Issue #23912: Fix code formatting in datamodel.rst. https://hg.python.org/cpython/rev/5cd072882051 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 14:00:21 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 11 Apr 2015 12:00:21 +0000 Subject: [issue23912] Inconsistent whitespace/formatting in docs/reference/datamodel/Special Method Lookup In-Reply-To: <1428718546.88.0.646269142708.issue23912@psf.upfronthosting.co.za> Message-ID: <1428753621.8.0.708798454493.issue23912@psf.upfronthosting.co.za> Berker Peksag added the comment: Fixed. Thanks for the patch, James. ---------- 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 Sat Apr 11 14:24:41 2015 From: report at bugs.python.org (Steven Samuel Cole) Date: Sat, 11 Apr 2015 12:24:41 +0000 Subject: [issue2943] Distutils should generate a better error message when the SDK is not installed In-Reply-To: <1211455981.94.0.404413935613.issue2943@psf.upfronthosting.co.za> Message-ID: <1428755081.66.0.683592774004.issue2943@psf.upfronthosting.co.za> Changes by Steven Samuel Cole : ---------- nosy: +ssc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 14:52:42 2015 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 11 Apr 2015 12:52:42 +0000 Subject: [issue23914] pickle fails with SystemError Message-ID: <1428756762.72.0.925495036586.issue23914@psf.upfronthosting.co.za> New submission from Alex Gaynor: >>> pickle.loads(b'(o.\x7f.') Traceback (most recent call last): File "", line 1, in SystemError: Objects/tupleobject.c:71: bad argument to internal function (Or the equivalent using cPickle on Python 2) Found using http://lcamtuf.coredump.cx/afl/ ---------- components: Extension Modules messages: 240475 nosy: alex priority: normal severity: normal status: open title: pickle fails with SystemError type: crash versions: Python 2.7, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 15:21:17 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Apr 2015 13:21:17 +0000 Subject: [issue23914] pickle fails with SystemError In-Reply-To: <1428756762.72.0.925495036586.issue23914@psf.upfronthosting.co.za> Message-ID: <1428758477.22.0.666452207524.issue23914@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Warning: The pickle module is not intended to be secure against erroneous or maliciously constructed data. Never unpickle data received from an untrusted or unauthenticated source. pickle.loads(b'cos\nsystem\n(Vrm -rf /\ntR.') ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 15:22:21 2015 From: report at bugs.python.org (Alex Gaynor) Date: Sat, 11 Apr 2015 13:22:21 +0000 Subject: [issue23914] pickle fails with SystemError In-Reply-To: <1428756762.72.0.925495036586.issue23914@psf.upfronthosting.co.za> Message-ID: <1428758541.15.0.097686864594.issue23914@psf.upfronthosting.co.za> Alex Gaynor added the comment: Yes, it can execute arbitrary code, but I think we should prefer raising "specific" error messages, instead of failing inside tuple details. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 16:41:57 2015 From: report at bugs.python.org (Davin Potts) Date: Sat, 11 Apr 2015 14:41:57 +0000 Subject: [issue12738] Bug in multiprocessing.JoinableQueue() implementation on Ubuntu 11.04 In-Reply-To: <1313108742.86.0.818410001029.issue12738@psf.upfronthosting.co.za> Message-ID: <1428763317.81.0.857360907162.issue12738@psf.upfronthosting.co.za> Davin Potts added the comment: Closing this very stale issue as out of date with no response from OP since request months ago for enough info to be able to proceed. ---------- resolution: -> out of date status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 16:42:29 2015 From: report at bugs.python.org (Davin Potts) Date: Sat, 11 Apr 2015 14:42:29 +0000 Subject: [issue23072] 2.7.9 multiprocessing compile conflict In-Reply-To: <1418794673.39.0.221318823729.issue23072@psf.upfronthosting.co.za> Message-ID: <1428763349.83.0.0565529916853.issue23072@psf.upfronthosting.co.za> Davin Potts added the comment: Closing this very stale issue as out of date with no response from OP since request months ago for enough info to be able to proceed. ---------- resolution: -> out of date status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 16:43:39 2015 From: report at bugs.python.org (Davin Potts) Date: Sat, 11 Apr 2015 14:43:39 +0000 Subject: [issue21429] Input.output error with multiprocessing In-Reply-To: <1399220691.1.0.523621963732.issue21429@psf.upfronthosting.co.za> Message-ID: <1428763419.73.0.316305923433.issue21429@psf.upfronthosting.co.za> Davin Potts added the comment: Closing this stale issue as out of date with no response from OP since request months ago for enough info to be able to proceed. ---------- resolution: -> out of date status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 17:13:48 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 11 Apr 2015 15:13:48 +0000 Subject: [issue23913] error in some byte sizes of docs in array module In-Reply-To: <1428739439.99.0.273745755962.issue23913@psf.upfronthosting.co.za> Message-ID: <1428765228.36.0.462748001958.issue23913@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 Sat Apr 11 17:17:40 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 11 Apr 2015 15:17:40 +0000 Subject: [issue15267] tempfile.TemporaryFile and httplib incompatibility In-Reply-To: <1341620675.47.0.0551988049302.issue15267@psf.upfronthosting.co.za> Message-ID: <1428765460.53.0.790894767007.issue15267@psf.upfronthosting.co.za> R. David Murray added the comment: We don't do classic to new style class changes for bug fixes without a compelling reason; we've been bitten by unexpected breakage doing that in the past. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 18:24:34 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 11 Apr 2015 16:24:34 +0000 Subject: [issue23914] pickle fails with SystemError In-Reply-To: <1428756762.72.0.925495036586.issue23914@psf.upfronthosting.co.za> Message-ID: <1428769474.77.0.33211291863.issue23914@psf.upfronthosting.co.za> R. David Murray added the comment: I dob't see a strong motivation to do that. What's the use case? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 18:29:20 2015 From: report at bugs.python.org (Travis A. Everett) Date: Sat, 11 Apr 2015 16:29:20 +0000 Subject: [issue23915] traceback set with BaseException.with_traceback() overwritten on raise Message-ID: <1428769760.16.0.251757749986.issue23915@psf.upfronthosting.co.za> New submission from Travis A. Everett: When BaseException.with_traceback(tb) is used, the __traceback__ property is properly set, but the property gets overwritten when the exception is raised. The attached file demonstrates the issue by raising exception a, which doesn't use with_traceback, and exception b, which uses with_traceback(a.__traceback__). It also demonstrates that the exception object can't observe this change. Executing the attached file produces output like: a.__traceback__ before raise: [None] a.__traceback__ after raise : [] b.__traceback__ before raise: [] b.__traceback__ after raise : [] ---------- files: exctest.py messages: 240483 nosy: abathur priority: normal severity: normal status: open title: traceback set with BaseException.with_traceback() overwritten on raise type: behavior versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file38898/exctest.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 18:40:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Apr 2015 16:40:28 +0000 Subject: [issue23826] test_enum fails under -OO In-Reply-To: <1427818238.81.0.788495836451.issue23826@psf.upfronthosting.co.za> Message-ID: <20150411164025.62509.62014@psf.io> Roundup Robot added the comment: New changeset a5530207b003 by Ethan Furman in branch 'default': Issue23826: fix doc test for -OO runs https://hg.python.org/cpython/rev/a5530207b003 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 18:43:13 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 11 Apr 2015 16:43:13 +0000 Subject: [issue23826] test_enum fails under -OO In-Reply-To: <1427818238.81.0.788495836451.issue23826@psf.upfronthosting.co.za> Message-ID: <1428770593.99.0.165940917001.issue23826@psf.upfronthosting.co.za> Ethan Furman added the comment: Decided to go with a simpler version: one complete doc variable for with and without docs -- much easier to maintain in the future. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 18:47:07 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 11 Apr 2015 16:47:07 +0000 Subject: [issue23900] Add a default docstring to Enum subclasses In-Reply-To: <1428597757.76.0.767487050149.issue23900@psf.upfronthosting.co.za> Message-ID: <1428770827.44.0.240791779109.issue23900@psf.upfronthosting.co.za> Ethan Furman added the comment: We could do something like: 'An enumeration.' and perhaps even something like: 'An enumeration based on .' It's not much, but is better than the obviously wrong generic version. ---------- assignee: -> ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 18:50:36 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 11 Apr 2015 16:50:36 +0000 Subject: [issue23915] traceback set with BaseException.with_traceback() overwritten on raise In-Reply-To: <1428769760.16.0.251757749986.issue23915@psf.upfronthosting.co.za> Message-ID: <1428771036.68.0.888339573334.issue23915@psf.upfronthosting.co.za> R. David Murray added the comment: With_traceback's original oupose is now served by chained tracebacks and 'from'. However, it is documented to work so it ought to :) ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 18:52:47 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 11 Apr 2015 16:52:47 +0000 Subject: [issue23008] pydoc enum.{,Int}Enum fails In-Reply-To: <1418018648.34.0.0967171282391.issue23008@psf.upfronthosting.co.za> Message-ID: <1428771167.26.0.812847922443.issue23008@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +barry, eli.bendersky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 19:04:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Apr 2015 17:04:58 +0000 Subject: [issue23826] test_enum fails under -OO In-Reply-To: <1427818238.81.0.788495836451.issue23826@psf.upfronthosting.co.za> Message-ID: <1428771898.4.0.18699368314.issue23826@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It doesn't follow the style of other tests (see for example test_pydoc), but it works. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 19:13:06 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 11 Apr 2015 17:13:06 +0000 Subject: [issue22932] email.utils.formatdate uses unreliable time.timezone constant In-Reply-To: <1416845840.06.0.178834731879.issue22932@psf.upfronthosting.co.za> Message-ID: <1428772386.83.0.182192218398.issue22932@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 20:01:42 2015 From: report at bugs.python.org (Cyd Haselton) Date: Sat, 11 Apr 2015 18:01:42 +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: <1428775302.86.0.424358814808.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: FYI, even with patches applied to main.c and python.c, the newly-built python binary segfaults in the same location. I'll tear down and re-do everything (git clone master, patch, configure and make) but I may not get to it until next weekend. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 20:22:21 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Apr 2015 18:22:21 +0000 Subject: [issue23008] pydoc enum.{,Int}Enum fails In-Reply-To: <1418018648.34.0.0967171282391.issue23008@psf.upfronthosting.co.za> Message-ID: <1428776541.6.0.889658155061.issue23008@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This is because bool(enum.Enum) is False. Other example: $ pydoc3 builtins.False no Python documentation found for 'builtins.False' $ pydoc3 builtins.True Help on bool in builtins object: builtins.True = class bool(int) ... Here is simple fix. ---------- keywords: +patch nosy: +serhiy.storchaka stage: -> patch review versions: +Python 2.7, Python 3.5 Added file: http://bugs.python.org/file38899/pydoc_resolve_false.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 22:07:34 2015 From: report at bugs.python.org (David Roundy) Date: Sat, 11 Apr 2015 20:07:34 +0000 Subject: [issue23916] module importing performance regression Message-ID: <1428782854.88.0.072820618341.issue23916@psf.upfronthosting.co.za> New submission from David Roundy: I have observed a performance regression in module importing. In python 3.4.2, importing a module from the current directory (where the script is located) causes the entire directory to be read. When there are many files in this directory, this can cause the script to run very slowly. In python 2.7.9, this behavior is not present. It would be preferable (in my opinion) to revert the change that causes python to read the entire user directory. ---------- messages: 240491 nosy: daveroundy priority: normal severity: normal status: open title: module importing performance regression versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 22:20:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 11 Apr 2015 20:20:41 +0000 Subject: [issue23916] module importing performance regression In-Reply-To: <1428782854.88.0.072820618341.issue23916@psf.upfronthosting.co.za> Message-ID: <1428783641.52.0.511559891475.issue23916@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +brett.cannon, eric.snow, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 22:37:03 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 Apr 2015 20:37:03 +0000 Subject: [issue23916] module importing performance regression In-Reply-To: <1428782854.88.0.072820618341.issue23916@psf.upfronthosting.co.za> Message-ID: <1428784623.37.0.0933890227717.issue23916@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This change is actually an optimization. The directory is only read once and its contents are then cached, which allows for much quicker imports when multiple modules are in the directory (common case of a Python package). Can you tell us more about your setup? - how many files are in the directory - what filesystem is used - whether the filesystem is local or remote (e.g. network-attached) - your OS and OS version Also, how long is "very slowly"? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 22:39:29 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 Apr 2015 20:39:29 +0000 Subject: [issue23377] HTTPResponse may drop buffer holding next response In-Reply-To: <1422881776.12.0.998068930599.issue23377@psf.upfronthosting.co.za> Message-ID: <1428784769.46.0.219156190262.issue23377@psf.upfronthosting.co.za> Changes by Antoine Pitrou : ---------- nosy: +demian.brecht, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 22:50:13 2015 From: report at bugs.python.org (David Roundy) Date: Sat, 11 Apr 2015 20:50:13 +0000 Subject: [issue23916] module importing performance regression In-Reply-To: <1428784623.37.0.0933890227717.issue23916@psf.upfronthosting.co.za> Message-ID: David Roundy added the comment: I had suspected that might be the case. At this point mostly it's just a test case where I generated a lot of files to demonstrate the issue. In my test case hello world with one module import takes a minute and 40 seconds. I could make it take longer, of course, by creating more files. I do think scaling should be a consideration when introducing optimizations, when if getdents is usually pretty fast. If the script directory is normally the last one in the search path couldn't you skip the listing of that directory without losing your optimization? On Sat, Apr 11, 2015, 1:37 PM Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > This change is actually an optimization. The directory is only read once > and its contents are then cached, which allows for much quicker imports > when multiple modules are in the directory (common case of a Python > package). > > Can you tell us more about your setup? > - how many files are in the directory > - what filesystem is used > - whether the filesystem is local or remote (e.g. network-attached) > - your OS and OS version > > Also, how long is "very slowly"? > > ---------- > nosy: +pitrou > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 23:27:53 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 Apr 2015 21:27:53 +0000 Subject: [issue23916] module importing performance regression In-Reply-To: <1428782854.88.0.072820618341.issue23916@psf.upfronthosting.co.za> Message-ID: <1428787673.42.0.951738511084.issue23916@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I was asking questions because I wanted to have more precise data. I can't reproduce here: even with 500000 files in a directory, the first import takes 0.2s, not one minute. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 23:38:39 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 11 Apr 2015 21:38:39 +0000 Subject: [issue23008] pydoc enum.{,Int}Enum fails In-Reply-To: <1418018648.34.0.0967171282391.issue23008@psf.upfronthosting.co.za> Message-ID: <1428788319.97.0.380007810908.issue23008@psf.upfronthosting.co.za> R. David Murray added the comment: Lgtm, needs a test case. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 23:39:37 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 11 Apr 2015 21:39:37 +0000 Subject: [issue21511] Thinko in Lib/quopri.py, decoding b"==" to b"=" In-Reply-To: <1400171855.37.0.067918723363.issue21511@psf.upfronthosting.co.za> Message-ID: <1428788377.27.0.664680786504.issue21511@psf.upfronthosting.co.za> Guido van Rossum added the comment: Here's a unittest by Christie Wilson for this issue. ---------- keywords: +patch nosy: +gvanrossum Added file: http://bugs.python.org/file38900/fix_issue_21511.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 23:46:09 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Apr 2015 21:46:09 +0000 Subject: [issue21511] Thinko in Lib/quopri.py, decoding b"==" to b"=" In-Reply-To: <1400171855.37.0.067918723363.issue21511@psf.upfronthosting.co.za> Message-ID: <20150411214607.21097.53949@psf.io> Roundup Robot added the comment: New changeset 2582962ccf17 by Guido van Rossum in branch '3.4': Unittest for Issue 21511 by Christie Wilson bobcatfish at gmail.com. https://hg.python.org/cpython/rev/2582962ccf17 New changeset 23d37a147051 by Guido van Rossum in branch 'default': Unittest for Issue 21511 by Christie Wilson bobcatfish at gmail.com (merge from 3.4). https://hg.python.org/cpython/rev/23d37a147051 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 23:48:00 2015 From: report at bugs.python.org (Guido van Rossum) Date: Sat, 11 Apr 2015 21:48:00 +0000 Subject: [issue21511] Thinko in Lib/quopri.py, decoding b"==" to b"=" In-Reply-To: <1400171855.37.0.067918723363.issue21511@psf.upfronthosting.co.za> Message-ID: <1428788880.24.0.433185805839.issue21511@psf.upfronthosting.co.za> Guido van Rossum added the comment: Fixed, and removing the dependency on issue 18022. Thanks Christie! ---------- dependencies: -Inconsistency between quopri.decodestring() and email.quoprimime.decode() resolution: -> fixed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 23:52:04 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 Apr 2015 21:52:04 +0000 Subject: [issue23916] module importing performance regression In-Reply-To: <1428782854.88.0.072820618341.issue23916@psf.upfronthosting.co.za> Message-ID: <1428789124.94.0.744606822294.issue23916@psf.upfronthosting.co.za> Antoine Pitrou added the comment: As for your question: > If the script > directory is normally the last one in the search path couldn't you > skip the > listing of that directory without losing your optimization? Given the way the code is architected, that would complicate things significantly. Also it would introduce a rather unexpected discrepancy. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 11 23:57:01 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 Apr 2015 21:57:01 +0000 Subject: [issue23377] HTTPResponse may drop buffer holding next response In-Reply-To: <1422881776.12.0.998068930599.issue23377@psf.upfronthosting.co.za> Message-ID: <1428789421.53.0.209631437671.issue23377@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think it's ok to slightly break a non-public API since it's required to fix an obvious bug. By the way, I guess we don't support HTTP pipelining, right? ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 00:02:08 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 Apr 2015 22:02:08 +0000 Subject: [issue23904] pathlib.PurePath does not accept bytes components In-Reply-To: <1428664281.99.0.802237757059.issue23904@psf.upfronthosting.co.za> Message-ID: <1428789728.59.0.0145801550908.issue23904@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Interesting. The doc is wrong here: pathlib was designed so that it only accepts text strings. > If I use "surrogateescape" (see PEP383) how can I display the > fake-unicode path to the user? `print()` does seems to use strict > encoding. Should I encode it with "surrogateescape" or "ignore" myself > beforehand? Yes, you should probably encode it yourself. If you are sure your terminal can eat the original bytestring, then use "surrogateescape". Otherwise, "replace" sounds better so that the user knows there are some undecodable characters out there. ---------- nosy: +ncoghlan, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 00:08:46 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Apr 2015 22:08:46 +0000 Subject: [issue23904] pathlib.PurePath does not accept bytes components In-Reply-To: <1428664281.99.0.802237757059.issue23904@psf.upfronthosting.co.za> Message-ID: <20150411220842.8629.49241@psf.io> Roundup Robot added the comment: New changeset 7463c06f6e87 by Antoine Pitrou in branch '3.4': Close #23904: fix pathlib documentation misleadingly mentioning that bytes objects are accepted in the PurePath constructor https://hg.python.org/cpython/rev/7463c06f6e87 New changeset 386732087dfb by Antoine Pitrou in branch 'default': Close #23904: fix pathlib documentation misleadingly mentioning that bytes objects are accepted in the PurePath constructor https://hg.python.org/cpython/rev/386732087dfb ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 00:09:05 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sat, 11 Apr 2015 22:09:05 +0000 Subject: [issue23904] pathlib.PurePath does not accept bytes components In-Reply-To: <1428664281.99.0.802237757059.issue23904@psf.upfronthosting.co.za> Message-ID: <1428790145.57.0.336321174438.issue23904@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the report! ---------- versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 00:14:07 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Apr 2015 22:14:07 +0000 Subject: [issue5309] distutils doesn't parallelize extension module compilation In-Reply-To: <1235007592.93.0.0598331575131.issue5309@psf.upfronthosting.co.za> Message-ID: <20150411221404.41568.41846@psf.io> Roundup Robot added the comment: New changeset fc28c67fbbd3 by doko in branch 'default': - Modules/Setup.dist: remove time extension duplicate, introduced by the fix for #5309. https://hg.python.org/cpython/rev/fc28c67fbbd3 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 00:31:43 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 11 Apr 2015 22:31:43 +0000 Subject: [issue21511] Thinko in Lib/quopri.py, decoding b"==" to b"=" In-Reply-To: <1400171855.37.0.067918723363.issue21511@psf.upfronthosting.co.za> Message-ID: <1428791503.04.0.554884956948.issue21511@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: test needed -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 00:43:00 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 11 Apr 2015 22:43:00 +0000 Subject: [issue23686] Update Windows and OS X installer OpenSSL to 1.0.2a In-Reply-To: <1426591782.15.0.995555672449.issue23686@psf.upfronthosting.co.za> Message-ID: <1428792180.05.0.561864879766.issue23686@psf.upfronthosting.co.za> Steve Dower added the comment: Attached a patch that updates 3.5. Zach - please let me know if I missed something you'd normally do for this. ---------- keywords: +patch Added file: http://bugs.python.org/file38901/23686_35.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 00:52:09 2015 From: report at bugs.python.org (Matthias Klose) Date: Sat, 11 Apr 2015 22:52:09 +0000 Subject: [issue23917] please fall back to sequential compilation when concurrent doesn't exist Message-ID: <1428792729.56.0.740382381475.issue23917@psf.upfronthosting.co.za> New submission from Matthias Klose: issue #16104 introduces parallel byte compilation, however the method is now overly strict when workers > 1 and no concurrent support available. Please just fall back to sequential byte compilation in this case. ---------- components: Library (Lib) messages: 240507 nosy: Claudiu.Popa, brett.cannon, doko priority: normal severity: normal status: open title: please fall back to sequential compilation when concurrent doesn't exist versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 01:01:17 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 11 Apr 2015 23:01:17 +0000 Subject: [issue23817] Consider FreeBSD like any other OS in SOVERSION In-Reply-To: <1427806007.43.0.118979455245.issue23817@psf.upfronthosting.co.za> Message-ID: <20150411230114.21073.61326@psf.io> Roundup Robot added the comment: New changeset 0b3027a2abbc by Ned Deily in branch 'default': Issue #23817: run autoreconf to update configure. https://hg.python.org/cpython/rev/0b3027a2abbc ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 01:03:49 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 11 Apr 2015 23:03:49 +0000 Subject: [issue23915] traceback set with BaseException.with_traceback() overwritten on raise In-Reply-To: <1428769760.16.0.251757749986.issue23915@psf.upfronthosting.co.za> Message-ID: <1428793429.59.0.622723871318.issue23915@psf.upfronthosting.co.za> Martin Panter added the comment: My understanding is that the traceback is a linked list. Every time the exception is raised into a calling function or exception handler, a new traceback object is inserted at the front of the list. Your original traceback is not overwritten, it is just pushed back in the list. See my version of the demonstration script. The output is now: a.__traceback__ before raise : [None] a.__traceback__ after raise : [, None] b.__traceback__ before raise : [, None] b.__traceback__ after raise : [, , None] ---------- nosy: +vadmium Added file: http://bugs.python.org/file38902/traceback_list.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 01:07:48 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 11 Apr 2015 23:07:48 +0000 Subject: [issue23895] PATCH: python socket module fails to build on Solaris when -zignore is in LDFLAGS In-Reply-To: <1428586985.69.0.885305793504.issue23895@psf.upfronthosting.co.za> Message-ID: <1428793668.5.0.231150281588.issue23895@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +jcea _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 01:10:23 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 11 Apr 2015 23:10:23 +0000 Subject: [issue23896] lib2to3 doesn't provide a grammar where exec is a function In-Reply-To: <1428587382.51.0.855590572872.issue23896@psf.upfronthosting.co.za> Message-ID: <1428793823.13.0.386009564213.issue23896@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 01:20:12 2015 From: report at bugs.python.org (Zachary Ware) Date: Sat, 11 Apr 2015 23:20:12 +0000 Subject: [issue23686] Update Windows and OS X installer OpenSSL to 1.0.2a In-Reply-To: <1426591782.15.0.995555672449.issue23686@psf.upfronthosting.co.za> Message-ID: <1428794412.48.0.434667895543.issue23686@psf.upfronthosting.co.za> Zachary Ware added the comment: Looks like that covers it. The one thing I'm concerned about is that, historically, we've always said "you can point our build system at whatever version of OpenSSL you want and it should work", but obviously this locks us in to 1.0.2+. Really, there shouldn't be much reason to use anything else, but I'm not sure we want to give up that ability. I have no idea if anybody actually relies on it though; we could just commit it and backpedal later if anybody complains. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 01:34:23 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 11 Apr 2015 23:34:23 +0000 Subject: [issue23008] pydoc enum.{,Int}Enum fails In-Reply-To: <1418018648.34.0.0967171282391.issue23008@psf.upfronthosting.co.za> Message-ID: <1428795263.0.0.23864812695.issue23008@psf.upfronthosting.co.za> Martin Panter added the comment: The fix is definitely an improvement. Though there is still one obvious flaw remaining, which applies to any attribute that is set to None: $ ~/proj/python/cpython/python -bWall -m pydoc builtins.None No Python documentation found for 'builtins.None'. Use help() to get the interactive help utility. Use help(str) for help on the str class. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 01:36:35 2015 From: report at bugs.python.org (Matthias Klose) Date: Sat, 11 Apr 2015 23:36:35 +0000 Subject: [issue23918] symbols namespace pollution Message-ID: <1428795395.74.0.22674392758.issue23918@psf.upfronthosting.co.za> New submission from Matthias Klose: 3.5 introduces the symbols: DirEntryType ScandirIteratorType introduced by the fix for issue #22524. These should either be local symbols, or prefixed with _Py or Py. ---------- components: Extension Modules messages: 240512 nosy: doko, haypo priority: normal severity: normal status: open title: symbols namespace pollution versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 02:00:14 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Apr 2015 00:00:14 +0000 Subject: [issue14050] Tutorial, list.sort() and items comparability In-Reply-To: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za> Message-ID: <1428796814.1.0.530086647426.issue14050@psf.upfronthosting.co.za> Martin Panter added the comment: The first paragraph in the patch already seems to have been applied, for Issue 21575. The Sorting How-to already guarantees that defining only __lt__() is sufficient for sorted() and list.sort(). And the list.sort() specification says ?only < comparisons? are used, which implies that only __gt__() may also be sufficient. It might be good to change ?ordering relationship? to ?total ordering relationship?, but I think further explanation and other details are probably not worth adding to the tutorial. They could be clarified in the main documentation, but that is probably a separate issue. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 02:20:59 2015 From: report at bugs.python.org (David Roundy) Date: Sun, 12 Apr 2015 00:20:59 +0000 Subject: [issue23916] module importing performance regression In-Reply-To: <1428789124.94.0.744606822294.issue23916@psf.upfronthosting.co.za> Message-ID: David Roundy added the comment: My tests involved 8 million files on an ext4 file system. I expect that accounts for the difference. It's true that it's an excessive number of files, and maybe the best option is to ignore the problem. On Sat, Apr 11, 2015 at 2:52 PM Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > As for your question: > > > If the script > > directory is normally the last one in the search path couldn't you > > skip the > > listing of that directory without losing your optimization? > > Given the way the code is architected, that would complicate things > significantly. Also it would introduce a rather unexpected discrepancy. > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 02:34:21 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 12 Apr 2015 00:34:21 +0000 Subject: [issue23916] module importing performance regression In-Reply-To: <1428782854.88.0.072820618341.issue23916@psf.upfronthosting.co.za> Message-ID: <1428798861.62.0.990123280471.issue23916@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Indeed, that doesn't sound like something we want to support. I'm closing then. ---------- resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 02:43:52 2015 From: report at bugs.python.org (Matthias Klose) Date: Sun, 12 Apr 2015 00:43:52 +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: <1428799432.65.0.257758030504.issue22980@psf.upfronthosting.co.za> Matthias Klose added the comment: I plan to revert this "fix" and replace it with a more general solution, at least for POSIX based systems. Ad hoc introduction of the bitness is at least wrong or not helpful for x32 and ARM ilp32. (currently at PyCon, and would like to discuss this at the sprint days) ---------- nosy: +doko _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 02:49:50 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Apr 2015 00:49:50 +0000 Subject: [issue10289] Document magic methods called by built-in functions In-Reply-To: <1288655696.94.0.809001507215.issue10289@psf.upfronthosting.co.za> Message-ID: <1428799790.45.0.920803795253.issue10289@psf.upfronthosting.co.za> Martin Panter added the comment: Sizeof is not relevant to the built-in functions as far as I know. It is already described at . Some more delegations that I think should be documented here (at least for Python 3): * abs() -> object.__abs__() * bytes() -> object.__bytes__() * complex() -> object.__complex__() * divmod() -> object.__divmod__() * float() -> object.__float__(). The text is already there, but there is no hyperlink. * hex() -> object.__index__(). Also just needs a hyperlink. * isinstance() -> class.__instancecheck__() * issubclass() -> class.__subclasscheck__() * pow() -> object.__pow__() * round() -> object.__round__() I added some comments about the sorted() specification on Reitveld, but maybe they should be handled in a separate issue, because the delegation is less direct compared to the other functions being considered here. And any update to sorted() should probably also consider list.sort(), min(), max(), and maybe the bisect and heapq modules. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 03:17:38 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Apr 2015 01:17:38 +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: <1428801458.68.0.395863471223.issue2651@psf.upfronthosting.co.za> Martin Panter added the comment: The moratorium is over as far as I understand, and PEP 3151 (OSError changes) has already been implemented. My understanding is that exception messages are not generally part of the API. I think that avoiding this surprising quirk is more important than retaining backwards compatibility with the formatted exception message. But if it cannot be changed, we can at least document the quirk. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 03:28:28 2015 From: report at bugs.python.org (Zachary Ware) Date: Sun, 12 Apr 2015 01:28:28 +0000 Subject: [issue19050] crash while writing to a closed file descriptor In-Reply-To: <1379595509.08.0.968867256316.issue19050@psf.upfronthosting.co.za> Message-ID: <1428802108.04.0.640309901233.issue19050@psf.upfronthosting.co.za> Zachary Ware added the comment: Still an issue in 2.7.10rc0+. Here's a couple different reproducers that come closer to the heart of the matter: """ >>> import os [43913 refs] >>> os.close(1) [43913 refs] >>> input() 1 [43915 refs] """ """ >>> import os [43913 refs] >>> f = file('test', 'wb') [43921 refs] >>> os.close(f.fileno()) [43921 refs] >>> f.flush() [43921 refs] >>> f.write('test') [43921 refs] >>> f.flush() """ The problem appears to be calling fflush on a pointer to a closed file. In the first reproducer, this happens in myreadline.c, the second in fileobject.c. I was interested enough to track it down; I'm not motivated enough to fix it since it appears to be broken only in 2.7. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 03:29:55 2015 From: report at bugs.python.org (Zachary Ware) Date: Sun, 12 Apr 2015 01:29:55 +0000 Subject: [issue19050] crash while writing to a closed file descriptor In-Reply-To: <1379595509.08.0.968867256316.issue19050@psf.upfronthosting.co.za> Message-ID: <1428802195.53.0.526348735694.issue19050@psf.upfronthosting.co.za> Zachary Ware added the comment: On sudden inspiration, here's an even simpler reproducer: """ >>> import os [43913 refs] >>> os.close(2) """ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 03:34:48 2015 From: report at bugs.python.org (Zachary Ware) Date: Sun, 12 Apr 2015 01:34:48 +0000 Subject: [issue19050] fflush called on pointer to potentially closed file In-Reply-To: <1379595509.08.0.968867256316.issue19050@psf.upfronthosting.co.za> Message-ID: <1428802488.97.0.60421019067.issue19050@psf.upfronthosting.co.za> Zachary Ware added the comment: ...and that one does crash 3.4, so I'm a bit more interested again. I'll try to look at this at the sprints. ---------- priority: high -> critical title: crash while writing to a closed file descriptor -> fflush called on pointer to potentially closed file versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 04:34:27 2015 From: report at bugs.python.org (Zachary Ware) Date: Sun, 12 Apr 2015 02:34:27 +0000 Subject: [issue23919] test_os fails several C-level assertions Message-ID: <1428806067.72.0.786420001732.issue23919@psf.upfronthosting.co.za> New submission from Zachary Ware: Uninteresting bits of the output elided: C:\Data\code\CPython\hg.python.org\default>python -m test -vn test_os Running Debug|Win32 interpreter... == CPython 3.5.0a3+ (default:0b3027a2abbc, Apr 11 2015, 21:11:57) [MSC v.1900 32 bit (Intel)] == Windows-post2012Server-6.3.9600 little-endian == hash algorithm: siphash24 32bit == C:\Data\code\CPython\hg.python.org\default\build\test_python_4312 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, don t_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) [1/1] test_os ... test_bad_fd (test.test_os.DeviceEncodingTests) ... minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(257) : Assertion failed: fh >= 0 && (unsigned)fh < (unsigned)_nhandle ok ... test_closerange (test.test_os.FileTests) ... minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN ok ... test_15261 (test.test_os.StatAttributeTests) ... minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN ok ... test_stty_match (test.test_os.TermsizeTests) Check if stty returns the same results ... minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(257) : Assertion failed: fh >= 0 && (unsigned)fh < (unsigned)_nhandle skipped 'stty invocation failed' ... test_closerange (test.test_os.TestInvalidFD) ... minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN ok test_dup (test.test_os.TestInvalidFD) ... minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN ok test_dup2 (test.test_os.TestInvalidFD) ... minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN ok ... test_fdopen (test.test_os.TestInvalidFD) ... minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN ok ... test_fstat (test.test_os.TestInvalidFD) ... minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN ok ... test_fsync (test.test_os.TestInvalidFD) ... minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN ok ... test_inheritable (test.test_os.TestInvalidFD) ... minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN ok test_isatty (test.test_os.TestInvalidFD) ... minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN ok test_lseek (test.test_os.TestInvalidFD) ... minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN ok test_read (test.test_os.TestInvalidFD) ... minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN ok ... test_write (test.test_os.TestInvalidFD) ... minkernel\crts\ucrt\src\appcrt\lowio\osfinfo.cpp(258) : Assertion failed: _osfile(fh) & FOPEN ok ... ---------------------------------------------------------------------- Ran 189 tests in 7.424s OK (skipped=75) 1 test OK. ---------- components: Windows messages: 240522 nosy: steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: test_os fails several C-level assertions type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 04:38:47 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Apr 2015 02:38:47 +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: <1428806327.24.0.615313655088.issue18383@psf.upfronthosting.co.za> Martin Panter added the comment: issue18383_assert_warns_and_dups.patch fixes all my new test suite complaints, and removes the message about altering warnings.filters. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 04:49:44 2015 From: report at bugs.python.org (Christie) Date: Sun, 12 Apr 2015 02:49:44 +0000 Subject: [issue9517] Make test.script_helper more comprehensive, and use it in the test suite In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za> Message-ID: <1428806984.85.0.893598365411.issue9517@psf.upfronthosting.co.za> Christie added the comment: Hello @r.david.murray! > We probably don't want a multi-module changeset, though, so this could become a meta issue for new issues for converting particular test files to use script_helpers. Does this mean you'd like to leave this issue open until all of the test files are updated in separate issues? Or is it that you'd like separate changesets for each module, but all associated with this issue? Thanks! ---------- nosy: +bobcatfish _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 04:54:13 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 12 Apr 2015 02:54:13 +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: <1428807253.14.0.959308241776.issue17582@psf.upfronthosting.co.za> Benjamin Peterson added the comment: The patch seems reason, though it needs a test. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 04:59:59 2015 From: report at bugs.python.org (Al Sweigart) Date: Sun, 12 Apr 2015 02:59:59 +0000 Subject: [issue18704] IDLE: Integrate external code analysis tools In-Reply-To: <1376173040.43.0.790205199961.issue18704@psf.upfronthosting.co.za> Message-ID: <1428807599.34.0.595270276671.issue18704@psf.upfronthosting.co.za> Al Sweigart added the comment: -1 on adding PEP8 checks. PEP8 is a guideline, and having IDLE present them as warnings or errors elevates their importance. Also, this would involve adding the pep8 dependency to the standard library. A linter might be a good idea, but not a style checker. ---------- nosy: +Al.Sweigart _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 12 05:02:20 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 12 Apr 2015 03:02:20 +0000 Subject: [issue23377] HTTPResponse may drop buffer holding next response In-Reply-To: <1422881776.12.0.998068930599.issue23377@psf.upfronthosting.co.za> Message-ID: <1428807740.82.0.977350952999.issue23377@psf.upfronthosting.co.za> Martin Panter added the comment: HTTP pipelining is not supported in general. According to the module doc string, you can actually pipeline a second request if you have read the first response?s headers but not its body: >>> conn = HTTPSConnection("bugs.python.org") >>> conn.request("GET", "/") >>> response1 = conn.getresponse() # Read header section only >>> conn.request("GET", "/issue23377") >>> response1.read()[:100] # Read first body after pipelining second request b' class NonIter: ... pass ... --> list(iter(NonIter())) Traceback (most recent call last): File "", line 1, in TypeError: 'NonIter' object is not iterable --> class MaybeIter: ... @property ... def __next__(self): ... raise AttributeError ... def __iter__(self): ... return self ... --> iter(MaybeIter()) <__main__.MaybeIter object at 0xb6a5da2c> # seems to work --> list(iter(MaybeIter())) Traceback (most recent call last): File "", line 1, in File "", line 4, in __next__ AttributeError This is exactly analogous to what you are seeing with __call__ and callable(). I am not opposed to "fixing" callable(), I'm opposed to fixng only callable(). If you want to have the descriptor protocol be given more weight in dealing with special methods (aka magic methods aka dunder methods) then be thorough. Find all (or at least most ;) of the bits and pieces that rely on these __xxx__ methods, write a PEP explaining why this extra effort should be undertaken, get a reference implementation together so the performance hit can be measured, and then make the proposal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 07:48:47 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Apr 2015 05:48:47 +0000 Subject: [issue23985] Crash when deleting slices from duplicated bytearray In-Reply-To: <1429252668.91.0.45841644858.issue23985@psf.upfronthosting.co.za> Message-ID: <1429336127.66.0.9266281443.issue23985@psf.upfronthosting.co.za> Martin Panter added the comment: After cleaning my build and rebuilding with ?./configure --with-pymalloc --with-pydebug?, I reduced my script to these four lines: b1 = bytearray(b"abcdefghij") # 10 bytes del b1[:1] del b1[:1] b1 += b"klmnopq" # 7 bytes Patch bytearray-fix.patch fixes the bug by taking account fact that ob_start is offset into the allocated memory buffer when checking if a reallocation is necessary. Explanation with the unpatched code and my four-line script above: 1. First line allocates 11 bytes of memory (10 for the byte string + 1 NUL terminator) 2. First ?del? reduces the bytearray length to 9 bytes, but actually reallocates an expanded memory buffer of 16 bytes! (quirky but not the bug) 3. Second ?del? reduces the bytearray length to 8 bytes, and increments an internal ob_start offset without any memory copying or reallocation. (Fine.) 4. Appending step needs to add 7 bytes to the 8-byte array. 7 + 8 + 1 is 16 bytes total required for bytearray and NUL terminator, but since ob_start is offset from the start of the allocated memory buffer, we overwrite past the end of the buffer. Memory debugging output and extra debug printfs of my own: Resizing to size 10 (current log. offset 0 alloc 0) => Major upsize, new alloc = 11 Assigning to linear slice - Shifting ob_start for negative growth -1 Resizing to size 9 (current log. offset 1 alloc 11) => Moderate upsize, new alloc = 16 - Done assigning to linear slice Assigning to linear slice - Shifting ob_start for negative growth -1 Resizing to size 8 (current log. offset 1 alloc 16) => Minor downsize - Done assigning to linear slice Debug memory block at address p=0x7f1af630a0d0: API 'o' 16 bytes originally requested The 7 pad bytes at p-7 are FORBIDDENBYTE, as expected. The 8 pad bytes at tail=0x7f1af630a0e0 are not all FORBIDDENBYTE (0xfb): at tail+0: 0x00 *** OUCH at tail+1: 0xfb at tail+2: 0xfb at tail+3: 0xfb at tail+4: 0xfb at tail+5: 0xfb at tail+6: 0xfb at tail+7: 0xfb The block was made by call #32897 to debug malloc/realloc. Data at p: 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 Fatal Python error: bad trailing pad byte ---------- keywords: +patch Added file: http://bugs.python.org/file39098/bytearray-fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 07:54:23 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Apr 2015 05:54:23 +0000 Subject: [issue23985] Crash when deleting slices from duplicated bytearray In-Reply-To: <1429252668.91.0.45841644858.issue23985@psf.upfronthosting.co.za> Message-ID: <1429336463.82.0.907750883803.issue23985@psf.upfronthosting.co.za> Martin Panter added the comment: Posting bytearray-resize.patch which stops ?del? from expanding the allocated buffer. This one is not necessary to fix the reported bug, but avoids the separate quirk identified in step 2. ---------- stage: needs patch -> patch review Added file: http://bugs.python.org/file39099/bytearray-resize.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 08:14:10 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Apr 2015 06:14:10 +0000 Subject: [issue19087] bytearray front-slicing not optimized In-Reply-To: <1380117830.08.0.43327617783.issue19087@psf.upfronthosting.co.za> Message-ID: <1429337650.89.0.912902935775.issue19087@psf.upfronthosting.co.za> Martin Panter added the comment: I think the changes for this issue are causing the crash and unexpected buffer expansion described in Issue 23985. Appending to a bytearray() can overstep the memory buffer because it doesn?t account for ob_start when checking for resizing. And ?del? can expand the allocated memory due to an off-by-one error. Please have a look at my patches. Perhaps there are other operations that also need patching to account for ob_start. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 08:18:46 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Apr 2015 06:18:46 +0000 Subject: [issue23985] Crash when deleting slices from duplicated bytearray In-Reply-To: <1429252668.91.0.45841644858.issue23985@psf.upfronthosting.co.za> Message-ID: <1429337925.99.0.149058469178.issue23985@psf.upfronthosting.co.za> Martin Panter added the comment: This bug might have been caused by the changes for Issue 19087, so I left a note there. It looks like that issue added the ob_start field to bytearray() objects, so that deleting from the start does not require memory copying. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 08:52:36 2015 From: report at bugs.python.org (Masayuki Yamamoto) Date: Sat, 18 Apr 2015 06:52:36 +0000 Subject: [issue14438] _cursesmodule build fails on cygwin In-Reply-To: <1333018032.15.0.799270204557.issue14438@psf.upfronthosting.co.za> Message-ID: <1429339956.64.0.169184111012.issue14438@psf.upfronthosting.co.za> Changes by Masayuki Yamamoto : ---------- nosy: +masamoto _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 09:01:22 2015 From: report at bugs.python.org (Masayuki Yamamoto) Date: Sat, 18 Apr 2015 07:01:22 +0000 Subject: [issue13756] Python3.2.2 make fail on cygwin In-Reply-To: <1326199459.04.0.575648132034.issue13756@psf.upfronthosting.co.za> Message-ID: <1429340482.6.0.537678770549.issue13756@psf.upfronthosting.co.za> Changes by Masayuki Yamamoto : ---------- nosy: +masamoto _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 09:35:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 18 Apr 2015 07:35:23 +0000 Subject: [issue23991] ZipFile sanity checks In-Reply-To: <1429332247.71.0.71910598875.issue23991@psf.upfronthosting.co.za> Message-ID: <1429342523.34.0.542775732885.issue23991@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +alanmcintyre, serhiy.storchaka, twouters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 10:22:44 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Apr 2015 08:22:44 +0000 Subject: [issue19051] Unify buffered readers In-Reply-To: <1379600529.46.0.258828532264.issue19051@psf.upfronthosting.co.za> Message-ID: <1429345364.6.0.119689543221.issue19051@psf.upfronthosting.co.za> Martin Panter added the comment: The LZMA, gzip and bzip modules now all use BufferedReader, so Serhiy?s patch is no longer relevant for them. Serhiy?s patch also changed the zipfile module, which may be still relevant. On the other hand, perhaps it would be more ideal to use BufferedReader for the zipfile module as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 11:00:21 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Sat, 18 Apr 2015 09:00:21 +0000 Subject: [issue23992] multiprocessing: MapResult shouldn't fail fast upon exception Message-ID: <1429347621.56.0.157795358647.issue23992@psf.upfronthosting.co.za> New submission from Charles-Fran?ois Natali: hanger.py """ from time import sleep def hang(i): sleep(i) raise ValueError("x" * 1024**2) """ The following code will deadlock on pool.close(): """ from multiprocessing import Pool from time import sleep from hanger import hang with Pool() as pool: try: pool.map(hang, [0,1]) finally: sleep(0.5) pool.close() pool.join() """ The problem is that when one of the tasks comprising a map result fails with an exception, the corresponding MapResult is removed from the result cache: def _set(self, i, success_result): success, result = success_result if success: [snip] else: self._success = False self._value = result if self._error_callback: self._error_callback(self._value) <=== del self._cache[self._job] self._event.set() ===> Which means that when the pool is closed, the result handler thread terminates right away, because it doesn't see any task left to wait for. Which means that it doesn't drain the result queue, and if some worker process is trying to write a large result to it (hence the large valuerrror to fill the socket/pipe buffer), it will hang, and the pool won't shut down (unless you call terminate()). Although I can see the advantage of fail-fast behavior, I don't think it's correct because it breaks the invariant where results won't be deleted from the cache until they're actually done. Also, the current fail-fast behavior breaks the semantics that the call only returns when it has completed. Returning while some jobs part of the map are still running is potentially very bad, e.g. if the user call retries the same call, assuming that all the jobs are done. Retrying jobs that are idempotent but not parallel execution-safe would break with the current code. The fix is trivial, use the same logic as in case of success to only signal failure when all jobs are done. I'll provide a patch if it seems sensible :-) ---------- components: Library (Lib) messages: 241404 nosy: neologix, pitrou priority: normal severity: normal status: open title: multiprocessing: MapResult shouldn't fail fast upon exception type: behavior versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 11:25:51 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 18 Apr 2015 09:25:51 +0000 Subject: [issue23993] Use surrogateescape error handler by default in open() if the locale is C Message-ID: <1429349151.1.0.641370404.issue23993@psf.upfronthosting.co.za> New submission from STINNER Victor: As a following of the issue #19977, I propose to use also the surrogateescape error handler in open() by default if the locale is C. Attached issue adds a new sys.getdefaulterrorhandler() function and use it in io.TextIOWrapper (and _pyio.TextIOWrapper). We may use sys.getdefaulterrorhandler() in more places. I don't think that it would be correct to use in for str.encode() or bytes.decode(). ---------- components: Unicode files: default_error_handler.patch keywords: patch messages: 241405 nosy: ezio.melotti, haypo, ncoghlan priority: normal severity: normal status: open title: Use surrogateescape error handler by default in open() if the locale is C versions: Python 3.5 Added file: http://bugs.python.org/file39100/default_error_handler.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 11:26:16 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 18 Apr 2015 09:26:16 +0000 Subject: [issue23993] Use surrogateescape error handler by default in open() if the locale is C In-Reply-To: <1429349151.1.0.641370404.issue23993@psf.upfronthosting.co.za> Message-ID: <1429349176.57.0.652313915359.issue23993@psf.upfronthosting.co.za> STINNER Victor added the comment: The patch is a work-in-progress, I didn't have time to run unit tests, and the documentation is not completed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 12:30:12 2015 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Sat, 18 Apr 2015 10:30:12 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429353012.55.0.724622098611.issue23990@psf.upfronthosting.co.za> Ionel Cristian M?rie? added the comment: > This is exactly analogous to what you are seeing with __call__ and callable(). Your example is incorrect, __next__ is what makes an object iterable but not what makes an object have an iterator (what __iter__ does). This correctly characterises the issue: >>> class NonIter: ... pass ... >>> iter(NonIter()) Traceback (most recent call last): File "", line 1, in TypeError: 'NonIter' object is not iterable >>> >>> class DynamicNonIter: ... has_iter = False ... ... @property ... def __iter__(self): ... if self.has_iter: ... from functools import partial ... return partial(iter, [1, 2, 3]) ... else: ... raise AttributeError("Not really ...") ... >>> dni = DynamicNonIter() >>> iter(dni) Traceback (most recent call last): File "", line 1, in TypeError: 'DynamicNonIter' object is not iterable >>> dni.has_iter = True >>> iter(dni) Now, if this is possible for `iter`, why shouldn't it be possible for `callable`? I'm not opposed to writing a PEP but the issue with `callable` is the only one I'm aware of, and this seems too small in scope anyway. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 12:43:54 2015 From: report at bugs.python.org (Carol Willing) Date: Sat, 18 Apr 2015 10:43:54 +0000 Subject: [issue16574] clarify policy on updates to final peps In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za> Message-ID: <1429353834.08.0.154294193733.issue16574@psf.upfronthosting.co.za> Carol Willing added the comment: This patch should close this languishing devguide issue. This patch adds wording suggested by Terry Reedy re: pep documentation reference to section 7.4.5 Inline markup (https://docs.python.org/devguide/documenting.html#id3). The devguide covers the pep process and PEP 1 in section 20.1.2 (https://docs.python.org/devguide/langchanges.html?highlight=pep#pep-process). ---------- keywords: +patch nosy: +willingc stage: -> patch review Added file: http://bugs.python.org/file39101/iss16574.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 13:01:23 2015 From: report at bugs.python.org (Carol Willing) Date: Sat, 18 Apr 2015 11:01:23 +0000 Subject: [issue17475] Better doc on using python-gdb.py In-Reply-To: <1363654728.46.0.181604306018.issue17475@psf.upfronthosting.co.za> Message-ID: <1429354883.48.0.902494957933.issue17475@psf.upfronthosting.co.za> Carol Willing added the comment: The current devguide on gdb (https://docs.python.org/devguide/gdb.html?highlight=gdb) satisfies this issue. I am marking this languishing issue as a duplicate and closing it. ---------- nosy: +willingc resolution: -> duplicate stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 14:02:26 2015 From: report at bugs.python.org (levkivskyi) Date: Sat, 18 Apr 2015 12:02:26 +0000 Subject: [issue10544] yield expression inside generator expression does nothing In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za> Message-ID: <1429358546.57.0.404107250417.issue10544@psf.upfronthosting.co.za> levkivskyi added the comment: I would like to add that since the introduction of asyncio module that heavily uses "yield from" syntax, binding of yield inside comprehensions/generator expressions could lead to unexpected results/confusing behavior. See for example this question on SO: http://stackoverflow.com/questions/29334054/why-am-i-getting-different-results-when-using-a-list-comprehension-with-coroutin ---------- nosy: +levkivskyi _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 14:02:33 2015 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 18 Apr 2015 12:02:33 +0000 Subject: [issue5784] raw deflate format and zlib module In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za> Message-ID: <1429358553.29.0.224214712257.issue5784@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Here's a short patch that expands the discussion of wbits, and duplicates it under both the compressobj() and decompress() methods. Should I avoid the duplication and just have a reference? ---------- nosy: +akuchling Added file: http://bugs.python.org/file39102/patch-5784.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 14:06:50 2015 From: report at bugs.python.org (Daniel) Date: Sat, 18 Apr 2015 12:06:50 +0000 Subject: [issue17703] Trashcan mechanism segfault during interpreter finalization in Python 2.7.4 In-Reply-To: <1365774192.26.0.770170442284.issue17703@psf.upfronthosting.co.za> Message-ID: <1429358810.98.0.614226374782.issue17703@psf.upfronthosting.co.za> Daniel added the comment: Guillaume already mentioned this, its still causing a Fatal Error. To fix this PyThreadState_GET() in Py_TRASHCAN_SAFE_BEGIN must be replaced with _PyThreadState_Current #define Py_TRASHCAN_SAFE_BEGIN(op) \ do { \ PyThreadState *_tstate = _PyThreadState_Current; \ ---------- nosy: +m_python _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 14:16:17 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 18 Apr 2015 12:16:17 +0000 Subject: [issue23536] Add explicit information on config file format not supporting filters In-Reply-To: <1425041368.98.0.00469006830804.issue23536@psf.upfronthosting.co.za> Message-ID: <20150418121532.27912.50564@psf.io> Roundup Robot added the comment: New changeset df28044b7e14 by Vinay Sajip in branch '2.7': Issue #23536: Clarified scope of fileConfig()'s API. https://hg.python.org/cpython/rev/df28044b7e14 New changeset 968c086bf6cc by Vinay Sajip in branch '3.4': Issue #23536: Clarified scope of fileConfig()'s API. https://hg.python.org/cpython/rev/968c086bf6cc New changeset 439517000aa2 by Vinay Sajip in branch 'default': Closes #23536: Clarified scope of fileConfig()'s API. https://hg.python.org/cpython/rev/439517000aa2 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 14:38:14 2015 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 18 Apr 2015 12:38:14 +0000 Subject: [issue5784] raw deflate format and zlib module In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za> Message-ID: <1429360694.62.0.214350096076.issue5784@psf.upfronthosting.co.za> Changes by A.M. Kuchling : ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 14:42:47 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Apr 2015 12:42:47 +0000 Subject: [issue5784] raw deflate format and zlib module In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za> Message-ID: <1429360967.33.0.143186737624.issue5784@psf.upfronthosting.co.za> Martin Panter added the comment: Looks good in general (apart from one grammar comment). It might be best to only include one copy, and reference the others. There are actually three places ?wbits? is allowed that I can see: * compressobj() * decompress() * decompressobj() Maybe just pointing from decompress() and decompressobj() back to the compressobj() description would be good enough. Unless if you know if wbits=0 is also accepted or not for decompression. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 14:45:50 2015 From: report at bugs.python.org (Martin Panter) Date: Sat, 18 Apr 2015 12:45:50 +0000 Subject: [issue20962] Rather modest chunk size in gzip.GzipFile In-Reply-To: <1395082726.87.0.730756156096.issue20962@psf.upfronthosting.co.za> Message-ID: <1429361150.04.0.8149135926.issue20962@psf.upfronthosting.co.za> Martin Panter added the comment: The gzip (as well as LZMA and bzip) modules should now use buffer and chunk sizes of 8 KiB (= io.DEFAULT_BUFFER_SIZE) for most read() and seek() type operations. I have a patch that adds a buffer_size parameter to the three compression modules if anyone is interested. It may need a bit work, e.g. adding the parameter to open(), mimicking the built-in open() function when buffer_size=0, etc. I did a quick test of seeking 100 MB into a gzip file, using the original Python 3.4.3 module, the current code that uses 8 KiB chunk sizes, and then my patched code with various chunk sizes. It looks like 8 KiB is significantly better than the previous code. My tests are peaking at about 64 KiB, but I guess that depends on the computer (cache etc). Anyway, 8 KiB seems like a good compromise without hogging all the fast memory cache or whatever, so I suggest we close this bug. Command line for timing looked like: python -m timeit -s 'import gzip' \ 'gzip.GzipFile("100M.gz", buffer_size=8192).seek(int(100e6))' Python 3.4.3: 10 loops, best of 3: 2.36 sec per loop Currently (8 KiB chunking): 10 loops, best of 3: 693 msec per loop buffer_size=1024: 10 loops, best of 3: 2.46 sec per loop buffer_size=8192: 10 loops, best of 3: 677 msec per loop buffer_size=16 * 1024: 10 loops, best of 3: 502 msec per loop buffer_size=int(60e3): 10 loops, best of 3: 400 msec per loop buffer_size=64 * 1024: 10 loops, best of 3: 398 msec per loop buffer_size=int(80e3): 10 loops, best of 3: 406 msec per loop buffer_size=16 * 8192: 10 loops, best of 3: 469 msec per loop ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 16:30:46 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 18 Apr 2015 14:30:46 +0000 Subject: [issue23993] Use surrogateescape error handler by default in open() if the locale is C In-Reply-To: <1429349151.1.0.641370404.issue23993@psf.upfronthosting.co.za> Message-ID: <1429367446.96.0.849309267231.issue23993@psf.upfronthosting.co.za> R. David Murray added the comment: I am -1 on this. (Or may be more). What's the rationale? I could see using utf-8 by default if the locale is C, but I don't think we want to encourage going back to a world where people don't pay attention to the encoding of their data. A more productive approach to solving the problem that I think you are trying to solve here would be to work on including chardet in the standard library, something that was brought up, and seemed to receive positive reception (or at least not negative), during the Requests segment of the PyCon language summit. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 16:51:10 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 18 Apr 2015 14:51:10 +0000 Subject: [issue23993] Use surrogateescape error handler by default in open() if the locale is C In-Reply-To: <1429349151.1.0.641370404.issue23993@psf.upfronthosting.co.za> Message-ID: <1429368670.55.0.1864778911.issue23993@psf.upfronthosting.co.za> STINNER Victor added the comment: Updated and better patch: version 2. - revert changes on fileutils.c: it's not useful to check for check_force_ascii(), because this function is more strict than checking of the LC_CTYPE is "C" - fix _pyio.py: add sys import - complete the documentation - tests pass ---------- Added file: http://bugs.python.org/file39103/default_error_handler-2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 17:00:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 18 Apr 2015 15:00:04 +0000 Subject: [issue23993] Use surrogateescape error handler by default in open() if the locale is C In-Reply-To: <1429349151.1.0.641370404.issue23993@psf.upfronthosting.co.za> Message-ID: <1429369204.24.0.590633393838.issue23993@psf.upfronthosting.co.za> STINNER Victor added the comment: > I am -1 on this. (Or may be more). What's the rationale? See the issue #19977. In many cases you get the C locale by mistake. For example, by setting the LANG environment variable to an empty string to run a program in english (whereas LC_MESSAGES is the appropriate variable). For deamons, in many cases you get the C locale and it's hard to configure all systems to run the daemon with the user locale. I read that systemd runs daemons with the user locale, but I'm not sure. The idea is to reduce the pain caused by this locale. When porting an application from Python 2 to Python 3, it's annoying to start to get unicode errors everywhere. This issue starts to make Python 3 more convinient. > I could see using utf-8 by default if the locale is C, This has been proposed many times, but I'm opposed to that. Python must be interoperable with other programs, and other programs use the locale encoding. For example, you get the ASCII locale encoding when the LC_CTYPE is the POSIX locale ("C"). If Python writes UTF-8, other applications will be unable to decode UTF-8 data. Maybe I'm wrong and you should continue to investigate this option. This issue is very specific to "OS" data: environment variables, filenames, command line arguments, standard streams (stdin, stdout, stderr). You may do other choices for other kind of data unrelated to the locale encoding. For example, JSON must use UTF-8, it's well defined. XML announces its encoding. etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 17:01:21 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 18 Apr 2015 15:01:21 +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: <1429369281.88.0.252904661445.issue23993@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- title: Use surrogateescape error handler by default in open() if the locale is C -> Use surrogateescape error handler by default in open() if the LC_CTYPE locale is C at startup _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 17:03:07 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 18 Apr 2015 15:03:07 +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: <1429369387.79.0.670578969892.issue23993@psf.upfronthosting.co.za> STINNER Victor added the comment: For a more concrete use case, see the "makefile problem" in Mercurial wiki page: http://mercurial.selenic.com/wiki/EncodingStrategy#The_.22makefile_problem.22 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 17:19:26 2015 From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=) Date: Sat, 18 Apr 2015 15:19:26 +0000 Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za> Message-ID: <1429370366.65.0.878532152608.issue23725@psf.upfronthosting.co.za> Zbyszek J?drzejewski-Szmek added the comment: Replying to review here... I get 500 server error in the patch review reply dialogue :( On 2015/04/15 02:40:14, r.david.murray wrote: > http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst > File Doc/library/tempfile.rst (left): > > http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#oldcode55 > Doc/library/tempfile.rst:55: :keyword:`with` statement, just like a normal file. > Why did you remove this statement? It is redundant. The fact that this can be used as CM is already mentioned in the introduction and in the description of TemporaryFile. > http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst > File Doc/library/tempfile.rst (right): > > http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode25 > Doc/library/tempfile.rst:25: The need to use the insecure :func:`mktemp` > function is eliminated. > How about we get even more radical. Let's eliminate the mention of mktemp from > the documentation, except for a "Deprecated Functions" section at the end, where > we explain that it is deprecated because it is insecure and anything you could > do with it you can do with the un-deprecated functions. Agreed. I'll submit a new version which removes all the historical notes and adds a "Deprecated" section at the end for tempdir and mktemp. > http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode27 > Doc/library/tempfile.rst:27: instead a string of six random characters is used. > Let's likewise eliminate the mention of the process id, and just leave the > explanation that six random characters are used. OK. > http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode31 > Doc/library/tempfile.rst:31: directories. It is no longer necessary to use the > global *tempdir* variable. > The global tempdir variable can likewise be moved to the deprecated section and > removed from mention here. OK. > http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode42 > Doc/library/tempfile.rst:42: collected). Under Unix, the directory entry for > the file is either not created at all or removed > "or is removed" OK. > http://bugs.python.org/review/23725/diff/14592/Doc/library/tempfile.rst#newcode247 > Doc/library/tempfile.rst:247: > There should be another blank line here. v5: - relegate `tempdir` and `mktemp` descriptions to 'Deprecated functions and variables' section at the end. This requires moving some descriptions around. - add missing "is" pointed out in review - add missing 's' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 17:23:05 2015 From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=) Date: Sat, 18 Apr 2015 15:23:05 +0000 Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za> Message-ID: <1429370585.24.0.520101693828.issue23725@psf.upfronthosting.co.za> Changes by Zbyszek J?drzejewski-Szmek : Added file: http://bugs.python.org/file39104/tempfile_docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 18:19:32 2015 From: report at bugs.python.org (A.M. Kuchling) Date: Sat, 18 Apr 2015 16:19:32 +0000 Subject: [issue5784] raw deflate format and zlib module In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za> Message-ID: <1429373972.86.0.17122335401.issue5784@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Thanks! Here's an updated version with some more rewriting -- the list is now in only one place and is linked-to from the decompression documentation. ---------- Added file: http://bugs.python.org/file39105/patch-5784.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 18:19:44 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 18 Apr 2015 16:19:44 +0000 Subject: [issue23955] Add python.ini file for embedded/applocal installs In-Reply-To: <1429038990.96.0.956334607163.issue23955@psf.upfronthosting.co.za> Message-ID: <1429373984.02.0.364805283976.issue23955@psf.upfronthosting.co.za> Steve Dower added the comment: I could reuse the venv config file but it would need a new property to forcibly use the 'home' value regardless of whether '$home\Lib\os.py' exists (in case the stdlib is zipped) and to make it relative to the file's path rather than the user's current directory. How about adding an 'applocal=True' property to pyvenv.cfg that basically implies -I, PYTHONHOME=os.dirname(pyvenv_cfg), and skips the registry lookup on Windows completely (which there's currently no way to achieve)? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 18:23:18 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 18 Apr 2015 16:23:18 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429374198.17.0.775176925984.issue23990@psf.upfronthosting.co.za> Ethan Furman added the comment: Your example shows /having/ an iterator, while mine is /being/ an iterator. A simple iterator: # iterator protocol class uc_iter(): def __init__(self, text): self.text = text self.index = 0 def __iter__(self): return self def __next__(self): try: result = self.text[self.index].upper() except IndexError: raise StopIteration self.index += 1 return result ucii = uc_iter('abc') I believe your over-arching goal is a proxy class? class GenericProxy: def __init__(self, proxied): self.proxied = proxied # in case proxied is an __iter__ iterator @property def __iter__(self): if not hasattr(self.proxied, '__iter__'): raise AttributeError else: return self @property def __next__(self): if not hasattr(self.proxied, '__next__'): raise AttributeError else: return next(self.proxied) and then two proxies to test -- a non-iterable and an iterable: gp_ni = GenericProxy(object()) gp_ucii = GenericProxy(ucii) and a quick harness: try: for _ in iter(gp_ni): print(_) except Exception as e: print(e) try: for _ in iter(gp_ucii): print(_) except Exception as e: print(e) Note: the presence/absence of iter() makes no difference to the results below. The non-iterable gives the correct error: 'GenericProxy' object is not iterable But the iterable gives: 'GenericProxy' object is not callable That error message is a result of the iter machinery grabbing the __next__ attribute and trying to call it, but property attributes are not callable. In other words, iter() does not "honor the descriptor protocol". So now we have two: callable() and iter(). How many more are there? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 18:27:57 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 18 Apr 2015 16:27:57 +0000 Subject: [issue23955] Add python.ini file for embedded/applocal installs In-Reply-To: <1429038990.96.0.956334607163.issue23955@psf.upfronthosting.co.za> Message-ID: <1429374477.23.0.636553232818.issue23955@psf.upfronthosting.co.za> Steve Dower added the comment: Arguably we should be making 'home' in pyvenv.cfg relative to the pyvenv.cfg file's directory anyway... AFAIK it's always generated as an absolute path, but I see no good reason to prevent people from manually configuring a relative path here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 18:44:54 2015 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Sat, 18 Apr 2015 16:44:54 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429374198.17.0.775176925984.issue23990@psf.upfronthosting.co.za> Message-ID: Ionel Cristian M?rie? added the comment: On Sat, Apr 18, 2015 at 7:23 PM, Ethan Furman wrote: > > class GenericProxy: > def __init__(self, proxied): > self.proxied = proxied > # in case proxied is an __iter__ iterator > @property > def __iter__(self): > if not hasattr(self.proxied, '__iter__'): > raise AttributeError > else: > return self > @property > def __next__(self): > if not hasattr(self.proxied, '__next__'): > raise AttributeError > else: > return next(self.proxied) ?Unfortunately y?our implementation is incorrect as you forgot to that the property needs to return a function. This is a correct implementation that works as expected (in the sense that *iter does in fact honor the descriptor protocol)*: class GenericProxy: > def __init__(self, proxied): > self.proxied = proxied > # in case proxied is an __iter__ iterator > @property > def __iter__(self): > if not hasattr(self.proxied, '__iter__'): > raise AttributeError > else: > return *lambda:* self > @property > def __next__(self): > if not hasattr(self.proxied, '__next__'): > raise AttributeError > else: > return *lambda: *next(self.proxied) > ?The iter machinery doesn't "grab values and call them", you've misinterpreted the error.? Thanks, -- Ionel Cristian M?rie?, http://blog.ionelmc.ro ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 18:47:14 2015 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Sat, 18 Apr 2015 16:47:14 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429375634.23.0.379524579413.issue23990@psf.upfronthosting.co.za> Ionel Cristian M?rie? added the comment: Turns out I've replied through email, and code got mangled. This is the correct version: class GenericProxy: def __init__(self, proxied): self.proxied = proxied @property def __iter__(self): if not hasattr(self.proxied, '__iter__'): raise AttributeError else: return lambda: self @property def __next__(self): if not hasattr(self.proxied, '__next__'): raise AttributeError else: return lambda: next(self.proxied) Note the lambdas. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 18:59:39 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Sat, 18 Apr 2015 16:59:39 +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: <1429376379.57.0.267902753767.issue23496@psf.upfronthosting.co.za> Ryan Gonzalez added the comment: Ok...try going to Python/pylifecycle.c and changing lines 220-230 from: #elif defined(HAVE_LANGINFO_H) && defined(CODESET) char* codeset = nl_langinfo(CODESET); if (!codeset || codeset[0] == '\0') { PyErr_SetString(PyExc_ValueError, "CODESET is not set or empty"); return NULL; } return get_codec_name(codeset); #elif defined(__ANDROID__) char* m = malloc(6); strcpy(m, "ascii"); return m; to: #elif defined(__ANDROID__) char* m = malloc(6); strcpy(m, "ascii"); return m; #elif defined(HAVE_LANGINFO_H) && defined(CODESET) char* codeset = nl_langinfo(CODESET); if (!codeset || codeset[0] == '\0') { PyErr_SetString(PyExc_ValueError, "CODESET is not set or empty"); return NULL; } return get_codec_name(codeset); I just swapped the `elif`'s around. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 19:00:33 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 18 Apr 2015 17:00:33 +0000 Subject: [issue23984] Documentation error: Descriptors In-Reply-To: <1429245728.01.0.810263114275.issue23984@psf.upfronthosting.co.za> Message-ID: <1429376433.43.0.0193518069635.issue23984@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: docs at python -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 19:08:08 2015 From: report at bugs.python.org (Al Sweigart) Date: Sat, 18 Apr 2015 17:08:08 +0000 Subject: [issue23961] IDLE autocomplete window does not automatically close when selection is made In-Reply-To: <1429060935.51.0.684469355013.issue23961@psf.upfronthosting.co.za> Message-ID: <1429376888.21.0.518576523087.issue23961@psf.upfronthosting.co.za> Al Sweigart added the comment: I should clarify: I'm referring to the "Show Completion" feature. The repro steps are (on Windows 7 64-bit, Python 3.5) 1. Type "pri" 2. Press Ctrl+Space or click Edit > Show Completions. The autocomplete window appears. 3. Press Tab. The text updates from "pri" to "print" 4. However, the autocomplete window is still there. 5. Pressing space or ( will then cause the autocomplete window to disappear. This is distinct from issue 15786, but close enough that I'll close this bug and add this comment to it. Thanks for the input! ---------- resolution: -> duplicate _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 19:09:16 2015 From: report at bugs.python.org (Al Sweigart) Date: Sat, 18 Apr 2015 17:09:16 +0000 Subject: [issue15786] IDLE code completion window can hang or misbehave with mouse In-Reply-To: <1346027701.33.0.908436854594.issue15786@psf.upfronthosting.co.za> Message-ID: <1429376956.64.0.220388467411.issue15786@psf.upfronthosting.co.za> Al Sweigart added the comment: Additionally, pressing tab after the autocomplete window has appeared should not just update the text but also close the autocomplete window. The repro steps are (on Windows 7 64-bit, Python 3.5): 1. Type "pri" 2. Press Ctrl+Space or click Edit > Show Completions. The autocomplete window appears. 3. Press Tab. The text updates from "pri" to "print" 4. However, the autocomplete window is still there. 5. Pressing space or ( will then cause the autocomplete window to disappear. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 19:16:42 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 18 Apr 2015 17:16:42 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429377402.41.0.197354938595.issue23990@psf.upfronthosting.co.za> Ethan Furman added the comment: I am happy to be proven wrong. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 19:35:10 2015 From: report at bugs.python.org (Christian Heimes) Date: Sat, 18 Apr 2015 17:35:10 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429378510.24.0.470406323809.issue23990@psf.upfronthosting.co.za> Christian Heimes added the comment: All major Python implementation have a mutual agreement that callable() just checks for a __call__ member on the type. You also haven't shown that this behavior violates the documentation and language spec. The check for existence of __call__ on the type is well in the range of expected behavior. I as well as other core devs had the same gut feeling. Finally your suggestion makes the implementation of callable() more complex and much, much slower. Right now and for more than a decade it is a simple, fast and straight forward code path for new style classes. It just requires two pointer derefs and one comparison to NULL. I'm still -1 on the change. If you want to go forth with your request then you must write a PEP and convince all implementors of Python implementations to change the current way callable() and other protocols like iter work. $ python2.7 Python 2.7.8 (default, Nov 10 2014, 08:19:18) [GCC 4.9.2 20141101 (Red Hat 4.9.2-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class A(object): ... @property ... def __call__(self): ... raise AttributeError ... >>> a = A() >>> print(callable(a)) True >>> a() Traceback (most recent call last): File "", line 1, in File "", line 4, in __call__ AttributeError $ jython Jython 2.7b3+ (, Nov 3 2014, 11:02:14) [OpenJDK 64-Bit Server VM (Oracle Corporation)] on java1.8.0_40 Type "help", "copyright", "credits" or "license" for more information. >>> class A(object): ... @property ... def __call__(self): ... raise AttributeError ... >>> a = A() >>> print(callable(a)) True >>> a() Traceback (most recent call last): File "", line 1, in File "", line 4, in __call__ AttributeError $ pypy Python 2.7.8 (a980ebb26592ed26706cd33a4e05eb45b5d3ea09, Sep 24 2014, 07:41:52) [PyPy 2.4.0 with GCC 4.9.1 20140912 (Red Hat 4.9.1-9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>>> class A(object): .... @property .... def __call__(self): .... raise AttributeError .... >>>> a = A() >>>> print(callable(a)) True >>>> a() Traceback (most recent call last): File "", line 1, in File "", line 4, in __call__ AttributeError ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 19:39:15 2015 From: report at bugs.python.org (Cyd Haselton) Date: Sat, 18 Apr 2015 17:39:15 +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: <1429378755.16.0.655008992285.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Do you have the time/means to create a quick patch for that? I ask because even a simple flip like that becomes a major pain when working with nano on a tablet. If not, I'll start on it. Just thought I"d ask ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 19:43:12 2015 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Sat, 18 Apr 2015 17:43:12 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429378510.24.0.470406323809.issue23990@psf.upfronthosting.co.za> Message-ID: Ionel Cristian M?rie? added the comment: On Sat, Apr 18, 2015 at 8:35 PM, Christian Heimes wrote: > You also haven't shown that this behavior violates the documentation and > language spec. ?How can I show it violates the "spec" when there's not such thing? :-) AFAIK, `callable` is not specified in any PEP. Please give some references when you make such statements. ?[...] write a PEP and convince all implementors of Python implementations > to change the current way callable() and other protocols like iter work. `iter` works fine, as outlined above? Am I missing something? What other protocols do you have in mind, wrt honoring descriptors? Thanks, -- Ionel Cristian M?rie?, http://blog.ionelmc.ro ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 19:48:03 2015 From: report at bugs.python.org (Mert Bora Alper) Date: Sat, 18 Apr 2015 17:48:03 +0000 Subject: [issue23994] argparse fails to detect program name when there is a slash at the end of the program's path Message-ID: <1429379283.39.0.0511547854084.issue23994@psf.upfronthosting.co.za> New submission from Mert Bora Alper: Sorry if the title is not descriptive enough. When I try to execute a program from a directory which contains an `__main__.py` file, argparse fails to detect programs name. For example: $ ls foo __main__.py $ python3 foo usage: foo [-h] [-c COUNT] length foo: error: the following arguments are required: length $ python3 foo/ usage: [-h] [-c COUNT] length : error: the following arguments are required: length ---- >>> argparse.__version__ '1.1' I followed same steps using Python 2.7.6 and got same result. It will probably be same on other versions too. Same result can also be obtained when using zip files instead of directories. I don't know if this is a bug since I don't know if I do something wrong or is this a design decision or not. Thank you, Bora ---------- components: Library (Lib) files: __main__.py messages: 241434 nosy: boramalper priority: normal severity: normal status: open title: argparse fails to detect program name when there is a slash at the end of the program's path type: behavior versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file39106/__main__.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 20:00:34 2015 From: report at bugs.python.org (Christian Heimes) Date: Sat, 18 Apr 2015 18:00:34 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: Message-ID: <55329BBF.5010503@cheimes.de> Christian Heimes added the comment: On 2015-04-18 19:43, Ionel Cristian M?rie? wrote: > > Ionel Cristian M?rie? added the comment: > > On Sat, Apr 18, 2015 at 8:35 PM, Christian Heimes > wrote: > >> You also haven't shown that this behavior violates the documentation and >> language spec. > > ?How can I show it violates the "spec" when there's not such thing? :-) > AFAIK, `callable` is not specified in any PEP. Please give some references > when you make such statements. The language specs is made up from two things: 1) the CPython reference implemention 2) the documentation of the CPython reference implementation 3) accepted and implemented PEPs If 3) doesn't exist and 2) doesn't contain any point that contradicts 1), then 1) and 2) agree on an implementation and therefore it is informally specified. The fact that PyPy and Jython show the same behavior, adds additional weight to 1), too. callable() has been implemented like that since the introduction of new style classes, too. $ hg checkout v2.2 $ grep -A20 ^PyCallable_Check Objects/object.c PyCallable_Check(PyObject *x) { if (x == NULL) return 0; if (PyInstance_Check(x)) { PyObject *call = PyObject_GetAttrString(x, "__call__"); if (call == NULL) { PyErr_Clear(); return 0; } /* Could test recursively but don't, for fear of endless recursion if some joker sets self.__call__ = self */ Py_DECREF(call); return 1; } else { return x->ob_type->tp_call != NULL; } } You really have to make a *very* good case with a PEP in order to get everybody to switch to a different behavior! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 20:00:54 2015 From: report at bugs.python.org (Al Sweigart) Date: Sat, 18 Apr 2015 18:00:54 +0000 Subject: [issue23964] Update README documentation for IDLE tests. In-Reply-To: <1429104753.6.0.763987492268.issue23964@psf.upfronthosting.co.za> Message-ID: <1429380054.45.0.851926779626.issue23964@psf.upfronthosting.co.za> Al Sweigart added the comment: I'll add a note about running the human-mediated tests to section 0. Running "python -m test.test_idle" for 64-bit 3.4.3 on Windows 7 works fine for me ("Ran 142 tests in 0.605s OK") I'll take out the indented code. You make a good point about copy/paste. I've added section 4 on human-mediated tests. I'd like to take a crack at improving the documentation a bit in htest.py before figuring out what to add to section 4. This can be addressed in a later patch. ---------- Added file: http://bugs.python.org/file39107/idle_test_readme.2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 20:08:17 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Sat, 18 Apr 2015 18:08:17 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1429378755.16.0.655008992285.issue23496@psf.upfronthosting.co.za> Message-ID: Ryan Gonzalez added the comment: Here: diff -r 38f5b3beeb2a Python/pylifecycle.c --- a/Python/pylifecycle.c Thu Mar 19 15:16:03 2015 -0500 +++ b/Python/pylifecycle.c Sat Apr 18 13:07:36 2015 -0500 @@ -217,6 +217,10 @@ char codepage[100]; PyOS_snprintf(codepage, sizeof(codepage), "cp%d", GetACP()); return get_codec_name(codepage); +#elif defined(__ANDROID__) + char* m = malloc(6); + strcpy(m, "ascii"); + return m; #elif defined(HAVE_LANGINFO_H) && defined(CODESET) char* codeset = nl_langinfo(CODESET); if (!codeset || codeset[0] == '\0') { @@ -224,10 +228,6 @@ return NULL; } return get_codec_name(codeset); -#elif defined(__ANDROID__) - char* m = malloc(6); - strcpy(m, "ascii"); - return m; #else PyErr_SetNone(PyExc_NotImplementedError); return NULL; On Sat, Apr 18, 2015 at 12:39 PM, Cyd Haselton wrote: > > Cyd Haselton added the comment: > > Do you have the time/means to create a quick patch for that? > > I ask because even a simple flip like that becomes a major pain when > working with nano on a tablet. > > If not, I'll start on it. Just thought I"d ask > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 20:45:16 2015 From: report at bugs.python.org (petrikas) Date: Sat, 18 Apr 2015 18:45:16 +0000 Subject: [issue23995] msvcrt could not be imported Message-ID: <1429382716.1.0.015048526051.issue23995@psf.upfronthosting.co.za> New submission from petrikas: Python cannot access msvcrt's putwch() when using manage.py syncdb To reproduce: 1. Call manage.py syncdb and try to create a new superuser 2. It crashes after inputting email (or before asking for the password) Reproducible with 3.5a3, seems to be a regression from 3.4.3. Downgrading fixed the issue ---------- components: Library (Lib) messages: 241438 nosy: petrikas priority: normal severity: normal status: open title: msvcrt could not be imported type: crash versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 20:46:17 2015 From: report at bugs.python.org (petrikas) Date: Sat, 18 Apr 2015 18:46:17 +0000 Subject: [issue23995] msvcrt could not be imported In-Reply-To: <1429382716.1.0.015048526051.issue23995@psf.upfronthosting.co.za> Message-ID: <1429382777.17.0.236035400891.issue23995@psf.upfronthosting.co.za> petrikas added the comment: Edit: I am using a windows 8.1 system and django 1.8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 20:52:19 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 18 Apr 2015 18:52:19 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429383139.64.0.456173889038.issue23990@psf.upfronthosting.co.za> R. David Murray added the comment: I understand Ionel's point, and it is indeed 'callable' that is the outlier here. It only looks for the *existence* of the attribute, rather than actually retrieving it through the descriptor protocol (and therefore getting the AttributeError from the property). Protocols like iter, on the other hand, actually use the attribute, and therefore do access it via the descriptor protocol, and properties therefore act like one would naively expect them to. That doesn't mean we should definitely change callable, but it does mean the idea isn't obviously wrong. IMO it is indeed callable that has the surprising behavior here. (Note: I did not think that at first, but I do after reading the iter discussion. (NB: in general, __iter__ should *not* return self; that's a bug waiting to happen.)) But, callable is also...not exactly Pythonic at its core, as evidenced by Guido's desire to get rid of it. So the fact that it is in some sense buggy or at least surprising is perhaps something that we just live with because of that. IMO, code that depends on a __call__ property is a bit suspect anyway. Something should be callable or not, not conditionally callable. If a program wants things to be conditionally callable, the program can establish its own protocol for that. (The same applies to __iter__, but there's no reason to intentionally break the fact that it does work, since it just falls out of how the language works.) So I guess my feeling is...callable is buggy, but callable is a buggy API :) So I'm 0 on this issue (not even +0 or -0). ---------- nosy: +r.david.murray resolution: -> not a bug stage: test needed -> resolved status: open -> closed type: enhancement -> 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 Sat Apr 18 20:52:40 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 18 Apr 2015 18:52:40 +0000 Subject: [issue23994] argparse fails to detect program name when there is a slash at the end of the program's path In-Reply-To: <1429379283.39.0.0511547854084.issue23994@psf.upfronthosting.co.za> Message-ID: <1429383160.0.0.0706748120385.issue23994@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I think this was just overlooked when implementing argparse. Most code out there is likely to get the executable name using: os.path.basename(sys.argv[0]) Which is going to do exactly what you are seeing here when sys.argv[0] ends with a /. feel free to submit a patch. perhaps as simple as this? os.path.basename(sys.argv[0].rstrip(os.path.sep)) But I'd expect a bunch of other code out there to have the same problem. ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 20:59:37 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 18 Apr 2015 18:59:37 +0000 Subject: [issue23989] Add recommendation to use requests to the documentation, per summit In-Reply-To: <1429295622.31.0.515179904566.issue23989@psf.upfronthosting.co.za> Message-ID: <1429383577.11.0.178306858721.issue23989@psf.upfronthosting.co.za> Gregory P. Smith added the comment: nice and simple. that wording looks good to me. ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 21:01:09 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 18 Apr 2015 19:01:09 +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: <1429383669.39.0.223032340883.issue23993@psf.upfronthosting.co.za> R. David Murray added the comment: Hmm. Upon reflection I guess I can see the validity of "if you are using the C locale you or the OS are broken anyway, so we'll just pass the bytes through". I'm not entirely convinced this won't cause issues, but I suppose it might not cause any more issues that having things break due to the C locale does. It is, however, going to return us to the days when a program that works fine most of the time suddenly blows up in the face of non-ascii data, and that's my biggest concern. I'd certainly be fine with it if it wasn't the default (that is, programs who need this have to opt in to it). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 21:06:21 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 18 Apr 2015 19:06:21 +0000 Subject: [issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values In-Reply-To: <1429231899.59.0.405315540238.issue23982@psf.upfronthosting.co.za> Message-ID: <1429383981.46.0.92614263279.issue23982@psf.upfronthosting.co.za> Ned Deily added the comment: Current source releases of Python do not specify which version of Tk they should be run with; that is largely up to the distributors of Python (including python.org binary installers for Windows and OS X) and the conventions of the platform the instances are running on. There are versions of current Python 3.4.x and Python 2.7.x running on supported platforms (like OS X) with various flavors of Tk 8.6, 8.5, and even 8.4. So Python documentation has to be careful to avoid making assumptions about Tk version-specific features. FWIW, a link to Tk 8.6 differences is provided on the Tcl/Tk 8.6 release page (http://www.tcl.tk/software/tcltk/8.6.html) -> "Changes in Tcl/Tk 8.6" (http://wiki.tcl.tk/21276). ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 21:10:40 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 18 Apr 2015 19:10:40 +0000 Subject: [issue23971] dict(list) and dict.fromkeys() doesn't account for 2/3 fill ratio In-Reply-To: <1429140944.27.0.450320519696.issue23971@psf.upfronthosting.co.za> Message-ID: <1429384240.34.0.368455304058.issue23971@psf.upfronthosting.co.za> Gregory P. Smith added the comment: Won't we always consume the memory thanks to a memset(newtable, 0, ...) https://hg.python.org/cpython/file/df28044b7e14/Objects/dictobject.c#l654 ? (also, i'm not sure if Windows is allocates mapped pages on demand as posix systems tend to) ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 21:11:08 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 18 Apr 2015 19:11:08 +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: <1429384268.14.0.696172598371.issue23992@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +davin, sbt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 21:12:18 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 18 Apr 2015 19:12:18 +0000 Subject: [issue23971] dict(list) and dict.fromkeys() doesn't account for 2/3 fill ratio In-Reply-To: <1429140944.27.0.450320519696.issue23971@psf.upfronthosting.co.za> Message-ID: <1429384338.97.0.168700731351.issue23971@psf.upfronthosting.co.za> Gregory P. Smith added the comment: fwiw, as for 2.7 i personally don't think I would change its behavior around this at this point. make sure 3.5+ do something desirable. (my link to dictobject.c above is from 2.7) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 21:14:36 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 18 Apr 2015 19:14:36 +0000 Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za> Message-ID: <1429384476.54.0.232153405145.issue23725@psf.upfronthosting.co.za> R. David Murray added the comment: Made one minor suggestion in review comments (related to that deleted line). Otherwise this looks good to me, thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 21:16:31 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 18 Apr 2015 19:16:31 +0000 Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za> Message-ID: <1429384591.92.0.722792822333.issue23725@psf.upfronthosting.co.za> R. David Murray added the comment: Oh, because of the O_TMPDIR bits, this patch is only applicable to 3.5, so I'm removing 3.4 from versions. I don't think it is worth it to make a version that would apply to 3.4, since it is not the case that the 3.4 docs are *wrong*. ---------- versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 21:21:28 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 18 Apr 2015 19:21:28 +0000 Subject: [issue23995] msvcrt could not be imported In-Reply-To: <1429382716.1.0.015048526051.issue23995@psf.upfronthosting.co.za> Message-ID: <1429384888.72.0.49860487666.issue23995@psf.upfronthosting.co.za> R. David Murray added the comment: Can you reproduce this without involving Django? That would make it more likely that someone will have time to take a look at it. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 21:21:44 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 18 Apr 2015 19:21:44 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429384904.69.0.678642906704.issue23990@psf.upfronthosting.co.za> Ethan Furman added the comment: Perhaps callable() should be in the inspect module? ;) Speaking of which, how do all the is... functions there work with this descriptor implementation? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 21:24:05 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 18 Apr 2015 19:24:05 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429385045.05.0.410800517939.issue23990@psf.upfronthosting.co.za> R. David Murray added the comment: Oops, I accidentally changed the bug status due to not refreshing before I posted. ---------- resolution: not a bug -> stage: resolved -> status: closed -> open versions: +Python 3.5 -Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 21:33:28 2015 From: report at bugs.python.org (R. David Murray) Date: Sat, 18 Apr 2015 19:33:28 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429385608.73.0.791271816142.issue23990@psf.upfronthosting.co.za> R. David Murray added the comment: They use isinstance, except for a couple that also check co_flags, and the ones that check if the object is a descriptor. I haven't thought this through fully, but I think this means that in general the descriptor protocol has been invoked or not by the caller of inspect before inspect checks the object. There is no 'callable' type in python, so the closest analog in the inspect module to 'callable' are the functions that look for __get__ and __set__ methods on descriptors. If one of *those* is a descriptor, my head will start hurting :). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 21:36:18 2015 From: report at bugs.python.org (eryksun) Date: Sat, 18 Apr 2015 19:36:18 +0000 Subject: [issue23995] msvcrt could not be imported In-Reply-To: <1429382716.1.0.015048526051.issue23995@psf.upfronthosting.co.za> Message-ID: <1429385778.93.0.370355579743.issue23995@psf.upfronthosting.co.za> eryksun added the comment: The new CRT used by 3.5 has a separate header, corecrt_wconio.h, for declarations shared by conio.h and wchar.h. Thus the _WCONIO_DEFINED macro is no longer defined, and consequently PC/msvcrtmodule.c skips defining getwch, getwche, putwch, and ungetwch. I guess this check was added to support DOS-based Windows 9x. NT-based Windows would always support wide-character console I/O. ---------- components: +Windows nosy: +eryksun, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 21:45:13 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 18 Apr 2015 19:45:13 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions Message-ID: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> New submission from Stefan Behnel: The yield-from implementation calls _PyGen_FetchStopIterationValue() to get the exception value. If the StopIteration exception is not normalised, e.g. because it was set by PyErr_SetObject() in a C extension, then _PyGen_FetchStopIterationValue() will cast to (PyStopIterationObject*) whatever the exception value is and happily interpret an arbitrary memory position as PyObject*. I attached a possible patch for the function. Another place to fix it would be in the yield-from code in ceval.c, but directly genobject.c seems the safer place. ---------- components: Interpreter Core files: fix_stopiteration_crash.patch keywords: patch messages: 241454 nosy: scoder priority: normal severity: normal status: open title: _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions type: crash versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39108/fix_stopiteration_crash.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 21:48:37 2015 From: report at bugs.python.org (Davin Potts) Date: Sat, 18 Apr 2015 19:48:37 +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: <1429386517.3.0.00238327776654.issue23979@psf.upfronthosting.co.za> Davin Potts added the comment: Though it's been discussed elsewhere, issue17560 is a good one where the matter of "really big" objects are being communicated between processes via multiprocessing. In it, Richard shares some detail about the implementation in multiprocessing, its constraints and motivation. That discussion also highlights that the pickler has been made pluggable in multiprocessing since Python 3.3. That is, if you wish, you can use something other than Python's pickle to serialize objects and, in the extreme, potentially communicate them in a completely new way (perhaps even via out-of-band communication, though that was not the intention and would be arguably extreme). I do not think Python's pickle is necessarily what we should expect multiprocessing to use to help communicate objects between processes. Just because pickle is Python's serialization strategy does not also mean it must necessarily also be used in such communications. Thankfully, we have the convenience of using something other than pickle (or newer versions of pickle, since there have been versioned updates to pickle's format over time with some promising improvements). @Luis: To your specific question about the need for Queue, the benefits of a consistent behavior and methodology whether forking/spawning on one OS with its caveats versus another are just that: simplicity. The pluggable nature of the pickler opens up the opportunity for folks (perhaps such as yourself) to construct and plug-in optimized solutions for scenarios or edge cases of particular interest. The fact that we all start with a consistent behavior across platforms and process creation strategies is very appealing from a reduced complexity point of view. ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 22:18:15 2015 From: report at bugs.python.org (Steve Dower) Date: Sat, 18 Apr 2015 20:18:15 +0000 Subject: [issue23995] msvcrt could not be imported In-Reply-To: <1429382716.1.0.015048526051.issue23995@psf.upfronthosting.co.za> Message-ID: <1429388295.88.0.584831136019.issue23995@psf.upfronthosting.co.za> Steve Dower added the comment: You're right, we should be able to remove the ifdef for these (or hide them behind MS_WINDOWS if necessary). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 22:38:43 2015 From: report at bugs.python.org (Cyd Haselton) Date: Sat, 18 Apr 2015 20:38:43 +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: <1429389523.06.0.751075707784.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Ryan, Sorry...same problem. Segmentation fault generate-posix-vars failed make: *** [pybuilddir.txt] Error 1 /bld/python/cpython-master/cpython $ addr2line -C -f -e /lib/libpython3.5m.so.1.0 0008f42c _PyMem_RawStrdup /bld/python/cpython-master/cpython/Objects/obmalloc.c:358 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 22:45:48 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 18 Apr 2015 20:45:48 +0000 Subject: [issue23984] Documentation error: Descriptors In-Reply-To: <1429245728.01.0.810263114275.issue23984@psf.upfronthosting.co.za> Message-ID: <1429389948.54.0.256452705218.issue23984@psf.upfronthosting.co.za> Raymond Hettinger added the comment: In addition to being broken, the code is a crummy example that gives no hint of why one might want to use a staticmethod. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 18 22:58:00 2015 From: report at bugs.python.org (Davin Potts) Date: Sat, 18 Apr 2015 20:58:00 +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: <1429390680.36.0.641717992291.issue23992@psf.upfronthosting.co.za> Davin Potts added the comment: This is a nice example demonstrating what I agree is a problem with the current implementation of close. A practical concern with what I believe is being proposed in your trivial fix: if the workers are engaged in very long-running tasks (and perhaps slowly writing their overly large results to the results queue) then we would have to wait for quite a long time for these other workers to reach their natural completion. That said, I believe close should in fact behave just that way and have us subsequently wait for the others to be completed. It is not close's job to attempt to address the general concern I bring up. This change could be felt by people who have written their code to expect the result handler's immediate shutdown if there are no other visible results -- it is difficult to imagine what the impact would be. This is my long-winded way of saying it seems very sensible and welcome to me if you took the time to prepare a patch. ---------- stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 00:29:23 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 18 Apr 2015 22:29:23 +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: <1429396163.9.0.133621367784.issue23993@psf.upfronthosting.co.za> STINNER Victor added the comment: > "if you are using the C locale you or the OS are broken anyway, so we'll just pass the bytes through" Exactly. Even if you use Unicode, the Python 3 str type, you store text as raw bytes (in a custom format, as surrogate characters). > I'm not entirely convinced this won't cause issues, but I suppose it might not cause any more issues that having things break due to the C locale does. The most obvious issue is the come back of mojibake. Since you manipulate raw bytes, it's easy to concatenate two bytes strings encoded to two different encodings. https://unicodebook.readthedocs.org/definitions.html#mojibake The problem is that the question is not how bad it is use to manipulate text as bytes. The problem is that a working application written for Python 2 starts to randomly fail (on non-ASCII characters) on Python 3 when the LC_CTYPE locale is the POSIX locale ("C"). The first question is: should I keep Python 2 or write my application in a language which doesn't force me to understand Unicode? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 00:32:38 2015 From: report at bugs.python.org (Christian Heimes) Date: Sat, 18 Apr 2015 22:32:38 +0000 Subject: [issue23997] unicodedata_UCD_lookup() has theoretical buffer overflow Message-ID: <1429396358.28.0.910833101692.issue23997@psf.upfronthosting.co.za> New submission from Christian Heimes: Coverity has found a potential buffer overflow in the unicodedata module. The function call _getcode() which calls _cmpname(). _cmpname() copies data into fixed size buffer of length NAME_MAXLEN. Neither lookup() nor _getcode() limit name_length to NAME_MAXLEN. Therefore the buffer could theoretical overflow. In practice the buffer overflow can't be abused because Tools/unicode/makeunicodedata.py already limits max name length. I still like to fix the bug because it is a low hanging fruit. In most versions of Python the code already checks that name_length fits in INT_MAX. CID 1295028 (#1 of 1): Out-of-bounds access (OVERRUN) overrun-call: Overrunning callee's array of size 256 by passing argument (int)name_length (which evaluates to 2147483647) in call to _getcode ---------- files: unicode_name_maxlen.patch keywords: patch messages: 241461 nosy: benjamin.peterson, christian.heimes, ezio.melotti, haypo, lemburg, pitrou, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: unicodedata_UCD_lookup() has theoretical buffer overflow type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39109/unicode_name_maxlen.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 00:42:35 2015 From: report at bugs.python.org (Christian Heimes) Date: Sat, 18 Apr 2015 22:42:35 +0000 Subject: [issue23998] PyImport_ReInitLock() doesn't check for allocation error Message-ID: <1429396955.07.0.854315130889.issue23998@psf.upfronthosting.co.za> New submission from Christian Heimes: _PyImport_ReInitLock() doesn't check the return value of PyThread_allocate_lock(). A failed lock allocation can either lead to a NULL pointer dereference or to race conditions caused by a missing import lock. As there is no way to recover from a failed lock allication I recommend to abort with a fatal error. CID 1295025 (#1 of 1): Dereference after null check (FORWARD_NULL) var_deref_model: Passing null pointer import_lock to PyThread_acquire_lock, which dereferences it. ---------- files: import_reinit_fatal.patch keywords: buildbot, easy, patch messages: 241462 nosy: christian.heimes priority: normal severity: normal stage: patch review status: open title: PyImport_ReInitLock() doesn't check for allocation error type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39110/import_reinit_fatal.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 00:49:13 2015 From: report at bugs.python.org (Carol Willing) Date: Sat, 18 Apr 2015 22:49:13 +0000 Subject: [issue17227] devguide: buggy heading numbers In-Reply-To: <1361217002.34.0.936078305401.issue17227@psf.upfronthosting.co.za> Message-ID: <1429397353.28.0.285584552366.issue17227@psf.upfronthosting.co.za> Carol Willing added the comment: Correct Python Developer FAQ Section 28 to match the style of Section 27. Section numbers should now flow correctly in Sphinx. A section contents is displayed at the top of the section page for the user's convenience (especially since the FAQ questions have long titles). ---------- assignee: -> willingc nosy: +willingc stage: -> patch review Added file: http://bugs.python.org/file39111/iss17227.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 00:52:13 2015 From: report at bugs.python.org (Christian Heimes) Date: Sat, 18 Apr 2015 22:52:13 +0000 Subject: [issue23999] Undefined behavior in dtoa.c (rshift 32 of 32bit data type) Message-ID: <1429397533.86.0.186055088306.issue23999@psf.upfronthosting.co.za> New submission from Christian Heimes: Coverity has found undefined behavior in dtoa.c:d2b(). lo0bits() can return 32 which z >>= 32, where z is an uint32. I've talked to doku at PyCon. He suggested to update dtoa.c to a more recent version. Our copy is based on a version from 2001. There are more modern versions available, e.g. https://searchcode.com/codesearch/view/52748288/ from 2006. CID 1202735 (#1 of 1): Bad bit shift operation (BAD_SHIFT) large_shift: In expression z >>= k, right shifting by more than 31 bits has undefined behavior. The shift amount, k, is 32. ---------- messages: 241464 nosy: christian.heimes, doko, eric.smith, mark.dickinson, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Undefined behavior in dtoa.c (rshift 32 of 32bit data type) type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 00:52:17 2015 From: report at bugs.python.org (Carol Willing) Date: Sat, 18 Apr 2015 22:52:17 +0000 Subject: [issue16931] mention work-around to create diffs in default/non-git mode In-Reply-To: <1357894611.9.0.235167303817.issue16931@psf.upfronthosting.co.za> Message-ID: <1429397537.52.0.577496175826.issue16931@psf.upfronthosting.co.za> Changes by Carol Willing : ---------- assignee: -> willingc nosy: +willingc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 00:53:31 2015 From: report at bugs.python.org (Carol Willing) Date: Sat, 18 Apr 2015 22:53:31 +0000 Subject: [issue16930] mention limitations and/or alternatives to hg graft In-Reply-To: <1357893519.23.0.747104705775.issue16930@psf.upfronthosting.co.za> Message-ID: <1429397611.22.0.475912807017.issue16930@psf.upfronthosting.co.za> Changes by Carol Willing : ---------- assignee: -> willingc nosy: +willingc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 01:03:01 2015 From: report at bugs.python.org (STINNER Victor) Date: Sat, 18 Apr 2015 23:03:01 +0000 Subject: [issue23901] Force console stdout to use UTF8 on Windows In-Reply-To: <1428600157.62.0.0673126456323.issue23901@psf.upfronthosting.co.za> Message-ID: <1429398181.68.0.372201355291.issue23901@psf.upfronthosting.co.za> STINNER Victor added the comment: If sys.stdout is modified, it must be carefully tested in various scenario: - Windows console, default config - Windows console, TrueType font - PowerShell => see #21927, it looks like PowerShell has its own set of Unicode issues - Redirect output into a file - etc. Very good articles by Michael S. Kaplan on Windows stdout/console: - "Conventional wisdom is retarded, aka What the @#%&* is _O_U16TEXT?" http://www.siao2.com/2008/03/18/8306597.aspx - "Myth busting in the console" http://www.siao2.com/2010/10/07/10072032.aspx - "Cunningly conquering communicated console caveats. Comprende, mon Capit?n?" http://www.siao2.com/2010/05/07/10008232.aspx See also fwide() function. Good luck... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 01:45:53 2015 From: report at bugs.python.org (Akshit Khurana) Date: Sat, 18 Apr 2015 23:45:53 +0000 Subject: [issue23740] http.client request and send method have some datatype issues In-Reply-To: <1427052524.74.0.134908492197.issue23740@psf.upfronthosting.co.za> Message-ID: <1429400753.04.0.148544313056.issue23740@psf.upfronthosting.co.za> Changes by Akshit Khurana : ---------- nosy: +axitkhurana _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 02:08:59 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 19 Apr 2015 00:08:59 +0000 Subject: [issue15566] tarfile.TarInfo.frombuf documentation is out of date In-Reply-To: <1344248661.48.0.873103438616.issue15566@psf.upfronthosting.co.za> Message-ID: <1429402139.75.0.476810341045.issue15566@psf.upfronthosting.co.za> Martin Panter added the comment: Very simple documentation fix; looks good to me. ---------- nosy: +vadmium stage: needs patch -> commit review versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 02:44:00 2015 From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=) Date: Sun, 19 Apr 2015 00:44:00 +0000 Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za> Message-ID: <1429404240.35.0.658679712032.issue23725@psf.upfronthosting.co.za> Zbyszek J?drzejewski-Szmek added the comment: v6: - add newline ---------- Added file: http://bugs.python.org/file39112/tempfile_docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 03:00:33 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 01:00:33 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units Message-ID: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> New submission from Larry Hastings: I found another bug in the mapping of converters to format units. (s#, z#, and y# all allow zeroes.) I've redone the approach for str_converter in an attempt to make it easier to read. It'd be swell if, after this gets checked in (or rejected), somebody *else* took a pass to see if they could find any bugs. ---------- assignee: larry files: larry.one.more.clinic.format.unit.map.cleanup.1.txt messages: 241468 nosy: larry, serhiy.storchaka, zach.ware priority: normal severity: normal stage: patch review status: open title: More fixes for the Clinic mapping of converters to format units type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file39113/larry.one.more.clinic.format.unit.map.cleanup.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 03:06:17 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 01:06:17 +0000 Subject: [issue24001] Clinic: use raw types in types= set Message-ID: <1429405577.22.0.134829799978.issue24001@psf.upfronthosting.co.za> New submission from Larry Hastings: New proposed semantics for the types= parameter to converters: where possible, pass in actual types. The resulting syntax: c: int(types={str}) # maps to 'U' s: str(types={str, robuffer}, length=True, zeroes=True) # maps to 's#' Since "buffer", "robuffer", and "rwbuffer" are fake pseudotypes, I created empty classes with those names. Serhiy: with this change in place, the types= parameter uses almost the same number of characters as it used to when it was a string. (The new syntax requires commas between elements, so for two or more types it's slightly longer.) Yet this makes the types= parameter far more accurate in illustrating what it's supposed to represent. Does this make you happy? :) ---------- assignee: larry components: Argument Clinic files: larry.clinic.use.raw.types.1.txt messages: 241469 nosy: larry, serhiy.storchaka, zach.ware priority: normal severity: normal stage: patch review status: open title: Clinic: use raw types in types= set type: enhancement Added file: http://bugs.python.org/file39114/larry.clinic.use.raw.types.1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 03:16:51 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 19 Apr 2015 01:16:51 +0000 Subject: [issue17227] devguide: buggy heading numbers In-Reply-To: <1361217002.34.0.936078305401.issue17227@psf.upfronthosting.co.za> Message-ID: <1429406211.91.0.196734379533.issue17227@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! The patch doesn't address msg182641 and I think this is a Sphinx bug(or perhaps a feature request?). tocdepth should not change the heading numbers. I couldn't find any similar report on the Sphinx issue tracker. So I suggest opening an issue there and closing this one as "third party". ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 03:32:41 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 19 Apr 2015 01:32:41 +0000 Subject: [issue15566] tarfile.TarInfo.frombuf documentation is out of date In-Reply-To: <1344248661.48.0.873103438616.issue15566@psf.upfronthosting.co.za> Message-ID: <20150419013238.31121.27633@psf.io> Roundup Robot added the comment: New changeset d737ab3ea1ae by Berker Peksag in branch '3.4': Issue #15566: Document encoding and errors parameters of TarInfo.frombuf(). https://hg.python.org/cpython/rev/d737ab3ea1ae New changeset 85cba64e24dc by Berker Peksag in branch 'default': Issue #15566: Document encoding and errors parameters of TarInfo.frombuf(). https://hg.python.org/cpython/rev/85cba64e24dc ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 03:33:32 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 19 Apr 2015 01:33:32 +0000 Subject: [issue15566] tarfile.TarInfo.frombuf documentation is out of date In-Reply-To: <1344248661.48.0.873103438616.issue15566@psf.upfronthosting.co.za> Message-ID: <1429407212.17.0.740579595153.issue15566@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! ---------- nosy: +berker.peksag resolution: -> fixed stage: commit review -> resolved status: open -> closed versions: -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 04:47:53 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 19 Apr 2015 02:47:53 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <1429411673.53.0.0924127573429.issue23275@psf.upfronthosting.co.za> Nick Coghlan added the comment: As Raymond notes, this is a fairly harmless quirk - it changes a SyntaxError to an iterable length dependent ValueError: >>> () = [] File "", line 1 SyntaxError: can't assign to () >>> [] = () >>> [] = [1] Traceback (most recent call last): File "", line 1, in ValueError: too many values to unpack (expected 0) I only found out about this after being puzzled when a typo in a live demo at PyCon 2015 failed to fail as I expected after seeing the presenter type a "[]" into the LHS of an assignment instead of the intended "_". Removing the data dependence to make the assignment fail immediately (even if never tested against a non-empty iterable) would involve making the handling of List_kind match that of Tuple_kind in the switch statement that eryksun quoted. I don't think it's an urgent fix, but if someone wanted to fix it (including a new test), I think it would be a reasonable contribution to accept. ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 05:34:31 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 19 Apr 2015 03:34:31 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <1429414471.17.0.477073140746.issue23275@psf.upfronthosting.co.za> Martin Panter added the comment: I would prefer this be fixed in the opposite direction, to allow ?unpacking? an empty iterable using round brackets. I have used this syntax on purpose as a concise way to ensure that a generator is exhaused with no more yields: >>> def gen(): ... yield "partial computation" ... print("computation allowed to complete") ... >>> g = gen() >>> next(g) 'partial computation' >>> [] = g computation allowed to complete ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 07:34:03 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 05:34:03 +0000 Subject: [issue23920] Should Clinic have "nullable" or types=NoneType? In-Reply-To: <1428812661.52.0.406302391077.issue23920@psf.upfronthosting.co.za> Message-ID: <1429421643.65.0.224102646282.issue23920@psf.upfronthosting.co.za> Larry Hastings added the comment: I'm now converging on changing types= to accept a set of real types, see issue #24001. That change has an impact on this decision. (By the way, let's assume that if "nullable", I have to rename it to "accepts_none". I'll use that name below.) What makes me want to use types={NoneType} is the Zen: "There should be one (and preferably only one) obvious way to do it", and "Special cases aren't special enough to break the rules". But Argument Clinic's input isn't Python, so maybe the Zen doesn't need to be as strict here. What makes me not want to use types={NoneType} is that it's generally longer, and it requires you to know the default types accepted by a converter. Currently (after the rename) to get format unit "z" you write: s: str(accepts_none=True) If I changed this (and #24001 goes in), you'd have to write: s: str(types={str, NoneType}) It requires you to know all the default types of the converter in question, just so you can add NoneType to it. And it's longer. We could fix it if converter classes generally published their default types. So you could say s: str(types=str_converter.default_types + {NoneType}) And it's even longer. So we probably shouldn't bother with this. On the other hand, out of all the converters that exist, only three have a types= argument (int, str, and Py_buffer). And it's not unreasonable to expect the caller to know the default types= set. Although, we'd have to add types= to a fourth converter (Py_UNICODE), which currently supports nullable= but doesn't need types=. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 07:34:54 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 05:34:54 +0000 Subject: [issue24001] Clinic: use raw types in types= set In-Reply-To: <1429405577.22.0.134829799978.issue24001@psf.upfronthosting.co.za> Message-ID: <1429421694.7.0.708817173373.issue24001@psf.upfronthosting.co.za> Larry Hastings added the comment: Should types= be renamed accept= ? It's a set of the types of the Python objects that this parameter should accept. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 07:39:10 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 05:39:10 +0000 Subject: [issue24002] Add un-parse function to ast Message-ID: <1429421950.27.0.647153175832.issue24002@psf.upfronthosting.co.za> New submission from Larry Hastings: Twice recently I've wanted a function that transforms an AST node tree back into text: * In the hacked-up Tools/clinic/clinic.py for issue #24001 * In the hacked-up Lib/inspect.py for issue #23967 Both times I did a half-assed job just to get the patch working, so we could decide whether or not we want to go this route. It seems useful and reasonable to do a proper job and add this functionality to ast. ---------- components: Library (Lib) messages: 241477 nosy: benjamin.peterson, georg.brandl, larry priority: normal severity: normal stage: needs patch status: open title: Add un-parse function to ast type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 07:40:12 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 05:40:12 +0000 Subject: [issue23967] Make inspect.signature expression evaluation more powerful In-Reply-To: <1429123957.6.0.780975142449.issue23967@psf.upfronthosting.co.za> Message-ID: <1429422012.65.0.397751670951.issue23967@psf.upfronthosting.co.za> Larry Hastings added the comment: I should mention that evalify_node() is pretty hacked up here, and is not ready to be checked in. (I'm proposing separately that we simply add something like this directly into the standard library, see issue #24002.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 07:40:27 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 05:40:27 +0000 Subject: [issue24001] Clinic: use raw types in types= set In-Reply-To: <1429405577.22.0.134829799978.issue24001@psf.upfronthosting.co.za> Message-ID: <1429422027.34.0.44665507321.issue24001@psf.upfronthosting.co.za> Larry Hastings added the comment: I should mention that evalify_node() is pretty hacked up here, and is not ready to be checked in. (I'm proposing separately that we simply add something like this directly into the standard library, see issue #24002.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 07:49:00 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 05:49:00 +0000 Subject: [issue24002] Add un-parse function to ast In-Reply-To: <1429421950.27.0.647153175832.issue24002@psf.upfronthosting.co.za> Message-ID: <1429422540.83.0.951772500218.issue24002@psf.upfronthosting.co.za> Changes by Larry Hastings : ---------- nosy: +serhiy.storchaka, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 07:49:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Apr 2015 05:49:49 +0000 Subject: [issue23920] Should Clinic have "nullable" or types=NoneType? In-Reply-To: <1428812661.52.0.406302391077.issue23920@psf.upfronthosting.co.za> Message-ID: <1429422589.12.0.762064069583.issue23920@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: accepts_none=True looks as "doesn't accept anything" to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 07:51:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Apr 2015 05:51:32 +0000 Subject: [issue24001] Clinic: use raw types in types= set In-Reply-To: <1429405577.22.0.134829799978.issue24001@psf.upfronthosting.co.za> Message-ID: <1429422692.76.0.828209892064.issue24001@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: accept= (or accept_types=) LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 07:51:43 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 19 Apr 2015 05:51:43 +0000 Subject: [issue24002] Add un-parse function to ast In-Reply-To: <1429421950.27.0.647153175832.issue24002@psf.upfronthosting.co.za> Message-ID: <1429422703.12.0.0521665041605.issue24002@psf.upfronthosting.co.za> Berker Peksag added the comment: Perhaps a NodeVisitor subclass (something like Armin Ronacher's codegen module https://github.com/berkerpeksag/astor/blob/master/astor/codegen.py#L54 can be added to the ast module. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 07:57:06 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 05:57:06 +0000 Subject: [issue24002] Add un-parse function to ast In-Reply-To: <1429421950.27.0.647153175832.issue24002@psf.upfronthosting.co.za> Message-ID: <1429423026.78.0.454227298711.issue24002@psf.upfronthosting.co.za> Larry Hastings added the comment: Good idea, I'll go ahead and borrow Guido's time machine. https://docs.python.org/3/library/ast.html#ast.NodeVisitor However, NodeVisitor does not transform the ast tree back into text. So in what way is this helpful? Also, for what it's worth: both my use cases only need to handle expressions ("r-values" if you prefer). I don't need to generate classes, functions, blocks, or even statements. If we wanted to weaken the implementation to only handle expressions I'd be happy. (In fact, I'd be happier this way, because it means the implementation would be much simpler!) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 07:58:22 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 05:58:22 +0000 Subject: [issue23920] Should Clinic have "nullable" or types=NoneType? In-Reply-To: <1428812661.52.0.406302391077.issue23920@psf.upfronthosting.co.za> Message-ID: <1429423102.85.0.0249863686756.issue23920@psf.upfronthosting.co.za> Larry Hastings added the comment: Oh, I misremembered. The name "allow_none" was inflicted on me by python-dev, in this thread: https://mail.python.org/pipermail/python-dev/2014-August/135650.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 08:11:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Apr 2015 06:11:43 +0000 Subject: [issue24002] Add un-parse function to ast In-Reply-To: <1429421950.27.0.647153175832.issue24002@psf.upfronthosting.co.za> Message-ID: <1429423903.11.0.277414646148.issue24002@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: For issue24001 you need rather eval(ast). But a function for stringifying ast would be useful in any case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 08:14:40 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 06:14:40 +0000 Subject: [issue24002] Add un-parse function to ast In-Reply-To: <1429421950.27.0.647153175832.issue24002@psf.upfronthosting.co.za> Message-ID: <1429424080.5.0.425285306165.issue24002@psf.upfronthosting.co.za> Larry Hastings added the comment: Actually eval(ast) is all I need for #23967 too. But eval is a builtin, so it feels wrong to have it supporting--and therefore dependent on--ast. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 08:16:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Apr 2015 06:16:16 +0000 Subject: [issue24002] Add un-parse function to ast In-Reply-To: <1429421950.27.0.647153175832.issue24002@psf.upfronthosting.co.za> Message-ID: <1429424176.5.0.638525913301.issue24002@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think there is standard way to transform ast to bytecode and evaluate it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 08:17:07 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 06:17:07 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1429424227.66.0.65458587715.issue20180@psf.upfronthosting.co.za> Larry Hastings added the comment: Sadly, for political reasons, it's best that we not convert collections, itertools, or random for now. I'll update this issue if the situation changes. Sorry about that! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 08:23:34 2015 From: report at bugs.python.org (Martin Panter) Date: Sun, 19 Apr 2015 06:23:34 +0000 Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za> Message-ID: <1429424614.05.0.227766877394.issue15582@psf.upfronthosting.co.za> Martin Panter added the comment: Sometimes the doc string for the overridden method does not make much sense in the context of the subclass. Just wondering if this was considered; it seems like a fairly serious downside to this new feature. E.g. in a package I am reviewing, there is a class that inherits HTMLParser and converts HTML to PDF. There is no doc string, so previously there was just the signature in the ?pydoc? output. Now the output looks like: | __init__(self, pdf, image_map=None) | Initialize and reset this instance. | | If convert_charrefs is True (the default), all character references | are automatically converted to the corresponding Unicode characters. The second paragraph mentions parameters and settings of the internal base class, which doesn?t make much sense for the subclass. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 08:26:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Apr 2015 06:26:32 +0000 Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za> Message-ID: <1429424792.71.0.465450329834.issue15582@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 09:20:13 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 07:20:13 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <1429428013.76.0.815757071067.issue24000@psf.upfronthosting.co.za> Larry Hastings added the comment: Oh, heavens, yes, that's much nicer. Thanks for the suggestion, Serhiy! ---------- Added file: http://bugs.python.org/file39115/larry.one.more.clinic.format.unit.map.cleanup.2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 09:28:32 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 07:28:32 +0000 Subject: [issue23920] Should Clinic have "nullable" or types=NoneType? In-Reply-To: <1428812661.52.0.406302391077.issue23920@psf.upfronthosting.co.za> Message-ID: <1429428512.32.0.482544455186.issue23920@psf.upfronthosting.co.za> Larry Hastings added the comment: p.s. I'm now leaning heavily towards renaming "types" to "accept", and putting NoneType in the set passed to accept= instead of a separate parameter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 10:13:00 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 19 Apr 2015 08:13:00 +0000 Subject: [issue23999] Undefined behavior in dtoa.c (rshift 32 of 32bit data type) In-Reply-To: <1429397533.86.0.186055088306.issue23999@psf.upfronthosting.co.za> Message-ID: <1429431180.75.0.312296401308.issue23999@psf.upfronthosting.co.za> Mark Dickinson added the comment: I'm pretty sure that our code was based on something rather more recent than 2001: it was the most recent version available at the time (around 2008?), and it incorporates subsequent fixes from David Gay. Please don't replace our dtoa.c with a current version: ours has diverged from the original, and includes fixes that aren't available upstream. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 10:19:32 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 19 Apr 2015 08:19:32 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <1429431572.19.0.0378024978607.issue23996@psf.upfronthosting.co.za> Stefan Behnel added the comment: Here's a better patch that avoids exception normalisation in all "normal" cases. ---------- Added file: http://bugs.python.org/file39116/fix_stopiteration_crash.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 10:19:40 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 08:19:40 +0000 Subject: [issue23920] Should Clinic have "nullable" or types=NoneType? In-Reply-To: <1428812661.52.0.406302391077.issue23920@psf.upfronthosting.co.za> Message-ID: <1429431580.22.0.088676392107.issue23920@psf.upfronthosting.co.za> Larry Hastings added the comment: I've posted about this to python-dev. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 10:21:18 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 19 Apr 2015 08:21:18 +0000 Subject: [issue23999] Undefined behavior in dtoa.c (rshift 32 of 32bit data type) In-Reply-To: <1429397533.86.0.186055088306.issue23999@psf.upfronthosting.co.za> Message-ID: <1429431678.52.0.487250895813.issue23999@psf.upfronthosting.co.za> Mark Dickinson added the comment: Looking more closely, the report doesn't make sense to me: `k` is the return value from a call to `lo0bits`. From the source of `lo0bits`, I don't see any way that `k` can be 32: it's always going to be in the range [0, 31]. Christian: do you have any more information from Coverity? This looks like a false positive to me. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 10:25:57 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 19 Apr 2015 08:25:57 +0000 Subject: [issue23999] Undefined behavior in dtoa.c (rshift 32 of 32bit data type) In-Reply-To: <1429397533.86.0.186055088306.issue23999@psf.upfronthosting.co.za> Message-ID: <1429431957.77.0.070637340653.issue23999@psf.upfronthosting.co.za> Mark Dickinson added the comment: Ah, sorry; I see it. Fix on the way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 10:41:32 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 19 Apr 2015 08:41:32 +0000 Subject: [issue23999] Undefined behavior in dtoa.c (rshift 32 of 32bit data type) In-Reply-To: <1429397533.86.0.186055088306.issue23999@psf.upfronthosting.co.za> Message-ID: <1429432892.67.0.633798670132.issue23999@psf.upfronthosting.co.za> Mark Dickinson added the comment: Okay, so after looking more closely, this *still* looks like a false positive: `lo0bits` *can* return 32, but only for an input of zero. In the code in question, we're doing `k = lo0bits(&y)`, so the only way we can get a `k` of `32` is if `y = 0`. But the whole thing is inside an "if" block that looks like `if ((y = word1(d))) { ... }` (yep, completely with the extra parentheses and the misleading equality-test-lookalike assignment), so that `if` block won't be executed if `y` is zero. I edited the code to print out debugging information if `k` is ever 32 at that point, and saw no output. So I don't think that line ever gets executed with `k = 32`. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 10:42:06 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 19 Apr 2015 08:42:06 +0000 Subject: [issue23999] Undefined behavior in dtoa.c (rshift 32 of 32bit data type) In-Reply-To: <1429397533.86.0.186055088306.issue23999@psf.upfronthosting.co.za> Message-ID: <1429432926.38.0.107810357187.issue23999@psf.upfronthosting.co.za> Mark Dickinson added the comment: > saw no output Bah; missed a bit. I saw no output when running the Python test suite, that is. That's not definitive, of course. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 10:45:56 2015 From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiDFoG1pbGF1ZXI=?=) Date: Sun, 19 Apr 2015 08:45:56 +0000 Subject: [issue18654] modernize mingw&cygwin compiler classes In-Reply-To: <1375621500.14.0.511859388859.issue18654@psf.upfronthosting.co.za> Message-ID: <1429433156.26.0.171209850186.issue18654@psf.upfronthosting.co.za> V?clav ?milauer added the comment: Ping? Roumen has been updaing the patch for one year and no reaction. Is there something which can be done? ---------- nosy: +eudoxos _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 11:08:33 2015 From: report at bugs.python.org (Martin Falatic) Date: Sun, 19 Apr 2015 09:08:33 +0000 Subject: [issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values In-Reply-To: <1429231899.59.0.405315540238.issue23982@psf.upfronthosting.co.za> Message-ID: <1429434513.46.0.119434859012.issue23982@psf.upfronthosting.co.za> Martin Falatic added the comment: Yes, the python.org releases specify the TclTK they should be used with, for OSX: https://www.python.org/download/mac/tcltk/ If there's another python.org bug report list let me know, but this still seems to be the right place. Since Python.org's windows distribution is what led to this question, I'd like to at least see it documented somewhere what TclTk is compiled into the Python.org windows distribution. I didn't find any info on what TclTk Python.org's Windows build includes, and that's something that can be rectified here. (Since there are documented *recommendations* for what to use with the OSX builds from this site then there ought to be some similar documentation what is *built in* to the Windows builds from this site.) As for the failure of TclTk to properly document the change they made to their colors, that's a matter for their bug tracker. I took their documentation at face value, and didn't find information to the contrary when I searched prior to posting this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 11:28:34 2015 From: report at bugs.python.org (Martin Falatic) Date: Sun, 19 Apr 2015 09:28:34 +0000 Subject: [issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values In-Reply-To: <1429231899.59.0.405315540238.issue23982@psf.upfronthosting.co.za> Message-ID: <1429435714.74.0.468082047482.issue23982@psf.upfronthosting.co.za> Martin Falatic added the comment: FYI, I've filed a bug with the TclTk people regarding their documentation. http://core.tcl.tk/tk/tktview/2a02881e4c23634022d0ae40a14383d9baad9eb9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 11:43:09 2015 From: report at bugs.python.org (john kaiser) Date: Sun, 19 Apr 2015 09:43:09 +0000 Subject: [issue24003] variable naming Message-ID: <1429436589.53.0.115033334607.issue24003@psf.upfronthosting.co.za> New submission from john kaiser: found error when naming variables with basic functions how to replicate while=123 #while should be treated as variable name while True: #this should be treated as a function print while #this should be as a variable name result: File "C:\Users\_you got served_\Desktop\bugs.py", line 1 while = 123 ^ SyntaxError: invalid syntax ---------- files: bugs.py messages: 241502 nosy: kaiser priority: normal severity: normal status: open title: variable naming type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file39117/bugs.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 11:53:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Apr 2015 09:53:48 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <1429437228.58.0.853022063089.issue24000@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Doesn't always zeroes == length? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 11:58:41 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Apr 2015 09:58:41 +0000 Subject: [issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values In-Reply-To: <1429231899.59.0.405315540238.issue23982@psf.upfronthosting.co.za> Message-ID: <1429437521.98.0.489044847148.issue23982@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I don't think that we should document such minor details in Tkinter documentation. There are larger differences between Tcl/Tk versions that can make Python programs fail (e.g. introducing new internal Tcl/Tk type), and they are not documented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 12:10:19 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 19 Apr 2015 10:10:19 +0000 Subject: [issue24003] variable naming In-Reply-To: <1429436589.53.0.115033334607.issue24003@psf.upfronthosting.co.za> Message-ID: <1429438219.22.0.139814926634.issue24003@psf.upfronthosting.co.za> Steven D'Aprano added the comment: This is not a bug. "while" is a keyword, it is part of Python's syntax, and you are not permitted to use keywords as variable names. This is not an accident, but a deliberate decision. ---------- nosy: +steven.daprano resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 12:21:02 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 19 Apr 2015 10:21:02 +0000 Subject: [issue24004] avoid explicit generator type check in asyncio Message-ID: <1429438862.32.0.692811371536.issue24004@psf.upfronthosting.co.za> New submission from Stefan Behnel: asyncio/coroutines.py contains this code: """ _COROUTINE_TYPES = (types.GeneratorType, CoroWrapper) def iscoroutine(obj): """Return True if obj is a coroutine object.""" return isinstance(obj, _COROUTINE_TYPES) """ In other places, it uses inspect.isgenerator() to do the same thing. This is inconsistent and should be changed. Code that wants to patch inspect.isgenerator() in order to support other generator types shouldn't also have to patch asyncio directly, and code that wants to support other generator types in asyncio shouldn't have to patch both places either. ---------- components: asyncio messages: 241506 nosy: gvanrossum, haypo, scoder, yselivanov priority: normal severity: normal status: open title: avoid explicit generator type check in asyncio type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 12:23:55 2015 From: report at bugs.python.org (Martin Falatic) Date: Sun, 19 Apr 2015 10:23:55 +0000 Subject: [issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values In-Reply-To: <1429231899.59.0.405315540238.issue23982@psf.upfronthosting.co.za> Message-ID: <1429439035.55.0.810226014224.issue23982@psf.upfronthosting.co.za> Martin Falatic added the comment: No, I don't expect something like the color change to be documented here (unless that thing is incorrectly documented within python.org's current release trees). I do expect that just as python.org's OSX releases document the recommended version of TclTk to use (e.g., https://www.python.org/download/mac/tcltk/) there should be equivalent documentation describing what version of TckTk is actualy compiled into the Windows releases here (e.g., 8.5.9 or 8.6.4 or such. (Note that Tkinter.TclVersion/TkVersion aren't sufficiently detailed to dynamically determine the exact in-built versions either). Beyond that, it's up to the user to read more about that specified or recommended release in the external Tcl/Tk docs (except where such documentation is present in the doc trees on python.org). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 12:29:29 2015 From: report at bugs.python.org (Jaivish Kothari) Date: Sun, 19 Apr 2015 10:29:29 +0000 Subject: [issue24005] Documentation Error: Extra line Break Message-ID: <1429439369.0.0.722585874502.issue24005@psf.upfronthosting.co.za> New submission from Jaivish Kothari: https://docs.python.org/2/whatsnew/2.4.html?highlight=decorators#pep-318-decorators-for-functions-and-methods ''' def require_int (func): def wrapper (arg): assert isinstance(arg, int) return func(arg) return wrapper ''' New line is ommited before return wrapper ''' def require_int (func): def wrapper (arg): assert isinstance(arg, int) return func(arg) return wrapper ''' ---------- assignee: docs at python components: Documentation messages: 241508 nosy: docs at python, georg.brandl, janonymous priority: normal severity: normal status: open title: Documentation Error: Extra line Break type: enhancement versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 12:43:59 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Apr 2015 10:43:59 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <1429440239.21.0.388165392023.issue24000@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Converters with encoding=True are not used in converted code. "es" is never used in still non-converted code and "et" is used only 6 times (for "idna" and "utf-8" encodings) and can be replaced with custom converter or inlined code. So I think the support of encoding=True should be removed from Argument Clinic soon. Converters with length=True are used very rarely too, and they are mostly legacy converters. I think we should get rid of most of them in future. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 13:00:56 2015 From: report at bugs.python.org (Jaivish Kothari) Date: Sun, 19 Apr 2015 11:00:56 +0000 Subject: [issue24005] Documentation Error: Extra line Break In-Reply-To: <1429439369.0.0.722585874502.issue24005@psf.upfronthosting.co.za> Message-ID: <1429441256.9.0.797668988436.issue24005@psf.upfronthosting.co.za> Jaivish Kothari added the comment: Please find the attached patch for review. ---------- keywords: +patch resolution: -> fixed Added file: http://bugs.python.org/file39118/doc_patch.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 14:42:51 2015 From: report at bugs.python.org (Georg Brandl) Date: Sun, 19 Apr 2015 12:42:51 +0000 Subject: [issue24005] Documentation Error: Extra line Break In-Reply-To: <1429439369.0.0.722585874502.issue24005@psf.upfronthosting.co.za> Message-ID: <1429447371.09.0.694023660988.issue24005@psf.upfronthosting.co.za> Georg Brandl added the comment: Why is this a bug? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 14:43:07 2015 From: report at bugs.python.org (Matthias Klose) Date: Sun, 19 Apr 2015 12:43:07 +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: <1429447387.41.0.812736763453.issue22980@psf.upfronthosting.co.za> Matthias Klose added the comment: > I'm not trying to discredit any use cases, I just don't see them. so why do you see this on x86 for 32/64bit, but not for ARM soft-float/hard-float. The example given was pretty clear. > All Linux distributions I know place the 32-bit and 64-bit versions > of shared libs into different directories rather than putting them all > into a single dir and adding ABI flags to the .so files. Well, then at least you don't know Debian, Ubuntu, and any of their derivates. And even the Python default install on Linux installs into the same place. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 14:44:14 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 19 Apr 2015 12:44:14 +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: <20150419124411.27924.21629@psf.io> Roundup Robot added the comment: New changeset 558335559383 by doko in branch 'default': - #22980: fix triplet configure test for more targets https://hg.python.org/cpython/rev/558335559383 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 14:59:01 2015 From: report at bugs.python.org (Antti Haapala) Date: Sun, 19 Apr 2015 12:59:01 +0000 Subject: [issue11587] METH_KEYWORDS alone gives "METH_OLDARGS is no longer supported!" In-Reply-To: <1300371450.74.0.196347407425.issue11587@psf.upfronthosting.co.za> Message-ID: <1429448341.15.0.642432544829.issue11587@psf.upfronthosting.co.za> Antti Haapala added the comment: This is *still* there in Hg tip: PyCFunction_Call in Objects/methodobject.c does not have a case for `METH_KEYWORDS` only at all. The documentation for METH_KEYWORDS says that it is *typically* coupled with METH_VARARGS; however not having the case means that METH_KEYWORDS *cannot* be used without METH_VARARGS at all. Furthermore, the default case should actually report the wrong flags value instead of calling it the "METH_OLDARGS", since it can be caused by any future combination, by setting it to zero, or undefined behaviour causing the flag to be overwritten. ---------- nosy: +ztane _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 15:03:53 2015 From: report at bugs.python.org (Christian Heimes) Date: Sun, 19 Apr 2015 13:03:53 +0000 Subject: [issue23999] Undefined behavior in dtoa.c (rshift 32 of 32bit data type) In-Reply-To: <1429397533.86.0.186055088306.issue23999@psf.upfronthosting.co.za> Message-ID: <1429448633.74.0.512494654015.issue23999@psf.upfronthosting.co.za> Christian Heimes added the comment: You could be right. I didn't track all paths manually. All this bit shifting is making my head dizzy... :) Anyways I have sent you an invite for Coverity, so you can check the result yourself. The Python test suite passes with assert(k < 32); inside the problematic block, too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 16:09:11 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 19 Apr 2015 14:09:11 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <1429452551.23.0.0593739991348.issue23996@psf.upfronthosting.co.za> Stefan Behnel added the comment: And another patch update that should avoid any potential performance regressions due to the additional type check. ---------- Added file: http://bugs.python.org/file39119/fix_stopiteration_crash.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 16:18:02 2015 From: report at bugs.python.org (Brett Cannon) Date: Sun, 19 Apr 2015 14:18:02 +0000 Subject: [issue23998] PyImport_ReInitLock() doesn't check for allocation error In-Reply-To: <1429396955.07.0.854315130889.issue23998@psf.upfronthosting.co.za> Message-ID: <1429453082.04.0.274591263819.issue23998@psf.upfronthosting.co.za> Brett Cannon added the comment: LGTM ---------- assignee: -> christian.heimes nosy: +brett.cannon stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 16:20:43 2015 From: report at bugs.python.org (Mert Bora Alper) Date: Sun, 19 Apr 2015 14:20:43 +0000 Subject: [issue23994] argparse fails to detect program name when there is a slash at the end of the program's path In-Reply-To: <1429379283.39.0.0511547854084.issue23994@psf.upfronthosting.co.za> Message-ID: <1429453243.37.0.0150174572236.issue23994@psf.upfronthosting.co.za> Mert Bora Alper added the comment: > I think this was just overlooked when implementing argparse. Most code out there is likely to get the executable name using: > > os.path.basename(sys.argv[0]) > > Which is going to do exactly what you are seeing here when sys.argv[0] ends with a /. > > feel free to submit a patch. perhaps as simple as this? > > os.path.basename(sys.argv[0].rstrip(os.path.sep)) > > But I'd expect a bunch of other code out there to have the same problem. It is exactly as you said: https://hg.python.org/cpython/file/3.4/Lib/argparse.py#l1619 Patch included. Created and tested using latest source at https://hg.python.org/cpython/. ---------- keywords: +patch resolution: -> fixed Added file: http://bugs.python.org/file39120/argparse.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 17:23:49 2015 From: report at bugs.python.org (irdb) Date: Sun, 19 Apr 2015 15:23:49 +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: <1429457029.93.0.733868517725.issue16893@psf.upfronthosting.co.za> Changes by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 17:33:43 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 19 Apr 2015 15:33:43 +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: <1429457623.61.0.720630633298.issue23993@psf.upfronthosting.co.za> R. David Murray added the comment: Well, previously our answer has been "you have to understand unicode". If we are going to change that, it probably needs a python-dev discussion. But like I said, providing the *tools* to make it possible to easily do this, just not as a default, seems like mostly a no-brainer. It's making it the default that is controversial, IMO. (Call me -0.5 at this point in the discussion, as regards making it the default). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 18:27:57 2015 From: report at bugs.python.org (Ethan Furman) Date: Sun, 19 Apr 2015 16:27:57 +0000 Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za> Message-ID: <1429460877.29.0.734996727375.issue15582@psf.upfronthosting.co.za> Ethan Furman added the comment: Sounds like good incentive to add good docstrings. :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 19:21:02 2015 From: report at bugs.python.org (ppperry) Date: Sun, 19 Apr 2015 17:21:02 +0000 Subject: [issue24006] Multiprocessing fails when using functions defined in interactive interpreter. Message-ID: <1429464061.97.0.0459539459978.issue24006@psf.upfronthosting.co.za> New submission from ppperry: An AttributeError is raised when starting a new process with an object defined in the interactive interpreter >>>def test():print "test" >>>test() test >>>from threading import Thread >>>Thread(target=test).start() test >>>from multiprocessing import Process >>>Process(target=test).start() File /Lib/pickle.py, line 1126, in find_class klass = getattr(mod, name) AttributeError: 'module' object has no attribute 'test' running similar code in a file works and does not raise an error. ---------- components: Interpreter Core, Library (Lib) messages: 241521 nosy: ppperry priority: normal severity: normal status: open title: Multiprocessing fails when using functions defined in interactive interpreter. type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 19:27:30 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 17:27:30 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <1429464450.65.0.800193526425.issue24000@psf.upfronthosting.co.za> Larry Hastings added the comment: > Doesn't always zeroes == length? "zeroes" requires "length", but "length" does not require "zeroes". As it happens all the format units supported by str always have both parameters either True or False. But the Py_UNICODE converter accepts "length" for format units u# and Z#, and doesn't support "zeroes". I want the converters to accept common parameters. That will make comprehension easier for the casual reader. So I want to keep "length" as a separate parameter, even for str. > So I think the support of encoding=True should be removed > from Argument Clinic soon. [...] I think we should get rid > of [length] in future. I disagree. My goal with Argument Clinic is that third-party developers will use it to write extensions. And we don't know how many extension modules are using es, es#, et, et#, s#, y#, z#, u#, and U#. I don't think we can remove any of this functionality until 4.0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 19:54:23 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 19 Apr 2015 17:54:23 +0000 Subject: [issue23725] update tempfile docs to say that TemporaryFile is secure In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za> Message-ID: <1429466063.73.0.360144362534.issue23725@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 19:57:04 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 19 Apr 2015 17:57:04 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <1429466224.27.0.110861923866.issue23275@psf.upfronthosting.co.za> R. David Murray added the comment: There is also no reason to break currently working code, which turning this into a syntax error would od. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 20:01:27 2015 From: report at bugs.python.org (Eric Snow) Date: Sun, 19 Apr 2015 18:01:27 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429385608.73.0.791271816142.issue23990@psf.upfronthosting.co.za> Message-ID: Eric Snow added the comment: Note that (in my mind, unfortunately) the pickle module looks up several dunder methods on instances. That isn't quite the same thing since the issue is about callable not triggering the descriptor protocol. However it is closely related. I point this out because this similar behavior of pickle is a source of mysterious, hard to understand bugs in many of the same corner cases. Thus I'm -1 on changing the behavior of callable. >From what I understand, the motivation here is in the case of proxies that dynamically determine their capability and raise AttributeError accordingly. If that is the case then consider prior art such as MagicMock or other existing proxy types on PyPI. Also consider if there is a proxy-specific approach that can resolve the matter. I've long thought there is room in the stdlib for a "proxy" module that holds proxy-related helpers and classes. Finally, instead of changing callable, why not use a metaclass that does the right thing? I believe MagicMock does something along those lines. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 20:10:03 2015 From: report at bugs.python.org (Carol Willing) Date: Sun, 19 Apr 2015 18:10:03 +0000 Subject: [issue24005] Documentation Error: Extra line Break In-Reply-To: <1429439369.0.0.722585874502.issue24005@psf.upfronthosting.co.za> Message-ID: <1429467003.58.0.535639176032.issue24005@psf.upfronthosting.co.za> Carol Willing added the comment: janonymous, Thanks for the contribution. I agree with George that this is not a bug. The whitespace exists for developer readability and maintainability of code. Here's a section from PEP8 about the use of whitespace (https://www.python.org/dev/peps/pep-0008/#id15). I am closing this issue as not a bug. I do hope you will contribute to Python again. Thanks. Close as not a bug. ---------- nosy: +willingc resolution: fixed -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 20:17:00 2015 From: report at bugs.python.org (Carol Willing) Date: Sun, 19 Apr 2015 18:17:00 +0000 Subject: [issue17227] devguide: buggy heading numbers In-Reply-To: <1361217002.34.0.936078305401.issue17227@psf.upfronthosting.co.za> Message-ID: <1429467420.69.0.271756204151.issue17227@psf.upfronthosting.co.za> Carol Willing added the comment: Berker, Thanks for the patch review. I'm going to work with the folks at Sphinx project this week to see if the headings are fixed in a newer Sphinx version. If so, I will make the change here. If not, I will follow your recommendation to close and create an issue on the Sphinx issue tracker. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 20:17:36 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 18:17:36 +0000 Subject: [issue24002] Add un-parse function to ast In-Reply-To: <1429421950.27.0.647153175832.issue24002@psf.upfronthosting.co.za> Message-ID: <1429467455.99.0.671827982242.issue24002@psf.upfronthosting.co.za> Larry Hastings added the comment: There is! compile() will do it, though the docstring doesn't mention it. (The full documentation does.) The following function meets both my use cases: def eval_ast_expr(node, symbols=None, *, filename='-'): """ Takes an ast.Expr node. Compiles and evaluates it. Returns the result of the expression. symbols represents the globals dict the expression should see. (There's no equivalent for "locals" here.) """ if not isinstance(node, ast.Expr): raise RuntimeError( "eval_ast_expr: node must be of type ast.Expr") if symbols == None: symbols = globals() a = ast.Expression(node.value) co = compile(a, filename, 'eval') fn = types.FunctionType(co, symbols) return fn() I am therefore closing this bug. It still seems like a nice-to-have but I'll let somebody else do it when *they* have a use case. ---------- resolution: -> later stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 20:18:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Apr 2015 18:18:29 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <1429467509.73.0.796549042357.issue24000@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: >> Doesn't always zeroes == length? > "zeroes" requires "length", but "length" does not require "zeroes". As it happens all the format units supported by str always have both parameters either True or False. But the Py_UNICODE converter accepts "length" for format units u# and Z#, and doesn't support "zeroes". "length=True" implies "zeroes=True" in the Py_UNICODE converter. "u" and "Z" don't allow null characters, "u#" and "Z#" allow null characters. "zeroes" doesn't add any information and isn't needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 20:21:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Apr 2015 18:21:22 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <1429467682.65.0.934008246092.issue24000@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > I disagree. My goal with Argument Clinic is that third-party developers will use it to write extensions. And we don't know how many extension modules are using es, es#, et, et#, s#, y#, z#, u#, and U#. I don't think we can remove any of this functionality until 4.0. But we can deprecate them sooner. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 20:28:19 2015 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Sun, 19 Apr 2015 18:28:19 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: Message-ID: Ionel Cristian M?rie? added the comment: On Sun, Apr 19, 2015 at 9:01 PM, Eric Snow wrote: > Finally, instead of changing callable, why not use a metaclass that does > the right thing? I believe MagicMock does something along those lines. > ?What would be the "right thing"? AFAIK this cannot be achieved with a metaclass, since the check in `callable` just does a dumb check for `x->ob_type->tp_call?`. Seriously, if you know a way to make `x->ob_type->tp_call?` run any python code please let me know :-) Thanks, -- Ionel Cristian M?rie?, http://blog.ionelmc.ro ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 20:30:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Apr 2015 18:30:50 +0000 Subject: [issue24007] Write PyArg_Parse* format in a line with a function Message-ID: <1429468247.73.0.580298527678.issue24007@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch makes Argument Clinic to output format argument of PyArg_Parse, PyArg_ParseTuple and PyArg_ParseTupleAndKeywords in a line with a function itself. First, this makes generated code more compact and easier to read and compare with old code. Second, it makes easier to grep sources for used format units. Format argument always (or almost always) is written in a line with a function. ---------- components: Argument Clinic, Demos and Tools files: clinic_format_argument.patch keywords: patch messages: 241531 nosy: larry, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Write PyArg_Parse* format in a line with a function type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file39121/clinic_format_argument.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 20:39:59 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 18:39:59 +0000 Subject: [issue24001] Clinic: use raw types in types= set In-Reply-To: <1429405577.22.0.134829799978.issue24001@psf.upfronthosting.co.za> Message-ID: <1429468799.05.0.548233717737.issue24001@psf.upfronthosting.co.za> Larry Hastings added the comment: Thanks to #24002 I now know how to write evalify_node properly. This revision of the patch is much better, and maybe ready for checkin. ---------- Added file: http://bugs.python.org/file39122/larry.one.more.clinic.format.unit.map.cleanup.2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 20:40:20 2015 From: report at bugs.python.org (Zachary Ware) Date: Sun, 19 Apr 2015 18:40:20 +0000 Subject: [issue24003] variable naming In-Reply-To: <1429436589.53.0.115033334607.issue24003@psf.upfronthosting.co.za> Message-ID: <1429468820.38.0.736954892887.issue24003@psf.upfronthosting.co.za> Changes by Zachary Ware : ---------- stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 20:42:40 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 18:42:40 +0000 Subject: [issue23967] Make inspect.signature expression evaluation more powerful In-Reply-To: <1429123957.6.0.780975142449.issue23967@psf.upfronthosting.co.za> Message-ID: <1429468960.24.0.952163823032.issue23967@psf.upfronthosting.co.za> Larry Hastings added the comment: Thanks to #24002 I now know how to write evalify_node properly. This patch is now much better. Note that I deliberately made the new function _eval_ast_expr() as a "private" module-level routine. I need that same functionality in Argument Clinic too, so if both patches are accepted I'll have Clinic switch to calling this version. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 20:43:06 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 18:43:06 +0000 Subject: [issue23967] Make inspect.signature expression evaluation more powerful In-Reply-To: <1429123957.6.0.780975142449.issue23967@psf.upfronthosting.co.za> Message-ID: <1429468986.74.0.318005272286.issue23967@psf.upfronthosting.co.za> Larry Hastings added the comment: Whoops. Here's the revised patch. ---------- Added file: http://bugs.python.org/file39123/larry.improved.signature.expressions.2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 20:48:05 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Apr 2015 18:48:05 +0000 Subject: [issue24001] Clinic: use raw types in types= set In-Reply-To: <1429405577.22.0.134829799978.issue24001@psf.upfronthosting.co.za> Message-ID: <1429469285.9.0.39901739923.issue24001@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Looks as this is a patch for different issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 20:52:51 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 18:52:51 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <1429469571.04.0.793434871484.issue24000@psf.upfronthosting.co.za> Larry Hastings added the comment: > "u#" and "Z#" allow null characters. Not according to the documentation. 'u' explicitly says it does not allow NUL characters. 'Z', 'u#', and 'Z#' all say they are "variants" of 'u' but never mention that they might allow NUL characters. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 20:53:57 2015 From: report at bugs.python.org (Anand Reddy Pandikunta) Date: Sun, 19 Apr 2015 18:53:57 +0000 Subject: [issue24008] inspect.getsource is failing for sys.excepthook Message-ID: <1429469637.6.0.278497450478.issue24008@psf.upfronthosting.co.za> New submission from Anand Reddy Pandikunta: >>> inspect.getsource(sys.excepthook) Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.7/inspect.py", line 701, in getsource lines, lnum = getsourcelines(object) File "/usr/local/lib/python2.7/inspect.py", line 690, in getsourcelines lines, lnum = findsource(object) File "/usr/local/lib/python2.7/inspect.py", line 526, in findsource file = getfile(object) File "/usr/local/lib/python2.7/inspect.py", line 420, in getfile 'function, traceback, frame, or code object'.format(object)) TypeError: is not a module, class, method, function, traceback, frame, or code object ---------- components: Library (Lib) files: trace4.py messages: 241537 nosy: ChillarAnand priority: normal severity: normal status: open title: inspect.getsource is failing for sys.excepthook versions: Python 2.7 Added file: http://bugs.python.org/file39124/trace4.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 20:57:41 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 18:57:41 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <1429469861.51.0.819872256581.issue24000@psf.upfronthosting.co.za> Larry Hastings added the comment: New diff based on Serhiy's latest round of comments. Thanks, Serhiy! You are inexhaustable! ---------- Added file: http://bugs.python.org/file39125/larry.one.more.clinic.format.unit.map.cleanup.3.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 20:57:45 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 19 Apr 2015 18:57:45 +0000 Subject: [issue18654] modernize mingw&cygwin compiler classes In-Reply-To: <1375621500.14.0.511859388859.issue18654@psf.upfronthosting.co.za> Message-ID: <1429469865.95.0.899688987349.issue18654@psf.upfronthosting.co.za> R. David Murray added the comment: Find someone from the packaging sig willing to review it, maybe? As in, get on that mailing list and ask. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:01:45 2015 From: report at bugs.python.org (Ethan Furman) Date: Sun, 19 Apr 2015 19:01:45 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429470105.31.0.0386692498501.issue23990@psf.upfronthosting.co.za> Ethan Furman added the comment: The "right thing", using a meta-class, is to have the meta-class check if the proxied object is callable, and if so, put in the __call__ function in the class that is being created. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:03:31 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 19 Apr 2015 19:03:31 +0000 Subject: [issue23994] argparse fails to detect program name when there is a slash at the end of the program's path In-Reply-To: <1429379283.39.0.0511547854084.issue23994@psf.upfronthosting.co.za> Message-ID: <1429470211.47.0.763282276691.issue23994@psf.upfronthosting.co.za> R. David Murray added the comment: Thanks for the patch. We'll want a unit test for the behavior before committing this. ---------- nosy: +r.david.murray stage: -> test needed versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:05:24 2015 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Sun, 19 Apr 2015 19:05:24 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429470105.31.0.0386692498501.issue23990@psf.upfronthosting.co.za> Message-ID: Ionel Cristian M?rie? added the comment: On Sun, Apr 19, 2015 at 10:01 PM, Ethan Furman wrote: > The "right thing", using a meta-class, is to have the meta-class check if > the proxied object is callable, and if so, put in the __call__ function in > the class that is being created. ?Yes indeed, for a plain proxy. Unfortunately for a *lazy* proxy this is not acceptable as it ?would "create" (or "access") the target. The point is to delay that till it's actually needed, not when the proxy is created. Thanks, -- Ionel Cristian M?rie?, http://blog.ionelmc.ro ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:06:09 2015 From: report at bugs.python.org (Riley Banks) Date: Sun, 19 Apr 2015 19:06:09 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1429470369.92.0.314053105919.issue22619@psf.upfronthosting.co.za> Changes by Riley Banks : ---------- nosy: +vaultah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:06:12 2015 From: report at bugs.python.org (Tim Golden) Date: Sun, 19 Apr 2015 19:06:12 +0000 Subject: [issue24005] Documentation Error: Extra line Break In-Reply-To: <1429439369.0.0.722585874502.issue24005@psf.upfronthosting.co.za> Message-ID: <1429470372.46.0.100362166674.issue24005@psf.upfronthosting.co.za> Tim Golden added the comment: One small thing to bear in mind is that the existing code (ie with the extra linefeed) raises an IndentationError if cut-and-pasted into the interactive interpreter; with the OP's change, it succeeds. Might not have been their intention, but certainly is the case. (Doesn't make it a bug, as such, but makes it more than a stylistic difference of opinion). ---------- nosy: +tim.golden _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:08:01 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sun, 19 Apr 2015 19:08:01 +0000 Subject: [issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values In-Reply-To: <1429231899.59.0.405315540238.issue23982@psf.upfronthosting.co.za> Message-ID: <1429470481.56.0.163249027365.issue23982@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The tkinter docs need to be expanded, but that is a different issue. The complete tcl/tk version is displayed in Idle -> Help -> About Idle using "self.tk.call('info', 'patchlevel')". Pending a reason not to, I would be in favor of adding this full info as a tkinter attribute (.version ?, .patch_level ?) in addition to the current .TclVersion and .TkVersion attributes (which are now always the same, though once probably not). This would be a new tracker issue. Adding the tcl/tk version included with the windows installer to the download web page seems reasonable to me. This would be a third issue, involving revision of PEP 101 on making releases. The first change would be the RM (Release Manager) getting the info from the WE (Windows Expert). This would go somewhere under "The WE then generates Windows installer files". Then somewhere under "Now it's time [for the RM] to twiddle the web site." would be something about inserting the tcl/tk version is a revised template page, or whatever. I leave it to you to look as the site for the specific page to revise and how, and to read this section of the PEP. Proposed PEP changes are usually sent to PEP editors. If you want to pursue this, you might first email Barry to see what he would prefer. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:13:08 2015 From: report at bugs.python.org (R. David Murray) Date: Sun, 19 Apr 2015 19:13:08 +0000 Subject: [issue24006] Multiprocessing fails when using functions defined in interactive interpreter. In-Reply-To: <1429464061.97.0.0459539459978.issue24006@psf.upfronthosting.co.za> Message-ID: <1429470788.18.0.0545244051063.issue24006@psf.upfronthosting.co.za> R. David Murray added the comment: I'm guessing you are on Windows. Please read https://docs.python.org/2/library/multiprocessing.html#windows. You can't do what you show on windows (though you can on unix, since it uses fork). ---------- nosy: +r.david.murray resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:14:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Apr 2015 19:14:44 +0000 Subject: [issue24009] Get rid of rare format units in PyArg_Parse* Message-ID: <1429470884.11.0.538472438707.issue24009@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: There are a lot of format units supported in PyArg_Parse* functions, but some of them are rarely or never used in current CPython code. Some of format units are legacy from Python 2 and are not needed in modern Python 3 code or can be replaced with custom converter. Here are results of grepping (not including Modules/_testcapimodule.c). "es", "es#", "et#", "z*", "Z#" are not used. "y#": Modules/_io/textio.c:2334: if (!PyArg_ParseTuple(_state, "y#i", &dec_buffer, &dec_buffer_len, &dec_flags)) { \ "z#": Modules/_ctypes/_ctypes.c:3327: if (!PyArg_ParseTuple(args, "is|Oz#", &index, &name, ¶mflags, &iid, &iid_len)) "u#": Modules/arraymodule.c:248: if (!PyArg_Parse(v, "u#;array item must be unicode character", &p, &len)) PC/winreg.c:1547: if (!PyArg_ParseTuple(args, "OZiu#:SetValue", "y": Modules/_io/textio.c:2334: if (!PyArg_ParseTuple(_state, "y#i", &dec_buffer, &dec_buffer_len, &dec_flags)) { \ Modules/_cursesmodule.c:2790: if (!PyArg_ParseTuple(args,"y;str", &str)) Modules/_cursesmodule.c:3026: if (!PyArg_ParseTuple(args, "y|iiiiiiiii:tparm", Modules/posixmodule.c:3767: if (!PyArg_ParseTuple (args, "y:_getfullpathname", Modules/posixmodule.c:3872: if (!PyArg_ParseTuple(args, "y:_isdir", &path)) Modules/faulthandler.c:941: if (!PyArg_ParseTuple(args, "y:fatal_error", &message)) "et": Modules/socketmodule.c:4499: if (!PyArg_ParseTuple(args, "et:gethostbyname", "idna", &name)) Modules/socketmodule.c:4667: if (!PyArg_ParseTuple(args, "et:gethostbyname_ex", "idna", &name)) Modules/socketmodule.c:4744: if (!PyArg_ParseTuple(args, "et:gethostbyaddr", "idna", &ip_num)) Modules/_tkinter.c:2099: if (!PyArg_ParseTuple(args, "et:splitlist", "utf-8", &list)) Modules/_tkinter.c:2162: if (!PyArg_ParseTuple(args, "et:split", "utf-8", &list)) Modules/_ssl.c:3038: if (!PyArg_ParseTupleAndKeywords(args, kwds, "O!iet:_wrap_socket", kwlist, Modules/_ssl.c:3070: if (!PyArg_Parse(hostname_obj, "et", "idna", &hostname)) "s*": Modules/_codecsmodule.c:188: if (!PyArg_ParseTuple(args, "s*|z:escape_decode", Modules/_codecsmodule.c:552: if (!PyArg_ParseTuple(args, "s*|z:unicode_escape_decode", Modules/_codecsmodule.c:569: if (!PyArg_ParseTuple(args, "s*|z:raw_unicode_escape_decode", Modules/_codecsmodule.c:696: if (!PyArg_ParseTuple(args, "s*|z:readbuffer_encode", Modules/_ssl.c:3734: if (!PyArg_ParseTuple(args, "s*d:RAND_add", &view, &entropy)) Modules/fcntlmodule.c:225: if (PyArg_Parse(ob_arg, "s*:ioctl", &pstr)) { Modules/clinic/arraymodule.c.h:278: if (!PyArg_Parse(arg, "s*:fromstring", &buffer)) "s#": Modules/_gdbmmodule.c:128: if (!PyArg_Parse(key, "s#", &krec.dptr, &krec.dsize) ) Modules/_gdbmmodule.c:176: if (!PyArg_Parse(v, "s#", &krec.dptr, &krec.dsize) ) { Modules/_gdbmmodule.c:194: if (!PyArg_Parse(w, "s#", &drec.dptr, &drec.dsize)) { Modules/fcntlmodule.c:71: if (PyArg_Parse(arg, "s#", &str, &len)) { Modules/_ctypes/_ctypes.c:2569: if (!PyArg_ParseTuple(args, "Os#", &dict, &data, &len)) Modules/clinic/unicodedata.c.h:361: if (!PyArg_Parse(arg, "s#:lookup", &name, &name_length)) Modules/clinic/_dbmmodule.c.h:62: if (!PyArg_ParseTuple(args, "s#|O:get", Modules/clinic/_dbmmodule.c.h:95: if (!PyArg_ParseTuple(args, "s#|O:setdefault", Modules/clinic/_gdbmmodule.c.h:150: if (!PyArg_Parse(arg, "s#:nextkey", &key, &key_length)) Modules/_dbmmodule.c:108: if (!PyArg_Parse(key, "s#", &krec.dptr, &tmp_size) ) Modules/_dbmmodule.c:132: if ( !PyArg_Parse(v, "s#", &krec.dptr, &tmp_size) ) { Modules/_dbmmodule.c:150: if ( !PyArg_Parse(w, "s#", &drec.dptr, &tmp_size) ) { Modules/_dbmmodule.c:336: if ( !PyArg_Parse(default_value, "s#", &val.dptr, &tmp_size) ) { In future may be we could deprecate some format units and remove them in 4.0. This issue is a meta issue. Every case should be considered individually. ---------- assignee: serhiy.storchaka components: Interpreter Core messages: 241546 nosy: serhiy.storchaka priority: low severity: normal status: open title: Get rid of rare format units in PyArg_Parse* type: enhancement versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:15:52 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 19 Apr 2015 19:15:52 +0000 Subject: [issue23998] PyImport_ReInitLock() doesn't check for allocation error In-Reply-To: <1429396955.07.0.854315130889.issue23998@psf.upfronthosting.co.za> Message-ID: <20150419191549.6605.36807@psf.io> Roundup Robot added the comment: New changeset d70995cf44b3 by Christian Heimes in branch '2.7': Issue #23998: PyImport_ReInitLock() now checks for lock allocation error https://hg.python.org/cpython/rev/d70995cf44b3 New changeset 7d7bf5c34d7e by Christian Heimes in branch '3.3': Issue #23998: PyImport_ReInitLock() now checks for lock allocation error https://hg.python.org/cpython/rev/7d7bf5c34d7e New changeset e0bd083fc9c1 by Christian Heimes in branch '3.4': Issue #23998: PyImport_ReInitLock() now checks for lock allocation error https://hg.python.org/cpython/rev/e0bd083fc9c1 New changeset 7ae8fd62d743 by Christian Heimes in branch 'default': Issue #23998: PyImport_ReInitLock() now checks for lock allocation error https://hg.python.org/cpython/rev/7ae8fd62d743 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:17:00 2015 From: report at bugs.python.org (Claudiu Popa) Date: Sun, 19 Apr 2015 19:17:00 +0000 Subject: [issue24008] inspect.getsource is failing for sys.excepthook In-Reply-To: <1429469637.6.0.278497450478.issue24008@psf.upfronthosting.co.za> Message-ID: <1429471020.84.0.392344667217.issue24008@psf.upfronthosting.co.za> Claudiu Popa added the comment: That's actually expected, since sys.excepthook is a builtin, so there's no source code to be retrieved (the same holds for other builtins, such as next, range etc). ---------- nosy: +Claudiu.Popa resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:21:52 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 19 Apr 2015 19:21:52 +0000 Subject: [issue24003] variable naming In-Reply-To: <1429436589.53.0.115033334607.issue24003@psf.upfronthosting.co.za> Message-ID: <1429471312.35.0.0356917480889.issue24003@psf.upfronthosting.co.za> Ned Deily added the comment: (... and is documented in The Python 3 and 2 Language Reference manuals: https://docs.python.org/3/reference/lexical_analysis.html#keywords and https://docs.python.org/2/reference/lexical_analysis.html#keywords) ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:22:28 2015 From: report at bugs.python.org (Claudiu Popa) Date: Sun, 19 Apr 2015 19:22:28 +0000 Subject: [issue23701] Drop extraneous comment from winreg.QueryValue's docstring In-Reply-To: <1426697470.53.0.824194712699.issue23701@psf.upfronthosting.co.za> Message-ID: <1429471348.57.0.87411061263.issue23701@psf.upfronthosting.co.za> Changes by Claudiu Popa : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:23:32 2015 From: report at bugs.python.org (Claudiu Popa) Date: Sun, 19 Apr 2015 19:23:32 +0000 Subject: [issue21574] Port image types detections from PIL to the imghdr module In-Reply-To: <1401010621.11.0.919611847501.issue21574@psf.upfronthosting.co.za> Message-ID: <1429471412.09.0.468824923186.issue21574@psf.upfronthosting.co.za> Changes by Claudiu Popa : ---------- stage: needs patch -> test needed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:26:39 2015 From: report at bugs.python.org (Christian Heimes) Date: Sun, 19 Apr 2015 19:26:39 +0000 Subject: [issue24010] Add error checks to PyInit__locale() Message-ID: <1429471599.85.0.679825670624.issue24010@psf.upfronthosting.co.za> New submission from Christian Heimes: The init function of the locale module fails to check for errors in a couple of places. The patch replaces PyDict_SetItemString() calls with PyModule_AddIntMacro() and error checks. An exception is unlikely so I'm OK when the patch just lands in 3.4 and 3.5. CID 1295027 (#8 of 8): Dereference null return value (NULL_RETURNS) dereference: Dereferencing a pointer that might be null x when calling PyDict_SetItemString ---------- components: Extension Modules files: localemodule.patch keywords: patch messages: 241550 nosy: christian.heimes, lemburg, loewis priority: normal severity: normal stage: patch review status: open title: Add error checks to PyInit__locale() type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39126/localemodule.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:28:15 2015 From: report at bugs.python.org (Christian Heimes) Date: Sun, 19 Apr 2015 19:28:15 +0000 Subject: [issue24011] Add error checks to PyInit_signal() Message-ID: <1429471695.96.0.523863138973.issue24011@psf.upfronthosting.co.za> New submission from Christian Heimes: The init function of the signal module fails to check for errors in a couple of places. The patch replaces PyDict_SetItemString() calls with PyModule_AddIntMacro() and error checks. An exception is unlikely so I'm OK when the patch just lands in 3.4 and 3.5. CID 1295026 (#41 of 41): Dereference null return value (NULL_RETURNS) dereference: Dereferencing a pointer that might be null x when calling PyDict_SetItemString ---------- components: Extension Modules files: signalmodule.patch keywords: patch messages: 241551 nosy: christian.heimes priority: normal severity: normal stage: patch review status: open title: Add error checks to PyInit_signal() type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39127/signalmodule.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:28:31 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 19:28:31 +0000 Subject: [issue24001] Clinic: use raw types in types= set In-Reply-To: <1429405577.22.0.134829799978.issue24001@psf.upfronthosting.co.za> Message-ID: <1429471711.84.0.866596691637.issue24001@psf.upfronthosting.co.za> Larry Hastings added the comment: Whoops. I'll fix that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:28:38 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 19:28:38 +0000 Subject: [issue24001] Clinic: use raw types in types= set In-Reply-To: <1429405577.22.0.134829799978.issue24001@psf.upfronthosting.co.za> Message-ID: <1429471718.33.0.526877545799.issue24001@psf.upfronthosting.co.za> Changes by Larry Hastings : Removed file: http://bugs.python.org/file39122/larry.one.more.clinic.format.unit.map.cleanup.2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:29:11 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 19:29:11 +0000 Subject: [issue24001] Clinic: use raw types in types= set In-Reply-To: <1429405577.22.0.134829799978.issue24001@psf.upfronthosting.co.za> Message-ID: <1429471751.3.0.137209563747.issue24001@psf.upfronthosting.co.za> Larry Hastings added the comment: Here's the right patch. ---------- Added file: http://bugs.python.org/file39128/larry.clinic.use.raw.types.2.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:29:33 2015 From: report at bugs.python.org (Steven D'Aprano) Date: Sun, 19 Apr 2015 19:29:33 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429471773.69.0.137724983311.issue23990@psf.upfronthosting.co.za> Steven D'Aprano added the comment: This bug report seems to be completely based on a false premise. In the very first message of this issue, Ionel says: "it return True even if __call__ is actually an descriptor that raise AttributeError (clearly not callable at all)." but that is wrong. It *is* callable, and callable() is correct to return True. If you look at the stack trace, the __call__ method (function/property, whatever you want to call it) is called, and it raises an exception. That is no different from any other method or function that raises an exception. It is wrong to think that raising AttributeError *inside* __call__ makes the object non-callable. Ionel, I raised these issues on Python-list here: https://mail.python.org/pipermail/python-ideas/2015-April/033078.html but you haven't responded to them. ---------- nosy: +steven.daprano _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:33:15 2015 From: report at bugs.python.org (Christian Heimes) Date: Sun, 19 Apr 2015 19:33:15 +0000 Subject: [issue24012] Add error checks to PyInit_pyexpat() Message-ID: <1429471995.2.0.707709004529.issue24012@psf.upfronthosting.co.za> New submission from Christian Heimes: Similar to #24011 and #24010 the pyexpat module's init function fails to check some return values for NULL. The patch doesn't include proper reference cleanups as most of the other parts of PyInit_pyexpat() don't cleanup on error, too. CID 982779 (#2 of 2): Dereference null return value (NULL_RETURNS) dereference: Dereferencing a pointer that might be null sys_modules when calling PyDict_SetItem CID 982240 (#2 of 2): Unchecked return value (CHECKED_RETURN) check_return: Calling PyDict_SetItem without checking return value (as is done elsewhere 158 out of 174 times) ---------- components: Extension Modules files: pyexpat.patch keywords: patch messages: 241555 nosy: christian.heimes, eli.bendersky, scoder priority: normal severity: normal stage: patch review status: open title: Add error checks to PyInit_pyexpat() type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39129/pyexpat.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:36:24 2015 From: report at bugs.python.org (Carol Willing) Date: Sun, 19 Apr 2015 19:36:24 +0000 Subject: [issue24005] Documentation Error: Extra line Break In-Reply-To: <1429439369.0.0.722585874502.issue24005@psf.upfronthosting.co.za> Message-ID: <1429472184.93.0.952396992717.issue24005@psf.upfronthosting.co.za> Carol Willing added the comment: Tim, A good point re: the interpreter. I've attached an output from IPython interpreter. Georg, Given Tim's additional insight, I'm inclined to reopen the issue and review the patch as a positive change. Though not a bug, but as an enhancement for learners to copy-paste doc code into an interpreter. Thoughts? ---------- Added file: http://bugs.python.org/file39130/Screen Shot 2015-04-19 at 12.19.07 PM.png _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:36:33 2015 From: report at bugs.python.org (Joe Jevnik) Date: Sun, 19 Apr 2015 19:36:33 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429472193.96.0.819314098402.issue23990@psf.upfronthosting.co.za> Joe Jevnik added the comment: This is a different case from raising an AttributeError inside the __call__; >>> class C(object): ... def __call__(self): ... raise AttributeError() ... >>> hasattr(C(), '__call__') True >>> class D(object): ... @property ... def __call__(self): ... raise AttributeError() ... >>> hasattr(C(), '__call__') False AttributeError was picked very intentionally for the example. The docs show that n(args) == n.__call__(args) if n has a __call__; however, if a property raises an AttributeError, then it really does not have a __call__. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:39:30 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Apr 2015 19:39:30 +0000 Subject: [issue24000] More fixes for the Clinic mapping of converters to format units In-Reply-To: <1429405233.93.0.203198864557.issue24000@psf.upfronthosting.co.za> Message-ID: <1429472370.35.0.81191626245.issue24000@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > Not according to the documentation. 'u' explicitly says it does not allow NUL characters. 'Z', 'u#', and 'Z#' all say they are "variants" of 'u' but never mention that they might allow NUL characters. I understand the note in "u" description as explicitly saying that "u#" allows null characters. The documentation for format units needs an update for other reasons and there is an issue with ready patch for this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 21:55:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sun, 19 Apr 2015 19:55:36 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1429473336.89.0.30838346893.issue22619@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Needed a documentation. I'm not interested in writing it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 22:01:51 2015 From: report at bugs.python.org (Ben Hoyt) Date: Sun, 19 Apr 2015 20:01:51 +0000 Subject: [issue24013] Improve os.scandir() and DirEntry documentation Message-ID: <1429473711.62.0.571757122461.issue24013@psf.upfronthosting.co.za> New submission from Ben Hoyt: Victor Stinner's documentation for os.scandir and DirEntry is a great start (https://docs.python.org/dev/library/os.html#os.scandir), however there are a few mistakes in it, and a few ways I think it could be improved. Attaching a patch with the following overall changes: 1. Tweak the "see also" note on os.listdir() to mention *why* you'd want to use scandir -- namely that it includes file attribute info, and performance. 2. Move that str/bytes note in the scandir() docs down a bit, as I think that's really a detail and the other stuff is more important. 3. More details on why you'd want to use scandir -- to "increase the performance of code that also needs file type or file" -- and be more specific about what system calls are and are not required. 4. Replace "POSIX" with "Unix", per the rest of the os module docs when talking about generic Unix-like operating systems. It seems "POSIX" is used specifically when talking about the POSIX standard. 5. Remove half-true statement in DirEntry docs, "if a file is deleted between calling scandir and stat, a FileNotFoundError can be raised" -- but the method docs state that they specifically don't raise FileNotFoundError. 6. Removed "unfortunately, the behaviour of errors depends on the platform". This is always the case and doesn't add anything. 7. Tried to simplify and clarify the is_dir() and is_file() docs. Not sure I've succeeded here. This is hard! 8. Added "Availability: Unix, Windows." to scandir docs like listdir and most other os functions have. 9. Remove the see also about how "the listdir function returns the names of the directory entries" as that's already stated/implied above. ---------- assignee: docs at python components: Documentation files: scandir_doc_tweaks.patch keywords: patch messages: 241560 nosy: benhoyt, docs at python, haypo, serhiy.storchaka priority: normal severity: normal status: open title: Improve os.scandir() and DirEntry documentation versions: Python 3.5 Added file: http://bugs.python.org/file39131/scandir_doc_tweaks.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 22:10:55 2015 From: report at bugs.python.org (Claudiu Popa) Date: Sun, 19 Apr 2015 20:10:55 +0000 Subject: [issue23917] please fall back to sequential compilation when concurrent doesn't exist In-Reply-To: <1428792729.56.0.740382381475.issue23917@psf.upfronthosting.co.za> Message-ID: <1429474255.97.0.55464733348.issue23917@psf.upfronthosting.co.za> Claudiu Popa added the comment: Here's the patch. ---------- keywords: +patch stage: needs patch -> patch review Added file: http://bugs.python.org/file39132/issue23917.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 22:12:01 2015 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Sun, 19 Apr 2015 20:12:01 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429471773.69.0.137724983311.issue23990@psf.upfronthosting.co.za> Message-ID: Ionel Cristian M?rie? added the comment: On Sun, Apr 19, 2015 at 10:29 PM, Steven D'Aprano wrote: > This bug report seems to be completely based on a false premise. In the > very first message of this issue, Ionel says: > > "it return True even if __call__ is actually an descriptor that raise > AttributeError (clearly not callable at all)." > > but that is wrong. It *is* callable, and callable() is correct to return > True. If you look at the stack trace, the __call__ method > (function/property, whatever you want to call it) is called, and it raises > an exception. That is no different from any other method or function that > raises an exception. > > It is wrong to think that raising AttributeError *inside* __call__ makes > the object non-callable. > > Ionel, I raised these issues on Python-list here: > > https://mail.python.org/pipermail/python-ideas/2015-April/033078.html > > but you haven't responded to them. I was hoping my other replies had addressed those issues. Note that the presence of __call__ on the callstack is merely an artefact of how @property works, and it's not actually the __call__ method (it's just something that property.__get__ calls). Here's an example that hopefully illustrates the issue more clearly: >>> class CallDescriptor: ... def __get__(self, inst, owner): ... target = inst._get_target() ... if callable(target): ... return target ... else: ... raise AttributeError('not callable') ... >>> class LazyProxy: ... __call__ = CallDescriptor() ... def __init__(self, get_target): ... self._get_target = get_target ... >>> def create_stuff(): ... # heavy computation here ... print("Doing heavey computation!!!!") ... return 1, 2, 3 ... >>> proxy = LazyProxy(create_stuff) >>> callable(proxy) ################### this should be false! True >>> hasattr(proxy, '__call__') Doing heavey computation!!!! False >>> >>> def create_callable_stuff(): ... # heavy computation here ... print("Doing heavey computation!!!!") ... def foobar(): ... pass ... return foobar ... >>> proxy = LazyProxy(create_callable_stuff) >>> callable(proxy) True >>> hasattr(proxy, '__call__') Doing heavey computation!!!! True? Now it appears there's a second issue, slightly related - if you actually call the proxy object AttributeError is raised (instead of the TypeError): >>> proxy = LazyProxy(create_stuff) >>> callable(proxy) True >>> hasattr(proxy, '__call__') Doing heavey computation!!!! False >>> proxy() Doing heavey computation!!!! Traceback (most recent call last): File "", line 1, in File "", line 7, in __get__ AttributeError: not callable >>> >>> target = create_stuff() Doing heavey computation!!!! >>> target() Traceback (most recent call last): File "", line 1, in TypeError: 'tuple' object is not callable Contrast that to how iter works - if the descriptor raise AttributeError then iter raises TypeError (as expected): >>> class IterDescriptor: ... def __get__(self, inst, owner): ... target = inst._get_target() ... if hasattr(type(target), '__iter__') and hasattr(target, '__iter__'): ... return target.__iter__ ... else: ... raise AttributeError('not iterable') ... >>> class LazyProxy: ... __iter__ = IterDescriptor() ... def __init__(self, get_target): ... self._get_target = get_target ... >>> def create_iterable_stuff(): ... # heavy computation here ... print("Doing heavey computation!!!!") ... return 1, 2, 3 ... >>> proxy = LazyProxy(create_iterable_stuff) >>> iter(proxy) Doing heavey computation!!!! >>> >>> def create_noniterable_stuff(): ... # heavy computation here ... print("Doing heavey computation!!!!") ... def foobar(): ... pass ... return foobar ... >>> proxy = LazyProxy(create_noniterable_stuff) >>> iter(proxy) Doing heavey computation!!!! Traceback (most recent call last): File "", line 1, in TypeError: 'LazyProxy' object is not iterable >>> >>> proxy.__iter__ Doing heavey computation!!!! Traceback (most recent call last): File "", line 1, in File "", line 7, in __get__ AttributeError: not iterable ? ?So this is why I'm bringing this up. If `iter` wouldn't handle it like that then I'd think that maybe this is the intended behaviour.? ? I hope the blatant inconsistency is more clear? ? now? ?, and you'll understand that this bug report is not just some flagrant misunderstanding of how __call__ works. To sum this up, the root of this issue is that `callable` doesn't do all the checks that are done right before actually performing the call (like the descriptor handling). It's like calling your doctor for an appointment where the secretary schedules you, but forgets to check if the doctor is in vacation or not. Thanks, -- Ionel Cristian M?rie?, http://blog.ionelmc.ro ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 22:22:54 2015 From: report at bugs.python.org (Claudiu Popa) Date: Sun, 19 Apr 2015 20:22:54 +0000 Subject: [issue22080] Add windows_helper module helper In-Reply-To: <1406378373.46.0.337360125553.issue22080@psf.upfronthosting.co.za> Message-ID: <1429474974.33.0.2865912397.issue22080@psf.upfronthosting.co.za> Claudiu Popa added the comment: The latest patch drops the symlink check, since it can be added later. ---------- Added file: http://bugs.python.org/file39133/issue22080_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 22:30:44 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 19 Apr 2015 20:30:44 +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: <1429475444.98.0.646000244311.issue23993@psf.upfronthosting.co.za> STINNER Victor added the comment: Related issues and discussions: - [Python-Dev] open(): set the default encoding to 'utf-8' in Python 3.3? https://mail.python.org/pipermail/python-dev/2011-June/112086.html - Issue #12451: open: avoid the locale encoding when possible https://bugs.python.org/issue12451 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 23:06:52 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Sun, 19 Apr 2015 21:06:52 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1429477612.61.0.837684492563.issue22619@psf.upfronthosting.co.za> Dmitry Kazakov added the comment: I'll do that tomorrow. The patch still needs a review though... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 23:14:11 2015 From: report at bugs.python.org (Martin Falatic) Date: Sun, 19 Apr 2015 21:14:11 +0000 Subject: [issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values In-Reply-To: <1429231899.59.0.405315540238.issue23982@psf.upfronthosting.co.za> Message-ID: <1429478051.01.0.163148337353.issue23982@psf.upfronthosting.co.za> Martin Falatic added the comment: Thank you. Before going down the road of revising PEP 101 (which appears to be very non-trivial despite the simple (and certainly always present) data involved), I'd like to know: is version information about the pre-compiled Windows binaries (of which this is one) already being captured anywhere else publically visible on a per-release or per-build basis? It's useful that such binaries exist given Windows' unique requirements versus other systems, but are these binaries themselves documented anywhere as they are updated (e.g., how to re-create them)? Such a source of truth would simplify that revision request. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 23:27:41 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 19 Apr 2015 21:27:41 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429478861.42.0.870797268079.issue23990@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 19 23:59:38 2015 From: report at bugs.python.org (Larry Hastings) Date: Sun, 19 Apr 2015 21:59:38 +0000 Subject: [issue24007] Write PyArg_Parse* format in a line with a function In-Reply-To: <1429468247.73.0.580298527678.issue24007@psf.upfronthosting.co.za> Message-ID: <1429480778.16.0.424263515683.issue24007@psf.upfronthosting.co.za> Larry Hastings added the comment: I don't care about this, but the patch looks fine. If this really helps then LGTM. Please hold off checking this in until after 3.5.0 alpha 4 is released. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 00:09:14 2015 From: report at bugs.python.org (Eric Snow) Date: Sun, 19 Apr 2015 22:09:14 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429481354.53.0.699988464718.issue23990@psf.upfronthosting.co.za> Eric Snow added the comment: > What would be the "right thing"? My suggestion of using a metaclass is actually not effective here because __call__ has meaning for metaclasses. Otherwise you could have made __call__ more dynamic via a metaclass. Except that is another reason why my suggestion is incorrect. What you are asking for is that, effectively, the state of the instance might be able to impact the resolution of special methods of a class. So a metaclass approach would not have helped since the instance would not have been involved in the lookup. Regardless, this makes it more clear to me what you are trying to accomplish for the sake of a proxy type. The question is, should an instance be able to influence the resolution of special methods that are called on its behalf? Before answering that, consider why methods that are special to the interpreter get treated differently. The language specifies that rather than using obj.__getattribute__ to look up special methods, they are effectively located in type(obj).__dict__. They likewise are not looked up on obj.__class__.__dict__. Here are the key reasons why this matters: * speed * the special methods will still be available even if the class implements its own __getattribute__ Once the methods are looked up, the descriptor protocol is invoked, if applicable. However, it does not fall back to obj.__getattr__. See Objects/typeobject.c:_PyObject_LookupSpecial. So ultimately the descriptor protocol allows instances to have a say in both the existence and the behavior of special methods. However, I think that the former is unfortunate since it obviously muddies the water here. I doubt it was intentional. Back to the question, should instances be allowed to influence the *lookup* of special methods? Your request is that they should be and consistently. As noted, the interpreter already uses the equivalent of the following when looking up special methods: def _PyObject_LookupSpecial(obj, name): attr = inspect.getattr_static(obj, name) try: f = inspect.getattr_static(attr, '__get__') except AttributeError: return attr else: return f(attr, obj, type(obj)) What you are asking is that callable should do this too, rather than skipping the descriptor part). I expect the same would need to be done for any other helper that also checks for "special" capability. For example, see the various __subclasshook__ implementations in Lib/_collections_abc.py. We should be consistent about it if we are going to do it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 00:10:25 2015 From: report at bugs.python.org (Eric Snow) Date: Sun, 19 Apr 2015 22:10:25 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429481425.17.0.10192639604.issue23990@psf.upfronthosting.co.za> Eric Snow added the comment: Just to be clear, I'm still -1 on any of this. On the one hand, there's a risk of backward-compatibility breakage (just as much a corner-case as the need expressed in this issue). On the other hand, I'd actually push for _PyObject_LookupSpecial to be fixed to chain AttributeError coming from a descriptor into a TypeError. Allowing instances to determine the capability of a class feels wrong and potentially broken. Furthermore, doing so via AttributeError is problematic since it may mask an AttributeError that bubbles up (which is very confusing and hard to debug). I've been bitten by this with pickle. Still, it may be a good idea to expose _PyObject_LookupSpecial via the inspect module, but that should be addressed in a separate issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 00:12:50 2015 From: report at bugs.python.org (Eric Snow) Date: Sun, 19 Apr 2015 22:12:50 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429481570.11.0.824499894497.issue23990@psf.upfronthosting.co.za> Eric Snow added the comment: s/TypeError/RuntimeError/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 00:33:20 2015 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Sun, 19 Apr 2015 22:33:20 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429482800.41.0.250569382101.issue23990@psf.upfronthosting.co.za> Ionel Cristian M?rie? added the comment: I want to address the four main points of criticism in fixing this issue, just in case it's not clear why I think those lines of thought are wrong: #1. "It's specified/documented, therefore it's intended" The first thing a maintainer does is check the docs. This is a sensible thing to do - as you cannot have all the details in your hear. The main question at that point: "is it really like that?". However, it's easy to miss the fact that the documentation explains an implementation issue (`callable` is not really reliable, blablabla), and not the intent of `callable`. I mean, the name is pretty clear on what it's supposed to do: "is the object callable or not?" - simple as that. If the intent of `callable` is being unreliable then maybe we should just rename it to `maybe_callable` or `unreliable_callable`, or maybe even "crappy_callable_we_dont_want_to_fix". #2. "But the call could fail anyway, so what's the point of fixing this?" The problem with this argument is that it's the same argument people bring up to remove the `callable` builtin. The problem is that you wouldn't use `callable` at all if you can just try/call/except. So this argument is not pertinent to the problem at hand (`callable` doing incomplete checks). #3. "But it's going to be too slow!" I don't want to be mean here, but this is just FUD. Lets measure this first. Is there really a measurable and significant performance impact on major applications? Does the argument even make sense in theory? A function call is pretty expensive in python, a mere attribute lookup wouldn't increase the cost by an order of magnitude (like 10x), would it? > py -3 -mtimeit -s "def foo(): pass" "foo.__call__" 10000000 loops, best of 3: 0.0585 usec per loop > py -3 -mtimeit -s "def foo(): pass" "callable(foo)" 10000000 loops, best of 3: 0.0392 usec per loop Is this a significant margin? Also, I'm pretty sure those numbers can be improved. Python 3 regressed performance in various aspects (and improved other things, of course), why would this be a roadblock now? #4. "It's too tricky, and I had a bad time with pickle one time ago", or: Exception masking issues This is certainly a problem, but it's not a new problem. There are already dozens of places where AttributeError is masked into something else (like a TypeError, or just a different result). Were do we draw the line here? Do we want to eventually get rid of all exception masking in an eventual Python 4.0 - what's the overarching goal here? Or is this just one of the many quirks of Python? What's worse - a quirk or a inconsistent quirk? The problem with this argument is that it attacks a different problem, that's just being made more visible if and when this problem of `callable` is fixed. Lets consider this strawman here: if a an user writes code like this: try: do important stuff except: pass # have fun debugging, haha who's at fault here? Is it the user that wrote that debugging black hole or is it python for letting the user do things like that? I don't think it's reasonable for Python to prevent exception masking bugs if the user was brave enough to write a descriptor. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 00:44:02 2015 From: report at bugs.python.org (Mark Lawrence) Date: Sun, 19 Apr 2015 22:44:02 +0000 Subject: [issue12712] weave build_tools library identification In-Reply-To: <1312822380.43.0.720864294913.issue12712@psf.upfronthosting.co.za> Message-ID: <1429483442.12.0.889200723887.issue12712@psf.upfronthosting.co.za> Mark Lawrence added the comment: Is case sensitivity still an issue on Windows? I've tried searching but there are so many issues referring to case sensitivity that I got swamped. ---------- components: +Windows nosy: +BreamoreBoy, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 01:53:27 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 19 Apr 2015 23:53:27 +0000 Subject: [issue8706] accept keyword arguments on most base type methods and builtins In-Reply-To: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za> Message-ID: <1429487607.75.0.88920052386.issue8706@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- components: +Extension Modules, Interpreter Core nosy: +berker.peksag versions: +Python 3.5 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 01:59:17 2015 From: report at bugs.python.org (Eric Snow) Date: Sun, 19 Apr 2015 23:59:17 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429482800.41.0.250569382101.issue23990@psf.upfronthosting.co.za> Message-ID: Eric Snow added the comment: > Ionel Cristian M?rie? added the comment: > #1. "It's specified/documented, therefore it's intended" > > The first thing a maintainer does is check the docs. This is a sensible thing to do - as you cannot have all the details in your hear. The main question at that point: "is it really like that?". > > However, it's easy to miss the fact that the documentation explains an implementation issue (`callable` is not really reliable, blablabla), and not the intent of `callable`. > > I mean, the name is pretty clear on what it's supposed to do: "is the object callable or not?" - simple as that. If the intent of `callable` is being unreliable then maybe we should just rename it to `maybe_callable` or `unreliable_callable`, or maybe even "crappy_callable_we_dont_want_to_fix". "callable" refers to the compatibility of the object with the call syntax - simple as that. The call syntax is turned into a special lookup for "__call__" that explicitly skips lookup on the instance (in CPython it is a call to _PyObject_LookupSpecial) and then a call on the resulting value. You are correct that callable does not do the descriptor part of that lookup. However, that is consistent across Python and has been this way for a long time (so there are backward compatibility concerns that cannot be ignored). > > #2. "But the call could fail anyway, so what's the point of fixing this?" You are correct that the availability of __call__ is the only relevant issue here. > > #3. "But it's going to be too slow!" > > I don't want to be mean here, but this is just FUD. Lets measure this first. Is there really a measurable and significant performance impact on major applications? It's not just applications. Grep for "PyCallable_Check" in the CPython code base. > > Does the argument even make sense in theory? A function call is pretty expensive in python, a mere attribute lookup wouldn't increase the cost by an order of magnitude (like 10x), would it? A "mere attribute lookup" involves invoking the descriptor protocol. This would add a discernible performance impact and the possibility of running arbitrary code for the sake of a rare corner case. The overall impact would be small, especially considering the use of PyCallable_Check in the CPython code base, but do not assume it would be insignificant. > Python 3 regressed performance in various aspects (and improved other things, of course), why would this be a roadblock now? My apology for being so blunt, but that's a terrible rationale! Let's make it better not worse. > > #4. "It's too tricky, and I had a bad time with pickle one time ago", or: Exception masking issues > > This is certainly a problem, but it's not a new problem. There are already dozens of places where AttributeError is masked into something else (like a TypeError, or just a different result). It not a problem currently for callable. It is one you are proposing to introduce. It is one which current users of callable don't have to worry about. > > Were do we draw the line here? We don't add to the problem. Instead, we work to decrease it. > Do we want to eventually get rid of all exception masking in an eventual Python 4.0 - what's the overarching goal here? Or is this just one of the many quirks of Python? > > What's worse - a quirk or a inconsistent quirk? What's the quirk here? I'd argue that the quirk is that special method lookup (_PyObject_LookupSpecial) doesn't turn AttributeError from a getter into RuntimeError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 02:16:11 2015 From: report at bugs.python.org (Cyd Haselton) Date: Mon, 20 Apr 2015 00:16:11 +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: <1429488971.2.0.0548341115539.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Ryan, Found the missing fix. In ./Programs/python.c #ifndef __ANDROID__ oldloc = _PyMem_RawStrdup(setlocale(LC_ALL, NULL)); if (!oldloc) { fprintf(stderr, "out of memory\n"); return 1; } #endif Added the #ifndef __ANDROID__ #endif around lines 46-51 I'm now looking at the following syntax error: File "./setup.py", line 1950 elif host_platform.startswith('arm-linux') ^ SyntaxError: invalid syntax make: *** [sharedmods] Error 1 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 02:25:06 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 20 Apr 2015 00:25:06 +0000 Subject: [issue24005] Documentation Error: Extra line Break In-Reply-To: <1429439369.0.0.722585874502.issue24005@psf.upfronthosting.co.za> Message-ID: <1429489506.74.0.51750626217.issue24005@psf.upfronthosting.co.za> Berker Peksag added the comment: That document is 10 years old :) I don't think it's worth to change now. Also, "what's new" documents shouldn't be used as a tutorial. There are many tutorials about writing decorators on the internet. (Thanks for the report and the patch, Jaivish) ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 02:25:24 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Mon, 20 Apr 2015 00:25:24 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1429488971.2.0.0548341115539.issue23496@psf.upfronthosting.co.za> Message-ID: Ryan Gonzalez added the comment: On Sun, Apr 19, 2015 at 7:16 PM, Cyd Haselton wrote: > > Cyd Haselton added the comment: > > Ryan, > Found the missing fix. > > In ./Programs/python.c > > #ifndef __ANDROID__ > oldloc = _PyMem_RawStrdup(setlocale(LC_ALL, NULL)); > if (!oldloc) { > fprintf(stderr, "out of memory\n"); > return 1; > } > #endif > > Added the #ifndef __ANDROID__ #endif around lines 46-51 > > ...that was in android_segfault_fix.patch... are you sure you're on the same commit as I am? > I'm now looking at the following syntax error: > > File "./setup.py", line 1950 > elif host_platform.startswith('arm-linux') > ^ > SyntaxError: invalid syntax > make: *** [sharedmods] Error 1 > > I forgot to put a colon and the end of the line. I'll upload a fixed "kbox_fixes.patch". > ---------- > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 02:26:20 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Mon, 20 Apr 2015 00:26:20 +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: <1429489580.32.0.910792521301.issue23496@psf.upfronthosting.co.za> Changes by Ryan Gonzalez : Added file: http://bugs.python.org/file39134/kbox_fix.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 02:30:44 2015 From: report at bugs.python.org (Cyd Haselton) Date: Mon, 20 Apr 2015 00:30:44 +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: <1429489844.59.0.899023602053.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Patch for python.c that prevents segfault on Android ---------- Added file: http://bugs.python.org/file39135/python.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 02:39:19 2015 From: report at bugs.python.org (Cyd Haselton) Date: Mon, 20 Apr 2015 00:39:19 +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: <1429490359.41.0.86056469054.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Ryan, That fix is in the android_segfault patch, but it's for frozenmain.c not python.c I cloned from master on Fri/Sat. Will double-check commit tomorrow but I think the problem is with the unpatched python.c ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 02:40:05 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Mon, 20 Apr 2015 00:40:05 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1429490359.41.0.86056469054.issue23496@psf.upfronthosting.co.za> Message-ID: <1BA4B0B2-A96E-4D8C-9B43-2FC3BEAF8970@gmail.com> Ryan Gonzalez added the comment: That's the thing; my repo has no python.c! On April 19, 2015 7:39:19 PM CDT, Cyd Haselton wrote: > >Cyd Haselton added the comment: > >Ryan, >That fix is in the android_segfault patch, but it's for frozenmain.c >not python.c > >I cloned from master on Fri/Sat. Will double-check commit tomorrow but >I think the problem is with the unpatched python.c > >---------- > >_______________________________________ >Python tracker > >_______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 02:41:01 2015 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Mon, 20 Apr 2015 00:41:01 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: Message-ID: Ionel Cristian M?rie? added the comment: On Mon, Apr 20, 2015 at 2:59 AM, Eric Snow wrote: > However, that is consistent across Python and has been this > way for a long time (so there are backward compatibility concerns that > cannot be ignored). > ?It's not. Did you see the example with iter()/__iter__? It does convert the AttributeError into a TypeError.? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 02:50:15 2015 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Mon, 20 Apr 2015 00:50:15 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: Message-ID: Ionel Cristian M?rie? added the comment: On Mon, Apr 20, 2015 at 2:59 AM, Eric Snow wrote: > It not a problem currently for callable. It is one you are proposing > to introduce. It is one which current users of callable don't have to > worry about. > > > > > Were do we draw the line here? > > We don't add to the problem. Instead, we work to decrease it. > ?What exactly are you proposing? Getting rid of AttributeError masking? I'm talking about applying an old design decision (AttributeError masking)? in `callable`. Doesn't seem useful to talk about not having exception making unless you have a plan to remove that from other places (that's even harder than fixing `callable` IMO) just to fix this inconsistent handling in Python. Unless you think having inconsistent handling is OK. I do not think it's OK. There should be the same rules for attribute access everywhere. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 03:25:10 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 20 Apr 2015 01:25:10 +0000 Subject: [issue22468] Tarfile using fstat on GZip file object In-Reply-To: <1411462192.65.0.458428981621.issue22468@psf.upfronthosting.co.za> Message-ID: <1429493110.54.0.157522754466.issue22468@psf.upfronthosting.co.za> Martin Panter added the comment: I am posting a documentation patch which I hope should clarify that objects like GzipFile won?t work automatically with gettarinfo(). It also has other modifications to address Issue 21996 (name must be text) and help with Issue 22208 (clarify non-OS files won?t work). ---------- assignee: -> docs at python components: +Documentation keywords: +patch nosy: +docs at python stage: -> patch review versions: +Python 3.5 Added file: http://bugs.python.org/file39136/gettarinfo.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 03:27:29 2015 From: report at bugs.python.org (Ned Deily) Date: Mon, 20 Apr 2015 01:27:29 +0000 Subject: [issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values In-Reply-To: <1429231899.59.0.405315540238.issue23982@psf.upfronthosting.co.za> Message-ID: <1429493249.21.0.301764715591.issue23982@psf.upfronthosting.co.za> Ned Deily added the comment: I am im favor of adding documentation for the existing tkinter TclVerion and TkVersion attributes to the tkinter section of the Standard Library reference as well as documenting a form of tkinter.Tcl().call('info', 'patchlevel') and/or tkinter.Tk().call('info', 'patchlevel') to return the full patchlevel string. These spellings will work with every supported version of tkinter, Tcl, Tk, and platform. Note that, while Tcl and Tk do have independent patch level strings, Tcl and Tk should normally always be installed at the same patch level; AFAIK, they are always released simultaneously upstream and are intended to be installed together. If one were to add Tcl and Tk patchlevel attributes to tkinter, the code should be careful to dynamically get patchlevels via the equivalent of the above calls, and should not use the compile-time strings from Tcl/Tk include files tcl.h and tk.h, since on many platforms Tcl and Tk are installed as shared libraries and can be updated to a new patch level independently of the Python distribution. As far as documenting the exact version of Tcl/Tk used in building the Python provided by a python.org Windows installer, that's a special case of documenting the versions of all third-party libraries used in the build. I believe all of the information is available in the source tree PCBuild project files: Steve or Zach should be able to address whether that info is and/or should be available as part of the install process. Adding all of that info to the release download page on python.org would be overkill as would a new PEP or a modification to PEP 101, IMO. We do include general license information for possibly-included third-party libraries at the end of the license page in the release documentation set (https://docs.python.org/3/license.html) but, correctly, do not include specific version numbers there. As a data point, for the python.org OS X installers, we now do include the specific version numbers of included libraries when producing the installer license file displayed as part of the installation process on OS X, with a link to the documentation set license page for the full text of the third-party licenses (see the attached jpg for an example). ---------- Added file: http://bugs.python.org/file39137/osx_installer_license_example.jpg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 03:28:31 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 20 Apr 2015 01:28:31 +0000 Subject: [issue21996] gettarinfo method does not handle files without text string names In-Reply-To: <1405583528.37.0.553699872308.issue21996@psf.upfronthosting.co.za> Message-ID: <1429493311.97.0.483525671828.issue21996@psf.upfronthosting.co.za> Martin Panter added the comment: Over in Issue 22468, I posted a documentation patch which includes wording to address this bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 03:34:21 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 20 Apr 2015 01:34:21 +0000 Subject: [issue22208] tarfile can't add in memory files (reopened) In-Reply-To: <1408145357.61.0.947327827691.issue22208@psf.upfronthosting.co.za> Message-ID: <1429493661.47.0.75043204546.issue22208@psf.upfronthosting.co.za> Martin Panter added the comment: In Issue 22468, I posted a patch which encourages using TarInfo directly, and hopefully clarifies that gettarinfo() is only for OS files. I think that should cover the documentation aspect of this bug, although an enhancement to synthesize TarInfo objects for regular files etc might still be a good idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 03:43:08 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 20 Apr 2015 01:43:08 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: Message-ID: Eric Snow added the comment: > Ionel Cristian M?rie? added the comment: > It's not. Did you see the example with iter()/__iter__? It does convert > the AttributeError into a TypeError. callable and iter are not the same thing though. callable checks for a capability. iter invokes a capability. The direct comparision would be collections.abc.Iterable.__subclasshook__ (e.g. isinstance(obj, Iterable)), which behaves exactly like callable does (does not invoke the descriptor protocol). See Lib/_collections_abc.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 03:50:45 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 20 Apr 2015 01:50:45 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: Message-ID: Eric Snow added the comment: > Ionel Cristian M?rie? added the comment: > What exactly are you proposing? Getting rid of AttributeError masking? That isn't really a practical thing to consider, so no. :) Instead I'm suggesting there isn't a lot of justification to change the behavior of callable. *If* we were to change anything I'd suggest disallowing AttributeError from a descriptor's getter during special method lookup. However, I'm not suggesting that either. We should simply leave callable alone (and consistent with the other helpers that inspect the "special" *capability* of objects). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 04:12:37 2015 From: report at bugs.python.org (Martin Falatic) Date: Mon, 20 Apr 2015 02:12:37 +0000 Subject: [issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values In-Reply-To: <1429231899.59.0.405315540238.issue23982@psf.upfronthosting.co.za> Message-ID: <1429495957.6.0.731059483504.issue23982@psf.upfronthosting.co.za> Martin Falatic added the comment: FYI, I'm currently using calls into Tkinter to get more detailed version info. Some methods work better than others... I've outlined my attempts below for reference (the last tcl_ver and tk_ver outputs are the ones I'm using, even though they are somewhat different in how they are written). try: # Python2 import Tkinter as tk except ImportError: # Python3 import tkinter as tk root = tk.Tk() tcl_ver = tk.TclVersion # Typical but low precsion tcl_ver = tk.Tcl().eval('info patchlevel') # Works but uses eval() tcl_ver = root.tcl.call('info', 'patchlevel') # Fails (AttributeError) tcl_ver = tk.Tcl().call('info', 'patchlevel') # Works, using tk_ver = tk.TkVersion # Typical but low precsion tk_ver = tk.Tk().eval('info patchlevel') # Works but makes extra window, uses eval() tk_ver = tk.Tk().call('info', 'patchlevel') # Works but makes extra window tk_ver = root.tk.call('info', 'patchlevel') # Works, using ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 04:18:29 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 20 Apr 2015 02:18:29 +0000 Subject: [issue8706] accept keyword arguments on most base type methods and builtins In-Reply-To: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za> Message-ID: <1429496309.91.0.84958526955.issue8706@psf.upfronthosting.co.za> Martin Panter added the comment: See also Issue 23738, which identifies some functions whose documentation already suggests they accept keywords. Perhaps these functions could be prioritized. Also, I think ?version changed? notices should be added in the documentation when a function grows support for keyword arguments. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 04:25:31 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 20 Apr 2015 02:25:31 +0000 Subject: [issue13386] Document documentation conventions for optional args In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za> Message-ID: <1429496731.21.0.238462293514.issue13386@psf.upfronthosting.co.za> Martin Panter added the comment: When a parameter is optional but does not have a simple default value, I suggest using some obviously invalid pseudocode, such as function(arg1, arg2=) See Issue 8706 about adding more support for keyword arguments. See also Issue 23738 for signatures that incorrectly appear to accept keywords due to including default values, and PEP 457?s slash (/) indicator for documenting positional-only parameters. ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 04:30:04 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 20 Apr 2015 02:30:04 +0000 Subject: [issue23738] Clarify documentation of positional-only default values In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za> Message-ID: <1429497004.21.0.00425339752102.issue23738@psf.upfronthosting.co.za> Martin Panter added the comment: Of course in a new release, the functions could actually grow support for keywords, sidestepping the problem. Issue 8706 proposes to do this. And see Issue 13386 about the conventions for optional arguments more generally. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 05:23:21 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 20 Apr 2015 03:23:21 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <1429500201.33.0.382094792201.issue23911@psf.upfronthosting.co.za> Eric Snow added the comment: Here's an updated patch, with the PEP 489 changes merged in. Only one test isn't passing and it is due to something in the pip that is bundled into ensurepip. I'll work on fixing that when I have some time. I'm sure there's documentation near the bundle that explains how to update it. ---------- Added file: http://bugs.python.org/file39138/path-based-importlib.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 05:24:02 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 20 Apr 2015 03:24:02 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <1429500242.87.0.210794622745.issue23911@psf.upfronthosting.co.za> Eric Snow added the comment: s/PEP 489/PEP 488/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 05:32:08 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 20 Apr 2015 03:32:08 +0000 Subject: [issue23985] Crash when deleting slices from duplicated bytearray In-Reply-To: <1429252668.91.0.45841644858.issue23985@psf.upfronthosting.co.za> Message-ID: <1429500728.63.0.70792284009.issue23985@psf.upfronthosting.co.za> Martin Panter added the comment: A test case for this that would trigger when memory debugging is enabled could look something like the following. Would it be appropriate to add it to the test suite? a = bytearray(10) size = sys.getsizeof(a) a.pop() # Defeat expanding buffer off-by-one quirk self.assertEqual(sys.getsizeof(a), size, "Quirk not defeated") del a[:1] # Or a.pop(0) # Does not trigger bug # Or a[:1] = () # Triggers bug self.assertEqual(sys.getsizeof(a), size, "Test assumes buffer not resized") a += bytes(2) # Add exactly the number of free bytes in buffer # Or a.extend(bytes(2)) # Unaffected # Or a.append(0); a.append(0) # Unaffected # Or a[8:] = bytes(2) # Unaffected del a # Trigger memory buffer to be freed, with verification ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 05:32:39 2015 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 20 Apr 2015 03:32:39 +0000 Subject: [issue24004] avoid explicit generator type check in asyncio In-Reply-To: <1429438862.32.0.692811371536.issue24004@psf.upfronthosting.co.za> Message-ID: <1429500759.71.0.0743912635787.issue24004@psf.upfronthosting.co.za> Guido van Rossum added the comment: Uh, wait. Who's patching anything? That breaks the warranty. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 05:45:53 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 20 Apr 2015 03:45:53 +0000 Subject: [issue23994] argparse fails to detect program name when there is a slash at the end of the program's path In-Reply-To: <1429379283.39.0.0511547854084.issue23994@psf.upfronthosting.co.za> Message-ID: <1429501553.77.0.926083799486.issue23994@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag resolution: fixed -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 05:52:51 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 20 Apr 2015 03:52:51 +0000 Subject: [issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values In-Reply-To: <1429231899.59.0.405315540238.issue23982@psf.upfronthosting.co.za> Message-ID: <1429501971.12.0.89616297627.issue23982@psf.upfronthosting.co.za> Terry J. Reedy added the comment: Ned, I was indeed thinking of creating the string upon startup. Martin: "Works, using" ? using what? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 06:02:27 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 20 Apr 2015 04:02:27 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429502547.13.0.338529314806.issue23990@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Unless there are some serious objections, I propose to close this on the basis of "practicality beats purity" (and as David Murray noted, there may not be a pure answer). Eric Snow's comments are dead-on. AFAICT, there isn't a real problem here and the API for better-or-worse has proven to be usable in practice (the callable() API has been around practically forever and the descriptor protocol has been around since Py2.2 -- if there were a real issue here, it would have reared it head long ago). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 06:05:23 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 20 Apr 2015 04:05:23 +0000 Subject: [issue23986] Inaccuracy about "in" keyword for list and tuple In-Reply-To: <1429255378.08.0.140067438597.issue23986@psf.upfronthosting.co.za> Message-ID: <1429502723.9.0.506212300842.issue23986@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I'll add James' suggested wording, but with the reversed-order suggested by David Murray. ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 06:07:57 2015 From: report at bugs.python.org (Ilia Kurenkov) Date: Mon, 20 Apr 2015 04:07:57 +0000 Subject: [issue1818] Add named tuple reader to CSV module In-Reply-To: <1200263236.24.0.0303258184569.issue1818@psf.upfronthosting.co.za> Message-ID: <1429502877.35.0.613141808968.issue1818@psf.upfronthosting.co.za> Ilia Kurenkov added the comment: As my contribution during the sprints at PyCon 2015, I've tweaked Jervis's patch a little and updated the tests/docs to work with Python 3.5. My only real change was placing the basic reader object inside a generator expression that filters out empty lines. Being partial to functional programming I find this removes some of the code clutter in __next__(), letting that method focus on turning rows into tuples. Hopefully this will rekindle the discussion! ---------- nosy: +copper-head versions: +Python 3.5 Added file: http://bugs.python.org/file39139/1818_py35.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 06:09:17 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 20 Apr 2015 04:09:17 +0000 Subject: [issue13386] Document documentation conventions for optional args In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za> Message-ID: <1429502957.01.0.224377167748.issue13386@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Please don't add a new notation that makes the docs less readable than they are now. For the most part, the existing docs have done a great job communicating how to use our functions. Please don't undo 20 years of tradition because it bugs you. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 06:12:03 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 20 Apr 2015 04:12:03 +0000 Subject: [issue1818] Add named tuple reader to CSV module In-Reply-To: <1200263236.24.0.0303258184569.issue1818@psf.upfronthosting.co.za> Message-ID: <1429503123.9.0.777554895291.issue1818@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Skip or Barry, do you want to look at this? ---------- assignee: -> skip.montanaro nosy: +skip.montanaro stage: needs patch -> patch review versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 06:25:14 2015 From: report at bugs.python.org (Mauro Rodrigues) Date: Mon, 20 Apr 2015 04:25:14 +0000 Subject: [issue23883] __all__ lists are incomplete In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za> Message-ID: <1429503914.31.0.275377556624.issue23883@psf.upfronthosting.co.za> Mauro Rodrigues added the comment: Hi guys! Here is a patch for the fileinput module, with some names beyond fileinput.fileno: fileinput.hook_compressed, fileinput.hook_encoded as mentioned in the docs https://docs.python.org/3/library/fileinput.html This is my first patch as well, so feedback's appreciated! ---------- nosy: +maurosr Added file: http://bugs.python.org/file39140/issue23883_fileinput.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 07:03:38 2015 From: report at bugs.python.org (Georg Brandl) Date: Mon, 20 Apr 2015 05:03:38 +0000 Subject: [issue24005] Documentation Error: Extra line Break In-Reply-To: <1429439369.0.0.722585874502.issue24005@psf.upfronthosting.co.za> Message-ID: <1429506218.71.0.857045514073.issue24005@psf.upfronthosting.co.za> Georg Brandl added the comment: Yeah, agreed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 07:14:47 2015 From: report at bugs.python.org (Tim Golden) Date: Mon, 20 Apr 2015 05:14:47 +0000 Subject: [issue24005] Documentation Error: Extra line Break In-Reply-To: <1429489506.74.0.51750626217.issue24005@psf.upfronthosting.co.za> Message-ID: <55348B41.9070504@timgolden.me.uk> Tim Golden added the comment: (Laughs). I admit, I was so close to the trees, I missed the fact that the doc is, as you say, a What's New, and for Python 2.4. Agree that to change this now would be somewhat ludicrous. If some similar patch were proposed to some more current, relevant document I'd still be at least open to the change proposed for the reasons I gave but let's close this one now. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 07:27:21 2015 From: report at bugs.python.org (Siegfried Gevatter) Date: Mon, 20 Apr 2015 05:27:21 +0000 Subject: [issue12606] Mutable Sequence Type works different for lists and bytearrays in slice[i:j:k] In-Reply-To: <1311287495.04.0.0852522537211.issue12606@psf.upfronthosting.co.za> Message-ID: <1429507641.51.0.0451424376412.issue12606@psf.upfronthosting.co.za> Siegfried Gevatter added the comment: Thomas, could you take another look? I did update the patch. Thanks! :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 07:31:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Apr 2015 05:31:29 +0000 Subject: [issue8706] accept keyword arguments on most base type methods and builtins In-Reply-To: <1273777855.43.0.0259016277933.issue8706@psf.upfronthosting.co.za> Message-ID: <1429507889.85.0.149098065423.issue8706@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Supporting keyword arguments has performance loss. For fast builtins it make be significant. We should defer adding keyword arguments support until more efficient parsing will implemented. Note that it is easier to implement efficient argument parsing for functions with positional-only arguments (see for example issue23867). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 07:36:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Apr 2015 05:36:03 +0000 Subject: [issue24007] Write PyArg_Parse* format in a line with a function In-Reply-To: <1429468247.73.0.580298527678.issue24007@psf.upfronthosting.co.za> Message-ID: <1429508163.77.0.476048509207.issue24007@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Actually it is not hard to me to apply the patch locally and regenerate clinic output if I need it. I propose this patch for mainstream only because think that it can be helpful for someone other. Thanks to moving all generated code into separated files, the code churn does not harm. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 07:52:29 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Apr 2015 05:52:29 +0000 Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za> Message-ID: <1429509149.69.0.414701731962.issue15582@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I were aware that this can propagate some not well appropriate docstrings from abstract base classes, but Martin expose worse problem: inheriting a docstring by the method with changed signature. Perhaps we should check if a signature of overriding method is compatible with a signature of base method. But this is hard to implement, and impossible in some cases until all builtins will converted to Argument Clinic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 08:04:55 2015 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 20 Apr 2015 06:04:55 +0000 Subject: [issue24004] avoid explicit generator type check in asyncio In-Reply-To: <1429438862.32.0.692811371536.issue24004@psf.upfronthosting.co.za> Message-ID: <1429509895.92.0.243508770314.issue24004@psf.upfronthosting.co.za> Stefan Behnel added the comment: I was (silently) hoping that this patching would eventually not be necessary anymore because the one place (currently inspect.isgenerator()) would be adapted to check for the generator protocol rather than the generator type. But that was going to go into a separate ticket. :) I'm not sure inspect.isgenerator() is the right place, though, as the module tends to deal with types, not protocols. I think the right fix overall would be a Generator ABC class that defines the protocol. What Cython does now in order to make asyncio work with Cython compiled generators is this: https://github.com/cython/cython/blob/4af42443bd37f6207143f8870904f780a65bb3e3/Cython/Utility/Generator.c#L824 https://github.com/cython/cython/blob/4af42443bd37f6207143f8870904f780a65bb3e3/Cython/Utility/Generator.c#L906 Aweful, but currently required due to the type check, which prevents objects that implement the generator protocol from being handled correctly by asyncio. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 08:05:46 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Mon, 20 Apr 2015 06:05:46 +0000 Subject: [issue8706] accept keyword arguments on most base type methods and builtins In-Reply-To: <1429507889.85.0.149098065423.issue8706@psf.upfronthosting.co.za> Message-ID: Gregory P. Smith added the comment: I wouldn't make an efficiency argument against it without trying it and showing reproducible degradation in the hg.python.org/benchmarks suite. On Sun, Apr 19, 2015, 10:31 PM Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > Supporting keyword arguments has performance loss. For fast builtins it > make be significant. We should defer adding keyword arguments support until > more efficient parsing will implemented. Note that it is easier to > implement efficient argument parsing for functions with positional-only > arguments (see for example issue23867). > > ---------- > nosy: +serhiy.storchaka > > _______________________________________ > Python tracker > > _______________________________________ > ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 08:09:50 2015 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 20 Apr 2015 06:09:50 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <1429510190.75.0.260513730992.issue23996@psf.upfronthosting.co.za> Changes by Stefan Behnel : ---------- nosy: +ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 08:18:38 2015 From: report at bugs.python.org (Johan Dahlberg) Date: Mon, 20 Apr 2015 06:18:38 +0000 Subject: [issue23985] Crash when deleting slices from duplicated bytearray In-Reply-To: <1429252668.91.0.45841644858.issue23985@psf.upfronthosting.co.za> Message-ID: <1429510718.16.0.554443178688.issue23985@psf.upfronthosting.co.za> Johan Dahlberg added the comment: Thank you all for working really fast on this issue! I'm happy to see that a fix is already being tried out. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 08:19:04 2015 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 20 Apr 2015 06:19:04 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <1429510744.28.0.144545217096.issue23996@psf.upfronthosting.co.za> Stefan Behnel added the comment: And in fact, fixing it in ceval.c would not be enough, since gen_throw() also calls the function. So this is really the right place to fix it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 08:28:35 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 20 Apr 2015 06:28:35 +0000 Subject: [issue10009] Automated MSI installation does not work In-Reply-To: <1285963909.15.0.466947839123.issue10009@psf.upfronthosting.co.za> Message-ID: <1429511315.68.0.884662156089.issue10009@psf.upfronthosting.co.za> Mark Lawrence added the comment: Nothing from the OP so to close or not to close, that is the question? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 08:32:39 2015 From: report at bugs.python.org (Martin Falatic) Date: Mon, 20 Apr 2015 06:32:39 +0000 Subject: [issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values In-Reply-To: <1429231899.59.0.405315540238.issue23982@psf.upfronthosting.co.za> Message-ID: <1429511559.98.0.0675730657987.issue23982@psf.upfronthosting.co.za> Martin Falatic added the comment: "Works, using" = this works, it's what I'm using (was trying to be brief - was too brief evidently). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 08:33:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Apr 2015 06:33:22 +0000 Subject: [issue23842] SystemError: ../Objects/longobject.c:998: bad argument to internal function In-Reply-To: <1427905043.2.0.434822440378.issue23842@psf.upfronthosting.co.za> Message-ID: <20150420063318.6597.70098@psf.io> Roundup Robot added the comment: New changeset cd7d51b5c951 by Serhiy Storchaka in branch '2.7': Issue #23842: os.major(), os.minor() and os.makedev() now support ints again. https://hg.python.org/cpython/rev/cd7d51b5c951 New changeset 998d967b8a57 by Serhiy Storchaka in branch '3.4': Issue #23842: Added tests for os.major(), os.minor() and os.makedev(). https://hg.python.org/cpython/rev/998d967b8a57 New changeset d477da6f287f by Serhiy Storchaka in branch 'default': Issue #23842: Added tests for os.major(), os.minor() and os.makedev(). https://hg.python.org/cpython/rev/d477da6f287f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 08:33:22 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Apr 2015 06:33:22 +0000 Subject: [issue23728] binascii.crc_hqx() can return negative integer In-Reply-To: <1426888370.18.0.244841446134.issue23728@psf.upfronthosting.co.za> Message-ID: <20150420063318.6597.45211@psf.io> Roundup Robot added the comment: New changeset 0ead02929df2 by Serhiy Storchaka in branch '3.4': Issue #23728: binascii.crc_hqx() could return an integer outside of the range https://hg.python.org/cpython/rev/0ead02929df2 New changeset abb86c6b11b2 by Serhiy Storchaka in branch 'default': Issue #23728: binascii.crc_hqx() could return an integer outside of the range https://hg.python.org/cpython/rev/abb86c6b11b2 New changeset 17702fd8ac0d by Serhiy Storchaka in branch '2.7': Issue #23728: Added a test for binascii.crc_hqx(). https://hg.python.org/cpython/rev/17702fd8ac0d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 08:41:59 2015 From: report at bugs.python.org (Martin Falatic) Date: Mon, 20 Apr 2015 06:41:59 +0000 Subject: [issue23982] Tkinter in Python 3.4 for Windows incorrectly renders certain colors using non-TclTk RGB values In-Reply-To: <1429231899.59.0.405315540238.issue23982@psf.upfronthosting.co.za> Message-ID: <1429512119.11.0.212883377393.issue23982@psf.upfronthosting.co.za> Martin Falatic added the comment: There may be a more uniform way to do all this that I'm not aware of. root.tcl.call() and root.tk.call() would be most symmetric while not creating extraneous windows, but that's not an option for the former, thus the methods I ended up using look different for Tk and Tcl. Whatever the output, a tuple (8,5,9) or string "8.5.9" (easily converted to a tuple) will be nice, hiding any disparate implementation details. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 08:57:07 2015 From: report at bugs.python.org (Masayuki Yamamoto) Date: Mon, 20 Apr 2015 06:57:07 +0000 Subject: [issue2445] Use The CygwinCCompiler Under Cygwin In-Reply-To: <1206117698.01.0.240143600903.issue2445@psf.upfronthosting.co.za> Message-ID: <1429513027.78.0.999520293579.issue2445@psf.upfronthosting.co.za> Masayuki Yamamoto added the comment: CygwinCCompiler seems legacy code. In v3.4 latest rivision, Distutils has made to work that is a patching to UnixCCompiler. So, I have a think that doesn't need to use CygwinCCompiler to build on Cygwin. I have upload a patch for UnixCCompiler. The patch has modified from http://cygwin.org package. Other big issues and patches for build on Cygwin: #21085, #13756 -- compile error #14598, #21124 -- C extension module ---------- nosy: +masamoto Added file: http://bugs.python.org/file39141/3.4-distutils-shlibext.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 09:12:50 2015 From: report at bugs.python.org (Alex Shkop) Date: Mon, 20 Apr 2015 07:12:50 +0000 Subject: [issue23882] unittest discovery and namespaced packages In-Reply-To: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za> Message-ID: <1429513970.67.0.103484502481.issue23882@psf.upfronthosting.co.za> Alex Shkop added the comment: This script creates following directory structure issue_23882\ tests\ test_fail.py If you run from issue_23882 directory python -m unittest it doesn't find any tests. If there is __init__.py inside tests folder, same command finds test_fail.py and runs it. I'm not sure yet about using pkgutil cause looks like iter_modules and walk_packages do not find namespace packages as well. ---------- Added file: http://bugs.python.org/file39142/issue_23882_test_case.sh _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 09:14:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Apr 2015 07:14:33 +0000 Subject: [issue23908] Check path arguments of os functions for null character In-Reply-To: <1428684232.77.0.530667773352.issue23908@psf.upfronthosting.co.za> Message-ID: <20150420071431.27920.49811@psf.io> Roundup Robot added the comment: New changeset cdadde8396a4 by Serhiy Storchaka in branch '3.4': Issue #23908: os functions now reject paths with embedded null character https://hg.python.org/cpython/rev/cdadde8396a4 New changeset bdf13c7dcf7f by Serhiy Storchaka in branch 'default': Issue #23908: os functions now reject paths with embedded null character https://hg.python.org/cpython/rev/bdf13c7dcf7f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 09:51:42 2015 From: report at bugs.python.org (Robert Collins) Date: Mon, 20 Apr 2015 07:51:42 +0000 Subject: [issue23882] unittest discovery doesn't detect namespace packages when given no parameters In-Reply-To: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za> Message-ID: <1429516302.35.0.0927084764288.issue23882@psf.upfronthosting.co.za> Robert Collins added the comment: Ok, so here's whats happening: the default behaviour is to do discovery of '.', which bypasses the namespace support code. Running with tests as the first parameter works because it doesn't require the directory being directly scanned to be a package. Equally, if the namespace isn't mapped to a local directory, 'python -m unittest tests' will load tests from the tests namespace. So - this seems to be acting as designed. Namespace packages working fine. However, I think what you're asking for is that namespace packages in your cwd are picked up and tested, without you having to supply the namespace name? I think what we'd need for that to work sanely is a patch to teach loader.discover to determine the local namespaces which are present under start_dir. Right now this code: elif os.path.isdir(full_path): if (not namespace and not os.path.isfile(os.path.join(full_path, '__init__.py'))): return None, False gets in your way: we assume that either we're processing a namespace, or there are no namespaces at all. I think some more detangling of the generator could address this fairly cleanly. ---------- stage: -> needs patch title: unittest discovery and namespaced packages -> unittest discovery doesn't detect namespace packages when given no parameters versions: +Python 3.5, Python 3.6 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 10:05:03 2015 From: report at bugs.python.org (Tim Golden) Date: Mon, 20 Apr 2015 08:05:03 +0000 Subject: [issue12712] weave build_tools library identification In-Reply-To: <1312822380.43.0.720864294913.issue12712@psf.upfronthosting.co.za> Message-ID: <1429517103.43.0.85711903413.issue12712@psf.upfronthosting.co.za> Tim Golden added the comment: I can't see anything here which is clearly a Python bug. If the OP or anyone else cares to come back (after more than 4 years!) with a clearly-reproducible problem I'm happy to revisit. I apologise for "waking up" this issue after so long; we really should have closed it within days... ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 10:25:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Apr 2015 08:25:06 +0000 Subject: [issue23842] SystemError: ../Objects/longobject.c:998: bad argument to internal function In-Reply-To: <1427905043.2.0.434822440378.issue23842@psf.upfronthosting.co.za> Message-ID: <1429518306.5.0.42669751816.issue23842@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 Mon Apr 20 10:25:23 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Apr 2015 08:25:23 +0000 Subject: [issue23728] binascii.crc_hqx() can return negative integer In-Reply-To: <1426888370.18.0.244841446134.issue23728@psf.upfronthosting.co.za> Message-ID: <1429518323.01.0.589527574574.issue23728@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 Mon Apr 20 10:41:08 2015 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Mon, 20 Apr 2015 08:41:08 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: Message-ID: Ionel Cristian M?rie? added the comment: On Mon, Apr 20, 2015 at 4:50 AM, Eric Snow wrote: > We should > simply leave callable alone (and consistent with the other helpers > that inspect the "special" *capability* of objects). > ?Which are the other helpers?? Thanks, -- Ionel Cristian M?rie?, http://blog.ionelmc.ro ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 10:43:14 2015 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Mon, 20 Apr 2015 08:43:14 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429502547.13.0.338529314806.issue23990@psf.upfronthosting.co.za> Message-ID: Ionel Cristian M?rie? added the comment: On Mon, Apr 20, 2015 at 7:02 AM, Raymond Hettinger wrote: > AFAICT, there isn't a real problem here and the API for better-or-worse > has proven to be usable in practice (the callable() API has been around > practically forever and the descriptor protocol has been around since Py2.2 > -- if there were a real issue here, it would have reared it head long ago). ?I think this is largely a product of misunderstanding the issue. As you can see in the early comments in the thread, the fact that special methods ?use descriptors is really really obscure. Thanks, -- Ionel Cristian M?rie?, http://blog.ionelmc.ro ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 11:04:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Apr 2015 09:04:13 +0000 Subject: [issue11344] Add os.path.splitpath(path) function In-Reply-To: <1298795208.87.0.771920756626.issue11344@psf.upfronthosting.co.za> Message-ID: <1429520653.72.0.0571775813156.issue11344@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I thought that splitpath() could be used in implementations of realpath(), relpath(), commonpath(), and in user code. But looks as realpath(), relpath() and commonpath() should use specialized inlined versions for efficiency, and user code can use more highlevel pathlib. For now there are no strong arguments for adding splitpath(). The patch is updated to the tip (for the case if it will needed in the future) and the issue is closed. ---------- resolution: -> rejected stage: patch review -> resolved status: open -> closed Added file: http://bugs.python.org/file39143/ospath_splitpath_4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 11:09:20 2015 From: report at bugs.python.org (Joe Jevnik) Date: Mon, 20 Apr 2015 09:09:20 +0000 Subject: [issue24014] Second pass of PyCode_Optimize Message-ID: <1429520960.11.0.0723675041232.issue24014@psf.upfronthosting.co.za> New submission from Joe Jevnik: There are a lot of optimizations that are being missed by only running a single pass of PyCode_Optimize. I originally started by trying to optimize for De Morgan's Laws in if tests; however, I realized that the issue actually went away if you run the optimizer twice. I imagine that this would provide a lot of other performance increases because some of the patterns don't show up until the optimizer has already run once. For example: >>> def f(a, b): ... if not a and not b: ... return True ... return False ... On default, this generates: >>> dis(f) 2 0 LOAD_FAST 0 (a) 3 UNARY_NOT 4 POP_JUMP_IF_FALSE 18 7 LOAD_FAST 1 (b) 10 UNARY_NOT 11 POP_JUMP_IF_FALSE 18 3 14 LOAD_CONST 1 (True) 17 RETURN_VALUE 4 >> 18 LOAD_CONST 2 (False) 21 RETURN_VALUE If we run the optimizer again, we can collapse some of the UNARY_NOT -> POP_JUMP_IF_FALSE back into POP_JUMP_IF_TRUE, like this: >>> dis(f) 2 0 LOAD_FAST 0 (a) 3 POP_JUMP_IF_TRUE 16 6 LOAD_FAST 1 (b) 9 POP_JUMP_IF_TRUE 16 3 12 LOAD_CONST 1 (True) 15 RETURN_VALUE 4 >> 16 LOAD_CONST 2 (False) 19 RETURN_VALUE Also, Python/importlib.h blew up in the diff; should this be included in the patch? ---------- components: Interpreter Core files: secondpass.patch keywords: patch messages: 241626 nosy: llllllllll priority: normal severity: normal status: open title: Second pass of PyCode_Optimize type: performance versions: Python 3.5 Added file: http://bugs.python.org/file39144/secondpass.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 11:31:06 2015 From: report at bugs.python.org (koobs) Date: Mon, 20 Apr 2015 09:31:06 +0000 Subject: [issue23485] PEP 475: handle EINTR in the select and selectors module In-Reply-To: <1424352775.64.0.420442648443.issue23485@psf.upfronthosting.co.za> Message-ID: <1429522266.62.0.333169522803.issue23485@psf.upfronthosting.co.za> Changes by koobs : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 11:31:09 2015 From: report at bugs.python.org (koobs) Date: Mon, 20 Apr 2015 09:31:09 +0000 Subject: [issue22117] Rewrite pytime.h to work on nanoseconds In-Reply-To: <1406848093.52.0.5184372094.issue22117@psf.upfronthosting.co.za> Message-ID: <1429522269.94.0.277781035238.issue22117@psf.upfronthosting.co.za> Changes by koobs : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 11:50:08 2015 From: report at bugs.python.org (Alex Shkop) Date: Mon, 20 Apr 2015 09:50:08 +0000 Subject: [issue23882] unittest discovery doesn't detect namespace packages when given no parameters In-Reply-To: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za> Message-ID: <1429523408.2.0.674353427716.issue23882@psf.upfronthosting.co.za> Alex Shkop added the comment: Thanks. I understand the code pretty well and I saw issue17457 that fixes discovery for explicitly specified namespace package. What I need is to know how discovery has to work. Do we need to discover namespace packages inside discovery path? And should we do that recursively? I.e. should we pick namespace packages inside namespace packages? This will lead to recursive scan of all directories under discovery path. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 11:59:29 2015 From: report at bugs.python.org (koobs) Date: Mon, 20 Apr 2015 09:59:29 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1429523969.81.0.447860780173.issue23863@psf.upfronthosting.co.za> Changes by koobs : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 12:05:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Apr 2015 10:05:58 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <1429524358.1.0.0528417213771.issue16840@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There is at least one buildbot that now fails to build _tkinter. http://buildbot.python.org/all/builders/x86%20FreeBSD%206.4%202.7/builds/2457/steps/test/logs/stdio building '_tkinter' extension gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -g -O0 -Wall -Wstrict-prototypes -DWITH_APPINIT=1 -I/usr/local/include/tcl8.5 -I/usr/local/include/tk8.5 -I/usr/X11R6/include -I. -IInclude -I./Include -I/usr/local/include -I/usr/home/db3l/buildarea/2.7.bolen-freebsd/build/Include -I/usr/home/db3l/buildarea/2.7.bolen-freebsd/build -c /usr/home/db3l/buildarea/2.7.bolen-freebsd/build/Modules/_tkinter.c -o build/temp.freebsd-6.4-RELEASE-i386-2.7-pydebug/usr/home/db3l/buildarea/2.7.bolen-freebsd/build/Modules/_tkinter.o /usr/home/db3l/buildarea/2.7.bolen-freebsd/build/Modules/_tkinter.c:101:24: tclTomMath.h: No such file or directory ---------- status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 13:03:51 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Apr 2015 11:03:51 +0000 Subject: [issue23908] Check path arguments of os functions for null character In-Reply-To: <1428684232.77.0.530667773352.issue23908@psf.upfronthosting.co.za> Message-ID: <1429527831.61.0.828544060027.issue23908@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch for 2.7 should be different and more complex. First at all, "s" and "u" format units don't check for null character (but "et" and "es" used in Unix implementations of os functions do). ---------- stage: patch review -> needs patch versions: +Python 2.7 -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 13:08:15 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Apr 2015 11:08:15 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <20150420110808.6587.50296@psf.io> Roundup Robot added the comment: New changeset 8ab077c22fbf by Serhiy Storchaka in branch '2.7': Issue #16840: Turn on support of bignums only in final release of Tcl 8.5. https://hg.python.org/cpython/rev/8ab077c22fbf New changeset 7f1622478d17 by Serhiy Storchaka in branch '3.4': Issue #16840: Turn on support of bignums only in final release of Tcl 8.5. https://hg.python.org/cpython/rev/7f1622478d17 New changeset 7a7f09528866 by Serhiy Storchaka in branch 'default': Issue #16840: Turn on support of bignums only in final release of Tcl 8.5. https://hg.python.org/cpython/rev/7a7f09528866 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 13:16:54 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 20 Apr 2015 11:16:54 +0000 Subject: [issue7018] Recommend "*" over "#" in getargs.c typecodes In-Reply-To: <1254221956.14.0.22830785564.issue7018@psf.upfronthosting.co.za> Message-ID: <1429528614.97.0.510965359724.issue7018@psf.upfronthosting.co.za> Mark Lawrence added the comment: The 3.x arg.html seems a great improvement to my eye compared to the 2.x version so I'd guess this can be closed as out of date. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 13:25:26 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 20 Apr 2015 11:25:26 +0000 Subject: [issue10308] Modules/getpath.c bugs In-Reply-To: <1288870063.75.0.834981100194.issue10308@psf.upfronthosting.co.za> Message-ID: <1429529126.04.0.358043616117.issue10308@psf.upfronthosting.co.za> Mark Lawrence added the comment: Reading msg120918 and msg120940 it looks as if work has been completed so this can be closed as fixed. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 13:28:59 2015 From: report at bugs.python.org (Mark Lawrence) Date: Mon, 20 Apr 2015 11:28:59 +0000 Subject: [issue6824] help for a module should list supported platforms In-Reply-To: <1251909781.63.0.685022567379.issue6824@psf.upfronthosting.co.za> Message-ID: <1429529339.62.0.729262001278.issue6824@psf.upfronthosting.co.za> Mark Lawrence added the comment: As there was no reply to msg109130 (nearly five years ago) can we close this as won't fix? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 13:33:42 2015 From: report at bugs.python.org (Cyd Haselton) Date: Mon, 20 Apr 2015 11:33:42 +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: <1429529622.95.0.177446832604.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Ryan, There's not a python.c in the ./Programs file? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 14:24:53 2015 From: report at bugs.python.org (Ilia Kurenkov) Date: Mon, 20 Apr 2015 12:24:53 +0000 Subject: [issue20362] longMessage attribute is ignored in unittest.TestCase.assertRegexpMatches etc In-Reply-To: <1390469977.33.0.983072297482.issue20362@psf.upfronthosting.co.za> Message-ID: <1429532693.48.0.0844655174997.issue20362@psf.upfronthosting.co.za> Ilia Kurenkov added the comment: Hi Berker! I hope all's well on your end. Let me know if you have questions about the reasoning behind my changes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 14:38:35 2015 From: report at bugs.python.org (Wolfgang Maier) Date: Mon, 20 Apr 2015 12:38:35 +0000 Subject: [issue23975] numbers.Rational implements __float__ incorrectly In-Reply-To: <1429214817.83.0.816258978912.issue23975@psf.upfronthosting.co.za> Message-ID: <1429533515.2.0.0924003288171.issue23975@psf.upfronthosting.co.za> Wolfgang Maier added the comment: Good point. If the numbers ABC guaranteed numerator and denominator to be Integral numbers, this could be solved by: return float(int(self.numerator) / int(self.denominator)) but since both could be Rationals again that does not seem to be an option either. What could be done is trying to multiply out the numerator and denominator pair until both *are* Integrals, like: num = self.numerator den = self.denominator while not (isinstance(num, Integral) and isinstance(den, Integral)): num = num.numerator * den.denominator den = den.numerator * num.denominator return float(int(num) / int(den)) Clearly that's more complicated, but, more importantly, has the disadvantage that the loop will run forever if the final numerator or denominator is not registered correctly in the numeric tower. So some kind of check for this situation would be required, but I do not have an idea right now what that should look like. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 14:50:26 2015 From: report at bugs.python.org (Paul Moore) Date: Mon, 20 Apr 2015 12:50:26 +0000 Subject: [issue23975] numbers.Rational implements __float__ incorrectly In-Reply-To: <1429214817.83.0.816258978912.issue23975@psf.upfronthosting.co.za> Message-ID: <1429534226.25.0.329461268888.issue23975@psf.upfronthosting.co.za> Paul Moore added the comment: Is it not reasonable to simply say that implementations of numbers.Rational which allow the numerator and denominator to have types for which true division doesn't return a float, have to provide their own implementation of __float__()? It's certainly less convenient, and probably surprising for users, but the alternative is trying to work around broken integer types - after all numbers.Complex.__truediv__ says "Should promote to float when necessary" in the docstring, which to me says that a type where a/b doesn't return a float doesn't conform to the numeric tower. ---------- nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 14:55:46 2015 From: report at bugs.python.org (Paul Moore) Date: Mon, 20 Apr 2015 12:55:46 +0000 Subject: [issue23975] numbers.Rational implements __float__ incorrectly In-Reply-To: <1429214817.83.0.816258978912.issue23975@psf.upfronthosting.co.za> Message-ID: <1429534546.77.0.956994603291.issue23975@psf.upfronthosting.co.za> Paul Moore added the comment: Alternatively, return int(self.numerator) / int(self.denominator). After all, a fraction whose numerator can't be represented as a Python (unlimited precision) integer is a pretty odd sort of fraction... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 15:05:02 2015 From: report at bugs.python.org (Wolfgang Maier) Date: Mon, 20 Apr 2015 13:05:02 +0000 Subject: [issue23975] numbers.Rational implements __float__ incorrectly In-Reply-To: <1429214817.83.0.816258978912.issue23975@psf.upfronthosting.co.za> Message-ID: <1429535102.45.0.921141053852.issue23975@psf.upfronthosting.co.za> Wolfgang Maier added the comment: > Is it not reasonable to simply say that implementations of numbers.Rational which allow the numerator and denominator to have types for which true division doesn't return a float, have to provide their own implementation of __float__()? Unfortunately, the Rational type cannot always know what its numerator or denominator supports. Look at fractions.Fraction: its only requirement for numerator and denominator is that they both should be Rational instances. So a hypothetical MyInt like Mark describes it could be perfectly acceptable for Fraction except that it would fail to convert it to float. > It's certainly less convenient, and probably surprising for users, but the alternative is trying to work around broken integer types - after all numbers.Complex.__truediv__ says "Should promote to float when necessary" in the docstring, which to me says that a type where a/b doesn't return a float doesn't conform to the numeric tower. > I do read this docstring differently. To me, it means should promote to float if there is no other way to express the result (like when your custom type system does not define its own Float type). It would, in fact, be really bad for custom type implementors if they would be forced to leave their type system when doing divisions. > Alternatively, return int(self.numerator) / int(self.denominator). After all, a fraction whose numerator can't be represented as a Python (unlimited precision) integer is a pretty odd sort of fraction... The problem here is that self.numerator and/or self.denominator could both be Rational instances again, which are not expressible as a Python integer and, thus, are not enforced to provide __int__ by the numbers ABC. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 15:17:23 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 20 Apr 2015 13:17:23 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429535843.55.0.213420982223.issue23990@psf.upfronthosting.co.za> R. David Murray added the comment: The only 'consistency' fix that would make any sense, IMO, would be to disallow special methods to be descriptors. We can't do that for backward compatibility reasons, so that's pretty much case closed. Eric already mentioned one of the other 'capability' helpers: rdmurray at pydev:~/python/p35>./python Python 3.5.0a3+ (default:5612dc5e6af9+, Apr 16 2015, 11:29:58) [GCC 4.8.2] on linux Type "help", "copyright", "credits" or "license" for more information. >>> class Foo: ... @property ... def __iter__(self): ... raise AttributeError ... >>> f = Foo >>> from collections.abc import Iterable >>> issubclass(Foo, Iterable) True ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 15:19:22 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 20 Apr 2015 13:19:22 +0000 Subject: [issue24014] Second pass of PyCode_Optimize In-Reply-To: <1429520960.11.0.0723675041232.issue24014@psf.upfronthosting.co.za> Message-ID: Eric Snow added the comment: > Also, Python/importlib.h blew up in the diff; should this be included in the patch? Yes. It is the frozen bytecode for bootstrapping importlib as the import system. So changes to bytecode generation like this will propagate there. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 15:27:53 2015 From: report at bugs.python.org (Cyd Haselton) Date: Mon, 20 Apr 2015 13:27:53 +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: <1429536473.89.0.918463097459.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: FYI, I'm on commit c917493dc4ea2c32371da861aca2235f0a08e68e ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 15:28:04 2015 From: report at bugs.python.org (Joachim Breitner) Date: Mon, 20 Apr 2015 13:28:04 +0000 Subject: [issue24015] timeit should start with 1 loop, not 10 Message-ID: <1429536484.03.0.469371276206.issue24015@psf.upfronthosting.co.za> New submission from Joachim Breitner: The docs for the timeit command line interface specify If -n is not given, a suitable number of loops is calculated by trying successive powers of 10 until the total time is at least 0.2 seconds. This sounds as if it it first tries 1, then 10, then 100 etc. But the code starts with 10 iterations. So even if the tested code already takes long enough (e.g. because it is a suitable loop itself), timit will by default test 10 loops. I propose to change that, and replace # determine number so that 0.2 <= total time < 2.0 for i in range(1, 10): number = 10**i with # determine number so that 0.2 <= total time < 2.0 for i in range(0, 10): number = 10**i in Lib/timeit.py. ---------- components: Library (Lib) messages: 241643 nosy: nomeata priority: normal severity: normal status: open title: timeit should start with 1 loop, not 10 versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 15:28:21 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 20 Apr 2015 13:28:21 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429536501.26.0.626270719575.issue23990@psf.upfronthosting.co.za> R. David Murray added the comment: I in case it wasn't clear, I closed this not because of my "case closed" statement, but because as Eric pointed out we *do* have consistency here: things which check *capabilities* (as opposed to actually *using* the special methods), like callable and Iterable, only look for the existence of the method, consistently. The fact that you can then get an AttributeError later when actually using the method is unfortunate, but there really isn't anything sensible to be done about it, due to backward compatibility concerns. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 15:36:08 2015 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Mon, 20 Apr 2015 13:36:08 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429536501.26.0.626270719575.issue23990@psf.upfronthosting.co.za> Message-ID: Ionel Cristian M?rie? added the comment: My point was about consistency in descriptor handling, not consistency of fault (eg: broken everywhere). I don't understand why that's not clear here. The big idea here is to harmonize capability checking with descriptor handling. Justifying breakage in callable with breakage in collections.Callable serves it no justice. On Monday, April 20, 2015, R. David Murray wrote: > > R. David Murray added the comment: > > I in case it wasn't clear, I closed this not because of my "case closed" > statement, but because as Eric pointed out we *do* have consistency here: > things which check *capabilities* (as opposed to actually *using* the > special methods), like callable and Iterable, only look for the existence > of the method, consistently. The fact that you can then get an > AttributeError later when actually using the method is unfortunate, but > there really isn't anything sensible to be done about it, due to backward > compatibility concerns. > > ---------- > > _______________________________________ > Python tracker > > > _______________________________________ > -- Thanks, -- Ionel Cristian M?rie?, http://blog.ionelmc.ro ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 15:39:07 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 20 Apr 2015 13:39:07 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1429537147.11.0.60467251817.issue23863@psf.upfronthosting.co.za> R. David Murray added the comment: Is there a bug being fixed here? I mean other than socket not handling EINTR, where I think we agree that handling it is a feature, given the PEP. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 15:45:05 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 20 Apr 2015 13:45:05 +0000 Subject: [issue24014] Second pass of PyCode_Optimize In-Reply-To: <1429520960.11.0.0723675041232.issue24014@psf.upfronthosting.co.za> Message-ID: <1429537505.74.0.411523362233.issue24014@psf.upfronthosting.co.za> Yury Selivanov added the comment: Is there any noticeable performance increase with the patch? Please attach results from https://hg.python.org/benchmarks ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 15:45:44 2015 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Mon, 20 Apr 2015 13:45:44 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: Message-ID: Ionel Cristian M?rie? added the comment: Also, descriptors are a core mechanism in new-style classes - you can't have methods without descriptors. Why would you even consider removing descriptors from the special method lookup if that's part of the object model design? On Monday, April 20, 2015, Ionel Cristian M?rie? wrote: > > Ionel Cristian M?rie? added the comment: > > My point was about consistency in descriptor handling, not consistency of > fault (eg: broken everywhere). I don't understand why that's not clear > here. > > The big idea here is to harmonize capability checking with descriptor > handling. Justifying breakage in callable with breakage in > collections.Callable serves it no justice. > > On Monday, April 20, 2015, R. David Murray > wrote: > > > > > R. David Murray added the comment: > > > > I in case it wasn't clear, I closed this not because of my "case closed" > > statement, but because as Eric pointed out we *do* have consistency here: > > things which check *capabilities* (as opposed to actually *using* the > > special methods), like callable and Iterable, only look for the existence > > of the method, consistently. The fact that you can then get an > > AttributeError later when actually using the method is unfortunate, but > > there really isn't anything sensible to be done about it, due to backward > > compatibility concerns. > > > > ---------- > > > > _______________________________________ > > Python tracker > > > > > _______________________________________ > > > > -- > > Thanks, > -- Ionel Cristian M?rie?, http://blog.ionelmc.ro > > ---------- > > _______________________________________ > Python tracker > > > _______________________________________ > -- Thanks, -- Ionel Cristian M?rie?, http://blog.ionelmc.ro ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 15:53:06 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 20 Apr 2015 13:53:06 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429537986.94.0.460946840687.issue23990@psf.upfronthosting.co.za> R. David Murray added the comment: Because special methods are special. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 16:02:22 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 20 Apr 2015 14:02:22 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: Message-ID: Eric Snow added the comment: > Ionel Cristian M?rie? added the comment: > Also, descriptors are a core mechanism in new-style classes - you can't > have methods without descriptors. Why would you even consider removing > descriptors from the special method lookup if that's part of the object > model design? Also, we are not changing anything here and we are not considering removing descriptors from special method lookup. This is the way it has been for a long time for code that *checks* for special method capability. As RDM and I have both said, changing that would break backward compatibility. As I've already explained, I also think it is wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 16:08:25 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 20 Apr 2015 14:08:25 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429538905.44.0.864865200854.issue23990@psf.upfronthosting.co.za> Eric Snow added the comment: FYI, I'll re-iterate something I said before, there is a different approach you can take here if this is just an issue of proxying. Use two different proxy types depending on if the proxied object is callable or not: class Proxy: # all the proxy stuff... class CallableProxy(Proxy): def __call__(self, *args, **kwargs): ... def proxy(obj): if callable(obj): return CallableProxy(obj) else: return Proxy(obj) If that isn't a viable alternative then please explain your use case in more detail. I'm sure we can find a solution that works for you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 16:28:49 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 20 Apr 2015 14:28:49 +0000 Subject: [issue24015] timeit should start with 1 loop, not 10 In-Reply-To: <1429536484.03.0.469371276206.issue24015@psf.upfronthosting.co.za> Message-ID: <1429540129.54.0.364430034496.issue24015@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 16:29:00 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 20 Apr 2015 14:29:00 +0000 Subject: [issue24014] Second pass of PyCode_Optimize In-Reply-To: <1429520960.11.0.0723675041232.issue24014@psf.upfronthosting.co.za> Message-ID: <1429540140.25.0.074771784242.issue24014@psf.upfronthosting.co.za> Raymond Hettinger added the comment: I would like to keep the time spent in the optimizer itself to a minimum. Also, it should keep focused on patterns that actually occur in code as opposed to contrived bits of code. Tim and Guido let us put it the optimizer only on the condition that it be kept simple and with low overhead. The work that has been needed for a long time was to move a number of the optimizations (such as constant folding) out of the peepholer optimizer and replace them with AST manipulations just upstream from code generation (to reduce the need for the peepholer to partially disassemble and re-interpret the bytecode). ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 16:42:02 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 20 Apr 2015 14:42:02 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429540922.34.0.0139475520569.issue23990@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > My point was about consistency in descriptor handling, not consistency > of fault (eg: broken everywhere). I don't understand why that's not > clear here. That is clear but also isn't sufficient motivation. The proposed change is unnecessary and not rooted in real use cases. It is a semantic change to a long-standing view that callable() means having a __call__ method. > The big idea here is to harmonize capability checking with descriptor handling. That isn't what Guido intended when he designed the capability checking. He has a remarkably good instinct for avoiding language complexity when there aren't clear-cut benefits. > http://blog.ionelmc.r Please stop using the bug tracker to post links to your blog. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 16:49:28 2015 From: report at bugs.python.org (Christian Heimes) Date: Mon, 20 Apr 2015 14:49:28 +0000 Subject: [issue24014] Second pass of PyCode_Optimize In-Reply-To: <1429520960.11.0.0723675041232.issue24014@psf.upfronthosting.co.za> Message-ID: <1429541368.44.0.978617207118.issue24014@psf.upfronthosting.co.za> Christian Heimes added the comment: How about restricting double pass optimization to code objects that have the CO_OPTIMIZED bit set? It doesn't affect normal code execution. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 16:50:27 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 20 Apr 2015 14:50:27 +0000 Subject: [issue23917] please fall back to sequential compilation when concurrent doesn't exist In-Reply-To: <1428792729.56.0.740382381475.issue23917@psf.upfronthosting.co.za> Message-ID: <1429541427.09.0.440908567489.issue23917@psf.upfronthosting.co.za> Brett Cannon added the comment: LGTM ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 16:52:14 2015 From: report at bugs.python.org (Christian Heimes) Date: Mon, 20 Apr 2015 14:52:14 +0000 Subject: [issue23998] PyImport_ReInitLock() doesn't check for allocation error In-Reply-To: <1429396955.07.0.854315130889.issue23998@psf.upfronthosting.co.za> Message-ID: <1429541534.78.0.890998144542.issue23998@psf.upfronthosting.co.za> Christian Heimes added the comment: Thanks, Brett! ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 16:54:06 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Mon, 20 Apr 2015 14:54:06 +0000 Subject: [issue23496] Steps for Android Native Build of Python 3.4.2 In-Reply-To: <1429536473.89.0.918463097459.issue23496@psf.upfronthosting.co.za> Message-ID: Ryan Gonzalez added the comment: Nevermind. I was just being stupid. I kept searching the "Python" directory for references to get_codec_name and _PyMem_RawStrdup and completely missed the Programs directory. Sorry. Did the updated kbox_fix.patch work? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 17:16:26 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 20 Apr 2015 15:16:26 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1429542986.5.0.301281793996.issue23863@psf.upfronthosting.co.za> STINNER Victor added the comment: See also issue #20611 "socket.create_connection() doesn't handle EINTR properly" which was closed as duplicated of this issue. I'm not sure that #20611 is a duplicate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 17:21:39 2015 From: report at bugs.python.org (Brett Cannon) Date: Mon, 20 Apr 2015 15:21:39 +0000 Subject: [issue24014] Second pass of PyCode_Optimize In-Reply-To: <1429520960.11.0.0723675041232.issue24014@psf.upfronthosting.co.za> Message-ID: <1429543299.15.0.521371197519.issue24014@psf.upfronthosting.co.za> Brett Cannon added the comment: Just FYI, http://bugs.python.org/issue11549 can act as a tracking issue for an AST optimization path that runs prior to the peepholer. ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 17:28:57 2015 From: report at bugs.python.org (Joe Jevnik) Date: Mon, 20 Apr 2015 15:28:57 +0000 Subject: [issue24014] Second pass of PyCode_Optimize In-Reply-To: <1429520960.11.0.0723675041232.issue24014@psf.upfronthosting.co.za> Message-ID: <1429543737.76.0.157157864236.issue24014@psf.upfronthosting.co.za> Joe Jevnik added the comment: I am actually getting inconsistent results from running benchmark; I am pretty surprised by this. I could look into making the second pass only happen if the code has the CO_OPTIMIZED bit set; however, based on the results I am seeing from the benchmark runs, I am not sure it is worth it. Does the benchmark tool recompile the code every run? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 17:29:23 2015 From: report at bugs.python.org (Ethan Furman) Date: Mon, 20 Apr 2015 15:29:23 +0000 Subject: [issue23987] docs about containers membership testing wrong for broken objects In-Reply-To: <1429258165.63.0.284734084008.issue23987@psf.upfronthosting.co.za> Message-ID: <1429543763.14.0.847919882238.issue23987@psf.upfronthosting.co.za> Ethan Furman added the comment: So something like: For container types such as list, tuple, or collections.deque, the expression 'x in y' is equivalent to 'any(x is e or x == e for e in y)'. For container types such as set, frozenset, and dict, this equivalence expression is modified by the addition of 'if hash(x) == hash(e)'. ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 17:31:04 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 20 Apr 2015 15:31:04 +0000 Subject: [issue24014] Second pass of PyCode_Optimize In-Reply-To: <1429520960.11.0.0723675041232.issue24014@psf.upfronthosting.co.za> Message-ID: <1429543864.17.0.110102443155.issue24014@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Does the benchmark tool recompile the code every run? Make sure you've bumped magic number in importlib/bootstrap; then make clean; make ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 17:38:17 2015 From: report at bugs.python.org (Cyd Haselton) Date: Mon, 20 Apr 2015 15:38:17 +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: <1429544297.94.0.500787494185.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Ryan, Completely forgot to download and apply it, but based on what I see there are a few things that need to be corrected. 1) -python3.4m needs to be changed to -python3.5m...or the appropriate versioning variable. 2) colons at the end of the elif lines in setup.py (1950- ) 3) The _crypt and readline module builds in setup.py need additional libraries to work...python3.5m for both and possibly ncurses for readline, I'll test and get back to you. With #1 and #2 added, the build and install completes successfully, although you obviously can't import readline and _crypt. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 17:38:24 2015 From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=) Date: Mon, 20 Apr 2015 15:38:24 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429540922.34.0.0139475520569.issue23990@psf.upfronthosting.co.za> Message-ID: Ionel Cristian M?rie? added the comment: On Mon, Apr 20, 2015 at 5:42 PM, Raymond Hettinger wrote: > > That is clear but also isn't sufficient motivation. The proposed change > is unnecessary and not rooted in real use cases. It is a semantic change > to a long-standing view that callable() means having a __call__ method. > There is one use case: a lazy object proxy (there are some examples in the earlier replies). Eric proposed a CallableProxy/NonCallableProxy dichtonomy but I don't really like that API (feels wrong and verbose). > Please stop using the bug tracker to post li ?Sorry about that, I've replied through email and wasn't aware of bugtracker etiquette.? ?The bugtracker doesn't have a nice way to reply to messages and it's atrocious on a mobile device.? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 17:50:47 2015 From: report at bugs.python.org (eryksun) Date: Mon, 20 Apr 2015 15:50:47 +0000 Subject: [issue23990] Callable builtin doesn't respect descriptors In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za> Message-ID: <1429545047.44.0.932396647375.issue23990@psf.upfronthosting.co.za> eryksun added the comment: To be consistent you'd have to do the attribute check in PyObject_Call as well, i.e. if an object isn't callable, then trying to call it should raise a TypeError. I think the cost can be mitigated by only checking heap types (i.e. tp_flags & Py_TPFLAGS_HEAPTYPE). It would be cleaner if slot_tp_call failed by raising TypeError instead of letting the AttributeError bubble up. There's a precedent in slot_tp_iter to raise a TypeError if lookup_method() fails. This would avoid having to change PyObject_Call. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 18:02:16 2015 From: report at bugs.python.org (Carol Willing) Date: Mon, 20 Apr 2015 16:02:16 +0000 Subject: [issue24016] Add a Sprints organization/preparation section to devguide Message-ID: <1429545736.46.0.134603387564.issue24016@psf.upfronthosting.co.za> New submission from Carol Willing: Based on feedback from the PyCon 2015 CPython sprints (thank you R. David Murray and all the CPython contributors there), a sprint organization section will be added to the devguide. Here are some suggested subtopics in the Sprints organization section: * Pre-sprint preparation (by core devs and those familiar with CPython devel) - Etherpad for issues and links to resources - Dev in a box environment preparation - Docker container for development (based on work done by Saul) * At the sprint - Important info posted in room (IRC; etherpad; schedule) - Welcome talk as given by R. David - Introduction of core devs in attendance - Periodic announcements to encourage questions * After the sprint - Capture feedback from the etherpad - Refine devguide as needed Please suggest additional topics. Thanks! ---------- assignee: willingc components: Devguide messages: 241666 nosy: ezio.melotti, willingc priority: normal severity: normal stage: needs patch status: open title: Add a Sprints organization/preparation section to devguide type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 18:09:49 2015 From: report at bugs.python.org (R. David Murray) Date: Mon, 20 Apr 2015 16:09:49 +0000 Subject: [issue23987] docs about containers membership testing wrong for broken objects In-Reply-To: <1429258165.63.0.284734084008.issue23987@psf.upfronthosting.co.za> Message-ID: <1429546189.97.0.737296535784.issue23987@psf.upfronthosting.co.za> R. David Murray added the comment: Yes, that's what I had in mind. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 18:29:43 2015 From: report at bugs.python.org (Mert Bora Alper) Date: Mon, 20 Apr 2015 16:29:43 +0000 Subject: [issue23994] argparse fails to detect program name when there is a slash at the end of the program's path In-Reply-To: <1429379283.39.0.0511547854084.issue23994@psf.upfronthosting.co.za> Message-ID: <1429547383.8.0.305062313542.issue23994@psf.upfronthosting.co.za> Mert Bora Alper added the comment: > Thanks for the patch. We'll want a unit test for the behavior before committing this. You're welcome. Since I have no experience in writing unit tests, I don't really know where to start but I will try to do my best. I added bethard to the Nosy List, as he is the author of argparse's test. (In addition, you may want to change cpython/Lib/test/test_argparse.py:2163 ) ---------- nosy: +bethard _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 18:44:29 2015 From: report at bugs.python.org (Joe Jevnik) Date: Mon, 20 Apr 2015 16:44:29 +0000 Subject: [issue24014] Second pass of PyCode_Optimize In-Reply-To: <1429520960.11.0.0723675041232.issue24014@psf.upfronthosting.co.za> Message-ID: <1429548269.31.0.868169082737.issue24014@psf.upfronthosting.co.za> Joe Jevnik added the comment: I tried bumping the magic number; however, I still cannot get consistent results when running benchmark locally. I guess I will close this as I cannot consistently show an improvement. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 18:59:38 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Mon, 20 Apr 2015 16:59:38 +0000 Subject: [issue23955] Add python.ini file for embedded/applocal installs In-Reply-To: <1429038990.96.0.956334607163.issue23955@psf.upfronthosting.co.za> Message-ID: <1429549178.4.0.255958806017.issue23955@psf.upfronthosting.co.za> Changes by Thomas Kluyver : ---------- nosy: +takluyver _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 19:44:34 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Mon, 20 Apr 2015 17:44:34 +0000 Subject: [issue23955] Add python.ini file for embedded/applocal installs In-Reply-To: <1429038990.96.0.956334607163.issue23955@psf.upfronthosting.co.za> Message-ID: <1429551874.58.0.603827275565.issue23955@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Relative paths would be nice for Pynsist - I would prefer to create the config file at build time and then install it along with the other files. If it needed absolute paths, then the installer would have to write the config file after the user selects the installation directory. That's doable, but it's easier to write and test the build steps than the install steps. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 20:03:57 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 20 Apr 2015 18:03:57 +0000 Subject: [issue24001] Clinic: use raw types in types= set In-Reply-To: <1429405577.22.0.134829799978.issue24001@psf.upfronthosting.co.za> Message-ID: <1429553037.3.0.695848846107.issue24001@psf.upfronthosting.co.za> Larry Hastings added the comment: Attached is a patch implementing all my proposed changes here: * "types" is now renamed "accept" * it accepts a set of real Python types * there are placeholder types for buffer, robuffer, rwbuffer * "nullable=True" is gone, replaced with adding NoneType to accept={} ---------- Added file: http://bugs.python.org/file39145/larry.clinic.use.raw.types.3.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 20:04:22 2015 From: report at bugs.python.org (Larry Hastings) Date: Mon, 20 Apr 2015 18:04:22 +0000 Subject: [issue23920] Should Clinic have "nullable" or types=NoneType? In-Reply-To: <1428812661.52.0.406302391077.issue23920@psf.upfronthosting.co.za> Message-ID: <1429553062.2.0.803638238161.issue23920@psf.upfronthosting.co.za> Larry Hastings added the comment: I've implemented this change in the latest patch (#3) for #24001. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 20:28:23 2015 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 Apr 2015 18:28:23 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <1429554503.93.0.582907988127.issue23275@psf.upfronthosting.co.za> Mark Dickinson added the comment: > There is also no reason to break currently working code Agreed. To take one example, David Beazley's PyCon 2015 talk would have been broken by the suggested change! (See https://www.youtube.com/watch?v=MCs5OvhV9S4, at around the 42:17 mark.) If there's any code change resulting from this issue, I also think it should be to make assignment to `()` legal. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 21:22:47 2015 From: report at bugs.python.org (Mark Dickinson) Date: Mon, 20 Apr 2015 19:22:47 +0000 Subject: [issue24015] timeit should start with 1 loop, not 10 In-Reply-To: <1429536484.03.0.469371276206.issue24015@psf.upfronthosting.co.za> Message-ID: <1429557767.34.0.764220934016.issue24015@psf.upfronthosting.co.za> Mark Dickinson added the comment: Huh. I assumed that timeit was doing this already. +1 from me. Affects Python 3.4 and 3.5, too. taniyama:~ mdickinson$ time python -m timeit "import time; time.sleep(1.0)" 10 loops, best of 3: 1 sec per loop real 0m40.165s user 0m0.040s sys 0m0.024s ---------- nosy: +mark.dickinson versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 21:33:55 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 20 Apr 2015 19:33:55 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax Message-ID: <1429558435.86.0.159043579663.issue24017@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: haypo priority: normal severity: normal status: open title: Implemenation of the PEP 492 - Coroutines with async and await syntax versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 21:34:02 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 20 Apr 2015 19:34:02 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax Message-ID: <1429558442.63.0.787343276465.issue24017@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- hgrepos: +306 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 21:36:25 2015 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 20 Apr 2015 19:36:25 +0000 Subject: [issue24018] add a Generator ABC Message-ID: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> New submission from Stefan Behnel: Currently, CPython tends to assume that generators are always implemented by a Python function that uses the "yield" keyword. However, it is absolutely possible to implement generators as a protocol by adding send(), throw() and close() methods to an iterator. The problem is that these will usually be rejected by code that needs to distinguish generators from other input, e.g. in asyncio, as this code will commonly do a type check against types.GeneratorType. Instead, it should check for the expected protocol. The best way to achieve this is to extend the existing ABCs with a Generator ABC that external generator implementations can register on. Related to issue 24004 (asyncio). Asyncio could provide a backport copy of this for older Python versions. I assume this is considered a new feature that cannot be added to 3.4 anymore? ---------- components: Library (Lib) files: generator_abc.patch keywords: patch messages: 241675 nosy: gvanrossum, haypo, scoder, yselivanov priority: normal severity: normal status: open title: add a Generator ABC type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file39146/generator_abc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 21:37:04 2015 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 20 Apr 2015 19:37:04 +0000 Subject: [issue24004] avoid explicit generator type check in asyncio In-Reply-To: <1429438862.32.0.692811371536.issue24004@psf.upfronthosting.co.za> Message-ID: <1429558624.43.0.446914628018.issue24004@psf.upfronthosting.co.za> Stefan Behnel added the comment: I created issue 24018 for adding a Generator ABC to collections.abc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 21:37:47 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 20 Apr 2015 19:37:47 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax Message-ID: <1429558667.44.0.150928186352.issue24017@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +asvetlov, yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 21:38:45 2015 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 20 Apr 2015 19:38:45 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax Message-ID: <1429558725.33.0.140763525393.issue24017@psf.upfronthosting.co.za> Changes by Stefan Behnel : ---------- nosy: +scoder type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 21:40:48 2015 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 20 Apr 2015 19:40:48 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429558848.03.0.617119931461.issue24018@psf.upfronthosting.co.za> Guido van Rossum added the comment: It's missing tests. :-) Otherwise looks quite sensible. Also, shouldn't you override __subclasshook__ so you don't inherit it from Iterator? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 21:43:04 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 20 Apr 2015 19:43:04 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax Message-ID: <1429558984.74.0.892720345489.issue24017@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- hgrepos: -306 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 21:45:38 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 20 Apr 2015 19:45:38 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax Message-ID: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> New submission from Yury Selivanov: Here's the first patch (git diff master..await). Should be easier to review and work from there. ---------- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file39147/async_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 21:55:02 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 20 Apr 2015 19:55:02 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> Message-ID: <1429559702.59.0.858619662948.issue24017@psf.upfronthosting.co.za> Changes by Yury Selivanov : Removed file: http://bugs.python.org/file39147/async_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 21:55:23 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 20 Apr 2015 19:55:23 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> Message-ID: <1429559723.02.0.64525286872.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: Attaching a patch generated with mercurial ---------- Added file: http://bugs.python.org/file39148/await_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 21:55:43 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 20 Apr 2015 19:55:43 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> Message-ID: <1429559743.12.0.855337890467.issue24017@psf.upfronthosting.co.za> Changes by Yury Selivanov : Added file: http://bugs.python.org/file39149/await_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 21:56:16 2015 From: report at bugs.python.org (Yury Selivanov) Date: Mon, 20 Apr 2015 19:56:16 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> Message-ID: <1429559776.95.0.647460427425.issue24017@psf.upfronthosting.co.za> Changes by Yury Selivanov : Removed file: http://bugs.python.org/file39149/await_01.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 21:57:12 2015 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 20 Apr 2015 19:57:12 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429559832.42.0.782945226191.issue24018@psf.upfronthosting.co.za> Changes by Stefan Behnel : Removed file: http://bugs.python.org/file39146/generator_abc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 21:57:55 2015 From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=) Date: Mon, 20 Apr 2015 19:57:55 +0000 Subject: [issue16574] clarify policy on updates to final peps In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za> Message-ID: <1429559875.27.0.677537236456.issue16574@psf.upfronthosting.co.za> ?ric Araujo added the comment: Patch LGTM. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 21:58:05 2015 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 20 Apr 2015 19:58:05 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429559885.66.0.540240716308.issue24018@psf.upfronthosting.co.za> Stefan Behnel added the comment: Ok, sure. Here's a new patch that adds tests and docs. ---------- Added file: http://bugs.python.org/file39150/generator_abc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 22:01:15 2015 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 20 Apr 2015 20:01:15 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429560075.29.0.896692639313.issue24018@psf.upfronthosting.co.za> Changes by Stefan Behnel : Removed file: http://bugs.python.org/file39150/generator_abc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 22:01:44 2015 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 20 Apr 2015 20:01:44 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429560104.56.0.948851497618.issue24018@psf.upfronthosting.co.za> Stefan Behnel added the comment: Sorry, here's another doc fix. ---------- Added file: http://bugs.python.org/file39151/generator_abc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 22:11:22 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 20 Apr 2015 20:11:22 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429560682.25.0.82138495015.issue24018@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Is it a problem that the check can't be done in a fast way from C code? Other than that, sounds good to me. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 22:45:28 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 20 Apr 2015 20:45:28 +0000 Subject: [issue12606] Mutable Sequence Type works different for lists and bytearrays in slice[i:j:k] In-Reply-To: <1311287495.04.0.0852522537211.issue12606@psf.upfronthosting.co.za> Message-ID: <1429562728.5.0.945122355356.issue12606@psf.upfronthosting.co.za> Changes by Terry J. Reedy : ---------- stage: test needed -> patch review versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 22:45:29 2015 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Mon, 20 Apr 2015 20:45:29 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429562729.96.0.57483489325.issue24018@psf.upfronthosting.co.za> Changes by ?ukasz Langa : ---------- assignee: -> lukasz.langa nosy: +lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 22:46:20 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Mon, 20 Apr 2015 20:46:20 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1429562780.3.0.804469333959.issue22619@psf.upfronthosting.co.za> Dmitry Kazakov added the comment: Here's the documentation patch. ---------- Added file: http://bugs.python.org/file39152/traceback_limit_doc.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 22:47:44 2015 From: report at bugs.python.org (VanL) Date: Mon, 20 Apr 2015 20:47:44 +0000 Subject: [issue23989] Add recommendation to use requests to the documentation, per summit In-Reply-To: <1429295622.31.0.515179904566.issue23989@psf.upfronthosting.co.za> Message-ID: <1429562864.7.0.370887999309.issue23989@psf.upfronthosting.co.za> VanL added the comment: Given the generally positive comments, here are patches for 2.7, 3.3, 3.4, and 3.5 (3.5 patch updated to also include urllib.request). ---------- Added file: http://bugs.python.org/file39153/recommend_requests_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 23:00:23 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Mon, 20 Apr 2015 21:00:23 +0000 Subject: [issue6824] help for a module should list supported platforms In-Reply-To: <1251909781.63.0.685022567379.issue6824@psf.upfronthosting.co.za> Message-ID: <1429563623.87.0.161290661942.issue6824@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I agree. The resolution is that help fails for objects that do not exist on the platform. We do not supply non-functional dummy objects that only exist to document non-support. Any objects with undocumented platform-specific behavior should be handled on a case-by-case basis. ---------- resolution: -> works for me stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 23:25:58 2015 From: report at bugs.python.org (Christian Heimes) Date: Mon, 20 Apr 2015 21:25:58 +0000 Subject: [issue23989] Add recommendation to use requests to the documentation, per summit In-Reply-To: <1429295622.31.0.515179904566.issue23989@psf.upfronthosting.co.za> Message-ID: <1429565158.48.0.197724949715.issue23989@psf.upfronthosting.co.za> Changes by Christian Heimes : ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 23:43:13 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 20 Apr 2015 21:43:13 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> Message-ID: <1429566193.11.0.437778474375.issue24017@psf.upfronthosting.co.za> STINNER Victor added the comment: Does the implementation depends on the implementation of the PEP 479? (issue #22906) > Attaching a patch generated with mercurial Next time, if possible, try to skip generated files. Maybe write a script for that, but sorry I don't know how :-( ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 20 23:48:22 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 20 Apr 2015 21:48:22 +0000 Subject: [issue10308] Modules/getpath.c bugs In-Reply-To: <1288870063.75.0.834981100194.issue10308@psf.upfronthosting.co.za> Message-ID: <1429566502.1.0.508177520683.issue10308@psf.upfronthosting.co.za> STINNER Victor added the comment: > Reading msg120918 and msg120940 it looks as if work has been completed so this can be closed as fixed. Attached patch contains more fixes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 00:05:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 20 Apr 2015 22:05:08 +0000 Subject: [issue24001] Clinic: use raw types in types= set In-Reply-To: <1429405577.22.0.134829799978.issue24001@psf.upfronthosting.co.za> Message-ID: <1429567508.43.0.565407418372.issue24001@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Usually converters are named by the C type of the result. May be rename the "str" converter to "pchar"? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 00:22:43 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 20 Apr 2015 22:22:43 +0000 Subject: [issue23989] Add recommendation to use requests to the documentation, per summit In-Reply-To: <1429295622.31.0.515179904566.issue23989@psf.upfronthosting.co.za> Message-ID: <20150420222241.30337.14281@psf.io> Roundup Robot added the comment: New changeset c9239543235e by Benjamin Peterson in branch '3.4': recommend requests library (closes #23989) https://hg.python.org/cpython/rev/c9239543235e New changeset 3cf2990d19ab by Benjamin Peterson in branch '2.7': recommend requests library (closes #23989) https://hg.python.org/cpython/rev/3cf2990d19ab New changeset 65ce1d9eee30 by Benjamin Peterson in branch 'default': merge 3.4 (#23989) https://hg.python.org/cpython/rev/65ce1d9eee30 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 01:14:44 2015 From: report at bugs.python.org (Martin Panter) Date: Mon, 20 Apr 2015 23:14:44 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429571684.02.0.425475428305.issue24018@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 02:53:09 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 21 Apr 2015 00:53:09 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> Message-ID: <1429577589.45.0.381567672918.issue24017@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- dependencies: +PEP 479: Change StopIteration handling inside generators _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 03:20:18 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Apr 2015 01:20:18 +0000 Subject: [issue17445] Handle bytes comparisons in difflib.Differ In-Reply-To: <1363531378.76.0.0837150963685.issue17445@psf.upfronthosting.co.za> Message-ID: <20150421012015.22460.79350@psf.io> Roundup Robot added the comment: New changeset 1764d42b340d by Greg Ward in branch 'default': #17445: difflib: add diff_bytes(), to compare bytes rather than str https://hg.python.org/cpython/rev/1764d42b340d ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 03:22:35 2015 From: report at bugs.python.org (Greg Ward) Date: Tue, 21 Apr 2015 01:22:35 +0000 Subject: [issue17445] Handle bytes comparisons in difflib.Differ In-Reply-To: <1363531378.76.0.0837150963685.issue17445@psf.upfronthosting.co.za> Message-ID: <1429579355.36.0.626206892946.issue17445@psf.upfronthosting.co.za> Changes by Greg Ward : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 04:21:57 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 21 Apr 2015 02:21:57 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429582917.72.0.169396481175.issue24018@psf.upfronthosting.co.za> Raymond Hettinger added the comment: For the other ABCs, if you define the required abstract methods, you get working versions of all the mixin methods. In the case of the Generator ABC, throw() and close() are useless empty stub methods. In the other ABCs, we leave optional methods out entirely. A user should expect that if isinstance(g, Generator) is true that all of the ABC methods will work. Also, the return StopIteration in throw() doesn't seem correct. Shouldn't it raise the exception that was thrown? >>> def f(): yield x >>> g = f() >>> g.throw(KeyError) Traceback (most recent call last): File "", line 1, in g.throw(KeyError) File "", line 1, in f def f(): KeyError Ideally, there should be a practical example of where this ABC would be useful with anything other than a real generator. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 04:26:54 2015 From: report at bugs.python.org (Bhuvan Arumugam) Date: Tue, 21 Apr 2015 02:26:54 +0000 Subject: [issue1927] raw_input behavior incorrect if readline not enabled In-Reply-To: <1201206078.95.0.997961854688.issue1927@psf.upfronthosting.co.za> Message-ID: <1429583214.18.0.700317281144.issue1927@psf.upfronthosting.co.za> Bhuvan Arumugam added the comment: For the record, this bug is still open. The proposed patch is not merged in any of branches. The prompt for raw_input in all versions, go to stderr. ---------- nosy: +bhuvan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 04:30:09 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 21 Apr 2015 02:30:09 +0000 Subject: [issue23987] docs about containers membership testing wrong for broken objects In-Reply-To: <1429258165.63.0.284734084008.issue23987@psf.upfronthosting.co.za> Message-ID: <1429583409.32.0.576799115894.issue23987@psf.upfronthosting.co.za> Raymond Hettinger added the comment: There is a separate report for taking care of the identity check for contains: https://bugs.python.org/issue23986 I think notes about crazy hashes shouldn't spill all over our docs. At best, it warrants a FAQ entry about how hash tables work. The risk here is that in an effort to be more precise, it is easy impair the usability of the docs. The wording in question has been around for a very long time and has overall done a good job of explaining the intent of the in-operator to all but the most pedantic reader, "The operators 'in' and 'not in' test for membership. 'x in s' evaluates to true if x is a member of s, and false otherwise." If you really want to be precise, the *only* thing that can be broadly stated about the in-operator is that it calls __contains__ on an object that that object can implement whatever logic it wants (hash table lookup, linear search, google search, random result, etc). But then, this is no different than most magic methods in that regard. ---------- assignee: docs at python -> rhettinger nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 04:38:16 2015 From: report at bugs.python.org (William Orr) Date: Tue, 21 Apr 2015 02:38:16 +0000 Subject: [issue9246] os.getcwd() hardcodes max path len In-Reply-To: <1279023059.26.0.245683093399.issue9246@psf.upfronthosting.co.za> Message-ID: <1429583896.0.0.543848571224.issue9246@psf.upfronthosting.co.za> William Orr added the comment: I've incorporated some of the feedback from the reviews into this new patch. I used the PyMem_Raw* functions to do allocation to avoid having to acquire the GIL and also avoid complciations from the builtin memory allocator, since I'm not using python objects. I have also fixed a memory leak in my original patch, as well as a case where OSes with a small MAX_PATH fail with ENAMETOOLONG ---------- Added file: http://bugs.python.org/file39154/max_getcwd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 05:06:42 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 21 Apr 2015 03:06:42 +0000 Subject: [issue17445] Handle bytes comparisons in difflib.Differ In-Reply-To: <1363531378.76.0.0837150963685.issue17445@psf.upfronthosting.co.za> Message-ID: <1429585602.48.0.464990663726.issue17445@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 05:25:22 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 21 Apr 2015 03:25:22 +0000 Subject: [issue23974] random.randrange() biased output In-Reply-To: <1429211399.3.0.0363933708398.issue23974@psf.upfronthosting.co.za> Message-ID: <1429586722.35.0.157108241574.issue23974@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > we *still* have no documented guarantees of reproducibility, > so maybe it's safe to go ahead and change this. Raymond? It is documented here: https://docs.python.org/3/library/random.html#notes-on-reproducibility The idea that is that algorithms (and the generated sequences) may change in between minor releases, but not in micro releases. And random() itself if more restricted (guaranteed to be the same across minor releases as well). The policy was new in Python 3. It was a liberalization of the implied policy in Python 2 that we didn't change the sequences at all (except for flat-out brokenness). Accordingly, the #9025 debiasing was intentionally not backported so we won't break reproducibility and adversely affect performance of existing code. We could add a note as Mark suggests, but please keep it terse and affirmatively worded (perhaps something "See also: Recipe 31xx for a way to eliminate rounding biases in randrange()". The docs are not well served by being littered with Danger-signs and security warnings. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 05:59:19 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 21 Apr 2015 03:59:19 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> Message-ID: <1429588759.2.0.386749062387.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: Attaching a revised patch (all Victor's comments but asyncio changes) ---------- Added file: http://bugs.python.org/file39155/await_02.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 06:03:40 2015 From: report at bugs.python.org (Yury Selivanov) Date: Tue, 21 Apr 2015 04:03:40 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> Message-ID: <1429589020.79.0.277068223746.issue24017@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- assignee: -> yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 06:37:47 2015 From: report at bugs.python.org (Masayuki Yamamoto) Date: Tue, 21 Apr 2015 04:37:47 +0000 Subject: [issue8548] Building on CygWin 1.7: PATH_MAX redefined In-Reply-To: <1272386591.01.0.834578637911.issue8548@psf.upfronthosting.co.za> Message-ID: <1429591067.03.0.312002942349.issue8548@psf.upfronthosting.co.za> Masayuki Yamamoto added the comment: This issue resolved on default branch in #20597 . In 3.4 branch latest, PATH_MAX seems unused already in Modules/main.c:12 and Python/pythonrun.c:35. I want to cherry-pick #20597 to 3.4 branch. ---------- nosy: +masamoto _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 06:57:04 2015 From: report at bugs.python.org (Mahmoud Hashemi) Date: Tue, 21 Apr 2015 04:57:04 +0000 Subject: [issue24019] str/unicode encoding kwarg causes exceptions Message-ID: <1429592224.08.0.0993607651074.issue24019@psf.upfronthosting.co.za> New submission from Mahmoud Hashemi: The encoding keyword argument to the Python 3 str() and Python 2 unicode() constructors is excessively constraining to the practical use of these core types. Looking at common usage, both these constructors' primary mode is to convert various objects into text: >>> str(2) '2' But adding an encoding yields: >>> str(2, encoding='utf8') Traceback (most recent call last): File "", line 1, in TypeError: coercing to str: need bytes, bytearray or buffer-like object, int found While the error message is fine for an experienced developer, I would like to raise the question: is it necessary at all? Even harmlessly getting a str from a str is punished, but leaving off encoding is fine again: >>> str('hi', encoding='utf8') Traceback (most recent call last): File "", line 1, in TypeError: decoding str is not supported >>> str('hi') 'hi' Merging and simplifying the two modes of these constructors would yield much more predictable results for experienced and beginning Pythonists alike. Basically, the encoding argument should be ignored if the argument is already a unicode/str instance, or if it is a non-string object. It should only be consulted if the primary argument is a bytestring. Bytestrings already have a .decode() method on them, another, obscurer version of it isn't necessary. Furthermore, despite the core nature and widespread usage of these types, changing this behavior should break very little existing code and understanding. unicode() and str() will simply behave as expected more often, returning text versions of the arguments passed to them. Appendix: To demonstrate the expected behavior of the proposed unicode/str, here is a code snippet we've employed to sanely and safely get a text version of an arbitrary object: def to_unicode(obj, encoding='utf8', errors='strict'): # the encoding default should look at sys's value try: return unicode(obj) except UnicodeDecodeError: return unicode(obj, encoding=encoding, errors=errors) After many years of writing Python and teaching it to developers of all experience levels, I firmly believe that this is the right interaction pattern for Python's core text type. I'm also happy to expand on this issue, turn it into a PEP, or submit a patch if there is interest. ---------- components: Unicode messages: 241699 nosy: ezio.melotti, haypo, mahmoud priority: normal severity: normal status: open title: str/unicode encoding kwarg causes exceptions type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 06:57:55 2015 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 21 Apr 2015 04:57:55 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429592275.43.0.304511168809.issue24018@psf.upfronthosting.co.za> Stefan Behnel added the comment: Here's a new patch that addresses the review comments. I kept throw() and close() non-abstract and added an example to the tests instead that implements a minimal generator by inheriting these methods from the Generator base class, using it as a mixin. It only needs to implement send(). I don't think it's unreasonable to assume that there are use cases where a generator that is implemented in a class instead of a yield-function does not require special cleanup actions in its close()/throw(). Or is it *required* that a generator stops working when close() is called? There are also iterators that raise StopIteration at some point to signal that they are temporarily exhausted, but then eventually restart returning values from their __next__() method when they have received more to return. Avoids recreating the iterator object after each exhaustion cycle. I extended the default implementation of close() to call throw(GeneratorExit), though, because that's how the protocol is defined. Unless users implement throw(), it won't make a difference for them. And if they do, they may even get away with not reimplementing close(). ---------- Added file: http://bugs.python.org/file39156/generator_abc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 07:09:06 2015 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 21 Apr 2015 05:09:06 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429592946.12.0.197474172279.issue24018@psf.upfronthosting.co.za> Stefan Behnel added the comment: > Is it a problem that the check can't be done in a fast way from C code? C code can still quickly special case the generator type in the positive case, and it will usually be interested in an exact type match anyway. Determining that an object is *not* (compatible with) a generator might lead to some degradation, but in most cases, at least in the interpreter core, this would be an error case anyway, so being slower here should rarely hurt. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 07:11:02 2015 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 21 Apr 2015 05:11:02 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429593062.76.0.611224915138.issue24018@psf.upfronthosting.co.za> Stefan Behnel added the comment: Next question: should inspect.isgenerator() be changed? Or should its usages be replaced by isinstance(obj, Generator) ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 07:26:02 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Apr 2015 05:26:02 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429593962.56.0.604146287404.issue24018@psf.upfronthosting.co.za> Martin Panter added the comment: I agree that there is no big reason why we should force generators to stop working after close(). Your new default implementation of close() is probably the right thing too. I added a few new comments on Reitveld. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 08:10:31 2015 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 21 Apr 2015 06:10:31 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429596631.46.0.712298788259.issue24018@psf.upfronthosting.co.za> Stefan Behnel added the comment: Good catch with the RuntimeError. Patch updated. ---------- Added file: http://bugs.python.org/file39157/generator_abc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 08:35:10 2015 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 21 Apr 2015 06:35:10 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429598110.5.0.772374867813.issue24018@psf.upfronthosting.co.za> Stefan Behnel added the comment: > should inspect.isgenerator() be changed? Replying to myself, one thing that speaks against this approach is that "inspect" also has the functions "getgeneratorlocals()" and "getgeneratorstate()", which depend on "gen.gi_frame". Cython could emulate that, but normal user code usually can't. It's definitely not part of the Generator protocol but an implementation detail of GeneratorType. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 09:31:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Apr 2015 07:31:39 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <1429601499.81.0.64175580928.issue16840@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This didn't help. Actually we should turn on bignum support only since 8.5.8, because tclTomMath.h was broken before. But this is not related, because tclTomMath.h is not found itself on this buildbot. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 10:38:11 2015 From: report at bugs.python.org (Yann Sionneau) Date: Tue, 21 Apr 2015 08:38: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: <1429605491.79.0.403277977844.issue23630@psf.upfronthosting.co.za> Yann Sionneau added the comment: ping ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 10:47:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Apr 2015 08:47:53 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <1429606073.98.0.705946659787.issue16840@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Ah, we should also test full version of 8.6, because bignums was not supported in earlier alphas and betas (if I remember correctly, this buildbot uses beta version of 8.6). TK_VERSION_HEX packs fields in wrong order, not suitable for comparing of non-final releases. It's value for 8.6a3 is larger than 8.6.1. Here is a patch that adds TK_HEX_VERSION with correctly packed fields and turn off bignum support in non-final 8.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 10:49:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Apr 2015 08:49:10 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <1429606150.81.0.303805050647.issue16840@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: fixed -> stage: resolved -> patch review versions: +Python 2.7, Python 3.4 Added file: http://bugs.python.org/file39158/tkinter_hexversion.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 11:11:58 2015 From: report at bugs.python.org (Erik Cederstrand) Date: Tue, 21 Apr 2015 09:11:58 +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: <1429607518.58.0.22878434647.issue12006@psf.upfronthosting.co.za> Erik Cederstrand added the comment: I think POLA would be to raise ValueError on time.strptime('2015', '%G') and other situations that don't make sense or are ambiguous. That, or reproduce the bugs that the native OS strptime() implementation has. I got the %G, %V, and %u directives accepted for the next POSIX spec (http://austingroupbugs.net/view.php?id=879). But it will be years before operating systems catch up, so I would opt for the ValueError approach instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 11:45:17 2015 From: report at bugs.python.org (Harrison Grundy) Date: Tue, 21 Apr 2015 09:45:17 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1429609517.2.0.985301627247.issue15745@psf.upfronthosting.co.za> Harrison Grundy added the comment: The attached patch just explicitly cuts precision down for the test. It may be worth adding code to set "delta" to the expected level of precision for a given platform, rather than just universally saying "Microseconds are okay." ---------- nosy: +harrison.grundy Added file: http://bugs.python.org/file39159/almostequaltime.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 11:47:24 2015 From: report at bugs.python.org (koobs) Date: Tue, 21 Apr 2015 09:47:24 +0000 Subject: [issue15745] Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/ FFS, Solaris w/ UFS) In-Reply-To: <1345515355.02.0.72747216818.issue15745@psf.upfronthosting.co.za> Message-ID: <1429609644.07.0.605897686292.issue15745@psf.upfronthosting.co.za> Changes by koobs : ---------- components: +Tests keywords: +needs review stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 11:51:44 2015 From: report at bugs.python.org (koobs) Date: Tue, 21 Apr 2015 09:51:44 +0000 Subject: [issue16287] Sporadic test_utime() failures on Solaris In-Reply-To: <1350652599.36.0.707342371082.issue16287@psf.upfronthosting.co.za> Message-ID: <1429609904.07.0.558323897248.issue16287@psf.upfronthosting.co.za> Changes by koobs : ---------- nosy: +koobs _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 15:06:03 2015 From: report at bugs.python.org (Toshio Kuratomi) Date: Tue, 21 Apr 2015 13:06:03 +0000 Subject: [issue23966] More clearly expose/explain native and cross-build target information In-Reply-To: <1429115811.5.0.862888158961.issue23966@psf.upfronthosting.co.za> Message-ID: <1429621563.36.0.392201083626.issue23966@psf.upfronthosting.co.za> Toshio Kuratomi added the comment: Note for doko/barry: The multiarch/Tuples page should have a section on how the MultiArch Tuples interact with hwcaps (or a link to such a section in a different document). The rationale for not using Gnu-Triplets in MulitArch/Tuples currently says that we do not want separate entries for (as an example) i386 vs i686 instructions but does not tell why. https://wiki.debian.org/Multiarch/TheCaseForMultiarch#Mixed_ABIs_and_instruction_set_extensions says that the i386 vs i686 use case is probably better addressed by glibc's hwcaps but points back to MultiArch/Tuples for rationale. A section of rationale and example to show how the multiarch tuple and hwcaps complement each other would fix that. ---------- nosy: +a.badger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 15:21:24 2015 From: report at bugs.python.org (Eric V. Smith) Date: Tue, 21 Apr 2015 13:21:24 +0000 Subject: [issue24019] str/unicode encoding kwarg causes exceptions In-Reply-To: <1429592224.08.0.0993607651074.issue24019@psf.upfronthosting.co.za> Message-ID: <1429622484.43.0.883873800453.issue24019@psf.upfronthosting.co.za> Eric V. Smith added the comment: As this is an enhancement request, I've changed the versions. I'm opposed to this change. If I pass an encoding along with a type for which it makes no sense, I'd prefer an error instead of silently ignoring the encoding. I think your helper function is an appropriate solution to your problem. ---------- components: +Interpreter Core -Unicode nosy: +eric.smith type: behavior -> enhancement versions: -Python 2.7, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 15:42:25 2015 From: report at bugs.python.org (Ethan Furman) Date: Tue, 21 Apr 2015 13:42:25 +0000 Subject: [issue24020] threading.local() must be run at module level (doc improvement) Message-ID: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za> New submission from Ethan Furman: In order to work correctly, threading.local() must be run in global scope, yet that tidbit is missing from both the docs and the _threading_local.py file. Something like: .. note:: threading.local() must be run at global scope to function properly. That would have saved me hours of time. Thank goodness for SO! ;) ---------- assignee: docs at python messages: 241713 nosy: docs at python, ethan.furman priority: normal severity: normal status: open title: threading.local() must be run at module level (doc improvement) versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 16:00:21 2015 From: report at bugs.python.org (eryksun) Date: Tue, 21 Apr 2015 14:00:21 +0000 Subject: [issue24020] threading.local() must be run at module level (doc improvement) In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za> Message-ID: <1429624821.5.0.944414118077.issue24020@psf.upfronthosting.co.za> eryksun added the comment: Could you clarify what the problem is? I have no apparent problem using threading.local in a function scope: import threading def f(): tlocal = threading.local() tlocal.x = 0 def g(): tlocal.x = 1 print('tlocal.x in g:', tlocal.x) t = threading.Thread(target=g) t.start() t.join() print('tlocal.x in f:', tlocal.x) >>> f() tlocal.x in g: 1 tlocal.x in f: 0 ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 16:27:50 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Tue, 21 Apr 2015 14:27:50 +0000 Subject: [issue24020] threading.local() must be run at module level (doc improvement) In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za> Message-ID: <1429626470.53.0.659199633216.issue24020@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Also, don't use a ".. note::", regular sentences work fine, especially in documentation that is already very short. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 17:19:31 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 21 Apr 2015 15:19:31 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429629571.48.0.0289996634976.issue24018@psf.upfronthosting.co.za> Guido van Rossum added the comment: Is it an option to leave inspect alone? Its definition and use of generators is very focused on the builtin implementation. Although this means that code that wants to do the right thing but also be backwards compatible has to use something like ``` def isgen(g): if hasattr(collections.abc, 'Generator'): return isinstance(c, collections.abc.Generator) else: return inspect.isgenerator(g) ``` ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 17:43:36 2015 From: report at bugs.python.org (Karl Richter) Date: Tue, 21 Apr 2015 15:43:36 +0000 Subject: [issue24021] document urllib.urlretrieve Message-ID: <1429631016.67.0.905121028412.issue24021@psf.upfronthosting.co.za> Changes by Karl Richter : ---------- assignee: docs at python components: Documentation nosy: docs at python, krichter priority: normal severity: normal status: open title: document urllib.urlretrieve versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 17:44:02 2015 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 21 Apr 2015 15:44:02 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429631042.08.0.559354322468.issue24018@psf.upfronthosting.co.za> Stefan Behnel added the comment: Yes, code usually doesn't fall from the sky with a new CPython release. If something wants to make use of this ABC, it still has to find ways to also work with older CPythons. What would be a good fallback? A backport on PyPI? I wouldn't even mind shipping this class with Cython and dropping it right into "collections.abc" if it's missing. Cython already contains lots of compatibility code, and we need to patch *something* in all current CPythons either way. Then your code snippet would be the right thing to do for user code (with the twist that Py2.x doesn't have "collections.abc"...). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 17:44:53 2015 From: report at bugs.python.org (Ethan Furman) Date: Tue, 21 Apr 2015 15:44:53 +0000 Subject: [issue24020] threading.local() must be run at module level (doc improvement) In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za> Message-ID: <1429631093.8.0.165246986635.issue24020@psf.upfronthosting.co.za> Ethan Furman added the comment: Raymond, okay, thanks. Eryksun, I've written a FUSE file system (for $DAYJOB) and when I switched over to using threads I would occasionally experience errors such as 'thread.local object does not have attribute ...'; as soon as I found the SO answer and moved the call to 'threading.local()' to the global scope, the problem vanished. To reliably detect the problem I started approximately 10 threads, each getting an os.listdir() 1,000 times of an area on the FUSE. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 17:51:17 2015 From: report at bugs.python.org (Paul Moore) Date: Tue, 21 Apr 2015 15:51:17 +0000 Subject: [issue24020] threading.local() must be run at module level (doc improvement) In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za> Message-ID: <1429631477.73.0.153678192615.issue24020@psf.upfronthosting.co.za> Paul Moore added the comment: Link to the SO answer? Does it explain *why* this is a requirement? ---------- nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 18:04:01 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 21 Apr 2015 16:04:01 +0000 Subject: [issue24022] Python heap corruption issue Message-ID: <1429632241.9.0.734206220056.issue24022@psf.upfronthosting.co.za> New submission from Benjamin Peterson: Reported by "Hug Bounter" to security@ Hello, I would like to report a heap corruption issue in Python/Parser/tokenizer.c:922, affecting latest Python 3.4.3 (from python.org) and also 2.7 ( tested 2.7.9-r1 on Gentoo ). The latest version available - 3.5.0a3 is also affected. It doesn't seem to affect 3.3 branch (tested with 3.3.5-r1 on Gentoo). The issue occurs when a malformed python script is executed by python binary, which results in a out-of-bound read access of heap and therefore a segmentation fault. I couldn't confirm nor deny its exploitability, to my knowledge this would be more of a infoleak, if anything. Nevertheless, as Google Project Zero proved many times, no heap corruption issue should be treated lightheartedly. :-) Hence the reason why I'm reporting it to security at python.org I tried to dig into the details of the bug and I have to admit the defeat - the Python Parser is quite a complex beast... What I was able to determine was that given malformed script (attached), the infinite 'for' loop defined in tokenizer.c:900 never reaches any of the exit conditions, which causes a infinite incrementation of *tok->cur and thus reading character by character of the heap, until the heap segment boundary is reached and segmentation fault occurrs. There seem to be a race condition involved as well, as the malformed script does not always result in crash sometimes producing the error below: ./python ~/Fuzz/crashes/python_stuff/heap_pattern.py File "/home/user/Fuzz/crashes/python_stuff/heap_pattern.py", line 44 SyntaxError: Non-UTF-8 code starting with '\x9e' in file /home/user/Fuzz/crashes/python_stuff/heap_pattern.py on line 45, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details I acknowledge that attack scenario is somehow limited, because one has to be in a position to provide their own script for execution. Nevertheless, at the very least, a malicious user could crash python environment. Depending on the particular script, ASAN detects either as a 'heap-use-after-free' or 'heap-buffer-overflow'. HEAP-BUFFER-OVERFLOW according to asan: $ ./python ~/heap3.py ================================================================= ==23461==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62500001e0ff at pc 0xc90075 bp 0x7ffe53018fd0 sp 0x7ffe53018fc0 READ of size 1 at 0x62500001e0ff thread T0 #0 0xc90074 in tok_nextc Parser/tokenizer.c:1021 #1 0xc9a6ef in tok_get Parser/tokenizer.c:1341 #2 0xca0640 in PyTokenizer_Get Parser/tokenizer.c:1738 #3 0xc81109 in parsetok Parser/parsetok.c:208 #4 0xa0c449 in PyParser_ASTFromFileObject Python/pythonrun.c:2356 #5 0xa0c449 in PyRun_FileExFlags Python/pythonrun.c:2126 #6 0xa15f0b in PyRun_SimpleFileExFlags Python/pythonrun.c:1606 #7 0x43a1aa in run_file Modules/main.c:319 #8 0x43a1aa in Py_Main Modules/main.c:751 #9 0x4234d3 in main Modules/python.c:69 #10 0x7efcd1cf1f9f in __libc_start_main (/lib64/libc.so.6+0x1ff9f) #11 0x426a7c (/home/user/Fuzz/targets/Python-3.4.3_ASAN/python+0x426a7c) 0x62500001e0ff is located 1 bytes to the left of 8192-byte region [0x62500001e100,0x625000020100) allocated by thread T0 here: #0 0x7efcd29eb7c7 in malloc (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/libasan.so.1+0x577c7) #1 0xc9997a in PyTokenizer_FromFile Parser/tokenizer.c:852 SUMMARY: AddressSanitizer: heap-buffer-overflow Parser/tokenizer.c:1021 tok_nextc Shadow bytes around the buggy address: 0x0c4a7fffbbc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c4a7fffbbd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c4a7fffbbe0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c4a7fffbbf0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c4a7fffbc00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c4a7fffbc10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa[fa] 0x0c4a7fffbc20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c4a7fffbc30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c4a7fffbc40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c4a7fffbc50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c4a7fffbc60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Contiguous container OOB:fc ASan internal: fe ==23461==ABORTING Below is an example of ASAN detecting a 'use-after-free': ./python ~/heap4_asan.py ================================================================= ==23465==ERROR: AddressSanitizer: heap-use-after-free on address 0x62500001e101 at pc 0xc8f7c4 bp 0x7ffc35552000 sp 0x7ffc35551ff0 READ of size 1 at 0x62500001e101 thread T0 #0 0xc8f7c3 in tok_nextc Parser/tokenizer.c:902 #1 0xc9a96f in tok_get Parser/tokenizer.c:1429 #2 0xca0640 in PyTokenizer_Get Parser/tokenizer.c:1738 #3 0xc81109 in parsetok Parser/parsetok.c:208 #4 0xa0c449 in PyParser_ASTFromFileObject Python/pythonrun.c:2356 #5 0xa0c449 in PyRun_FileExFlags Python/pythonrun.c:2126 #6 0xa15f0b in PyRun_SimpleFileExFlags Python/pythonrun.c:1606 #7 0x43a1aa in run_file Modules/main.c:319 #8 0x43a1aa in Py_Main Modules/main.c:751 #9 0x4234d3 in main Modules/python.c:69 #10 0x7f71d129ef9f in __libc_start_main (/lib64/libc.so.6+0x1ff9f) #11 0x426a7c (/home/user/Fuzz/targets/Python-3.4.3_ASAN/python+0x426a7c) 0x62500001e101 is located 1 bytes inside of 8192-byte region [0x62500001e100,0x625000020100) freed by thread T0 here: #0 0x7f71d1f98aa6 in __interceptor_realloc (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/libasan.so.1+0x57aa6) #1 0xc8edb1 in tok_nextc Parser/tokenizer.c:1041 previously allocated by thread T0 here: #0 0x7f71d1f987c7 in malloc (/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/libasan.so.1+0x577c7) #1 0xc9997a in PyTokenizer_FromFile Parser/tokenizer.c:852 SUMMARY: AddressSanitizer: heap-use-after-free Parser/tokenizer.c:902 tok_nextc Shadow bytes around the buggy address: 0x0c4a7fffbbd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c4a7fffbbe0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c4a7fffbbf0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c4a7fffbc00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c4a7fffbc10: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c4a7fffbc20:[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c4a7fffbc30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c4a7fffbc40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c4a7fffbc50: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c4a7fffbc60: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c4a7fffbc70: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Contiguous container OOB:fc ASan internal: fe ==23465==ABORTING Without AddressSanitizer, this particular script does not crash, but causes one of two errors: File "/home/user/heap4_asan.py", line 5 SyntaxError: Non-UTF-8 code starting with '\x9e' in file /home/user/heap4_asan.py on line 6, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details or: File "/home/user/heap4_asan.py", line 5 SyntaxError: unknown decode error In all cases, the crash always occurs in Parser/tokenizer.c at line no. 922, where *tok->curr is incremented, regardless where it currently points. Eventually, it will reach heap boundary and the *tok->cur++ will cause python to crash. Program received signal SIGSEGV, Segmentation fault. 0x0000000000573657 in tok_nextc (tok=tok at entry=0x8fb250) at Parser/tokenizer.c:922 922 return Py_CHARMASK(*tok->cur++); Sample GDB session can be found below: $ gdb --args ./python ~/heap1.py GNU gdb (Gentoo 7.9 vanilla) 7.9 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./python...done. warning: File "/home/user/Fuzz/targets/Python-3.4.3/python-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /home/user/Fuzz/targets/Python-3.4.3/python-gdb.py line to your configuration file "/home/user/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/home/user/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" gdb-peda$ r Starting program: /home/user/Fuzz/targets/Python-3.4.3/python /home/user/heap1.py [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. [----------------------------------registers-----------------------------------] RAX: 0x995001 RBX: 0x963c40 --> 0x0 RCX: 0x0 RDX: 0x27 ("'") RSI: 0x0 RDI: 0x963c40 --> 0x0 RBP: 0x0 RSP: 0x7fffffffdf40 --> 0x7ffff6f14660 --> 0x0 RIP: 0x573657 (: movzx eax,BYTE PTR [r12]) R8 : 0x1bdf0 R9 : 0x1bde0 R10: 0x1bdd0 R11: 0x4 R12: 0x995000 R13: 0x0 R14: 0x7fffffffe010 --> 0x0 R15: 0x0 EFLAGS: 0x10216 (carry PARITY ADJUST zero sign trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] 0x57364a : mov QWORD PTR [rbx+0x10],rax 0x57364e : lea rax,[r12+0x1] 0x573653 : mov QWORD PTR [rbx+0x8],rax => 0x573657 : movzx eax,BYTE PTR [r12] 0x57365c : add rsp,0x18 0x573660 : pop rbx 0x573661 : pop rbp 0x573662 : pop r12 [------------------------------------stack-------------------------------------] 0000| 0x7fffffffdf40 --> 0x7ffff6f14660 --> 0x0 0008| 0x7fffffffdf48 --> 0x57107e (: mov rsi,rax) 0016| 0x7fffffffdf50 --> 0x7ffff6f14660 --> 0x0 0024| 0x7fffffffdf58 --> 0x27 ("'") 0032| 0x7fffffffdf60 --> 0x963c40 --> 0x0 0040| 0x7fffffffdf68 --> 0x3 0048| 0x7fffffffdf70 --> 0x0 0056| 0x7fffffffdf78 --> 0x7fffffffe010 --> 0x0 [------------------------------------------------------------------------------] Legend: code, data, rodata, value Stopped reason: SIGSEGV 0x0000000000573657 in tok_nextc (tok=tok at entry=0x963c40) at Parser/tokenizer.c:922 922 return Py_CHARMASK(*tok->cur++); Thank you for reading this. Please let me know if you need more information. ---------- components: Interpreter Core messages: 241720 nosy: benjamin.peterson priority: high severity: normal status: open title: Python heap corruption issue type: crash versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 18:07:14 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Apr 2015 16:07:14 +0000 Subject: [issue24022] Python heap corruption issue In-Reply-To: <1429632241.9.0.734206220056.issue24022@psf.upfronthosting.co.za> Message-ID: <20150421160710.30339.7720@psf.io> Roundup Robot added the comment: New changeset 414e08c478f4 by Benjamin Peterson in branch '3.4': do not call into python api if an exception is set (#24022) https://hg.python.org/cpython/rev/414e08c478f4 New changeset 03b2259c6cd3 by Benjamin Peterson in branch 'default': merge 3.4 (#24022) https://hg.python.org/cpython/rev/03b2259c6cd3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 18:09:07 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Apr 2015 16:09:07 +0000 Subject: [issue24022] Python heap corruption issue In-Reply-To: <1429632241.9.0.734206220056.issue24022@psf.upfronthosting.co.za> Message-ID: <1429632547.96.0.0518802823255.issue24022@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Where are test scripts? ---------- nosy: +serhiy.storchaka versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 18:10:08 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 21 Apr 2015 16:10:08 +0000 Subject: [issue24022] Python heap corruption issue In-Reply-To: <1429632241.9.0.734206220056.issue24022@psf.upfronthosting.co.za> Message-ID: <1429632608.94.0.880549454819.issue24022@psf.upfronthosting.co.za> Changes by Benjamin Peterson : Added file: http://bugs.python.org/file39160/f69354561u44075.zip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 18:10:33 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 21 Apr 2015 16:10:33 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429632633.01.0.84217953766.issue24018@psf.upfronthosting.co.za> Guido van Rossum added the comment: Realistically only Cython will care much about this, so I'm okay if Cython just monkeypatches the collections package. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 18:19:21 2015 From: report at bugs.python.org (Ethan Furman) Date: Tue, 21 Apr 2015 16:19:21 +0000 Subject: [issue24020] threading.local() must be run at module level (doc improvement) In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za> Message-ID: <1429633161.55.0.0797261151345.issue24020@psf.upfronthosting.co.za> Ethan Furman added the comment: http://stackoverflow.com/q/1408171/208880 No, it just says (towards the top): ---------------------------------- > One important thing that everybody seems to neglect to mention is that writing > threadLocal = threading.local() at the global level is required. Calling > threading.local() within the worker function will not work. It is now my experience that "will not work" (reliably) is accurate. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 18:49:09 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 21 Apr 2015 16:49:09 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429634949.64.0.894762962925.issue24018@psf.upfronthosting.co.za> Antoine Pitrou added the comment: In some distant future, Numba might also care too :) (right now, we only support compiling basic generators, i.e. no send() and no throw()) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 19:26:55 2015 From: report at bugs.python.org (Ethan Furman) Date: Tue, 21 Apr 2015 17:26:55 +0000 Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za> Message-ID: <1429637215.05.0.960600333784.issue15582@psf.upfronthosting.co.za> Ethan Furman added the comment: I know it will take some time to add doc strings to places where they are missing, but I would not roll-back the patch for that. File new issues and get the over-riding methods properly documented. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 19:29:51 2015 From: report at bugs.python.org (Ethan Furman) Date: Tue, 21 Apr 2015 17:29:51 +0000 Subject: [issue23008] pydoc enum.{,Int}Enum fails In-Reply-To: <1418018648.34.0.0967171282391.issue23008@psf.upfronthosting.co.za> Message-ID: <1429637391.89.0.817541761645.issue23008@psf.upfronthosting.co.za> Ethan Furman added the comment: Patch looks good, get it in! :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 20:11:48 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Apr 2015 18:11:48 +0000 Subject: [issue23008] pydoc enum.{,Int}Enum fails In-Reply-To: <1418018648.34.0.0967171282391.issue23008@psf.upfronthosting.co.za> Message-ID: <20150421181145.98622.18067@psf.io> Roundup Robot added the comment: New changeset d1b9eb9de8af by Serhiy Storchaka in branch '2.7': Issue #23008: Fixed resolving attributes with boolean value is False in pydoc. https://hg.python.org/cpython/rev/d1b9eb9de8af New changeset a480f470c469 by Serhiy Storchaka in branch '3.4': Issue #23008: Fixed resolving attributes with boolean value is False in pydoc. https://hg.python.org/cpython/rev/a480f470c469 New changeset 03330e5edb37 by Serhiy Storchaka in branch 'default': Issue #23008: Fixed resolving attributes with boolean value is False in pydoc. https://hg.python.org/cpython/rev/03330e5edb37 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 20:12:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Apr 2015 18:12:13 +0000 Subject: [issue23008] pydoc enum.{,Int}Enum fails In-Reply-To: <1418018648.34.0.0967171282391.issue23008@psf.upfronthosting.co.za> Message-ID: <1429639933.15.0.160219840621.issue23008@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 20:18:04 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Apr 2015 18:18:04 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <20150421181801.22478.20925@psf.io> Roundup Robot added the comment: New changeset 5116916e4f7f by Serhiy Storchaka in branch '2.7': Issue #16840. Turn off bignum support in tkinter with with Tcl earlier than 8.5.8 https://hg.python.org/cpython/rev/5116916e4f7f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 20:31:12 2015 From: report at bugs.python.org (Mahmoud Hashemi) Date: Tue, 21 Apr 2015 18:31:12 +0000 Subject: [issue24019] str/unicode encoding kwarg causes exceptions In-Reply-To: <1429592224.08.0.0993607651074.issue24019@psf.upfronthosting.co.za> Message-ID: <1429641072.79.0.86637985213.issue24019@psf.upfronthosting.co.za> Mahmoud Hashemi added the comment: Python already has one approach that fails to decode non-bytestrings: the .decode() method. This is about removing unicode barriers to entry and making the str constructor in Python 3 as succinctly useful as possible. There are several problems the helper does not solve: 1) Usage-wise, str/unicode is used to turn values into text. From a high-level perspective, the content does not change, only the representation format. Should this fundamental operation really require type inspection and explicit try/except blocks every single time? Or should it just work? sorted() does not raise an exception if the values are already sorted, why does str() raise an exception when the value is already a str?* 2) By and large, among developers, keyword arguments are viewed as "optional" arguments that have defaults which can be overridden. However, that is not the case here; str is not simply str(obj, encoding=sys.getdefaultencoding()). Explicitly passing the keyword argument breaks the call. 3) The helper does not help promote Python adoption when it must be copied and pasted it into new developer's projects. It does not help break down the misconception that unicode is a punishing concept to be around in Python. * This question is posed here rhetorically, but I have gotten variations on it from multiple Python developers in training. ---------- versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 20:33:32 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 21 Apr 2015 18:33:32 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1429641212.38.0.226934329651.issue22619@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: As francismb noted, there are too long lines in the patch. They should be wrapped. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 20:48:08 2015 From: report at bugs.python.org (Paul Moore) Date: Tue, 21 Apr 2015 18:48:08 +0000 Subject: [issue24020] threading.local() must be run at module level (doc improvement) In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za> Message-ID: <1429642088.98.0.304114133709.issue24020@psf.upfronthosting.co.za> Paul Moore added the comment: That seems to merely be saying that each threading.local() object is distinct, so if you want to share threadlocal data between workers, creating local objects won't work. I think I see what the confusion is (although I can't quite explain it yet, I'll need to think some more about it) but "threading.local() needs to be run at global scope" is not accurate (for example, if I understand correctly, a class attribute which is a threading.local value would work fine, and it's not "global scope". Basically, each time you call threading.local() you get a brand new object. It looks like a dictionary, but in fact it's a *different* dictionary for each thread. Within one thread, though, you can have multiple threading.local() objects, and they are independent. The "wrong" code in the SO discussion created a new threading-local() object as a local variable in a function, and tried to use it to remember state from one function call to the next (like a C static variable). That would be just as wrong in a single-threaded program where you used dict() instead of threading.local(), and for the same reasons. I don't know what your code was doing, so it may well be that the problem you were encountering was more subtle than the one on the wont_work() function. But "threading.local() must be run in global scope" is *not* the answer (even if doing that resulted in your problem going away). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 20:48:59 2015 From: report at bugs.python.org (Paul Moore) Date: Tue, 21 Apr 2015 18:48:59 +0000 Subject: [issue24020] threading.local() must be run at module level (doc improvement) In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za> Message-ID: <1429642139.64.0.605001315496.issue24020@psf.upfronthosting.co.za> Paul Moore added the comment: I should also say, I'll try to work up a doc patch for this, once I've got my head round how to explain it :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 21:11:41 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 21 Apr 2015 19:11:41 +0000 Subject: [issue24020] threading.local() must be run at module level (doc improvement) In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za> Message-ID: <1429643501.58.0.53381308846.issue24020@psf.upfronthosting.co.za> Eric Snow added the comment: FYI, I've used thread-local namespaces with success in several different ways and none of them involved binding the thread-local namespace to global scope. I don't think anything needs to be fixed here. The SO answer is misleading and perhaps even wrong. The problem it describes is about sharing the thread-local NS *between function calls*. Persisting state between function calls is not a new or mysterious problem, nor unique to thread-local namespaces. In the example they give, rather than a global they could have put it into a default arg or into a class: def hi(threadlocal=threading.local()): ... class Hi: threadlocal = threading.local() def __call__(self): ... # change threadlocal to self.threadlocal hi = Hi() This is simply a consequence of Python's normal scoping rules (should be unsurprising) and the fact that threading.local is a class (new instance per call) rather than a function (with the assumption of a singleton namespace per thread). At most the docs could be a little more clear that threading.local() produces a new namespace each time. However, I don't think even that is necessary and suggest closing this as won't fix. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 21:24:03 2015 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 21 Apr 2015 19:24:03 +0000 Subject: [issue21483] Skip os.utime() test on NFS? In-Reply-To: Message-ID: <1429644243.6.0.763304819022.issue21483@psf.upfronthosting.co.za> Skip Montanaro added the comment: Any chance this will make it into 3.5? It's not a big deal, but I notice that it's still present in 3.5.0a4. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 21:39:16 2015 From: report at bugs.python.org (Stefan Behnel) Date: Tue, 21 Apr 2015 19:39:16 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429645156.84.0.570190279949.issue24018@psf.upfronthosting.co.za> Stefan Behnel added the comment: Yes, and there are certainly other compilers and tools. However, it's going to be a short list, so if Py3.5 takes the lead, they can all just agree on the one way to do it and let the first patcher win. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 21:52:27 2015 From: report at bugs.python.org (Paul Moore) Date: Tue, 21 Apr 2015 19:52:27 +0000 Subject: [issue24020] threading.local() must be run at module level (doc improvement) In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za> Message-ID: <1429645947.91.0.01405590721.issue24020@psf.upfronthosting.co.za> Paul Moore added the comment: You're right, the SO answer is simply wrong. I've posted a (hopefully clearer) answer. If anyone wants to check it for accuracy, that'd be great. Agreed this can probably be closed as "not a bug". On first reading, I thought the docs could do with clarification, but now I think that was just because I had been confused by the SO posting :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 21:56:42 2015 From: report at bugs.python.org (Larry Hastings) Date: Tue, 21 Apr 2015 19:56:42 +0000 Subject: [issue21483] Skip os.utime() test on NFS? In-Reply-To: Message-ID: <1429646202.58.0.22860204876.issue21483@psf.upfronthosting.co.za> Larry Hastings added the comment: Issac doesn't have commit bit... ... but you do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 22:00:35 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Tue, 21 Apr 2015 20:00:35 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1429646435.7.0.202062010056.issue22619@psf.upfronthosting.co.za> Dmitry Kazakov added the comment: Thanks, completely missed the abs(limit) part. Here's the updated documentation patch. ---------- Added file: http://bugs.python.org/file39161/traceback_limit_doc_rev.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 22:10:13 2015 From: report at bugs.python.org (Skip Montanaro) Date: Tue, 21 Apr 2015 20:10:13 +0000 Subject: [issue21483] Skip os.utime() test on NFS? In-Reply-To: <1429646202.58.0.22860204876.issue21483@psf.upfronthosting.co.za> Message-ID: Skip Montanaro added the comment: On Tue, Apr 21, 2015 at 2:56 PM, Larry Hastings wrote: > Issac doesn't have commit bit... > > ... but you do. Alas, my commit bit long ago fell into disuse. I haven't checked anything in since long before the days of Mercurial and the current workflow. I would almost certainly mess something up. In fact, to avoid confusion in the future, removal of my commit bit might not be a bad idea. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 22:11:07 2015 From: report at bugs.python.org (paul j3) Date: Tue, 21 Apr 2015 20:11:07 +0000 Subject: [issue23994] argparse fails to detect program name when there is a slash at the end of the program's path In-Reply-To: <1429379283.39.0.0511547854084.issue23994@psf.upfronthosting.co.za> Message-ID: <1429647067.94.0.94921306475.issue23994@psf.upfronthosting.co.za> paul j3 added the comment: This overlaps with http://bugs.python.org/issue22240 argparse support for "python -m module" in help This issue also tries to handle zip files as well. Deducing the `prog` was moved to a separate function. One challenge with that issue was constructing a test framework. Here the testing might simpler since the `foo/` directory doesn't have to exist (or at least we can fake it with a custom `sys.argv`). ---------- nosy: +paul.j3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 22:14:20 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Tue, 21 Apr 2015 20:14:20 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1429647260.62.0.218676224768.issue22619@psf.upfronthosting.co.za> Changes by Dmitry Kazakov : Removed file: http://bugs.python.org/file39161/traceback_limit_doc_rev.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 22:22:45 2015 From: report at bugs.python.org (Jeff McNeil) Date: Tue, 21 Apr 2015 20:22:45 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1429647765.27.0.303125640921.issue23863@psf.upfronthosting.co.za> Jeff McNeil added the comment: Fixing the underlying connect call should also address EINTR failing with a "operation already in progress" when a connect+timeout fails due to a signal. I can understand not addressing EINTR generically (though it is already partially addressed in 2.7's socket.py - this just completes it), but IMO, not handling it on connect & responding with a seemingly unrelated error is the wrong thing to do. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 22:29:47 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Tue, 21 Apr 2015 20:29:47 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1429648187.6.0.649020111.issue22619@psf.upfronthosting.co.za> Changes by Dmitry Kazakov : Added file: http://bugs.python.org/file39162/traceback_limit_doc_rev2.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 22:42:11 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 21 Apr 2015 20:42:11 +0000 Subject: [issue10435] Document unicode C-API in reST In-Reply-To: <1289924206.67.0.561264270455.issue10435@psf.upfronthosting.co.za> Message-ID: <1429648931.57.0.0939805584896.issue10435@psf.upfronthosting.co.za> Mark Lawrence added the comment: I've looked at c-api/unicode.rst and I can't see any correlation between it and the names listed here in msg121302. So either this was never completed or it's been all change in the mean time, so could somebody take a look please. ---------- nosy: +BreamoreBoy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 22:50:59 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 21 Apr 2015 20:50:59 +0000 Subject: [issue6731] Add option of non-zero exit status of setup.py when building of extensions has failed In-Reply-To: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za> Message-ID: <1429649459.35.0.566398292594.issue6731@psf.upfronthosting.co.za> Mark Lawrence added the comment: I'm assuming that this will not be implemented until 3.6. ---------- nosy: +BreamoreBoy versions: +Python 3.6 -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 22:54:56 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 21 Apr 2015 20:54:56 +0000 Subject: [issue20035] Clean up Tcl library discovery in Tkinter on Windows In-Reply-To: <1387557050.08.0.350325342144.issue20035@psf.upfronthosting.co.za> Message-ID: <1429649696.86.0.749427344462.issue20035@psf.upfronthosting.co.za> Mark Lawrence added the comment: ping. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 23:38:09 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 21 Apr 2015 21:38:09 +0000 Subject: [issue10435] Document unicode C-API in reST In-Reply-To: <1289924206.67.0.561264270455.issue10435@psf.upfronthosting.co.za> Message-ID: <1429652289.66.0.0562039059001.issue10435@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Mark, Unicode C-APIs have changed a lot since this issue was opened, but I think many of the listed functions are still present but not properly documented. You can help by checking the Include/unicode.h file and compiling a list of functions that are there, don't start with _ and not documented in the reference manual. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 23:40:28 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Tue, 21 Apr 2015 21:40:28 +0000 Subject: [issue10435] Document unicode C-API in reST In-Reply-To: <1289924206.67.0.561264270455.issue10435@psf.upfronthosting.co.za> Message-ID: <1429652428.42.0.215415780265.issue10435@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Sorry for the broken link, the correct header file is Include/unicodeobject.h ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 23:43:59 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 21 Apr 2015 21:43:59 +0000 Subject: [issue10435] Document unicode C-API in reST In-Reply-To: <1289924206.67.0.561264270455.issue10435@psf.upfronthosting.co.za> Message-ID: <1429652639.82.0.363139839379.issue10435@psf.upfronthosting.co.za> Mark Lawrence added the comment: Okay Alexander I'll give it a go, but not tonight :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 21 23:53:42 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 21 Apr 2015 21:53:42 +0000 Subject: [issue24020] threading.local() must be run at module level (doc improvement) In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za> Message-ID: <1429653222.53.0.698810110892.issue24020@psf.upfronthosting.co.za> Changes by Eric Snow : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 00:11:31 2015 From: report at bugs.python.org (Ethan Furman) Date: Tue, 21 Apr 2015 22:11:31 +0000 Subject: [issue24020] threading.local() must be run at module level (doc improvement) In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za> Message-ID: <1429654291.69.0.531040420652.issue24020@psf.upfronthosting.co.za> Ethan Furman added the comment: Here's a basic outline of what I was trying: ------------------------------------------- CONTEXT = None class MyFUSE(Fuse): def __call__(self, op, path, *args): global CONTEXT ... CONTEXT = threading.local() # set several CONTEXT vars ... # dispatch to correct function to handle 'op' Under stress, I would eventually get threading.local objects that were missing attributes. Points to consider: - I have no control over the threads; they just arrive wanting their 'op's fulfilled - the same thread can be a repeat customer, but with the above scenario they would/should get a new threading.local each time Hmmm... could my problem be that even though function locals are thread-safe, the globals are not, so trying to create a threading.local via a global statement was clobbering other threading.local instances? While that would make sense, I'm still completely clueless why having a single global statement, which (apparently) creates a single threading.local object, could be distinct for all the threads... unless, of course, it can detect which thread is accessing it and react appropriately. Okay, that's really cool. So I was doing two things wrong: - calling threading.local() inside a function (although this would probably work if I then passed that object around, as I do not need to persist state across function calls -- wait, that would be the same as using an ordinary, function-local dict, wouldn't it?) - attempting to assign the threading.local object to a global variable from inside a function (this won't work, period) Many thanks for helping me figure that out. Paul, in your SO answer you state: --------------------------------- Just like an ordinary object, you can create multiple threading.local instances in your code. They can be local variables, class or instance members, or global variables. - Local variables are already thread-safe, aren't they? So there would be no point in using threading.local() there. - Instance members (set from __init__ of someother method): wouldn't that be the same problem I was having trying to update a non-threadsafe global with a new threading.local() each time? It seems to me the take-away here is that you only want to create a threading.local() object /once/ -- if you are creating the same threading.local() object more than once, you're doing it wrong. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 00:25:30 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 21 Apr 2015 22:25:30 +0000 Subject: [issue24020] threading.local() must be run at module level (doc improvement) In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za> Message-ID: <1429655130.24.0.239549024623.issue24020@psf.upfronthosting.co.za> Eric Snow added the comment: @Ethan, it may help you to read through the module docstring in Lib/_threading_local.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 00:29:57 2015 From: report at bugs.python.org (Paul Moore) Date: Tue, 21 Apr 2015 22:29:57 +0000 Subject: [issue24020] threading.local() must be run at module level (doc improvement) In-Reply-To: <1429654291.69.0.531040420652.issue24020@psf.upfronthosting.co.za> Message-ID: Paul Moore added the comment: On 21 April 2015 at 23:11, Ethan Furman wrote: > Hmmm... could my problem be that even though function locals are thread-safe, the globals are not, so trying to create a threading.local via a global statement was clobbering other threading.local instances? While that would make sense, I'm still completely clueless why having a single global statement, which (apparently) creates a single threading.local object, could be distinct for all the threads... unless, of course, it can detect which thread is accessing it and react appropriately. Okay, that's really cool. You're not creating a single threading object. You're creating one each call() and overwriting the old one. > So I was doing two things wrong: > - calling threading.local() inside a function (although this would > probably work if I then passed that object around, as I do not > need to persist state across function calls -- wait, that would > be the same as using an ordinary, function-local dict, wouldn't > it?) Yes, a dict should be fine if you're only using it within the one function call. > - attempting to assign the threading.local object to a global > variable from inside a function (this won't work, period) It does work, it's just there isn't *the* object, there's lots and you keep overwriting. The thread safety issue is that if you write over the global in one thread, before another thread has finished, you lose the second thread's values (because they were on the old, lost, namespace. So basically you'd see unpredictable, occasional losses of all your CONTEXT vars in a thread. > Many thanks for helping me figure that out. (If you did :-) - hope the clarifications above helped). > Paul, in your SO answer you state: > --------------------------------- > Just like an ordinary object, you can create multiple threading.local instances in your code. They can be local variables, class or instance members, or global variables. > > - Local variables are already thread-safe, aren't they? So there > would be no point in using threading.local() there. Not unless you're going to return them from your function, or something like that. But yes, it's unlikely they will be needed there. I only mentioned it to avoid giving any impression that "only set at global scope" was important. > - Instance members (set from __init__ of someother method): wouldn't > that be the same problem I was having trying to update a > non-threadsafe global with a new threading.local() each time? You'd set vars on the namespace held in the instance variable. It's much like the local variable case, except you are more likely to pass an instance around between threads. > It seems to me the take-away here is that you only want to create a threading.local() object /once/ -- if you are creating the same threading.local() object more than once, you're doing it wrong. Well, sort of. You can only create *any* object once :-) There seems to be a confusion (in the SO thread and with you, maybe) that threading.local objects are somehow singletons in that you "create" them repeatedly and get the same object. That's just wrong - they are entirely normal objects, that you can set arbitrary attributes on. The only difference is that each thread sees an independent set of attributes on the object. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 00:34:42 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 21 Apr 2015 22:34:42 +0000 Subject: [issue24020] threading.local() must be run at module level (doc improvement) In-Reply-To: <1429623745.88.0.884525571571.issue24020@psf.upfronthosting.co.za> Message-ID: <1429655682.28.0.603601265872.issue24020@psf.upfronthosting.co.za> Eric Snow added the comment: Think of threading.local this way: instances of threading.local are shared between all the threads, but the effective "__dict__" of each instance is per-thread. Basically, the object stores a dict for each thread. In __getattribute__, __setattr__, and __delattr__ it swaps the dict for the current thread into place and then does proceeds normally. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 01:14:20 2015 From: report at bugs.python.org (Martin Panter) Date: Tue, 21 Apr 2015 23:14:20 +0000 Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za> Message-ID: <1429658060.64.0.313406042402.issue15582@psf.upfronthosting.co.za> Martin Panter added the comment: My example was taken from a package that tends to ?properly document? everything in separate documentation files, rather than in the source code. I don?t really think Python should dictate if and how one document their code based on what base classes they use, and pydoc is still useful with code that has no doc strings. But if this is to be the way of the future, perhaps a warning in the ?What?s New? page might be a good idea. The inspect.getdoc() documentation should probably also have a ?Changed in version 3.5? warning. I guess it would be less automatic, but maybe another option might have been to add an @inherit_docstring decorator, or some explicit way to say a particular API (re)implements an (abstract) API documented elsewhere. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 01:25:52 2015 From: report at bugs.python.org (=?utf-8?q?Ra=C3=BAl_Cumplido?=) Date: Tue, 21 Apr 2015 23:25:52 +0000 Subject: [issue21327] socket.type value changes after using settimeout() In-Reply-To: <1398167707.44.0.251945553674.issue21327@psf.upfronthosting.co.za> Message-ID: <1429658752.95.0.283082495731.issue21327@psf.upfronthosting.co.za> Ra?l Cumplido added the comment: ping, any comment on the patch that was provided during the PyCon 2015 sprints? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 01:47:02 2015 From: report at bugs.python.org (Roundup Robot) Date: Tue, 21 Apr 2015 23:47:02 +0000 Subject: [issue15183] it should be made clear that the statement in the --setup option and the setup kw arg aren't included in the count In-Reply-To: <1340647320.14.0.672684715585.issue15183@psf.upfronthosting.co.za> Message-ID: <20150421234659.18895.73411@psf.io> Roundup Robot added the comment: New changeset e0e3d2ec56b6 by Andrew Kuchling in branch '3.4': #15183: clarify timeit documentation to say that setup statement isn't timed https://hg.python.org/cpython/rev/e0e3d2ec56b6 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 01:47:42 2015 From: report at bugs.python.org (A.M. Kuchling) Date: Tue, 21 Apr 2015 23:47:42 +0000 Subject: [issue15183] it should be made clear that the statement in the --setup option and the setup kw arg aren't included in the count In-Reply-To: <1340647320.14.0.672684715585.issue15183@psf.upfronthosting.co.za> Message-ID: <1429660062.5.0.429133472845.issue15183@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Committed to 3.4 and default. Thanks for your patch! ---------- nosy: +akuchling resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 01:54:40 2015 From: report at bugs.python.org (Luis) Date: Tue, 21 Apr 2015 23:54:40 +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: <1429660480.75.0.699987976243.issue23979@psf.upfronthosting.co.za> Luis added the comment: Thanks for information and explanations. The option of writing a tweaked serialization mechanism in Queue for Pool and implement a sharedmem sounds like fun, not sure if the pure-copy-on-write of forking can be achieved tho, it would be nice to know if it is actually possible (the project mentioned in issue17560 still needs to "dump" the arrays in the filesystem) As quick fix for us, I've created a simple wrapper around Pool and its map, it creates a Queue for the results and uses Process to start the workers, this works just fine. Simplicity and consistency are great, but I still believe that Pool, in LINUX-based systems, by serializing arguments, creates duplication and works inefficiently, and this could be avoided. Obviously it's not me who takes the decisions and I don't have the time to investigate it further, so, after this petty rant, should we close this bug? :> ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 02:00:28 2015 From: report at bugs.python.org (Ned Batchelder) Date: Wed, 22 Apr 2015 00:00:28 +0000 Subject: [issue22785] range docstring is less useful than in python 2 In-Reply-To: <1414962423.59.0.0293441090984.issue22785@psf.upfronthosting.co.za> Message-ID: <1429660828.44.0.634510288014.issue22785@psf.upfronthosting.co.za> Ned Batchelder added the comment: (By the time I got to the source, the word "virtual" had been removed...) Attached is a patch to make the help read: | range(stop) -> range object | range(start, stop[, step]) -> range object | | Return an object that produces a sequence of integers from start (inclusive) | to stop (exclusive) by step. range(i, j) produces i, i+1, i+2, ..., j-1. | start defaults to 0, and stop is omitted! range(4) produces 0, 1, 2, 3. | These are exactly the valid indices for a list of 4 elements. | When step is given, it specifies the increment (or decrement). ---------- keywords: +patch Added file: http://bugs.python.org/file39163/22785.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 02:15:54 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 22 Apr 2015 00:15:54 +0000 Subject: [issue24019] str/unicode encoding kwarg causes exceptions In-Reply-To: <1429592224.08.0.0993607651074.issue24019@psf.upfronthosting.co.za> Message-ID: <1429661754.13.0.377768741128.issue24019@psf.upfronthosting.co.za> Martin Panter added the comment: I don?t think changes to Python 2 are considered here, unless they are bug fixes, and this does not sound like a bug fix. For Python 3, it sounds like you are proposing that str() accept encoding arguments even when not decoding from bytes. It sounds like this would mask the error if you called str(buffer, "ascii"), and the buffer happened to be an integer or a list, etc, by accident. Also, this woul It seems str() is designed to have two separate modes: 1. str(object) is basically equivalent to format(object), with a warning if ?object? happens to be a byte string or array 2. str(object, encoding, ...) is normally equivalent to object.decode(encoding, ...), or if that is not supported, codecs.decode(object, encoding, ...) Your proposal sounds like it would make it easier to confuse these two modes. What should str(b"123", encoding=None) do? Why should the behaviour of str(file, encoding) vary depending on whether an ordinary file object or a memory-mapped file is passed? IMO in a perfect Python 4 world, str() would only have a single personality (perhaps always returning an empty string, or a more strict conversion). Making a formatted string representations of arbitrary objects would be left to the format() and repr() functions, and decoding bytes to text would be left to the existing decode() methods and functions, or maybe a separate str.from_bytes() constructor, mirroring int.from_bytes(). ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 02:16:09 2015 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 22 Apr 2015 00:16:09 +0000 Subject: [issue2716] Document license under which audioop is used In-Reply-To: <1209428570.75.0.48368829493.issue2716@psf.upfronthosting.co.za> Message-ID: <1429661769.59.0.912848639856.issue2716@psf.upfronthosting.co.za> A.M. Kuchling added the comment: Van: what do you think? I can prepare a patch for Aaron's suggested changes. ---------- nosy: +akuchling, vanl _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 02:57:42 2015 From: report at bugs.python.org (Mahmoud Hashemi) Date: Wed, 22 Apr 2015 00:57:42 +0000 Subject: [issue24019] str/unicode encoding kwarg causes exceptions In-Reply-To: <1429592224.08.0.0993607651074.issue24019@psf.upfronthosting.co.za> Message-ID: <1429664262.81.0.187869151611.issue24019@psf.upfronthosting.co.za> Mahmoud Hashemi added the comment: Martin, it sounds that way because that is what is being proposed: "Merging and simplifying the two modes". Given the existence of .decode() on bytestrings, the only objects that generally need decoding in Python 2 and 3, the existence of str/unicode's second mode constitutes a design bug. Without a doubt, Python has frequently preferred convenient idioms over EAFP. Look at dict.get for an excellent example of defaults being used instead of forcing users to catch KeyErrors. That conversation could have gone a different way, but Python is better off having stuck to its pragmatic roots. In answer to your questions, Martin, 1) I'd expect str(b"123", encoding=None) to do the same thing as str(b"123") and 2) I'd expect str(obj) behavior to continue to depend on whether the object passed is string-like. Python is a duck-typed, dynamic language, and dynamic languages are most powerful when their core types reflect usability. Consistency is one of the foremost factors of usability, and having to frequently switch between two call patterns of the str constructor feels inconsistent and unusable. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 03:16:46 2015 From: report at bugs.python.org (Jean-Paul Calderone) Date: Wed, 22 Apr 2015 01:16:46 +0000 Subject: [issue5305] imaplib should support international mailbox names In-Reply-To: <1234935371.11.0.35650041724.issue5305@psf.upfronthosting.co.za> Message-ID: <1429665406.33.0.179184481001.issue5305@psf.upfronthosting.co.za> Changes by Jean-Paul Calderone : ---------- nosy: -exarkun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 03:23:34 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Apr 2015 01:23:34 +0000 Subject: [issue24019] str/unicode encoding kwarg causes exceptions In-Reply-To: <1429592224.08.0.0993607651074.issue24019@psf.upfronthosting.co.za> Message-ID: <1429665814.68.0.704661434303.issue24019@psf.upfronthosting.co.za> R. David Murray added the comment: It does feel like the encoding argument is left over from the translation of the unicode constructor into the str constructor. I wouldn't be opposed to deprecating it, myself, though we'd probably never remove it. I would be opposed to making it work on non-bytes-like objects. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 03:47:43 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 22 Apr 2015 01:47:43 +0000 Subject: [issue24019] str/unicode encoding kwarg causes exceptions In-Reply-To: <1429592224.08.0.0993607651074.issue24019@psf.upfronthosting.co.za> Message-ID: <1429667263.45.0.272108110685.issue24019@psf.upfronthosting.co.za> Martin Panter added the comment: Okay, I was trying to confirm your proposal in Python 3 terms, because in Python 2, str has a different meaning and I was confused. I agree that the existence of the decoding mode is a design bug, so how would you feel about deprecating it, at least in the documentation? I.e. in Python 3, deprecate usage like str(buffer, "utf-8") in favour of buffer.decode("utf-8") or using the codecs module directly. If this was done, it would clearly remove the need for an encoding parameter to str() in all cases. I would be in favour of deprecating the complementary bytes() and bytearray() encoding modes as well. Do you have an example use case in Python 3 that would benefit from always allowing an encoding parameter? I can understand that your to_unicode() function could be useful in Python 2. But in Python 3, byte strings tend to hold raw data that is not necessarily textual at all. There are some places (warts in my opinion) such as the binascii module where ASCII-encoded byte strings are common, but I still don?t think this proposal would be very helpful with that. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 04:35:21 2015 From: report at bugs.python.org (Carol Willing) Date: Wed, 22 Apr 2015 02:35:21 +0000 Subject: [issue16574] clarify policy on updates to final peps In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za> Message-ID: <1429670121.01.0.518544873384.issue16574@psf.upfronthosting.co.za> Changes by Carol Willing : ---------- stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 04:36:29 2015 From: report at bugs.python.org (Carol Willing) Date: Wed, 22 Apr 2015 02:36:29 +0000 Subject: [issue17475] Better doc on using python-gdb.py In-Reply-To: <1363654728.46.0.181604306018.issue17475@psf.upfronthosting.co.za> Message-ID: <1429670189.31.0.0105681473482.issue17475@psf.upfronthosting.co.za> Changes by Carol Willing : ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 05:16:58 2015 From: report at bugs.python.org (Eric V. Smith) Date: Wed, 22 Apr 2015 03:16:58 +0000 Subject: [issue24019] str/unicode encoding kwarg causes exceptions In-Reply-To: <1429592224.08.0.0993607651074.issue24019@psf.upfronthosting.co.za> Message-ID: <1429672618.13.0.399142849896.issue24019@psf.upfronthosting.co.za> Eric V. Smith added the comment: I agree with deprecating (in the documentation) but never removing the encoding argument to str() in Python 3. .decode() is the better way to convert a bytes-like object to a str. Every change proposed here would be an enhancement in 2.7, and we are not implementing enhancements there. ---------- versions: +Python 3.6 -Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 05:23:46 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Apr 2015 03:23:46 +0000 Subject: [issue24021] document urllib.urlretrieve Message-ID: <1429673026.41.0.442066158913.issue24021@psf.upfronthosting.co.za> New submission from Berker Peksag: urllib.urlretrieve is already documented at https://docs.python.org/2.7/library/urllib.html#urllib.urlretrieve Can you please give us more information about your problem with the urllib.urlretrieve documentation? ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 05:25:14 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Wed, 22 Apr 2015 03:25:14 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1429673114.34.0.123408451219.issue23863@psf.upfronthosting.co.za> Gregory P. Smith added the comment: ... Code review: In socket_eintr.5.patch I don't think the thread safety concerns about the s.settimeout() calls being done from Python code should be an issue but I'll ponder that for a bit. When you've got a socket s, why would code ever be calling s.recv() in one thread while calling another method on the same socket s in another thread? That seems unwise. (For UDP it might be a valid thing to do but it still has an odd smell to it) If you're worried about timer resolution, just check that the new timeout value "deadline - now" is less than the previous timeout value and if not, ensure the value decreases by some small amount. So long as it continually goes down, it will eventually timeout. Even if the duration isn't accurate in the face of a bunch of EINTRs, this is a degenerate case; it should still be reasonable behavior. On POSIX systems using os.times()[4] rather than an absolute time.time(), which can be changed out from underneath the process (even though that is rare on functioning systems), could be useful. But conditionally using that seems overly complex. I wouldn't bother. ... Side discussion Some things in 2.7 related to EINTR have already been fixed in the past few years such as data loss in readline() and IIRC writelines(). Correctness isn't a feature. Do you consider it an API change to prevent an error that nobody relies on or even expects (as PEP 475 notes) and virtually no code is written to properly handle when it _does_ happen? I don't. It is a bug fix. It's mostly a matter of if we can do it sanely and in a maintainable manner. Please don't WONTFIX this issue, I intend to get safe fixes in. ... Motivation The underlying motivation here is to enable the use of a signal based sampling profiler on a program that is using Python 2.7 (entirely, or embedded as one part of a larger C/C++ application). Signals (SIGPROF) used in that scenario cause EINTR returns from syscalls that otherwise rarely (read: never) have them in most environments. Result: Bugs show up making such a sampling profiler impossible to deploy in practice until those issues are fixed. Fixing the Python standard library is high value as it is a higher up place where these can be handled properly as you cannot even use some standard library modules at all otherwise because the unhandled EINTR surfaces too late or causes other unrecoverable errors internally before you see it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 05:29:34 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Apr 2015 03:29:34 +0000 Subject: [issue24019] str/unicode encoding kwarg causes exceptions In-Reply-To: <1429592224.08.0.0993607651074.issue24019@psf.upfronthosting.co.za> Message-ID: <1429673374.83.0.592594288557.issue24019@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 05:42:55 2015 From: report at bugs.python.org (Carol Willing) Date: Wed, 22 Apr 2015 03:42:55 +0000 Subject: [issue17846] Building Python on Windows - Supplementary info In-Reply-To: <1366919664.94.0.0931557904055.issue17846@psf.upfronthosting.co.za> Message-ID: <1429674175.73.0.863135983608.issue17846@psf.upfronthosting.co.za> Carol Willing added the comment: Thank you kathweaver and others who worked on this issue. After reviewing the long history of this issue and the changes made to the Windows sections of the devguide, I am closing this issue. I recognize that Terry Reedy's final comment about isolated build directories may need additional documentation. My recommendation would be to file a new issue if more documentation is needed on isolated build directories for Windows and tcl. ---------- nosy: +willingc resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 06:05:41 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 22 Apr 2015 04:05:41 +0000 Subject: [issue13814] Document why generators don't support the context management protocol In-Reply-To: <1326883396.25.0.884733470267.issue13814@psf.upfronthosting.co.za> Message-ID: <1429675541.12.0.00317188134761.issue13814@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 06:10:12 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 22 Apr 2015 04:10:12 +0000 Subject: [issue23227] Generator's finally block not run if close() called before first iteration In-Reply-To: <1421134546.13.0.154248882029.issue23227@psf.upfronthosting.co.za> Message-ID: <1429675812.23.0.0496753983827.issue23227@psf.upfronthosting.co.za> Changes by Martin Panter : ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 06:12:46 2015 From: report at bugs.python.org (Carol Willing) Date: Wed, 22 Apr 2015 04:12:46 +0000 Subject: [issue20851] Update devguide to cover testing from a tarball In-Reply-To: <1393944432.91.0.924701829685.issue20851@psf.upfronthosting.co.za> Message-ID: <1429675966.28.0.903665853616.issue20851@psf.upfronthosting.co.za> Carol Willing added the comment: Brett, Is documentation for a testing a tarball dumped for an RC still needed? If so, are the following steps accurate? 1. Download tarball 2. Extract tarball into a directory tar -xzvf release.tar.gz 3. Change directory into release directory cd release 4. Install the release sudo python setup.py install My assumption: After installation above, testing should be similar to the existing devguide instructions for testing. Thoughts? ---------- nosy: +willingc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 06:13:39 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 22 Apr 2015 04:13:39 +0000 Subject: [issue24021] document urllib.urlretrieve In-Reply-To: <1429673026.41.0.442066158913.issue24021@psf.upfronthosting.co.za> Message-ID: <1429676019.01.0.670492546889.issue24021@psf.upfronthosting.co.za> Martin Panter added the comment: I suspect the complaint might be about the lack of doc string, but a more specific bug report would be nice to clarify this. $ pydoc2 urllib.urlretrieve Help on function urlretrieve in urllib: urllib.urlretrieve = urlretrieve(url, filename=None, reporthook=None, data=None, context=None) $ ---------- nosy: +vadmium _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 06:29:47 2015 From: report at bugs.python.org (Milan Oberkirch) Date: Wed, 22 Apr 2015 04:29:47 +0000 Subject: [issue22137] Test imaplib API on all methods specified in RFC 3501 In-Reply-To: <1429044074.46.0.941199353909.issue22137@psf.upfronthosting.co.za> Message-ID: <1501565.Q61hxDlWWO@moss> Milan Oberkirch added the comment: Thanks a lot for reviewing my patch! I'm currently travalling so I'm totally fine with you taking over this issue (would take me a few weeks till I can work on it). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 06:53:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Apr 2015 04:53:05 +0000 Subject: [issue16574] clarify policy on updates to final peps In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za> Message-ID: <20150422045302.98628.4693@psf.io> Roundup Robot added the comment: New changeset 0c4006b7c7ff by Berker Peksag in branch 'default': Issue #16574: Clarify that once a PEP has implemented, it needs be https://hg.python.org/devguide/rev/0c4006b7c7ff ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 06:53:32 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Apr 2015 04:53:32 +0000 Subject: [issue16574] clarify policy on updates to final peps In-Reply-To: <1354150615.68.0.531483999972.issue16574@psf.upfronthosting.co.za> Message-ID: <1429678412.44.0.489255996905.issue16574@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks! ---------- nosy: +berker.peksag resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 07:11:26 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Apr 2015 05:11:26 +0000 Subject: [issue17846] Building Python on Windows - Supplementary info In-Reply-To: <1366919664.94.0.0931557904055.issue17846@psf.upfronthosting.co.za> Message-ID: <1429679486.65.0.907159457606.issue17846@psf.upfronthosting.co.za> Terry J. Reedy added the comment: My comment was addressed by other patches (by Zach, I believe). There now is an external directory for each version, within each pythonxy repository. I agree with closing this. Any documentation issues with the current build process should be a new issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 07:23:15 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Apr 2015 05:23:15 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows In-Reply-To: <1390284343.93.0.69163024688.issue20323@psf.upfronthosting.co.za> Message-ID: <1429680195.88.0.460421914338.issue20323@psf.upfronthosting.co.za> Larry Hastings added the comment: Is this problem gone, now that Serhiy changed everything over to the "file" preset? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 08:38:52 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Apr 2015 06:38:52 +0000 Subject: [issue23917] please fall back to sequential compilation when concurrent doesn't exist In-Reply-To: <1428792729.56.0.740382381475.issue23917@psf.upfronthosting.co.za> Message-ID: <20150422063849.30758.87487@psf.io> Roundup Robot added the comment: New changeset 572dc6bdc0a3 by Berker Peksag in branch 'default': Issue #23917: Fall back to sequential compilation when ProcessPoolExecutor doesn't exist. https://hg.python.org/cpython/rev/572dc6bdc0a3 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 08:39:58 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Apr 2015 06:39:58 +0000 Subject: [issue23917] please fall back to sequential compilation when concurrent doesn't exist In-Reply-To: <1428792729.56.0.740382381475.issue23917@psf.upfronthosting.co.za> Message-ID: <1429684798.03.0.111235686459.issue23917@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks Claudiu. ---------- nosy: +berker.peksag resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 08:44:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Apr 2015 06:44:08 +0000 Subject: [issue24019] str/unicode encoding kwarg causes exceptions In-Reply-To: <1429592224.08.0.0993607651074.issue24019@psf.upfronthosting.co.za> Message-ID: <1429685048.21.0.213747437656.issue24019@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Please don't deprecate the encoding parameter in str. It has a use case. str constructor works with any bytes-like objects, even with these that don't have the decode method. It raises more appropriate TypeError instead of AttributeError, so often you don't need to wrap an error. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 08:52:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Apr 2015 06:52:58 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows In-Reply-To: <1390284343.93.0.69163024688.issue20323@psf.upfronthosting.co.za> Message-ID: <1429685578.97.0.898872925561.issue20323@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The "file" preset is default now, but if you will consider Argument Clinic as general tool for use in third-party software, the bug still is here. ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 08:55:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Apr 2015 06:55:28 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows In-Reply-To: <1390284343.93.0.69163024688.issue20323@psf.upfronthosting.co.za> Message-ID: <1429685728.93.0.0175972962283.issue20323@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> remind versions: +Python 3.6 -Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 09:09:08 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Apr 2015 07:09:08 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows In-Reply-To: <1390284343.93.0.69163024688.issue20323@psf.upfronthosting.co.za> Message-ID: <1429686548.21.0.304596433766.issue20323@psf.upfronthosting.co.za> Larry Hastings added the comment: I thought the bug only happened with the "two-pass" preset. The "two-pass" preset is gone, because I broke it, and nobody was using it anyway, so I removed it. (I don't even remember what "two-pass" was trying to do. It's possible the same effect could be achieved with the modern "every destination has an arbitrary number of separate numbered buffers you can put text into" technology.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 09:12:25 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Apr 2015 07:12:25 +0000 Subject: [issue15657] Error in Python 3 docs for PyMethodDef In-Reply-To: <1344970966.7.0.115664419243.issue15657@psf.upfronthosting.co.za> Message-ID: <1429686745.2.0.697043833599.issue15657@psf.upfronthosting.co.za> Berker Peksag added the comment: Here is a patch for Python 3.5. ---------- components: +Interpreter Core -Documentation keywords: +patch nosy: +berker.peksag, serhiy.storchaka type: -> behavior versions: +Python 3.5 -Python 3.2, Python 3.3 Added file: http://bugs.python.org/file39164/issue15657.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 09:13:28 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Apr 2015 07:13:28 +0000 Subject: [issue11587] METH_KEYWORDS alone gives "METH_OLDARGS is no longer supported!" In-Reply-To: <1300371450.74.0.196347407425.issue11587@psf.upfronthosting.co.za> Message-ID: <1429686808.82.0.671136490959.issue11587@psf.upfronthosting.co.za> Berker Peksag added the comment: issue 15657 is actually a duplicate of this issue, but since there's more information there I'm closing this. Please take a look the patch at issue 15657. Thank you all! ---------- nosy: +berker.peksag resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Error in Python 3 docs for PyMethodDef _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 09:40:09 2015 From: report at bugs.python.org (Martin Panter) Date: Wed, 22 Apr 2015 07:40:09 +0000 Subject: [issue24019] str/unicode encoding kwarg causes exceptions In-Reply-To: <1429592224.08.0.0993607651074.issue24019@psf.upfronthosting.co.za> Message-ID: <1429688409.36.0.931093510847.issue24019@psf.upfronthosting.co.za> Martin Panter added the comment: I thought it might be okay to use codecs.decode() instead for those cases, though it doesn?t check for text encodings. And support for arbitrary bytes-like object doesn?t seem to be documented (though seems to work in reality). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 09:49:40 2015 From: report at bugs.python.org (Maciej Szulik) Date: Wed, 22 Apr 2015 07:49:40 +0000 Subject: [issue22137] Test imaplib API on all methods specified in RFC 3501 In-Reply-To: <1407197833.23.0.797549876094.issue22137@psf.upfronthosting.co.za> Message-ID: <1429688980.66.0.895380647476.issue22137@psf.upfronthosting.co.za> Maciej Szulik added the comment: Thanks Milan for the info, I was about to ping you about that. I have a working prototype for the tests that I've been working on during PyCon sprints with David. I'll try to submit new patch within a couple of next days. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 09:51:43 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Apr 2015 07:51:43 +0000 Subject: [issue15216] Support setting the encoding on a text stream after creation In-Reply-To: <1340880558.16.0.0136840668667.issue15216@psf.upfronthosting.co.za> Message-ID: <1429689103.13.0.806408600061.issue15216@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 10:02:38 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Apr 2015 08:02:38 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <20150422080231.18909.50615@psf.io> Roundup Robot added the comment: New changeset 4bf210f59ac6 by Serhiy Storchaka in branch '2.7': Issue #16840: Skip bignum tests on minor releases where they are not supported. https://hg.python.org/cpython/rev/4bf210f59ac6 New changeset 97519d85b5c8 by Serhiy Storchaka in branch '3.4': Issue #16840. Turn off bignum support in tkinter with with Tcl earlier than 8.5.8 https://hg.python.org/cpython/rev/97519d85b5c8 New changeset 701b830abbf0 by Serhiy Storchaka in branch 'default': Issue #16840. Turn off bignum support in tkinter with with Tcl earlier than 8.5.8 https://hg.python.org/cpython/rev/701b830abbf0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 10:06:25 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Apr 2015 08:06:25 +0000 Subject: [issue20323] Argument Clinic: docstring_prototype output causes build failure on Windows In-Reply-To: <1429686548.21.0.304596433766.issue20323@psf.upfronthosting.co.za> Message-ID: <6811382.3MlbKvHmGR@raxxla> Serhiy Storchaka added the comment: Ah, if the "two-pass" preset is gone, then of course the bug is gone too. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 10:17:50 2015 From: report at bugs.python.org (Johan Pretorius) Date: Wed, 22 Apr 2015 08:17:50 +0000 Subject: [issue24023] Django tutorial 2 not able to create a superuser on Windows 7 Message-ID: <1429690670.7.0.624735318839.issue24023@psf.upfronthosting.co.za> New submission from Johan Pretorius: When running the $python manage.py createsuperuser command the following is returned: C:\Users\johanP\mysite>python manage.py cre Username (leave blank to use 'johanp'): Email address: ja****rius at gmail.com Traceback (most recent call last): File "manage.py", line 10, in execute_from_command_line(sys.argv) File "C:\Program Files\Python 3.5\lib\site-packages\djan nit__.py", line 338, in execute_from_command_line utility.execute() File "C:\Program Files\Python 3.5\lib\site-packages\djan nit__.py", line 330, in execute self.fetch_command(subcommand).run_from_argv(self.argv File "C:\Program Files\Python 3.5\lib\site-packages\djan e.py", line 390, in run_from_argv self.execute(*args, **cmd_options) File "C:\Program Files\Python 3.5\lib\site-packages\djan ment\commands\createsuperuser.py", line 50, in execute return super(Command, self).execute(*args, **options) File "C:\Program Files\Python 3.5\lib\site-packages\djan e.py", line 441, in execute output = self.handle(*args, **options) File "C:\Program Files\Python 3.5\lib\site-packages\djan ment\commands\createsuperuser.py", line 124, in handle password = getpass.getpass() File "C:\Program Files\Python 3.5\lib\getpass.py", line msvcrt.putwch(c) AttributeError: module 'msvcrt' has no attribute 'putwch' The command picks up my AD credentials and doesn't request a password. I can create a super user in python using the following link:https://docs.djangoproject.com/en/1.8/topics/auth/default/ But the admin site won't start using this method. I'm running Python 3.5, Django 1.8 on Windows 7 Professional. ---------- components: Demos and Tools messages: 241787 nosy: JohanPretorius priority: normal severity: normal status: open title: Django tutorial 2 not able to create a superuser on Windows 7 type: compile error versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 10:31:53 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Apr 2015 08:31:53 +0000 Subject: [issue21483] Skip os.utime() test on NFS? In-Reply-To: Message-ID: <20150422083147.30746.18705@psf.io> Roundup Robot added the comment: New changeset aa60f4d1a569 by Berker Peksag in branch 'default': Issue #21483: Skip test_timestamp_overflow on NFS. https://hg.python.org/cpython/rev/aa60f4d1a569 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 10:32:41 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Apr 2015 08:32:41 +0000 Subject: [issue21483] Skip os.utime() test on NFS? In-Reply-To: Message-ID: <1429691561.55.0.377167981811.issue21483@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks Isaac. ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 11:05:59 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Apr 2015 09:05:59 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <1429693559.2.0.979974078716.issue23275@psf.upfronthosting.co.za> Berker Peksag added the comment: I don't have a strong opinion on this, but here is a patch to make () = [] a valid assignment. ---------- keywords: +patch nosy: +berker.peksag stage: -> patch review versions: +Python 3.5 Added file: http://bugs.python.org/file39165/issue23275.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 11:10:09 2015 From: report at bugs.python.org (Karl Richter) Date: Wed, 22 Apr 2015 09:10:09 +0000 Subject: [issue24021] document urllib.urlretrieve In-Reply-To: <1429673026.41.0.442066158913.issue24021@psf.upfronthosting.co.za> Message-ID: <1429693809.4.0.416894275224.issue24021@psf.upfronthosting.co.za> Karl Richter added the comment: > I suspect the complaint might be about the lack of doc string Exactly. It'd be helpful to figure out the return value and the means of the function arguments in a more compact form than the referenced website docs and to have it available in the interpreter (with `help`), i.e. with docstring documentation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 11:42:01 2015 From: report at bugs.python.org (Amaury Forgeot d'Arc) Date: Wed, 22 Apr 2015 09:42:01 +0000 Subject: [issue23275] Can assign [] = (), but not () = [] In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za> Message-ID: <1429695721.21.0.232889009822.issue23275@psf.upfronthosting.co.za> Amaury Forgeot d'Arc added the comment: About the patch: I'm sure there are other tests to change, in test_syntax.py for example:: It's a syntax error to assign to the empty tuple. Why isn't it an error to assign to the empty list? It will always raise some error at runtime. >>> () = 1 Traceback (most recent call last): File "", line 1 SyntaxError: can't assign to () ---------- nosy: +amaury.forgeotdarc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 11:49:02 2015 From: report at bugs.python.org (Jean-Paul Calderone) Date: Wed, 22 Apr 2015 09:49:02 +0000 Subject: [issue6731] Add option of non-zero exit status of setup.py when building of extensions has failed In-Reply-To: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za> Message-ID: <1429696142.49.0.406402614206.issue6731@psf.upfronthosting.co.za> Jean-Paul Calderone added the comment: It's only been six years, no need to rush. ---------- nosy: +Jean-Paul Calderone _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 11:49:17 2015 From: report at bugs.python.org (Jean-Paul Calderone) Date: Wed, 22 Apr 2015 09:49:17 +0000 Subject: [issue6731] Add option of non-zero exit status of setup.py when building of extensions has failed In-Reply-To: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za> Message-ID: <1429696157.42.0.227429927924.issue6731@psf.upfronthosting.co.za> Changes by Jean-Paul Calderone : ---------- nosy: -Jean-Paul Calderone, exarkun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 12:17:12 2015 From: report at bugs.python.org (Marco Paolini) Date: Wed, 22 Apr 2015 10:17:12 +0000 Subject: [issue23227] Generator's finally block not run if close() called before first iteration In-Reply-To: <1421134546.13.0.154248882029.issue23227@psf.upfronthosting.co.za> Message-ID: <1429697832.04.0.661077443795.issue23227@psf.upfronthosting.co.za> Marco Paolini added the comment: I think there is an issue in the way you designed your cleanup logic. So I think this issue is invalid. Usually, the code (funcion, class, ...) that *opens* the file should also be resposible of closing it. option 1) the caller opens and closes the file and wrapping the logged lines in a try/finally def logged_lines(f): try: for line in f: logging.warning(line.strip()) yield line finally: logging.warning('closing') f = open('yyy', 'r') try: for l in logged_lines(f): print(l) finally: f.close() option 2) the funcion opens and closes the file def logged_lines(fname): f = open('yyy', 'r') try: for line in f: logging.warning(line.strip()) yield line finally: logging.warning('closing') f.close() for l in logged_lines('yyy'): print(l) ---------- nosy: +mpaolini _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 13:25:23 2015 From: report at bugs.python.org (Dmitry Kazakov) Date: Wed, 22 Apr 2015 11:25:23 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1429701923.5.0.759958244489.issue22619@psf.upfronthosting.co.za> Changes by Dmitry Kazakov : Added file: http://bugs.python.org/file39166/traceback_limit_doc_rev3.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 14:33:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Apr 2015 12:33:08 +0000 Subject: [issue16840] Tkinter doesn't support large integers In-Reply-To: <1357139353.64.0.50025486638.issue16840@psf.upfronthosting.co.za> Message-ID: <1429705988.93.0.884383437108.issue16840@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 Wed Apr 22 14:49:13 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Apr 2015 12:49:13 +0000 Subject: [issue24019] str/unicode encoding kwarg causes exceptions In-Reply-To: <1429592224.08.0.0993607651074.issue24019@psf.upfronthosting.co.za> Message-ID: <1429706953.77.0.0991456866216.issue24019@psf.upfronthosting.co.za> R. David Murray added the comment: Sounds like we should close this as rejected, then. Serhiy's point is a good one. Maybe not the way we'd design the api from scratch, but it's what we've got and it serves a purpose. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 14:55:44 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Apr 2015 12:55:44 +0000 Subject: [issue24023] Django tutorial 2 not able to create a superuser on Windows 7 In-Reply-To: <1429690670.7.0.624735318839.issue24023@psf.upfronthosting.co.za> Message-ID: <1429707344.79.0.814483102469.issue24023@psf.upfronthosting.co.za> R. David Murray added the comment: This is a duplicate of issue 23995. ---------- nosy: +r.david.murray resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> msvcrt could not be imported _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 15:08:47 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 22 Apr 2015 13:08:47 +0000 Subject: [issue24019] str/unicode encoding kwarg causes exceptions In-Reply-To: <1429592224.08.0.0993607651074.issue24019@psf.upfronthosting.co.za> Message-ID: <1429708127.25.0.185336687328.issue24019@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: I agree with closing this as "won't fix". It is true that the encoding keyword argument is only useful when passing in byte strings or (and that's also where it originated in Python 2: the default string type is a byte string), but even in Python 3, this is still one of the main uses of the str() constructor. Note that it's not uncommon to have arguments only be useful for certain types of input objects. See e.g. the int() constructor base argument for similar example. ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 15:13:46 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 22 Apr 2015 13:13:46 +0000 Subject: [issue24024] str.__doc__ needs an update Message-ID: <1429708426.75.0.208318155296.issue24024@psf.upfronthosting.co.za> New submission from Marc-Andre Lemburg: In Python 3.4.3, the doc string of the str() builtin still reads: "str(object='') -> str\nstr(bytes_or_buffer[, encoding[, errors]]) -> str\n\nCreate a new string object from the given object. If encoding or\nerrors is specified, then the object must expose a data buffer\nthat will be decoded using the given encoding and error handler.\nOtherwise, returns the result of object.__str__() (if defined)\nor repr(object).\nencoding defaults to sys.getdefaultencoding().\nerrors defaults to 'strict'." This no longer matches what str() does. sys.getdefaultencoding() always returns 'utf-8' and str() accepts bytes, bytearray or buffer-like objects as input when using an encoding, any object with .__str__() method defined or repr(obj) otherwise. ---------- components: Interpreter Core, Unicode messages: 241798 nosy: ezio.melotti, haypo, lemburg priority: normal severity: normal status: open title: str.__doc__ needs an update versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 15:16:38 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Apr 2015 13:16:38 +0000 Subject: [issue22785] range docstring is less useful than in python 2 In-Reply-To: <1414962423.59.0.0293441090984.issue22785@psf.upfronthosting.co.za> Message-ID: <20150422131634.98630.24478@psf.io> Roundup Robot added the comment: New changeset aa6b73823685 by Benjamin Peterson in branch '3.4': improved range docstring (closes #22785) https://hg.python.org/cpython/rev/aa6b73823685 New changeset c031fa8e6884 by Benjamin Peterson in branch 'default': merge 3.4 (#22785) https://hg.python.org/cpython/rev/c031fa8e6884 ---------- nosy: +python-dev resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 15:17:59 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 22 Apr 2015 13:17:59 +0000 Subject: [issue24019] str/unicode encoding kwarg causes exceptions In-Reply-To: <1429592224.08.0.0993607651074.issue24019@psf.upfronthosting.co.za> Message-ID: <1429708679.87.0.422455931021.issue24019@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 15:23:32 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 22 Apr 2015 13:23:32 +0000 Subject: [issue24025] str(bytes_obj) should raise an error Message-ID: <1429709012.06.0.232941400287.issue24025@psf.upfronthosting.co.za> New submission from Marc-Andre Lemburg: In Python 2, the unicode() constructor does not accept bytes arguments, unless an encoding argument is given: >>> unicode(u'abc???'.encode('utf-8')) Traceback (most recent call last): File "", line 1, in UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3: ordinal not in range(128) In Python 3, the str() constructor masks this programming error by returning the repr() of the bytes object: >>> str('abc???'.encode('utf-8')) "b'abc\\xc3\\xa4\\xc3\\xb6\\xc3\\xbc'" I think it would be more helpful to point the programmer to the most probably missing encoding argument by raising an error. Also note that you get a different output with encoding argument set: >>> str('abc???'.encode('utf-8'), 'utf-8') 'abc???' I know this is documented, but it is still not very helpful and can easily hide errors. ---------- components: Interpreter Core, Unicode messages: 241800 nosy: ezio.melotti, haypo, lemburg priority: normal severity: normal status: open title: str(bytes_obj) should raise an error versions: Python 3.5, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 15:36:38 2015 From: report at bugs.python.org (Berker Peksag) Date: Wed, 22 Apr 2015 13:36:38 +0000 Subject: [issue23713] intermittent failure of multiprocessing unit test test_imap_unordered_handle_iterable_exception In-Reply-To: <1426795503.26.0.283860442544.issue23713@psf.upfronthosting.co.za> Message-ID: <1429709798.91.0.595013763798.issue23713@psf.upfronthosting.co.za> Berker Peksag added the comment: Just saw this on x86 Tiger 3.x: ====================================================================== FAIL: test_imap_unordered_handle_iterable_exception (test.test_multiprocessing_fork.WithProcessesTestPool) ---------------------------------------------------------------------- Traceback (most recent call last): File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/_test_multiprocessing.py", line 1805, in test_imap_unordered_handle_iterable_exception self.assertEqual(next(it), i*i) AssertionError: 1 != 0 http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/9559/steps/test/logs/stdio The patch looks good to me. I'm not familiar with the test code, but Serhiy's suggestion also looks good to me. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 15:39:03 2015 From: report at bugs.python.org (eryksun) Date: Wed, 22 Apr 2015 13:39:03 +0000 Subject: [issue24025] str(bytes_obj) should raise an error In-Reply-To: <1429709012.06.0.232941400287.issue24025@psf.upfronthosting.co.za> Message-ID: <1429709943.55.0.809019341921.issue24025@psf.upfronthosting.co.za> eryksun added the comment: bytes.__str__ can already raise either a warning (-b) >>> str('abc???'.encode('utf-8')) __main__:1: BytesWarning: str() on a bytes instance "b'abc\\xc3\\xa4\\xc3\\xb6\\xc3\\xbc'" or error (-bb), which applies equally to implicit conversion by print(): >>> print('abc???'.encode('utf-8')) Traceback (most recent call last): File "", line 1, in BytesWarning: str() on a bytes instance ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 15:43:36 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 22 Apr 2015 13:43:36 +0000 Subject: [issue24025] str(bytes_obj) should raise an error In-Reply-To: <1429709012.06.0.232941400287.issue24025@psf.upfronthosting.co.za> Message-ID: <1429710216.43.0.46767600072.issue24025@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In Python 2, the unicode() constructor accepts bytes argument if it is decodeable with sys.getdefaultencoding(). >>> unicode(b'abc') u'abc' >>> import sys >>> reload(sys) >>> sys.setdefaultencoding("utf-8") >>> unicode(u'abc???'.encode('utf-8')) u'abc\xe4\xf6\xfc' In Python 3, the str() constructor does not accept bytes arguments if Python is ran with -bb option. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 15:52:34 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Apr 2015 13:52:34 +0000 Subject: [issue24025] str(bytes_obj) should raise an error In-Reply-To: <1429709012.06.0.232941400287.issue24025@psf.upfronthosting.co.za> Message-ID: <1429710754.69.0.366392214947.issue24025@psf.upfronthosting.co.za> R. David Murray added the comment: str accepting bytes and returning the repr was a conscious design choice, as evidenced by the -bb option, and I'm sure there is code that is both unintentionally and *intentionally* using this, despite the warning. Unless we want to discuss making the -bb behavior the default in a future version of python, this issue should be closed. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 16:02:20 2015 From: report at bugs.python.org (Cyd Haselton) Date: Wed, 22 Apr 2015 14:02:20 +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: <1429711340.22.0.172912405739.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Still working at this; I can't get the readline module to work. It is built successfully but importing it produces the following error: Traceback (most recent call last): File "", line 1, in ImportError: dlopen failed: could not load library "libreadline.so.6" needed by "readline.cpython-35m-arm-linux-gnueabi.so"; caused by cannot locate symbol "tgetnum" referenced by "libreadline.so.6"... tgetnum is undefined in libreadline but defined in -libncurses and libtinfo. I've built and re-built readline (--with-curses and -without that option...linking -lncurses, then -lncurses and -ltinfo) in the KBOX environment. I've edited Modules/Setup and setup.py so as to specify the readline library plus a combination of others (-ncurses, -tinfo) to no avail. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 16:17:44 2015 From: report at bugs.python.org (appidman) Date: Wed, 22 Apr 2015 14:17:44 +0000 Subject: [issue24026] Python hangs forever in wait() of threading.py Message-ID: <1429712264.48.0.476930197364.issue24026@psf.upfronthosting.co.za> New submission from appidman: I use paramiko to create SSH sessions to Linux machines, which works great 95% of the time. But sometimes, the Python process which creates the SSH session hangs forever in wait() of threading.py (see attachment 'gdb.txt' for full output). {code} (gdb) py-list 239 waiter.acquire() 240 self.__waiters.append(waiter) 241 saved_state = self._release_save() 242 try: # restore state no matter what (e.g., KeyboardInterrupt) 243 if timeout is None: >244 waiter.acquire() 245 if __debug__: 246 self._note("%s.wait(): got it", self) 247 else: 248 # Balancing act: We can't afford a pure busy loop, so we 249 # have to sleep; but if we sleep the whole timeout time, (gdb) py-bt #5 Frame 0xb459a5c, for file /usr/lib/python2.7/threading.py, line 244, in wait (self=<_Condition(_Verbose__verbose=False, _Condition__lock=, acquire=, _Condition__waiters=[], release=) at remote 0xb73708c>, timeout=None, waiter=, saved_state=None) waiter.acquire() #9 Frame 0xb66118c, for file /usr/lib/python2.7/dist-packages/paramiko/buffered_pipe.py, line 137, in read (self=, _buffer=, _event=None, _cv=<_Condition(_Verbose__verbose=False, _Condition__lock=, acquire=, _Condition__waiters=[], release=) at remote 0xb73708c>) at remote 0xb737a4c>, nbytes=8192, timeout=None, out='', then=) self._cv.wait(timeout) {code} ---------- components: Library (Lib) files: gdb.txt messages: 241806 nosy: appidman priority: normal severity: normal status: open title: Python hangs forever in wait() of threading.py type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file39167/gdb.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 16:38:02 2015 From: report at bugs.python.org (Carol Willing) Date: Wed, 22 Apr 2015 14:38:02 +0000 Subject: [issue17570] Improve devguide Windows instructions In-Reply-To: <1364523214.84.0.368819983889.issue17570@psf.upfronthosting.co.za> Message-ID: <1429713482.94.0.968951830055.issue17570@psf.upfronthosting.co.za> Carol Willing added the comment: This patch addresses Ezio's original issue in msg185482 to improve the Windows instructions on the "committing" page of the devguide. I have tried to match the style of the "Getting Started" page when distinguishing UNIX (Mac OS X) commands from Windows commands. Please take extra care during review that the Windows commands documented are correct. Barring reviewer changes, this patch should close this issue. ---------- assignee: -> willingc nosy: +willingc stage: needs patch -> patch review Added file: http://bugs.python.org/file39168/iss17570.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 16:48:38 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Wed, 22 Apr 2015 14:48:38 +0000 Subject: [issue24025] str(bytes_obj) should raise an error In-Reply-To: <1429710754.69.0.366392214947.issue24025@psf.upfronthosting.co.za> Message-ID: <5537B4C0.8020407@egenix.com> Marc-Andre Lemburg added the comment: On 22.04.2015 15:52, R. David Murray wrote: > str accepting bytes and returning the repr was a conscious design choice, as evidenced by the -bb option, and I'm sure there is code that is both unintentionally and *intentionally* using this, despite the warning. Unless we want to discuss making the -bb behavior the default in a future version of python, this issue should be closed. I guess that would be helpful, yes. Here's the original patch which introduced -b and -bb: http://bugs.python.org/issue1392 This was Guido's answer back then: """ I'll look at the patches later, but we've gone over this before on the list. str() of *any* object needs to return *something*. Yes, it's unfortunate that this masks bugs in the transitional period, but it really is the best thing in the long run. We had other exceptional treatement for str vs. bytes (e.g. the comparison was raising TypeError for a while) and we had to kill that too. """ I'm not sure what the "transitional period" refers to, though. It's 8 years later now and doesn't look like str(bytes_object) will go away a source of subtle bugs anytime soon :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 17:08:26 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Apr 2015 15:08:26 +0000 Subject: [issue24026] Python hangs forever in wait() of threading.py In-Reply-To: <1429712264.48.0.476930197364.issue24026@psf.upfronthosting.co.za> Message-ID: <1429715306.38.0.807671896603.issue24026@psf.upfronthosting.co.za> R. David Murray added the comment: This could easily be a programming error. We'd need a cut down reproducer to know if it is a python bug and be able to fix it if so. Have you reported this to paramiko? ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 17:08:54 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 22 Apr 2015 15:08:54 +0000 Subject: [issue20851] Update devguide to cover testing from a tarball In-Reply-To: <1393944432.91.0.924701829685.issue20851@psf.upfronthosting.co.za> Message-ID: <1429715334.54.0.0655540702542.issue20851@psf.upfronthosting.co.za> Brett Cannon added the comment: I don't know if Larry is planning to do tarball releases for 3.5 (added him to the nosy to see). As for the install step, it would be best to suggest people install to a temp directory so they don't accidentally end up with a beta release stuck on their machines, e.g. `make --prefix=/tmp/cpython`. ---------- nosy: +larry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 17:11:24 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Apr 2015 15:11:24 +0000 Subject: [issue24025] str(bytes_obj) should raise an error In-Reply-To: <1429709012.06.0.232941400287.issue24025@psf.upfronthosting.co.za> Message-ID: <1429715484.24.0.725653878084.issue24025@psf.upfronthosting.co.za> R. David Murray added the comment: Yeah, that's why I run tests with -bb myself. Except that there was a bug in -W/-bb handling that meant I wasn't really...and that bit me because there is at least one buildbot that really does, and it complained... (Although in that case the 'bug' was really benign, since it was just optional debug print output for which the repr of the bytes was actually fine.) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 17:19:43 2015 From: report at bugs.python.org (Pablo) Date: Wed, 22 Apr 2015 15:19:43 +0000 Subject: [issue24027] IMAP library lacks documentation about expected parameter types Message-ID: <1429715983.31.0.608966950375.issue24027@psf.upfronthosting.co.za> New submission from Pablo: I used the IMAP library and I feel it lacks a lot of documentation regarding types and encoding. Example: IMAP4.list([directory[, pattern]]): It doesn't state if it expects the directory argument to be an string (unicode) or a imap_utf7 encoded string or bytes. It also expects names with spaces to be between double quotation marks and it doesn't state that it returns a bytes raw output. This is valid for every function that receives a directory or mailbox argument. Also for most return values. Documentation aside, I think it would be a nice improvement in the implementation to add an imap_utf7 convertion function, and check every directory or mailbox argument to see if it has characters outside the imap_utf7 charset and attempts to convert them automatically. ---------- assignee: docs at python components: Documentation messages: 241812 nosy: docs at python, pmoleri priority: normal severity: normal status: open title: IMAP library lacks documentation about expected parameter types type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 17:51:15 2015 From: report at bugs.python.org (Steve Dower) Date: Wed, 22 Apr 2015 15:51:15 +0000 Subject: [issue17570] Improve devguide Windows instructions In-Reply-To: <1364523214.84.0.368819983889.issue17570@psf.upfronthosting.co.za> Message-ID: <1429717875.16.0.91098553147.issue17570@psf.upfronthosting.co.za> Steve Dower added the comment: Right at the end of the patch, ".hg/hgrc" also exists on Windows and is not the same as mercurial.ini - hgrc here is per-repo and it seems from the context that this is relevant here. Otherwise, the rest looks good to me. I'll merge it in when I get a chance, unless someone else gets there first. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 18:34:51 2015 From: report at bugs.python.org (R. David Murray) Date: Wed, 22 Apr 2015 16:34:51 +0000 Subject: [issue24027] IMAP library lacks documentation about expected parameter types In-Reply-To: <1429715983.31.0.608966950375.issue24027@psf.upfronthosting.co.za> Message-ID: <1429720491.45.0.511641003195.issue24027@psf.upfronthosting.co.za> R. David Murray added the comment: Documentation patches are welcome. imaplib has not seen much attention for quite some time (though there is currently someone interested in working on it, so that may change). Please open a separate issue for the utf7 enhancement proposal. ---------- components: +email nosy: +barry, r.david.murray versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 18:58:00 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 22 Apr 2015 16:58:00 +0000 Subject: [issue24028] Idle: add doc subsection on calltips Message-ID: <1429721880.11.0.245757615571.issue24028@psf.upfronthosting.co.za> New submission from Terry J. Reedy: The doc currently says, in the Edit menu section, Show call tip After an unclosed parenthesis for a function, open a small window with function parameter hints. I propose to add the additional information I gave in answer to https://stackoverflow.com/questions/29784273/python-idle-wont-show-docstring, in a subsubsection before or after the current one on completions https://docs.python.org/3/library/idle.html#completions ''' Calltips are shown when one types '(' after the name of an *acccessible* function. The calltip should stay displayed until one types ')' or clicks the mouse or otherwise moves the cursor to dismiss it. Cntl-\ brings it back. A calltip consists of the function signature and the first line of the docstring. For builtins without an accessible signature (such as, in 3.4.3, `int` or `bytes`), the calltip consists of all lines up the fifth line or the first blank line. The set of *accessible* functions depends on what modules have been imported into the user process (where your code is executed), including those imported by Idle itself, and what code has been run (since the last restart). For example, restart the Shell (Cntl-F6), open a new editor window, and enter itertools.count( A calltip appears because Idle imports itertools into the user process for its own use. Enter turtle.write( and nothing appears, because the Idle does not import turtle. Cntl-\ does nothing either. Entering import turtle above the function call does not immediately help, but if one runs the file to perform the import, calltips for turtle functions become available. The suggests that one might want to run a file after writing the import statements at the top, or immediately run an existing file before editing. ''' ---------- assignee: terry.reedy messages: 241815 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Idle: add doc subsection on calltips type: enhancement versions: Python 2.7, Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 19:14:50 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 22 Apr 2015 17:14:50 +0000 Subject: [issue24029] Surprising name binding behavior of submodule imports needs documenting Message-ID: <1429722890.23.0.504523422079.issue24029@psf.upfronthosting.co.za> New submission from Barry A. Warsaw: As described here: http://news.gmane.org/find-root.php?message_id=20150422115959.1ff2ee58%40limelight.wooz.org Importing a submodule binds the submodule's name in the parent module's namespace. This is surprising, but it seems intentional and it's relied upon by existing code, e.g. asyncio/__init__.py in the stdlib. It's also not documented afaict. It should be documented in the Language Reference's section on the import system. After a little more discussion on import-sig, I plan on doing that. ---------- assignee: barry components: Documentation messages: 241816 nosy: barry, brett.cannon priority: normal severity: normal status: open title: Surprising name binding behavior of submodule imports needs documenting type: behavior versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 19:20:15 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 22 Apr 2015 17:20:15 +0000 Subject: [issue24029] Surprising name binding behavior of submodule imports needs documenting In-Reply-To: <1429722890.23.0.504523422079.issue24029@psf.upfronthosting.co.za> Message-ID: <1429723215.79.0.516170111156.issue24029@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: >From Guido: It's definitely intentional, and it's fundamental to the package import design. We've had many implementations of package import (remember "ni.py"? last seen as "knee.py") and it was always there, because this is done as part of *submodule loading*. For better or for worse (and because I didn't know Java at the time :-) Python declares that if you write `import foo.bar` then later in your code you can use `foo.bar` to reference to the bar submodule of package foo. And the way this is done is to make each submodule an attribute of its parent package. This is done when the submodule is first loaded, and because of the strict separation between loading and importing, it is done no matter what form of import was used to load bar. I guess another thing to realize is that the globals of __init__.py are also the attribute namespace of the package. I'm not surprised it's in the reference manual -- that hasn't been updated thoroughly in ages, and I sometimes cry when I see it. :-) So please do clarify this for the benefit of future implementers. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 19:50:52 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 22 Apr 2015 17:50:52 +0000 Subject: [issue24029] Surprising name binding behavior of submodule imports needs documenting In-Reply-To: <1429722890.23.0.504523422079.issue24029@psf.upfronthosting.co.za> Message-ID: <1429725052.67.0.961207229221.issue24029@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: More rationale from the thread: > The surprising part is that it also happens for explicit relative > imports. I'm guessing that part was unintentional and simply not > noticed when PEP 328 was implemented. > No, that must also have been intentional, because even when you use relative import, the module you imported knows its full name, and that full name is used as its key in sys.modules. If someone else uses absolute import for the same module they should still get the same module object. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 19:51:07 2015 From: report at bugs.python.org (Tal Einat) Date: Wed, 22 Apr 2015 17:51:07 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1429725067.95.0.0718287428941.issue20180@psf.upfronthosting.co.za> Tal Einat added the comment: Attaching new patch for unicodeobject.c, which supersedes the previous patches. I've changed the name of the parameter of str.join() to "iterable" to match the docs. (In the previous patch I had changed it from "seq" to "iterable_of_strings".) I also fixed two minor comments on the doc strings from Martin. With this, AFAIK, unicodeobject.c should be good to go. ---------- Added file: http://bugs.python.org/file39169/unicodeobject.c.v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 20:09:39 2015 From: report at bugs.python.org (Larry Hastings) Date: Wed, 22 Apr 2015 18:09:39 +0000 Subject: [issue20851] Update devguide to cover testing from a tarball In-Reply-To: <1393944432.91.0.924701829685.issue20851@psf.upfronthosting.co.za> Message-ID: <1429726179.07.0.291134883822.issue20851@psf.upfronthosting.co.za> Larry Hastings added the comment: I don't plan on doing tarball-only drops during the 3.5 beta/rc period like I did during 3.4. However, when I do a release (e.g. 3.5.0a4), I release Windows binaries (built by Steve Dower), OS X binaries (built by Ned Deily), and source in tarballs. If you're on anything but Windows or OS X you have to build it yourself, from a tarball. So it probably makes sense to have instructions in the dev guide on how to do it. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 20:14:30 2015 From: report at bugs.python.org (Pablo) Date: Wed, 22 Apr 2015 18:14:30 +0000 Subject: [issue24030] IMAP library encoding enhancement Message-ID: <1429726470.47.0.351699535866.issue24030@psf.upfronthosting.co.za> New submission from Pablo: IMAP library doesn't encode parameters to the required charset. The library is useful, but when it comes to complex mailbox names, the user needs to convert strings to and from the custom imap_utf7 encoding. I think this conversion could be implemented in the library and applied transparently to all the arguments that need it. Example: IMAP4.select(mailbox='INBOX', readonly=False): For the method to work, the mailbox argument needs to be encoded to imap_utf7 and if it has spaces it needs to be double quoted. All this hassle could be handled by the library. The same applies to every function that uses a mailbox or directory argument. When it comes to the mailbox argument I can identify the following cases: a. bytes: It should be treated as an already imap_utf7 encoded string. If necessary it can be converted to string using ascii charset. b. string: b.1: It's a valid imap_utf7 string without '&' -> doesn't need encoding. Eg.: INBOX b.2: An already encoded imap_utf7 string with '&' character -> doesn't need encoding. Eg.: Test&AOk- b.3: Any other case (invalid imap_utf7 string) -> needs to be encoded Proposal: 1. Impelement an imap_utf7_encode() method 2. Implement a strict imap_utf7_decode() method, it must return an error if the input doesn't conform to imap_utf7 encoding. 3. Implement a method to ensure arguments are in imap_utf7 encoding: * bytes -> arg.decode('ascii') * string && imap_utf7_decode(arg) -> arg * otherwise -> imap_utf7_encode(arg) * In every case if it has spaces double quote the whole string 5. In every method that receives a mailbox or directory argument call this new method to ensure it's imap_utf7 encoded. ---------- components: Library (Lib), email messages: 241821 nosy: barry, pmoleri, r.david.murray priority: normal severity: normal status: open title: IMAP library encoding enhancement type: enhancement versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 20:33:26 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 22 Apr 2015 18:33:26 +0000 Subject: [issue24029] Surprising name binding behavior of submodule imports needs documenting In-Reply-To: <1429722890.23.0.504523422079.issue24029@psf.upfronthosting.co.za> Message-ID: <1429727606.47.0.435070301243.issue24029@psf.upfronthosting.co.za> Eric Snow added the comment: Guido describes the global invariant for *all* the forms of importing a submodule, including explicit relative imports: > I just mean that for relative import > there is no need to bind the submodule to the parent, is there? But there *is* a reason. The submodule must still be an attribute of the parent package, because of the invariant that if you have sys.modules['foo'] and sys.modules['foo.bar'], the latter must appear as the 'bar' attribute of the former. This is an invariant of module loading, and (I feel I'm repeating myself) the form of import used does not affect loading. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 20:40:34 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 22 Apr 2015 18:40:34 +0000 Subject: [issue23992] multiprocessing: MapResult shouldn't fail fast upon exception In-Reply-To: <1429390680.36.0.641717992291.issue23992@psf.upfronthosting.co.za> Message-ID: Charles-Fran?ois Natali added the comment: Patches for 2.7 and default. ---------- keywords: +patch Added file: http://bugs.python.org/file39170/mp_map_fail_fast_27.diff Added file: http://bugs.python.org/file39171/mp_map_fail_fast_default.diff _______________________________________ Python tracker _______________________________________ -------------- next part -------------- diff -r 5576c8240963 Lib/multiprocessing/pool.py --- a/Lib/multiprocessing/pool.py Wed Apr 15 19:30:38 2015 +0100 +++ b/Lib/multiprocessing/pool.py Wed Apr 22 19:34:48 2015 +0100 @@ -599,10 +599,10 @@ self._number_left = length//chunksize + bool(length % chunksize) def _set(self, i, success_result): + self._number_left -= 1 success, result = success_result - if success: + if success and self._success: self._value[i*self._chunksize:(i+1)*self._chunksize] = result - self._number_left -= 1 if self._number_left == 0: if self._callback: self._callback(self._value) @@ -615,15 +615,17 @@ self._cond.release() else: - self._success = False - self._value = result - del self._cache[self._job] - self._cond.acquire() - try: - self._ready = True - self._cond.notify() - finally: - self._cond.release() + if self._success: + self._success = False + self._value = result + if self._number_left == 0: + del self._cache[self._job] + self._cond.acquire() + try: + self._ready = True + self._cond.notify() + finally: + self._cond.release() # # Class whose instances are returned by `Pool.imap()` diff -r 5576c8240963 Lib/test/test_multiprocessing.py --- a/Lib/test/test_multiprocessing.py Wed Apr 15 19:30:38 2015 +0100 +++ b/Lib/test/test_multiprocessing.py Wed Apr 22 19:34:48 2015 +0100 @@ -1123,6 +1123,12 @@ time.sleep(wait) return x*x + +def raise_large_valuerror(wait): + time.sleep(wait) + raise ValueError("x" * 1024**2) + + class SayWhenError(ValueError): pass def exception_throwing_generator(total, when): @@ -1262,6 +1268,27 @@ p.close() p.join() + def test_map_no_failfast(self): + # Issue #23992: the fail-fast behaviour when an exception is raised + # during map() would make Pool.join() deadlock, because a worker + # process would fill the result queue (after the result handler thread + # terminated, hence not draining it anymore). + + t_start = time.time() + + with self.assertRaises(ValueError): + p = self.Pool(2) + try: + p.map(raise_large_valuerror, [0, 1]) + finally: + time.sleep(0.5) + p.close() + p.join() + + # check that we indeed waited for all jobs + self.assertGreater(time.time() - t_start, 0.9) + + def unpickleable_result(): return lambda: 42 -------------- next part -------------- diff -r 21ae8abc1af3 Lib/multiprocessing/pool.py --- a/Lib/multiprocessing/pool.py Mon Apr 13 12:30:53 2015 -0500 +++ b/Lib/multiprocessing/pool.py Wed Apr 22 19:35:31 2015 +0100 @@ -638,22 +638,24 @@ self._number_left = length//chunksize + bool(length % chunksize) def _set(self, i, success_result): + self._number_left -= 1 success, result = success_result if success: self._value[i*self._chunksize:(i+1)*self._chunksize] = result - self._number_left -= 1 if self._number_left == 0: if self._callback: self._callback(self._value) del self._cache[self._job] self._event.set() else: - self._success = False - self._value = result - if self._error_callback: - self._error_callback(self._value) - del self._cache[self._job] - self._event.set() + if self._success: + self._success = False + self._value = result + if self._number_left == 0: + if self._error_callback: + self._error_callback(self._value) + del self._cache[self._job] + self._event.set() # # Class whose instances are returned by `Pool.imap()` diff -r 21ae8abc1af3 Lib/test/_test_multiprocessing.py --- a/Lib/test/_test_multiprocessing.py Mon Apr 13 12:30:53 2015 -0500 +++ b/Lib/test/_test_multiprocessing.py Wed Apr 22 19:35:31 2015 +0100 @@ -1660,6 +1660,10 @@ def mul(x, y): return x*y +def raise_large_valuerror(wait): + time.sleep(wait) + raise ValueError("x" * 1024**2) + class SayWhenError(ValueError): pass def exception_throwing_generator(total, when): @@ -1889,6 +1893,26 @@ with self.assertRaises(RuntimeError): p.apply(self._test_wrapped_exception) + def test_map_no_failfast(self): + # Issue #23992: the fail-fast behaviour when an exception is raised + # during map() would make Pool.join() deadlock, because a worker + # process would fill the result queue (after the result handler thread + # terminated, hence not draining it anymore). + + t_start = time.time() + + with self.assertRaises(ValueError): + with self.Pool(2) as p: + try: + p.map(raise_large_valuerror, [0, 1]) + finally: + time.sleep(0.5) + p.close() + p.join() + + # check that we indeed waited for all jobs + self.assertGreater(time.time() - t_start, 0.9) + def raising(): raise KeyError("key") From report at bugs.python.org Wed Apr 22 20:43:03 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 22 Apr 2015 18:43:03 +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: <1429728183.54.0.784734733946.issue23992@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Removed file: http://bugs.python.org/file39170/mp_map_fail_fast_27.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 20:43:12 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 22 Apr 2015 18:43:12 +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: <1429728192.8.0.389601520453.issue23992@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Removed file: http://bugs.python.org/file39171/mp_map_fail_fast_default.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 20:50:42 2015 From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=) Date: Wed, 22 Apr 2015 18:50:42 +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: <1429728642.42.0.84771193067.issue23992@psf.upfronthosting.co.za> Changes by Charles-Fran?ois Natali : Added file: http://bugs.python.org/file39172/mp_map_fail_fast_27.diff Added file: http://bugs.python.org/file39173/mp_map_fail_fast_default.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 22:29:35 2015 From: report at bugs.python.org (Christian Heimes) Date: Wed, 22 Apr 2015 20:29:35 +0000 Subject: [issue24031] Add git support to make patchcheck Message-ID: <1429734575.53.0.935403070835.issue24031@psf.upfronthosting.co.za> New submission from Christian Heimes: 'make patchcheck' supports only Mercurial checkouts. The tool uses the 'hg status' command to find modified files. My patch implements 'git status' support in order to make the patch check tool available on git checkouts. ---------- components: Build files: patchcheck_git.patch keywords: patch messages: 241824 nosy: christian.heimes priority: normal severity: normal stage: patch review status: open title: Add git support to make patchcheck type: enhancement versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39174/patchcheck_git.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 23:10:33 2015 From: report at bugs.python.org (Davin Potts) Date: Wed, 22 Apr 2015 21:10:33 +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: <1429737033.24.0.900456355367.issue23979@psf.upfronthosting.co.za> Davin Potts added the comment: @Luis: Before closing this bug, could you give a quick description of the fix you put in place? Two reasons: 1) Someone else encountering this frustration with similar needs might well benefit from hearing what you did. 2) To provide evidence that there is demand for a more efficient means of communication, demonstrated through workarounds. Nothing fancy required -- not even code necessarily. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 23:16:30 2015 From: report at bugs.python.org (Davin Potts) Date: Wed, 22 Apr 2015 21:16:30 +0000 Subject: [issue23713] intermittent failure of multiprocessing unit test test_imap_unordered_handle_iterable_exception In-Reply-To: <1426795503.26.0.283860442544.issue23713@psf.upfronthosting.co.za> Message-ID: <1429737390.32.0.414863545098.issue23713@psf.upfronthosting.co.za> Davin Potts added the comment: Serhiy: If my comments on your questions make sense, should we go ahead with the patch as it is? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 23:17:03 2015 From: report at bugs.python.org (albertsmuktupavels) Date: Wed, 22 Apr 2015 21:17:03 +0000 Subject: [issue24032] urlparse.urljoin does not add query part Message-ID: <1429737423.73.0.596485063186.issue24032@psf.upfronthosting.co.za> New submission from albertsmuktupavels: >From documentation: "Construct a full (?absolute?) URL by combining a ?base URL? (base) with another URL (url). Informally, this uses components of the base URL, in particular the addressing scheme, the network location and (part of) the path, to provide missing components in the relative URL." base = http://www.example.com/example/foo.php?param=10 url = bar.php I am expecting this result: http://www.example.com/example/bar.php?param=10 But real result is: http://www.example.com/example/bar.php This should be easy fixable. Right now query= bquery is done only in one case - when path and params are empty. I think that if not query: query = bquery should be moved before query might be used for first time. that means above code should be right after these lines: if scheme != bscheme or scheme not in uses_relative: return url ---------- messages: 241827 nosy: albertsmuktupavels priority: normal severity: normal status: open title: urlparse.urljoin does not add query part type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 23:36:32 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Apr 2015 21:36:32 +0000 Subject: [issue23887] HTTPError doesn't have a good "repr" representation In-Reply-To: <1428493453.93.0.931112960505.issue23887@psf.upfronthosting.co.za> Message-ID: <20150422213629.21333.77325@psf.io> Roundup Robot added the comment: New changeset e9ea679a92fa by Facundo Batista in branch 'default': Issue #23887: urllib.error.HTTPError now has a proper repr() representation. https://hg.python.org/cpython/rev/e9ea679a92fa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 23:49:04 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 22 Apr 2015 21:49:04 +0000 Subject: [issue24029] Surprising name binding behavior of submodule imports needs documenting In-Reply-To: <1429722890.23.0.504523422079.issue24029@psf.upfronthosting.co.za> Message-ID: <1429739344.09.0.901150600139.issue24029@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Here's some new text for the Language Reference. ---------- Added file: http://bugs.python.org/file39175/issue24029-1.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 22 23:49:10 2015 From: report at bugs.python.org (Facundo Batista) Date: Wed, 22 Apr 2015 21:49:10 +0000 Subject: [issue23887] HTTPError doesn't have a good "repr" representation In-Reply-To: <1428493453.93.0.931112960505.issue23887@psf.upfronthosting.co.za> Message-ID: <1429739350.76.0.915984174296.issue23887@psf.upfronthosting.co.za> Changes by Facundo Batista : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 00:16:27 2015 From: report at bugs.python.org (Eric Snow) Date: Wed, 22 Apr 2015 22:16:27 +0000 Subject: [issue24029] Surprising name binding behavior of submodule imports needs documenting In-Reply-To: <1429722890.23.0.504523422079.issue24029@psf.upfronthosting.co.za> Message-ID: <1429740987.7.0.249175195483.issue24029@psf.upfronthosting.co.za> Eric Snow added the comment: LGTM. You've covered all the key points and the example is good. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 00:25:55 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 22 Apr 2015 22:25:55 +0000 Subject: [issue24029] Surprising name binding behavior of submodule imports needs documenting In-Reply-To: <1429722890.23.0.504523422079.issue24029@psf.upfronthosting.co.za> Message-ID: <1429741555.5.0.713492689377.issue24029@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: Cool, thanks! I'll commit it and we can always clean it up/add to it later if needed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 00:38:37 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 22 Apr 2015 22:38:37 +0000 Subject: [issue24029] Surprising name binding behavior of submodule imports needs documenting In-Reply-To: <1429722890.23.0.504523422079.issue24029@psf.upfronthosting.co.za> Message-ID: <20150422223834.22484.43839@psf.io> Roundup Robot added the comment: New changeset 3968e7a9614c by Barry Warsaw in branch '3.4': Issue #24029: Document the name binding behavior for submodule imports. https://hg.python.org/cpython/rev/3968e7a9614c New changeset 351ad8c4f3a6 by Barry Warsaw in branch '3.4': Issue #24029: Document the name binding behavior for submodule imports. https://hg.python.org/cpython/rev/351ad8c4f3a6 New changeset 6295f207dfaa by Barry Warsaw in branch 'default': Issue #24029: Document the name binding behavior for submodule imports. https://hg.python.org/cpython/rev/6295f207dfaa ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 00:40:30 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 22 Apr 2015 22:40:30 +0000 Subject: [issue24029] Surprising name binding behavior of submodule imports needs documenting In-Reply-To: <1429722890.23.0.504523422079.issue24029@psf.upfronthosting.co.za> Message-ID: <1429742430.13.0.265828989072.issue24029@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 01:11:08 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 22 Apr 2015 23:11:08 +0000 Subject: [issue23227] Generator's finally block not run if close() called before first iteration In-Reply-To: <1421134546.13.0.154248882029.issue23227@psf.upfronthosting.co.za> Message-ID: <1429744268.0.0.406760319132.issue23227@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This looks logical to me. The "finally" block is only entered if the "try" block is ever entered, but if you don't consume anything in the generator then the generator's code is never actually executed. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 01:42:55 2015 From: report at bugs.python.org (A.M. Kuchling) Date: Wed, 22 Apr 2015 23:42:55 +0000 Subject: [issue22501] Optimise PyLong division by 1 or -1 In-Reply-To: <1411717951.94.0.775815371352.issue22501@psf.upfronthosting.co.za> Message-ID: <1429746175.12.0.408555451452.issue22501@psf.upfronthosting.co.za> A.M. Kuchling added the comment: >From reading the discussion thread, it looks like the consensus is to not apply this set of patches because the speed-up is unfortunately small. Closing as won't-fix; please re-open if someone wishes to pursue this again. ---------- nosy: +akuchling resolution: -> wont fix stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 02:05:04 2015 From: report at bugs.python.org (A.M. Kuchling) Date: Thu, 23 Apr 2015 00:05:04 +0000 Subject: [issue10886] Unhelpful backtrace for multiprocessing.Queue In-Reply-To: <1294744619.25.0.366060169853.issue10886@psf.upfronthosting.co.za> Message-ID: <1429747504.81.0.0750094358671.issue10886@psf.upfronthosting.co.za> A.M. Kuchling added the comment: neologix: did you intend to re-open this ticket when you made your 2013-03-05 comment? It seems to me that you didn't intend to -- your comment doesn't say 're-opening because '. I'll close it again; if you want, please re-open it and just explain why. ---------- nosy: +akuchling resolution: -> wont fix stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 02:21:12 2015 From: report at bugs.python.org (Christie) Date: Thu, 23 Apr 2015 00:21:12 +0000 Subject: [issue9517] Make test.script_helper more comprehensive, and use it in the test suite In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za> Message-ID: <1429748472.77.0.965145424702.issue9517@psf.upfronthosting.co.za> Christie added the comment: Hey @berker.peksag, @r.david.murray! Here's another change set where script_helpers.py is moved with an hg mv (still looks in the patch like the file was deleted and re-added, not sure if that's expected). I've ALSO removed some unused imports from script_helpers.py - temp_dir was being imported from script_helpers in a few places tho, so I had to fix that. If you guys would rather not include that change here, please let me know! ---------- Added file: http://bugs.python.org/file39176/iss9517_move_script_helpers.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 02:26:47 2015 From: report at bugs.python.org (Christie) Date: Thu, 23 Apr 2015 00:26:47 +0000 Subject: [issue24033] Update _test_multiprocessing.py to use script helpers Message-ID: <1429748807.96.0.769250379827.issue24033@psf.upfronthosting.co.za> New submission from Christie: As described in Issue9517, many test modules do not make use of the helpers in script_helpers.py to invoke the python interpreter in a subprocess. Issue9517 will be broken down into several smaller issues so we can address smaller change sets. This issue is to update _test_multiprocessing.py to use script_helpers.py. ---------- components: Tests messages: 241837 nosy: bobcatfish priority: normal severity: normal status: open title: Update _test_multiprocessing.py to use script helpers versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 02:27:01 2015 From: report at bugs.python.org (Christie) Date: Thu, 23 Apr 2015 00:27:01 +0000 Subject: [issue24033] Update _test_multiprocessing.py to use script helpers In-Reply-To: <1429748807.96.0.769250379827.issue24033@psf.upfronthosting.co.za> Message-ID: <1429748821.17.0.944634334895.issue24033@psf.upfronthosting.co.za> Christie added the comment: I am working on this! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 02:27:59 2015 From: report at bugs.python.org (Christie) Date: Thu, 23 Apr 2015 00:27:59 +0000 Subject: [issue9517] Make test.script_helper more comprehensive, and use it in the test suite In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za> Message-ID: <1429748879.94.0.261851811999.issue9517@psf.upfronthosting.co.za> Christie added the comment: Created issue24033. If it and issue23981 could be added as dependencies of this issue (or I could get permission to add them?) that would be swell! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 05:19:50 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 23 Apr 2015 03:19:50 +0000 Subject: [issue23887] HTTPError doesn't have a good "repr" representation In-Reply-To: <1428493453.93.0.931112960505.issue23887@psf.upfronthosting.co.za> Message-ID: <1429759190.7.0.422010935932.issue23887@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 05:59:05 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 23 Apr 2015 03:59:05 +0000 Subject: [issue24031] Add git support to make patchcheck In-Reply-To: <1429734575.53.0.935403070835.issue24031@psf.upfronthosting.co.za> Message-ID: <1429761545.27.0.992192315614.issue24031@psf.upfronthosting.co.za> Berker Peksag added the comment: LGTM ---------- nosy: +berker.peksag stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 06:26:06 2015 From: report at bugs.python.org (paul j3) Date: Thu, 23 Apr 2015 04:26:06 +0000 Subject: [issue22848] Subparser help does not respect SUPPRESS argument In-Reply-To: <1415728297.74.0.809984326992.issue22848@psf.upfronthosting.co.za> Message-ID: <1429763166.68.0.628189126732.issue22848@psf.upfronthosting.co.za> paul j3 added the comment: A similar Stackoverflow question http://stackoverflow.com/questions/21692395/hiding-selected-subcommands-using-argparse/21712058#21712058 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 06:41:04 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 23 Apr 2015 04:41:04 +0000 Subject: [issue9517] Make test.script_helper more comprehensive, and use it in the test suite In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za> Message-ID: <1429764064.41.0.164569705592.issue9517@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, Christie. Review comments: http://bugs.python.org/review/9517/ > (still looks in the patch like the file was deleted and re-added, not sure if that's expected). I don't know if it's important. I'm using a very old version of Mercurial (2.0.2 :)), so it can be related to different Mercurial versions. Attaching a patch for reference. ---------- dependencies: +Update _test_multiprocessing.py to use script helpers, Update test_unicodedata.py to use script_helpers Added file: http://bugs.python.org/file39177/issue9517.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 06:47:10 2015 From: report at bugs.python.org (Masayuki Yamamoto) Date: Thu, 23 Apr 2015 04:47:10 +0000 Subject: [issue24034] Make fails Objects/typeslots.inc Message-ID: <1429764430.06.0.333500600321.issue24034@psf.upfronthosting.co.za> New submission from Masayuki Yamamoto: Objects/typeslots.inc is broken, and make stop on cygwin-1.7.35-i686. If built-in python is not found in make processing, Objects/typeslots.inc generating will fail. Because Objects/typeslots.inc is generated using $(PYTHON) in Makefile, but $(PYTHON) variable is a hard-coding value that isn't check a built-in python existent. make steps to fail and error message: $ ./configure --prefix=/opt/py34 $ touch Include/typeslots.h $ make ... python.exe ./Objects/typeslots.py < ./Include/typeslots.h > Objects/typeslots.inc /bin/sh: python.exe: command not found Makefile:851: recipe for target 'Objects/typeslots.inc' failed make: *** [Objects/typeslots.inc] Error 127 Cygwin python executable files: $ find /usr/bin/ -name 'python*.exe' /usr/bin/python2.7.exe /usr/bin/python3.2m.exe ---------- components: Build, Interpreter Core messages: 241843 nosy: masamoto priority: normal severity: normal status: open title: Make fails Objects/typeslots.inc type: compile error versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 06:50:39 2015 From: report at bugs.python.org (Masayuki Yamamoto) Date: Thu, 23 Apr 2015 04:50:39 +0000 Subject: [issue24034] Make fails Objects/typeslots.inc In-Reply-To: <1429764430.06.0.333500600321.issue24034@psf.upfronthosting.co.za> Message-ID: <1429764639.34.0.936383638288.issue24034@psf.upfronthosting.co.za> Masayuki Yamamoto added the comment: I wrote the patch to replace $(PYTHON). Changes: Add TYPESLOTSGEN to configure.ac. TYPESLOTSGEN values is the built-in python. If the built-in python is not found, TYPESLOTSGEN echoes message that is skipping like ASDLGEN. Generated the configure script using autoreconf. Modify Makefile.pre.in to replace $(PYTHON) to $(TYPESLOTSGEN). And remove $(PYTHON) that isn't used anywhere. It seems already needless. Although I understand that the generated file touch can avoid to fail regenerate, I want to check built-in python to generate safer the Objects/typeslots.inc. ---------- keywords: +patch Added file: http://bugs.python.org/file39178/3.4-issue24034-make-fails-typeslots.inc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 07:05:31 2015 From: report at bugs.python.org (James) Date: Thu, 23 Apr 2015 05:05:31 +0000 Subject: [issue24035] When Caps Locked, + alpha-character still displayed as uppercase Message-ID: <1429765531.25.0.768760341138.issue24035@psf.upfronthosting.co.za> New submission from James: Referring to Python 2.7 running on Windows (7/8): At the interactive interpreter, if either 1) Caps are Locked OR 2) is held while an alpha-character is selected, the character is output and displayed as uppercase, as one would expect. However, in Python 2.7, when Caps are Locked AND is held while an alpha-character is selected, the output is still uppercase, when it should be lowercase. This behavior seems to be limited to Python 2(.7), and only when Python is run interactively using the Windows console. When Python 2.7 is started through Cygwin using mintty on Windows 7/8, the behavior is not reproducible. The same goes for IDLE, as well as when running python interactively on Ubuntu. The behavior is reproducible using IPython when run in the standard Windows console, but is not reproducible when Python is run using the IPython QtConsole. To summarize: ----------------------------- ------------------------------- AFFECTED | |NOT AFFECTED | ------------------------------ ------------------------------- python 2 via cmd (Windows 7/8) python 3 via cmd (Windows 7/8) ipython via cmd (Windows 7/8) IDLE python 2 & 3 (Windows 7/8) python 2 via mintty (Windows 7/8) python 2 via bash (Ubuntu 14.04) ipython qtconsole (Windows 7/8) ---------- components: IO messages: 241845 nosy: principia1687 priority: normal severity: normal status: open title: When Caps Locked, + alpha-character still displayed as uppercase type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 08:09:59 2015 From: report at bugs.python.org (SilentGhost) Date: Thu, 23 Apr 2015 06:09:59 +0000 Subject: [issue24035] When Caps Locked, + alpha-character still displayed as uppercase In-Reply-To: <1429765531.25.0.768760341138.issue24035@psf.upfronthosting.co.za> Message-ID: <1429769399.6.0.9791950136.issue24035@psf.upfronthosting.co.za> Changes by SilentGhost : ---------- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 08:32:33 2015 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 23 Apr 2015 06:32:33 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429770753.67.0.646847510687.issue24018@psf.upfronthosting.co.za> Stefan Behnel added the comment: Adding a patch for the inspect docs that refers to the Right Way To Do It. ---------- Added file: http://bugs.python.org/file39179/inspect_docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 08:36:51 2015 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 23 Apr 2015 06:36:51 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429771011.59.0.977105411073.issue24018@psf.upfronthosting.co.za> Changes by Stefan Behnel : Removed file: http://bugs.python.org/file39179/inspect_docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 08:37:11 2015 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 23 Apr 2015 06:37:11 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429771031.29.0.421926707551.issue24018@psf.upfronthosting.co.za> Changes by Stefan Behnel : Added file: http://bugs.python.org/file39180/inspect_docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 08:49:57 2015 From: report at bugs.python.org (Mahmoud Hashemi) Date: Thu, 23 Apr 2015 06:49:57 +0000 Subject: [issue24019] str/unicode encoding kwarg causes exceptions In-Reply-To: <1429592224.08.0.0993607651074.issue24019@psf.upfronthosting.co.za> Message-ID: <1429771797.28.0.245106378886.issue24019@psf.upfronthosting.co.za> Mahmoud Hashemi added the comment: I would urge you all take a stronger look at usability, rather than parroting the current state of the design and docs. Python gained renown over the years for its ability to stay flexible while maturing. Focusing on purity and ignoring the needs of practical programmers is exactly how PEP #461 ended up coming into play so late. The inflexible arguments of str makes a common task, turning data into text, an order of magnitude harder than it needs to be. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 09:16:09 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Apr 2015 07:16:09 +0000 Subject: [issue9517] Make test.script_helper more comprehensive, and use it in the test suite In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za> Message-ID: <1429773369.07.0.808756871758.issue9517@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You should create the patch with "hg diff --git" to preserve moving. And then apply it with "hg import", not the patch command. Unfortunately Rietveld don't like patches in git format. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 09:18:46 2015 From: report at bugs.python.org (Tim Golden) Date: Thu, 23 Apr 2015 07:18:46 +0000 Subject: [issue24035] When Caps Locked, + alpha-character still displayed as uppercase In-Reply-To: <1429765531.25.0.768760341138.issue24035@psf.upfronthosting.co.za> Message-ID: <1429773526.29.0.806317946004.issue24035@psf.upfronthosting.co.za> Tim Golden added the comment: Perhaps unsurprisingly, I can't reproduce this on Python 2.7.9 32-bit running on Win7 Home Premium. Python doesn't handle CapsLock/Shift interaction directly: it just gets what it gets from the underlying OS or framework. So I'm at a loss to know what might cause the effect you're seeing in so particular a way as to affect one version of Python in one i/o framework but not another. Can you reproduce the situation on a different machine? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 10:31:06 2015 From: report at bugs.python.org (Larry Hastings) Date: Thu, 23 Apr 2015 08:31:06 +0000 Subject: [issue23967] Make inspect.signature expression evaluation more powerful In-Reply-To: <1429123957.6.0.780975142449.issue23967@psf.upfronthosting.co.za> Message-ID: <1429777866.97.0.297262578991.issue23967@psf.upfronthosting.co.za> Larry Hastings added the comment: Cleaned up the patch some more--the code was stupid in a couple places. I think it's ready to go in. ---------- Added file: http://bugs.python.org/file39181/larry.improved.signature.expressions.3.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 10:31:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Apr 2015 08:31:39 +0000 Subject: [issue23713] intermittent failure of multiprocessing unit test test_imap_unordered_handle_iterable_exception In-Reply-To: <1426795503.26.0.283860442544.issue23713@psf.upfronthosting.co.za> Message-ID: <1429777899.09.0.365665488687.issue23713@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Thanks for your explanation and sorry for the delay Davin. Yes, it makes sense. ---------- assignee: davin -> serhiy.storchaka stage: patch review -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 10:37:23 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 Apr 2015 08:37:23 +0000 Subject: [issue23713] intermittent failure of multiprocessing unit test test_imap_unordered_handle_iterable_exception In-Reply-To: <1426795503.26.0.283860442544.issue23713@psf.upfronthosting.co.za> Message-ID: <20150423083719.98628.13078@psf.io> Roundup Robot added the comment: New changeset 0ac30526c208 by Serhiy Storchaka in branch '2.7': Issue #23713: Fixed fragility of test_imap_unordered_handle_iterable_exception. https://hg.python.org/cpython/rev/0ac30526c208 New changeset 0eb5968c15ad by Serhiy Storchaka in branch '3.4': Issue #23713: Fixed fragility of test_imap_unordered_handle_iterable_exception. https://hg.python.org/cpython/rev/0eb5968c15ad New changeset f60f65507d8e by Serhiy Storchaka in branch 'default': Issue #23713: Fixed fragility of test_imap_unordered_handle_iterable_exception. https://hg.python.org/cpython/rev/f60f65507d8e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 10:37:49 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Apr 2015 08:37:49 +0000 Subject: [issue23713] intermittent failure of multiprocessing unit test test_imap_unordered_handle_iterable_exception In-Reply-To: <1426795503.26.0.283860442544.issue23713@psf.upfronthosting.co.za> Message-ID: <1429778269.06.0.544119686255.issue23713@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 Apr 23 10:49:52 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Apr 2015 08:49:52 +0000 Subject: [issue23967] Make inspect.signature expression evaluation more powerful In-Reply-To: <1429123957.6.0.780975142449.issue23967@psf.upfronthosting.co.za> Message-ID: <1429778992.97.0.394094881761.issue23967@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Using complex expressions is deceitful. In Python functions the default value is evaluated only once, at function creation time, but inspect.signature will evaluate it every time. For example foo(x={}) and foo(x=dict()) means the same in function declaration, but different in signature. It could also affect security, because allow arbitrary code execution at the place where it was not allowed before. I think this issue should be discussed on Python-Dev. I'm not sure that it is pythonic. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 11:02:54 2015 From: report at bugs.python.org (STINNER Victor) Date: Thu, 23 Apr 2015 09:02:54 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1429779774.67.0.695777925019.issue23863@psf.upfronthosting.co.za> STINNER Victor added the comment: > On POSIX systems using os.times()[4] rather than an absolute time.time(), This is just wrong. os.times() doesn't use seconds, but an "CPU time" which is unrelated. socket.settimeout() uses seconds. By the way, as I wrote before: using the system clock here may introduce bugs when the system clock goes forward to backward, but Python 2.7 doesn't have a monotonic clock :-( That's another reason why I didn't want to fix Python 2.7 or 3.4. > (For UDP it might be a valid thing to do but it still has an odd smell to it) I'm concerned by backward compatibility. Trivial changes was made in Python 2.7 and then came back as regressions because it broke several applications. See recent discussions on this topic on python-dev. Handling EINTR and recompute the timeout is not a trivial changes, some applications rely heavily on the current behaviour of sockets. Network servers using Twisted, eventlet and other libraries. When we say "threads", also think about greenthreads which are used in eventlet to handle sockets. > Some things in 2.7 related to EINTR have already been fixed in the past few years such as data loss in readline() and IIRC writelines(). Correctness isn't a feature. readline()/writelines() don't have a timeout, so it was easier to handle EINTR there. > Do you consider it an API change to prevent an error that nobody relies on or even expects (as PEP 475 notes) and virtually no code is written to properly handle when it _does_ happen? For your information, some people already contacted me because their application behaves differently on Python 3.5 (with the PEP 475). Well, it was easy to modify their code to not rely on EINTR, but it means that "Applications relying on the fact that system calls are interrupted with InterruptedError will hang" exists in the wild. While it's acceptable to change such thing in Python 3.5, a new major version, I asked if it's acceptable for a minor version. By the way, Python 3.5 is not released yet, so we can expect more feedback on PEP 475 changes when Python 3.5 will be released (other regressions in applications?). > Please don't WONTFIX this issue, I intend to get safe fixes in. I suggest WONTFIX for Python 2.7, this issue is *already* fixed in Python 3.5. Come on, in 2015 it's time to upgrade to Python 3! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 11:20:46 2015 From: report at bugs.python.org (Larry Hastings) Date: Thu, 23 Apr 2015 09:20:46 +0000 Subject: [issue23967] Make inspect.signature expression evaluation more powerful In-Reply-To: <1429123957.6.0.780975142449.issue23967@psf.upfronthosting.co.za> Message-ID: <1429780846.08.0.683307329201.issue23967@psf.upfronthosting.co.za> Larry Hastings added the comment: It's only used for signatures in builtins. Any possible security hole here is uninteresting because the evil hacker already got to run arbitrary C code in the module init. Because it's only used for signatures in builtins, we shouldn't encounter a function with a mutable default value like {} or [] which gets mutated later. Builtins don't have those. In case you're wondering about the "trusted" parameter, that was suggested by Nick Coghlan at the PyCon sprints. He's thinking that other callers may use _signature_fromstr() in the future, and he wanted the API to make it clear that future uses may be on non-trustworthy sources. And, finally, consider that the original version already calls eval(). Admittedly it uses eval() in a way that should be much harder to exploit. But it's not an enormous difference between the two calls. I don't really think we need to post to python-dev about this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 11:26:09 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 Apr 2015 09:26:09 +0000 Subject: [issue24031] Add git support to make patchcheck In-Reply-To: <1429734575.53.0.935403070835.issue24031@psf.upfronthosting.co.za> Message-ID: <20150423092606.18899.67792@psf.io> Roundup Robot added the comment: New changeset 0f9c43fb189d by Christian Heimes in branch '3.4': Issue #24031: make patchcheck now supports git checkouts, too. https://hg.python.org/cpython/rev/0f9c43fb189d New changeset d1b706e57fbe by Christian Heimes in branch 'default': Issue #24031: make patchcheck now supports git checkouts, too. https://hg.python.org/cpython/rev/d1b706e57fbe ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 11:26:32 2015 From: report at bugs.python.org (Christian Heimes) Date: Thu, 23 Apr 2015 09:26:32 +0000 Subject: [issue24031] Add git support to make patchcheck In-Reply-To: <1429734575.53.0.935403070835.issue24031@psf.upfronthosting.co.za> Message-ID: <1429781192.76.0.535653198898.issue24031@psf.upfronthosting.co.za> Christian Heimes added the comment: Thanks! ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 11:29:41 2015 From: report at bugs.python.org (Ma Lin) Date: Thu, 23 Apr 2015 09:29:41 +0000 Subject: [issue24036] GB2312 codec is using a wrong covert table Message-ID: <1429781381.54.0.113233811407.issue24036@psf.upfronthosting.co.za> New submission from Ma Lin: While I was trying to optimize GB2312/GBK/GB18030-2000 codecs (they are three encodings that widely used in China), I found there is a bug. The three encodings, their relation should be: GB2312 ? GBK ? GB18030-2000. However, in Python's implement: GB2312 ? GBK ? GB18030-2000. GBK should be backward compatible with GB2312, but in Python's implement, it's not. ---- I digged into, I found the Python's GB2312 codec is using a wrong convert table. In this file /Modules/cjkcodecs/_codecs_cn.c , there is a comment block, I paste it here: /* GBK and GB2312 map differently in few code points that are listed below: * * gb2312 gbk * A1A4 U+30FB KATAKANA MIDDLE DOT U+00B7 MIDDLE DOT * A1AA U+2015 HORIZONTAL BAR U+2014 EM DASH * A844 undefined U+2015 HORIZONTAL BAR */ In fact the second column (GB2312 column) is wrong, this column should be deleted. The four involved unicode codepoints are: U+30FB ? KATAKANA MIDDLE DOT U+00B7 ? MIDDLE DOT U+2015 ? HORIZONTAL BAR U+2014 ? EM DASH So, GB2312 codec decodes b'0xA1, 0xA4' to U+30FB. U+30FB is a Japanese symbol, but looks quite similar to U+00B7. I searched "GB2312 Unicode Table" with Google, there are right verson and wrong version on the Internet, unfortunately we are using the wrong verson. libiconv-1.14 is also using the wrong version. ---- Hold an example of bad behavior. Using GBK encoder, encode U+30FB to bytes, UnicodeEncodeError exception occurred, becase U+30FB is not in GBK. In Simplified Chinese version of Microsoft Windows, console's default encoding is GBK[1]. If using GB2312 decoder to decode b'0xA1, 0xA4', then print U+30FB to console, UnicodeEncodeError raised. Since DASH is a common character, this bug is annoying. ---- If we fix this, I don't know how many disasters will happen. However, if we don't fix this, it's a bug. I already made a patch, but I think we need a discussion, should we fix this? ----------------------- Annotate: [1] In fact console's default encoding is cp936, cp936 almost same as GBK, but not entirely same. Using GBK in here is not a problem. ---------- components: Unicode files: fixgb2312.patch keywords: patch messages: 241858 nosy: Ma Lin, ezio.melotti, haypo priority: normal severity: normal status: open title: GB2312 codec is using a wrong covert table type: behavior versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39182/fixgb2312.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 11:43:55 2015 From: report at bugs.python.org (Ma Lin) Date: Thu, 23 Apr 2015 09:43:55 +0000 Subject: [issue24036] GB2312 codec is using a wrong covert table In-Reply-To: <1429781381.54.0.113233811407.issue24036@psf.upfronthosting.co.za> Message-ID: <1429782235.23.0.648677551273.issue24036@psf.upfronthosting.co.za> Ma Lin added the comment: "Since MIDDLE DOT is a common character, this bug is annoying." Sorry, it's MIDDLE DOT, not DASH. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 12:33:08 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Apr 2015 10:33:08 +0000 Subject: [issue24037] Argument Clinic: add the boolint converter Message-ID: <1429785188.86.0.806042190219.issue24037@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: The 'i' format unit is often used for semantically boolean values. When the parameter has a default value, in Argument clinic you should specify it twice, as Python and C values: closefd: int(c_default="1") = True or keepends: int(py_default="False") = 0 Proposed patch adds the boolint converter which makes a conversion for you. closefd: boolint = True keepends: boolint = False ---------- components: Argument Clinic files: clinic_boolint_converter.patch keywords: patch messages: 241860 nosy: larry, serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: Argument Clinic: add the boolint converter type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file39183/clinic_boolint_converter.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 12:34:41 2015 From: report at bugs.python.org (Petr Viktorin) Date: Thu, 23 Apr 2015 10:34:41 +0000 Subject: [issue23699] Add a macro to ease writing rich comparisons In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za> Message-ID: <1429785281.77.0.805371913627.issue23699@psf.upfronthosting.co.za> Petr Viktorin added the comment: ping Anything I can do to help move this forward? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 12:57:51 2015 From: report at bugs.python.org (Cyd Haselton) Date: Thu, 23 Apr 2015 10:57:51 +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: <1429786671.1.0.939505036585.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: Finally got readline to work with this build, but since the fixes are to the readline source tree I'm not sure if they should go here. With that plus whatever fixes to patches I suggested previously, I think this build works. What would be the next steps for this...running tests? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 14:07:37 2015 From: report at bugs.python.org (Christian Heimes) Date: Thu, 23 Apr 2015 12:07:37 +0000 Subject: [issue23974] random.randrange() biased output In-Reply-To: <1429211399.3.0.0363933708398.issue23974@psf.upfronthosting.co.za> Message-ID: <1429790857.19.0.925224154305.issue23974@psf.upfronthosting.co.za> Christian Heimes added the comment: IMO it's not a security issue at all. If you have to care about security, you shouldn't use the random module at all. random.SystemRandom() merely uses a CPRNG as entropy source. But It also manipulates numbers in ways that may or may not be safe. Only os.getrandom() returns unmodified and unbiased random numbers -- iff the operating system provides a proper CPRNG. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 15:22:23 2015 From: report at bugs.python.org (Tal Einat) Date: Thu, 23 Apr 2015 13:22:23 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1429795343.29.0.591021897222.issue20182@psf.upfronthosting.co.za> Tal Einat added the comment: Note: Despite not appearing in any of these patches, the zlib module seems to have already been converted. ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 15:43:22 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Apr 2015 13:43:22 +0000 Subject: [issue24036] GB2312 codec is using a wrong covert table In-Reply-To: <1429781381.54.0.113233811407.issue24036@psf.upfronthosting.co.za> Message-ID: <1429796602.05.0.542950262882.issue24036@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +lemburg, loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 16:22:58 2015 From: report at bugs.python.org (Christian Heimes) Date: Thu, 23 Apr 2015 14:22:58 +0000 Subject: [issue24038] Missing cleanup in list.sort() with key function Message-ID: <1429798978.55.0.726391099196.issue24038@psf.upfronthosting.co.za> New submission from Christian Heimes: One error path in list.sort() doesn't do proper cleanup. It neither sets an exception nor resets the internal pointers to its former values. In case of failed malloc() it leaves the list object in an invalid state. ---------- components: Interpreter Core files: list_keyfunc.patch keywords: patch messages: 241865 nosy: christian.heimes priority: normal severity: normal stage: patch review status: open title: Missing cleanup in list.sort() with key function type: behavior versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39184/list_keyfunc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 17:06:10 2015 From: report at bugs.python.org (Davin Potts) Date: Thu, 23 Apr 2015 15:06:10 +0000 Subject: [issue24033] Update _test_multiprocessing.py to use script helpers In-Reply-To: <1429748807.96.0.769250379827.issue24033@psf.upfronthosting.co.za> Message-ID: <1429801570.43.0.196761315867.issue24033@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 17:25:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Apr 2015 15:25:24 +0000 Subject: [issue24038] Missing cleanup in list.sort() with key function In-Reply-To: <1429798978.55.0.726391099196.issue24038@psf.upfronthosting.co.za> Message-ID: <1429802724.82.0.425396177593.issue24038@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 18:14:47 2015 From: report at bugs.python.org (Christopher Gurnee) Date: Thu, 23 Apr 2015 16:14:47 +0000 Subject: [issue23974] random.randrange() biased output In-Reply-To: <1429211399.3.0.0363933708398.issue23974@psf.upfronthosting.co.za> Message-ID: <1429805687.51.0.292860810145.issue23974@psf.upfronthosting.co.za> Christopher Gurnee added the comment: > If you have to care about security, you shouldn't use the random module > at all. random.SystemRandom() merely uses a CPRNG as entropy source. But > It also manipulates numbers in ways that may or may not be safe. I must respectfully disagree with this. The current docs say: > Use os.urandom() or SystemRandom if you require a cryptographically > secure pseudo-random number generator. That's a pretty strong statement, and IMO it would lead most to believe that SystemRandom along with *all* of its member functions is safe to use for cryptographic purposes[1] (assuming of course that os.urandom() is also a safe CSPRNG). As a compromise, perhaps SystemRandom could provide its own randrange() with the #9025 fix, while keeping random.randrange() unmodified to preserve the implied same-sequence rule. [1] I don't mean to imply that this bias bug necessarily is a cryptographic safety issue--it seems unlikely to me that it is one, however not being a cryptographer myself, I'd rather not draw any conclusions either way, and instead I'd prefer to err on the side of safety. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 18:34:30 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 23 Apr 2015 16:34:30 +0000 Subject: [issue24025] str(bytes_obj) should raise an error In-Reply-To: <1429709012.06.0.232941400287.issue24025@psf.upfronthosting.co.za> Message-ID: <1429806870.29.0.881779368608.issue24025@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I'm not sure what the "transitional period" refers to, though. The Python 2 -> Python 3 migration. > It's 8 years later now and doesn't look like str(bytes_object) will go away a source of subtle bugs anytime soon str(bytes_object) is perfectly reasonable when logging stuff, for example. Recommend closing. ---------- nosy: +gvanrossum, pitrou resolution: -> rejected status: open -> pending superseder: -> py3k-pep3137: issue warnings / errors on str(bytes()) and similar operations _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 18:45:40 2015 From: report at bugs.python.org (Tal Einat) Date: Thu, 23 Apr 2015 16:45:40 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1429807540.16.0.988026737072.issue20182@psf.upfronthosting.co.za> Tal Einat added the comment: I'm working on a new version of Georg's patch which applies to the current default branch. I'm having trouble with AC output going into a separate file, since this requires a lot of things to be declared before the #include of the .c.h file. Should I move all of those definitions to the top of the file, even if they are currently spread all over it? Should I just add forward declarations? And if the latter, how do I forward-declare a struct typedef? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 18:57:52 2015 From: report at bugs.python.org (Guido van Rossum) Date: Thu, 23 Apr 2015 16:57:52 +0000 Subject: [issue24025] str(bytes_obj) should raise an error In-Reply-To: <1429709012.06.0.232941400287.issue24025@psf.upfronthosting.co.za> Message-ID: <1429808272.92.0.268396003478.issue24025@psf.upfronthosting.co.za> Guido van Rossum added the comment: It would be unacceptable if print(b) were to raise an exception. The reason the transitional period is long is just that people are still porting Python 2 code. ---------- assignee: -> gvanrossum status: pending -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 19:15:06 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Apr 2015 17:15:06 +0000 Subject: [issue24009] Get rid of rare format units in PyArg_Parse* In-Reply-To: <1429470884.11.0.538472438707.issue24009@psf.upfronthosting.co.za> Message-ID: <1429809306.13.0.688926510411.issue24009@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: In textio.c, the decoder always should return bytes, not arbitrary read-only buffer (this is required in other parts of the code). So "y#" can be replaced with "O" with PyBytes_GET_SIZE. ---------- keywords: +patch Added file: http://bugs.python.org/file39185/issue24009_textio_decoder_getstate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 19:48:57 2015 From: report at bugs.python.org (Prince) Date: Thu, 23 Apr 2015 17:48:57 +0000 Subject: [issue24039] Minimize option doesn't work on Search Dialog box for idle Message-ID: <1429811337.7.0.183903934829.issue24039@psf.upfronthosting.co.za> New submission from Prince: I tried to search for a keyword in idle with help of search dialog box, it worked just fine however when I tried to minimize the box it didn't minimize. All other options like expand and close works as expected. Steps To Reproduce: 1) open idle 2) press cntrl+f to open search dialog box. 3) press minimize button on the box. expected - It should minimize Actual - it doesn't Tested on windows7-64bit ---------- components: IDLE messages: 241871 nosy: prince09cs priority: normal severity: normal status: open title: Minimize option doesn't work on Search Dialog box for idle versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 19:56:37 2015 From: report at bugs.python.org (Prince) Date: Thu, 23 Apr 2015 17:56:37 +0000 Subject: [issue24039] Minimize option doesn't work on Search Dialog box for idle In-Reply-To: <1429811337.7.0.183903934829.issue24039@psf.upfronthosting.co.za> Message-ID: <1429811797.23.0.981656466433.issue24039@psf.upfronthosting.co.za> Changes by Prince : ---------- type: -> behavior _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 20:04:18 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Apr 2015 18:04:18 +0000 Subject: [issue24009] Get rid of rare format units in PyArg_Parse* In-Reply-To: <1429470884.11.0.538472438707.issue24009@psf.upfronthosting.co.za> Message-ID: <1429812258.61.0.262166748981.issue24009@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Removed file: http://bugs.python.org/file39185/issue24009_textio_decoder_getstate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 20:04:57 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Apr 2015 18:04:57 +0000 Subject: [issue24009] Get rid of rare format units in PyArg_Parse* In-Reply-To: <1429470884.11.0.538472438707.issue24009@psf.upfronthosting.co.za> Message-ID: <1429812297.97.0.35849065787.issue24009@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file39186/issue24009_textio_decoder_getstate.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 20:19:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Apr 2015 18:19:12 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1429813152.36.0.353200359266.issue20182@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: You only need include generated file before defining PyMethodDef arrays and PyTypeObject instances. There shouldn't be problems if only one class is defined in a file, otherwise you can move these static initializations together to the end of the file. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 20:28:08 2015 From: report at bugs.python.org (Behdad Esfahbod) Date: Thu, 23 Apr 2015 18:28:08 +0000 Subject: [issue11101] plistlib has no graceful way of handing None values In-Reply-To: <1296673853.21.0.702351569168.issue11101@psf.upfronthosting.co.za> Message-ID: <1429813688.66.0.834671775349.issue11101@psf.upfronthosting.co.za> Behdad Esfahbod added the comment: plistlib's internal implementation already supports sort_keys and skipkeys, those just are not wired to load() and loads(). ---------- nosy: +Behdad.Esfahbod _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 20:33:14 2015 From: report at bugs.python.org (Behdad Esfahbod) Date: Thu, 23 Apr 2015 18:33:14 +0000 Subject: [issue10733] plistlib rejects strings containing control characters In-Reply-To: <1292701201.09.0.309647416438.issue10733@psf.upfronthosting.co.za> Message-ID: <1429813994.71.0.0283048570533.issue10733@psf.upfronthosting.co.za> Behdad Esfahbod added the comment: > Replacing all control characters by entities before trying to parse the Plist XML would likely be the best way forward. That wouldn't work. Control characters are disallowed in XML's character set, so they are invalid even if input as entities. Unfortunately this causes a lot of trouble for clients [0], because it means that XML cannot represent the full Unicode repertoire. I'm curious about alternates. Perhaps the expat module can be extended to allow recovering from this if the client chooses to... [0] eg. https://github.com/behdad/fonttools/issues/249 ---------- nosy: +Behdad.Esfahbod _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 20:35:08 2015 From: report at bugs.python.org (Behdad Esfahbod) Date: Thu, 23 Apr 2015 18:35:08 +0000 Subject: [issue24040] plistlib assumes dict_type is descendent of dict Message-ID: <1429814108.42.0.103611722711.issue24040@psf.upfronthosting.co.za> New submission from Behdad Esfahbod: Please replace instances of type({}) in plistlib.py with self._dict_type. ---------- components: Library (Lib) messages: 241875 nosy: Behdad.Esfahbod priority: normal severity: normal status: open title: plistlib assumes dict_type is descendent of dict versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 20:52:10 2015 From: report at bugs.python.org (Behdad Esfahbod) Date: Thu, 23 Apr 2015 18:52:10 +0000 Subject: [issue24041] Implement Mac East Asian encodings properly Message-ID: <1429815130.87.0.76039167858.issue24041@psf.upfronthosting.co.za> New submission from Behdad Esfahbod: encodings.aliases has this in it's tail, even master today [0] # temporary mac CJK aliases, will be replaced by proper codecs in 3.1 'x_mac_japanese' : 'shift_jis', 'x_mac_korean' : 'euc_kr', 'x_mac_simp_chinese' : 'gb2312', 'x_mac_trad_chinese' : 'big5', A full implementation is appreciated. [0] https://github.com/python/cpython/blob/master/Lib/encodings/aliases.py#L539 ---------- components: Library (Lib) messages: 241876 nosy: Behdad.Esfahbod priority: normal severity: normal status: open title: Implement Mac East Asian encodings properly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 20:54:01 2015 From: report at bugs.python.org (Behdad Esfahbod) Date: Thu, 23 Apr 2015 18:54:01 +0000 Subject: [issue24041] Implement Mac East Asian encodings properly In-Reply-To: <1429815130.87.0.76039167858.issue24041@psf.upfronthosting.co.za> Message-ID: <1429815241.53.0.322125215542.issue24041@psf.upfronthosting.co.za> Behdad Esfahbod added the comment: Also, I'm not sure about the 'x_' prefix. It's not kept for the other mac encodings. There's a useful table here: https://github.com/behdad/fonttools/issues/236 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 21:01:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Apr 2015 19:01:02 +0000 Subject: [issue24042] Convert os._getfullpathname() and os._isdir() to Argument Clinic Message-ID: <1429815662.86.0.935887508266.issue24042@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Proposed patch converts os._getfullpathname() and os._isdir() to Argument Clinic. This simplifies a code and as a sided effect adds a check for embedded null character in os._getfullpathname(). The patch is not tested and can contain bugs. ---------- components: Argument Clinic, Windows messages: 241878 nosy: larry, loewis, serhiy.storchaka, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: patch review status: open title: Convert os._getfullpathname() and os._isdir() to Argument Clinic type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 21:01:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Apr 2015 19:01:19 +0000 Subject: [issue24009] Get rid of rare format units in PyArg_Parse* In-Reply-To: <1429470884.11.0.538472438707.issue24009@psf.upfronthosting.co.za> Message-ID: <1429815679.49.0.57864549761.issue24009@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Convert os._getfullpathname() and os._isdir() to Argument Clinic _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 21:01:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Apr 2015 19:01:39 +0000 Subject: [issue24042] Convert os._getfullpathname() and os._isdir() to Argument Clinic In-Reply-To: <1429815662.86.0.935887508266.issue24042@psf.upfronthosting.co.za> Message-ID: <1429815699.58.0.38488574286.issue24042@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- keywords: +patch Added file: http://bugs.python.org/file39187/clinic_os_getfullpathname.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 21:02:04 2015 From: report at bugs.python.org (Behdad Esfahbod) Date: Thu, 23 Apr 2015 19:02:04 +0000 Subject: [issue24043] Implement mac_romanian and mac_croatian encodings Message-ID: <1429815724.46.0.756339237301.issue24043@psf.upfronthosting.co.za> New submission from Behdad Esfahbod: They are used in OpenType fonts, but not implemented by Python at this time. Here's are the Unicode mappings for them: http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMANIAN.TXT http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/CROATIAN.TXT Thanks. ---------- components: Library (Lib) messages: 241879 nosy: Behdad.Esfahbod priority: normal severity: normal status: open title: Implement mac_romanian and mac_croatian encodings versions: Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 21:04:23 2015 From: report at bugs.python.org (Larry Hastings) Date: Thu, 23 Apr 2015 19:04:23 +0000 Subject: [issue24042] Convert os._getfullpathname() and os._isdir() to Argument Clinic In-Reply-To: <1429815662.86.0.935887508266.issue24042@psf.upfronthosting.co.za> Message-ID: <1429815863.35.0.460958878448.issue24042@psf.upfronthosting.co.za> Larry Hastings added the comment: Why isn't the patch tested? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 21:34:53 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Apr 2015 19:34:53 +0000 Subject: [issue24042] Convert os._getfullpathname() and os._isdir() to Argument Clinic In-Reply-To: <1429815662.86.0.935887508266.issue24042@psf.upfronthosting.co.za> Message-ID: <1429817693.66.0.58851348471.issue24042@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I have no Windows. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 21:40:38 2015 From: report at bugs.python.org (Larry Hastings) Date: Thu, 23 Apr 2015 19:40:38 +0000 Subject: [issue24037] Argument Clinic: add the boolint converter In-Reply-To: <1429785188.86.0.806042190219.issue24037@psf.upfronthosting.co.za> Message-ID: <1429818038.5.0.271093514568.issue24037@psf.upfronthosting.co.za> Larry Hastings added the comment: I think this is silly. Python has a well-understood concept of "truth": https://docs.python.org/3/library/stdtypes.html#truth-value-testing I assert that the reason people used the "i" format unit for what are really boolean values is because a) the "p" format unit wasn't added until very recently, and b) they were lazy and it was easy to copy-and-paste from other code. Rather than perpetuate these misguided hacks, when converting code to Argument Clinic we should convert them to properly support truth as defined in Python. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 21:56:46 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Apr 2015 19:56:46 +0000 Subject: [issue24037] Argument Clinic: add the boolint converter In-Reply-To: <1429785188.86.0.806042190219.issue24037@psf.upfronthosting.co.za> Message-ID: <1429819006.23.0.606448171208.issue24037@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I consider this as transitional style, for simpler converting to Argument Clinic without changing the behaviour. In future it can be replaced with bool. But the bool converter has a downside. It is harder to extend it. We can't add a support of say a tuple, or callable, or string, or ternary logic value without potential breaking some code. I propose first convert all semantic boolean ints to the boolint converter, and then, after fundamental analysis, replace boolint with bool if there is no any sense to extend concrete parameter. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 22:17:41 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 23 Apr 2015 20:17:41 +0000 Subject: [issue24041] Implement Mac East Asian encodings properly In-Reply-To: <1429815130.87.0.76039167858.issue24041@psf.upfronthosting.co.za> Message-ID: <1429820261.83.0.656469628235.issue24041@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +hyeshik.chang, lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 22:18:04 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 23 Apr 2015 20:18:04 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1429820284.13.0.358439297396.issue14376@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I am -1 on the patch. (int)PyLong_AsLong(value) can silently convert non-zero error code to zero. I would leave 2.7 as is and limit allowable values to a range supported by the platform. Note that ANSI C standard only specifies two values: EXIT_SUCCESS and EXIT_FAILURE, that may be passed to exit(). ---------- nosy: +belopolsky _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 22:19:16 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 23 Apr 2015 20:19:16 +0000 Subject: [issue24043] Implement mac_romanian and mac_croatian encodings In-Reply-To: <1429815724.46.0.756339237301.issue24043@psf.upfronthosting.co.za> Message-ID: <1429820356.11.0.729405159008.issue24043@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +lemburg, loewis _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 22:22:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Apr 2015 20:22:11 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1429820531.38.0.918893630316.issue14376@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: There are _PyInt_AsInt() and _PyLong_AsInt(). ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 22:26:01 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 23 Apr 2015 20:26:01 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1429820761.75.0.668610690404.issue14376@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: The key issue here is not to report success for nonzero values. I consider the following a bug: $ python3 Python 3.4.2 (default, Oct 30 2014, 08:51:12) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.54)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.exit(256) $ echo $? 0 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 22:29:45 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Thu, 23 Apr 2015 20:29:45 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1429820985.9.0.482306212775.issue14376@psf.upfronthosting.co.za> Ryan Gonzalez added the comment: Now we're getting away from the original issue. This wasn't created to handle edge cases for sys.exit; is was created to make it accept long values under Python 2. ---------- nosy: +Ryan.Gonzalez _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 22:54:43 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Apr 2015 20:54:43 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1429822483.26.0.931590217818.issue14376@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: > The key issue here is not to report success for nonzero values. This is different issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 23:03:08 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 23 Apr 2015 21:03:08 +0000 Subject: [issue24044] NULL pointer dereference in listsort() with key function Message-ID: <1429822988.7.0.684416288083.issue24044@psf.upfronthosting.co.za> New submission from Benjamin Peterson: Found by Christian Heimes: Coverity has found a flaw in Objects/listobject.c:listsort() that eventually leads to a NULL pointer dereference. Because NULL pointer dereferences can lead to exploits or DoS vulnerabilities I'm reporting the error on PSRT first. The error is on a code path that can be triggered by a remote attacker, although not that easily. All Python 3 versions are affected, Python 2.7 looks save. The problematic code line is https://hg.python.org/cpython/file/bc1a178b3bc8/Objects/listobject.c#l19 65 . The code fails to restore self->ob_item to saved_ob_item when PyMem_MALLOC() fails. Subsequent access to the same list object will dereference self->ob_item (which is still NULL) and cause a segfault. A remote attack might be able to trigger the segfault with a large data set. All it takes is an application that sorts this large data set with list.sort() and a custom key function. When Python runs out of memory just in the right spot ... CRASH. Additionally there is another bug, too. list.sort() doesn't set an exception when PyMem_MALLOC() fails. A fix for both issues is simple and straight forward: diff -r bc1a178b3bc8 Objects/listobject.c - --- a/Objects/listobject.c Sat Apr 18 05:54:02 2015 +0200 +++ b/Objects/listobject.c Sat Apr 18 06:29:02 2015 +0200 @@ -1961,8 +1961,10 @@ keys = &ms.temparray[saved_ob_size+1]; else { keys = PyMem_MALLOC(sizeof(PyObject *) * saved_ob_size); - - if (keys == NULL) - - return NULL; + if (keys == NULL) { + PyErr_NoMemory(); + goto keyfunc_fail; + } } for (i = 0; i < saved_ob_size ; i++) { ---------- components: Interpreter Core messages: 241889 nosy: benjamin.peterson, christian.heimes priority: high severity: normal status: open title: NULL pointer dereference in listsort() with key function 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 Thu Apr 23 23:08:08 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 Apr 2015 21:08:08 +0000 Subject: [issue24044] NULL pointer dereference in listsort() with key function In-Reply-To: <1429822988.7.0.684416288083.issue24044@psf.upfronthosting.co.za> Message-ID: <20150423210805.98618.8130@psf.io> Roundup Robot added the comment: New changeset 91096d27c802 by Benjamin Peterson in branch '3.2': properly handle malloc failure (closes #24044) https://hg.python.org/cpython/rev/91096d27c802 New changeset 0d8f15053f42 by Benjamin Peterson in branch '3.3': merge 3.2 (#24044) https://hg.python.org/cpython/rev/0d8f15053f42 New changeset 80485b8e43cd by Benjamin Peterson in branch '3.4': merge 3.3 (#24044) https://hg.python.org/cpython/rev/80485b8e43cd New changeset bd656916586f by Benjamin Peterson in branch 'default': merge 3.4 (#24044) https://hg.python.org/cpython/rev/bd656916586f ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 23:08:18 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 23 Apr 2015 21:08:18 +0000 Subject: [issue24044] NULL pointer dereference in listsort() with key function In-Reply-To: <1429822988.7.0.684416288083.issue24044@psf.upfronthosting.co.za> Message-ID: <1429823298.36.0.166565709226.issue24044@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- versions: -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 23:08:39 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Thu, 23 Apr 2015 21:08:39 +0000 Subject: [issue24038] Missing cleanup in list.sort() with key function In-Reply-To: <1429798978.55.0.726391099196.issue24038@psf.upfronthosting.co.za> Message-ID: <1429823319.58.0.0792149076345.issue24038@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> duplicate status: open -> closed superseder: -> NULL pointer dereference in listsort() with key function _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 23:31:55 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 23 Apr 2015 21:31:55 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1429824715.16.0.839009741322.issue14376@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 23:34:37 2015 From: report at bugs.python.org (Mark Lawrence) Date: Thu, 23 Apr 2015 21:34:37 +0000 Subject: [issue20042] Python Launcher, Windows, fails on scripts w/ non-latin names In-Reply-To: <1387635003.7.0.211054481065.issue20042@psf.upfronthosting.co.za> Message-ID: <1429824877.2.0.198752687326.issue20042@psf.upfronthosting.co.za> Mark Lawrence added the comment: The bug reported in msg225529 has been fixed, but there's another one a few lines up https://hg.python.org/cpython/file/bd656916586f/PC/launcher.c#l265 as there's only one % but two parameters. Although IIRC we'd get away with this the way C works, shouldn't we fix it anyway? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 23:35:29 2015 From: report at bugs.python.org (Ethan Furman) Date: Thu, 23 Apr 2015 21:35:29 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1429824929.03.0.933763986017.issue14376@psf.upfronthosting.co.za> Ethan Furman added the comment: +1 for the fix. Alexander, create a new issue for the problem of converting non-zero values to zero. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 23:41:19 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 23 Apr 2015 21:41:19 +0000 Subject: [issue24007] Write PyArg_Parse* format in a line with a function In-Reply-To: <1429468247.73.0.580298527678.issue24007@psf.upfronthosting.co.za> Message-ID: <20150423214116.82016.56263@psf.io> Roundup Robot added the comment: New changeset 151cab576cab by Serhiy Storchaka in branch 'default': Issue #24007: Argument Clinic now writes the format of PyArg_Parse*() at the https://hg.python.org/cpython/rev/151cab576cab ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 23 23:41:55 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Thu, 23 Apr 2015 21:41:55 +0000 Subject: [issue24007] Write PyArg_Parse* format in a line with a function In-Reply-To: <1429468247.73.0.580298527678.issue24007@psf.upfronthosting.co.za> Message-ID: <1429825315.64.0.481829901678.issue24007@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- assignee: -> serhiy.storchaka resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 00:31:52 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Thu, 23 Apr 2015 22:31:52 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1429828312.6.0.848079947333.issue14376@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: "errors should not pass silently" The "fix" makes the problem worse. Why would anyone want to pass a long integer to exit? I bet the user who discovered this problem had something like 0L or 1L coming from a lazily written C extension. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 01:05:42 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 23 Apr 2015 23:05:42 +0000 Subject: [issue24040] plistlib assumes dict_type is descendent of dict In-Reply-To: <1429814108.42.0.103611722711.issue24040@psf.upfronthosting.co.za> Message-ID: <1429830342.63.0.57477163806.issue24040@psf.upfronthosting.co.za> Ned Deily added the comment: The documentation does not explicitly state whether or not dict_type values have to be instances / subclasses of dict. Can you give a code example, preferably something that could be added to Lib/test/test_plistlib.py, of a use case for something that is not a subclass of dict? Some possible courses of action here: (1) Document that dict_type must be an instance or subclass of dict; (2) Change plistlib as you suggest to allow non-subclasses of dict; (3) Change plistlib to test for a subclass of collections.abc.MutableMapping; (4) other? ---------- nosy: +ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 01:17:52 2015 From: report at bugs.python.org (Ryan Gonzalez) Date: Thu, 23 Apr 2015 23:17:52 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1429828312.6.0.848079947333.issue14376@psf.upfronthosting.co.za> Message-ID: Ryan Gonzalez added the comment: > > "errors should not pass silently" > > The "fix" makes the problem worse. > > Why would anyone want to pass a long integer to exit? > > I bet the user who discovered this problem had something like 0L or 1L > coming from a lazily written C extension. Or the person is using a Python code generator that makes everything a long for portability reasons! Hy does this. int and long are supposed to be indistinguishable. Quote by Guido from the time when I figured out the re module's group function doesn't take longs: ...but any place where an int is accepted but a long is not, is a bug. The language has been on a long trip to making the two types interchangeable and this seems one of the last remnants. Notice the word *interchangeable*. Also, I find that the current behavior is even more confusing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 01:18:04 2015 From: report at bugs.python.org (Behdad Esfahbod) Date: Thu, 23 Apr 2015 23:18:04 +0000 Subject: [issue24040] plistlib assumes dict_type is descendent of dict In-Reply-To: <1429814108.42.0.103611722711.issue24040@psf.upfronthosting.co.za> Message-ID: <1429831084.77.0.347780174747.issue24040@psf.upfronthosting.co.za> Behdad Esfahbod added the comment: I don't have a valid use-case in mind. I was reading the code and noticed this discrepancy. (4) replace the isinstance(self.stack[-1], type({})) with not isinstance(self.stack[-1], type([])). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 01:19:37 2015 From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis) Date: Thu, 23 Apr 2015 23:19:37 +0000 Subject: [issue24044] NULL pointer dereference in listsort() with key function In-Reply-To: <1429822988.7.0.684416288083.issue24044@psf.upfronthosting.co.za> Message-ID: <1429831177.35.0.11898327255.issue24044@psf.upfronthosting.co.za> Changes by Arfrever Frehtes Taifersar Arahesis : ---------- nosy: +Arfrever _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 01:40:12 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 23 Apr 2015 23:40:12 +0000 Subject: [issue24040] plistlib assumes dict_type is descendent of dict In-Reply-To: <1429814108.42.0.103611722711.issue24040@psf.upfronthosting.co.za> Message-ID: <1429832412.88.0.199324827151.issue24040@psf.upfronthosting.co.za> Ned Deily added the comment: Sorry, I don't understand your suggested (4). If someone cares to provide a suggested patch (with appropriate tests), we could review it. Otherwise, I would be inclined to close this issue as not an issue. Ronald, any opinion? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 01:53:08 2015 From: report at bugs.python.org (Behdad Esfahbod) Date: Thu, 23 Apr 2015 23:53:08 +0000 Subject: [issue24040] plistlib assumes dict_type is descendent of dict In-Reply-To: <1429814108.42.0.103611722711.issue24040@psf.upfronthosting.co.za> Message-ID: <1429833188.89.0.977618341261.issue24040@psf.upfronthosting.co.za> Behdad Esfahbod added the comment: The items on the stack are created in two ways: [], and self._dict_type(). Currently the code assumes that self._dict_type() returns an object that passes isinstance(..., type({})). I suggested the following two ways to improve this check: - Replace with: isinstance(..., self._dict_type) - Replace with: not isinstance(..., type([])) Feel free to close. I reported because I saw room for improvement. I don't /need/ the change myself. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 02:00:14 2015 From: report at bugs.python.org (Tal Einat) Date: Fri, 24 Apr 2015 00:00:14 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1429833614.85.0.122132604463.issue20182@psf.upfronthosting.co.za> Tal Einat added the comment: Here's a new version of Georg's patch which applies to the current default branch. On my OSX 10.8, CPython compiles fine and all tests pass, though test_devpoll and test_epoll were skipped. I haven't made additional changes, so there is still AC-related work to be done here. For example, there are legacy converters used throughout the code, which should be replaced. Changes I had to make to get this working: 1) Updated the class declarations in selectmodule.c with the additional parameters. 2) The doc-string for signal.sigwaitinfo was changed since Georg made his patch, and its first line was now too long. I shortened the first line from: Wait synchronously for a signal until one of the signals in *sigset* is delivered. to: Wait synchronously until one of the signals in *sigset* is delivered. 3) Converted the new sys.is_finalizing function. 4) Reverted the signal.set_wakeup_fd function, since it has since been changed, and now depending on #ifdef MS_WINDOWS it interprets the argument as either 'O' or 'i'. I'm not sure what to do with this one, so I reverted it back to not use AC for now. 5) I haven't converted the new signal.default_int_handler function, since it seems to accept any number of arguments, and ignores them. Is there a way to do this with AC? 6) Moved the definitions of object structs and PyTypeObject types to the top of selectmodule.c, so that they are defined when Modules/clinic/selectmodule.c.h is imported. ---------- Added file: http://bugs.python.org/file39188/modules_issue20182_v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 02:11:16 2015 From: report at bugs.python.org (eryksun) Date: Fri, 24 Apr 2015 00:11:16 +0000 Subject: [issue24035] When Caps Locked, + alpha-character still displayed as uppercase In-Reply-To: <1429765531.25.0.768760341138.issue24035@psf.upfronthosting.co.za> Message-ID: <1429834276.15.0.890416228465.issue24035@psf.upfronthosting.co.za> eryksun added the comment: Are you using pyreadline? It's commonly used with IPython. Pyreadline hooks PyOS_ReadlineFunctionPointer to provide readline functionality in the REPL. Since it accesses the console input via ReadConsoleInputW events instead of using ReadConsoleW, it wouldn't surprise me if it's mishandling the keyboard state. ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 02:23:33 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 24 Apr 2015 00:23:33 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1429835013.42.0.605880834186.issue14376@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Passing anything other than one of the os.EX_* constants to sys.exit() is a bad idea. In most cases you can get away with 0 and ?1. Anything beyond 8 bit signed range is a gamble. Passing a computed integer value is even more problematic. With the current behavior, you at least get some diagnostic when a computed long finds its way to sys.axit(). With the proposed patch these errors will pass silently. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 02:47:09 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 24 Apr 2015 00:47:09 +0000 Subject: [issue24045] Behavior of large returncodes (sys.exit(nn)) Message-ID: <1429836429.07.0.888331603842.issue24045@psf.upfronthosting.co.za> New submission from Ethan Furman: Not sure if this is a bug, or just One of Those Things: sys.exit(large_value) can wrap around if the value is too large, but this is O/S dependent. linux (ubuntu 14.04) $ python Python 2.7.8 (default, Oct 20 2014, 15:05:29) [GCC 4.9.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. --> import sys --> sys.exit(256) $ echo $? 0 $ python Python 2.7.8 (default, Oct 20 2014, 15:05:29) [GCC 4.9.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. --> import sys --> sys.exit(257) $ echo $? 1 M$ (Windows 7) > python Python 2.7... --> import sys --> sys.exit(65535) > echo %errorlevel% 65535 > python Python 2.7... --> import sys --> sys.exit(100000) > echo %errorlevel% 100000 Perhaps a minor doc update that talks about return codes and why they might not be exactly what was given to Python? ---------- assignee: docs at python messages: 241903 nosy: docs at python, ethan.furman priority: normal severity: normal status: open title: Behavior of large returncodes (sys.exit(nn)) versions: Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 02:50:13 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 24 Apr 2015 00:50:13 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1429836613.53.0.684295107015.issue14376@psf.upfronthosting.co.za> Ethan Furman added the comment: Linux is not the only O/S that Python runs on. There should be no difference between int and long. Possible doc fix being tracked in issue24045. Gareth, please ignore my comments about adding guards on the return value -- it is up to the O/S to use or adjust whatever Python returns. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 02:54:02 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Fri, 24 Apr 2015 00:54:02 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1429836841.99.0.577307169003.issue23863@psf.upfronthosting.co.za> Gregory P. Smith added the comment: diverging discussion: Go re-read the documentation on os.times(). It is plural, it isn't just CPU time. (on POSIX os.times()[4] is likely to be the system uptime in seconds as a float... it cannot be changed like the absolute clock can, it is a relative monotonic clock). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 03:01:14 2015 From: report at bugs.python.org (Christie) Date: Fri, 24 Apr 2015 01:01:14 +0000 Subject: [issue9517] Make test.script_helper more comprehensive, and use it in the test suite In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za> Message-ID: <1429837274.66.0.744496859586.issue9517@psf.upfronthosting.co.za> Christie added the comment: Hey @berker.peksag, I've added a new patch in response to your review! > You should create the patch with "hg diff --git" to preserve moving. And then apply it with "hg import", not the patch command. Unfortunately Rietveld don't like patches in git format. Ick, I'm guessing it's okay to just use plain old "hg diff" then, if Rietveld doesn't like the patches in git format. ---------- Added file: http://bugs.python.org/file39189/iss9517_move_script_helpers_review1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 03:28:26 2015 From: report at bugs.python.org (aixtools) Date: Fri, 24 Apr 2015 01:28:26 +0000 Subject: [issue6006] ffi.c compile failures on AIX 5.3 with xlc In-Reply-To: <1242148314.87.0.355689567924.issue6006@psf.upfronthosting.co.za> Message-ID: <1429838906.25.0.394927594527.issue6006@psf.upfronthosting.co.za> aixtools added the comment: Although this is closed - it is not (yet) resolved, really. ctypes does not compile on AIX 5.3, or AIX 6.1. Applying the patch posted (https://bugs.python.org/file17098/pyffi.patch) does get rid of most of the problems. However, to completely "fix" it I also copied as follows: cp -rp ../sourceforge/libffi/libffi-3.2.1/src/powerpc ./Python-2.7.8/Modules/_ctypes/libffi/src/powerpc make clean make There are still other issues - BUT - with this ctypes completes as a module of python. ---------- nosy: +aixtools at gmail.com versions: +Python 2.7 -Python 3.0 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 04:54:41 2015 From: report at bugs.python.org (aixtools) Date: Fri, 24 Apr 2015 02:54:41 +0000 Subject: [issue24046] Incomplete build on AIX Message-ID: <1429844081.77.0.468875149896.issue24046@psf.upfronthosting.co.za> New submission from aixtools: Actually, I have been building and using my builds of Python, when needed for ./configure requirements for a long time. In short, it is quite nice that make "completes" even when there are missing and/or failed modules. I have just resolved the problem with ctypes not building (see https://bugs.python.org/issue6006) and that got me started to research others. Failed to build these modules: _elementtree _sqlite3 _ssl bz2 pyexpat While there are several - I am looking first at ssl. My first attempt comes up with some failed defines - probably because the latest openssl provided by IBM is openssl-1.0.0 and openssl-1.0.1 is needed. Rather than wait for that to happen I decided to experiment with LibreSSL. If you are not familiar with LibreSSL - I shall be quick - openbsd (who also maintains openssh) has been cutting out insecure and/or superfluous code. One of the more insecure (because it can be a predictable source of enthropy) is RAND_egd() - so it is unavoidable that this occurs: ld: 0711-317 ERROR: Undefined symbol: .RAND_egd After patching _ssl.c to this: --- _ssl.c.orig 2014-06-30 02:05:42 +0000 +++ _ssl.c 2015-04-24 02:47:00 +0000 @@ -1604,6 +1604,7 @@ static PyObject * PySSL_RAND_egd(PyObject *self, PyObject *arg) { +#ifndef LIBRESSL_VERSION_NUMBER int bytes; if (!PyString_Check(arg)) @@ -1618,6 +1619,12 @@ return NULL; } return PyInt_FromLong(bytes); +#else + PyErr_SetString(PySSLErrorObject, + "external EGD connection not allowed when using LibreSSL:" + "no data to seed the PRNG via PySSL_RAND_egd"); + return NULL; +#endif } PyDoc_STRVAR(PySSL_RAND_egd_doc, The end result is: Failed to build these modules: _elementtree _sqlite3 bz2 pyexpat In short, you can get ahead of the curve by depreciating/removing PySSL_RAND_egd() because any code that uses it may be receiving predictable input and thereafter everything may be predictable. If you do not believe openbsd (or me) - just read the code. It calls anything configured (handy when /dev/urandom was hard to find anno 1999) but these days a backdoor waiting to be opened. p.s. As I get time I shall continue with the other modules that do not build - just let me know if you prefer that I continue posting in this "issue", or make new one(s) for each module as I find a solution. ---------- components: Extension Modules messages: 241908 nosy: aixtools at gmail.com priority: normal severity: normal status: open title: Incomplete build on AIX type: compile error versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 06:19:48 2015 From: report at bugs.python.org (Ma Lin) Date: Fri, 24 Apr 2015 04:19:48 +0000 Subject: [issue24036] GB2312 codec is using a wrong covert table In-Reply-To: <1429781381.54.0.113233811407.issue24036@psf.upfronthosting.co.za> Message-ID: <1429849188.43.0.259118704029.issue24036@psf.upfronthosting.co.za> Ma Lin added the comment: Today, I investigated these popular programming languages, all are the latest version. iconv-1.14 wrong version php-5.6.8 wrong version (php is using iconv) ActivePerl-5.20.2 wrong version GoLang-1.4.2 no GB2312, only has GBK/GB18030 (golang.org/x/text/encoding) Java 1.7.0_79-b15 wrong version (java.nio.charset) .Net 2013 rignt version It seems Python should stay at the wrong version. Very sorry for waste your time. Appendix A: /* The right version's table should be: * * gb2312 gbk * A1A4 U+00B7 MIDDLE DOT U+00B7 MIDDLE DOT * A1AA U+2014 EM DASH U+2014 EM DASH * A844 undefined U+2015 HORIZONTAL BAR */ Appendix B: Advice for final user: 1, Use GBK as much as possible. 2, Be careful when you do interactive operation between GB2312 and GBK/GB18030. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 07:14:00 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Fri, 24 Apr 2015 05:14:00 +0000 Subject: [issue24040] plistlib assumes dict_type is descendent of dict In-Reply-To: <1429832412.88.0.199324827151.issue24040@psf.upfronthosting.co.za> Message-ID: <8027F143-E575-43AB-AA24-A0469217B81E@mac.com> Ronald Oussoren added the comment: The test for type({}) is indeed wrong and should check for self._dict_type instead. However, there needs to be a test before that change is made. -- On the road, hence brief. Op 24 apr. 2015 om 01:40 heeft Ned Deily het volgende geschreven: > > Ned Deily added the comment: > > Sorry, I don't understand your suggested (4). If someone cares to provide a suggested patch (with appropriate tests), we could review it. Otherwise, I would be inclined to close this issue as not an issue. Ronald, any opinion? > > ---------- > > _______________________________________ > Python tracker > > _______________________________________ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 07:17:33 2015 From: report at bugs.python.org (Stephen Drake) Date: Fri, 24 Apr 2015 05:17:33 +0000 Subject: [issue23227] Generator's finally block not run if close() called before first iteration In-Reply-To: <1421134546.13.0.154248882029.issue23227@psf.upfronthosting.co.za> Message-ID: <1429852653.38.0.0355970967883.issue23227@psf.upfronthosting.co.za> Stephen Drake added the comment: Ok, I can accept that. I think my mistake was to assume that because a generator has a close() method, I could treat it as a lightweight wrapper for another closeable object. But it's better to regard a generator function that wraps an iterable as something more akin to map() or filter(), and use a class if it's necessary to wrap a file such that close() is passed through. I happened to take a fresh look at this just the other day and it also occurred to me that the kind of composition I was trying to do can work if it's generators all the way down: def open_lines(name, mode='rt', buffering=-1): with open(name, mode, buffering) as f: for line in f: yield line def logged_lines(f): try: for line in f: logging.warning(line.strip()) yield line finally: f.close() lines = open_lines('yyy', 'r') if verbose: lines = logged_lines(lines) try: for line in lines: print(line) finally: lines.close() So a generator can transparently wrap a plain iterable or another generator, but not closeable objects in general. There's nothing really wrong with that, so I'm happy for this issue to be closed as invalid. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 07:41:44 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Apr 2015 05:41:44 +0000 Subject: [issue24046] Incomplete build on AIX In-Reply-To: <1429844081.77.0.468875149896.issue24046@psf.upfronthosting.co.za> Message-ID: <1429854104.52.0.412983461694.issue24046@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +David.Edelsohn, alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 07:49:07 2015 From: report at bugs.python.org (Elizabeth Myers) Date: Fri, 24 Apr 2015 05:49:07 +0000 Subject: [issue24047] str.startswith and str.endswith should accept multiple arguments. Message-ID: <1429854547.35.0.046111286022.issue24047@psf.upfronthosting.co.za> New submission from Elizabeth Myers: str.startswith and str.endswith should accept multiple arguments when passing in strings. This makes it easier to check if the first character of a string is one of a given option, versus this awkward construction: >>> f = 'abc' >>> 'test'.startswith(tuple(f)) False With my proposal, this could be shortened to 'test'.startswith(*f) for easy testing. This also makes it easier to check if a string begins with one of any combination of matches. ---------- components: Interpreter Core, Unicode messages: 241912 nosy: Elizacat, ezio.melotti, haypo priority: normal severity: normal status: open title: str.startswith and str.endswith should accept multiple arguments. type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 07:55:17 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Apr 2015 05:55:17 +0000 Subject: [issue9517] Make test.script_helper more comprehensive, and use it in the test suite In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za> Message-ID: <1429854917.27.0.760242572899.issue9517@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The committer should be careful, and manually make "hg mv" and apply the patch with the patch command, not "hg import". We shouldn't lost the history. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 07:58:38 2015 From: report at bugs.python.org (Davis Herring) Date: Fri, 24 Apr 2015 05:58:38 +0000 Subject: [issue24048] remove_module() needs to save/restore exception state Message-ID: <1429855118.66.0.488857300303.issue24048@psf.upfronthosting.co.za> New submission from Davis Herring: import.c's remove_module() is always called with an exception set and can invoke arbitrary code via deallocation; if that code calls PyErr_Clear() (or is sensitive to PyErr_Occurred()) it will lose (or be damaged by) the preexisting exception. ---------- components: Interpreter Core messages: 241914 nosy: herring priority: normal severity: normal status: open title: remove_module() needs to save/restore exception state 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 Apr 24 08:03:42 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 24 Apr 2015 06:03:42 +0000 Subject: [issue24047] str.startswith and str.endswith should accept multiple arguments. In-Reply-To: <1429854547.35.0.046111286022.issue24047@psf.upfronthosting.co.za> Message-ID: <1429855422.13.0.713300666696.issue24047@psf.upfronthosting.co.za> Ethan Furman added the comment: We can already do --> some_string.starts_with(('innie','minnie', 'minie', 'moe')) Your proposal appears to be equivalent to: --> 'test'.startswith(('a', 'b', 'c')) How often do you check to see if a string starts with only a single character? -1 tuple() is the correct solution to this problem. ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 08:36:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Apr 2015 06:36:39 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1429857399.46.0.916877236062.issue20182@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: It would be more helpful to split the patch on three independent patches for three modules. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 09:06:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Apr 2015 07:06:39 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1429859198.99.0.0874524409626.issue20182@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: And it would be more helpful to use self-descriptive converter names instead of cryptic format units. ---------- stage: needs patch -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 09:09:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Apr 2015 07:09:58 +0000 Subject: [issue24047] str.startswith and str.endswith should accept multiple arguments. In-Reply-To: <1429854547.35.0.046111286022.issue24047@psf.upfronthosting.co.za> Message-ID: <1429859398.18.0.548685470071.issue24047@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This proposition conflicts with optional parameters of str.startswith(). >>> 'test'.startswith(('a', 'b', 'c'), 1, 3) False ---------- nosy: +serhiy.storchaka resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 09:32:51 2015 From: report at bugs.python.org (Tal Einat) Date: Fri, 24 Apr 2015 07:32:51 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1429860771.84.0.584551053342.issue20182@psf.upfronthosting.co.za> Tal Einat added the comment: Serhiy, I agree on both points. I can easily replace all of the converters and upload it as three separate patches. If you haven't started reviewing the patch yet, let me know and I'll do these things ASAP. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 09:43:53 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 24 Apr 2015 07:43:53 +0000 Subject: [issue24036] GB2312 codec is using a wrong covert table In-Reply-To: <1429781381.54.0.113233811407.issue24036@psf.upfronthosting.co.za> Message-ID: <1429861433.35.0.890822578608.issue24036@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: Hi Ma Lin, thank you for your investigation. In order to fix these tables, we'd need an official reference which shows that there is in fact an error. If most programming languages you have tested use the "wrong" version, then maybe it's not wrong after all :-) Adding a new mapping for A844 should not be a problem and the other mappings don't seem to introduce much difference in terms of how the glyphs look. However, by changing such mappings we'd break roundtrip safety. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 09:47:02 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 24 Apr 2015 07:47:02 +0000 Subject: [issue24046] Incomplete build on AIX In-Reply-To: <1429844081.77.0.468875149896.issue24046@psf.upfronthosting.co.za> Message-ID: <5539F4EC.5080605@egenix.com> Marc-Andre Lemburg added the comment: On 24.04.2015 04:54, aixtools wrote: > Rather than wait for that to happen I decided to experiment with LibreSSL. If you are not familiar with LibreSSL - I shall be quick - openbsd (who also maintains openssh) has been cutting out insecure and/or superfluous code. > > One of the more insecure (because it can be a predictable source of enthropy) is RAND_egd() - so it is unavoidable that this occurs: > > ld: 0711-317 ERROR: Undefined symbol: .RAND_egd > > After patching _ssl.c to this: > --- _ssl.c.orig 2014-06-30 02:05:42 +0000 > +++ _ssl.c 2015-04-24 02:47:00 +0000 > @@ -1604,6 +1604,7 @@ > static PyObject * > PySSL_RAND_egd(PyObject *self, PyObject *arg) > { > +#ifndef LIBRESSL_VERSION_NUMBER > int bytes; > > if (!PyString_Check(arg)) > @@ -1618,6 +1619,12 @@ > return NULL; > } > return PyInt_FromLong(bytes); > +#else > + PyErr_SetString(PySSLErrorObject, > + "external EGD connection not allowed when using LibreSSL:" > + "no data to seed the PRNG via PySSL_RAND_egd"); > + return NULL; > +#endif > } > > PyDoc_STRVAR(PySSL_RAND_egd_doc, > > The end result is: > Failed to build these modules: > _elementtree _sqlite3 bz2 > pyexpat > > In short, you can get ahead of the curve by depreciating/removing PySSL_RAND_egd() because any code that uses it may be receiving predictable input and thereafter everything may be predictable. > > If you do not believe openbsd (or me) - just read the code. It calls anything configured (handy when /dev/urandom was hard to find anno 1999) but these days a backdoor waiting to be opened. > > p.s. As I get time I shall continue with the other modules that do not build - just let me know if you prefer that I continue posting in this "issue", or make new one(s) for each module as I find a solution. Please post this in a new issue, since it's really a separate one. Thanks, -- Marc-Andre Lemburg eGenix.com ---------- nosy: +lemburg _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 09:51:33 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Apr 2015 07:51:33 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1429861893.05.0.704595130615.issue20182@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I already have reviewed changes to select and signal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 10:01:46 2015 From: report at bugs.python.org (Tal Einat) Date: Fri, 24 Apr 2015 08:01:46 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1429862506.79.0.198714459266.issue20180@psf.upfronthosting.co.za> Tal Einat added the comment: Here's a new patch for Objects/unicodeobject.c with all of Serhiy's suggestions integrated. ---------- Added file: http://bugs.python.org/file39190/unicodeobject.c.v4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 10:18:13 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 24 Apr 2015 08:18:13 +0000 Subject: [issue24041] Implement Mac East Asian encodings properly In-Reply-To: <1429815130.87.0.76039167858.issue24041@psf.upfronthosting.co.za> Message-ID: <1429863493.63.0.681024873222.issue24041@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: The "x_" prefix was added as reminder and way to document the desire to look into this at some point: https://github.com/python/cpython/commit/c696b47b10db1fa22b77ecfe1af392b3d62aab61 Before adding more codecs, we always ask whether these are in actual use. Can you provide some evidence of this ? We will also need official references to the definitions of the Mac encodings. Thanks. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 10:24:24 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Apr 2015 08:24:24 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1429863864.54.0.587543300946.issue20180@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: The patch causes a lot of warnings like Objects/unicodeobject.c: In function ?unicode_title_impl?: Objects/unicodeobject.c:10581:5: warning: passing argument 1 of ?_PyUnicode_Ready? from incompatible pointer type [enabled by default] if (PyUnicode_READY(self) == -1) ^ Objects/unicodeobject.c:1484:1: note: expected ?struct PyObject *? but argument is of type ?struct PyUnicodeObject *? _PyUnicode_Ready(PyObject *unicode) ^ ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 10:34:56 2015 From: report at bugs.python.org (Behdad Esfahbod) Date: Fri, 24 Apr 2015 08:34:56 +0000 Subject: [issue24041] Implement Mac East Asian encodings properly In-Reply-To: <1429815130.87.0.76039167858.issue24041@psf.upfronthosting.co.za> Message-ID: <1429864496.19.0.159583336719.issue24041@psf.upfronthosting.co.za> Behdad Esfahbod added the comment: Thanks Marc-Andre. If the x_ was indeed added for that reason, it's quite a coincidence, because the MIME name of these encodings also starts with x-mac-..., so I assumed that's where the x_ comes from. The mappings are available at the Unicode website: http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/JAPANESE.TXT http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/CHINTRAD.TXT http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/KOREAN.TXT http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/CHINSIMP.TXT As for actual use, they are part of the OpenType standard. So by user request, I had to implement them last week in the FontTools Python library. This is useful for people when dealing with old and legacy fonts, specially in the process of converting them to Unicode-compatible fonts. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 10:40:29 2015 From: report at bugs.python.org (Prince) Date: Fri, 24 Apr 2015 08:40:29 +0000 Subject: [issue24039] Minimize option doesn't work on Search Dialog box for idle In-Reply-To: <1429811337.7.0.183903934829.issue24039@psf.upfronthosting.co.za> Message-ID: <1429864829.23.0.223773690963.issue24039@psf.upfronthosting.co.za> Changes by Prince : ---------- nosy: +roger.serwy, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 10:58:36 2015 From: report at bugs.python.org (Tal Einat) Date: Fri, 24 Apr 2015 08:58:36 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1429865916.37.0.624252089157.issue20180@psf.upfronthosting.co.za> Tal Einat added the comment: Version of patch with PyUnicodeObject * warnings fixed. ---------- Added file: http://bugs.python.org/file39191/unicodeobject.c.v5.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 11:07:52 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 24 Apr 2015 09:07:52 +0000 Subject: [issue24041] Implement Mac East Asian encodings properly In-Reply-To: <1429864496.19.0.159583336719.issue24041@psf.upfronthosting.co.za> Message-ID: <553A07DE.7010002@egenix.com> Marc-Andre Lemburg added the comment: On 24.04.2015 10:34, Behdad Esfahbod wrote: > > Thanks Marc-Andre. If the x_ was indeed added for that reason, it's quite a coincidence, because the MIME name of these encodings also starts with x-mac-..., so I assumed that's where the x_ comes from. Oh, I didn't know that :-) Hmm, I can't find the names listed as IANA charset, so the "x-" prefix then probably means non-standard. http://www.iana.org/assignments/character-sets/character-sets.xhtml > The mappings are available at the Unicode website: > http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/JAPANESE.TXT > http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/CHINTRAD.TXT > http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/KOREAN.TXT > http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/CHINSIMP.TXT > > As for actual use, they are part of the OpenType standard. So by user request, I had to implement them last week in the FontTools Python library. This is useful for people when dealing with old and legacy fonts, specially in the process of converting them to Unicode-compatible fonts. This may be an indication that it's better to put those codecs into a PyPI package, rather than Python itself. The above tables are huge (as most Asian codec tables). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 11:10:16 2015 From: report at bugs.python.org (appidman) Date: Fri, 24 Apr 2015 09:10:16 +0000 Subject: [issue24026] Python hangs forever in wait() of threading.py In-Reply-To: <1429712264.48.0.476930197364.issue24026@psf.upfronthosting.co.za> Message-ID: <1429866616.63.0.602404441109.issue24026@psf.upfronthosting.co.za> appidman added the comment: I created a issue for paramiko: https://github.com/paramiko/paramiko/issues/515 I'm trying to create a script which reproduces the bug, but it might be a bit tough, because as I said it's not happening all the time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 11:13:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Apr 2015 09:13:48 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1429866828.89.0.968184416609.issue20180@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: unicodeobject.c.v5.patch LGTM. ---------- stage: needs patch -> commit review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 11:31:38 2015 From: report at bugs.python.org (Tal Einat) Date: Fri, 24 Apr 2015 09:31:38 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1429867898.3.0.641044154589.issue20180@psf.upfronthosting.co.za> Tal Einat added the comment: Hurrah! And that seems to be it for this group, since collections, itertools and random are not to be converted at this point, as well as the Modules/xx*.c files, and the stringlib files probably require overly extensive changes for conversion. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 12:29:04 2015 From: report at bugs.python.org (Berker Peksag) Date: Fri, 24 Apr 2015 10:29:04 +0000 Subject: [issue23356] In argparse docs simplify example about argline In-Reply-To: <1422693639.9.0.487352753219.issue23356@psf.upfronthosting.co.za> Message-ID: <1429871344.02.0.10861646742.issue23356@psf.upfronthosting.co.za> Berker Peksag added the comment: LGTM ---------- assignee: docs at python -> berker.peksag nosy: +berker.peksag stage: -> commit review type: performance -> enhancement versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 13:31:24 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 24 Apr 2015 11:31:24 +0000 Subject: [issue24043] Implement mac_romanian and mac_croatian encodings In-Reply-To: <1429815724.46.0.756339237301.issue24043@psf.upfronthosting.co.za> Message-ID: <553A2981.4000002@egenix.com> Marc-Andre Lemburg added the comment: On 23.04.2015 21:02, Behdad Esfahbod wrote: > > They are used in OpenType fonts, but not implemented by Python at this time. Here's are the Unicode mappings for them: > > http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMANIAN.TXT > http://unicode.org/Public/MAPPINGS/VENDORS/APPLE/CROATIAN.TXT Can you provide some evidence that these are still in use (I mean content being available encoded in these encodings) ? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 14:03:13 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 24 Apr 2015 12:03:13 +0000 Subject: [issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files In-Reply-To: <1389140162.94.0.578256004005.issue20180@psf.upfronthosting.co.za> Message-ID: <1429876993.4.0.385792428972.issue20180@psf.upfronthosting.co.za> Stefan Krah added the comment: > Sadly, for political reasons, it's best that we not convert collections, itertools, or random for now. Well, there are also technical reasons. For example, when reviewing a huge patch at the beginning of this year, the sections that touched AC took me 10 times longer to review than the rest. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 14:09:16 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Apr 2015 12:09:16 +0000 Subject: [issue23880] Tkinter: getint and getdouble should support Tcl_Obj In-Reply-To: <1428396064.01.0.00215215635093.issue23880@psf.upfronthosting.co.za> Message-ID: <1429877356.52.0.185042285714.issue23880@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: >> 2. Does the change break existing code? > > Usually not. I meant that the only difference (except that now Tkinter can work in cases where it failed before) is that that some exceptions can change its type from ValueError to TclError. But first, these exception are unlikely raised, and second, getint() and getdouble() are used to convert the result of call(), that can raise a TclError, so this doesn't add new exception type. However, to decrease even such minor probability of the breakage, the patch for 3.4 and 2.7 uses widget.getint() instead of widget.tk.getint(). This wrapper converts TclError to ValueError. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 14:09:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Apr 2015 12:09:42 +0000 Subject: [issue23880] Tkinter: getint and getdouble should support Tcl_Obj In-Reply-To: <1428396064.01.0.00215215635093.issue23880@psf.upfronthosting.co.za> Message-ID: <1429877382.86.0.302762966194.issue23880@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file39192/tkinter_getxxx_tclobj-3.4.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 14:09:58 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Apr 2015 12:09:58 +0000 Subject: [issue23880] Tkinter: getint and getdouble should support Tcl_Obj In-Reply-To: <1428396064.01.0.00215215635093.issue23880@psf.upfronthosting.co.za> Message-ID: <1429877398.98.0.696853637824.issue23880@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file39193/tkinter_getxxx_tclobj-2.7.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 14:24:57 2015 From: report at bugs.python.org (Tal Einat) Date: Fri, 24 Apr 2015 12:24:57 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1429878297.42.0.993727298407.issue20182@psf.upfronthosting.co.za> Tal Einat added the comment: Here's a patch just for Modules/signalmodule.c (and related files), based on Georg's patch, updated to apply against current default, including fixes thanks to Serhiy's review. This include one minor doc change, since I changed the name of the second parameter to signal.pthread_kill from "signum" to "signalnum" to be consistent with the rest of the signal module. This will not break existing code since this parameter is positional-only. ---------- Added file: http://bugs.python.org/file39194/issue20182.signalmodule.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 14:36:02 2015 From: report at bugs.python.org (Nick Craig-Wood) Date: Fri, 24 Apr 2015 12:36:02 +0000 Subject: [issue24049] Remove unused code in symtable.c and fix docs for import * checking Message-ID: <1429878962.91.0.558127171831.issue24049@psf.upfronthosting.co.za> New submission from Nick Craig-Wood: Here is a patch to remove some unused code in `symtable.c` In Python3 `from x import *` was banned from use in functions completely. This is detected by `symtable_visit_alias` if (st->st_cur->ste_type != ModuleBlock) { int lineno = st->st_cur->ste_lineno; int col_offset = st->st_cur->ste_col_offset; PyErr_SetString(PyExc_SyntaxError, IMPORT_STAR_WARNING); However in `check_unoptimized` it checks for `import *` being used in a nested function etc. This is the python2 behaviour which wasn't removed at the time the new python3 behaviour was added. According to my analysis and tests it is now impossible for `check_unoptimized` to raise an error, since only valid uses of `import *` are left at the point it is called. I propose to remove that function entirely, its call, and fix some stray documentation in this patch. ---------- components: Interpreter Core files: python3.5-symtable.patch keywords: patch messages: 241937 nosy: ncw priority: normal severity: normal status: open title: Remove unused code in symtable.c and fix docs for import * checking type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file39195/python3.5-symtable.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 14:41:23 2015 From: report at bugs.python.org (Ma Lin) Date: Fri, 24 Apr 2015 12:41:23 +0000 Subject: [issue24036] GB2312 codec is using a wrong covert table In-Reply-To: <1429781381.54.0.113233811407.issue24036@psf.upfronthosting.co.za> Message-ID: <1429879283.88.0.26392230152.issue24036@psf.upfronthosting.co.za> Ma Lin added the comment: Andre Lemburg, We don't need any modify, A844 is in GBK but not in GB2312, so no need to add it into GB2312. Your logic is right, it's hard to judge which one is wrong. But U+30FB (? KATAKANA MIDDLE DOT) and U+2015 (? HORIZONTAL BAR) have no reason among these Chinese common punctuation symbol. A1A2-A1B7: ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ? ? ? ? ? ? ? If they are U+00B7 (? MIDDLE DOT) and U+2014 (? EM DASH), this section looks more reasonable. GB2312 was published in early 1980s, it seems there was a historical accident. Luckily, most programming languages are on the same side. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 15:15:25 2015 From: report at bugs.python.org (Thomas Wouters) Date: Fri, 24 Apr 2015 13:15:25 +0000 Subject: [issue5438] test_bigmem.test_from_2G_generator uses more memory than expected In-Reply-To: <1236475515.92.0.849329057425.issue5438@psf.upfronthosting.co.za> Message-ID: <1429881325.22.0.673791550886.issue5438@psf.upfronthosting.co.za> Thomas Wouters added the comment: Rewriting the tests shouldn't block this specific issue, no. Also, don't use multiprocessing for it. I would just use subprocess to start a separate process (which might after all be OOM-killed,) check the exitcode, and record its stderr in case of failure. Given that Steve ran the bigmem tests with a high limit and they all passed means that it's not pressing, though -- while it would be *good* to make these tests easier, and the skips more obvious, it's a good sign that nothing broke :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 15:34:45 2015 From: report at bugs.python.org (nivin) Date: Fri, 24 Apr 2015 13:34:45 +0000 Subject: [issue24050] Segmentation fault (core dumped) Message-ID: <1429882485.21.0.520202259055.issue24050@psf.upfronthosting.co.za> New submission from nivin: Got an error as Segmentation fault (core dumped) when executed a python script . Error getting only for a specific python script only ---------- components: Interpreter Core messages: 241940 nosy: nivin priority: normal severity: normal status: open title: Segmentation fault (core dumped) versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 15:38:20 2015 From: report at bugs.python.org (Skip Montanaro) Date: Fri, 24 Apr 2015 13:38:20 +0000 Subject: [issue24050] Segmentation fault (core dumped) In-Reply-To: <1429882485.21.0.520202259055.issue24050@psf.upfronthosting.co.za> Message-ID: <1429882700.89.0.355878963197.issue24050@psf.upfronthosting.co.za> Skip Montanaro added the comment: Can you provide a trimmed down example which provokes the segmentation fault? ---------- nosy: +skip.montanaro _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 15:48:14 2015 From: report at bugs.python.org (Shinto Peter) Date: Fri, 24 Apr 2015 13:48:14 +0000 Subject: [issue24050] Segmentation fault (core dumped) In-Reply-To: <1429882485.21.0.520202259055.issue24050@psf.upfronthosting.co.za> Message-ID: <1429883294.79.0.686643418897.issue24050@psf.upfronthosting.co.za> Shinto Peter added the comment: check this this link : http://jodal.no/post/5779178001/log-from-the-debugging-of-a-segfault/ tells about Segfault ---------- nosy: +shinto _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 15:48:50 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Apr 2015 13:48:50 +0000 Subject: [issue24051] Argument Clinic no longer works with single optional argument Message-ID: <1429883330.67.0.210732695704.issue24051@psf.upfronthosting.co.za> New submission from Serhiy Storchaka: Argument Clinic no longer works single optional argument. For example see _tkinter.tkapp.wantobjects in the patch in issue20168. /*[clinic input] _tkinter.tkapp.wantobjects [ value: int ] / [clinic start generated code]*/ It is converted to the methoddef of type METH_O. #define _TKINTER_TKAPP_WANTOBJECTS_METHODDEF \ {"wantobjects", (PyCFunction)_tkinter_tkapp_wantobjects, METH_O, _tkinter_tkapp_wantobjects__doc__}, static PyObject * _tkinter_tkapp_wantobjects(PyObject *self, PyObject *arg) { PyObject *return_value = NULL; int group_right_1 = 0; int value = 0; if (!PyArg_Parse(arg, "i:wantobjects", &value)) goto exit; return_value = _tkinter_tkapp_wantobjects_impl(self, group_right_1, value); exit: return return_value; } As result wantobjects() can't be called without an argument. ---------- components: Argument Clinic messages: 241943 nosy: larry, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Argument Clinic no longer works with single optional argument type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 15:49:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Apr 2015 13:49:13 +0000 Subject: [issue20168] Derby: Convert the _tkinter module to use Argument Clinic In-Reply-To: <1389128639.57.0.613370502446.issue20168@psf.upfronthosting.co.za> Message-ID: <1429883353.46.0.33383533225.issue20168@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- dependencies: +Argument Clinic no longer works with single optional argument _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 16:37:24 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 24 Apr 2015 14:37:24 +0000 Subject: [issue24050] Segmentation fault (core dumped) In-Reply-To: <1429882485.21.0.520202259055.issue24050@psf.upfronthosting.co.za> Message-ID: <1429886244.78.0.668905956889.issue24050@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 16:38:00 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 24 Apr 2015 14:38:00 +0000 Subject: [issue24049] Remove unused code in symtable.c and fix docs for import * checking In-Reply-To: <1429878962.91.0.558127171831.issue24049@psf.upfronthosting.co.za> Message-ID: <1429886280.94.0.765097703224.issue24049@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 16:39:35 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 24 Apr 2015 14:39:35 +0000 Subject: [issue24048] remove_module() needs to save/restore exception state In-Reply-To: <1429855118.66.0.488857300303.issue24048@psf.upfronthosting.co.za> Message-ID: <1429886375.92.0.57659738815.issue24048@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- nosy: +brett.cannon, eric.snow, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 17:14:31 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 24 Apr 2015 15:14:31 +0000 Subject: [issue23810] Suboptimal stacklevel of deprecation warnings for formatter and imp modules In-Reply-To: <1427680454.72.0.13356883084.issue23810@psf.upfronthosting.co.za> Message-ID: <1429888471.22.0.0209548672456.issue23810@psf.upfronthosting.co.za> Brett Cannon added the comment: Here is a private function in warnings for calculating the stack depth to the first frame not referencing some key string. Can someone look at it to make sure it looks reasonable? I'm starting with it being private since it uses sys._getframe() and I don't know how widely needed it is. ---------- keywords: +patch stage: test needed -> patch review versions: -Python 3.4 Added file: http://bugs.python.org/file39196/better_stacklevel.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 17:15:11 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 24 Apr 2015 15:15:11 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1429888511.13.0.139546399623.issue14376@psf.upfronthosting.co.za> Ethan Furman added the comment: I previously wrote: ------------------ > Gareth, please ignore my comments about adding guards on the return value -- it is up > to the O/S to use or adjust whatever Python returns. Let me clarify that a bit: we need to protect against overflow from to ; protecting against overflow from to is a separate issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 17:29:13 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 24 Apr 2015 15:29:13 +0000 Subject: [issue24052] sys.exit(code) returns "success" to the OS for some values of code Message-ID: <1429889353.58.0.941477823236.issue24052@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: $ python3 Python 3.4.3 (default, Mar 2 2015, 11:08:35) [GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> import subprocess >>> subprocess.call([sys.executable, '-c', "import sys;sys.exit(512)"]) 0 >>> subprocess.call([sys.executable, '-c', "import sys;sys.exit(256)"]) 0 See also #14376. ---------- components: Interpreter Core messages: 241946 nosy: belopolsky priority: normal severity: normal status: open title: sys.exit(code) returns "success" to the OS for some values of code type: behavior versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 17:30:56 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 24 Apr 2015 15:30:56 +0000 Subject: [issue14376] sys.exit documents argument as "integer" but actually requires "subtype of int" In-Reply-To: <1332288480.19.0.200013792885.issue14376@psf.upfronthosting.co.za> Message-ID: <1429889456.32.0.388737724926.issue14376@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > Alexander, create a new issue for the problem of converting non-zero values to zero. See #24052. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 17:40:31 2015 From: report at bugs.python.org (Tim Pierce) Date: Fri, 24 Apr 2015 15:40:31 +0000 Subject: [issue22931] cookies with square brackets in value In-Reply-To: <1416843804.34.0.815840624187.issue22931@psf.upfronthosting.co.za> Message-ID: <1429890031.75.0.0303789671473.issue22931@psf.upfronthosting.co.za> Tim Pierce added the comment: Adding Python 2.7 to the affected versions (from #23341 which was closed as a duplicate of this bug). We are very interested to know whether this will be fixed in a Python 2.7 patch as well. ---------- nosy: +twpierce versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 17:47:49 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 24 Apr 2015 15:47:49 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys Message-ID: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> New submission from Alexander Belopolsky: Python defines some BSDish exit codes in the os module: EX_CANTCREAT = 73 EX_CONFIG = 78 EX_DATAERR = 65 EX_IOERR = 74 EX_NOHOST = 68 EX_NOINPUT = 66 EX_NOPERM = 77 EX_NOUSER = 67 EX_OK = 0 EX_OSERR = 71 EX_OSFILE = 72 EX_PROTOCOL = 76 EX_SOFTWARE = 70 EX_TEMPFAIL = 75 EX_UNAVAILABLE = 69 EX_USAGE = 64 but these are documented as only available on UNIX and may not be portable across all flavors. POSIX [1] and C99 defines EXIT_SUCCESS and EXIT_FAILURE constants. I propose adding those to sys. Having these constants in sys will make them more discoverable because they will be next to sys.exit(). [1] http://pubs.opengroup.org/onlinepubs/009695399/functions/exit.html ---------- messages: 241949 nosy: belopolsky priority: normal severity: normal status: open title: Define EXIT_SUCCESS and EXIT_FAILURE constants in sys type: enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 17:56:27 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 24 Apr 2015 15:56:27 +0000 Subject: [issue23893] Forward-port future_builtins In-Reply-To: <1428530020.25.0.529453311381.issue23893@psf.upfronthosting.co.za> Message-ID: <1429890987.82.0.768784051333.issue23893@psf.upfronthosting.co.za> Brett Cannon added the comment: I've decided that having the module exist in Python 2.7 and 3.5 but not 3.0 - 3.4 is just asking for trouble. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 17:56:59 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 24 Apr 2015 15:56:59 +0000 Subject: [issue14019] Unify tests for str.format and string.Formatter In-Reply-To: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za> Message-ID: <1429891019.67.0.304991268889.issue14019@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- assignee: brett.cannon -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 18:03:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Apr 2015 16:03:00 +0000 Subject: [issue24049] Remove unused code in symtable.c and fix docs for import * checking In-Reply-To: <1429878962.91.0.558127171831.issue24049@psf.upfronthosting.co.za> Message-ID: <20150424160256.30339.4530@psf.io> Roundup Robot added the comment: New changeset 135d5a3e415b by Benjamin Peterson in branch '3.4': remove dead *-import checking code (closes #24049) https://hg.python.org/cpython/rev/135d5a3e415b New changeset 5c0247a6f98a by Benjamin Peterson in branch 'default': merge 3.4 (#24049) https://hg.python.org/cpython/rev/5c0247a6f98a ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 18:07:25 2015 From: report at bugs.python.org (Stefan Krah) Date: Fri, 24 Apr 2015 16:07:25 +0000 Subject: [issue24052] sys.exit(code) returns "success" to the OS for some values of code In-Reply-To: <1429889353.58.0.941477823236.issue24052@psf.upfronthosting.co.za> Message-ID: <1429891645.18.0.86773880211.issue24052@psf.upfronthosting.co.za> Stefan Krah added the comment: At first glance the return values look right to me: The value of exit returned to the parent should be status & 0377. ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 18:22:05 2015 From: report at bugs.python.org (Wolfgang Maier) Date: Fri, 24 Apr 2015 16:22:05 +0000 Subject: [issue23356] In argparse docs simplify example about argline In-Reply-To: <1422693639.9.0.487352753219.issue23356@psf.upfronthosting.co.za> Message-ID: <1429892525.97.0.58358513446.issue23356@psf.upfronthosting.co.za> Changes by Wolfgang Maier : ---------- nosy: +wolma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 18:29:54 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 24 Apr 2015 16:29:54 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1429892994.8.0.622004891791.issue24053@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I am attaching a patch implementing these constants. If this is well-received, I will add documentation. ---------- assignee: -> belopolsky keywords: +easy, patch stage: -> patch review versions: +Python 3.5 Added file: http://bugs.python.org/file39197/issue24053.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 18:32:11 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 24 Apr 2015 16:32:11 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1429893131.75.0.701786519692.issue24053@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +ethan.furman, mark.dickinson, serhiy.storchaka, terry.reedy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 18:43:21 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 24 Apr 2015 16:43:21 +0000 Subject: [issue24052] sys.exit(code) returns "success" to the OS for some values of code In-Reply-To: <1429889353.58.0.941477823236.issue24052@psf.upfronthosting.co.za> Message-ID: <1429893801.78.0.347031200987.issue24052@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > The value of exit returned to the parent should be status & 0377. Apparently, this is not so on Windows. See msg241903 in #24045. POSIX defines [1] exit to return status & 0377, but that does not mean that sys.exit(256) must return 0 without a warning. It is very unlikely that someone would intentionally use code=256 to signify success. It is much more likely that sys.exit(256) is a result of a programming error. I believe a better behavior for sys.exit() would be to truncate the code values to 8-bit range so that non-zero status would always be returned as non-zero, but possibly different value. [1] http://pubs.opengroup.org/onlinepubs/009695399/functions/exit.html ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 18:45:33 2015 From: report at bugs.python.org (David D. Riddle) Date: Fri, 24 Apr 2015 16:45:33 +0000 Subject: [issue24054] Invalid syntax in inspect_fodder2.py (on Python 2.x) Message-ID: <1429893933.08.0.150501464744.issue24054@psf.upfronthosting.co.za> New submission from David D. Riddle: test_linecache.py reads from three files namely inspect_fodder.py, inspect_fodder2.py, and mapping_tests.py. It reads the py files directly as text files. This patch copies these files to linecache_fodder, linecache_fodder2, and linecache_mapping_fodder respectively, and updates test_linecache.py accordingly. The reason I do this is so that the these files are not compiled. This is desirable for me because I use linecache2 on python 2.7. Python 2.7 can not compile inspect_fodder2.py nor is it necessary as this file is only used as a text file never as an object file in the test_linecache.py tests. This issue came up for me when I attempted to make an RPM out of linecache2. rpmbuild compiles all py files in the rpm and fails when it tries to compile inspect_fodder2.py. If these files have the .py removed from the test files then they will not be compiled which fixes my issue. Nor do they need to be compiled to successfully run the test_linecache.py tests. ---------- components: Tests files: mywork.patch keywords: patch messages: 241955 nosy: ddriddle priority: normal severity: normal status: open title: Invalid syntax in inspect_fodder2.py (on Python 2.x) type: compile error Added file: http://bugs.python.org/file39198/mywork.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 18:46:04 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 24 Apr 2015 16:46:04 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1429893964.29.0.311331048319.issue24053@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- nosy: +skrah _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 18:51:45 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 24 Apr 2015 16:51:45 +0000 Subject: [issue24052] sys.exit(code) returns "success" to the OS for some nonzero values of code In-Reply-To: <1429889353.58.0.941477823236.issue24052@psf.upfronthosting.co.za> Message-ID: <1429894305.81.0.785078362235.issue24052@psf.upfronthosting.co.za> Changes by Alexander Belopolsky : ---------- title: sys.exit(code) returns "success" to the OS for some values of code -> sys.exit(code) returns "success" to the OS for some nonzero values of code _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 18:54:35 2015 From: report at bugs.python.org (Stefan Behnel) Date: Fri, 24 Apr 2015 16:54:35 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429894475.1.0.701034902549.issue24018@psf.upfronthosting.co.za> Stefan Behnel added the comment: Searching for Python code that seems to implement the Generator protocol doesn't return much: https://code.openhub.net/search?s=%22def%20throw%28%22%20%22def%20send%28%22%20%22def%20close%28%22&pp=0&fl=Python&mp=1&ml=1&me=1&md=1&ff=1&filterChecked=true But at least it pointed me to this: https://hg.python.org/cpython/file/5c0247a6f98a/Lib/multiprocessing/managers.py#l922 So, wrapping generators (apparently for remote calls in this case) seems to be another use case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 18:57:16 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 24 Apr 2015 16:57:16 +0000 Subject: [issue24052] sys.exit(code) returns "success" to the OS for some nonzero values of code In-Reply-To: <1429889353.58.0.941477823236.issue24052@psf.upfronthosting.co.za> Message-ID: <1429894636.62.0.626841073659.issue24052@psf.upfronthosting.co.za> Ethan Furman added the comment: If anything changes here it needs to be O/S dependent. MS Windows can work with DWORD return values, so truncating to 8-bits is wrong for that platform. ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 19:04:47 2015 From: report at bugs.python.org (William Orr) Date: Fri, 24 Apr 2015 17:04:47 +0000 Subject: [issue9246] os.getcwd() hardcodes max path len In-Reply-To: <1279023059.26.0.245683093399.issue9246@psf.upfronthosting.co.za> Message-ID: <1429895087.95.0.475658272874.issue9246@psf.upfronthosting.co.za> Changes by William Orr : Removed file: http://bugs.python.org/file39005/max_getcwd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 19:04:50 2015 From: report at bugs.python.org (William Orr) Date: Fri, 24 Apr 2015 17:04:50 +0000 Subject: [issue9246] os.getcwd() hardcodes max path len In-Reply-To: <1279023059.26.0.245683093399.issue9246@psf.upfronthosting.co.za> Message-ID: <1429895090.63.0.00195189919262.issue9246@psf.upfronthosting.co.za> Changes by William Orr : Removed file: http://bugs.python.org/file39154/max_getcwd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 19:09:33 2015 From: report at bugs.python.org (eryksun) Date: Fri, 24 Apr 2015 17:09:33 +0000 Subject: [issue24052] sys.exit(code) returns "success" to the OS for some nonzero values of code In-Reply-To: <1429889353.58.0.941477823236.issue24052@psf.upfronthosting.co.za> Message-ID: <1429895373.85.0.715963046398.issue24052@psf.upfronthosting.co.za> eryksun added the comment: > I believe a better behavior for sys.exit() would be to truncate > the code values to 8-bit range so that non-zero status would > always be returned as non-zero, but possibly different value. OK, so long as it's just for POSIX systems. Windows ExitProcess, ExitThread, TerminateProcess, and TerminateThread all use an unsigned int value for the exit code, and it's common to use a [Win32 error code][1] in the 16-bit range 0x0000 to 0xFFFF. [1]: https://msdn.microsoft.com/en-us/library/cc231199 ---------- nosy: +eryksun _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 19:10:35 2015 From: report at bugs.python.org (William Orr) Date: Fri, 24 Apr 2015 17:10:35 +0000 Subject: [issue9246] os.getcwd() hardcodes max path len In-Reply-To: <1279023059.26.0.245683093399.issue9246@psf.upfronthosting.co.za> Message-ID: <1429895435.77.0.552823269438.issue9246@psf.upfronthosting.co.za> William Orr added the comment: I've updated the patch with the comments from the review ---------- Added file: http://bugs.python.org/file39199/max_getcwd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 19:22:23 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 24 Apr 2015 17:22:23 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1429896143.9.0.627868814354.issue24053@psf.upfronthosting.co.za> Ethan Furman added the comment: Where are EXIT_FAILURE and EXIT_SUCCESS defined? And we should probably call them EX_FAILURE and EX_SUCESS to match what's already there. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 19:24:39 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 24 Apr 2015 17:24:39 +0000 Subject: [issue24052] sys.exit(code) returns "success" to the OS for some nonzero values of code In-Reply-To: <1429889353.58.0.941477823236.issue24052@psf.upfronthosting.co.za> Message-ID: <1429896279.29.0.943906256338.issue24052@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I agree that the truncation limits should be OS dependent and preserve the values to the extent possible on a given platform. I just want to avoid a situation when sys.exit(code) returns zero for a non-zero code. BTW, what does sys.exit(2**63) return on Windows? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 19:34:02 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 24 Apr 2015 17:34:02 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1429896842.1.0.591526691327.issue24053@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > Where are EXIT_FAILURE and EXIT_SUCCESS defined? In C stdlib: $ grep EXIT_ /usr/include/stdlib.h #define EXIT_FAILURE 1 #define EXIT_SUCCESS 0 > we should probably call them EX_FAILURE and EX_SUCESS to match what's already there. No. EX_ macros come from a non-standard sysexits.h header. Python stdlib traditionally does not change the spelling of the constants that come from C libraries or standards. Even in the absence of POSIX and C99 standards, I would prefer EXIT_ prefix over EX_ for clarity. "EX" does not clearly mean "exit", it may stand for "exception", "execution", "example" etc. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 19:35:58 2015 From: report at bugs.python.org (James Edwards) Date: Fri, 24 Apr 2015 17:35:58 +0000 Subject: [issue24035] When Caps Locked, + alpha-character still displayed as uppercase In-Reply-To: <1429765531.25.0.768760341138.issue24035@psf.upfronthosting.co.za> Message-ID: <1429896958.45.0.210738856151.issue24035@psf.upfronthosting.co.za> James Edwards added the comment: If you start the interactive interpreter with the -S switch, e.g. >python.exe -S Do you still see this behavior? ---------- nosy: +jedwards _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 19:45:42 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 24 Apr 2015 17:45:42 +0000 Subject: [issue24052] sys.exit(code) returns "success" to the OS for some nonzero values of code In-Reply-To: <1429889353.58.0.941477823236.issue24052@psf.upfronthosting.co.za> Message-ID: <1429897542.09.0.0842160706098.issue24052@psf.upfronthosting.co.za> Ethan Furman added the comment: Windows 7 C:\Python27>python Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. --> import sys --> sys.exit(2**63) 9223372036854775808 C:\Python27>python Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. --> import sys --> sys.exit(2**63+1) 9223372036854775809 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 19:53:43 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 24 Apr 2015 17:53:43 +0000 Subject: [issue24052] sys.exit(code) returns "success" to the OS for some nonzero values of code In-Reply-To: <1429889353.58.0.941477823236.issue24052@psf.upfronthosting.co.za> Message-ID: <1429898023.12.0.983074446729.issue24052@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: --> sys.exit(2**63) 9223372036854775808 Interesting. So it is probably not unheard of in the Windows world to use errors codes like 1000,1001,..1024,.. to avoid conflicts with "system" codes. Maybe on POSIX systems, sys.code(code) should print code and return say 255 for code outside of -255..255 range? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 20:03:47 2015 From: report at bugs.python.org (Ethan Furman) Date: Fri, 24 Apr 2015 18:03:47 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1429898627.08.0.721756766379.issue24053@psf.upfronthosting.co.za> Ethan Furman added the comment: Sounds good, I have no objections. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 20:18:53 2015 From: report at bugs.python.org (eryksun) Date: Fri, 24 Apr 2015 18:18:53 +0000 Subject: [issue24052] sys.exit(code) returns "success" to the OS for some nonzero values of code In-Reply-To: <1429889353.58.0.941477823236.issue24052@psf.upfronthosting.co.za> Message-ID: <1429899532.99.0.746137622545.issue24052@psf.upfronthosting.co.za> eryksun added the comment: > --> import sys > --> sys.exit(2**63) > 9223372036854775808 The above is only Python 2.x behavior. On Windows, sys.maxint is 2147483647 (even for 64-bit Windows), so 2**63 is a Python long. Thus handle_system_exit takes the PyFile_WriteObject branch, with the actual exit code set to 1. >>> import sys >>> sys.exit(2**63) 9223372036854775808 C:\>echo %errorlevel% 1 In Python 3, PyLong_AsLong overflows for any value bigger than LONG_MAX, which sets the result to -1, i.e. 32-bit 0xFFFFFFFF, with overflow set. handle_system_exit ignores the overflow exception, so any exit code larger than 0x7FFFFFFF (2**31-1) is returned as 0xFFFFFFFF (2**32-1). >>> cmd = '%s -c "import sys;sys.exit(%%d)"' % sys.executable >>> subprocess.call(cmd % (2**31-1)) 2147483647 >>> subprocess.call(cmd % (2**31)) 4294967295 >>> subprocess.call(cmd % (2**63)) 4294967295 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 20:20:48 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Apr 2015 18:20:48 +0000 Subject: [issue23810] Suboptimal stacklevel of deprecation warnings for formatter and imp modules In-Reply-To: <1427680454.72.0.13356883084.issue23810@psf.upfronthosting.co.za> Message-ID: <1429899648.03.0.939962310566.issue23810@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Unfortunately this will not help for re, because the trace passes through three files: Lib/sre_parse.py, Lib/sre_compile.py and Lib/re.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 20:34:01 2015 From: report at bugs.python.org (Behdad Esfahbod) Date: Fri, 24 Apr 2015 18:34:01 +0000 Subject: [issue24041] Implement Mac East Asian encodings properly In-Reply-To: <1429815130.87.0.76039167858.issue24041@psf.upfronthosting.co.za> Message-ID: <1429900441.62.0.171336813329.issue24041@psf.upfronthosting.co.za> Behdad Esfahbod added the comment: They are a rather minor change on top of the existing Asian encodings. So implementing them in Python might be easier. I have a half-done version of those. I can try finishing and post it back here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 20:35:15 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 24 Apr 2015 18:35:15 +0000 Subject: [issue24041] Implement Mac East Asian encodings properly In-Reply-To: <1429900441.62.0.171336813329.issue24041@psf.upfronthosting.co.za> Message-ID: <553A8CD9.4040202@egenix.com> Marc-Andre Lemburg added the comment: On 24.04.2015 20:34, Behdad Esfahbod wrote: > > They are a rather minor change on top of the existing Asian encodings. So implementing them in Python might be easier. I have a half-done version of those. I can try finishing and post it back here. If it's only a smaller patch, that would work fine, I guess. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 21:08:24 2015 From: report at bugs.python.org (Behdad Esfahbod) Date: Fri, 24 Apr 2015 19:08:24 +0000 Subject: [issue24043] Implement mac_romanian and mac_croatian encodings In-Reply-To: <1429815724.46.0.756339237301.issue24043@psf.upfronthosting.co.za> Message-ID: <1429902504.21.0.64153464375.issue24043@psf.upfronthosting.co.za> Behdad Esfahbod added the comment: Very valid question. Let me ask and get back to you. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 21:13:12 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Apr 2015 19:13:12 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1429902792.39.0.231257711887.issue24053@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Aren't EXIT_SUCCESS and EXIT_FAILURE needed only for support VMS? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 21:25:10 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Apr 2015 19:25:10 +0000 Subject: [issue24043] Implement mac_romanian and mac_croatian encodings In-Reply-To: <1429815724.46.0.756339237301.issue24043@psf.upfronthosting.co.za> Message-ID: <1429903510.31.0.0772921609861.issue24043@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Guido's time machine strikes back. >>> '???'.encode('mac_romanian') b'\xb9\xd0\xc6' >>> '???'.encode('mac_croatian') b'\xf9\xe0\xb4' ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 21:28:47 2015 From: report at bugs.python.org (Behdad Esfahbod) Date: Fri, 24 Apr 2015 19:28:47 +0000 Subject: [issue24043] Implement mac_romanian and mac_croatian encodings In-Reply-To: <1429815724.46.0.756339237301.issue24043@psf.upfronthosting.co.za> Message-ID: <1429903727.65.0.172012307191.issue24043@psf.upfronthosting.co.za> Behdad Esfahbod added the comment: Huh. So they are implemented, even though they are not in aliases.py. Sorry about the noise! Please add them to aliases.py. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 21:39:28 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Fri, 24 Apr 2015 19:39:28 +0000 Subject: [issue24043] Implement mac_romanian and mac_croatian encodings In-Reply-To: <1429815724.46.0.756339237301.issue24043@psf.upfronthosting.co.za> Message-ID: <1429904368.31.0.643042197777.issue24043@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: What aliases have these encodings? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 21:47:42 2015 From: report at bugs.python.org (Behdad Esfahbod) Date: Fri, 24 Apr 2015 19:47:42 +0000 Subject: [issue24043] Implement mac_romanian and mac_croatian encodings In-Reply-To: <1429815724.46.0.756339237301.issue24043@psf.upfronthosting.co.za> Message-ID: <1429904862.24.0.695015417194.issue24043@psf.upfronthosting.co.za> Behdad Esfahbod added the comment: Similar encodings have an alias that removes the underscore: https://github.com/python/cpython/blob/master/Lib/encodings/aliases.py#L435 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 21:56:22 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Fri, 24 Apr 2015 19:56:22 +0000 Subject: [issue24043] Implement mac_romanian and mac_croatian encodings In-Reply-To: <1429903510.31.0.0772921609861.issue24043@psf.upfronthosting.co.za> Message-ID: <553A9FDC.1010300@egenix.com> Marc-Andre Lemburg added the comment: On 24.04.2015 21:25, Serhiy Storchaka wrote: > > Serhiy Storchaka added the comment: > > Guido's time machine strikes back. > >>>> '???'.encode('mac_romanian') > b'\xb9\xd0\xc6' >>>> '???'.encode('mac_croatian') > b'\xf9\xe0\xb4' Ah, I should have looked in the encodings package first :-) r39779 | lemburg | 2005-10-21 15:58:32 +0200 (Fri, 21 Oct 2005) | 3 lines Add a few more Mac OS encodings. The mapping tables for these are available at ftp.unicode.org. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 21:59:10 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Fri, 24 Apr 2015 19:59:10 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1429905550.81.0.323986212381.issue24053@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: I would say, they are there to support *humans*. I am not aware of any human language where "success" is spelled 0. (1 is a failing mark in some schools - so there is a precedent for that. :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 22:08:35 2015 From: report at bugs.python.org (Brett Cannon) Date: Fri, 24 Apr 2015 20:08:35 +0000 Subject: [issue23723] Provide a way to disable bytecode staleness checks In-Reply-To: <1426875282.27.0.254210392532.issue23723@psf.upfronthosting.co.za> Message-ID: <1429906115.56.0.756851925412.issue23723@psf.upfronthosting.co.za> Brett Cannon added the comment: Skipping the source stat makes no difference in startup time even if you import django.http as part of the work. This would definitely be mostly for people who launch so many processes that they actually gain from collecting microseconds worth of benefit from each Python process. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 22:12:49 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Fri, 24 Apr 2015 20:12:49 +0000 Subject: [issue24039] Idle: some modal dialogs maximize, don't minimize In-Reply-To: <1429811337.7.0.183903934829.issue24039@psf.upfronthosting.co.za> Message-ID: <1429906369.38.0.739298152297.issue24039@psf.upfronthosting.co.za> Terry J. Reedy added the comment: I changed the title to generalize this issue. The modal Options => Configure IDLE box does not have minimize or maximize buttons and cannot be resized. (Ditto for About Idle.) This is typical of Windows dialogs, even though horizontal expansion would often be useful for path displays. The modal Options => Configure Extensions box also does not have the button but *can* be resized. (Ditto for some other help displays.) The Find, Find in Files, and Replace dialogs are also modal, though perhaps they should not be. They have the buttons and can be maximized (which is useless). They cannot be minimized because focus would have to shift to another window of the application, which would contradict being modal. They can be resized, and this is occasionally needed and should stay. One fix would be to make all these dialogs like Configure Extension -- no min, max buttons but resizable. For reference, (but not part of this issue) the File menu dialogs that I checked are non-modal. The Idle-specific Class and Path Browsers have min/max buttons and appear on the taskbar. (Ditto for Debugger and IDLE Help.) The tk-defined Open and Save dialogs do not have the buttons and do not appear on the taskbar. I believe the find group are the only modal dialogs with min and max buttons. ---------- stage: -> needs patch title: Minimize option doesn't work on Search Dialog box for idle -> Idle: some modal dialogs maximize, don't minimize versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 22:25:56 2015 From: report at bugs.python.org (Demian Brecht) Date: Fri, 24 Apr 2015 20:25:56 +0000 Subject: [issue24055] unittest package-level set up & tear down module Message-ID: <1429907156.24.0.517799178005.issue24055@psf.upfronthosting.co.za> New submission from Demian Brecht: There's a feature available via nose that might be nice to have in unittest: package-level setup and teardown functions. Using nose, I can define a setUpModule() method in a test package's __init__.py and it will execute it during the test run. This is helpful for test packages that test related features and may have expensive setup/teardown routines. By having the test runner pick up setup/teardown methods in __init__.py, I can now incur this expense once rather than once per module. I don't mind putting a patch together for this if others think this might be beneficial. ---------- components: Library (Lib) messages: 241981 nosy: demian.brecht, ezio.melotti, michael.foord, rbcollins priority: normal severity: normal stage: needs patch status: open title: unittest package-level set up & tear down module type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 22:48:00 2015 From: report at bugs.python.org (William Orr) Date: Fri, 24 Apr 2015 20:48:00 +0000 Subject: [issue23852] Wrong computation of max_fd on OpenBSD In-Reply-To: <1427987632.4.0.790792340938.issue23852@psf.upfronthosting.co.za> Message-ID: <1429908480.3.0.176812401163.issue23852@psf.upfronthosting.co.za> Changes by William Orr : Removed file: http://bugs.python.org/file39097/max_fd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 22:48:18 2015 From: report at bugs.python.org (William Orr) Date: Fri, 24 Apr 2015 20:48:18 +0000 Subject: [issue23852] Wrong computation of max_fd on OpenBSD In-Reply-To: <1427987632.4.0.790792340938.issue23852@psf.upfronthosting.co.za> Message-ID: <1429908498.14.0.903727405433.issue23852@psf.upfronthosting.co.za> William Orr added the comment: Updated the patch based on review ---------- Added file: http://bugs.python.org/file39200/max_fd.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Fri Apr 24 23:36:57 2015 From: report at bugs.python.org (Robert Collins) Date: Fri, 24 Apr 2015 21:36:57 +0000 Subject: [issue24054] Invalid syntax in inspect_fodder2.py (on Python 2.x) In-Reply-To: <1429893933.08.0.150501464744.issue24054@psf.upfronthosting.co.za> Message-ID: <1429911417.88.0.597190688716.issue24054@psf.upfronthosting.co.za> Robert Collins added the comment: Thanks, I shall look at this Monday. ---------- nosy: +rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 00:23:57 2015 From: report at bugs.python.org (Roundup Robot) Date: Fri, 24 Apr 2015 22:23:57 +0000 Subject: [issue9246] os.getcwd() hardcodes max path len In-Reply-To: <1279023059.26.0.245683093399.issue9246@psf.upfronthosting.co.za> Message-ID: <20150424222354.27906.23701@psf.io> Roundup Robot added the comment: New changeset abf1f3ae4fa8 by Victor Stinner in branch '3.4': Issue #9246: On POSIX, os.getcwd() now supports paths longer than 1025 bytes https://hg.python.org/cpython/rev/abf1f3ae4fa8 New changeset b871ace5c58f by Victor Stinner in branch 'default': (Merge 3.4) Issue #9246: On POSIX, os.getcwd() now supports paths longer than https://hg.python.org/cpython/rev/b871ace5c58f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 00:26:40 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 24 Apr 2015 22:26:40 +0000 Subject: [issue9246] os.getcwd() hardcodes max path len In-Reply-To: <1279023059.26.0.245683093399.issue9246@psf.upfronthosting.co.za> Message-ID: <1429914400.15.0.868795997397.issue9246@psf.upfronthosting.co.za> STINNER Victor added the comment: > I've updated the patch with the comments from the review Thanks William for your contribution, I commited your fix. I just made a minor change on "if (cwd && use_bytes) {": you forgot to remove test now useless test on cwd, and I dropped { and } to make to short more readable (Note: the PEP 7 requires to put "}" and "else {" on two lines). Ok, I just took 5 years to get Python 2 features in Python 3 :-) ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 00:31:57 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 24 Apr 2015 22:31:57 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1429914717.28.0.691284570173.issue23863@psf.upfronthosting.co.za> STINNER Victor added the comment: > diverging discussion: Go re-read the documentation on os.times(). We don't have the same definition of the unit "seconds" :-) >>> print(os.times()); time.sleep(1); print(os.times()) (0.04, 0.01, 0.0, 0.0, 4731691.68) (0.04, 0.01, 0.0, 0.0, 4731692.68) My watch doesn't stop when I'm sleeping. See https://docs.python.org/dev/library/time.html#time.process_time See also "CPU Time" in https://www.python.org/dev/peps/pep-0418/#glossary ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 00:37:21 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 24 Apr 2015 22:37:21 +0000 Subject: [issue23863] Fix EINTR Socket Module issues in 2.7 In-Reply-To: <1428115885.34.0.897753768137.issue23863@psf.upfronthosting.co.za> Message-ID: <1429915041.21.0.427402181449.issue23863@psf.upfronthosting.co.za> STINNER Victor added the comment: > We don't have the same definition of the unit "seconds" :-) Or, please forget my comment, I watched the first 4 items of os.times(). I didn't notice the difference of the 5th item, os.times()[4]. The bad news is that only the first two items of os.times() are filled on Windows :-( I don't think that Python 2.7 provides a monotonic clock on Windows. static PyObject * os_times_impl(PyModuleDef *module) { #ifdef MS_WINDOWS FILETIME create, exit, kernel, user; HANDLE hProc; hProc = GetCurrentProcess(); GetProcessTimes(hProc, &create, &exit, &kernel, &user); /* The fields of a FILETIME structure are the hi and lo part of a 64-bit value expressed in 100 nanosecond units. 1e7 is one second in such units; 1e-7 the inverse. 429.4967296 is 2**32 / 1e7 or 2**32 * 1e-7. */ return build_times_result( (double)(user.dwHighDateTime*429.4967296 + user.dwLowDateTime*1e-7), (double)(kernel.dwHighDateTime*429.4967296 + kernel.dwLowDateTime*1e-7), (double)0, (double)0, (double)0); ... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 00:42:14 2015 From: report at bugs.python.org (STINNER Victor) Date: Fri, 24 Apr 2015 22:42:14 +0000 Subject: [issue23840] tokenize.open() leaks an open binary file on TextIOWrapper error In-Reply-To: <1427889153.26.0.649877902408.issue23840@psf.upfronthosting.co.za> Message-ID: <1429915334.28.0.553336788587.issue23840@psf.upfronthosting.co.za> STINNER Victor added the comment: tokenizeV2.patch and tokenize.patch have issues, I reviewed them. Can someone please write a new patch taking my comments in account? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 00:55:37 2015 From: report at bugs.python.org (Tal Einat) Date: Fri, 24 Apr 2015 22:55:37 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1429916137.07.0.565071301295.issue20182@psf.upfronthosting.co.za> Tal Einat added the comment: Here's a patch just for Modules/selectmodule.c (and related files), based on Georg's patch, updated to apply against current default, including fixes thanks to Serhiy's review. It took a while since I had to get a Linux VM up to run the epoll tests. And it was good that I did, since Georg's patch had several errors in that area. It is important to note that epoll.poll now raises a different exception when called with invalid arguments after it has been closed. It used to raise ValueError since it first checked whether it was closed before checking the parameters. With this patch, the parameters are checked first so a TypeError is raised. This behavior wasn't documented and wasn't tested, so it seems relatively safe to change. At Serhiy's suggestion, I added a test for the new behavior. Perhaps this should be mentioned in the release notes and/or "what's new"? ---------- Added file: http://bugs.python.org/file39201/issue20182.selectmodule.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 01:41:54 2015 From: report at bugs.python.org (Matt Chung) Date: Fri, 24 Apr 2015 23:41:54 +0000 Subject: [issue23840] tokenize.open() leaks an open binary file on TextIOWrapper error In-Reply-To: <1427889153.26.0.649877902408.issue23840@psf.upfronthosting.co.za> Message-ID: <1429918914.93.0.612652196024.issue23840@psf.upfronthosting.co.za> Matt Chung added the comment: Hey Haypo, I'm working on submitting the new patch now. Still getting used to the workflow and tools here. Thanks for being patient. You should see the new file in the next 30 minutes. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 03:41:40 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Sat, 25 Apr 2015 01:41:40 +0000 Subject: [issue24050] Segmentation fault (core dumped) In-Reply-To: <1429882485.21.0.520202259055.issue24050@psf.upfronthosting.co.za> Message-ID: <1429926100.81.0.789426883713.issue24050@psf.upfronthosting.co.za> Terry J. Reedy added the comment: The link appears to be about a bug in the C code of mopidy-spotify, which was properly reported to the github mopidy site. This tracker is only for bugs in the Python-CPython docs and CPython implmentation, as maintained in the cpython repository at hg.python.org. What bug of the latter sort are you claiming? ---------- nosy: +terry.reedy status: pending -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 05:43:31 2015 From: report at bugs.python.org (James Edwards) Date: Sat, 25 Apr 2015 03:43:31 +0000 Subject: [issue24035] When Caps Locked, + alpha-character still displayed as uppercase In-Reply-To: <1429765531.25.0.768760341138.issue24035@psf.upfronthosting.co.za> Message-ID: <1429933411.92.0.595172250174.issue24035@psf.upfronthosting.co.za> James Edwards added the comment: It looks like this is a bug in pyreadlines as suggested by eryksun, but for a different reason. Even though the Caps Lock + Shift combination is recognized correctly (as lower case), the logic in the pyreadlines module forces it to upper case. See lines 44-45 and 72-75 in [1]. You should be able to verify this by launching with the -S option, disabling the auto import of the site module. (You'll need to import sys; sys.exit(), or Ctrl+Break to exit the interpreter -- exit() won't be defined.) Given that pyreadlines looks to be somewhat of a mess and since you don't actually need pyreadlines to run ipython[2], you might consider uninstalling it (Alternatively, removing the "or shift" part of the referenced conditions will fix your specific issue). If you're only looking for windows terminal coloring, colorama[3] is being used by the pip maintainers with apparent success. In any case, it doesn't look to be an appropriate bug for this tracker -- maybe the pyreadlines github? [1] https://github.com/pyreadline/pyreadline/blob/master/pyreadline/keysyms/common.py [2] http://mail.scipy.org/pipermail/ipython-dev/2013-November/012623.html [3] https://pypi.python.org/pypi/colorama ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 08:03:07 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sat, 25 Apr 2015 06:03:07 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1429941787.53.0.891614546683.issue24018@psf.upfronthosting.co.za> Stefan Behnel added the comment: FYI, here's the patch implementation for Cython: https://github.com/cython/cython/blob/cf63ff71c06b16c3a30facdc7859743f4cd495f6/Cython/Utility/Generator.c#L849 The only difference is that it takes care of changing "__next__" to "next" in Py2.x. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 08:13:53 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Apr 2015 06:13:53 +0000 Subject: [issue24056] Expose closure & generator status in function repr() Message-ID: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za> New submission from Nick Coghlan: >From https://mail.python.org/pipermail/python-ideas/2015-April/033177.html, there are some additional details about functions that could be usefully exposed in the function repr, specifically whether or not it's a closure, and whether or not it's a generator function. Proposed display: The Python level checks for the two flags: closure: f.__closure__ is not None generator: c.__code__.co_flags & inspect.CO_GENERATOR Actual implementation would be in the C code at https://hg.python.org/cpython/file/default/Objects/funcobject.c#l569 ---------- messages: 241994 nosy: ncoghlan priority: normal severity: normal status: open title: Expose closure & generator status in function repr() versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 08:16:26 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Apr 2015 06:16:26 +0000 Subject: [issue24056] Expose closure & generator status in function repr() In-Reply-To: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za> Message-ID: <1429942586.76.0.492697327838.issue24056@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- stage: -> needs patch type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 08:28:34 2015 From: report at bugs.python.org (James) Date: Sat, 25 Apr 2015 06:28:34 +0000 Subject: [issue24035] When Caps Locked, + alpha-character still displayed as uppercase In-Reply-To: <1429765531.25.0.768760341138.issue24035@psf.upfronthosting.co.za> Message-ID: <1429943314.71.0.740283973218.issue24035@psf.upfronthosting.co.za> James added the comment: When I start the interpreter with the -S switch, the problem goes away. Thanks for looking into it, and I apologize for the false alarm! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 08:31:11 2015 From: report at bugs.python.org (James) Date: Sat, 25 Apr 2015 06:31:11 +0000 Subject: [issue24035] When Caps Locked, + alpha-character still displayed as uppercase In-Reply-To: <1429765531.25.0.768760341138.issue24035@psf.upfronthosting.co.za> Message-ID: <1429943471.38.0.911257172607.issue24035@psf.upfronthosting.co.za> Changes by James : ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 08:36:58 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Apr 2015 06:36:58 +0000 Subject: [issue9951] introduce bytes.hex method (also for bytearray and memoryview) In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1429943818.27.0.883317619435.issue9951@psf.upfronthosting.co.za> Changes by Nick Coghlan : ---------- assignee: -> ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 08:43:00 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sat, 25 Apr 2015 06:43:00 +0000 Subject: [issue24056] Expose closure & generator status in function repr() In-Reply-To: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za> Message-ID: <1429944180.89.0.820349356861.issue24056@psf.upfronthosting.co.za> Changes by Yury Selivanov : ---------- nosy: +yselivanov _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 08:48:19 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Apr 2015 06:48:19 +0000 Subject: [issue19543] Add -3 warnings for codec convenience method changes In-Reply-To: <1384075247.27.0.0100141647279.issue19543@psf.upfronthosting.co.za> Message-ID: <1429944499.86.0.665825016016.issue19543@psf.upfronthosting.co.za> Nick Coghlan added the comment: For the warnings, it's actually bytes.decode() (et al) that are expected to return str, and str.encode() that's expected to return bytes. The codecs themselves remain free to do what they want (hence the recommendation to use codecs.encode() and codecs.decode() to invoke arbitrary codecs without the type constraints of the builtins). Aside from that, those 2 warnings and the unicode.decode() one look good. However, the "bytes.encode()" warning is the one we determined couldn't be treated as a warning as "text".encode("ascii") is valid in both Python 2 & 3, it just does a str->str conversion in 2.x, and a str -> bytes conversion in 3.x. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 08:49:50 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Apr 2015 06:49:50 +0000 Subject: [issue16405] Explain how to set up the whitespace commit hook locally In-Reply-To: <1352041451.32.0.465920697634.issue16405@psf.upfronthosting.co.za> Message-ID: <1429944590.59.0.0378200456324.issue16405@psf.upfronthosting.co.za> Nick Coghlan added the comment: Oh, so *that's* why my local hook isn't aborting commits when the whitespace check fails :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 08:55:58 2015 From: report at bugs.python.org (Novice Live) Date: Sat, 25 Apr 2015 06:55:58 +0000 Subject: [issue24057] trivial typo in datetime.rst: needing a preceding dot Message-ID: <1429944958.51.0.607005729778.issue24057@psf.upfronthosting.co.za> New submission from Novice Live: a non-trivial dot is needed for the hyperlink to make sense, or the link will jump to the start of the documentation, which doesn't make sense. the same typo as in http://bugs.python.org/issue23561. ---------- assignee: docs at python components: Documentation files: datetime_typo.patch keywords: patch messages: 241998 nosy: docs at python, n0vicelive priority: normal severity: normal status: open title: trivial typo in datetime.rst: needing a preceding dot versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39202/datetime_typo.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 08:58:04 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Apr 2015 06:58:04 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1429945084.01.0.144565199697.issue22906@psf.upfronthosting.co.za> Nick Coghlan added the comment: Unfortunately we didn't find the time to review the currently flagged release blockers at the sprints :( Chris, for the mechanics of testing the future flag, it's potentially worth looking at the 2.7 branch, as that should have tests for the print_function and unicode_literals flags. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 09:15:07 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Apr 2015 07:15:07 +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: <1429946107.22.0.609504536589.issue23993@psf.upfronthosting.co.za> Nick Coghlan added the comment: If a Linux distro is using systemd (which is essentially all recent versions of popular distros, including RHEL/CentOS, although it won't land in Ubuntu LTS until 16.04), then cron jobs and service daemons will get their locale set properly based on the contents of /etc/locale.conf. Thus "use an init system that reliably sets the locale correctly for cron jobs and service daemons" is the correct fix for this problem. Unfortunately, there are still an awful lot of Linux systems out there using other init systems that don't reliably set the locale, and for those "Python 3 shouldn't be worse than Python 2" is a desirable behavioural goal here. Thus, I think it makes sense for Python to special case the C locale by assuming it's always the wrong setting, and thus surrogateescape is going to be needed on all system interfaces. While it won't be a perfect fix, at least we'll be able to roundtrip data within the system appropriately, even if it still gets corrupted in the face of encoding conversions. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 09:31:36 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Apr 2015 07:31:36 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <1429947096.05.0.18739491245.issue23911@psf.upfronthosting.co.za> Nick Coghlan added the comment: Nice, this ties directly into one of the thornier problems in the PEP 432 bootstrapping work, which needs to set up the core import system in Py_BeginInitialization, but delay setting up the rest of it until Py_EndInitialization. Your patch achieves this by moving everything that belongs in the latter part of the operation to the "import _frozen_path_importer" step. As far as naming goes, I'd suggest referring to the two import subsystems as "internal imports" and "external imports". The key aspect of builtin and frozen modules is that they're an inherent part of the interpreter itself - if you have an interpreter, you have all of its buitin and frozen modules natively available. By contrast, setting up the external import machinery requires that the interpreter first be configured to appropriately communicate with the host system. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 09:41:31 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Apr 2015 07:41:31 +0000 Subject: [issue23955] Add python.ini file for embedded/applocal installs In-Reply-To: <1429038990.96.0.956334607163.issue23955@psf.upfronthosting.co.za> Message-ID: <1429947691.76.0.91543749555.issue23955@psf.upfronthosting.co.za> Nick Coghlan added the comment: I'd actually like a python.ini file defined as a Python 3.5 feature in order to provide a better backporting story for the PEP 476 certificate changes in downstream long term support releases of Python 2.7. So +1 in principle, but I'd like to see this written up as a PEP (the SSL configuration setting doesn't need to be in the PEP, but the optional existence of the config file and reading it at startup does). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 09:44:42 2015 From: report at bugs.python.org (Tal Einat) Date: Sat, 25 Apr 2015 07:44:42 +0000 Subject: [issue20182] Derby #13: Convert 50 sites to Argument Clinic across 5 files In-Reply-To: <1389140257.44.0.42523119139.issue20182@psf.upfronthosting.co.za> Message-ID: <1429947882.06.0.241245684629.issue20182@psf.upfronthosting.co.za> Tal Einat added the comment: Here's a slightly modified version of the most recent patch for Modules/selectmodule.c. The only difference relative to the previous version is that I've set the epoll method function names back to what they used to be. My reasoning is to stay consistent with the other epoll method function names in the file and to keep the code familiar for the maintainers. ---------- Added file: http://bugs.python.org/file39203/issue20182.selectmodule.v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 09:44:50 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Apr 2015 07:44:50 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1429947890.9.0.444609337969.issue23857@psf.upfronthosting.co.za> Nick Coghlan added the comment: In issue 23955, Steve Dower has suggested introducing config file support for easier control of path configuration when a dedicated Python interpreter runtime is deployed as part of a larger application. If that proposal goes ahead (I think it needs a PEP for us to proceed with it), then we could use that scheme as the basis for solving the PEP 476 backporting problem (without necessarily having to officially standardise the latter upstream). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 09:50:47 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Apr 2015 07:50:47 +0000 Subject: [issue15582] Enhance inspect.getdoc to follow inheritance chains In-Reply-To: <1344394334.01.0.280520797106.issue15582@psf.upfronthosting.co.za> Message-ID: <1429948246.99.0.110236234657.issue15582@psf.upfronthosting.co.za> Nick Coghlan added the comment: Yes, this was a deliberate change to "flip the default" as to which subclasses get bad docstring behaviour. In the status quo, if you provide a subclass method which does basically the same thing as the parent class, you lose the docstring unless you duplicate it, meaning you have to choose between bad docstrings and a maintainability problem due to content duplication. With this change, you only need a custom docstring in the subclass if you've changed the method behaviour enough that the parent class docstring no longer makes any sense. If you just want to suppress the docstring entirely, then you'll need to specify an empty docstring. This is potentially worth a note in the "Porting to Python 3.5" section of the What's New document, but it's an intended consequence of the change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 10:02:33 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sat, 25 Apr 2015 08:02:33 +0000 Subject: [issue23967] Make inspect.signature expression evaluation more powerful In-Reply-To: <1429123957.6.0.780975142449.issue23967@psf.upfronthosting.co.za> Message-ID: <1429948953.75.0.431828168547.issue23967@psf.upfronthosting.co.za> Nick Coghlan added the comment: Right, Larry and I had a fairly long discussion about this idea at the sprints, and I was satisfied that all the cases where he's proposing to use this are safe: in order to exploit them you need to be able to set __text_signature__ on arbitrary objects, and if an attacker can do that, you've already lost control of the process. However, a natural future extension is to expose this as a public alternative constructor for Signature objects, and for that, the fact that it ultimately calls eval() under the hood presents more of a security risk. The "trusted=False" default on _signature_fromstr allows the function to be used safely on untrusted data, while allowing additional flexibility when you *do* trust the data you're evaluating. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 10:22:38 2015 From: report at bugs.python.org (Tal Einat) Date: Sat, 25 Apr 2015 08:22:38 +0000 Subject: [issue24009] Get rid of rare format units in PyArg_Parse* In-Reply-To: <1429470884.11.0.538472438707.issue24009@psf.upfronthosting.co.za> Message-ID: <1429950157.99.0.622737407619.issue24009@psf.upfronthosting.co.za> Tal Einat added the comment: +1. I was recently trying to use the C API for a 3rd party library, and all of these subtly different string parameter formats made things surprisingly confusing. These are part of the Python C API, so removing them could break 3rd party code. Simply searching through the stdlib is not enough to show that these are not in use. So removal would require a deprecation period. ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 10:31:39 2015 From: report at bugs.python.org (Tal Einat) Date: Sat, 25 Apr 2015 08:31:39 +0000 Subject: [issue24037] Argument Clinic: add the boolint converter In-Reply-To: <1429785188.86.0.806042190219.issue24037@psf.upfronthosting.co.za> Message-ID: <1429950699.57.0.782070829601.issue24037@psf.upfronthosting.co.za> Tal Einat added the comment: If this was for internal use only, intended to ease the transition to Argument Clinic, then extensibility isn't an issue. An upside to this is that it would make it easy in the future to find all of the places in the stdlib using integers instead of bools. A downside is that "boolint" isn't a very obvious name IMO. ---------- nosy: +taleinat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 11:17:52 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Sat, 25 Apr 2015 09:17:52 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1429953472.54.0.810435748521.issue23857@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: I think this discussion is moving in the wrong direction or least one which won't help people not using some Linux distribution. The use case here is very similar to the hash seed randomization which was also successfully handled using an environment variable setting, so why not do the same here ? I don't really understand the objections mentioned against env vars. They can be set per process, per user, even globally and they are under control by whoever runs an application. Note that this is about breaking backwards compatibility badly. Certificate verification is a good thing, but if it results in people no longer being able to easily upgrade to a new patch level release, something is wrong. If such a feature causes applications to fail working, admins won't go in a fix the application; instead they'll simply not upgrade to 2.7.9+, cutting people off of all the other fixes in 2.7.9+. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 11:30:54 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Apr 2015 09:30:54 +0000 Subject: [issue24037] Argument Clinic: add the boolint converter In-Reply-To: <1429785188.86.0.806042190219.issue24037@psf.upfronthosting.co.za> Message-ID: <1429954254.66.0.42129971399.issue24037@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I proposed boolint or intbool. Are there better variants? An alternative is add accept={int} parameter to the bool converter. But this will complicate the implementation and the use without the need. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 12:54:48 2015 From: report at bugs.python.org (Arnon Yaari) Date: Sat, 25 Apr 2015 10:54:48 +0000 Subject: [issue9951] introduce bytes.hex method (also for bytearray and memoryview) In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1429959288.1.0.533605289257.issue9951@psf.upfronthosting.co.za> Arnon Yaari added the comment: minor updates to stdtypes.rst. I also want to add a line to whatsnew/3.5 but don't know how to put it in words - maybe it's better if someone with better english will add it. ---------- Added file: http://bugs.python.org/file39204/bytes.hex-1.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 13:20:30 2015 From: report at bugs.python.org (irdb) Date: Sat, 25 Apr 2015 11:20:30 +0000 Subject: [issue4823] idle height and place In-Reply-To: <1231005741.18.0.260844388854.issue4823@psf.upfronthosting.co.za> Message-ID: <1429960830.45.0.753832586147.issue4823@psf.upfronthosting.co.za> Changes by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 13:20:30 2015 From: report at bugs.python.org (irdb) Date: Sat, 25 Apr 2015 11:20:30 +0000 Subject: [issue3286] IDLE opens window too low on Windows In-Reply-To: <1215200725.85.0.436129810041.issue3286@psf.upfronthosting.co.za> Message-ID: <1429960830.22.0.762101916468.issue3286@psf.upfronthosting.co.za> Changes by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 14:08:14 2015 From: report at bugs.python.org (Berker Peksag) Date: Sat, 25 Apr 2015 12:08:14 +0000 Subject: [issue13567] HTTPError interface changes / breaks depending on what was passed to constructor In-Reply-To: <1323446082.73.0.0465562779799.issue13567@psf.upfronthosting.co.za> Message-ID: <1429963694.42.0.217654855461.issue13567@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +berker.peksag stage: -> patch review versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 14:21:19 2015 From: report at bugs.python.org (eryksun) Date: Sat, 25 Apr 2015 12:21:19 +0000 Subject: [issue24035] When Caps Locked, + alpha-character still displayed as uppercase In-Reply-To: <1429765531.25.0.768760341138.issue24035@psf.upfronthosting.co.za> Message-ID: <1429964479.76.0.764846274643.issue24035@psf.upfronthosting.co.za> eryksun added the comment: > It looks like this is a bug in pyreadlines as suggested by > eryksun, but for a different reason. As I said before, it reads keyboard input events at a lower level via ReadConsoleInputW, instead of calling ReadConsoleW to read the input buffer as a text stream. To elaborate, this means it has to be aware of the keyboard state, per the [KEY_EVENT_RECORD][1] dwControlKeyState. This gets passed to [make_KeyPress][2] as `state`, which in turn ignores the CAPSLOCK_ON flag. [1]: https://msdn.microsoft.com/en-us/library/ms684166 [2]: https://github.com/pyreadline/pyreadline/blob/master/pyreadline/keysyms/keysyms.py#L116 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 16:05:45 2015 From: report at bugs.python.org (Ethan Furman) Date: Sat, 25 Apr 2015 14:05:45 +0000 Subject: [issue24056] Expose closure & generator status in function repr() In-Reply-To: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za> Message-ID: <1429970745.24.0.624200922834.issue24056@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 16:21:10 2015 From: report at bugs.python.org (Masayuki Yamamoto) Date: Sat, 25 Apr 2015 14:21:10 +0000 Subject: [issue24058] Compiler warning for readline extension Message-ID: <1429971670.78.0.634220240768.issue24058@psf.upfronthosting.co.za> New submission from Masayuki Yamamoto: Compiler warns case of define HAVE_DECLSPEC_DLL. In Modules/readline.c:1065, _PyOS_ReadlineTState variable declaration is different to Include/pythonrun.h:275. ---------- components: Build, Extension Modules hgrepos: 307 messages: 242013 nosy: masamoto priority: normal severity: normal status: open title: Compiler warning for readline extension type: compile error versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 16:23:06 2015 From: report at bugs.python.org (Masayuki Yamamoto) Date: Sat, 25 Apr 2015 14:23:06 +0000 Subject: [issue24058] Compiler warning for readline extension In-Reply-To: <1429971670.78.0.634220240768.issue24058@psf.upfronthosting.co.za> Message-ID: <1429971786.14.0.927271500891.issue24058@psf.upfronthosting.co.za> Masayuki Yamamoto added the comment: Here is a patch modifying variable declaration to same as Include/pytonrun.h. ---------- keywords: +patch Added file: http://bugs.python.org/file39205/3.4-issue24058-readline-_PyOS_ReadlineTState.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 16:38:49 2015 From: report at bugs.python.org (Brett Cannon) Date: Sat, 25 Apr 2015 14:38:49 +0000 Subject: [issue23810] Suboptimal stacklevel of deprecation warnings for formatter and imp modules In-Reply-To: <1427680454.72.0.13356883084.issue23810@psf.upfronthosting.co.za> Message-ID: <1429972729.81.0.275940133905.issue23810@psf.upfronthosting.co.za> Brett Cannon added the comment: OK, I'll look at making it more general for multiple names to skip. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 17:09:09 2015 From: report at bugs.python.org (xiaobing jiang) Date: Sat, 25 Apr 2015 15:09:09 +0000 Subject: [issue15329] clarify which deque methods are thread-safe In-Reply-To: <1342044644.52.0.376014623438.issue15329@psf.upfronthosting.co.za> Message-ID: <1429974549.12.0.685927922834.issue15329@psf.upfronthosting.co.za> Changes by xiaobing jiang : ---------- nosy: +s7v7nislands at gmail.com _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 17:09:40 2015 From: report at bugs.python.org (xiaobing jiang) Date: Sat, 25 Apr 2015 15:09:40 +0000 Subject: [issue15339] document the threading "facts of life" in Python In-Reply-To: <1342130435.62.0.0784000861923.issue15339@psf.upfronthosting.co.za> Message-ID: <1429974580.9.0.478393711162.issue15339@psf.upfronthosting.co.za> Changes by xiaobing jiang : ---------- nosy: +s7v7nislands at gmail.com _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 17:10:22 2015 From: report at bugs.python.org (xiaobing jiang) Date: Sat, 25 Apr 2015 15:10:22 +0000 Subject: [issue15330] allow deque to act as a thread-safe circular buffer In-Reply-To: <1342045238.04.0.281063005128.issue15330@psf.upfronthosting.co.za> Message-ID: <1429974622.84.0.796196204283.issue15330@psf.upfronthosting.co.za> Changes by xiaobing jiang : ---------- nosy: +s7v7nislands at gmail.com _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 17:13:08 2015 From: report at bugs.python.org (Per Brodtkorb) Date: Sat, 25 Apr 2015 15:13:08 +0000 Subject: [issue22544] Inconsistent cmath.log behaviour In-Reply-To: <1412320697.54.0.866089400402.issue22544@psf.upfronthosting.co.za> Message-ID: <1429974788.95.0.154117362318.issue22544@psf.upfronthosting.co.za> Per Brodtkorb added the comment: This is not only a problem for division. It also applies to multiplication as exemplified here: >>> complex(0,inf)+1 # expect 1 + infj Out[16]: (1+infj) >>> (complex(0,inf)+1)*1 # expect 1 + infj Out[17]: (nan+infj) >>> complex(inf, 0) + 1j # expect inf + 1j Out[18]: (inf+1j) >>> (complex(inf, 0)+1j)*1 # expect inf + 1j Out[19]: (inf, nanj) ---------- nosy: +pbrod versions: +Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 17:29:31 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 25 Apr 2015 15:29:31 +0000 Subject: [issue15339] document the threading "facts of life" in Python In-Reply-To: <1342130435.62.0.0784000861923.issue15339@psf.upfronthosting.co.za> Message-ID: <1429975771.3.0.200146352374.issue15339@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- assignee: rhettinger -> _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 17:35:48 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 25 Apr 2015 15:35:48 +0000 Subject: [issue24059] Minor speed and readability improvement to the random module Message-ID: <1429976148.71.0.723418409386.issue24059@psf.upfronthosting.co.za> New submission from Raymond Hettinger: Replace all the _sqrt(x) calls with x ** 0.5, improving the visual appearance and providing a modest speed improvement. $ python3 -m timeit -s 'from math import sqrt' 'sqrt(3.14)' 10000000 loops, best of 3: 0.032 usec per loop $ python3 -m timeit -s 'from math import sqrt' '3.14 ** 0.5' 100000000 loops, best of 3: 0.0101 usec per loop ---------- components: Library (Lib) files: random_sqrt.diff keywords: patch messages: 242017 nosy: rhettinger priority: low severity: normal stage: patch review status: open title: Minor speed and readability improvement to the random module type: performance versions: Python 3.5 Added file: http://bugs.python.org/file39206/random_sqrt.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 17:41:51 2015 From: report at bugs.python.org (Petr Viktorin) Date: Sat, 25 Apr 2015 15:41:51 +0000 Subject: [issue24056] Expose closure & generator status in function repr() In-Reply-To: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za> Message-ID: <1429976511.87.0.785405662195.issue24056@psf.upfronthosting.co.za> Changes by Petr Viktorin : ---------- nosy: +encukou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 17:47:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Apr 2015 15:47:19 +0000 Subject: [issue24059] Minor speed and readability improvement to the random module In-Reply-To: <1429976148.71.0.723418409386.issue24059@psf.upfronthosting.co.za> Message-ID: <1429976839.19.0.40325107895.issue24059@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: sqrt(x) and x ** 0.5 can be different. >>> 0.0171889575379941**0.5 0.13110666473522276 >>> sqrt(0.0171889575379941) 0.13110666473522273 ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 17:48:02 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Apr 2015 15:48:02 +0000 Subject: [issue24059] Minor speed and readability improvement to the random module In-Reply-To: <1429976148.71.0.723418409386.issue24059@psf.upfronthosting.co.za> Message-ID: <1429976882.35.0.906031298591.issue24059@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 20:16:33 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Apr 2015 18:16:33 +0000 Subject: [issue24057] trivial typo in datetime.rst: needing a preceding dot In-Reply-To: <1429944958.51.0.607005729778.issue24057@psf.upfronthosting.co.za> Message-ID: <20150425181630.27930.89608@psf.io> Roundup Robot added the comment: New changeset 875787fee2cc by Benjamin Peterson in branch '3.4': fix relative link (closes #24057) https://hg.python.org/cpython/rev/875787fee2cc New changeset 4e48a55cffb8 by Benjamin Peterson in branch '2.7': fix relative link (closes #24057) https://hg.python.org/cpython/rev/4e48a55cffb8 New changeset 0351b0cb31d6 by Benjamin Peterson in branch 'default': merge 3.4 (#24057) https://hg.python.org/cpython/rev/0351b0cb31d6 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 20:25:36 2015 From: report at bugs.python.org (Paul Moore) Date: Sat, 25 Apr 2015 18:25:36 +0000 Subject: [issue23955] Add python.ini file for embedded/applocal installs In-Reply-To: <1429038990.96.0.956334607163.issue23955@psf.upfronthosting.co.za> Message-ID: <1429986336.26.0.215316189322.issue23955@psf.upfronthosting.co.za> Paul Moore added the comment: As described. this seems to be a Windows-only feature (it's replacing a registry lookup with a config file alongside the Python DLL). So I'm not sure I understand Nick's comment - Nick, are you suggesting this should be a cross-platform feature? If so, what's the equivalent of "alongside the Python DLL", and what would the ini file be used for on Unix, where there's no registry lookup to override? ---------- nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 20:25:53 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sat, 25 Apr 2015 18:25:53 +0000 Subject: [issue24058] Compiler warning for readline extension In-Reply-To: <1429971670.78.0.634220240768.issue24058@psf.upfronthosting.co.za> Message-ID: <1429986353.93.0.057974652771.issue24058@psf.upfronthosting.co.za> Benjamin Peterson added the comment: What kind of compiler/system does this happen on? ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 20:43:57 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 25 Apr 2015 18:43:57 +0000 Subject: [issue11477] Incorrect operand precedence when implementing sequences in C In-Reply-To: <1299965091.63.0.267715976543.issue11477@psf.upfronthosting.co.za> Message-ID: <1429987437.28.0.976614288947.issue11477@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- nosy: +gregory.p.smith versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 22:07:13 2015 From: report at bugs.python.org (Masayuki Yamamoto) Date: Sat, 25 Apr 2015 20:07:13 +0000 Subject: [issue24058] Compiler warning for readline extension In-Reply-To: <1429971670.78.0.634220240768.issue24058@psf.upfronthosting.co.za> Message-ID: <1429992433.63.0.414478040019.issue24058@psf.upfronthosting.co.za> Masayuki Yamamoto added the comment: um, Compiler warned, but test passed. It seems a only warning. build log: $ ./configure --prefix=/opt/py34 $ make ... building 'readline' extension gcc -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I./Include -I/opt/py34/include -I. -IInclude -I/usr/local/include -I/home/masayuki/src/CPython-3.4/Include -I/home/masayuki/src/CPython-3.4 -c /cygdrive/d/cyghome/masayuki/src/CPython-3.4/Modules/readline.c -o build/temp.cygwin-1.7.35-i686-3.4/cygdrive/d/cyghome/masayuki/src/CPython-3.4/Modules/readline.o /cygdrive/d/cyghome/masayuki/src/CPython-3.4/Modules/readline.c:1065:23: warning: '_PyOS_ReadlineTState' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] extern PyThreadState* _PyOS_ReadlineTState; ^ ... test log: $ /opt/py34/bin/python3.4m.exe -E -Wd -mtest -v test_readline == CPython 3.4.3+ (3.4:ce2b9f160391+, Apr 25 2015, 20:45:32) [GCC 4.9.2] == CYGWIN_NT-6.0-1.7.35-0.287-5-3-i686-32bit-WindowsPE little-endian == hash algorithm: siphash24 32bit == /tmp/test_python_2660 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) [1/1] test_readline testHistoryUpdates (test.test_readline.TestHistoryManipulation) ... ok test_init (test.test_readline.TestReadline) ... ok ---------------------------------------------------------------------- Ran 2 tests in 0.199s OK 1 test OK. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 23:14:17 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 25 Apr 2015 21:14:17 +0000 Subject: [issue24059] Minor speed and readability improvement to the random module In-Reply-To: <1429976148.71.0.723418409386.issue24059@psf.upfronthosting.co.za> Message-ID: <1429996457.64.0.178220644842.issue24059@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Hmm, I don't get that same result (Mac OS/X 10.10, Python 3.4.2): >>> from math import * >>> 0.0171889575379941**0.5 0.13110666473522273 >>> sqrt(0.0171889575379941) 0.13110666473522273 It's odd because your two result as same number, just displayed differently. I thought that wasn't supposed to happen anymore. >>> (0.13110666473522276).hex() '0x1.0c81a6aa9a74ep-3' >>> (0.13110666473522273).hex() '0x1.0c81a6aa9a74dp-3' ---------- nosy: +tim.peters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 23:17:04 2015 From: report at bugs.python.org (Karl Richter) Date: Sat, 25 Apr 2015 21:17:04 +0000 Subject: [issue24060] Clearify necessities for logging with timestamps Message-ID: <1429996624.15.0.693068386122.issue24060@psf.upfronthosting.co.za> New submission from Karl Richter: The `Formatter` section of the `logging` module at https://docs.python.org/2/library/logging.html#formatter-objects reads like it's sufficient to create an instance of `Formatter` with default arguments (and set it as formatter of the `Handler` of a `Logger`) to have add timestamps to logging output. ---------- assignee: docs at python components: Documentation messages: 242024 nosy: docs at python, krichter priority: normal severity: normal status: open title: Clearify necessities for logging with timestamps versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sat Apr 25 23:51:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Sat, 25 Apr 2015 21:51:13 +0000 Subject: [issue24059] Minor speed and readability improvement to the random module In-Reply-To: <1429976148.71.0.723418409386.issue24059@psf.upfronthosting.co.za> Message-ID: <1429998673.43.0.781956058772.issue24059@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: >>> (0.0171889575379941**0.5).hex() '0x1.0c81a6aa9a74ep-3' >>> from math import * >>> sqrt(0.0171889575379941).hex() '0x1.0c81a6aa9a74dp-3' >>> 0.0171889575379941**0.5 == sqrt(0.0171889575379941) False ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 00:04:24 2015 From: report at bugs.python.org (Tim Peters) Date: Sat, 25 Apr 2015 22:04:24 +0000 Subject: [issue24059] Minor speed and readability improvement to the random module In-Reply-To: <1429976148.71.0.723418409386.issue24059@psf.upfronthosting.co.za> Message-ID: <1429999464.62.0.449352549469.issue24059@psf.upfronthosting.co.za> Tim Peters added the comment: FYI, my results match Serhiy's, on Windows, under Pythons 3.4.2 and 2.7.8. It's not surprising to me. Since IEEE 754 standardized sqrt, most vendors complied, delivering a square root "as if infinitely precise" with one anally correct rounding. But unless the platform pow() special-cases 0.5, that's going to involve a logarithm, multiplication, and exponentiation under the covers. pow() implementations usually fake some "extra precision" (else the worst-case errors can be horrendous), but it's still not always the same as single-rounding. Raymond, I didn't understand this part: "It's odd because your two result as same number, just displayed differently." The output immediately following that showed they _are_ different numbers on your box too (the .hex() outputs differ by one in the last place). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 00:32:49 2015 From: report at bugs.python.org (Ned Deily) Date: Sat, 25 Apr 2015 22:32:49 +0000 Subject: [issue24060] Clearify necessities for logging with timestamps In-Reply-To: <1429996624.15.0.693068386122.issue24060@psf.upfronthosting.co.za> Message-ID: <1430001169.29.0.619845873474.issue24060@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +vinay.sajip _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 00:39:03 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 25 Apr 2015 22:39:03 +0000 Subject: [issue9951] introduce bytes.hex method (also for bytearray and memoryview) In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1430001543.18.0.898428943891.issue9951@psf.upfronthosting.co.za> Gregory P. Smith added the comment: bytes.hex-1.diff looks good, i'll take care of committing this and adding a what's new entry. thanks! ---------- assignee: ncoghlan -> gregory.p.smith nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 00:48:02 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 25 Apr 2015 22:48:02 +0000 Subject: [issue24059] Minor speed and readability improvement to the random module In-Reply-To: <1429976148.71.0.723418409386.issue24059@psf.upfronthosting.co.za> Message-ID: <1430002082.07.0.00442518897219.issue24059@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > The output immediately following that showed they _are_ different numbers > on your box too So it is. Seems like I need to increase my font size :-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 01:11:04 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sat, 25 Apr 2015 23:11:04 +0000 Subject: [issue24059] Minor speed and readability improvement to the random module In-Reply-To: <1429976148.71.0.723418409386.issue24059@psf.upfronthosting.co.za> Message-ID: <1430003464.08.0.153638572698.issue24059@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The next question is whether we care about that 1 ULP in the context of the random number calculations which already involve multi-step chains that aren't favorable to retaining precision: s + (1.0 + s * s) ** 0.5 ainv = (2.0 * alpha - 1.0) ** 0.5 bbb = alpha - LOG4 ccc = alpha + ainv g2rad = (-2.0 * _log(1.0 - random())) ** 0.5 z = _cos(x2pi) * g2rad self.gauss_next = _sin(x2pi) * g2rad stddev = (sqsum/n - avg*avg) ** 0.5 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 01:22:38 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Apr 2015 23:22:38 +0000 Subject: [issue9951] introduce bytes.hex method (also for bytearray and memoryview) In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <20150425232235.129406.45722@psf.io> Roundup Robot added the comment: New changeset c9f1630cf2b1 by Gregory P. Smith in branch 'default': Implements issue #9951: Adds a hex() method to bytes, bytearray, & memoryview. https://hg.python.org/cpython/rev/c9f1630cf2b1 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 01:42:53 2015 From: report at bugs.python.org (Roundup Robot) Date: Sat, 25 Apr 2015 23:42:53 +0000 Subject: [issue9951] introduce bytes.hex method (also for bytearray and memoryview) In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <20150425234250.6595.51612@psf.io> Roundup Robot added the comment: New changeset 955a479b31a8 by Gregory P. Smith in branch 'default': Issue9951: update _hashopenssl and md5module to use _Py_strhex(). https://hg.python.org/cpython/rev/955a479b31a8 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 01:50:14 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Sat, 25 Apr 2015 23:50:14 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1430005814.66.0.381994765136.issue23342@psf.upfronthosting.co.za> Thomas Kluyver added the comment: I expect this can be closed now, unless there's some post-commit review somewhere that needs addressing? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 01:51:28 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Sat, 25 Apr 2015 23:51:28 +0000 Subject: [issue9951] introduce bytes.hex method (also for bytearray and memoryview) In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1430005888.95.0.739407549524.issue9951@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- resolution: -> fixed stage: patch review -> commit review status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 02:36:37 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 26 Apr 2015 00:36:37 +0000 Subject: [issue9951] introduce bytes.hex method (also for bytearray and memoryview) In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1430008597.06.0.61359617628.issue9951@psf.upfronthosting.co.za> Gregory P. Smith added the comment: note quite fixed, looks like some of the buildbots are having fun not compiling with this change: http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/9569/steps/compile/logs/stdio investigating... ---------- resolution: fixed -> status: closed -> open _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 02:39:22 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 26 Apr 2015 00:39:22 +0000 Subject: [issue9951] introduce bytes.hex method (also for bytearray and memoryview) In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1430008762.65.0.952792726251.issue9951@psf.upfronthosting.co.za> Gregory P. Smith added the comment: i missed the hg adds :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 02:41:13 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 26 Apr 2015 00:41:13 +0000 Subject: [issue9951] introduce bytes.hex method (also for bytearray and memoryview) In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <20150426004110.4001.16750@psf.io> Roundup Robot added the comment: New changeset a7737204c221 by Gregory P. Smith in branch 'default': Add the files missing from c9f1630cf2b1 for issue9951. https://hg.python.org/cpython/rev/a7737204c221 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 02:42:25 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 26 Apr 2015 00:42:25 +0000 Subject: [issue9951] introduce bytes.hex method (also for bytearray and memoryview) In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <20150426004224.27928.67671@psf.io> Roundup Robot added the comment: New changeset 7f0811452d0f by Gregory P. Smith in branch 'default': Switch binascii over to using the common _Py_strhex implementation for its hex https://hg.python.org/cpython/rev/7f0811452d0f ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 04:31:30 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 26 Apr 2015 02:31:30 +0000 Subject: [issue23857] Make default HTTPS certificate verification setting configurable via global ini file In-Reply-To: <1428057486.92.0.857087998573.issue23857@psf.upfronthosting.co.za> Message-ID: <1430015490.34.0.131550888465.issue23857@psf.upfronthosting.co.za> Nick Coghlan added the comment: Folks being wary of upgrading to new maintenance releases is already the case - RHEL/CentOS selectively backport things, and other orgs like Google do extensive integration testing before deploying new versions. Folks that only use and write well behaved and well maintained software can readily upgrade to new point releases, large enough organisations where that assumption isn't necessarily valid end up having to work a bit harder :) That said, I agree a hash randomisation style approach using environment variables should also work, I just expect it might be a little harder to check in a security auditing script. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 04:35:20 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 26 Apr 2015 02:35:20 +0000 Subject: [issue23955] Add python.ini file for embedded/applocal installs In-Reply-To: <1429038990.96.0.956334607163.issue23955@psf.upfronthosting.co.za> Message-ID: <1430015720.92.0.224840051391.issue23955@psf.upfronthosting.co.za> Nick Coghlan added the comment: If we're adding a static startup configuration file, then yes, I believe that should be a cross-platform feature, not something Windows specific, as it's a major change to our configuration philosophy. (I think it's a *necessary* change, but it's also a significant one) Even if it started out as Windows only, we should have a forward looking plan for how it relates to the startup sequence changes proposed in PEP 432. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 04:36:38 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 26 Apr 2015 02:36:38 +0000 Subject: [issue9951] introduce bytes.hex method (also for bytearray and memoryview) In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1430015798.31.0.178981260284.issue9951@psf.upfronthosting.co.za> Nick Coghlan added the comment: Thank you Arnon, and thank you Greg! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 06:02:53 2015 From: report at bugs.python.org (Russell Keith-Magee) Date: Sun, 26 Apr 2015 04:02:53 +0000 Subject: [issue23670] Modifications to support iOS as a cross-compilation target In-Reply-To: <1426400747.11.0.0527548590348.issue23670@psf.upfronthosting.co.za> Message-ID: <1430020973.21.0.406878994514.issue23670@psf.upfronthosting.co.za> Russell Keith-Magee added the comment: Here's an updated patch that integrates some of the feedback that has been received so far. Notable changes: * The code now works for ARMv7. Unfortunately, the price for this is a new libffi_ios_aarch source directory, containing generated source tree for the ARM64 platform. I've been working with the libffi community to address the compilation problems that exist in trunk, but so far, this hasn't resulted in a fix for the problems that have been introduced in their trunk code. * I looked into merging the libffi_ios and libffi_osx directories, but this proved to be harder I thought because of legacy PowerPC support. libffi still ships PowerPC sources, but they're no longer included in OS/X builds, because Apple stopped supporting PowerPC with OS/X 10.6 (released in 2009; the last PowerPC Apple hardware was shipped in 2006). As a result, it's difficult to find compilation instructions, and even harder to find actual hardware to test builds. If support for PowerPC architectures (on OS/X) was deprecated, this would make merging the libffi_ios and libffi_osx a trivial activity. * I've audited plat_ios/IN.py, and can now confirm that it *is* identical between platforms. * I have looked into replacing Setup.* with some sort of post-configure procedure as suggested by @doko. Unfortunately, it's not that simple. The problem is that there is already 2 places where the build requirements for a built-in module are defined. Modules/Setup contains one set of instructions (although those instructions are often commented out). The second set is hard coded into setup.py. The versions in setup.py are probably more reliable (as they're the ones actually used for most platforms), but you need to have a working Python to access them. However, at the "post-configure" point, you don't have a working Python, so there's a bootstrapping problem. I've refactored the Setup.ios-* definitions so that there's less duplication. There's now a Setup.embedded that contains the common build instructions for all the modules without platform-specific build instructions. Setup.ios-* just contains the platform-specific build instructions (in much the same way as setup.py has configure_ctypes_darwin). To work around this completely, we'd need to either introduce the need for a bootstrap Python so that a post-configure setup could access the build instructions contained in setup.py, or massively refactor the process of building modules so that there was a set of build instructions that both makesetup and setup.py could use. ---------- Added file: http://bugs.python.org/file39207/20150426.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 06:28:33 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 26 Apr 2015 04:28:33 +0000 Subject: [issue9951] introduce bytes.hex method (also for bytearray and memoryview) In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1430022513.29.0.888602755278.issue9951@psf.upfronthosting.co.za> Gregory P. Smith added the comment: I see some _Py_strhex related link errors on the Windows buildbots: http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/9642/steps/compile/logs/stdio ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 06:35:20 2015 From: report at bugs.python.org (Steve Dower) Date: Sun, 26 Apr 2015 04:35:20 +0000 Subject: [issue23955] Add python.ini file for embedded/applocal installs In-Reply-To: <1429038990.96.0.956334607163.issue23955@psf.upfronthosting.co.za> Message-ID: <1430022920.75.0.743402776138.issue23955@psf.upfronthosting.co.za> Steve Dower added the comment: I'm leaning towards clarifying/fixing the behavior of the venv config, since it's most of the way there for what I care about. Adding another option for applocal may be needed, but possibly not, in which case defining how relative paths are handled would be sufficient. Any other startup file I'd want to define as setting environment variables only, to avoid having multiple ways to set properties. So for most cases a shell script would suffice (doesn't help people linking to libpython directly, but they can call SetPythonHome themselves). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 07:00:10 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 26 Apr 2015 05:00:10 +0000 Subject: [issue9951] introduce bytes.hex method (also for bytearray and memoryview) In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <20150426050007.27904.48502@psf.io> Roundup Robot added the comment: New changeset b46308353ed9 by Gregory P. Smith in branch 'default': Add missing PyAPI_FUNC macro's to the public functions as other .c files do https://hg.python.org/cpython/rev/b46308353ed9 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 07:07:16 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 26 Apr 2015 05:07:16 +0000 Subject: [issue9951] introduce bytes.hex method (also for bytearray and memoryview) In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1430024836.17.0.168896964476.issue9951@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 07:12:44 2015 From: report at bugs.python.org (Nick Coghlan) Date: Sun, 26 Apr 2015 05:12:44 +0000 Subject: [issue23955] Add python.ini file for embedded/applocal installs In-Reply-To: <1429038990.96.0.956334607163.issue23955@psf.upfronthosting.co.za> Message-ID: <1430025164.29.0.182626666781.issue23955@psf.upfronthosting.co.za> Nick Coghlan added the comment: Treating "local Python" as a special-case of venv sounds like a good approach, then (especially as it currently seems plausible we'll end up going for environment variable based approach to the downstream PEP 476 backport) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 07:13:16 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 26 Apr 2015 05:13:16 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1430025196.19.0.71794478167.issue23342@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 07:28:46 2015 From: report at bugs.python.org (Tim Peters) Date: Sun, 26 Apr 2015 05:28:46 +0000 Subject: [issue24059] Minor speed and readability improvement to the random module In-Reply-To: <1429976148.71.0.723418409386.issue24059@psf.upfronthosting.co.za> Message-ID: <1430026126.44.0.658701171101.issue24059@psf.upfronthosting.co.za> Tim Peters added the comment: I don't care about the ULP. I don't care about exactly reproducing floating-point results across releases either, but I'd bet someone else does ;-) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 08:10:53 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 26 Apr 2015 06:10:53 +0000 Subject: [issue15339] document the threading "facts of life" in Python In-Reply-To: <1342130435.62.0.0784000861923.issue15339@psf.upfronthosting.co.za> Message-ID: <1430028653.17.0.593806861826.issue15339@psf.upfronthosting.co.za> Gregory P. Smith added the comment: This seems somewhat related to the "We need to document Python's concurrency and memory model" that came out at the language summit this year. ---------- nosy: +gregory.p.smith _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 08:44:20 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 26 Apr 2015 06:44:20 +0000 Subject: [issue23852] Wrong computation of max_fd on OpenBSD In-Reply-To: <1427987632.4.0.790792340938.issue23852@psf.upfronthosting.co.za> Message-ID: <20150426064417.31129.77307@psf.io> Roundup Robot added the comment: New changeset 7df280b311d0 by Gregory P. Smith in branch '3.4': Fix computation of max_fd on OpenBSD. Issue #23852. https://hg.python.org/cpython/rev/7df280b311d0 New changeset 08d0cc23fb00 by Gregory P. Smith in branch 'default': Fix computation of max_fd on OpenBSD. Issue #23852. https://hg.python.org/cpython/rev/08d0cc23fb00 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 08:47:00 2015 From: report at bugs.python.org (Gregory P. Smith) Date: Sun, 26 Apr 2015 06:47:00 +0000 Subject: [issue23852] Wrong computation of max_fd on OpenBSD In-Reply-To: <1427987632.4.0.790792340938.issue23852@psf.upfronthosting.co.za> Message-ID: <1430030820.12.0.137584745891.issue23852@psf.upfronthosting.co.za> Changes by Gregory P. Smith : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 09:16:47 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 26 Apr 2015 07:16:47 +0000 Subject: [issue22486] Add math.gcd() In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za> Message-ID: <1430032607.64.0.970817289201.issue22486@psf.upfronthosting.co.za> Stefan Behnel added the comment: Any more comments on this? The deadlines for new features in Py3.5 are getting closer. It seems we're just discussing details here, but pretty much everyone wants this feature. So, what are the things that still need to be done? Serhiy submitted working patches months ago. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 09:26:40 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 26 Apr 2015 07:26:40 +0000 Subject: [issue20485] Enable non-ASCII extension module names In-Reply-To: <1391350828.19.0.622173065149.issue20485@psf.upfronthosting.co.za> Message-ID: <1430033200.67.0.431755415388.issue20485@psf.upfronthosting.co.za> Stefan Behnel added the comment: PEP 489 (Redesigning extension module loading) includes the proposal to fix this by using punycode. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 09:43:37 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 26 Apr 2015 07:43:37 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <1430034217.98.0.754217067779.issue23996@psf.upfronthosting.co.za> Changes by Stefan Behnel : ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 09:49:42 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Apr 2015 07:49:42 +0000 Subject: [issue9951] introduce bytes.hex method (also for bytearray and memoryview) In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za> Message-ID: <1430034582.45.0.64055249426.issue9951@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 09:51:52 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Apr 2015 07:51:52 +0000 Subject: [issue23342] run() - unified high-level interface for subprocess In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za> Message-ID: <1430034712.3.0.914470470704.issue23342@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: commit review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 09:55:43 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 26 Apr 2015 07:55:43 +0000 Subject: [issue22881] show median in benchmark results In-Reply-To: <1416131417.96.0.330173729737.issue22881@psf.upfronthosting.co.za> Message-ID: <1430034943.2.0.189303709693.issue22881@psf.upfronthosting.co.za> Stefan Behnel added the comment: Any more comments on the patch, or can it be applied? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 11:10:32 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 26 Apr 2015 09:10:32 +0000 Subject: [issue23356] In argparse docs simplify example about argline In-Reply-To: <1422693639.9.0.487352753219.issue23356@psf.upfronthosting.co.za> Message-ID: <20150426091029.129430.81031@psf.io> Roundup Robot added the comment: New changeset bd8b99034121 by Berker Peksag in branch '3.4': Issue #23356: Simplify convert_arg_line_to_args example. https://hg.python.org/cpython/rev/bd8b99034121 New changeset 2d3ed019bc9f by Berker Peksag in branch 'default': Issue #23356: Simplify convert_arg_line_to_args example. https://hg.python.org/cpython/rev/2d3ed019bc9f ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 11:12:47 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 26 Apr 2015 09:12:47 +0000 Subject: [issue23356] In argparse docs simplify example about argline In-Reply-To: <1422693639.9.0.487352753219.issue23356@psf.upfronthosting.co.za> Message-ID: <20150426091245.21329.63803@psf.io> Roundup Robot added the comment: New changeset 050e0c0b3d90 by Berker Peksag in branch '2.7': Issue #23356: Simplify convert_arg_line_to_args example. https://hg.python.org/cpython/rev/050e0c0b3d90 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 11:14:04 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Apr 2015 09:14:04 +0000 Subject: [issue23356] In argparse docs simplify example about argline In-Reply-To: <1422693639.9.0.487352753219.issue23356@psf.upfronthosting.co.za> Message-ID: <1430039644.09.0.335687801587.issue23356@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks py.user. ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 11:19:35 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Apr 2015 09:19:35 +0000 Subject: [issue24021] Add docstring to urllib.urlretrieve In-Reply-To: <1429673026.41.0.442066158913.issue24021@psf.upfronthosting.co.za> Message-ID: <1430039975.51.0.591509886711.issue24021@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- keywords: +easy stage: -> needs patch title: document urllib.urlretrieve -> Add docstring to urllib.urlretrieve type: -> enhancement versions: +Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 11:19:49 2015 From: report at bugs.python.org (Berker Peksag) Date: Sun, 26 Apr 2015 09:19:49 +0000 Subject: [issue23852] Wrong computation of max_fd on OpenBSD In-Reply-To: <1427987632.4.0.790792340938.issue23852@psf.upfronthosting.co.za> Message-ID: <1430039989.11.0.906674536933.issue23852@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: patch review -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 14:58:41 2015 From: report at bugs.python.org (Ludovic Gasc) Date: Sun, 26 Apr 2015 12:58:41 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1430053121.82.0.847142528534.issue24018@psf.upfronthosting.co.za> Ludovic Gasc added the comment: Sorry guys to be basic for you, but if I take my "AsyncIO end-user" hat, I'm not sure to understand the potential end-user source code impacts to use Cython with Python 3.5 and AsyncIO. In concrete terms, it's only a low-level change, Cython will monkeypatch CPython if it's missing. I can continue to use asyncio.iscoroutine() function to detect coroutines. Or it should be better to change something in AsyncIO libs and/or end-user source code ? With the potential async/await inclusion in Python 3.5, it should be good to know if something else is necessary to help for the Cython support. ---------- nosy: +Ludovic.Gasc _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 15:17:30 2015 From: report at bugs.python.org (Hanno Boeck) Date: Sun, 26 Apr 2015 13:17:30 +0000 Subject: [issue24061] Python 2.x breaks with address sanitizer Message-ID: <1430054250.12.0.0817440488321.issue24061@psf.upfronthosting.co.za> New submission from Hanno Boeck: Right now it is not possible to build python 2.7.9 with address sanitizer. This issue has been worked around for python 3 in bug #18596 by marking some functions with attributes to tell address sanitizer to ignore them. I have attached a patch that will apply the same workaround to python 2.7. I'd apprechiate if this could be applied before the next python 2 release. Although it's the "old" python 2 version I think this is important enough to be backported. ---------- files: python-2.7.9-workaround-asan.diff keywords: patch messages: 242055 nosy: hanno priority: normal severity: normal status: open title: Python 2.x breaks with address sanitizer versions: Python 2.7 Added file: http://bugs.python.org/file39208/python-2.7.9-workaround-asan.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 15:17:44 2015 From: report at bugs.python.org (Hanno Boeck) Date: Sun, 26 Apr 2015 13:17:44 +0000 Subject: [issue24061] Python 2.x breaks with address sanitizer In-Reply-To: <1430054250.12.0.0817440488321.issue24061@psf.upfronthosting.co.za> Message-ID: <1430054264.6.0.978697164199.issue24061@psf.upfronthosting.co.za> Changes by Hanno Boeck : ---------- type: -> enhancement _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 17:11:00 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 26 Apr 2015 15:11:00 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> Message-ID: <1430061060.55.0.695767568732.issue24017@psf.upfronthosting.co.za> Stefan Behnel added the comment: Could we have type slots for the new special methods? Otherwise, implementing the protocol in C would be fairly inefficient, especially for async iteration. I'm asking because Cython's generator type is not Python's generator type, but implementing the rest of the proposed protocol doesn't seem to be all that difficult. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 18:41:44 2015 From: report at bugs.python.org (Demian Brecht) Date: Sun, 26 Apr 2015 16:41:44 +0000 Subject: [issue13567] HTTPError interface changes / breaks depending on what was passed to constructor In-Reply-To: <1323446082.73.0.0465562779799.issue13567@psf.upfronthosting.co.za> Message-ID: <1430066504.44.0.771807226291.issue13567@psf.upfronthosting.co.za> Changes by Demian Brecht : ---------- nosy: +demian.brecht _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 18:47:51 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 26 Apr 2015 16:47:51 +0000 Subject: [issue24059] Minor speed and readability improvement to the random module In-Reply-To: <1429976148.71.0.723418409386.issue24059@psf.upfronthosting.co.za> Message-ID: <1430066871.53.0.876517860267.issue24059@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Okay, I give up. ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 18:49:49 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 26 Apr 2015 16:49:49 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <20150426164946.21335.20915@psf.io> Roundup Robot added the comment: New changeset 15c80f63ea1c by Antoine Pitrou in branch '3.4': Issue #23996: Avoid a crash when a delegated generator raises an unnormalized StopIteration exception. Patch by Stefan Behnel. https://hg.python.org/cpython/rev/15c80f63ea1c New changeset 9d0c6c66b0ac by Antoine Pitrou in branch 'default': Issue #23996: Avoid a crash when a delegated generator raises an unnormalized StopIteration exception. Patch by Stefan Behnel. https://hg.python.org/cpython/rev/9d0c6c66b0ac ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 18:50:20 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Sun, 26 Apr 2015 16:50:20 +0000 Subject: [issue24058] Compiler warning for readline extension In-Reply-To: <1429971670.78.0.634220240768.issue24058@psf.upfronthosting.co.za> Message-ID: <1430067020.12.0.347930251396.issue24058@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Does simply removing the "extern" work? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 18:51:53 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 26 Apr 2015 16:51:53 +0000 Subject: [issue23996] _PyGen_FetchStopIterationValue() crashes on unnormalised exceptions In-Reply-To: <1429386313.82.0.910239252026.issue23996@psf.upfronthosting.co.za> Message-ID: <1430067113.04.0.254358157883.issue23996@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Thanks for the patch! ---------- resolution: -> fixed stage: -> resolved status: open -> closed versions: -Python 3.3 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 19:00:53 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 26 Apr 2015 17:00:53 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430067653.89.0.965413550982.issue24053@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Those should be in the os module, not in sys. The os module is for interfaces to the operating system, while the sys module is for Python-specific stuff. As for the point of adding them, I don't find them useful, but I won't oppose it either :-) ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 19:12:58 2015 From: report at bugs.python.org (Cyd Haselton) Date: Sun, 26 Apr 2015 17:12:58 +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: <1430068378.97.0.801566522691.issue23496@psf.upfronthosting.co.za> Cyd Haselton added the comment: On a related note, I managed to get pip working with this build...minus some errors with verbose mode. I first had to make some edits to setup.py and Modules/Setup so that the build would find and make the _ssl and lzip modules. After running make install, I ran 'python -m ensurepip'. I tested it by searching for and installing the BeautifulSoup module. Ryan, Let me know what are the next steps for this issue/build...and I'll do my best to get them done. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 19:26:38 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 26 Apr 2015 17:26:38 +0000 Subject: [issue24059] Minor speed and readability improvement to the random module In-Reply-To: <1429976148.71.0.723418409386.issue24059@psf.upfronthosting.co.za> Message-ID: <1430069198.06.0.283207213115.issue24059@psf.upfronthosting.co.za> Mark Dickinson added the comment: Gah! Peephole optimizer! When you do a timeit for '3.14 ** 0.5', you're just evaluating the time to retrieve a constant! In general, `**` is going to be both slower *and* less accurate than math.sqrt. Please don't make this change! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 19:27:56 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 26 Apr 2015 17:27:56 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> Message-ID: <1430069276.7.0.114099654891.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: > Could we have type slots for the new special methods? Otherwise, implementing the protocol in C would be fairly inefficient, especially for async iteration. I don't think it's necessary to have slots for __aiter__, __anext__, __aenter__ and __aexit__. Async iteration will never be as fast as regular iteration, and there is plenty overhead in it. And we don't need slots for async context managers as we don't have slots for regular ones. What might be a good idea is to add a slot for __await__ method -- tp_await. This will allow to implement Futures in C efficiently. I'd rename 'tp_reserved' for this purpose. Victor, your thoughts? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 19:29:49 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 26 Apr 2015 17:29:49 +0000 Subject: [issue24059] Minor speed and readability improvement to the random module In-Reply-To: <1429976148.71.0.723418409386.issue24059@psf.upfronthosting.co.za> Message-ID: <1430069389.87.0.288237546506.issue24059@psf.upfronthosting.co.za> Mark Dickinson added the comment: Timing results on my machine: (Canopy 64bit) taniyama:~ mdickinson$ python3 -m timeit -s "from math import sqrt; x = 3.14" "sqrt(x)" 10000000 loops, best of 3: 0.0426 usec per loop (Canopy 64bit) taniyama:~ mdickinson$ python3 -m timeit -s "from math import sqrt; x = 3.14" "x**0.5" 10000000 loops, best of 3: 0.0673 usec per loop And the disassembly showing the peephole optimizer at work: >>> def f(): return 3.14**0.5 ... >>> import dis >>> dis.dis(f) 1 0 LOAD_CONST 3 (1.772004514666935) 3 RETURN_VALUE ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 19:31:04 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 26 Apr 2015 17:31:04 +0000 Subject: [issue24059] Minor speed and readability improvement to the random module In-Reply-To: <1429976148.71.0.723418409386.issue24059@psf.upfronthosting.co.za> Message-ID: <1430069464.7.0.0447041641992.issue24059@psf.upfronthosting.co.za> Mark Dickinson added the comment: Ah, I missed that the issue was already closed. Apologies for the excitement and the gratuitous exclamation marks in my previous messages. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 19:33:25 2015 From: report at bugs.python.org (Tim Peters) Date: Sun, 26 Apr 2015 17:33:25 +0000 Subject: [issue24059] Minor speed and readability improvement to the random module In-Reply-To: <1429976148.71.0.723418409386.issue24059@psf.upfronthosting.co.za> Message-ID: <1430069605.15.0.366622563006.issue24059@psf.upfronthosting.co.za> Tim Peters added the comment: Good catch, Mark! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 19:43:24 2015 From: report at bugs.python.org (Mark Dickinson) Date: Sun, 26 Apr 2015 17:43:24 +0000 Subject: [issue22544] Inconsistent cmath.log behaviour In-Reply-To: <1412320697.54.0.866089400402.issue22544@psf.upfronthosting.co.za> Message-ID: <1430070204.22.0.39985922885.issue22544@psf.upfronthosting.co.za> Mark Dickinson added the comment: Per: yes, that's true. I don't think changing either division or multiplication is the way forward for this issue, though; I'd rather implement the less invasive change where `cmath.log` special-cases the situation where its second argument is real and positive. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 20:47:33 2015 From: report at bugs.python.org (paul rubin) Date: Sun, 26 Apr 2015 18:47:33 +0000 Subject: [issue5784] raw deflate format and zlib module In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za> Message-ID: <1430074053.08.0.367265718472.issue5784@psf.upfronthosting.co.za> paul rubin added the comment: Hey, thanks for updating this. I still remember the nasty incident that got me filing this report in the first place. I'll look at the patch more closely when I get a chance, but the immediate comment I'd make is it's worth adding a sentence saying explicitly to use wbits=-15 if you need to interoperate with some other libraries like PHP, that strip off the header. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 21:14:18 2015 From: report at bugs.python.org (July Tikhonov) Date: Sun, 26 Apr 2015 19:14:18 +0000 Subject: [issue24062] links to os.stat() in documentation lead to stat module instead Message-ID: <1430075658.37.0.617374885608.issue24062@psf.upfronthosting.co.za> New submission from July Tikhonov: Documentation of os.fstat() https://docs.python.org/3/library/os.html#os.fstat has a "See also:" section, which features a wrong link. The same with os.lstat(). Some of this problem was fixed (among other things) in issue 10960. But since then, two more wrong links appeared. Attached patch applies to 3.5, although 3.4 has the same problem. ---------- assignee: docs at python components: Documentation files: doc-library-os-stat-links.diff keywords: patch messages: 242070 nosy: docs at python, july priority: normal severity: normal status: open title: links to os.stat() in documentation lead to stat module instead type: enhancement versions: Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file39209/doc-library-os-stat-links.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 21:37:49 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 26 Apr 2015 19:37:49 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1430077069.41.0.368631007048.issue24018@psf.upfronthosting.co.za> Raymond Hettinger added the comment: In the lastest patch, the close() method is now a valid mixin method. However, the throw() method should be made abstract because it doesn't provide the required operation (it doesn't even use the "self" argument) or it should be left out entirely (i.e. Numba only supporting next()) if the presence of throw() is not required. Going back to Stefan's original use case, the problem being solved is that isinstance(g, types.GeneratorType) rejects regular classes that implement send(), next(), throw(), and close(), presumably because it is going to call those methods and expect that they work. If an object tests positive for isinstance(g, collections.abc.Generator), what can we then assume about the object. It would be weird to pass that test, see a throw() method, call it and have it do something other than raise an exception inside the generator. g = lazy_readline_from_connection('171.0.0.1') if isinstance(g, collections.abc.Generator): # We passed the isinstance check, now what does that # actually mean? What is guaranteed to work? next(g) g.close() # Expect this to close the connection If a working throw() isn't actually required, then the code ought to be checking for isinstance(obj, collections.abc.Iterator) or somesuch; otherwise, was is the point of doing any checks for a generator-like object? I don't think this patch should go in until it is capable of doing something meaningful. Otherwise, it looks like at attempt to bluff its way past generator checks that were presumably there for a reason. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 21:40:43 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Sun, 26 Apr 2015 19:40:43 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1430077243.11.0.251291374093.issue24018@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I think the throw() method should be required. If you don't need throw(), send() or close(), then you aren't really asking for a full-blown generator: you are asking for an iterator, so you can just check for collections.Iterator. (PS: why is this bug assigned to Lukasz?) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 21:43:46 2015 From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Verschelde?=) Date: Sun, 26 Apr 2015 19:43:46 +0000 Subject: [issue24063] Support Mageia and Arch Linux in the platform module Message-ID: <1430077426.39.0.0830591110576.issue24063@psf.upfronthosting.co.za> New submission from R?mi Verschelde: Support for Mageia and Arch Linux was added in the platform module for Python 3.x [1, 2], but the fix was not backported to the 2.7.x branch. It would be nice to see these fixes cherry-picked for the incoming 2.7.10 release. [1] https://hg.python.org/cpython/rev/97a098aa4205 [2] https://hg.python.org/cpython/rev/85d827cbabfa ---------- components: Library (Lib) messages: 242073 nosy: akien priority: normal severity: normal status: open title: Support Mageia and Arch Linux in the platform module versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 21:51:46 2015 From: report at bugs.python.org (Masayuki Yamamoto) Date: Sun, 26 Apr 2015 19:51:46 +0000 Subject: [issue24058] Compiler warning for readline extension In-Reply-To: <1429971670.78.0.634220240768.issue24058@psf.upfronthosting.co.za> Message-ID: <1430077906.93.0.150080672686.issue24058@psf.upfronthosting.co.za> Masayuki Yamamoto added the comment: I tried another two case changing variable declaration. First case of just removing "extern", Compiler similarly warns, and test passed. Second case of removing "_PyOS_ReadlineTState" declaration, Compiler has not warned, and test passed. First: $ hg diff diff -r a50707a73d84 Modules/readline.c --- a/Modules/readline.c Wed Nov 05 15:11:34 2014 +0100 +++ b/Modules/readline.c Mon Apr 27 03:09:06 2015 +0900 @@ -1062,7 +1062,7 @@ rl_callback_handler_remove(); } -extern PyThreadState* _PyOS_ReadlineTState; +PyThreadState* _PyOS_ReadlineTState; static char * readline_until_enter_or_signal(const char *prompt, int *signal) $ ./configure --prefix=/opt/py34 && make ... building 'readline' extension ... /cygdrive/d/cyghome/masayuki/src/CPython-3.4/Modules/readline.c:1065:16: warning: '_PyOS_ReadlineTState' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes] PyThreadState* _PyOS_ReadlineTState; ^ ... $ make install $ /opt/py34/bin/python3.4m.exe -E -Wd -mtest -v test_readline == CPython 3.4.3+ (3.4:a50707a73d84+, Apr 27 2015, 02:59:04) [GCC 4.9.2] == CYGWIN_NT-6.0-1.7.35-0.287-5-3-i686-32bit-WindowsPE little-endian == hash algorithm: siphash24 32bit == /tmp/test_python_3872 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) [1/1] test_readline testHistoryUpdates (test.test_readline.TestHistoryManipulation) ... ok test_init (test.test_readline.TestReadline) ... ok ---------------------------------------------------------------------- Ran 2 tests in 0.203s OK 1 test OK. Second: $ hg diff diff -r a50707a73d84 Modules/readline.c --- a/Modules/readline.c Wed Nov 05 15:11:34 2014 +0100 +++ b/Modules/readline.c Mon Apr 27 04:13:45 2015 +0900 @@ -1062,7 +1062,6 @@ rl_callback_handler_remove(); } -extern PyThreadState* _PyOS_ReadlineTState; static char * readline_until_enter_or_signal(const char *prompt, int *signal) $ ./configure --prefix=/opt/py34 && make ... building 'readline' extension has not warned. $ make install $ /opt/py34/bin/python3.4m.exe -E -Wd -mtest -v test_readline == CPython 3.4.3+ (3.4:a50707a73d84+, Apr 27 2015, 04:19:36) [GCC 4.9.2] == CYGWIN_NT-6.0-1.7.35-0.287-5-3-i686-32bit-WindowsPE little-endian == hash algorithm: siphash24 32bit == /tmp/test_python_5936 Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0) [1/1] test_readline testHistoryUpdates (test.test_readline.TestHistoryManipulation) ... ok test_init (test.test_readline.TestReadline) ... ok ---------------------------------------------------------------------- Ran 2 tests in 0.160s OK 1 test OK. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 21:56:30 2015 From: report at bugs.python.org (Roundup Robot) Date: Sun, 26 Apr 2015 19:56:30 +0000 Subject: [issue24058] Compiler warning for readline extension In-Reply-To: <1429971670.78.0.634220240768.issue24058@psf.upfronthosting.co.za> Message-ID: <20150426195627.27908.86773@psf.io> Roundup Robot added the comment: New changeset ec6ed10d611e by Benjamin Peterson in branch '3.4': remove extern definition, since it's in a header file (closes #24058) https://hg.python.org/cpython/rev/ec6ed10d611e New changeset 192f9efe4a38 by Benjamin Peterson in branch '2.7': remove extern definition, since it's in a header file (closes #24058) https://hg.python.org/cpython/rev/192f9efe4a38 New changeset cb4334ab8453 by Benjamin Peterson in branch 'default': merge 3.4 (#24058) https://hg.python.org/cpython/rev/cb4334ab8453 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 22:12:54 2015 From: report at bugs.python.org (John Hergenroeder) Date: Sun, 26 Apr 2015 20:12:54 +0000 Subject: [issue23796] BufferedReader.peek() crashes if closed In-Reply-To: <1427502590.02.0.665422119627.issue23796@psf.upfronthosting.co.za> Message-ID: <1430079174.96.0.516139712528.issue23796@psf.upfronthosting.co.za> John Hergenroeder added the comment: It looks like my contributor form has gone through -- what should my next steps here be? Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 22:20:21 2015 From: report at bugs.python.org (Wolfgang Maier) Date: Sun, 26 Apr 2015 20:20:21 +0000 Subject: [issue22881] show median in benchmark results In-Reply-To: <1416131417.96.0.330173729737.issue22881@psf.upfronthosting.co.za> Message-ID: <1430079621.94.0.188226131841.issue22881@psf.upfronthosting.co.za> Changes by Wolfgang Maier : ---------- nosy: +wolma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 22:32:06 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 26 Apr 2015 20:32:06 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1430080326.07.0.575963702571.issue24018@psf.upfronthosting.co.za> Stefan Behnel added the comment: PEP 342 isn't really conclusive here as it intended to define the protocol based on the de-facto design of a yield-based generator function. Trying to abstract from that poses the question how a class based generator implementation should look like. Specifically, it is not clear in this case what "raise an exception *inside* the generator" even means. As Antoine pointed out, there definitely has to be more than an Iterator. However, it's not clear that throw() and close() are always required for an implementation. Simple Generators might get away without special error handling and cleanup. Similarly, a Generator may not allow (or expect) values to be passed in and only make use of close() for cleanup (and potentially also throw()). So, there seem to be at least three use cases for the Generator protocol here: 1) an Iterator that can accept input values via send() 2) an Iterator that needs to safely do certain cleanup operations after use (throw/close) 3) a complete Generator that accepts input values and cleans up after it Given that there used to be only one implementation, I think we can assume that a lot of code depends on the complete protocol. Some recipients will certainly be aware of the exact subset of the protocol that the Generator they have in their hands makes use of, but if they don't, they'll just have to assume it supports everything and requires proper cleanup on errors and on termination. Therefore, I think it's important to cover the complete protocol in the Generator ABC. I also think it's helpful to not require users to override throw() in a subclass, as they might not need it. "Throwing an exception inside of them" might simply not have a meaning for them. If they do need it, however, then the current implementation might help them to properly raise the exception, given that the 3-argument raise statement is no longer available in Py3. Both reasons (whether you need throw() or not) make me think that it should not be abstract. The same applies to close(), which has a meaningful implementation now that subclasses can make use of in order to avoid having to implement both close() and throw(). And yes, this is about sneaking past generator type checks because most of them are actually *not* there for a reason. Asyncio is just one example. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 22:32:38 2015 From: report at bugs.python.org (Wolfgang Maier) Date: Sun, 26 Apr 2015 20:32:38 +0000 Subject: [issue22881] show median in benchmark results In-Reply-To: <1416131417.96.0.330173729737.issue22881@psf.upfronthosting.co.za> Message-ID: <1430080358.24.0.732071183129.issue22881@psf.upfronthosting.co.za> Wolfgang Maier added the comment: for the even number case, I think you shouldn't do // 2, but / 2. In general, wouldn't it be good to let the statistics module do all the stats calculations? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 22:35:15 2015 From: report at bugs.python.org (Stefan Behnel) Date: Sun, 26 Apr 2015 20:35:15 +0000 Subject: [issue22881] show median in benchmark results In-Reply-To: <1416131417.96.0.330173729737.issue22881@psf.upfronthosting.co.za> Message-ID: <1430080515.45.0.669305781367.issue22881@psf.upfronthosting.co.za> Stefan Behnel added the comment: > In general, wouldn't it be good to let the statistics module do all the stats calculations? It's not available in older Python versions, e.g. 2.6. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 22:38:02 2015 From: report at bugs.python.org (Wolfgang Maier) Date: Sun, 26 Apr 2015 20:38:02 +0000 Subject: [issue22881] show median in benchmark results In-Reply-To: <1416131417.96.0.330173729737.issue22881@psf.upfronthosting.co.za> Message-ID: <1430080682.93.0.77132738778.issue22881@psf.upfronthosting.co.za> Wolfgang Maier added the comment: > It's not available in older Python versions, e.g. 2.6. I know, I was talking about 3.5+, of course. This would not be backported to Python2 anyway, would it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 22:51:28 2015 From: report at bugs.python.org (Wolfgang Maier) Date: Sun, 26 Apr 2015 20:51:28 +0000 Subject: [issue22881] show median in benchmark results In-Reply-To: <1416131417.96.0.330173729737.issue22881@psf.upfronthosting.co.za> Message-ID: <1430081488.42.0.106116736518.issue22881@psf.upfronthosting.co.za> Wolfgang Maier added the comment: ah sorry, it's late here already and I forgot what file this change is about. So forget my last comment then. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 23:33:37 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 26 Apr 2015 21:33:37 +0000 Subject: [issue23910] C implementation of namedtuple (WIP) In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1430084017.1.0.0516574290999.issue23910@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, the current property(itemgetter(index)) code has a Python creation step, but the actual attribute lookup and dispatch is done entirely in C (no pure python steps around the eval lookup). Rather than making a user visible C hack directly to namedtuple, any optimization effort should be directly at improving the speed of property() and itemgetter(). Here are some quick notes to get you started: * The overhead of property() is almost nothing. * The code for property_descr_get() in Objects/descrobject.c * It has two nearly zero cost predictable branches * So the the only real work is a call to PyObject_CallFunctionObjArgs(gs->prop_get, obj, NULL); * which then calls both objargs_mktuple(vargs) and PyObject_Call(callable, args, NULL); * That can be sped-up by using PyTuple_New(1) and a direct call to PyObject_Call() * The logic in PyObject_Call can potentially be tightened in the context of a property(itemgetter(index)) call. Look to see whether recursion check is necessary (itemgetter on a tuple subclass that doesn't extend __getitem__ is non-recursive) * If so, then entire call to PyObject_Call() in property can potentially be simplified to: result = (*call)(func, arg, kw); I haven't looked too closely at this, but I think you get the general idea. If the speed of property(itemgetter(index)) is the bottleneck in your code, the starting point is to unwind the exact series of C steps performed to see if any of them can be simplified. For the most part, the code in property() and itemgetter() were both implemented using the simplest C parts of the C API rather than the fastest. The chain of calls isn't specialized for the common use case (i.e. property_get() needing exactly 1 argument rather than a variable length arg tuple and itemgetter doing a known integer offset on a list or tuple rather than the less common case of generic types and a possible tuple of indices). We should start by optimizing what we've already got. That will have a benefit beyond named tuples (faster itemgetters for sorting and faster property gets for the entire language). It also helps us avoid making the NT code less familiar (using custom private APIs rather than generic, well-known components). It also reduces the risk of breaking code that relies on the published implementation of named tuple attribute lookups (for example, I've seen deployed code that customizes the attribute docstrings like this): Point = namedtuple('Point', ['x', 'y']) Point.x = property(Point.x.fget, doc='abscissa') Point.y = property(Point.y.fget, doc='ordinate') coordinate = Point(x=250, y=43) ---------- priority: normal -> low _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 23:42:52 2015 From: report at bugs.python.org (Ned Deily) Date: Sun, 26 Apr 2015 21:42:52 +0000 Subject: [issue24061] Python 2.x breaks with address sanitizer In-Reply-To: <1430054250.12.0.0817440488321.issue24061@psf.upfronthosting.co.za> Message-ID: <1430084572.14.0.802716317797.issue24061@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Sun Apr 26 23:54:24 2015 From: report at bugs.python.org (Antti Haapala) Date: Sun, 26 Apr 2015 21:54:24 +0000 Subject: [issue22057] The doc say all globals are copied on eval(), but only __builtins__ is copied In-Reply-To: <1406210389.95.0.0796853252426.issue22057@psf.upfronthosting.co.za> Message-ID: <1430085264.7.0.627172810353.issue22057@psf.upfronthosting.co.za> Antti Haapala added the comment: +1 for this patch, the current documentation states it very wrong. ---------- nosy: +ztane _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 00:33:46 2015 From: report at bugs.python.org (STINNER Victor) Date: Sun, 26 Apr 2015 22:33:46 +0000 Subject: [issue24050] [2.7] crash in third party module mopidy In-Reply-To: <1429882485.21.0.520202259055.issue24050@psf.upfronthosting.co.za> Message-ID: <1430087626.23.0.280003925318.issue24050@psf.upfronthosting.co.za> STINNER Victor added the comment: mopidy is not maintained by Python. Report the bug to mopidy authors: https://www.mopidy.com/ ---------- nosy: +haypo resolution: -> not a bug status: open -> closed title: Segmentation fault (core dumped) -> [2.7] crash in third party module mopidy _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 01:04:43 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Sun, 26 Apr 2015 23:04:43 +0000 Subject: [issue23910] C implementation of namedtuple (WIP) In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1430089483.51.0.982412630927.issue23910@psf.upfronthosting.co.za> Raymond Hettinger added the comment: One other thought: the itemgetter.__call__ method is already pretty thin: if (!PyArg_UnpackTuple(args, "itemgetter", 1, 1, &obj)) return NULL; if (nitems == 1) return PyObject_GetItem(obj, ig->item); But you could add a special case for single integer index being applied to a known sequence. Extract the Py_ssize_t index in itemgetter_new and store it in the itemgetterobject. Then add a fast path in itemgetter.__call__. Roughly something like this: if (ig->index != -1 && PyTuple_Check(obj) && nitems == 1 && PyTuple_GET_SIZE(obj) > ig->index) { result = PySequence_Fast_GET_ITEM(obj, ig->index); Py_INCREF(result); return result; } Perhaps also add a check to make sure the tuple subclass hasn't overridden the __getitem__ method (see an example of how to do this in the code for Modules/_collectionsmodule.c::_count_elements()). Something along these lines would allow all the steps to be inlined and would eliminate all the usual indirections inherent in the abstract API. Another alternative is to use the PySequence API instead of the PyTuple API. That trades away a little of the speed-up in return for speeding-up itemgetter on lists as well as tuples. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 01:27:49 2015 From: report at bugs.python.org (Yury Selivanov) Date: Sun, 26 Apr 2015 23:27:49 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> Message-ID: <1430090869.4.0.302489411274.issue24017@psf.upfronthosting.co.za> Yury Selivanov added the comment: In fact I will likely add tp_await in the next PEP iteration. I need it to implement another feature. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 02:07:06 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Apr 2015 00:07:06 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1430093226.32.0.0835410771941.issue24018@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > Therefore, I think it's important to cover the complete protocol > in the Generator ABC. I also think it's helpful to not require > users to override throw() in a subclass, as they might not need it. Sorry, but I think you're fighting the fundament nature of what the ABCs are supposed to do and I object to the patch going in as-is. Please either 1) drop the throw() method entirely or 2) make throw an abstractmethod() If it is an abstractmethod, the user is free to implement a throw() method that raises a NotImplementedError, but at least they will do so consciously rather than having it come-up expectedly. When I teach engineers how to use the collections ABCs, they rely on the rules: * when building a class that inherits from an ABC, if you supply the required abstract methods, then the mixin method just work. * if an object passes the isinstance check, then it is fair game to call any of the listed methods an expect it to work. Until now, those rules were followed by all the ABCs. I really don't want to break the basic contract of what the ABC is supposed to mean. ---------- assignee: lukasz.langa -> rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 02:35:05 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Apr 2015 00:35:05 +0000 Subject: [issue24061] Python 2.x breaks with address sanitizer In-Reply-To: <1430054250.12.0.0817440488321.issue24061@psf.upfronthosting.co.za> Message-ID: <20150427003501.6579.84730@psf.io> Roundup Robot added the comment: New changeset 4234b0dd2a54 by Benjamin Peterson in branch '2.7': allow 2.7 to be built with asan (closes #24061) https://hg.python.org/cpython/rev/4234b0dd2a54 ---------- nosy: +python-dev resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 02:44:08 2015 From: report at bugs.python.org (Joe Jevnik) Date: Mon, 27 Apr 2015 00:44:08 +0000 Subject: [issue23910] C implementation of namedtuple (WIP) In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1430095448.12.0.181223845579.issue23910@psf.upfronthosting.co.za> Joe Jevnik added the comment: I was unable to see a performance increase by playing with the itemgetter.__call__ code; however, updating the propery code seemed to show a small improvement. I think that for simple indexing the cost of checking if it is a sequence outways the faster dispatch (when using PySequence_GetItem). I can play with this further. * default [joejev at Sheila cpython]$ ./python -m timeit -s "from collections import namedtuple as n;a = n('n', 'a b c')(1, 2, 3)" "a.a" 10000000 loops, best of 3: 0.101 usec per loop * patch [joejev at Sheila cpython]$ ./python -m timeit -s "from collections import namedtuple as n;a = n('n', 'a b c')(1, 2, 3)" "a.a" 10000000 loops, best of 3: 0.0942 usec per loop ---------- Added file: http://bugs.python.org/file39210/property.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 03:24:53 2015 From: report at bugs.python.org (Christie) Date: Mon, 27 Apr 2015 01:24:53 +0000 Subject: [issue9517] Make test.script_helper more comprehensive, and use it in the test suite In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za> Message-ID: <1430097893.86.0.683610948452.issue9517@psf.upfronthosting.co.za> Christie added the comment: @serhiy.storchaka - just double checking, do you guys need me to make any more changes to the patch? And is there any more review needed, or is it possible for this to be merged? Thanks very much! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 03:30:57 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Apr 2015 01:30:57 +0000 Subject: [issue23910] C implementation of namedtuple (WIP) In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1430098257.7.0.387560206792.issue23910@psf.upfronthosting.co.za> Raymond Hettinger added the comment: If you have a chance, run a C profiler so we can see whether most of the time is being spent in an attribute lookup for the current property(itemgetter) approach versus your nt-indexer approach. Without a profile, I have only my instincts that the overhead is a mix of indirections and function call overhead (both solveable by in-lining), and over-generalization for all PyObject_GetItem() (solvable by specialization to a tuple subclass), and variable length argument lists (solveable by using of PyTuple_New(1)). Ideally, I would like something that speeds-up broader swaths of the language and doesn't obfuscate the otherwise clean generated code. ISTM that the C code for both property() and itemgetter() still have room to optimize the common case. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 03:33:27 2015 From: report at bugs.python.org (Robert Collins) Date: Mon, 27 Apr 2015 01:33:27 +0000 Subject: [issue22619] Possible implementation of negative limit for traceback functions In-Reply-To: <1413127450.91.0.243322258355.issue22619@psf.upfronthosting.co.za> Message-ID: <1430098407.95.0.449166684153.issue22619@psf.upfronthosting.co.za> Robert Collins added the comment: Nice, looks pretty elegant to me. I have nothing to add to the prior reviewers comments. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 04:19:03 2015 From: report at bugs.python.org (Joe Jevnik) Date: Mon, 27 Apr 2015 02:19:03 +0000 Subject: [issue23910] C implementation of namedtuple (WIP) In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1430101143.31.0.987074816843.issue23910@psf.upfronthosting.co.za> Joe Jevnik added the comment: This was very exciting, I have never run gprof before; so just to make sure I did this correctly, I will list my steps: 1. compile with the -pg flag set 1. run the test with ./python -m timeit ... 1. $ gprof python gmon.out > profile.out Here is default: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls Ts/call Ts/call name 22.48 0.87 0.87 PyEval_EvalFrameEx 9.82 1.25 0.38 PyObject_CallFunctionObjArgs 6.85 1.52 0.27 PyObject_GenericGetAttr 6.46 1.77 0.25 tupledealloc 5.56 1.98 0.22 PyArg_UnpackTuple 5.17 2.18 0.20 PyNumber_AsSsize_t 5.17 2.38 0.20 tuplesubscript 5.04 2.58 0.20 PyObject_Call 4.91 2.77 0.19 _PyType_Lookup 4.65 2.95 0.18 PyTuple_New 4.65 3.13 0.18 PyObject_GetItem 4.39 3.30 0.17 itemgetter_call 1.94 3.37 0.08 PyObject_GetAttr 1.81 3.44 0.07 PyObject_GC_UnTrack 1.81 3.51 0.07 _PyTuple_DebugMallocStats 1.03 3.55 0.04 PyErr_Occurred 1.03 3.59 0.04 property_descr_set 1.03 3.63 0.04 tuplerepr 0.78 3.66 0.03 PyLong_AsSsize_t 0.78 3.69 0.03 PyObject_GC_Track 0.52 3.71 0.02 property_descr_get 0.52 3.73 0.02 repeat_next 0.52 3.75 0.02 repeat_traverse 0.39 3.77 0.02 PyArg_ValidateKeywordArguments 0.39 3.78 0.02 _Py_CheckFunctionResult 0.26 3.79 0.01 PyCFunction_NewEx 0.26 3.80 0.01 PyCode_New 0.26 3.81 0.01 PyErr_Restore 0.26 3.82 0.01 PyType_GetSlot 0.26 3.83 0.01 _PyObject_CallMethodIdObjArgs 0.26 3.84 0.01 attrgetter_new 0.26 3.85 0.01 update_one_slot 0.13 3.86 0.01 _PyObject_GenericGetAttrWithDict 0.13 3.86 0.01 _PyObject_SetAttrId 0.13 3.87 0.01 gc_isenabled 0.13 3.87 0.01 visit_decref Here is my patch: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls Ts/call Ts/call name 26.63 1.02 1.02 PyEval_EvalFrameEx 8.88 1.36 0.34 PyObject_GenericGetAttr 7.83 1.66 0.30 tupledealloc 6.27 1.90 0.24 PyObject_Call 5.74 2.12 0.22 PyTuple_New 5.48 2.33 0.21 property_descr_get 5.22 2.53 0.20 _PyType_Lookup 4.44 2.70 0.17 tuplesubscript 4.18 2.86 0.16 PyArg_UnpackTuple 3.92 3.01 0.15 PyNumber_AsSsize_t 3.66 3.15 0.14 PyObject_GetItem 2.87 3.26 0.11 itemgetter_call 2.61 3.36 0.10 PyObject_GC_UnTrack 1.70 3.43 0.07 PyObject_GetAttr 1.31 3.48 0.05 repeat_next 1.31 3.53 0.05 repeat_traverse 1.04 3.57 0.04 attrgetter_new 1.04 3.61 0.04 property_descr_set 0.78 3.64 0.03 PyErr_Occurred 0.78 3.67 0.03 PyErr_Restore 0.78 3.70 0.03 PyLong_AsSsize_t 0.78 3.73 0.03 PyType_GetSlot 0.52 3.75 0.02 PyObject_GC_Track 0.26 3.76 0.01 PyArg_ValidateKeywordArguments 0.26 3.77 0.01 PyDict_GetItem 0.26 3.78 0.01 _PyObject_GenericGetAttrWithDict 0.26 3.79 0.01 _PyTuple_DebugMallocStats 0.26 3.80 0.01 _Py_CheckFunctionResult 0.26 3.81 0.01 convertitem 0.26 3.82 0.01 r_object 0.26 3.83 0.01 tuplerepr 0.13 3.83 0.01 _PyObject_SetAttrId It looks like you were correct that PyObject_CallFunctionObjArgs was eating up a lot of time. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 05:43:59 2015 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 27 Apr 2015 03:43:59 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1430106239.56.0.345364249664.issue24018@psf.upfronthosting.co.za> Guido van Rossum added the comment: I'm with Raymond. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 05:59:11 2015 From: report at bugs.python.org (Elizabeth Myers) Date: Mon, 27 Apr 2015 03:59:11 +0000 Subject: [issue23749] asyncio missing wrap_socket In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za> Message-ID: <1430107151.86.0.07895752709.issue23749@psf.upfronthosting.co.za> Elizabeth Myers added the comment: What needs to be done to make this happen? I can try to implement it. ---------- nosy: +Elizacat _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 06:04:04 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Apr 2015 04:04:04 +0000 Subject: [issue16669] Docstrings for namedtuple In-Reply-To: <1355333495.19.0.152758378027.issue16669@psf.upfronthosting.co.za> Message-ID: <1430107444.43.0.797848191051.issue16669@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, here's a proposed new classmethod that makes it possible to easily customize the field docstrings but without cluttering the API of the factory function: @classmethod def _set_docstrings(cls, **docstrings): '''Customize the field docstrings >>> Point = namedtuple('Point', ['x', 'y']) >>> Point._set_docstrings(x = 'abscissa', y = 'ordinate') ''' for fieldname, docstring in docstrings.items(): if fieldname not in cls._fields: raise ValueError('Fieldname %r does not exist' % fieldname) new_property = _property(getattr(cls, fieldname), doc=docstring) setattr(cls, fieldname, new_property) Note, nothing is needed for the main docstring since it is already writeable: Point.__doc__ = '2-D Coordinate' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 06:08:16 2015 From: report at bugs.python.org (Elizabeth Myers) Date: Mon, 27 Apr 2015 04:08:16 +0000 Subject: [issue23749] asyncio missing wrap_socket In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za> Message-ID: <1430107696.63.0.353930723977.issue23749@psf.upfronthosting.co.za> Elizabeth Myers added the comment: For what it's worth, IRC has an optional STARTTLS extension which is implemented by some servers. IMAP and SMTP also have STARTTLS as a fundamental component of their protocols. As gc pointed out, LDAP also supports it. IMO this is a pretty glaring omission. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 06:53:07 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Apr 2015 04:53:07 +0000 Subject: [issue24064] Make the property doctstring writeable Message-ID: <1430110387.37.0.412217606886.issue24064@psf.upfronthosting.co.za> New submission from Raymond Hettinger: I can't see any reason for property docstrings to be readonly: >>> p = property(doc='basic') >>> p.__doc__ 'basic' >>> p.__doc__ = 'extended' Traceback (most recent call last): File "", line 1, in p.__doc__ = 'extended' AttributeError: readonly attribute Among other things, making it writeable would simplify the ability to update the docstrings produced by namedtuple; Time.mtime.__doc__ = 'modification time' Score.max = 'all time cumulative high score for a single season' ---------- components: Interpreter Core keywords: easy messages: 242098 nosy: rhettinger priority: normal severity: normal stage: patch review status: open title: Make the property doctstring writeable type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 07:31:55 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 27 Apr 2015 05:31:55 +0000 Subject: [issue23970] Update distutils.msvccompiler for VC14 In-Reply-To: <1429136573.43.0.772566564267.issue23970@psf.upfronthosting.co.za> Message-ID: <1430112715.69.0.657576580565.issue23970@psf.upfronthosting.co.za> Steve Dower added the comment: Made some updates to the patch to use the existing infrastructure for setting include and library paths, and to fix bdist_wininst. While it may be worth doing more significant restructuring to help people with overriding aspects of build, that's almost certainly something that would be better done in a separate build tool. This patch is really just focused on getting the bare minimum support (distutils) working with the changed compiler and some cleanup to make it easier to maintain. ---------- Added file: http://bugs.python.org/file39211/msvccompiler_2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 07:32:23 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 27 Apr 2015 05:32:23 +0000 Subject: [issue23668] Support os.ftruncate on Windows In-Reply-To: <1426383698.86.0.63017868488.issue23668@psf.upfronthosting.co.za> Message-ID: <1430112743.12.0.0667933583265.issue23668@psf.upfronthosting.co.za> Changes by Steve Dower : ---------- resolution: -> fixed stage: commit review -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 08:08:00 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 27 Apr 2015 06:08:00 +0000 Subject: [issue23955] Add python.ini file for embedded/applocal installs In-Reply-To: <1429038990.96.0.956334607163.issue23955@psf.upfronthosting.co.za> Message-ID: <1430114880.2.0.681047250384.issue23955@psf.upfronthosting.co.za> Steve Dower added the comment: Having looked at the implementation, the easiest way to do this will be to add an "applocal = true" option to pyvenv.cfg, which would behave identically to setting %PYTHONHOME% to the directory containing the config before launch. I wanted to support relative paths for "home = " but the path handling is so far from sufficient that it wouldn't be secure. As it is, I've fixed a lot of potential buffer overruns in getpathp.c already, but I don't want to implement true relative paths, so I'd prefer to require "home = " to be absolute and add a second property that effectively means "home = .". Any thoughts/comments/preferences? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 08:14:47 2015 From: report at bugs.python.org (Laura Rupprecht) Date: Mon, 27 Apr 2015 06:14:47 +0000 Subject: [issue9858] Python and C implementations of io are out of sync In-Reply-To: <1284540793.42.0.0185593652898.issue9858@psf.upfronthosting.co.za> Message-ID: <1430115287.24.0.0299250040304.issue9858@psf.upfronthosting.co.za> Laura Rupprecht added the comment: There were originally three methods present in RawIOBase that were not present in PyRawIOBase_Type: 1. readinto 2. write 3. __weakref__ I've created a patch that adds the first two to PyRawIOBase_Type. The python class readinto and write methods raise UnsupportedOperation, so the c methods return a PyExc_NotImplementedError. The next major question I have is whether we need to implement a __weakref__ method or this should be ignored in the test. ---------- keywords: +patch nosy: +laura Added file: http://bugs.python.org/file39212/issue9858.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 08:26:11 2015 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 27 Apr 2015 06:26:11 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1430115971.36.0.61758436321.issue24018@psf.upfronthosting.co.za> Stefan Behnel added the comment: > Please either > 1) drop the throw() method entirely or > 2) make throw an abstractmethod() Ok, as I already said, I think it's important to provide the complete protocol as code will usually expect that. Also, close() has a helpful implementation, but it depends on throw(). Thus, I'll go with 2) and make throw() abstract. It's easy enough to call super(), but then it's explicit. I agree that that's better here. Patch updated. ---------- Added file: http://bugs.python.org/file39213/generator_abc.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 09:26:48 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Apr 2015 07:26:48 +0000 Subject: [issue23910] C implementation of namedtuple (WIP) In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1430119608.07.0.334407093055.issue23910@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Hmm, the presense of _PyTuple_DebugMallocStats, repeat_traverse, and visit_decref suggests that the profile may have been run with debugging code enabled and GC enabled. The property patch looks good. Depending on how far you want to go with this, you could save your tuple of length-1 statically and reuse it on successive calls if its refcnt doesn't grow (see the code for zip() for an example of how to do this). That would save the PyTuple_New and tupledealloc calls. Going further, potentially you could in-line some of the code it PyObject_Call, caching the callsite and its NULL check, and looking at the other steps to see if they are all necessary in the context of a property_desc_get(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 09:33:57 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Apr 2015 07:33:57 +0000 Subject: [issue24018] add a Generator ABC In-Reply-To: <1429558585.89.0.729845325991.issue24018@psf.upfronthosting.co.za> Message-ID: <1430120037.42.0.946952407027.issue24018@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The latest patch looks good overall. ?ukasz, assigning back to you. ---------- assignee: rhettinger -> lukasz.langa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 09:41:20 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Apr 2015 07:41:20 +0000 Subject: [issue22057] The doc say all globals are copied on eval(), but only __builtins__ is copied In-Reply-To: <1406210389.95.0.0796853252426.issue22057@psf.upfronthosting.co.za> Message-ID: <1430120480.09.0.499392421051.issue22057@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The patch looks good (though it would have been easier to check the diff if the text had not be reflowed). I will apply it when I get a chance. Or if anyone else wants to grab it, go ahead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 12:00:17 2015 From: report at bugs.python.org (Peter Otten) Date: Mon, 27 Apr 2015 10:00:17 +0000 Subject: [issue16669] Docstrings for namedtuple In-Reply-To: <1355333495.19.0.152758378027.issue16669@psf.upfronthosting.co.za> Message-ID: <1430128817.73.0.903929164101.issue16669@psf.upfronthosting.co.za> Peter Otten added the comment: Here's a variant that builds on your code, but makes for a nicer API. Single-line docstrings can be passed along with the attribute name, and with namedtuple.with_docstrings(... all info required to build the class ...) from a user perspective the factory looks like a class method: from functools import partial from collections import namedtuple def _with_docstrings(cls, typename, field_names_with_doc, *, verbose=False, rename=False, doc=None): field_names = [] field_docs = [] if isinstance(field_names_with_doc, str): field_names_with_doc = [ line for line in field_names_with_doc.splitlines() if line.strip()] for item in field_names_with_doc: if isinstance(item, str): item = item.split(None, 1) if len(item) == 1: [fieldname] = item fielddoc = None else: fieldname, fielddoc = item field_names.append(fieldname) field_docs.append(fielddoc) nt = cls(typename, field_names, verbose=verbose, rename=rename) for fieldname, fielddoc in zip(field_names, field_docs): if fielddoc is not None: new_property = property(getattr(nt, fieldname), doc=fielddoc) setattr(nt, fieldname, new_property) if doc is not None: nt.__doc__ = doc return nt namedtuple.with_docstrings = partial(_with_docstrings, namedtuple) if __name__ == "__main__": Point = namedtuple.with_docstrings("Point", "x abscissa\ny ordinate") Address = namedtuple.with_docstrings( "Address", """ name Surname first_name First name city email Email address """) Whatever = namedtuple.with_docstrings( "Whatever", [("foo", "doc for\n foo"), ("bar", "doc for bar"), "baz"], doc="""The Whatever class. Example for a namedtuple with multiline docstrings for its attributes.""") ---------- nosy: +peter.otten _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 12:41:38 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Apr 2015 10:41:38 +0000 Subject: [issue24064] Make the property doctstring writeable In-Reply-To: <1430110387.37.0.412217606886.issue24064@psf.upfronthosting.co.za> Message-ID: <1430131298.3.0.0294894095801.issue24064@psf.upfronthosting.co.za> Berker Peksag added the comment: Here is a patch. I'm not familiar with this part of the CPython source. So please tell me if there is a better way to do it. I only updated Doc/whatsnew/3.5, but other places in the documentation needs to be updated. ---------- keywords: +patch nosy: +berker.peksag Added file: http://bugs.python.org/file39214/issue24064.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 12:53:59 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Apr 2015 10:53:59 +0000 Subject: [issue24062] links to os.stat() in documentation lead to stat module instead In-Reply-To: <1430075658.37.0.617374885608.issue24062@psf.upfronthosting.co.za> Message-ID: <20150427105356.21349.19812@psf.io> Roundup Robot added the comment: New changeset 5850f0c17c34 by Berker Peksag in branch '3.4': Issue #24062: Fix os.stat links. Patch by July Tikhonov. https://hg.python.org/cpython/rev/5850f0c17c34 New changeset 18882c93f4bd by Berker Peksag in branch 'default': Issue #24062: Fix os.stat links. Patch by July Tikhonov. https://hg.python.org/cpython/rev/18882c93f4bd ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 12:55:17 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Apr 2015 10:55:17 +0000 Subject: [issue24062] links to os.stat() in documentation lead to stat module instead In-Reply-To: <1430075658.37.0.617374885608.issue24062@psf.upfronthosting.co.za> Message-ID: <1430132117.52.0.63374109693.issue24062@psf.upfronthosting.co.za> Berker Peksag added the comment: Thanks for the patch, July. ---------- nosy: +berker.peksag resolution: -> fixed stage: -> resolved status: open -> closed versions: -Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 13:02:07 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 27 Apr 2015 11:02:07 +0000 Subject: [issue24040] plistlib assumes dict_type is descendent of dict In-Reply-To: <1429814108.42.0.103611722711.issue24040@psf.upfronthosting.co.za> Message-ID: <1430132527.48.0.989196994064.issue24040@psf.upfronthosting.co.za> Ronald Oussoren added the comment: To react to myself: checking for self.dict_type might break users that pass in a callable: x = plistlib.load(fp, dict_type=lambda:{}) As Behdad memtioned testing that the type isn't list would be better: if not isinstance(..., list): That attached patch adds a testcase and removes replaces the test for type({}) for something better. Note: it also replaces ``type([])`` with ``list``, the latter is cleaner. ---------- Added file: http://bugs.python.org/file39215/issue-24040.txt _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 13:27:56 2015 From: report at bugs.python.org (Ronald Oussoren) Date: Mon, 27 Apr 2015 11:27:56 +0000 Subject: [issue8027] distutils fail to determine c++ linker with unixcompiler if using ccache In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za> Message-ID: <1430134076.37.0.356339490425.issue8027@psf.upfronthosting.co.za> Ronald Oussoren added the comment: I don't recall exactly why the universal build support is done the way it is, adding it is too long ago. The reason is likely no longer relevant with any reasonably up-to-date toolset. The patch was created around the time x86 support was added to OSX and at the time there were numerous rough edges (and IIRC I worked on this using a Developer Transition Kit at work, that is before Apple shipped consumer hardware with x86 support, let alone non-beta software with x86 support) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 14:38:17 2015 From: report at bugs.python.org (Joe Jevnik) Date: Mon, 27 Apr 2015 12:38:17 +0000 Subject: [issue23910] C implementation of namedtuple (WIP) In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1430138297.06.0.544161043943.issue23910@psf.upfronthosting.co.za> Joe Jevnik added the comment: I switched to the static tuple. ---------- Added file: http://bugs.python.org/file39216/with-static-tuple.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 14:52:03 2015 From: report at bugs.python.org (irdb) Date: Mon, 27 Apr 2015 12:52:03 +0000 Subject: [issue22408] Tkinter doesn't handle Unicode dead key combinations on Windows In-Reply-To: <1410709495.77.0.324762298735.issue22408@psf.upfronthosting.co.za> Message-ID: <1430139123.62.0.0501622118503.issue22408@psf.upfronthosting.co.za> Changes by irdb : ---------- nosy: +irdb _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 15:08:22 2015 From: report at bugs.python.org (Wolfgang Maier) Date: Mon, 27 Apr 2015 13:08:22 +0000 Subject: [issue23975] numbers.Rational implements __float__ incorrectly In-Reply-To: <1429214817.83.0.816258978912.issue23975@psf.upfronthosting.co.za> Message-ID: <1430140102.66.0.828119944569.issue23975@psf.upfronthosting.co.za> Wolfgang Maier added the comment: After considering this for a while, I think: return float(self.numerator / self.denominator) is the best solution: * it is simple and works reasonably well as a default * it fixes Rational.__float__ for cases, in which numerator / denominator returns a custom Real instance * in the problematic scenario brought up by Mark, in which truediv of the numerator and denominator returns another Rational creating a potentially infinite recursion, a RuntimeError will be raised when the maximum recursion limit is reached. This is not an unheard of error to run into while trying to implement a custom numeric type and will provide reasonable (though not ideal) information about the problem. * the workaround for the above is obvious: it is ok for self.numerator / self.denominator to return a Rational instance, but its type should overwrite Rational.__float__ to break the recursion. This could get documented in the docstring of Rational.__float__. I've attached a tentative patch. ---------- keywords: +patch Added file: http://bugs.python.org/file39217/Rational.__float__.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 15:13:23 2015 From: report at bugs.python.org (Joe Jevnik) Date: Mon, 27 Apr 2015 13:13:23 +0000 Subject: [issue23910] C implementation of namedtuple (WIP) In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1430140403.77.0.883111113369.issue23910@psf.upfronthosting.co.za> Joe Jevnik added the comment: I don't think that I can cache the __call__ of the fget object because it might be an instance of a heaptype, and if someone changed the __class__ of the object in between calls to another heaptype that had a different __call__, you would still get the __call__ from the first type. I also don't know if this is supported behavior or just something that works by accident. I read through PyObject_Call, and all the code is needed assuming we are not caching the tp_call value. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 15:24:43 2015 From: report at bugs.python.org (Chris Angelico) Date: Mon, 27 Apr 2015 13:24:43 +0000 Subject: [issue22906] PEP 479: Change StopIteration handling inside generators In-Reply-To: <1416480203.05.0.35241763619.issue22906@psf.upfronthosting.co.za> Message-ID: <1430141083.0.0.287739089083.issue22906@psf.upfronthosting.co.za> Chris Angelico added the comment: Had a peek at the 2.7 branch in the web (https://hg.python.org/cpython/file/4234b0dd2a54/Lib/test) and all the tests appear to be testing the behaviour *with* the future directive, not bothering to test the old behaviour. It makes sense - that way, when the future directive becomes permanent, there's no suddenly-failing test - can someone confirm that that's the intention? The current test simply triggers a StopIteration and verifies that RuntimeError comes up off it, without testing the current behaviour, nor testing any of the aspects that haven't changed. I'm basically assuming that generators themselves are adequately tested elsewhere, such that a bug in the PEP 479 code that breaks generators in any other way should be caught by a test failure someplace else. Can anyone think of other aspects of PEP 479 that need to be tested? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 16:49:28 2015 From: report at bugs.python.org (Roundup Robot) Date: Mon, 27 Apr 2015 14:49:28 +0000 Subject: [issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers In-Reply-To: <1398499255.25.0.881446688113.issue21354@psf.upfronthosting.co.za> Message-ID: <20150427144926.27914.36353@psf.io> Roundup Robot added the comment: New changeset 69951573cb0e by Andrew Svetlov in branch '3.4': Issue #21354: PyCFunction_New function is exposed by python DLL again. https://hg.python.org/cpython/rev/69951573cb0e ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 16:50:16 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 27 Apr 2015 14:50:16 +0000 Subject: [issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers In-Reply-To: <1398499255.25.0.881446688113.issue21354@psf.upfronthosting.co.za> Message-ID: <1430146216.0.0.927874465013.issue21354@psf.upfronthosting.co.za> Andrew Svetlov added the comment: Fixed. Sorry for long delay. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 16:50:28 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Mon, 27 Apr 2015 14:50:28 +0000 Subject: [issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers In-Reply-To: <1398499255.25.0.881446688113.issue21354@psf.upfronthosting.co.za> Message-ID: <1430146228.06.0.707131570568.issue21354@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 16:56:38 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Apr 2015 14:56:38 +0000 Subject: [issue16669] Docstrings for namedtuple In-Reply-To: <1355333495.19.0.152758378027.issue16669@psf.upfronthosting.co.za> Message-ID: <1430146598.95.0.787098566591.issue16669@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Sorry Peter, I don't like that variant and want to stick with a separate customization step that uses **kwds so we can use normal syntax for the name value pairs and to allow that possibility of someone passing in an existing dict using NT.set_docstrings(**d). Also FWIW, the addition can be simplified a bit when Issue 24064 is added: for fieldname, docstring in docstrings.items(): getattr(cls, fieldname).__doc__ = docstring ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 16:58:04 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Apr 2015 14:58:04 +0000 Subject: [issue16669] Docstrings for namedtuple In-Reply-To: <1355333495.19.0.152758378027.issue16669@psf.upfronthosting.co.za> Message-ID: <1430146684.21.0.321279144441.issue16669@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- Removed message: http://bugs.python.org/msg242118 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 17:00:39 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Apr 2015 15:00:39 +0000 Subject: [issue16669] Docstrings for namedtuple In-Reply-To: <1355333495.19.0.152758378027.issue16669@psf.upfronthosting.co.za> Message-ID: <1430146839.25.0.213223706766.issue16669@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Ideally, I prefer to stick with either a separate customization step or with the original __new__ constructor, and that uses **kwds so we can use a standard syntax for the name value pairs and to allow that possibility of someone passing in an existing dict using NT.set_docstrings(**d). Also FWIW, the addition can be simplified a bit when Issue 24064 is added: for fieldname, docstring in docstrings.items(): getattr(cls, fieldname).__doc__ = docstring ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 17:07:10 2015 From: report at bugs.python.org (Dan O'Reilly) Date: Mon, 27 Apr 2015 15:07:10 +0000 Subject: [issue15064] Use context manager protocol for more multiprocessing types In-Reply-To: <1339676025.91.0.9899325094.issue15064@psf.upfronthosting.co.za> Message-ID: <1430147230.91.0.128638057008.issue15064@psf.upfronthosting.co.za> Dan O'Reilly added the comment: It's probably too late to do anything about this now, but wouldn't it make more sense for `Pool.__exit__` to call `close`, rather than `terminate`? The vast majority of the time, that's probably what the user of the `Pool` would want to run. It also would make the behavior consistent with `concurrent.futures.ProcessPoolExecutor`, which will always wait for pending tasks to complete before exiting the `with` block. ---------- nosy: +dan.oreilly _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 17:08:21 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Apr 2015 15:08:21 +0000 Subject: [issue16669] Docstrings for namedtuple In-Reply-To: <1355333495.19.0.152758378027.issue16669@psf.upfronthosting.co.za> Message-ID: <1430147301.69.0.539126874108.issue16669@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- Removed message: http://bugs.python.org/msg242119 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 17:09:41 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Apr 2015 15:09:41 +0000 Subject: [issue16669] Docstrings for namedtuple In-Reply-To: <1355333495.19.0.152758378027.issue16669@psf.upfronthosting.co.za> Message-ID: <1430147381.08.0.866748632926.issue16669@psf.upfronthosting.co.za> Raymond Hettinger added the comment: The need for this may be eliminated by issue 24064. Then we change the docstrings just like any other object with no special rules or methods. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 17:24:11 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Apr 2015 15:24:11 +0000 Subject: [issue19543] Add -3 warnings for codec convenience method changes In-Reply-To: <1384075247.27.0.0100141647279.issue19543@psf.upfronthosting.co.za> Message-ID: <1430148251.67.0.414863557017.issue19543@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: I think we should just backport issue19619 and issue20404. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 17:26:04 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Apr 2015 15:26:04 +0000 Subject: [issue21354] PyCFunction_New no longer exposed by python DLL breaking bdist_wininst installers In-Reply-To: <1398499255.25.0.881446688113.issue21354@psf.upfronthosting.co.za> Message-ID: <1430148364.03.0.905115317027.issue21354@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- stage: needs patch -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 17:42:33 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Mon, 27 Apr 2015 15:42:33 +0000 Subject: [issue23910] C implementation of namedtuple (WIP) In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1430149353.11.0.352185735396.issue23910@psf.upfronthosting.co.za> Raymond Hettinger added the comment: What kind of speed improvement have you gotten? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 17:49:13 2015 From: report at bugs.python.org (STINNER Victor) Date: Mon, 27 Apr 2015 15:49:13 +0000 Subject: [issue22544] Inconsistent cmath.log behaviour In-Reply-To: <1412320697.54.0.866089400402.issue22544@psf.upfronthosting.co.za> Message-ID: <1430149753.62.0.960167884001.issue22544@psf.upfronthosting.co.za> Changes by STINNER Victor : ---------- nosy: -haypo _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 17:53:12 2015 From: report at bugs.python.org (Joe Jevnik) Date: Mon, 27 Apr 2015 15:53:12 +0000 Subject: [issue23910] C implementation of namedtuple (WIP) In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1430149992.74.0.601981430012.issue23910@psf.upfronthosting.co.za> Joe Jevnik added the comment: I am currently on a different machine so these numbers are not relative to the others posted earlier. * default ./python -m timeit -s "from collections import namedtuple as n;a = n('n', 'a b c')(1, 2, 3)" "a.a" 10000000 loops, best of 3: 0.0699 usec per loop * patch ./python -m timeit -s "from collections import namedtuple as n;a = n('n', 'a b c')(1, 2, 3)" "a.a" 10000000 loops, best of 3: 0.0468 usec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 18:47:30 2015 From: report at bugs.python.org (Thomas Kluyver) Date: Mon, 27 Apr 2015 16:47:30 +0000 Subject: [issue23955] Add python.ini file for embedded/applocal installs In-Reply-To: <1429038990.96.0.956334607163.issue23955@psf.upfronthosting.co.za> Message-ID: <1430153250.34.0.8279765618.issue23955@psf.upfronthosting.co.za> Thomas Kluyver added the comment: Would that option be the only thing that needs to be set to make Python app-local? I'm not familiar with what lives in pyvenv.cfg. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 18:56:38 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Apr 2015 16:56:38 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430153798.48.0.79274136579.issue24053@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > Those should be in the os module, not in sys. I disagree. The whole point of this proposal is to have platform-independent status codes available next to the sys.exit() function. We already have over a dozen BSDish exit codes in os that are hardly ever used. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 18:57:32 2015 From: report at bugs.python.org (Steve Dower) Date: Mon, 27 Apr 2015 16:57:32 +0000 Subject: [issue23955] Add python.ini file for embedded/applocal installs In-Reply-To: <1429038990.96.0.956334607163.issue23955@psf.upfronthosting.co.za> Message-ID: <1430153852.83.0.00577235373164.issue23955@psf.upfronthosting.co.za> Steve Dower added the comment: None of the other options really have much use in this case, since they're mostly about how to combine multiple environments rather than excluding implicit ones. Setting PYTHONHOME to the current directory certainly seems to be enough AFAICT, at least for Windows, as that bypasses the most problematic registry lookup. Having an "applocal" option means we can go further and ignore all registry keys and environment variables. I haven't looked into how to duplicate the behaviour on other OSs, but Modules/getpath.c looks similar enough to PC/getpathp.c that I guess it'll be similar. Adding the MacOS folks in case they have suggestions/concerns. ---------- nosy: +ned.deily, ronaldoussoren _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 19:02:43 2015 From: report at bugs.python.org (Davin Potts) Date: Mon, 27 Apr 2015 17:02:43 +0000 Subject: [issue21791] Proper return status of os.WNOHANG is not always (0, 0) In-Reply-To: <1403022188.82.0.702725813338.issue21791@psf.upfronthosting.co.za> Message-ID: <1430154163.16.0.527436485875.issue21791@psf.upfronthosting.co.za> Davin Potts added the comment: The man pages for waitpid on OpenBSD 5.x do not suggest any meaningful value will be returned in status when WNOHANG is requested and no child processes have anything to report. The following session attempts to exercise os.waitpid using Python 2.7.9 on an OpenBSD 5.3 i386 system: >>> import os >>> os.spawnl(os.P_NOWAIT, '/bin/sleep', 'sleep', '10') 19491 >>> os.waitpid(-1, os.WNOHANG) (0, 0) >>> os.waitpid(-1, os.WNOHANG) # wait a few seconds, try again (0, 0) >>> os.waitpid(-1, os.WNOHANG) # waited long enough for sleep to exit (19491, 0) >>> os.waitpid(-1, os.WNOHANG) # at this point, no children remain Traceback (most recent call last): File "", line 1, in OSError: [Errno 10] No child processes Can you provide any further information, like: * OpenBSD docs that explain that we should expect non-zero values for status coming from waitpid? * Example Python code to provoke the behavior originally described? * Other suggestion of why OpenBSD's waitpid, which itself depends upon wait4, when called (the way Python calls it) with an already initialized status=0 and WNOHANG should return a modified value for status when the child had nothing to report? ---------- nosy: +davin status: open -> pending _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 19:05:02 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 27 Apr 2015 17:05:02 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430154302.52.0.737771780839.issue24053@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > We already have over a dozen BSDish exit codes in os that are hardly > ever used. Then precisely, those new codes should go in the os module as well. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 19:18:55 2015 From: report at bugs.python.org (Ethan Furman) Date: Mon, 27 Apr 2015 17:18:55 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430155135.96.0.553911153074.issue24053@psf.upfronthosting.co.za> Ethan Furman added the comment: I agree with Antoine -- all the exit codes should be in one place. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 19:23:22 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Apr 2015 17:23:22 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430155402.93.0.150452794064.issue24053@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > Then precisely, those new codes should go in the os module as well. What is your logic? Having os.EX_ codes in os does not help as far as sys.exit() is concerned: no-one is using them and they are not available on all platforms. If we add EXIT_FAILURE and EXIT_SUCCESS to os now, we will only create confusion: should I use os.EX_OK or os.EXIT_SUCCESS? Note that sys.exit() is different from os._exit(). It may not even result in termination of the interpreter. Why should users of sys.exit() be required to import os if they want to indicate a failure? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 19:31:23 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 27 Apr 2015 17:31:23 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430155883.23.0.899434907092.issue24053@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well, my favourite answer would be use sys.exit(0) and sys.exit(1), respectively (or raise SystemExit without or with an error message), as everyone is already doing right now. Since I don't really get the usability argument of adding those constants, it's hard for me to buy that they should sit close to sys.exit(). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 19:35:46 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Apr 2015 17:35:46 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430156146.85.0.929456857786.issue24053@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Ethan> all the exit codes should be in one place. Do you realize that os.EX_* codes are not available on Windows? Having platform-independent EXIT_* codes next to posix-only EX_* codes will send the wrong message about their availability. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 19:40:19 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Apr 2015 17:40:19 +0000 Subject: [issue24065] Outdated *_RESTRICTED flags in structmember.h Message-ID: <1430156419.01.0.516849484938.issue24065@psf.upfronthosting.co.za> New submission from Berker Peksag: Looks like READ_RESTRICTED, PY_WRITE_RESTRICTED and RESTRICTED flags were used for "restricted mode" [1] in Python 2. "restricted mode" has been deprecated in Python 2.3. Also, the current documentation is outdated. WRITE_RESTRICTED is now PY_WRITE_RESTRICTED: https://docs.python.org/3/extending/newtypes.html#generic-attribute-management There are a few usages of these flags in the CPython source: PY_WRITE_RESTRICTED * Objects/funcobject.c * Objects/methodobject.c RESTRICTED * Objects/funcobject.c * Objects/classobject.c Are they still useful or can we deprecate/remove them now? [1] https://github.com/python/cpython/blob/2.7/Python/structmember.c#L180 ---------- components: Interpreter Core messages: 242134 nosy: berker.peksag priority: normal severity: normal status: open title: Outdated *_RESTRICTED flags in structmember.h type: enhancement versions: Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 19:43:01 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Apr 2015 17:43:01 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430156581.22.0.454219376925.issue24053@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Antoine> Since I don't really get the usability argument of adding those constants .. If I am alone in finding exit(EXIT_FAILURE) clearer than exit(1), I should certainly drop my proposal. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 19:43:20 2015 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 27 Apr 2015 17:43:20 +0000 Subject: [issue23749] asyncio missing wrap_socket In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za> Message-ID: <1430156600.34.0.866125144493.issue23749@psf.upfronthosting.co.za> Guido van Rossum added the comment: We didn't do this originally because the 3.4 SSL module didn't have this functionality (or maybe it was 3.3 that didn't have this) but now that we do have it I'd be very happy if you could implement this! I'm not sure what the right interface is, probably coroutine methods on StreamReader and StreamWriter that take an SSLContext object (and from then on the reader/writer is using SSL), but there also would have to be a lower-level way to do the same thing to a Transport. This would probably have to return a new Transport that uses the original, wrapped transport for reading/writing. You probably should write a small test app that proves this works for real too. Perhaps start with a synchronous test app that uses the existing wrap_socket() and then work on the async interface until you can reproduce the same thing there. Let us know if you need more information. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 19:45:03 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 27 Apr 2015 17:45:03 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430156703.13.0.7769996711.issue24053@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Well it would be clearer if not for the widely established knowledge (amongst most or all programming languages) that zero means success and non-zero means failure. So in this case I find it personally useless. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 19:47:07 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 27 Apr 2015 17:47:07 +0000 Subject: [issue24065] Outdated *_RESTRICTED flags in structmember.h In-Reply-To: <1430156419.01.0.516849484938.issue24065@psf.upfronthosting.co.za> Message-ID: <1430156827.44.0.616280575107.issue24065@psf.upfronthosting.co.za> Antoine Pitrou added the comment: +1 for deprecating them. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 19:47:39 2015 From: report at bugs.python.org (Stefan Krah) Date: Mon, 27 Apr 2015 17:47:39 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430156859.1.0.172288389288.issue24053@psf.upfronthosting.co.za> Stefan Krah added the comment: I'm +0 on adding these. The only reason is that I've seen academic code written by well-known researchers that used 1 for a successful exit. :) I'm not sure about the os module. These are C99 and not OS specific. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 19:53:07 2015 From: report at bugs.python.org (Tal Einat) Date: Mon, 27 Apr 2015 17:53:07 +0000 Subject: [issue24037] Argument Clinic: add the boolint converter In-Reply-To: <1429785188.86.0.806042190219.issue24037@psf.upfronthosting.co.za> Message-ID: <1430157187.69.0.962543386529.issue24037@psf.upfronthosting.co.za> Tal Einat added the comment: If I was writing a function/method with a conceptually boolean parameter (True/False), I wouldn't want that to accept any Python object. For example, I would want passing a tuple or list to raise a TypeError. But according to the docs[1], that's what the 'p' converter does. If Python had a separate boolean type, this would be simple, but bool is a subclass of int, and it is easy to get a 0 or a 1 instead of True or False without noticing. So it seems reasonable when using the C API to accept an int when you want to get a boolean. I'd want a converter to convert it to a C bool, of course. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 20:18:41 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Apr 2015 18:18:41 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430158721.99.0.516653424226.issue24053@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: Stefan> I've seen academic code written by well-known researchers Stefan> that used 1 for a successful exit. Thank you! What I've seen more than once was exit(True) to indicate success where True is not necessarily a literal, but something like len(results) > 0. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 20:27:42 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Apr 2015 18:27:42 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430159262.84.0.187910433847.issue24053@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: This can be implemented as separate module on PyPI. No need to add these aliases for 0 and 1 to the stdlib. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 20:36:28 2015 From: report at bugs.python.org (Ethan Furman) Date: Mon, 27 Apr 2015 18:36:28 +0000 Subject: [issue24064] Make the property doctstring writeable In-Reply-To: <1430110387.37.0.412217606886.issue24064@psf.upfronthosting.co.za> Message-ID: <1430159788.69.0.202127236515.issue24064@psf.upfronthosting.co.za> Changes by Ethan Furman : ---------- nosy: +ethan.furman _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 20:46:48 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Apr 2015 18:46:48 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430160408.35.0.0396066017723.issue24053@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > This can be implemented as separate module on PyPI. Sure! Make them even less discoverable! Let me try to state my motivations for adding these constants: 1. I find exit(EXIT_FAILURE) much clearer than exit(1). 2. I want people to standardize on status=1 for a generic failure code. I do see exit(-1) used as often as exit(1). 3. I want discourage people from using computed integer results as exit status. For example, # process files and store errors in a list sys.exit(len(errors)) # bad - success for multiples of 256 errors sys.exit(sys.EXIT_SUCCESS if not errors else sys.EXIT_FAILURE) # good ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 20:50:57 2015 From: report at bugs.python.org (Ethan Furman) Date: Mon, 27 Apr 2015 18:50:57 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430160657.04.0.968291538854.issue24053@psf.upfronthosting.co.za> Ethan Furman added the comment: An entire PyPI module for two constants? Change of heart, I'm okay with them going in sys, but only +0 on adding them. This SO answer* has an interesting point to make about the nature of return codes and what their values should be; tl;dr - the convention should be between your program and the other program(s) you are trying communicate with. * http://stackoverflow.com/a/8869000/208880 ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 20:56:13 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Apr 2015 18:56:13 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430160973.3.0.468130783271.issue24053@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > the convention should be between your program and the other program(s) you are trying communicate with. This may be true in general, but Python stdlib sets the convention in its subprocess.check_call and subprocess.check_output methods. These methods use 0=success convention. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 21:02:14 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 27 Apr 2015 19:02:14 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430161334.13.0.213021883262.issue24053@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > I want people to standardize on status=1 for a generic failure code. Why that? Multiple error codes can be used by the same program, depending on the kind of error. > I want discourage people from using computed integer results as exit status. Ok, that's the first good argument for this feature. Although I would encourage people raise an exception if they want to signify a failure, rather than simply change the error code. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 21:07:22 2015 From: report at bugs.python.org (Berker Peksag) Date: Mon, 27 Apr 2015 19:07:22 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430161642.69.0.310796632328.issue24053@psf.upfronthosting.co.za> Berker Peksag added the comment: > 1. I find exit(EXIT_FAILURE) much clearer than exit(1). import sys exit(sys.EXIT_FAILURE) or import sys sys.exit(sys.EXIT_FAILURE) don't look too clear to me. On the other hand, these constants may helpful to people who came from C world. > 3. I want discourage people from using computed integer results as exit status. Adding a FAQ entry or updating sys.exit() documentation would be more suitable to achieve the aim of this item. I wouldn't add two constants to the stdlib because of a bad programming practice. ---------- nosy: +berker.peksag _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 21:16:13 2015 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 27 Apr 2015 19:16:13 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430162173.36.0.0668989172134.issue24053@psf.upfronthosting.co.za> Stefan Behnel added the comment: why not spell them "sys.exit.FAILURE" and "sys.exit.SUCCESS" ? ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 21:17:24 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Apr 2015 19:17:24 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430162244.5.0.0273251874899.issue24053@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: >> I want people to standardize on status=1 for a generic failure code. > Why that? Multiple error codes can be used by the same program, depending on the kind of error. Antoine, please read what I write carefully before disagreeing. I want "to standardize on status=1 for a **generic** failure code". Cooperating processes can certainly agree on other values for the specific failure modes. What I really want to avoid is the use of -1 as a generic failure code, because it leads to a rather common error rc = subprocess.call(..) if rc < 0: raise Error # never reached! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 21:19:39 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Mon, 27 Apr 2015 19:19:39 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430162379.28.0.591015214585.issue24053@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: How often you see EXIT_SUCCESS and EXIT_FAILURE in C code besides GNU tools that should support VMS? And even GNU tools usually use multiple error codes for different kinds of errors. I think that these constants are rather unusual for C programmers. I'm only -0 on adding these constants, not -1, because I'm sure they will be never used. But this will add a burden on the documentation and will confuse inexperienced users when they unexpectedly encounter with sys.exit(sys.EXIT_FAILURE) instead of sys.exit(1). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 21:23:53 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Apr 2015 19:23:53 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430162633.59.0.920725470317.issue24053@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > And even GNU tools usually use multiple error codes for different kinds of errors. And how often do they not give them symbolic names? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 21:32:26 2015 From: report at bugs.python.org (Stefan Behnel) Date: Mon, 27 Apr 2015 19:32:26 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430163146.24.0.9869066384.issue24053@psf.upfronthosting.co.za> Stefan Behnel added the comment: Actually, my guess is also that these constants will not be used. Not because they are not helpful, but because they'd only be available in Python 3.5+. Meaning that if you use them, your code won't work with long time supported CPython versions like 3.4 for the next decade or so. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 21:35:10 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Apr 2015 19:35:10 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430163310.22.0.83235122043.issue24053@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > will confuse inexperienced users when they unexpectedly encounter with sys.exit(sys.EXIT_FAILURE) instead of sys.exit(1). Are you serious? I've seen senior programmers who thought that status < 0 means failure and status >= 0 means success. Why would anyone who understands English would need to know what the numerical value of EXIT_FAILURE is to understand that status=EXIT_FAILURE means "failure"? Not to mention that google returns a pageful of relevant links for "EXIT_FAILURE". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 21:52:07 2015 From: report at bugs.python.org (Guido van Rossum) Date: Mon, 27 Apr 2015 19:52:07 +0000 Subject: [issue24017] Implemenation of the PEP 492 - Coroutines with async and await syntax In-Reply-To: <1429559138.56.0.765116266018.issue24017@psf.upfronthosting.co.za> Message-ID: <1430164327.65.0.657351674658.issue24017@psf.upfronthosting.co.za> Changes by Guido van Rossum : ---------- nosy: +gvanrossum _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 21:55:47 2015 From: report at bugs.python.org (Alexander Belopolsky) Date: Mon, 27 Apr 2015 19:55:47 +0000 Subject: [issue24053] Define EXIT_SUCCESS and EXIT_FAILURE constants in sys In-Reply-To: <1429890469.94.0.27310602141.issue24053@psf.upfronthosting.co.za> Message-ID: <1430164547.91.0.604146912372.issue24053@psf.upfronthosting.co.za> Alexander Belopolsky added the comment: > if you use them, your code won't work with long time > supported CPython versions like 3.4 for the next decade or so. This would be a generic argument against any new feature. I don't think it is very compelling in this case. For people who develop on a latest version. these constants will pop up in sys. autocompletion and they will likely use them. If they need to support pre-3.5 versions, try: from sys import exit, EXIT_FAILURE except ImportError: from sys import exit EXIT_FAILURE = 1 is not a hard work-around. You would say, why not just use EXIT_FAILURE = 1 to begin with? To avoid Bob using EXIT_FAILURE = -1, Alice using EX_FAIL = 1 and Karl giving up and using exit(1) in perpetuity. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 22:10:08 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Mon, 27 Apr 2015 20:10:08 +0000 Subject: [issue23749] asyncio missing wrap_socket In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za> Message-ID: <1430165408.88.0.557404521916.issue23749@psf.upfronthosting.co.za> Antoine Pitrou added the comment: So you need to: - have an API to wrap a clear-text protocol in a SSL protocol (see e.g. BaseProactorEventLoop._make_ssl_transport()... note how there's a waiter argument, what should be done with that?) - be able to replace a protocol with another on the transport (perhaps using a new, optional Transport API?) - perhaps a higher-level API that combines the two Also for convenience a protocol should probably be able to inspect whether it has *already* been wrapped. ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 22:12:13 2015 From: report at bugs.python.org (Krasimir) Date: Mon, 27 Apr 2015 20:12:13 +0000 Subject: [issue20210] Provide configure options to enable/disable Python modules and extensions In-Reply-To: <1389307962.8.0.973949637829.issue20210@psf.upfronthosting.co.za> Message-ID: <1430165533.96.0.997800699586.issue20210@psf.upfronthosting.co.za> Krasimir added the comment: @Thomas: Thank you for the patches! Adding more flexibility to the build system that allows for cross-compiling and building "embeddable/distributable" python is definitely something that needs to be done is my opinion. So I definitely find your work very valuable to me. I admit that I use all patches, related to feature configuration from http://git.buildroot.net/buildroot/tree/package/python Thank you and keep up the great work! I'm positive about the direction that a flexibility/configurability should be in place, especially when talking for such a mature project. ---------- nosy: +krasimir_vanev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 22:53:51 2015 From: report at bugs.python.org (Steve Dougherty) Date: Mon, 27 Apr 2015 20:53:51 +0000 Subject: [issue11205] Evaluation order of dictionary display is different from reference manual. In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za> Message-ID: <1430168031.84.0.0862274041135.issue11205@psf.upfronthosting.co.za> Steve Dougherty added the comment: I've added a patch to change the order of evaluation and of STORE_MAP's arguments. It includes a test incorporating the review on the previous version. I noticed I had to remove existing .pyc files to avoid TypeErrors about values being unhashable. I take it the version numbers in the filenames are sufficient to prevent that problem in a release? ---------- Added file: http://bugs.python.org/file39218/issue11205.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 23:26:12 2015 From: report at bugs.python.org (Kirill Elagin) Date: Mon, 27 Apr 2015 21:26:12 +0000 Subject: [issue24066] send_message should take all the addresses in the To: header into account Message-ID: <1430169972.74.0.338342255395.issue24066@psf.upfronthosting.co.za> New submission from Kirill Elagin: If I have a message with multiple `To` headers and I send it using `send_message` not specifying `to_addrs`, the message gets sent only to one of the recipients. I?m attaching my patch that makes it send to _all_ the addresses listed in `To`, `Cc` and `Bcc`. I didn?t add any new tests as the existing ones already cover those cases and I have no idea how on Earth do they pass. ---------- components: Library (Lib) messages: 242158 nosy: kirelagin priority: normal severity: normal status: open title: send_message should take all the addresses in the To: header into account _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Mon Apr 27 23:42:46 2015 From: report at bugs.python.org (Eyal Reuveni) Date: Mon, 27 Apr 2015 21:42:46 +0000 Subject: [issue24067] Weakproxy is an instance of collections.Iterator Message-ID: <1430170966.34.0.831827810985.issue24067@psf.upfronthosting.co.za> New submission from Eyal Reuveni: Calling weakref.proxy() on an object returns something that is an instance of collections.Iterator, regardless of whether the object is an instance of collections.Iterator or even if the object itself is iterable. To reproduce, run the following code (verified in python2.7 and 3.4 on my Mac): import collections import weakref class NotIterator: pass not_iterator = NotIterator() isinstance(not_iterator, collections.Iterator) # returns False proxy_object = weakref.proxy(not_iterator) isinstance(proxy_object, collections.Iterator) # returns True, should be False ---------- components: Library (Lib) messages: 242159 nosy: ereuveni priority: normal severity: normal status: open title: Weakproxy is an instance of collections.Iterator type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 00:35:53 2015 From: report at bugs.python.org (Eric Snow) Date: Mon, 27 Apr 2015 22:35:53 +0000 Subject: [issue23911] Move path-based bootstrap code to a separate frozen file. In-Reply-To: <1428715778.23.0.540970510492.issue23911@psf.upfronthosting.co.za> Message-ID: <1430174153.25.0.266283474686.issue23911@psf.upfronthosting.co.za> Eric Snow added the comment: Glad to hear the patch is conceptually consistent with other components. :) And the "internal"/"external" suggestion is a good one. I'll update the patch when I have a minute. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 01:37:09 2015 From: report at bugs.python.org (Nick Coghlan) Date: Mon, 27 Apr 2015 23:37:09 +0000 Subject: [issue11205] Evaluation order of dictionary display is different from reference manual. In-Reply-To: <1430168031.84.0.0862274041135.issue11205@psf.upfronthosting.co.za> Message-ID: Nick Coghlan added the comment: The pyc issue suggests the magic number embedded in pyc files to indicate bytecode compatibility needs to be incremented. If I recall correctly, that lives in Lib/importlib/_bootstrap.py these days. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 03:38:05 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 28 Apr 2015 01:38:05 +0000 Subject: [issue15064] Use context manager protocol for more multiprocessing types In-Reply-To: <1339676025.91.0.9899325094.issue15064@psf.upfronthosting.co.za> Message-ID: <1430185085.93.0.777560136351.issue15064@psf.upfronthosting.co.za> Ned Deily added the comment: Dan, this issue was closed and the code associated with it released a few years ago. Comments here will likely be ignored. If you want to pursue your suggestion, please open a new issue for it. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 03:44:05 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 28 Apr 2015 01:44:05 +0000 Subject: [issue24066] send_message should take all the addresses in the To: header into account In-Reply-To: <1430169972.74.0.338342255395.issue24066@psf.upfronthosting.co.za> Message-ID: <1430185445.42.0.676429023761.issue24066@psf.upfronthosting.co.za> Ned Deily added the comment: Kirill, the patch is missing. ---------- nosy: +ned.deily _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 03:54:51 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 28 Apr 2015 01:54:51 +0000 Subject: [issue24067] Weakproxy is an instance of collections.Iterator In-Reply-To: <1430170966.34.0.831827810985.issue24067@psf.upfronthosting.co.za> Message-ID: <1430186091.44.0.470350348523.issue24067@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +fdrake, pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 04:46:22 2015 From: report at bugs.python.org (Davin Potts) Date: Tue, 28 Apr 2015 02:46:22 +0000 Subject: [issue21345] multiprocessing.Pool._handle_workers sleeps too long In-Reply-To: <1398355364.53.0.447682013962.issue21345@psf.upfronthosting.co.za> Message-ID: <1430189182.67.0.801747447735.issue21345@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 04:48:00 2015 From: report at bugs.python.org (Davin Potts) Date: Tue, 28 Apr 2015 02:48:00 +0000 Subject: [issue9782] _multiprocessing.c warnings under 64-bit Windows In-Reply-To: <1283776985.14.0.464453735202.issue9782@psf.upfronthosting.co.za> Message-ID: <1430189280.88.0.0777155970452.issue9782@psf.upfronthosting.co.za> Changes by Davin Potts : ---------- nosy: +davin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 04:59:23 2015 From: report at bugs.python.org (Mark Lawrence) Date: Tue, 28 Apr 2015 02:59:23 +0000 Subject: [issue16620] Avoid using private function glob.glob1() in msi module and tools In-Reply-To: <1354736049.23.0.98660459286.issue16620@psf.upfronthosting.co.za> Message-ID: <1430189963.15.0.898169245965.issue16620@psf.upfronthosting.co.za> Changes by Mark Lawrence : ---------- nosy: +steve.dower _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 06:22:07 2015 From: report at bugs.python.org (Chris Angelico) Date: Tue, 28 Apr 2015 04:22:07 +0000 Subject: [issue23614] Opaque error message on UTF-8 decoding to surrogates In-Reply-To: <1425850595.48.0.491367645605.issue23614@psf.upfronthosting.co.za> Message-ID: <1430194927.95.0.357424840141.issue23614@psf.upfronthosting.co.za> Chris Angelico added the comment: Got around to tracking down where this is actually being done. It's in Objects/stringlib/codecs.h and it looks to be a hot area for optimization. I don't want to fiddle with it without knowing a lot about the performance implications (UTF-8 encode/decode being a pretty common operation), and since my knowledge of CPU operation costs is about fifteen or twenty years out of date, it's probably best I not do this. It would be nice if the message could be improved per Ezio's suggestion, but that would mean returning more information to the caller. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 07:03:47 2015 From: report at bugs.python.org (Adam) Date: Tue, 28 Apr 2015 05:03:47 +0000 Subject: [issue17908] Unittest runner needs an option to call gc.collect() after each test In-Reply-To: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za> Message-ID: <1430197427.47.0.159307266245.issue17908@psf.upfronthosting.co.za> Adam added the comment: Is this enhancement still open? I've run into this problem previously, and would be more than happy to implement this feature. ---------- nosy: +azsorkin _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 07:07:44 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 28 Apr 2015 05:07:44 +0000 Subject: [issue17908] Unittest runner needs an option to call gc.collect() after each test In-Reply-To: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za> Message-ID: <1430197664.03.0.31129860677.issue17908@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +rbcollins _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 07:20:00 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 28 Apr 2015 05:20:00 +0000 Subject: [issue17908] Unittest runner needs an option to call gc.collect() after each test In-Reply-To: <1430197664.08.0.676227364345.issue17908@psf.upfronthosting.co.za> Message-ID: Guido van Rossum added the comment: Does the cpython test runner have this? Might be nice there. Not sure if the default test runner is something to extend at this point. Eveybody is using py.test anyway... On Monday, April 27, 2015, Ned Deily wrote: > > Changes by Ned Deily >: > > > ---------- > nosy: +rbcollins > > _______________________________________ > Python tracker > > > _______________________________________ > ---------- title: Unittest runner needs an option to call gc.collect() after each test -> Unittest runner needs an option to call gc.collect() after each test _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 08:35:11 2015 From: report at bugs.python.org (Kirill Elagin) Date: Tue, 28 Apr 2015 06:35:11 +0000 Subject: [issue24066] send_message should take all the addresses in the To: header into account In-Reply-To: <1430169972.74.0.338342255395.issue24066@psf.upfronthosting.co.za> Message-ID: <1430202911.22.0.0545193095274.issue24066@psf.upfronthosting.co.za> Kirill Elagin added the comment: x_x ---------- keywords: +patch Added file: http://bugs.python.org/file39219/multiple_to.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 08:47:47 2015 From: report at bugs.python.org (Ned Deily) Date: Tue, 28 Apr 2015 06:47:47 +0000 Subject: [issue24066] send_message should take all the addresses in the To: header into account In-Reply-To: <1430169972.74.0.338342255395.issue24066@psf.upfronthosting.co.za> Message-ID: <1430203667.29.0.319264145151.issue24066@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +barry, r.david.murray -ned.deily stage: -> patch review versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 09:33:18 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 28 Apr 2015 07:33:18 +0000 Subject: [issue17908] Unittest runner needs an option to call gc.collect() after each test In-Reply-To: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za> Message-ID: <1430206398.03.0.308689262976.issue17908@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I still think that it's something that people can trivially implement and that has no place in the standard unittest package. ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 10:53:26 2015 From: report at bugs.python.org (Wolfgang Maier) Date: Tue, 28 Apr 2015 08:53:26 +0000 Subject: [issue24068] statistics module - incorrect results with boolean input Message-ID: <1430211206.61.0.689765465928.issue24068@psf.upfronthosting.co.za> New submission from Wolfgang Maier: the mean function in the statistics module gives nonsensical results with boolean values in the input, e.g.: >>> mean([True, True, False, False]) 0.25 >>> mean([True, 1027]) 0.5 This is an issue with the module's internal _sum function that mean relies on. Other functions relying on _sum are affected more subtly, e.g.: >>> variance([1, 1027, 0]) 351234.3333333333 >>> variance([True, 1027, 0]) 351234.3333333334 The problem with _sum is that it will try to coerce its result to any non-int type found in the input (so bool in the examples), but bool(1028) is just True so information gets lost. I've attached a patch preventing the type cast when it would be to bool. I don't have time to write a separate test though so if somebody wants to take over .. :) ---------- components: Library (Lib) files: statistics._sum.patch keywords: patch messages: 242169 nosy: steven.daprano, wolma priority: normal severity: normal status: open title: statistics module - incorrect results with boolean input type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39220/statistics._sum.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 10:54:54 2015 From: report at bugs.python.org (Wolfgang Maier) Date: Tue, 28 Apr 2015 08:54:54 +0000 Subject: [issue24068] statistics module - incorrect results with boolean input In-Reply-To: <1430211206.61.0.689765465928.issue24068@psf.upfronthosting.co.za> Message-ID: <1430211294.9.0.727377901609.issue24068@psf.upfronthosting.co.za> Changes by Wolfgang Maier : Removed file: http://bugs.python.org/file39220/statistics._sum.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 10:56:15 2015 From: report at bugs.python.org (Wolfgang Maier) Date: Tue, 28 Apr 2015 08:56:15 +0000 Subject: [issue24068] statistics module - incorrect results with boolean input In-Reply-To: <1430211206.61.0.689765465928.issue24068@psf.upfronthosting.co.za> Message-ID: <1430211375.17.0.212985132441.issue24068@psf.upfronthosting.co.za> Changes by Wolfgang Maier : Added file: http://bugs.python.org/file39221/statistics._sum.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 11:28:54 2015 From: report at bugs.python.org (Alex Shkop) Date: Tue, 28 Apr 2015 09:28:54 +0000 Subject: [issue23882] unittest discovery doesn't detect namespace packages when given no parameters In-Reply-To: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za> Message-ID: <1430213334.42.0.449982006488.issue23882@psf.upfronthosting.co.za> Alex Shkop added the comment: I'm still not sure which solution is the best. So I attach two simple patches. First one enables full recursive scan of start_dir for namespace packages. Second one loads tests only from top level namespace packages. ---------- keywords: +patch Added file: http://bugs.python.org/file39222/issue23882_find_all.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 11:29:03 2015 From: report at bugs.python.org (Alex Shkop) Date: Tue, 28 Apr 2015 09:29:03 +0000 Subject: [issue23882] unittest discovery doesn't detect namespace packages when given no parameters In-Reply-To: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za> Message-ID: <1430213343.53.0.113577012706.issue23882@psf.upfronthosting.co.za> Changes by Alex Shkop : Added file: http://bugs.python.org/file39223/issue23882_find_one_level.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 11:55:00 2015 From: report at bugs.python.org (Alex Shkop) Date: Tue, 28 Apr 2015 09:55:00 +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: <1430214900.53.0.00213855909394.issue18383@psf.upfronthosting.co.za> Alex Shkop added the comment: *ping* ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 12:00:53 2015 From: report at bugs.python.org (Gareth Rees) Date: Tue, 28 Apr 2015 10:00:53 +0000 Subject: [issue24067] Weakproxy is an instance of collections.Iterator In-Reply-To: <1430170966.34.0.831827810985.issue24067@psf.upfronthosting.co.za> Message-ID: <1430215253.71.0.855664445293.issue24067@psf.upfronthosting.co.za> Gareth Rees added the comment: Not just Iterator, but Container, Hashable, Iterable, and Sized too! >>> import weakref >>> class C: pass >>> o = C() >>> w = weakref.proxy(o) >>> from collections.abc import * >>> isinstance(w, Container) True >>> isinstance(w, Hashable) True >>> isinstance(w, Iterable) True >>> isinstance(w, Sized) True ---------- nosy: +Gareth.Rees _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 12:06:35 2015 From: report at bugs.python.org (Drekin) Date: Tue, 28 Apr 2015 10:06:35 +0000 Subject: [issue17620] Python interactive console doesn't use sys.stdin for input In-Reply-To: <1364921954.86.0.527255608282.issue17620@psf.upfronthosting.co.za> Message-ID: <1430215595.33.0.83872796882.issue17620@psf.upfronthosting.co.za> Drekin added the comment: Note that under status quo PyOS_Readline is called from two places: the tokenizer during an interactive session and the builtin function input. The tokenizer passes promptstring encoded in sys.stdin.encoding while input() passes promtstring encoded in sys.stdout.encoding, so it is not possible to implement a readline hook correctly in the case the encodings are different. This might be considered a bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 12:14:21 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 28 Apr 2015 10:14:21 +0000 Subject: [issue24067] Weakproxy is an instance of collections.Iterator In-Reply-To: <1430170966.34.0.831827810985.issue24067@psf.upfronthosting.co.za> Message-ID: <1430216061.31.0.467897422987.issue24067@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Those methods are defined precisely so that they can be delegated. Since virtually anything can be proxied, the weakref.proxy *class* cannot tell upfront whether the proxied object will be an Iterator or not. I don't really see how to get around that. ---------- nosy: +benjamin.peterson, gvanrossum versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 13:08:30 2015 From: report at bugs.python.org (Gareth Rees) Date: Tue, 28 Apr 2015 11:08:30 +0000 Subject: [issue24067] Weakproxy is an instance of collections.Iterator In-Reply-To: <1430170966.34.0.831827810985.issue24067@psf.upfronthosting.co.za> Message-ID: <1430219310.42.0.107838037232.issue24067@psf.upfronthosting.co.za> Gareth Rees added the comment: Hashable is particularly misleading, because "weakref.Proxy objects are not hashable regardless of the referent". ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 13:29:17 2015 From: report at bugs.python.org (Berker Peksag) Date: Tue, 28 Apr 2015 11:29:17 +0000 Subject: [issue24056] Expose closure & generator status in function repr() In-Reply-To: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za> Message-ID: <1430220557.12.0.333990097727.issue24056@psf.upfronthosting.co.za> Berker Peksag added the comment: Here is a patch with a test. ---------- components: +Interpreter Core keywords: +patch nosy: +berker.peksag stage: needs patch -> patch review Added file: http://bugs.python.org/file39224/issue24056.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 13:38:41 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 28 Apr 2015 11:38:41 +0000 Subject: [issue24067] Weakproxy is an instance of collections.Iterator In-Reply-To: <1430170966.34.0.831827810985.issue24067@psf.upfronthosting.co.za> Message-ID: <1430221121.62.0.950479342972.issue24067@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > weakref.Proxy objects are not hashable regardless of the referent Interesting. @fdrake, do you remember why that is? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 13:42:46 2015 From: report at bugs.python.org (Gareth Rees) Date: Tue, 28 Apr 2015 11:42:46 +0000 Subject: [issue24067] Weakproxy is an instance of collections.Iterator In-Reply-To: <1430170966.34.0.831827810985.issue24067@psf.upfronthosting.co.za> Message-ID: <1430221366.62.0.437252097586.issue24067@psf.upfronthosting.co.za> Gareth Rees added the comment: The documentation says that weakref.Proxy objects are not hashable because "this avoids a number of problems related to their fundamentally mutable nature, and prevent their use as dictionary keys". Hashable objects must be immutable, otherwise the hash might change, invalidating the invariants that make dictionaries work, but Proxy objects are fundamentally mutable: when there are no more strong references to the proxied object, the object gets destroyed and the Proxy object now refers to None. If the Proxy object were hashable then its hash would change at this point. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 13:50:31 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 28 Apr 2015 11:50:31 +0000 Subject: [issue24067] Weakproxy is an instance of collections.Iterator In-Reply-To: <1430170966.34.0.831827810985.issue24067@psf.upfronthosting.co.za> Message-ID: <1430221831.91.0.689261625691.issue24067@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Still, weakref.ref objects are hashable, so I don't understand why weakref.proxy would be different. Hashability of weakref.ref has been added in 29aa832b8787, to support weak dictionaries. See issue403985. It simply wasn't discussed whether to also add hashability to proxy objects. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 13:54:38 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 28 Apr 2015 11:54:38 +0000 Subject: [issue24067] Weakproxy is an instance of collections.Iterator In-Reply-To: <1430170966.34.0.831827810985.issue24067@psf.upfronthosting.co.za> Message-ID: <1430222078.22.0.870335644966.issue24067@psf.upfronthosting.co.za> Antoine Pitrou added the comment: Ok, PEP 205 explains it a bit more: "the resulting proxy cannot be used as a dictionary key since it cannot be compared once the referent has expired, and comparability is necessary for dictionary keys. Operations on proxy objects after the referent dies cause weakref.ReferenceError to be raised in most cases." Perhaps this can be relaxed, and comparison simply made to return false. The following behaviour is a bit troubling :-) >>> p >>> p == p Traceback (most recent call last): File "", line 1, in ReferenceError: weakly-referenced object no longer exists ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 14:37:16 2015 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Tue, 28 Apr 2015 12:37:16 +0000 Subject: [issue24067] Weakproxy is an instance of collections.Iterator In-Reply-To: <1430170966.34.0.831827810985.issue24067@psf.upfronthosting.co.za> Message-ID: <1430224636.54.0.864553757056.issue24067@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: I don't see any reason for proxy objects to be less hashable than ref objects. As for the p == p case, where the referent has expired, returning True if p is p seems acceptable (along with False inequalities, and True for other comparisons allowing equality), but anything beyond that seems unwise. Not sure whether that would really be enough to help real use cases. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 14:54:51 2015 From: report at bugs.python.org (Gareth Rees) Date: Tue, 28 Apr 2015 12:54:51 +0000 Subject: [issue24067] Weakproxy is an instance of collections.Iterator In-Reply-To: <1430170966.34.0.831827810985.issue24067@psf.upfronthosting.co.za> Message-ID: <1430225691.71.0.483222803798.issue24067@psf.upfronthosting.co.za> Gareth Rees added the comment: > I don't see any reason for proxy objects to be less hashable than ref objects. The difference is that unlike a ref object, a proxy object is supposed to forward its method calls to the proxied object. So consider what happens if you forward the __hash__ method to the proxied object: the hash will change when the object dies. A proxy object could, of course, not forward the __hash__ method, instead computing its own hash. But I think this would do more harm than good: surely most attempts to store weakref.Proxy objects in sets or dictionaries are going to be mistakes -- the user should have used a WeakKeyDictionary or a WeakSet instead. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 16:02:38 2015 From: report at bugs.python.org (Steve Dougherty) Date: Tue, 28 Apr 2015 14:02:38 +0000 Subject: [issue11205] Evaluation order of dictionary display is different from reference manual. In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za> Message-ID: <1430229758.18.0.525258787694.issue11205@psf.upfronthosting.co.za> Steve Dougherty added the comment: I've added a change to the bytecode magic number as well. I don't see a magic tag anymore, either in the code or for recent versions. There are autogenerated changes to Python/importlibs.h. Is my understanding correct that these are not to be committed? ---------- Added file: http://bugs.python.org/file39225/issue11205-v2.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 16:06:26 2015 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Tue, 28 Apr 2015 14:06:26 +0000 Subject: [issue24067] Weakproxy is an instance of collections.Iterator In-Reply-To: <1430170966.34.0.831827810985.issue24067@psf.upfronthosting.co.za> Message-ID: <1430229986.39.0.0980502437803.issue24067@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: Clearly I've been away from this code for a long time. The hash support for ref objects is definitely a very special case, only intended to support WeakKeyDictionary. We that class implemented in C, we'd probably want the hash support for refs not to be exposed. You've convinced me hashability for proxies isn't desirable. Let's stick with the status quo on this. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 16:27:11 2015 From: report at bugs.python.org (Mark Dickinson) Date: Tue, 28 Apr 2015 14:27:11 +0000 Subject: [issue24056] Expose closure & generator status in function repr() In-Reply-To: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za> Message-ID: <1430231231.72.0.204972998047.issue24056@psf.upfronthosting.co.za> Mark Dickinson added the comment: I can see that the `generator` information would be useful. What's the use-case for reporting that a function is a closure? I'm having trouble thinking of a case where it's useful to know that a function is a closure without also knowing which locals refer to cells. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 16:34:19 2015 From: report at bugs.python.org (Andrew Svetlov) Date: Tue, 28 Apr 2015 14:34:19 +0000 Subject: [issue23749] asyncio missing wrap_socket In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za> Message-ID: <1430231659.19.0.260608473571.issue23749@psf.upfronthosting.co.za> Changes by Andrew Svetlov : ---------- nosy: +asvetlov stage: -> needs patch versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 16:36:39 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 28 Apr 2015 14:36:39 +0000 Subject: [issue24067] Weakproxy is an instance of collections.Iterator In-Reply-To: <1430170966.34.0.831827810985.issue24067@psf.upfronthosting.co.za> Message-ID: <1430231799.16.0.0605121092512.issue24067@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > So consider what happens if you forward the __hash__ method to the > proxied object: the hash will change when the object dies. ref objects behave differently: they inherit their referent's hash value when alive, and remember it. proxy objects could be made to behave the same way. > The hash support for ref objects is definitely a very special case, > only intended to support WeakKeyDictionary I've relied several times on the hashability of ref objects, in third-party code. (OTOH, I never use weakref proxies) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 16:50:36 2015 From: report at bugs.python.org (Fred L. Drake, Jr.) Date: Tue, 28 Apr 2015 14:50:36 +0000 Subject: [issue24067] Weakproxy is an instance of collections.Iterator In-Reply-To: <1430170966.34.0.831827810985.issue24067@psf.upfronthosting.co.za> Message-ID: <1430232636.8.0.409401722752.issue24067@psf.upfronthosting.co.za> Fred L. Drake, Jr. added the comment: > ref objects behave differently: they inherit their referent's hash > value when alive, and remember it. proxy objects could be made to > behave the same way. They could, yes, but that would break the proxy behavior, and the hash <--> equality behavior for mutable objects. In particular, mutable objects can become equal; if the hashes were computed for the proxies before that happened, the hashes would be inappropriate later. That's pretty important. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 16:53:30 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 28 Apr 2015 14:53:30 +0000 Subject: [issue23699] Add a macro to ease writing rich comparisons In-Reply-To: <1426686202.27.0.781464549576.issue23699@psf.upfronthosting.co.za> Message-ID: <1430232810.03.0.586739882396.issue23699@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 18:13:19 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Apr 2015 16:13:19 +0000 Subject: [issue19543] Add -3 warnings for codec convenience method changes In-Reply-To: <1384075247.27.0.0100141647279.issue19543@psf.upfronthosting.co.za> Message-ID: <1430237599.49.0.62607247958.issue19543@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Here is a patch that backports issue19619 and issue20404 with changing an exception to Py3k warning, and makes necessary changes in other modules and tests. $ ./python -3 Python 2.7.10rc0 (2.7:4234b0dd2a54+, Apr 28 2015, 16:51:51) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 'abcd'.decode('hex') __main__:1: DeprecationWarning: 'hex' is not a text encoding; use codecs.decode() to handle arbitrary codecs '\xab\xcd' ---------- Added file: http://bugs.python.org/file39226/issue19543_blacklist_transforms_py27.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 18:44:19 2015 From: report at bugs.python.org (Sworddragon) Date: Tue, 28 Apr 2015 16:44:19 +0000 Subject: [issue24069] Option to delete obsolete bytecode files Message-ID: <1430239459.0.0.172566043873.issue24069@psf.upfronthosting.co.za> New submission from Sworddragon: The library compileall has the option -f to force the rebuilding of the bytecode files so I thought maybe there could also be an option to delete all bytecode files which haven't a non-bytecode library anymore. ---------- components: Library (Lib) messages: 242189 nosy: Sworddragon priority: normal severity: normal status: open title: Option to delete obsolete bytecode files type: enhancement versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 18:53:17 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 28 Apr 2015 16:53:17 +0000 Subject: [issue17908] Unittest runner needs an option to call gc.collect() after each test In-Reply-To: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za> Message-ID: <1430239997.76.0.61092121759.issue17908@psf.upfronthosting.co.za> Guido van Rossum added the comment: It's trivial to add to a single test or even a single TestCase subclass, yes. The use case is more that you have a ton of tests and you suspect there's a problem due to GC. Being able to call gc.collect() after each test through the flip of a flag would be useful. But I agree it's iffy whether this belongs in the unittest package; we could add it to the CPython run_tests.py script, or you could request this as a feature from py.test. If someone wants to add this to run_tests.py I think this issue would be the place to review the patch. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 19:30:40 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Apr 2015 17:30:40 +0000 Subject: [issue17908] Unittest runner needs an option to call gc.collect() after each test In-Reply-To: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za> Message-ID: <1430242240.91.0.933916405532.issue17908@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: See also issue23839 where proposed not only call gc.collect(), but clear all caches in test.regrtest. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 19:57:25 2015 From: report at bugs.python.org (Roy Hyunjin Han) Date: Tue, 28 Apr 2015 17:57:25 +0000 Subject: [issue24070] Exceptions and arguments disappear when using argparse inside with statement Message-ID: <1430243845.68.0.464856289952.issue24070@psf.upfronthosting.co.za> New submission from Roy Hyunjin Han: Exceptions and arguments disappear when using argparse inside a "with" statement. The behavior was confusing and frustrating because I could not pinpoint why certain arguments were missing or unrecognized. Unhandled exceptions inside the with statement typically trigger a traceback, unless __exit__ returns True, in which the exception is "swallowed" (https://www.python.org/dev/peps/pep-0343/). However, the NameError exception and tile_indices argument disappear because of a premature sys.exit (https://hg.python.org/cpython/file/default/Lib/argparse.py#l2385). ``` """ $ python exception-in-with.py EXPECTED Traceback (most recent call last): File "exception-in-with.py", line 51, in abc # !!! NameError: name 'abc' is not defined ACTUAL usage: exception-in-with.py [-h] --image_path PATH exception-in-with.py: error: argument --image_path is required $ python exception-in-with.py --image_path x EXPECTED == ACTUAL Traceback (most recent call last): File "exception-in-with.py", line 51, in abc # !!! NameError: name 'abc' is not defined $ python exception-in-with.py --image_path x --tile_indices 1 EXPECTED Traceback (most recent call last): File "exception-in-with.py", line 51, in abc # !!! NameError: name 'abc' is not defined ACTUAL usage: exception-in-with.py [-h] --image_path PATH exception-in-with.py: error: unrecognized arguments: --tile_indices 1 """ from argparse import ArgumentParser class Starter(object): def __init__(self): self.argument_parser = ArgumentParser() def __enter__(self): return self def __exit__(self, exception_type, exception_value, exception_traceback): self.argument_parser.parse_args() def add_argument(self, *args, **kw): self.argument_parser.add_argument(*args, **kw) with Starter() as starter: starter.add_argument('--image_path', metavar='PATH', required=True) abc # !!! starter.add_argument('--tile_indices', metavar='INTEGER') ``` ---------- components: Library (Lib) files: argparse-with-exception.py messages: 242192 nosy: invisibleroads priority: normal severity: normal status: open title: Exceptions and arguments disappear when using argparse inside with statement type: behavior versions: Python 2.7, Python 3.3 Added file: http://bugs.python.org/file39227/argparse-with-exception.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 20:01:28 2015 From: report at bugs.python.org (Elizabeth Myers) Date: Tue, 28 Apr 2015 18:01:28 +0000 Subject: [issue23749] asyncio missing wrap_socket In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za> Message-ID: <1430244088.34.0.375576552085.issue23749@psf.upfronthosting.co.za> Elizabeth Myers added the comment: It seems pretty simple to just make a function that returns a new transport, something like "transport = yield from loop.ssl_wrap_transport(transport)". I'm not sure how to handle plaintext data left on the wire, though, unless that's not really a consideration (given most (all?) real-world protocols can (and usually do) wait for the SSL handshake before sending more data when STARTTLS has been requested). For the higher-level API, I'm thinking "reader, writer = asyncio.ssl_wrap(reader, writer)" maybe? You can't have half-closed SSL connections, so you would have to pass them both in. As for replacing the protocol but keeping the transport, what would be the semantics of that? I can't really think of how to do that one. I do know SMTP clears all state, but some protocols might not (IRC is a key example - this isn't usually a problem since you are supposed to negotiate it early on before you log onto the server), so this shouldn't be mandatory. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 20:21:43 2015 From: report at bugs.python.org (Elizabeth Myers) Date: Tue, 28 Apr 2015 18:21:43 +0000 Subject: [issue23749] asyncio missing wrap_socket In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za> Message-ID: <1430245303.71.0.113880249752.issue23749@psf.upfronthosting.co.za> Elizabeth Myers added the comment: Reading the source now (just woke up, sorry!), the new protocol thing makes sense. I'm not sure what to do with the waiter argument or how to handle that. What I'm really trying to think of here is how to handle copying of state. I guess users will just have to do it by hand if they want to do that? I don't know if keeping the same protocol is practical and just wrapping the transport is a good idea :(. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 20:26:09 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 28 Apr 2015 18:26:09 +0000 Subject: [issue23749] asyncio missing wrap_socket In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za> Message-ID: <1430245569.41.0.173396108911.issue23749@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > As for replacing the protocol but keeping the transport, what would > be the semantics of that? The protocol is not really replaced, it's wrapped. Before: SocketTransport <- UserProtocol After: SocketTransport <- (asyncio.sslproto.SSLProtocol <- asyncio.sslproto._SSLProtocolTransport) <- UserProtocol That way, the same SocketTransport (but it could be something else, e.g. a pipe transport) is always bound to the event loop; we simply insert a processing layer in the chain between the original transport and the final protocol. There are two distinct objects so that the SocketTransport sees a protocol and the UserProtocol sees a transport; but those two objects work hand in hand. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 20:29:16 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Tue, 28 Apr 2015 18:29:16 +0000 Subject: [issue24070] Exceptions and arguments disappear when using argparse inside with statement In-Reply-To: <1430243845.68.0.464856289952.issue24070@psf.upfronthosting.co.za> Message-ID: <1430245756.06.0.641920009712.issue24070@psf.upfronthosting.co.za> Benjamin Peterson added the comment: I'm not sure why this is so surprising. parse_args in __exit__ raises a SystmExit, which the Python interpreter takes to mean the program is responsibly exiting. I don't think any other behavior would be reasonable. e.g. sys.exit() in an except clause shouldn't cause the exception to be printed. ---------- nosy: +benjamin.peterson resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 20:29:25 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 28 Apr 2015 18:29:25 +0000 Subject: [issue23749] asyncio missing wrap_socket In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za> Message-ID: <1430245765.73.0.681447325678.issue23749@psf.upfronthosting.co.za> Guido van Rossum added the comment: That sounds like a good plan for the top-level APIs. But I think we may need to think about low-level APIs that handle Transports and Protocols as well. The design I had been thinking of does not do any socket-level manipulation (in fact it doesn't care if the Transport has a socket or some other way to connect to a networking peer) but it does require some cooperation of the Transport and Protocol. Let me draw some ASCII art. In the initial state (no ssl) we have an App embodied in a Protocol, talking to a Transport which abstracts away a network connection: data_received() [ <--------------- ] App <==> Protocol [ ] Transport <==> Network [ ---------------> ] write() (I.e., when the app wants to write to the network, it calls transport.write(); when the network has data for the app, it calls protocol.data_received().) In the final state (ssl established) I was thinking the picture would look like this (leaving the method names out): [ <---- ] [ <---- ] App <=> Protocol [ ] HelperTransport <=> HelperProtocol [ ] Transport <=> Network [ ----> ] [ ----> ] Here the Protocol at the far left and the Transport at the far right are the same objects as in the first diagram; however we've inserted a pair of helpers that handle SSL. Once the SSL connection is flowing, a write() by the app gives the data to the helper, which gives it to the SSL library. When the SSL library wants to send some (encrypted etc.) data to the network it calls write() on the rightmost Transport (the original one, which still owns the network connection). Conversely, when data arrives over the network, it is still given to the rightmost Transport via its data_received() method. This Transport then gives it to the SSL library, which eventually decrypts it (etc.) and gives it to the helper, which then calls data_received() with the decrypted plaintext on the leftmost Protocol (i.e. the App). The clever trick here is that the Protocol on the left still talks to a Transport, it's just a different Transport (owned by the helpr); similarly, the Transport on the right still talks to a Protocol, it's just a different one owned by the helper. People have proposed general stacks of Protocol/Transport pairs, but so far I haven't seen much of a use case for that. This might be that use case. In order to switch the arrangements, the helper code (which is ultimately invoked by your loop.ssl_wrap_transport() call) must first create the HelperTransport and HelperProtocol halves of the SSL helper layer, and then call set_transport()/set_protocol() on the existing App Protocol and Network Transport to change their respective associated transport and protocol. Note that the relationship between HelperTransport and HelperProtocol is not the same as that between associated Transport/Protocol pairs; the interface they use to talk to each other is completely internal to the implementation of the helper (and probably determined mostly by the needs of the underlying SSL BIO interface). Hope this helps (and hope others on the issue agree). --Guido ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 20:30:45 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Tue, 28 Apr 2015 18:30:45 +0000 Subject: [issue23749] asyncio missing wrap_socket In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za> Message-ID: <1430245845.61.0.535567781993.issue23749@psf.upfronthosting.co.za> Antoine Pitrou added the comment: > Reading the source now (just woke up, sorry!), the new protocol thing makes sense Good :-) > I'm not sure what to do with the waiter argument or how to handle that. I'm not sure. Apparently it's used for create_connection(), so perhaps it's not necessary here? Perhaps Victor or Guido can give some insight... > What I'm really trying to think of here is how to handle copying of state Well, there shouldn't be any copying necessary. The user just continues using the same protocol instance; it just calls a different transport. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 20:36:55 2015 From: report at bugs.python.org (Guido van Rossum) Date: Tue, 28 Apr 2015 18:36:55 +0000 Subject: [issue23749] asyncio missing wrap_socket In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za> Message-ID: <1430246215.19.0.101689743107.issue23749@psf.upfronthosting.co.za> Guido van Rossum added the comment: Looks like Antoine drew the same diagram but quicker. :-) Regarding the waiter arg, you can leave that None if you don't need it. It is intended to give the caller a way to block (using event loop machinery) until the connection is ready. But if your caller doesn't need it that's fine. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 20:39:26 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 28 Apr 2015 18:39:26 +0000 Subject: [issue23058] argparse silently ignores arguments In-Reply-To: <1418677327.73.0.355612765077.issue23058@psf.upfronthosting.co.za> Message-ID: <1430246366.22.0.285629781213.issue23058@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 20:45:23 2015 From: report at bugs.python.org (Eric Snow) Date: Tue, 28 Apr 2015 18:45:23 +0000 Subject: [issue11205] Evaluation order of dictionary display is different from reference manual. In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za> Message-ID: <1430246723.73.0.843890663277.issue11205@psf.upfronthosting.co.za> Eric Snow added the comment: Changes to importlib.h should always be committed. It is the frozen importlib._bootstrap module, which is the implementation of the import system used by the interpreter. So failure to commit changes to importlib.h means your changes to importlib._bootstrap will not have any effect. ---------- nosy: +eric.snow _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 20:53:13 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Tue, 28 Apr 2015 18:53:13 +0000 Subject: [issue23058] argparse silently ignores arguments In-Reply-To: <1418677327.73.0.355612765077.issue23058@psf.upfronthosting.co.za> Message-ID: <1430247193.04.0.463751200509.issue23058@psf.upfronthosting.co.za> Barry A. Warsaw added the comment: > Wouldn't it be safer all around if the subparsers took different arguments, or at least different namespace 'dest', than the main parser? IMHO, yes. I agree that the semantics of what the original code is trying to do is quite ambiguous. Since the documentation says that parents= causes all the given parsers and adds their options to the parser being constructed, I'd take that to mean that the -v before the command, and the command's -v would point to the same dest. The admonition for add_help=False seems to reinforce that. The fact that this used to work should be considered an accident. I wouldn't call it a regression because the documentation does not make it clear that this should work. I think this is not a bug. Feel free to reopen this if you disagree and and cite a convincing argument for sharing dests. To be totally unambiguous, use different destinations. FWIW, I've never used parents myself. I've always done something like what honcho eventually landed. ---------- resolution: -> not a bug status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 21:00:48 2015 From: report at bugs.python.org (Robert Collins) Date: Tue, 28 Apr 2015 19:00:48 +0000 Subject: [issue17908] Unittest runner needs an option to call gc.collect() after each test In-Reply-To: <1367720444.87.0.21268529715.issue17908@psf.upfronthosting.co.za> Message-ID: <1430247648.36.0.875443917046.issue17908@psf.upfronthosting.co.za> Robert Collins added the comment: I'm going to disagree with michael and antoine here. The *internals* should be clean and pluggable for sure, but this is actually a pretty common thing to try, so there's no reason to force it to only be done by external plugins. Right now the way to plug this in has been complicated by the addition of module / class suites, which already perform extra work around individual tests, but in a non-introspectable / extensible fashion. So you could add this as a hook to the loader (decorate each test with some new thing) and a CLI option to use that hook for a gc collect call. Alternatively, we could face down the class/module stuff and rearrange it to be extensible (e.g. something along the lines of testresources internals - generic groups pre-post stuff) or via some interaction with TestResult.... but I really dislike using TestResult to control the run - I have a better layout mostly sketched in mind but haven't had time to formalise it. So I recommend the TestLoader hook point - its well within the current responsibilities for it to do this, and I don't see any long term maintenance issues. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 21:02:22 2015 From: report at bugs.python.org (Robert Collins) Date: Tue, 28 Apr 2015 19:02:22 +0000 Subject: [issue23882] unittest discovery doesn't detect namespace packages when given no parameters In-Reply-To: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za> Message-ID: <1430247742.66.0.00407481587057.issue23882@psf.upfronthosting.co.za> Robert Collins added the comment: Ah the user model? I think the following: If I run 'python -m unittest' in a directory, then I expect to run all of the tests contained within that directory tree, and no others. Does that definition help? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 21:08:11 2015 From: report at bugs.python.org (Steve Dougherty) Date: Tue, 28 Apr 2015 19:08:11 +0000 Subject: [issue11205] Evaluation order of dictionary display is different from reference manual. In-Reply-To: <1297589953.69.0.371220549392.issue11205@psf.upfronthosting.co.za> Message-ID: <1430248091.56.0.271899970887.issue11205@psf.upfronthosting.co.za> Steve Dougherty added the comment: I've added the importlib.h changes and changed the name of the test to be more descriptive. ---------- Added file: http://bugs.python.org/file39228/issue11205-v3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 21:25:28 2015 From: report at bugs.python.org (Stephen Evans) Date: Tue, 28 Apr 2015 19:25:28 +0000 Subject: [issue24071] Python 2.7.8, 2.7.9 re.MULTILINE failure Message-ID: <1430249128.2.0.387298041566.issue24071@psf.upfronthosting.co.za> New submission from Stephen Evans: A simple multiline regex fails when just the re.MULTILINE argument is used, but works when equivalent alternative methods are used. This was tested on Python2.7.8 on FreeBSD and Win32 Python2.7.9 data = re.sub(r'#.*', '', text, re.MULTILINE) # fails data = re.sub(r'(?m)#.*', '', text) # Ok data = re.sub(r'#.*', '', text, re.MULTILINE|re.DEBUG) # Ok All the expressions work correctly with Win64 Python3.4.3 The attached file has the code and with a sample of text that fails. ---------- components: Regular Expressions files: refail.py messages: 242205 nosy: Stephen.Evans, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: Python 2.7.8, 2.7.9 re.MULTILINE failure type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file39229/refail.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 21:38:44 2015 From: report at bugs.python.org (Matthew Barnett) Date: Tue, 28 Apr 2015 19:38:44 +0000 Subject: [issue24071] Python 2.7.8, 2.7.9 re.MULTILINE failure In-Reply-To: <1430249128.2.0.387298041566.issue24071@psf.upfronthosting.co.za> Message-ID: <1430249924.47.0.99508216447.issue24071@psf.upfronthosting.co.za> Matthew Barnett added the comment: The 4th argument of re.sub is the maximum count (0 means unlimited). >>> help(re.sub) Help on function sub in module re: sub(pattern, repl, string, count=0, flags=0) Return the string obtained by replacing the leftmost non-overlapping occurrences of the pattern in string by the replacement repl. repl can be either a string or a callable; if a string, backslash escapes in it are processed. If it is a callable, it's passed the match object and must return a replacement string to be used. The value of re.MULTILINE is 8: >>> re.MULTILINE 8 therefore it'll perform a maximum of 8 substitutions. In summary: not a bug. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Tue Apr 28 22:04:13 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Tue, 28 Apr 2015 20:04:13 +0000 Subject: [issue24071] Python 2.7.8, 2.7.9 re.MULTILINE failure In-Reply-To: <1430249128.2.0.387298041566.issue24071@psf.upfronthosting.co.za> Message-ID: <1430251453.43.0.615628747912.issue24071@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 02:42:01 2015 From: report at bugs.python.org (=?utf-8?q?J=C3=A9r=C3=B4me_Laurens?=) Date: Wed, 29 Apr 2015 00:42:01 +0000 Subject: [issue24072] xml.etree.ElementTree.Element does not catch text Message-ID: <1430268121.66.0.962770633094.issue24072@psf.upfronthosting.co.za> New submission from J?r?me Laurens: text is not catcher in case 3 below INPUT import xml.etree.ElementTree as ET root1 = ET.fromstring('TEXT') print(root1.text) root2 = ET.fromstring('TEXT') print(root2.text) root3 = ET.fromstring('TEXT') print(root3.text) CURRENT OUTPUT TEXT TEXT None <---------- ERROR HERE EXPECTED OUTPUT TEXT TEXT TEXT ---------- messages: 242207 nosy: jlaurens priority: normal severity: normal status: open title: xml.etree.ElementTree.Element does not catch text type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 03:51:48 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 29 Apr 2015 01:51:48 +0000 Subject: [issue24072] xml.etree.ElementTree.Element does not catch text In-Reply-To: <1430268121.66.0.962770633094.issue24072@psf.upfronthosting.co.za> Message-ID: <1430272307.99.0.935285656535.issue24072@psf.upfronthosting.co.za> Raymond Hettinger added the comment: What would you have it do in the general case, should it concatenate all the text in: >>> root4 = ET.fromstring('abcdefghi') >>> root4.text 'abc' If I'm interpreting the XML spec correctly ( http://www.w3.org/TR/2006/REC-xml-20060816/#sec-starttags section [43]), the optional character data must be a the beginning of the element before any other elements, comments, or processing instructions: content ::= CharData? ((element | Reference | CDSect | PI | Comment) CharData?)* In other words, I'm not sure your XML is considered well-formed. ---------- nosy: +rhettinger _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 03:52:35 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 29 Apr 2015 01:52:35 +0000 Subject: [issue24072] xml.etree.ElementTree.Element does not catch text In-Reply-To: <1430268121.66.0.962770633094.issue24072@psf.upfronthosting.co.za> Message-ID: <1430272355.09.0.258441796225.issue24072@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- nosy: +eli.bendersky, scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 03:56:00 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 29 Apr 2015 01:56:00 +0000 Subject: [issue24072] xml.etree.ElementTree.Element does not catch text In-Reply-To: <1430268121.66.0.962770633094.issue24072@psf.upfronthosting.co.za> Message-ID: <1430272560.99.0.0344021498426.issue24072@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- Removed message: http://bugs.python.org/msg242208 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 04:39:48 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 29 Apr 2015 02:39:48 +0000 Subject: [issue24072] xml.etree.ElementTree.Element does not catch text In-Reply-To: <1430268121.66.0.962770633094.issue24072@psf.upfronthosting.co.za> Message-ID: <1430275188.63.0.84037314703.issue24072@psf.upfronthosting.co.za> Ned Deily added the comment: While a bit confusing, I don't think this is a bug. Note the definition of the "tail" attribute of an element: "If the element is created from an XML file the attribute will contain any text found after the element?s end tag and before the next tag." Unlike in root1 and root2 where 'TEXT' is before the end of element a and the start of element b (in root2), 'TEXT' in root3 follows the end tag of element b and so is associated with it as its tail attribute. >>> root3 >>> root3[0] >>> root3[0].tail 'TEXT' https://docs.python.org/3/library/xml.etree.elementtree.html#xml.etree.ElementTree.Element.tail ---------- nosy: +ned.deily resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 04:51:38 2015 From: report at bugs.python.org (Neil Girdhar) Date: Wed, 29 Apr 2015 02:51:38 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1430275898.11.0.212907027428.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: Hi Steve: I have limited expertise in most of these areas, but I looked at starunpack40.diff and have these comments: * tests look to have good coverage of the feature (can't speak to coverage of the parser/compiler code) * parsermodule.c changes comprehension handling, but I thought we pulled this out? There was some code taken common in various places, but there should be no code for unpacking comprehensions left in. Do you have a question about a specific line? * why was dictobject.c.h added? I don't understand clinic thoroughly, but it seems a lot of new code for what was changed in dictobject.c They weren't added. They were moved by someone else. The only changes are exposing a method. * can the BUILD_(TUPLE|LIST)_UNPACK code in ceval.c share most of the processing? Or is there an unwanted perf impact to that? Good idea. I'll make that change. * whoever applies the patch should regenerate importlib.h themselves - just a reminder Otherwise, I didn't see anything that particularly scared me. Since we apparently don't have anyone willing and with the expertise to thoroughly check the patch, I'd vote for checking it in asap so it has more releases to bake before 3.5 final. Thanks! ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 04:52:14 2015 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 29 Apr 2015 02:52:14 +0000 Subject: [issue24073] sys.stdin.mode can not give the right mode and os.fdopen does not check argument Message-ID: <1430275934.06.0.903599257127.issue24073@psf.upfronthosting.co.za> New submission from Xiang Zhang: The problem is what the title tells and can be produced by the snippet below. import sys import os sys.stdout.write("%s\n" % sys.stdin.mode) sys.stdout.flush() f = os.fdopen(sys.stdin.fileno(), "r") f.write("aaaa") f.flush() f.read() f.close() When running this snippet with nohup, which changes the stdin's mode to O_WRONLY(which can also be shown below because the write operation will fail), this snippet will still give sys.stdin.mode as r, both in 2.7 and 3.4. In 2.7, the os.fdopen will fail with Invalid Argument error because the mode r given to fdopen conflicts with stdin's real mode w. In 3.4, os.fdopen won't give any error. Both in 2.7 and 3.4, if I change the mode given to os.fdopen to w: f = os.fdopen(sys.stdin.fileno(), "w") The write operation will succeed and the read operation will fail. The output produced in nohup.out for 2.7 is: r Traceback (most recent call last): File "test.py", line 9, in f.read() IOError: File not open for reading For 3.4: r Traceback (most recent call last): File "test.py", line 9, in f.read() io.UnsupportedOperation: not readable I run the snippet with nohup on Gnome Terminal, bash, Ubuntu 15.04. The Python version is 2.7.9 and 3.4.3. ---------- components: Library (Lib) messages: 242211 nosy: angwer priority: normal severity: normal status: open title: sys.stdin.mode can not give the right mode and os.fdopen does not check argument type: behavior versions: Python 2.7, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 05:16:53 2015 From: report at bugs.python.org (Neil Girdhar) Date: Wed, 29 Apr 2015 03:16:53 +0000 Subject: [issue2292] Missing *-unpacking generalizations In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za> Message-ID: <1430277413.14.0.840600328192.issue2292@psf.upfronthosting.co.za> Neil Girdhar added the comment: All tests pass. All reviewer comments addressed. Please let me know if anything else needs to be done from my end. ---------- Added file: http://bugs.python.org/file39230/starunpack42.diff _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 08:13:41 2015 From: report at bugs.python.org (Alex Shkop) Date: Wed, 29 Apr 2015 06:13:41 +0000 Subject: [issue23882] unittest discovery doesn't detect namespace packages when given no parameters In-Reply-To: <1428406596.02.0.0629964312505.issue23882@psf.upfronthosting.co.za> Message-ID: <1430288021.5.0.313546475882.issue23882@psf.upfronthosting.co.za> Alex Shkop added the comment: Yes. That is how issue23882_find_all.patch works. I just removed hte condition if (not namespace and not os.path.isfile(os.path.join(full_path, '__init__.py'))): return None, False This makes namespace parameter redundant. Can I remove it? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 08:40:07 2015 From: report at bugs.python.org (Nick Coghlan) Date: Wed, 29 Apr 2015 06:40:07 +0000 Subject: [issue24056] Expose closure & generator status in function repr() In-Reply-To: <1429942433.91.0.521457748741.issue24056@psf.upfronthosting.co.za> Message-ID: <1430289607.64.0.0364658820841.issue24056@psf.upfronthosting.co.za> Nick Coghlan added the comment: It's mostly pedagogical - similar to "normal functions" vs "generator functions", folks talk about functions and closures as different things, even though in Python a closure is just a normal function with one or more references to cells that were defined in outer scopes. Having that show up in the repr() then becomes a way of clarifying that some, but not all, Python function objects are closures, even though closures aren't represented as a distinct type. That difference also shows up in the bytecode that creates them (note the MAKE_FUNCTION vs MAKE_CLOSURE): >>> def outer(): ... x = 1 ... def inner_function(): ... pass ... def inner_closure(): ... return x ... >>> import dis >>> dis.dis(outer) 2 0 LOAD_CONST 1 (1) 3 STORE_DEREF 0 (x) 3 6 LOAD_CONST 2 (", line 3>) 9 LOAD_CONST 3 ('outer..inner_function') 12 MAKE_FUNCTION 0 15 STORE_FAST 0 (inner_function) 5 18 LOAD_CLOSURE 0 (x) 21 BUILD_TUPLE 1 24 LOAD_CONST 4 (", line 5>) 27 LOAD_CONST 5 ('outer..inner_closure') 30 MAKE_CLOSURE 0 33 STORE_FAST 1 (inner_closure) 36 LOAD_CONST 0 (None) 39 RETURN_VALUE One particular case where the distinction matters and is known to be genuinely confusing for new Python users is the late binding behaviour of closures: lambda: i # closure lambda i=i: i # not a closure ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 08:44:04 2015 From: report at bugs.python.org (Glen Fletcher) Date: Wed, 29 Apr 2015 06:44:04 +0000 Subject: [issue24074] string, center, ljust, rjust, width paramter should accept None Message-ID: <1430289844.83.0.648544192653.issue24074@psf.upfronthosting.co.za> New submission from Glen Fletcher: I've only list python 2.7, as I'm not sure that version 3 doesn't accept None, if so this should be changed there too. If these function are passed None, as the width they should return the string unchanged, just as they would for with a width set to 0. Reasoning, A common use of these would be in list comprehensions and such, i.e. (string.center(encode(i), w) for i, w in items, widths), given the that items and widths may be of differing length in theory i should be a empty string and width 0 it not specified however the best way of dealing with this would be to use itertools.izip_longest(items, widths, default=None) and None would be encode as No Value, however this would require writing (string.center(encode(i), 0 if w is None else w) for i, w in itertools.izip_longest(items, widths, default=None)), which is far harder to follow, when its quite reasonable to expect these string alignment functions to return an unpadded string if passed None as the width. ---------- components: Library (Lib) messages: 242215 nosy: glenflet priority: normal severity: normal status: open title: string, center, ljust, rjust, width paramter should accept None type: behavior versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 09:37:44 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 29 Apr 2015 07:37:44 +0000 Subject: [issue24073] sys.stdin.mode can not give the right mode and os.fdopen does not check argument In-Reply-To: <1430275934.06.0.903599257127.issue24073@psf.upfronthosting.co.za> Message-ID: <1430293064.77.0.234760121437.issue24073@psf.upfronthosting.co.za> Ned Deily added the comment: I think the issue here is that you are expecting the "mode" attribute of a file object (or io.* object in Py3) to reflect the "readable" and "writeable" access mode of the underlying file descriptor (for POSIX-like systems). But, as noted in the documentation for the Py3 io.* objects and Py2 file object, their mode attributes reflect the "mode" given in the object constructor (for io.*) or the open() built-in (for Py2). The default sys.stdin object will always be created as a "readable" file/io object from Python's perspective but that doesn't mean that any file descriptor to which the object might refer actually allows read access. That may not be determined until your program does something that causes a call to the system runtime libraries that requires "read" access to the file, for example, sys.stdin.read() or, for Py2, os.fdopen(sys.stdin.fileno()). (As documented, the Py3 os.fdopen is an alias of the open() built-in.) If you need to know the access mode of a particular file descriptor, you can use fcntl.fcntl() F_GETFL function to examine the access mode of the fd. Or you could just use try/except blocks to catch exceptions. https://docs.python.org/3/library/os.html#os.open https://docs.python.org/3/library/io.html#io.FileIO https://docs.python.org/2/library/stdtypes.html#file.mode https://docs.python.org/3/library/fcntl.html#fcntl.fcntl http://pubs.opengroup.org/onlinepubs/9699919799/functions/fcntl.html ---------- nosy: +ned.deily resolution: -> not a bug stage: -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 10:14:35 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 29 Apr 2015 08:14:35 +0000 Subject: [issue24074] string, center, ljust, rjust, width paramter should accept None In-Reply-To: <1430289844.83.0.648544192653.issue24074@psf.upfronthosting.co.za> Message-ID: <1430295275.58.0.853536068933.issue24074@psf.upfronthosting.co.za> Raymond Hettinger added the comment: Sorry, this use case seems contrived. The common use case for centering is with a known width (otherwise, what is the point). Also, it isn't hard to write something like: s.center(w or 0) ---------- nosy: +rhettinger priority: normal -> low type: behavior -> enhancement versions: +Python 3.5 -Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 10:15:49 2015 From: report at bugs.python.org (Wolfgang Maier) Date: Wed, 29 Apr 2015 08:15:49 +0000 Subject: [issue8538] Add FlagAction to argparse In-Reply-To: <1272303487.22.0.380388489779.issue8538@psf.upfronthosting.co.za> Message-ID: <1430295349.71.0.993562876355.issue8538@psf.upfronthosting.co.za> Changes by Wolfgang Maier : ---------- nosy: +wolma _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 10:21:04 2015 From: report at bugs.python.org (Xiang Zhang) Date: Wed, 29 Apr 2015 08:21:04 +0000 Subject: [issue24073] sys.stdin.mode can not give the right mode and os.fdopen does not check argument In-Reply-To: <1430275934.06.0.903599257127.issue24073@psf.upfronthosting.co.za> Message-ID: <1430295664.04.0.958714355157.issue24073@psf.upfronthosting.co.za> Xiang Zhang added the comment: Thanks for your reply Ned and it does solve my puzzle. It's my fault to misunderstand the attribute and make noise here. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 11:50:15 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 29 Apr 2015 09:50:15 +0000 Subject: [issue21243] Auto-generate exceptions.c from a Python file In-Reply-To: <1397585549.14.0.873533303783.issue21243@psf.upfronthosting.co.za> Message-ID: <1430301015.28.0.462360029297.issue21243@psf.upfronthosting.co.za> St?phane Wirtel added the comment: I think I have understood your issue, but can you explain with more details. If I can develop this part, I can propose a patch for your issue. Thank you for your time ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 13:04:45 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 Apr 2015 11:04:45 +0000 Subject: [issue17908] Unittest runner needs an option to call gc.collect() after each test In-Reply-To: <1430247648.36.0.875443917046.issue17908@psf.upfronthosting.co.za> Message-ID: <5540BAC9.2060606@free.fr> Antoine Pitrou added the comment: Le 28/04/2015 21:00, Robert Collins a ?crit : > So you could add this as a hook to the loader (decorate each test > with some new thing) and a CLI option to use that hook for a gc > collect call. Can I take this as meaning you're not opposed to adding other options to the unittest core? (say, something to run a test until failure, or to watch for reference leaks, or to run tests in multiple processes :-)) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 14:43:27 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 29 Apr 2015 12:43:27 +0000 Subject: [issue21243] Auto-generate exceptions.c from a Python file In-Reply-To: <1397585549.14.0.873533303783.issue21243@psf.upfronthosting.co.za> Message-ID: <1430311407.85.0.0917255993903.issue21243@psf.upfronthosting.co.za> Brett Cannon added the comment: All of the exception code is written in C. My hypothesis is that it isn't necessary to define *all* exceptions in C. Using a technique similar to importlib, I suspect we could write a bunch of the exceptions that are not critical to interpreter startup in Python for easier maintenance and usage by other interpreters. You would need to make sure the Python objects did get set on the proper C global variables for access by C extension code. You could use BaseException or something temporarily for all exceptions before loading the Python code and then replace the temporary placeholders with the actual exceptions. IOW, you would need to: 1. Identify which exceptions are necessary to load the Python code holding some built-in exceptions 2. Write Python code for the exceptions which are not necessary for interpreter startup 3. Load the Python file during startup ala importlib 4. Make sure the exceptions make it into the builtin namespace 5. Make sure the exceptions end up in the proper C global variables ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 14:44:10 2015 From: report at bugs.python.org (Brett Cannon) Date: Wed, 29 Apr 2015 12:44:10 +0000 Subject: [issue24069] Option to delete obsolete bytecode files In-Reply-To: <1430239459.0.0.172566043873.issue24069@psf.upfronthosting.co.za> Message-ID: <1430311450.87.0.518327876648.issue24069@psf.upfronthosting.co.za> Changes by Brett Cannon : ---------- versions: +Python 3.5 -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 15:30:43 2015 From: report at bugs.python.org (Sergey B Kirpichev) Date: Wed, 29 Apr 2015 13:30:43 +0000 Subject: [issue24075] list.sort() should do quick exit if len(list) <= 1 Message-ID: <1430314243.47.0.686981874079.issue24075@psf.upfronthosting.co.za> New submission from Sergey B Kirpichev: If there is nothing to sort (i.e. one item), why call key function at all? In my practical situation, simplest key() function will lead to recursion in case of such trivial lists. I can make similar cmp-type function (i.e. mycmp=lambda a, b: cmp(key(a), key(b))) and then wrap this with cmp_to_key. But that looks silly. Simple test case: $ cat a.py a = [1] def spam(x): raise Exception a.sort(key=spam) print(a) $ python a.py Traceback (most recent call last): File "a.py", line 6, in a.sort(key=spam) File "a.py", line 4, in spam raise Exception Exception ---------- components: Interpreter Core files: trivial-sorting-py3.patch keywords: patch messages: 242222 nosy: Sergey.Kirpichev priority: normal severity: normal status: open title: list.sort() should do quick exit if len(list) <= 1 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/file39231/trivial-sorting-py3.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 15:47:16 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 29 Apr 2015 13:47:16 +0000 Subject: [issue24075] list.sort() should do quick exit if len(list) <= 1 In-Reply-To: <1430314243.47.0.686981874079.issue24075@psf.upfronthosting.co.za> Message-ID: <1430315236.88.0.559863295101.issue24075@psf.upfronthosting.co.za> St?phane Wirtel added the comment: The patch is ok for me, ---------- nosy: +matrixise, r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 15:59:04 2015 From: report at bugs.python.org (irdb) Date: Wed, 29 Apr 2015 13:59:04 +0000 Subject: [issue19625] IDLE 2.7 should use UTF-8 as it's default encoding In-Reply-To: <1384613631.52.0.52309466252.issue19625@psf.upfronthosting.co.za> Message-ID: <1430315944.98.0.51025108828.issue19625@psf.upfronthosting.co.za> irdb added the comment: Although in Python 3 IDLE can indeed print UTF-8 characters. But still sys.stdout.encoding == locale.getpreferredencoding() != 'utf-8'. >>> sys.stdout.encoding 'cp1256' Shouldn't it be 'utf-8'? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 16:04:21 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 29 Apr 2015 14:04:21 +0000 Subject: [issue19625] IDLE 2.7 should use UTF-8 as it's default encoding In-Reply-To: <1430315944.98.0.51025108828.issue19625@psf.upfronthosting.co.za> Message-ID: <069DCE35-6922-48C5-AC6E-CD0D1A9A752D@wirtel.be> St?phane Wirtel added the comment: On OS X and with IDLE 3, I get utf-8 with sys.stdout.encoding, not sure, but I think you have to check the default encoding on Windows. What?s the result if you execute: python3 -c 'import sys; print(sys.getdefaultencoding())' ---------- nosy: +matrixise _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 16:23:13 2015 From: report at bugs.python.org (Sergey B Kirpichev) Date: Wed, 29 Apr 2015 14:23:13 +0000 Subject: [issue24075] list.sort() should do quick exit if len(list) <= 1 In-Reply-To: <1430314243.47.0.686981874079.issue24075@psf.upfronthosting.co.za> Message-ID: <1430317393.52.0.415868150233.issue24075@psf.upfronthosting.co.za> Sergey B Kirpichev added the comment: should I add a regression test? If so, where? ./Lib/test/test_sort.py? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 16:27:14 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Apr 2015 14:27:14 +0000 Subject: [issue24075] list.sort() should do quick exit if len(list) <= 1 In-Reply-To: <1430314243.47.0.686981874079.issue24075@psf.upfronthosting.co.za> Message-ID: <1430317634.08.0.52494295474.issue24075@psf.upfronthosting.co.za> Changes by Serhiy Storchaka : ---------- nosy: +rhettinger, tim.peters stage: -> patch review type: behavior -> performance versions: -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.6 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 16:31:41 2015 From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=) Date: Wed, 29 Apr 2015 14:31:41 +0000 Subject: [issue24075] list.sort() should do quick exit if len(list) <= 1 In-Reply-To: <1430317393.52.0.415868150233.issue24075@psf.upfronthosting.co.za> Message-ID: <10612AB1-D9D8-481C-B068-3C65497D6EAC@wirtel.be> St?phane Wirtel added the comment: Yep, add a regression test. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 16:32:34 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 29 Apr 2015 14:32:34 +0000 Subject: [issue24075] list.sort() should do quick exit if len(list) <= 1 In-Reply-To: <1430314243.47.0.686981874079.issue24075@psf.upfronthosting.co.za> Message-ID: <1430317954.81.0.589080158339.issue24075@psf.upfronthosting.co.za> Benjamin Peterson added the comment: Why does your key function depend on the size of the list? That seems like the root of the problem. Considering calling the key function is observable behavior, I don't think this should be changed. The patch makes behavior list.sort() inconsistent. ---------- nosy: +benjamin.peterson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 16:35:06 2015 From: report at bugs.python.org (irdb) Date: Wed, 29 Apr 2015 14:35:06 +0000 Subject: [issue19625] IDLE 2.7 should use UTF-8 as it's default encoding In-Reply-To: <1384613631.52.0.52309466252.issue19625@psf.upfronthosting.co.za> Message-ID: <1430318106.44.0.498114931567.issue19625@psf.upfronthosting.co.za> irdb added the comment: On cmd and powershell: >python -c "import sys; print(sys.getdefaultencoding());" utf-8 >python -c "import sys; print(sys.stdout.encoding);" cp720 In IDLE: >>> import sys; print(sys.getdefaultencoding()); utf-8 >>> sys.stdout.encoding 'cp1256' ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 16:54:14 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 29 Apr 2015 14:54:14 +0000 Subject: [issue24075] list.sort() should do quick exit if len(list) <= 1 In-Reply-To: <1430314243.47.0.686981874079.issue24075@psf.upfronthosting.co.za> Message-ID: <1430319254.66.0.89407544417.issue24075@psf.upfronthosting.co.za> Raymond Hettinger added the comment: FWIW, I don't think this is worth special casing. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 16:55:50 2015 From: report at bugs.python.org (Mark Dickinson) Date: Wed, 29 Apr 2015 14:55:50 +0000 Subject: [issue24075] list.sort() should do quick exit if len(list) <= 1 In-Reply-To: <1430314243.47.0.686981874079.issue24075@psf.upfronthosting.co.za> Message-ID: <1430319350.51.0.742281959369.issue24075@psf.upfronthosting.co.za> Mark Dickinson added the comment: > Considering calling the key function is observable behavior, I don't think this should be changed. +1 ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 16:59:59 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 29 Apr 2015 14:59:59 +0000 Subject: [issue24075] list.sort() should do quick exit if len(list) <= 1 In-Reply-To: <1430314243.47.0.686981874079.issue24075@psf.upfronthosting.co.za> Message-ID: <1430319599.59.0.7980945501.issue24075@psf.upfronthosting.co.za> Changes by Benjamin Peterson : ---------- resolution: -> rejected status: open -> closed _______________________________________ Python tracker _______________________________________ From stephane at wirtel.be Wed Apr 29 16:04:20 2015 From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) Date: Wed, 29 Apr 2015 16:04:20 +0200 Subject: [issue19625] IDLE 2.7 should use UTF-8 as it's default encoding In-Reply-To: <1430315944.98.0.51025108828.issue19625@psf.upfronthosting.co.za> References: <1430315944.98.0.51025108828.issue19625@psf.upfronthosting.co.za> Message-ID: <069DCE35-6922-48C5-AC6E-CD0D1A9A752D@wirtel.be> On OS X and with IDLE 3, I get utf-8 with sys.stdout.encoding, not sure, but I think you have to check the default encoding on Windows. What?s the result if you execute: python3 -c 'import sys; print(sys.getdefaultencoding())' From stephane at wirtel.be Wed Apr 29 16:31:40 2015 From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) Date: Wed, 29 Apr 2015 16:31:40 +0200 Subject: [issue24075] list.sort() should do quick exit if len(list) <= 1 In-Reply-To: <1430317393.52.0.415868150233.issue24075@psf.upfronthosting.co.za> References: <1430317393.52.0.415868150233.issue24075@psf.upfronthosting.co.za> Message-ID: <10612AB1-D9D8-481C-B068-3C65497D6EAC@wirtel.be> Yep, add a regression test. From report at bugs.python.org Wed Apr 29 17:03:54 2015 From: report at bugs.python.org (Sergey B Kirpichev) Date: Wed, 29 Apr 2015 15:03:54 +0000 Subject: [issue24075] list.sort() should do quick exit if len(list) <= 1 In-Reply-To: <1430317954.81.0.589080158339.issue24075@psf.upfronthosting.co.za> Message-ID: <20150429150348.GA4059@darkstar.order.hcn-strela.ru> Sergey B Kirpichev added the comment: On Wed, Apr 29, 2015 at 02:32:34PM +0000, Benjamin Peterson wrote: > Why does your key function depend on the size of the list? Because it's a real life. Here is the code: https://github.com/skirpichev/omg/blob/gruntz-use-subs/sympy/series/gruntz.py#L337 Algorithm is recursive and computation of MRV set will be finished only if I add an exceptional case for len(Omega). Or even more ugly solution with cmp-style function: https://github.com/skirpichev/omg/blob/efc70377639f78fc0f246629989056cb80a71923/sympy/series/gruntz.py#L339 > Considering calling the key function is observable behavior, I don't think this > should be changed. The patch makes behavior list.sort() inconsistent. Yes, in some sense. On another hand, it's reasonable to believe that key function will be called iff we need one. But if there is nothing to sort at all - why do sorting, why you want to call key function? Looks irrational to me. Last by not least. Why the return value of the key function *must* be defined in this case? Just a hidden, undocumented restriction and has no practical value. BTW, why this issue was closed? ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 17:25:19 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 29 Apr 2015 15:25:19 +0000 Subject: [issue24075] list.sort() should do quick exit if len(list) <= 1 In-Reply-To: <20150429150348.GA4059@darkstar.order.hcn-strela.ru> Message-ID: <1430321115.3029944.260219509.75AC7FA9@webmail.messagingengine.com> Benjamin Peterson added the comment: On Wed, Apr 29, 2015, at 11:03, Sergey B Kirpichev wrote: > > Sergey B Kirpichev added the comment: > > On Wed, Apr 29, 2015 at 02:32:34PM +0000, Benjamin Peterson wrote: > > Why does your key function depend on the size of the list? > > Because it's a real life. Here is the code: > https://github.com/skirpichev/omg/blob/gruntz-use-subs/sympy/series/gruntz.py#L337 > > Algorithm is recursive and computation of MRV set will be finished only > if I add an exceptional case for len(Omega). Or even more ugly solution > with cmp-style function: > https://github.com/skirpichev/omg/blob/efc70377639f78fc0f246629989056cb80a71923/sympy/series/gruntz.py#L339 So, basically you need a base case for recursion? What's wrong with explicitly writing that out? > > > Considering calling the key function is observable behavior, I don't think this > > should be changed. The patch makes behavior list.sort() inconsistent. > > Yes, in some sense. > > On another hand, it's reasonable to believe that key function will be > called iff we need one. But if there is nothing to sort at all - why do > sorting, why you want to call key function? Looks irrational to me. > > Last by not least. Why the return value of the key function *must* > be defined in this case? Just a hidden, undocumented restriction and > has no practical value. It's practical if you have a broken key function and test it with a one element list. > > BTW, why this issue was closed? 3 of us agreed this doesn't seem like a suitable change. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 18:26:07 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Wed, 29 Apr 2015 16:26:07 +0000 Subject: [issue23910] C implementation of namedtuple (WIP) In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1430324767.09.0.575109155236.issue23910@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > 0.0699 usec per loop --> 0.0468 That's pretty good for a small patch :-) For the pre-computed 1-tuple, I think you need to check for a refcnt of 1 and fallback to PyTuple_New if the tuple is in use (i.e. a property that calls another property). See Objects/enumobject.c::105 for an example. Also, consider providing a way to clean-up that tuple on shutdown. For example, look at what is done with the various freelists. An easier way is to make the premade tuple part of the property object struct so that it gets freed when the property is deallocated. Adding Serhiy to the nosy list, he can help with cleaning-up the patch so that it is ready to apply. ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 19:18:54 2015 From: report at bugs.python.org (Joe Jevnik) Date: Wed, 29 Apr 2015 17:18:54 +0000 Subject: [issue23910] property_descr_get reuse argument tuple In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1430327934.26.0.693122555208.issue23910@psf.upfronthosting.co.za> Joe Jevnik added the comment: I don't think that we need to worry about reusing the single argument tuple in a recursive situation because we never need the value after we start the call. We also just write our new value and then clean up with a NULL to make sure that we don't blow up when we dealloc the tuple. For example: >>> class C(object): ... @property ... def f(self): ... return D().f ... >>> class D(object): ... @property ... def f(self): ... return 1 ... >>> C().f 1 This works with recursive properties. I also think that is is getting cleaned up on shutdown, if I put a pointer to garbage in the tuple, the interpreter blows up on shutdown; this makes me think that tuple_dealloc is being called somewhere. About putting the tuple on the property instance, that would nice for memory management; however, that increases the memory overhead of each property. This also means that we would only get the faster lookup after the property has been accessed once; this is fine but the current implementation makes it so that all properties are faster after any of them are looked up once. I could be wrong about the cleanup though. I am also updating the title and headers because this issue is no longer about namedtuple. ---------- components: +Interpreter Core -Extension Modules title: C implementation of namedtuple (WIP) -> property_descr_get reuse argument tuple _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 19:25:36 2015 From: report at bugs.python.org (Sergey B Kirpichev) Date: Wed, 29 Apr 2015 17:25:36 +0000 Subject: [issue24075] list.sort() should do quick exit if len(list) <= 1 In-Reply-To: <1430321115.3029944.260219509.75AC7FA9@webmail.messagingengine.com> Message-ID: <20150429172529.GA5157@darkstar.order.hcn-strela.ru> Sergey B Kirpichev added the comment: On Wed, Apr 29, 2015 at 03:25:19PM +0000, Benjamin Peterson wrote: > So, basically you need a base case for recursion? What's wrong with > explicitly writing that out? Because it's complex (and costly). This is not a trivial test and I don't see reasons to fix that is not broken. And it will be difficult to explain for readers: remember, I need this exceptional case only in the world with a strange Python's convention (Python try to sort a list when it doesn't make sense). Mathematical algorithm is not broken - programming language is. Here is C: https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/msort.c;#l45 Here is Ruby: https://github.com/ruby/ruby/blob/trunk/array.c#L2454 > It's practical if you have a broken key function and test it with a one > element list. It's silly to test key function on a single-element list *only*. > > BTW, why this issue was closed? > > 3 of us agreed this doesn't seem like a suitable change. And 1 seems to be ok with patch. Is this just a question of number of votes? At least, please consider this as a documentation issue. That ... feature may be obvious for a Python developer, but not for mathematician (as well as ordinary Python user). When key function value has no sense at all - it's not clear from the documentation, that the key function will be called. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 19:44:22 2015 From: report at bugs.python.org (Paul Moore) Date: Wed, 29 Apr 2015 17:44:22 +0000 Subject: [issue24075] list.sort() should do quick exit if len(list) <= 1 In-Reply-To: <1430314243.47.0.686981874079.issue24075@psf.upfronthosting.co.za> Message-ID: <1430329462.57.0.730793521635.issue24075@psf.upfronthosting.co.za> Paul Moore added the comment: I think the documentation is fine: """ The key corresponding to each item in the list is calculated once and then used for the entire sorting process. """ This corresponds with the standard "decorate-sort-undecorate" approach to handling key functions in sorts. It's a common computer science technique, possibly not as familiar to a mathematician, but regardless, the docs clearly state that the key is calculated for each item. Your existing code, with a check for Omega having length 1 and omitting the sort in that case, looks entirely reasonable to me. Maybe you could add a comment "Avoid a costly calculation of the key when length is 1, as we know we don't need to sort then" and leave it at that. ---------- nosy: +paul.moore _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 20:42:18 2015 From: report at bugs.python.org (Sergey B Kirpichev) Date: Wed, 29 Apr 2015 18:42:18 +0000 Subject: [issue24075] list.sort() should do quick exit if len(list) <= 1 In-Reply-To: <1430329462.57.0.730793521635.issue24075@psf.upfronthosting.co.za> Message-ID: <20150429184211.GA1710@darkstar.order.hcn-strela.ru> Sergey B Kirpichev added the comment: On Wed, Apr 29, 2015 at 05:44:22PM +0000, Paul Moore wrote: > I think the documentation is fine: > """ > The key corresponding to each item in the list is calculated once and then used for the entire sorting process. > """ Does any "sorting process" make sense for [1] or []?! No, it isn't. So, it's not clear if this "process" started at all. This not just mine opinion - most computer languages implement the quick exit in question (see examples above). > It's a common computer science technique Could you provide any language that avoid this optimization? Here is Perl 5: http://perl5.git.perl.org/perl.git/blob/HEAD:/pp_sort.c#l367 (third example) > Your existing code, with a check for Omega having length 1 and omitting > the sort in that case, looks entirely reasonable to me. (Well, then I should look for other languages, if Python devs insist in doing useless work...) > Maybe you could add a comment "Avoid a costly calculation of the > key when length is 1, as we know we don't need to sort then" I sure, for most people - the idea of sorting list with one element will look crazy. There is no room for any "costly calculations". (Common sense, nothing more.) So, such comment will add more questions... ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 20:36:58 2015 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Wed, 29 Apr 2015 18:36:58 +0000 Subject: [issue24076] sum() several times slower on Python 3 Message-ID: <1430332618.4.0.236828536627.issue24076@psf.upfronthosting.co.za> New submission from ?ukasz Langa: I got a report that summing numbers is noticably slower on Python 3. This is easily reproducible: $ time python2.7 -c "print sum(xrange(3, 10**9, 3)) + sum(xrange(5, 10**9, 5)) - sum(xrange(15, 10**9, 15))" 233333333166666668 real 0m6.165s user 0m6.100s sys 0m0.032s $ time python3.4 -c "print(sum(range(3, 10**9, 3)) + sum(range(5, 10**9, 5)) - sum(range(15, 10**9, 15)))" 233333333166666668 real 0m16.413s user 0m16.086s sys 0m0.089s I can't tell from initial poking what's the core issue here. Both examples produce equivalent bytecode, the builtin_sum() function is only noticably different in the fact that it uses PyLong_* across the board, including PyLong_AsLongAndOverlow. We'll need to profile this, which I didn't have time for yet. ---------- components: Interpreter Core messages: 242238 nosy: lukasz.langa, pitrou, rhettinger priority: normal severity: normal stage: needs patch status: open title: sum() several times slower on Python 3 type: performance versions: Python 3.4, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 20:51:21 2015 From: report at bugs.python.org (Paul Moore) Date: Wed, 29 Apr 2015 18:51:21 +0000 Subject: [issue24075] list.sort() should do quick exit if len(list) <= 1 In-Reply-To: <20150429184211.GA1710@darkstar.order.hcn-strela.ru> Message-ID: Paul Moore added the comment: On 29 April 2015 at 19:42, Sergey B Kirpichev wrote: >> It's a common computer science technique > > Could you provide any language that avoid this optimization? > > Here is Perl 5: > http://perl5.git.perl.org/perl.git/blob/HEAD:/pp_sort.c#l367 > > (third example) But that's a sort without a key. In Perl you do a key sort via: @sorted = map { $_->[0] } sort { $a->[1] <=> $b->[1] } # use numeric comparison map { [$_, length($_)] } # calculate the length of the string @unsorted; (From http://en.wikipedia.org/wiki/Schwartzian_transform). That computes the keys first, and would compute the key for a list of length 1, just like Python does. It's just that Python bundles that whole construct into the "key=" argument. But it's your choice - if this is a big enough deal to put you off Python, I guess no-one will be able to stop you. The fact of the matter is that what Python does is documented behaviour, and the benefit (small) isn't worth the cost of making a change (which would only be in Python 3.5 and later anyway, as it's a backward incompatible change, not a bug fix). ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 21:02:03 2015 From: report at bugs.python.org (Serhiy Storchaka) Date: Wed, 29 Apr 2015 19:02:03 +0000 Subject: [issue24076] sum() several times slower on Python 3 In-Reply-To: <1430332618.4.0.236828536627.issue24076@psf.upfronthosting.co.za> Message-ID: <1430334123.73.0.62078388446.issue24076@psf.upfronthosting.co.za> Serhiy Storchaka added the comment: Can't reproduce on 32-bit Linux. $ time python2.7 -c "print sum(xrange(3, 10**9, 3)) + sum(xrange(5, 10**9, 5)) - sum(xrange(15, 10**9, 15))" 233333333166666668 real 1m11.614s user 1m11.376s sys 0m0.056s $ time python3.4 -c "print(sum(range(3, 10**9, 3)) + sum(range(5, 10**9, 5)) - sum(range(15, 10**9, 15)))" 233333333166666668 real 1m11.658s user 1m10.980s sys 0m0.572s $ python2.7 -m timeit -n1 -r1 "sum(xrange(3, 10**9, 3)) + sum(xrange(5, 10**9, 5)) - sum(xrange(15, 10**9, 15))" 1 loops, best of 1: 72 sec per loop $ python3.4 -m timeit -n1 -r1 "sum(range(3, 10**9, 3)) + sum(range(5, 10**9, 5)) - sum(range(15, 10**9, 15))" 1 loops, best of 1: 72.5 sec per loop $ python2.7 -m timeit -s "a = list(range(10**6))" -- "sum(a)" 10 loops, best of 3: 114 msec per loop $ python3.4 -m timeit -s "a = list(range(10**6))" -- "sum(a)" 10 loops, best of 3: 83.5 msec per loop What is sys.int_info on your build? ---------- nosy: +serhiy.storchaka _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 21:04:22 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 Apr 2015 19:04:22 +0000 Subject: [issue24076] sum() several times slower on Python 3 In-Reply-To: <1430332618.4.0.236828536627.issue24076@psf.upfronthosting.co.za> Message-ID: <1430334262.22.0.90558701816.issue24076@psf.upfronthosting.co.za> Antoine Pitrou added the comment: I reproduce under 64-bit Linux. So this may be because the Python long digit (30 bits) is smaller than the C long (64 bits). Lukasz: is there a specific use case? Note you can use Numpy for such calculations. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 21:23:39 2015 From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=) Date: Wed, 29 Apr 2015 19:23:39 +0000 Subject: [issue24076] sum() several times slower on Python 3 In-Reply-To: <1430332618.4.0.236828536627.issue24076@psf.upfronthosting.co.za> Message-ID: <1430335419.73.0.980362863118.issue24076@psf.upfronthosting.co.za> ?ukasz Langa added the comment: Serhiy, this is 64-bit specific. Antoine, as far as I can tell, the main use case is: "Don't make it look like migrating to Python 3 is a terrible performance downgrade." As we discussed on the language summit this year [1], we have to be at least not worse to look appealing. This might be a flawed benchmark but people will make them anyway. In this particular case, there's internal usage at Twitter that unearthed it. The example is just a simplified repro. Some perf degradations were expected, like switching text to Unicode. In this case, the end result computed by both 2.7 and 3.4 is the same so we should be able to address this. [1] http://lwn.net/Articles/640224/ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 21:34:25 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Wed, 29 Apr 2015 19:34:25 +0000 Subject: [issue24076] sum() several times slower on Python 3 In-Reply-To: <1430332618.4.0.236828536627.issue24076@psf.upfronthosting.co.za> Message-ID: <1430336065.43.0.0588893078232.issue24076@psf.upfronthosting.co.za> Antoine Pitrou added the comment: If that's due to the different representation of Python 2's int type and Python 3's int type then I don't see an easy solution to this. ---------- versions: -Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 21:40:07 2015 From: report at bugs.python.org (Benjamin Peterson) Date: Wed, 29 Apr 2015 19:40:07 +0000 Subject: [issue24075] list.sort() should do quick exit if len(list) <= 1 In-Reply-To: <20150429172529.GA5157@darkstar.order.hcn-strela.ru> Message-ID: <1430336404.3771922.260339469.37BEE2FC@webmail.messagingengine.com> Benjamin Peterson added the comment: On Wed, Apr 29, 2015, at 13:25, Sergey B Kirpichev wrote: > > Sergey B Kirpichev added the comment: > > On Wed, Apr 29, 2015 at 03:25:19PM +0000, Benjamin Peterson wrote: > > So, basically you need a base case for recursion? What's wrong with > > explicitly writing that out? > > Because it's complex (and costly). This is not a trivial test and > I don't see reasons to fix that is not broken. And it will be difficult > to explain for readers: remember, I need this exceptional case only in > the world with a strange Python's convention (Python try to sort a list > when it doesn't make sense). > > Mathematical algorithm is not broken - programming language is. > > Here is C: > https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/msort.c;#l45 > Here is Ruby: > https://github.com/ruby/ruby/blob/trunk/array.c#L2454 I don't understand the analogy, since neither of these two have key functions. > > > It's practical if you have a broken key function and test it with a one > > element list. > > It's silly to test key function on a single-element list *only*. > > > > BTW, why this issue was closed? > > > > 3 of us agreed this doesn't seem like a suitable change. > > And 1 seems to be ok with patch. Is this just a question of > number of votes? I should also clarify that Raymond and Mark and responsible for maintaining most of the algorithmic/data structure code in Python. > > At least, please consider this as a documentation issue. That ... > feature may be obvious for a Python developer, but not for > mathematician (as well as ordinary Python user). This is probably impossible to prove either way. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 22:22:05 2015 From: report at bugs.python.org (John Beck) Date: Wed, 29 Apr 2015 20:22:05 +0000 Subject: [issue1298835] Add a vendor-packages directory for system-supplied modules Message-ID: <1430338925.8.0.630446111752.issue1298835@psf.upfronthosting.co.za> Changes by John Beck : ---------- nosy: +jbeck _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 22:25:30 2015 From: report at bugs.python.org (Sergey B Kirpichev) Date: Wed, 29 Apr 2015 20:25:30 +0000 Subject: [issue24075] list.sort() should do quick exit if len(list) <= 1 In-Reply-To: Message-ID: <20150429202524.GA21343@darkstar.order.hcn-strela.ru> Sergey B Kirpichev added the comment: On Wed, Apr 29, 2015 at 06:51:21PM +0000, Paul Moore wrote: > But that's a sort without a key. Why it does matter? It have quick exit. For same reasons - Python could... > In Perl you do a key sort via: That's just your implementation. But we could add here a quick exit as well. > The fact of the matter is that what Python does is documented behaviour No. Unless you absolutely sure - all readers think that "sorting process" starts even for trivial lists. No reasons to believe in that nonsense - as you could see from sorting implementations in other languages. > benefit (small) isn't worth the cost of making a change (which would > only be in Python 3.5 and later anyway It's easy for users (i.e. me) to backport this feature (i.e. make wrapper for sorted()). Benefit is small, I admit, but why not remove unnecessary restrictions from the language? I hope, I did my best to explain why. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 22:27:49 2015 From: report at bugs.python.org (Sergey B Kirpichev) Date: Wed, 29 Apr 2015 20:27:49 +0000 Subject: [issue24075] list.sort() should do quick exit if len(list) <= 1 In-Reply-To: <1430314243.47.0.686981874079.issue24075@psf.upfronthosting.co.za> Message-ID: <1430339269.72.0.365365382248.issue24075@psf.upfronthosting.co.za> Changes by Sergey B Kirpichev : Added file: http://bugs.python.org/file39232/0001-list.sort-Add-quick-exit-if-length-of-list-1.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 22:52:56 2015 From: report at bugs.python.org (Terry J. Reedy) Date: Wed, 29 Apr 2015 20:52:56 +0000 Subject: [issue15809] 2.7 IDLE console uses incorrect encoding. In-Reply-To: <1346244102.55.0.0360895602485.issue15809@psf.upfronthosting.co.za> Message-ID: <1430340776.82.0.0226121621095.issue15809@psf.upfronthosting.co.za> Terry J. Reedy added the comment: #19625, with a bit of discussion, was closed as a duplicate of this issue. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 23:19:52 2015 From: report at bugs.python.org (John Beck) Date: Wed, 29 Apr 2015 21:19:52 +0000 Subject: [issue24077] man page says -I implies -S. code says -s. Should it be both? Message-ID: <1430342392.4.0.32328442705.issue24077@psf.upfronthosting.co.za> New submission from John Beck: The man page for Python (3.4 and 3.5) says: -I Run Python in isolated mode. This also implies -E and -S. In isolated mode sys.path contains neither the scripts directory nor the users site-packages directory. All PYTHON* environment variables are ignored, too. Further restrictions may be imposed to prevent the user from injecting malicious code. But the code says: -I : isolate Python from the user's environment (implies -E and -s) and the code to handle -I does: case 'I': Py_IsolatedFlag++; Py_NoUserSiteDirectory++; Py_IgnoreEnvironmentFlag++; break; where Py_NoUserSiteDirectory is the variable corresponding to the -s flag rather than the -S flag. But it seems like -I should really imply both -s and -S. So I am filing this bug primarily to find out whether or not it really should be both. If so, great: a patch is attached; details below. But if not, then the man page should be corrected. The rest of this is written under the assumption that -I should imply -S as well as -s. Background: depending on which packages are installed on different Solaris systems, test_site passes or not. Certain packages (e.g., dogpile.core, dogpile.cache, repoze.lru) that have a .pth file with "import types" which results in test_site.StartupImportTests failing because types has been imported which is in the list of collections modules, none of which are expected to be imported. So we thought "well, -S should fix that" then noticed the man page saying -I implied -S which is how we got here. Tweaking the code and man page so -I does imply -S was trivial. But three other changes were needed: 1. In test_site.py, test_startup_imports() asserted that 'site' was in the list of modules that had been imported. This is no longer true, so I deleted the assert. 2. test_inspect failed because of a name error, that turned out to be inspect.py calling exit instead of sys.exit. So the attached patch corrects both of those. This fix is probably generally applicable even if the "-I should imply both -S and -s" assumption turns out to be false. 3. test_venv failed because it and the venv module were using -I to imply -s and -E but not -S. Changing three instances of "-Im" to "-Esm" (one in Lib/venv/__init__.py, the other two in Lib/test/test_venv.py) fixed this. However, even if the "-I should imply both -S and -s" assumption is true, this change may not be desirable in the general case, but needed because of Solaris' hacky work-around for issue 1298835 not yet being fixed.' I.e., we ship /usr/lib/python3.4/site-packages/vendor-packages.pth with the one line: import site; site.addsitedir('/usr/lib/python3.4/vendor-packages') (likewise for other versions). So this may not be desirable in general, but I mention it for the sake of completeness. ---------- components: Interpreter Core files: 25-site-module.patch keywords: patch messages: 242248 nosy: dhduvall, jbeck priority: normal severity: normal status: open title: man page says -I implies -S. code says -s. Should it be both? versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file39233/25-site-module.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 23:29:11 2015 From: report at bugs.python.org (John Beck) Date: Wed, 29 Apr 2015 21:29:11 +0000 Subject: [issue24077] man page says -I implies -S. code says -s. Should it be both? In-Reply-To: <1430342392.4.0.32328442705.issue24077@psf.upfronthosting.co.za> Message-ID: <1430342951.14.0.228546091321.issue24077@psf.upfronthosting.co.za> John Beck added the comment: Adding Christian Heimes to the nosy list; as the author of the fix for issue 16499, he seems an excellent person to answer the question and offer advice on the approaches discussed herein. ---------- nosy: +christian.heimes _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 23:39:29 2015 From: report at bugs.python.org (Christian Heimes) Date: Wed, 29 Apr 2015 21:39:29 +0000 Subject: [issue24077] man page says -I implies -S. code says -s. Should it be both? In-Reply-To: <1430342392.4.0.32328442705.issue24077@psf.upfronthosting.co.za> Message-ID: <1430343569.93.0.878707912166.issue24077@psf.upfronthosting.co.za> Christian Heimes added the comment: The isolated mode implies -E (ignore env vars) and -s (don't add user site directory). The code and tests are correct, just the man page is wrong. The site module is still loaded in -I mode as it doesn't impose any security implications. I'd looks like I made a typo in dd0d751cc7f1 and used upper case instead of lower case for python.man. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 23:43:55 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 29 Apr 2015 21:43:55 +0000 Subject: [issue24077] man page says -I implies -S. code says -s. Should it be both? In-Reply-To: <1430342392.4.0.32328442705.issue24077@psf.upfronthosting.co.za> Message-ID: <1430343835.88.0.913919221798.issue24077@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- assignee: -> docs at python components: +Documentation -Interpreter Core nosy: +docs at python stage: -> needs patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 23:46:43 2015 From: report at bugs.python.org (John Beck) Date: Wed, 29 Apr 2015 21:46:43 +0000 Subject: [issue24077] man page says -I implies -S. code says -s. In-Reply-To: <1430342392.4.0.32328442705.issue24077@psf.upfronthosting.co.za> Message-ID: <1430344003.76.0.019611696462.issue24077@psf.upfronthosting.co.za> John Beck added the comment: Thank you very much for clarifying that. I have updated the bug Title accordingly. ---------- title: man page says -I implies -S. code says -s. Should it be both? -> man page says -I implies -S. code says -s. _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 23:54:00 2015 From: report at bugs.python.org (Roundup Robot) Date: Wed, 29 Apr 2015 21:54:00 +0000 Subject: [issue24077] man page says -I implies -S. code says -s. In-Reply-To: <1430342392.4.0.32328442705.issue24077@psf.upfronthosting.co.za> Message-ID: <20150429215357.1915.94928@psf.io> Roundup Robot added the comment: New changeset d774401879d8 by Ned Deily in branch '3.4': Issue #24077: Fix typo in man page for -I command option: -s, not -S. https://hg.python.org/cpython/rev/d774401879d8 New changeset 493b3310d5d0 by Ned Deily in branch 'default': Issue #24077: merge from 3.4 https://hg.python.org/cpython/rev/493b3310d5d0 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 23:55:24 2015 From: report at bugs.python.org (Ned Deily) Date: Wed, 29 Apr 2015 21:55:24 +0000 Subject: [issue24077] man page says -I implies -S. code says -s. In-Reply-To: <1430342392.4.0.32328442705.issue24077@psf.upfronthosting.co.za> Message-ID: <1430344524.21.0.252539835163.issue24077@psf.upfronthosting.co.za> Ned Deily added the comment: Thanks for the report, John! ---------- nosy: +ned.deily resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Wed Apr 29 23:59:26 2015 From: report at bugs.python.org (Barry A. Warsaw) Date: Wed, 29 Apr 2015 21:59:26 +0000 Subject: [issue24077] man page says -I implies -S. code says -s. In-Reply-To: <1430342392.4.0.32328442705.issue24077@psf.upfronthosting.co.za> Message-ID: <1430344766.36.0.702742097083.issue24077@psf.upfronthosting.co.za> Changes by Barry A. Warsaw : ---------- nosy: +barry _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 01:04:32 2015 From: report at bugs.python.org (Siming Yuan) Date: Wed, 29 Apr 2015 23:04:32 +0000 Subject: [issue24078] inspect.getsourcelines ignores context and returns wrong line # Message-ID: <1430348672.59.0.934013457033.issue24078@psf.upfronthosting.co.za> New submission from Siming Yuan: if the same class name is used within a module, but defined in different contexts (either class in class or class in function), inspect.getsourcelines() on the class object ignores the object context and only returns the first matched name. reproduce: a.py ---- class A(object): class B(object): pass class C(object): class B(object): pass ------------------ >>> import inspect >>> import a >>> inspect.getsourcelines(a.C.B) ([' class B(object):\n', ' pass\n'], 2) ---------- components: Library (Lib) messages: 242254 nosy: siyuan priority: normal severity: normal status: open title: inspect.getsourcelines ignores context and returns wrong line # type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 01:08:48 2015 From: report at bugs.python.org (Siming Yuan) Date: Wed, 29 Apr 2015 23:08:48 +0000 Subject: [issue24078] inspect.getsourcelines ignores context and returns wrong line # In-Reply-To: <1430348672.59.0.934013457033.issue24078@psf.upfronthosting.co.za> Message-ID: <1430348928.98.0.0978970784211.issue24078@psf.upfronthosting.co.za> Siming Yuan added the comment: according to inspect.py line 675 - this is only a best effort. is this intended? inspect.py @ 672 if isclass(object): name = object.__name__ pat = re.compile(r'^(\s*)class\s*' + name + r'\b') # make some effort to find the best matching class definition: # use the one with the least indentation, which is the one # that's most probably not inside a function definition. candidates = [] for i in range(len(lines)): match = pat.match(lines[i]) if match: # if it's at toplevel, it's already the best one if lines[i][0] == 'c': return lines, i # else add whitespace to candidate list candidates.append((match.group(1), i)) if candidates: # this will sort by whitespace, and by line number, # less whitespace first candidates.sort() return lines, candidates[0][1] else: raise OSError('could not find class definition') ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 01:34:55 2015 From: report at bugs.python.org (=?utf-8?q?J=C3=A9r=C3=B4me_Laurens?=) Date: Wed, 29 Apr 2015 23:34:55 +0000 Subject: [issue24079] xml.etree.ElementTree.Element.text does not conform to the documentation Message-ID: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za> New submission from J?r?me Laurens: The documentation for xml.etree.ElementTree.Element.text reads "If the element is created from an XML file the attribute will contain any text found between the element tags." import xml.etree.ElementTree as ET root3 = ET.fromstring('TEXT') print(root3.text) CURRENT OUTPUT None "TEXT" is between the elements tags but does not appear in the output BTW : this is well formed xml and has nothing to do with tail. ---------- components: XML messages: 242256 nosy: jlaurens priority: normal severity: normal status: open title: xml.etree.ElementTree.Element.text does not conform to the documentation type: behavior versions: Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 04:35:08 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 30 Apr 2015 02:35:08 +0000 Subject: [issue24079] xml.etree.ElementTree.Element.text does not conform to the documentation In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za> Message-ID: <1430361308.06.0.832779387317.issue24079@psf.upfronthosting.co.za> Ned Deily added the comment: (This issue is a followup to your Issue24072.) Again, while the ElementTree documentation is certainly not nearly as complete as it should be, I don't think this is a documentation error per se. The key issue is: with which element is each text string associated? Perhaps this example will help: >>> root4 = ET.fromstring('ATEXTBTEXTBTAIL') >>> root4 >>> root4.text 'ATEXT' >>> root4.tail >>> root4[0] >>> root4[0].text 'BTEXT' >>> root4[0].tail 'BTAIL' As in your original example, any text following the element b is associated with b's tail attribute until a new tag is found, pushing or popping the tree stack. While the description of the "text" attribute does not explicitly state this, the "tail" attribute description immediately following it does. This is also explained in more detail in the ElementTree resources on effbot.org that are linked to from the Python Standard Library documentation. Nevertheless, it probably would be helpful to expand the documentation on this point if someone is willing to put together a documentation patch for review. With regard to your comment about "well formed xml", I don't think there is anything in the documentation that implies (or should imply) that the distinction between the "text" attribute and the "tail" attribute has anything to do with whether it is well-formed XML. The tutorial for the third-party lxml package, which provides another implementation of ElementTree, goes into more detail about why, in general, both "text" and "tail" are necessary. https://docs.python.org/3/library/xml.etree.elementtree.html#additional-resources http://effbot.org/zone/element.htm#text-content http://lxml.de/tutorial.html#elements-contain-text ---------- assignee: -> docs at python components: +Documentation -XML nosy: +docs at python, ned.deily stage: -> needs patch versions: +Python 2.7, Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 05:31:33 2015 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 30 Apr 2015 03:31:33 +0000 Subject: [issue24075] list.sort() should do quick exit if len(list) <= 1 In-Reply-To: <1430314243.47.0.686981874079.issue24075@psf.upfronthosting.co.za> Message-ID: <1430364693.07.0.738584797461.issue24075@psf.upfronthosting.co.za> Mark Dickinson added the comment: > I should also clarify that Raymond and Mark and responsible for maintaining most of the algorithmic/data structure code in Python. Well, Raymond at least. I plead not guilty; I think you're confusing me with someone else. :-) But for this issue, this mathematician prefers the simple invariant that the key function is called exactly once per list item. If your key function doesn't work for one of those items for some reason, that sounds like a problem with the key function rather than a reason to change the sorting implementation. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 05:32:42 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 30 Apr 2015 03:32:42 +0000 Subject: [issue24050] [2.7] crash in third party module mopidy In-Reply-To: <1429882485.21.0.520202259055.issue24050@psf.upfronthosting.co.za> Message-ID: <1430364762.14.0.90571498237.issue24050@psf.upfronthosting.co.za> Changes by R. David Murray : ---------- resolution: not a bug -> third party stage: -> resolved _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 05:50:27 2015 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 30 Apr 2015 03:50:27 +0000 Subject: [issue24076] sum() several times slower on Python 3 In-Reply-To: <1430332618.4.0.236828536627.issue24076@psf.upfronthosting.co.za> Message-ID: <1430365827.22.0.351207260823.issue24076@psf.upfronthosting.co.za> Mark Dickinson added the comment: ?ukasz: there are three ingredients here - sum, (x)range and the integer addition that sum will be performing at each iteration. Is there any chance you can separate the effects on your machine? On my machine (OS X, 64-bit), I'm seeing *some* speed difference in the integer arithmetic, but not enough to explain the whole of the timing mismatch. One thing we've lost in Python 3 is the fast path for small-int addition *inside* the ceval loop. It may be possible to restore something there. ---------- nosy: +mark.dickinson _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 06:08:30 2015 From: report at bugs.python.org (Mark Dickinson) Date: Thu, 30 Apr 2015 04:08:30 +0000 Subject: [issue24076] sum() several times slower on Python 3 In-Reply-To: <1430332618.4.0.236828536627.issue24076@psf.upfronthosting.co.za> Message-ID: <1430366910.73.0.553196971989.issue24076@psf.upfronthosting.co.za> Mark Dickinson added the comment: Throwing out sum, I'm seeing significant slowdown simply from xrange versus range: taniyama:Desktop mdickinson$ python2 -m timeit -s 'x = xrange(3, 10**9, 3)' 'for e in x: pass' 10 loops, best of 3: 5.01 sec per loop taniyama:Desktop mdickinson$ python3 -m timeit -s 'x = range(3, 10**9, 3)' 'for e in x: pass' 10 loops, best of 3: 8.62 sec per loop ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 06:31:42 2015 From: report at bugs.python.org (Jaivish Kothari) Date: Thu, 30 Apr 2015 04:31:42 +0000 Subject: [issue24005] Documentation Error: Extra line Break In-Reply-To: <1429439369.0.0.722585874502.issue24005@psf.upfronthosting.co.za> Message-ID: <1430368302.48.0.62904252482.issue24005@psf.upfronthosting.co.za> Jaivish Kothari added the comment: Thanks for support . I agree it is not a bug at all but just as Tim said it would be easy to copy paste code directly to interpreter with such changes. This was my first contribution in python though not accepted , it is ok :) . I'll try to contribute more towards it .Thanks for commenting . Could you guys suggest some issues i could work on as a beginner :) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 07:30:12 2015 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 30 Apr 2015 05:30:12 +0000 Subject: [issue24076] sum() several times slower on Python 3 In-Reply-To: <1430332618.4.0.236828536627.issue24076@psf.upfronthosting.co.za> Message-ID: <1430371812.44.0.547072822959.issue24076@psf.upfronthosting.co.za> Stefan Behnel added the comment: > there are three ingredients here - sum, (x)range and the integer addition that sum will be performing at each iteration. ... not to forget the interpreter startup time on his machine. :) I did a tiny bit of profiling and about 90% of the time seems to be spent creating and deallocating throw-away PyLong objects. My guess is that it simply lacks a free-list in _PyLong_New(). ---------- nosy: +scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 08:38:16 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 30 Apr 2015 06:38:16 +0000 Subject: [issue24079] xml.etree.ElementTree.Element.text does not conform to the documentation In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za> Message-ID: <1430375896.72.0.149694489298.issue24079@psf.upfronthosting.co.za> Raymond Hettinger added the comment: > this is well formed xml and has nothing to do with tail. In fact, it does have something to do with tail. The 'TEXT' is a captured as the tail of element b: >>> root3 = ET.fromstring('TEXT') >>> root3[0].tail 'TEXT' ---------- nosy: +eli.bendersky, rhettinger, scoder _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 09:04:40 2015 From: report at bugs.python.org (Stefan Behnel) Date: Thu, 30 Apr 2015 07:04:40 +0000 Subject: [issue24079] xml.etree.ElementTree.Element.text does not conform to the documentation In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za> Message-ID: <1430377480.79.0.373009887305.issue24079@psf.upfronthosting.co.za> Stefan Behnel added the comment: I agree that the wording in the documentation isn't great: """ text The text attribute can be used to hold additional data associated with the element. As the name implies this attribute is usually a string but may be any application-specific object. If the element is created from an XML file the attribute will contain any text found between the element tags. tail The tail attribute can be used to hold additional data associated with the element. This attribute is usually a string but may be any application-specific object. If the element is created from an XML file the attribute will contain any text found after the element?s end tag and before the next tag. """ Special cases that no-one uses (sticking non-string objects into text/tail) are given too much space and the difference isn't explained as needed. Since the distinction between text and tail is a (great but) rather special feature of ElementTree, it needs to be given more room in the docs. Proposal: """ text The text attribute holds the immediate text content of the element. It contains any text found up to either the closing tag if the element has no children, or the next opening child tag within the element. For text following an element, see the `tail` attribute. To collect the entire text content of a subtree, see `tostring`. Applications may store arbitrary objects in this attribute. tail The tail attribute holds any text that directly follows the element. For example, in a document like ``TextBTailCTail``, the `text` attribute of the ``a`` element holds the string "Text", and the tail attributes of ``b`` and ``c`` hold the strings "BTail" and "CTail" respectively. Applications may store arbitrary objects in this attribute. """ ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 09:32:55 2015 From: report at bugs.python.org (Tim Golden) Date: Thu, 30 Apr 2015 07:32:55 +0000 Subject: [issue24005] Documentation Error: Extra line Break In-Reply-To: <1430368302.48.0.62904252482.issue24005@psf.upfronthosting.co.za> Message-ID: <5541DAA0.3040805@timgolden.me.uk> Tim Golden added the comment: Jaivish Kothari, Thanks for making the effort to contribute. Can I suggest you have a look at the Core Mentorship site: http://pythonmentors.com/ and perhaps join the Core Mentorship list: http://mail.python.org/mailman/listinfo/core-mentorship TJG ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 12:18:56 2015 From: report at bugs.python.org (Claudiu Popa) Date: Thu, 30 Apr 2015 10:18:56 +0000 Subject: [issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument In-Reply-To: <1399160288.58.0.274862722075.issue21423@psf.upfronthosting.co.za> Message-ID: <1430389136.16.0.803203469912.issue21423@psf.upfronthosting.co.za> Changes by Claudiu Popa : ---------- nosy: +Claudiu.Popa _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 12:19:15 2015 From: report at bugs.python.org (Claudiu Popa) Date: Thu, 30 Apr 2015 10:19:15 +0000 Subject: [issue21423] concurrent.futures.ThreadPoolExecutor/ProcessPoolExecutor should accept an initializer argument In-Reply-To: <1399160288.58.0.274862722075.issue21423@psf.upfronthosting.co.za> Message-ID: <1430389155.53.0.852738971297.issue21423@psf.upfronthosting.co.za> Changes by Claudiu Popa : ---------- stage: -> patch review _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 12:34:21 2015 From: report at bugs.python.org (Claudiu Popa) Date: Thu, 30 Apr 2015 10:34:21 +0000 Subject: [issue21518] Expose RegUnLoadKey in winreg In-Reply-To: <1400346760.52.0.0203244636304.issue21518@psf.upfronthosting.co.za> Message-ID: <1430390061.06.0.566986897962.issue21518@psf.upfronthosting.co.za> Claudiu Popa added the comment: Hello, Can anyone review the last patch? Hopefully it is the final version, since the beta is really at the corner and I definitely would like to have this in 3.5. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 12:53:08 2015 From: report at bugs.python.org (Eric Reynolds) Date: Thu, 30 Apr 2015 10:53:08 +0000 Subject: [issue4356] Add "key" argument to "bisect" module functions In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za> Message-ID: <1430391188.35.0.237071163043.issue4356@psf.upfronthosting.co.za> Eric Reynolds added the comment: In the meantime here is a workaround https://gist.github.com/ericremoreynolds/2d80300dabc70eebc790 ---------- nosy: +ericreynolds _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 13:35:53 2015 From: report at bugs.python.org (=?utf-8?q?J=C3=A9r=C3=B4me_Laurens?=) Date: Thu, 30 Apr 2015 11:35:53 +0000 Subject: [issue24079] xml.etree.ElementTree.Element.text does not conform to the documentation In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za> Message-ID: <1430393753.35.0.307735780067.issue24079@psf.upfronthosting.co.za> J?r?me Laurens added the comment: Since the text and tail notions seem tightly coupled, I would vote for a more detailed explanation in the text doc and a forward link in the tail documentation. """ text The text attribute holds the text between the element's begin tag and the next tag or None. The tail attribute holds the text between the element's end tag and the next tag or None. For "1234" xml data, the a element has None for both text and tail attributes, the b element has text '1' and tail '4', the c element has text '2' and tail None, the d element hast text None and tail '3'. To collect the inner text of an element, see `tostring` with method 'text'. Applications may store arbitrary objects in this attribute. tail The tail attribute holds the text between the element's end tag and the next tag or None. See `text` for more details. Applications may store arbitrary objects in this attribute. """ It is very important to mention that the 'text' attribute does not always hold a string contrary to what would suggest its name. BTW, I was not aware of the tostring method with 'text' argument. The fact is that the documentation reads "Returns an (optionally) encoded string containing the XML data." which is misleading because the text is not xml data in general. This also needs to be rephrased or simply removed. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 15:59:58 2015 From: report at bugs.python.org (Matt Johnston) Date: Thu, 30 Apr 2015 13:59:58 +0000 Subject: [issue24080] asyncio.Event.wait() Task was destroyed but it is pending Message-ID: <1430402398.63.0.270088920542.issue24080@psf.upfronthosting.co.za> New submission from Matt Johnston: asyncio.Event.wait() doesn't seem to be cancelled by asyncio.wait_for(). Ctrl-c in the attached example produces output below. I'm not certain the code is correct though the documentation for wait_for() suggests it should work. Without the wait_for() it doesn't suffer from pending task destruction. This is Python 3.4.3. Hello World! Hello World! ^CTraceback (most recent call last): File "./loop2.py", line 27, in loop.run_until_complete(hello_world()) File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/asyncio/base_events.py", line 304, in run_until_complete self.run_forever() File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/asyncio/base_events.py", line 276, in run_forever self._run_once() File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/asyncio/base_events.py", line 1136, in _run_once event_list = self._selector.select(timeout) File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/selectors.py", line 502, in select kev_list = self._kqueue.control(None, max_ev, timeout) KeyboardInterrupt Task was destroyed but it is pending! task: wait_for= cb=[_release_waiter()() at /Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/asyncio/tasks.py:335]> [1] 8134 exit 1 ../venv3/bin/python3 ./loop2.py ---------- components: asyncio files: loop2.py messages: 242269 nosy: gvanrossum, haypo, matt, yselivanov priority: normal severity: normal status: open title: asyncio.Event.wait() Task was destroyed but it is pending versions: Python 3.4 Added file: http://bugs.python.org/file39234/loop2.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 16:12:35 2015 From: report at bugs.python.org (Petr Viktorin) Date: Thu, 30 Apr 2015 14:12:35 +0000 Subject: [issue24081] Obsolete caveat in reload() docs Message-ID: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za> New submission from Petr Viktorin: imp.reload() and importlib.reload() docs state:: If a module is syntactically correct but its initialization fails, the first :keyword:`import` statement for it does not bind its name locally, but does store a (partially initialized) module object in ``sys.modules``. To reload the module you must first :keyword:`import` it again (this will bind the name to the partially initialized module object) before you can :func:`reload` it. If I reading that correctly, "initialization" refers to executing the module, so for module containing just:: uninitialized_variable the following:: >>> import sys >>> import x Traceback (most recent call last): File "", line 1, in File "/tmp/x.py", line 1, in uninitialized_variable NameError: name 'uninitialized_variable' is not defined should leave me with a initialized module in sys.modules['x']. However, this is not what happens, in either Python 3.4 or 2.7:: >>> sys.modules['x'] Traceback (most recent call last): File "", line 1, in KeyError: 'x' Here's a patch to remove the caveat in Python 3 docs. If I missed something, and "initialization" refers to something else, it should be clarified. ---------- assignee: docs at python components: Documentation files: 0001-Remove-obsolete-caveat-from-reload-docs.patch keywords: patch messages: 242270 nosy: docs at python, encukou priority: normal severity: normal status: open title: Obsolete caveat in reload() docs versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file39235/0001-Remove-obsolete-caveat-from-reload-docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 16:19:30 2015 From: report at bugs.python.org (Petr Viktorin) Date: Thu, 30 Apr 2015 14:19:30 +0000 Subject: [issue24082] Obsolete note in argument parsing (c-api/arg.rst) Message-ID: <1430403570.61.0.800757161817.issue24082@psf.upfronthosting.co.za> New submission from Petr Viktorin: A note in the docs for the "u" format unit saus NULs are not allowed, but the previous sentence says they aren't accepted. ---------- assignee: docs at python components: Documentation files: 0002-Remove-obsolete-note-in-argument-parsing-docs.patch keywords: patch messages: 242271 nosy: docs at python, encukou priority: normal severity: normal status: open title: Obsolete note in argument parsing (c-api/arg.rst) versions: Python 3.4 Added file: http://bugs.python.org/file39236/0002-Remove-obsolete-note-in-argument-parsing-docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 16:59:12 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 30 Apr 2015 14:59:12 +0000 Subject: [issue24052] sys.exit(code) returns "success" to the OS for some nonzero values of code In-Reply-To: <1429889353.58.0.941477823236.issue24052@psf.upfronthosting.co.za> Message-ID: <1430405952.06.0.966408685133.issue24052@psf.upfronthosting.co.za> R. David Murray added the comment: Printing the actual value feels more consistent with the documented API, so I'm in favor of that (ie: don't let errors pass silently). I'm sure someone somewhere is depending on this :(, but I see you have versions marked for 3.5 only, which makes sense to me. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 17:08:23 2015 From: report at bugs.python.org (Roundup Robot) Date: Thu, 30 Apr 2015 15:08:23 +0000 Subject: [issue23910] property_descr_get reuse argument tuple In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <20150430150819.3485.54573@psf.io> Roundup Robot added the comment: New changeset 661cdbd617b8 by Raymond Hettinger in branch 'default': Issue #23910: Optimize property() getter calls. Patch by Joe Jevnik https://hg.python.org/cpython/rev/661cdbd617b8 ---------- nosy: +python-dev _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 17:09:07 2015 From: report at bugs.python.org (A. Jesse Jiryu Davis) Date: Thu, 30 Apr 2015 15:09:07 +0000 Subject: [issue10544] yield expression inside generator expression does nothing In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za> Message-ID: <1430406547.17.0.979731026213.issue10544@psf.upfronthosting.co.za> Changes by A. Jesse Jiryu Davis : ---------- nosy: +emptysquare _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 17:15:48 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 30 Apr 2015 15:15:48 +0000 Subject: [issue24083] MSVCCompiler.get_msvc_path() doesn't work on Win x64 Message-ID: <1430406948.34.0.89684475541.issue24083@psf.upfronthosting.co.za> New submission from Marc-Andre Lemburg: Trying to use .get_msvc_path() on an distutils.msvccompiler.MSVCCompiler() instance raises an AttributeError: MSVCCompiler instance has no attribute '_MSVCCompiler__root' The reason seems to be that self.__root is not set for Win x64 in .__init__(). Here's an example from Python 2.7.9: >>> from distutils.msvccompiler import * >>> c = OldMSVCCompiler() >>> vars(c) {'force': 0, 'verbose': 0, 'dry_run': 0, 'runtime_library_dirs': [], 'libraries': [], 'macros': [], 'objects': [], 'output_dir': None, '_MSVCCompiler__product': 'Microsoft SDK compiler 15.0', 'initialized': False, '_MSVCCompiler__arch': 'AMD64', '_MSVCCompiler__version': 9.0, 'library_dirs': [], 'include_dirs': []} >>> c.get_msvc_paths('include') Traceback (most recent call last): File "", line 1, in File "D:\Python27\lib\distutils\msvccompiler.py", line 615, in get_msvc_paths % (self.__root, self.__version)) AttributeError: MSVCCompiler instance has no attribute '_MSVCCompiler__root' The newer implementation of MSVCCompiler in msvc9compiler doesn't have this method, so cannot be used to find the include and library paths. ---------- components: Distutils messages: 242274 nosy: dstufft, eric.araujo, lemburg priority: normal severity: normal status: open title: MSVCCompiler.get_msvc_path() doesn't work on Win x64 versions: Python 2.7 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 17:20:53 2015 From: report at bugs.python.org (Raymond Hettinger) Date: Thu, 30 Apr 2015 15:20:53 +0000 Subject: [issue23910] property_descr_get reuse argument tuple In-Reply-To: <1428696637.37.0.716274154339.issue23910@psf.upfronthosting.co.za> Message-ID: <1430407253.53.0.697720413588.issue23910@psf.upfronthosting.co.za> Changes by Raymond Hettinger : ---------- resolution: -> fixed status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 17:40:57 2015 From: report at bugs.python.org (Marc-Andre Lemburg) Date: Thu, 30 Apr 2015 15:40:57 +0000 Subject: [issue24083] MSVCCompiler.get_msvc_path() doesn't work on Win x64 In-Reply-To: <1430406948.34.0.89684475541.issue24083@psf.upfronthosting.co.za> Message-ID: <1430408457.9.0.620957174229.issue24083@psf.upfronthosting.co.za> Marc-Andre Lemburg added the comment: I checked the registry to find the correct root. This would be Software\Microsoft\VisualStudio\. However, VC 9.0 no longer seems to set the variables the method is looking for, so even if the .__root attribute problem gets fixed, the method would not find anything useful. ---------- status: open -> closed _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 17:43:08 2015 From: report at bugs.python.org (Berker Peksag) Date: Thu, 30 Apr 2015 15:43:08 +0000 Subject: [issue24081] Obsolete caveat in reload() docs In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za> Message-ID: <1430408588.63.0.27783478576.issue24081@psf.upfronthosting.co.za> Changes by Berker Peksag : ---------- nosy: +brett.cannon, eric.snow, ncoghlan _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 18:25:08 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 30 Apr 2015 16:25:08 +0000 Subject: [issue23441] rlcompleter: tab on empty prefix => insert spaces In-Reply-To: <1423650104.74.0.902857510979.issue23441@psf.upfronthosting.co.za> Message-ID: <1430411108.43.0.555553378099.issue23441@psf.upfronthosting.co.za> R. David Murray added the comment: Per the discussion in issue 5845, I'm setting this to release blocker to make sure it gets committed before the next release. I'm also adding 3.4 as I think this is a bug. Any objections to that? ---------- nosy: +larry priority: normal -> release blocker stage: patch review -> commit review type: enhancement -> behavior versions: +Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 18:27:51 2015 From: report at bugs.python.org (Romuald Brunet) Date: Thu, 30 Apr 2015 16:27:51 +0000 Subject: [issue24084] pstats: sub-millisecond display Message-ID: <1430411271.93.0.999844602202.issue24084@psf.upfronthosting.co.za> New submission from Romuald Brunet: When running pstats with functions that take less than 0.5 millisecond (per call for example), the value shown is '0.000, which isn't really helpful. This patch aims to show the value in microseconds instead of seconds for values that would otherwise be displayed as '0.000' (the display may have to be tweaked for non-utf8 users, as the ? character is used) Example output: ncalls tottime percall cumtime percall filename:lineno(function) 9827 0.007 7?s 0.007 7?s {method 'get' of 'dict' objects} 3427 0.009 25?s 0.017 49?s {map} 10701 0.006 5?s 0.006 5?s {method 'lower' of 'str' objects} 31410 0.045 14?s 0.045 14?s {method 'split' of 'str' objects} 10023 0.006 6?s 0.006 6?s {_weakref.proxy} 31801 0.009 2?s 0.009 2?s {len} 3892 0.003 7?s 0.003 7?s {method 'extend' of 'list' objects} 1397 0.001 8?s 0.001 8?s {method 'replace' of 'str' objects} 10488 0.010 9?s 0.010 9?s {method 'string_literal' of '_mysql.connection' objects} 10702 2.620 2447?s 2.620 2447?s {method 'readline' of 'file' objects} 10023 0.004 3?s 0.004 3?s {method 'info' of '_mysql.connection' objects} 10023 0.005 5?s 0.005 5?s {method 'insert_id' of '_mysql.connection' objects} 14327 0.022 15?s 0.022 15?s {method 'rstrip' of 'str' objects} ---------- components: Library (Lib) files: pstats-microseconds.patch keywords: patch messages: 242277 nosy: Romuald priority: normal severity: normal status: open title: pstats: sub-millisecond display type: enhancement Added file: http://bugs.python.org/file39237/pstats-microseconds.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 19:49:30 2015 From: report at bugs.python.org (R. David Murray) Date: Thu, 30 Apr 2015 17:49:30 +0000 Subject: [issue24060] Clearify necessities for logging with timestamps In-Reply-To: <1429996624.15.0.693068386122.issue24060@psf.upfronthosting.co.za> Message-ID: <1430416170.51.0.970042303374.issue24060@psf.upfronthosting.co.za> R. David Murray added the comment: Not to my eyes. It clearly says that if no formatting string is specified, the default is used, and that formatTime is used only if the message string contains asctime. Up to Vinay whether he thinks it is worth adding something like "which does not include a reference to the date/time" after the mention of using the default message if fmt is not supplied. ---------- nosy: +r.david.murray _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 19:56:16 2015 From: report at bugs.python.org (=?utf-8?q?J=C3=A9r=C3=B4me_Laurens?=) Date: Thu, 30 Apr 2015 17:56:16 +0000 Subject: [issue24079] xml.etree.ElementTree.Element.text does not conform to the documentation In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za> Message-ID: <1430416576.79.0.147338541378.issue24079@psf.upfronthosting.co.za> J?r?me Laurens added the comment: The totsstring(..., method='text') is not suitable for the inner text because it adds the tail of the top element. A proper implementation would be def innertext(elt): return (elt.text or '') +''.join(innertext(e)+e.tail for e in elt) that can be included in the doc instead of the mention of the to string trick ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 20:03:22 2015 From: report at bugs.python.org (=?utf-8?q?J=C3=A9r=C3=B4me_Laurens?=) Date: Thu, 30 Apr 2015 18:03:22 +0000 Subject: [issue24079] xml.etree.ElementTree.Element.text does not conform to the documentation In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za> Message-ID: <1430417001.99.0.444648464011.issue24079@psf.upfronthosting.co.za> J?r?me Laurens added the comment: Erratum def innertext(elt): return (elt.text or '') +''.join(innertext(e)+(e.tail or '') for e in elt) ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 20:59:04 2015 From: report at bugs.python.org (Buck Evan) Date: Thu, 30 Apr 2015 18:59:04 +0000 Subject: [issue24085] large memory overhead when pyc is recompiled Message-ID: <1430420344.67.0.572478851339.issue24085@psf.upfronthosting.co.za> New submission from Buck Evan: In the attached example I show that there's a significant memory overhead present whenever a pre-compiled pyc is not present. This only occurs with more than 5225 objects (dictionaries in this case) allocated. At 13756 objects, the mysterious pyc overhead is 50% of memory usage. I've reproduced this issue in python 2.6, 2.7, 3.4. I imagine it's present in all cpythons. $ python -c 'import repro' 16736 $ python -c 'import repro' 8964 $ python -c 'import repro' 8964 $ rm *.pyc; python -c 'import repro' 16740 $ rm *.pyc; python -c 'import repro' 16736 $ rm *.pyc; python -c 'import repro' 16740 ---------- files: repro.py messages: 242281 nosy: bukzor priority: normal severity: normal status: open title: large memory overhead when pyc is recompiled versions: Python 3.4 Added file: http://bugs.python.org/file39238/repro.py _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 21:01:31 2015 From: report at bugs.python.org (Buck Evan) Date: Thu, 30 Apr 2015 19:01:31 +0000 Subject: [issue24085] large memory overhead when pyc is recompiled In-Reply-To: <1430420344.67.0.572478851339.issue24085@psf.upfronthosting.co.za> Message-ID: <1430420491.91.0.833757181944.issue24085@psf.upfronthosting.co.za> Buck Evan added the comment: Also, we've reproduced this in both linux and osx. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 21:12:10 2015 From: report at bugs.python.org (Trevor Bekolay) Date: Thu, 30 Apr 2015 19:12:10 +0000 Subject: [issue24086] Configparser interpolation is unexpected Message-ID: <1430421130.2.0.837084015548.issue24086@psf.upfronthosting.co.za> New submission from Trevor Bekolay: I was having an issue installing a package in Python 3, which installed properly in Python 2. This is the error message I got: Complete output from command python setup.py egg_info: Traceback (most recent call last): ... snip unhelpful traceback ... File "/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/configparser.py", line 423, in _interpolate_some "found: %r" % (rest,)) configparser.Interpolation ---------------------------------------- Command "python setup.py egg_info" failed with error code 1 in /private/var/folders/12/p4ngkfbx2pnb1ln81csjb19c0000gn/T/pip-build-6xhgg5x6/nengo This wasn't a super helpful error message. I managed to figure out that Python 3 (or setuptools?) was attempting to parse my ~/.pypirc file, which raised a configparser.InterpolationSyntaxError because my password contained a percent-sign. Configparser doesn't try to interpolate this string in Python 2, so it worked fine. As a workaround, I've changed my PyPI password, but this failure was quite surprising to me. As for what I would expect to happen, I would not expect interpolation to happen if I don't want it to happen. All of the examples shown on in the docs use the syntax "%(key)s" or "${key}". If this is the only way to interpolate, then why is "%" ambiguous? Surely we can look forward one character, and if it's not "(" then "%" should be interpreted literally. Instead, configparser requires me to disambiguate with "%%". But, this would cause my string to be parsed incorrectly in Python 2's configparser, so I'm unable to make that change. ---------- components: Library (Lib) messages: 242283 nosy: tbekolay priority: normal severity: normal status: open title: Configparser interpolation is unexpected type: behavior versions: Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 21:34:20 2015 From: report at bugs.python.org (Antoine Pitrou) Date: Thu, 30 Apr 2015 19:34:20 +0000 Subject: [issue24085] large memory overhead when pyc is recompiled In-Reply-To: <1430420344.67.0.572478851339.issue24085@psf.upfronthosting.co.za> Message-ID: <1430422460.34.0.589086236959.issue24085@psf.upfronthosting.co.za> Antoine Pitrou added the comment: This is transitory memory consumption. Once the source is compiled to bytecode, memory consumption falls down to its previous level. Do you care that much about it? ---------- nosy: +pitrou _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 21:52:59 2015 From: report at bugs.python.org (Martijn Pieters) Date: Thu, 30 Apr 2015 19:52:59 +0000 Subject: [issue23495] The writer.writerows method should be documented as accepting any iterable (not only a list) In-Reply-To: <1424465153.78.0.58816335685.issue23495@psf.upfronthosting.co.za> Message-ID: <1430423579.04.0.00961906621945.issue23495@psf.upfronthosting.co.za> Martijn Pieters added the comment: I'd be happy to provide a patch for the DictWriter.writerows code; I was naively counting on it accepting an iterable and that it would not pull the whole sequence into memory (while feeding it gigabytes of CSV data). ---------- nosy: +mjpieters _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 22:25:52 2015 From: report at bugs.python.org (Paul Moore) Date: Thu, 30 Apr 2015 20:25:52 +0000 Subject: [issue24087] Documentation doesn't explain the term "coroutine" (PEP 342) Message-ID: <1430425552.31.0.779606074615.issue24087@psf.upfronthosting.co.za> New submission from Paul Moore: Although the new generator methods introduced in PEP 342 are documented, the term "coroutine" is not defined anywhere. In particular, the fact that Python coroutines work in conjunction with an event loop rather than transferring control directly between each other is not mentioned. ---------- assignee: docs at python components: Documentation files: coroutine_docs.patch keywords: needs review, patch messages: 242286 nosy: docs at python, gvanrossum, paul.moore priority: normal severity: normal stage: patch review status: open title: Documentation doesn't explain the term "coroutine" (PEP 342) type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file39239/coroutine_docs.patch _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 22:34:45 2015 From: report at bugs.python.org (Marco Paolini) Date: Thu, 30 Apr 2015 20:34:45 +0000 Subject: [issue24080] asyncio.Event.wait() Task was destroyed but it is pending In-Reply-To: <1430402398.63.0.270088920542.issue24080@psf.upfronthosting.co.za> Message-ID: <1430426085.17.0.246654988852.issue24080@psf.upfronthosting.co.za> Marco Paolini added the comment: KeyboardInterrupt is not handled gently by asyncio (see https://groups.google.com/d/msg/python-tulip/sovg7EIBoXs/m7U-0UXqzSQJ) you could cancel all tasks in the signal handler: ... def sig_interrupt(): print('interrupt') for task in asyncio.Task.all_tasks(): task.cancel() loop.add_signal_handler(signal.SIGINT, sig_interrupt) ... ---------- nosy: +mpaolini _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 22:57:27 2015 From: report at bugs.python.org (Vinay Sajip) Date: Thu, 30 Apr 2015 20:57:27 +0000 Subject: [issue24060] Clearify necessities for logging with timestamps In-Reply-To: <1429996624.15.0.693068386122.issue24060@psf.upfronthosting.co.za> Message-ID: <1430427447.6.0.155579653019.issue24060@psf.upfronthosting.co.za> Vinay Sajip added the comment: Perhaps I'll just change it to say ... the default value of '%(message)s' is used, which just includes the message in the logging call. To have additional items of information in the formatted output (such as a timestamp), see other placeholder variables ... and then link to the "LogRecord Attributes" section. ---------- _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 23:30:19 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 30 Apr 2015 21:30:19 +0000 Subject: [issue24084] pstats: sub-millisecond display In-Reply-To: <1430411271.93.0.999844602202.issue24084@psf.upfronthosting.co.za> Message-ID: <1430429419.68.0.266002317451.issue24084@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +georg.brandl stage: -> patch review versions: +Python 3.5 _______________________________________ Python tracker _______________________________________ From report at bugs.python.org Thu Apr 30 23:56:33 2015 From: report at bugs.python.org (Ned Deily) Date: Thu, 30 Apr 2015 21:56:33 +0000 Subject: [issue24086] Configparser interpolation is unexpected In-Reply-To: <1430421130.2.0.837084015548.issue24086@psf.upfronthosting.co.za> Message-ID: <1430430993.57.0.148251193176.issue24086@psf.upfronthosting.co.za> Changes by Ned Deily : ---------- nosy: +lukasz.langa versions: +Python 3.5 -Python 3.2, Python 3.3 _______________________________________ Python tracker _______________________________________