Python arrays and sting formatting options

[Marc 'BlackJack' Rintsch]

On Tue, 30 Sep 2008 23:40:22 +0000, Steven D'Aprano wrote:

> On Tue, 30 Sep 2008 14:34:31 +0000, Marc 'BlackJack' Rintsch wrote:
> 
>> There is no array.  The data type is called "list" in Python, so
>> `result` is a nested list.  And in Python it quite unusual to build
>> lists by creating them with the final size filled with place holder
>> objects and then fill the real values in.  Instead lists are typically
>> created by appending values to existing lists, using list comprehension
>> or the `list()` function with some iterable object.
> 
> I would weaken that claim a tad... I'd say it is "usual" to write
> something like this:
> 
> alist = []
> for x in some_values:
>     alist.append(something_from_x)
> 
> 
> but it is not uncommon (at least not in my code) to write something like
> this equivalent code instead:
> 
> alist = [None]*len(some_values)
> for i, x in enumerate(some_values):
>     alist[i] = something_from_x

I have never done this, except in the beginning I used Python, and -- 
maybe more importantly -- I've never seen this in others code.  I really 
looks like a construct from someone who is still programming in some 
other language(s).

> Most often the first way is most natural, but the second way is
> sometimes more natural.

When will it be more natural to introduce an unnecessary index?

> And Marc, I think you're being a little unfair to the OP, who is clearly
> unfamiliar with Python. I've been using Python for perhaps ten years,
> and I still find your code above dense and hard to comprehend. It uses a
> number of "advanced Python concepts" that a newbie is going to have
> trouble with:
> 
> - the with statement acts by magic; if you don't know what it does, it's
> an opaque black box.

Everything acts by magic unless you know what it does.  The Fortran

  read(*,*)(a(i,j,k),j=1,3)

in the OP's first post looks like magic too.  I admit that my code shows 
off advanced Python features but I don't think ``with`` is one of them.  
It makes it easier to write robust code and maybe even understandable 
without documentation by just reading it as "English text".

> - you re-use the same name for different uses, which can cause
> confusion.

Do you mean `lines`?  Then I disagree because the (duck) type is always 
"iterable over lines".  I just changed the content by filtering.

> - generator expressions.
> 
> - functional programming using partial.
> 
> - you call a function that uses a list comprehension with both map and
> iterator slicing inside it.
> 
> 
> No wonder the OP had trouble with it. *I* have trouble with it, and
> would need to sit down at the interactive interpreter and play around
> with it for a while to be sure what it actually does. If it was your
> intention to make Python look as obtuse and mysterious as possible, you
> almost succeeded. The one things you missed was to replace the
> read_group function with a lambda in the partial.

Well that would make the code harder to understand.  ;-)

Serious, I think it should be easy to understand the code for someone who 
knows Python.  Yes a newbie will have trouble to understand this, but 
Python is not Fortran and IMHO I haven't used something really exotic or 
strange nor did I wrote convoluted and hard to understand things like 
deeply nested list comprehensions.

Ciao,
	Marc 'BlackJack' Rintsch