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
If you go to your bugs.python.org account you will notice there is now a
"GitHub Name" field. Please fill that in with your GitHub username sometime
this month. You can see who has already filled in their username by going
Let's aim to have those fields filled in by the end of the month? It's not
a huge deal if you don't get to it in time but it makes my life easier if I
can add everyone to the python-dev -- or maybe python-commiters; haven't
chosen the name yet -- team on GitHub at once instead of piecemeal over
time. I'm hoping to get devinabox, benchmarks, peps, and devguide
repositories moved to GitHub by PyCon US, hence why I'm asking people do
this now instead of later.
This month there were over 350 emails in python-dev with the word
"pathlib" in the title. Yet, despite this massive online debate, nobody
volunteered to present about pathlib at the language summit.
Based on Jake Edge's summary of the conversation from LWN.net we've
boiled down the debate to these six basic positions.
1. We should keep pathlib in the standard library.
2. We should remove pathlib from the standard library.
3. The Path object should inherit from str.
4. The Path object shouldn't inherit from str; it should continue to be
its own unrelated type.
5. We need a new "fspath" protocol.
6. We don't need an "fspath" protocol.
We'd like some volunteers to speak on each of these positions. Speakers
should plan for a maximum of 2 minutes per position. After the six
positions are presented at the summit we'll open the floor for debate.
You're encouraged to volunteer to present more than one! For example,
if you think we need the protocol, you're probably pro- keeping the
object and anti-inherit from str. (Brett, we're looking at /you.)/
Please note, volunteers should be people who are *already invited to the
summit*. We can't invite additional people just for this--and we're
basically full anyway.
p.s. In case you're thinking "That's not fair! I can't make it to the
summit, I don't want to get left out of the decision!" We don't propose
to make any binding decisions at the summit--unless the BDFL makes
pronouncements there of course. This discussion is intended as a quick
face-to-face debate on the topic, both to inform the delegates at the
summit, and to possibly find a rough consensus.
p.p.s. If we mischaracterized the debate, and the positions above aren't
a good distillation, by all means follow up and make a
counter-proposal! We're listening.
I've been holding off on the hope that one or two bugs would get fixes.
But those seem to have stalled. So I think it's time that we pushed out
a 3.5.2. Maybe announcing a schedule will light a fire under some rumps.
I put "Spring 2016" as the release date for 3.5.2 on the 3.5 release
schedule PEP. Officially, spring ends--and summer begins--Tuesday June
21 at 12:24am EDT. However on the off chance that the PyCon sprints are
productive, I want to hold off until those are done, and maybe give it a
couple extra days for the dust to settle. Last sprint day is Sunday
June 5th. So, bottom line, the RC will happen during spring, but the
final release will technically be during summer.
3.5.2 RC 1 - tag Sat June 11, release Sun June 12
3.5.2 Final - tag Sat June 25, release Sun June 26
Any problems with that? Speak up now.
I just pushed an update to the Motivations & Affiliations page in the
Developer Guide: https://hg.python.org/devguide/rev/9a9f32fcb794
That's mainly based on a recent conversation with Brett, where he pointed
- not everyone is going to have a concise personal bio handy, but might
still be happy to provide relevant employer info
- I'd never explicitly posted here to say the page was no longer
The update aims to address both of those observations.
For the first one, I changed the wording of both the overall page and the
guidelines for making new entries to say that "I work for <company> in
<country/continent>" is still useful information to share if folks are
comfortable doing so.
So, if you work for a CPython redistributor, or a large corporate or
institutional user of CPython, and are willing to share that info, I
encourage you to clone the devguide repo and update the revised page.
The reason for that is that professional affiliations give both the PSF and
other organisations with a vested interest in CPython's future a better
- the diversity of use cases encountered directly by current core developers
- the diversity of funding supporting the availability of current core
developers (as even when employers aren't funding contributions directly,
it's our paid work and other sources of income that provide us with the
free time needed for volunteer work like contributing to CPython ourselves,
as well as mentoring other contributors)
The request for regional information primarily relates to the "diversity of
use cases" representation question - the world's a complex place, and
there's no substitute for actually living and working in a region when it
comes to understanding the needs and interests of that region.
For the second one, while I do still consider this page part of an
experiment, the page itself isn't likely to go away at this point. Instead,
I consider the experiment to be a larger one around open source supply
chain management and what happens if you take sustaining engineering
information for a project that could (at least in theory) be obtained by
mining publicly available information, and instead ask contributors if
they're willing to explicitly volunteer that data in a central location.
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!