
I'm changing the subject to keep this separate from the project management tools discussion. On Sun, Mar 16, 2008 at 10:13 AM, Gregor Lingl <gregor.lingl@aon.at> wrote:
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.
I think that for 3.0, replacing turtle with xturtle is great, *IF* xturtle doesn't add any additional dependencies *AND* it works well on Mac OSX, Linux and Windows.
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.
That sounds cool. In 2.6 I'm reluctant to replace the existing turtle module; xturtle can be added as xturtle.
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.
I think that for a library module like this, an email like you've sent is just fine. Maybe Brett has a suggestion on whether it would remain a toplevel module or could be placed in some umbrella package (is Tkinter being moved around?). -- --Guido van Rossum (home page: http://www.python.org/~guido/)

On Sun, Mar 16, 2008 at 10:32 AM, Guido van Rossum <guido@python.org> wrote:
I'm changing the subject to keep this separate from the project management tools discussion.
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.
I think that for a library module like this, an email like you've sent is just fine. Maybe Brett has a suggestion on whether it would remain a toplevel module or could be placed in some umbrella package (is Tkinter being moved around?).
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

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

On Mon, Mar 17, 2008 at 3:35 PM, Gregor Lingl <gregor.lingl@aon.at> wrote:
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")?
I don't use Windows so I can't help with that. But you might want to try a checkout and build from source. You can find instructions in the PCbuild directory. -Brett

On 17/03/2008, Gregor Lingl <gregor.lingl@aon.at> wrote:
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
It worked for me. I have Python 2.5 installed, so I did an install of Python 2.6a1 "for all users", but I deselected the "register extensions" option (which makes this the default Python). I then ran idle using C:\Apps\Python26\python C:\Apps\Python26\Lib\idlelib\idle.py This worked fine for me.
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")?
This is my sys.path:
C:\Apps\Python26\python Python 2.6a1 (r26a1:61155, Mar 1 2008, 12:11:56) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information.
import sys sys.path ['', 'C:\\Apps\\Python26\\python26.zip', 'C:\\Apps\\Python26\\DLLs', 'C:\\Apps\\Python26\\lib', 'C:\\Apps\\Python26\\lib\\plat-win', 'C:\\Apps\\Python26\\lib\\lib-tk', 'C:\\Apps\\Python26', 'C:\\Apps\\Python26\\lib\\site-packages']
I don't see why "for this user only" should work any differently. No, I just tried it and it's OK as well. I can't see any reason why "register extensions" sould cause you a problem either. Can I suggest you uninstall and reinstall and see if that helps? Keep a log of what you didn, and if it's still a problem let me know and I'll see what I can do. Paul. PS What version of Windows are you on? I'm using XP Home (32 bit). If you're using 64-bit, I can't help, I'm afraid...

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
participants (4)
-
Brett Cannon
-
Gregor Lingl
-
Guido van Rossum
-
Paul Moore