[Python-Dev] Not all public names in C API have the "Py" prefix
A number of public typedef names without the "Py" prefix survived the Grand Renaming [1]. A couple of new names without the "Py" prefix were added after the Grand Renaming (e.g. getter and setter [2]). That names were included in the Stable ABI. The long list of such names can be found in PEP 384 [3]: unaryfunc binaryfunc ternaryfunc inquiry lenfunc ssizeargfunc ssizessizeargfunc ssizeobjargproc ssizessizeobjargproc objobjargproc objobjproc visitproc traverseproc destructor getattrfunc getattrofunc setattrfunc setattrofunc reprfunc hashfunc richcmpfunc getiterfunc iternextfunc descrgetfunc descrsetfunc initproc newfunc allocfunc getter setter And I suppose new names were added since Python 3.2. A couple of underscored name without the "_Py" prefix (e.g. _object, _typeobject) are defined when include "Python.h". Should we to do something with this? Maybe add Py-prefixed aliases and temporary keep old names for compatibility (but allow to hide them if define a special macro)? [1] https://python-history.blogspot.com/2009/03/great-or-grand-renaming.html [2] https://github.com/python/cpython/commit/6d6c1a35e08b95a83dbe47dbd9e6474daff00354 [3] https://www.python.org/dev/peps/pep-0384/ ___ 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] Not all public names in C API have the "Py" prefix
2017-03-27 12:22 GMT+02:00 Serhiy Storchaka : > Should we to do something with this? Maybe add Py-prefixed aliases and > temporary keep old names for compatibility (but allow to hide them if define > a special macro)? Is is possible to keep backward compatibility if an older version of the stable ABI is explicitly requested? Something like: #if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 < 0x0307 #define getter _Py_getter ... #endif Victor ___ 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] Issue #21071: change struct.Struct.format type from bytes to str
Hi I would like to change struct.Struct.format type from bytes to str. I don't expect that anyone uses this attribute, and struct.Struct() constructor accepts both bytes and str. http://bugs.python.org/issue21071 It's just to be convenient: more functions accept str than bytes in Python 3. Example: print() (python3 -bb raises an exceptions if you pass bytes to print). Is anything opposed to breaking the backward compatibility? Victor ___ 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] Not all public names in C API have the "Py" prefix
On 27.03.17 13:43, Victor Stinner wrote: 2017-03-27 12:22 GMT+02:00 Serhiy Storchaka : Should we to do something with this? Maybe add Py-prefixed aliases and temporary keep old names for compatibility (but allow to hide them if define a special macro)? Is is possible to keep backward compatibility if an older version of the stable ABI is explicitly requested? Something like: #if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 < 0x0307 #define getter _Py_getter #endif I think it is better to use typedef than #define. ___ 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] Distutils frozen?
So, I had opened up a PR (#563) to add README.rst to the distutils readme list. Turns out, I didn't read the devguide correctly, and there needed to be an open issue first. Oops. Then I found bpo-11913 (https://bugs.python.org/issue11913), which said: This would be easy to fix, but as it would be considered a new feature, it can’t go into distutils, which is frozen. I interpreted this as being "frozen to new features"...but I can't find any info about that. Anywhere. The devguide doesn't even remotely mention this. A Google search only gives me information on how to freeze modules *using* distutils, which is hardly helpful. FWIW, no one on the PR seemed to mention that, either. If distutils is indeed frozen, shouldn't it be documented somewhere in the devguide? -- Ryan (ライアン) Yoko Shimomura > ryo (supercell/EGOIST) > Hiroyuki Sawano >> everyone else http://refi64.com/ ___ 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] Distutils frozen?
On Mon, 27 Mar 2017 12:32:09 -0500 Ryan Gonzalez wrote: > So, I had opened up a PR (#563) to add README.rst to the distutils readme > list. Turns out, I didn't read the devguide correctly, and there needed to > be an open issue first. Oops. > > Then I found bpo-11913 (https://bugs.python.org/issue11913), which said: > > > This would be easy to fix, but as it would be considered a new feature, it > can’t go into distutils, which is frozen. I've reopened the issue. Feel free to propose a patch! Regards Antoine. ___ 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] Signups for 2017 Python Language Summit are now open
(reposting, cc'ing python-dev) It’s that time again: time to start thinking about the Python Language Summit! The 2017 summit will be held on Wednesday, May 17, from 10am to 4pm, at the Oregon Convention Center in Portland, Oregon, USA. Your befezzled hosts Larry and Barry will once again be at the helm. The summit’s purpose is to disseminate information and spark conversation among core Python developers. It’s our yearly opportunity to get together for an in-person discussion, to review interesting developments of the previous year and hash out where we’re going next. And we have lots to talk about! Since our last summit, Python 3.6 was released, and the main CPython development process has been moved to GitHub. Naturally Python 3.7 development continues apace. Speaking of changes, we’re continuing to evolve the summit. Everyone seemed to like the lightning talks, so we’ll keep those. Everyone seemed to hate us keeping the schedule secret -sorry!- so we’ll make that available beforehand, with the understanding that it’ll be fluid as the day progresses. Due to room size limitations and the yearly increase in participation, we’re limiting summit invitations to just core developers and invited speakers. As usual, we’ll have whiteboards and a projector. But this year we’re adding roaming microphones, so everybody in the room will be able to hear your question! With the help of the ever awesome Ewa, this year we’ll have badge ribbons for Language Summit participants, which we’ll hand out at the summit room in the morning. As with last year, we’re using Google Forms to collect signups. The form will let you request an invitation to the summit and optionally propose a talk. Signups are open now, and will remain open until Wednesday April 12th, 2017. You can find the link to the signup form from the summit’s official web page, here: https://us.pycon.org/2017/events/language-summit/ But never forget: you don’t need to be registered for PyCon in order to attend the summit! One final note. We’re re-inviting Jake Edge from Linux Weekly News to attend the summit and provide press coverage. Jake’s done a phenomenal job of covering the previous two years’ summits, providing valuable information not just for summit attendees, but also for the Python community at large. Jake’s coverage goes a long way toward demystifying the summit, while remaining respectful of confidential information that’s deemed “off the record” ahead of time by participants. We hope to see you at the summit! [BL]arry ___ 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] Not all public names in C API have the "Py" prefix
On Mon, 27 Mar 2017 at 03:23 Serhiy Storchaka wrote: > A number of public typedef names without the "Py" prefix survived the > Grand Renaming [1]. A couple of new names without the "Py" prefix were > added after the Grand Renaming (e.g. getter and setter [2]). > > That names were included in the Stable ABI. The long list of such names > can be found in PEP 384 [3]: > > unaryfunc binaryfunc ternaryfunc inquiry lenfunc ssizeargfunc > ssizessizeargfunc ssizeobjargproc ssizessizeobjargproc objobjargproc > objobjproc visitproc traverseproc destructor getattrfunc getattrofunc > setattrfunc setattrofunc reprfunc hashfunc richcmpfunc getiterfunc > iternextfunc descrgetfunc descrsetfunc initproc newfunc allocfunc getter > setter > > And I suppose new names were added since Python 3.2. > > A couple of underscored name without the "_Py" prefix (e.g. _object, > _typeobject) are defined when include "Python.h". > > Should we to do something with this? Maybe add Py-prefixed aliases and > temporary keep old names for compatibility (but allow to hide them if > define a special macro)? > I think we should at least add aliases somehow. Maybe in a Py4k world we can update the stable ABI and drop names that re not properly prefixed. ___ 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] PyCharm debugger became 40x faster on Python 3.6 thanks to PEP 523
On 03/25/2017 08:57 PM, Terry Reedy wrote: > On 3/25/2017 8:56 AM, Serhiy Storchaka wrote: >> On 25.03.17 12:04, Victor Stinner wrote: >>> https://blog.jetbrains.com/pycharm/2017/03/inside-the-debugger-interview-with-elizaveta-shashkova/ >>> >>> >>> "What changed in Python 3.6 to allow this? >>> >>> The new frame evaluation API was introduced to CPython in PEP 523 and it >>> allows to specify a per-interpreter function pointer to handle the >>> evaluation of frames." >>> >>> Nice! >> >> Awesome! Any chance that pdb can utilize similar technique? Or this >> doesn't make sense for pdb? > > According to the bdb.Bdb docstring, pdb implements a command-line user interface on top of bdb, while bdb.Bdb "takes care of the details of the trace facility". idlelib.debugger similarly implements > a GUI user interface on top of bdb. I am sure that there are other debuggers that build directly or indirectly (via pdb) on bdb. So the question is whether bdb can be enhanced or augmented with a > C-coded _bdb or other new module. > > As I understand it, sys.settrace results in an execution break and function call at each point in the bytecode corresponding to the beginning of a (logical?) line. This add much overhead. In return, > a trace-based debugger allows one to flexibly control stop and go execution either with preset breakpoints* or with interactive commands: step (one line), step into (a function frame), step over (a > function frame), or go to next breakpoint. The last is implemented by the debugger automatically stepping at each break call unless the line is in the existing breakpoint list. > > * Breakpoints can be defined either in an associated editor or with breakpoint commands in the debugger when execution is stopped. > > PEP 523 envisioned an alternate non-trace implementation of 'go to next breakpoint' by a debugger going "as far as to dynamically rewrite bytecode prior to execution to inject e.g. breakpoints in the > bytecode." > https://www.python.org/dev/peps/pep-0523/#debugging > > A debugger doing this could either eliminate the other 'go' commands (easiest) or implement them by either setting temporary breakpoints or temporarily turning tracing on. > > I presume it should be possible to make bdb.Bdb use bytecode breakpoints or add a new class with a similar API. Then any bdb-based debugger to be modified to make the speedup available. pdb-clone, an extension to pdb, gets about those same performance gains over pdb while still using sys.settrace(). pdb-clone runs at a speed of less than twice the speed of the interpreter when pdb runs at about 80 times the speed of the interpreter. See some performance measurements at https://bitbucket.org/xdegaye/pdb-clone/wiki/Performances.md Given those results, it is not clear how one would get a boost of a factor 40 by implementing PEP 523 for the pdb debugger as pdb could already be very close to the speed of the interpreter mostly by implementing in a C extension module the bdb.Bdb methods that check whether the debugger should take control. Setting a trace function with sys.settrace() adds the following incompressible overhead: * 15-20 % overhead: computed goto are not used in the ceval loop when tracing is active. * The trace function receives all the PyTrace_LINE events (even when the frame f_trace is NULL :(). The interpreter calls _PyCode_CheckLineNumber() for each of these events and the processing in this function is the one that is costly. An optimization is done in pdb-clone that swaps the trace function with a profiler function whenever possible (i.e. when there is no need to trace the lines of the function) to avoid calling _PyCode_CheckLineNumber() (the profiler still gets PyTrace_C_CALL events but there is not such overhead with these events). The performance gain obtained with this scheme is about 30%. I think that the main point here is not whether to switch from sys.settrace() to PEP 523, but first to implement the stop_here() bdb.Bdb method in a C extension module. Xavier ___ 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] I will be deleting the cpython-mirror repo on April 10
On the two-month anniversary of the GitHub migration I'm going to delete the old git mirror: https://github.com/python/cpython-mirror. If you have a old PR that got closed with comments or something, now is the time to get those comments off. ___ 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] Distutils frozen?
2017-03-27 19:32 GMT+02:00 Ryan Gonzalez : > Then I found bpo-11913 (https://bugs.python.org/issue11913), which said: > > This would be easy to fix, but as it would be considered a new feature, it > can’t go into distutils, which is frozen. Oh, that painful story. There was a huge "distutils2 project" which failed for some reasons. While distutils2 was developed, it was decided to revert recent changes in distutils to prevent *any kind* of regression and block further changes. But that was in 2011. Today, pip is very popular, released often, take care on backward compatibility on top of setuptools and distutils. Hopefully, parts of distutils2 became distlib which is now a core library of pip. Victor ___ 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 will be deleting the cpython-mirror repo on April 10
Oops, thanks for the reminder! I found two old pull requests that I forgot to rebase and republish on the new CPython Git repository. Victor 2017-03-27 22:13 GMT+02:00 Brett Cannon : > On the two-month anniversary of the GitHub migration I'm going to delete the > old git mirror: https://github.com/python/cpython-mirror. If you have a old > PR that got closed with comments or something, now is the time to get those > comments off. > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com > ___ 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] OpenIndiana and Solaris support
2017-02-08 15:14 GMT+01:00 Jesus Cea : > On 08/02/17 11:24, Victor Stinner wrote: >> So I suggest to drop official Solaris support, but I don't propose to >> remove the C code specific to Solaris. In practice, I suggest to >> remove Solaris and OpenIndiana buildbots since they are broken for >> months and are more annoying than useful. > > Give me a week to move this forward. Last hope. Any update? "One week" was one month ago :-) Victor ___ 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] Reminder: buildbots are alive :-)
Hi, Don't forget our brave buildbots which compile Python to run the full test suite, every day, every night, even if it's raining or worse! Python 3.7: http://buildbot.python.org/all/waterfall?category=3.x.stable&category=3.x.unstable Python 3.6: http://buildbot.python.org/all/waterfall?category=3.6.stable&category=3.6.unstable Python 3.5: http://buildbot.python.org/all/waterfall?category=3.5.stable&category=3.5.unstable Python 2.7: http://buildbot.python.org/all/waterfall?category=2.7.stable&category=2.7.unstable It seems like most buildbots are back to normal (green). I backported ".gitattributes" to 3.5 today to fix the last major known buildbot issue on Windows. I proposed to drop OS X Tiger support since the OS is old, tests are failing, and I don't know how to get access to such old OS nowadays: http://bugs.python.org/issue29915 But Ned Deily wrote that right now, it's the last online macOS buildbot! Moreover, only one test fails and it's a minor regression of test_uuid: http://bugs.python.org/issue29925 For OpenIndiana, I just sent a new ping on the "OpenIndiana and Solaris support" thread on this list. I'm still in favor of removing completely the buildbot. Maybe we can add a new Illumos buildbot slave later? That's all Folks! Victor ___ 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] Issue with _thread.interrupt_main (29926)
https://bugs.python.org/issue29926 was opened as an IDLE issue, which means that most watching the new issues list would ignore it. But I think it is an issue with _thread.interrupt_main (which IDLE calls in respond to ^C) not interrupting time.sleep(n) in main thread*. I tested on Windows, don't know yet about OP. Since there is no Expert's Index listing for _thread (or threading), I am asking here for someone who knows anything to take a look. * >>> time.sleep(10) <... remainder of 10 seconds pass> KeyboardInterrupt >>> I don't know if this is a bug or inherent limitation. -- Terry Jan Reedy ___ 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] Issue with _thread.interrupt_main (29926)
On Mon, Mar 27, 2017 at 10:33:44PM -0400, Terry Reedy wrote: > https://bugs.python.org/issue29926 was opened as an IDLE issue, which > means that most watching the new issues list would ignore it. But I > think it is an issue with _thread.interrupt_main (which IDLE calls in > respond to ^C) not interrupting time.sleep(n) in main thread*. I tested > on Windows, don't know yet about OP. Since there is no Expert's Index > listing for _thread (or threading), I am asking here for someone who > knows anything to take a look. > > * > >>> time.sleep(10) > > > <... remainder of 10 seconds pass> > KeyboardInterrupt I get similar behaviour under Linux. I don't have the debug print, but the KeyboardInterrupt doesn't interrupt the sleep until the 10 seconds are up. -- Steve ___ 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] Issue with _thread.interrupt_main (29926)
On 28 March 2017 at 03:11, Steven D'Aprano wrote: > On Mon, Mar 27, 2017 at 10:33:44PM -0400, Terry Reedy wrote: >> https://bugs.python.org/issue29926 was opened as an IDLE issue, which >> means that most watching the new issues list would ignore it. But I >> think it is an issue with _thread.interrupt_main (which IDLE calls in >> respond to ^C) not interrupting time.sleep(n) in main thread*. I tested >> on Windows, don't know yet about OP. Since there is no Expert's Index >> listing for _thread (or threading), I am asking here for someone who >> knows anything to take a look. >> >> * >> >>> time.sleep(10) >> >> >> <... remainder of 10 seconds pass> >> KeyboardInterrupt > > > I get similar behaviour under Linux. I don't have the debug print, but > the KeyboardInterrupt doesn't interrupt the sleep until the 10 seconds > are up. Looking at the implementation, _thread.interrupt_main just calls PyErr_SetInterrupt. It doesn’t appear to send a signal. I played with “strace” and couldn’t see any evidence of a signal. I guess it just sets a flag that will be polled. To actually interrupt the “sleep” call, you might need to use “pthread_kill” or similar (at least on Unix). ___ 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
