Re: [Python-Dev] [python] Re: New lines, carriage returns, and Windows
Greg Ewing <[EMAIL PROTECTED]> wrote: > > > I don't know PRECISELY what you mean by "universal newlines mode" > > I mean precisely what Python means by the term: any of > "\r", "\n" or "\r\n" represent a newline, and no distinction > is made between them. Excellent. While this over-simplifies the issue, let's stick to the over-simplified form, as we may be able to get somewhere. The question is independent of what the outside system believes a text file should look like, and is solely what Python believes a sequence of characters should mean. For example, does 'A\r\nB' mean that B is separated from A by one newline or two? The point is that, once we know that, we can design a translator to and from Python's conventions to any reasonable system (and, as I say, I have done it many times). But, if Python's own interpretation is ambiguous, it is a sure recipe for different translators being incompatible, even on the same system. Which is what has happened here. So, damn the outside system, EXACTLY what does Python mean by such characters, and EXACTLY what uses of them are discouraged as having unspecified meanings? If we could get an answer to that precisely enough to write a parse tree with all terminals explicit, this problem would go away. And that is all that I say can or should be done. The details of how to write the translators to other file systems are then a separate matter. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ 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] GC Changes
On 01/10/2007, Justin Tulloss <[EMAIL PROTECTED]> wrote: > > Hello, > > I've been doing some tests on removing the GIL, and it's becoming clear > that some basic changes to the garbage collector may be needed in order for > this to happen efficiently. Reference counting as it stands today is not > very scalable. > > I've been looking into a few options, and I'm leaning towards the > implementing IBMs recycler GC > (http://www.research.ibm.com/people/d/dfb/recycler-publications.html ) > since it is very similar to what is in place now from the users' > perspective. However, I haven't been around the list long enough to really > understand the feeling in the community on GC in the future of the > interpreter. It seems that a full GC might have a lot of benefits in terms > of performance and scalability, and I think that the current gc module is of > the mark-and-sweep variety. Is the trend going to be to move away from > reference counting and towards the mark-and-sweep implementation that > currently exists, or is reference counting a firmly ingrained tradition? > > On a more immediately relevant note, I'm not certain I understand the full > extent of the gc module. From what I've read, it sounds like it's fairly > close to a fully functional GC, yet it seems to exist only as a > cycle-detecting backup to the reference counting mechanism. Would somebody > care to give me a brief overview on how the current gc module interacts with > the interpreter, or point me to a place where that is done? Why isn't the > mark-and-sweep mechanism used for all memory management? The cyclic GC is just too slow to react and makes programmers mad. For instance, in PyGtk we had a traditional problem with gtk.gdk.Pixbuf, which is basically an object that wraps a raw RGB image. When users deleted such an object, which could sometimes comprise tens or hundreds of megabytes, the memory was not relased until much much later. That kind of code ended up having to manually call gc.collect() to fix what was perceived by most programmers as a "memory leak", which kind of defeats the purpose of a garbage collector. This happened because PyGtk used to rely on the cyclic GC doing its work. Thankfully we moved away from that and now simple reference counting can free a Pixbuf in most cases. The cyclic GC is a very useful system, but it should only be used in addition to, not instead of, reference counting. At least that's my personal opinion... -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert ___ 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] [python] Re: New lines, carriage returns, and Windows
On 01/10/2007, Nick Maclaren <[EMAIL PROTECTED]> wrote: > So, damn the outside system, EXACTLY what does Python mean by > such characters, and EXACTLY what uses of them are discouraged > as having unspecified meanings? If we could get an answer to > that precisely enough to write a parse tree with all terminals > explicit, this problem would go away. Python, the language, means nothing by the characters. They are bytes with defined values in a byte string (in 2.x, in 3.0 they are Unicode characters, but otherwise no difference). The *language* places no interpretation on them. Certain library functions place an interpretation on the byte values, but you need to read the function definition for that. And (a) they may not all be consistent, and (b) they may say "follows platform behaviour", but that's the way it is, so you have to live with it. Paul. ___ 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] [python] Re: New lines, carriage returns, and Windows
"Paul Moore" <[EMAIL PROTECTED]> wrote: > > > So, damn the outside system, EXACTLY what does Python mean by > > such characters, and EXACTLY what uses of them are discouraged > > as having unspecified meanings? If we could get an answer to > > that precisely enough to write a parse tree with all terminals > > explicit, this problem would go away. > > Python, the language, means nothing by the characters. They are bytes > with defined values in a byte string (in 2.x, in 3.0 they are Unicode > characters, but otherwise no difference). The *language* places no > interpretation on them. Actually, it's not that simple, because of the "universal newline" rule and the fact that both Unix/C ASCII and Unicode DO provide meanings for their characters, but let that pass. Your statement is not far off the situation. > Certain library functions place an interpretation on the byte values, > but you need to read the function definition for that. And (a) they > may not all be consistent, and (b) they may say "follows platform > behaviour", but that's the way it is, so you have to live with it. And that is why there will continue to be confusion and inconsistency, and why there will be similar threads to this for the foreseeable future. If you regard continuing problems of this sort as acceptable, then fine, but I am pointing out that they are fairly easy to avoid. But only by specifying a precise Python model. Incidentally, the response (b) you give is a common one, but isn't usually correct when it is given. It is, after all, the cause of the problem that started this thread. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ 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] GC Changes
On 10/1/07, Justin Tulloss <[EMAIL PROTECTED]> wrote: > Hello, > > I've been doing some tests on removing the GIL, and it's becoming clear that > some basic changes to the garbage collector may be needed in order for this > to happen efficiently. Reference counting as it stands today is not very > scalable. > > I've been looking into a few options, and I'm leaning towards the > implementing IBMs recycler GC ( > http://www.research.ibm.com/people/d/dfb/recycler-publications.html > ) since it is very similar to what is in place now from the users' > perspective. However, I haven't been around the list long enough to really > understand the feeling in the community on GC in the future of the > interpreter. It seems that a full GC might have a lot of benefits in terms > of performance and scalability, and I think that the current gc module is of > the mark-and-sweep variety. Is the trend going to be to move away from > reference counting and towards the mark-and-sweep implementation that > currently exists, or is reference counting a firmly ingrained tradition? > > On a more immediately relevant note, I'm not certain I understand the full > extent of the gc module. From what I've read, it sounds like it's fairly > close to a fully functional GC, yet it seems to exist only as a > cycle-detecting backup to the reference counting mechanism. Would somebody > care to give me a brief overview on how the current gc module interacts with > the interpreter, or point me to a place where that is done? Why isn't the > mark-and-sweep mechanism used for all memory management? There are probably lots of interesting things to say about the gc cycle collector, but I'll just pick a few things that seem relevant. First off, the gc doesn't have a root set. It traces all the container objects, subtracting known references from the refcount, and is left with a root set, i.e. those objects that have some references that can't be accounted for among the known container objects. (see update_refs and substract_refs) In the end, we make three traversals of the heap to detect the objects that appear to be unreachable. (move_unreachable is the third.) The cycle detection relies on having the reference counts correct, so it doesn't really represent a move away from refcounting. I skipped the generations. The GC divides the heap into three generations and tends to focus on the youngest generation. So that limits the portion of the heap that is scanned, but I don't understand the magnitude of that effect in practice. The current collector works in collaboration with ref counting. In particular, refcounting probably handles the majority of deallocations. If the cycle detection system were responsible for all deallocations, the gc module would have a lot more work to do. I do think it would be interesting to experiment with the recycler approach, but I think it would take a lot of work to do a decent experiment. But please give it a shot! Jeremy ___ 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] building with -Wwrite-strings
Hi Martin,
On Fri, Sep 28, 2007 at 11:09:54PM +0200, "Martin v. Löwis" wrote:
> What's wrong with
>
> static const char *kwlist[] = {"x", "base", 0};
The following goes wrong if we try again to walk this path:
http://mail.python.org/pipermail/python-dev/2006-February/060689.html
Armin
___
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] building with -Wwrite-strings
Yes, you are completely right. I ended up realizing that a change like
this would break almost all third-party extension.
But... What about of doing this for Py3K? Third-party extension have
to be fixed anyway.
On 10/1/07, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi Martin,
>
> On Fri, Sep 28, 2007 at 11:09:54PM +0200, "Martin v. Löwis" wrote:
> > What's wrong with
> >
> > static const char *kwlist[] = {"x", "base", 0};
>
> The following goes wrong if we try again to walk this path:
> http://mail.python.org/pipermail/python-dev/2006-February/060689.html
>
>
> Armin
>
--
Lisandro Dalcín
---
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594
___
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] [python] Re: New lines, carriage returns, and Windows
Michael Foord wrote: > Steven Bethard wrote: >> On 9/29/07, Michael Foord <[EMAIL PROTECTED]> wrote: >> >>> Terry Reedy wrote: >>> There are two normal ways for internal Python text to have \r\n: 1. Read from a file with \r\r\n. Then \r\r\n is correct output (on the same platform). 2. Intentially put there by a programmer. If s/he also chooses default \n translation on output, \r is correct. >>> Actually, I usually get these strings from Windows UI components. A file >>> containing '\r\n' is read in with '\r\n' being translated to '\n'. New >>> user input is added containing '\r\n' line endings. The file is written >>> out and now contains a mix of '\r\n' and '\r\r\n'. >>> >> Out of curiosity, why don't the Python wrappers for your Windows UI >> components do the appropriate '\r\n' -> '\n' conversions? >> > > One of the great things about IronPython is that you don't *need* any > wrappers - you access .NET objects natively (which in fact wrap the > lower level win32 API) - and the .NET APIs are usually not as bad as you > probably assume. ;-) > This thread might represent an argument that you *do* need wrappers ... > You just have to be aware that line endings are '\r\n'. I'm not sure how > or if pywin32 handles this. > Presumably that awareness should be implemented by the "unnecessary" wrappers. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Sorry, the dog ate my .sigline ___ 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] [python] Re: New lines, carriage returns, and Windows
Steve Holden wrote: > Michael Foord wrote: > >> Steven Bethard wrote: >> >>> On 9/29/07, Michael Foord <[EMAIL PROTECTED]> wrote: >>> >>> Terry Reedy wrote: > There are two normal ways for internal Python text to have \r\n: > 1. Read from a file with \r\r\n. Then \r\r\n is correct output (on the > same platform). > 2. Intentially put there by a programmer. If s/he also chooses default \n > translation on output, \r is correct. > > > Actually, I usually get these strings from Windows UI components. A file containing '\r\n' is read in with '\r\n' being translated to '\n'. New user input is added containing '\r\n' line endings. The file is written out and now contains a mix of '\r\n' and '\r\r\n'. >>> Out of curiosity, why don't the Python wrappers for your Windows UI >>> components do the appropriate '\r\n' -> '\n' conversions? >>> >>> >> One of the great things about IronPython is that you don't *need* any >> wrappers - you access .NET objects natively (which in fact wrap the >> lower level win32 API) - and the .NET APIs are usually not as bad as you >> probably assume. ;-) >> >> > This thread might represent an argument that you *do* need wrappers ... > > >> You just have to be aware that line endings are '\r\n'. I'm not sure how >> or if pywin32 handles this. >> >> > Presumably that awareness should be implemented by the "unnecessary" > wrappers. > Well, it's an OS level difference and I thought that in general Python *doesn't* try to protect you from OS differences. These different line endings are returned by the components - and making the string type aware of where it comes from and transform itself accordingly seems odd. It also leaves you with all sorts of other problems like string comparison (do you ignore difference in line endings?), string length (on different sides of the .NET / IronPython strings would report different lengths). It is also different from how libraries like wxPython behave - where they *don't* protect you from OS differences and if a textbox has '\r\n' line endings - that is what you get... Michael http://www.manning.com/foord > regards > Steve > ___ 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] OpenSSL httplib bug
I believe this is already fixed in 2.6 with the new SSL code (I got the same error writing the unit tests and fixed it). Thanks for reporting it, though. Bill ___ 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] [python] Re: New lines, carriage returns, and Windows
> Well, it's an OS level difference and I thought that in general Python > *doesn't* try to protect you from OS differences. I think that's the key point. In general, Python tries to present a "translucent" interface to the OS in which OS differences can show through, in contrast to other languages (Java?) which try to present a complete abstraction of the underlying environment. This makes Python in general more useful, thought it also makes it harder to write portable code in Python, because you have to be aware of the potential differences (and they aren't particularly well documented -- it's not clear that they can be). Bill ___ 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] [python] Re: New lines, carriage returns, and Windows
Guido van Rossum wrote: > The best solution for IronPython is probably to have the occasional > wrapper around .NET APIs that translates between \r\n and \n on the > boundary between Python and .NET; That's probably true. I was responding to the notion that IronPython shouldn't need any wrappers. To make that really true would require IronPython to become a different language that has a different canonical representation of newlines. It's fine with me to keep things as they are. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [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
Re: [Python-Dev] GC Changes
Justin Tulloss wrote: > Is the trend going to be to > move away from reference counting and towards the mark-and-sweep > implementation that currently exists, or is reference counting a firmly > ingrained tradition? It's hard to predict the future, but the general feeling I get is that many people would like to keep the current reference counting behaviour, because it has a number of nice properties: * It's cache-friendly - it doesn't periodically go rampaging through large chunks of memory like mark-and-sweep tends to do. * It tends to reclaim things very promptly. This is important in a language like Python that uses dynamic allocation extremely heavily, even for trivial things like integers. It also helps with cacheing. * It's easy to make it interoperate with external libraries that have their own ways of managing memory. You don't have to take special steps to "protect" things from the garbage collector. > Would > somebody care to give me a brief overview on how the current gc module > interacts with the interpreter The cyclic GC kicks in when memory is running low. Since the reference counting takes care of any data structures that don't contain cycles, the GC only has to deal with cycles. It goes through all currently allocated objects trying to find sets whose reference counts are all accounted for by references within the set. Such a set must constitute a cycle that is not referenced anywhere from outside. It then picks an arbitrary object from the set and decrements the reference counts of all the objects it references. This breaks the cycle, and allows the reference counting mechanism to reclaim the memory. Although the cyclic GC requires passing over large chunks of memory like mark-and-sweep, it happens far less frequently than would happen if mark-and-sweep were used for all memory management. Also, the programmer can minimise the need for it by manually breaking cycles where they are known to occur. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [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
Re: [Python-Dev] [python] Re: New lines, carriage returns, and Windows
Nick Maclaren wrote: > if Python's own > interpretation is ambiguous, it is a sure recipe for different > translators being incompatible, Python's own interpretation is not ambiguous. The problem at hand is people wanting to use some random mixture of Python and .NET conventions. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [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
Re: [Python-Dev] [python] Re: New lines, carriage returns, and Windows
Michael Foord wrote: > It is also different from how libraries like wxPython behave - where > they *don't* protect you from OS differences and if a textbox has '\r\n' > line endings - that is what you get... That sounds like an undesirable deficiency of those library wrappers, especially cross-platform ones like wxPython. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [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
Re: [Python-Dev] GC Changes
> The cyclic GC kicks in when memory is running low. When what memory is running low? Its default pool? System memory? Justin ___ 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] GC Changes
On 10/1/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > Justin Tulloss wrote: > > Would > > somebody care to give me a brief overview on how the current gc module > > interacts with the interpreter > > The cyclic GC kicks in when memory is running low. Since This isn't true at all. It's triggered by heuristics based on the total number of allocated objects. It doesn't know how much memory is available and is not called if an allocation fails. -- Adam Olsen, aka Rhamphoryncus ___ 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] GC Changes
Justin Tulloss wrote: > When what memory is running low? Its default pool? System memory? I'm not sure of the details, but I think it keeps a high-water mark of the amount of memory allocated for Python objects so far. When that is reached, it tries to free up memory by cyclic GC, and only mallocs more if that fails. I think it also counts the number of allocations made since the last GC and does a GC when it gets up to some threshold, so that things get cleaned out periodically and the processing is spread out somewhat. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [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
Re: [Python-Dev] GC Changes
Adam Olsen wrote: > This isn't true at all. It's triggered by heuristics based on the > total number of allocated objects. Hmmm, all right, it seems I don't know what I'm talking about. I'll shut up now before I spread any more misinformation. Sorry. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [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
Re: [Python-Dev] GC Changes
On 10/1/07, Greg Ewing <[EMAIL PROTECTED]> wrote: > Adam Olsen wrote: > > This isn't true at all. It's triggered by heuristics based on the > > total number of allocated objects. > > Hmmm, all right, it seems I don't know what I'm > talking about. I'll shut up now before I spread > any more misinformation. Sorry. Hey, no worries. I half expect someone to correct me. ;) -- Adam Olsen, aka Rhamphoryncus ___ 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] GC Changes
[xposted to python-ideas, reply-to python-ideas, leaving python-dev in to correct misinformation] On Tue, Oct 02, 2007, Greg Ewing wrote: > > The cyclic GC kicks in when memory is running low. Not at all. The sole and only basis for GC is number of allocations compared to number of de-allocations. See http://docs.python.org/lib/module-gc.html -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ The best way to get information on Usenet is not to ask a question, but to post the wrong information. ___ 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] [python] Re: New lines, carriage returns, and Windows
"Nick Maclaren" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | The question is independent of what the outside system believes a | text file should look like, and is solely what Python believes a | sequence of characters should mean. For example, does 'A\r\nB' | mean that B is separated from A by one newline or two? The grammar presupposes that Python code is divided into lines. Any successful interpreter must adjust to the external source's idea of line endings. This is implementation, not language definition. The grammar itself has no notion of structure within Python string objects. The split method lets one define anything as chunk separators. The builtin compile method that uses strings as code input specifies \n and only \n as a line ending. The universal line-ending model of string output to files does the same. So from either viewpoint, the unambiguous answer to your question is 'one'. Terry Jan Reedy ___ 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] [python] Re: New lines, carriage returns, and Windows
Does anyone else have the feeling that discussions with Mr. MacLaren don't usually bear any fruit? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
