61 ms·

Reasons Python Sucks

• TheAlchemist 8y ago
  All this hate is justified, but not the conclusion. The libraries available in Python, for everything touching data / scripting are just so powerful and well thought, that for many small projects, using Python is a no-brainer. The best thing is that those libraries are actually incredibly fast, while Python is supposedly slow.
• CurtHagenlocher 8y ago
  A number of these points seem like reasonable opinions to have. But two which had me questioning the breadth of the author's experience were "Most programming languages pass function parameters by value." and "In every other language, arrays are called 'arrays'. In Python, they are called 'lists'." To the author: 1. Java, JavaScript and C# all have types which are passed by reference. (They also have types which are passed by value.) 2. Python lists are not arrays, if by arrays you mean a C- or FORTRAN-style block of non-resizable memory which is indexed by position. Python lists are much more like the Java List or C# IList interface.
  • SargeZT 8y ago
    And python does have arrays in the array module.
  • colanderman 8y ago
    Python (and Java) do not pass anything by reference. They pass by pointer-value. (If they passed by reference, you could change to which value a caller's variable was bound, like you can in C++).
    • alexhutcheson 8y ago
      > (If they passed by reference, you could change to which value a caller's variable was bound, like you can in C++) I might be misunderstanding you, but I don't think you can do this in C++. References can't be changed to point to a different object after initialization. If you have code like: void MyFunc(Foo& ref_param) { Foo new_foo; ref_param = new_foo; } The assignment above isn't "changing the value to which a caller's variable is bound". Instead, it's running the '=' operator on the Foo object to copy the state from new_foo to ref_param. To demonstrate this, you could run the following to see that the addresses are the same: Foo original_object; Foo& object_ref = original_object; MyFunc(object_ref); // object_ref still points to the same address assert(&original_object == &object_ref); Under the hood, C++ reference params are basically syntactic sugar for passing by pointer-value, so this behavior isn't surprising.
      • colanderman 8y ago
        The proper analogy for a Python object is `std::shared_ptr<Foo>`: in Python, all "objects" are actually reference-counted pointers to objects (thus making them shareable). And then yes, in C++, you can change to which object the caller's "object" (pointer-to-object) points to, if you pass a reference to that. This is not possible in Python: all you can do is pass that shared-pointer value around, not the value of the object itself, nor a reference to the shared pointer. This is a well-known distinction that goes by several names, see e.g. https://en.m.wikipedia.org/wiki/Evaluation_strategy#Call_by_sharing https://en.m.wikipedia.org/wiki/Evaluation_strategy#Call_by_...
        • alexhutcheson 8y ago
          Ah, got it. Your basic point is that C++ params can use two layers of indirection (pointer-to-ref, ref-to-pointer, pointer-to-pointer, etc.), while doing so in Python is clunky. Makes sense.
    • lmm 8y ago
      Those languages use references rather than pointers (that is, their referring-things do not support arithmetic), so any name for what they do that involves "pointer" is a poor one. The distinction between passing the value of a reference being used by the caller and passing a reference to the caller's stack is so rarely important or useful that there's no consensus terminology for it. The distinction that's actually relevant and useful is whether, when we write f(a), f receives the (thing we would call the) value of a or a reference to the value of a (and in particular whether f can change the value of a). In Python, f can change the value of a (that is to say, the thing Python programmers understand to be the value of a); therefore Python is pass by reference as the term is usually understood (and certainly any term for its call style that uses "value" is more misleading than calling it "pass by reference").
      • jerf 8y ago
        "The distinction between passing the value of a reference being used by the caller and passing a reference to the caller's stack is so rarely important or useful that there's no consensus terminology for it." And the reason for that is essentially all modern languages make copies of something when passing argument parameters. The only question is what they are passing and exactly how hard the language layer works to make it look as if you are or are not passing something by reference. I have to reach to something as obscure as Forth to find a language that does not work that way, and truly does not copy parameters into a function. (I haven't dug into Factor enough to know if under the hood it still copies parameters.) It's a very unusual choice to not copy something for a function call. (This is one of the ways our CPUs have been optimized for the languages we run; they make this intuitively expensive operation otherwise cheaper than it would be on a naively designed CPU.)
        • com2kid 8y ago
          > And the reason for that is essentially all modern languages make copies of something when passing argument parameters. Then of course someone turns on whole program optimization for C++, half the code gets inlined into one terrifying large function, nothing is copied anywhere, and the code runs 2x faster. Then some poor SOB has to debug the assembly code for all of this and has nightmares for years after. Not like I'd know or anything. :)`
    • pdonis 8y ago
      > They pass by pointer-value. No, Python doesn't even do that, because Python variables aren't names for storage locations to begin with. They're namespace bindings. Passing a variable to a Python function means transferring a namespace binding from the caller's namespace to the function's local namespace.
      • arduinomancer 8y ago
        What is a namespace binding? Can you explain at a low level what that means?
        • pdonis 8y ago
          Compare a variable assignment in C and Python. In C: int i = 17; Means "set aside one int's worth of storage and fill it with the bit pattern for the number 17". In Python: i = 17 means "create an int object with the value 17 and bind it in the current namespace dictionary to the name i".
      • colanderman 8y ago
        The semantics are identical.
        • pdonis 8y ago
          If you think this, I'm confused about what you mean by "semantics".
  • deleted 8y ago
    [deleted]
  • dagw 8y ago
    Python lists are not arrays In addition python also does have arrays if you want/need them: https://docs.python.org/3.7/library/array.html https://docs.python.org/3.7/library/array.html
    • deleted 8y ago
      [deleted]
  • cm2187 8y ago
    If I remember VB6/VBA passes everything by reference by default, even value types.
  • porpoisely 8y ago
    In C#, all variables ( reference or value types ) are passed by value. Yes, even reference types are passed by value. If you want to pass variables by reference, you need to use special modifiers ( out or ref ).
    • graycrow 8y ago
      Yes, but for a reference types that value IS a reference, so if you change a complex type, that change will persist after return to the calling code.
      • aurelwu 8y ago
        static void Change(int[] myArray) { myArray = new int[5] {3, 1, 2}; } this will not change the array which was passed in and is a purely local change in C#. static void Change(ref int[] myArray) on the other side would change the array which was passed in.
      • city41 8y ago
        But it’s still pass by value. Passing by ref allows swapping out the entire object, which is not possible in a language such as JavaScript.
        • sciurus 8y ago
          Right, but this is the same way Python works. Jumping back to the original argument in the post, the author claimed that Python was "going out of it's way to be different" by passing objects by reference value. C# provides a counterxample to that claim.
      • porpoisely 8y ago
        You are correct that changes to the object will be reflected in the calling code. But that's the nature of the reference, not whether it is called by value or called by reference. Whether you pass a reference by value or by reference, the changes to the object will be reflected in the calling code. And as I noted, it's all passed by value in C# unless you use modifiers ( ref or out ). The difference between "pass by value" and "pass by reference" for reference variables is how the variables themselves are handled. For example, if you pass a reference "by reference" to a function and set it to null, then the reference variable in the calling code is also set to null and will cause null ref exception if you try to access the object. Whereas if you pass a reference "by value", if you set the variable to null, the calling code variable isn't affected. Pass by value and pass by reference is not about objects or types really, it's about variables.
  • brudgers 8y ago
    What Java, JavaScript and C# call "arrays" are each very much like what Python calls "lists'. In particular the indexing after push() and pop() type operations and the bigO of indexing. More abstractly, Historically, in computing "list" connotes pointers and "array" connotes sequential memory. The connotations imply engineering tradeoffs. [1] "List" may make more sense for a beginning programmer. It is an arbitrary context switch for programmers writing in multiple languages. Considering that one of the driving use cases of Python has been systems programming, "list" is misleading regarding performance characteristics. [2] [1]: For example as in Scala https://docs.scala-lang.org/overviews/collections/performance-characteristics.html https://docs.scala-lang.org/overviews/collections/performanc... [2]: googling "python arrays" returns a lot of results explaining the difference between Python's Arrays and Python's Lists. "List" is "foo => spam" and "bar => eggs" Pythonism gone too far.
    • TheCoelacanth 8y ago
      Not true for Java or C#. In both of those languages, arrays are fixed-size and don't have anything like a push or pop operation. Both have an automatically resizing container backed by an array that is referred to as a list. Python's use of "list" matches the use in Java and C# perfectly.
      • brudgers 8y ago
        Requiring a type definition, Python's Array type more closely matches Java and C# Lists than Python's List type. In Python, Arrays are sequence types and behave very much like lists[1] In other words, even in Python, arrays have similar semantics to Javascript Arrays not Java Arrays. [1] https://docs.python.org/3.4/library/array.html https://docs.python.org/3.4/library/array.html
    • michaelt 8y ago
      What Java, JavaScript and C# call "arrays" are each very much like what Python calls "lists'. In Java and C#, 'arrays' are fixed size at creation time. Both Java and C# provide 'lists' which are variable sized* Python 'lists' are variable-sized. Seems like a consistent naming scheme to me? *there might be an underlying array that gets reallocated - but it's encapsulated within the list object; the reference to the list object is unchanged when this happens.
  • phodge 8y ago
    > Most programming languages pass function parameters by value The biggest irony here is that if you wrote your code in C instead, you would actually pass more arguments by reference than in equivalent python, because you're going to use pointers for everything but primitive integer values.
    • Koshkin 8y ago
      No, the biggest irony is that C as a language does not even have a syntax for passing by reference. Everything, including pointers, is passed by value. References were introduced in C++.
  • twblalock 8y ago
    Java passes by value. The value being passed happens to be a copy of a pointer (properly called a "reference" in the spec, which confuses people). A copy of a pointer points to the same place as the original pointer. For normal use cases this works very well. However, if you reassigned your copy of a pointer in the body of a function, the original pointer would still point to the same place it did before the function was called. That's not the same thing as actual pass-by-reference in languages like C++.
  • InclinedPlane 8y ago
    Also, in javascript the thing that's called "an array" is actually a hashmap, because everything in javascript is secretly just a hashmap.
• booleandilemma 8y ago
  I feel like Python is a case of the emperor’s new clothes. In this case the emperor has no visible scope delimiters.
  • KMag 8y ago
    The counter-argument is that in practice, most programmers use the indentation of the first non-whitespace character on each line to estimate lexical scopes, which is why removing all indenting drives most programmers wild. I've seen several bugs in C++ and Java where colleagues have indented the code for the correct control flow, but misplaced the curly braces, resulting in incorrect flow. Granted, the two bugs that come to mind first are dangling-else problems that were fixed by inserting the optional braces. I think that you and I both prefer auto-formatters to force indenting to match flow control. However, there's an argument to be made for actually enforcing it at the language level rather than at the tooling level.
• sidcool 8y ago
  Interesting points. I disagree with Reason 2 though. Python has smoother installation than Java and GCC. One of the reasons Python is popular is because it's easy to do a lot of things. Some python choices don't make sense technically, but they were made to make python as easy as possible. Performance was never the first criteria of Python (or ruby). My personal peeve is with mandatory indentation. But again, that's the idiom the language has adopted.
  • cirgue 8y ago
    I go back and forth about mandatory indentation. Part of me hates it, but I remember why I don’t mind as much every time I have to do code reviews.
  • int0x80 8y ago
    >Python has smoother installation than Java and GCC How so? With java you can get your distro version from the package manager or just download a tarball and setup your PATH. Maybe install maven. GCC and build deps is as simple as a xxx install build-essential/build-base and you have a C compiler for C89/C99/C11.
  • camjohnson26 8y ago
    I think the huge volume of 3rd party libraries that Javascript and Python have show that prioritizing developer experience over technical perfection leads to a more useful language. I hate Python's quirks but it's the first language I reach for if I'm just fetching data from an api or doing some web scraping. It's so fast and expressive that it makes up for the negative parts of the language.
• sytelus 8y ago
  Many of the reasons authors states are quite silly. Personally I don’t like the huge perf hits everywhere you look. For example, a bool in Python takes whopping 24 bytes! Multi threading is a giant mess due to GIL that apparently no one can get rid of. Things like true static variables are missing. Import behavior differences for programs and modules is baffling. Lambda is intentionally kept under powered (ex. no group by). Need to create new environments to avoid conflicting package versions can quickly become annoying (could have been improved by side by side versions). Still, I don’t hate it at all. It’s good and beautiful for lot of other stuff.
  • cgora 8y ago
    Now this is a good list of things to hate about Python. I would add the fracturing of build methods for large applications is another frustrating thing about working with python. Although projects like Pipenv and Poetry seem to be bringing python up to modern standards in that arena.
    • gonational 8y ago
      I have yet to use poetry although I’ve heard great things and I’ve read a blog post that kind of sold me into it. How would you say it ranks compared to pipenv? I’ve had frustrating issues with the latter in the past month. I can’t help but think that the lack of Kenneth Ritz in the commit list since summer has something to do with this. I don’t recall the exact scenario, but I think there was some kind of falling out between him and the community.
  • notacoward 8y ago
    I encourage you to expand on these excellent points in a blog post. It would be about 100x better than the OP.
  • jjrh 8y ago
    Even if you despise python to the core, it's hard to shrug off the massive number of well documented, mature libraries. Usually there are 2 or more choices with at least one of them being fairly mature and maintained. Not to mention the wealth of examples showing how you can do something. So despite all the things I dislike about python, it's still my go to for a proof of concept or getting something done quickly.
• MichaelMoser123 8y ago
  the self argument for methods/method calls is stressful (having to define self for methods and having to call a method via self); also the fact that you need to check if dictionary key exists, else you get an exception when trying to get the keys value. Also ':' at the end of each line. I always forget at least one of these. You didn't have any of these goodies in good old perl (sob, sob) (wow, this one got flagged pretty quickly, wonder why)
  • dagw 8y ago
    you need to check if dictionary key exists, else you get an exception when trying to get the keys value. What should be the correct behavior when accessing a key that doesn't exists? If you want a specific default value when a key doesn't exist you can use the get() method. Also ':' at the end of each line. What do you mean? You don't need ':' at the end of each line, only at the start of a block (basically anywhere you'd use a '{' in other languages).
    • blattimwind 8y ago
      > What should be the correct behavior when accessing a key that doesn't exists? Undefined behaviour, i.e. the JIT generates code to 3D print a clay golem on your desktop that sets your village ablaze.
  • gwillz 8y ago
    Idk, maybe because your arguments are bit shallow? I like 'self'. There's a lot to complain about magical 'this' of every other language - especially in Javascript. Specifying self makes it really clear if it's a member method or a standalone function. Python really likes the idea of 'seek forgiveness, not permission', aka. abusing try/except. But it's kind of nice: # seek permission if 'key' in map: fn(map['key']) else: whatever() # seek forgiveness try: fn(map['key']) except KeyError: whatever() Just pray that 'fn()' doesn't also throw a KeyError.
  • Felz 8y ago
    It's been a while since I touched Python (thankfully), but there's also: - The hideous __method__ and _private conventions - A friend of mine was complaining about the implicit string concatenation: ["foo" "bar", "baz"] whoops forgot a comma and now there's a very hard to find bug - pyc and pyo files littering the filesystem after running (yes, only a minor nuisance) - import anywhere, the ugly __name__ = "main" hack - GIL, reference counting GC, abysmal performance in general - Dynamic typing, which is probably my most major complaint but I realize opinions differ
• faitswulff 8y ago
  > Here I am hating on the language I love, but I remember when I would have to review this question on StackOverflow every time I wanted to create a new virtual environment: > https://stackoverflow.com/questions/41573587/what-is-the-difference-between-venv-pyvenv-pyenv-virtualenv-virtualenvwrappe https://stackoverflow.com/questions/41573587/what-is-the-dif... What a mess. Came here to post something similar, but a commenter on the blog post itself got to it first. Virtual environments never made sense to me.
  • velcrovan 8y ago
    This right here is the biggest problem with Python. I don't see this garbage in any other programming language.
• mothsonasloth 8y ago
  Deep inside every Python developer is a frustrated Java dev waiting to come out... i just made that up
• sehugg 8y ago
  I would post "these are very reasonable gripes" but I can't decide whether to make my string a unicode object or a UTF8-encoded bytes object...
  • mkirklions 8y ago
    Can you explain this? I'm interested
• ceronman 8y ago
  "There are only two kinds of languages: the ones people complain about and the ones nobody uses." -- Bjarne Stroustrup
• abcmer 8y ago
  Bill and Neal? Are these the geeks from Freaks and Geeks all grown up?
• deleted 8y ago
  [deleted]
• superasn 8y ago
  I too have tried it many times mainly because of all the great ML libs for python but each time I dreaded using it for Reason #3 (Syntax). Using indents for blocks just seemed unintuitive and error prone to me. But I dismissed it because all the programming languages I've worked with have had curly braces so maybe the reason for my discomfort was that it was unfamiliar.
  • jdblair 8y ago
    Only in Python can I commit a whitespace-only change that results in a 10x speed improvement.
    • b_tterc_p 8y ago
      Care to explain? I’m not sure where this would work without fundamentally changing the meaning of the code
      • notacoward 8y ago
        I'm guessing it refers to moving something out of a loop, which in Python often requires only an indentation change. In most other languages, it requires moving the code to the other side of a brace, or perhaps adding a brace. If braces were considered whitespace, which is not entirely unreasonable when talking about Python vs. other languages, it would be much harder to come up with examples. Drawing a blank right now. Anyone else want to try?
        • jdblair 8y ago
          That correct. It was a case of nested loops and some code that was in the wrong loop. Braces are most definitely not whitespace, even if they serve the same function as whitespace in Python.
  • Symmetry 8y ago
    Most languages that use braces also encourage you to indent the things enclosed by the braces to make it easier to read. However, people sometimes make mistakes. For instance I've seen this quite a number of times if (a) somestatement; someotherstatement; athirdstatement; Which is of course horribly misleading unless you're careful because the second statement isn't actually conditional on a. Python forces the indent to match the semantics.
• pmarreck 8y ago
  Elixir has none of these faults, so I guess I will continue to enjoy using it. Lists and arrays are fundamentally different beasts, though. Shouldn’t most coders understand that?
  • deleted 8y ago
    [deleted]
• leshow 8y ago
  A lot of these gripes are unfair and don't really matter IMO. I think complaining about things as trivial as syntax is really just scratching the surface and doesn't serve your conclusion. A dictionary is an interchangeable word with hashmap in most situations. The string 'quirks' actually look to be pretty helpful. Gripes I do actually agree with: the schism in versions, mutation from pass by ref (although this isn't different from JS, Java or any other OO lang). In my opinion you can add OOP in general to the list of gripes against python.
• ezoe 8y ago
  Reason 2 is getting out of hand for Python, Ruby, JavaScript, Haskell and OCaml. These so called package manager can't manage packages at all. I'd like to call it package downloader. They just download everything from language interpreter to library to a single directory and call it job done. No easy way to remove the package. The interpreter and library's version is forever fixed. Theoretically, it can upgrade the version but the user mostly don't. I really hate their ecosystem.
  • bdcravens 8y ago
    > They just download everything from language interpreter to library to a single directory and call it job done. This is scoped to the project in npm. In Ruby, you can specify the path (common to "vendor" your gems). You can use version managers (like rvm or nvm) to scope your libs to versions or even named projects (thinking of rvm's "gemsets") > The interpreter and library's version is forever fixed. Theoretically, it can upgrade the version but the user mostly don't. I can't speak for all ecosystems, but on Ruby projects I've been a part of, keeping gems updated is pretty common. Github even includes monitoring for vulnerabilities to encourage this. Having been part of ecosystems that don't have package management (for example, ColdFusion) even the worst package managers are a major improvement. (Though I do think the isolation of python's virtualenvs is a better approach than most systems)
  • ubernostrum 8y ago
    No easy way to remove the package. "pip uninstall" has been around as long as pip has. Theoretically, it can upgrade the version but the user mostly don't. In practice, people deploy to a virtualenv that gets recreated on each deployment, and tend to treat a virtualenv as an ephemeral thing.
• romeisendcoming 8y ago
  This article illustrates amateur hour in many ways. The whole can't manage my environment and don't understand how to manage the python thing at all has my sympathy. Python is messy at that level. With the organizational 'control' sysadmin deprecated by devops and containers/automation becoming the new norm these types of complaints have to be dealt with by people who have no idea of what they are doing in generalized context.
• giffarage 8y ago
  Of all the things to “hate with a passion”, choosing a programming language sounds miserable
  • deleted 8y ago
    [deleted]
• faizshah 8y ago
  My top 3 criticisms as an intermediate (~5 months of study) python programmer: 1. Importing behavior is ridiculous: https://chrisyeh96.github.io/2017/08/08/definitive-guide-python-imports.html https://chrisyeh96.github.io/2017/08/08/definitive-guide-pyt... 2. Python libraries' documentation leave a lot to be desired (compared to good javadocs). Just because your language is dynamically typed doesn't mean you don't need to describe what the expected shape of a parameter should be. 3. Static method? @staticmethod Static variable? declare it outside of your methods but inside your class Private method/var? name it: __name (but it's not really private just hard to find) I'm sure other Java programmers have had a culture shock coming to python as well. I appreciate how concise the language is, the great community and module ecosystem, and how productive it is. But, it feels to me like there's features missing (I've only been seriously programming python for 5 months though, before I was basically just scripting and writing java code in python). Also the most fun part of learning python has been list comprehensions and itertools, they've really been a revelation. Like when I first learned Ruby procs, blocks, closures and lambdas.
  • texmex20 8y ago
    As a fellow Java programmer who's picked up Python in the past year, I completely agree with these. Especially #2 -imo a dynamically typed language/library warrants having better documentation, not worse.
  • lmm 8y ago
    > Static method? @staticmethod > Static variable? declare it outside of your methods but inside your class Sounds like you're still thinking in Java :). A static method is rarely what you want (and if you do you can put it on the class like for variables); functions are first-class so you can just put them in your module.
  • laurentl 8y ago
    As a former certified Java programmer, moving to Python was a breath of fresh air. More concise syntax, no more braces all over the place, much less boilerplate (think getter, setter, public static void main(String[] args)) and not everything has to be an object. First-class functions, yay ! (I haven’t used Java seriously since 1.6 so I don’t know how much the language has evolved since then). The only reason I’ve had to go back to Java is specific libraries, and speed. Python’s philosophy of convention rather than constraint is a nice chance from Java’s corseted mindset. But I’ve never had to use Python in a large development team, so I don’t know how well it holds up with a large group of devs. As an aside, if you have fun with comprehensions, itertools and lambdas, I urge you to take a look at functional programming!
• rafiki6 8y ago
  I used to hate python because of of the lack of static typing. I realized the reason I hated it because of that, was due to other people's bad code. One of the nice things with compiled languages that are statically typed is that there's that nice check up front for types. I actually think you need to be a really good developer to properly use dynamically typed languages.
• colanderman 8y ago
  A better reason to hate Python: the internal model is way overcomplicated for what it's meant to be: a beginner-friendly scripting language. "Everything-is-an-object", duck typing, decorators, bizarre scoping rules, etc., all make it difficult for experienced programmers to understand, let along beginners. I've always thought there's a much simpler language struggling to get out of Python, and I wish it would and would become popular so I wouldn't have to recommend Python to beginners any more, and be on the hook for explaining e.g. why default values are mutable, or why nested generator comprehensions behave differently than nested list conprehensions. (Think Erlang levels of simplicity.) The standard library is also haphazard and inconsistent (much like JavaScript's). Take lists: some operations are methods, some are functions, some mutate the list, some make a copy, some are global, some are in a module. There's no rhyme or reason that I can tell. Modern C++ has, in my opinion, a much more well-thought-out standard library. There are very few methods/functions which exist due to historical accident (iostreams aside), and the distinctions between methods/free functions and mutators/copiers is fairly uniform.
  • mannykannot 8y ago
    The C++ standard library is (mostly) an exemplary work, but that is despite the language's complexity, with pointers and lvalue, rvalue and forwarding references, just to get started...
    • colanderman 8y ago
      Oh completely agreed. C++ the language is as or more complex/overcomplicated as Python. (Hence my example of Erlang as a simple language.)
  • qntty 8y ago
    Is python really meant to be a beginner-friendly language? I tend to think of it as lisp-without-parens, and lisp is not very beginner friendly.
    • cschmidt 8y ago
      It is usually the "first language" of choice these days, when teaching programming.
• deleted 8y ago
  [deleted]
• carlsborg 8y ago
  * Versions and installation: Consider doing all dev work in a virtual env. It installs the correct python interpreter on your PATH, and installs pips in that isolated env. $ python2.7 -m virtualenv .venv or $ python3.6 -m venv .venv $ source .venv/bin/activate // dev + test here $ deactiveate > This worked great until I started on a second project that needed Python 3.6. Two concurrent projects with two different versions of Python -- no, that wasn't confusing. Note that Java also comes in various version of the compiler and jvm, and its common to have several versions on the same system. They are backward compatible but forward compatibility issues exist: your main server app runs on java7 but your batch process is running java9. you might not want to make java9 the default on the system without formally upgrading the server app. * Syntax/spaces : you get used to it. Hey some people write code in perl :) * Includes: In principle, this works somewhat similar in Java: You use imports and the imported package hierarchy can nest quite deep so you need to look. > The import function also allows users to rename the imported code. They basically define a custom namespace.. This can be a good thing, it helps you prevent name clashes. C++ also lets you do this, its called Namespace aliases. namespace fbz = foo::bar::baz; std::cout << fbz::qux << '\n'; * Nomenclature: > In every other language, arrays are called 'arrays'. In Python, they are called 'lists'. Thats because it is a list. Nodes are dynamically allocated and appended to the list. You can expect similar algorithmic complexity for the operations. Python also has arrays if you want the better efficiency: https://docs.python.org/3/library/array.html https://docs.python.org/3/library/array.html * Pass By Object Reference: same as java
• reachshabib 8y ago
  Love it or hate it, python is here to stay for a really long time.
• berdon 8y ago
  I agree with the OPs points but disagree with the degree to which the author has used them as a means to "hate" a language. I generally avoid Python too but saying you hate the language because of a bunch of contrivances mostly wrought from inexperience and holding too strongly to C like languages is poor form. Versions: Ok? Versioning and fragmentation is a hard problem. Backwards compatibility is a hard problem. Moving fast and never breaking anything is a nearly impossible problem. Python sucks at it, lots of things suck at it. There are many examples of other languages (.NET Core, for example), platforms, frameworks, etc that all suffer from this. It can be a reason to avoid those things but probably not one to base a loathing on. Also, lots of people still use Perl. Lots of people still love Perl. I don't know why. Installation: This screams "windows only" user. Path'ing, local dependencies, and package management is relatively common and you should force yourself to be comfortable with those concepts. Just saying "I should be able to just run one thing and be done forever", albeit ideal, is naive and never going to happen. Syntax: Yep. Spacing blows and you're always going to have stupid issues with it. I hate Python's spacing. Someone ought to create a custom interpreter that allows for using braces. Includes: Most of these complaints sound like they're coming from someone largely silo'd in the C/C++ world of wanting to know everything. "With C, you can just look in /usr/include/*.h" - the author is admitting he's unhappy because Python isn't C. Quirks: General complaints about other languages... and using those complaints to somehow sour Python? The quirks he does list for Python aren't even strange - they're pretty useful. Local Names: OP probably could have just included this in quirks rather than having another point. I'm pretty sure there's actually a means of avoiding this type of import issue by some silly Python pathing shenanigans.
  • ArchTypical 8y ago
    > author is admitting he's unhappy because Python isn't C That's not the point at all. I mean, did you read it? How do you mischaracterize the specific point about the casual opportunity for foreign module metaprogamming? Module initialization is bad in a pernicious way. While you can't do operator overloading, you can clobber namespaces (which was referenced). Paired with a community repository, this is exactly the same case of what's so dangerous about npm.
    • 8y ago
• peterwwillis 8y ago
  This rant would have been exactly the same if he had just discovered Perl5. It's got way more quirks than Python, but you deal with it, because the language is super useful. The one valid gripe that wasn't quite there is why doesn't Python (or any other language really) manage its modules like CPAN? CPAN is amazing. It's ancient and dusty and missing obvious modern improvements, but it's still way more useful than anything else. Searching through PyPi is pretty awful. Look for "yaml versioning" and get 10,000 projects to wade through. CPAN is hierarchial, so not only can I find what I'm looking for, it even exists on disk where I expect it. Because of all that, a few other things happen. The low level modules are older, exposed to more users, so people find them first, improve them over time, and this influences and improves new code. Not only are there these great examples of quality code for comparison, but code reuse and extending is way more common than entirely new modules. Testing is also really rigorous. CPAN testers framework tests across all Perl releases and computing platforms, continuously. Perl module build instructions are converted easily to Makefiles, making it easier to build and test on other platforms if you're not familiar with Perl conventions. Most modules also provide real in-line documentation, not just one line describing what a function does. Perldoc usually gives you a real man page for any given module you're looking at, whereas Pydoc gives you a bare list of method calls and objects that maybe the author added documentation to, but often not. Which am I supposed to use, for what? Might as well go read all the code... ...oh, and unrelated, but using regex's in Python is kind of horrifying.
  • hpcjoe 8y ago
    I remember the perl4 to perl5 transition. I had some perl4 code I wrote to automate runs of my code. Porting it to perl5 made me grumble a little, but it was mostly very minor changes. About an hour of work for all my code. But, yeah ... CPAN, and C-TAN, are things to behold. Python hasn't done a great/good job with this. Npm is just plain awful. Julia's Pkg was good in the 0.6.x days ... seems to be borked now, though this may be due to the 0.6 -> 1.0 transition. For me, Perl is my go-to scripting language. I've written some pretty intensive apps in it, which would be horrifying in other languages. It has (many) warts, though packaging isn't one of them. I am looking at using Julia for scripting in places where I'd ordinarily use Perl ... mostly data clean up. This noted, it is very hard to beat Perl in munging data. R comes close, but writing parsers in it is hard. Perl6 aka Rakudo is very interesting to me. Addresses many of the issues I've had with Perl in the past, and gives some truly incredible power going forward. Adoption appears to be low and slow right now. I don't actually have time to play with it now, as I've got other higher priority issues to deal with.
• woodrowbarlow 8y ago
  > if I'm testing a screen capture program with a C library called "libscreencapture.so", i would call my program "screencapture.c" and compile into "screencapture.exe" author must be running an unusual OS.
  • Kliment 8y ago
    I've seen ELF executables with .exe suffices (as well as .run, .bin, no suffix, etc etc, I'm just waiting for someone to name one .com). This was done specifically to distinguish them from a directory of the same name.
• Symmetry 8y ago
  I agree with a number of these but I really don't understand #4. If you want to know what's in a module then 'import foo; help(foo)' in your interpreter will give you it. In C you can't just grep /usr/include because you might be importing form somewhere else. And in C everything goes directly into your main namespace, the equivalent of 'form foo import *'. And even with single letter renames you can just quickly check at the top of the file for what the rename is, 'gg<c-o>' in vim and probably similarly easy in most people's editors. And really importing common libraries as single letters should be by convention in a codebase. I really think that Python's import story is one of my favorite things about the language and it's something where I'm often comparing other languages to Python and finding that they're coming up short.
  • breatheoften 8y ago
    There's so much incidental design exposed to the user/library author because of python's import system ... Ultimately you have to step through a large list of questions in order to understand the actual import behavior -- its not easy and adds a large (pointless?) cognitive load for every library user/author ... Are you import'ing a Module or a Package? If it is a package then maybe there's a magic file called __init__.py in a directory that might have an __all__ = [...] array or might just import some other modules but not contain an __all__ or it might import some names from some other modules. Or maybe there's a namespace package somewhere which has some behavior when there are directories that contain .py files but don't have an __init__.py (I honestly don't know the rules -- but I do know they can't be explained to me in a small number of words and that makes me insane!) ... And by the way -- every instance of 'import' used throughout your program is additionally beholden in its behavior to a global runtime magic state magic called the PYTHONPATH (that often has to get munged from the shell environment prior to invoking a python program ...) which is a list of path's that will be consulted/augmented differently depending on whether its a (module/package/namespace) import search to ultimately decide which set of files will be inspected ... As a half-assed python developer (who is firmly in the 'I hate python camp') I honestly have very little idea how you are 'supposed' to use these mechanism when defining a package. I recently tried to figure out actual best practices so I could publish a small package -- I relied on lots of boilerplate copying from what seemed like knowledgable sources. I think I got something vaguely workable (https://github.com/breathe/NotebookScripter https://github.com/breathe/NotebookScripter) but there's a lot of line noise all throughout the filesystem layout ... What is it about my Project name that python demands I should repeat it in the filesystem over and over and over again? I believe this is actually the common pattern for laying out a small library ...: Project/setup.py Project/Project/__init__.py Project/Project/SomethingToDoWithProject.py
• chasedehan 8y ago
  (2) —> virtual environments.
• mattbillenstein 8y ago
  Stopped at "I'd rather rewrite it in C" - I guess he's one of those programmers with infinite time. Python has its warts, but so do most languages that are almost 30 years old.
• projektfu 8y ago
  C and its standard library have some consistency and C89 code mostly runs on future versions of the spec (provided they don't use something like _Bool). But the idea that you don't run into version hell in C is crazy.
• rcthompson 8y ago
  It seems unfair to complain that Python 3 breaks backward compatibility and then also complain about the reason that Python 3 broke backward compatibility (i.e. broken string encoding in Python 2).
• smt88 8y ago
  I'm flagging this not because I disagree, but because there's nothing new or insightful in the article and the headline is just flamewar bait. I'd love to see a deep dive from an expert on why Python sucks, because I truly hate Python, but this isn't it.
• ApolloFortyNine 8y ago
  >By the same means, Python has distinct silos of code for each version. And the community keeps dragging along the old versions. So you end up with a lot of old, dead Python code that keeps getting dragged along because nobody wants to spend the time porting it to the latest version. As far as I can tell, nobody creates new code for Python2, but we drag it along because nobody's ported the needed code to Python3.x. At the official Python web site, their documentation is actively maintained and available for Python 2.7, 3.5, 3.6, and 3.7 -- because they can't decide to give up on the old code. Python is like the zombie of programming languages -- the dead just keep walking on. I think I could make a comment on every one of this authors 'gripes' but I'll just do one for now. Does this author think a minor version update should immediately EOL the previous version (3.5,3.6)? And obviously this author never heard that Python 2.7 is EOL 2020 [1]. But you know just reading this author's problems that if Python 2.7 had been EOL right after 3 released, or if a minor version upgrade immediately EOLs the previous minor versions (seriously, how is this a complaint?) he'd be posting about that instead of these 'which version do I choose' issues. I just honestly can't believe a developer would complain about maintaining code for 'too long'. [1] https://legacy.python.org/dev/peps/pep-0373/ https://legacy.python.org/dev/peps/pep-0373/
  • lmm 8y ago
    > Does this author think a minor version update should immediately EOL the previous version (3.5,3.6)? More likely the author thinks minor version updates should be backward compatible, like they are in virtually every other language? In most languages you'd be able to uninstall 3.5 when you installed 3.6, because you'd be confident that all your 3.5 code would keep working in 3.6.
    • Hello71 8y ago
      Except... they mostly are? As far as I can tell, Debian only ships one Python per major version per release, Fedora does the same, Arch does the same. Gentoo lets you install everything side-by-side, but it does the same thing for gcc, binutils, ruby, wine, llvm, and dozens of other packages, and I don't see the author complaining about those.
• nicodjimenez 8y ago
  For scripting, there's nothing better than Python (that I know of).
• notacoward 8y ago
  Most of the points in this article fall on a continuum between irrelevant to dead wrong. 1 (versions) and 2 (installation) have to do with the ecosystem, not the language. Unsigned packages are a real problem, but hating on community-maintained software is just weird. Most software in your local Linux distro's repository is maintained by a "community" that might just be one person working in their spare time. 3 (syntax) seems to be about not supporting the author's own highly idiosyncratic habits, which include deep nesting and putting debug code in the first column (ugh). The result actually seems better for maintainability than the author's own unconstrained code would be. 4 (includes) is in the "exactly wrong" category. Includes as in C/C++ are a horrible way to handle module interfaces. Really, just about the worst option available. Modules are far better, and if the author hates the fact that importing a module might run initialization code wait until s/he finds out about constructors (including __init__ and __attribute__((constructor)) even in C). 5 (nomenclature) is also a bit insane. Lists aren't called arrays in Python because they're not arrays. Next! 6 (quirks) criticizes quote handling in Python, but mentions bash's quote handling without a word of comment about how that's even worse. Different languages have different quoting conventions. Python's might not be perfect, but many are far worse. Get over it. 7 (pass by reference) is another totally-wrong one. Passing by value is not the universal norm in other languages, and it's not even clear what it means sometimes because of deep vs. shallow copies. Passing by reference is almost certainly better for efficiency, and often for correctness as well when copies becoming inconsistent with each other is a concern. I'd rather have pass-by-reference as the default, and have to work to make copies, than the other way around. 8 (local names) barely even make sense. Shadowing names, whether of variables or of modules/libraries, is a bad idea anyway. If you want the library and the program not to have the same name, use a prefix for each role. Expecting the language to handle this for you is just asking for trouble.
  • diminoten 8y ago
    Thank you for going point by point. I was blown away by how little experience the author had with Python, compared to how strong his opinion is about it. I hate hate hate language debates, but this isn't even that, it's just a misunderstanding. If this guy took a class on Python he'd figure out like 5 or 6 of these issues no problem!
• SamWhited 8y ago
  I tend to agree with the author (although not with a few of his specific reasons) that Python is terrible. Everywhere I've ever been that used Python they've claimed it was to make development faster, but mostly we just fought with bugs that cropped up around tests that were too aggressively mocked and weren't testing things, or stuff that somehow was in the wrong scope because someones editor was using the wrong type of whitespace, etc. And don't get me started how on every single code review I had to force people to write unit tests that wouldn't have to exist if there was a static type system to effectively be those tests for us. That being said, if your alternative is C or PHP suck it up and stick with Python. There is no situation in which PHP is the appropriate tool for the job, and as simple as C is and as much as I love it you're much more likely to introduce weird bugs and create broken software if you're using C. Python at least has some basic memory safety, even if its tooling and versioning is all horribly broken. As a user of software (and also a devloper): please stop writing things in C and related languages, if I keep seeing segfaults in popular products with huge QA teams behind them, I'm going to go insane.
  • capdeck 8y ago
    Wanted to second that the author mentions C as being "simpler" alternative -- doesn't make much sense as it is quite a "footgun" it itself. I'd much rather search for missing indents in Python than debug segfaults in C. Also, package managers are almost not a thing in C land. Did OP try Rust -- that may check quite a few of his boxes...
  • tabtab 8y ago
    Re: There is no situation in which PHP is the appropriate tool for the job... While clunky as a language, PHP's "environment" is better if you are doing web apps. Easier to install, including a test setup, more web-oriented libraries and functions, and a built-in HTML templating language for "view" pages (per MVC). If your stack is designed right, you'll be spending most your time plugging in parameters to API's such that the language itself won't make a whole lot of difference. You should be mostly gluing libraries, not writing an OS from scratch. If I were doing the second, then Python would be the better choice.
    • 8y ago
• drugme 8y ago
  If I have the choice between using some pre-existing Python code or rewriting it in C, I'd rather rewrite it in C. Go ahead, get your jollies and rewrite it in C. But will anyone else be able to read it and maintain it? That's the core issue.
• dheerendra73 8y ago
  Reason 5: Nomenclature That is problem with every single programming language out there. - Python array are not called arrays because they are not array in C/C++ sense. It's like saying in C++ lists are called vector and not lists/ArrayList etc. - Python library naming is inconsistent like PyGame, Numpy etc. Most of these mentioned libraries are third party libraries. How can a language enforce naming convention or documentation of a library? - If you pick all softwares and libraries for all languages, you can't guess uses for most of them just by name. What are WireShark, TimeMachine, ReactJS, Boost, Armadillo etc?
• t_fatus 8y ago
  I'm quite surprised by some of these reasons: - 1 & 2: just use virtualenv, js has its own version manager too (nvm) which is very useful. This is one of the reason why only python2.7 is included in OSX, since most of seasoned python devs not use it. usr/include vs usr/local/include in cpp are not easier to use / understand. - 3: my opinion is this forces you to write readable code, in which you don't have to ask yourself where the scope starts / ends - 4: since import use dot notation you just need to follow the path until you find a file and in this file the corresponding function. Or read the doc. Or use an IDE with autocompletion. Looking a .h files in c sometimes lead to using a wrong function judging only by its name. - 5: They are called "list" because they are lists, not arrays in a C sense (size not fixed) - 6: multiline strings are a mess indeed, but python3 handles them all in utf-8 (one of the reasons why it broke backward compatibility) - 7: just like js, making them 2 of the 3 most used languages. Understand the difference between pointers and references is harder to grasp for a beginner to just remind modifying the arguments of one method is dangerous unless you know what you're doing - 8: there is the from ... import ... which allows you to avoid this while being explicit
  • kemitche 8y ago
    > 3: my opinion is this forces you to write readable code, in which you don't have to ask yourself where the scope starts / ends I agree with this so much. I've never looked at someone's python code and had a moment's confusion about where a particular function ends. On the flip side, I see plenty of randomly/confusingly indented C/C++/C# code.
• dbllxr 8y ago
  > And Gawd forbid you make the mistake of running 'sudo pip', because that can screw up your entire computer! virtualenv is your friend.
• commandlinefan 8y ago
  There are two types of programming languages - the ones nobody uses, and the ones people complain about.
• honkycat 8y ago
  I will stick up for this person. I agree with all of the points listed here. But especially: Python version management and installation sucks. A while ago I had a broken python ship with my Ubuntu desktop. Pip decided they were going to deprecate behaviour, and nobody updated or tested on Ubuntu. Also it is slow and ugly. Just write it in Golang or something.
  • icedchai 8y ago
    Version management is pretty easy to solve: Just use virtualenv and you won't have a problem. If you start messing around with system level python package installs, you'll likely make a mess. As for ugly, I disagree and find Python some of the easiest code to read. "Slow" depends on the application. For 90% of the apps out there, you're waiting on something else (network IO, DB, etc.) and it's fine.
    • honkycat 8y ago
      I have used pipenv, virtualenv, pip, poetry, xyz. I still have consistent problems with package versions and the like. I like the library `invoke` for scripting A LOT, I just prefer to write my larger software in other languages.
• drosan 8y ago
  Loud title for an article from a person who has little to none experience with real life programming (imho). Talking about passing objects as a copy or by reference looked plain retarded even, he barely understands what are advantages or disadvantages of both methods. When I went down to reason 8 I was already utterly disappointed and felt like my time was wasted on a ramblings of 13yrs old that wrote "hello world" in 2-3 different scrypt languages and already thinks of himself an expert and a _hacker_ (that's even in the website title). Too bad it is a senior citizen that some people might have actually listened to and think he know what's he is saying.
• mherrmann 8y ago
  > My code for Python 3.5 won't work with the Python 3.7 installation unless I intentionally port it to 3.7. This statement is plain wrong at best and intentionally misleading at worst. 99.99% of Python 3.5 code runs unmodified on 3.7. > At the official Python web site, their documentation is actively maintained and available for Python 2.7, 3.5, 3.6, and 3.7 -- because they can't decide to give up on the old code. No. It's because some people still are on the not-latest version and still need access to the documentation. It's what every good project should do. I stopped reading there. Too much wrong in too little text.
  • fernandotakai 8y ago
    afaik the only thing on python 3.7 that is backwards incompatible to 3.5 is: > async and await are now reserved keywords. so unless the author is using async/await as variable names (and i wonder why they would), 3.5 code is going to run as expected.
    • mahoro 8y ago
      > and i wonder why they would It's easy, actually: import asyncio @asyncio.async # SyntaxError in 3.7 def my_coroutine(...): ... And since asyncio is one of the strongest reason to migrate to python 3.x, I bet far less than 99.99% of code written for 3.4/3.5 can be run on 3.7 with no changes. Luckly, 99% of changes were trivial. Other 1% is a nightmare.
      • blattimwind 8y ago
        Using async and await as non-keywords was deprecated since 3.5, while asyncio.async was deprecated since 3.4.
    • paulie_a 8y ago
      I wouldn't be surprised, I've seen a developer use type as a function name and it was imported everywhere...it caused a lot of problems. Not to mention the function literally did nothing, it essentially returned none under 99 percent of circumstances. If the person that wrote that was still at the company, that should have been a fire able offense.
• hpcjoe 8y ago
  I agree with a number of the author's points. For me personally, the biggest single issue is the scope by indentation. I know some folks like this, and think it is good to restrict single functions/methods to less than a page in an editor ... but I personally do not like a language imposing such opinions on me. It makes, IMO, reasoning about the code your reading, even if it fits in a single editor page, very ... very hard. As someone who works with multiple languages across multiple environments, the author's comments on the installation ecosystem are on point. Though, these critiques are better directed at the packagers of the distribution. I'd given up on getting current, correctly built versions of Perl, Python, R, Octave, etc. from packagers/distros, and simply build my own in a separate tree[1]. Most folks now do this in user home directories, but I still personally like the system level availability. FWIW, I've found that Julia[2] is a far better Python than Python. You have all the advantages of a JIT compiled language which does parallelism/concurrency well, has an awesome FFI to simply use external libraries, etc. [1] https://github.com/joelandman/nlytiq-base https://github.com/joelandman/nlytiq-base [2] https://julialang.org/ https://julialang.org/
• IvyMike 8y ago
  His early history of Perl is at odds with my memory. In my memory, perl was pretty great with not breaking old stuff. Even the pretty amazing feature set added between perl4->perl5 seemed a natural evolution to me. https://en.wikipedia.org/wiki/Perl#Early_versions https://en.wikipedia.org/wiki/Perl#Early_versions (P.S. yes yes perl 6 went kookoo crazytown, but that's not what he was talking about.)
• n-gatedotcom 8y ago
  I want to get a vote on indented nested blocks- how many of you like them? Please up the appropriate child comments (if I'm rate limited someone else please make child comments with like and unlike). My reasoning (please give yours below proper heading)- I'm deadly afraid of refactoring or even accidental indentation change.
• Nickersf 8y ago
  Someone's mad at some python code and needed to vent.
• sevensor 8y ago
  I'm taking this article as a lesson in humility. It's really easy to concoct specious reasons for hating something, reasons you believe you've backed up with sound technical and philosophical arguments, but which are really just rationalizations for your failure to understand it.
• markbnj 8y ago
  >> Most programming languages pass function parameters by value. If the function alters the value, the results are not passed back to the calling code. But as I've already explained, Python goes out of its way to be different. Python defaults to doing functions with pass-by-object-reference parameters. Python passes method arguments by value, pushing them on the stack like every other language I've used. Because everything is an object in python the passed _scalar_ values are references (addresses), the objects the references refer to are on the heap. I sometimes think literally everyone should have to use C for six months, most of this stuff would stop being debated endlessly.
  • brudgers 8y ago
    Everything in Python may be an object in some technical sense. Semantically, everything isn't. The utility of "everything is an object" is as a promise that lets programmers write: 3.fizzbuzz # returns "fizz" 5.fizzbuzz # returns "buzz" 7.fizzbuzz # returns 7 15.fizzbuzz # returns "fizzbuzz" as is the case with Ruby or Smalltalk. I think that the author's complaints center around Python behaving like C sometimes and Smalltalk other times. In particular, some operations happen according to the semantics of types and others happen according to the semantics of objects. At the lowest levels of Python, object oriented programming isn't available to do things like adding methods to Integer.
    • bakery2k 8y ago
      You can't add methods to integers in Python, but they're still objects in the sense that you can call methods on them: >>> i = 123 >>> i.bit_length() 7
      • brudgers 8y ago
        Some methods but not others. Specifically, I can call built-in methods, but not methods I define. For example: >>> def f(self): ... return self ... >>> (3).f Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'int' object has no attribute 'f'
• dangom 8y ago
  Actually, PyPI and PyPy are pronounced differently. The former is pronounced Pie-Pea-Eye, whereas the latter Pie-Pie. "PyPI (Python Packaging Index): said aloud by using its full name, or by spelling out the last two letters, as in "Py-P-I". Alternatives are to abbreviate as the "Packaging Index", or to use the colloquial nickname "the Cheese Shop" (which refers to the name of a Monty Python's Flying Circus sketch). Referring to the packaging index aloud as "Py-Py" is strongly discouraged, as "PyPy" is the name of a popular alternative Python interpreter." See, for example, https://github.com/pypa/python-packaging-user-guide/issues/89 https://github.com/pypa/python-packaging-user-guide/issues/8...
• androidgirl 8y ago
  For one and two: in what world is any of the software in repos like apt or yum up to date? Every time I set up an ubuntu machine for using at work, I end up compiling a few packages from source, a myriad of packages that are installed from app images or curl | bash installed binaries (like docker, ugh), and more PPA's than I care to keep track of and clean out. And now there's flatpack, snapcraft... packaging on linux is a mess currently. Honestly, on workstations the rolling release model is the only one that makes sense. But for python, with tools like pyenv, virtualenv, or even just using LXC/docker/vagrant/whatever, versions in the 3.5-3.7 range are a non-issue. I agree the quotes thing sucks, though. I wish there was more enforced discipline on that.
• Agathos 8y ago
  As far as I can tell, nobody creates new code for PostgreSQL 9, but we drag it along because nobody's ported the needed code to PostgreSQL 11. At the official PostgreSQL web site, their documentation is actively maintained and available for PostgreSQL 9.4, 9.5, 9.6, 10.6, and 11.1 -- because they can't decide to give up on the old code. PostgreSQL is like the zombie of relational databases -- the dead just keep walking on.
• sli 8y ago
  > And Python? It uses spaces. If you need to define a scope for complex code, then you indent the next few lines. The scope ends when the indent ends. Curiously, I never see the indent scope complaint about, say, Haskell. It's always just Python. I've wondered for a long time why that is. There's the obvious one, that Python is just far more popular, but I'd expect experienced people to have used or at least seen another language that does it.
  • the_gastropod 8y ago
    No idea if this is true, but my gut feeling is Python is commonly written in an imperative style, whereas Haskell is more functionally written. Imperative style (especially at the beginner level) tends to include lots of nested conditionals which quickly create this indentation triangle of confusion.
• amelius 8y ago
  Author forgot to mention: - The GIL (global interpreter lock), which can in some cases reduce your multicore CPU to a single core CPU. - No multiline lambdas. You can't write a quick anonymous closure and pass it to another function, unless you manage to fit the whole thing in one line.
• nurettin 8y ago
  As a python newbie, I've had some trouble with the unstable async API (many differences between 3.6 and 3.7 and within minor versions of 3.7). Many ways of accomplishing the same goal with slightly different side effects are off-putting. Another problem is packages. Authors don't really care about fixing dependency versions (had trouble with celery, quart and redis so far) we have much less trouble with node in this respect. plus sides are: vs code has been amazing. pipenv is almost good enough. Community is great.
• juhzy 8y ago
  Python sucks because how slow it is. The rest of problems pale in comparison.
• paavoova 8y ago
  Not mentioned under quirks/syntax: - Special-snowflake, verbose ternary syntax (expr if cond else expr) - (De)evolution of language features over time, such as format strings (from "%s" % val to "{}".format(val), and now to format strings f"{val" - Poor design decisions all around, and stubborn in its refusal to admit wrong, such as the sudden but long overdue addition of assignment expressions - Lack of control flow like switch statements, leading to data-structure abuse e.g. via dictionaries The recent addition of assignment expressions provoked much discussion and much effort into its proposals, but, outside of Python's echo chamber, it's a language feature that most other languages have, and that should have just been included from the beginning. Instead, decades after the fact, the language is tacking on the syntax and pretending it's some genius new feature.
• jMyles 8y ago
  I saw "Reasons Python Sucks" on HN and I thought I was going to finally see an updated list of well-informed and articulated concerns about Python. Instead, this list is bizarre, misinformed, and largely incorrect. Other commenters have already pointed out several specifics. Two things I haven't seen yet that I'll add: > And I pity anyone who miscounts spaces and accidentally puts in three spaces instead of four somewhere -- this can take hours to debug and track down. This is just absolutely batshit ridiculous. You'll get an IndentationError pointing to the exact line in question. In all my years of working with people at all levels, I've never seen anybody spend more than a few minutes working out an IndendationError. > <Pass by reference/object> is one of the big differences between procedural, functional, and object-oriented programming languages. This is a non-sequitur, and it's plain to see. It's possible (in fact common) to write with all three of these orientations in python, and object transit has absolutely nothing to do with it.
  • heavyset_go 8y ago
    Came to a similar conclusion. I use Python a lot, and it certainly has its problems. However, the article's analysis doesn't even begin to scratch the surface of this topic in an informed manner. Instead, we're presented with paragraphs written by someone who can't read a stack trace: In [7]: def foo(): ...: print('foo') ...: print('bar') File "<ipython-input-7-47f5b52e9e07>", line 3 print('bar') ^ IndentationError: unexpected indent
    • mangodrunk 8y ago
      Isn't that a strawman? Wouldn't a more apt example be: def foo(): nums = [...] sum = 0 for x in nums: print(x) sum += x I don't know python well, but it seems like there could be subtle issues with indentation that wouldn't cause a compiler error, but would cause the wrong output.
      • jMyles 8y ago
        1) This is not the case that the author presented, though - it was specifically about 3 spaces instead of 4. This tells me that the author simply doesn't hang out with python people. 2) On the substance of your concern: I think the evidence is clear (although I'm aware of no study) that having both syntactical control characters (typical curlies) and style-only indentation is more likely to lead to the outcome that you present, because the eye will always gravitate to read by indentation, whether it's syntactical or not. So have the indentation be the syntax makes this problem more easily avoided, not less. IE: def foo() { nums = [...] sum = 0 for x in nums { print(x) } sum += x }
• arduinomancer 8y ago
  What is he even trying to say in the pass by reference part? Does he want the language to automatically deep copy objects every time they’re assigned?
• PaulHoule 8y ago
  The version problem is Python being a victim of its own success. Since so many Linux distros used Python 2 for system scripting, you still have to have a Python 2 sitting around on your system somewhere. Then people came along with "python3" and (yikes!) "pip3", but now you might have python 3.4, 3.5, 3.6 and 3.7. The transition was pretty painful because of the Unicode thing. It does make it painful, though, to give people instructions on how to use Python-based software products. I am converging towards the solution, however, of installing Python straight from the python web site with the appropriate version, hiding that Python somewhere where people won't mess with it, then working out of a venv. Even though I have trouble with the implementation, I like the idea behind pypoetry. If it were me though, I'd put in a real SMT dependency solver because you don't need to download a whole wheel to get the dependencies, you just have to look at the ZIP directory at the tail of the file and you then grab the metadata file and leave the rest. When kivy officially supports asyncio and they make it a little easier to install cross platform (e.g. brew was down for me over the weekend) that will be nice.
  • orf 8y ago
    > I am converging towards the solution, however, of installing Python straight from the python web site with the appropriate version, hiding that Python somewhere where people won't mess with it, then working out of a venv. Pyenv[1] is your friend. pyenv install 3.6.4 1. https://github.com/pyenv/pyenv https://github.com/pyenv/pyenv
    • PaulHoule 8y ago
      That "shim executable" trick sounds evil to me.
      • orf 8y ago
        How so? There are lots of evil tricks at most layers. This one is particularly effective, and I can't think of another solution to it.
• trumped 8y ago
  for me, the main reason why python is not as good as it could be is because of the slow interpreter
• VectorLock 8y ago
  A lot of these "problems" are things I love about Python. I complained about the whitespace thing back in 2002 before I really loved Python too. And trying to make out poorly named projects as a Python issue? Please.
• bakery2k 8y ago
  Regarding reason 3 (syntax), I don't mind significant whitespace in itself, but it has knock-on effects which can be problematic. It's the direct cause of Python's `lambda` limitations [1], and IIRC the lack of an explicit end-of-block marker is also the reason for Python not having `do-while` loops. However, what would be the alternative to significant indentation? I really don't think C-style syntax would work for Python... [1] https://www.artima.com/weblogs/viewpost.jsp?thread=147358 https://www.artima.com/weblogs/viewpost.jsp?thread=147358
• zzo38computer 8y ago
  I thought I was the only one to put debug code in the first column. (The code doesn't last long; generally debug code in the first column is expected to be removed very soon; debug code that lasts longer goes in its proper column.)
• deleted 8y ago
  [deleted]
• agounaris 8y ago
  Yea you cannot do molecular meta-dynastic micro transdusevelociraptatable programming
• altmind 8y ago
  One of my biggest gripe is how python have a hidden non-declared agenda to have syntax as far from C as possible. its really not giving language any usage benefits when you cannot use ternary expressions, ! as not, !=, increment operators. Also, PEP8 is very very presriptive, you are disallowed to do violate any rule, even when if you need to to make the code better. (I feel shunned by the community for not liking 80 chars line hard breaks) Python3 migration was not planned well - the lack of back and forward compatibility gave users a legit reason to stay with python 2 forever. I've seen some conference talks where end users/projects being shamed for not jumping on python3. GIL in python is something that was talked about 5 years ago and will still be talked in 5 years. It limits the ability of python to reap the benefits of better hardware. This may be minor, but I really missing ruby rich set of collection methods: take_while, group_by, sample. Yet I can see a point in extracting that to a external library. Of course, all this does not mean python is not good. Builtin pip/venv, adrequate unicode in python3, some of fantastic libraries(numpy/scipy, bokeh) making it indispensable.
  • acdha 8y ago
    > GIL in python is something that was talked about 5 years ago and will still be talked in 5 years. It limits the ability of python to reap the benefits of better hardware. It's also a huge source of misattributed problems — I've seen more cases where a complaint about the GIL was really “my algorithm depended on a single locked data structure” or “I was calling a C library which isn't thread-safe” than where the GIL was actually the limiting factor. That's not to say that there aren't real problems for people who want to run pure-Python computational code (not e.g. libraries like Numpy or Pillow) but it also seems to be popular as the bogeyman to blame when someone doesn't want to run a profiler. > This may be minor, but I really missing ruby rich set of collection methods: take_while, group_by, sample. Yet I can see a point in extracting that to a external library. See https://docs.python.org/3/library/itertools.html https://docs.python.org/3/library/itertools.html and https://docs.python.org/3/library/random.html https://docs.python.org/3/library/random.html for the sample function. I believe the difference is mostly that the Ruby methods are on Array but the Python ones are seen as processors for iterables so they're in a separate part of the standard library.
  • Havoc 8y ago
• minimidge 8y ago
  nods head and agrees But I still love Python XD
• corydominguez 8y ago
  I agree with a lot of these points. To get around them I created https://github.com/c11z/python-mk https://github.com/c11z/python-mk which is a make file that contains the seed of a python development environment. It uses docker containers to get around most of the issues this article brings up.
• metaculus 8y ago
  Though it's an opinion piece and I don't agree with all the points, some I do. The readability issue is real when dealing with any code more than a hundred line, and worse the convention seems to encourage using empty lines very sparingly. The shortcomings came out clearer as I've been teaching someone to program in Python. The subtlety of per-scope indentation really confused her. The concept of a "block" is just not visually clear. Not to mention mixing spaces and tabs by accident. That could halt a new programmer for an hour.
• projektfu 8y ago
  The random complaint about Perl version compatibility was particularly bizarre. There was really no incompatibility between Perl 3 and 4. Then I guess all those people got fed up and quit using Perl when they made the next version and it was left in, what? a 15 year glory period where several orders of magnitude more software was written with it? Talking about how there's very little new software written in Perl now is definitely using post-hoc reasoning. There's probably a language named after a British comedy troupe that is somewhat responsible.
• Koshkin 8y ago
  Strong opinions usually come from a lack of experience.
• davesque 8y ago
  I feel like it's sadly telling that such a poorly written article has managed to sucker at least 175 HNers into up-voting it (assuming that's how the score system works).
• preordained 8y ago
  For me, the siren call of Python was the supposed "elegance" (executable pseudo code!). But then you have these horrible non-composing list comprehensions (compared to say Ruby where the chain just flows from left to right instead of getting more and more nested), and that god awful "self" and "__init__" cruft. It just seems like a poorly designed (and/or evolved?) language. It'd be nice if something else would carry the torch for nice AI library wrapper language...that alone is the only thing that can tempt me touch it.
  • zmmmmm 8y ago
    It's such an odd mix of elegance and completely half-assed botched up language design isn't it? It always feels to me like one of those movies where they ran out of budget half way through and hastily pasted together the rest of the script.
• cleandreams 8y ago
  I'm a python hater. Yes it is easy, but in exactly the wrong way. Easy for simple code for middle schoolers. For grownups with large codebases to develop and maintain, it's not optimal. Of course I hate the whitespace trickery. I hate the auto formatting that sometimes doesn't work. Those are fairly minor. What I really, really hate is the lack of static typechecking. You often have to read lengthy swathes of code to understand how functions are actually used. The conventions in the community are terrible. I have used respected libraries where functions are designed to return a variety of types, just because, so you need to dynamically typecheck your results. Gawd. And just as bad the fact it is impossible to encapsulate code. This underscore nonsense, don't even mention it. Sheesh. I have found that in real life, internals bleed out over the code base making code more fragile over time and harder to refactor. It has all these open source scientific libraries because professional programmers were working on other things, and that is truly unfortunate. The lack of seriousness is demonstrated by the fact that it's frozen in time in terms of runtime data structures because cpython knows and relies on those internals. Nutso. And then the GIL!! What the ?@.
  • xtracto 8y ago
    I used to program in Python, and found Ruby as a language to give me everything Python provides but with a more Programmer friendly syntax. I never understood why you would use a function like len() in an Object Oriented Language (instead of x.len ) or having to explicitly add self to every method...
    • orf 8y ago
      > I never understood why you would use a function like len() in an Object Oriented Language (instead of x.len ) or having to explicitly add self to every method... The answer is simple: there is a x.len function. It's just x.__len__, the protocol. Forcing it to be exposed on every type is a waste: do you use .len, .length, .size? This duck-typing allows any object that supports the length protocol to be passed to `len()`. Simple. Having it add itself to every object is.... not what you want at all. Some objects don't have a length.
  • ubernostrum 8y ago
• mixmastamyk 8y ago
  This article gets worse with every paragraph: > My code for Python 3.5 won't work with the Python 3.7 installation unless I intentionally port it to 3.7. Probably not. While I can't guarantee there are zero breaking changes, it is highly unlikely to encounter any from 3.5 to 3.7. Another numerical pair might have been a better example. The split between 2/3 was an issue, widely known, and in the past. Personally I'm glad some big problems in 2 were fixed, though there was some pain. > When Perl5 came out, a lot of people just switched to a different programming language that was more stable. Nope, Perl 5 was incredibly popular. It was 6 and the two decade wait where folks jumped ship. > And I pity anyone who miscounts spaces and accidentally puts in three spaces instead of four somewhere -- this can take hours to debug and track down. Nope, it tells you the first line where the indent is wrong. > imports: then search every file in every directory Nope, just type import ... If you want to know which file it found, print(module). .... Others have found the other issues. Most of these are nitpicks from someone who doesn't fully understand or agree with the tradeoffs chosen. IMHO, the biggest design flaw left in Python is that it is always dynamic and that's what makes it so slow. Why too dynamic? Well, changing types of variables isn't used much in practice. So, to pay a time cost for it on every single line is unnecessary. If types were fixed by default but let you opt in to dynamic when needed, we'd have the best of both worlds. Speedy most of the time, dynamic and slow when actually useful. Basically whole infrastructures like Cython have been built to correct this.
  • a-dub 8y ago
    hah yeah, perl5 was basically perl's renaissance. the web took off and perl was basically used to glue it all together. they did go crazy with perl6 though, and i think a lot of the reason why python took off was because of the hole the perl developers left and google liked python. it seems the performance problems in python can (and are) being fixed. the big downsides i see are the 2to3 mess (which seems like it will be solved with time), weak concurrency support in the default implementation and the lack of the ability to do much real static analysis. makes for great interactive glue though!
• jimnotgym 8y ago
  I'm not even sure his pronunciation anecdote is true. Pypy is pronounced pie-pie PyPI is pronounced Pie Pee-Eye Isn't it?
• nickthemagicman 8y ago
  I personally do not think python is more readable than other langs. Making a language more Englishy, does not make that language more readable. I still have to learn what the hell the syntax is trying to express except the English makes it more verbose.
• rienbdj 8y ago
  I don’t like Python, but not for the reasons given. My dislikes: - no pipe operator - no type checker (something Flow would do) - over dependence on whitespace syntax
• hyperbovine 8y ago
  If someone forced me, an avowed Python lover, to write 1000 words about why I hate Python, I imagine it would turn out something like this article.
• turlando 8y ago
  >The Python manual says that you can use any number of spaces or tabs for defining the scope. But it doesn't. In Python only modules, classes and functions make a new scope. A block doesn't. (And that's because it "forces" you to write small self-contained functions.) It's funny that he also links to a documentation page that clearly doesn't talk about scope at all. Personal reflection: I rarely rant publicly about something, but when I do I make sure that I'm not saying something stupid that a quick google search can refute.
• kekeblom 8y ago
  The thing that actually sucks is in python is parallelism.
• mindcrime 8y ago
  I don't think the author of TFA makes the case he's trying to make at all. And mind you, Python isn't my first or favorite language, and I'm not particularly biased in terms of defending Python. My language of choice is Groovy in most contexts. Anyway, this all seems like a lot of nit-picking to me. Yes, these "issues" are real, they just don't amount to much. And basically every other language has an equally long list of similar nits you could pick. If the author had called this "Reasons Python Sometimes Annoys Me" then I could get behind that. But none of this, IMO, reaches of the bar of establishing that the language "sucks".
  • mixmastamyk 8y ago
    Right, Python is better than most in terms of nitpick-ability. It's one of the only mainstream languages to make it big without corporate support due to that.
• GuB-42 8y ago
  The one good thing with Python is that it is great at making beginners write readable code. I had nightmares about code written by scientists who certainly were experts in their fields, but their coding skills were limited to the bare minimum for running their calculations, once. With python, not only their code is readable, but they also enjoy using it. For more advanced programming however, it is a mess, and I understand the author. It limits your option so that there is basically only one way to do things (the opposite of Perl), it makes it annoying to write since even debug code needs to comply. But on the other hand, it gives you constructs that are very permissive. Pass by mutable reference is an example: there is no easy way to know what will happen to your arguments. You can completely modify just about anything so that even simple operations can do really weird stuff in the background. Flexibility is nice but it feels strange for a "clean" language to let you mess things up so deeply with very little safeguards.
• golergka 8y ago
  > In contrast, many Python modules include initialization functions that run during the import. I just thought it's a natural consequence of a dynamic languge. Defining a class IS running code - you can even decide to define or not to define something based on a runtime random roll.
• jancsika 8y ago
  > PyPy, PyPi, NumPy, SciPy, SymPy, PyGtk, Pyglet, PyGame... pyimport pygame Name two things wrong with what I wrote above.
• jcranberry 8y ago
  I don't often use python nor do I know it well but it's obvious to me that several of these points are stupid, misinformed or wrong. Numbers 3, 5 and 8 are just nonsense whining. Number 7 is terribly wrong. I find it incredibly surprising that this person got a Computer Science PhD while confusing Python lists with arrays and not knowing that pass by reference semantics is by no means niche.
• kanox 8y ago
  Obligatory https://xkcd.com/1987/ https://xkcd.com/1987/
• lajun 8y ago
  I can't believe this was upvoted. These aren't reasons that Python sucks, they're nitpicks from a guy who has decided long ago that he knows what he likes and refuses to try anything else. > "If I have the choice between using some pre-existing Python code or rewriting it in C, I'd rather rewrite it in C." I should have stopped reading there, because this shows just how set the author is in his ways. Both languages have a place, and if I'm writing a web scraper, you can bet your ass it's not going to be in C.
• triMichael 8y ago
  My take on this is that it has some valid points, but is mostly unjustified rants: 1. Versions: Definitely an issue with Python, the v2 to v3 split was a huge mess and is Python's biggest issue IMO. 2. Installation: Pros and cons, what I find is that Python tends to be easy to set up, but that it does it automagically for you via pip, which means if you run into trouble it is harder than doing it manually 3. Syntax: Python's syntax is wonderful and I find these arguments mostly flawed. The space vs tabs wars are the exception and a valid criticism that the language doesn't force one or the other. As someone on the tab side, I don't run into his issue at all of accidentally putting 3 spaces instead of 4 in, but then I do run the issue of going against the language's grain so to speak. On the other hand, his issue about deep nesting is a problem in any programming language - unless he is not indenting properly when he wants to, which is my guess. If that is the case, that will cause severe issues when anyone else tries to read it! Debug code without indents also sounds like a bad idea to me. And even if you aren't a fan of Python's whitespace, I find that there are other features, such as using words instead of symbols (and, or, not instead of &&, ||, !) that definitely make Python one of the most readable languages out there. 4. Includes: I'm mixed on this one. On the one hand, I don't understand the first half of what he is saying, I have to go track down includes in any language. In Python at least I only have to deal with one include, whereas in C and C++ I have to go track down two, the header include and the actual library. This mostly seems to be complaining for the sake of complaining. The last bit I personally agree with though. I once worked on a project that would analyze other people's Python code. At first Python seemed to do this extremely well as it can take any Python code and change it into its abstract syntax tree for further analysis. However, I soon found that in order to do this, it would have to execute any global code while it was reading it! I'm definitely not a fan of how Python technically runs anything it imports. 5. Nomenclature: Definitely unfair criticisms here. First, Python's lists aren't arrays but are lists! Arrays are blocks of unchanging memory, whereas lists are a structure that under the hood points to an array, but that array can be deleted and reallocated to resize it. I admit, I've never liked Python's word for dictionaries, but I don't like hash either, I think map is the better term, but it's still just a single name of a concept, not a huge deal. His arguments about the names of libraries are stupid, they are third party libraries that Python doesn't even control! And as someone who is very picky about function and variable names, a library name hardly ever matters, especially as Python allows you to rename imported modules. 6. Quirks: I don't even understand what his complaint is here. Does needing to triple quote multi-line strings really bother him that much? The binary and raw syntax might be a bit confusing, but I'll take that any day over C++'s L"" for wide strings and _T() for strings that may be wide or not and are determined at compile time. The string vs unicode is a bit confusing, I'll give him that, but I think the entire concept is confusing in any language. 7. Pass by object reference: I actually completely agree with him here, though I don't know how Python would fix this. I think I can explain it better than he does though. The issue is that if you create a list "list1" and then set "list2 = list1", and then append the element "3" to list2, list 1 changes as well even though list1 was never directly changed. This was one of the biggest things I struggled with in Python until I learned C++ better which taught me how Python was working under the hood. Python makes you think that it doesn't have pointers, but the truth is that everything in Python is a pointer, which I found confusing relative to how everything else in Python was beginner friendly. 8. Local names: I don't really understand his complaint here, don't shadow names.
• Walkman 8y ago
  A great example of how Trump has been elected. He lied a lot, (or said stupid things because he was ignorant in a topic) but it doesn't matter, because rebuttal takes a bit more effort than saying stupid things so what he said stuck with a lot of people. Sorry, but this article is just ignorant in almost every point.
  • dragonwriter 8y ago
    > A great example of how Trump has been elected. He lied a lot, (or said stupid things because he was ignorant in a topic) but it doesn't matter A number of the people with federal felony convictions, some having already gotten federal prison sentences to go with them, for their role in supporting Trump's dishonesty might quibble with the “doesn’t matter” characterization.
• Annatar 8y ago
  While I agree with the author's reasons why Python sucks ass, he's wrong about Commodore but thinks that he isn't: "Where's Commodore today? It died out as users abandoned the platform." No. Commodore died because Irving Gould told Tramiel to pack his bags and go when Tramiel told him it wasn't okay to use company's assets like the jet as personal property. Once Tramiel was fired, the company was plagued by chaos and mismanagement, but it had nothing to do with how bad or good Commodore's computers were. It's the 21st century and people still write fresh software and design modern hardware for Commodore computers, so they've never been abandoned.
  • DerekL 8y ago
    He gets so much wrong in that paragraph: > Commodore created one of the first home computers (long before the IBM PC or Apple). Commodore, Apple and Radio Shack all released home computers in 1977. Six months is hardly “long before”. > But the Commodore PET wasn't compatible with the subsequent Commodore CBM computer. He must mean the CBM-II, because the original Commodore CBM machines were just rebranded PETs.
• CiPHPerCoder 8y ago
  > Inevitably, the discussion will turn to programming languages. One might lament "I have to modify some Java code. I hate Java. (Oh, sorry, Kyle.)" (It probably doesn't help that we gave Kyle the nickname "Java-boy" over a decade ago.) This circle of "friends" sounds like a toxic environment where apologies are empty and contempt runs rampant. Are they truly sorry for what they said, or are they sorry they said it to Kyle's face?
• zmmmmm 8y ago
  Well, I do think Python sucks but those reasons have relatively little to do with it to me. I just don't like it from an engineering point of view. - lack of proper typing - it pretends to have a type system but hardly enforces it anywhere at least with any of the common practices used by the community. 'quacks like a duck' is a completely asinine excuse for not properly using types and interfaces. - lack of true multithreading (aka, GIL): if you can't use all the cores on your computer you drastically limit the scope of applications that can be implemented. No, I don't want to restructure my application into a distributed multiprocessing system just to access the basic capabilities of the CPU in my computer thanks. - lack of true cross-platform. partly because of the previous point half of Python's ecosystem is written in C and needs to be compiled for (if not on) the target platform. Python tries to pass as a language with Java-like bytecode but the reality is it doesn't even come close to that. We regularly try to install Python tools and find that they can't run because some obscure shared library isn't available on our system, etc. Mostly, I dislike Python because it seems to be such a trap for new programmers who learn programming in it and then think they should never have to learn anything else. Trying to coach people on my team who started with Python to use or learn anything else is extraordinarily difficult. I remember when Java was like that and it was ugly then - it's just as bad if not worse with Python.
• exabrial 8y ago
  Python: something you can't see causes significant change in program behavior. Go: Something you see ends up as a compiler error. Oft heard is the bellyaching cries of the proponents that try to conflate these two things, but they are not the same thing. One results in bugs, the other can be bypassed. Most languages opt for the second. (With Java for instance, most shops have a checkstyle gate in their build process).
• tanin 8y ago
  Coming from Ruby, I encountered this funny situation in Python. I was looking how to get first element of an array or get nil if the array is empty. Python library doesn't provide this kind of functionality. https://stackoverflow.com/questions/363944/python-idiom-to-return-first-item-or-none https://stackoverflow.com/questions/363944/python-idiom-to-r... offers multiple ugly ways of doing it. For Ruby, we use `.first`. In Ruby, the standard library is richer. A lot of libraries are "official" because Rails uses it.
• firefwing24 8y ago
  People hate on spacing, but people rarely talk about the benefits that specific spacing has. Yeah, sure, you can complain about how strict it might be, and complain about how it can cause bugs when something is mis-indented. But it's not like brace-languages are perfect either. How about people who mix tabs & spaces within a single line because of lack of discipline or maybe a mistake from refactoring code? Imagine that nightmare of rereading that based on what editor you use. Missing braces can sometimes be annoying and difficult to find, and placing the brace in the wrong place can result in bad code. Isn't that equivalent to a lingering whitespace in Python? Yeah sure, you might say "Once you code enough, that usually doesn't happen" But Pythonistas can say the same thing with their indentation. It's just a different way of programming. Get over it.
  • cageface 8y ago
    The more serious issue with significant white space is that it makes writing code formatting tools like Prettier impossible. That’s too much to give up to avoid having to write an extra brace or two IMO.
    • minusf 8y ago
      heard of black?
• Gatsky 8y ago
  Interesting to compare R on these specific pain points. I’m ignoring 5,6 & 8 because they are silly (you have to learn the language to use it at the end of the day). 1. Versions. R gets updated quite frequently, and most users just update regularly. It is rare for there to be breaking changes. Packages often require the latest versions of R, so that is an issue. 2. Installation. Well on linux distros R often has the same problem, you install R with the package manager and it isn’t clear which version it is. Some additional config is required to make sure you get the latest version. This is explained on the R core website. On windows and Mac, this isn’t an issue. 3. Syntax. If you don’t like indents then R is your friend. The syntax is pretty flexible compared to python. For data science this is a plus in my book. 4. Includes. In R, for larger projects the issue is dealt with by turning your code into a package, which is quite neat and tidy. 7. Pass by object reference. R functions default to pass by value. You can still mess around with global state if you want to complicate your life.
• jhuni 8y ago
  One note about point (2) dealing with the versions and the languages object oriented features. I noticed the object-oriented support has been tacked on, before Python 2.2 the objects had their own type which was accessed by .__class__. The tacked on nature of the OOP support of the language is perhaps why there are these __identifiers__ which are hard to type using consecutive letters, needing shift to be held down, are still used in the language. Although Python fixed the problem partially, it only did so only by adding new style classes along the old style ones in order to avoid breaking compatibility, which only complicated the issue. Unfortunately, Python 2.7 is still around. As this post mentions, Python 2.7 & 3 are both installed on Linux machines and the default is still Python 2.7 when you type python.
• raldi 8y ago
  One more for the list, and my all-time most hated Python annoyance: No equivalent of Perl's "use strict vars". In other words... blah = 1 if foo: balh = 2 print blah ...doesn't let me know I've made a typo the way the equivalent Perl would: my $blah = 1; if ($foo) $balh = 2; print $blah; Which outputs the following even without "use strict vars": Name "main::balh" used only once: possible typo And if you turn that on (like all Perl programmers have, in all their programs, for decades): Global symbol "$balh" requires explicit package name
  • mixmastamyk 8y ago
    Ya know this isn't a bad idea to float on python-ideas. I first thought pyflakes would flag it, but it doesn't. Don't think it would hard to implement a warning, without need for strict, as python already spits various warnings when given non-optimal code.
• Chazprime 8y ago
  There certainly are some drawbacks to using Python versus another language like C (I’m thinking of the GIL in Python 3 specifically), but I’ve yet to find a better language with which I can prototype reasonably complex applications in the space of an afternoon...even GUI apps with Qt.
• calhoun137 8y ago
  At the end of the day the thing that makes Python the best programming language is not actually the language itself, which has a lot going for it, but the community around it. The python community is the full of extremely good programmers, and there is a vast ecosystem of first class resources that are available for everyone. Yes, these are all valid points, and I laughed. Holding up javascript (npm anyone?) as some kind of counter example that proves python is bad may have held some un-intentional humor as well. Don't get me wrong, I love js but it seems to me like if you took these same 8 points and made them about javascript it would be 100 times more damning. Heck, I am even willing to count this great article itself as a reason to love the python community even more. Someone who hates python so much must do so from a place of extreme love.
• luord 8y ago
  > because someone thinks recursive acronyms are still funny Not that I was expecting depth from a site called "hackerfactor" by a guy who wrote something like "open source sucks", but seriously, this middle school level "sass" (and about a popular practice at that) shouldn't be near tech writing. Should have stopped reading there. On that note, this has way too many upvotes for such a misinformed, badly written, sophomoric piece.
• rafaelvasco 8y ago
  I can only agree to his hate of spaces. I personally hate space based languages. It only brings annoying problems and you have to care for things (spaces/tabs) that you shouldn't have to care about in the first place. {}'s -> Love.
• jonnycomputer 8y ago
  import numpy as n seriously? the community norm is: import numpy as np and because its a norm, nobody is confused. But the author certainly is. the whole list of complaints basically exposes his basic lack of familiarity with the language.
• Lazare 8y ago
  About 1/4 are valid, important criticisms, another 1/4 are technically true but quite trivial (and are mostly caused by his very idiosyncratic coding habits), and 1/2 are just howlingly wrong, mostly in that order. A decent chunk of the actually correct ones seems to boil down to "C does it differently", which well...if that's you're yard stick, you're going to be pretty busy criticising other languages. I've got to call out his point 7 in particular; it's so wrong it kind of makes me wonder what he was trying to say. He's calling out Python for not following a convention that doesn't exist, nobody else follows, couldn't even work, and which you wouldn't even want. What in the world?
  • mark-r 8y ago
    Point 7 is only relevant because it leads to behavior that's not intuitively obvious. If you reassign an object in a function then it's not visible outside the function, but if you modify the object it is. That's a very subtle distinction.
• est 8y ago
  These are the reasons why python sucks? Gosh python must be a pretty good programming language.
• mark-r 8y ago
  Why hasn't somebody come up with a code editor that shows left-brace or right-brace in the left margin when the indentation changes?
• lindbergh 8y ago
  Python is like democracy. It's the worst programming languages except for all the others.
• KK89 8y ago
  I dislike python I love Matlab！
• KK89 8y ago
  I dislike python but I use it sometimes. I love Matlab, and I usually use it.
• yellowapple 8y ago
  I also rather strongly dislike Python (which tends to be a problem given that my employer's engineering team uses Python for everything, whereas I very much prefer to use the right tool for the job - which might be Python sometimes, but not often, let alone always). Whitespace-sensitive languages are - in my opinion - not at all user friendly, and the quirks around passing variables by object reference (like how you should never do "def foo(bar=[])" unless you want bar to equal [1,2,3] when you call foo() after having previously called foo([1,2,3])) make JavaScript look somewhat sane. I will say, though, that I don't mind Python calling things lists and dicts. Those are indeed common terms (both are used in Erlang/Elixir), and reflect the fact that there are multiple possible implementations (lists might be arrays, linked, double-linked, etc., and dicts might be hash tables, keyword lists, etc.).
• perrychan 8y ago
  You are right! Any language has its disadvantages. Btw, I'm very interested in which programing language you're using mainly? Would you like to share with us? Thanks in advance ^_^
• bribri 8y ago
  if you could only chose one language for server side "web apps", would you choose python or javascript?
• qwerty456127 8y ago
  Looks more like a proof Python is near-perfect to me. Because they've tried to write a list of what's wrong with Python and failed to name a single real problem/quirk you even have to know about. I've seen lists illustrating how JavaScript, PHP, C++ and other languages are bad and they all made me feel like "that's so crazy I will never code this language!" but this list for Python is just "pff... will you name a single thing that is not a minor inconvenience?". The only thing that really annoys me about Python as a language (and it still is just an inconvenience and a matter of taste) is the file=module thing, I want to split a module into a number of files so I could define every class in a separate file without having to import every one from a separate module then, C# namespace model feels a way better. I would also love to see 1-st class support for type enforcing (i.e. if I define a "type hint" and a value fails to comply to it should raise a warning) and support for immutable variables (that can only be assigned once). Using 4 spaces per indentation level indeed sucks (I would prefer 2 spaces) but this is not a language problem and its seriousness is futlie.
• SilverSlash 8y ago
  How does this garbage make it to the front page of HN?