Teaching Programming
in [Python]
|
From: alex23 on 4 May 2010 20:47 Ed Keith <e_...(a)yahoo.com> wrote: > Knuth wanted the generated source to be unreadable, so people would not be tempted to edit the generated code. This is my biggest issue with Knuth's view of literate programming. If the generated source isn't readable, am I just supposed to trust it? How can I tell if an error lies in my expression of the algorithm or in the code generation itself?
From: Dave Angel on 5 May 2010 04:50 alex23 wrote: > Ed Keith <e_...(a)yahoo.com> wrote: > >> Knuth wanted the generated source to be unreadable, so people would not be tempted to edit the generated code. >> > > This is my biggest issue with Knuth's view of literate programming. If > the generated source isn't readable, am I just supposed to trust it? > How can I tell if an error lies in my expression of the algorithm or > in the code generation itself? > > Do you think a compiler is required to make its object file conveniently readable? Do you regularly read the machine code generated by your C compiler? I admit I've frequently studied compiler output over the years, but I think I'm very unusual in that respect. I've never disassembled a python byte code file, though I wrote tools to display and manipulate both java byte code files and dot-net (before it was called that). I think the question really boils down to whether you trust the compiler. DaveA
From: Terry Reedy on 5 May 2010 14:03 On 5/5/2010 4:50 AM, Dave Angel wrote: > alex23 wrote: >> Ed Keith <e_...(a)yahoo.com> wrote: >>> Knuth wanted the generated source to be unreadable, so people would >>> not be tempted to edit the generated code. >> >> This is my biggest issue with Knuth's view of literate programming. If >> the generated source isn't readable, am I just supposed to trust it? >> How can I tell if an error lies in my expression of the algorithm or >> in the code generation itself? >> > Do you think a compiler is required to make its object file conveniently > readable? Do you regularly read the machine code generated by your C > compiler? I admit I've frequently studied compiler output over the > years, but I think I'm very unusual in that respect. I've never > disassembled a python byte code file, The output from dis.dis() is quite readable, and people (developers and others) have used it to check on what the compiler is doing.
From: Martin P. Hellwig on 5 May 2010 18:01 On 05/04/10 12:59, superpollo wrote: > Martin P. Hellwig ha scritto: <cut> >> For the corner cases (I can think of a couple) it is good to know you >> can use ';' most of the time. >> > > most but not always as i noted (think about loops or function definition) > Well through in some exec magic then, for example: for number in [1,2,3,4]: def nprint(number): print(number) number += 1 nprint(number translates to: >>> exec('for number in [1,2,3,4]:\n\tdef nprint(number):\n\t\tprint(number)\n\tnumber += 1\n\tnprint(number)') 2 3 4 5 But if you have an example why indentation is still a problem please give it :-) -- mph
From: superpollo on 5 May 2010 18:10
Martin P. Hellwig ha scritto: > On 05/04/10 12:59, superpollo wrote: >> Martin P. Hellwig ha scritto: > <cut> >>> For the corner cases (I can think of a couple) it is good to know you >>> can use ';' most of the time. >>> >> >> most but not always as i noted (think about loops or function definition) >> > Well through in some exec magic then, for example: > for number in [1,2,3,4]: > def nprint(number): > print(number) > number += 1 > nprint(number > > translates to: > > >>> exec('for number in [1,2,3,4]:\n\tdef > nprint(number):\n\t\tprint(number)\n\tnumber += 1\n\tnprint(number)') > 2 > 3 > 4 > 5 > > But if you have an example why indentation is still a problem please > give it :-) > i think your exec example solved most of my problems. thanks a lot. bye |