Re: [Python-Dev] Documentation about Python's GC, python-dev list messages referenced in Modules/gcmodule.c not reachable anymore
Tim Peters wrote: > Python-style refcounting isn't generally a good approach either when > real-time constraints must be met: when a refcount on an object P > falls to 0, not only does the interpreter "pause" to reclaim P, but > also to reclaim all the objects that were reachable only from P. Sure - but that still allows for meeting real-time constraints. You need to understand, or estimate, the worst-case execution time that any statement may have. In general, any assignment in Python could trigger releasing many objects, as the old value is released. In a specific program, analysis is much brighter. You *know* what variables carry references to huge data structures, and you *know* where these variables are assigned to. Also, you can often give an upper bound to the number of objects that may get released in the worst case if you assign to a variable. This is different from garbage collection: it is generally very difficult to predict when precisely the garbage collector will be invoked; in the current Python implementation, you would have to predict at what point in the code you hit the 1000 objects quota. This is nothing that can be learned from local inspection, and thus hard to tell. For a real time system, it is not just important that all actions complete fast. Instead, it is important to tell what statements might be long-running, and how long. In Python's reference counting, this is possible, hence it is (IMO) suitable for real-time purposes. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker anonymity
[EMAIL PROTECTED] wrote: > Paul> In the old days, it was possible to post stuff to Python's > Paul> sourceforge pages without logging in. That was turned off for > Paul> various reasons that weren't bogus, but that didn't strike me as > Paul> overwhelmingly compelling. Maybe that could be revisited, at > Paul> least for the category of documentation bugs and patches. > > Any thoughts about maybe relaxing the login restriction? I can't understand why he could expect that patch submissions could be anonymous. We are moving towards more bureaucracy here, not less: we should really require that the contributor form is filled out for submissions (both code and documentation): on documentation, there is also copyright, and formally, the contributor needs to declare under what license we can use the text that he wrote. Now, there is always the issue with "trivial" modifications (like typos); we haven't been able to clarify yet what the bar for "this has copyright" really is, that's why I haven't been pushing for executing a "require forms signed" policy, yet. For bug reports, this issue does not exist - but the other issues (of being able to get feedback) do, of course. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tracker anonymity
[EMAIL PROTECTED] wrote: > Fine with me. Is it ready to go though? If not, what more needs to be > done? I was under the assumption that it wasn't ready for prime time and > solicited inputs on c.l.py in a couple messages yesterday and today. Primarily, it needs a dedicated operator. Somebody who is willing to get it done, and somebody who doesn't run away when it is done, but reacts in a timely manner (similar to what I have been doing with subversion). So far, nobody has stepped forward. Without such a person, I would be very hesitant to accept switching, even if the technology was demonstrable ready and easy to operate. In addition, the pending technical issues are perhaps deeper than in the case for subversion. The conversion tool, for subversion, was ready to go, and nearly perfect (except that I managed to get the time not increasing monotonically); I'm just not sure what the status of the roundup conversion tool is (but I do remember that it exists, and is able to process the data obtained from SF XML export). One other issue I remember is that the SF redirector replacement is not implemented: I would expect that python.org/sf/ will map the SF bug ids into roundup bug ids, and redirect appropriately; this hasn't been done (to my knowledge). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)
Passing along from c.l.py. I think ElementTree is the poster child for best-of-breed code belonging in the standard distribution. Its API is so much better than what we have there now that assuming any non-technical issues can be solved (licensing, duplicate copies of the source code) that ElementTree and any necessary C helper/accelerator modules it uses should wind up in the distribution. Skip --- Begin Message --- [EMAIL PROTECTED] wrote: > I think the key here is ElementTree's Pythoninc API. While it's clearly > possible to install it as a third-party package, I think there's a clear > best-of-breed aspect here that suggests it belongs in the standard > distribution simply to discourage continued use of DOM-based APIs. I second this. Guido has said many times that the stdlib is for best-of-breed modules that have proven themselves in the wild. ElementTree has proven itself in the wild and is clearly best-of-breed. And dramatically better (IMHO) than the APIs currently included in the stdlib[1]. I don't have a whole lot of free time, and I'm not sure exactly how I could help, but if there's anything I could do that would help get ElementTree into the stdlib, let me know. STeVe [1] If I had my way, we'd deprecate and then remove the current Python xml modules. But of course then people would complain that Python doesn't have a SAX or DOM API. Of course we could tell them that they don't need it and that ElementTree is easier, but I'm not sure people really want to fight that battle. -- http://mail.python.org/mailman/listinfo/python-list --- End Message --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Documentation about Python's GC, python-dev list messages referenced in Modules/gcmodule.c not reachable anymore
[Tim Peters] >> Python-style refcounting isn't generally a good approach either when >> real-time constraints must be met: when a refcount on an object P >> falls to 0, not only does the interpreter "pause" to reclaim P, but >> also to reclaim all the objects that were reachable only from P. [Martin v. Löwis] > Sure - but that still allows for meeting real-time constraints. I doubt people who work in hard real-time would agree -- I'm just regurgitating the standard line here. For recent work, see: The Space Cost of Lazy Reference Counting Boehm, Hans-J. POPL 2004, or online at http://www.hpl.hp.com/techreports/2003/HPL-2003-215.html Reference counting memory management is often advocated as a technique for reducing or avoiding the pauses associated with tracing garbage collection. We present some measurements to remind the reader that classic reference count implementations [i.e., "Python-style refcounting" - tim] may in fact exhibit longer pauses than tracing collectors. We then analyze reference counting with lazy deletion, the standard technique for avoiding long pauses by deferring deletions and associated reference count decrements, [which is indeed the standard technique for making refcounting friendlier to real-time work - tim] usually to allocation time. ... > ... > In a specific program, analysis is much brighter. You *know* what > variables carry references to huge data structures, and you *know* > where these variables are assigned to. > ... Most people work with countless lines of library code they didn't write, and whose internals aren't documented at all. When I do myinstance.a = zope.app.frobulater.gringo() did I just create a reference to a huge new data structure? I have no idea. How long will refcounting take to clean up mysinstance.a when myinstance becomes trash? Ditto. Multiply by many thousands. "Lazy" refcounting guarantees "not long" regardless -- although it introduces other problems. > ... ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)
[EMAIL PROTECTED] wrote: > Passing along from c.l.py. I think ElementTree is the poster child for > best-of-breed code belonging in the standard distribution. That's primarily for the author of the software to decide, at this point. Fredrik Lundh would have to offer it for contribution first. I don't know what his current position is, but I think it is unlikely that he will contribute it: in the past, he often indicated that he a) dislikes the growth of the standard Python library, and b) dislikes forking his own branch for inclusion in another package (which would happen if he contributed one version for the standard library, and would continue to maintain the code outside of Python also). That said, I agree that ElementTree would be a valuable addition to the Python library, and has certainly passed the "collect feedback in the real world" test. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)
Martin> [EMAIL PROTECTED] wrote: >> Passing along from c.l.py. I think ElementTree is the poster child >> for best-of-breed code belonging in the standard distribution. Martin> That's primarily for the author of the software to decide, at Martin> this point. Fredrik Lundh would have to offer it for Martin> contribution first. Understood. Hence the reference in my note to "non-technical issues". Fredrik has been participating in the c.l.py thread. I doubt he will be shy about voicing his opinion here. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Documentation about Python's GC, python-dev list messages referenced in Modules/gcmodule.c not reachable anymore
Tim Peters <[EMAIL PROTECTED]> wrote: > > ... > > > In a specific program, analysis is much brighter. You *know* what > > variables carry references to huge data structures, and you *know* > > where these variables are assigned to. > > > ... > > Most people work with countless lines of library code they didn't > write, and whose internals aren't documented at all. When I do > > myinstance.a = zope.app.frobulater.gringo() > > did I just create a reference to a huge new data structure? I have no > idea. How long will refcounting take to clean up mysinstance.a when > myinstance becomes trash? Ditto. Multiply by many thousands. "Lazy" > refcounting guarantees "not long" regardless -- although it introduces > other problems. I believe this particular argument is specious. Using Python won't change requirements for knowing what is or is not referenced during program execution for "real time" development. Further, "real time" developers won't be using arbitrary 3rd party code which may do unknown crazy things, it'll all be known crazy things. My flight-controller-software-validator friend tells me that they use a slimmed-down variant of Python for some of their software, and that it works great. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Documentation about Python's GC, python-dev list messages referenced in Modules/gcmodule.c not reachable anymore
[Josiah Carlson] > I believe this particular argument is specious. Not at all, but it's not compelling on its own. > Using Python won't change requirements for knowing what is or is > not referenced during program execution for "real time" development. > Further, "real time" developers won't be using arbitrary 3rd party code > which may do unknown crazy things, it'll all be known crazy things. So you believe they're not going to use any code they didn't write from scratch themselves? For example, they're not going to use the Python libraries? Not going to use core Python data types? "3rd party" seems a wrong distinction if "wholly understood" is what's relevant. Even something as simple as list.append(3) _can_ cause a long delay, and that's not a "_known_ crazy thing" unless you're an expert in Python internals. > My flight-controller-software-validator friend tells me that they use a > slimmed-down variant of Python for some of their software, and that it > works great. Then I hope that and a marketing department makes you rich ;-) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)
Martin v. Löwis wrote: > [EMAIL PROTECTED] wrote: > >>Passing along from c.l.py. I think ElementTree is the poster child for >>best-of-breed code belonging in the standard distribution. > > > That's primarily for the author of the software to decide, at this > point. Fredrik Lundh would have to offer it for contribution first. > > I don't know what his current position is, but I think it is unlikely > that he will contribute it: in the past, he often indicated that he > a) dislikes the growth of the standard Python library, and > b) dislikes forking his own branch for inclusion in another package > (which would happen if he contributed one version for the > standard library, and would continue to maintain the code > outside of Python also). Ooh. Well said. I agree with both of these points. :) +1 > That said, I agree that ElementTree would be a valuable addition > to the Python library, and has certainly passed the "collect feedback > in the real world" test. I hope that packaging progress will someday make it matter much less whether something is in the standard library. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)
Jim Fulton wrote: [...] > > I hope that packaging progress will someday make it matter much less > whether something is in the standard library. > For which we need a *mechanism* that all package providers can implement, rather than a repository to which all package providers must contribute. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)
Steve Holden wrote: > Jim Fulton wrote: > [...] > >>I hope that packaging progress will someday make it matter much less >>whether something is in the standard library. >> > > For which we need a *mechanism* that all package providers can > implement, rather than a repository to which all package providers must > contribute. I think we need both. We need the mechanism and repositories, although non necessarily one repository. Phillip Eby and others seem to be making wonderful progress on the mechanism. I haven't had a chance to play with this yet, but I expect to over the next few months. People who have seem quite enthusiastic. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)
Jim> I hope that packaging progress will someday make it matter much Jim> less whether something is in the standard library. It undoubtedly will. The point I was trying to raise here is that ElementTree is so much better than the stuff we currently distribute (*) that it should be included in the standard distribution if for no other reason than to discourage use of the current stuff in new applications. Here are a couple perhaps useful BDFL references: http://mail.python.org/pipermail/python-dev/2003-December/040928.html http://mail.python.org/pipermail/python-dev/2003-April/034881.html In the first, Guido tells a potential submitter to "do the math" to make sure his package is "best of breed". In the second Guido warns that having code in the standard distribution tends to suppress usage of other packages, even though they may be better: We can't put every approach in the core, but putting one package in the core may damage the viability of another, possibly better (for some users) solution. To some extent this has happened with GUI toolkits: the presence of Tkinter in the core makes it harder for other GUI toolkits to compete (leaving aside whether Tkinter is better or not -- it's just not a level playing field). I think that's sort of the reverse of the point I'm trying to make. ET belongs in the standard distribution to create a level playing field for a module many people feel is superior to the current XML-related modules. Think of it as Pythonic affirmative action. ;-) Skip (*) As in so much better that I was actually able to a) understand how to use it and then b) actually use it in a real application. With the DOM stuff the barrier was always too high for me to ever want to solve real problems with them. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)
[EMAIL PROTECTED] wrote: > Jim> I hope that packaging progress will someday make it matter much > Jim> less whether something is in the standard library. > > It undoubtedly will. The point I was trying to raise here is that > ElementTree is so much better than the stuff we currently distribute (*) > that it should be included in the standard distribution if for no other > reason than to discourage use of the current stuff in new applications. Maybe we should deprecate the current stuff. It's been done before. Of course, much of the current XML support is still useful, if only because lots of existing 3rd-party code depend on it. When we have a packaging system we could move these out of the core without disparaging them and without breaking third-party modules. > > Here are a couple perhaps useful BDFL references: > > http://mail.python.org/pipermail/python-dev/2003-December/040928.html > http://mail.python.org/pipermail/python-dev/2003-April/034881.html > > In the first, Guido tells a potential submitter to "do the math" to make > sure his package is "best of breed". In the second Guido warns that having > code in the standard distribution tends to suppress usage of other packages, > even though they may be better: > > We can't put every approach in the core, but putting one package in > the core may damage the viability of another, possibly better (for > some users) solution. To some extent this has happened with GUI > toolkits: the presence of Tkinter in the core makes it harder for > other GUI toolkits to compete (leaving aside whether Tkinter is > better or not -- it's just not a level playing field). Well said. +1 I agree with this too. :) > I think that's sort of the reverse of the point I'm trying to make. But it's one of the reasons why I'd like to see fewer application-level facilities added to the core. I'd rather make it easier to try out different tools and figure out what's best for a particular situation. > ET > belongs in the standard distribution to create a level playing field for a > module many people feel is superior to the current XML-related modules. > Think of it as Pythonic affirmative action. ;-) I would only think of it as Pythonoc affirmative action if you also included the FourSuite stuff and lxml and ... which, of course, would be bad. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree - Why not part of the core? (fwd)
At 04:45 PM 12/8/2005 -0500, Jim Fulton wrote: >I think we need both. We need the mechanism and repositories, although >non necessarily one repository. Phillip Eby and others seem to be making >wonderful progress on the mechanism. And FYI, it does not depend on a single repository. TurboGears, for example, depends on a number of packages that are not distributed on PyPI, or which lack a setup script. A packager can simply publish a page of usable download links (or even Subversion URLs) in order to participate. Of course, it's easier if packages are linked from PyPI, and you can avoid naming collisions that way, but the basic requirements for a "repository" can actually be met with nothing more than an Apache directory index. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Bug bz2.BZ2File(...).seek(0,2) + patch
Le Vendredi 25 Novembre 2005 15:54, Aahz a écrit : > On Fri, Nov 25, 2005, Victor STINNER wrote: > > I found a bug in bz2 python module. Example: > > > > Details and *patch* at: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1366000&group_id > >=5470&atid=105470 > > Thanks! Particularly with the Thanksgiving weekend, you may not get any > other responses for a while. Please be patient. No other reaction!? A s small patch :-) Haypo -- Victor Stinner - student at the UTBM (Belfort, France) http://www.haypocalc.com/wiki/Victor_Stinner ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Documentation about Python's GC, python-dev list messages referenced in Modules/gcmodule.c not reachable anymore
Tim Peters <[EMAIL PROTECTED]> wrote: > > [Josiah Carlson] > > I believe this particular argument is specious. > > Not at all, but it's not compelling on its own. I like that better. > > Using Python won't change requirements for knowing what is or is > > not referenced during program execution for "real time" development. > > Further, "real time" developers won't be using arbitrary 3rd party code > > which may do unknown crazy things, it'll all be known crazy things. > > So you believe they're not going to use any code they didn't write > from scratch themselves? Of course not. > For example, they're not going to use the > Python libraries? Not going to use core Python data types? "3rd > party" seems a wrong distinction if "wholly understood" is what's > relevant. Even something as simple as list.append(3) _can_ cause a > long delay, and that's not a "_known_ crazy thing" unless you're an > expert in Python internals. If someone is planning on using Python for real time systems, and they don't know that Python uses arrays as lists, then they aren't paying attention to the stuff they should be - exactly those Python internals that _can_ affect their running time. Considering that Mr. Weber was asking about the Python garbage collector specifically, I would imagine that they have at least started delving into the inner workings of Python data structures. I personally don't build real-time systems, but if I did, the first thing I would do is remove everything from the standard library. As the code in the standard library is verified, validated, and its running time documented (as such module functionality is requested), I'd add them into the standard library. The first things that I would document would be all of the objects which sit in __builtins__ . But who knows, maybe real-time people aren't as anal about correctness as a CS Theory grad student - though I would guess they are a bit more anal than I am (what with all that formal correctness and proof training that some of my eastern European friends poke me in the ribs about). > > My flight-controller-software-validator friend tells me that they use a > > slimmed-down variant of Python for some of their software, and that it > > works great. > > Then I hope that and a marketing department makes you rich ;-) I'm completely detached from his work and what he does, and he's a salaried employee. Only the guys on the top are getting rich. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Documentation about Python's GC, python-dev list messages referenced in Modules/gcmodule.c not reachable anymore
Title: Documentation about Python's GC, python-dev list messages referenced in Modules/gcmodule.c not reachable anymore Hi All, Hi Neil, While searching documentation about Pythons GC and it's behaviour I found references to the python-dev list in ``Modules/gcmodule.c``. But unfortunately the links to the list do not work anymore. May someone give me a hint how to find the messages (2. to 4. below). Is the article (Link 1. below) up to date or were there major changes in the GC strategies since year 2000? http://svn.python.org/projects/python/trunk/Modules/gcmodule.c 1. http://www.arctrix.com/nas/python/gc/ 2. http://www.python.org/pipermail/python-dev/2000-March/003869.html 3. http://www.python.org/pipermail/python-dev/2000-March/004010.html 4. http://www.python.org/pipermail/python-dev/2000-March/004022.html Background Info: We're seriously evaluating Python for use in embedded realtime systems and need some informations about Pythons garbage collector. What we're interested mostly in the runtime behaviour of the GC. The main question is: Does it interrupt the python interpreter to collect stuff or is collecting done more in the background (e.g. just incrementally collecting)? This is an important question for realtime systems with well defined reaction times. Just point me to documentation if available. Gregoire ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hasattr and properties
Guido van Rossum wrote: > Um, that does't work for types which customize __getattribute__ or > __getattr__ in various ways. There could be a __hasattr__ slot in the class itself for that purpose. > IMO a property that has a side effect (other than updating a cache or > statistics or perhaps logging) is a misfeature anyway, Even if it doesn't have side effects, getting the attribute's value could be expensive. One shouldn't have to pay the full cost of getting the value just to find out whether the attribute itself exists. To put it another way, hasattr is enquiring about the object's interface, not asking it to perform a computation. Doing the latter when only being asked to do the former is wrong, IMO. Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hasattr and properties
Calvin Spealman wrote: > I will have to disagree with you there. If hasattr(a,b) returns True, > one should be able to expect a.b will work properly. Otherwise, the > majority of use cases for hasattr will be completely thrown out the > window. How can hasattr work properly with properties if it doesn't > call the property access code? In the vast majority of code that I write, if a class has a descriptor for a given property, but the accessor code doesn't work, then there is a bug. In a case where that wasn't true, a hasattr slot in the descriptor would enable me to code it so it did the right thing. Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Documentation about Python's GC, python-dev list messages referenced in Modules/gcmodule.c not reachable anymore
Gregoire> But unfortunately the links to the list do not work Gregoire> anymore. May someone give me a hint how to find the messages Gregoire> (2. to 4. below). Gregoire> 2. http://www.python.org/pipermail/python-dev/2000-March/003869.html Gregoire> 3. http://www.python.org/pipermail/python-dev/2000-March/004010.html Gregoire> 4. http://www.python.org/pipermail/python-dev/2000-March/004022.html I don't know what happened to the numbering. Those article numbers all appear in the May 2000 archive and don't appear related to cyclic GC. Try browsing from this point: http://mail.python.org/pipermail/python-dev/2000-March/thread.html I think this may be one of the articles: http://mail.python.org/pipermail/python-dev/2000-March/002385.html That article is the starting point for an extensive thread. In general, March 2000 seems to have been a fertile month for cyclic GC. -- Skip Montanaro Katrina Benefit Concerts: http://www.musi-cal.com/katrina [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
