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

51–60 of 87 posts

Re: All the things I hate about Python

#51

Post by mistrial9 »

mattlondon wrote: post #32

Totally agree with this person's assessment on types. I took over a smallish half-completed web application written in python a couple of years ago. Nothing major - simple business-y analytics/data viewing app with some fancy charts and tables etc - perhaps a couple of thousand lines of code interfacing to backend database unique to our business. It had some tests, but nowhere near 100% coverage. I needed to finish i…

.. sorry to hear about the frustration, but almost all of these are ordinary problems with application development. Maybe the original developer made a mess, but that is ordinary too.. if you have a short-list of hmm .. ways to solve typical problems, in a workflow you like, in a language and functions you like.. then you can bring those to the new efforts.. production technical engineering groups will sometimes just bid to remake the whole thing, using their own ways, for exactly these reasons.. but individual developers rarely have that option.. chin up!

Re: All the things I hate about Python

#52

Post by lvh »

dnautics wrote: post #50
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

What was the root cause?

Re: All the things I hate about Python

#53

Post by krylon »

vpribish wrote: post #34

lazy article. dude wishes python was java. also, it fails the snake-test: python is named for Monty Python's Flying Circus, not the snake. anyone who uses the snake is not clueful.

Well, to be fair, Python's logo resembles a snake more closely than John Cleese.

Re: All the things I hate about Python

#54

Post by didymospl »

One thing not mentioned by anyone yet, that kinda annoys me is the fact that Python libraries use different naming conventions. Even though PEP 8 has existed for 17 years now, there are many examples where I see lower_case_with_underscores mixed with lowercase and camelCase in the function names.

I know that many libraries and Python standard lib itself predate this PEP but I don't understand why Python 3, which broke backward compatibility anyways, did not fix that at least in the standard library.

Re: All the things I hate about Python

#55

Post by hedora »

lvh wrote: post #49
hedora wrote: post #38

Earlier quoted context omitted.

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 g…

https://en.m.wikipedia.org/wiki/Strong_and_weak_typing

Strong and weak typing are poorly defined terms.

I’d argue that type errors (not including memory safety errors) should not occur at runtime in a strongly typed language, or at least that a “stronger typed” language would admit fewer classes of those errors in practice.

I’d argue that de facto, modern C/C++ does not have a memory safety issue. Operating systems like OpenBSD and many other secure, hardened network daemons provide existence proofs that are not available for languages like python.

In contrast, I’d argue that python has severe type safety issues.

I’m not sure why evidence that “strongly typed” python in practice suffers from all sorts of typing errors that “weakly typed” C/C++ avoids is not relevant to your point.

I also don’t understand why you dislike the string examples, which explains the (strongly typed) semantics of the operators you mentioned in your comment.

By “strongly typed” do you mean that all operators return the (single type) of their parameters?

I don’t know of any languages that enforce such a thing.

Perhaps you mean “strongly typed languages only include operators that are to my taste”? That’s surely not a useful definition.

Re: All the things I hate about Python

#56

Post by marcosdumay »

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…

> I dunno, a wchar_t or something

Most likely a char or a * wchar. Yeah, random pointers.

Re: All the things I hate about Python

#57

Post by lvh »

hedora wrote: post #55
lvh wrote: post #49

Earlier quoted context omitted.

> 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 g…

https://en.m.wikipedia.org/wiki/Strong_and_weak_typing Strong and weak typing are poorly defined terms. I’d argue that type errors (not including memory safety errors) should not occur at runtime in a strongly typed language, or at least that a “stronger typed” language would admit fewer classes of those errors in practice. I’d argue that de facto, modern C/C++ does not have a memory safety issue. Operating systems l…

OK, Wikipedia it is. Wikipedia lists C’s typing discipline as “Static, weak, manifest, nominal“, and Python’s as “ Duck, dynamic, strong since version 3.5: Gradual[4]”.

> I’m not sure why evidence that “strongly typed” python in practice suffers from all sorts of typing errors that “weakly typed” C/C++ avoids is not relevant to your point. > I also don’t understand why you dislike the string examples, which explains the (strongly typed) semantics of the operators you mentioned in your comment.

I have no idea what evidence you’re referring to, or what examples I supposedly dislike.

Re: All the things I hate about Python

#58

Post by hedora »

lvh wrote: post #57
hedora wrote: post #55

Earlier quoted context omitted.

https://en.m.wikipedia.org/wiki/Strong_and_weak_typing Strong and weak typing are poorly defined terms. I’d argue that type errors (not including memory safety errors) should not occur at runtime in a strongly typed language, or at least that a “stronger typed” language would admit fewer classes of those errors in practice. I’d argue that de facto, modern C/C++ does not have a memory safety issue. Operating systems l…

OK, Wikipedia it is. Wikipedia lists C’s typing discipline as “Static, weak, manifest, nominal“, and Python’s as “ Duck, dynamic, strong since version 3.5: Gradual[4]”. > I’m not sure why evidence that “strongly typed” python in practice suffers from all sorts of typing errors that “weakly typed” C/C++ avoids is not relevant to your point. > I also don’t understand why you dislike the string examples, which explains…

There are examples of string operators two comments up. Those are the examples I’m referring to.

To any readers that made it this far, and are hoping for something precise, here is a minimally useful definition of “strongly typed”. I’ve never heard of a broader definition of “strongly typed”:

The language’s type system must be embedable in a lattice, and at runtime, it is guaranteed that functions aren’t passing the top element around and then using it without an explicit downcast.

C/C++ meet this definition, since you need to cast void* before dereferncing it, and void isn’t a valid type for a variable. Also, the only union types are defined at compile time.

Python does not meet this definition because functions can have multiple return types due to control flow, which means you can create call sites that return things like lub(integer, string), and then compose them until you have something of type “top”, and there’s no way to statically guard against usages of such a type.

Re: All the things I hate about Python

#59

Post by arwhatever »

It aggravates me the abundance of scientific/mathematical packages that exist for Python, because of all of the language shortcomings that this article details.

No doubt your typical Math Ph.D. type doesn't want a language with a step learning curve to implement their expertise, so what to do?

Perhaps everyone could at least switch to Go,a language which (as I understand) provides for some basic static type safety, good performance, etc.

I spent six months working in Python a while back and I'll be intent to avoid it from now on.

Re: All the things I hate about Python

#60

Post by DonaldPShimoda »

hedora wrote: post #55
lvh wrote: post #49

Earlier quoted context omitted.

> 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 g…

https://en.m.wikipedia.org/wiki/Strong_and_weak_typing Strong and weak typing are poorly defined terms. I’d argue that type errors (not including memory safety errors) should not occur at runtime in a strongly typed language, or at least that a “stronger typed” language would admit fewer classes of those errors in practice. I’d argue that de facto, modern C/C++ does not have a memory safety issue. Operating systems l…

> Strong and weak typing are poorly defined terms.

I work as a research assistant in a PL research lab and have talked with many PL researchers who have been in the field for a long time. They all use the terminology consistently, and it all lines up with what lvh has been saying.

I agree that the terms are poorly defined, because there's not a single definition which can be used as a criterion for evaluation. But that Python is more strongly typed than C seems to be a common sentiment, at least among people that I explicitly asked about it. Much C code practically relies on the weakness of the type system to function, whereas Python cannot be deceived in the same way.

> I’m not sure why evidence that “strongly typed” python in practice suffers from all sorts of typing errors that “weakly typed” C/C++ avoids is not relevant to your point.

Typing errors are evidence of a strong typing system...

> I also don’t understand why you dislike the string examples

Your string example relied on the weak typing of C to work. The conversions are implicit, aren't they? This is a hallmark of a weakly-typed language.

Post reply on HN