Some functions in cpython are private. These APIs
are called from only python executable or DLL.
They are not called even from extension modules in stdlib.
In this time, I want to keep _PyObject_GetMethod private.
As far as I know, it is used to expose the function from DLL user on Windows.
So I think when the private function is not intended to be
called from outside of DLL, it should not use PyAPI_FUNC.
Am I collect?
Currently, many private APIs uses `PyAPI_FUNC()`.
Is there any downside about having much unnecessary exported functions?
(e.g. slower calling invention is used, bothering link time
optimization, LoadLibrary get slower, etc...)
Inada Naoki <songofacandy(a)gmail.com>
Hey Python developers,
I just published the initial release of PyOxidizer - a utility for
producing self-contained, potentially single file executable Python
applications. You can read more about it at
I wanted to draw this list's attention to it because I think PyOxidizer
could have significant implications for the Python community. And the 2nd
to final section in the blog post is of particular relevance to CPython's
I want to state explicitly that I would prefer to work with the Python
community in whatever appropriate capacity is needed to advance the state
of Python application distribution. (I have already participated in
discussions about PEP 587.) PyOxidizer is still young and there's a long
way to go. But I would love to e.g. implement PyOxidizer with an eye
towards incorporation in official Python packaging tools a few years down
the road. I'm not too familiar with the various day-to-day happenings of
Python and Python Packaging. But if you steer me in the right direction, I
could start getting involved...
I hope you like PyOxidizer!
A reminder: it is time for the next quarterly maintenance release of
Python 3.7. The cutoff for **3.7.4rc1** had been scheduled for this
coming Monday (2019-06-10) but many of us have been focused on feature
code off for 3.8.0, which just took place a few days ago (yay!). So, to
give us all a bit more time to attend to 3.7.x matters, I have moved the
code cutoff a week, to **Monday 2019-06-17** by the end of day AOE.
Please review open issues and ensure that any that you believe need to be
addressed in 3.7.4 are either resolved or marked as a **release
blocker**. Any assistance you can provide in helping resolve issues will
be greatly appreciated! Following the rc1 cutoff, changes merged to the
3.7 branch will be released in 3.7.5 three months from now unless you
mark the issue as a release blocker prior to **3.7.4 final**, planned for
release on **2019-06-28**, and explain why the change should be
cherry-picked into the final release.
I am also scheduling for the same dates the rc1 and final releases of
Python **3.6.9**, which is the first 3.6 security-fix-only source release
since its final bugfix release, 3.6.8, six months ago. If there are any
open security issues that you feel should be backported to 3.6, please
get them in before its cutoff on **2019-06-17** AoE.
Thanks to everyone who has been helping to ensure the continued success
of Python 3.6 and 3.7! Our users truly appreciate it and are showing
their confidence in us by the rapid adoption of these latest releases.
P.S. I have recently updated the 3.7.x release schedule in PEP 537 to
show tentative release dates for the rest of 3.7's bugfix phase. Like
with 3.6, we plan to continue having 3.7.x bugfix releases every three
months until 2020-06-27, two years after the initial release of 3.7.0. At
that point, 3.7.x will enter its security-fix-only phase for an
additional three years.
nad(a)python.org -- 
Nick Coghlan, I'm thinking about what you said, over a year ago, about
finding a new champion for PEP 467. I think it would be a privilege to work
on something like that, which may be used by millions of people over a
period of years or decades.
However, I have decided that I no longer have the time or interest.
This PEP has been open but delayed for years. It was originally written in
2014 (apparently with the expectation that it would be included in Python
3.5). My initial attempt to implement it was in 2016. In 2018, Guido said
"It's too late for 3.7 period, but there's no reason it can't be considered
for 3.8.", but now 3.8 is already in beta.
I didn't realize that this would go on for so long. I was working on a
personal project, and at one point I was wishing for something like the
proposed iterator methods. I thought the details were already decided and I
just had to code the thing, which would take a few weeks or maybe a few
months at most. I did not realize what I was getting myself into.
I wish the best of luck to whoever decides to finish this effort.
Python 3.7.4rc1 and 3.6.9rc1 are now available. 3.7.4rc1 is the release
preview of the next maintenance release of Python 3.7, the latest feature
release of Python. 3.6.9rc1 is the release preview of the first
security-fix release of Python 3.6. Assuming no critical problems are
found prior to 2019-06-28, no code changes are planned between these
release candidates and the final releases. These release candidates are
intended to give you the opportunity to test the new security and bug
fixes in 3.7.4 and security fixes in 3.6.9. We strongly encourage you to
test your projects and report issues found to bugs.python.org as soon as
possible. Please keep in mind that these are preview releases and, thus,
their use is not recommended for production environments.
You can find the release files, a link to their changelogs, and more
nad(a)python.org -- 
I'm writing a function meant to print out the context of a given
function call when executed - for example:
1. def main():
3. _st = stack_trace_closure("/path/to/log")
would print out
for each line when executed. Basic idea is to create a closure and
associate that closure with a filename, then run that closure to print
to the log without needing to give the filename over and over again.
So far so good. But when I write this function, the frames given by
getframeinfo or extract_stack skip the actual calling point of the
function, instead giving back the *point where the closure was
defined*. (in the above example, it would print /path/to/file.py:3,
/path/to/file.py:3 instead of incrementing to show 4 and 5).
However, when I insert a pdb statement, it gives me the expected
calling frame where _st is actually called.
What's going on here? It looks an awful lot like a bug to me, like an
extra frame is being optimized out of of the closure's stack
I've tried this in python2.7 and python3.3, both show this.
thanks much for any info,
def stack_trace_closure(message, file_name=None, frame=3):
fh = open(file_name, "w+")
return stack_trace(message, frame, fh)
def stack_trace(message _frame, fh):
_bt = traceback.extract_stack()
fh.write( "%s:%s - %s" % (_bt[_frame], _bt[_frame], _message))
Just letting everyone know that I signed up any core devs who are going
to be at EuroPython to run sprints :) (including myself, since I'll be
Like PyCon US, the sprints at EuroPython will attract many first-time
contributors, so it will be helpful to have as many people who
understand our workflow around to help out. We might also be able to get
some of our own contributions done.
For those who didn't hear, the EuroPython Society is offering a grant
for core developers to get free attendance at EuroPython (see
https://www.europython-society.org/core-grant). If you take this, it
would be a nice gesture of thanks to help support the sprints!
And in the meantime, if you see an easy bug on the tracker, please mark
it as "Easy" or "Easy (C)" and post an explanation of how to fix it.
That way we will have a good supply of tasks for new contributors.
The implementation of issue 36085 breaks PyQt on Windows as it relies on
PATH to find the Qt DLLs. The problem is that PyQt is built using the
stable ABI and a single wheel is supposed to support all versions of
Python starting with v3.5. On the assumption (perhaps naive) that using
the stable ABI would avoid future compatibility issues, the existing
PyPI wheels have long been tagged with cp38.
Was this issue considered at the time? What is the official view?