[Myk267]

"Part of it is due to the very strict Python standard of coding."

I don't know about that. Good code is good code. It's sort of one of those, "I'll know it when I see it" things.

The ease of which you can code classes for the sake of classes in Python can make some really hairy code out of what should be simple programs. Was that necessarily the 'one right way to do it'? Who's to say. And all the static analysis tools and syntactic aren't going to undo those hairballs anytime soon.

You might just feel more comfortable with languages with lower code density. 'brandonbloom made a good blog about that[1]. I think it can be doubly applied to any situation where meta-programming is employed.

1: http://www.brandonbloom.name/blog/2013/06/24/code-density/

[d0m]

Take Javascript, if you want to iterate over a list, you have dozen of ways. One could hardly argue that one is better. Some prefer using built-in foreach, some .map, some underscore, some the native for(). As you say, great code is great code and as long as it's well written and understandable, it's good Javascript.

In python things are a bit different. There are agreed-on ways to do certain patterns. If someone uses a different method, I.e. [1,2,3].foreach(lambda x: something(x)) pythonist will all agree that this is no pep-8 standard and that for readability and maintenability's sake it should be changed to for x in [1,2,3]: something(x).

Another way to say that.. very good pythonists will agree on a "best way to do it", whereas in Lisp, very good lispers will agree that "both ways are very good and clean".

With all that being said, that's why I prefer to jump into a large python project (considering that pep 8 is strictly being used).