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 <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@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 <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@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 <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@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 <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@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 <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@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 <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@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 */ /* 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@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 <wink>.
>
> 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. <fdrake at acm.org>
> 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 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@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. <fdrake at acm.org>
> 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.
>
> 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@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
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