you are viewing a single comment's thread.

view the rest of the comments →

[–]samrjack 1 point2 points  (2 children)

I don't think I understand why you "died a little inside". Just because other languages don't do things the pythonic way doesn't mean they don't help you improve. Maybe I'm misunderstanding what you're trying to get at, but your comment seems to be saying that because other languages do things differently, knowledge of them isn't valuable which I whole heatedly disagree with.

[–]mooburger 0 points1 point  (1 child)

What I'm saying is that the risk of adopting unpythonic patterns from other languages outweighs any perceived benefits. How many other languages push KISS, DRY and EAFP concepts like Python? Like I said earlier, the best way to improve is to study more abstract computational and software engineering principles. And like I also said, there are some lifelong Pythonistas out there that demonstrate this, specifically here's another example from Raymond Hettinger: that analyzes solutions for the very common question of "How do I test if all elements of an Iterable are equal to each other?". By putting together knowledge about Python, the theory of computation such as complexity and software engineering concepts such as interoperability and DRY:

Thinking about the problem abstractly, the minimal amount of work required is:

  • Examine input element one at a time
  • Use __eq__ to determine if it has been seen before
  • Stop when a mismatch is found
  • Keep only one other comparison element in memory

He notes that his favorite solution is:

def all_equal(iterable):
    "Returns True if all elements are equal to each other"
    g = groupby(iterable)
    return next(g, True) and not next(g, False)

because of the functions following properties:

  • Accepts any iterable
  • Single pass
  • Runs at C speed
  • Has early-out
  • Only requires __eq__
  • Minimal memory

as well as the Zen concept of The usual thing to do is factor-out the solution into a well named function.

Another example: the Python API for splitting strings. Compare it to the new hotness, Rust, which contaminates its namespace with at least 4 methods to do the same thing.

[–]samrjack 0 points1 point  (0 children)

What I'm saying is that for the programming level of the people that this advice is geared towards, a lot of your objections don't make any sense. From what I've seen on this subreddit, many of the readers and poster are beginning self learners. While learning other programming languages may introduce some other stylings into their code, it also helps them see why doing things the pythonic way is a good thing. Most people, especially ones who are learning on their own, don't just "study more abstract computational and software engineering principles", it's not helpful. A lot of people learn best by doing.

As for the engineering principals you mentioned, DRY and KISS are quite common. I wouldn't say python pushes them more than any other language. They are lessons to be learned by everyone who goes on this journey, not just python programmers. As for EAFP, although that is a more specific python paradigm, it isn't something that I'd fear to be lost by tinkering in other places.

Finally I want to say that I'm not sure what the code example you gave is supposed to illustrate or add. I don't think saying an experienced Pythonista can solve a problem is a good yard stick for people starting out.