Re: [Tutor] Ongoing trouble with Turtle's end_fill() - caused by abug in turtle.py

[Gregor Lingl]

Hi Dick,

just to show you a bit of the versatility of the new turtle module
I've prepared to tiny rectangle-generator program examples.

They intentionally use different programming styles and also
turtle graphics techniques different from the ones you used
to accomplish something similar to what you did, of course
in a very simplified way and without your eleborated user
interface and colormanagement.

---
Version 1: procedural, using stamp()
---

from turtle import *
from random import random, randint
from time import sleep

MAXLEN = 30
MAXWID = 25

def randomcolor():
   return random(), random(), random()

reset()
title("Python turtle graphics: random rectangle generator")
hideturtle()
resizemode("user")
shape("square")
for cycle in range(randint(3, 5)):
   bgcolor(randomcolor())
   for rect in range(randint(5,10)):
   shapesize(3 + random()*MAXLEN, 3 + random()*MAXWID,
  randint(3, 10))
   color(randomcolor(), randomcolor())
   stamp()
   sleep(0.5)
   sleep(1)
   clearstamps()


---
Version 2: object oriented, uses a list of turtles,
which change their properties (size, color, visibility)
---

from turtle import Screen, Turtle
from random import random, randint
from time import sleep

MAXLEN = 30
MAXWID = 25

def randomcolor():
   return random(), random(), random()

class RectGenerator(object):
   def __init__(self):
   self.s = s = Screen()
   s.reset()
   s.title("Python turtle graphics: random rectangle generator")
   self.rectturtles = []
   for n in range(10):
   t = Turtle(visible=False)
   t.hideturtle()
   t.resizemode("user")
   t.shape("square")
   self.rectturtles.append(t)
   def run(self):
   for cycle in range(randint(3, 5)):
   self.s.bgcolor(randomcolor())
   n  = randint(5,10)
   for index in range(n):
   t = self.rectturtles[index]
   t.shapesize(3 + random()*MAXLEN, 3 + random()*MAXWID,
randint(3, 10))
   t.color(randomcolor(), randomcolor())
   t.showturtle()
   sleep(0.5)
   sleep(1)
   for t in self.s.turtles():
   t.hideturtle()

if __name__ == "__main__":
   rg = RectGenerator()
   rg.run()


Hope you like it
Gregor
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Ongoing trouble with Turtle's end_fill() - Important note!

[Gregor Lingl]

P.S.: If you are interested, you can download a series of sample programs
covering a broad range from very easy to fairly advanced, which
intend to show some features and capabilities of the new turtle module
from here:

http://svn.python.org/view/python/trunk/Demo/turtle/

These will be included in the source distribution - but not in the 
Windows

installer.



IMPORTANT NOTE!
In order to have the examples working correctly you have to have turtle.cfg
in the directory where the example scripts are (or in that with turtle.py).
An easy way to have a look at all the examplescripts is using turtleDemo.py

Gregor

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor




___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Ongoing trouble with Turtle's end_fill() - caused by abug in turtle.py

[Gregor Lingl]

Dick Moores schrieb:


Here better tracer() should come in!



'Deprecated in version 2.6'?? And the doc gives nary a clue how to use it.
http://docs.python.org/dev/library/turtle.html#turtle.tracer
  
tracer is only deprecated as a Turtle-method, because it doesn't concern 
single turtles but
all the turtles on the screen. It will stay as Screen-method and of 
course also as function.
(As a turtle-method it's only there because of compatibility with the 
old turtle module.)


Gregor


___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Ongoing trouble with Turtle's end_fill() - caused by abug in turtle.py

[Dick Moores]

On Thu, Aug 7, 2008 at 4:04 PM, Gregor Lingl <[EMAIL PROTECTED]> wrote:
> Hi Dick,
>
> first of all, thanks for your efforts using the new turtle module
> and reporting about your experiences and the problems you ran into.

Sure. And I'm not finished. There seem to be some interesting new
things worth investigating.

> I've already made some remarks on it in a former reply in this thread.

Yes. Thanks.

>> On Thu, Aug 7, 2008 at 11:26 AM, Alan Gauld <[EMAIL PROTECTED]>
>> wrote:
>>  ...

 2. The turtle can also be seen moving from the last corner of the last
 rectangle to the first corner of the next. I don't want this.

>>>
>>> Again true of a physical turtle... But if you set speed to fastest
>>> does that work? Also in the old turtle moduile there was a way to
>>> hide the turtles movements completely and just draw the finished
>>> graphic - which was orders of magnitude faster for complex
>>> shapes - is that still available in turtle26?
>>>
>
> Here better tracer() should come in!

'Deprecated in version 2.6'?? And the doc gives nary a clue how to use it.
http://docs.python.org/dev/library/turtle.html#turtle.tracer

>> Yes, penup().
>> 
>>
>>>
>>> Maybe more not understanding(remembering) the origin of turtle graphics.
>>> It was for kids to understand computer graphics... Seeing the shapes
>>> being drawn is a big part of that.
>>>
>
> That's why now turtles have got a better animation. (That means: the
> resulting drawing should be
> the same weather you use the old module or the new one, but *not* what you
> see, when you observe
> the turtles at work. Therfore I wrote (nearly?) 100% compatible. And of
> course, the now one
> has a lot of additional enhacements.)

And I'm going to have questions! Already have one. What is tracer()?

Thanks for these: 

Dick
===
Have you seen Kelie Feng's video introducing the terrific and free
IDE, Ulipad? 
Get Ulipad 3.9 from 
svn for the latest revision 
Mailing list for Ulipad: 
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Ongoing trouble with Turtle's end_fill() - caused by abug in turtle.py

[Dick Moores]

On Thu, Aug 7, 2008 at 4:04 PM, Gregor Lingl <[EMAIL PROTECTED]> wrote:
> Hi Dick,
>
> first of all, thanks for your efforts using the new turtle module
> and reporting about your experiences and the problems you ran into.

Sure. And I'm not finished. There seem to be some interesting new
things worth investigating.

> I've already made some remarks on it in a former reply in this thread.

Yes. Thanks.

>> On Thu, Aug 7, 2008 at 11:26 AM, Alan Gauld <[EMAIL PROTECTED]>
>> wrote:
>>  ...

 2. The turtle can also be seen moving from the last corner of the last
 rectangle to the first corner of the next. I don't want this.

>>>
>>> Again true of a physical turtle... But if you set speed to fastest
>>> does that work? Also in the old turtle moduile there was a way to
>>> hide the turtles movements completely and just draw the finished
>>> graphic - which was orders of magnitude faster for complex
>>> shapes - is that still available in turtle26?
>>>
>
> Here better tracer() should come in!

'Deprecated in version 2.6'?? And the doc gives nary a clue how to use it.
http://docs.python.org/dev/library/turtle.html#turtle.tracer

>> Yes, penup().
>> 
>>
>>>
>>> Maybe more not understanding(remembering) the origin of turtle graphics.
>>> It was for kids to understand computer graphics... Seeing the shapes
>>> being drawn is a big part of that.
>>>
>
> That's why now turtles have got a better animation. (That means: the
> resulting drawing should be
> the same weather you use the old module or the new one, but *not* what you
> see, when you observe
> the turtles at work. Therfore I wrote (nearly?) 100% compatible. And of
> course, the now one
> has a lot of additional enhacements.)

And I'm going to have questions! Already have one. What is tracer()?

Thanks for these: 
And clock.py uses tracer(), so cancel that question. Obvious.

Dick
===
Have you seen Kelie Feng's video introducing the terrific and free
IDE, Ulipad? 
Get Ulipad 3.9 from 
svn for the latest revision 
Mailing list for Ulipad: 
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Ongoing trouble with Turtle's end_fill() - caused by abug in turtle.py

[Gregor Lingl]

Hi Dick,

first of all, thanks for your efforts using the new turtle module
and reporting about your experiences and the problems you ran into.

I've already made some remarks on it in a former reply in this thread.

On Thu, Aug 7, 2008 at 11:26 AM, Alan Gauld <[EMAIL PROTECTED]> wrote:
  
...

2. The turtle can also be seen moving from the last corner of the last
rectangle to the first corner of the next. I don't want this.
  

Again true of a physical turtle... But if you set speed to fastest
does that work? Also in the old turtle moduile there was a way to
hide the turtles movements completely and just draw the finished
graphic - which was orders of magnitude faster for complex
shapes - is that still available in turtle26?


Here better tracer() should come in!


Yes, penup(). 
  


Maybe more not understanding(remembering) the origin of turtle graphics.
It was for kids to understand computer graphics... Seeing the shapes
being drawn is a big part of that.

That's why now turtles have got a better animation. (That means: the 
resulting drawing should be
the same weather you use the old module or the new one, but *not* what 
you see, when you observe
the turtles at work. Therfore I wrote (nearly?) 100% compatible. And of 
course, the now one

has a lot of additional enhacements.)

Best regards,
Gregor

Well, I also want to see the rectangles being drawn--by an invisible turtle. ;-)

Actually, I got interested in this because of the colors. I had just
bought my first LCD monitor, a 22-incher. And I wrote the program so
that it prints the color names to the console window. I had been
ignorant about colors--had no idea what magenta, chartreuse,
turquoise, cyan were, just to mention a few.

Thanks, Alan.

Dick
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor


  


___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Ongoing trouble with Turtle's end_fill()

[Gregor Lingl]

Alan Gauld schrieb:

"Dick Moores" <[EMAIL PROTECTED]> wrote


1. The turtle has some behavior I don't see how to eliminate. If you
refer to lines 223, 225, 227, 229, etc., you'll see that the turtle
always faces in the direction it is moving when drawing a rectangle.


That is correct behaviour for a turtle!
Remember turtle graphics are notionally about moving a physical
drawing device (the turtle) around on the floor or desk. If the turtle
doesn't turn to face the direction of travel it can't travel that way!

IMHO that's just a feature of the technology and any other behaviour
would be out of keeping with the intent.


Hi all,
development of this rectangle pattern program is going verry fast and
as I see Dick has managed to abridge his program by some
fifty lines (using the new turtle module).

Most of his questions got superb answers by Alan, so I'll add only
a few remarks:

In fact Dick doesn't use any turtle graphics functions in it's precise 
original

meaning. Instead he uses a (global) Cartesian coordinate system and
moves the turtle only by calling goto().
(This approach is perfectly ok for his task, of course).

Turtle graphics by contrast uses a local coordinate system of the "turtle"
and moves it by calling only forward(), back(), left() and right() 
functions.



Using the Python2.6 beta2 version of turtle.py, the turtle can be seen
at each corner spinning to orient itself to the new direction. I don't
want this.

So you eliminated the superfluous setheading() calls.


While far from common in turtle implementations (I have only seen
it in my old CP/M Logo version) it is a feature that would be true
of a physical turtle too. Its not really a bug but a "feature" I guess!


2. The turtle can also be seen moving from the last corner of the last
rectangle to the first corner of the next. I don't want this.

This is ideed an intended difference between the new and the old
turtle module. I consider this to be an improvement of the animation
of the turtle. (You can observe another improvement by trying out
e. g. left(1080) ) The intention is that the beginning programmer
can visually observe what he or she has programmed and thus more
easily identify errors in his/her program. To that end the turtle
moves and turns at the specified speed regardless of the state of
the pen (up or down).

If you don't like this you can set speed to 0 which - paradoxically -
means that the animation is turned off and the turtle jumps instantaneously.
(Think of something like speed(False))

Again true of a physical turtle... But if you set speed to fastest
does that work? 

Yes, that is speed(0). See above

Also in the old turtle moduile there was a way to
hide the turtles movements completely and just draw the finished
graphic - which was orders of magnitude faster for complex
shapes - is that still available in turtle26?

Yes it is (of course ;-) ). Use tracer in the same way as in the old one.



One way to hide the turtle would be top change colour to the
background color. That would make themoving turtle invisible...


As Dick discoverd you can use  hideturtle() and showturtle()

3. When the screen is cleared between cycles by line 367, the blank
screen shows for a second or so. I don't want this.
In my program using the old turtle I've had to create
colored-backgrounds by drawing a rectangle almost as large as the
screen (see my draw_background() beginning at line 365). With the new
turtle, the background color can be set by, for example,
screen.bgcolor("orange"). But even so, in the V16 I was trying to
write, that blank screen still shows for a second or so. With the old
turtle, the transition from one "background" to another seems
instantaneous. No white blank screen visible at all.


Sounds like a valid complaint that one...

This again is a result of the animation of the turtle. Of course a correct
use of bgcolor() solves this problem - as Dick did now -, but also use 
of speed(0)

or tracer(False) would have solved it.

Regards,
Gregor

P.S.: If you are interested, you can download a series of sample programs
covering a broad range from very easy to fairly advanced, which
intend to show some features and capabilities of the new turtle module
from here:

http://svn.python.org/view/python/trunk/Demo/turtle/

These will be included in the source distribution - but not in the Windows
installer.


___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Ongoing trouble with Turtle's end_fill() - caused by abug in turtle.py

[Dick Moores]

On Thu, Aug 7, 2008 at 11:26 AM, Alan Gauld <[EMAIL PROTECTED]> wrote:
> "Dick Moores" <[EMAIL PROTECTED]> wrote
>
>> 1. The turtle has some behavior I don't see how to eliminate. If you
>> refer to lines 223, 225, 227, 229, etc., you'll see that the turtle
>> always faces in the direction it is moving when drawing a rectangle.
>
> That is correct behaviour for a turtle!

Yes. I wanted that, and set it accordingly. Those lines refer to the
program using the 2.5 turtle.py.

> Remember turtle graphics are notionally about moving a physical
> drawing device (the turtle) around on the floor or desk. If the turtle
> doesn't turn to face the direction of travel it can't travel that way!
>
> IMHO that's just a feature of the technology and any other behaviour
> would be out of keeping with the intent.

Actually, if you look at those lines, I had to go to some trouble to
get the turtle to do that!

>> Using the Python2.6 beta2 version of turtle.py, the turtle can be seen
>> at each corner spinning to orient itself to the new direction. I don't
>> want this.
>
> While far from common in turtle implementations (I have only seen
> it in my old CP/M Logo version) it is a feature that would be true
> of a physical turtle too. Its not really a bug but a "feature" I guess!

I finally found how to make the turtle disappear permanently. In the
new turtle.py, the code is "hideturtle()".

>> 2. The turtle can also be seen moving from the last corner of the last
>> rectangle to the first corner of the next. I don't want this.
>
> Again true of a physical turtle... But if you set speed to fastest
> does that work? Also in the old turtle moduile there was a way to
> hide the turtles movements completely and just draw the finished
> graphic - which was orders of magnitude faster for complex
> shapes - is that still available in turtle26?

Yes, penup(). 

> One way to hide the turtle would be top change colour to the

Thanks for thinking about it, but with hideturtle() I'm a happy camper.

>> 3. When the screen is cleared between cycles by line 367, the blank
>> screen shows for a second or so. I don't want this.
>> In my program using the old turtle I've had to create
>> colored-backgrounds by drawing a rectangle almost as large as the
>> screen (see my draw_background() beginning at line 365). With the new
>> turtle, the background color can be set by, for example,
>> screen.bgcolor("orange"). But even so, in the V16 I was trying to
>> write, that blank screen still shows for a second or so. With the old
>> turtle, the transition from one "background" to another seems
>> instantaneous. No white blank screen visible at all.

Solved that. I'm pasting the version that uses the new turtle.py.
. This runs fine, but I'll
be doing more work on it.

> Sounds like a valid complaint that one...

>> 4. I've attempted to make the turtle invisible, but haven't succeeded.

See above.

> Should be possible to set color to bgcolor. but set it back to
> draw the lines or they too will be invisible!
>
>> I'm guessing that all the problems I've mentioned aren't the result of
>> bugs--rather, I just don't understand the doc.
>
> Maybe more not understanding(remembering) the origin of turtle graphics.
> It was for kids to understand computer graphics... Seeing the shapes
> being drawn is a big part of that.

Well, I also want to see the rectangles being drawn--by an invisible turtle. ;-)

Actually, I got interested in this because of the colors. I had just
bought my first LCD monitor, a 22-incher. And I wrote the program so
that it prints the color names to the console window. I had been
ignorant about colors--had no idea what magenta, chartreuse,
turquoise, cyan were, just to mention a few.

Thanks, Alan.

Dick
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Ongoing trouble with Turtle's end_fill() - caused by abug in turtle.py

[Alan Gauld]

"Dick Moores" <[EMAIL PROTECTED]> wrote


1. The turtle has some behavior I don't see how to eliminate. If you
refer to lines 223, 225, 227, 229, etc., you'll see that the turtle
always faces in the direction it is moving when drawing a rectangle.


That is correct behaviour for a turtle!
Remember turtle graphics are notionally about moving a physical
drawing device (the turtle) around on the floor or desk. If the turtle
doesn't turn to face the direction of travel it can't travel that way!

IMHO that's just a feature of the technology and any other behaviour
would be out of keeping with the intent.

Using the Python2.6 beta2 version of turtle.py, the turtle can be 
seen
at each corner spinning to orient itself to the new direction. I 
don't

want this.


While far from common in turtle implementations (I have only seen
it in my old CP/M Logo version) it is a feature that would be true
of a physical turtle too. Its not really a bug but a "feature" I 
guess!


2. The turtle can also be seen moving from the last corner of the 
last

rectangle to the first corner of the next. I don't want this.


Again true of a physical turtle... But if you set speed to fastest
does that work? Also in the old turtle moduile there was a way to
hide the turtles movements completely and just draw the finished
graphic - which was orders of magnitude faster for complex
shapes - is that still available in turtle26?

One way to hide the turtle would be top change colour to the
background color. That would make themoving turtle invisible...


3. When the screen is cleared between cycles by line 367, the blank
screen shows for a second or so. I don't want this.
In my program using the old turtle I've had to create
colored-backgrounds by drawing a rectangle almost as large as the
screen (see my draw_background() beginning at line 365). With the 
new

turtle, the background color can be set by, for example,
screen.bgcolor("orange"). But even so, in the V16 I was trying to
write, that blank screen still shows for a second or so. With the 
old

turtle, the transition from one "background" to another seems
instantaneous. No white blank screen visible at all.


Sounds like a valid complaint that one...

4. I've attempted to make the turtle invisible, but haven't 
succeeded.


Should be possible to set color to bgcolor. but set it back to
draw the lines or they too will be invisible!

I'm guessing that all the problems I've mentioned aren't the result 
of

bugs--rather, I just don't understand the doc.


Matybe more not understanding(remembering) the origin of turtle 
graphics.

It was for kids to understand computer graphics... Seeing the shapes
being drawn is a big part of that.

HTH,

--
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld 



___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Ongoing trouble with Turtle's end_fill() - caused by a bug in turtle.py

[Dick Moores]

On Thu, Aug 7, 2008 at 9:54 AM, Dick Moores <[EMAIL PROTECTED]> wrote:
> 4. I've attempted to make the turtle invisible, but haven't succeeded.

Got it!  hideturtle()


Dick
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Ongoing trouble with Turtle's end_fill() - caused by a bug in turtle.py

[Dick Moores]

On Wed, Aug 6, 2008 at 5:09 PM, Gregor Lingl <[EMAIL PROTECTED]> wrote:
> This is due to a bug in turtle.py - interestingly after so many years of use
> and improvement of turtle.py there still appear new bugs from time to time.
>
> The bug consists in a missing update of the Canvas in the fill() function
> You can repair it by inserting a line at line#309 in turtle.py in the
> fill method as follows:
>
>   if self._filling:
>   path = tuple(self._path)
>   smooth = self._filling < 0
>   if len(path) > 2:
>   item = self._canvas._create('polygon', path,
>   {'fill': self._color,
>'smooth': smooth})
>   self._items.append(item)
>   self._canvas.update()  #  <=== bug-fix
>   self._path = []
>
> Now for the good news:
>
> (1) If you have done this, not only Dick's program works as
> intended,


Yes, it does! I've pasted a version at
. Thank you!


> (2) Python 2.6 will have a new turtle module - formerly known to some
> as xturtle.py - which has much more capabilities and which at least doesn't
> show
> this bug. Presumably there will appear others, especially in the beginning
> of
> it's use. It is contained in Python2.6 beta2, it runs also under Python2.5
> and it should be (nearly?) 100%-compatible with the old turtle module.
>
> Its documentation can be found here:
> http://docs.python.org/dev/library/turtle.html#module-turtle
>
> It would be really very helpful, if those of you who use to use turtle
> graphcis would work with this new module in order to reveal as many
> bugs as possible before the final release of Python 2.6 scheduled for
> early october 2008.


I got Python2.6 beta2 and copied its turtle.py to my Python 2.5 after
renaming it turtle26.py. By now I've spent several hours trying to
figure out how to get my program to work well with it. I don't know if
I've discovered any bugs, but here are some of the problems I have:

1. The turtle has some behavior I don't see how to eliminate. If you
refer to lines 223, 225, 227, 229, etc., you'll see that the turtle
always faces in the direction it is moving when drawing a rectangle.
Using the Python2.6 beta2 version of turtle.py, the turtle can be seen
at each corner spinning to orient itself to the new direction. I don't
want this. I thought I could remove the spinning effect by setting the
turtle's shape to a circle. But the circle is way bigger than the
default turtle. No spinning, but not what I'm after.

2. The turtle can also be seen moving from the last corner of the last
rectangle to the first corner of the next. I don't want this.

3. When the screen is cleared between cycles by line 367, the blank
screen shows for a second or so. I don't want this.
In my program using the old turtle I've had to create
colored-backgrounds by drawing a rectangle almost as large as the
screen (see my draw_background() beginning at line 365). With the new
turtle, the background color can be set by, for example,
screen.bgcolor("orange"). But even so, in the V16 I was trying to
write, that blank screen still shows for a second or so. With the old
turtle, the transition from one "background" to another seems
instantaneous. No white blank screen visible at all.

4. I've attempted to make the turtle invisible, but haven't succeeded.

I'm guessing that all the problems I've mentioned aren't the result of
bugs--rather, I just don't understand the doc.


> Of course I'd assist if questions or problems would arise.


Thanks.

Dick
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Ongoing trouble with Turtle's end_fill() - caused by a bug in turtle.py

[Gregor Lingl]

Kent Johnson schrieb:

On Tue, Aug 5, 2008 at 6:49 PM, Dick Moores <[EMAIL PROTECTED]> wrote:
  

For a while now I've had trouble with end_fill(). Sometimes I can use
it to fill a figure such as a square, triangle or rectangle, but
sometimes not.

Here's a barebones script using end_fill(). As you can see, it draws a
square twice, but fails to fill it. Pleas show me how to use it
correctly in tandem with begin_fill().



  

Hi all,

Kent's version below repairs the problem more or less accidentally
and moreover not completely:

(1) the first square is not filled properly; instead a filled pentagon 
appears

after the first traversal of the loop.
(2) the filling takes place due to the goto() call after the end_fill() 
call and

before the clear() call.

This is due to a bug in turtle.py - interestingly after so many years of use
and improvement of turtle.py there still appear new bugs from time to time.

The bug consists in a missing update of the Canvas in the fill() function
You can repair it by inserting a line at line#309 in turtle.py in the
fill method as follows:

   if self._filling:
   path = tuple(self._path)
   smooth = self._filling < 0
   if len(path) > 2:
   item = self._canvas._create('polygon', path,
   {'fill': self._color,
'smooth': smooth})
   self._items.append(item)
   self._canvas.update()  #  <=== bug-fix
   self._path = []

Now for the good news:

(1) If you have done this, not only Dick's program works as
intended, but you may also write the square_filling program
in a cleaner way, for instance like this:

from turtle import *
import time

setup(width=1000, height=700, startx=0, starty=0)
color_name = 'red'
x, y = 50, 50
color(color_name)
print color_name
up()
goto(x, y)
down()
for n in range(2):
  begin_fill()
  goto(x, -y)
  goto(-x, -y)
  goto(-x, y)
  goto(x, y)
  end_fill()
  print "end_fill()"
  time.sleep(1)
  clear()

(2) Python 2.6 will have a new turtle module - formerly known to some
as xturtle.py - which has much more capabilities and which at least 
doesn't show
this bug. Presumably there will appear others, especially in the 
beginning of

it's use. It is contained in Python2.6 beta2, it runs also under Python2.5
and it should be (nearly?) 100%-compatible with the old turtle module.

Its documentation can be found here:
http://docs.python.org/dev/library/turtle.html#module-turtle

It would be really very helpful, if those of you who use to use turtle
graphcis would work with this new module in order to reveal as many
bugs as possible before the final release of Python 2.6 scheduled for
early october 2008.

Of course I'd assist if questions or problems would arise.

Regards
Gregor

Here is a version that does fill:
from turtle import *
import time

setup(width=1000, height=700, startx=0, starty=0)
for n in range(2):
   color_name = 'red'
   x, y = 50, 50
   color(color_name)
   print color_name
   up()
   goto(x, y)
   down()
   begin_fill()
   goto(x, -y)
   goto(-x, -y)
   goto(-x, y)
   end_fill()
   print "end_fill()"
   goto(x, y)
   time.sleep(1)
   clear()

I have no idea why this one works and yours doesn't. Your program is
very similar to the filled square in turtle.demo() which does work.

The filling is implemented by drawing a polygon on a Tkinter Canvas;
is there something strange about polygons?

Kent
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor


  

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Ongoing trouble with Turtle's end_fill()

[Alan Gauld]

"Dick Moores" <[EMAIL PROTECTED]> wrote
Well, Kent, it seems you have found the right places for 
begin_fill()

and end_fill().


Yes, quite bizarrely the fill needs an open shape to fill.
If you close the figure and then end_fill it doesn't work.
How counter intuitive is that!

Oh well, one to remember for future use.

Alan G. 



___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Ongoing trouble with Turtle's end_fill()

[Dick Moores]

On Wed, Aug 6, 2008 at 4:50 AM, Kent Johnson <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 5, 2008 at 6:49 PM, Dick Moores <[EMAIL PROTECTED]> wrote:
>> For a while now I've had trouble with end_fill(). Sometimes I can use
>> it to fill a figure such as a square, triangle or rectangle, but
>> sometimes not.
>>
>> Here's a barebones script using end_fill(). As you can see, it draws a
>> square twice, but fails to fill it. Pleas show me how to use it
>> correctly in tandem with begin_fill().
>
> Here is a version that does fill:
> from turtle import *
> import time
>
> setup(width=1000, height=700, startx=0, starty=0)
> for n in range(2):
>   color_name = 'red'
>   x, y = 50, 50
>   color(color_name)
>   print color_name
>   up()
>   goto(x, y)
>   down()
>   begin_fill()
>   goto(x, -y)
>   goto(-x, -y)
>   goto(-x, y)
>   end_fill()
>   print "end_fill()"
>   goto(x, y)
>   time.sleep(1)
>   clear()
>
> I have no idea why this one works and yours doesn't. Your program is
> very similar to the filled square in turtle.demo() which does work.

Well, Kent, it seems you have found the right places for begin_fill()
and end_fill().
The 450-line script I was writing now works perfectly at last, in what
is now version 15.

Thanks very much. And my thanks also to Alan.

Dick
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Ongoing trouble with Turtle's end_fill()

[Kent Johnson]

On Tue, Aug 5, 2008 at 6:49 PM, Dick Moores <[EMAIL PROTECTED]> wrote:
> For a while now I've had trouble with end_fill(). Sometimes I can use
> it to fill a figure such as a square, triangle or rectangle, but
> sometimes not.
>
> Here's a barebones script using end_fill(). As you can see, it draws a
> square twice, but fails to fill it. Pleas show me how to use it
> correctly in tandem with begin_fill().

Here is a version that does fill:
from turtle import *
import time

setup(width=1000, height=700, startx=0, starty=0)
for n in range(2):
   color_name = 'red'
   x, y = 50, 50
   color(color_name)
   print color_name
   up()
   goto(x, y)
   down()
   begin_fill()
   goto(x, -y)
   goto(-x, -y)
   goto(-x, y)
   end_fill()
   print "end_fill()"
   goto(x, y)
   time.sleep(1)
   clear()

I have no idea why this one works and yours doesn't. Your program is
very similar to the filled square in turtle.demo() which does work.

The filling is implemented by drawing a polygon on a Tkinter Canvas;
is there something strange about polygons?

Kent
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Ongoing trouble with Turtle's end_fill()

[Alan Gauld]

"Dick Moores" <[EMAIL PROTECTED]> wrote


Here's a barebones script using end_fill(). As you can see, it draws 
a

square twice, but fails to fill it. Pleas show me how to use it
correctly in tandem with begin_fill().

The Turtle doc is at 


How odd.

I can't get it to work either but it does in the turtle demo.
Even cut n pasting the demo code into a function didn't work for me.

I'm curious if anyone else gets this one working?

I'm on XP, Python 2.5 BTW

Alan G. 



___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor