[Python-Dev] Developer activity (Was: New winreg module really an improvement?)

Guido van Rossum guido@beopen.com
Fri, 28 Jul 2000 07:53:54 -0500


[Mark H]
> > I fear this may be a general symptom of the new flurry of activity; no-one
> > with a real job can keep up with this list, meaning valuable feedback on
> > many proposals is getting lost.  For example, DigiCool have some obviously
> > smart people, but they are clearly too busy to offer feedback on anything
> > lately.  That is a real shame, and a good resource we are missing out on.

[Thomas W]
> Well, the same goes for Guido.

Not sure what you mean.  I'm too busy to offer feedback on anything?
Give me a break!  I probably spend 4 hours reading and responding to
python-dev each day.

> Much though I liked the discussion about
> slices (and about augmented assignment) yesterday, it took me completely by
> suprise. And I'm not sure what the end result is, either. I don't even know
> whether it's finished or not, and it's not that easy to find out: it could
> be restin', pinin' for the fjords, or it could be nailed to its perch, it
> could be an ex-thread. And if it has ceased to be, well, it didn't amount to
> much, I think. Some opinions, and a simple (but effective, as far as I can
> tell) patch from Michael on one of the sub-issues.

It's still open.  I was trying to respond to your own post where you
considered a redesign of the augmented assignment bytecode.  I still
think the proposed redesign is a good one (always use LOAD a, LOAD b,
AUGASS, STORE b; or LOADSLICE, LOAD b, AUGASS, STORESLICE etc.)

> And I believe that's where PEPs are supposed to come in. They summarise the
> discussions, so that cool and smart people can look through it, see the
> proposal, see the pros and cons, and add their own. I'm not sure if it'll
> *work* like that, given that PEPs take some effort to create, and the format
> is still not too clear (at least, not to me.)

Don't worry too much about the format!  Just write in a style that you
think works for you.  We're specifying the format to ensure that PEPs
contain all the necessary information and are easily readable; I hope
the rules aren't seen as stifling for PEP authors!

> And then there is the stuff
> that keeps popping up and isn't really PEPable: segfaults, tests failing,
> problem areas not covered by tests, unexpected behaviour noone has come
> around to fix or can figure out how to fix, etc.
> 
> Maybe we need a TODO list, to store these issues ? Noone else is keeping
> track, I think, unless it's done in the Jitterbug buglist -- and I can't
> really work with jitterbug, myself. Items on the TODO list that stay on too
> long and start repetetive discussions are clearly candidates for PEPs, but
> others are just longstanding bugs that need to be properly investigated and
> fixed (probably elaborately) and noone disagrees with that. And if the 'fix'
> is non-obvious and involved, and generates too much discussion, it can
> always be PEPulated ;-)
> 
> And if the TODO list needs a maintainer, someone that keeps track of all
> 'issues' that need closer examination, I'd be happy to volunteer. My idea
> would be to limit it to python-dev, unless someone forwards c.l.py traffic
> or other traffic that points out TODO-listable issues.

Actually, Jeremy is the officially appointed 2.0 release manager, and
as far as I can tell he's doing a good job of keeping track of open
issues.  He's also working on transferring the JitterBug database to
the SF Bug Tracker, so we can shut off Jitterbug.

> (Or maybe SF has a good tool for this ? Not being a project admin, I've
> never seen the 'project manager', so I'm not sure if it has anything like a
> 'wishlist' ?)

The SF Bug Trackerwould work, I think.

> PS: Mark, I *do* have a real job, honest ;) I just get to be near my mail
> for about 14 hours a day. (I waste 4 hours to work/home travel, 6 hours to
> sleep/eating.) You should try working for an ISP, too! <wink>

4 hours travel time?  That gets you across the country!  This job must
be real important for you...!

--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)