I propose to promote Xavier de Gaye as a Python core developer.
I noticed that he is proposing good patches since a lot time ago
(first one around 2010! issue #9250). He now looks to be motivated to
help porting CPython to Android. IMHO it's a good thing to support
this platform. It's a common user request, Android platform becomes
more and more popular.
Xavier proposed patches for the Python code, but also on the C code.
To be honest, I didn't look at his work closely, but he looks to be
motivated and have a good knowledge of Python and even CPython
I already asked him if he would like to become a core developer and he
replied that he is ok, but it wouldn't change his motivation to
contribute (he is already motivated ;-)).
Oh, and I propose to be his mentor to start in CPython.
So, what do you think of his profile?
His nickname on bugs.python.org is "xdegaye".
Less french speaking core developers are active last months, so I'm
looking for fresh blood for the French Connection :-D More seriously,
it would be nice if we can recruit more core developers!
On May 23, 2016, at 21:36, Chris Barker - NOAA Federal <chris.barker(a)noaa.gov> wrote:
> It looks like you're still building for OS-X v. 10.6.
> I can't find an official statement, but this:
> Indicates that 10.8 is falling off Apple's support.
> Maybe it's time for a newer baseline.
I agree. There will be changes to the OS X installers during the alpha phase, prior to feature code cutoff. There is a note to that effect in the 3.6.0a1 OS X installer ReadMe and that's why there is only one OS X installer variant for 3.6.0a1.
nad(a)python.org -- 
On behalf of the Python development community and the Python 3.6 release
team, I'm happy to announce the availability of Python 3.6.0a1.
3.6.0a1 is the first of four planned alpha releases of Python 3.6,
the next major release of Python. During the alpha phase, Python 3.6
remains under heavy development: additional features will be added
and existing features may be modified or deleted. Please keep in mind
that this is a preview release and its use is not recommended for
You can find Python 3.6.0a1 here:
The next release of Python 3.6 will be 3.6.0a2, currently scheduled for
nad(a)python.org -- 
Thank you for all of your work so far on our next feature release cycle, Python 3.6. Code checkins for 3.6 began 12 months ago, after the feature code cutoff and beta phase for Python 3.5.0. We are now about to do 3.6.0 alpha 1, our first of 4 alpha and 4 beta releases planned for the next 6 months.
As a reminder, alpha releases are intended to make it easier for the wider community to test the current state of new features and bug fixes for an upcoming Python release as a whole and for us to test the release process. The start of the alpha phase does *not* mean feature development is complete. During the alpha phase, features may be added, modified, or deleted up until the start of the beta phase. Alpha users beware!
3.6.0 beta 1, currently scheduled for 2016-09-07, marks feature code cutoff, at which time new feature development is expected to be complete and no additional features are to be added to 3.6. At the same time, feature development will begin for the following release cycle, 3.7. During the 3.6.0 beta phase, which is planned to end on 2016-12-04 with the first final release candidate, the focus will be on bug fixes and regressions and preparing for the final release. The goal is for the first release candidate to be the same as the final release: that is, no changes will be accepted for 3.6.0 after release candidate 1 without discussion, review, and release manager approval. Please plan accordingly!
Although I've been involved behind the scenes in most releases over the past several years, 3.6.0a1 will be my first as a release manager so no doubt there will be bumps along the way. Many thanks to my fellow release managers, particularly Benjamin, Georg, Larry, and Barry, for their help and support. Your understanding, help, and feedback will be greatly appreciated!
For this first alpha release at least, the release team (primarily Steve Dower and myself) are going to try a slightly different timetable for producing the release. We are planning for the code cutoff for alpha 1 to be on 2016-05-16 around 12:00 UTC; that allows for code checkins to continue through Sunday almost anywhere on the planet. We will then go off and manufacture the release bits and make them available via the python.org website as soon as possible thereafter, assuming no major glitches, that should be no later than 24 hours thereafter.
In the remaining hours until the code cutoff, please get your commits in as soon as possible and please pay attention to the buildbots for possible regressions.
Looking ahead, the next alpha release, 3.6.0a2, will follow in about a month on 2016-06-12, which is a week after the end of the development sprints at US PyCon 2016 in Portland, Oregon. Hope to see you there!
2016-05-16 ~12:00 UTC: code snapshot for 3.6.0 alpha 1
now to 2016-09-07: Alpha phase (unrestricted feature development)
2016-09-07: 3.6.0 feature code freeze, 3.7.0 feature development begins
2016-09-07 to 2016-12-04: 3.6.0 beta phase (bug and regression fixes, no new features)
2016-12-04 3.6.0 release candidate 1 (3.6.0 code freeze)
2016-12-16 3.6.0 release (3.6.0rc1 plus, if necessary, any dire emergency fixes)
Let me know if you have questions or comments. And thanks again for all of your work towards making Python even better!
AKA The Other Ned
nad(a)python.org -- 
Freenode IRC: ned_deily, #python-dev
My hg skills are still fairly basic, and I'm looking for somebody who
can mentor me (or at least point me in the right direction) with respect
to making the same change across multiple versions of Python.
I have just made a one-line change to the 3.6 (default) branch:
and I'll like to apply it to 3.4 and 3.5 as well. I'm not sure if this
is the right language: is this called a merge?
Can somebody point me at the right way to handle this? Last time I had a
change to apply to all three versions, I manually applied it
individually to each branch. I take it that's the wrong way to do it.
We've sent out notices to all talk submitters telling them whether their
talk was accepted or rejected. If you haven't gotten yours yet, check
your spam folder. If you still can't find it, email us!
See you there,
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.