[Python-Dev] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!

[Gregor Lingl]

Martin v. Löwis schrieb:
> Gregor Lingl wrote:
>   
> ...
>> (Who reviewed it? This is a _newly_added_ function -
>> did nobody try it out yet? Incredible!!)
>>     
>
> Apparently not. Thanks for pointing that out; Georg (who committed the
> patch originally) just fixed it in r47151.
>
> This illustrates the main point: Even small changes need careful review.
> Much more so large changes.
>
>   
I understand that now.
> [turtle does not just fill the shape, but the entire boundary polygon]
>   
>> What a shame!! An immanent bug, persistent
>> for years now!
>>     
>
> If the bug had existed for years, somebody could have contributed a
> patch.
>   
I've 2 remarks on this point:
(i) apparingly turtle.py isn't used that much, that things like these 
come out necessarily
(ii) I had a discussion with Vern Ceder about exactly this point (on 
edupython list). He had the
opinion, that this couldn't be fixed. Somebody else promised to fix it 
anyway, but he didn't.
> ...
> It's not only about finding bugs. It's also about studying the
> consistency of the new API, and so on.
>   
That's right and very important. I would be very happy to have somebody 
to discuss
questions like these. It was not so easy to make all those decisions, 
and I know, of
course, others necessarily would have decided differently in some points. 

One question in this respect - how important do you  consider backward 
compatibility.
When designing a new module the requirement backward copmpatibility can 
have a big
impact on the code although it may in some parts be questionable. As an 
example let me
mention the radians() function.

> As for "reliable proofs": An automatic test suite for turtle.py
> would be a good thing to have.
>   
Yes,, and I have some ideas in this respect, but mainly a prioncipal 
question. I read about
using doctest and unittest, but how does one devise
automatic test suites for graphical output. In the end it depends on how 
it looks like.
That was one reason, why I made my example scripts. I use them for (not 
automatic)
testing and I can _see_ if things go wrong. Example: how do you test 
automatically if a
shape is filled correctly or not (as in the above mentioned bug)?
>> A more courageous and less bureaucratic approach to the problem
>> would be appropriate. Perhaps combined with some fantasy.
>>     
>
> ...
> The approach used in xturtle (i.e. represent circles as polylines)
> could also be used for turtle.py, no?
>
>   
Yes. I've done that patch right now, and I'll put it (as a suggestion) 
on the path manger, along
with a test script, when it's online again. It works as expected. See if 
you like it.

Believe it or not, when testing this patch I discovered (within half an 
hour) three more
bugs of turte.py:

I did the following interactive session:

 >>> from turtle import *
 >>> circle(100,90)
 >>> radians()
 >>> circle(100, pi/2)

two bugs occured:
(i) after calling radians() the turtle moves a
wrong path (I assume because of misinterpretation
of its heading, which doesn't know of the change
of units) (as it does when executing e. g. forward(50)
(ii) it doesn't draw the arc(!) (if as up() were given - I don't know why)

restoring degrees() it draws again.
In the meantime I had put the drawing window away
from the center to be better able to use the Shell
window. When I constructed a new Pen:

 >>> p = Pen()

(ii) the graphcis window jumped into the screencenter again (and it does 
so with every newly constructed Pen).
Apparently one shouldn't have  setup() called in Pen's __init__() 
method. This again seems to be a newly
introduced bug.

 I'll put them on the bug manager, when it's online again.

Regards,
Gregor


> Regards,
> Martin
>
>
>