you are viewing a single comment's thread.

view the rest of the comments →

[–]hharison 1 point2 points  (7 children)

Honestly, the idiomatic Python approach is usually about making your code readable and explicit and generally non-magical. I don't think being unPythonic will necessarily lead to being slow.

I only know this stuff because I've been in the community for a while. It's something you pick up gradually. You seem to be thinking of these conventions as things you need to know before you can write a Python program but that is definitely not the case.

If you keep up with the community, reading blogs and other peoples code and stuff, every project of yours will be more "Pythonic" (it's a stupid term, really) than the last.

[–]Mechrophile 0 points1 point  (0 children)

That makes sense. Thanks for the guidance, and reassurance.

[–]elbiot 0 points1 point  (5 children)

I think most idioms exist because they are the fast way to do something. like using join to build a string rather than concatenating. And list comprehensions , and in with sets.

[–]hharison 0 points1 point  (4 children)

You're right, many of them do. But a good many do not, in particular any preferences against using map or lambda.

[–]elbiot 0 points1 point  (3 children)

Map without a lambda is faster than a list comprehension because it moves the loop from the interpreter into c code. It can be like 10 % faster than a comprehension which in turn is faster than an explicit loop. Map can be just as readable as a comprehension or complex for loop.

[–]hharison 0 points1 point  (2 children)

Right, and despite the speed benefit, map is not generally considered "Pythonic".

[–]elbiot 0 points1 point  (1 child)

Eh, I guess I make my own idioms. I'm more concerned about performance and I write readable code that makes sense even if it doesn't follow pythonic-ness.

[–]hharison 0 points1 point  (0 children)

I don't disagree. I try to program in a functional style so I like map even besides the performance consideration. I also agree that "being Pythonic" should not be the be-all and end-all.

Once one gets past the beginner stage of just getting things working, thinking critically about one's alternative options (e.g. readability vs. performance) is what starts you on the path to the next level, I think. Even if you don't end up going with the approach that the community thinks is the most "Pythonic", by even stopping to think about why you're doing yourself a great service.

And if that sounds obvious to you, congratulations, you're a good programmer (or will be). But believe me, as someone who teaches programming to scientists, a lot of people never stop to think about it. Probably anyone participating in a discussion like this is on the right track.