python-committers April 2016

python-committers@python.org

5 participants
7 discussions

Idea: listing commercial prioritisation options as a new section in the developer guide?

by Nick Coghlan

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 years

Please add your GitHub username to your bugs.python.org account

by Brett Cannon

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.

5 years

2016 Python Language Summit: Can we get volunteers to talk about pathlib?

by Larry Hastings

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.

5 years

Release schedule for Python 3.5.2

by Larry Hastings

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. //arry/

5 years

Tweaks to the Motivations & Affiliations page

by Nick Coghlan

Hi folks, 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 out: - 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 experimental 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 sense of: - 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. Regards, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

5 years

All Language Summit invites have been sent!

by Larry Hastings

Barry and I have sent out notices to everyone who requested an invite--check the inbox for the email address you supplied us with! And boy are our fingers tired, [BL]arry

5 years

Call For Participants For The 2016 Python Language Summit

by Larry Hastings

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, face-to-face. 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 separately. 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, here: https://us.pycon.org/2016/events/langsummit/ 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. https://lwn.net/Articles/639773/ 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 the record". We hope to see you at the summit! [BL]arry

5 years, 1 month

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-committers April 2016