Recently I received 20 one-year licenses from JetBrains for the PyCharm IDE (Professional) and other JetBrains products (the licenses cover their "All Products Pack") for use in Python development. There are 11 licenses available - of the licenses I asked for last year, nine people took them up, so those are in use and come out of the allocation of 20.
Those of you who took up the licences last time should find that the tools continue to work normally. The licences expire on 27 November 2018.
If any others of you are interested in using these licenses, let me know off-list and I will forward the license access details to you. To access the licenses, you will need to have (or create) a JetBrains account.
We of the core dev community commit to supporting Python releases for
five years. Releases get eighteen months of active bug fixes, followed
by three and a half years of security fixes. Python 3.4 turns 5 next
March--at which point we'll stop supporting it, and I'll retire as 3.4
My plan is to make one final release on or around its fifth birthday
containing the last round of security fixes. That's about seven months
from now. Nothing has been merged since the releases of 3.4.9 and 3.5.6
last week, and there are no open PRs against either of those releases.
But! There are still a couple languishing "critical" bugs:
"shutil copy* unsafe on POSIX - they preserve setuid/setgit bits"
"XML vulnerabilities in Python"
"fflush called on pointer to potentially closed file" (Windows only)
It'd be nice to resolve all those issues, one way or another, before we
See you next March,
I've had a few people reach out to me recently (or not so recently; sorry
about that) about renewals for their MSDN subscriptions. If yours is
expired or soon to expire, please send me the email address you're using to
login, your full name, and your mailing address, and after I've received a
bunch of responses I'll send them over and you should get an email from
Microsoft in a few days.
NOTE: If you've contacted me in the last while and haven't received a
response, please respond here. I'm sorry for leaving you hanging.
If you've never had a subscription but would like one, please send me the
email address you'll use as a login, your full name, and your mailing
address. This will give you access to Microsoft's Developer Network, which
includes access to things like Visual Studio and Windows licenses that we
can use for working on Python.
Thanks for everyone's work on Python!
This failed (I think travis, but can't tell now). I thought I could
close it and re-open it to get it to retry, but apparently not. When I
closed it, the backport branch was deleted. At this stage, how do I get
the backport to try again?
I have spotty internet access, so it might take me a while to try this
On Thu, Jul 12, 2018 at 6:35 PM, Łukasz Langa <lukasz(a)langa.pl> wrote:
> I'm +1 to an Informational PEP around the state of the art in project governance.
I think this is a great idea. There's a lot of experience out there on
different governance models, but of course any given project only uses
one of them, so knowledge about what works and what doesn't is pretty
fragmented across the F/OSS community. And this is a really important
decision for us and our users, so we should do due diligence. For
example, we should think this through at least as carefully as we
thought through Github vs. Gitlab :-). A PEP is a good format to start
I volunteer to co-author such a PEP. But I'm not up to doing it on my
own. So... who else wants to be a co-author? (I'm not going to
pressure anyone, but Brett, Mariatta, and Carol, please know that your
names were the first ones that jumped to my mind when thinking about
What I'm thinking:
- While this might eventually produce some recommendations, the
immediate goal would just be to collect together different options and
ideas and point out their trade-offs. I'm guessing most core devs
aren't interested in becoming experts on open-source governance, so
the goal here would be to help the broader community get up to speed
and have a more informed discussion .
- As per the general PEP philosophy, I think this is best done by
having some amount of general discussion on
python-dev/python-committers, plus a small group of coauthors (say 2-4
people) who take responsibility for filtering ideas and organizing
them in a coherent document.
- Places where we'll want to look for ideas:
- The thread already happening on python-committers
- Whatever books / articles / blog posts / etc. we can find (e.g. I
know Karl Fogel's Producing OSS book has some good discussion)
- Other major projects in a similar position to CPython (e.g.,
node.js, Rust) -- what do they do, and what parts are they
- Large Python projects (e.g. Django) -- likewise
If you have suggestions for particularly interesting projects or
excellent writing on the topic, then this thread would be a good place
to mention them.
 The NumPy project has put a lot of energy into working through
governance issues over the last few years, and one thing that
definitely helped was coming up with some "assigned reading" ahead of
the main sprint where we talked about this. NumPy's problems are/were
pretty different from CPython's, but I'm imagining this PEP as filling
a similar role.
Nathaniel J. Smith -- https://vorpus.org
It's been a while since we added a Jython contributor, so I no longer
know what the process would be and we have at least one person we'd
like to add.
Previously, I think the process was:
1) Contributor creates a user on bugs.python.org using their real name.
2) Contributor signs the PSF agreement (not the Jython-specific one,
which is not used anymore).
3) Someone gives contributor push rights to hg.python.org.
Is this still the process for Jython?
Since this is like a CFP I figured we should clarify what's expected the
proposal, and I also wanted to be more detailed in the timeline.
*Oct 1 00:00:00 UTC:* Deadline of coming up with proposals of governance
To be included in the proposal:
- explanation and reasoning of the governance model
- expected roles and responsibilities
- candidate for the role need not be included at this time, since we're
only choosing the governance model. Depending on the governance model
chosen, we might have different people to be nominated. There will be a
separate process for nominating the candidate.
- the term of governance: is it for life? 5 years? 10 years?
Who can submit the proposal?
Python core developers. Individual core devs can submit a proposal, or
co-author the proposal with another core dev.
How to submit the proposal?
Proposal should be in a form of a PEP, and merged into peps repo before Oct
1 00:00:00 UTC. Proposals not merged after Oct 1 00:00:00 UTC will not be
*Oct 1 - Nov 15: Review period.*
All core developers will review the PEPs, and ask any questions to the PEP
author. This timeline allows for enough time for all core devs to carefully
review each PEPs, and for authors to respond.
There will be two parts of this:
*Review phase 1: Oct 1- Nov 1:* Allow changes and tweaks to the proposed
I figured people will have questions and will need to clarify the PEPs
during this period. But if we want the PEP to be final by Oct 1, that's
fine by me. maybe allow typo fixes still.
*Review phase 2: Nov 1 00:00:00 UTC*: No more changes to the above PEPs.
No more tweaks to these PEPs. PRs to these PEPs should be rejected.
This is the final chance to carefully review all governance PEPs, and
formulate your decisions.
*Nov 15 00:00:00 UTC: Voting for new governance model starts, and will go
for 2 weeks*
Send reminders for folks to vote.
Who can vote:
Only core developers can vote.
*Vote will be anonymous.*
*We will use the system used to elect PSF board members.*
*Dec 1 00:00:00 UTC: Voting ended*.
The most voted proposal will be accepted.
Depending on the chosen governance model, we'll begin nominating candidates
to fill the role(s).
*Dec 10 00:00:00 UTC Deadline for nominating candidates to fill the role*
Maybe just one PEP to list all the nominations, instead of separate PEPs of
Who can nominate: Python core developers
Who can be nominated: Python core developers
*Dec 15 00:00:00 UTC Voting for new successor starts*
(Depends on the governance model chosen on Dec 1)
*Who can vote:*
*Only core developers can vote.*
*Vote will be anonymous.*
*We will use the system used to elect PSF board members.*
*Jan 1 00:00:00 UTC Voting for new successor ends.* Most voted candidate(s)
The PSF's Code of Conduct applies to all interactions with core devs
regarding this process, including interactions in any mailing lists, zulip,
IRC, twitter, GitHub, backchannels.
1. For the purpose of eligibility (for voting or writing the PEP), who are
considered as "core developers"? Anyone in python-committers? Anyone on
Python Core GitHub team? Anyone with commit bit? What about core developers
of alternate implementation (PyPy, IronPython, etc)
2. Are people ok UTC timezone?
3. Should this be a PEP?
It's become fairly obvious that we are missing a list of core
developers on some site. One we can use as reference and one
which core devs can also show to other to prove they are
I guess the natural place for such a list is the dev guide,
but we could also use a page on www.python.org, if that's easier
Regarding format, I'd suggest to use the same as PSF Fellows
Note: Asking for this now is not completely unintentional.
The EuroPython Society has something to announce which will
require such a list.
Professional Python Services directly from the Experts (#1, Aug 01 2018)
>>> Python Projects, Coaching and Consulting ... http://www.egenix.com/
>>> Python Database Interfaces ... http://products.egenix.com/
>>> Plone/Zope Database Interfaces ... http://zope.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611