python-committers September 2015

python-committers@python.org

13 participants
12 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, 2 months

PSA: replace your DSA keys for SSH

by Georg Brandl

Hi all, newer OpenSSH versions (7.0+) default to not allowing ssh-dss keys for public key authentication. If you experience "permission denied" errors, this (currently) comes from the client side only and hg.python.org will accept these keys if you enable them using the PubkeyAcceptedKeyTypes option in your SSH config file. Of course ssh-dss is being phased out for a reason; we'd like to invite everybody who has only DSA keys submitted for hg.python.org access to send an RSA (min. 1024 bits) or ED25519 key to hgaccounts(a)python.org. cheers, Georg

5 years, 9 months

Quick status update on updating our dev process

by Brett Cannon

I just thought I would quickly update everyone on where things stand in terms of fixing our development process to be easier for us to keep up with patches. First, I have given Donald Stufft and Nick Coghlan a deadline of October 31 -- Halloween in North America -- to get demo instances of their approaches for tweaking our approaches (and they were the only ones to propose anything so if you are asking "what about considering XXX?", it's because no one proposed it and stepped up to make sure it happened if their approach was chosen). Nick is proposing using Kalithea and his proposal is found at https://www.python.org/dev/peps/pep-0474/ . Donald is proposing GitHub + Phabricator -- although the Phabricator bit is optional for people -- and his proposal is at https://www.python.org/dev/peps/pep-0481/ . The plan is to get the test instances up, play with them to see what it looks like from both a core dev and contributor perspective and get opinions from various people of different levels of experience as to how the proposals feel. My hope is to make a decision by January 1 so we can switch over ancillary repositories like the devguide, devinabox, and the benchmark suite quickly and then work towards switching the cpython repository. Second, if you find Misc/NEWS a pain when doing merges then have a look at http://bugs.python.org/issue18967 and look at the recent posts. Larry Hastings is proposing a wrapper around `hg commit` that will create individual files per NEWS entry so that you can just pull the file forward in a merge and thus have no issues. We probably need feedback from Windows developers more than anyone since this would make using TortoiseHg a bigger pain since you would need to generate the NEWS file separately before doing your commit while everyone else has it integrated into the commit process. The long term goal is to put a field in the issue tracker for the NEWS entry so that it's directly attached to the issue related to the change and makes it easier to update before a release. So that's the current status. As always, if you want to participate in any of this you should join the core-workflow@ mailing list.

5 years, 10 months

Can't merge into 3.6 (default) branch

by Guido van Rossum

I've made some changes to asyncio but I've run into a snag -- I can't merge the changes from 3.5 into 3.6 (the default branch). It seems some other changes to 3.5 haven't been merged and I don't want to just commit the default merge outcome (which affected a huge number of files). I thought the merge policy was to relentlessly merge everything from 3.5 into 3.6 (using null merges to mark decisions not to copy a specific diff)? -- --Guido van Rossum (python.org/~guido)

5 years, 10 months

3.6 release plans

by Ned Deily

Just a quick update on 3.6 release plans. First, thanks for the kind words. With their help, I will try my best to follow the high standards set by our previous release managers: Larry, Benjamin, Georg, Barry, Martin, et al. As you may have noticed, we don't have a release schedule for 3.6 published yet. One, we've all been busy getting 3.5.0 out the door. Two, with the experimental overlap of next release feature development with the stabilization of the current feature release, feature work for 3.6 has been underway since the feature code freeze for 3.5 (3.5 beta 1). We hope to take advantage of that overlap to shorten the release cycle for 3.6. Three, since accepting the RM role for 3.6 earlier this year, unexpected events - primarily a transcontinental relocation - have taken most of my time for the past few months. Things are now settling back down to a new normal and, starting in about a week, I look forward to devoting a significant amount of time to Python-dev, and specifically 3.6, going forward. I plan to have a 3.6 schedule out for review by Sep 30. In the meantime, please keep up the good work on the already identified features for 3.6 and discussions about additional ones. Here's to another great release! --Ned -- Ned Deily

5 years, 10 months

Re: [python-committers] [Python-Dev] Make stacklevel=2 by default in warnings.warn()

by Serhiy Storchaka

субота, 19-вер-2015 23:55:44 Nathaniel Smith написано: > OTOH I guess if there is anyone out there who's intentionally using > stacklevel=1 they might be reasonably surprised at this change. That is why I ask on Python-Dev instead of just open an issue. But I doubt that there is such case.

5 years, 10 months

[RELEASED] Python 3.5.0 is now available

by Larry Hastings

On behalf of the Python development community and the Python 3.5 release team, I'm proud to announce the availability of Python 3.5.0. Python 3.5.0 is the newest version of the Python language, and it contains many exciting new features and optimizations. You can read all about what's new in Python 3.5.0 here: https://docs.python.org/3.5/whatsnew/3.5.html And you can download Python 3.5.0 here: https://www.python.org/downloads/release/python-350/ Windows and Mac users: please read the important platform-specific "Notes on this release" section near the end of that page. We hope you enjoy Python 3.5.0! //arry/

5 years, 10 months

daily refleaks

by Yury Selivanov

Hi, Does anybody know what happened to daily-refleaks? Yury

5 years, 10 months

[RELEASED] Python 3.5.0rc4 is now available!

by Larry Hastings

On behalf of the Python development community and the Python 3.5 release team, I'm surprised to announce the availability of Python 3.5.0rc4, also known as Python 3.5.0 Release Candidate 4. Python 3.5.0 Release Candidate 3 was only released about a day ago. However: during testing, a major regression was discovered, reported on the issue tracker as #25027: http://bugs.python.org/issue25027 Python 3.5 includes some big changes on how Python is built on Windows. One of those changes resulted in Python processes on Windows exceeding the maximum number of loadable shared libraries. As a result Windows builds of Python could no longer run major Python software stacks like Pandas and Jupyter. Fixing this required non-trivial last-minute changes to the Windows build--and those changes need testing. We therefore elected to insert an extra release candidate before the final release, to get these changes into your hands as soon as possible, so that Windows users could test these changes. As with all other Python 3.5 releases to date, this is a preview release, and its use is not recommended for production settings. However, users are encouraged to test with Python 3.5.0rc4, /especially/ Windows users who build or make use of numerous external packages. (Non-Windows users will find little difference between Python 3.5.0rc3 and Python 3.5.0rc4.) You can find Python 3.5.0rc4 here: https://www.python.org/downloads/release/python-350rc4/ Windows and Mac users: please read the important platform-specific "Notes on this release" section near the end of that page. Please kick the tires, //arry/ p.s. Special thanks from the Python 3.5 release team to Christoph Gohlke for the bug report!

5 years, 10 months

[RELEASED] Python 3.5.0rc3 is now available

by Larry Hastings

On behalf of the Python development community and the Python 3.5 release team, I'm relieved to announce the availability of Python 3.5.0rc3, also known as Python 3.5.0 Release Candidate 3. The next release of Python 3.5 will be Python 3.5.0 final. There should be few (or no) changes to Python 3.5 between rc3 and final. This is a preview release, and its use is not recommended for production settings. You can find Python 3.5.0rc3 here: https://www.python.org/downloads/release/python-350rc3/ Windows and Mac users: please read the important platform-specific "Notes on this release" section near the end of that page. Happy hacking, //arry/

5 years, 10 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-committers September 2015