[Python-Dev] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
glingl at aon.at
Thu Jun 29 16:51:17 CEST 2006
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
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
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
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
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, 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
I'll put them on the bug manager, when it's online again.
More information about the Python-Dev