[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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4