[issue10199] Move Demo/turtle under Lib/
Gregor Lingl added the comment:
First of all: I'd not like to see turtle.py converted into a package. I think
with the turtle module things should be as simple as possible and I don't see
any need to put approx. 100kB of code into an __init__.py and be it only
because there are hundreds of them and on cannot see from the name what's in
there. I do not expect the avarage turtle user to look at the code, but
certainly some teachers and instructors do even if they are not python
specialists accustomed to the use of packages.
As far as I understood from the discussion the MAIN POINT is to make the
turtleDemo accessible as easyly as possible.
So at first this needs a decision to put the demo code into the
Windows-Distribution.
The next question is where to put it. In my opinion there are two possibilities.
1) The one mentioned by Alexander in msg119612: a turtledemo directory in Lib.
2) To put a turtledemo directory into the Tools directory (in some sense the
demoViewer is sort of a tool, isn't it.)
I quickly prepared a 'prototypical' collection with a modified viewer, which
accounts for some of the arguments which came up in the current discussion. It
contains a turtledemo package. Please download it and have a look.
Each demo can be run by doubleclicking, as a standalone script, as well as from
the turtledemo.viewer
If from the above options 1) were chosen or the package is somewhere else in
the search path, on can - at the interactive prompt - do things like:
>>> from turtledemo import bytedesign
>>> bytedesign.main()
and also:
>>> from turtledemo import viewer
>>> viewer.run()
Morover one can load the examples into Idle and start them via the run-command.
So one has a look at the code and moreover the possibility to make changes and
try out, what happens.
I have renamed the sample scripts, omitting the tdemo_ - prefix, as
this looks nicer (at least for me). The previous version turtleDemo recognized
scripts with this suffix as belonging to the demo-suite and
added it to the examples menu. This was necessary because of a script, which
cannot be demonstrated in the demo_viewer (two canvases). I changed this in my
proposition in the following way: scripts that are in the demodirectory and
should not appear in the DemoViewer's example-Menu, should end with _.py or
some other extension.
To make the demo_viewer importable creates a special problem: the demos are
imported by the demoViewer via the __import__ function, so everyone can add his
own demos to the demo-directory and they will show up in the viewer. The
original version (and even this one) can do this also for demos in
subdirectories when started directly. (I've included as an example the geometry
directory). This does't work yet for importing the viewer, I only provided a
very clumsy quick and dirty solution and I hope that someone has a better, more
bright idea to do this more elegantly and correctly.
Now for something completely different: how to make it easily accessible.
1) Put remarks (and links) into the documentation, near the head of the turtle
module's docs. (Referring to 24.5.7)
2) Put a hint into the commentary/docstring of the file turtle.py itself.
3) I do not consider it a good idea to put the viewer.py into the
if __name__ == "__main__" - part of turtle.py thus replacing the current demo.
I think this part should demonstrate the possibilities of the module without
recurring to extra use of Tkinter (as the demo viewer does). (I must also
confess, that the quality of the code of the viewer, which I programmed back in
2006, does not reach the standards I tried to achieve for turtle.py)
4) BUT I'd find it useful to change this final demo code of turtle.py, so it -
in the end - displays a message where to find more demos (i. e. turtledemo) or
even to put there a question like ("Do you want to see more demos?") and two
"turtle-generated" "buttons": "YES" and "NO". If one chooses "Yes", the
turtledemo.viewer would pop up in a separate process.
Please consider this to be a proposal or a contribution. I'm very interested in
discussing it further and bringing it to a quick and easy solution for Python
3.2. Unfortunately I'm currently involved in a project (also python-related)
with very severe time constraints for the next four to five month. So ideas for
enhancing the demoviewer and probably turtle.py have to wait until then and
possibly will be an issue for Python 3.3
Best regards,
Gregor
--
Added file: http://bugs.python.org/file19380/turtledemo32.zip
___
Python tracker
<http://bugs.python.org/issue10199>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10199] Move Demo/turtle under Lib/
Gregor Lingl added the comment: Imho it is very important to clarify the name convention for demoscripts to be added to the demo before committing (or at least before the apperance of beta1). It decides about adding scripts to the Examples Menu of the viewer. We all know, that things once they have found their way into Lib cannot be changed easily afterwards. Guidos argument on backwards compatibility applies. So now is the only point in time to decide about this. Should we - stick with the tdemo_ prefix or - change to another pre- or postfix (like eg. bytedesign_demo) - or should we allow for arbitrary *.py filenames with some exception (e.g. filenames that contain an underscore) to mark files that are not meant as demos for the viewer? Please note that there are other constraints also for demo_files anyway, like the size of the graphics window and the presence of a main()-function to be called by the viewer. I'd like this to be decided actively. What do you think? Best regards, Gregor -- ___ Python tracker <http://bugs.python.org/issue10199> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7061] Improve 24.5. turtle doc
Gregor Lingl added the comment: What do you mean with "similar approach"? Keep in mind, that functions derived form turtle methods, call methods for the class variable _pen of class Turtle. A new Turtle-object is bound to _pen, if it is not already present, whenever one of these functions is called, via _getpen() So perhaps _getpen() can do for you what you need? (A similar approach is used for screen-oriented functions with turtle._screen.) I'm very sorry that, due to time restrictions, for the next two or three months I'm not able to participate in these discussions as intensely as I'd like to. Best regards, Gregor -- ___ Python tracker <http://bugs.python.org/issue7061> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7124] idle.py -n : help() doesn't work in a reopened shell window
Gregor Lingl added the comment: Right. I cannot replicate this bug even with an IDLE from Python 3.2. So it seems to me, that this problem has been solved. Regards, Gregor -- ___ Python tracker <http://bugs.python.org/issue7124> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1513695] new turtle module
Gregor Lingl <[EMAIL PROTECTED]> added the comment: Hi, here is my contribution. The zip-file contains - the module turtle.py - a doc-file turtle-docs.txt - a subdirectory with a series of sample scripts and a demoviewer. (one of the demoscripts is a standalone script) Clearly the docs have to be transformed to reST. I would do it or participate but that certainly would only be ready within 2 or 3 weeks. The end of the school year is near and I have a huge amount of work in my school until approx. 20th of June. After this I have plenty of time also for correcting etc. Of course I'll also do bugfixes etc. Anyway I'm interested in feedback of any sort. I worked hard to do my best and I hope the result will be appreciated. Best regards, Gregor Added file: http://bugs.python.org/file10493/turtle.zip ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1513695> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1513695] new turtle module
Gregor Lingl <[EMAIL PROTECTED]> added the comment: I'd like to propose a few modifications of turtle.py for the transition from Python 2.6 to Python 3.0, which would result in a cleaner interface but also in some - i think marginal - incompatibiliy: 1) drop from math import * 2) delete the methods Turtle.window_width() and Turtle.indow_height() (They are mereley transferred from Screen to Turtle and are imho generic Screen.methods. So they will still be present as Screen methods and as functions. In fact this proposition has a didactic background - on should teach to differentiate between Screen- and Turtle-methods as belonging to two completely different types of objects, and the only realistic reply to the student's question "Why do Turtle objects have a window_width() method would be: "for historical reasons!" When, if not now, is time to make changes like this?) 3) The same is valid for Turtle.tracer() as tracer controls in fact Screen-updates and not Turtle updates. (The only difference is, that Turtle.tracer cannot be deleted, because it's (currently) used in turtle.circle(), so I'd propose to rename it to Turtle._tracer() and so delete it from the public interface. Of course tracer() will also remain present als Screen-method and as function. Pros and cons? I have prepared a file with these changes which could be used for porting it to Python3.0. So if everybody agrees, I could upload it. Regards, Gregor ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1513695> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1513695] new turtle module
Gregor Lingl <[EMAIL PROTECTED]> added the comment: In my last posting i forgot a fourth proposition. Currently one has the Turtle.methods fill(), begin_fill() and end_fill() As is stated in the old turtle docs the specification of fill is "rather complex". begin_fill() and end_fill(), are identical to fill(True) and fill(False) (or fill(1) and fill(0)). That means, that begin_fill() sometimes may do somthing unexpected, namely complete som filling underway. In the new turtle module fill() without arguments returns the filling state, i. e. True/False respectively. I'd prefer the following: begin_fill() should only start a new filling process and cancel some underway, if necessary (that means: a filling without end_fill will not take place) end_fill() should only complete the current filling process a new method filling() should be used to ask if same filling is currently taking place and fill() could be dropped. (deprecated in 2.6) I think Vern Ceders intention with introducing begin_fill and end_fill was to have a clear and easily understandable meaning, which is only partially accomplished with the current solution. What is your opinion? Gregor ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1513695> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3064] new turtle module for Python 3.0
New submission from Gregor Lingl <[EMAIL PROTECTED]>: turtle3.zip contains the port of the new turtle module (including demo viewer and demo scripts) to Python 3.0 . One demo script has been added (tdemo_forest.py) It has been tested under Windows/MacOsX/Linux without showing up any problems. I've done a few small changes to the API - as proposed in issue 1513695 - which are described in the docfile. Gregor Lingl -- components: Tkinter files: turtle3.zip messages: 67852 nosy: gregorlingl, loewis severity: normal status: open title: new turtle module for Python 3.0 type: feature request versions: Python 3.0 Added file: http://bugs.python.org/file10557/turtle3.zip ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3064> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3064] new turtle module for Python 3.0
Gregor Lingl <[EMAIL PROTECTED]> added the comment: Here is the (slightly) modified docfile in rst-format for the new turtle module for Python 3.0 I'll submit the diff (from the turtle.rst for Python 2.6) in a follow up posting for your convenience. So you can easily check the few differences - as well as if I have used reST correctly. Regards, Gregor Added file: http://bugs.python.org/file10563/turtle30.rst ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3064> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3064] new turtle module for Python 3.0
Gregor Lingl <[EMAIL PROTECTED]> added the comment: And here the diff from docfile turtle.rst to what I have named turtle30.rst for now. Gregor -- keywords: +patch Added file: http://bugs.python.org/file10564/turtle.rst.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3064> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3884] turtle in the tkinter package?
Gregor Lingl <[EMAIL PROTECTED]> added the comment: Of course I highly appreciate this decision. I'd like to point you to an urgent issue concerning turtle.py which needs a decision and which I've just posted to Python-dev Regards, Gregor ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3884> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3940] turtle.py - minor bugfixes
New submission from Gregor Lingl <[EMAIL PROTECTED]>: Thorough testing revealesd the following bugs in turtle.py (Python 2.6): 1) Around lines 359 and 379: There's a name conflict with a methodname of the parentclass Frame: _root. The bugfix consists in renaming this attribute, which occurs only twice 2) Around line 732: Turtles with image-shapes do not recognize user coordinates. This is fixed in TurtleScreenBase method _drawimage by introducing the corresponding scaling factors 3) Around line 3570: Calling the __init__ - Method of the Screen-class (which uses the Borg idiom) destroys graphics and Turtles on the Screen. This is an undesired behaviour. The fix brings the behaviour of Screen in accordance with the Python 3.0 version. 4) Around line 3612: Screen.setup() needs a final update() call in order to ensure, that immediately following calls of window_width() or window_height() return correct values. Moreover there is a correction of the version number and date Bugfixes are attached in turtle.py.diff Regards, Gregor -- components: Library (Lib) files: turtle.py.diff keywords: patch messages: 73607 nosy: gregorlingl severity: normal status: open title: turtle.py - minor bugfixes type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file11565/turtle.py.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3940> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3940] turtle.py - minor bugfixes
Gregor Lingl <[EMAIL PROTECTED]> added the comment: The bugfix for bug 3) described above makes necessary the insertion of a line in turtleDemo.py (around line 96) Again I've attached the corresponding diff file Added file: http://bugs.python.org/file11566/turtleDemo.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3940> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3941] Help in IDLE doesn't work correctly
New submission from Gregor Lingl <[EMAIL PROTECTED]>: >From IDLE either pressing F1 or choosing the menu Help-Python Docs should open a Help-Window with the docs of the current version. (This works well for instance in Python 2.5.2) The docs file normally resides on the local computer in the Doc directory (at least under Windows) With 2.6rc2 under Windows pressing F1 only opens a Browser with the url http://www.python.org/doc/current/ which leads to the 2.5.2 documentation. It should be linked to the python26.chm file in the Doc directory Regards, Gregor -- components: IDLE messages: 73609 nosy: gregorlingl severity: normal status: open title: Help in IDLE doesn't work correctly type: behavior versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3941> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3950] turtle.py: bug in TurtleScreenBase._drawimage
New submission from Gregor Lingl <[EMAIL PROTECTED]>: In the first line of TurtleScreenBase._drawimage() there are to scalefactors missing. This leads to the annoying fact, that the drawings and the movement of a turtle which has an image shape differ. This is shown in the short script _drawimage_bug_fix-test.py which I'll submit immediately. (You have to have huhn.gif in the same directory as the script.) After applying the bugfix submitted in _drawimage_patch.diff this annoying behaviour goes away. It is really an ambarassing and easy to fix bug. Regards, Gregor -- files: _drawimage-patch.diff keywords: patch messages: 73673 nosy: gregorlingl, loewis severity: normal status: open title: turtle.py: bug in TurtleScreenBase._drawimage Added file: http://bugs.python.org/file11578/_drawimage-patch.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3950> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3950] turtle.py: bug in TurtleScreenBase._drawimage
Changes by Gregor Lingl <[EMAIL PROTECTED]>: -- type: -> behavior versions: +Python 2.6 Added file: http://bugs.python.org/file11579/_drawimage_bug_fix_test.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3950> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3950] turtle.py: bug in TurtleScreenBase._drawimage
Changes by Gregor Lingl <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file11580/huhn.gif ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3950> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3956] turtle.py - bug in Screen.__init__()
New submission from Gregor Lingl <[EMAIL PROTECTED]>: There is a bug in Screen.__init__() (The Screen class uses the Borg idiom to simulate a Singleton). This bug is demonstrated best interactively from IDLE (using the -n switch) like this: >>> from turtle import Screen, Turtle >>> t = Turtle() >>> t.fd(100) # idea: let's have a yellow background, so we need # *the* screen >>> s = Screen() # the drawing vanishes >>> s.turtles() [] This is undesired behaviour. Instead the Screen() call should leave the drawings an the turtles untouched and return the already existing Screen. So the call of turtles() would result in something like: >>> s.turtles() [] This is accomplished by the patch described in the attached file turtle.diff Of course sequences of commands like those shown in the interactive session above do not occur in well designed scripts, but they may well occur during sessions of students in interactive classroom use. Two more important notes: (1) This patch is already done in turtle.py for Python 3.0. So in 2.6 it would ensure that Turtles and the Screen show identical behaviour in both versions. (2) This patch makes necessary one other patch in turtleDemo.py - in the Demo directory - which is shown in the attached turtleDemo.diff turtleDemo.py is not a normal turtle application but a GUI - utility designed to run a series of 'normal' turtle - apps conforming to some simple rules (These apps in most cases use a Screen()). So when switching from one to another demo script within turtleDemo one wants to reinitialize the Canvas - what is just the contrary of what one wants normally as explained above. This is accomplished by this patch of turtleDemo.py. (This patch is also already done for Python 3.0) -- files: turtle.diff keywords: patch messages: 73712 nosy: benjamin.peterson, gregorlingl, loewis severity: normal status: open title: turtle.py - bug in Screen.__init__() type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file11591/turtle.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3956> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3956] turtle.py - bug in Screen.__init__()
Gregor Lingl <[EMAIL PROTECTED]> added the comment: Do the patch of turtleDemo.py if and only if the patch of turtle.py is accepted. Added file: http://bugs.python.org/file11592/turtleDemo.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3956> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3956] turtle.py - bug in Screen.__init__()
Gregor Lingl <[EMAIL PROTECTED]> added the comment:
First of all I'd like to point you at a posting which I posted to
Python-dev on August 18th, where I addressed this issue in full detail.
http://mail.python.org/pipermail/python-dev/2008-August/081846.html
I hoped to provoke a clarifying discussion but I have to complain, that
I didn't succeed with this probably because many people were on vacation
at this time.
The only substantial reply I got was by Vern Ceder, a turtle graphics
veteran who contributed a lot to the old turtle module. He wrote:
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
The design decision to use a singleton is of interest only for
interactive use. (A well designed Script uses at most one Screen() call
at the beginning. So that is no issue.)
I'll demonstrate here in a short interactive session (which you can
reproduce using IDLE with the -n switch as usual), why the solution
Martin proposes doesn't meet the requirements I tried to accomplish with
my code. This session 'simulates' a student curiously playing around and
experimenting with *the* Screen():
>>> from turtle import Screen, Turtle
>>> class YellowScreen(Screen):
def __init__(self):
Screen.__init__(self)
self.bgcolor("yellow")
>>> s = YellowScreen()
>>> t = Turtle()
>>> for i in range(10):
t.fd(50)
t.lt(36)
>>> s1 = Screen()
>>> s1.bgcolor("pink")
>>> s = YellowScreen()
>>> s1.bgcolor()
'yellow'
>>> s1.turtles()
[]
>>> class TextScreen(Screen):
def __init__(self):
Screen.__init__(self)
self. writer = Turtle(visible=False)
self.writer.pu()
def writeAt(self, x, y, txt):
self.writer.goto(x,y)
self.writer.write(txt)
>>> s = TextScreen()
>>> s.writeAt(0, -200, "Read me ...")
>>> s.turtles()
[, ]
>>> s.writer
>>> class RedScreen(Screen):
def __init__(self):
Screen .__init__(self)
self.bgcolor(1, 0.5, 0.5)
>>> u = RedScreen()
>>> u.writeAt(0,200, "Read me too")# should fail!
Traceback (most recent call last):
File "", line 1, in
u.writeAt(0,200, "Read me too")
AttributeError: 'RedScreen' object has no attribute 'writeAt'
>>> u = TextScreen()
>>> u.writeAt(0,200, "Read me too")
>>> u.turtles() # at this point for the first time occurs an
# unfavorable consequence of what Martin called a
# 'design bug', namely a turtle in the turtles() list
# which is not used any more.
[, , ]
>>> u.writer
>>> s.writer
# We want a fresh screen ...
>>> s.clear()
>>> s.turtles()
[]
So there occurres this and possibly some more somewhat weird elements,
presumably a result of using the Singleton pattern which is especially
controversial in combination with inheritance. Nevertheless I decisively
propose to accept this behaviour in order to be able do things like the
ones demonstrated above. Morover I also consider it to be a benefit to
use spezialized and/or reusable screens derived from the Screen() class
in scripts, what would not be possible with a Screen()-function
returning *the* single _Screen() object. (All this meant in the context
of teaching and learning OOP).
Now for the additional questions of Martin:
Yes, the second if statement is superfluous. It looks like to be a
remain from Pen.__init__ from the old turtle module, where - in contrast
- it was not superfluous. My fault. It could be removed, but it doesn't
do harm. (The overwhelming part of the module is *re*written but it
still contains (in this case regrettably) quite some traces of the old
module.) And also the assignement of self to Turtle._screen in the last
line could be put into the if-statement-body. But somehow I seem to have
felt that a conditionally empty body of __init__() looks dangerous - or
at least not nice. More seriously taken, the Borg idiom ensures the
creation of new instances (with different id), sharing state and
behaviour and I somehow felt it to be better to have the last created
instance in Turtle._screen (whereas in fact this is of no importance).
My preliminary conclusion: as I'm not a professional programmer but a
teacher I can't judge the importance of observing the design
principle mentioned by Martin. (I know the principle, I normally observe
it and conside
[issue3968] fill() and end_fill() do not work correctly
New submission from Gregor Lingl <[EMAIL PROTECTED]>: fill() and end_fill() do not work as expected. As a user on the tutor list 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. This is due to a missing update() call in the RawPen.fill() method A patch is attached Regards, Gregor -- components: Tkinter files: 2.5turtle_fillpatch.diff keywords: patch messages: 73825 nosy: gregorlingl severity: normal status: open title: fill() and end_fill() do not work correctly type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file11604/2.5turtle_fillpatch.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3968> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3969] turtle.py - setup() doesn't work correctly
New submission from Gregor Lingl <[EMAIL PROTECTED]>: setup() doesn't work correctly: startx argument is not recognized This is due to a typo in the setup() function A patch is attached. Regards, Gregor -- components: Tkinter files: 2.5turtle_setup_patch.diff keywords: patch messages: 73826 nosy: gregorlingl severity: normal status: open title: turtle.py - setup() doesn't work correctly type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file11605/2.5turtle_setup_patch.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3969> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3968] turtle.py: fill() and end_fill() do not work correctly
Changes by Gregor Lingl <[EMAIL PROTECTED]>: -- title: fill() and end_fill() do not work correctly -> turtle.py: fill() and end_fill() do not work correctly ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3968> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3941] Help in IDLE should open the chm file
Gregor Lingl <[EMAIL PROTECTED]> added the comment: I just found out, that this doesn't work correctly, because the Windows-helpfile in Python26rc2 is strangely named Python26c2.chm . It works correctly however if one renames this file to Python26.chm (as this is what the code in EditorWindow.py expects). So this will (almost certainly) be no problem in the final release. Regards, Gregor ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3941> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3956] turtle.py - bug in Screen.__init__()
Gregor Lingl <[EMAIL PROTECTED]> added the comment: I agree to Martin's patch for 2.6, because it seems to provide a more clean solution. And, as he states, there will be time and opportunity to discuss it more thoroughly later to possibly find another approach. As I remarked before I know that singleton+inheritance is a controversial subject. However the gang of four state in their book that one should use the singleton design pattern if one needs exactly one instance af a class and this should be extensible by subclassing ... (And there are reasons why I'd like to have Screen() subclassable.) Anyway, I think there are two more things to do: 1) Add a docstring to the Screen() function 2) Insert (at least) one sentence in the docs, 9.th paragraph of the Introduction. Something like: ... so there can exist only one instance of Screen at a time. *Notice that consequently Screen cannot be sublassed.* It should be used when turtle is used as a standalone tool for doing graphics. ... Perhaps one should also note, that the singleton object is returned by a function. I've applied the proposed patch (file11645) to a working copy and I've tested it in interactive mode as well as with turtleDemo and all the supplied demoscripts and found it to work well. Last, but not least: thanks Martin for your contribution. Regards, Gregor ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3956> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3956] turtle.py - bug in Screen.__init__()
Gregor Lingl <[EMAIL PROTECTED]> added the comment: Agreeing to this patch, I'd just like to mention, that nevertheless this change is not very pleasing for me. Not feeling that singleton with inheritance is a 'meaningless' but rather a 'very special' concept,the meaning of which could be explained, I've used this concept in the last chapter of my book "Python for Kids" designing sort of a GameScreen class derived from Screen(). Hmmm. So sthis seems to remain sort of a unique selling point of xturtle for now. And in the 4th edition I can certainly adapt this chapter. When 2.6 is out, what do you think is the right point for a further discussion of this? (I think certainly not the bugtracker and particularly not this issue. Regards, Gregor ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3956> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3956] turtle.py - bug in Screen.__init__()
Gregor Lingl <[EMAIL PROTECTED]> added the comment: ... I meant: the right place for a further discussion Sorry, Gregor ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3956> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8615] turtle.py - backport of 3.1 features
New submission from Gregor Lingl : The file submitted, turtle.py, essentially contains a backport of the new features, which were added to the turtle module with Python 3.1. Otherwise this versions is 100% compatible with the turtle module of Python 2.6. So scripts written with Python 3.1's turtle module will run unchanged with identical behaviour under Python 2.7. The same do - of course - scripts written with Python 2.6's version of the turtle module. Remark: There were also some enhancements and cleanup in the code for Python 3.1, which I also did backport to this version. Inclusion of this version of turtle.py into Python 2.7 will need an update of the docs (essentially to those of Python 3.1). I'll be able to submit an appropriate *.rst file within a week or so. -- components: Library (Lib) files: turtle.py messages: 104975 nosy: georg.brandl, gregorlingl, loewis priority: normal severity: normal status: open title: turtle.py - backport of 3.1 features type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file17206/turtle.py ___ Python tracker <http://bugs.python.org/issue8615> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8615] turtle.py - backport of 3.1 features
Gregor Lingl added the comment: Here, just for your information, the appropriate unified diff (from the version in 2.7b1 to the new submitted one. -- keywords: +patch Added file: http://bugs.python.org/file17207/turtle27b1_to_turtle27.diff ___ Python tracker <http://bugs.python.org/issue8615> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8616] Changes to content of Demo/turtle
New submission from Gregor Lingl : turtleDemo.py contains a string referring to the outdated xturtle. Should be replaced according to the submitted diff. Moreover I'd like to propose to add to demo-scripts to the Demo-directory, namely tdemo_nim.py and tdemo_round_dance.py as well as to replace the old tdemo_paint.py by the enhanced version tdemo_scribble.py. I'll add those files subsequently. Regards, Gregor -- components: Demos and Tools files: turtleDemo_27b1_to_turtleDemo.diff keywords: patch messages: 104977 nosy: georg.brandl, gregorlingl, loewis priority: normal severity: normal status: open title: Changes to content of Demo/turtle versions: Python 2.7 Added file: http://bugs.python.org/file17208/turtleDemo_27b1_to_turtleDemo.diff ___ Python tracker <http://bugs.python.org/issue8616> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8616] Changes to content of Demo/turtle
Changes by Gregor Lingl : Added file: http://bugs.python.org/file17209/tdemo_nim.py ___ Python tracker <http://bugs.python.org/issue8616> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8616] Changes to content of Demo/turtle
Changes by Gregor Lingl : Added file: http://bugs.python.org/file17210/tdemo_round_dance.py ___ Python tracker <http://bugs.python.org/issue8616> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8616] Changes to content of Demo/turtle
Changes by Gregor Lingl : Added file: http://bugs.python.org/file17211/tdemo_scribble.py ___ Python tracker <http://bugs.python.org/issue8616> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8615] turtle.py - backport of 3.1 features
Gregor Lingl added the comment: As far as I remember, in the past there was a feature - freeze only with the appearance of beta2? Maybe I'm wrong. So there remains only to try to interpret the term "new feature" appropriately, as all those features are already present in Python 3.1. If there are serious objections against adopting it, I'll accept them of course. I just wanted to serve the community with making Python 2.7 more similar to Python 3.1 Regards, Gregor -- ___ Python tracker <http://bugs.python.org/issue8615> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8615] turtle.py - backport of 3.1 features
Gregor Lingl added the comment: I see, that Benjamin Peterson, the release manager, is on the nosy list now. So please decide on this issue. If you need any supplementary information, I'll try to provide it. (The issue concerning the adoption of this version of the turtle module for Python 3.1 can be found here: http://bugs.python.org/issue5923) Regards, Gregor -- ___ Python tracker <http://bugs.python.org/issue8615> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1513695] new turtle module
Gregor Lingl <[EMAIL PROTECTED]> added the comment: This version runs under Python 2.5 and should run under python 2.6 It still needs some amendments and polishing concerning the code as well as the docstrings. Here it can serve as a starting point for a discussion about necessary and/or desirable modifications. A version for Python-3000 is under construction For the new features please consult xturtle-docs. Remarks on Martin's 10 points (msg 50550): 1) Should be discussed. I think a few demos would be fine, the whole package perhaps would be to large. (I'll prepare a selection and upload it in due time) 2) decision about replacement or supllement has still to be done. This update will be easy ;-) 3) Who is that somebody? 4) Still has to be done 5) I for my part don't like Point, because this name refers more to the geometrical than to the computational aspects of the object. What about _Vec2 or _Vec2D? In this version an alias without the leading underscore can be created via an entry in the xturtle.cfg file. 6) camelCase methodnames are changed to lowercase (at least the public ones) 7) Docstrings has still to be checked 8) n argument of clear has been dropped. 9) checkargs has been dropped (for now). It's purpose was intended to be to check the types of the arguments and construct appropriate error messages useful for programming beginners. I deferred it until I eventually be able to come up with some intelligent solution using decorators ;-) Would be fine but is not urgent. 10) Maybe there are still a few. These will be changed. -- nosy: +glingl versions: +Python 2.6 -Python 2.4 Added file: http://bugs.python.org/file9693/xturtle.py _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1513695> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1513695] new turtle module
Changes by Gregor Lingl <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file9694/xturtle-docs.txt _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1513695> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1513695] new turtle module
Gregor Lingl <[EMAIL PROTECTED]> added the comment: If you put (this example of) xturtle.cfg either into the directory where xturtle.py resides or into the current working directory, the configuration will be loaded. In this case window size and turtle are configured to look like in module turtle. If no config-file is found a standard configuration is used. (This standard configuration currently uses a scrolled canvas but could of course be changed to look like that furnished by the above cfg-file.) Added file: http://bugs.python.org/file9695/xturtle.cfg _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1513695> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1513695] new turtle module
Changes by Gregor Lingl <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file9715/whatsnew.txt _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1513695> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1513695] new turtle module
Gregor Lingl <[EMAIL PROTECTED]> added the comment: Supplementary remark: xturtle has proved to run without problems under Python 2.6. (Not surprisingly) it's behaviour is exactly like under Python 2.5, with the exception, that the tested scripts run 5 to 15% faster. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1513695> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4116] name conflict in ScrolledCanvas.__init__() in Lib/turtle.py
New submission from Gregor Lingl <[EMAIL PROTECTED]>: In ScrolledCanvas.__init__() there's a name conflict with a methodname of the parentclass Frame: _root. The bugfix consists in renaming this attribute, which occurs only twice. No change in behaviour at all. Regards, Gregor -- components: Library (Lib) files: ScrolledCanvas.__init__.diff keywords: patch messages: 74709 nosy: gregorlingl, loewis severity: normal status: open title: name conflict in ScrolledCanvas.__init__() in Lib/turtle.py versions: Python 3.0 Added file: http://bugs.python.org/file11776/ScrolledCanvas.__init__.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4116> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4117] missing update() in _Screen.setup() of Lib/turtle.py
New submission from Gregor Lingl <[EMAIL PROTECTED]>: In Lib/turtle.py _Screen.setup() needs a final update() call in order to ensure, that immediately following calls of window_width() or window_height() return correct values. Consequently the setup() method call in _Screen.__init__() has to take place only after the call of TurtleScreen.__init__() -- components: Library (Lib) files: _Screen.setup.diff keywords: patch messages: 74710 nosy: gregorlingl, loewis severity: normal status: open title: missing update() in _Screen.setup() of Lib/turtle.py type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file11777/_Screen.setup.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4117> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4116] name conflict in ScrolledCanvas.__init__() in Lib/turtle.py
Gregor Lingl <[EMAIL PROTECTED]> added the comment: This patch applies to Python 2.6 as well Gregor -- versions: +Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4116> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4117] missing update() in _Screen.setup() of Lib/turtle.py
Gregor Lingl <[EMAIL PROTECTED]> added the comment: This patch applies to Python 2.6 as well Gregor -- versions: +Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4117> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4116] name conflict in ScrolledCanvas.__init__() in Lib/turtle.py
Gregor Lingl <[EMAIL PROTECTED]> added the comment: I'd like to see this patch accepted and done for Python 2.6.1 and (at the same time) python 3.0 before the last rc is released. So could you dedicate a few minutes to reviewing it. To demonstrate the nature of this issue (and also the nuisance it could produce) I've constructed a minimal example to show the consequences of the bug: import turtle s = turtle.Screen() def changecolor(): s.bgcolor(1.0, 0.5) # needs 3 floats as arguments s.ontimer(changecolor, 1000) turtle.mainloop() This should create an error message like this: TurtleGraphicsError: bad color arguments: (100, 100) Instead it results in: Traceback (most recent call last): File "C:\_\provoke_error.py", line 11, in turtle.mainloop() File "C:\Python26\lib\lib-tk\Tkinter.py", line 325, in mainloop _default_root.tk.mainloop(n) File "C:\Python26\lib\lib-tk\Tkinter.py", line 1414, in __call__ self.widget._report_exception() File "C:\Python26\lib\lib-tk\Tkinter.py", line 1175, in _report_exception root = self._root() AttributeError: _Root instance has no __call__ method because the _root() method defined in line 1105 of Tkinter.py is overwritten by the _root attribute of ScrolledCanvas (lines 362 and 382). So in these (hopefully rare) cases where an error message is directly provoked from the Tkinter module, this will fail letting the user without clue about what happened. With the proposed patch applied, the above script produces the correct error message. Regards, Gregor ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4116> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4117] missing update() in _Screen.setup() of Lib/turtle.py
Gregor Lingl <[EMAIL PROTECTED]> added the comment: I'd also like to see this patch accepted and done for Python 2.6.1 and (at the same time) python 3.0 before the last rc is released. So perhaps you could you dedicate a few minutes to this one also. Thanks for your efforts, Gregor ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4117> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4117] missing update() in _Screen.setup() of Lib/turtle.py
Gregor Lingl <[EMAIL PROTECTED]> added the comment: I cannot call the Canvas method _update_idletasks() from within _Screen.setup() becaus this would contradict to the architecture of the module which isolates all direct references to Tkinter to TurtleScreenBase. (The idea behind this is to make the module easily portable, by porting only this class). So if one followed your proposition one had to change TurtleScreenBase which would result in a different (additional) patch. For now I'd like to stick with the one proposed here - I worked a lot with it, it works and I didn't experience unwanted side effects. My question: I suppose to change the call self.cv.update() to self.cv.update_idletasks() in TurtleScreenBase._update wouldn't work properly so one had to add a new method to TurtleScreenBase - something like TurtleScreenBase._update_idletasks. Originally I had the intention to keep this interface as small as possible and use only things that are really needed. Did you experience any problems or undesired behaviour because of using unly cv.update? If so, please report it. Perhaps you could also provide an example. Regards, Gregor ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4117> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4117] missing update() in _Screen.setup() of Lib/turtle.py
Gregor Lingl <[EMAIL PROTECTED]> added the comment: > > I find that desire misguided; this is (IMO) a case of false abstraction. > > Is there any kind of proof that this design actually > > works, i.e. can be ported to a different GUI library (like, say, > > PythonWin? or AWT, when run in Jython?) Yes there is. I have a (nearly complete) port to Pygame. (The only exception is the ondrag method, which I will incorporate if I have time for it.) It runs all of the turtle graphics example scripts (except colormixer which uses ondrag) without problems. > > Unless such proof can be provided (and then integrated into the code), > > I recommend to give up that objective, and start merging the base class > > code into the subclasses where reasonable. Sorry, but I definitely shall not follow your recommendation. I have presented the architecture of the turtle module at Europython 2006 in a talk which was visited also by Guido v. Rossum and later in Leipzig at a workshop where you yourself, Martin, was present. On both of these occasions I showed working prototypes of this port (along with another one to VPython) and nobody had any objections nor were there any objections by other useres who have used it up to now against this design. You can find this also in the "Tagungsband" to the Leipzig Python workshop together with some screenshots. I'm very confident that this is a good design and I know (form the experience mentioned above) that it works. So instead I'll proceed with porting it to Jython and I for my part would consider it as an advantage to have the same turtle module in both of these flavours of Python. Two more remarks on this discussion, a specific one and a general one. 1. The bug I submitted a patch for is in the method setup() and in the __init__ method of _Screen, both of which usually will be called only once in a program.So in *this* case it cannot cause any performance problems. The bug has annoying consequences and I found a simple remedy, which I consider appropriate for a bug-fix-release like 2.6.1. I don't see any reason why to keep a known bug like this one in the code. Acceptance of the patch will certainly not affect any more fundamental amendments to follow (possibly). Moreover up to now I didn't hear of a single complaint about the performance of the turtle module. I think this is (i) because for beginning programmers this is no issue and (ii) there are means (to call tracer() and also to call update() directly) to control performance to a considerable extent. Shortly, my opinion is that there are *good reasons* why the implementation is done like this, seen from the educator's point of view. 2. Is it really fruitful to discuss general design issues along with (comparatively) small problems like this one - in the sense of alternative ways to fix that problem? Implementations of redesigns like the one you recommended wouldn't be accepted anyway for bug fix releases or releases in rc phase. I'm open to fundamental criticism also, but I think that should be led in Python-Dev or possibly comp.lang.python. And working out an amended concept would take some time and also it's implementation and it's testing. Moreover, to find co-workers to work on this would be an advantage. Regards, Gregor ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4117> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4117] missing update() in _Screen.setup() of Lib/turtle.py
Gregor Lingl <[EMAIL PROTECTED]> added the comment: > Most definitely. The module went into Python without any review > whatsoever. Nobody (but you) has ever looked at the code in detail. That's not True! Brad Miller, for example, who also had submitted patches to the pythontracker, coauthor of "Python Programming in Context", has used a predecessor of turtle.py as a main tool (swiss army knife, as he says) in his book. He has contributed a few patches (via private communication, before the module went into the Python trunk), one of them directly concerning the update method. He had also suggested some of the features, which I have added towards the end of the development. > You might argue that with due process, review should have taken > place before the code was integrated. You might be right, but then > the new turtle module wouldn't have been part of Python 2.6. Rigth, more or less. At least I had expected, that someone reads the doc-strings of the approx. 15 classes in the module. The one of TurtleScreenBase reads like this: """Provide the basic graphics functionality. Interface between Tkinter and turtle.py. To port turtle.py to some different graphics toolkit a corresponding TurtleScreenBase class has to be implemented. """ Gregor ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4117> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4117] missing update() in _Screen.setup() of Lib/turtle.py
Gregor Lingl <[EMAIL PROTECTED]> added the comment:
The attached file setup_bug_demo.py shows the bug of this issue. It's
taken out of a working game application and radically abridged to
concentrate on this issue.
Now the patch to fix the bug has to be changed a bit (because of the
changes of Martin's Singleton fix). A diff file follows immediately
(setup_patch.diff).
I tried out (in a simple straight forward way and in contradiction with
my ideas mentioned in a previous posting)
(1) to replace the update() call by _Screen._canvas.update_idletasks() and
(2) to do a similar replacement in TurtleScreenBase._update()
Neither of these work. The second change even affects seriously the
working of the modules demo().
I'd like to mention that in the former turtle module upto 2.5 (remember:
the compatibility to it was a requirement for the new one) there are
also several Canvas.update() calls but no Canvas.update_idletasks() call.
I never noticed negative consequences of this and as far as I know,
neither concerning the old module nor the new one there were ever
complaints concerning bad ("sluggish") performance due to this (or any
other) fact.
Added file: http://bugs.python.org/file12079/setup_bug_demo.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4117>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4117] missing update() in _Screen.setup() of Lib/turtle.py
Gregor Lingl <[EMAIL PROTECTED]> added the comment: Here the patch, updated Added file: http://bugs.python.org/file12080/setup_patch.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4117> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4117] missing update() in _Screen.setup() of Lib/turtle.py
Gregor Lingl <[EMAIL PROTECTED]> added the comment: Sorry, but there is a remain from testing different versions of the turtle module in the demo file's import statement. Should read (of course): from turtle import Screen, Turtle, mainloop A corrected version is attached Sorry, again, for the inconvenience Gregor Added file: http://bugs.python.org/file12081/setup_bug_demo.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4117> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6618] Typo in a listing in 5.2.9 of language reference
New submission from Gregor Lingl : Error in: Python v3.1 documentation >> The Python language reference >> In the listing at the end of section 5.2.9 Yield expressions, line 7: ... except Exception, e: is syntactically incorrect and consequently raises a Syntax Error. Should read: ... except Exception as e: -- assignee: georg.brandl components: Documentation messages: 91171 nosy: georg.brandl, gregorlingl severity: normal status: open title: Typo in a listing in 5.2.9 of language reference versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue6618> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6717] Some problem with recursion handling
New submission from Gregor Lingl : I suspect that there is some deeper (more severe) issue behind the problem I describe below. I've observed the following on Windows only. Didn't try it with different OSs running dragbug.py shows different behaviour with Python 3.1 compared to Python 2.6: Running it with Python 3.1 and performing heavy turtle dragging with the mouse results in: Fatal Python error: Cannot recover from stack overflow This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team -- As I do at the moment ;-) Running the same script from Python 2.6: The error is much harder to reproduce (only with very excessive dragging). It's a bit easier to reproduce when running the program from a console and if it occurs one gets a conventional Python error message: First a long sequence of: Exception in Tkinter callback Traceback (most recent call last): Exception RuntimeError: 'maximum recursion depth exceeded while ignored Followed by: Traceback (most recent call last): File "dragbug.py", line 10, in mainloop() File "c:\Python26\lib\traceback.py", line 57, in print_tb if hasattr(sys, 'tracebacklimit'): AttributeError: 'module' object has no attribute 'tracebacklimit' This problem can be overcome by setting a higher recurson limit. But I think one should require that it doesn't produce a Fatal Error like in Python 3.1 Regards, Gregor -- components: Library (Lib) files: dragbug.py messages: 91664 nosy: gregorlingl severity: normal status: open title: Some problem with recursion handling versions: Python 3.1 Added file: http://bugs.python.org/file14738/dragbug.py ___ Python tracker <http://bugs.python.org/issue6717> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7001] turtle.py bug-fixes, backported from 3.1 [issue5923]
New submission from Gregor Lingl : Among the changes of turtle.py from Python 3.0 to Python 3.1 there were three bugfixes. Those bugs appear also in the Python 2.6 version of turtle.py imho these should be fixed for Python 2.6.3 The appended diffs contain the (backported) fixes of these bugs, (1) in TurtleScreen.update() (2) in TurtleScreen.onkey() (3) in _Screen.__init__ and _Screen.setup The last one entails the need of adding one line into turtleDemo.py. This change does not affect the correct working of turtleDemo with the Python 2.6.2 turtle and demos. -- files: turtle_262_263.diff keywords: patch messages: 93142 nosy: gregorlingl severity: normal status: open title: turtle.py bug-fixes, backported from 3.1 [issue5923] versions: Python 2.6 Added file: http://bugs.python.org/file14976/turtle_262_263.diff ___ Python tracker <http://bugs.python.org/issue7001> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7001] turtle.py bug-fixes, backported from 3.1 [issue5923]
Gregor Lingl added the comment: !! This patch should be applied if and only if the corresponding one of turtle.py is applied !! -- nosy: +georg.brandl, loewis Added file: http://bugs.python.org/file14977/turtleDemo_262_263.diff ___ Python tracker <http://bugs.python.org/issue7001> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7001] turtle.py bug-fixes, backported from 3.1 [issue5923]
Gregor Lingl added the comment: These patches need to be applied to 2.6 in order that they appear in 2.6.3. (/python/branches/release26-maint, I think). As far as I see this is urgent because 2.6.3rc1 is only a few days away. Eventually (or, if you want at the same time) they need to be applied to 2.7. But there are quite a few amendments more that should be backported from Python 3.1 to Python 2.7. Moreover, we do not know today, which bugfixes etc. will go into 3.2 and I think 3.2 should be synchronized with 2.7. Since 2.7 still seems to be pretty far away, we can defer this for now and do it later together with the complementing pathes. As already said, it needs to be done eventually, anyhow. Regards, Gregor -- ___ Python tracker <http://bugs.python.org/issue7001> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7052] "from logging import *" causes an error under Ubuntu Karmic
Gregor Lingl added the comment: The same True for captureWarnings? (It's also is only present in __all__) -- nosy: +gregorlingl ___ Python tracker <http://bugs.python.org/issue7052> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7052] "from logging import *" causes an error under Ubuntu Karmic
Gregor Lingl added the comment: As stated above: the name captureWarnings is also present *only* in __all__. Same reason, same effect. -- ___ Python tracker <http://bugs.python.org/issue7052> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7061] Improve 24.5. turtle doc
Gregor Lingl added the comment: Thanks, Terry, for reading the docs that thoroughly. Alas, for the next week I'm too busy (with preparing "Python für Kids" for press) to work through this long list. Since it doesn't seem to be *very* urgent, I'll defer that work until Oct. 12th or so. Then I'll be glad to discuss each and every point of your list (some of them are known to me already) and I'm sure that the necessary fixes and amendments can be done quickly then. Best regards, Gregor -- ___ Python tracker <http://bugs.python.org/issue7061> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7124] idle.py -n : help() doesn't work in a reopened shell window
New submission from Gregor Lingl :
The following procedure reveals a problem with help:
1) Start IDLE with -n option (no subprocess)
2) Create a script (e. g. helloworld one-liner
3) Run script
4) Close Shell Window
5) Via Menu: Run | Python Shell reopen Shell window
6) >>> help(print)
Help on ...
...
end: string appended after the last value, default a newline.
Traceback (most recent call last):
File "", line 1, in
help(print)
File "C:\Python31\lib\site.py", line 429, in __call__
return pydoc.help(*args, **kwds)
File "C:\Python31\lib\pydoc.py", line 1710, in __call__
self.help(request)
File "C:\Python31\lib\pydoc.py", line 1758, in help
self.output.write('\n')
File "C:\Python31\lib\idlelib\PyShell.py", line 1231, in write
self.shell.write(s, self.tags)
File "C:\Python31\lib\idlelib\PyShell.py", line 1212, in write
self.text.mark_gravity("iomark", "right")
AttributeError: 'NoneType' object has no attribute 'mark_gravity'
>>>
So in a re-opened Shell-Window in an IDLE in -n mode, help() doesn't
work correctly.
Regards,
Gregor
--
components: IDLE
messages: 93980
nosy: gregorlingl
severity: normal
status: open
title: idle.py -n : help() doesn't work in a reopened shell window
type: behavior
versions: Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue7124>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7129] 'filling' missing in __all__
New submission from Gregor Lingl : By oversight the turtle graphics function filling is missing in the __all__ list which is composed by several parts, among them _tg_turtle_functions. So 'filling' has to be added to _tg_turtle_functions a path is attached -- components: Library (Lib) files: filling-bug.diff keywords: patch messages: 94007 nosy: georg.brandl, gregorlingl, loewis severity: normal status: open title: 'filling' missing in __all__ type: resource usage versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file15128/filling-bug.diff ___ Python tracker <http://bugs.python.org/issue7129> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7129] 'filling' missing in __all__ ot turtle.py
Changes by Gregor Lingl : -- title: 'filling' missing in __all__ -> 'filling' missing in __all__ ot turtle.py ___ Python tracker <http://bugs.python.org/issue7129> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6717] Some problem with recursion handling
Gregor Lingl added the comment: I've written and appended with this message a small script using tkinter, that produces the same crash as described earlier with turtle.py: tkinter_recursion_31.py It occurs when heavily and fast dragging the red square. So the bug doesn't depent on turtle.py I'd like to mention again, that the corresponding script under Python26 does crash also, but with a regular Python Error-Message. It does not kill IDLE when stated from within IDLE. So I'd suggest to give this one a higher priority. Should be fixed with 3.2 Regards, Gregor -- Added file: http://bugs.python.org/file15149/tkinter_recursionbug_31.py ___ Python tracker <http://bugs.python.org/issue6717> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5923] turtle.py update: 1.0 --> 1.1
New submission from Gregor Lingl : I propose to update turtle.py with this new version 1.1 of the turtle module. Summary of changes: 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. For convenience I'll add the diff subsequently Regards, Gregor -- components: Library (Lib) files: turtle31.py messages: 87132 nosy: benjamin.peterson, gregorlingl, loewis, rhettinger severity: normal status: open title: turtle.py update: 1.0 --> 1.1 type: feature request versions: Python 3.1 Added file: http://bugs.python.org/file13870/turtle31.py ___ Python tracker <http://bugs.python.org/issue5923> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5923] turtle.py update: 1.0 --> 1.1
Gregor Lingl added the comment: Just to see what I've changed: The unified diff from version 1.0 ( Revision 69847 ) to the proposed version 1.1b (Should result in version 1.1 'final'ly) -- keywords: +patch Added file: http://bugs.python.org/file13871/turtle30_to_31.diff ___ Python tracker <http://bugs.python.org/issue5923> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5923] turtle.py update: 1.0 --> 1.1
Gregor Lingl added the comment: I just wanted to submit the reply below. In the meantime Benjamin's remark arrived. So perhaps the issue can be resolved successfully. May I submit here one of the two example scripts I'd like to add to the demos: tdemo_round_dance.py . Have a look at it and run it. Just for fun - in this strained situation - I hope you enjoy it. I'll prepare the patch for the docs and I'll submit it as soon as possible, not later than tomorrow. Of course the print(_ver) statement should be commented out. Regards, Gregor --- So perhaps there is someone else who could do it. I'd like to state decisively: Version 1.1 contains significant amendments. I tested it thoroughly It would be a big advantage if others could test it also during the 4 weeks of beta testing. So I'd like to ask: Would it be practicable to put it into 3.1b with the caveat to revert this adoption if it turns out to have unrecoverable flaws? I'd like to remind you that Martin even did significant changes to version 1.0 only a few days before the final release of Python2.6. I know (and regret) that I submitted these changes rather late, but it was four days ago that I asked Martin and also Raymond for advice on how to proceed with the submission but regrettably with no response. Unfortunately I'm a full time teacher and have to do a lot of final exams these days. So I have only limited resources to work on turtle development. Nevertheless I'm anxious to only deliver valuable contributions. I hope there is a way to accept these for now. Regards Gregor -- Added file: http://bugs.python.org/file13879/tdemo_round_dance.py ___ Python tracker <http://bugs.python.org/issue5923> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5923] turtle.py update: 1.0 --> 1.1
Gregor Lingl added the comment: Here the patch to comment out the print(_ver) statement -- Added file: http://bugs.python.org/file13880/print_ver_patch.diff ___ Python tracker <http://bugs.python.org/issue5923> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5923] turtle.py update: 1.0 --> 1.1
Gregor Lingl added the comment: Here is a patch for the documentation. It may contain some typos and/or inaccuracies. I promise to check it and submit a patch if necessary before final. It contains also the announcement of two new demo scripts, the one beeing round_dance submitted already, the other one being a nim game. I'll submit it subsequently Regards, Gregor -- Added file: http://bugs.python.org/file13885/turtle31.rst.diff ___ Python tracker <http://bugs.python.org/issue5923> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5923] turtle.py update: 1.0 --> 1.1
Gregor Lingl added the comment: The second demo script just announced -- Added file: http://bugs.python.org/file13886/tdemo_nim.py ___ Python tracker <http://bugs.python.org/issue5923> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6339] Some functional errors in turtle.py documentation (missing links)
New submission from Gregor Lingl : In the Python3.1rc2 documentation for turtle.py there are the following functional errors: In the overview section the (newly added) entries for the functions/methods shearfactor get_shapepoly onkeypress numinput do not have links to the corresponding text sections. These exist but also have errors, sometimes the leading 'turtle.' is missing, sometimes the parameter self erroneously appears in the text. I'm not very educated in restructured Text Syntax respectively the documentatin system. Nevertheless I inspected the source and I assume the following causes for this: In the first lines of the sections for shearfactor and numinput there are superfluous self, which should be deleted. In the sections for get_shapepoly, onkeypress and numinput there are perturbing colons at the end of the first lines, which perhaps should be deleted. As I'm not sure if this suggestions are right and/or comlete and I do not have any means to test them, I cannot submit a patch. Please could some docs-guru check my suggestions (and possibly repair the defects) It would be fine if this errors wouldn't appear in 3.1 Regards, Gregor -- assignee: georg.brandl components: Documentation messages: 89682 nosy: georg.brandl, gregorlingl, loewis severity: normal status: open title: Some functional errors in turtle.py documentation (missing links) versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue6339> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6340] replace tdemo_chaos.py
New submission from Gregor Lingl : I've submitted a replacement, which is functionally 100% equivalent, but cleaner code, more appropriate for a demo: four or five superfluous lines, which were remains from some previous version are deleted now; names and comments are now in English. Regards, Gregor -- components: Demos and Tools files: tdemo_chaos.py messages: 89686 nosy: georg.brandl, gregorlingl, loewis severity: normal status: open title: replace tdemo_chaos.py versions: Python 3.1 Added file: http://bugs.python.org/file14358/tdemo_chaos.py ___ Python tracker <http://bugs.python.org/issue6340> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6340] replace tdemo_chaos.py
Changes by Gregor Lingl : Removed file: http://bugs.python.org/file14358/tdemo_chaos.py ___ Python tracker <http://bugs.python.org/issue6340> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6340] replace tdemo_chaos.py
Changes by Gregor Lingl : Added file: http://bugs.python.org/file14359/tdemo_chaos.py ___ Python tracker <http://bugs.python.org/issue6340> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6340] replace tdemo_chaos.py
Changes by Gregor Lingl : Removed file: http://bugs.python.org/file14359/tdemo_chaos.py ___ Python tracker <http://bugs.python.org/issue6340> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6340] replace tdemo_chaos.py
Changes by Gregor Lingl : Added file: http://bugs.python.org/file14360/tdemo_chaos.py ___ Python tracker <http://bugs.python.org/issue6340> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6340] replace tdemo_chaos.py
Gregor Lingl added the comment: So do I. I'd like to ask you to do the commit. And I'd also like to suggest that - in the first three comment-lines of the script - you replace Datei:by File: Autor:by Author: Datum: 24. 6. 2009by Date: 2009-06-24 Then (hopefully) we will never need to touch it any more ;-) Thanks in advance Gregor -- ___ Python tracker <http://bugs.python.org/issue6340> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8616] Changes to content of Demo/turtle
Gregor Lingl added the comment: Yes, tdemo_raund_dance.py and tdemo_scribble.py definitely do not work with turtle.py from Python 2.7 :-( I submitted them expecting, that my backport of turtle.py from Python 3.1 to Python 2.7 would be accepted. But, alas, I was too late :-((( So it's definitely ok not to add it to the turtle-demo-collection. The case of tdemo_nim.py is a mystery to me. To be sure to use the incriminated version I downloaded it from here (bug-tracker) and tried it out several times. The malfunction you mentioned never did occur. Moreover I've checked the code. Ther are only two lines, 62 (initialization with None) and 72, containing assignments to the NimModel.winner attribute which decides about the winner's announcement. Cannot imagine why this shouldn't work correctly? In fact the very same script is contained in Demo/turtle of Python 3.1.2 (in fact since 3.1) and up to now I never got any feedback about any malfunction whatever. So please could you check it once again and give some information in oder to be able to reproduce the effect mentioned? I'm definitely very interested in *know*ing if the script is faulty or not. However, committing this demo script or not can safely be regarded as a very unimportant issue. Regards, Gregor -- ___ Python tracker <http://bugs.python.org/issue8616> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
