Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

new turtle module #43565

Closed
gregorlingl mannequin opened this issue Jun 28, 2006 · 14 comments
Closed

new turtle module #43565

gregorlingl mannequin opened this issue Jun 28, 2006 · 14 comments
Assignees

Comments

@gregorlingl
Copy link
Mannequin

gregorlingl mannequin commented Jun 28, 2006

BPO 1513695
Nosy @gvanrossum, @loewis, @benjaminp
Files
  • xturtle.py: code of xturtle.py
  • xturtle-docs.txt: documentation for xturtle.py
  • xturtle.py: xturtle.py version 0.95a0
  • xturtle-docs.txt: documentation for xturtle.py v0.95a0
  • xturtle.cfg: configuration file for xturtle
  • whatsnew.txt: What's new in xturtle0.95 (compared to 0.91)
  • turtle.zip: turtle module including docs and demos
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/loewis'
    closed_at = <Date 2008-06-04.06:30:52.210>
    created_at = <Date 2006-06-28.00:50:47.000>
    labels = ['expert-tkinter']
    title = 'new turtle module'
    updated_at = <Date 2008-06-04.06:30:52.180>
    user = 'https://bugs.python.org/gregorlingl'

    bugs.python.org fields:

    activity = <Date 2008-06-04.06:30:52.180>
    actor = 'loewis'
    assignee = 'loewis'
    closed = True
    closed_date = <Date 2008-06-04.06:30:52.210>
    closer = 'loewis'
    components = ['Tkinter']
    creation = <Date 2006-06-28.00:50:47.000>
    creator = 'gregorlingl'
    dependencies = []
    files = ['7351', '7352', '9693', '9694', '9695', '9715', '10493']
    hgrepos = []
    issue_num = 1513695
    keywords = ['patch']
    message_count = 14.0
    messages = ['50549', '50550', '63604', '63711', '63714', '63842', '64388', '67241', '67371', '67374', '67596', '67640', '67644', '67683']
    nosy_count = 6.0
    nosy_names = ['gvanrossum', 'loewis', 'glingl', 'gregorlingl', 'benjamin.peterson', 'bmiller']
    pr_nums = []
    priority = 'normal'
    resolution = 'accepted'
    stage = None
    status = 'closed'
    superseder = None
    type = None
    url = 'https://bugs.python.org/issue1513695'
    versions = ['Python 2.6', 'Python 3.0']

    @gregorlingl
    Copy link
    Mannequin Author

    gregorlingl mannequin commented Jun 28, 2006

    The file, at present named xturtle.py is a
    reimplementation of turtle.py with additional features,
    among them:

    -Better animation of the turtle movements, especially
    of turning the turtle. So the turtles can more easily
    be used as a visual feedback instrument by the
    (beginning) programmer.
    -Different turtle shapes, gif-images as turtle shapes,
    user defined and user controllable turtle shapes, among
    them compound (multicolored) shapes.
    -Fine control over turtle movement and screen updates
    via delay(), and enhanced tracer() and speed(),
    update() methods.
    -Aliases for the most commonly used commands, like fd
    for forward etc. ...
    -Some simple commands/methods for creating event driven
    programs (mouse-, key-, timer-events). Especially
    useful for programming simple games.
    -A scrollable Canvas class. The scrollable Canvas can
    be extended interactively as needed while playing
    around with the turtle(s) (e. g. to follow some escaped
    turtle).
    -Commands for controlling background color or
    background image.

    detailed documentation is in the docstrings (similar to
    the last version of turtle.py) which copmrise approx.
    50% of the filesize.

    xturtle.py is widely backward compatible to turtle.py
    (i. e. except the appearance of the turtle(s) and their
    animation)

    I propose to replace turtle.py by xturtle.py

    Separate Documentation is available as a text file
    reassembled and enhanced from the docstring.
    I'll supply this in a separate patch (as it seems
    impossible here to attach 2 files)

    Regards,
    Gregor Lingl

    @gregorlingl gregorlingl mannequin assigned loewis Jun 28, 2006
    @gregorlingl gregorlingl mannequin added the topic-tkinter label Jun 28, 2006
    @gregorlingl gregorlingl mannequin assigned loewis Jun 28, 2006
    @gregorlingl gregorlingl mannequin added the topic-tkinter label Jun 28, 2006
    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Jun 29, 2006

    Logged In: YES
    user_id=21627

    A number of remarks:

    1. would you like to see the demo applications included as
      well? They could go somewhere into Demo. If so, please
      prepare the patch as a single tar/zip file that unpacks on
      top of a Python source tree.

    2. The doc string refers to the module as xturtle, and says
      it replaces turtle. If the module becomes turtle, this
      remark becomes self-referential. Please update the doc
      string accordingly.

    3. Somebody should investigate the rationale for
      re-exporting math in the current turtle.py. If that
      rationale is still valid, the new module should comply.

    4. The module should grow an __all__ attribute.

    5. _Vec does not appear to be a general vector class, but be
      restricted to 2D cartesian coordinates. It should be
      renamed. Perhaps to "Point?"

    6. Try to follow PEP-8, in particular, drop camelCase for
      method names.

    7. Avoid passive voice for doc strings; use active voice
      instead (e.g. addshape: "Adds a turtle" -> "Add a turtle")

    8. What happens to the n= argument of clear()?

    9. What is the purpose/status of checkargs? Do you want to
      keep it or drop it?

    10. There are some German doc strings left (e.g. _rotate).

    @gvanrossum
    Copy link
    Member

    (This is no longer the latest version. Gregor, mind uploading a newer one?)

    @glingl
    Copy link
    Mannequin

    glingl mannequin commented Mar 17, 2008

    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.

    @glingl
    Copy link
    Mannequin

    glingl mannequin commented Mar 17, 2008

    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.)

    @gregorlingl
    Copy link
    Mannequin Author

    gregorlingl mannequin commented Mar 18, 2008

    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.

    @bmiller
    Copy link
    Mannequin

    bmiller mannequin commented Mar 24, 2008

    I have xturtle 0.95a0 running under Python 3.0. Mostly the 2to3 program
    just worked for everything except in three places:

    1. in __forward methods I had to change:
      fromClass.__dict__[method] = d[method] to
      setattr(fromClass,method,d[method])

    2. in getmethparlist The line:
      if type(ob)==types.MethodType: does not evaluate to true even when ob
      is a method. In 3.0 it seems that ob always evaluates to a function.

    3. in the _pointlist method I changed
      cl = self.cv.coords(item) to
      cl = list(self.cv.coords(item))
      There is probably a more elegant way to use the results from the coords
      call than converting to a list, but I'm confused.
      The canvas coords function now returns an itertools.imap object. This
      confuses me because the documentation on python.org does not mention the
      imap function in the itertools module documentation. So I'm not sure if
      imap is going away or is just missing documentation.

    I would like to propose two additional features that I have added to my
    copy of xturtle and have used extensively in my classes:

    1. exitOnClick() --- This function simply hides the call to mainloop()
      from beginners. It makes life much easier for beginning programers to
      run xturtle from IDLE.

    2. setWorldCoordinates(llx,lly,ulx,uly) This maps a given set of real
      world coordinates to window coordinates and allows programmers to run
      the turtle using real world coordinates. Again for beginning
      programmers this makes it easy for them to use the turtle to graph
      functions, make bar charts, etc. without needing to scale everything
      themselves.

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented May 23, 2008

    Can you please file a contributor agreement? This would be a
    prerequisite for including the module.

    Also, is there any progress on the open issues? I really would like to
    see a single zip file that unpacks on top of the Python tree, replaces
    the turtle module, and works just fine in all respects out of the box.

    @gregorlingl
    Copy link
    Mannequin Author

    gregorlingl mannequin commented May 26, 2008

    Certainly I'd like to file a contributor agreement. But I don't know
    what is required exactly. Is there any template or example? (There is
    already a compyright-preamble in the submitted version - but I think you
    mean something else?)

    There is progress on most of the open issues and I have now a version
    which works well with Python 2.6 and is fairly well documented via
    docstrings. I could upload this within (at most) two days. It has also
    those 2 features requested by Brad miller (msg64388) implemented.

    But I have a few questions to which I need answers in order to continue
    my work optimally:

    1. The turtle module is contained in one large file. But there will be
      two versions, one for Python2.6 the other one for Python3.0. Right?

    2. As far as I understand, xturtle.py will replace turtle.py in Python
      3.0. Will xturtle.py replace turtle.py already in Python2.6 or are the
      plans that it will only be added to Python2.6?

    3. I understand, that compatibility issues are of primary importance for
      Python 2.6. Is this also the case for Python 3.0? (If not some cleanup
      could be done. I.e. some code, which is only there for compatibility
      reasons could be dropped.)

    4. How to proceed with documentation? Is it extracted automatically from
      the docstrings? Or should I compose a single text file mainly from the
      docstrings with some additional structure and explanations? I also
      would be happy to create sources for Sphinx, but that would take some
      time (approx. a week) as I'm not familiar neither with Sphinx nor with
      reStructuredText. There are quite a few people around who would like to
      help with the documentation, especially to amend my not very brillant
      and clear English. This brings me to two very important questions:

    5. How will the development of xturtle/turtle continue? There are more
      than 3 month until the final release and it will be reasonable to use
      this time to amend the docs (as mentioned above) and to fix those bugs,
      which inevitably will occur during the beta testing period.

    • Should I prepare bugfix-releases of the module on my own and then
      submit them every 1 or 2 weeks, or
    • should the bugs and amendments be submitted to the bugtracker one at a
      time and then be incorporated by some reviewer?
    1. Who will be the reviewer? Martin? Or has the reviewer still to be
      determined? I would very much appreciate some regular communication
      about the open issues.

    2. Where is the right place for this communication? Here at the
      bugtracker? At Python-dev?

    3. Another open issue is, if there should be added some sample scripts
      to the standard-distro? What is your opinion?

    More questions will certainly arise, but for now I'd be happy to get
    answers to these ones.

    Thanks in advance

    Gregor Lingl

    @benjaminp
    Copy link
    Contributor

    You can get a contributor agreement at http://www.python.org/psf/contrib/.

    1. We will add it to the 2.6, and tree and it will be ported to 3.0.

    2. As long as it's compatible, it will replace the old turtle in 2.6.

    3. We're trying not to change the APIs too much, but this is a
      possibility if you deprecate them in 2.6.

    4. reST is what we are using. If you could give the doc team a plain
      text, we'd be happy to work with you and convert it to reST.

    5. We can probably give you commit access to maintain your module. In
      that case you can just do your fixes in Subversion.

    6. I don't know. :)

    7. Yes.

    8. I think we could use some examples in the Demo directory.

    Thanks for contributing!

    @gregorlingl
    Copy link
    Mannequin Author

    gregorlingl mannequin commented Jun 1, 2008

    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

    @gregorlingl
    Copy link
    Mannequin Author

    gregorlingl mannequin commented Jun 2, 2008

    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

    @gregorlingl
    Copy link
    Mannequin Author

    gregorlingl mannequin commented Jun 2, 2008

    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

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Jun 4, 2008

    Thanks for the patch, committed as r63929. Please move any further
    discussion or other necessary changes into a new issue.

    @loewis loewis mannequin closed this as completed Jun 4, 2008
    @loewis loewis mannequin closed this as completed Jun 4, 2008
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Projects
    None yet
    Development

    No branches or pull requests

    2 participants