[Python-ideas] Personal Project Roadmap (Was: sys.path is a hack - bringing it back under control)

[anatoly techtonik]

On Mon, Feb 20, 2012 at 4:58 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 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
> interrupts :)
>
> 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.
>

That's a good insight. That is an interesting info for new people, because
if gives a picture which ideas can be interesting to tackle, because they
have more contributors to help.
-- 
anatoly t.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20120220/c91c763b/attachment.html>