From glyph@twistedmatrix.com Sat Apr 1 01:34:17 2000 From: glyph@twistedmatrix.com (Glyph Lefkowitz) Date: Fri, 31 Mar 2000 20:34:17 -0500 (EST) Subject: [Idle-dev] completed WindowMaker compatiblity patch Message-ID: I have tested this against idle-0.5 and the recently-released idle-0.6; it's nice and short so it works on both, and I didn't even have to change anything :-) This groups all of the windows under the same invisible group leader. It also gives IDLE windows a unique WM_CLASS that various UNIX window-managers (sawmill, enlightenment, windowmaker) can 'remember' settings based on. In order that I don't keep cluttering up the mailinglist with patches (in case I have made a serious mistake and I have to send this again, which is eminently likely) the patch can be found here: http://www.twistedmatrix.com/~glyph/idle-wm.diff If anyone cares, please let me know. I am beginning to think that I'm the only person who uses these features of these windowmanagers :-) ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://www.twistedmatrix.com/~glyph/ From glyph@twistedmatrix.com Sat Apr 1 05:21:32 2000 From: glyph@twistedmatrix.com (Glyph Lefkowitz) Date: Sat, 1 Apr 2000 00:21:32 -0500 (EST) Subject: [Idle-dev] Totally Wacky Proposals / Feature Requests Message-ID: Note: this message is rather stream-of consciousness. Requests for clarification or explanation will be honored as promptly as my schedule allows, as I realize that some of this might be confusing or ill-described. I just finished reading the entire idle-dev archive, and I'm suitably impressed. However, it seems to me that IDLE's development is going the same route as many free and commercial IDEs before it, in that it has the same flawed assumptions about an "interactive" interface, "files", "projects", et. al. Before I get myself into any more trouble :-) let me say that I am the son of an "old school" hacker who has some really kooky ideas about the way that interactive environments should work. He (my father) is currently tinkering with starting a very ambitious multi-language multi-interpreter platform-independent interactive development system, so some of my ideas are lifted nearly directly what he's said about that. I also don't have any idea how to design half of the things I'm talking about here, let alone implement them, so I will understand perfectly if everything I say is ignored. I just hope that this raises some potential issues for IDLE's design that challenges everyone's basic assumptions about the way IDEs should work in general, and maybe makes IDLE truly rise above the rest. First of all, let me share some of my own experiences with interactive environments, specifically in python. I am developing a multi-threaded, client/server application using GTK in python. When I started the project, I was editing a single file, tinkering with the API. Mostly, I had the file because the interactive session was really crappy to copy-and-paste from; I was just re-running the same small file. (I note that, completely beyond the scope of Python's culpability, PyGTK has a very annoying habit of *completely* ignoring keyboard interrupts, so I always have to kill it manually.) Obviously, IDLE is currently unsuitable for this sort of development. GTK+threading constantly crashes Tkinter's event loop, it's not possible to simultaneously debug a client and a server in one IDLE instance, etcetera. Although some of these concerns will soon be resolved (the XIDLE seems to at least take care of the first one) a great many issues remain problematic even if IDLE is completely successful at what I perceive as its current goals. (Again, I may be wrong! I have attempted to do my research on this front, but there isn't a perfect project-outline on the web as to what features and paradigm IDLE intends to pursue, so I am mostly working from hearsay) If IDLE were to move to a more 'project' centric model, as other IDEs have, that scratch file would have no place in my "project"; it's just some extra state and cruft that I want around for my interactive interpreter sessions so I can experiment with the various APIs that I'm using, not an actual piece of code I want linked into my released application. Unless you're sticking with "100% pure python" (no outside libraries) though, such experimentation seems intrinsic to the development process (especially since **NO** native API bindings seem to have docstrings! ^_^) and the results of it should be more easily reusable. Now ... here's an interesting question. I'm working with one session that's got lots of state, and I think to myself, "hey, I wonder what would happen if I had done it *this* way instead?" I would ideally like to be able to compare the results of both side-by-side in a somewhat interactive manner. First of all, if I've got lots of state, it would be super-nice if I could *save* that state so I could diverge in my experimentations at some point without re-running everything (especially if the session is interactive). Moreover, if I define a function in one that would be useful for the other, I'd like to be able to move it from one to the other. Which leads me into what I suppose is my main point here; we all know how cool it is that python treats functions, modules, and classes as objects. Why should the IDE be any different? The path browser is very nice (IMHO the best feature of IDLE so far ^_^) and a step in the right direction, but it's not very interactive; it's just a static listing of pre-existing code in a prettier format. For an example; Let's say I'm working in an interactive session, re-typing and re-evaluating the same function over and over again, and testing it. Once I'm done with that, I have to go back to the file that I'd like to put it into, and likely as not, retype the whole thing (at least IDLE takes away those pesky '...' prompts so I don't need to manually remove them) in order to integrate it. Regardless of the previously-debated effects of hitting the up-arrow or backspace or the return-key on a blank line, I don't like that interface at all; imagine something more along these lines: I type 'def foo():' at an interactive interpreter. A window pops up (or a buffer opens, or whatever) entitled " __main__.foo". I enter the code to my function there. Then I hit 'evaluate'. I go back to my interactive interpreter window, I run the function, it produces incorrect output, I go back to my popup window, tweak the function, hit 'evaluate' again... after a few iterations of this, the function works properly. Somehow (if someone thinks that I'm not insane, feel free to push me for specifics on more of this) you drag the 'icon' of this newly defined function into a module that I'm working on. It's essentially the same effect as copying something from the interactive interpreter into a module you're working on, or having a 'dummy' module to do work like this in; but the advantages of a more object-oriented approach seem obvious to me. At a simple level, rather than manually adding tabs and spaces, the editing phase of this would be transparent; you move code into the appropriate container (and of course, moving functions into classes would turn them into methods, along with the displayed warning that the functionality is slightly different and the user should test again...). The 'incremental' development process could be greatly sped up, as each component down to the smallest detail could be removed and tested independently, before integrating them into a whole. Lifting an idea directly from my father's design plans; it would also be highly useful to be able to bring up a window for a variable in a particular namespace, and watch it in real-time as it changes (I know that the debugger can do something like this, but you effectively have to stop the program in order to see it). Speaking of debugging; remote debugging is a must, but in the age of the internet, the ability to remotely debug multiple interpreters / threads simultaneously is equally critical. I have yet to see a development environment in which I may comfortably work on a client/server combination, especially one which communicates over some sort of remote object protocol, and very few that can properly handle multithreaded programs. Built-in version control would also be nice. It would be good to be able to go to any module (I refuse to say 'file' in this context ^_^) and retrieve the contents of that module on a given date. Support for a CVS-like interface (not actually using CVS; CVS is rife with the sort of anachronistic UNIX idiosyncracies that I gather CP4E is attempting to avoid) to enable collaborative projects would really be useful. One existing interface which escapes the traditional project paradigms in a rather novel, although highly domain-specific, way is the Mathematica "notebook" interface. I haven't used it very much myself, but it's an interesting concept; you run your code (code, equations, whatever...) and each block of input is saved with its block of output, along with all the state that that generated, so you can go back again and poke at it. Those on this list who are running physics simulations would probably enjoy something to this effect; any traditional computation-oriented programming probably has input, code, and output, and being able to look at all three in a format that juxtaposes them would be helpful. Okay. That's my $0.02, although probably more like $0.08... ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://www.twistedmatrix.com/~glyph/ From bas@andrew.cmu.edu Sun Apr 2 18:17:32 2000 From: bas@andrew.cmu.edu (Bruce Sherwood) Date: Sun, 02 Apr 2000 13:17:32 -0400 Subject: [Idle-dev] Re: IDLE-dev digest, Vol 1 #23 - 8 msgs In-Reply-To: <20000331170042.E3F201CDD4@dinsdale.python.org> Message-ID: <1198712358.954681452@HYPERON.REM.CMU.EDU> > But it should at least ask before saving. I guess if you don't save > it can't run, because the other process can't see the unsaved source. Asking whether to save would destroy the high interactivity that is what I most want from IDLE. With this as the highest priority, the issue of how to retreat to earlier versions of a project has a different flavor. It would be done either with a flexible un-do mechanism, or users would be taught to do "save a copy" occasionally. Bruce Sherwood From faassen@vet.uu.nl Sun Apr 2 23:05:05 2000 From: faassen@vet.uu.nl (Martijn Faassen) Date: Mon, 3 Apr 2000 00:05:05 +0200 Subject: [Idle-dev] (no subject) In-Reply-To: References: Message-ID: <20000403000505.A15192@vet.uu.nl> Jim Boyle wrote: > I've been using Dave Scherer's version of idle (XIDLE-1000-03-13.zip). > I strongly support these changes, I now use idle regularly, whereas > before I only used it out of idle curiosity. I still use Emacs myself, but I *have* been using this version in the Python class I give each monday (for the last month) for my coworkers here. It's a bit easier to foist on someone (especially windows users) than Emacs! :) Regards, Martijn From neilh@scintilla.org Mon Apr 3 15:33:22 2000 From: neilh@scintilla.org (Neil Hodgson) Date: Tue, 4 Apr 2000 00:33:22 +1000 Subject: [Idle-dev] Unicode within IDLE Message-ID: <021601bf9d79$988f1220$36dd3fcb@neil> I was pleased to find that IDLE is already using a Unicode based text widget so is able to display non-roman strings. However, the syntax colouring is disturbed by this. It appears to be confused by the difference in length when measuring bytes or characters. If: s="?"#H is the first line of the file with ? replaced by a two byte UTF-8 character, the string highlight colour extends over the '#' and the colouring of the rest of the file is out by one. Neil From Fredrik Lundh" Message-ID: <012401bf9d7a$a9e21440$34aab5d4@hagrid> Neil Hodgson wrote: > I was pleased to find that IDLE is already using a Unicode based text > widget so is able to display non-roman strings. >=20 > However, the syntax colouring is disturbed by this. It appears to be > confused by the difference in length when measuring bytes or = characters. the regular expression engine used by IDLE's tokenizer doesn't (yet) understand UTF-8. in other words, it sees your UTF-8 character as two distinct 8-bit characters, while the Text widget sees it as a single character. this shouldn't be very hard to fix, once 'sre' is up to snuff. maybe in the next alpha. From guido@python.org Tue Apr 4 06:56:03 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 04 Apr 2000 01:56:03 -0400 Subject: [Idle-dev] Totally Wacky Proposals / Feature Requests In-Reply-To: Your message of "Sat, 01 Apr 2000 00:21:32 EST." References: Message-ID: <200004040556.BAA11723@eric.cnri.reston.va.us> Glyph, I'm currently severely under-resourced, and I can't spend as much time as I would like to discuss your proposals. I also won't ask for clarifications since that would just add to my burden. But I did read your ideas. There's some stuff I like, and some I don't. Much of the practical stuff (interrupting runaway programs etc) will happen. The debugger will become much better and you will be able to run the program in slo-mo while watching variables. Popping up a new editor when you type "def foo():" was tried in the ABC environment that I built over 15 years ago; I didn't like it very much. What I do like is a feature of DrScheme, which has *two* interactive buffers. The top one contains the definitions you are working on and can easily be saved. Whenever you hit the "run" button, a clean environment is started and this code is run. You can then experiment with its state in the second buffer, which is like Python's interactive shell. I guess this is a simplified form of the notebook(s) you describe. For some thoughts on where IDLE might go, see the TODO.txt file in the IDLE 0.5 distribution (or in the Python 1.6a1 distribution, which contains IDLE 0.6). --Guido van Rossum (home page: http://www.python.org/~guido/) From hvrosen@hotmail.com Wed Apr 5 13:06:35 2000 From: hvrosen@hotmail.com (Henning von Rosen) Date: Wed, 05 Apr 2000 05:06:35 PDT Subject: [Idle-dev] unicode variable names Message-ID: <20000405120636.4552.qmail@hotmail.com> I want to use unicode varible names, i. e. non-english letters in variable names. This will work fine in python 1.6 if I define them at runtime, using mainpulations of the __dict__ dictionary, Where the names are strings. Qestions: 1) Will future python accept unicode variables in source code? 2) It seems like a very easily implemented, natural and desireable adjustment, is it? 3) Or is it so that the current implemntation of namespaces does allow sting names of variables and that would possibly disappear in another implemntation? 4) Is it desireable to allow unicode variable names in sourcecode, like in Java. Is it desireable for JPython? I am thankful for ansvers/comments! ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com From guido@python.org Wed Apr 5 15:21:37 2000 From: guido@python.org (Guido van Rossum) Date: Wed, 05 Apr 2000 10:21:37 -0400 Subject: [Idle-dev] unicode variable names In-Reply-To: Your message of "Wed, 05 Apr 2000 05:06:35 PDT." <20000405120636.4552.qmail@hotmail.com> References: <20000405120636.4552.qmail@hotmail.com> Message-ID: <200004051421.KAA16126@eric.cnri.reston.va.us> > I want to use unicode varible names, i. e. non-english letters in variable > names. > This will work fine in python 1.6 if I define them at runtime, using > mainpulations of the __dict__ dictionary, Where the names are strings. > Qestions: > 1) Will future python accept unicode variables in source code? Maybe in Python 3000. Not anytime soon, at least not in an officially "blessed" version. > 2) It seems like a very easily implemented, natural and > desireable adjustment, is it? There are major problems with this if you consider code portability. WHen I was 18 and first started to program, I decided to write all my code (including variable names, comments and string literals) in English, even though my mother tongue is Dutch. I have never regretted this. Much more of my code than I ever dreamed has found its way all over the world. If I had used Duch in my programs, they would never have crossed the borders. > 3) Or is it so that the current implemntation of namespaces > does allow sting names of variables and that would possibly > disappear in another implemntation? There is no implementation reason -- the implementation uses arbitrary strings. > 4) Is it desireable to allow unicode variable names in > sourcecode, like in Java. Is it desireable for JPython? Since most computer systems used by programmers have hardly any support for entering and displaying Unicode, this would again hamper source code portability, so I'm not a big fan of this. --Guido van Rossum (home page: http://www.python.org/~guido/) From neilh@scintilla.org Thu Apr 6 03:52:24 2000 From: neilh@scintilla.org (Neil Hodgson) Date: Thu, 6 Apr 2000 12:52:24 +1000 Subject: [Idle-dev] unicode variable names References: <20000405120636.4552.qmail@hotmail.com> <200004051421.KAA16126@eric.cnri.reston.va.us> Message-ID: <02c401bf9f73$2ef2c220$3ddd3fcb@neil> > > 2) It seems like a very easily implemented, natural and > > desireable adjustment, is it? > > There are major problems with this if you consider code portability. > WHen I was 18 and first started to program, I decided to write all my > code (including variable names, comments and string literals) in > English, even though my mother tongue is Dutch. I have never > regretted this. Much more of my code than I ever dreamed has found > its way all over the world. If I had used Duch in my programs, they > would never have crossed the borders. This is easier for Dutch people than for people whose mother tongue is further removed from English. I've worked on Japanese code and found that choice of program identifiers was often poor, which I attribute to the burden placed on Japanese programmers in having to use roman characters for identifiers. They can try to think up a good English word for an identifier (which takes too long and may require a dictionary to make sure its OK) or try to write a Japanese word in roman characters. I've not seen anyone use the latter technique, possibly because its never done in other fields of life where roman characters are only used for imported words. If this is a problem for professional programmers, who have generally learnt good enough technical English skills to read English journals, how much of a burden is it for the Es in CP4E? > > 4) Is it desireable to allow unicode variable names in > > sourcecode, like in Java. Is it desireable for JPython? > > Since most computer systems used by programmers have hardly any > support for entering and displaying Unicode, this would again hamper > source code portability, so I'm not a big fan of this. NT/W2K has quite decent support for Unicode entry and display which can be reasonably easily used in programmer tools. On Windows at least, IDLE supports Unicode display and Pythonwin will real soon now. Neil From bas@andrew.cmu.edu Thu Apr 6 18:49:43 2000 From: bas@andrew.cmu.edu (Bruce Sherwood) Date: Thu, 06 Apr 2000 13:49:43 -0400 Subject: [Idle-dev] Re: IDLE-dev digest, Vol 1 #28 - 1 msg In-Reply-To: <20000406160045.E31AD1CEB6@dinsdale.python.org> Message-ID: <1546243708.955028983@MUON.PC.CC.CMU.EDU> > NT/W2K has quite decent support for Unicode entry and display which can > be reasonably easily used in programmer tools. On Windows at least, IDLE > supports Unicode display and Pythonwin will real soon now. Even if Python and IDLE are "English-only" (in terms of predefined names, menu titles, etc.), it will end up being important to be able to display text in other languages, so I'm glad to hear that at least on Windows it may already be possible to use and output Unicode strings. Bruce Sherwood From njriley@uiuc.edu Fri Apr 7 18:38:15 2000 From: njriley@uiuc.edu (Nicholas Riley) Date: Fri, 7 Apr 2000 12:38:15 -0500 Subject: [Idle-dev] Changes to TreeWidget Message-ID: <20000407123815.B25163@uiuc.edu> Hi, I am pretty new to Python (about three weeks now). IDLE has been a real help in learning the language. I especially like its multi-window model - I have had enough of IDEs which presume to own your entire screen in order to work properly. One of my first things to do in Python was implementing a tree-style viewer. I found two that looked good - "TreeBox.py" by Arpad Kiss, and "TreeWidget.py" from IDLE. TreeBox is very powerful and efficient but didn't really permit binding of objects to nodes, or editing of nodes. TreeWidget was simple, not hugely efficient, but looked really easily extendable. The only visible problems with TreeWidget I could find were: - text disappeared while expanding nodes, and flashed when the TreeWidget was scrolled - the two columns' text baselines didn't line up (in the standard IDLE interface, see the variable browser in the thread viewer for an example) - text was inappropriately drawn from nodes that had been collapsed, at times So I fixed these, and optimized a few things (like not walking the entire tree just to get the current selection). I've tried to keep as much of the TreeWidget behavior as possible, however there are some behaviors related to double-clicking that I couldn't figure out how to simulate effectively. I don't really trust my Python/Tkinter knowledge enough to just submit a patch, so I was wondering if I could get some feedback from this list as to any problems with my changes; in particular, I haven't tested on Windows. I have tested with IDLE 0.5, 0.6, and XIDLE and haven't seen anything. As for feature requests, I'm behind with my main open-source project right now, so I probably can't do anything big. (Side projects like this and the Sawmill theme I did last week don't help, even if I rationalize them as helping me with my research. :-) The file is just a drop-in replacement, and downloadable from: If some of the changes related to double-clicking look a bit weird, it might help to explain what I'm using it for. Instead of changing the icon of a particular node depending on whether it's selected or not, I'm changing it on double-click. The interface I've got it hooked up to will display "detail" information about a node you double-click on in the right side of the window, but you should be able to move the selection without disturbing the detail view, and still be able to see what node the detail display corresponds to - hence the icon change. -- Nicholas Riley From guido@python.org Fri Apr 7 20:46:31 2000 From: guido@python.org (Guido van Rossum) Date: Fri, 07 Apr 2000 15:46:31 -0400 Subject: [Idle-dev] Changes to TreeWidget In-Reply-To: Your message of "Fri, 07 Apr 2000 12:38:15 CDT." <20000407123815.B25163@uiuc.edu> References: <20000407123815.B25163@uiuc.edu> Message-ID: <200004071946.PAA27595@eric.cnri.reston.va.us> > The file is just a drop-in replacement, and downloadable from: > > Thanks -- I don't have time to look at this right now but I'm glad you found my TreeWidget a good starting point! > If some of the changes related to double-clicking look a bit weird, it > might help to explain what I'm using it for. Instead of changing the > icon of a particular node depending on whether it's selected or not, > I'm changing it on double-click. The interface I've got it hooked up > to will display "detail" information about a node you double-click on > in the right side of the window, but you should be able to move the > selection without disturbing the detail view, and still be able to see > what node the detail display corresponds to - hence the icon change. I suggest that the proper solution is to decouple the actions from the bindings. This has been on my (imaginary) wish list for the TreeWidget anyway... --Guido van Rossum (home page: http://www.python.org/~guido/) From bas@andrew.cmu.edu Mon Apr 10 03:46:30 2000 From: bas@andrew.cmu.edu (Bruce Sherwood) Date: Sun, 09 Apr 2000 22:46:30 -0400 Subject: [Idle-dev] Forward progress with full backward compatibility Message-ID: <1837651188.955320390@HYPERON.REM.CMU.EDU> Dave Scherer and I have talked quite a bit about possible ways to introduce a changed rule for division, so that 1/2 would be 0.5 rather than 0. This is extremely important to our plans to have freshman physics students do scientific computer modeling in Python, with real-time 3D output, which we are planning to do in the fall. A problem with making such a change is of course the danger of breaking existing Python programs. Dave has come up with a clever scheme to provide forward progress on this issue with complete backward compatibility. His proposal involves remarkably little coding, which he has already tried out He intends to make a specific proposal soon. More generally, it would seem useful to have a mechanism for incremental yet politically acceptable improvements to Python, with full backward compatibility. I offer a history of how this was achieved in the TUTOR family of languages, and a bit about the political experience associated with making incremental, seemingly incompatible changes in a language. I showed this to Guido, who suggested that I post it to the Idle newsgroup as being of general interest. In the case of TUTOR (initiated in 1967 by Paul Tenczar), and to a large extent MicroTutor (initiated in 1977 by David Andersen), compatibility was achieved by a mechanism no longer available. TUTOR was the graphics-oriented programming language of the PLATO system, which ran on a large scientific mainframe (a CDC Cyber). In the early 1970s there was only one PLATO computer-based education system, located at the University of Illinois and running hundreds of graphics terminals. Later there were a number of PLATO systems, but with links among the systems. All TUTOR source code was stored centrally on the mainframe disks. This made it possible to run source conversions centrally to change the language. From one day to the next you found your source files changed in small ways so that the programs continued to work as before but with new possibilities available in the language. This source-conversion mechanism for TUTOR was essential for a subtle and interesting reason. The cores of languages such as C, Pascal, and Python are relatively clean and compact, with a small number of constructs. This facilitates the design and maintenance of compilers. Graphics libraries for such languages however are notoriously huge and cumbersome. TUTOR on the other hand in order to support the development of educational software by nonexpert faculty programmers was necessarily graphics-oriented and therefore had a significantly larger number of constructs, though vastly fewer than are found in standard graphics libraries. Because of the larger arena covered by TUTOR, it was not feasible to design a nice clean small language from the start, because no one knew quite what would be needed. The language was not so much created as evolved, within a community of diverse users. And there was much more scope for design errors, which became evident only with time and use. Unable to evolve without mistakes, source conversion was important in making it possible to improve the language, but without invalidating old programs. (Recently there was a talk at Carnegie Mellon by one of the creators of Java, and I was amused to see in the abstract some comments to the effect that when you're dealing with graphics the language has to evolve within a community of diverse users; you can't just design some small language core once and for all.) It was politically important that with this mechanism in place, users of TUTOR built up confidence that their work would not be lost due to change, and therefore they had little reason to fear or oppose change. Changes in the language were no big deal. The situation with cT (initiated in 1985 by Bruce Sherwood) was somewhat different. It was no longer the case that all source code was stored centrally. And even though the design of cT benefitted enormously from experience with TUTOR and MicroTutor, still the requirements for a novice-friendly graphics language in a windows and mouse world posed new challenges. Also challenging were the rapidly changing hardware and operating systems of Unix, Mac, and PC. So again it was important to have a mechanism for being able to change the language while preserving backward compatibility. The mechanisms I will describe, due to David Andersen, have had the effect that there are graphics- and mouse-oriented cT programs written on Unix in 1985 that work today on diverse platforms, without change to the source code. Needless to say, this is not true of any educational software written in C within the Carnegie Mellon Andrew project in the 1980s, due to changes in operating systems and graphics environments. When you create a new file in the cT editor today, it automatically starts with a pseudostatement "$syntaxlevel 2". This is a directive to the editor and to the compiler. If you read up an old file containing "$syntaxlevel 1", an automatic source conversion is run, and then the initial pseudostatement is changed to "$syntaxlevel 2". This conversion has two mechanisms at its disposal. It can make actual changes to source code, though this is less often used. The more commonly used mechanism is to add one or more additional pseudostatements at the start of the file. For example, the initial color model in cT proved to be inadequate as changes occurred in the color models for Mac and PC. There was no way to change source code automatically to match needed changes in the language. So the pseudostatement "$oldcolor" was added to old programs when updating the syntax level. Old programs containing "$oldcolor" continue to work as before. A natural thing to try after such a conversion is to comment out "$oldcolor" and try running the program. If it runs fine, you can delete the pseudostatement. But there is no penalty to leaving it there. Nor is there a major penalty in terms of application bloat. Typically the amount of code involved in maintaining an older capability is a very small fraction of the entire application. And it need not affect execution speed at all, since the compiler may generate different output depending on the presence or absence of the pseudostatement. (This is the case with Dave Scherer's proposed change to Python division.) I have the impression that the Python community has been somewhat paralyzed and polarized over discussions of language change. Having a mechanism for moving forward but with full backward compatibility would make people much less fearful of change. Bruce Sherwood From pf@artcom-gmbh.de Mon Apr 10 08:17:19 2000 From: pf@artcom-gmbh.de (Peter Funk) Date: Mon, 10 Apr 2000 09:17:19 +0200 (MEST) Subject: [Idle-dev] Forward progress with full backward compatibility In-Reply-To: <1837651188.955320390@HYPERON.REM.CMU.EDU> from Bruce Sherwood at "Apr 9, 2000 10:46:30 pm" Message-ID: Hi! Bruce Sherwood: > Dave Scherer and I have talked quite a bit about possible ways to introduce > a changed rule for division, so that 1/2 would be 0.5 rather than 0. This is [...] > More generally, it would seem useful to have a mechanism for > incremental yet politically acceptable improvements to Python, with full > backward compatibility. [...] I appreciate your insightful description about TUTOR. The discussion of 'pragmas' telling the Python interpreter something about a particular source file came up on the 'python-dev' mailing list recently. The idea to define a special comment like for example: ##Python-Level=1 or ##Python-Level=2 sure has its merits. But this idea leaves two fundamental problems open: 1: In the case of changing the meaning of the '/' division operator, it is impossible to automatically fix source files, which depend on the old semantic into the new semantic. Example: 42 / some_module.some_function() In Python 1.X the meaning of the '/'-operator is determined by the type of the object returned from 'some_module.some_function()' at run-time. Assume for example 'some_function' is defined as follows: def some_function(): if int(time.time() / 3600) % 2: return 123 # an integer object else: return 123.0 # an float object You see what I mean: It is impossible to change the expression above to the proposed language level 2 (aka as Py3k) automatically, since you would either have to use use the truncating integer division or the floating point division depending on the time of day. 2. What should the new Interpreter do, if he sees a source file without a pragma defining the language level? There are two possibilities: 1. Assume, it is an old source file and apply Language level 1 to it. This has the disadvantage, that the pragma is required for all new source files. No great problem as long as all programmers new to the language would use an IDE and templates. Unfortuantely you can't all those familar with *emacs or *vi* to abbandon their preffered editor. This is an "reliogous" issue. [BTW: This is the main reason, why I don't use IDLE yet, although I certainly like some of its features] 2. Assume, it is a new source file and apply language level 2 to it. This has the disadvantage, that it will break any existing code. Regards, Peter BTW: This discussion is swway off-topic for IDLE. May be you should reply to python-dev@python.org wwith the subject marked with 'Py3k'. May be you should review the discussions about 1/2 == 0.5 in the archives. There are a lot. :-( -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From dscherer@cmu.edu Mon Apr 10 14:54:35 2000 From: dscherer@cmu.edu (David Scherer) Date: Mon, 10 Apr 2000 09:54:35 -0400 Subject: [Idle-dev] Forward progress with full backward compatibility In-Reply-To: Message-ID: [Peter writes, essentially] > def some_function(): > if int(time.time() / 3600) % 2: > return 123 # an integer object > else: > return 123.0 # an float object > > 42 / some_function() > > You see what I mean: It is impossible to change the expression above > to the proposed language level 2 (aka as Py3k) automatically, since you > would either have to use use the truncating integer division or > the floating point division depending on the time of day. This is quite possible in principle, just really ugly: def _div(a,b): if isinstance(a,types.IntType) and isinstance(b,types.IntType): return divmod(a,b)[0] else: return a/b _div(42, some_module.some_function()) In practice, doing this would be both ugly and slow. However, doing it *in the interpreter* is fast. In principle, one could put THREE operators in the language: one with the new "float division" semantics, one that divided only integers, and a "backward compatibility" operator with EXACTLY the old semantics: print 42 div 6 # 7 print 42 div 6.0 # error? print 42 / 6 # 7.0 print 42 olddiv 6 # 7 print 42 olddiv 6.0 # 7.0 Sprinkling "olddiv" through old programs is still ugly. There is a better way... I actually implemented 1/2==0.5 in Python 1.5.2, complete with a module-level backward compatibility flag. The flag made an unusual use of the "global" statement, which appears to be accepted at toplevel by 1.5.2 without any effect. Therefore a statement like "global olddivision" will be silently ignored by 1.5.2 and earlier, and will result in the old behavior under my patch. "global" even has the right sort of sound for module-level options :) An outline of what I did: 1. Add new opcode BINARY_FRACTION to opcode.h and dis.py 2. Add new flag "int c_olddivision" to struct compiling in compile.c 3. Set c_olddivision to base->c_olddivision or 0 in jcompile 4. Check for "global olddivision" outside a function definition in com_global_stmt, and set c_olddivision=1 5. Check c_olddivision in com_term, and generate either BINARY_DIVISION or BINARY_FRACTION 6. Add PyNumber_Fraction to abstract.h, and define it in abstract.c to explicitly check for a pair of integers and do float division 7. Add a BINARY_FRACTION case to ceval.c, which calls PyNumber_Fraction instead of PyNumber_Divide. This took me very little time, despite my total unfamiliarity with the internals of the Python interpreter. It's more effort than just modifying intobject.c to do all integer divisions the new way, but is hardly a big deal. Any python module that ran under 1.5.2 can be made to work under these changes by adding one line to the start: "global olddivision." Such a module continues to work with 1.5.2. Inserting this automatically in a large group of python files would be trivial. The only problems would be with programs that make extraordinary use of eval() or exec. .pyc files generated with 1.5.2 will still run under my patch, since they use the old opcode that generates the old semantics. C modules will also retain their behavior; if they want the new division behavior they can call PyNumber_Fraction instead of PyNumber_Divide. Something very similar could be done for any other kind of "pragma" - the only difference would be where c_olddivision gets set. > 2. What should the new Interpreter do, if he sees a source file without a > pragma defining the language level? There are two possibilities: > > 1. Assume, it is an old source file and apply Language level 1 to it. > This has the disadvantage, that the pragma is required for all new > source files. [...] > > 2. Assume, it is a new source file and apply language level 2 to it. > This has the disadvantage, that it will break any existing code. I think the answer is 2. A high-quality script for adding the pragma to existing files, with CLI and GUI interfaces, should be packaged with Python. Running it on your existing modules would be part of the installation process. Long-lived modules should always have a language level, since it makes them more robust against changes and also serves as documentation. A version statement could be encouraged at the top of any nontrivial script, e.g: python 1.6 import sys, time # etc Such a statement, if used consistently, would permit all future changes to the language to be made gracefully. People who don't use it are living dangerously, and if they install a new version of Python, they will have to add a version statement to *.py. Personally, I think that it makes more sense to talk about ways to gracefully migrate individual changes into the language than to put off every backward-incompatible change to a giant future "flag day" that will break all existing scripts. Versioning of some sort should be encouraged starting *now*, and incorporated into 1.6 before it goes final. Just my $0.02. > BTW: This discussion is swway off-topic for IDLE. Indeed, but Guido has spoken: > Great ideas there, Bruce! I hope you will post these to an > appropriate mailing list (perhaps idle-dev, as there's no official SIG > to discuss the Python 3000 transition yet, and python-dev is closed). Dave From dscherer@cmu.edu (David Scherer), python-dev@python.org Mon Apr 10 17:54:09 2000 From: dscherer@cmu.edu (David Scherer), python-dev@python.org (Peter Funk) Date: Mon, 10 Apr 2000 18:54:09 +0200 (MEST) Subject: [Idle-dev] Forward progress with full backward compatibility In-Reply-To: from David Scherer at "Apr 10, 2000 9:54:35 am" Message-ID: Hi! David Scherer on idle-dev@python.org: [...] > in the interpreter* is fast. In principle, one could put THREE operators in > the language: one with the new "float division" semantics, one that divided > only integers, and a "backward compatibility" operator with EXACTLY the old > semantics: [...] > An outline of what I did: [...] Yes, this really clever. I like the ideas. [me]: > > 2. What should the new Interpreter do, if he sees a source file without a > > pragma defining the language level? There are two possibilities: [...] > > 2. Assume, it is a new source file and apply language level 2 to it. > > This has the disadvantage, that it will break any existing code. > I think the answer is 2. A high-quality script for adding the pragma to > existing files, with CLI and GUI interfaces, should be packaged with Python. > Running it on your existing modules would be part of the installation > process. Okay. But what is with the Python packages available on the Internet? May be the upcoming dist-utils should handle this? Or should the Python core distribution contain a clever installer program, which handles this? > Long-lived modules should always have a language level, since it makes them > more robust against changes and also serves as documentation. A version > statement could be encouraged at the top of any nontrivial script, e.g: > > python 1.6 [...] global python_1_5 #implies global old_division or global python_1_6 #implies global old_division or global python_1_7 #may be implies global new_division may be we can solve another issue just discussed on python_dev with global source_iso8859_1 or global source_utf_8 Cute idea... but we should keep the list of such pragmas short. > Personally, I think that it makes more sense to talk about ways to > gracefully migrate individual changes into the language than to put off > every backward-incompatible change to a giant future "flag day" that will > break all existing scripts. Versioning of some sort should be encouraged > starting *now*, and incorporated into 1.6 before it goes final. Yes. > Indeed, but Guido has spoken: > > > Great ideas there, Bruce! I hope you will post these to an > > appropriate mailing list (perhaps idle-dev, as there's no official SIG > > to discuss the Python 3000 transition yet, and python-dev is closed). May be someone can invite you into 'python-dev'? However the archives are open to anyone and writing to the list is also open to anybody. Only subscription is closed. I don't know why. Regards, Peter P.S.: Redirected Reply-To: to David and python-dev@python.org ! -- Peter Funk, Oldenburger Str.86, D-27777 Ganderkesee, Germany, Fax:+49 4222950260 office: +49 421 20419-0 (ArtCom GmbH, Grazer Str.8, D-28359 Bremen) From tim_one@email.msn.com Tue Apr 11 07:01:19 2000 From: tim_one@email.msn.com (Tim Peters) Date: Tue, 11 Apr 2000 02:01:19 -0400 Subject: [Idle-dev] Forward progress with full backward compatibility In-Reply-To: Message-ID: <002101bfa37b$5b2acde0$27a2143f@tim> [Peter Funk] > ... > 2. What should the new Interpreter do, if he sees a source file without a > pragma defining the language level? Python has tens of thousands of users now -- if it doesn't default to "Python 1.5.2" (however that's spelled), approximately 79.681% of them will scream. Had the language done this earlier, it would have been much more sellable to default to the current version. However, a default is *just* "a default", and platform-appropriate config mechanism (from Windows registry to cmdline flag) could be introduced to change the default. That is, 1.7 comes out and all my code runs fine without changing a thing. Then I set a global config option to "pretend every module that doesn't say otherwise has a 1.7 pragma in it", and run things again to see what breaks. As part of the process of editing the files that need to be fixed, I can take that natural opportunity to dump in a 1.7 pragma in the modules I've changed, or a 1.6 pragma in the broken modules I can't (for whatever reason) alter just yet. Two pleasant minutes later, I'll have 6,834 .py files all saying "1.7" at the top. Hmm! So when 1.8 comes out, not a one of them will use any incompatible 1.8 features. So I'll also need a global config option that says "pretend every module has a 1.8 pragma in it, *regardless* of whether it has some other pragma in it already". But that will also screw up the one .py file I forgot that had a 1.5.2 pragma in it. Iterate this process a half dozen times, and I'm afraid the end result is intractable. Seems it would be much more tractable over the long haul to default to the current version. Then every incompatible change will require changing every file that relied on the old behavior (to dump in a "no, I can't use the current version's semantics" pragma) -- but that's the situation today too. The difference is that the minimal change required to get unstuck would be trivial. A nice user (like me ) would devote their life to keeping up with incompatible changes, so would never ever have a version pragma in any file. So I vote "default to current version" -- but, *wow*, that's going to be hard to sell. Tech note: Python's front end is not structured today in such a way that it's feasible to have the parser deal with a change in the set of keywords keying off a pragma -- any given identifier today is either always or never a keyword, and that choice is hardwired into the generated parse tables. Not a reason to avoid starting this process with 1.6, just a reason to avoid adding new keywords in 1.6 (it will take some real work to overcome the front end's limitations here). go-for-it!-ly y'rs - tim From gherman@darwin.in-berlin.de Tue Apr 11 11:42:18 2000 From: gherman@darwin.in-berlin.de (Dinu C. Gherman) Date: Tue, 11 Apr 2000 12:42:18 +0200 Subject: [Idle-dev] New here / prining from IDLE? Message-ID: <38F3018A.51722F7D@darwin.in-berlin.de> Hello all, I'm new to this list, so please forgive me if I'm going to ask stupid questions! After reading the IDLE-Dev todo list I think I already found a good candidate, so here we go... Is there any feature planned for providing printing support from IDLE, i.e. print source code in some way, the prettier the better? There doesn't seem to be such an item on the list, or I have well managed to ignore it. If I am right and there is some need for a generic printing support I suggest you look at a project of mine for which I just completed v. 0.4: py2pdf. It is currently available either in a pre-release version bundled with Andy Robinson's ReportLab package (0.92) or as the final 0.4 in the ReportLab-Users vault at egroups.com. http://www.egroups.com/files/reportlab-users/dinu/ There you have to register for the group before getting access to the vault, but at the moment I cannot put py2pdf on the Starship Python as it seems to be down... The 0.4 zip file in the vault has some bugs fixed compared to the pre-release in RL 0.92 and has the big advantage of giving you a whole bunch of sample PDFs created with py2pdf, so you don't even have to install it to get an idea of what it does. Please let me know what you think, but be warned that from later on this afternoon (GMT) I'll be on vacation until next monday, 2000-04-17. As of now there is not much documentation, but I'm working on it. Regards, Dinu -- Dinu C. Gherman ................................................................ "The thing about Linux or open software in general is that it actually tries to move software from being witchcraft to being a science," [...] "A lot of the programs you see today are actually put together by shamans, and you just take it and if the computer crashes you walk around it three times... and maybe it's OK." (Linus Thorvalds, LinuxWorld 2000, NYC) From guido@python.org Tue Apr 11 16:31:10 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 11 Apr 2000 11:31:10 -0400 Subject: [Idle-dev] New here / prining from IDLE? In-Reply-To: Your message of "Tue, 11 Apr 2000 12:42:18 +0200." <38F3018A.51722F7D@darwin.in-berlin.de> References: <38F3018A.51722F7D@darwin.in-berlin.de> Message-ID: <200004111531.LAA08150@eric.cnri.reston.va.us> > Is there any feature planned for providing printing support > from IDLE, i.e. print source code in some way, the prettier > the better? > > There doesn't seem to be such an item on the list, or I have > well managed to ignore it. If I am right and there is some > need for a generic printing support I suggest you look at a > project of mine for which I just completed v. 0.4: py2pdf. Funny -- I believe that Andy or Aaron suggested that they would add printing to IDLE (via PDF) if I wanted it. Printing is definitely on my virtual TODO list -- and I've added it to the real one one! I don't have the time to do much about this at the moment, so if anyone else feels so inclined, please send patches! (see python.org/patches) --Guido van Rossum (home page: http://www.python.org/~guido/) From gherman@darwin.in-berlin.de Tue Apr 11 17:41:55 2000 From: gherman@darwin.in-berlin.de (Dinu C. Gherman) Date: Tue, 11 Apr 2000 18:41:55 +0200 Subject: [Idle-dev] New here / prining from IDLE? References: <38F3018A.51722F7D@darwin.in-berlin.de> <200004111531.LAA08150@eric.cnri.reston.va.us> Message-ID: <38F355D3.8BF9EE12@darwin.in-berlin.de> Guido van Rossum wrote: > > Funny -- I believe that Andy or Aaron suggested that they would add > printing to IDLE (via PDF) if I wanted it. Printing is definitely on > my virtual TODO list -- and I've added it to the real one one! I > don't have the time to do much about this at the moment, so if anyone > else feels so inclined, please send patches! (see python.org/patches) In any case, py2pdf 0.4 is now on the starship with all samples available for individual download: http://starship.python.net/crew/gherman/programs/py2pdf Look especially at: demo-test3.pdf in the demo subdirectory! Kind regards, and back on monday, Dinu -- Dinu C. Gherman ................................................................ "The thing about Linux or open software in general is that it actually tries to move software from being witchcraft to being a science," [...] "A lot of the programs you see today are actually put together by shamans, and you just take it and if the computer crashes you walk around it three times... and maybe it's OK." (Linus Thorvalds, LinuxWorld 2000, NYC) From bas@andrew.cmu.edu Tue Apr 11 20:25:14 2000 From: bas@andrew.cmu.edu (Bruce Sherwood) Date: Tue, 11 Apr 2000 15:25:14 -0400 Subject: [Idle-dev] mouse selection extension Message-ID: <1983975068.955466714@MUON.PC.CC.CMU.EDU> Maybe this has been discussed and treated already? Idle currently doesn't let me make a mouse selection in a way that is common to all word processors: click somewhere, then shift-click somewhere else to form a selection. Could this feature please be added? I find it confusing for this standard editing feature to be missing. Bruce Sherwood From guido@python.org Tue Apr 11 20:54:11 2000 From: guido@python.org (Guido van Rossum) Date: Tue, 11 Apr 2000 15:54:11 -0400 Subject: [Idle-dev] mouse selection extension In-Reply-To: Your message of "Tue, 11 Apr 2000 15:25:14 EDT." <1983975068.955466714@MUON.PC.CC.CMU.EDU> References: <1983975068.955466714@MUON.PC.CC.CMU.EDU> Message-ID: <200004111954.PAA09609@eric.cnri.reston.va.us> > Maybe this has been discussed and treated already? Idle currently doesn't > let me make a mouse selection in a way that is common to all word > processors: click somewhere, then shift-click somewhere else to form a > selection. Could this feature please be added? I find it confusing for this > standard editing feature to be missing. It's some weirdness in IDLE. I'm aware of the problem but am afraid that the solution (to this as well as many other little annyoances) will require completely redoing all of the Text widget's bindings in Python... --Guido van Rossum (home page: http://www.python.org/~guido/) From glyph@twistedmatrix.com Wed Apr 12 20:46:24 2000 From: glyph@twistedmatrix.com (Glyph Lefkowitz) Date: Wed, 12 Apr 2000 14:46:24 -0500 (EST) Subject: [Idle-dev] Forward progress with full backward compatibility In-Reply-To: <002101bfa37b$5b2acde0$27a2143f@tim> Message-ID: Language pragmas are all fine and good, BUT ... Here in the Real World(TM) we have to deal with version in compatibilities out the wazoo. I am currently writing a java application that has to run on JDK 1.1, and 1.2, and microsoft's half-way JDK 1.1+1/2 thingy. Python comes installed on many major linux distributions, and the installed base is likely to be even larger than it is now by the time Python 1.6 is ready for the big time. I'd like to tell people who still have RedHat 6.2 installed in six months that they can just download a 40k script and not a 5M interpreter source tarball (which will be incompatible with their previous python installation, which they need for other stuff) when I deploy an end-user application. (Sorry, I can't think of another way to say that, I'm still recovering from java-isms...) :-) What I'm saying is that it would be great if you could write an app that would still function with existing versions of the interpreter, but would be missing certain features that were easier to implement with the new language symantics or required a new core library feature. Backward compatibility is as important to me as forward compatibility, and I'd prefer not to achieve it by writing exclusively to python 1.5.2 for the rest of my life. The way I would like to see this happen is NOT with language pragmas ('global' strikes me as particularly inappropriate, since that already means something else...) but with file-extensions. For example, if you have a python file which uses 1.6 features, I call it 'foo.1_6.py'. I also have a version that will work with 1.5, albeit slightly slower/less featureful: so I call it 'foo.py'. 'import foo' will work correctly. Or, if I only have 'foo.1_6.py' it will break, which I gather would be the desired behavior. As long as we're talking about versioning issues, could we perhaps introduce a slightly more robust introspective facility than assert(sys.version[:3])=='1.5' ? And finally, I appreciate that some physics students may find it confusing that 1/2 yeilds 0 instead of 0.5, but I think it would be easier to just teach them to do 1./2 rather than changing the symantics of integer constants completely ... I use python to do a lot of GUI work right now (and it's BEAUTIFUL for interfacing with Gtk/Tk/Qt, so I'm looking forward to doing more of it) and when I divide *1* by *2*, that's what I mean. I want integers, because I'm talking about pixels. It would be a real drag to go through all of my code and insert int(1/2) because there's no way to do integer math in python anymore... (Besides, what about 100000000000000000000L/200000000000000000000L, which I believe will shortly be lacking the Ls...?) Maybe language features that are like this could be handled by a pseudo-module? I.E. import syntax syntax.floating_point_division() or somesuch ... I'm not sure how you'd implement this so it would be automatic in certain contexts (merging it into your 'site' module maybe? that has obvious problems though), but considering that such features may be NOT the behavior desired by everyone, it seems strange to move the language in that direction unilaterally. ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://www.twistedmatrix.com/~glyph/ From bwarsaw@cnri.reston.va.us Wed Apr 12 19:56:32 2000 From: bwarsaw@cnri.reston.va.us (Barry A. Warsaw) Date: Wed, 12 Apr 2000 14:56:32 -0400 (EDT) Subject: [Python-Dev] RE: [Idle-dev] Forward progress with full backward compatibility References: <002101bfa37b$5b2acde0$27a2143f@tim> Message-ID: <14580.50912.543239.347566@anthem.cnri.reston.va.us> >>>>> "GL" == Glyph Lefkowitz writes: GL> As long as we're talking about versioning issues, could we GL> perhaps introduce a slightly more robust introspective GL> facility than GL> assert(sys.version[:3])=='1.5' sys.hexversion? Python 1.6a2 (#26, Apr 12 2000, 13:53:57) [GCC 2.8.1] on sunos5 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> import sys >>> sys.hexversion 17170593 >>> hex(sys.hexversion) '0x10600a1' From glyph@twistedmatrix.com Wed Apr 12 21:06:17 2000 From: glyph@twistedmatrix.com (Glyph Lefkowitz) Date: Wed, 12 Apr 2000 15:06:17 -0500 (EST) Subject: [Python-Dev] RE: [Idle-dev] Forward progress with full backward compatibility In-Reply-To: <14580.50912.543239.347566@anthem.cnri.reston.va.us> Message-ID: On Wed, 12 Apr 2000, Barry A. Warsaw wrote: > sys.hexversion? Thank you! I stand corrected (and embarrassed) but perhaps this could be a bit better documented? a search of Google comes up with only one hit for this on the entire web: http://www.python.org/1.5/NEWS-152b2.txt ... From bas@andrew.cmu.edu Thu Apr 13 20:51:17 2000 From: bas@andrew.cmu.edu (Bruce Sherwood) Date: Thu, 13 Apr 2000 15:51:17 -0400 Subject: [Idle-dev] Re: IDLE-dev digest, Vol 1 #34 - 4 msgs In-Reply-To: <20000413160048.A28D91CF28@dinsdale.python.org> Message-ID: <2158338138.955641077@MUON.PC.CC.CMU.EDU> > Glyph Lefkowitz writes: > And finally, I appreciate that some physics students may find it confusing > that 1/2 yeilds 0 instead of 0.5, but I think it would be easier to just > teach them to do 1./2 rather than changing the symantics of integer > constants completely ... I use python to do a lot of GUI work right now > (and it's BEAUTIFUL for interfacing with Gtk/Tk/Qt, so I'm looking forward > to doing more of it) and when I divide *1* by *2*, that's what I mean. I > want integers, because I'm talking about pixels. > It would be a real drag to go through all of my code and insert int(1/2) > because there's no way to do integer math in python anymore... If you object to int(1/2), how about something like 1 div 2, or 1 idiv 2, or even, say, 1\2? In cT we have both 1 $divt$ 2 (integer division with truncation) and 1 $divr $ 2 (integer division with rounding). > The way I would like to see this happen is NOT with language pragmas > ('global' strikes me as particularly inappropriate, since that already > means something else...) but with file-extensions. For example, if you > have a python file which uses 1.6 features, I call it 'foo.1_6.py'. I > also have a version that will work with 1.5, albeit slightly slower/less > featureful: so I call it 'foo.py'. 'import foo' will work correctly. > Or, if I only have 'foo.1_6.py' it will break, which I gather would be the > desired behavior. Doesn't any of these schemes mean that you can continue to have 1/2 be zero if you like, forever? How would it impact you unfavorably for 1/2 to be 0.5 for files marked as using the newer definition? I agree that there is some advantage to using file extensions rather than pragmas. Bruce Sherwood From Fredrik Lundh" Message-ID: <002301bfa587$762b9940$34aab5d4@hagrid> (if you possibly can, please fix the subject when replying to digested messages) Bruce Sherwood wrote: > > It would be a real drag to go through all of my code and insert = int(1/2) > > because there's no way to do integer math in python anymore...=20 >=20 > If you object to int(1/2), how about something like 1 div 2, or 1 idiv = 2, > or even, say, 1\2? the plan is to have two distinct operators. if backwards compatibility wasn't an issue, those operators would probably be: 1 / 2 =3D=3D 0.5 1 div 2 =3D=3D 0 or maybe div(1, 2) =3D=3D 0. unfortunately, changing to this scheme may introduce some really nasty bugs in existing code... > > The way I would like to see this happen is NOT with language pragmas > > ('global' strikes me as particularly inappropriate, since that = already > > means something else...) but with file-extensions. For example, if = you > > have a python file which uses 1.6 features, I call it 'foo.1_6.py'. = I > > also have a version that will work with 1.5, albeit slightly = slower/less > > featureful: so I call it 'foo.py'. 'import foo' will work = correctly. =20 > > Or, if I only have 'foo.1_6.py' it will break, which I gather would = be the > > desired behavior. >=20 > Doesn't any of these schemes mean that you can continue to have 1/2 be = zero > if you like, forever? hopefully not... > How would it impact you unfavorably for 1/2 to be 0.5 for files marked = as > using the newer definition? >=20 > I agree that there is some advantage to using file extensions rather = than > pragmas. like when you're cutting and pasting code from newsgroup postings and webpages? pragmas are bad enough as they are -- encoding information in the file name makes things even worse. what if the file is accidentally renamed? how do you figure out what extension you need to use to make it work again? what about systems storing code in databases? what about writing unix scripts in python (using the "#!" mechanism)? what about piping code to the interpreter? how do you handle code embedded in other files? (like python scripts embedded in html?) etc. (besides, "import" is slow as it is. having it look for a whole bunch of possible extensions isn't going to make it faster...) From mhammond@skippinet.com.au Fri Apr 14 03:56:32 2000 From: mhammond@skippinet.com.au (Mark Hammond) Date: Fri, 14 Apr 2000 12:56:32 +1000 Subject: [Idle-dev] Fw: Deadlocking IDLE under Win32 Message-ID: This is from the main Python newsgroup. In summary, it appears that under IDLE "print", via OutputWindow.write(), via the Tk test.insert/see/update methods is not thread safe. Id like to fix this, but I need some Tk help WRT events, If anyone can help I would appreciate it! The obvious (to me) fix is for the write method to use the Queue module to save away the output, then to set some sort of event for the main GUI thread. This thread simply unqueues and prints the output. Is anyone able to tell me how to trigger this sort of event under Tk? Under Windows, each thread would simply perform a "PostMessage()" with a custom message. The main event loop would then see and repsond to this message, giving me the required thread affinity. I have no idea what the Tkinter equivilent is... Thanks, Mark. "David Fisher" wrote in message news:<00aa01bfa53b$2fe73bc0$0201a8c0@spkydomain>... > > ----- Original Message ----- > From: "Mark Hammond" > > > > My guess is that the "print" under IDLE is not thread-safe. Change the > > program to not print (or to append items to a queue, which the main thread > > then prints) and see if this is the problem. > > You are correct sir. Of course, your guess is a bit more educated that most > . I ran into the problem printing from multiple threads in IDLE a > while ago, and just assumed it was something that everybody new about > already. I'm pretty new to python. > From casa@sdv.fr Sun Apr 16 01:08:24 2000 From: casa@sdv.fr (Michel CASABIANCA) Date: 16 Apr 2000 02:08:24 +0200 Subject: [Idle-dev] Patch for IDLE Message-ID: --=-=-= Hi all I propose the patch in attachment to implement a config file to choose background color and font. I don't want to subscribe to this list (too many mails), so please send responses to my personal email. Modifications are tagged with "casa" (my nick). --=-=-= Content-Type: application/zip Content-Disposition: attachment; filename=modifs-idle-0.5.zip Content-Transfer-Encoding: base64 Content-Description: Modified files UEsDBBQAAAAIAEgMkCjru7nU5BkAAKZaAAAPABAARWRpdG9yV2luZG93LnB5VVgMAIj9+Dh4/Pg4 9AH0AbQ8f5fbNo7/z6dglctZbmwn017v3ZuNs5sfk3Zuk0xfMtl033SelpZoWzey6BPl8fi6+90P ACmJpGiP0307r40tEgBBEARAEHK+WsuqZmqnTnL9VbbfVF3l5aJ5qkTzDT5O5pVcsavbvKxFxUz7 tw1AffsJvhXiTc4Lueha3wul+EK8kvctqawQd6JqHr/kZSa373JVNy2pLOf54uTkEbtaCpaJOd8U QIrPmBJ1DeyxuawYZ1fivmbbPFuIesTyknGgCkONoalesnTJK54Cq2pycvXn5Orlqy8Xb65+St6c v335+d0Vm7L/wiHe5oVgK1Fu4OHfGDBW1uz5c7kW5Xgls00hXrzAji3Qf/6yqMcretyU+T17/lqW dSWL8f2L9it09+ikBVdqPKvkVonKI5ceJjcLkFvzemlRs/vTQiqcP0r0xWHKz8LdfxY709Wy+PY/ cBB2nuV1X1Cv5XpnTamhZE8LaWxdPl9v6gDSfYAlD/FnrmoRQL0LoO5cVCUKkdZjXhTeEnCPV07T /UkU6/50l9Bqob89tXDxwYblM7mpx6jtL7QAsV0BYr2EDqLNoKXKhXLwKrGSd2Ks+c1laY13rlK+ Ft6aC9yP47wEdQhJtQiIpnBJZHJcynoJOyusNCcnJzSZpM5r2C1TFr3ER3bx5t151HThZoSeKPr1 BNvZY5jVy5JdAHeLitciY29gvHdyvcJBz8u7vJIlfcfd/PMOpFKenMx27MdNnkl2x0v2USq1WZ0A Tfa4MRsTJJ785fzjp4vLDycntLdIN2WlLcnZyQmDPzJWP4sqlQWHvsZedS0d1GtZyOoNiHthQ7qt HfRnGKQH7DR2sBeXr4AntFgGrm0gGNNomlSH5xnZK7nGuRcdwHuwiPmnmtcb9Yq3cG6rloO7cNaT 3avXrnvQqHe8UtD82z/0IxhiliR5mddJEoN2zkdsXoDZnn6QpYDvYEhLvhLm8VbszLdKSg0zPCM6 +JeuKzFH4khn4op6ojtbWAKhkQCePtsuJA2N9AGLQZ0TfHKRLbC2I59r8I6nFtzMW1PDB5cabtwZ CH3K3sO3GKkOXYharqFX/0sNzQIS8Ii2/tSm5eHfafLm41MKu7CA7zFQHDGS8QD7Bv6wsHLJvIJ+ HN1+eIufiB7AMLDwgf407vCaobBlMGJrnt1Pfxg54gr9wW6GDS83ZTbVCzl5/UFWK15cP7t5GHvG 09sw9ukR2Mt8sSzg/zpFjWop/JQXeS2OGr+lEGDEkDmGEW2NAzRebyolq6NobCu+nkYlbJxoeOKu W1oJsKhGeWJvUfl6XeySmTEqsY8LWjBZV7KWIKM4+vIeAqJ351fnyZeLD28uv0QjMwJGEn21niDZ OPIjDQcrIbfS4aL+dHiut2oRqTnRzQcJaA/c4OFTklHIuQd+TY5lnMlUdWi6McHGPWi2826wtH08 OJoTNzZ42Jjoxj1otgMGrIKvZhnX7vmMRTNY7dtoD6od1jQD6rYE2vYg9UOMBlX3JG1PmMD3HTzu lQQ10V+1sIHVRjUvwZMrkeVpfY1kbsD6gMNwIAEfms5620RTIFTovzEm1gHrL0kptj1l1YSgJ0k5 2tf0drifitZ3gDNklE9Hqz4AHEMtdCxwtIX6EtP3ECH3QODQwa6OTEsHvcf1IJWrFS+zwY1xAZPd XS62DtBkDROJVZ6J6ceLH3+6IjdfTP9q0ULM68FOkZeySRI+nNhayEcs5YqzM0YWqjnmWesNJ9LJ GoIzcCGr67PvgciUDUDeg7OeBK4HcwhPaZxYE5pgw4hZD5/y/xPDB+kXQJ8dHMAi2Z9LZ+MZOR1P Ll23TaprdcC137Vk/u78bSPyV5dXP42YuF+DeKen3rbsMK4ufz4GYS7TjYJdXvfcw1pgzKH/pYYu YqbYwBUoAuRKm1MlN1Uq4iYOHAYiK5IQiUF/BqK/ePgHHH2iXQEQA78QE7y7DR49WlcQJLPoAgJS MMmaJqx4FbVwolDiLIz1QbJ8P2KPYQxfXTnB2knoMB/U5BwCgvNAaM+p5oietzTaAwJF2N42o0GT WSHT20TVvKoNA732A1gUlPaR5LrFoU5QjUTxO5El6ZKXC5EspbyNtXfxmy2V0IiNCvRxQz3WJNFn GAh33aBDwt4FazYR92Bu1T41M1wUkmcI0YE5UH3FCHBv4bpL1peLD4HDJyB6USrwoU4MRsf+aXeS QEc2WcBGHBjHMnB2GIK4nAqwNFNqB93KxH0cQUs09MWFYLkixe3PVNMYn4aQXkzZsz4GjcezDGzG mldawfeQxX+fsNP+ZtrqMKEBcgC6LCCEIAv4gGiwcaRaddZS1UZESMcS6SP2ScIxh89UjRk/lDhT krITrFsExivBwEmBz714c+6FzOp2J1SJu9DOWLbtPWg8ni/IRrp5T6vP05ml3IqqkpU/RNvh7ALC 6XifLLlKINqJBy83tbyAZQfXFDKwHcq1DXpDip3TA0cBJbiIKxX3lvCgRfdMF9kIyjYk+hjSpgm8 HjJlZx5y293sBjd7EXtHWn/sFp3YKPgMTtcQ0RSbVQmH1QE4lTP2R/jWxS5HUYBoQCD+u/J49M77 gs+9unxvHPAvgcO2DtwGmGb9CJ6CK/FiMOqkiaMn4K8TPZEDBF5t6lqWv5MGn9NhCw438X40ZzG9 XpP+oYjfT+0gKIZhCIdLSxcKE7WGs3O3psZ0XXz4dP7xagjynvjJjKMW+LEasMcsONGHl1cjY4s1 2S2/FZu1r7HNjsQT8HZFqi3iIYaPUQ4hXZ5Ggb1ogDNBIPOdZTD7/qfFqG8rnivhH+rDURsZVLUW KearrluMOMItCweBKMHrjWg4srrg1FVTFyZN3S5jXqn3i/nuAOBxm3oxO9503XTSc/MSnhBX1l43 IP3EGrpD497M19/+0UJhorikzBQtJ975tIhaDK5QIZIRldZHjQCBbSXWoJIxPbserBnzGoe4MUw0 WT5k3iTE+uEEdpJzhDNByjOhqU/pX5Ptw39GHUPT9pu3zmg56DitbHvq+T5fso/YZYkHKvCXImPb pSiNP1XmloFCJgv8l19+YS/TegMIuxGrlxAo/PdG1eOLcnyVgyvdrDNOF22Uhp6LSig46GTFzqOB dxmALiDO5NVYziF8AwXYVGLC2EXNtnJTZGwm4L8a09m11JSFRwbYcBhWNAfM9hNxSv3KOTMSYDry UpODMdV1G0/ddNvugdDpUNjUC5macMmLbc56OjXJwErXxtS2cE9OR4jfDW5FQKhKhvuklqQOsRXz VGa+dChpdcTPxNg22ne+ZE1qvkh0uieOoBX39enkGX64UukwVry6JfMT6VMNwv7pcTZ6nOEFTUxD Te7NmJPd0JFsKWuTMurHtHrlwPQm1GkZv8peW3pw+dJXWFM9ZDecwiuw6f6Egs0YAYesMU5ZH9jj lNK204hDpLaNPPbAZidruQa3YSSQ6DS/EUPi3hB85Yj5TPBVZK98wOA/Atv8Dq0Nrsjz53d5hXt7 TAy8eAGGmk0m3XaJo9eYrNKwXiIXQB+x83uOIa1v3a0F8gxQZZvKdiojMgtgFabPuumjDTeGkdhD a9oa8mqfJSfnonNLlIWYWoO0ZKbtt8ChkGRLAMkCbAveSMYdvANetYedZkjHnpvGqfn0NkojCq2r rezs3PGh6Kl3NsjLuYyt9DPd3TkJaZJCb77u3wrvzatOakaf0J9jqIAXt/h9Ut/XUce0lV0/yHPl pWktss2p/X9kXsbNQ5ZXdMBO6KydJEMrm48tVqB0n4p1zT4A9DkekvaO4+D34rZ9N306dYuZ0jgw djhIs7MLHRLBaW/2Nr9Ht6UE6brxa624E8yx0skxKkVN9/lsjGa4FmyAnGyqIn4cw79DNRyw7148 zcTd03IDLvLvf2cR+zWw0h0lg8j+PeoGhBZa37penz19ut1uzfXHRFaLp5lMn4KpqWBZn1orb12Q HFr5dJXZsm/m9pj9FsGo0ZnVBc9dIAeKAKYZIsUYKDhHjebi4tCorguDfRrwX+PT9GgXhlghWCVE C2aZfAEBTtncylj+17s5OX4GX+eEXa7a4a1LpkMjaxX9tMTIrBzUOvabkQXuihWwrqGkyigMR/64 f6OX+nq5Yw4TWTgPiGMrRcLFhwKsT9Tb1FdpEdjThmR0KIvbDGuOlvCxjl0zbuKNfiLRoPazNppY HL0nEUZ7DGp0TnUZGJUSJYhKualdYVr4v5bRHlSIfhX4w3TJAJgiE7CFDDwIrd3ZviHXHDenbbrt Xpxob5LHyeignPBPa7qnOpcbCDMxklebNRWdYPYD/BXMqKz5/T5orbDMmBrK8g4UA0cAm0VWO9S3 eSVLivNRLvt1Lp7rWpMRi9VmPs8h3gTJw2O9W4vhELPpqzXoX5k128GdttG+uPUpI3ZB5TP0AK5o pRbedVAwXxdHGo3RE966wbEScIejB5bMEyssAXLOvtGM//zX5NPl54+vz4/j4XNp1gEOfkgmoEXR Y4VHGlxnznRKz+gqRu36PP21HM+9W119/Rk7G/BYz/vVXtfyuK3lcy5MDxnAJpnZmC0g3DT51iN8 FbFnJfpi/yBbCqFVuSLLCxoM9mTJcX0YTEGmOdXKHcDsx3I9afWyRTaEcWDOldZS8Ax2EM8LK2bT Obv+DcqMK4E3i7UPS/VDQMNSA1NLh6vzSi9O22c3TuyHuNOQkRnsGhm88Rfdvt0+tOZN7R+A+0xY bRPru8WCNehC1hJzNmYs/FpKN02o25r9hnyQhTfNL/yrlcOByeMMQgGToyzlvnU+NoToY9mhUzeq MdVPTosQsq7UsZNT3m2Blk3geu7grjJKeXqckjUNCORe1TkWqAEr4fifAmiMuwVdTRxBDIxzhQ84 zj/ASs8FzZGnxnT1nSouF9YPTiBCzEhf3P6+tTQ+6eIyEBAZdp75ASgSvj77Tuc0Hn0zID0z7h69 X6wTnwO9OIMhXexZqVqqV2lvZgPJ7sOm25R6ZSar790XeNRH1nB+GNz1YGFA+9DR23ub/NU8e5Qy m30HPHTD6w8VUHvbmYRu52C/tcUGD98GgM5awF0mwSayRwwEEFKjLjxrCiFeZlmoAkKZWhBTEGbq F1RT+eDJ62A9R5+mUxPRETgKUo/enbpWh4TR5hy/QiAfacL/vEzCgKGJ7i8yOUoE4TINe5stJZWK KHMRXZkskrU0hYRj37QpXigXPQDULCJD3gwgvKDI1JdrmCcsYmP4/wlBWnreUDmA7ELvH8mj7O+g 9k2FzyV9zbplxOu4llXMRkp95O2q4s2EW+1ZNMUw8XDPKN8+Vt+ip3ZpWKMhBL3FAI/eoV5fE2qB 07+BslsAQEzydfjFDkpa5vykrPYTrcrY0/Cu6lt0LOnnC99EuxVBMYHYiQ/sQpjgRT8hWzD22JYu eqhHhunhYMJC3h8p+HJqybfsWRvhgGgtzlCLIislFKhqPnQr0w+tTIvGwQhx2mZ+rPSrDpLa0K7r wNcFZrLthPXXeX6MDJS9+3V02oHphhhH7KCWAm+YAApJjpldMlaKrS4sW/H7+LSJjAFI4zz9zis/ pEJT0CPJ61jjDl2Ntvn0ZH9ouv0pRH96NrKze644LKD//OGH739w7wKJoJ4uWj3inPLxiZ6WrgA4 9SoM2Y9CrgTEjCCMki/06Q5TbdWmZDurHNaRKbieWFeM6qbBjRszar6RoycN0tgKUY1CNivuyNJM 8ncqkaGM/On1sso3SD/slbPq/w8qugl/W7wV380EGpd9AU0ug0FxswE7fJ+ZoEk6UJnR9vfrMCqB VcvNNbM1osWshvkG7H3KyxROVoG4LvGjfzMZwrVetQryb90Sb8pjK+V8aXZRdqhGtwvd/doE8w6W E6eYOCmn+OGZi7Ap+4WQDgAsnRHGH6xq2L3FtnScpsTiMRGvw1kHNOnaHfBMLpvKZI1E5ymjDgEx aVrEPaAOga/XtOQNCaqz8/RKb7L+/MwbZ+EA0JWQrsx2IE2o0rG+p7QoE3A8lDt7j/jrE9otVgml U41jgkUgoGqQFa9CJa84SF8NfGdPFw6qvQa2Ch/veLFBX9UrBwajyuu6igEPzvEkI/8gT5BAw99v wVm5IgnNKMC0c3m90EWPHl6CML0J9FIKrkBb7EDKXucK+tjm+PKW51gEVEuaSFf/Go3Y35DY3/oi Mq/qVzwVaER6AG3PhMYA7tLYD0D3zdu35yZljlBdAbAxgLp10tDap6XGs3iH7JXEq8gk0SMkSawT 24tCzngB8oegRKbm27XlXNMCFQDmQNoEVAzljmXSEAALJQqsetumagzgW5jbjKSAtRrRrdjBXFR0 Y+9bu0ClKU75/jvvfRdDBV/sE/jaT1Ma1FC0MwkhmiuePkARIILU/FOVj4cvigcQTUu/eE/j444x lA5vaw0U2NVmgImuJoub1bORHK9n4EMpGfdlSQPo5euA8ztdaIScm7Hhs7et8Q9iv6XM3Os3dO2w h2JNBezVmKoovfwq/m2X+vcoGhrXZ6c6w/d80B+qN5yFd3p28zDxMUAR9RdfSf1sfNonvwcY0wE6 JuzfjPor3mEFJIt/XQKbCqEbgToaYBFxtMB1GVQoSHobyhd2ZZjoQRrYEespSBsfKytF5yqVtlcG s3c30WpnuO6w20vEWPNbARPzsyjN7jvieIRC66j5eKjkRpjQRZGepex5LVYhL2xA+2tFIoitoiue gWXVFVejIahEvVnDudrg22cIS/RacK3U9sqQfsWloFt5QpxQIZqCBl7Tax98pnD3whQphMztS20d zjf1xgidL0pZiWxir9H+BQquTqMw/7JltgqknQk8rAe40CvtHHFVm5Xu20dTyOa8pLTaW0LQL+rE Pzhf1Xm5cVNiFO7B0Dhsw0IgctN0EWCfbTrmlaTgm174ZxchotuGcYJw6VKktzN63QJfNiW01ip/ M+gPaZi38MIMtExgNpOohmw2/n1dHXvzx1M4jQgSjI5wEqul8XTNCT1IoVd1aRVcTv2Tvf+3t+Dy n5PYXfcSAUyp4ltoMGaFvZKyELz8C6/CY+BfV9vZjebWdwaK9A+XV3oFoSNb8lPr+2EqMI+czwox vdvH/n5ddicWKlr9l03KPQjc8SocngeXrVezBY3BPA+0k/lx89buYCNGZ0X8qLASxncSezloMQ6z cqffJIppFHfWhpjLy0NM4JmfJhWsXENATEAYOoEQBfHbQ4ema4C7CuxemHLX/CzQI3Z1y6gEbtW8 E6iw9ioytePaf+hISkVsPGaCp0vWnCsMjUpsFKZK8FXLgWpLwlKZCVYKkSk8h4KQ8EK8K4nNa8V+ /HwxUIbKvOB30ExveOCPuU0aFi9U9ytuDFw5vQ1IqUf6ubem8E4H2X9k7KO5KsdRDIlosQECZQ3M gFwh6q6rjeaClzv6xQ3aVhPGqB4Hs7vooMX9Gs91d8KQgWnARlhvaowl9JvjcsTAeiDwuoIz5qzY MV7gjf+O3ZZyW7LZDudsCDSCAym1N4sTu4YCL/DwqiAxhYhamboZH3fL+6iRAU0zn8+70Zo0dFyJ 4ULWcG7VxZ9z6zUsTWKHv6cndZVjJ38ArfliAXLkWDGq3w7CijL9i4GBXdvF6lhsAh7rrsI7yji6 unxzGTmTw+FClc0s+nT18eLDj1GbZWnp6fyCRePAuVX/kmAnCpjLKleoumdYdLVZkXqyraxUHZrJ aauRWO+pmhJfpKO1O0P+9ItQ1m8SGuyY3skfGRL40g+KsPmNL8LAcC8V4I0lEKm2OeyUBllHvmRH 3JRLw0VikHsXJb2yFazJdcp1zVtQqi3Y9QpZ+H54r6bXEhZRGhFytySHSn6tgrSR9VJTp8uuXHEL mTJSvEYiu0GBvv6JSLwjWUEU0FiXWPzvJgejjfD6lyFRldZwHFfDiZvFAnyC8CXZDGeJ4noAwGpw g4ob+HXJ/vGwjg2V9l2BT6L+vVObuPe3Dt8juo0zLcfc8DTmxJHAEC8xLELuiq3ze0F5M70bbyd4 ARFH+AspER2tudpUwmzxa91+xC9ewXYfZ7kCW7mTc4M90eWORyGXEfu2ZRom7+BYL1cBbzEu31TP A1aE3nkwIbUyQtO/AalfWwRcNIO0XhRAqRSOiPq3+BoTCIHxZDFp7L0hFr2WyXoXDY0iKBZ/BwLC X82Mhho279JEVLYFRmCQmGMFvivm/SADHRGvz/IbOEOr6/xJc2ZoFO3/C7mW3oRhGHzvr4i4tAha uA4xJLbzbpwGXdRC2KK+UB/btGn/ff6SJrRQthPUr5qQxI5je8oqx3HIuzeRx2+HuTEpn4g6Fcfa XTB3607PQFU3CGiooBWt2zc8zujxR4/MP2cHrZyJGtjQgnJuOh5/69lchQxMQYWODrWxCZBs56EF lSKomtgrR/428r/CXXxuk5UtzPiR+yFKLwvQWufkjVFWNL6WsIt3H5MLAWa89CHXCJiyv2WN0C0V E340iDUNNEHxWJfqywCZwk+GcaslkGwYubz96lUfZQyyo//Po/wkU3dQFSyVbmBopvxTlAiGxauD J5sEWfpFQ+cSf5/KfaKc0pyWwwz2XBao1SVRLXdxwgxRvmRDJqxoSm0fpbKWqlgC1MyTAblcEU1X dKSQR2maXNVIAoRCtKm0AL23uPU+5eB9gNJrNDBAHX/EYvqY4/Yts5qDLCB6mGdcHYhDXxRtmeA1 EuHiVABgZq3957l/x0N3fJMnL/I+20ufT49xLaraBMza/pMbc6M6MP6WLsDOdaAThWdXDQL6Ufn6 jvjAcIaMJdALpu8AdQjttSESH+m52zdV6XGvK1dtL89+tgy4gov0TqUzWdjuT8gimadFcfI6sM7l o0QfUZWHyVUQhXMwcN7GoPXIOb9QSwMEFAAAAAgAZAyQKLLJw93PAAAANAEAAAkAEABjb25maWcu cHlVWAwAnf34OKv8+Dj0AfQBdY49a8NADIb3+xXCHgKBCwkm4Bo8JS0UkiUdMoQOl/tIRM+n4PPh pL8+sinFHSot0vtKj5SDpuDwAg69BUctvG93ryIHlbordxXsUV+th42K6owqaCUENjdqO4iPKHjS UejGzSMGQ30U6AZrcfOqY7k5VcUn1DXMegyzSgDHuFJD5pNGo4YXInmb/Xof+G3ZL6f0HYZ0/5ft mQ1/4XIu3/Bujdxbg6mRBxaGXBXLn2ouMVJZrl/kKuNTZ6W/Li2lYPgjT62YCMzL3XLITDwBUEsB AhUDFAAAAAgASAyQKOu7udTkGQAAploAAA8ADAAAAAAAAQAAQKSBAAAAAEVkaXRvcldpbmRvdy5w eVVYCACI/fg4ePz4OFBLAQIVAxQAAAAIAGQMkCiyycPdzwAAADQBAAAJAAwAAAAAAAEAAEC0gSEa AABjb25maWcucHlVWAgAnf34OKv8+DhQSwUGAAAAAAIAAgCMAAAAJxsAAAAA --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --=20 +---------------------------+--------------------------------+ | Michel CASABIANCA | http://www.sdv.fr/pages/casa | | mailto:casa@sdv.fr | Articles sur Java et XML | | D=E9veloppement Java et XML | Applications et Applets de Jeu | +---------------------------+--------------------------------+ --=-=-=--