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

On Mon, Feb 20, 2012 at 11:11 PM, anatoly techtonik <techtonik@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.

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

On Mon, Feb 20, 2012 at 11:11 PM, anatoly techtonik <techtonik@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.