Hacker News new | past | comments | ask | show | jobs | submit login

Sure Python has many problems, but these aren't a great selection.

> The syntax for classical inheritance. Half of each Django app is super().__init__(args, *kwargs). At least you don't have to pass arguments to super anymore.

Yes, inheritance is hard to do well, but that's generally true. Much better to prefer composition (https://en.wikipedia.org/wiki/Composition_over_inheritance)

> Too many magic __double-underscore__ methods and properties that you have to just memorize.

Better to just start using http://attrs.org or dataclasses so you don't have to do all the manual work. Classes without boilerplate.

> Too many top-level built-in functions that (a) you have to just memorize, and (b) get really ugly. You end up with stuff like list(map(...)). I haven't used so many nested parentheses since my early days in PHP. Guido's explanation makes sense in theory, but is really annoying in practice.

I agree, there should be a pipeline operator |> like F# has. A similar proposal has been made for JS. https://github.com/tc39/proposal-pipeline-operator

> Too many other weirdo bits of magic syntax, like [list comprehensions].

List comprehensions are good, they just take 5 minutes of getting used to.

> Django specifically is so full of magic words, and its documentation is so convoluted, that I've basically given up on documentation altogether and just look at the Django source code now.

Pyramid has a much more principled design IMHO. https://trypyramid.com/

> Needing to put dict property names `{'in': 'quotes'}.

Or use `dict(foo=5)`. Python mappings can contain non-string keys, so `{5: 1.2, 6: 3.4}` maps ints to floats.

> You have to cast your data back to a list/tuple after using enumerate() and map().

Don't use map, use comprehensions.

> Different syntaxes for lists and tuples.

They are different objects, why would they have the same syntax?

> foo['bar'] returns a KeyError, so you have to do foo.get('bar')... or in some cases getattr(foo, 'bar', None), but not in others because getattr and .get are different things.

Python is a different language from Javascript.

> You can't just tack on flags to /regular_expressions/ig.

Yeah that's annoying.

> All the goofy string literals: f' ', u' ', r' ', etc.

That's a good thing, not a bad thing.

> Pipfile does not work that well.

Poetry works better. https://poetry.eustace.io




Sure Python has many problems, but these aren't a great selection.

Yes. I have my disagreements with Python, but those are not it. The article author is mostly complaining about ways Python differs from Javascript.

- Agree that the mechanism for talking about parent classes wasn't very good. Multiple inheritance usually adds complication without adding much necessary functionality. That's not just a Python problem. It's a leftover from viewing objects through an "A is-a B" lens, one of the dead ends of early AI.

- Python has too much gratuitous dynamism. Any thread can find and mess with any code and data in another thread. The implementation has to support that, which knocks out many valuable optimizations. The language model, and the original implementation, use "everything is a dict", which implies "slow".

- One consequence of the above is Python's terrible one thread at a time thread system, with the "global interpreter lock". The "multiprocessing" hack to get around that is ugly and uses too much memory, since each subprocess has its very own Python system instance. To some extent, the "async" add on is yet another hack to get around the limits of threading.

- Another consequence is a tendency to call C code where Python performance is terrible. The C code has to carefully obey the rules of the Python system. Mostly it does.

- Optional typing is a marginal idea, but unchecked marginal typing is just weird. Language design seems to be converging on implicit static typing - result variables are automatically typed whenever possible. Go, Rust, and now C++ (with "auto") took that route.

- And, of course, the botched Python 2 to 3 transition set Python back for a decade.

On the other hand, Python exceptions work out well. A reasonably sane exception hierarchy helps. Although the one for 2.x was better than the one for 3.x; the 2.x one made a clear distinction between external problems ("Environment errors") and internal problems.

The "with" clause system plays well with exceptions, and nested exception failures unwind correctly. It's far better than Go's "defer". C++ and Rust try to handle this sort of thing with RAII, which never handles trouble in a destructor well.


Regarding performance, I'm hoping alternate interpreters like pypy start thriving. Theres no reason python needs to be as slow as CPython.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: