Wild idea, swiped directly from haskell/ghc: How about making the python interpreter just a little bit smarter, to support literate programming? Add a 'literate python' mode, triggered by file type being .pyl, a '-l' option, or the interpreter being run as 'lpython', then the compiler does a little bit of filtering before compiling (and potentially saving .pyc/.pyo) the file. If the first non-white-space character after the shebang line (if present) is a backslash, then the compiler ignores lines until it sees a line consisting of \begin{code} (which could be the first line), then compiles lines until it sees a line consisting of \end{code}, after which it switches back to searching for \begin{code}. Otherwise, all lines (again, after the shebang line, if present) are treated as comments until the compiler sees a line starting with "> " (that's greater than followed by space) following an empty line, which causes the compiler to start stripping the "> " from lines and compiles them until it finds a line that doesn't start with "> ". <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
I absolutely love the idea of literate programming and have investigated several existing projects that attempt this. There already exist several third-party packages for literate programming in python: - PyLit (http://pylit.berlios.de/) - PyWeb (http://pywebtool.sourceforge.net/) - Leo (http://webpages.charter.net/edreamleo/front.html) PyLit approaches it by transforming between RestructuredText and source, which allows line numbers to match for debugging. PyWeb takes the more traditional noweb/tangle approach of creating source from a document. The biggest issue is making exceptions and debugging nice if you allow code re-ordering. Interpreter support may help with this, but I think there's still a lot to be explored by third party libraries (importlib, ast transforms, etc.) I'm not sure if python-ideas is the appropriate venue, but if you'd like to develop this idea more, please feel free to email me. Cheers ===== --Ryan E. Freckleton On Tue, Mar 8, 2011 at 3:02 PM, Mike Meyer <mwm@mired.org> wrote:
Wild idea, swiped directly from haskell/ghc:
How about making the python interpreter just a little bit smarter, to support literate programming? Add a 'literate python' mode, triggered by file type being .pyl, a '-l' option, or the interpreter being run as 'lpython', then the compiler does a little bit of filtering before compiling (and potentially saving .pyc/.pyo) the file.
If the first non-white-space character after the shebang line (if present) is a backslash, then the compiler ignores lines until it sees a line consisting of \begin{code} (which could be the first line), then compiles lines until it sees a line consisting of \end{code}, after which it switches back to searching for \begin{code}.
Otherwise, all lines (again, after the shebang line, if present) are treated as comments until the compiler sees a line starting with "> " (that's greater than followed by space) following an empty line, which causes the compiler to start stripping the "> " from lines and compiles them until it finds a line that doesn't start with "> ".
<mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On 3/8/2011 5:02 PM, Mike Meyer wrote:
Wild idea, swiped directly from haskell/ghc:
How about making the python interpreter just a little bit smarter,
It already is ;-) Though not exactly well known, expression statements that consist of a literal (number or string) are ignored -- except for string literals in docstring position (and then, they are attached as attributes, rather than being in the code object. def f(): 'doc' # to .__doc__ 1 # ignored (1,2,3) # will not be ignored, even though constand and unused # comments are ignored 'same as comment' ''' multiline comment ''' from dis import dis dis(f)
4 0 LOAD_CONST 5 ((1, 2, 3)) 3 POP_TOP
10 4 LOAD_CONST 4 (None) 7 RETURN_VALUE
If the first non-white-space character after the shebang line (if present) is a backslash, then the compiler ignores lines until it sees a line consisting of \begin{code} (which could be the first line), then compiles lines until it sees a line consisting of \end{code}, after which it switches back to searching for \begin{code}.
So this appears unnecessary. Just use quotes. The main problems is that program editors are generally not smart enough to do auto text wrapping within multiline strings. -- Terry Jan Reedy
On 9 mars 2011, at 03:01, Terry Reedy <tjreedy@udel.edu> wrote:
On 3/8/2011 5:02 PM, Mike Meyer wrote:
Wild idea, swiped directly from haskell/ghc:
How about making the python interpreter just a little bit smarter,
It already is ;-) Though not exactly well known, expression statements that consist of a literal (number or string) are ignored -- except for string literals in docstring position (and then, they are attached as attributes, rather than being in the code object.
def f(): 'doc' # to .__doc__ 1 # ignored (1,2,3) # will not be ignored, even though constand and unused # comments are ignored 'same as comment' ''' multiline comment '''
from dis import dis dis(f)
4 0 LOAD_CONST 5 ((1, 2, 3)) 3 POP_TOP
10 4 LOAD_CONST 4 (None) 7 RETURN_VALUE
If the first non-white-space character after the shebang line (if present) is a backslash, then the compiler ignores lines until it sees a line consisting of \begin{code} (which could be the first line), then compiles lines until it sees a line consisting of \end{code}, after which it switches back to searching for \begin{code}.
So this appears unnecessary. Just use quotes.
The main problems is that program editors are generally not smart enough to do auto text wrapping within multiline strings.
-- Terry Jan Reedy
That's a far cry from lhs though (to say nothing of lit prog). Abusing doctests would be much closer to literate haskell (just about identical if you find a terse way to ignore outputs), if still a long way from knuth's literate programming.
Stephen J. Turnbull wrote:
Mike Meyer writes:
Wild idea, swiped directly from haskell/ghc:
Note that at least the Darcs people are purging literate Haskell from their code base, I'm not sure about the rationale though.
"If it was hard to write, it should be hard to read" perhaps? *wink* -- Steven
On Tue, 08 Mar 2011 21:01:25 -0500 Terry Reedy <tjreedy@udel.edu> wrote:
On 3/8/2011 5:02 PM, Mike Meyer wrote:
Wild idea, swiped directly from haskell/ghc:
How about making the python interpreter just a little bit smarter,
It already is ;-) Though not exactly well known, expression statements that consist of a literal (number or string) are ignored -- except for string literals in docstring position (and then, they are attached as attributes, rather than being in the code object.
[Examples elided]
If the first non-white-space character after the shebang line (if present) is a backslash, then the compiler ignores lines until it sees a line consisting of \begin{code} (which could be the first line), then compiles lines until it sees a line consisting of \end{code}, after which it switches back to searching for \begin{code}. So this appears unnecessary. Just use quotes.
That works fine for the '> ' variant. But the point of the \...{code} version is that the resulting source could be run through both lpython and TeX without preprocessing. How does using quotes play with TeX?
The main problems is that program editors are generally not smart enough to do auto text wrapping within multiline strings.
Emacs MMM-mode (http://www.xemacs.org/Documentation/packages/html/mmm.html) should work for this - or the two variants I suggested (switching from Python to TeX mode dynamically). <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
At the cost of an extraneous # at the beginning you can do something like this: #\def\py#1{} \py{ ...python... """#} ...TeX... \py{""" ...python... #} This isn't completely right since a } in a string or python comment will mess it up. That can be handled by a slightly more complicated definition which changes the catcodes of #, " and ' so that they in turn change the definitions of }, \ and newline. I started to write this but it's complicated so I'll leave it as an exercise. :-) (If you can't figure it out, I'll be happy to help.) --- Bruce On Wed, Mar 9, 2011 at 3:34 PM, Mike Meyer <mwm@mired.org> wrote:
On Tue, 08 Mar 2011 21:01:25 -0500 Terry Reedy <tjreedy@udel.edu> wrote:
On 3/8/2011 5:02 PM, Mike Meyer wrote:
Wild idea, swiped directly from haskell/ghc:
How about making the python interpreter just a little bit smarter,
It already is ;-) Though not exactly well known, expression statements that consist of a literal (number or string) are ignored -- except for string literals in docstring position (and then, they are attached as attributes, rather than being in the code object.
[Examples elided]
If the first non-white-space character after the shebang line (if present) is a backslash, then the compiler ignores lines until it sees a line consisting of \begin{code} (which could be the first line), then compiles lines until it sees a line consisting of \end{code}, after which it switches back to searching for \begin{code}. So this appears unnecessary. Just use quotes.
That works fine for the '> ' variant. But the point of the \...{code} version is that the resulting source could be run through both lpython and TeX without preprocessing. How does using quotes play with TeX?
The main problems is that program editors are generally not smart enough to do auto text wrapping within multiline strings.
Emacs MMM-mode (http://www.xemacs.org/Documentation/packages/html/mmm.html) should work for this - or the two variants I suggested (switching from Python to TeX mode dynamically).
<mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html Independent Software developer/SCM consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
participants (7)
-
Bruce Leban
-
Masklinn
-
Mike Meyer
-
Ryan Freckleton
-
Stephen J. Turnbull
-
Steven D'Aprano
-
Terry Reedy