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 > > > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
