Re: [Python-Dev] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
Gregor Lingl wrote: > 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. There are a few options here.. Two that come to mind are: - Check the output -- e.g., run a demo, and then use Tkinter.Canvas to write its output to postscript, and then check the contents of that postscript file against a known correct file. - Monkey-patching -- replace specific classes (e.g., ScrolledCanvas?) with new testing classes that simply intercept drawing primitives, rather than displaying graphics. Then check that the right drawing primitives (lines, circles, etc) are generated in the right order. The former may be more robust, but requires that you have a display surface available. With the former approach, you may also run into some problems with different postscript files being generated on different systems (esp. with respect to font sizes -- I seem to remember that using negative font sizes might help there?). -Edward ___ 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
Re: [Python-Dev] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
Gregor Lingl wrote: > 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. It's fairly important. Text books have been written that refer to the turtle module; the examples in these text books must continue to work. As we don't know what features these examples use, we must rather err on the conservative side, breaking the API only for a very good reason. > 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. It might be ok not to verify the output. OTOH, this is a canvas widget, so it should be possible to get all items on the screen at any point with primitive canvas methods. These could then be compared to precompiled lists. > 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)? You could check whether there is a polygon with the "right" shape, where "right" is specified by a series of coordinates. This is regression testing, and perhaps also coverage: we want to know whether changes to the module effect the current behaviour. When we test discovers a behaviour change, somebody manually will have to determine whether the test is wrong or the new code, and update the test if it is the former. Thanks your investigations about the current turtle.py. 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
Re: [Python-Dev] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
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
Re: [Python-Dev] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
Gregor Lingl wrote: > So, if you can't accept that offer - now, or even ever - , because it > contradicts your rules, that's o.k. But it's not 'my cause'. I > concieve it to be the community's cause. All "we" said is that we cannot integrate it now, as a policy matter. Nobody said it can't be integrated for 2.6; I am in favour of doing that. However, I do think that a number of changes need to be made still; I'll post my first review on the SF tracker item when SF comes back. > I, for my part, can and will use xturtle.py, knowing and having the > experience, that it is far superior to turtle.py. So I have no > problem. And I'll offer it for download from the xturtle-webpage or > from wherever you suggest. So it will be freely available. (Perhaps a > sourceforge project would be appropriate. Give me your advice, > please) You should add it into the Cheeshop: python.org/pypi Notice that the Cheeseshop already knows about turtle2.py by Mark Summerfield. > The only point is, that it leaves Python's turtle.py an (imho) > unsatisfactory solution. Looking at the feature list on #1513695, I think none of the new feature really make turtle.py look "unsatisfactory": - better animation of turtle movements: yes, this is a good thing to have, but not absolutely necessary. The current turtle already displays the orientation after it has turned. - different turtle shapes. It's probably fun to play with these, but (IMO) a distraction from the module's primary purpose (although fun certainly also is a purpose of the module). OTOH, perhaps the original Logo turtle icon should be the default? - fine control over turtle movement (in particular speed) Why are these needed? - Aliases for the most common functions. I guess it's useful, but if it was unsatisfactory not to have them, somebody would have contributed a patch for turtle.py already. - scrollable canvas. I had a hard time to figure out what method to use to resize the canvas (and am still uncertain whether rescaling is supported or not) - background color and image. Again, this looks like a distraction to me, but I see that Logo tutorials use this (along with turtle shapes like "C64 sprites"), so I guess there is a point to them, also. The only respect in which I would consider turtle.py unsatisfactory is the true bugs. At the moment, I can only see one open turtle.py bug reported, namely #1047540 (where the submitter later says it might be an IDLE bug). 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
Re: [Python-Dev] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
On 6/28/06, Gregor Lingl <[EMAIL PROTECTED]> wrote: > I made xturtle.py and that was a big effort. And I offer it to replace > turtle.py. I do this because I'm a Python enthusiast and I want a better > Python. (And I know very well that my contribution is rather marginal). > We all, I think, have this motive. And of course it was my > fault to submit it too late. I am certainly interested in your module, and will have a look at it in due course (to use it, not as a review for inclusion in Python). > So, if you can't accept that offer - now, or even ever - , because it > contradicts your rules, that's o.k. But it's not 'my cause'. I concieve > it to be the community's cause. It's purely a timing issue. You offered the module just before the Python 2.5 feature freeze. At that point in time, a brand new module intended to replace an existing one is almost certainly going to be rejected, simply from time constraints. I see no reason at all why you can't offer the module for Python 2.6, however. > The only point is, that it leaves Python's turtle.py an (imho) > unsatisfactory solution. Please be aware that *someone* will need to champion your module for inclusion into Python 2.6 As Martin points out, review will require some effort - and particularly if the proposal is to replace turtle.py rather than sitting alongside it. It will be necessary to persuade one of the core developers to care enough to spend time on this. They are all doing this in their spare time, and have their own interests which will come first. I know from experience that getting developer time is hard. It's possible that it would help to leave the module as an external project for a while, until enough other people in the Python community have acknowledged its usefulness, and can testify that it gives them no issues. At that point, the job of a reviewer becomes much easier (there's a user base confirming most of the things a reviewer has to consider) and so it is more likely that your module will be accepted. Paul. ___ 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
Re: [Python-Dev] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
Fredrik Lundh schrieb: > Gregor Lingl wrote: > > >> What a shame!! An immanent bug, persistent >> for years now! >> >> Is this what Anthony Baxter calls >> "the most solid Python release ever" >> > > do you really think stuff like this helps your cause ? > > Perhaps it dosn't help the turtle - cause. (I confess, I was a bit upset, please excuse!) But please let me clarify one point. I made xturtle.py and that was a big effort. And I offer it to replace turtle.py. I do this because I'm a Python enthusiast and I want a better Python. (And I know very well that my contribution is rather marginal). We all, I think, have this motive. And of course it was my fault to submit it too late. So, if you can't accept that offer - now, or even ever - , because it contradicts your rules, that's o.k. But it's not 'my cause'. I concieve it to be the community's cause. I, for my part, can and will use xturtle.py, knowing and having the experience, that it is far superior to turtle.py. So I have no problem. And I'll offer it for download from the xturtle-webpage or from wherever you suggest. So it will be freely available. (Perhaps a sourceforge project would be appropriate. Give me your advice, please) The only point is, that it leaves Python's turtle.py an (imho) unsatisfactory solution. See for instance Vern Ceder judgment: http://mail.python.org/pipermail/edu-sig/2006-June/006625.html Regards, Gregor Final remark: I know, that my English is not very good. So I feel, that possibly I have not complete control over the 'undertones' of my writing. If sombody feels offended, please excuse, that was not my intent. > > > ___ > 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/glingl%40aon.at > > > ___ 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
Re: [Python-Dev] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
Guido van Rossum wrote: > It was already patched by the other Georg. Thanks for the quick fix, georgbot! My pleasure, even if there's a difference between "Georg" and "Gregor" ;) cheers, Georg ___ 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
Re: [Python-Dev] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
Gregor Lingl wrote: > For example: put turtle.py and xturtle.py both into beta2 and > see which one stands better the (beta)test of time. Or perhaps you have > an even better idea! As a compromise, we could put an ad into the turtle document (a "see also" link). 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
Re: [Python-Dev] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
Gregor Lingl wrote: > Sorry Martin, but to me this seems not to be the right way to manage > things. As you explain later, this is precisely the right way; it is unfortunate that it isn't always followed. > (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. [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. > Bugs like the one I detected above (by chance) cannot occur in the code of > my xturtle, because I don't have to type the definitions of those > frunctions > into the script by hand. Instead they are generated automatically from the > corresponding methods of RawPen and Pen respectively. That's all good and well. It still needs to be reviewed. > And aren't 25+ bugfree samplescripts of great variety > and broad range in complexity to consider a more > reliable proof of at least usability than the procedure > you applied? It's not only about finding bugs. It's also about studying the consistency of the new API, and so on. As for "reliable proofs": An automatic test suite for turtle.py would be a good thing to have. > A more courageous and less bureaucratic approach to the problem > would be appropriate. Perhaps combined with some fantasy. This bureaucracy has worked fine all the years, and in cases where it was relaxed, we had to regret the changes we accepted more often than not (just like the bug you discovered: the patch should not have been accepted without test cases). > P.S.: If this posting doesn't move points of view, at least > it reveals one fixable bug in turtle.py (albeit also one unfixable!) The approach used in xturtle (i.e. represent circles as polylines) could also be used for turtle.py, no? 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
Re: [Python-Dev] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
It was already patched by the other Georg. Thanks for the quick fix, georgbot!
--Guido
On 6/28/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
>
> On Jun 28, 2006, at 1:05 PM, Gregor Lingl wrote:
>
> > Martin v. Löwis schrieb:
> >> Collin Winter wrote:
> >>
> >>> While I have no opinion on Gregor's app, and while I fully agree
> >>> that
> >>> new language features and stdlib modules should generally stay
> >>> out of
> >>> bug-fix point releases, xturtle doesn't seem to rise to that level
> >>> (and hence, those restrictions).
> >>>
> >>
> >> It's a stdlib module, even if no other stdlib modules depend on it;
> >> try "import turtle".
> >>
> >> In the specific case, the problem with adding it to 2.5 is that
> >> xturtle
> >> is a huge rewrite, so ideally, the code should be reviewed before
> >> being
> >> added. Given that this is a lot of code, nobody will have the time to
> >> perform a serious review. It will be hard enough to find somebody to
> >> review it for 2.6 - often, changes of this size take several years to
> >> review (primarily because it is so specialized that only few people
> >> even consider reviewing it).
> >>
> > Sorry Martin, but to me this seems not to be the right way to
> > manage things.
> > We have turtle.py revised in Python2.5b1
> >
> > Please try this example (as I just did) :
> >
> > IDLE 1.2b1 No Subprocess
> > >>> from turtle import *
> > >>> begin_fill()
> > >>> circle(100,90) # observe the turtle
> > >>> backward(200)
> > >>> circle(100,90)
> > >>> color("red")
> > >>> end_fill()
> > IDLE internal error in runcode()
> > Traceback (most recent call last):
> > File "", line 1, in
> >end_fill()
> > File "C:\Python25\lib\lib-tk\turtle.py", line 724, in end_fill
> >def end_fill(): _getpen.end_fill()
> > AttributeError: 'function' object has no attribute 'end_fill'
> > >>>
> >
> > An error occurs, because in line 724 it should read
> > def end_fill(): _getpen().end_fill()
>
> File a patch, this is a bug fix and should definitely be appropriate
> for inclusion before the release of Python 2.5!
>
> -bob
>
> ___
> 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/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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
Re: [Python-Dev] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
On Jun 28, 2006, at 1:05 PM, Gregor Lingl wrote:
> Martin v. Löwis schrieb:
>> Collin Winter wrote:
>>
>>> While I have no opinion on Gregor's app, and while I fully agree
>>> that
>>> new language features and stdlib modules should generally stay
>>> out of
>>> bug-fix point releases, xturtle doesn't seem to rise to that level
>>> (and hence, those restrictions).
>>>
>>
>> It's a stdlib module, even if no other stdlib modules depend on it;
>> try "import turtle".
>>
>> In the specific case, the problem with adding it to 2.5 is that
>> xturtle
>> is a huge rewrite, so ideally, the code should be reviewed before
>> being
>> added. Given that this is a lot of code, nobody will have the time to
>> perform a serious review. It will be hard enough to find somebody to
>> review it for 2.6 - often, changes of this size take several years to
>> review (primarily because it is so specialized that only few people
>> even consider reviewing it).
>>
> Sorry Martin, but to me this seems not to be the right way to
> manage things.
> We have turtle.py revised in Python2.5b1
>
> Please try this example (as I just did) :
>
> IDLE 1.2b1 No Subprocess
> >>> from turtle import *
> >>> begin_fill()
> >>> circle(100,90) # observe the turtle
> >>> backward(200)
> >>> circle(100,90)
> >>> color("red")
> >>> end_fill()
> IDLE internal error in runcode()
> Traceback (most recent call last):
> File "", line 1, in
>end_fill()
> File "C:\Python25\lib\lib-tk\turtle.py", line 724, in end_fill
>def end_fill(): _getpen.end_fill()
> AttributeError: 'function' object has no attribute 'end_fill'
> >>>
>
> An error occurs, because in line 724 it should read
> def end_fill(): _getpen().end_fill()
File a patch, this is a bug fix and should definitely be appropriate
for inclusion before the release of Python 2.5!
-bob
___
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
Re: [Python-Dev] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
Gregor Lingl wrote: > What a shame!! An immanent bug, persistent > for years now! > > Is this what Anthony Baxter calls > "the most solid Python release ever" do you really think stuff like this helps your cause ? ___ 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
Re: [Python-Dev] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
Martin v. Löwis schrieb:
Collin Winter wrote:
While I have no opinion on Gregor's app, and while I fully agree that
new language features and stdlib modules should generally stay out of
bug-fix point releases, xturtle doesn't seem to rise to that level
(and hence, those restrictions).
It's a stdlib module, even if no other stdlib modules depend on it;
try "import turtle".
In the specific case, the problem with adding it to 2.5 is that xturtle
is a huge rewrite, so ideally, the code should be reviewed before being
added. Given that this is a lot of code, nobody will have the time to
perform a serious review. It will be hard enough to find somebody to
review it for 2.6 - often, changes of this size take several years to
review (primarily because it is so specialized that only few people
even consider reviewing it).
Sorry Martin, but to me this seems not to be the right way to manage things.
We have turtle.py revised in Python2.5b1
Please try this example (as I just did) :
IDLE 1.2b1 No Subprocess
>>> from turtle import *
>>> begin_fill()
>>> circle(100,90) # observe the turtle
>>> backward(200)
>>> circle(100,90)
>>> color("red")
>>> end_fill()
IDLE internal error in runcode()
Traceback (most recent call last):
File "", line 1, in
end_fill()
File "C:\Python25\lib\lib-tk\turtle.py", line 724, in end_fill
def end_fill(): _getpen.end_fill()
AttributeError: 'function' object has no attribute 'end_fill'
>>>
An error occurs, because in line 724 it should read
def end_fill(): _getpen().end_fill()
(Who reviewed it? This is a _newly_added_ function -
did nobody try it out yet? Incredible!!)
I corrected it and did:
IDLE 1.2b1 No Subprocess
>>> from turtle import *
>>> begin_fill()
>>> circle(100,90)
>>> backward(200)
>>> circle(100,90)
>>> color("red")
>>> end_fill()
>>>
What a shame!! An immanent bug, persistent
for years now!
Is this what Anthony Baxter calls
"the most solid Python release ever"
In contrast to this:
IDLE 1.2b1 No Subprocess
>>> from xturtle import *
>>> begin_fill()
>>> circle(100,90)
>>> backward(200)
>>> circle(100,90)
>>> color("red")
>>> end_fill()
>>>
works correctly and the turtle travels along the arcs
with the same speed as along the straight lines.
Bugs like the one I detected above (by chance) cannot occur in the code of
my xturtle, because I don't have to type the definitions of those
frunctions
into the script by hand. Instead they are generated automatically from the
corresponding methods of RawPen and Pen respectively.
And aren't 25+ bugfree samplescripts of great variety
and broad range in complexity to consider a more
reliable proof of at least usability than the procedure
you applied?
My xturtle is certainly not bugfree. But it's (also
certainly) not worse than turtle.py and way more versatile.
A more courageous and less bureaucratic approach to the problem
would be appropriate. Perhaps combined with some fantasy.
For example: put turtle.py and xturtle.py both into beta2 and
see which one stands better the (beta)test of time. Or perhaps you have
an even better idea!
Regards,
Gregor
P.S.: If this posting doesn't move points of view, at least
it reveals one fixable bug in turtle.py (albeit also one unfixable!)
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/glingl%40aon.at
___
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
