[Python-Dev] Tkinter script crashes Python 3.1

[Gregor Lingl]

I've written a small Tkinter-Script, that crashes Python 3.1 (but not 
Python 2.6) without any specific rrror message. When started from within 
IDLE, the failing of the script also closes IDLE. (This is the case 
under Windows, Mac OS X and Linux (teted with Ubuntu 9.04))


Bug-Tracker Issue 6717
The script is attached to this issue

I think, errors like this should definitely not occur. Instead a message 
like "recusion depth exceeded" should be displayed (and IDLE should 
remain functional, if used)


Since I do not have the means availble to track down this bug, I'd like 
to draw your attention to it and to ask if someone else has the means 
and time to do so.


I'd also suggest to increase the priority of this bug in the bugtracker.

Regards,
Gregor



___
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

[Python-Dev] turtle.py update for 3.1

[Gregor Lingl]

Hi,

Encouraged by a conversation with Martin at PyCon 2009
I've prepared a version 1.1b of the turtle module and I'd like to
get some advice or assistance to get it into the beta as explained
below. Thus I'd appreciate very much if also the release manager
would take notice of this posting.

python 2.0 had the version 1.0 and for now I'll give a terse
summary of the changes I did:

1. a few bugfixes, with 1 - 5 lines of code changed for each;
   these concern bugs that prevented turtle to run correctly

2. I've added four methods to the class TurtleScreeenBase:
   _onkeypress(fun, key)  (supplementing _onkeyrelease)
   mainloop()  (which is now a Screen-method and a function)
   textinput(title, prompt)
   numinput(title, prompt, default, minval, maxval)
  the latter two remedy the complete lack of input methods

   _onkey, an internal method name is changed to _onkeyrelease

3. I've added one method to the class TurtleScreen:
   onkeypress(fun, key=None) 
   implemented in analogy to the already present onkey()

   which got onkeyrelease as an alias.

4. I've changed several portions of the code that affect
  the representation of the turtleshape thus making it
  more compact (by removing some duplicated code) and more
  powerful, i. e. by adding the possibility to apply
  shearings to turtleshapes (in addition to the already present
  scaling and rotating transformations). Thus now the full
  range of (non singular) linear transformations is available.

  New methods in class RawTurtle:
   shearfactor(shear=None)set or get the shearfactor
   shapetransform(t11, t12, t21, t22)
   set or get the shape transform directly
   get_shapepoly() return the polygon of the current shape

  I've enhanced the functionality of tiltangle(angle=None)
  to contain also that of settiltangle and I propose to
  declare settiltangle as deprecated.
  
5. I've removed a lot of codelines that were commented out

  during the process of transferring the module from 2.6
  to 3.0

6. I've implemented the bugfix for http://bugs.python.org/issue4117
  according do my proposition there and I strongly
  recommend this change again, as the bug described is very
  annoying, the fix is easy and no one proposed a better
  solution.

7. I've tested the present version 1.1 extensivly. It runs
  all the demo scripts without problems and many others
  too (some of them significantly better than version 1.1).
  I'd like to add two additional scripts to the demo
  directory, one of them using new features so it only runs
  with this new version.

I've *not* touched the issue of the Screen singleton, so that
remains unchanged as it was as a result of Martins patch.

Thus, as a summary, this update does some bugfixes and eliminates
three deficiencies of the module: (1) accept keypress event,
(2) provide user input functions and (3) complement scaling
and rotating of turtleshapes by shearing, thus providing
the full range of linear transforms.

HOW TO PROCEED NOW?

(1) Submit the new version as a single file
(2) submit a unified diff containing all the changes
(3) Divide the changes into several chunks of
   related changes and submit the according diffs separately
   That would pose the problems, that there are lines
   in the code that are affected by several changes,
   e. g. those lines that define __all__
   And also: does the order of applying the patches matter?
   How do I have to account for this?
(4) Some other approach?

I'd appreciate to discuss open issues as needed and I'm
prepared to give more elaborate explanations and rationales
as wanted or as needed.

Docs for the changes are (to a large extent) contained in the
docstrings and I'm going to update the Documentation of the
turtle module (on the basis of theses docstrings) now.

Thanks in advance for your support

Gregor


 
  







 









___
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] draft 3.1 release schedule

[Gregor Lingl]

Benjamin Peterson schrieb:

On Sun, Feb 15, 2009 at 10:59 AM, Guido van Rossum  wrote...
  



Something like this?

3.1a1 March 7
3.1a2 April 4
3.1b1 May 2
3.1rc1 May 30
3.1rc2 June 13
3.1 Final June 27

That sounds reasonable. I will try to enforce a fairly strict
stability policy during the beta and RCs.
  



I've started a list on the release PEP [1].

[1] http://www.python.org/dev/peps/pep-0375/
  

Is the intention to release 2.7 and 3.1 in parallel?

I suspect, comparing this to

http://www.python.org/dev/peps/pep-0373/

that there is some name mangling in pep-0375?

Regards,
Gregor
___
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] RELEASED Python 3.0 final

[Gregor Lingl]

[EMAIL PROTECTED] schrieb:


To be fair, if someone asked me specifically about educating non- 
programmer adults about programming, I would probably at least 
*mention* py3, if not recommend it outright.  The improved consistency 
is worth a lot in an educational setting.  (But, if one is educating 
children and interested in soliciting their genuine enthusiasm, 
whiz-bang graphics are really a must-have, not a negotiable extra.)
As a non native English speaker I'm not sure if I understand correctly, 
what you mean with whiz-bang graphics. Nevertheless I'd like to point 
you to the new turtle graphics module (which is part of the standard 
librarys since 2.6). At least it was designed especially for use in the 
educational  domain. Moreover the source-distribution also contains a 
bunch of some ten example scripts.


Regards,
Gregor

___
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] RELEASED Python 3.0 final

[Gregor Lingl]

Guido van Rossum schrieb:

I hear some folks are considering advertising 3.0 as experimental or
not ready for serious use yet.

I think that's too negative -- we should encourage people to use it,
period. They'll have to decide for themselves whether they can live
with the lack of ported 3rd party libraries -- which may resolve
itself soon enough. 
I'd find it useful to have a special regularly updated index of 
libraries already ported to 3.0 somewhere on python.org


Gregor
___
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

[Python-Dev] Old green snake icon on Windows

[Gregor Lingl]

I've installed the new Python 2.6 for windows (Windows-installer)
on several machines among them a new one which has never seen
Python before and all these installations show the old fashioned green
snake logo (from Python 2.3 or before, I think) in the automatically
created menu-entries.

Has anybody else observed this?

What could be the reason for this?

Is this intentional, and if so what is the intention?

Or is there something wrong with the installer?

(I even cannot change  the icons for the menu-entries  because  these
links don't behave like ordinary links and the change-icon-button
in the property dialog is greyed out).

Should this be posted to the issue-tracker
Regards,
Gregor
___
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] turtle.Screen.__init__ issue

[Gregor Lingl]

Martin v. Löwis schrieb:

What is your opinion, and who should decide?



Please don't post patches to the mailing list. Post them exclusively
to bugs.python.org instead.
  
Ok. But this was meant for illustrative purposes only and not as a 
patch-submission, which

I'll do eventually separately.

Sorry
Gregor

Also, don't post unrelated patches in a single message. Create separate
issues in the bug tracker for them.

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

[Python-Dev] turtle.Screen.__init__ issue

[Gregor Lingl]

Hello there,

its high time to resolve an issue, which I have already addressed twice 
some weeks ago. (You can find a more elaborate description in my former 
posting cited below)


There is a tiny difference (also in behaviour!) in 
turtle.Screen.__init__() between the versions for 2.6 and 3.0. The 
difference results from the fact, that I submitted the 3.0 version 
approx. a week later, after having it ported to 3.0. In this process I 
had found what I now consider to be a bug in 2.6 and changed it 
accordingly.  Shortly:


If you have already a Screen object containing some turtles and some 
graphics,


in 2.6: s = Screen() returns an object with identical state and 
behaviour, but clears (re-initializes) the screen and thus destroys the 
content
in 3.0 s = Screen()  returns an object with identical state and 
behaviour, but leaves the content untouched


The difference in code consist only in indenting the call of the 
__init__ method of the parent class, so it will be executed only 
conditionally.


Anyway, as this difference between the two versions is highly 
undesirable there are (imho) three options to proceed:


(1) correct 2.6 in order that it will work like 3.0
(2) undo the change in 3.0 in order that it will work like 2.6
(3) find a different solution for both

I would (like Vern, see below) decisevely prefer option (1), and I 
suppose that there is not enough time left to chose option (3) as this 
would probably need some discussions.


What is your opinion, and who should decide?

For your convenience I've attached a diff-file which also contains the 
description of three other small bugs, which I've found in the meantime 
and which shouldn't cause any controversies.


Regards, Gregor


%%

Here follows the answer of Vern Ceder - a long term turtle graphics user 
and author of several patches for the old turtle module - to my former 
posting:


>> Gregor,
>>
>> I don't feel authoritative on the correctness/appropriateness of the 
implementation,
>> but I do agree completely that behavior b, or what you have in the 
3.0 version,

>> is vastly preferable.
>>
>> Cheers,
>> Vern



 Original-Nachricht 
Betreff:[Python-Dev] turtle.Screen- how to implement best a Singleton
Datum:  Mon, 18 Aug 2008 10:15:45 +0200
Von:Gregor Lingl <[EMAIL PROTECTED]>
An: python-dev@python.org
CC: 	Toby Donaldson <[EMAIL PROTECTED]>, [EMAIL PROTECTED], 
[EMAIL PROTECTED], Brad Miller <[EMAIL PROTECTED]>, Vern Ceder 
<[EMAIL PROTECTED]>




Hi,

this posting - concerning the new turtle module - goes to the Python-Dev 
and Python-3000 lists and to a couple of 'power users' of turtle 
graphics, hoping to recieve feedback from the developer's point of view 
as well as from the user's point of view.


Currently the implementations of the turtle.Screen class for Python 2.6 
and Python 3.0 differ by a 'tiny' detail with an important difference in 
behaviour. So clearly this has to be resolved  before the final 
release.(The origin of this difference is, that when I ported turtle.py 
to Python 3.0 I discovered (and 'fixed') what I now consider to be a bug 
in the 2.6 version.) I'd like to ask you kindly for your advice to 
achieve an optimal solution.


The posting consists of three parts:
1. Exposition of design goals
2. Problem with the implementation 
3. How to solve it?


Preliminary remark:  I've had some discussions on this topic before but 
I still do not see a clear solution. Moreover I'm well aware of the fact 
that using the Singleton pattern is controversial. So ...


1. Exposition of design goals
... why use the Singleton design pattern? The turtle module contains a 
TurtleScreen class, which implements methods to control the drawing area 
the turtle is (turtles are) drawing on. It's constructor needs a Tkinter 
Canvas as argument. In order to avoid the need for users to tinker 
around with Tkinter stuff there is the Screen(TurtleScreen) class, 
designed to be used by beginners(students, kids,...), particularly in 
interactive sessions.


A (THE (!)) Screen object is essentially a window containing a scrolled 
canvas, the TurtleScreen. So it's a ressource which should exist only 
once. It can be constructed in several ways:
- implicitely by calling an arbitrary function derived from a 
Turtle-method, such as forward(100) or by constructing a Turtle such as 
bob = Turtle()
- implicitely by calling an arbitrary function derived from a Screen 
method, such as bgcolor("red")

- explicitely by calling it's constructor such as s = Screen()
Anyway this construction should only happen if a Screen object doesn't 
exist yet.
Now for the pending question: What should happen, when s = Screen() is 
called explicitely and there exists already 'the' Screen object.

(i) Clearly s should get a refe

Re: [Python-Dev] turtle.Screen- how to implement best a Singleton

[Gregor Lingl]

Thanks for the feedback,
Gregor

Vern Ceder schrieb:

Gregor,

I don't feel authoritative on the correctness/appropriateness of the 
implementation, but I do agree completely that behavior b, or what you 
have in the 3.0 version, is vastly preferable.


Cheers,
Vern

Gregor Lingl wrote:

Hi,

this posting - concerning the new turtle module - goes to the 
Python-Dev and Python-3000 lists and to a couple of 'power users' of 
turtle graphics, hoping to recieve feedback from the developer's 
point of view as well as from the user's point of view.


Currently the implementations of the turtle.Screen class for Python 
2.6 and Python 3.0 differ by a 'tiny' detail with an important 
difference in behaviour. So clearly this has to be resolved  before 
the final release.(The origin of this difference is, that when I 
ported turtle.py to Python 3.0 I discovered (and 'fixed') what I now 
consider to be a bug in the 2.6 version.) I'd like to ask you kindly 
for your advice to achieve an optimal solution.


The posting consists of three parts:
1. Exposition of design goals
2. Problem with the implementation 3. How to solve it?

Preliminary remark:  I've had some discussions on this topic before 
but I still do not see a clear solution. Moreover I'm well aware of 
the fact that using the Singleton pattern is controversial. So ...


1. Exposition of design goals
... why use the Singleton design pattern? The turtle module contains 
a TurtleScreen class, which implements methods to control the drawing 
area the turtle is (turtles are) drawing on. It's constructor needs a 
Tkinter Canvas as argument. In order to avoid the need for users to 
tinker around with Tkinter stuff there is the Screen(TurtleScreen) 
class, designed to be used by beginners(students, kids,...), 
particularly in interactive sessions.


A (THE (!)) Screen object is essentially a window containing a 
scrolled canvas, the TurtleScreen. So it's a ressource which should 
exist only once. It can be constructed in several ways:
- implicitely by calling an arbitrary function derived from a 
Turtle-method, such as forward(100) or by constructing a Turtle such 
as bob = Turtle()
- implicitely by calling an arbitrary function derived from a Screen 
method, such as bgcolor("red")

- explicitely by calling it's constructor such as s = Screen()
Anyway this construction should only happen if a Screen object 
doesn't exist yet.
Now for the pending question: What should happen, when s = Screen() 
is called explicitely and there exists already 'the' Screen object.
(i) Clearly s should get a reference to the existing Screen object, 
but ...
(ii) (a)... should s be reinitialized (this is the case now in Python 
2.6), or
(b)... should s be left untouched (this is the case now in Python 
3.0)


I, for my part, prefer the latter solution (b). Example: a student, 
having (interactively) produced some design using some turtle t = 
Turtle() decides spontaneously to change backgroundcolor. s = 
Screen(); s.bgcolor("pink") should do this for her - instead of 
deleting her design and moreover her turtle. To reinitialize the 
screen she still can use s.clear().


Of course, there are workarounds to achieve the same effect also with 
solution (a), for instance by assigning s = Screen() *before* drawing 
anything or by assigning s = t.getscreen(). But imho (which derives 
itself from my experience as a teacher) solution (b) supports better 
the oop-view as well as experimenting spontaneously in interactive 
sessions.


2. Problem with the implementation
The task is to derive a Singleton class from a Nonsingleton class 
(Screen from TurtleScreen). The current implementations of the Screen 
'Singleton' both use the Borg idiom.  Just for *explaining* the 
difference between the two versions of class Screen here concisely,  
I'll use a 'standard' Singleton pattern (roughly equivalent to the 
Borg idiom):


class Spam(object):
   def __init__(self, s):
   self.s = s

class SingleSpam(Spam):
   _inst = None
   def __new__(cls, *args, **kwargs):  if cls != 
type(cls._inst):

   cls._inst = Spam.__new__(cls, *args, **kwargs)
   return cls._inst
   def __init__(self, s):
   if vars(self): return##  should this be here???
   Spam.__init__(self, s)

Shortly, this means that SingleSpam.__init__() acts like an empty 
method whenever a (the!) SingleSpam object already exists. 3.0 
version of Screen acts like this. By contrast 2.6 version of Screen 
acts as if the butlast line were not there and thus reinitializes the 
Screen object.


3. How to solve it?

Main question: which *behaviour* of the Screen class should be 
preferred.  If  3.0, is it feasible and correct not to call the 
constructor of the parent class if the object already exists?


Additional question: Do you consider the Borg idiom a good solution 
for

[Python-Dev] turtle.Screen- how to implement best a Singleton

[Gregor Lingl]

Hi,

this posting - concerning the new turtle module - goes to the Python-Dev 
and Python-3000 lists and to a couple of 'power users' of turtle 
graphics, hoping to recieve feedback from the developer's point of view 
as well as from the user's point of view.


Currently the implementations of the turtle.Screen class for Python 2.6 
and Python 3.0 differ by a 'tiny' detail with an important difference in 
behaviour. So clearly this has to be resolved  before the final 
release.(The origin of this difference is, that when I ported turtle.py 
to Python 3.0 I discovered (and 'fixed') what I now consider to be a bug 
in the 2.6 version.) I'd like to ask you kindly for your advice to 
achieve an optimal solution.


The posting consists of three parts:
1. Exposition of design goals
2. Problem with the implementation 
3. How to solve it?


Preliminary remark:  I've had some discussions on this topic before but 
I still do not see a clear solution. Moreover I'm well aware of the fact 
that using the Singleton pattern is controversial. So ...


1. Exposition of design goals
... why use the Singleton design pattern? The turtle module contains a 
TurtleScreen class, which implements methods to control the drawing area 
the turtle is (turtles are) drawing on. It's constructor needs a Tkinter 
Canvas as argument. In order to avoid the need for users to tinker 
around with Tkinter stuff there is the Screen(TurtleScreen) class, 
designed to be used by beginners(students, kids,...), particularly in 
interactive sessions.


A (THE (!)) Screen object is essentially a window containing a scrolled 
canvas, the TurtleScreen. So it's a ressource which should exist only 
once. It can be constructed in several ways:
- implicitely by calling an arbitrary function derived from a 
Turtle-method, such as forward(100) or by constructing a Turtle such as 
bob = Turtle()
- implicitely by calling an arbitrary function derived from a Screen 
method, such as bgcolor("red")

- explicitely by calling it's constructor such as s = Screen()
Anyway this construction should only happen if a Screen object doesn't 
exist yet.
Now for the pending question: What should happen, when s = Screen() is 
called explicitely and there exists already 'the' Screen object.

(i) Clearly s should get a reference to the existing Screen object, but ...
(ii) (a)... should s be reinitialized (this is the case now in Python 
2.6), or

(b)... should s be left untouched (this is the case now in Python 3.0)

I, for my part, prefer the latter solution (b). Example: a student, 
having (interactively) produced some design using some turtle t = 
Turtle() decides spontaneously to change backgroundcolor. s = Screen(); 
s.bgcolor("pink") should do this for her - instead of deleting her 
design and moreover her turtle. To reinitialize the screen she still can 
use s.clear().


Of course, there are workarounds to achieve the same effect also with 
solution (a), for instance by assigning s = Screen() *before* drawing 
anything or by assigning s = t.getscreen(). But imho (which derives 
itself from my experience as a teacher) solution (b) supports better the 
oop-view as well as experimenting spontaneously in interactive sessions.


2. Problem with the implementation
The task is to derive a Singleton class from a Nonsingleton class 
(Screen from TurtleScreen). The current implementations of the Screen 
'Singleton' both use the Borg idiom.  Just for *explaining* the 
difference between the two versions of class Screen here concisely,  
I'll use a 'standard' Singleton pattern (roughly equivalent to the Borg 
idiom):


class Spam(object):
   def __init__(self, s):
   self.s = s

class SingleSpam(Spam):
   _inst = None
   def __new__(cls, *args, **kwargs):   
   if cls != type(cls._inst):

   cls._inst = Spam.__new__(cls, *args, **kwargs)
   return cls._inst
   def __init__(self, s):
   if vars(self): return##  should this be here???
   Spam.__init__(self, s)

Shortly, this means that SingleSpam.__init__() acts like an empty method 
whenever a (the!) SingleSpam object already exists. 3.0 version of 
Screen acts like this. By contrast 2.6 version of Screen acts as if the 
butlast line were not there and thus reinitializes the Screen object.


3. How to solve it?

Main question: which *behaviour* of the Screen class should be 
preferred.  If  3.0, is it feasible and correct not to call the 
constructor of the parent class if the object already exists?


Additional question: Do you consider the Borg idiom a good solution for 
this task or should the standard singleton pattern as shown above be 
preferred. Or would you suggest a solution/an approach different from both?


Thanks for your patience, and - in advance - for your assistance

Regard,
Gregor




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/opt

Re: [Python-Dev] RELEASED Python 2.6a2 and 3.0a4

[Gregor Lingl]

Hi, something doesn't work as usual, at least for me:

When I try to download the Python 2.6a2 release for Windows by clicking

* Windows x86 MSI Installer (2.6a2)
   (sig)
  

instead of the usual download dialog I get an

Error 404: File not found

for the url

http://www.python.org/ftp/python/2.6/python-2.6a2.msi .

The same is true when trying to download Python 3.0 a4.

Embarassed,
Gregor



Barry Warsaw schrieb:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On behalf of the Python development team and the Python community, I'm  
> happy to announce the second alpha release of Python 2.6, and the  
> fourth alpha release of Python 3.0.
>
> Please note that these are alpha releases, and as such are not  
> suitable for production environments.  We continue to strive for a  
> high degree of quality, but there are still some known problems and  
> the feature sets have not been finalized.  These alphas are being  
> released to solicit feedback and hopefully discover bugs, as well as  
> allowing you to determine how changes in 2.6 and 3.0 might impact  
> you.  If you find things broken or incorrect, please submit a bug  
> report at
>
> http://bugs.python.org
>
> For more information and downloadable distributions, see the Python  
> 2.6 web
> site:
>
> http://www.python.org/download/releases/2.6/
>
> and the Python 3.0 web site:
>
> http://www.python.org/download/releases/3.0/
>
> We are planning one more alpha release of each version, followed by  
> two beta releases, with the final releases planned for August 2008.   
> See PEP 361 for release details:
>
>  http://www.python.org/dev/peps/pep-0361/
>
> Enjoy,
> - -Barry
>
> Barry Warsaw
> [EMAIL PROTECTED]
> Python 2.6/3.0 Release Manager
> (on behalf of the entire python-dev team)
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.8 (Darwin)
>
> iQCVAwUBR/WImHEjvBPtnXfVAQJmoQP+MzqNDI+Xt8zua/FE7Ca4TVXoIIy2uoOm
> I1i3+vmevZ9vtAb9hcGwfEgPY4LSwb9Js4KnJJWMPaMuFJK4NgGoiMdj+t42zDbQ
> bEzfBUOCoVkejLRxIQnWeJf1Hu8JocYyCHIRffv57/QdKpHuiSs8aE8GIT3STo3o
> I88H5NY1GgI=
> =WT2z
> -END PGP SIGNATURE-
> ___
> 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/gregor.lingl%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

[Python-Dev] xturtle and 2.6

[Gregor Lingl]

Hi everyone,

I happily like to report, that xturtle is running under Python 2.6
seemingly without any problems.

Thanks to Paul Moore's advice I could get Python 2.6 running on
my windows machine.

I tested xturtle running those 30+ sample scripts, which are contained in
the xturtle package with the included demoViewer and not a single (new)
problem did occur.

Quite a few of these samplescripts contain runtime measurements, which
consistently showed that they ran 5 to 15% faster than under Python2.5

Regards,
Gregor


___
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] Installing Python 2.6 alpha1 on Windows XP

[Gregor Lingl]

Paul Moore schrieb:
> On 17/03/2008, Gregor Lingl <[EMAIL PROTECTED]> wrote:
>>  When doing the same call to execute idle as you, I got the following:
>>
>>  Traceback (most recent call last):
>>   File "c:\Python26\Lib\idlelib\idle.py", line 6, in 
>> import PyShell
>>   File "c:\Python26\Lib\idlelib\PyShell.py", line 9, in 
>> import socket
>>   File "c:\Python26\Lib\socket.py", line 46, in 
>> import _socket
>>  ImportError: DLL load failed: 
>
> Can you try running C:\Python26\python.exe, and then at the
> interpreter prompt, execute:
>
> import sys
> print sys.path
> import socket
>
> and post the results?
>
 >>> import sys
 >>> print sys.path
['', 'C:\\Python26\\python26.zip', 'C:\\Python26\\DLLs', 
'C:\\Python26\\lib', ]
'C:\\Python26\\lib\\plat-win', 'C:\\Python26\\lib\\lib-tk', 'C:\\Python26',
'C:\\Python26\\lib\\site-packages']
 >>> import socket
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Python26\lib\socket.py", line 46, in 
import _socket
ImportError: DLL load failed: Das System kann die angegebene Datei nicht 
finden.  ;-) :-(

 >>>
> I expect you will get the same error about _socket not being loadable,
> but I'd like to check. Also can you try just "import _socket"?
>
 >>> import _socket
Traceback (most recent call last):
  File "", line 1, in 
ImportError: DLL load failed: Das System kann die angegebene Datei nicht 
finden.

> What is the size of _socket.pyd - mine is 44,032 bytes.
>
The same
> Another thought - do you have any copies of msvcr90.dll on your PATH?
> I don't think it'll make a difference, but if you do can you try
> renaming them?
>
>   
No I don't! Only in c:\Python26, in c:\Python30 and on c:\Python30\DLLs.
Strange that there are two copies of msvcr90.dll in Python30.

So I'll copy this beast also to C:\Python26\DLLs,
and ... it works!
I can import socket and I even can start IDLE from the Python2.6 Menu

Thanks for your advice.

Do you have an idea if this is a 'bug' in the installer? Why the 
differences between
2.6 and 3000. Why two copies of that .dll in Python 30.0?

I'm rather happy now :-)
Have a nice evening. (Here in Vienna it's already 0:51 am.)

All the best
Gregor
>>  I never experienced a similar Problem before when installing Python.
>>
>>  Any ideas?
>> 
>
> Not many :-(
>
> One final thought, what is the value of your PATH variable? Mine has
> no Python entries in it at all - that's normal, the Python installer
> doesn't set PATH.
>
> Sorry I can't be of more help,
> 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

[Python-Dev] Installing Python 2.6 alpha1 on Windows XP

[Gregor Lingl]

Hi Paul,

thanks for you efforts, but up to now it still didn't work.

I'm using Windows XP Professional (32 bit).
I tried an install on two different machines with the same negative result.

I proceeded like you suggested.
- I installed for all users,
- I disabled the register extensions

When doing the same call to execute idle as you, I got the following:

Traceback (most recent call last):
  File "c:\Python26\Lib\idlelib\idle.py", line 6, in 
import PyShell
  File "c:\Python26\Lib\idlelib\PyShell.py", line 9, in 
import socket
  File "c:\Python26\Lib\socket.py", line 46, in 
import _socket
ImportError: DLL load failed: 

I get a similar error message, when I do

from turtle import *

with
 ...
import _tkinter
 Import Error. DLL load failed 

sys.path is exactly like yours. (So the DLLs directory is contained
in sys.path) _tkinter.pyd and _socket.pyd are present in DLLs.

I've installed  Python 2.5 on both machines. On the first one I
moreover deleted all entries concerning Python (2.5) from the
PATH variable, with no positive effect.

On the other machine I have also installed Python 3000 successfully,
which even still doesn't have IDLE in it's Menu. Nevertheless there

C:\Python30> python Lib\idlelib\idle.py

brings up IDLE 3.0a1 (and I even can import and use a port of xturtle.py to
Python 3000 there).

I never experienced a similar Problem before when installing Python.

Any ideas?

Regards,
Gregor



___
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] [Python-3000] xturtle and 3.0

[Gregor Lingl]

Brett Cannon schrieb:
> ...
> The current plan is to introduce a tk package and turtle was to become
> tk.turtle. xturtle, if picked up, can just take the place of the
> current turtle at that location.
>
> -Brett
>   
Hi Brett,

as you probably can imagine, I'd like to try out xturtle.py with Python 2.6
Alas, I didn't succeed installing Python 2.6 correctly on my Windows 
machine using
the Windows msi installer.

Whereas I could start the python interpreter successfully it was 
impossible to use it
to execute either idle.py nor turtle.py

In the first case I got an import error:

import _socket
Import Error: DLL load failed

in the second one likewise

import _tkinter
Import Error: DLL load failed

A look on sys.path showed the DLLs directory to be present there.
Do you have an explanation for this behaviour? What can I do to
avoid it? Do I have to take some special action when installing the
alpha release (I did it "for this user only")?

With best regards,
Gregor

___
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] [Python-3000] 2.6 and 3.0 project management

[Gregor Lingl]

Hi everyone,

with this posting I refer to a paragraph in PEP 361, which says:

"""Each non-trivial feature listed here that is not a PEP must be discussed on 
python-dev.  Other enhancements include:

   - ...
   - turtle.py replacement or enhancements
"""

Some time ago I had offered my xturtle.py as a replacement of or 
supplement to turtle.py. The discussion that followed is here:

http://www.python.org/dev/summary/2006-06-16_2006-06-30/

At Europython 2006 I gave a talk on xturtle and there and since then I 
had quite positive feedback including encouragement to offer it again to 
include it in the python standard distribution by quite a few people 
including Guido van Rossum.

During the last few weeks I did some enhancements to xturtle and put the 
current version on the xturtle website for download in order to get same 
feedback about the API as well as possible bug reports. This version 
still needs some code polishing.

http://www.rg16.at/~python/xturtle/download.html

So I'm interested to know if this is still an issue for you. If so there 
should be initiated some procedure to decide that.

If this decision were negative, things were done (- and I'd continue to 
develop xturtle elsewhere.)

If the decision were positive, I'd be able to prepare two equivalent 
versions for Python2.6 and Python3000 within two or three weeks. (The 
port to Python3000 is nearly ready.) These could include say 85% of the 
documentation, albeit still not in the correct format.

I think these had to be examined my some reviewer(s) and also a 
discussion about features to include or not include would be useful. I'd 
like to intensivly take part in this discussion and development.

After a possible decision to include xturtle into Python, which 
certainly should take place before the first beta release, there would 
be enough time to polish the documentation and to fix bugs. For their 
discovery it would certainly be an advantage to put it in some 
prerelease as early as possible.

Of course I know that xturtle is only a side issue in the current 
development efforts. Unfortunately I'm not familiar with the procedures 
needed to get a new module into Python, so I kindly ask you for your 
advice how to proceed, at the same time offering my cooperation.

With best regards

Gregor Lingl

Guido van Rossum schrieb:
> Python 3.0 and 2.6 are coming along really nice. I am optimistic that
> we can make the projected August date for the final releases of 2.6
> and 3.0. As you may remember, Barry (the new release manager for both)
> suggested that we synchronize releases of 2.6 and 3.0. Not only could
> this potentially save the release manager and his assistants some
> time, doing the final releases together sends a clear signal to the
> community that both versions will receive equal support.
>
> However, looking at the calendar, I think we need to do a little more
> planning and management than we've typically done for Python releases.
> A final release in August means that we should plan to release a first
> beta in June and a second one in July. That means we have time for
> only two more alpha releases (April and May). I'm thinking of 1-2
> release candidates 1-2 weeks ahead of the final release. Barry can
> make up a more detailed timetable. I'm fine with some slippage
> (especially if planned ahead) of individual releases due to
> availability of release personnel; but I don't want to be held up by
> features or bugs unless they are of absolutely dramatic show-stopping
> nature.
>
> In order to make such a tight release schedule we should try to come
> up with a list of tasks that need to be done, and prioritize them.
> This should include documentation, and supporting tools like 2to3. It
> should include features, backports of features, cleanup, bugs, and
> whatever else needs to be done (e.g. bugbot maintenance).
>
> In the past we've used shared spreadsheets in Google for this purpose,
> but seeing that these haven't been updated in ages, I'm skeptical that
> they are a sufficient tool. In my day job at Google we've started to
> do all task management for our project in the bug tracker (but that
> tracker has some features that make it particularly easy). Does anyone
> have a suggestion for an online open shared task management system
> that we cold adopt? Or should we bite the bullet and put everything in
> the bug tracker? Other suggestions? Anything's better than just
> email...
>
> PS. I realize that I've been rather absent from the day to day
> activities in the Python 3000 world lately. This is a temporary
> condition due to an important impending launch in my day job; I expect
> to have much more time for Python again starting in April.
>
>   
___
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

[Python-Dev] IDLE - firewall warning

[Gregor Lingl]

I have posted the following message to idle-dev,
but no reply yet. Just a suggestion:

The firewall warning message in the Pythonshell window
was introduced  in Python 2.3 (IDLE 1.0 or something similar?)

I remember well the problems, to which it was the answer. 
(If I remember correctly I was involved in the discussion 
thread which led to the introduction of that message.)

Since more than three years I've used IDLE on many different
systems and I didn't encounter a single Firewall warning since
then. (It seems that firewalls nowadays are not offended by
the use of 127.0.0.1)

Therefore, and because the message is long and ugly, I'd like to
suggest to delete it from the Python Shell window
and - if considered necessary - for instance to put
it into the IDLE Help - "About IDLE" submenu or
in a special IDLE-Firewall warning submenu of IDLE-Help.

Please observe that it pops up thousands of times and it's
read at most once.

Or perhaps a single-line message like
=== subprocesses use internal loopback interface ===
would do it, just to signal where you are as does the
respective line  in  -n mode.?


Regards,
Gregor Lingl


___
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]

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]

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!

[Gregor Lingl]

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

Re: [Python-Dev] xturtle.py a replacement for turtle.py(!?)

[Gregor Lingl]

Josiah Carlson schrieb:
> Gregor Lingl <[EMAIL PROTECTED]> wrote:
>   
>> 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
>  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
>
>
>
>   

___
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(!?)

[Gregor Lingl]

Anthony Baxter schrieb:
> On Wednesday 28 June 2006 20:57, Gregor Lingl wrote:
>   
>> 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
 

___
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

[Python-Dev] Oh-why that?? Please ignore one of the two

[Gregor Lingl]

Sorry (dunno why)
Gregor
___
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

[Python-Dev] xturtle.py - a replacement for turtle.py

[Gregor Lingl]

xturtle.py, extended turtle graphics
is a new Tkinter based turtle graphics module for Python

xturtle.py (Version 0.91) can be found at:

http://sourceforge.net/tracker/?group_id=5470&atid=305470
(Request ID 1513695, and 1513699 for the docs)

and at

http://ada.rg16.asn-wien.ac.at/~python/xturtle
together with a set of example scripts and a demoViewer

xturtle was first announced at edu-sig and is reported to 
work properly on all major platforms (Mac, Linux and
Windows) I propose to use it as a replacement for turtle.py

It was suggested to me to discuss it on this list.  So I'll try that.

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

(I) xturtle.py is a reimplementation of turtle.py, retaining 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 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). # Commands for controlling background 
color or background image.

(II) Motives: My goal was to provide utmost easy access to a 
sufficiently rich graphics toolkit. I consider this of crucial 
importance for students and teachers who, e. g., have to decide which 
language to use for introductory programming courses. Moreover I 
consider turtle graphics as an excellent tool to visualize programming 
concept. So I already used the current turtle.py as a central tool in 
the first edition of my book "Python für Kids", despite of its apparent 
deficiencies.

Now I propose an alternative: xturtle.py. You will best understand my 
intentions by having a look at the 25+ demo scripts using the 
accompanying demoViewer, which are provided with turtle.zip at the above 
mentioned website. (I do not propose to include these into the standard 
distribution. Perhaps they could go into some special edudistro as Kirby 
Urner suggested lately)

I would appreciate it very much if xturtle.py could go into Python2.5. 
I'm ready to do the amendments, which may emerge as necessary from the 
dicussion here.

Regards,
Gregor Lingl




___
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

[Python-Dev] xturtle.py a replacement for turtle.py(!?)

[Gregor Lingl]

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

___
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