6 ms·

For some reason, I never liked Python. I don't know... its classes look weird with all those self, init, etc. The init.py for packages is also a strange

For some reason, I never liked Python. I don't know... its classes look weird with all those self, __init__, etc. The __init__.py for packages is also a strange choice to me. It has classes, but no interfaces. The language is even slower than PHP. Does Python have type hinting? What all the hype is about? I just don't get it.

danso 8y ago
What other language are you comparing Python's flaws and tradeoffs to?
- andreygrehov 8y ago
  Java, PHP, C#, heck, even JavaScript/ES[6,7]. I feel like Python has a lot of its own ways of doing things, whereas a more idiomatic approach is imho a better way to go. Why the hell in the world would you call a class constructor as __init__? Pretty much every popular OOP language does it either by naming a constructor the same name as the class name or through some form of a `construct` notation. Why `self` and not `this`? I mean, I know that the language has a very low entry barrier, but wouldn't it make sense to design it in a more traditional way? if __name__ == '__main__': main() Code like that just doesn't make any sense to me.
  - danso 8y ago
    > whereas a more idiomatic approach is imho a better way to go. I don't know what you mean by "idiomatic approach". That phrase, I thought, refers to languages that are highly opinionated about using a specific style -- this philosophy is encoded in Python's philosophy: https://www.python.org/dev/peps/pep-0020/ https://www.python.org/dev/peps/pep-0020/ There should be one-- and preferably only one --obvious way to do it. > Pretty much every popular OOP language does it either by naming a constructor the same name as the class name or through some form of a `construct` notation Seems kind of arbitrary to complain about the constructor keyword `__init__` when the constructor word for pre-ES6 JS, C, Perl, Ruby varies between prototype, constructor, __construct(), and new. Not sure how you say Python's use of `__init__` is somehow worse. As for why `self`, no idea, but seems to be a pretty easy convention to figure out. As for the complaint about the `if __name__ == '__main__':`, to which language are you referring to that has a more self-evident way of encapsulating that functionality?
    - andreygrehov 8y ago
      I'm not talking about highly opinionated languages, but common idioms across OOP languages. C doesn't have classes. pre-ES6 - agreed, but who writes it? I think Perl is a bad example, it's dying and is one of those highly opinionated guys, with all its `method`, `trusts`, etc. > As for the complaint about the `if __name__ == '__main__':`, to which language are you referring to that has a more self-evident way of encapsulating that functionality? My gut tells me that this is an error-prone idiom. I'm not saying Python is bad, I just don't like it. I'd love to know what are the strongest sides of the language though?
  - duckerude 8y ago
    Java, C# and modern PHP have a very similar style that's not at all universal. If you're used to those, Python is odd, but it can get a lot weirder. At least Python has classes. __init__ is called that because it initializes the object. It could have been called "__construct__", but I think "__init__" is a lot clearer about what it actually does - the object is already created when it enters __init__, __init__ just prepares it. Calling it "self" instead of "this" is super traditional. Smalltalk did it. The __name__ == '__main__' pattern is ugly, and I'm not a huge fan of it. You don't always need it, it's just a guard to let you tell whether a script is run directly or imported as a module. The key is that Python only has runtime. A function declaration or class declaration is a fancy variable assignment. The content of the file is executed sequentially. Python is not especially weird, but it is different from what you're used to. Wrapping your head around it takes a while, like with all languages, but things start to click eventually. It helps to experiment. The REPL is great for that. If you don't understand why something is the way it is, mess with it until you think you understand its behavior, then mess with it some more.
noname120 8y ago
Yes, Python has type hinting since 3.5[1]. https://www.python.org/dev/peps/pep-0484/ https://www.python.org/dev/peps/pep-0484/
- yen223 8y ago
  To be clear, Python has had type annotations for a while now, but the default CPython interpreter doesn't use that information to optimise performance.
  - UncleEntity 8y ago
    The CPython interpreter does very little to optimise performance because, as the reference implementation, they strive for simplicity of implementation.
xapata 8y ago
No interfaces? from collections.abc import Sequence Slower? import numpy as np
- andreygrehov 8y ago
  You're referring to duck typing, which to me contradicts the Zen of Python: Explicit is better than implicit. > Slower? Yes, overall the language is slower than PHP. It's not a bad thing, just the result of benchmarks. It doesn't mean one should stop writing Python.
  - xapata 8y ago
    No, I'm not referring to duck typing. An abstract base class enforces the interface. Explicitly. Some benchmarks might be slower, but I don't know anyone doing high-performance computing with PHP. I do see the topic at Python conferences.
    - andreygrehov 8y ago
      abstract base class != interface
      - xapata 8y ago
        Right, they're even better than Interfaces: both a contract and a partial implementation. No need for an "Interface" when you've got ABCs.
        andreygrehov 8y ago
        I see what you mean, but to me abstract classes are distinct from interfaces. Abstract class answers the question "what an object is?", whereas an interface is about what the object can do.
        xapata 8y ago
cm2187 8y ago
Agree. I can't understand people praising the lightness and readability while at the same time stuffing their code with underscores. Also it seems often inconsistent. Like some functions are used as prefix (len(x)) while other are suffix (x.clear()), I assume for historical reasons. Or like the "b if a else c" which reverse the logical order (you evaluate the condition then you can tell if you go one way or another). Same for [x for x in list], the Linq approach is more logical (for x in list select x). I understand why people like it. And I like scripting languages, it's nice to find a piece of script somewhere and being able to edit it directly having to find the correct source code and recompiling. But it has lots of shortfalls and quirks too (multi-threading, dependencies management, deployment, no refactoring/static checking, python 2 vs 3, 50 different kinds of strings, APIs full of abbreviations which probably meant something to their creators 20 years ago, etc). It's a nice language, among others. Not an "ultimate" language by any means in my opinion.
- meowface 8y ago
  Those are all valid gripes, but for most use-cases (where performance isn't critical), I haven't found anything better than Python yet. Ruby is an aesthetically nicer language and doesn't have those issues you mentioned in the first paragraph, but the Python ecosystem is amazing and better than Ruby's IMO. And compared to most other languages Python still feels very clean, terse, and pretty to me. >multi-threading Most interpreted languages have a GIL, sadly. But yes, this is annoying. >dependencies management Annoying, but resolved in part with new projects like pipenv, and also still a big issue for other popular languages. >deployment Also helped by pipenv, and Facebook's xar (https://github.com/facebookincubator/xar https://github.com/facebookincubator/xar) is new but looks promising. >no refactoring/static checking It's a dynamic language. But this is now possible to some extent with type hints. >python 2 vs 3 They did screw this up, yeah. Python 3 fixes a ton of issues and is a better language, but the backwards incompatibility created way too many problems. >50 different kinds of strings There are 2 kinds: bytes and unicode. >APIs full of abbreviations which probably meant something to their creators 20 years ago Can you give some examples? This is an issue in a few of the old standard libraries, but even then it's not too common. This is way, way more prevalent in PHP and C than in Python.

For some reason, I never liked Python. I don't know... its classes look weird with all those self, __init__, etc. The __init__.py for packages is also a strange

danso 8y ago

What other language are you comparing Python's flaws and tradeoffs to?

andreygrehov 8y ago
Java, PHP, C#, heck, even JavaScript/ES[6,7]. I feel like Python has a lot of its own ways of doing things, whereas a more idiomatic approach is imho a better way to go. Why the hell in the world would you call a class constructor as __init__? Pretty much every popular OOP language does it either by naming a constructor the same name as the class name or through some form of a `construct` notation. Why `self` and not `this`? I mean, I know that the language has a very low entry barrier, but wouldn't it make sense to design it in a more traditional way? if __name__ == '__main__': main() Code like that just doesn't make any sense to me.
- danso 8y ago
  > whereas a more idiomatic approach is imho a better way to go. I don't know what you mean by "idiomatic approach". That phrase, I thought, refers to languages that are highly opinionated about using a specific style -- this philosophy is encoded in Python's philosophy: https://www.python.org/dev/peps/pep-0020/ https://www.python.org/dev/peps/pep-0020/ There should be one-- and preferably only one --obvious way to do it. > Pretty much every popular OOP language does it either by naming a constructor the same name as the class name or through some form of a `construct` notation Seems kind of arbitrary to complain about the constructor keyword `__init__` when the constructor word for pre-ES6 JS, C, Perl, Ruby varies between prototype, constructor, __construct(), and new. Not sure how you say Python's use of `__init__` is somehow worse. As for why `self`, no idea, but seems to be a pretty easy convention to figure out. As for the complaint about the `if __name__ == '__main__':`, to which language are you referring to that has a more self-evident way of encapsulating that functionality?
  - andreygrehov 8y ago
    I'm not talking about highly opinionated languages, but common idioms across OOP languages. C doesn't have classes. pre-ES6 - agreed, but who writes it? I think Perl is a bad example, it's dying and is one of those highly opinionated guys, with all its `method`, `trusts`, etc. > As for the complaint about the `if __name__ == '__main__':`, to which language are you referring to that has a more self-evident way of encapsulating that functionality? My gut tells me that this is an error-prone idiom. I'm not saying Python is bad, I just don't like it. I'd love to know what are the strongest sides of the language though?
- duckerude 8y ago
  Java, C# and modern PHP have a very similar style that's not at all universal. If you're used to those, Python is odd, but it can get a lot weirder. At least Python has classes. __init__ is called that because it initializes the object. It could have been called "__construct__", but I think "__init__" is a lot clearer about what it actually does - the object is already created when it enters __init__, __init__ just prepares it. Calling it "self" instead of "this" is super traditional. Smalltalk did it. The __name__ == '__main__' pattern is ugly, and I'm not a huge fan of it. You don't always need it, it's just a guard to let you tell whether a script is run directly or imported as a module. The key is that Python only has runtime. A function declaration or class declaration is a fancy variable assignment. The content of the file is executed sequentially. Python is not especially weird, but it is different from what you're used to. Wrapping your head around it takes a while, like with all languages, but things start to click eventually. It helps to experiment. The REPL is great for that. If you don't understand why something is the way it is, mess with it until you think you understand its behavior, then mess with it some more.

noname120 8y ago

Yes, Python has type hinting since 3.5[1]. https://www.python.org/dev/peps/pep-0484/ https://www.python.org/dev/peps/pep-0484/

yen223 8y ago
To be clear, Python has had type annotations for a while now, but the default CPython interpreter doesn't use that information to optimise performance.
- UncleEntity 8y ago
  The CPython interpreter does very little to optimise performance because, as the reference implementation, they strive for simplicity of implementation.

xapata 8y ago

No interfaces? from collections.abc import Sequence Slower? import numpy as np

andreygrehov 8y ago
You're referring to duck typing, which to me contradicts the Zen of Python: Explicit is better than implicit. > Slower? Yes, overall the language is slower than PHP. It's not a bad thing, just the result of benchmarks. It doesn't mean one should stop writing Python.
- xapata 8y ago
  No, I'm not referring to duck typing. An abstract base class enforces the interface. Explicitly. Some benchmarks might be slower, but I don't know anyone doing high-performance computing with PHP. I do see the topic at Python conferences.
  - andreygrehov 8y ago
    abstract base class != interface
    - xapata 8y ago
      Right, they're even better than Interfaces: both a contract and a partial implementation. No need for an "Interface" when you've got ABCs.
      - andreygrehov 8y ago
        I see what you mean, but to me abstract classes are distinct from interfaces. Abstract class answers the question "what an object is?", whereas an interface is about what the object can do.
        xapata 8y ago

cm2187 8y ago

Agree. I can't understand people praising the lightness and readability while at the same time stuffing their code with underscores. Also it seems often inconsistent. Like some functions are used as prefix (len(x)) while other are suffix (x.clear()), I assume for historical reasons. Or like the "b if a else c" which reverse the logical order (you evaluate the condition then you can tell if you go one way or another). Same for [x for x in list], the Linq approach is more logical (for x in list select x). I understand why people like it. And I like scripting languages, it's nice to find a piece of script somewhere and being able to edit it directly having to find the correct source code and recompiling. But it has lots of shortfalls and quirks too (multi-threading, dependencies management, deployment, no refactoring/static checking, python 2 vs 3, 50 different kinds of strings, APIs full of abbreviations which probably meant something to their creators 20 years ago, etc). It's a nice language, among others. Not an "ultimate" language by any means in my opinion.

meowface 8y ago
Those are all valid gripes, but for most use-cases (where performance isn't critical), I haven't found anything better than Python yet. Ruby is an aesthetically nicer language and doesn't have those issues you mentioned in the first paragraph, but the Python ecosystem is amazing and better than Ruby's IMO. And compared to most other languages Python still feels very clean, terse, and pretty to me. >multi-threading Most interpreted languages have a GIL, sadly. But yes, this is annoying. >dependencies management Annoying, but resolved in part with new projects like pipenv, and also still a big issue for other popular languages. >deployment Also helped by pipenv, and Facebook's xar (https://github.com/facebookincubator/xar https://github.com/facebookincubator/xar) is new but looks promising. >no refactoring/static checking It's a dynamic language. But this is now possible to some extent with type hints. >python 2 vs 3 They did screw this up, yeah. Python 3 fixes a ton of issues and is a better language, but the backwards incompatibility created way too many problems. >50 different kinds of strings There are 2 kinds: bytes and unicode. >APIs full of abbreviations which probably meant something to their creators 20 years ago Can you give some examples? This is an issue in a few of the old standard libraries, but even then it's not too common. This is way, way more prevalent in PHP and C than in Python.