Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

All the things I hate about Python

medium.com

Post reply on HN
Print view View original

41–50 of 87 posts

Re: All the things I hate about Python

#41

Post by ris »

pmoriarty wrote: post #23

My main beef with python is its packaging management. It's a clusterfuck of half-baked, non-standard, spaghetti code approaches. The Zen of Python says "There should be one-- and preferably only one --obvious way to do it." Python package management makes that in to a joke.

That's because package management is an extremely hard thing to do if you're only trying to control one part of a system and have it work magically in different environments. And so strangely enough programming language people writing their own toy-town package managers get it wrong again and again and again.

Re: All the things I hate about Python

#42

Post by btashton »

bbrunner wrote: post #4

To me, the core points seem like table stakes knowledge that one should have before jumping into development with ANY language, not just Python. Every language is a tool that is good at some things and not good at others. Cue the standard if all you have is a hammer, every problem looks like a nail. A few core things: The GIL problem is frustrating. I generally just try to avoid writing threaded code and instead exec…

The "GIL" problem is so over exaggerated for most problems. A significant amount of threaded code is IO bound and in most of those cases the GIL gets out of the way. Checkout the cpython code around the calls to things like select, poll, epoll. If you are needing to do high performance number crunching across multiple cores, then yeah it's a little more work, but it's gotten easier and easier to write some C libraries for that or leverage something like numpy.

Re: All the things I hate about Python

#43

Post by gkya »

My take:

- The indentation based syntax: it can easily trip you up when moving big blocks of code around. You want to put this if else block somehwere else, hope you get a syntax error, because you can get sth. that seemingly works but does not do what it's supposed to do. Also sometimes finding where you are can be difficult.

- Dogmaticism: a big thing in the community. They'll wait 20+ years until they add string interpolation, a feature common in many similar languages. They'll wait 20+ years until they start to realise having expression equivalents of statements is useful.

- Breaking syntax: new syntax is added in what seems to be minor releases, so you either avoid new syntax to be compatible w/ all the 3.* interpreters, or you need to expressly avoid certain interpreter versions. And there's no equivalent of Perl's "use v5.something;" so you need to write code juggling multiple supported versions.

Still I think it is a nice language to have in your toolbox for the vastness of the stdlib and the available 3rd party packages.

Re: All the things I hate about Python

#44

Post by dnautics »

> there is no question that type safety matters for building and maintaining large-scale distributed systems in the enterprise.

Some of the largest-scale enterprise distributed systems, as in, at the telecoms level, are written in erlang, which is dynamically typed, and highly reliable.

Re: All the things I hate about Python

#45

Post by bbrunner »

btashton wrote: post #42
bbrunner wrote: post #4

To me, the core points seem like table stakes knowledge that one should have before jumping into development with ANY language, not just Python. Every language is a tool that is good at some things and not good at others. Cue the standard if all you have is a hammer, every problem looks like a nail. A few core things: The GIL problem is frustrating. I generally just try to avoid writing threaded code and instead exec…

The "GIL" problem is so over exaggerated for most problems. A significant amount of threaded code is IO bound and in most of those cases the GIL gets out of the way. Checkout the cpython code around the calls to things like select, poll, epoll. If you are needing to do high performance number crunching across multiple cores, then yeah it's a little more work, but it's gotten easier and easier to write some C librarie…

I would agree it's over-exaggerated. In my day to day work, the GIL has rarely, if ever, been the performance bottleneck. It usually traces back to something outside of Python (e.g. a slow DB query or a slow API call) or to something that has been implemented in python in an inefficient way (e.g. writing something O(n^2) when if you read your algos 101 book or even just searched stack overflow you could find an O(n) solution).

I also think that the whole "drop down to C argument" is sometimes viewed as a cop-out when criticizing python, but I personally believe that being proficient at high-level and low-level languages, knowing their strengths and weaknesses, and transitioning between them when it makes sense is stronger than just using purely high OR low-level. It's sort of like having multiple gears on a car: you need all of them, and they are all useful and most opportune in different scenarios.

Re: All the things I hate about Python

#46

Post by lvh »

tln wrote: post #29
lvh wrote: post #11

This starts off with a misunderstanding of what "strongly typed" means. Python is strongly, but dynamically typed. Static typing means you know the type of something at compile time. Dynamic typing means you don't. The upside to dynamic typing is that the compiler doesn't have to prove much about your program; the downside is that it can't really prove much of interest either. Strong vs weak typing is about how much…

You're correct but this barely changes the authors points: "It’s virtually impossible to statically analyze" and "In Python a good amount of errors are discovered at runtime"

The rest of the points are silly rehashes of arguments as old as Emacs v vim, but sure, let's go there too. We've done empirical research to see if this matters. Charitably, the results are "inconclusive"[0].

> The first glaring issue is that I have no guarantee that is_valid() returns a bool type.

You can name functions ridiculous, unhelpful and misleading things in any language. The very fact that you know to expect a bool undermines the point: clearly, despite not having static types, a human managed to make a pretty reasonable assumption about what a piece of code was about to do. Just because the compiler can check that is_valid returns a string doesn't mean that hat's magically a useful thing to do.

> The fact that I cannot, in the absence of perfect test coverage, verify the syntactical correctness of someone’s code is a big red flag.

Syntax errors are caught by the compiler. Semantic errors aren't caught by the best type systems. At best, type systems are a way to encode a bit of the semantics so that the compiler can prove things about it.

> To improve static type checking in Python, developers made libraries like jedi, pytype, mypy, and toasted-marshmallow, but they are often not used in most projects because they do not belong to the standard toolchain

I can not imagine the author actually used jedi and believes this. That's... not how jedi works. I also don't know what to do with the argument of "oh, you have an optional static type system but people don't use it because it's annoying, this is why we should use a mandatory static type system" other than shrug.

I like types! I think there are great arguments for types. I like the idea of being able to have a type system prove that certain bugs can't happen. This adds nothing but FUD and no new insights.

[0]: https://danluu.com/empirical-pl/

Re: All the things I hate about Python

#48

Post by mlthoughts2018 »

tln wrote: post #29
lvh wrote: post #11

This starts off with a misunderstanding of what "strongly typed" means. Python is strongly, but dynamically typed. Static typing means you know the type of something at compile time. Dynamic typing means you don't. The upside to dynamic typing is that the compiler doesn't have to prove much about your program; the downside is that it can't really prove much of interest either. Strong vs weak typing is about how much…

You're correct but this barely changes the authors points: "It’s virtually impossible to statically analyze" and "In Python a good amount of errors are discovered at runtime"

> “In Python a good amount of errors are discovered at runtime"

In my experience this is roughly equally true with statically typed languages as it is with Python. The types of errors the compiler helps find before running tests are just not important. They are not types of errors that matter much. And if compiler errors are cryptic enough, it can be a huge huge pain that you can’t just run the code on a toy input to see what’s going on. The whole pitch about how static typing and compilation will save you time by forcing more correctness prior to testing is just a hogwash myth in practice. It happens occasionally, but not nearly enough to justify all the stuff advocating it, and the benefits of being able to debug according to desired behavior and just not care about strict safety in edge cases you can guarantee you won’t hit are really tangible. You cannot easily dismiss these benefits.

Re: All the things I hate about Python

#49

Post by lvh »

hedora wrote: post #38
lvh wrote: post #11

This starts off with a misunderstanding of what "strongly typed" means. Python is strongly, but dynamically typed. Static typing means you know the type of something at compile time. Dynamic typing means you don't. The upside to dynamic typing is that the compiler doesn't have to prove much about your program; the downside is that it can't really prove much of interest either. Strong vs weak typing is about how much…

Python objects are duck typed, and c/c++ structs are strongly typed. Duck typing is closer to weak typing than strong typing. Tagged unions are dangerous in C/C++, but python’s object type is strictly weaker than a union. In fact, C and C++ are both strongly typed, but they are both memory unsafe. However, C++ provides enough static typing to make it easy to write memory safe (but single threaded) programs. Also, too…

> In fact, C and C++ are both strongly typed, but they are both memory unsafe.

You are refuting my point but provide no evidence and implicitly redefine several terms in a way contrary to common usage.

Is there a definition you can pen down? Because C sure isn't strongly typed in the Liskov, Jackson or modern usage senses of the term.

> Also, tools like valgrind get you 99% of the benefit of memory safety, which is good enough for debugging. C++ lets you override the allocator, and build in inexpensive (fast enough for production) checks for most use after frees, memory consumption profilers / leak detection/ etc.

Would you say that de facto C/C++ has a memory safety problem? If it does, why?

(Also, not germane to my point.)

> I’d argue that python is memory unsafe in practice, since we get segfaults from third party dependencies in python about as often as we see them in c/c++.

Do you have extraordinary evidence to go with this extraordinary claim, or are you just talking about your own anecdata?

(Also, not germane to my point.)

> If you use std::string, adding a in integer does something well-defined (rtfm).

My argument was not that it is poorly defined. Weak typing doesn't mean UB.

Re: All the things I hate about Python

#50

Post by dnautics »

lvh wrote: post #16

The author complains about CPU-bound performance and then mentions PyPy but claims it's ecosystem is barren enough that the point stands. This claim is presented without evidence. In practice it doesn't really show up: the cases where code is actually CPython-specific usually imply all the work is being done in highly optimized C bits. Hence, those programs, despite being run on CPython, aren't CPU-bound. Finally: wh…

It will bite you when you don't expect it. When i work, we had a dev write a IO trace playback engine in Python to do some IO performance testing. We then deployed it on various platforms and got very strange results - eventually I noticed when TOPing the node, the CPU was pegged at 100%, so this wasted about 2 months time of about ~4 developers
Post reply on HN