Mailman 3 February 2002 - Python-Dev

Stackless Design Q.
by Christian Tismer Feb. 22, 2002

Feb. 22, 2002

Hi friends, my tasklets are flying. Now I am at the point where I'm worst suited for: Design an interface. First of all what it is: We have a "tasklet", a tiny object around chains of frames, with some additional structure that keeps C stack snippets. Ignore the details, tasklets are simply the heart of Stackless' coro/uthread/anything. The tstate maintains two lists of tasklets. One is the list of all running (or better "runnable"?) tasklets. These tasklets are not in "value state", they don't want to transmit a value. They can be scheduled as you like it. The other list keeps record of blocked tasklets. These are tasklets which are in "value state", they are waiting to do some transmission. Whenever a tasklet calls an other tasklet's "transfer" method for data transfer, the following happens: - the other tasklet is checked to be in blocked state. - the tasklet is removed from the runnable list, - it is blocked - data is transferred - the other tasklet is unblocked - the other tasklet is inserted into the runnables - the other tasklet is run The "transfer" word comes from Modula II. It implements coroutine behavior. Then, I have something like the ICON suspend, and I gave it the name "suspend" for now, since yield is in use. Suspend is a one-sided thing, and it is also needed to initiate a blocked state at all. Thre is a "client" variable that holds a reference to the tasklet that called "transfer". When suspend is called, then we have two cases: 1) There is another tasklet in the client variable. We take the client and call client.transfer(data) 2) There is no client set already. We go into blocked state and wait, until some tasklet transfers to us. What suspend does is yielding (like in generators), but also initial blocking, providing targets for transfer to jump to. What I'm missing is name and concept of an opposite method: Finish the data transfer, but leave both partners in runnable state. Ok, here a summary of what I have. Please tell me what you think, and what you'd like to change. stackless module: ----------------- schedule() switch to the next task in the runnable list. taskoutlet(func) call it with a function, and it generates a generator for tasklets. ret = suspend(value) initiates data exchange, see above. The current tasklet gets blocked. If client is set already, a transfer is performed. Example: def demo(n): print n factory = taskoutlet(demo) t = factory(42) # this is now a tasklet with bound arguments. tasklet methods: ---------------- t.insert() inserts t into the according tasklet ring at the "end". if t is in a ring already, it is removed first. The ring is either "runnables" or "blocked", depending on t's state. t.remove() removes t from whatever ring it is in. t.run() inserts t into runnables and switches to it immediately. ret = t.transfer(value) unblocks t, tansfers data, blocks myself. *Wanted* Again, What is the name of this function/method, and where does it belong? It - unblocks another tasklet - transfers data - does not block anything - schedules the other tasklet Or is this a bad design at all? If so, please help me as well. Thanks in advance - ciao - chris p.s.: Not all of the above is implemented already. -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net/ 14163 Berlin : PGP key -> http://wwwkeys.pgp.net/ PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com/

5 14

warning before a legal claim
by adam Feb. 21, 2002

Feb. 21, 2002

warning before a legal claim Remove us from your announcements list

1 0

warning before a legal claim
by adam Feb. 21, 2002

Feb. 21, 2002

warning before a legal claim Remove us from your announcements list !!

1 0

warning before a legal claim
by adam Feb. 21, 2002

Feb. 21, 2002

warning before a legal claim Remove us from your announcements list !! ----- Original Message ----- From: <python-dev-request(a)python.org> To: <python-dev(a)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(a)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(a)python.org > > You can reach the person managing the list at > python-dev-admin(a)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(a)penguin.theopalgroup.com> > To: Samuele Pedroni <pedroni(a)inf.ethz.ch> > cc: "'Python Dev'" <python-dev(a)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(a)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(a)comcast.net> > Subject: RE: [Python-Dev] Meta-reflections > To: 'Python Dev' <python-dev(a)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 <wink>, 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(a)rcn.com> > From: "David Abrahams" <david.abrahams(a)rcn.com> > To: <python-dev(a)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(a)comcast.net> > To: "'Python Dev'" <python-dev(a)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 <wink>, 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(a)python.org > > http://mail.python.org/mailman/listinfo/python-dev > > > > > > --__--__-- > > Message: 4 > From: "Samuele Pedroni" <pedroni(a)inf.ethz.ch> > To: "Tim Peters" <tim.one(a)comcast.net>, > "'Python Dev'" <python-dev(a)python.org>, > "Kevin Jacobs" <jacobs(a)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(a)comcast.net> > Subject: RE: [Python-Dev] Meta-reflections > To: David Abrahams <david.abrahams(a)rcn.com> > Cc: python-dev(a)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 <wink>. > > > 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 <wink>. > > > > --__--__-- > > Message: 6 > Date: Thu, 21 Feb 2002 17:51:13 -0500 > From: Tim Peters <tim.one(a)comcast.net> > Subject: RE: [Python-Dev] Meta-reflections > To: 'Python Dev' <python-dev(a)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 <wink>. 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(a)python.org > Subject: Re: [Python-Dev] Meta-reflections > From: Guido van Rossum <guido(a)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 <wink>. > > 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(a)inf.ethz.ch> > To: "Tim Peters" <tim.one(a)comcast.net>, > "'Python Dev'" <python-dev(a)python.org> > Subject: Re: [Python-Dev] Meta-reflections > Date: Fri, 22 Feb 2002 01:38:27 +0100 > > > From: Tim Peters <tim.one(a)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 <wink>. 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.has_key(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.has_key(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(a)comcast.net> > Subject: RE: [Python-Dev] Meta-reflections > To: python-dev(a)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(a)cosc.canterbury.ac.nz> > Subject: Re: [Python-Dev] A little GC confusion > To: python-dev(a)python.org > > Kevin Jacobs <jacobs(a)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 */ /* tp_alloc */ > > PySocketSock_new, /* tp_new */ > > 0, /* set below */ /* tp_free */ > > 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(a)cosc.canterbury.ac.nz +--------------------------------------+ > > > --__--__-- > > Message: 11 > To: Tim Peters <tim.one(a)comcast.net> > cc: David Abrahams <david.abrahams(a)rcn.com>, python-dev(a)python.org > From: Anthony Baxter <anthony(a)ekit-inc.com> > Reply-to: Anthony Baxter <anthony(a)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 <wink>. > > I still think adding a 'Resolution' of "HP/UX" would be a good way to > clean up the trackers... > > Anthony. > > -- > Anthony Baxter <anthony(a)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(a)python.org> > Cc: python-dev(a)python.org > Subject: Re: [Python-Dev] Meta-reflections > From: "Fred L. Drake, Jr." <fdrake(a)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. <fdrake at acm.org> > PythonLabs at Zope Corporation > > > --__--__-- > > Message: 13 > Date: Fri, 22 Feb 2002 16:21:09 +1300 (NZDT) > From: Greg Ewing <greg(a)cosc.canterbury.ac.nz> > Subject: Re: [Stackless] Re: [Python-Dev] Stackless Design Q. > To: python-dev(a)python.org, stackless(a)tismer.com > > Gordon McMillan <gmcm(a)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 current_tasklet() 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(a)cosc.canterbury.ac.nz +--------------------------------------+ > > > --__--__-- > > Message: 14 > Date: Thu, 21 Feb 2002 22:28:14 -0500 > To: python-dev(a)python.org > Subject: Re: [Python-Dev] Meta-reflections > From: "Fred L. Drake, Jr." <fdrake(a)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. <fdrake at acm.org> > PythonLabs at Zope Corporation > > > --__--__-- > > Message: 15 > Date: Fri, 22 Feb 2002 16:54:53 +1300 (NZDT) > From: Greg Ewing <greg(a)cosc.canterbury.ac.nz> > Subject: Re: [Stackless] Re: [Python-Dev] Stackless Design Q. > To: python-dev(a)python.org, stackless(a)tismer.com > > Christian Tismer <tismer(a)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. > > current_tasklet() > 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() > current_tasklet().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(a)cosc.canterbury.ac.nz +--------------------------------------+ > > > > --__--__-- > > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > http://mail.python.org/mailman/listinfo/python-dev > > > End of Python-Dev Digest

1 0

Re: [Python-Dev] Meta-reflections
by Anthony Baxter Feb. 21, 2002

Feb. 21, 2002

>>> 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 <wink>. I still think adding a 'Resolution' of "HP/UX" would be a good way to clean up the trackers... Anthony. -- Anthony Baxter <anthony(a)interlink.com.au> It's never to late to have a happy childhood.

1 0

Re: [Python-Dev] A little GC confusion
by Thomas Heller Feb. 21, 2002

Feb. 21, 2002

From: "David Abrahams" <david.abrahams(a)rcn.com> > From: "Thomas Heller" <thomas.heller(a)ion-tof.com> > > > PS: I have code very similar to yours, and a question: > > > > Why does your class_type_object have PyPyBase_ObjectType as > > tp_base? To implement a subtypable type this is not needed > > IMO, or do I miss something? > > I wanted subclasses of my class_type_object to have the same properties as > new-style classes, so it just made sense to me to do that. > > Python's documentation is... less than complete... so I'm sure I'm missing > something. Sure. Unfortunately, PEP253 still talks of PyType_InitDict instead of PyType_Ready, but we're beyond that already;-) Thomas

1 0

Re: A little GC confusion
by David Abrahams Feb. 21, 2002

Feb. 21, 2002

BTW, I haven't been approved for this list yet, so if you could cc: any replies to me directly at david.abrahams(a)rcn.com it would be greatly appreciated. Thanks, Dave

2 1

Re: [Python-Dev] A little GC confusion
by Michael Hudson Feb. 21, 2002

Feb. 21, 2002

Kevin Jacobs <jacobs(a)penguin.theopalgroup.com> writes: > 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. Here is the code from socketmodule.c: > > /* static PyTypeObject PySocketSock_Type = { > . > . > . > 0, /* set below */ /* tp_alloc */ > PySocketSock_new, /* tp_new */ > 0, /* set below */ /* tp_free */ > }; > > /* buried in init_socket */ > PySocketSock_Type.tp_alloc = PyType_GenericAlloc; > PySocketSock_Type.tp_free = _PyObject_Del; > > This trick ensures that the static type object is never freed. Um, I think you'll find this is because PyType_GenericAlloc & _PyObject_Del aren't compile-time constants when _socket is dynamically linked (they're defined in a different dll). Cheers, M. -- > so python will fork if activestate starts polluting it? I find it more relevant to speculate on whether Python would fork if the merpeople start invading our cities riding on the backs of giant king crabs. -- Brian Quinlan, comp.lang.python

1 0

RE: [Python-Dev] Meta-reflections
by Moore, Paul Feb. 21, 2002

Feb. 21, 2002

From: Kevin Jacobs [mailto:jacobs@penguin.theopalgroup.com] > Having a flat namespace (i.e., no hidden slots), and having > all 'reachable' slots in a single list are really two > separate issues. Right now, we have this situation: > > class Foo(object): > __slots__ = ('a','b') > > class Bar(Foo): > __slots__ = ('c','d') > > bar=Bar() > print bar.__slots__ > > ('c', 'd') > print bar.__class__.__base__.__slots__ > > ('a', 'b') > > I content that bar.__slots__ should be: > > ('a', 'b', 'c', 'd') > > I think somewhere along the line I may have mixed up which > 'flatness' I was> talking about. Um. Be aware that I'm not 100% sure about the "no hidden slots" point. I only support it on the basis of acting the same as attributes. But I'm not sure about it for attributes, either... (although I doubt it will ever change). As for your contention over __slots__, I don't agree. I don't have a strong view, but I feel that __slots__ is really only meant as a way of *defining* the slots (and as such, may be replaced later by better syntax). Think of it as write-only. Modifying it after the class is defined, or reading it, aren't really well defined (and don't need to be). If slot definition had been spelt "slot a" instead of "__slots__ = ['a']", you wouldn't necessarily expect to have a readable attribute containing the list of slots... > > The official, and supported, way is to use dir(). > > I agree, but that "official" support has clear limitations. I'm not sure what you mean. > Right now, there are several examples in the Python standard > library where we use obj.__dict__.keys() -- most significantly > in pickle and cPickle. But aren't we agreed that this is the source of a bug (that slots aren't picklable)? > There is also the vars(obj), which may be the better reflection > method, though it currently doesn't know about slots. Possibly you're right. This could easily be raised as a feature request. And possibly even as a bug (vars() should know about slots). > Naive, maybe, but saying "undocumented" is equivalent to "unsupported > implementation detail" saves us from having to maintain backward > compatibility and following the official Python deprecation process. Equally, saying "it's not in the manual, so tough luck" is unreasonably harsh. We need to be reasonable about this. > > Do you have any reason why you would need to get a list of > > only slots, or only dict-based attributes? > > Yes. Dict-based attributes always have values, while > slot-based attributes can be unset and raise AttributeErrors > when trying to access them. Hmm. I could argue this a couple of ways. Slots should contain None when unassigned (no AttributeErrors), or code should be (re-)written to cope with AttributeError from things in dir(). I wouldn't argue it as "slots can raise AttributeError, so we need to treat slots and dict-based attibutes separately, in 2 passes". > here is how I would handle pickling (excerpt from pickle.py): > > try: > getstate = object.__getstate__ > except AttributeError: > stuff = object.__dict__ > > # added to support slots > if hasattr(object.__slots__): > for slot in object.__slots__: > if hasattr(object, slot): > stuff[slot] = getattr(object, slot) > > else: > stuff = getstate() > _keep_alive(stuff, memo) > save(stuff) > write(BUILD) Why not just change the line stuff = object.__dict__ to stuff = [a for a in dir(object) if hasattr(object,a) and not callable(getattr(object,a))] [The hasattr() gets rid of unbound slots - this may be another argument for unbound slots containing None, and the callable() gets rid of methods]. Then slots are covered, as well as any future non-dict-based attribute types. If vars(obj) was fixed to include slots, like dir() was, then this could be reduced to "stuff = vars(object)" (modulo protection against AttributeError). > I'm not suggesting anything more incestuous and low-level than what is > already done in many, many, many places. A larger, more-encompassing > proposal is definitely welcome. I'm not sure we need a larger proposal. A smaller one may work better. I'm arguing above for 1. Make unbound slots return None rather than AttributeError 2. Make vars() return slots as well as dict-based attributes 3. Document __dict__ as legacy usage, not slots-aware 4. Fix bugs caused by use of the legacy __dict__ approach 5. Educate users in the new approaches which are slots-aware (dir/vars, calling base class setattr, etc) (and maybe a sixth, don't make __slots__ a reflection API - make it an implementation detail, a bit like __dict__ is now viewed) > Well, I've not found resounding agreement on the first two of > my three basic issues/bugs I've raised so far: > > 1) Flat slot namespaces: Objects should not hiding slots > when inherited by classes implementing the same slot name. You're right - I'm not in "resounding" agreement. I think it's probably better, for consistency with dict-based attributes, but I sort of wish it wasn't. (The fact that I've not hit problems because of the equivalent property of attributes means that I'm probably wrong, and attributes are fine as they are, though.) > 2) Flat slot descriptions: object.__slots__ being an > immutable flat tuple of all slot names (including > inherited ones), as opposed to being a potentially > mutable sequence of only the slots defined by the most > derived class. This I disagree with. I think __slots__ should be immutable. But I'm happy with "don't do that" as the way of implementing immutability, if that's what Guido prefers. I definitely don't think __slots__ should return something different when you read it than what you assigned to it in the first place (which is what including inherited slots does). But I don't really think people have any business reading __slots__ in any case (see my arguments above). > 3) First class status for slot reflection: making slots picklable by > default, returned by vars(object), and made part of > other relevant reflection APIs and standard implementations. I agree on this one. Paul.

2 1

Re: [Python-Dev] Meta-reflections
by Moore, Paul Feb. 20, 2002

Feb. 20, 2002

> I fully intend to provide a reference implementation of > some of these ideas. In fact, its likely to be a fairly > small patch. However, I still don't know what the ideal > semantics are. I would very much value your input on the > matter, even if on a purely theoretical level. So, lets > start with the premise that __attrs__ is a declaration like > __slots__ except that: It seems relevant to me that your choice of name ("attrs") indicates a relationship with attributes - which your ideas seem to deny. It is important to make the distinction entirely clear, otherwise your points are going to get obscured. I've been having a hard time keeping track of precisely what you are suggesting (on which basis, thanks for this summary...) > 1) the namespace of these 'attrs' is flat -- repeated > names in descendant classes either results in an error or > silently re-using the existing slot. This maintains the > traditional flat instance namespace of attributes. FWIW, I disagree with this completely. I would expect slots with a particular name in derived classes to hide the same-named slots in base classes. Whether or not the base class slot is available via some sort of "super" shenannigans is less relevant. But hiding semantics is critical. How do you expect to reliably make it possible to derive from a class with slots otherwise? Perl gets into this sort of mess with its implementation of objects. > 2) A complete and immutable list of slots is available > as a member of each type to allow for easy and efficient > reflection. (though I am also in favor of working on > better formal reflection APIs) Agreed - up to a point. I don't see a need for a way to distinguish between slots and "normal" attributes, personally. But I don't do anything fancy here, so my experience isn't very indicative. I'm more or less happy with dir() as a start, although I agree that a better formal reflection API would be helpful. I suspect that such a thing could be built in Python on top of the existing facilities, however... > 3) These 'attrs' are to otherwise have the same semantics > as normal __dict__ instance attributes. e.g., they should > be automatically picklable, they can have properties > assigned to them, etc. I think I agree here. However, if you want slots to behave like normal attributes, except for the flat namespace, I see no value. Why have the exception at all? Hmm, this raises the question of why we have slots at all. If they act exactly like attributes, why have them? As a user, I perceive them as an efficiency thing - they save the memory associated with a dictionary, and are probably faster as well. There can be tradeoffs which you pay for that efficiency, but that's all. No semantic difference. Actually, that's pretty much how the descrintro document describes slots. Strange that... I guess I am saying that I'm happy with slots as designed (documented in descrintro) - modulo some implementation bugs such as not getting automatically pickled. Paul.

4 7