[Python-Dev] warning before a legal claim (original) (raw)

adam adam@isdn.net.il
Fri, 22 Feb 2002 09:23:54 +0200

warning before a legal claim

Remove us from your announcements list !!

----- Original Message ----- From: <python-dev-request@python.org> To: <python-dev@python.org> Sent: Friday, February 22, 2002 5:56 AM Subject: Python-Dev digest, Vol 1 #1903 - 15 msgs

Send Python-Dev mailing list submissions to python-dev@python.org

To subscribe or unsubscribe via the World Wide Web, visit http://mail.python.org/mailman/listinfo/python-dev or, via email, send a message with subject or body 'help' to python-dev-request@python.org You can reach the person managing the list at python-dev-admin@python.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-Dev digest..."

Today's Topics: 1. Re: Meta-reflections (Kevin Jacobs) 2. RE: Meta-reflections (Tim Peters) 3. Re: Meta-reflections (David Abrahams) 4. Re: Meta-reflections (Samuele Pedroni) 5. RE: Meta-reflections (Tim Peters) 6. RE: Meta-reflections (Tim Peters) 7. Re: Meta-reflections (Guido van Rossum) 8. Re: Meta-reflections (Samuele Pedroni) 9. RE: Meta-reflections (Tim Peters) 10. Re: A little GC confusion (Greg Ewing) 11. Re: Meta-reflections (Anthony Baxter) 12. Re: Meta-reflections (Fred L. Drake, Jr.) 13. Re: [Stackless] Re: [Python-Dev] Stackless Design Q. (Greg Ewing) 14. Re: Meta-reflections (Fred L. Drake, Jr.) 15. Re: [Stackless] Re: [Python-Dev] Stackless Design Q. (Greg Ewing) ------ Message: 1 Date: Thu, 21 Feb 2002 12:30:56 -0500 (EST) From: Kevin Jacobs <jacobs@penguin.theopalgroup.com> To: Samuele Pedroni <pedroni@inf.ethz.ch> cc: "'Python Dev'" <python-dev@python.org> Subject: Re: [Python-Dev] Meta-reflections On Thu, 21 Feb 2002, Samuele Pedroni wrote: > [Kevin Jacobs] > > > > In the process I've found another issue with the slots implementation. > > I'll post the details to python-dev in a separate e-mail. > > > > FYI bug reported only on python-dev have a high probability > to get lost into vacuum (Tim often warns against that). > > Now a seemingly bug is a seemingly bug, so I have reported > your bug to SF: > > http://sourceforge.net/tracker/index.php?func=detail&aid=520644&group_id=547 0&a > tid=105470 > > In general don't expect that someone will post bugs on your behalf. Thanks. I have a collection of about ~8 more bugs that is expending as I grow my test suite. Before I spray all of them onto SF, I want to hear from Guido, since some of my "bugs" are potentially subjective. I have tried three times to post a summary-bug to SF and its not worked (as usual). Is just me or is SF flaky as hell? The last time I tried to post a bug, it kicked me out and was "Down for maintenance" for some time after that. Now it won't let me login since it thinks I haven't responded to the new account confirmation e-mail. Grrrrrrrrrr -Kevin -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com

------ Message: 2 Date: Thu, 21 Feb 2002 16:06:47 -0500 From: Tim Peters <tim.one@comcast.net> Subject: RE: [Python-Dev] Meta-reflections To: 'Python Dev' <python-dev@python.org> [Kevin Jacobs] > ... > I have a collection of about ~8 more bugs that is expending as I > grow my test suite. Before I spray all of them onto SF, I want > to hear from Guido, since some of my "bugs" are potentially subjective. The best way to hear from Guido is to post bugs, and suspected bugs, to SourceForge, one bug per report. There's so much verbiage about this now on Python-Dev that I doubt he'll ever be able to make time to catch up with it when he returns. A great advantage of a good bug report is that it's focused and brief. Slots were definitely intended as a memory optimization, and the ways in which they don't act like "regular old attributes" are at best warts. > I have tried three times to post a summary-bug to SF and its not worked > (as usual). Is just me or is SF flaky as hell? The last time I tried to > post a bug, it kicked me out and was "Down for maintenance" for some time > after that. Now it won't let me login since it thinks I haven't > responded to the new account confirmation e-mail. Grrrrrrrrrr It sounds like you're getting started with SF. Once it agrees not to hate you , life gets a lot easier. It's not flaky in general, but it does suffer bouts of extreme flakiness from time to time. ------ Message: 3 Reply-To: "David Abrahams" <david.abrahams@rcn.com> From: "David Abrahams" <david.abrahams@rcn.com> To: <python-dev@python.org> Subject: Re: [Python-Dev] Meta-reflections Date: Thu, 21 Feb 2002 16:23:36 -0500 FWIW, some of my Boost colleagues have been watching SF's future prospects with some suspicion. The financial outlook is worrisome; I submitted a support request in April 2001 that still hasn't been addressed ( http://sourceforge.net/tracker/?func=detail&aid=414066&group_id=1&atid=35000 1). We're establishing all new services elsewhere, and even moving some old ones. For the long-term health of Python, you might want to make sure you're prepared to move quickly if neccessary. -Dave ----- Original Message ----- From: "Tim Peters" <tim.one@comcast.net> To: "'Python Dev'" <python-dev@python.org> Sent: Thursday, February 21, 2002 4:06 PM Subject: RE: [Python-Dev] Meta-reflections > [Kevin Jacobs] > > ... > > I have a collection of about ~8 more bugs that is expending as I > > grow my test suite. Before I spray all of them onto SF, I want > > to hear from Guido, since some of my "bugs" are potentially subjective. > > The best way to hear from Guido is to post bugs, and suspected bugs, to > SourceForge, one bug per report. There's so much verbiage about this now on > Python-Dev that I doubt he'll ever be able to make time to catch up with it > when he returns. A great advantage of a good bug report is that it's > focused and brief. > > Slots were definitely intended as a memory optimization, and the ways in > which they don't act like "regular old attributes" are at best warts. > > > I have tried three times to post a summary-bug to SF and its not worked > > (as usual). Is just me or is SF flaky as hell? The last time I tried to > > post a bug, it kicked me out and was "Down for maintenance" for some time > > after that. Now it won't let me login since it thinks I haven't > > responded to the new account confirmation e-mail. Grrrrrrrrrr > > It sounds like you're getting started with SF. Once it agrees not to hate > you , life gets a lot easier. It's not flaky in general, but it does > suffer bouts of extreme flakiness from time to time. > > > ________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > ------_ Message: 4 From: "Samuele Pedroni" <pedroni@inf.ethz.ch> To: "Tim Peters" <tim.one@comcast.net>, "'Python Dev'" <python-dev@python.org>, "Kevin Jacobs" <jacobs@penguin.theopalgroup.com> Subject: Re: [Python-Dev] Meta-reflections Date: Thu, 21 Feb 2002 22:13:57 +0100 > [Kevin Jacobs] > > ... > > I have a collection of about ~8 more bugs that is expending as I > > grow my test suite. Before I spray all of them onto SF, I want > > to hear from Guido, since some of my "bugs" are potentially subjective. > > The best way to hear from Guido is to post bugs, and suspected bugs, to > SourceForge, one bug per report. There's so much verbiage about this now on > Python-Dev that I doubt he'll ever be able to make time to catch up with it > when he returns. A great advantage of a good bug report is that it's > focused and brief. It's very true. > Slots were definitely intended as a memory optimization, and the ways in > which they don't act like "regular old attributes" are at best warts. > I see, but it seems that the only way to coherently and transparently remove the warts implies that the dict of a new-style class instance with slots should be tied with the instance and cannot be anymore a vanilla dict. Something only Guido can rule about. some-more-verbiage-ly y'rs - Samuele. ------ Message: 5 Date: Thu, 21 Feb 2002 17:41:18 -0500 From: Tim Peters <tim.one@comcast.net> Subject: RE: [Python-Dev] Meta-reflections To: David Abrahams <david.abrahams@rcn.com> Cc: python-dev@python.org [David Abrahams] > FWIW, some of my Boost colleagues have been watching SF's future > prospects with some suspicion. It's worth a lot, and we do too -- at least in fits, when somebody remembers it's something that's going to kill us someday. > The financial outlook is worrisome; I submitted a > support request in April 2001 that still hasn't been addressed ( > <http://sourceforge.net/tracker/?func=detail&aid=414066&group_id=1&atid=3500 01>). Well, that's really a feature request, and nobody responds well to witty oblique references to the Odyssey except me . > We're establishing all new services elsewhere, and even moving some old > ones. For the long-term health of Python, you might want to make > sure you're prepared to move quickly if neccessary. We supposedly have a cron job set up to suck down Python's CVS tarball every night (the people who would know if this is currently working are out this week). What I don't think we ever figured out how to do was capture the info in the trackers (bugs, patches, feature requests). That would be a major loss, as well as a chance to forget about 500 people who can't figure out how to use threads on HP-UX, so let's call it a wash . ------ Message: 6 Date: Thu, 21 Feb 2002 17:51:13 -0500 From: Tim Peters <tim.one@comcast.net> Subject: RE: [Python-Dev] Meta-reflections To: 'Python Dev' <python-dev@python.org> [Tim] > Slots were definitely intended as a memory optimization, and the ways in > which they don't act like "regular old attributes" are at best warts. [Samuele Pedroni] > I see, but it seems that the only way to coherently and transparently > remove the warts implies that the dict of a new-style class > instance with slots should be tied with the instance and cannot > be anymore a vanilla dict. Something only Guido can rule about. He'll be happy to . Optimizations aren't always wart-free, and then living with warts is a price paid for benefiting from the optimization. I'm sure Guido would consider it "a bug" if slots are ignored by the pickling mechanism, but wouldn't for an instant consider it "a bug" that the set of slots in effect when a class is created can't be dynamically expanded later (this latter is more a sensible restriction than a wart, IMO -- and likely in Guido's too). ------ Message: 7 To: python-dev@python.org Subject: Re: [Python-Dev] Meta-reflections From: Guido van Rossum <guido@python.org> Date: Thu, 21 Feb 2002 19:28:19 -0500 > What I don't think we ever figured out how to do was capture the > info in the trackers (bugs, patches, feature requests). That would > be a major loss, as well as a chance to forget about 500 people who > can't figure out how to use threads on HP-UX, so let's call it a > wash . From a recent SF mailing to project administrators: DATA EXPORT --------------------------- We have added a new tool for project administrators to backup their Project data. It is now possible to export data from the Trackers (bug tracker, support tracker, etc), mailing lists, and forum data in to a single XML text file. This can be done at any time. This is actually not a new feature. The ability to export data was available through March of 2001 until we did a major upgrade of the site, which broke the export scripts. We have now re-worked the code, and it's available again. Enjoy. http://sourceforge.net/export SOMEBODY with admin perms should set up a cron job to such down the nightly XML. It's big! (Are we still sucking down the nightly cvs tarballs? We should!) --Guido van Rossum (home page: http://www.python.org/~guido/) ------ Message: 8 From: "Samuele Pedroni" <pedroni@inf.ethz.ch> To: "Tim Peters" <tim.one@comcast.net>, "'Python Dev'" <python-dev@python.org> Subject: Re: [Python-Dev] Meta-reflections Date: Fri, 22 Feb 2002 01:38:27 +0100 From: Tim Peters <tim.one@comcast.net> > [Tim] > > Slots were definitely intended as a memory optimization, and the ways in > > which they don't act like "regular old attributes" are at best warts. > > [Samuele Pedroni] > > I see, but it seems that the only way to coherently and transparently > > remove the warts implies that the dict of a new-style class > > instance with slots should be tied with the instance and cannot > > be anymore a vanilla dict. Something only Guido can rule about. > > He'll be happy to . Optimizations aren't always wart-free, and then > living with warts is a price paid for benefiting from the optimization. I'm > sure Guido would consider it "a bug" if slots are ignored by the pickling > mechanism, but wouldn't for an instant consider it "a bug" that the set of > slots in effect when a class is created can't be dynamically expanded later > (this latter is more a sensible restriction than a wart, IMO -- and likely > in Guido's too). > I was thinking along the line of the C equiv of this: [Yup the situation of a subclass of a class with slots is more relevant] class C(object): slots = ['a'] class D(C): pass def allslots(cls): mro = list(cls.mro) mro.reverse() allslots = {} for c in mro: cdict = c.dict if 'slots' in cdict: for slot in cdict['slots']: allslots[slot] = cdict[slot] return allslots class slotdict(dict): slots = ['inst','allslots'] def init(self,inst,allslots): self.inst = inst self.allslots = allslots def getitem(self,k): if self.allslots.haskey(k): # self allslots should be reachable as self.inst.class.allslots # AttributeError should become a KeyError ? return self.allslots[k].get(self.inst) else: return dict.getitem(self,v) def setitem(self,k,v): if self.allslots.haskey(k): # self allslots should be reachable as self.inst.class.allslots # AttributeError should become a KeyError ? return self.allslots[k].set(self.inst,v) else: return dict.setitem(self,v) # other methods accordingly d=D() d.dict = slotdict(d,allslots(D)) # should be so automagically # allslots(D) should be probably accessible as d.class.allslots # for transparency C.dict should not contain any slot descr # allslots should be readonly and disallow rebinding # d.dict should disallow rebinding # c =C() ; c.dict should return a proxy dict lazily or even more so ... Lots of things to rule about and trade-offs to consider. the-more-it's-arbitrary-the-more-you-need-one-ruler-ly y'rs - Samuele. ------ Message: 9 Date: Thu, 21 Feb 2002 20:46:35 -0500 From: Tim Peters <tim.one@comcast.net> Subject: RE: [Python-Dev] Meta-reflections To: python-dev@python.org [Guido] > From a recent SF mailing to project administrators: > > DATA EXPORT > --------------------------- Jeremy (and less so I) played with that in the past (before it was publicized), but hit a brick wall: there seemed to be a cap on how many records it would deliver, and we couldn't brute-force our way around it. Maybe it's better now. > ... > SOMEBODY with admin perms should set up a cron job to such down the > nightly XML. It's big! (Are we still sucking down the nightly cvs > tarballs? We should!) IIRC, Barry was doing that on a home machine, and if so he's not around this week to answer. ------ Message: 10 Date: Fri, 22 Feb 2002 15:41:29 +1300 (NZDT) From: Greg Ewing <greg@cosc.canterbury.ac.nz> Subject: Re: [Python-Dev] A little GC confusion To: python-dev@python.org Kevin Jacobs <jacobs@penguin.theopalgroup.com>: > I doesn't have any time to really look at your code, but I thought I'd point > out a trick that several extension modules use to protect statically > allocated type objects. > 0, /* set below / / tpalloc */ > PySocketSocknew, /* tpnew */ > 0, /* set below / / tpfree */ I don't think that has anything to do with protecting the type object. As I understand it, static type objects are protected by having their refcount statically initialised to 1, so that it will never drop to zero. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ ------ Message: 11 To: Tim Peters <tim.one@comcast.net> cc: David Abrahams <david.abrahams@rcn.com>, python-dev@python.org From: Anthony Baxter <anthony@ekit-inc.com> Reply-to: Anthony Baxter <anthony@ekit-inc.com> Subject: Re: [Python-Dev] Meta-reflections Date: Fri, 22 Feb 2002 14:04:57 +1100 >>> Tim Peters wrote > What I don't think we ever figured out how to do was capture the info in the > trackers (bugs, patches, feature requests). That would be a major loss, as > well as a chance to forget about 500 people who can't figure out how to use > threads on HP-UX, so let's call it a wash . I still think adding a 'Resolution' of "HP/UX" would be a good way to clean up the trackers... Anthony. -- Anthony Baxter <anthony@interlink.com.au> It's never to late to have a happy childhood. ------ Message: 12 Date: Thu, 21 Feb 2002 22:17:21 -0500 To: Guido van Rossum <guido@python.org> Cc: python-dev@python.org Subject: Re: [Python-Dev] Meta-reflections From: "Fred L. Drake, Jr." <fdrake@acm.org> Guido van Rossum writes: > SOMEBODY with admin perms should set up a cron job to such down the > nightly XML. It's big! (Are we still sucking down the nightly cvs > tarballs? We should!) It's failing for me now; I'll submit a support request. I think the tarballs are being downloaded to the python.org machine; I'm not sure if they're still landing on Barry's home machine. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation ------ Message: 13 Date: Fri, 22 Feb 2002 16:21:09 +1300 (NZDT) From: Greg Ewing <greg@cosc.canterbury.ac.nz> Subject: Re: [Stackless] Re: [Python-Dev] Stackless Design Q. To: python-dev@python.org, stackless@tismer.com Gordon McMillan <gmcm@hypernet.com>: > You need a way to refer to "this" tasklet from Python Yes, that occurred to me as well. Would a built-in function called currenttasklet() provide what you want? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ ------ Message: 14 Date: Thu, 21 Feb 2002 22:28:14 -0500 To: python-dev@python.org Subject: Re: [Python-Dev] Meta-reflections From: "Fred L. Drake, Jr." <fdrake@acm.org> I wrote: > It's failing for me now; I'll submit a support request. http://sourceforge.net/tracker/index.php?func=detail&aid=521302&group_id=1&a tid=200001 -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation ------ Message: 15 Date: Fri, 22 Feb 2002 16:54:53 +1300 (NZDT) From: Greg Ewing <greg@cosc.canterbury.ac.nz> Subject: Re: [Stackless] Re: [Python-Dev] Stackless Design Q. To: python-dev@python.org, stackless@tismer.com Christian Tismer <tismer@tismer.com>: > Now I see it: You mean I can make this schedule function behave > like a normal function call, that accepts and drops a dummy > value? Yes, that's right. (Or more precisely, it would take no parameters and return None.) > when I have a scheduler counter built into the Python > interpreter loop I can see the attraction of having pre-emption built in this way -- it would indeed be extremely efficient. But I think you need to make a decision about whether your tasklet model is going to be fundamentally pre-emptive or fundamentally non-pre-emptive, because, as I said before, the notion of switching to a specific tasklet is incompatible with pre-emptive scheduling. If you want to go with a fundamentally pre-emptive model, I would suggest the following primitives: t = tasklet(f) Creates a new tasklet executing f. The new tasklet is initially blocked. t.block() Removes tasklet t from the set of runnable tasklets. t.unblock() Adds tasklet t to the set of runnable tasklets. currenttasklet() A built-in function which returns the currently running tasklet. Using this model, a coroutine switch would be implemented using something like def transfer(t): "Transfer from the currently running tasklet to t." t.unblock() currenttasklet().block() although some locking may be needed in there somewhere. Have to think about that some more. For sending values from one tasklet to another, I think I'd use an intermediate object to mediate the transfer, something like a channel in Occam: c = channel() # tasklet 1 does: c.send(value) # tasklet 2 does: value = c.receive() Tasklet 1 blocks at the send() until tasklet 2 reaches the receive(), or vice versa if tasklet 2 reaches the receive() first. When they're both ready, the value is transferred and both tasklets are unblocked. The advantage of this is that it's more symmetrical. Instead of one tasklet having to know about the other, they don't know about each other but they both know about the intermediate object. > I want to provide an exception to kill tasklets. > Also it will be prossible to just pick it off and drop it, > but I'm a little concerned about the C stack inside. As I said before, if there are no references left to a tasklet, there's no way it can ever be switched to again, so its C stack is no longer relevant. Unless you can have return addresses from one C stack pointing into another, or something... can you? Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+ ------

Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev

End of Python-Dev Digest