Why Python Is Not My Favorite Language (2016) (zenhack.net)

It's refreshing to see criticism of Python that is not merely a rehash of the Python 2 vs. 3 whining.

> Documentation. There’s a common mis-conception that type systems make code verbose. Firstly, type inference is pretty doable and addresses the problems that give rise to these beliefs. Java and C++ aren’t verbose because they have type systems, they’re verbose (partially) because they have bad type systems. Second, in my experience, actually clearly documenting an interface in a language that doesn’t have types ends up being much more verbose than it would otherwise be. You need docstrings regardless, but if the type of the thing says it’s an integer, you don’t have to write “x is an integer” in the docstring too. And now you have a concise, agreed upon notation for that sort of fact.

Preach it. Also, you don't have to worry that a method whose signature is `public int DoWork(string input)` actually expects char[] as its input and returns a long, the way you do when the types are only documented through comments.

I don't know, that sound like details to me, or even taste.

There are many more important problems with Python: packaging, no way to know which exception you are gonna get, no nice async web framework and so on.

But this? You have those in any languages.

The first couple points ("encapsulation", specifically no private vars) and interface conflicts are not issues worth complaining about.

More importantly, we have 0 evidence that using private/protected in software is better than not. People like to use them because, as the author notes later in the Type System comments:

"Refactoring. If I’ve got a type system and I’m faced with needing to clean things up, I can put stuff behind an interface and follow the type errors to find everything that needs updating. Often in dynamic languages, even with a decent test suite, extensive changes can be really difficult."

You shouldn't have a workflow of fix failures blindly and private variables contribute to that style of over-reliance on language features instead of actual attention to detail.

That being said, the world isn't perfect and it's common to take this approach if you have a lot of strong language safety features and are under time pressure (who isn't). In my experience, this situation means things are being rushed and/or the developer is burned out to give up such fine grained control over the code.

  Point = namedtuple('Point', ['x', 'y'])

  Employee = typing.NamedTuple('Employee', [('name', str), ('id', int)])

I hate python because of the indentation. I know it's stupid, but I hate it.

   if (a == b) 
        do_this()

        and_always_dothis()

   object = ClassName()

   object = ClassName.new # Ruby
   object = new ClassName(); // Java

About the only two things I'm going to agree with here is the single underscore and lambdas. The single underscore import behavior is, by and large, a wart. You effectively can do "the same thing" two different ways and get two different outcomes. It is non-intuitive and error prone. That needs to get fixed.

I like to use Python for quick, fast, flexible things.

I like to use Java and Go for things that require more structure and type checking.

I like to use Scala for functional programming.

I suppose we all have our preferences, but I'm glad the author uses the word "favorite" because there are great cases to be made for every technology out there.

Python feels to me like a nifty little language that's been asked to do to much and had too much cobbled onto it, bending it all out of whack.

I have some fond memories of hacking around with it, about 10 years ago - although for some context, I was coming out of the wastelands of Visual Basic, pre-modern C++, and AWT/Swing era Java. I'm not sure there's anything easier for quick and dirty 2D game development than the PyGame SDL bindings were.

But I'd cringe at the thought of building anything serious with it today. It feels too loose and sloppy, like trying to build a castle made of sand, although I might have some Stockholm syndrome from years of more static, more strongly typed languages. But I have to do enough grepping around through the code base now to make sure tweaking something isn't going to break some snippet of JS code on the front-end now; I really don't need to be worried about that on the back-end too.

  from castles import CastleWithMoat
  c = CastleWithMoat('eyy')

Decorators should be higher on this list. I work with Python daily and I absolutely loathe people's custom decorators that obfuscate functionality away, like STL in C++, except no type system of course.

Also, preach on duck typing it's a python myth that is absurd. If it quacks like a duck means I had to figure out what it was.

This language is slowly destroying my soul, one painful unit test at a time.

    def make_money():
        blockchain_pyramid_scheme()

    @with_jazz_hands
    def make_money():
        blockchain_pyramid_scheme()

    def make_money(*args, **kwargs):
        with_jazz_hands(make_money_impl, *args, **kwargs)
    
    def make_money_impl():
        blockchain_pyramid_scheme()

I feel the same way. I'd rather use Typescript as a basic backend language but the nodejs community is less mature, especially if you, want an advanced SQL ORM.

There's a pull request for mypy protocols which moves further toward structural subtyping: https://github.com/python/mypy/pull/3132

Things I miss when I am programming in python:

- nothing similar to a build system that manages the external libraries

- no type checking, it means: no autocomplete in the IDE, runtime errors due to a value not expected

I don't mind to use python for small things, but for medium-big project I don't know how people can handle it.

  self.ivar = 1  # type: int
  
  self.ivar = [1]
  """ :type: list[int] """

  def fun(arg1, arg2):  # type: (int, str) -> str

  def fun(arg):
      """
      :param int or str arg:
      :rtype: str or None
      """

i have only used python for small (but professional) projects. i really did not enjoy working with the language. it just feels so sloppy and unprincipled. when i worked with it, it felt i constantly met strange quirks (the underscore business is a good example), much more than any other language i have learned.

i could probably think hard and remember the examples, as i realize i just said "feels" here, but i think that that's actually important. as i am writing code in f# or racket, i feel at ease. these languages are consistent and relatively simple in their experiences. how you feel when using a tool matters a lot in addition to technical talking points.

python feels like it ignores language design principles on purpose and not for a lot of good reason. but unfortunately, it's used everywhere. it's especially bad in scientific contexts where scientists don't know better and are lured in because of its decent selection of available packages.

I've noticed a new phenomena when it comes to posts on HN that criticize or complain about something I like. I find myself really drawn to it because I know that the comments will have people respectfully disagreeing and proposing alternatives that have a high chance of being useful to others. I used to downvote those kinds of posts on reddit back in the day, but this community makes disagreement progressive. You guys rock.

So, this shortens down to "I don't want people touching my private class members", "I want multi-line lambdas", and "I want types".

WRT private class members, I can understand why this might be frustrating for library writers. But it's just so damned useful to be able to reach into a library and get functionality the library's writer didn't think I'd need, that I'll personally never consider this to be bad.

Multi-line lambdas would certainly be nice, but most of it can be handled with a scope-level function. It adds, on average, one line of boilerplate. As for syntax, no need to use Ruby's syntax, just incorporate parenthesis (a well established continuation construct within Python):

    with(open("foo.txt"), lambda f: (
        print(f)
        print("I am a teapot")
    ))

The sinatra example doesn't really make the writer's argument about decorators to me; since the Flask example exposes a bit more functionality for only two lines of code - I now have a distinct app object, and can create more, or explicitly access attributes of the app itself. I can even add authentication to that function with just two lines:

    auth = flask.ext.httpauth.HTTPBasicAuth()

    @app.route("/")
    @auth.login_required
    def handle_route():
        return "I am a tea pot"

No, Python isn't Ruby; it doesn't support the same degree of metaprogramming. That's good, IMO. Metaprogramming is the source of exponentially more technical debt (and bugs) than is reasonable, frankly.

As for the lack of a type system, yeah, that is definitely Python's biggest weakness for large programs. A lot of it is resolved with the type hints in Python3, but a lot of it is just Python itself. Love it or hate it, that's how Python is, was, and will be.

As for the example error - there is a typo. Of course it's going to throw a traceback. The error message is even more explicit than I expected, frankly. It pointed out the missing function name, which would make the typo rather easy to find.

    (defauthedendpoint get-frobnaz [request user] 
        ...re<tab>quest)

    #include a.h
    #include b.h
    #include c.h
    MACRO(varname)

    class PricePredictionCalculator():
        def __init__(self, price_prediction_calculator_settings: 'PricePredictionCalculatorSettings'):
            self.x = price_prediction_calculator_settings.x
            self.y = price_prediction_calculator_settings.y

        def calculate_something(self) -> int:
            return self.x + self.y

    class PricePredictionCalculatorSettings():
        def __init__(self, x: int, y: int):
            self.x = x
            self.y = y

    class PricePredictor:
        class Settings:
           def __init__(self, x: int, y: int):
               self.x = x
               self.y = y
        
        def __init__(self, settings: Settings):
               self.x = settings.x
               ...

    def print_each_twice(xs):
        map(lambda x: print(x) # whoops, impossible

    def print_each_twice(xs):
        def print_twice(x):
            print(x)
            print(x)
        map(print_twice, xs)

    for x in xs:
       print(x)
       print(x)

    >>> def splatter(t):
    ...     def f(): print(t)
    ...     return f
    ... 
    >>> beep=splatter("beep")
    >>> boop=splatter("boop")
    >>> beep()
    beep
    >>> boop()
    boop

    def _with_body(f):
        print(f)
        print("I am a teapot")

    with(open("foo.txt"), _with_body)

    try:
        f = open("foo.txt")
        print(f)
        print("I am a teapot")

    finally:
        try: f.close()
        except: pass

Python type hinting is a nice newish feature. It needs to go further, though. PHP (gasp!!) for example is making the right strides when it comes to runtime checking.

That types criticism is a little bit old now. 3.6 will happily accept type annotations, and mypy can check them.

While I get what the decorator complaint was about, the example was just weird... My first follow up question would be: so how do I route 2 paths to that function?

    @route ('/')
    @route ('other')
    def ...

seems like a trivial answer. Now, how do I do that with that block-taking function? Maybe I can pass in an array of paths, maybe not...

just go c and javascript. or javascript and c. some prefer lua and c, or c and lua.

If you're going to complain about what Python lacks, at least verify that your argument is valid as of Python 3.6

I think the author has good points, but from where I sit they seem fairly subjective.

I've written Python for several years, and as a result the way I reason about problems have been heavily influenced by it.

I'm fluent in Ruby as well, but it takes mental effort for me to conform to its "flow", for lack of a better term. My time in Ruby has made me a better Python programmer, too - I understand more fully the idea of a DSL and how it should work. Ruby is great for writing DSLs and writing concise code that's guided by the language of the domain in which you're working.

I'm competent in Clojure, which if nothing else has given me a distinct distaste for impure functions - if a Python function takes an array, it should not modify that array in place unless it's very clear from the name that's it's going to do so, and a function should not both modify its input and return it.

At the end of the day, Python is still the language that I reach for whenever I'm writing pretty much any personal project. It's clean, easy to read, and the overall feel of the language guides me to write maintainable code.

I've been tinkering with Nim lately, and while I'm far from competent with it, it seems to address most or all of the issues brought up by the author. In particular, it has a very flexible, strong type system.

> I die a little inside every time I see NameError or TypeError in a server log. Even Javascript can catch undefined variables before runtime (with use strict), but not Python.

It's not like this is an accident, it's by design. Python pretty much waits until <<right now>> to bind things to names. It's part of the reason that it's "slow" and relatively challenging to make "fast." But OTOH you can do really interesting powerful stuff. "But I don't do that stuff"? Ok, maybe indeed Python's not for you.

As a simple fix for this problem, vim users can use syntastic, atom users have a/several python plugins to check syntax, I'm sure VSCode and emacs have analogous plugins. Yes, their power is limited to only some kinds of checks, so TypeErrors can slip through.

>It’s pretty well known that Guido van Rossum isn’t big on functional programming. Python tries pretty hard to make functional programming painful, to a degree that seems rather extreme, given how simple the fixes for the pain points would be.

>Python has lambdas, but they’re seriously hamstrung: They can only be a single expression. No statements. Furthermore, Python has a bunch of built-in language features that are totally obviated by adding a decent syntax for multi-statement lambdas.

This guy doesn't understand functional programming and why the lambda exists as a single expression.

Either way I agree it's better to have multiline lambdas but I disagree with how he related it to Guido making functional programming painful... If lambdas had multiline statements then the lambda would not be following the functional paradigm. In functional programming EVERY function is a single expression, including the main itself. In fact, in functional programming, your Entire program is just a single expression.

> Go’s interface types provide a nice solution for this.

Despite all of my various grievances with Go (on various levels), I strongly believe that interfaces were one of the things they did quite well.

I'm still making my mind up on whether Rust traits are an improvement in this department (though to be fair they are solving a harder problem because Rust has generics), but the fact that you can describe and use an interface without having to update every implementation is incredibly powerful.

I agree with the points made about python, but most of the C++ complaints were addressed in C++11. These days, you get extremely powerful type checking with sane compiler errors.

One cool example is the JSON for modern C++. You can write stuff like this:

json j = ... // read json

my_struct s = j;

and the compiler will check (recursively) that there is a complete my_struct deserializer. At runtime, it presumably avoids virtual method invocations as a bonus.

I get that some people want a GC, but python feels lower level than C++ to me these days.

TL;DR: Author complains because he wants to program Java-style within Python, and he can't. He doesn't mention real outstanding things that Python needs to solve like the threading/async features versus the Global Interpreter Lock (GIL). No, just trivial stuff.

Detailed reply:

- The author complains: "Most obviously, there’s no such thing as ‘private’. The convention is to prefix things with an underscore, as a way of saying to the user, “don’t touch.”"

Yes, underscore is just a convention. But the author ignores that a good Python IDE, like PyCharm, will automatically and explicitly warn you whenever you're accessing an 'underscored' member from outside.

- "Python has lambdas, but they’re seriously hamstrung: They can only be a single expression. No statements."

The author ignores that functions are pretty much first class in Python. Thus, if you want a multi-line 'lambda', just define a function and pass it around. Yes, they will not be anonymous, but functions can be defined at any inner block, as well, so if you do it that way, you will have no name conflict problems. Very easy to do.

- The with statement. "If you had multi-statement lambdas in the language, you could do something like:"

I guess the author has not used Python enough, since the example he shows can be done in Python. As I mentioned, you can pass a function as an argument pretty easily.

- "Decorators, on the other hand, are just a band-aid over the lack of multi-statement lambdas."

The author hasn't got a clue of what is the usefulness of decorators.

- Again, complaining about decorator use in Flask:

    from flask import Flask
    
    app = Flask(__name__)
    
    @app.route('/'):
    def index():
        return 'Hello, World!'

The author complains that he needs to define a name for index(), while this isn't needed in Ruby (under Sinatra).

Well, the author should use the Flask framework a little bit more before complaining, because the reason one needs to define a name for the index() function is to be able to... refer to this function later in many occasions!! For example, if i want to get the actual URL that is routed to index() i can use:

    url_for('index')

In this way, you can separate the routes from the view controllers, and thus, you can change the route paths without having to break many parts of the code.

- The rest of the article, the author complains that Python "does not have a Type System". However, the author conveniently ignores many things:

a. Python allows to call functions using keyword arguments, which strongly helps preventing bugs since the order of parameters is not going to affect the code and you clearly know what input parameters are you assigning values too.

b. You can always insert assert() statements to have a form of type checking. A good IDE, like PyCharm, will then warn you whenever you are calling a function with wrong types, and in runtime the type error will be catched as well.

c. If you want static typing at 100%, why are you using Python? Wrong choice.

d. There is a specific documentation style that, if you're using PyCharm or another decent IDE, will show you the documentation for every parameter as you are writing your function call. If, having this feature, the coder still makes mistakes calling a function with wrong parameter types, then the coder is too stupid to use Python.

e. Python is strongly typed, so a wrong input type to a function will cause a runtime error pretty soon, anyways. And, in my opinion, the bugs caused by type mismatches, in a strongly typed languaged, are trivial to solve. The bugs that worry me are the difficult to solve ones, the ones caused by wrong understanding of the problem, etc. Those bugs will never be prevented by a type system.

   FORTRAN programmers can write FORTRAN code in any language.