Hi everyone,
with this posting I refer to a paragraph in PEP 361, which says:
"""Each non-trivial feature listed here that is not a PEP must be discussed on
python-dev. Other enhancements include:
- ...
- turtle.py replacement or enhancements
"""
Some time ago I had offered my xturtle.py as a replacement of or
supplement to turtle.py. The discussion that followed is here:
http://www.python.org/dev/summary/2006-06-16_2006-06-30/
At Europython 2006 I gave a talk on xturtle and there and since then I
had quite positive feedback including encouragement to offer it again to
include it in the python standard distribution by quite a few people
including Guido van Rossum.
During the last few weeks I did some enhancements to xturtle and put the
current version on the xturtle website for download in order to get same
feedback about the API as well as possible bug reports. This version
still needs some code polishing.
http://www.rg16.at/~python/xturtle/download.html
So I'm interested to know if this is still an issue for you. If so there
should be initiated some procedure to decide that.
If this decision were negative, things were done (- and I'd continue to
develop xturtle elsewhere.)
If the decision were positive, I'd be able to prepare two equivalent
versions for Python2.6 and Python3000 within two or three weeks. (The
port to Python3000 is nearly ready.) These could include say 85% of the
documentation, albeit still not in the correct format.
I think these had to be examined my some reviewer(s) and also a
discussion about features to include or not include would be useful. I'd
like to intensivly take part in this discussion and development.
After a possible decision to include xturtle into Python, which
certainly should take place before the first beta release, there would
be enough time to polish the documentation and to fix bugs. For their
discovery it would certainly be an advantage to put it in some
prerelease as early as possible.
Of course I know that xturtle is only a side issue in the current
development efforts. Unfortunately I'm not familiar with the procedures
needed to get a new module into Python, so I kindly ask you for your
advice how to proceed, at the same time offering my cooperation.
With best regards
Gregor Lingl
Guido van Rossum schrieb:
> Python 3.0 and 2.6 are coming along really nice. I am optimistic that
> we can make the projected August date for the final releases of 2.6
> and 3.0. As you may remember, Barry (the new release manager for both)
> suggested that we synchronize releases of 2.6 and 3.0. Not only could
> this potentially save the release manager and his assistants some
> time, doing the final releases together sends a clear signal to the
> community that both versions will receive equal support.
>
> However, looking at the calendar, I think we need to do a little more
> planning and management than we've typically done for Python releases.
> A final release in August means that we should plan to release a first
> beta in June and a second one in July. That means we have time for
> only two more alpha releases (April and May). I'm thinking of 1-2
> release candidates 1-2 weeks ahead of the final release. Barry can
> make up a more detailed timetable. I'm fine with some slippage
> (especially if planned ahead) of individual releases due to
> availability of release personnel; but I don't want to be held up by
> features or bugs unless they are of absolutely dramatic show-stopping
> nature.
>
> In order to make such a tight release schedule we should try to come
> up with a list of tasks that need to be done, and prioritize them.
> This should include documentation, and supporting tools like 2to3. It
> should include features, backports of features, cleanup, bugs, and
> whatever else needs to be done (e.g. bugbot maintenance).
>
> In the past we've used shared spreadsheets in Google for this purpose,
> but seeing that these haven't been updated in ages, I'm skeptical that
> they are a sufficient tool. In my day job at Google we've started to
> do all task management for our project in the bug tracker (but that
> tracker has some features that make it particularly easy). Does anyone
> have a suggestion for an online open shared task management system
> that we cold adopt? Or should we bite the bullet and put everything in
> the bug tracker? Other suggestions? Anything's better than just
> email...
>
> PS. I realize that I've been rather absent from the day to day
> activities in the Python 3000 world lately. This is a temporary
> condition due to an important impending launch in my day job; I expect
> to have much more time for Python again starting in April.
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
