4 ms·

Thanks for the critique. I'm not sure I added much to that analysis on Stack Overflow outside of headers, a few more opinions, and a little bit more explanation

by th 11y ago

Thanks for the critique. I'm not sure I added much to that analysis on Stack Overflow outside of headers, a few more opinions, and a little bit more explanation. I mostly wrote to have something to link my students to because this question has come up before and I didn't find any of the more comprehensive SO answers to be easily digestible/skim-able. The python-ideas thread from last year about using + on dictionaries was also an inspiration. I don't recommend reading it in full (there's some painful debating) but there were some really interesting concerns brought up on there in regards to this particular problem. In regards to newcomers being scared away by criticism on Stack Overflow: I completely sympathize with this point of view. New Python programmers and new programmers especially should not worry about what is "pythonic" until they've become comfortable with their own Python programming abilities. Working and readable code is most important, idiomatic code is simply icing on the cake. I do however value discussions of what is "pythonic". I often discuss "pythonic" in my classes to instill the idea that community norms change from language to language and even between frameworks and projects. I really hope the wording of this post didn't come off as elitist. If so, I will certainly need to reconsider my wording for the next one.

p4wnc6 11y ago
You do not come off as elitist in any way. Having your write-up available for your students makes perfect sense, though I don't know that posting it to Hacker News will result in much (but it doesn't seem like your target audience anyway). I think "pythonic" is a slippery slope. Many people take it too far and begin to develop militant ideas of what "readability" means, or they do silly things. For instance, I once heard a tale about someone needing to create their own toolkit for handling paths in a certain project. It was just going to a wrapper around the usual os.path tools, but would factor out a lot of the team's repetitive code. That person actually implemented __abs__ so that "abs(p)" resulted in the absolute path for the path object p. Ugh! The justification was that this is supposed to be more "pythonic" than just writing a simple helper function. And of course, if you say that the documentation about Python idioms or accepted understandings of what is "pythonic" don't have anything to do with the choice to implement something as a special method, the other person's response is just "yes it does" -- their interpretation is that this is what pythonic means. It's like having an interpretation debate about the Bible or something. It means something different to everyone, which makes it pretty useless as a centralized standard. If you apply good Haskell style, or good C style, or good Java style, to writing Python, your code will be absolutely fine and perfectly readable even in large enterprise codebases (perhaps more so depending on who else reads it). I think Google's C++ guide has the right idea. You should follow the local conventions of the piece of code you're editing. If you're working in a Python module where someone puts every function argument on a new line (even if you're not near the 80 char limit) like this def foo(arg1, arg2, ...): # ... then you should just also do that, and not waste time about whether this is more Pythonic def foo(arg1, arg2, arg3, ...): I think if the Python community trumps up this idea of pythonic, it just alienates other people whose natural style (or the guides to their own main languages) tell them differently. Over time, Python developers will learn when it's better to use map than a comprehension, how to style things, how avoid doing needlessly complicated things like the __abs__ example above. You don't have to drill "pythonic" stuff into them for that sort of clean code common sense to emerge, and you certainly don't need to make it a major point of community pride or identity.

by th 11y ago

p4wnc6 11y ago

You do not come off as elitist in any way. Having your write-up available for your students makes perfect sense, though I don't know that posting it to Hacker News will result in much (but it doesn't seem like your target audience anyway). I think "pythonic" is a slippery slope. Many people take it too far and begin to develop militant ideas of what "readability" means, or they do silly things. For instance, I once heard a tale about someone needing to create their own toolkit for handling paths in a certain project. It was just going to a wrapper around the usual os.path tools, but would factor out a lot of the team's repetitive code. That person actually implemented __abs__ so that "abs(p)" resulted in the absolute path for the path object p. Ugh! The justification was that this is supposed to be more "pythonic" than just writing a simple helper function. And of course, if you say that the documentation about Python idioms or accepted understandings of what is "pythonic" don't have anything to do with the choice to implement something as a special method, the other person's response is just "yes it does" -- their interpretation is that this is what pythonic means. It's like having an interpretation debate about the Bible or something. It means something different to everyone, which makes it pretty useless as a centralized standard. If you apply good Haskell style, or good C style, or good Java style, to writing Python, your code will be absolutely fine and perfectly readable even in large enterprise codebases (perhaps more so depending on who else reads it). I think Google's C++ guide has the right idea. You should follow the local conventions of the piece of code you're editing. If you're working in a Python module where someone puts every function argument on a new line (even if you're not near the 80 char limit) like this def foo(arg1, arg2, ...): # ... then you should just also do that, and not waste time about whether this is more Pythonic def foo(arg1, arg2, arg3, ...): I think if the Python community trumps up this idea of pythonic, it just alienates other people whose natural style (or the guides to their own main languages) tell them differently. Over time, Python developers will learn when it's better to use map than a comprehension, how to style things, how avoid doing needlessly complicated things like the __abs__ example above. You don't have to drill "pythonic" stuff into them for that sort of clean code common sense to emerge, and you certainly don't need to make it a major point of community pride or identity.