[djur]

Not having touched Python for many years, four things jump out at me:

1) .format, which isn't immediately familiar and doesn't resemble similar string formatters in other languages 2) [1:], which I believe is a string slicing syntax that doesn't resemble similar syntax in other languages 3) Bug: nothing is done with the capitalized words, since the return value is thrown away 4) Bug: the name of the function was misspelled when used.

The last one may seem like a nitpick, but it is true that when you add a name to your code for the sake of clarity, you also take on the additional burden of ensuring the name is used consistently and accurately everywhere. This can be a particular pain in cases where you are generating a lot of uninteresting temporary values -- which is precisely why people end up writing chained function or method calls.

[cookiecaper]

Point 1 is conceded in my earlier response. You're right that someone who is unfamiliar with Python is going to be stopped by the format syntax. However, it's simple to acclimate and learn the basics of it and is something that is very pervasive in Python code and is one of the safest ways to interpolate string data, so its use is justified.

Point 2, this type of string slicing syntax is pretty common in languages similar to Python. A very similar syntax exists in Ruby and Perl. See https://en.wikipedia.org/wiki/Array_slicing for more examples of slice shorthand in the wild.

Point 3. I didn't intend to rewrite the whole thing again, just enough to demonstrate my problems with the reply's lambda-based approach. This is indicated by the ellipsis. If I were to create a full version instead of the quick demonstration of the more-clear full function definition here, then yes, I would've assigned the output of the function to something.

4. Conceded.

[djur]

OK, but that doesn't seem much different from "code written in Python should be written in a style familiar to Python developers", which is a good principle regardless of the language. In Ruby, the use of Enumerable methods is generally preferred; it would be as "surprising" to use a for loop in this case as it would be to use map in Python.

I also don't see a good argument that string slicing, `for ... in` and Python-style string formatters are more "universal" than lambdas and map/filter/reduce. All of them exist in large subsets of commonly used programming languages; all of them are used heavily in some languages and rarely in others; only one of them (in the form of sprintf) exists in C.

[cookiecaper]

> OK, but that doesn't seem much different from "code written in Python should be written in a style familiar to Python developers", which is a good principle regardless of the language. In Ruby, the use of Enumerable methods is generally preferred; it would be as "surprising" to use a for loop in this case as it would be to use map in Python.

Yes, ultimately, it's a judgment call about the degree to which language-specific caveats and conventions are considered substantially beneficial to justify their introduction.

I will, however, state that I hate that Ruby uses .each instead of for. I do use .each when I write Ruby because as you stated, most Ruby devs will look at you sideways if you used a real for loop, but I really dislike that it's become that way. That's an example of something that's different just for differences sake; any benefit derived from it is marginal and corner-case (something like wanting to override the standard Enumerable behavior), and it makes the whole thing more insular (meaning the behavior is difficult to generalize or extrapolate beyond Ruby, you have to look up the specific behavior), less friendly (meaning it draws attention to itself and takes away productive time; when your code style does this, it needs good justification), and harder to read (because of the two preceding points). IMO, that's a tradeoff that wasn't worthwhile.

>I also don't see a good argument that string slicing, `for ... in` and Python-style string formatters are more "universal" than lambdas and map/filter/reduce. All of them exist in large subsets of commonly used programming languages; all of them are used heavily in some languages and rarely in others; only one of them (in the form of sprintf) exists in C.

Again, it's about being as minimally disruptive to the typical programmer that would be reading the code as possible. While map/filter/reduce may exist in some form in most languages, they're not very commonly used by programmers with an imperative background. Languages like Python have formatting rules that make them harder to read than their language-construct counterparts like for, and while most other imperative languages won't enforce specific formatting rules and preclude the programmer from formatting his code such that map's iteration is equally visually obvious as a for loop's typical indentation and/or bracing, it'd be difficult and unusual to maintain them.

String slicing is a very common need and most languages provide a simple way to perform it, whether it's the slicing shorthand or substr() calls. You're right that C doesn't provide tools for this, but C doesn't even recognize the string as a thing; you just work with groups of chars. The programming community has clearly repudiated that philosophy and demonstrated that it expects its languages to do most of the string dirty work directly. Same goes for string formatters, even though, as I've stated 3 times now, Python's is unfortunately a bit anomalous for not much benefit. This is improved with PEP 498.

"for in" is a nearly self-evident and easy to remember. While this may or may not differ slightly from the specific syntax used in other Python-style languages, it's fairly obvious to someone who is familiar with that language class, and easy enough for someone who has only been exposed to C to hook up and remember once they've read about it once. There also isn't really a more or equally obvious way to express this in Python.

I accept that there are some classes of languages where this is not the case, primarily functional languages. In those cases, the most simple, universally-applicable approach for that language family should be used.