> > 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