[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2016-05-27 - 2016-06-03) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open5537 ( +8) closed 33416 (+52) total 38953 (+60) Open issues with patches: 2416 Issues opened (41) == #22331: test_io.test_interrupted_write_text() hangs on the buildbot Fr http://bugs.python.org/issue22331 reopened by martin.panter #27137: Python implementation of `functools.partial` is not a class http://bugs.python.org/issue27137 opened by ebarry #27139: Increased test coverage for statistics.median_grouped http://bugs.python.org/issue27139 opened by juliojr77 #27140: Opcode for creating dict with constant keys http://bugs.python.org/issue27140 opened by serhiy.storchaka #27141: Fix collections.UserList shallow copy http://bugs.python.org/issue27141 opened by bar.harel #27142: Default int value with xmlrpclib / xmlrpc.client http://bugs.python.org/issue27142 opened by julienc #27144: concurrent.futures.as_completed() memory inefficiency http://bugs.python.org/issue27144 opened by grzgrzgrz3 #27145: long_add and long_sub might return a new int where &small_ints http://bugs.python.org/issue27145 opened by Oren Milman #27149: Implement socket.sendmsg() for Windows http://bugs.python.org/issue27149 opened by mmarkk #27150: PEP446 (CLOEXEC by default) violation with fcntl.fcntl(..., fc http://bugs.python.org/issue27150 opened by mmarkk #27151: multiprocessing.Process leaves read pipes open (Process.sentin http://bugs.python.org/issue27151 opened by Roman Bolshakov #27152: Additional assert methods for unittest http://bugs.python.org/issue27152 opened by serhiy.storchaka #27154: Regression in file.writelines behavior http://bugs.python.org/issue27154 opened by snaury #27156: IDLE: remove unused code http://bugs.python.org/issue27156 opened by terry.reedy #27157: Unhelpful error message when one calls a subclass of type with http://bugs.python.org/issue27157 opened by ppperry #27161: Confusing exception in Path().with_name http://bugs.python.org/issue27161 opened by Antony.Lee #27162: Add idlelib.interface module http://bugs.python.org/issue27162 opened by terry.reedy #27163: IDLE entry for What's New in Python 3.6 http://bugs.python.org/issue27163 opened by terry.reedy #27164: zlib can't decompress DEFLATE using shared dictionary http://bugs.python.org/issue27164 opened by Vladimir Mihailenco #27165: Skip callables when displaying exception fields in cgitb http://bugs.python.org/issue27165 opened by Adam.BielaÅski #27167: subprocess reports signal as negative exit status, not documen http://bugs.python.org/issue27167 opened by dmacnet #27168: Yury isn't sure comprehensions and await interact correctly http://bugs.python.org/issue27168 opened by njs #27169: __debug__ is not optimized out at compile time for anything bu http://bugs.python.org/issue27169 opened by josh.r #27170: IDLE: remove Toggle Auto Coloring or add to edit menu & doc http://bugs.python.org/issue27170 opened by terry.reedy #27172: Add skip_bound_arg argument to inspect.Signature.from_callable http://bugs.python.org/issue27172 opened by ryan.petrello #27173: Modern Unix key bindings for IDLE http://bugs.python.org/issue27173 opened by serhiy.storchaka #27175: Unpickling Path objects http://bugs.python.org/issue27175 opened by Antony.Lee #27177: re match.group should support __index__ http://bugs.python.org/issue27177 opened by jdemeyer #27179: subprocess uses wrong encoding on Windows http://bugs.python.org/issue27179 opened by davispuh #27180: Doc/pathlib: Please describe the behaviour of Path().rename() http://bugs.python.org/issue27180 opened by hashimo #27181: Add geometric mean to `statistics` module http://bugs.python.org/issue27181 opened by cool-RR #27182: PEP 519 support in the stdlib http://bugs.python.org/issue27182 opened by ethan.furman #27184: Support path objects in the ntpath module http://bugs.python.org/issue27184 opened by ethan.furman #27186: add os.fspath() http://bugs.python.org/issue27186 opened by ethan.furman #27187: Relax __all__ location requirement in PEP 8 http://bugs.python.org/issue27187 opened by barry #27188: sqlite3 execute* methods return value not documented http://bugs.python.org/issue27188 opened by Dave Sawyer #27189: configure --with-lto with clang should find the appropriate ll http://bugs.python.org/issue27189 opened by gregory.p.smith #27190: Check sqlite3_version before allowing check_same_thread = Fals http://bugs.python.org/issue27190 opened by Dave Sawyer #27194: Tarfile superfluous truncate calls slows extraction. http://bugs.python.org/issue27194 opened by fried #27195: Crash when RawIOBase.write(b) evaluates b.format http://bugs.python.org/issue27195 opened by martin.panter #27196: Eliminate 'ThemeChanged' warning when running IDLE tests http://bugs.python.org/iss
[Python-Dev] frame evaluation API PEP
For those of you who follow python-ideas or were at the PyCon US 2016
language summit, you have already seen/heard about this PEP. For those of
you who don't fall into either of those categories, this PEP proposed a
frame evaluation API for CPython. The motivating example of this work has
been Pyjion, the experimental CPython JIT Dino Viehland and I have been
working on in our spare time at Microsoft. The API also works for
debugging, though, as already demonstrated by Google having added a very
similar API internally for debugging purposes.
The PEP is pasted in below and also available in rendered form at
https://github.com/Microsoft/Pyjion/blob/master/pep.rst (I will assign
myself a PEP # once discussion is finished as it's easier to work in git
for this for the rich rendering of the in-progress PEP).
I should mention that the difference from python-ideas and the language
summit in the PEP are the listed support from Google's use of a very
similar API as well as clarifying the co_extra field on code objects
doesn't change their immutability (at least from the view of the PEP).
--
PEP: NNN
Title: Adding a frame evaluation API to CPython
Version: $Revision$
Last-Modified: $Date$
Author: Brett Cannon ,
Dino Viehland
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 16-May-2016
Post-History: 16-May-2016
03-Jun-2016
Abstract
This PEP proposes to expand CPython's C API [#c-api]_ to allow for
the specification of a per-interpreter function pointer to handle the
evaluation of frames [#pyeval_evalframeex]_. This proposal also
suggests adding a new field to code objects [#pycodeobject]_ to store
arbitrary data for use by the frame evaluation function.
Rationale
=
One place where flexibility has been lacking in Python is in the direct
execution of Python code. While CPython's C API [#c-api]_ allows for
constructing the data going into a frame object and then evaluating it
via ``PyEval_EvalFrameEx()`` [#pyeval_evalframeex]_, control over the
execution of Python code comes down to individual objects instead of a
hollistic control of execution at the frame level.
While wanting to have influence over frame evaluation may seem a bit
too low-level, it does open the possibility for things such as a
method-level JIT to be introduced into CPython without CPython itself
having to provide one. By allowing external C code to control frame
evaluation, a JIT can participate in the execution of Python code at
the key point where evaluation occurs. This then allows for a JIT to
conditionally recompile Python bytecode to machine code as desired
while still allowing for executing regular CPython bytecode when
running the JIT is not desired. This can be accomplished by allowing
interpreters to specify what function to call to evaluate a frame. And
by placing the API at the frame evaluation level it allows for a
complete view of the execution environment of the code for the JIT.
This ability to specify a frame evaluation function also allows for
other use-cases beyond just opening CPython up to a JIT. For instance,
it would not be difficult to implement a tracing or profiling function
at the call level with this API. While CPython does provide the
ability to set a tracing or profiling function at the Python level,
this would be able to match the data collection of the profiler and
quite possibly be faster for tracing by simply skipping per-line
tracing support.
It also opens up the possibility of debugging where the frame
evaluation function only performs special debugging work when it
detects it is about to execute a specific code object. In that
instance the bytecode could be theoretically rewritten in-place to
inject a breakpoint function call at the proper point for help in
debugging while not having to do a heavy-handed approach as
required by ``sys.settrace()``.
To help facilitate these use-cases, we are also proposing the adding
of a "scratch space" on code objects via a new field. This will allow
per-code object data to be stored with the code object itself for easy
retrieval by the frame evaluation function as necessary. The field
itself will simply be a ``PyObject *`` type so that any data stored in
the field will participate in normal object memory management.
Proposal
All proposed C API changes below will not be part of the stable ABI.
Expanding ``PyCodeObject``
--
One field is to be added to the ``PyCodeObject`` struct
[#pycodeobject]_::
typedef struct {
...
PyObject *co_extra; /* "Scratch space" for the code object. */
} PyCodeObject;
The ``co_extra`` will be ``NULL`` by default and will not be used by
CPython itself. Third-party code is free to use the field as desired.
Values stored in the field are expected to not be required in order
for the code object to function, allowing the loss of the data of the
field to be acceptable (this keeps the code object as immutable from
a functional
[Python-Dev] I broke the 3.5 branch, apparently
I don't understand how it happened, but apparently I got a merge commit backward and merged 3.6 into 3.5 and pushed it without realizing what had happened. If anyone has any clue how to reverse this cleanly, please let me know. (There are a couple people at the sprints looking in to it, but the mercurial guys aren't here so we are short on experts). My apologies for the mess :( --David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] I broke the 3.5 branch, apparently
On 2016-06-03 22:50, R. David Murray wrote: I don't understand how it happened, but apparently I got a merge commit backward and merged 3.6 into 3.5 and pushed it without realizing what had happened. If anyone has any clue how to reverse this cleanly, please let me know. (There are a couple people at the sprints looking in to it, but the mercurial guys aren't here so we are short on experts). My apologies for the mess :( There's a lot about undoing changes here: http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FIXED: I broke the 3.5 branch, apparently
On Fri, 03 Jun 2016 23:21:25 +0100, MRAB wrote: > On 2016-06-03 22:50, R. David Murray wrote: > > I don't understand how it happened, but apparently I got a merge commit > > backward and merged 3.6 into 3.5 and pushed it without realizing what > > had happened. If anyone has any clue how to reverse this cleanly, > > please let me know. (There are a couple people at the sprints looking > > in to it, but the mercurial guys aren't here so we are short on experts). > > > > My apologies for the mess :( > > > There's a lot about undoing changes here: > > http://hgbook.red-bean.com/read/finding-and-fixing-mistakes.html Ned Deily has fixed the problem. --David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] C99
PEP 7 requires CPython to use C code conforming to the venerable C89 standard. Traditionally, we've been stuck with C89 due to poor C support in MSVC. However, MSVC 2013 and 2015 implement the key features of C99. C99 does not offer anything earth-shattering; here are the features I think we'd find most interesting: - Variable declarations can be on any line: removes possibly the most annoying limitation of C89. - Inline functions: We can make Py_DECREF and Py_INCREF inline functions rather than unpleasant macros. - C++-style line comments: Not an killer feature but commonly used. - Booleans In summary, some niceties that would make CPython hacking a little more fun. So, what say you to updating PEP 7 to allow C99 features for Python 3.6 (in so much as GCC and MSVC support them)? Regards, Benjamin ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
