Python arrays and sting formatting options

Fri Oct 3 05:19:29 EDT 2008

I'm not sure if our views are moving closer together or further apart, 
but here goes... 

On Thu, 02 Oct 2008 23:49:16 +0000, Marc 'BlackJack' Rintsch wrote:

> On Thu, 02 Oct 2008 14:51:29 +0000, Steven D'Aprano wrote:
> 
>> On Wed, 01 Oct 2008 10:38:12 +0000, Marc 'BlackJack' Rintsch wrote:
>> 
>>> 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."
> 
> It's not cargo cult programming if you tell people to use the ``with``
> statement to make sure the file will be closed after the block is left,
> for whatever reason the block was left.

You are right. If you explain what "with" blocks do, it isn't cargo cult 
programming. 

>>> 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.
> 
> My intention wasn't to teach the OP how to write Python but to give a
> concise, easy and straight forward solution in Python.  Yes, I really
> believe I have written such thing.  I'm well aware that a Fortran
> programmer will not understand this without learning Python.

I'm curious what the point of answering the OP's question was if you knew 
he wouldn't understand the answer. You might have saved us both a lot of 
time if you started your post with "You aren't expected to understand 
this".

>> 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.
> 
> If he doesn't know enough basic Python techniques to solve *a simple
> problem* I think this is the wrong forum and he should work through the
> tutorial from the documentation to learn the basics first.  The tutorial
> includes `map()`, list comprehensions, methods in strings, the fact that
> files are iterable, and generator expressions.

Then you should have said so.

>> [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.
> 
> Of course it means they are the same "things", that is what duck typing
> is about.

No, you still don't understand me. Let me give you a more extreme example 
to help clarify:

average_age = 64.7
width_of_page = 20.2
speed_of_car = 35.2
concentration_of_acid = 1.03
children_per_family = 2.3

All of the above have not just the same duck-type, but the same actual 
type (floats), and yet they are COMPLETELY different things. Imagine a 
piece of code like this:

def foo():
    x = 64.7  # x is the average age of a person
    ... more lines of code here
    x = 2.3  # x is now the average number of children per family
    ...
    return something

Would you defend the above code on the basis that x had the same duck-
type in both places? I hope not.

A decade or so ago, one of the Mars spaceships crashed because a coder 
used a variable that was a float in inches when they were supposed to use 
a variable that was a float in millimetres (or vice versa, I forget). 
Because of this mistake, the retro-rockets fired too late, and the 
spaceship flew into the surface of Mars at some thousands of miles an 
hour. And yet both variables were not just the same duck-type, but the 
same actual type. You cannot conclude that two things are the same kind 
of thing just because they have the same type.

The difference between the above and re-using the same variable for 
lines_of_text_before_filtering and lines_of_text_after_filtering is one 
of degree.

Now, in practice, I personally think that what you did was perfectly 
acceptable. I do it myself. I think the coders who refuse to EVER re-use 
variables in a code block are being over-strict. But I am aware that the 
cost of re-using variables is to increase the risk of confusing the two 
different meanings of the variable name.

When I'm reading code within the boundaries of my understanding, that 
risk is tiny. But when I'm reading code that is complicated or in a 
language I don't understand, then the risk is magnified greatly. That's 
all I was trying to get across.

I don't think I'm making an unreasonable claim.

[snip]

> Yes, but that's not what Python is all about.  I use it for programming
> and not for writing code with the primary goal to be newbie friendly or
> pseudo code like.

I never suggested that being newbie friendly was the only acceptable use 
of Python. But I think that when you are replying to a newbie's direct 
question, there are only two ways to answer: newbie-friendly, or newbie-
hostile. 

-- 
Steven