Gregor Lingl <[EMAIL PROTECTED]> added the comment: > > I find that desire misguided; this is (IMO) a case of false abstraction. > > Is there any kind of proof that this design actually > > works, i.e. can be ported to a different GUI library (like, say, > > PythonWin? or AWT, when run in Jython?) Yes there is. I have a (nearly complete) port to Pygame. (The only exception is the ondrag method, which I will incorporate if I have time for it.) It runs all of the turtle graphics example scripts (except colormixer which uses ondrag) without problems.
> > Unless such proof can be provided (and then integrated into the code), > > I recommend to give up that objective, and start merging the base class > > code into the subclasses where reasonable. Sorry, but I definitely shall not follow your recommendation. I have presented the architecture of the turtle module at Europython 2006 in a talk which was visited also by Guido v. Rossum and later in Leipzig at a workshop where you yourself, Martin, was present. On both of these occasions I showed working prototypes of this port (along with another one to VPython) and nobody had any objections nor were there any objections by other useres who have used it up to now against this design. You can find this also in the "Tagungsband" to the Leipzig Python workshop together with some screenshots. I'm very confident that this is a good design and I know (form the experience mentioned above) that it works. So instead I'll proceed with porting it to Jython and I for my part would consider it as an advantage to have the same turtle module in both of these flavours of Python. Two more remarks on this discussion, a specific one and a general one. 1. The bug I submitted a patch for is in the method setup() and in the __init__ method of _Screen, both of which usually will be called only once in a program.So in *this* case it cannot cause any performance problems. The bug has annoying consequences and I found a simple remedy, which I consider appropriate for a bug-fix-release like 2.6.1. I don't see any reason why to keep a known bug like this one in the code. Acceptance of the patch will certainly not affect any more fundamental amendments to follow (possibly). Moreover up to now I didn't hear of a single complaint about the performance of the turtle module. I think this is (i) because for beginning programmers this is no issue and (ii) there are means (to call tracer() and also to call update() directly) to control performance to a considerable extent. Shortly, my opinion is that there are *good reasons* why the implementation is done like this, seen from the educator's point of view. 2. Is it really fruitful to discuss general design issues along with (comparatively) small problems like this one - in the sense of alternative ways to fix that problem? Implementations of redesigns like the one you recommended wouldn't be accepted anyway for bug fix releases or releases in rc phase. I'm open to fundamental criticism also, but I think that should be led in Python-Dev or possibly comp.lang.python. And working out an amended concept would take some time and also it's implementation and it's testing. Moreover, to find co-workers to work on this would be an advantage. Regards, Gregor _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4117> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com