reduce to be removed?

[Steve Holden]

Dustan wrote: [...]
Repeat after me:

"Not everything has to be a one-liner."

Not everything has to be a one-liner. But readability helps.

Indeed. And there is absolutely no conflict between those two statements.

Guido resisted introducing tertiary expressions for as long as he did
precisely because he realised that some people would use them to produce
unreadable one-liners instead of readable multi-line expressions of the
same idea.

regards
Steve

 

[Steve Holden]

Alright, I can see I'm a bit outvoted here. I tried your suggestions
and it worked fine.

I'll also try to consider in the future that part of the problem might
be lack of information conveyed on my part.

Well, since such honest and public self-examination is so rarely seen
(especially in the face of the effbot's occasional vehement bluntness)
allow me to congratulate you on your open-mindedness.

Sometimes it seems like "egoless programming" went out with the 1980's.
I'm sure I'll enjoy reading your future posts.

regards
Steve

 

[Steve Holden]

Anyway, I figured out a way to get the builtin
function 'sum' to work as I need:
sum([[1,2,3],[4,5,6],[7,8,9]], [])

Hah!
No-one expects sum to be used on anything but numbers.

Except lists as above.

No-one expects sum to be used on anything but numbers, and maybe lists
too.

;-)

[voice mumbles:] "What about tuples"

Right, tuples too. But apart from tuples and lists, nobody expects sum
to be used on anything but numbers.

In actual fact when Alex Martelli introduced sum() he intended it to be
polymorphic over all the container types including strings. The check to
exclude the string case was added when it was determined that it was
terribly inefficient to concatenate strings that way. the same may well
apply to other sequences.

I suppose it's only a matter of time before someone wants to define
dict.__add__ ...

regards
Steve

 

[Fredrik Lundh]

In actual fact when Alex Martelli introduced sum() he intended it to be
polymorphic over all the container types including strings. The check to
exclude the string case was added when it was determined that it was
terribly inefficient to concatenate strings that way. the same may well
apply to other sequences.

an important difference is that if you repeatedly copy a string object,
you'll actually copy *all* data in the string over and over again. when
you copy a list, you only copy references to the objects in the list.
the size of the data *in* the list doesn't matter.

I suppose it's only a matter of time before someone wants to define
dict.__add__ ...

that's been proposed quite a few times, and always gets stuck when it's
time to define the exact semantics for dealing with collisions. there
are simply too many ways to do it, and all of them are can be trivially
and efficiently implemented in terms of copy/update or for-in (or, in
quite a few cases, by using sets instead of dicts).

</F>

 

[Steve Holden]

Steve Holden wrote: [...]

I suppose it's only a matter of time before someone wants to define
dict.__add__ ...

that's been proposed quite a few times, and always gets stuck when it's
time to define the exact semantics for dealing with collisions. there
are simply too many ways to do it, and all of them are can be trivially
and efficiently implemented in terms of copy/update or for-in (or, in
quite a few cases, by using sets instead of dicts).

But, as we both know, the fact that something can be trivially
implemented in Python doesn't stop people asking for it to be added as
native.

oh-no-indeed-ly y'rs - steve

 

[Kay Schluehr]

if you care about writing robust code, why not just use a for-loop,
and the list extend method?

</F>

Because generic solutions using HOFs increase abstraction and reduce()
the amount of code one has to write even when they are outcasted by
Guido?

 

[Dustan]

Alright, I can see I'm a bit outvoted here. I tried your suggestions
and it worked fine.

I'll also try to consider in the future that part of the problem might
be lack of information conveyed on my part.

If you insist on one-liners, it can be done without sum(), though it
probably doesn't buy you much in readability:

from itertools import chain
[list(chain(*row)) for row in foo]

By the way, if this was not a toy example and you're doing serious work
with n-dimensional arrays, make yourself a favor and install NumPy;
it's usually both faster and more elegant for array manipulations than
pure python.

1. I've already written pretty much all the code, and a complete
rewrite would be rather difficult.

2. While I haven't taken a good look at NumPy, my intuition tells me it
won't work with complex data types, which wouldn't work for me at all.

Am I correct on that second one?

 

[Robert Kern]

2. While I haven't taken a good look at NumPy, my intuition tells me it
won't work with complex data types, which wouldn't work for me at all.

Am I correct on that second one?

No. numpy can make arrays of Python objects in addition to arrays of double,
unsigned int, etc.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[Antoon Pardon]

No. numpy can make arrays of Python objects in addition to arrays of double,
unsigned int, etc.

Does numpy still gain you much if you have arrays of Python objects?

 

[Robert Kern]

Does numpy still gain you much if you have arrays of Python objects?

It depends on what you want out of it. You won't get fast math, but you will get
convenient multidimensional indexing, slicing, stacking, reshaping, and
transposition.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco