<div dir="ltr">Hi Raúl,<div><br></div><div style>Thank you for your elaborate answer to my question.  That's an entirely new, and very interesting, perspective on the Python export functionality.</div><div style><br></div>
<div style><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">In terms of the technical approach you suggest, I agree in principle<br>
but I suspect there might be shortcuts that you might<br>want to test to get a faster feedback on how this shall look. I.e.:<br>instead of refactoring TA initially to allow it to run projects<br>from exported Python you might want to have a way of transforming the<br>
Python code back to TA's internal DSL and run<br><span style="font-family:arial,sans-serif;font-size:12px">that (this was actually Walter's idea, which I think should give you a<br></span><span style="font-family:arial,sans-serif;font-size:12px">good start). Anyway, there's many ways to skin this Turtle :-)</span></blockquote>
</div><div style>I agree that it is also desirable to be able to convert Python code back into TA's internal DSL.  But I'm affraid that is a project of its own.  I can imagine that we would run into problems when the Python code uses constructs that aren't supported in TA (e.g., classes, if I'm not mistaken).  Maybe I can work on this after the GSoC.</div>
<div style>My motivation was that the users should be able to run the exported Python code outside of TA, e.g., in Pippy.  For this purpose, translating the Python code into TA's internal DSL is not an option because Pippy doesn't understand that language.  This is why I chose to have the exported Python code import some classes from TA's code.  Probably we won't even need that much refactoring to achieve this.  The code seems pretty reasonably organized into modules.</div>
<div style><br></div><div style>Marion</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/1 Raúl Gutiérrez Segalés <span dir="ltr"><<a href="mailto:rgs@itevenworks.net" target="_blank">rgs@itevenworks.net</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(re-sending - forgot to hit reply-all)<br>
<br>
Hi Marion,<br>
<div class="im"><br>
On 30 April 2013 17:13, Marion Zepf <<a href="mailto:marion.zepf@gmail.com">marion.zepf@gmail.com</a>> wrote:<br>
> Hi Raúl,<br>
><br>
> My name is Marion.  I am a student applying for the GSoC.  I would like to<br>
> work on a Python export feature for Turtle Blocks.  Here is a brief<br>
> description of my project proposal:<br>
><br>
> 'Turtle Blocks Python export' lets the user export their programming project<br>
> from the Turtle Blocks activity to a Python script. The generated Python<br>
> code can be run outside of Turtle Blocks, for example from the command line<br>
> or in the Pippy IDE.<br>
> This tool is designed for users who are already proficient Turtle Block<br>
> programmers and want to move on to text-based programming. It helps them<br>
> transfer their knowledge and skills from block-based to text-based<br>
> programming, as they can see their own creations in a new programming<br>
> language. Thus, they can focus on the new language rather than the content<br>
> of the program.<br>
><br>
> You can find a more detailed description on<br>
> <a href="http://wiki.sugarlabs.org/go/Summer_of_Code/2013/Turtle_Blocks_Python_export" target="_blank">http://wiki.sugarlabs.org/go/Summer_of_Code/2013/Turtle_Blocks_Python_export</a><br>
><br>
> One of the questions I have to answer for my application is, 'If your<br>
> project is successfully completed, what will its impact be on the Sugar Labs<br>
> community?' I am required to include answers from the Sugar Labs community.<br>
> Walter has already given me his, and I would like to ask you for your answer<br>
> to this question.<br>
<br>
</div><div class="im">In my mind, the big take away here is that we'll enable portability of<br>
Turtle Art projects. Being able to translate TA internal<br>
code into external languages (initially Python, eventually Javascript<br>
perhaps, or others) will allow this fundamental learning activity to<br>
reach other platforms and a much broader audience. The question we've<br>
got in front of us is not if Sugar or Turtle Art belong in the Cloud;<br>
it's just how fast can we get there.<br>
<br>
This project is a key step towards our goal of getting Sugar/Turtle<br>
Art onto more hands.<br>
<br>
In terms of the technical approach you suggest, I agree in principle<br>
but I suspect there might be shortcuts that you might<br>
want to test to get a faster feedback on how this shall look. I.e.:<br>
instead of refactoring TA initially to allow it to run projects<br>
from exported Python you might want to have a way of transforming the<br>
Python code back to TA's internal DSL and run<br>
</div>that (this was actually Walter's idea, which I think should give you a<br>
good start). Anyway, there's many ways to skin this Turtle :-)<br>
<br>
Have fun!<br>
</blockquote></div><br></div>