[issue4117] missing update() in _Screen.setup() of Lib/turtle.py
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: See also turtle.py update for 3.1 post on python-dev specifically mentioning this bug as fixed. http://mail.python.org/pipermail/python-dev/2009-May/089383.html -- status: pending - closed ___ Python tracker rep...@bugs.python.org 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
Alexander Belopolsky belopol...@users.sourceforge.net added the comment: It looks like this has been fixed in turtle 1.1. See r72318 and issue 5923. -- nosy: +belopolsky, georg.brandl resolution: - out of date stage: - committed/rejected status: open - pending ___ Python tracker rep...@bugs.python.org 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
[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
Martin v. Löwis [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). 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?) 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. Did you experience any problems or undesired behaviour because of using unly cv.update? I agree with with gpolo: it's a general Tk programming principle to defer updates whenever possible. This allows the event handler to return more quickly, making the system more responsive. Each individual update call will only contribute a small amount of time to the response time. It's many of these which eventually make the entire system sluggish. ___ 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
Martin v. Löwis [EMAIL PROTECTED] added the comment: 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? Most definitely. The module went into Python without any review whatsoever. Nobody (but you) has ever looked at the code in detail. Only now that I look at it I wonder whether the design of the code is appropriate. In this specific case, gpolo suggested a reasonable change to the proposed patch. You opposed this change, pointing out that this change contradicts the design behind it. As I think the change gpolo requested is desirable, it *must* be the design that is wrong (as it restricts us from doing what I think should be done). So: if you bring up the design as a reason for doing things the way they are done, expect the design to be challenged. 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. Wrt. the specific design issue: I believe that attempts to provide cross-platform GUI in a simple fashion are doomed to fail. Java AWT is an extraordinary example of it, but many more libraries exist that essentially prove that cross-platform GUI is a bad idea; one may argue that Tk itself is also proof of that (although it is fairly sophisticated, and not at all simple). The fact that I have not objected to it earlier is simply because I must have ignored any claims about cross-platform GUIs. ___ 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: 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
Guilherme Polo [EMAIL PROTECTED] added the comment: Why are you using update instead of update_idletasks ? I'm not talking exactly about this line being added, but this ends up calling TurtleScreenBase._update which calls self.cv.update(), cv being a canvas. update_idletasks should be used exactly for performing the kind of tasks expected here, display update and window layout calculations, while calling update may also process other events or pending errors. -- nosy: +gpolo ___ 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
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
[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
