Teaching Programming
in [Python]
|
From: Chris Rebert on 4 May 2010 12:13 On Tue, May 4, 2010 at 8:52 AM, Stefan Behnel <stefan_ml(a)behnel.de> wrote: > Ed Keith, 04.05.2010 17:43: >> The PITA is having to keep track of the indentation of each embedded >> chunk and summing it for each level of indentation. This requires a fair >> amount of bookkeeping that would not otherwise be necessary. >> >> The original prototype simply replaced each embedded chunk with the text >> from the chunk definition, all indenting information was lost. It worked >> for most languages, but not Python. >> >> In testing the program I used two languages, Python and J. > > Well, then both of the language generators have benefited from your effort > because the generated complete code is properly indented and therefore much > more readable during debugging. I'd say it was worth it. Though there are auto-re-indenting programs for curly-brace languages you know. Cheers, Chris -- http://blog.rebertia.com
From: Terry Reedy on 4 May 2010 12:15 On 5/4/2010 8:46 AM, superpollo wrote: > but i do not think i can use it myself, since my template system wants > the input to generate the code to stay on a single line ( don't ask :-( ) I think we can agree that Python (unlike C, for instance) is not good for writing non-humanly-readable one-unbounded-length-line code. That is contrary to its design goal. But I would think that you would have similar problems with other manditorily multiline languages, like Fortran and Basic. Terry Jan Reedy
From: Dave Angel on 4 May 2010 12:22 Ethan Furman wrote: > <div class="moz-text-flowed" style="font-family: -moz-fixed">Andre > Engels wrote: >> On Tue, May 4, 2010 at 4:35 PM, James Mills >> <prologic(a)shortcircuit.net.au> wrote: >>> On Wed, May 5, 2010 at 12:21 AM, Ed Keith <e_d_k(a)yahoo.com> wrote: >>>> To deal with indentation I had to >>>> >>>> 1) keep track of indentation of all chunks of code embedded in the >>>> document and indent inserted chunks to the sum of all the >>>> indentation of the enclosing chunks. >>> In my experience of non-indentation sensitive languages >>> such as C-class (curly braces) it's just as hard to keep track >>> of opening and closing braces. >> >> Although I have little or no experience with this, I still dare to say >> that I don't agree. The difference is that in C you do not _need_ to >> know where in the braces-defined hierarchy you are. You just embed or >> change a piece of code at the right location. In Python however you >> _do_ need to know how far your code is to be indented. > > And how do you know where the right location is? You have to figure > it out from the different (nested) braces at the 'right' location. > For me, at least, it's much easier to get that information from the > already indented Python code, as opposed to indenting (and > double-checking the indents) on the braces language. > > ~Ethan~ > > Much more important to be able to read code reliably than write it quickly. When I was heavily doing C++ I found myself wishing that incorrect indentation would be an error or at least a warning. And I hadn't ever heard of Python. When I did, I said "About time!" Of course, I was surrounded by many programmers who ignored any warning that the compiler produced, while I cranked up warnings to max, with pedantic. On one project I generated C++ code, about 20k lines. And it was all indented and commented. Most of that code went through the code generator twice. The "source" was a header file from outside my organization. The generator used that to create a new header, more detailed. Then the generator used that to create source & headers that were actually used by the project. DaveA
From: Gary Herron on 4 May 2010 12:23 Terry Reedy wrote: > On 5/3/2010 7:46 PM, cjw wrote: > >> Nobody likes indentation at first, > > Speak for yourself, please. For two decades before I met Python, I > indented code nicely whenever it was allowed. That option was one of > the great advancements of Fortran77 over FortranIV. Coming from C, I > was immediately glad to be done with those darn braces. > > tjr > Right. Somewhere in the 80's I read a paper in sigplan which demonstrated that indentation-only was sufficient to communicate the structure of a program. I immediately *knew* that was the right way to go. Sadly, I had to wait a decade or so before discovering Python in the mid 90's, but I never forgot that paper nor lost my eager anticipation waiting for language design to catch up with that idea. Gary Herron
From: Stefan Behnel on 4 May 2010 12:30
superpollo, 04.05.2010 17:55: > since i have some kind of computer literacy (as opposed to most of my > colleagues), some years ago i was kindly asked to try and solve a > "simple" particular problem, that is to write a program that generates > math exercises (q+a) from an example taken from the textbook. for > instance, this: > > %%TITLE:Sample worksheet > %% > %%SCHEMA:\lim_{x \to <A>} > %%SCHEMA:\frac > %%SCHEMA:{x^3-<A-B>x^2-<AB>x} > %%SCHEMA:{x^3-<A>x^2+<C>x-<AC>}\\ > %% > %%ANS:FRAC > %%ANSNUM:<A^2+AB> > %%ANSDEN:<A^2+C> > %% > %%AMIN:1 > %%AINC:1 > %%AMAX:2 > %%BMIN:3 > %%BINC:1 > %%BMAX:4 > %%CMIN:2 > %%CINC:1 > %%CMAX:3 > > should generate this latex source document: > > \documentclass[a4paper,10pt,twocolumn,fleqn]{article} > \title{Sample worksheet} > \pagestyle{empty} > \usepackage[italian]{babel} > \usepackage{amsmath} > \usepackage{amssymb} > \usepackage{cancel} > \usepackage{mathrsfs} > \usepackage[dvips]{graphicx} > \usepackage{eurosym} > \usepackage{pstricks} > \usepackage{pst-eucl} > \usepackage{pst-poly} > \usepackage{pst-plot} > \frenchspacing > \begin{document} > \section*{\center{\framebox{Sample worksheet}}} > \noindent > \begin{enumerate} > \item > \begin{multline*} > \lim_{x \to 1} > \frac > {x^3+3x^2-4x} > {x^3-x^2+2x-2}\\ > \end{multline*} > \item > \begin{multline*} > \lim_{x \to 2} > \frac > {x^3+x^2-6x} > {x^3-2x^2+2x-4}\\ > \end{multline*} > \item > \begin{multline*} > \lim_{x \to 2} > \frac > {x^3+2x^2-8x} > {x^3-2x^2+2x-4}\\ > \end{multline*} > \item > \begin{multline*} > \lim_{x \to 1} > \frac > {x^3+2x^2-3x} > {x^3-x^2+2x-2}\\ > \end{multline*} > \item > \begin{multline*} > \lim_{x \to 1} > \frac > {x^3+2x^2-3x} > {x^3-x^2+3x-3}\\ > \end{multline*} > \item > \begin{multline*} > \lim_{x \to 1} > \frac > {x^3+3x^2-4x} > {x^3-x^2+3x-3}\\ > \end{multline*} > \item > \begin{multline*} > \lim_{x \to 2} > \frac > {x^3+x^2-6x} > {x^3-2x^2+3x-6}\\ > \end{multline*} > \item > \begin{multline*} > \lim_{x \to 2} > \frac > {x^3+2x^2-8x} > {x^3-2x^2+3x-6}\\ > \end{multline*} > \end{enumerate} > \subsection*{\center{Answers}} > \begin{enumerate} > \item > \begin{displaymath} > \frac{5}{3} > \end{displaymath} > \item > \begin{displaymath} > \frac{5}{3} > [...] I'm not exactly sure I understand the mapping between the two formats, but it seems to me that you'll need a proper math expression parser (with a strong emphasis on *parser*) for this. Math expressions are not exactly trivial (recursion, prefix/infix/postfix notations, functions), which is why 'real' programmers don't write parsers for them but download tested, working code for that from somewhere. > another thing is that for some features i intended to include i found > convenient to use python (since it's the language i feel i am more at > ease with), so i had to cope with template lines like this: > > %%SCHEMA:<PYCODE1:import math ; print int(math.sqrt($A**2-2.*$A*$B))> You should assure that the math module is always imported, and otherwise restrict the expressiveness to expressions (terms that result in a value), not arbitrary statements (executable commands that do things without returning anything). > to make a long story short: the whole program is now 4775 lines of bash > code, Argh! > *but* it was and it is a wonderful experience to learn to program It does sound like you almost completely skipped over two very important programming lessons, though: reading code is harder than writing it (i.e. maintenance cost matters), and the best code is the code that you don't need to write (and debug and maintain). Stefan |