Guido tried to kill these functions over a decade ago, argh, heh.
Nicola Soranzo
@nsoranzo
Also, if you run 2to3 on Python2 code, it will change map(lambda:..., l) to a list comprehension, but map(f, l) to list(map(f, l))
Ghost
@ghost~5772e7e2c2f0db084a206e1b
meh, our performance bottlenecks are not list comprehension vs map ... I'd say the list comprehension looks better to me
Dannon
@dannon
Right, we're talking about saving a handful of microseconds here I think.
Nicola Soranzo
@nsoranzo
Yup, I think it comes down to personal preferences, John seems to use map() a lot for example
And map(str, l) seems quite readable
Dannon
@dannon
map(str, l) is, sure, but the statements are rarely that simple.
Nicola Soranzo
@nsoranzo
That was the case here, no?
Dannon
@dannon
list(map(str, range(1, MAX_DEFAULT_COLUMNS + 1)))
Three parens deep.
Aysam Guerler
@guerler
I liked the map statement but then again its not critical.
lol
Nicola Soranzo
@nsoranzo
Still shorter than using the list comprehension :D
Dannon
@dannon
Yeah, this is a minor point, I was just curious about the logic. I had seen a ton of the list(map(* functional approach in the py3 conversions, and was somewhat concerned about a shift towards more functional nesting that's harder to read, in general.
Anyway, I'm going to leave the python styleguiding to you guys and get back to javascript land.
Nicola Soranzo
@nsoranzo
Anyway, I don't mind either way, I just don't think we need a standard for that, both syntax are widely used in our codebase
Aysam Guerler
@guerler
I definitely agree.
Dannon
@dannon
Well, they are now, at least ;)
Aysam Guerler
@guerler
And thanks for the review.
Nicola Soranzo
@nsoranzo
As mentioned above, for the Py3 conversion I generally stuck to what 2to3 suggested. I didn't introduce any new map()
Dannon
@dannon
I wasn't implying you did anything wrong, sorry.
In general, do you think python syntax is shifting more functional though?
Things like next(iter(mylist)) instead of mylist[0], etc.
Nicola Soranzo
@nsoranzo
You probably refer to d.keys()[0]-> next(iter(d.keys()))
_
Dannon
@dannon
Right. I'm not asking about any specific changes, though, or even the Galaxy codebase here. I'm just talking Python in general.
Nicola Soranzo
@nsoranzo
which is a workaround needed to support both Python2 (where d.keys() is not an iterator) and Python3 where dict_keys does not support indexing
Dannon
@dannon
(I realize why we now do next(iter(..), it just feels unfortunate)
Nicola Soranzo
@nsoranzo
Surely many methods return iterables instead of lists in Python3, not sure if that's a shift towards functional programming or just trying to be efficient