A question I occasionally get asked by organisations that use Python
commercially but don't currently employ any core developers themselves
is "How can we prioritise getting particular issues
A related problem we have in the PSF is knowing which core developers
are available for freelance & consulting work when organisations
approach us regarding larger projects. At the moment, those kinds of
referrals are reliant on Board members' personal knowledge of who
amongst the core development team is open to that style of employment
and making direct introductions, which is neither transparent nor
As such, what do folks think of the idea of a new, *opt-in* section in
the developer guide, similar to the current experts index, but
allowing core developers to indicate the ways in which we're willing
to provide paid support.
I'd see four likely sections in such a document:
* Freelance consultants: folks that are available for contract
opportunities at the individual level
* Consulting companies: folks that are available for contract
opportunities, but work for larger consulting organisations rather
than contracting directly
* Commercial redistributors: folks that work for commercial Python
redistributors and are willing and able to both help in getting
customer issues resolved and in acting as a point of escalation for
* Direct employment: folks that work directly for organisations that
use Python extensively, and hence are able to act as a point of
escalation for their colleagues
The latter three categories would be further broken out by employer,
while the first would just be a list of names and professional contact
P.S. Disclosure: I do have my own interests in mind here, both
personally and professionally. At a personal level, I'm a strong
believer in "If you want me to care about your opinion on how I spend
my time, pay me", so it makes sense to me to make it easy for more
commercially-minded core developers to say "Pay me or my employer if
you'd like to influence my time allocation". Professionally, it's
definitely in my interests for both Python core developers and
commercial Python redistributors to be recognised as a group for their
expertise and overall influence on the technology sector.
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
It's that time once again: time to start planning for the 2016 Python
Language Summit! This year the summit will be at the Oregon Convention
Center in Portland, Oregon, USA, on May 28th. Sadly, again this year
Michael Foord won't be in attendance. Barry Warsaw and I are running
the summit for the second time.
The purpose of the event is to disseminate information and spark
conversation among Python core developers. It's our once-a-year chance
to get together and hash out where we're going and what we're doing,
We're making two minor changes this year. First: we're going to
experiment with lightning talks! We may have a bunch at the end, or we
may throw some in between longer presentations--not sure yet, we'll see
how it goes. In the grand tradition of lightning talks, they'll be
scheduled exclusively on the day of the summit. We'll provide a
whiteboard or other drawable surface in case you don't show up with
slides, and wild gesticulation isn't enough.
Second: we're using a Google Form to collect signups. This one form
lets you request an invitation to the summit, and also optionally
propose a talk. Please note: filling out the form does not guarantee
you an invitation. Space is limited; if you're a core developer, your
request for invitation *will* be honored, but we may need to restrict
attendance for others. (Sorry!) Barry and I will email the invitations
Signups are open as of now, and will remain open for six weeks, closing
April 12th. But it'll only take you a minute to fill out the form, so
you might as well do it right now! Signing up sooner will make our
lives easier, too.
You'll find a link to the signup form on the summit's official web page,
One final note. Again this year we're inviting Jake Edge from Linux
Weekly News to attend the summit and provide press coverage. In case
you missed it, Jake did a phenomenal job of covering last year's summit,
giving the reader a very thorough overview of what happened.
Some attendees were worried last year about sharing private or
proprietary information in front of a reporter. Jake, Barry, and I want
to assure you that it's just not a problem. Jake's not there to
embarrass anybody or get anybody in trouble. He said he'd be happy to
work with any attendees about any discussions you want considered "off
We hope to see you at the summit!
On Thu, Mar 3, 2016 at 12:38 PM, Brett Cannon <brett(a)python.org> wrote:
> [...] the maintenance issue we have with ctypes (or at least that's
> my hang-up with it). I think we still have not figured out what code we have
> patched and so no one has been willing to update to a newer version of
> libffi. I think Zachary looked into it and got some distance but never far
> enough to feel comfortable with trying to update things.
Since I've been invoked, I'll try to explain our libffi situation as
far as I understand it. This is just a history lesson, I don't really
have an opinion on what should be done with it. I will opine that we
have some seriously old unmaintained code here, and the whole libffi
situation in cpython is far more complex than is ideal.
We actually have four separate copies of libffi:
Modules/_ctypes/libffi: This is a mostly-vanilla copy of libffi-3.1
(released 19May2014), lightly patched according to
Modules/_ctypes/libffi.diff. This one is used for any non-OSX posix
build that doesn't use `--with-system-ffi`. doko has done a pretty
good job keeping this one relatively up to date.
Modules/_ctypes/libffi_osx: This is a "lightly patched" copy from
somewhere before libffi-2.0, probably. It has barely been touched
since 2009. I've been given to understand that it has modifications
necessary to allow building fat binaries on OSX (Ned or Ronald would
know better than I), but I don't know if such modifications may have
made it upstream since pre-2.0. This one is used for all OSX builds
that don't use `--with-system-ffi`.
Modules/_ctypes/libffi_msvc: This is a heavily patched copy from
27January2004 and is used for all Windows builds. The patches include
additional functionality, namely
(IIRC) returning the number of arguments expected when calling a
foreign function with the wrong number of arguments to allow ctypes to
raise a ValueError instead of crashing. I'm fairly certain those
modifications have not been even submitted upstream, and the
intervening twelve years (and my utter lack of experience working with
asm) scare me away from trying to forward-port the patches from
libffi_msvc. I did attempt to use a vanilla libffi on Windows
sometime in 2014/2015, but ran into the issue that it doesn't have the
features ctypes wants, which made a few fairly basic tests fail.
Modules/_ctypes/libffi_arm_wince: I don't know why we even have this.
Nobody has touched it since ctypes was merged into cpython in 2006.
I just finished doing what was necessary to make Davin a core dev, so let's
welcome our first new core dev of 2016!
And while I'm thinking about it, Davin, if you will be attending PyCon US
this year in Portland, it would be great if you can make the language
summit so we can all meet you in person! Details can be found in