In order to improve workflow it is important to collect data about
the process. Even if Python doesn't have any kind of democracy,
meritocracy or other kind of political system (well, dictatorship?),
it is nice to estimate how many people are really involved in the
process of language evolution.
For example, there is a new accepted PEP 440 which is
authored by two people (documented in PEP), and they are
are listed in credits. They definitely put a lot of work in making it
happen. Other people had less chances to monitor the progress,
and in my opinion this is the reason why handling semantic
versioning was not given enough attention - proposing to convert
versions instead of specifying mechanism for packages to
specify alternative versioning system:
But, my opinion is an opinion and it will stay so until it is backed
up by data that can put some weight to my words. This can be
possible if PEP pages allowed people with registered accounts
to provide structured feedback for PEP in a form of three metrics:
% of text read - 0 .. 100% (approximate)
Text clarity - 0 .. 5 (how hard to understand the text)
PEP coverage - 0 .. 5 (does the PEP cover your case well)
Accept / Reject / Clarify / meh.
When I select "enhancement" it would be nice for the version to be
filled with the current dev version. Also, the pre-filled priority
should probably be "normal".
(I've been using a laptop's keyboard and trackpad for some time, so I'm
becoming more sensitive to the number of UI actions necessary to
interact with the bug tracker :-))
I would like to ask about the differences between (from the devguide ):
a) stage:needs patch and keywords:patch
b) stage:patch review and keywords:needs review
Aren't those redundant? Why are those keywords needed?
IMHO the keywords ones could be refactored out. Doesn't a issue that's
on stage:needs patch be marked “without patch” (not marked in that case)
and some that is on stage:patch review or above be always marked as
Thanks in advance!
Chatting to an experienced C/C++ developer at PyCon AU today, they
were worried that their *Python* skills might not be good enough to
contribute to CPython. It reminded me of an idea I had a while ago,
but forgot to suggest: adding a keyword specifically to indicate
issues that require some C coding.
My main rationale is that there are some issues that are likely to be
pretty easy *if you already know C*. Adding the extra keyword means we
- easy Python only issues (just the 'easy' keyword)
- easy C or C+Python issues ('easy' and 'requires C' keywords)
- tricky Python only issues (no keywords)
- trick C or C+Python issues (just the 'requires C' keyword)
I'm not particularly enamoured of that specific keyword name, so I'm
interested in two specific kinds of feedback:
1. Does the extra keyword sound useful?
2. Any other suggestions for a name?
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia