Mailman 3 May 2016 - python-committers

Promote Xavier de Gaye as a core developer
by Victor Stinner June 3, 2016

June 3, 2016

Hi, 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 internals. 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! Victor

11 19

Re: [python-committers] [Python-Dev] Python 3.6.0a1 is now available
by Ned Deily May 23, 2016

May 23, 2016

On May 23, 2016, at 21:36, Chris Barker - NOAA Federal <chris.barker(a)noaa.gov> wrote: > Ned, > It looks like you're still building for OS-X v. 10.6. > > I can't find an official statement, but this: > http://www.computerworld.com/article/2950580/operating-systems/the-end-is-n… > > Indicates that 10.8 is falling off Apple's support. > > Maybe it's time for a newer baseline. Chris, 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. Stay tuned! --Ned -- Ned Deily nad(a)python.org -- []

1 0

Python 3.6.0a1 is now available
by Ned Deily May 17, 2016

May 17, 2016

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 production environments. You can find Python 3.6.0a1 here: https://www.python.org/downloads/release/python-360a1/ The next release of Python 3.6 will be 3.6.0a2, currently scheduled for 2016-06-13. Enjoy! --Ned -- Ned Deily nad(a)python.org -- []

1 0

First 3.6.0 alpha release coming up: 2016-05-16 12:00 UTC
by Ned Deily May 13, 2016

May 13, 2016

Hi everyone! 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! To summarize: 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! --Ned D AKA The Other Ned https://www.python.org/dev/peps/pep-0494/ https://docs.python.org/devguide/devcycle.html#stages https://en.wikipedia.org/wiki/Software_release_life_cycle#Alpha https://docs.python.org/devguide/buildbots.html -- Ned Deily nad(a)python.org -- [] Freenode IRC: ned_deily, #python-dev

1 0

Guidance on merging(?)
by Steven D'Aprano May 8, 2016

May 8, 2016

Hi, 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: https://hg.python.org/cpython/rev/2bf4a02f3570 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. Thanks, -- Steve

5 4

2016 Python Language Smmit: All talk submitters have been notified!
by Larry Hastings May 3, 2016

May 3, 2016

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, [BL]arry

1 0

Idea: listing commercial prioritisation options as a new section in the developer guide?
by Nick Coghlan May 3, 2016

May 3, 2016

Hi folks, 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 fixed/reviewed/merged?". 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 fair. 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 their colleagues * 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 details. Regards, Nick. 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

5 8

Please add your GitHub username to your bugs.python.org account
by Brett Cannon May 2, 2016

May 2, 2016

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 to http://bugs.python.org/user?iscommitter=1&@action=search&@sort=username&@pa… . 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.

7 19

2016 Python Language Summit: Can we get volunteers to talk about pathlib?
by Larry Hastings May 1, 2016

May 1, 2016

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. Thanks, [BL]arry 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.

4 6