Mailman 3 June 2015 - Python-Dev

Backporting the 3.5+ Windows build project files to 2.7
by Zachary Ware 25 Jun '15

25 Jun '15

Hi, As you may know, Steve Dower put significant effort into rewriting the project files used by the Windows build as part of moving to VC14 as the official compiler for Python 3.5. Compared to the project files for 3.4 (and older), the new project files are smaller, cleaner, simpler, more easily extensible, and in some cases quite a bit more correct. I'd like to backport those new project files to 2.7, and Intel is willing to fund that work as part of making Python ICC compilable on all platforms they support since it makes building Python 2.7 with ICC much easier. I have no intention of changing the version of MSVC used for official 2.7 builds, it *will* remain at MSVC 9.0 (VS 2008) as determined the last time we had a thread about it. VS 2010 and newer can access older compilers (back to 2008) as a 'PlatformToolset' if they're installed, so all we have to do is set the PlatformToolset in the projects at 'v90'. Backporting the projects would make it easier to build 2.7 with a newer compiler, but that's already possible if somebody wants to put enough work into it, the default will be the old compiler, and we can emit big scary warnings if somebody does use a compiler other than v90. With the stipulation that the officially supported compiler won't change, I want to make sure there's no major opposition to replacing the old project files in PCbuild. The old files would move to PC\VS9.0, so they'll still be available and usable if necessary. Using the backported project files to build 2.7 would require two versions of Visual Studio to be installed; VS2010 (or newer) would be required in addition to VS2008. All Windows core developers should already have VS2010 for Python 3.4 (and/or VS2015 for 3.5) and I expect that anyone else who cares enough to still have VS2008 probably has (or can easily get) one of the free editions of VS 2010 or newer, so I don't consider this to be a major issue. The backported files could be added alongside the old files in PCbuild, in a better-named 'NewPCbuild' directory, or in a subdirectory of PC. I would rather replace the old project files in PCbuild, though; I'd like for the backported files to be the recommended way to build, complete with support from PCbuild/build.bat which would make the new project files the default for the buildbots. I have a work-in-progress branch with the backported files in PCbuild, which you can find at https://hg.python.org/sandbox/zware/log/project_files_backport. There are still a couple bugs to work out (and a couple unrelated changes to PC/pyconfig.h), but most everything works as expected. Looking forward to hearing others' opinions, -- Zach

7 17

Is it a Python bug that the main thread of a process created in a daemon thread is a daemon itself?
by Elizabeth Shashkova 25 Jun '15

25 Jun '15

Hello everybody! When I call fork() inside a daemon thread, the main thread in the child process has the "daemon" property set to True. This is very confusing, since the program keeps running while the only thread is a daemon. According to the docs, if all the threads are daemons the program should exit. Here is an example: import os import threading def child(): assert not threading.current_thread().daemon # This shouldn't fail def parent(): new_pid = os.fork() if new_pid == 0: child() else: os.waitpid(new_pid, 0) t = threading.Thread(target=parent) t.setDaemon(True) t.start() t.join() Is it a bug in the CPython implementation? Also let's assume the second example. I have another non-daemon thread in the child process and want to detect this situation. Does anybody know a way to find such fake daemon threads that are really main threads? Best regards, Elizaveta Shashkova.

3 2

CRLF problems in repo
by Rustom Mody 25 Jun '15

25 Jun '15

Hello folks <context> Along with a few students we were preparing to poke around inside the CPython sources. Of course it would be neat if we submitted useful patches... but since I dont expect to get there so fast I thought I'd start by setting up with git which I am more familiar with than mercurial. That resulted in some adventures... including CRLF issues. </context> Some suggestions on both python mentors list and the general user list did not seem to think these completely irrelevant so reporting here. Can submit a bug-report if it looks ok ------------------------- Mixed file -- both LF and CRLF (line 29 LF rest CRLF) Lib/venv/scripts/nt/Activate.ps1 Lib/test/decimaltestdata is a directory with mixed up files -- ie some CRLF some LF files PCbuild/readme.txt: CRLF (explicit) This is fine. Many of the following should (ideally/IMHO) be likewise CRLF (not BIN) *.sln: CRLF but marked as BIN in hgeol PC/example_nt/example.vcproj Emacs shows as Dos file; But not picked up by file; maybe other such Missing BIN pattern from .hgeol *.pdf Note that Doc/library/turtle-star.pdf exists This is most likely a bug Existent file-types with non-existent files in hgeol; Probably harmless *.vsprops *.mk *.dsp *.dsw These seem straightforward CRLF files to me; why BIN in hgeol? Lib/test/test_email/data/msg_26.txt Lib/test/coding20731.py Regards, Rusi

2 3

Computed Goto dispatch for Python 2
by Parasa, Srinivas Vamsi 24 Jun '15

24 Jun '15

Hi All, This is Vamsi from Server Scripting Languages Optimization team at Intel Corporation. Would like to submit a request to enable the computed goto based dispatch in Python 2.x (which happens to be enabled by default in Python 3 given its performance benefits on a wide range of workloads). We talked about this patch with Guido and he encouraged us to submit a request on Python-dev (email conversation with Guido shown at the bottom of this email). Attached is the computed goto patch (along with instructions to run) for Python 2.7.10 (based on the patch submitted by Jeffrey Yasskin at http://bugs.python.org/issue4753). We built and tested this patch for Python 2.7.10 on a Linux machine (Ubuntu 14.04 LTS server, Intel Xeon - Haswell EP CPU with 18 cores, hyper-threading off, turbo off). Below is a summary of the performance we saw on the "grand unified python benchmarks" suite (available at https://hg.python.org/benchmarks/). We made 3 rigorous runs of the following benchmarks. In each rigorous run, a benchmark is run 100 times with and without the computed goto patch. Below we show the average performance boost for the 3 rigorous runs. Python 2.7.10 (original) vs Computed Goto performance Benchmark Delta (rigorous run #1) % Delta (rigorous run #2) % Delta (rigorous run #3) % Avg. Delta % iterative_count 24.48 24.36 23.78 24.2 unpack_sequence 19.06 18.47 19.48 19.0 slowspitfire 14.36 13.41 16.65 14.8 threaded_count 15.85 13.43 13.93 14.4 pystone 10.68 11.67 11.08 11.1 nbody 10.25 8.93 9.28 9.5 go 7.96 8.76 7.69 8.1 pybench 6.3 6.8 7.2 6.8 spectral_norm 5.49 9.37 4.62 6.5 float 6.09 6.2 6.96 6.4 richards 6.19 6.41 6.42 6.3 slowunpickle 6.37 8.78 3.55 6.2 json_dump_v2 1.96 12.53 3.57 6.0 call_simple 6.37 5.91 3.92 5.4 chaos 4.57 5.34 3.85 4.6 call_method_slots 2.63 3.27 7.71 4.5 telco 5.18 1.83 6.47 4.5 simple_logging 3.48 1.57 7.4 4.2 call_method 2.61 5.4 3.88 4.0 chameleon 2.03 6.26 3.2 3.8 fannkuch 3.89 3.19 4.39 3.8 silent_logging 4.33 3.07 3.39 3.6 slowpickle 5.72 -1.12 6.06 3.6 2to3 2.99 3.6 3.45 3.3 etree_iterparse 3.41 2.51 3 3.0 regex_compile 3.44 2.48 2.84 2.9 mako_v2 2.14 1.29 5.22 2.9 meteor_contest 2.01 2.2 3.88 2.7 django 6.68 -1.23 2.56 2.7 formatted_logging 1.97 5.82 -0.11 2.6 hexiom2 2.83 2.1 2.55 2.5 django_v2 1.93 2.53 2.92 2.5 etree_generate 2.38 2.13 2.51 2.3 mako -0.3 9.66 -3.11 2.1 bzr_startup 0.35 1.97 3 1.8 etree_process 1.84 1.01 1.9 1.6 spambayes 1.76 0.76 0.48 1.0 regex_v8 1.96 -0.66 1.63 1.0 html5lib 0.83 0.72 0.97 0.8 normal_startup 1.41 0.39 0.24 0.7 startup_nosite 1.2 0.41 0.42 0.7 etree_parse 0.24 0.9 0.79 0.6 json_load 1.38 0.56 -0.25 0.6 pidigits 0.45 0.33 0.28 0.4 hg_startup 0.32 2.07 -1.41 0.3 rietveld 0.05 0.91 -0.43 0.2 tornado_http 2.34 -0.92 -1.27 0.1 call_method_unknown 0.72 1.26 -1.85 0.0 raytrace -0.35 -0.75 0.94 -0.1 regex_effbot 1.97 -1.18 -2.57 -0.6 fastunpickle -1.65 0.5 -0.88 -0.7 nqueens -2.24 -1.53 -0.81 -1.5 fastpickle -0.74 1.98 -6.26 -1.7 Thanks, Vamsi ------------------------------------------------------------------------------------------------------------------------------------------------------------ From: gvanrossum(a)gmail.com<mailto:gvanrossum@gmail.com> [mailto:gvanrossum@gmail.com] On Behalf Of Guido van Rossum Sent: Tuesday, May 19, 2015 1:59 PM To: Cohn, Robert S Cc: R. David Murray (r.david.murray(a)murrayandwalker.com<mailto:r.david.murray@murrayandwalker.com>) Subject: Re: meeting at PyCon Hi Robert and David, I just skimmed that thread. There were a lot of noises about backporting it to 2.7 but the final message on the topic, by Antoine, claimed it was too late for 2.7. However, that was before we had announced the EOL extension of 2.7 till 2020, and perhaps we were also in denial about 3.x uptake vs. 2.x. So I think it's definitively worth bringing this up. I would start with a post on python-dev linking to the source code for your patch, and adding a message to the original tracker issue too (without reopening it though -- just so the people who were on the bug will be pinged about it). Because of backwards compatibility with previous 2.7.x releases, it's very important that the patch not break anything -- in particular this means you can't add opcodes or change their specification. You will also undoubtedly be asked to test this on a variety of platforms 32-bit and 64-bit that people care about. But I'm sure you're expecting all that. :-) You might also check with Benjamin Peterson, who is the 2.7 release manager. I think he just announced 2.7.10, so it's too late for that, but I assume we'll keep doing 2.7.x releases until 2020. Good luck, --Guido PS. I am assuming you are contributing this under a PSF-accepted license, e.g. Apache 2.0, otherwise it's an automatic nogo. On Tue, May 19, 2015 at 9:33 AM, Cohn, Robert S <robert.s.cohn(a)intel.com<mailto:robert.s.cohn@intel.com>> wrote: Hi Guido, When we met for lunch at pycon, I asked if performance related patches would be ok for python 2.x. My understanding is that you thought it was possible if it did not create a maintainability problem. We have an example now, a 2.7 patch for computed goto based on the implementation in python 3 http://bugs.python.org/issue4753 It increases performance by up to 10% across a wide range of workloads. As I mentioned at lunch, we hired David Murray's company, and he is guiding intel through the development process for cpython. David and I thought it would be good to run this by you before raising the issue on python-dev. Do you have a specific concern about this patch or a more general concern about performance patches to 2.7? Thanks. Robert --------

45 118

Getting ready for Python 3.5
by Barry Warsaw 23 Jun '15

23 Jun '15

[Apologies for the cross-posting! -BAW] For Ubuntu 15.10 (Wily Werewolf), we want to make Python 3.5 the default Python 3 version. It's currently undecided whether we will keep Python 3.4 as a supported version, but a lot of that depends on how easily an archive port to Python 3.5 goes. Ideally, we'd be able to make the switch to 3.5 now ahead of the planned 16.04 LTS release. As part of this work, we've done a partial test rebuild of packages in the archive that depend in some way on Python 3. For now, this is an x86 only partial rebuild in a PPA. In this PPA, we have Python 3.5 as the default Python 3 version, with 3.4 still enabled. You can see the results so far here: https://launchpad.net/~pythoneers/+archive/ubuntu/py35asdefault/+packages TL;DR: of 1065 uploads, we have ~64% success rate. Some caveats: * These are i386 and amd64 only, so we're still in the dark about other architectures. * These are build tests only. While many builds do run the package's test suite, not all packages have test suites, or not all are enabled. Also, we are not running what are called DEP-8 tests, which are various additional smoketests that are run after the package is built, on the built package (e.g. install the package and all its dependencies in a chroot and see if it can be imported in both Python 2 and 3). * Some failures are due to dependency build order, so a simple rebuild may succeed. * Some failures may not be new. Because a lot of packages don't get new uploads for every new Ubuntu version, they may be failing to build for reasons unrelated to Python 3.5. * We may have missed some packages which declare their build dependencies in a way that got past our rather simplistic filter. Our plan is get the success rate up on the PPA, filing and fixing bugs upstream where possible, then to set up a full archive test rebuild, again with 3.5 as default and 3.4 as enabled, to see what other failures may occur. This full archive rebuild will include all the other architectures, and it's possible packages will build on x86 but fail on some other platform. We're also planning on setting up a QA stack to run the DEP-8 tests for packages that have them. In the meantime, you can help! I've started a wiki page listing the backward compatibility breaks I've found so far. Feel free to add to this, or look into the linked issues. Contribute to the wiki or the linked issues. https://wiki.python.org/moin/PortingToPy3k/34to35 Build and install Python 3.5 from source and run your package's test suite in a virtual environment or in tox. (tox 2.1 supports Python 3.5 but it isn't yet available in Debian/Ubuntu - no worries, install tox in a virtualenv and use *that* to run your test suite.) Create a chroot with the py35asdefault PPA enabled, and do some porting there. Here's a good guideline on how to use a PPA. https://help.launchpad.net/Packaging/PPA https://launchpad.net/~pythoneers/+archive/ubuntu/py35asdefault Examine the build failures and see if you can identify or fix the problem. Start with the package details page https://launchpad.net/~pythoneers/+archive/ubuntu/py35asdefault/+packages and drill down into the console logs for specific failures by clicking on the 'amd64' or 'i386' links next to any big red X you see, then clicking on the 'buildlog' link. E.g. http://tinyurl.com/pnpjtv6 Scroll down near the bottom, which is where the failure will most likely be evident. Release new versions of your packages with Python 3.5 support to PyPI so the Debian maintainers and Ubuntu developers can begin to upload compatible versions. If you're a developer for other Linux distros or platforms, let's work together! (As is often the case, we'll trail blaze on Ubuntu and push the results upstream to Debian as much as possible.) Follow up here on any of the CC'd mailing lists, email me directly, or ping me on IRC (nick 'barry' on python-dev, ubuntu-release @ freenode, debian-python @ OFTC). Python 3.5 is in beta, with a final release scheduled for September 2015 (see PEP 478). There's still plenty of time to fix or adjust to issues we find but there are a ton of packages, so all help is greatly appreciated. Let's make Python 3.5 the easiest upgrade ever. Cheers, -Barry

1 0

Unbound locals in class scopes
by Ivan Levkivskyi 23 Jun '15

23 Jun '15

Hello, There appeared a question in the discussion on http://bugs.python.org/issue24129 about documenting the behavior that unbound local variables in a class definition do not follow the normal rules. Guido said 13 years ago that this behavior should not be changed: https://mail.python.org/pipermail/python-dev/2002-April/023428.html, however, things changed a bit in Python 3.4 with the introduction of the LOAD_CLASSDEREF opcode. I just wanted to double-check whether it is still a desired/expected behavior.

4 9

PEP 490: Chain exceptions at C level
by Victor Stinner 23 Jun '15

23 Jun '15

Hi, I didn't get much feedback on this PEP. Since the Python 3.6 branch is open (default), it's probably better to push such change in the beginning of the 3.6 cycle, to catch issues earlier. Are you ok to chain exceptions at C level by default? Relatedi issue: https://bugs.python.org/issue23763 Victor PEP: 490 Title: Chain exceptions at C level Version: $Revision$ Last-Modified: $Date$ Author: Victor Stinner <victor.stinner(a)gmail.com> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 25-March-2015 Python-Version: 3.6 Abstract ======== Chain exceptions at C level, as already done at Python level. Rationale ========= Python 3 introduced a new killer feature: exceptions are chained by default, PEP 3134. Example:: try: raise TypeError("err1") except TypeError: raise ValueError("err2") Output:: Traceback (most recent call last): File "test.py", line 2, in <module> raise TypeError("err1") TypeError: err1 During handling of the above exception, another exception occurred: Traceback (most recent call last): File "test.py", line 4, in <module> raise ValueError("err2") ValueError: err2 Exceptions are chained by default in Python code, but not in extensions written in C. A new private ``_PyErr_ChainExceptions()`` function was introduced in Python 3.4.3 and 3.5 to chain exceptions. Currently, it must be called explicitly to chain exceptions and its usage is not trivial. Example of ``_PyErr_ChainExceptions()`` usage from the ``zipimport`` module to chain the previous ``OSError`` to a new ``ZipImportError`` exception:: PyObject *exc, *val, *tb; PyErr_Fetch(&exc, &val, &tb); PyErr_Format(ZipImportError, "can't open Zip file: %R", archive); _PyErr_ChainExceptions(exc, val, tb); This PEP proposes to also chain exceptions automatically at C level to stay consistent and give more information on failures to help debugging. The previous example becomes simply:: PyErr_Format(ZipImportError, "can't open Zip file: %R", archive); Proposal ======== Modify PyErr_*() functions to chain exceptions ---------------------------------------------- Modify C functions raising exceptions of the Python C API to automatically chain exceptions: modify ``PyErr_SetString()``, ``PyErr_Format()``, ``PyErr_SetNone()``, etc. Modify functions to not chain exceptions ---------------------------------------- Keeping the previous exception is not always interesting when the new exception contains information of the previous exception or even more information, especially when the two exceptions have the same type. Example of an useless exception chain with ``int(str)``:: TypeError: a bytes-like object is required, not 'type' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: int() argument must be a string, a bytes-like object or a number, not 'type' The new ``TypeError`` exception contains more information than the previous exception. The previous exception should be hidden. The ``PyErr_Clear()`` function can be called to clear the current exception before raising a new exception, to not chain the current exception with a new exception. Modify functions to chain exceptions ------------------------------------ Some functions save and then restore the current exception. If a new exception is raised, the exception is currently displayed into sys.stderr or ignored depending on the function. Some of these functions should be modified to chain exceptions instead. Examples of function ignoring the new exception(s): * ``ptrace_enter_call()``: ignore exception * ``subprocess_fork_exec()``: ignore exception raised by enable_gc() * ``t_bootstrap()`` of the ``_thread`` module: ignore exception raised by trying to display the bootstrap function to ``sys.stderr`` * ``PyDict_GetItem()``, ``_PyDict_GetItem_KnownHash()``: ignore exception raised by looking for a key in the dictionary * ``_PyErr_TrySetFromCause()``: ignore exception * ``PyFrame_LocalsToFast()``: ignore exception raised by ``dict_to_map()`` * ``_PyObject_Dump()``: ignore exception. ``_PyObject_Dump()`` is used to debug, to inspect a running process, it should not modify the Python state. * ``Py_ReprLeave()``: ignore exception "because there is no way to report them" * ``type_dealloc()``: ignore exception raised by ``remove_all_subclasses()`` * ``PyObject_ClearWeakRefs()``: ignore exception? * ``call_exc_trace()``, ``call_trace_protected()``: ignore exception * ``remove_importlib_frames()``: ignore exception * ``do_mktuple()``, helper used by ``Py_BuildValue()`` for example: ignore exception? * ``flush_io()``: ignore exception * ``sys_write()``, ``sys_format()``: ignore exception * ``_PyTraceback_Add()``: ignore exception * ``PyTraceBack_Print()``: ignore exception Examples of function displaying the new exception to ``sys.stderr``: * ``atexit_callfuncs()``: display exceptions with ``PyErr_Display()`` and return the latest exception, the function calls multiple callbacks and only returns the latest exception * ``sock_dealloc()``: log the ``ResourceWarning`` exception with ``PyErr_WriteUnraisable()`` * ``slot_tp_del()``: display exception with ``PyErr_WriteUnraisable()`` * ``_PyGen_Finalize()``: display ``gen_close()`` exception with ``PyErr_WriteUnraisable()`` * ``slot_tp_finalize()``: display exception raised by the ``__del__()`` method with ``PyErr_WriteUnraisable()`` * ``PyErr_GivenExceptionMatches()``: display exception raised by ``PyType_IsSubtype()`` with ``PyErr_WriteUnraisable()`` Backward compatibility ====================== A side effect of chaining exceptions is that exceptions store traceback objects which store frame objects which store local variables. Local variables are kept alive by exceptions. A common issue is a reference cycle between local variables and exceptions: an exception is stored in a local variable and the frame indirectly stored in the exception. The cycle only impacts applications storing exceptions. The reference cycle can now be fixed with the new ``traceback.TracebackException`` object introduced in Python 3.5. It stores informations required to format a full textual traceback without storing local variables. The ``asyncio`` is impacted by the reference cycle issue. This module is also maintained outside Python standard library to release a version for Python 3.3. ``traceback.TracebackException`` will maybe be backported in a private ``asyncio`` module to fix reference cycle issues. Alternatives ============ No change --------- A new private ``_PyErr_ChainExceptions()`` function is enough to chain manually exceptions. Exceptions will only be chained explicitly where it makes sense. New helpers to chain exceptions ------------------------------- Functions like ``PyErr_SetString()`` don't chain automatically exceptions. To make the usage of ``_PyErr_ChainExceptions()`` easier, new private functions are added: * ``_PyErr_SetStringChain(exc_type, message)`` * ``_PyErr_FormatChain(exc_type, format, ...)`` * ``_PyErr_SetNoneChain(exc_type)`` * ``_PyErr_SetObjectChain(exc_type, exc_value)`` Helper functions to raise specific exceptions like ``_PyErr_SetKeyError(key)`` or ``PyErr_SetImportError(message, name, path)`` don't chain exceptions. The generic ``_PyErr_ChainExceptions(exc_type, exc_value, exc_tb)`` should be used to chain exceptions with these helper functions. Appendix ======== PEPs ---- * `PEP 3134 -- Exception Chaining and Embedded Tracebacks <https://www.python.org/dev/peps/pep-3134/>`_ (Python 3.0): new ``__context__`` and ``__cause__`` attributes for exceptions * `PEP 415 - Implement context suppression with exception attributes <https://www.python.org/dev/peps/pep-0415/>`_ (Python 3.3): ``raise exc from None`` * `PEP 409 - Suppressing exception context <https://www.python.org/dev/peps/pep-0409/>`_ (superseded by the PEP 415) Python C API ------------ The header file ``Include/pyerror.h`` declares functions related to exceptions. Functions raising exceptions: * ``PyErr_SetNone(exc_type)`` * ``PyErr_SetObject(exc_type, exc_value)`` * ``PyErr_SetString(exc_type, message)`` * ``PyErr_Format(exc, format, ...)`` Helpers to raise specific exceptions: * ``PyErr_BadArgument()`` * ``PyErr_BadInternalCall()`` * ``PyErr_NoMemory()`` * ``PyErr_SetFromErrno(exc)`` * ``PyErr_SetFromWindowsErr(err)`` * ``PyErr_SetImportError(message, name, path)`` * ``_PyErr_SetKeyError(key)`` * ``_PyErr_TrySetFromCause(prefix_format, ...)`` Manage the current exception: * ``PyErr_Clear()``: clear the current exception, like ``except: pass`` * ``PyErr_Fetch(exc_type, exc_value, exc_tb)`` * ``PyErr_Restore(exc_type, exc_value, exc_tb)`` * ``PyErr_GetExcInfo(exc_type, exc_value, exc_tb)`` * ``PyErr_SetExcInfo(exc_type, exc_value, exc_tb)`` Others function to handle exceptions: * ``PyErr_ExceptionMatches(exc)``: check to implement ``except exc: ...`` * ``PyErr_GivenExceptionMatches(exc1, exc2)`` * ``PyErr_NormalizeException(exc_type, exc_value, exc_tb)`` * ``_PyErr_ChainExceptions(exc_type, exc_value, exc_tb)`` Python Issues ------------- Chain exceptions: * `Issue #23763: Chain exceptions in C <http://bugs.python.org/issue23763>`_ * `Issue #23696: zipimport: chain ImportError to OSError <http://bugs.python.org/issue23696>`_ * `Issue #21715: Chaining exceptions at C level <http://bugs.python.org/issue21715>`_: added ``_PyErr_ChainExceptions()`` * `Issue #18488: sqlite: finalize() method of user function may be called with an exception set if a call to step() method failed <http://bugs.python.org/issue18488>`_ * `Issue #23781: Add private _PyErr_ReplaceException() in 2.7 <http://bugs.python.org/issue23781>`_ * `Issue #23782: Leak in _PyTraceback_Add <http://bugs.python.org/issue23782>`_ Changes preventing to loose exceptions: * `Issue #23571: Raise SystemError if a function returns a result with an exception set <http://bugs.python.org/issue23571>`_ * `Issue #18408: Fixes crashes found by pyfailmalloc <http://bugs.python.org/issue18408>`_ Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End:

7 8

How do people like the early 3.5 branch?
by Larry Hastings 23 Jun '15

23 Jun '15

A quick look through the checkin logs suggests that there's literally nothing happening in 3.6 right now. All the checkins are merges. Is anyone expecting to do work in 3.6 soon? Or did the early branch just create a bunch of make-work for everybody? Monitoring the progress of our experiment, //arry/

5 4

PEP 0420: Extent of implementation? Specifically Python 2?
by triccare triccare 22 Jun '15

22 Jun '15

Greetings, Will this PEP be implemented in Python 2? And, more generally, is there a way to know the extent of implementation of any particular PEP? Thank you for your time.

4 3

async __setitem__
by Martin Teichmann 21 Jun '15

21 Jun '15

Hi everyone, I was really happy to see PEP 492 - that is really a big step forward. It makes many programming constructs possible in combination with asyncio, which have been cumbersome or impossible until now. One thing that still is impossible is to have __setitem__ be used asynchronously. As an example, I am working with a database that I access over the network, and it is easy to write data = await table[key] to get something out of the database. But getting something in, I have to write something like await table.set(key, value) It would be cool if I could just write await table[key] = value which would, I think, fit in nicely with all of PEP 492. That said, I was hesitating which keyword to use, await or async. PEP 492 says something like async is an adjective, await a command. Then for setitem, technically, I would need an adverb, so "asyncly table[key] = value". But I didn't want to introduce yet another keyword (two different ones for the same thing are already confusing enough), so I arbitrarily chose await. If we are really going for it (I don't see the use case yet, I just mention it for completeness), we could also be extend this to other points where variables are set, e.g. "for await i in something():" which is a bit similar to "async for i in something()" yet different. Greetings Martin

5 4