Discussion:
xturtle.py a replacement for turtle.py(!?)
(too old to reply)
Gregor Lingl
2006-06-28 10:57:23 UTC
Permalink
xturtle.py, extended turtle graphics
a new Tkinter based turtle graphics module for Python

I just have released xturtle.py (v.0.91). It can be found at:

http://sourceforge.net/tracker/?group_id=5470&atid=305470

with RequestID 1513695 (and 1513699 for the docs)
and also here

http://ada.rg16.asn-wien.ac.at/~python/xturtle

with some supplementary information.

xturtle was first announced at the edu-sig and is reported
to work properly on all major platforms (Mac, Linux and
Windows)

Now I was suggested to discuss it on this list. So I'll try.

For now I'll give only two indroductory statements and wait
for a response, hoping that a fruitful discussion will evolve.

(I) The module xturtle.py is an extended reeimplementation
of turtle.py, retains its merits and is backward compatible
to turtle.py. Enhancements over turtle.py are:

# Better animation of the turtle movements, especially of
turning the turtle. So the turtles can more easily be used
as a visual feedback instrument by the (beginning) programmer.
# Different turtle shapes, gif-images as turtle shapes, user
defined and user controllable turtle shapes, among them
compound (multicolored) shapes.
# Fine control over turtle movement and screen updates via
delay(), and enhanced tracer() and speed(), update() methods.
# Aliases for the most commonly used commands, like fd for
forward etc., following the early Logo traditions. This
reduces the boring work of typing long sequences of
commands, which often occur in a natural way when kids try
to program fancy pictures on their first encounter with
turtle graphcis (still not knowing nothing about loops).
# Some simple commands/methods for creating event driven
programs (mouse-, key-, timer-events). Especially useful for
programming simple games.
# A scrollable Canvas class. The scrollable Canvas can be
extended interactively as needed while playing around with
the turtle(s) (e. g. to follow some escaped turtle). The
Window containing the default canvas when using the Pen -
class also can be resized and repositioned programmatically.
# Commands for controlling background color or background
image.


(II) Motives: I designed this module to provide utmost easy
access to a sufficiently rich graphics toolkit. I consider
this crucial as well for students as for teachers, who e. g.
have to decide which programming language to use for
teaching programming. Considering turtle graphics as a very
appropriate tool for introductory programming courses I used
the current turtle.py as a central tool in my book "Python
for kids" despite beeing well aware of its deficiencies.
Now I propose a better one.

You may unterstand by intentions best by having a look at
the 25+ example scripts (with the included demoViewer)
provided in the xturtle.zip file, which can be downloaded
from the above mentioned website. (I think these demos
should not be included in the standard distribution, they
could go into a special edu-distro as Kirby Urner suggested
lately.)

I would very much appreciate if xturtle.py could go into
Python 2.5

Let's see

Gregor
A.M. Kuchling
2006-06-28 14:08:41 UTC
Permalink
Post by Gregor Lingl
I would very much appreciate if xturtle.py could go into
Python 2.5
That decision is up to Anthony Baxter, the release manager.
Unfortunately 2.5beta1 is already out, and the developers try to avoid
large changes during the beta series, so I wouldn't be optimistic
about 2.5.

Enhancing the turtle module would be an excellent candidate for 2.6,
though. Please file a patch on SourceForge for this so the improved
module doesn't get forgotten.

Great demos, BTW! I especially like the gravity ones.

--amk
Anthony Baxter
2006-06-28 15:16:35 UTC
Permalink
Post by Gregor Lingl
I would very much appreciate if xturtle.py could go into
Python 2.5
Unfortunately Python 2.5b1 came out last week. Now that we're in beta,
we're feature frozen (unless some horrible issue comes up that means
we really need to do a feature change). This looks very nice, but
it's going to have to wait until 2.6 :-(

Sorry. Timing is everything.

For others reading along at home - I kinda think that the
post-beta-feature-freeze is a similar sort to the one we have for
bugfix releases (maybe _slightly_ lower hurdles for a new feature,
but only just). Does this seem reasonable? If so, I'll add a note to
the [still unfinished :-(] PEP 101 rewrite.

Anthony
--
Anthony Baxter <***@interlink.com.au>
It's never too late to have a happy childhood.
Gregor Lingl
2006-06-28 16:10:19 UTC
Permalink
Post by Anthony Baxter
Post by Gregor Lingl
I would very much appreciate if xturtle.py could go into
Python 2.5
Unfortunately Python 2.5b1 came out last week. Now that we're in beta,
we're feature frozen (unless some horrible issue comes up that means
we really need to do a feature change). This looks very nice, but
it's going to have to wait until 2.6 :-(
Sorry. Timing is everything.
So you mean that will at least last one more year? Not fine.

I wonder if this xturtle.py is a Python feature.
When Vern Ceder did his patch of turtle.py some weeks ago, there arouse a
discussion if a PEP was necessary to change turtle.py and the general
opinion
in the discussion then was no. So I thought, that turtle-graphics is some
marginal element in the Python standard distribution. (I thought something
like features get defined in PEPs)

Already now, only one week after publishing it I have some very positive
feedback and people start to use it. So I think there is some demand for
it.
Moreover I think it could also help to convince more teachers to use
Python as
a first language.

Could you imagine - downgrading it's 'featureness' - to put it into 2.5.1
or something like this?

I'll have a talk at Europython 2006 on July 5th about xturtle - an
opportunity if sombody feels it's worth discussing it.

Regards,
Gregor
Fredrik Lundh
2006-06-28 16:19:17 UTC
Permalink
Post by Gregor Lingl
Already now, only one week after publishing it I have some very positive
feedback and people start to use it. So I think there is some demand for
it.
some demand != should be added to the core distribution a few days after
its first release. (and if everything that someone somewhere is using should
be added to the core, a stock Python distro wouldn't fit on a DVD...)
Post by Gregor Lingl
Moreover I think it could also help to convince more teachers to use
Python as a first language.
and teachers won't be able to install a second package ? sorry, but I don't
believe that for a second.

</F>
Josiah Carlson
2006-06-28 16:48:41 UTC
Permalink
Post by Gregor Lingl
Could you imagine - downgrading it's 'featureness' - to put it into 2.5.1
or something like this?
Changing features/abilities of Python in micro releases (2.5 -> 2.5.1),
aside from bugfixes, is a no-no. See the Python 2.2 -> 2.2.1
availability of True/False for an example of where someone made a
mistake in doing this.

- Josiah
Gregor Lingl
2006-06-28 17:01:53 UTC
Permalink
Post by Josiah Carlson
Post by Gregor Lingl
Could you imagine - downgrading it's 'featureness' - to put it into 2.5.1
or something like this?
Changing features/abilities of Python in micro releases (2.5 -> 2.5.1),
aside from bugfixes, is a no-no.
I understand. Nevertheless one should see, that there is
_not_a _single_ module_ in the whole of Standard Python distro
which _depends_ on turtle.py.
This certainly makes a difference to the True/False-change problem.

Gregor
Post by Josiah Carlson
See the Python 2.2 -> 2.2.1
availability of True/False for an example of where someone made a
mistake in doing this.
- Josiah
Collin Winter
2006-06-28 17:03:03 UTC
Permalink
Post by Josiah Carlson
Post by Gregor Lingl
Could you imagine - downgrading it's 'featureness' - to put it into 2.5.1
or something like this?
Changing features/abilities of Python in micro releases (2.5 -> 2.5.1),
aside from bugfixes, is a no-no. See the Python 2.2 -> 2.2.1
availability of True/False for an example of where someone made a
mistake in doing this.
This may be a stupid question, but we're talking about replacing the
turtle.py in Lib/lib-tk/, right? The one that's basically just a GUI
demo / introduction to programming tool?

If so, can someone explain to me how improving something like this is
akin to introducing new keywords that everyone will take advantage of
(to use Josiah's True/False example)?

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

Thanks,
Collin Winter
Aahz
2006-06-28 17:11:20 UTC
Permalink
Post by Collin Winter
This may be a stupid question, but we're talking about replacing the
turtle.py in Lib/lib-tk/, right? The one that's basically just a GUI
demo / introduction to programming tool?
If so, can someone explain to me how improving something like this is
akin to introducing new keywords that everyone will take advantage of
(to use Josiah's True/False example)?
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).
The problem is that it's a slippery slope. There is a *LOT* of political
value coming from "no features in bug releases, period". People feel
that they can rely on Python to stay stable and not have to check what
the actual changes were; it increases the confidence level in bugfix
releases.

Either the new turtle module goes in for beta2 (after suitably convincing
the release manager and Guido) or it waits for 2.6. I don't have a
strong feeling about this issue, though I'm a mild -0 on allowing it.
Nobody can claim there wasn't notice about the beta release date and the
restrictions after it.
--
Aahz (***@pythoncraft.com) <*> http://www.pythoncraft.com/

"I saw `cout' being shifted "Hello world" times to the left and stopped
right there." --Steve Gonedes
Anthony Baxter
2006-06-28 17:21:09 UTC
Permalink
Post by Collin Winter
This may be a stupid question, but we're talking about replacing
the turtle.py in Lib/lib-tk/, right? The one that's basically just
a GUI demo / introduction to programming tool?
If so, can someone explain to me how improving something like this
is akin to introducing new keywords that everyone will take
advantage of (to use Josiah's True/False example)?
2.x.y releases should be compatible for all values of y, (including
the empty value <wink>). PEP-006 has the details and rationale.
People shouldn't have to worry that things break with a minor
release. It's important that packagers of Python for distributions
can feel confident that a "bugfix" release of Python is _actually_
just a bugfix release, and that they can push it out to their users.
This means everyone wins.

I'm unconvinced that a new turtle module is worth ramming in on short
notice to make it into 2.5 final. It can easily be made available via
the cheeseshop and with setuptools for extremely easy installation
between 2.5 and 2.6. With all the work that's been done to make 2.5
what will hopefully be the most solid Python release ever, I don't
want to slip up now. :-)

And needless to say, there is no way it is suitable for a bugfix
release.

Had it been pushed through a couple of weeks earlier (while we were in
alpha) - sure, it looks like it could have been a good addition to
the stdlib. But the release timeline's been out there for a while
now - heck, b1 was actually a few days later than originally planned.

Anthony
--
Anthony Baxter <***@interlink.com.au>
It's never too late to have a happy childhood.
Martin v. Löwis
2006-06-28 18:59:24 UTC
Permalink
Post by Collin Winter
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).

Regards,
Martin
Gregor Lingl
2006-06-28 20:05:19 UTC
Permalink
Post by Martin v. Löwis
Post by Collin Winter
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 ====
Post by Martin v. Löwis
Post by Collin Winter
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 "<pyshell#6>", line 1, in <module>
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 ====
Post by Martin v. Löwis
Post by Collin Winter
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 ====
Post by Martin v. Löwis
Post by Collin Winter
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!)
Post by Martin v. Löwis
Regards,
Martin
_______________________________________________
Python-Dev mailing list
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/glingl%40aon.at
Fredrik Lundh
2006-06-28 20:22:06 UTC
Permalink
Post by Gregor Lingl
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 ?

</F>
Gregor Lingl
2006-06-28 22:37:49 UTC
Permalink
Post by Fredrik Lundh
Post by Gregor Lingl
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.
Post by Fredrik Lundh
</F>
_______________________________________________
Python-Dev mailing list
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/glingl%40aon.at
Paul Moore
2006-06-29 11:03:30 UTC
Permalink
Post by Gregor Lingl
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).
Post by Gregor Lingl
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.
Post by Gregor Lingl
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.
Martin v. Löwis
2006-06-29 13:27:44 UTC
Permalink
Post by Gregor Lingl
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.
Post by Gregor Lingl
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.
Post by Gregor Lingl
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
Bob Ippolito
2006-06-28 20:53:32 UTC
Permalink
Post by Gregor Lingl
Post by Martin v. Löwis
Post by Collin Winter
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
IDLE 1.2b1 ==== No Subprocess ====
Post by Martin v. Löwis
Post by Collin Winter
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()
File "<pyshell#6>", line 1, in <module>
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
Guido van Rossum
2006-06-28 21:00:34 UTC
Permalink
It was already patched by the other Georg. Thanks for the quick fix, georgbot!

--Guido
Post by Bob Ippolito
Post by Gregor Lingl
Post by Martin v. Löwis
Post by Collin Winter
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
IDLE 1.2b1 ==== No Subprocess ====
Post by Martin v. Löwis
Post by Collin Winter
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()
File "<pyshell#6>", line 1, in <module>
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
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/)
Georg Brandl
2006-06-28 21:34:04 UTC
Permalink
Post by Guido van Rossum
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
Martin v. Löwis
2006-06-28 21:17:48 UTC
Permalink
Post by Gregor Lingl
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.
Post by Gregor Lingl
(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]
Post by Gregor Lingl
What a shame!! An immanent bug, persistent
for years now!
If the bug had existed for years, somebody could have contributed a
patch.
Post by Gregor Lingl
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.
Post by Gregor Lingl
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.
Post by Gregor Lingl
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).
Post by Gregor Lingl
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
Gregor Lingl
2006-06-29 14:51:17 UTC
Permalink
Post by Martin v. Löwis
...
Post by Gregor Lingl
(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.
Post by Martin v. Löwis
[turtle does not just fill the shape, but the entire boundary polygon]
Post by Gregor Lingl
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.
Post by Martin v. Löwis
...
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.
Post by Martin v. Löwis
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)?
Post by Martin v. Löwis
Post by Gregor Lingl
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
Post by Martin v. Löwis
Post by Gregor Lingl
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
Post by Martin v. Löwis
Post by Gregor Lingl
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
Post by Martin v. Löwis
Regards,
Martin
Martin v. Löwis
2006-06-29 15:27:16 UTC
Permalink
Post by Gregor Lingl
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.
Post by Gregor Lingl
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.
Post by Gregor Lingl
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
Edward Loper
2006-06-29 15:34:39 UTC
Permalink
Post by Gregor Lingl
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
Martin v. Löwis
2006-06-28 21:23:04 UTC
Permalink
Post by Gregor Lingl
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
Greg Ewing
2006-06-29 00:49:20 UTC
Permalink
Post by Gregor Lingl
xturtle
BTW, I'm not sure if 'xturtle' is such a good name.
There's a tradition of X Windows executables having
names starting with 'x', whereas this is presumably
platform-independent.

Maybe 'turtleplus' or something?

--
Greg
Martin v. Löwis
2006-06-29 01:21:12 UTC
Permalink
Post by Greg Ewing
BTW, I'm not sure if 'xturtle' is such a good name.
There's a tradition of X Windows executables having
names starting with 'x', whereas this is presumably
platform-independent.
Maybe 'turtleplus' or something?
When it goes into Python, it will be 'turtle'.

Regards,
Martin
Scott David Daniels
2006-06-29 23:18:53 UTC
Permalink
Post by Martin v. Löwis
Post by Greg Ewing
BTW, I'm not sure if 'xturtle' is such a good name.
There's a tradition of X Windows executables having
names starting with 'x', whereas this is presumably
platform-independent.
Maybe 'turtleplus' or something?
When it goes into Python, it will be 'turtle'.
Perhaps in the meantime (if xturtle is not loved),
you could go with "turtle_" as in "like the standard
turtle, but my definition."
--
-- Scott David Daniels
***@Acm.Org
Continue reading on narkive:
Loading...