Python arrays and sting formatting options

[Steven D'Aprano]

On Wed, 01 Oct 2008 10:38:12 +0000, Marc 'BlackJack' Rintsch wrote:

>> The first problem with "with" is that it looks like the Pascal "with"
>> statement, but acts nothing like it. That may confuse anyone with
>> Pascal experience, and there are a lot of us out there.
> 
> But Python is not Pascal either.  Nonetheless a Pascal coder might guess
> what the ``with`` does.  Not all the gory details but that it opens a
> file and introduces `lines` should be more or less obvious to someone
> who has programmed before.

But that's not what the with statement does. It doesn't open a file and 
it doesn't introduce lines. That's what open() does. So what you say is 
"obvious" is actually wrong. To a newbie who knows nothing about context 
managers, the statement 

with open(filename) as lines

will look like "syntactic fat" (like syntactic sugar but harder to digest 
and more fattening) for the simpler code:

lines = open(filename)



[snip]
> Even if newbies don't understand all the details they should be 
> introduced to ``with`` right away IMHO.  Because if you explain all the 
> details, even if they understand them, they likely will ignore the 
> knowledge because doing it right is a lot of boiler plate code.  So 
> usually people write less robust code and ``with`` is a simple way to 
> solve that problem.

So what you're saying is that we should encourage cargo-cult coding. 
"Write this boilerplate, because I tell you that if you do, good things 
will happen."

Newbies aren't going to be writing robust code anyway. The ability to 
write robust code is one of the things which distinguishes experienced 
coders from newbies. If they don't understand what the code is actually 
doing, they're going to make mistakes like these:

import urllib2
try:
    result = urllib2.open('http://www.python.org')
except IOError, URLError:
    print "Can't reach website"
except HTTPError:
    print "Page not found"




[much more snippage]

> Why on earth has everything to be guessable for someone who doesn't
> know Python or even programming at all?

Oh please. Don't take my words out of context. I'm not talking about 
"everything", and I'm not suggesting that advanced programming features 
should be prohibited and we should write to the level my grandmother 
would understand.

The context was that a Fortran programmer asked for some help in writing 
a piece of code in Python. Your answer was entirely opaque and 
undecipherable to the OP. If your intention in answering was to teach the 
OP how to write Python code, you failed, because the OP couldn't 
understand your code! You can argue with me until Doomsday and it won't 
change that basic fact.

Your answer may have solved the OP's *technical* problem, but it didn't 
do anything to solve the OP's *actual* problem, which was that he didn't 
know enough basic Python techniques to solve a simple problem. And that's 
the issue I was commenting on.


[more snippage]
> > Nevertheless, for people coming from less dynamic languages than
> > Python (such as Fortran), it is a common idiom to never use the same
> > variable for two different things.  It's not a bad choice really:
> > imagine reading a function where the name "lines" started off as an
> > integer number of lines, then became a template string, then was used
> > for a list of character positions...
> 
> Which I'm not doing at all.  It has the same duck type all the time: 
> "iterable of lines".

It has nothing to do with duck typing and everything to do with re-use of 
variables (or in Python, names) for different "things". Just because 
"lines" has the same duck-type doesn't mean they are conceptually the 
same things. If they were, the assignments would be null-ops.

There is a programming principle that says never re-use variables. It 
makes it harder for the programmer to figure out what the variable 
represents and for some languages, it can defeat compiler optimizations.

Now, I personally wouldn't treat this principle as a law. I'd treat it as 
a guideline with just as many exceptions as examples. But there's no 
doubt in my mind that reuse of names can lead to hard to understand code, 
particularly if the reader is not used to the language and is already 
struggling to understand it.


[snippity snip]
> *I* think I would do Python a disservice if I encourage people to 
> continue writing Python code as if it where language X or pretending 
> Python is all about "readable, executable Pseudocode for anyone". 

There's no "pretending". Python is excellent for writing readable, 
executable pseudo-code for anyone. With Python 3.0, GvR had the 
opportunity to strip Python of all the features that makes Python easy to 
learn, and he didn't. Python still has features that are easy for 
newbies, and features that are powerful for experienced coders, and that 
friendliness for newbies isn't going away. That's a good thing.



-- 
Steven