<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt">> Could you point me to some documentation explaining what would be
the ideal workflow to develop a serious (Multi-package, multi-modules)
Python project within Leo? I am seriously interested. May be even how
to import a project into Leo?<br><br>I'm not sure I've ever been asked this question<br>exactly. It's a good one.<br><br>My suggestion is to look at leoPy.leo (depending on<br>your distribution it may be called leoPyRef.leo.)<br>This file contains all of Leo's core sources. So the<br>"workflow" is simply to create @thin trees representing your files.<br><br>For a discussion of a way to develop Leo itself<br>without having to continually reload leoPy.leo during<br>testing, see<br><span><a target="_blank" href="http://webpages.charter.net/edreamleo/FAQ.html#how-can-i-use-leo-to-develop-leo-itself">http://webpages.charter.net/edreamleo/FAQ.html#how-can-i-use-leo-to-develop-leo-itself</a></span><br><br>> May be even how to import a project into Leo?<br>
<br>For largish projects I typically use a Leo script<br>to do the imports. For one example, see scripts.leo,<br>in the node:<br><br>Scripts-->@file leoScripts.txt-->Important-->Recursive import script<br><br>There is also a script in test.leo that creates @auto<br>nodes from a project. See the node:<br><br>Startup-->Commands, scripts-->create-at-auto-nodes<br><br>@auto nodes are new this year, but they seem to be<br>becoming the method of choice for studying other people's code. In any case, the import commands and the @auto logic both use the so-called "perfect import" logic that warns if writing the imported code<br>will not be identical (in various senses) to the<br>original code.<br><br>> IMO, literate programming shouldn't get in your way while
programming, thats why currently, all the "literature" in my programs
are the docstrings ;-)<br><br>I agree completely. Indeed, I have said many times<br>that Leo redefines what literate programming is. See:<br><br><span><a target="_blank" href="http://webpages.charter.net/edreamleo/design.html">http://webpages.charter.net/edreamleo/design.html</a></span><br><br>and especially:<br><br><span><a target="_blank" href="http://webpages.charter.net/edreamleo/design.html#how-leo-changes-the-notion-of-literate-programming">http://webpages.charter.net/edreamleo/design.html#how-leo-changes-the-notion-of-literate-programming</a></span> <br>
<br>In particular, Leo *dramatically decreases* the<br>need for comments, especially comments that are intended to provide the 'big picture' of complex code<br>or data. Outline structure is *way* clearer than<br>comments.<br><br>Furthermore, the more I use Leo, the less I use<br>literate programming features. Indeed, section references are usually anti-patterns, imo. I typically use section references only for constructs,<br>like groups of import statements, or long docstrings,<br>that can not be encapsulated easily in Python methods.<br><br>Edward<br><div> </div>--------------------------------------------------------------------<br>Edward K. Ream email: edreamleo@yahoo.com<br><span>Leo: <a target="_blank" href="http://webpages.charter.net/edreamleo/front.html">http://webpages.charter.net/edreamleo/front.html</a></span><br>--------------------------------------------------------------------<div style="font-family: times new
roman,new york,times,serif; font-size: 12pt;"><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><div class="gmail_quote"><div><br></div></div></div><br></div></div><br>
<hr size=1>Never miss a thing. <a href="http://us.rd.yahoo.com/evt=51438/*http://www.yahoo.com/r/hs"> Make Yahoo your homepage.</a>
</body></html>