python-committers March 2016

python-committers@python.org

28 participants
5 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

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

The state of our copies of libffi (was: Redoing the C API?)

by Zachary Ware

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. -- Zach

5 years, 1 month

Welcoming Davin Potts to the Python development team

by Brett Cannon

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 https://mail.python.org/pipermail/python-committers/2016-March/003784.html.

5 years, 2 months

Making the PSF CoC apply to core developers

by Brett Cannon

I noticed that the devguide didn't explicitly mention that core developers were expected to follow the PSF CoC ( https://docs.python.org/devguide/coredev.html and https://www.python.org/psf/codeofconduct/, respectively). I have opened http://bugs.python.org/issue26446 to make sure it gets documented. Since this is technically a modification of the requirements of getting commit privileges I wanted to mention it here before I (or anyone else) made the change.

5 years, 2 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-committers March 2016