[Python-ideas] Personal Project Roadmap (Was: sys.path is a hack - bringing it back under control)
ncoghlan at gmail.com
Mon Feb 20 14:58:04 CET 2012
On Mon, Feb 20, 2012 at 11:11 PM, anatoly techtonik <techtonik at gmail.com> wrote:
> I think that the idea of personal personal project roadmap would rock.
> If I'd like something to be done faster, I could look at these "other
> things" to see if I can help with some of them. In addition I could copy
> some stuff to my own list to say that I am also interested. Once the item
> reaches the top in somebody's list (or there a critical mass is reached), he
> opens a hangout with other people or schedules a time for discussion.
> The login method is Python account. Items are either bugs from trackers or
> short inline notes in a tree-like structure.
> Will it improve the Python development process?
My own time spent on Python things certainly isn't that organised.
I'll have a couple of items on the "do this next" list (e.g. PEP 394
was at the top of my list recently, and getting PEP 409 finalised now
occupies that spot). However, I may switch to other things based on
external events (e.g. the email I just sent proposing acceptance of
PEP 3144 was based on Georg posting Peter's latest draft, the PEP 408
discussions a short while back that were prompted by Eli following up
on article I'd written some time ago with a full PEP), or because I
want to get them done while they're clear in my mind (e.g. the time I
spent last weekend writing up my summary of the text file processing
in Python 3 Unicode discussion was time that I had previously planned
to spend working on either PEP 394, which had already been resolved by
then, or on PEP 409).
There's a few other things that I'd like to get up on PyPI soon
(especially contextlib2.CallbackStack) so people can tinker with them
for a few months before the first 3.3 beta, which means setting up CI
for contextlib2 before I cut a new release. I also had an illuminating
off-list discussion with the PEP 407 authors and the 3.4 RM that I
want to write up as a new PEP before the language summit in a few
week's time (even though I won't be there in person). Other things
(like revamping the sequence docs to bring them into the modern Python
era or fixing CPython's longstanding operand precedence bug for
sequences implemented in C) have been postponed until after more of
the API related changes are done.
Then there's a whole cloud of "other things to do" (such as all the
bugs I'm nosy on on the tracker, all the issues I created because I
wanted to remember them but didn't have time to address immediately
myself, my perennial efforts to try to make callback-based programming
in Python feel less forced and awkward) that may attract my interest
at any given point in time.
A reference implementation for PEP 395 is definitely in the mix of
things I want to get done, but I'm happy to postpone even thinking
particularly hard about it until after the importlib bootstrapping
effort (which appears to be progressing well) is complete.
And all that's without even considering that I'm doing almost
everything Python related in personal time rather than work time, so
there's plenty of scope for life to intervene with higher priority
My impression is that the other core devs work in a similar fashion -
our personal Python to-do lists are vague, nebulous things, not
well-formed long-term plans (except in particular cases, like specific
PEPs we're working on).
In important ways, Greg Kroah-Hartman's recent description of Linux
kernel development applies to CPython, too: "We always say that Linux
kernel development is 'evolution, not intelligent design,' in that
solutions are found to problems as they come up, so making forecasts
as to what is going to happen in the future is always quite
difficult,". In the CPython case, it's a matter of solutions generally
being achievable with the language *as it already exists* - the
proposed changes are mostly just ways of reducing external
dependencies, or allowing developers to achieve the same results while
writing less code of their own.
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-ideas