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

Drawbacks of Python

quora.com

Post reply on HN
Print view View original

91–100 of 117 posts

Re: Drawbacks of Python

#91

Post by m463 »

roland35 wrote: post #6

I agree with the response that there are a few "gotchas" with python, like with any language! I have gotten caught up with a few type problems when dealing with sending raw binary data over serial and things like that - but luckily python has great unit testing frameworks to help with this. My main beef with python is that it is harder to deploy projects to other people, without them setting up a virtual environment…

> My main beef with python is that it is harder to deploy projects to other people

On the other hand, I think python has more "batteries included" than other scripting languages and for many projects you can usually figure out how to eliminate dependencies.

Re: Drawbacks of Python

#92

Post by wolf550e »

_never_k wrote: post #84
wolf550e wrote: post #47

Earlier quoted context omitted.

What is wrong with virtualenv, pip and pip freeze?

They work, but there's much more friction and many more gotchas than node. The requirements file for example, doesn't distinguish between direct and ancestor dependencies, it has to be explicitly passed to pip, you need to have created and activated your virtual environment correctly, many python libs have fragile, c based builds. Node and nvm just work.

I use separate requirements-to-freeze.txt and requirements.txt, so that I maintain only list of direct dependencies (no transitive dependencies) and only pin versions when I know the code won't work with the latest version, but pip freeze creates a file like package lock with all the dependencies versioned so I can recreate the exact environment again without needing to store a docker image of it or something like that. See https://www.kennethreitz.org/essays/a-better-pip-workflow

Needing to name the requirements file and needing to activate venv are not pain points I feel.

Wrapping native libraries and not invoking a C compiler at package install time means some trade-offs. https://cffi.readthedocs.io/en/latest/cdef.html

Re: Drawbacks of Python

#93

Post by fuzz4lyfe »

smt88 wrote: post #78
psv1 wrote: post #63

Earlier quoted context omitted.

> But in a language with brackets, the compiler can at least determine scope even when things are poorly-indented. Yes, but can it determine scope if things are poorly-bracketed? Because that's the fair comparison.

Poor bracketing almost always causes syntax or compiler errors. As long as you have a language that's block-scoped (which is true of modern JavaScript and most other popular languages), you'll get an error if you make a bracketing mistake. That's not true of indent mistakes. Semantic whitespace is lossy -- there's data contained in those brackets that some people think is low-value that it's expendable for the sake o…

With Python, generally speaking, if you are more than a few indentations deep you are doing something wrong.

Flat is better than nested

Re: Drawbacks of Python

#94

Post by siddboots »

j88439h84 wrote: post #59
kyllo wrote: post #41

These are minor annoyances to me. The major annoyance I have with Python is that most Python code makes such heavy use of classes, even when it only needs lists, tuples, and dicts. Why do I really need a class, when: - Instance fields can be added and removed at runtime - Private fields and methods are not actually private ("we're all consenting adults here") - No pattern matching on types and `if isinstance(foo, Bar…

My solution to this is http://attrs.org or dataclasses. They make a huge difference in readability and type safety.

I feel like PEP557 missed an opportunity when it named data classes. The syntax is such an improvement that there is very little reason not to use them over ordinary classes for most purposes.

Re: Drawbacks of Python

#95

Post by j88439h84 »

siddboots wrote: post #94
j88439h84 wrote: post #59

Earlier quoted context omitted.

My solution to this is http://attrs.org or dataclasses. They make a huge difference in readability and type safety.

I feel like PEP557 missed an opportunity when it named data classes. The syntax is such an improvement that there is very little reason not to use them over ordinary classes for most purposes.

Python probably should've just used attrs directly, like it does with setuptools, rather than making a whole new package.

Re: Drawbacks of Python

#96

Post by dreamcompiler »

fuzz4lyfe wrote: post #93
smt88 wrote: post #78

Earlier quoted context omitted.

Poor bracketing almost always causes syntax or compiler errors. As long as you have a language that's block-scoped (which is true of modern JavaScript and most other popular languages), you'll get an error if you make a bracketing mistake. That's not true of indent mistakes. Semantic whitespace is lossy -- there's data contained in those brackets that some people think is low-value that it's expendable for the sake o…

With Python, generally speaking, if you are more than a few indentations deep you are doing something wrong. Flat is better than nested

That's a good heuristic for a programmer but it's no help to a compiler.

Re: Drawbacks of Python

#97

Post by weberc2 »

coldtea wrote: post #88
weberc2 wrote: post #80

Earlier quoted context omitted.

Mostly I was just amusing myself, but here's what I meant: Usually when people refer to generics they're referring to a static type system that allows for expressing generic algorithms. (Untyped) Python inherently has no static type system, so necessarily can't support generics by that definition. The other definition of generics that _is_ satisfiable by (untyped) Python--the definition you presumably had in mind--is…

> The other definition of generics that _is_ satisfiable by (untyped) Python--the definition you presumably had in mind--is equally satisfiable by Go via its `interface{}` type. So regardless of which definition you adhere to, "Go lacks generics" is no more valid a criticism for Go than for Python. Well, that's not exactly the case. Interface{} might have the same tradeoffs with Python's dynamic types (plus more cere…

For whatever it's worth, I'm a proponent of generics in Go.

"Static type checking" does not mean "every conceivable program is safely expressable by the type system". Haskell doesn't make this promise and neither does Go.

Anyway, Go is as slow and as unsafe as Python in the ~1-5% of code that is generic. It's still a pretty good deal even if you were mistakenly expecting 0%.

Re: Drawbacks of Python

#98

Post by dragonsh »

ummonk wrote: post #83
dragonsh wrote: post #40

Earlier quoted context omitted.

May be different people have different experience with Python. After c and Perl had been using it for over 15 years and among the languages I have seen Python code is one of the most readable one so far, again subjective as I like sparse and empty spaces in architecture with minimalist design. For me whitespace is same in Python code. Whitespaces forces programmer to make code readable. Obviously today with tools lik…

If C and Perl are your comparison points, obviously python will seem better...

I have tried golang, Java, C++, js and recently rust. I can still confidently say python code is the most readable of them all.

Indeed so much so that python style is adopted by swift language and it does look cleaner than others.

Obviously I like concise perl, Haskell code too they have a beauty of their own, but that does not make python whitespace is bad.

It's just people who feel it's a burden to explicitly follow whitespace hate python indentation based on my observations. Since suddenly instead of braces or statement end one need to use a visual sense of beauty along with logic.

Re: Drawbacks of Python

#99

Post by coldtea »

weberc2 wrote: post #97
coldtea wrote: post #88

Earlier quoted context omitted.

> The other definition of generics that _is_ satisfiable by (untyped) Python--the definition you presumably had in mind--is equally satisfiable by Go via its `interface{}` type. So regardless of which definition you adhere to, "Go lacks generics" is no more valid a criticism for Go than for Python. Well, that's not exactly the case. Interface{} might have the same tradeoffs with Python's dynamic types (plus more cere…

For whatever it's worth, I'm a proponent of generics in Go. "Static type checking" does not mean "every conceivable program is safely expressable by the type system". Haskell doesn't make this promise and neither does Go. Anyway, Go is as slow and as unsafe as Python in the ~1-5% of code that is generic. It's still a pretty good deal even if you were mistakenly expecting 0%.

>"Static type checking" does not mean "every conceivable program is safely expressable by the type system". Haskell doesn't make this promise and neither does Go.

No, and I didn't make this claim or demand this either.

But it should mean: "any algorithm variation where just the type changes should be expressable by the type system without me having to rewrite e.g. a sort list for int64 lists, int32 lists, float lists, etc, it's 2019 already".

Re: Drawbacks of Python

#100

Post by weberc2 »

coldtea wrote: post #99
weberc2 wrote: post #97

Earlier quoted context omitted.

For whatever it's worth, I'm a proponent of generics in Go. "Static type checking" does not mean "every conceivable program is safely expressable by the type system". Haskell doesn't make this promise and neither does Go. Anyway, Go is as slow and as unsafe as Python in the ~1-5% of code that is generic. It's still a pretty good deal even if you were mistakenly expecting 0%.

> "Static type checking" does not mean "every conceivable program is safely expressable by the type system". Haskell doesn't make this promise and neither does Go. No, and I didn't make this claim or demand this either. But it should mean: "any algorithm variation where just the type changes should be expressable by the type system without me having to rewrite e.g. a sort list for int64 lists, int32 lists, float list…

That's not what static typing means. If you want it to mean that, go right ahead. I agree that Go should support that feature, but it has no bearing on the definition of static typing nor on Go's position relative to Python with respect to speed or safety.
Post reply on HN