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

61–70 of 117 posts

Re: Drawbacks of Python

#61

Post by zeveb »

Back when I wrote a lot of Python, something I disliked was how one could easily reload a module, but existing instances of classes wouldn't get updated. You could implement the machinery to do so for your own stuff, but of course that could be arbitrarily flaky.

Performance was definitely an issue, but for the sort of programming we were doing it normally wasn't a big issue.

Duck typing could definitely be an issue — one had little confidence that code would run as desired.

Overall, I really liked Python, but these days I'd sooner use Go or Lisp.

Re: Drawbacks of Python

#62

Post by dragonwriter »

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…

> Why do I really need a class,

Among other cases, you need a class where natural, convenient, consumer-friendly use of a data structure should leverage features like operators and standard protocols that rely on the existence of particular methods (often special methods.)

> If I need a more performant data structure, I'm not writing it in Python in the first place.

While Python is linearly slow, that’s no excuse to use data structures with poor big-O performance (small n may be, but that's no more or less true of Python than of a more performant language.)

> I've seen some very experienced Pythonistas recommend using namedtuple instead of classes for most use cases

Namedtuple is just a function that returns a fresh class; you can't use “namedtuple instead of classes”, as it's a convenience mechanism for creating a class with certain commonly-useful features.

> Clojure programmers seem perfectly happy with just lists and maps

And vectors. And sets. And records. And a bunch of other common data structures.

But, yes, the use of multimethods for type-based dispatch that clojure uses replaces classes. But Python doesn't have multimethods built-in and the core language and stdlib don't use them (they are available in a non-standard library).

Re: Drawbacks of Python

#63

Post by psv1 »

dreamcompiler wrote: post #57
psv1 wrote: post #55

Earlier quoted context omitted.

> very difficult for python to realize when a line is indented incorrectly. It just assumes that if a line is indented a certain way, it was intentional. How is this different from some language not realising that a statement should be inside of the curly brackets instead of outside?

No compiler can read your mind. But in a language with brackets, the compiler can at least determine scope even when things are poorly-indented. In Python it can't in a lot of cases. It's like static type checking: The class of errors the compiler can catch is larger when it's present. Likewise, with visible scoping characters, the class of errors the compiler can catch is larger than when they are invisible.

> 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.

Re: Drawbacks of Python

#64

Post by turtlebits »

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…

This project- https://github.com/unixtreme/D3Edit, has an interesting approach of bundling the virtual environment for linux/Mac/Windows and activating the corresponding when you launch the script.

Re: Drawbacks of Python

#65

Post by sebastos »

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…

Isn't the reason to use classes the dispatch aspect of it? If I take in a duck-typed object and call obj.foo(), then I get an appropriate class-specific version of foo().

Like you said, isinstance() is an anti-pattern - I don't want to define a function that behaves differently based on explicit testing of input type, because that wrecks the duck typing. Right?

Re: Drawbacks of Python

#66

Post by weberc2 »

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…

I wish it had a better async story. We've had production outages that were difficult to debug because some third party library made a sync call deep in the call stack and starved the event loop. APM showed performance degradation in unrelated endpoints. Eventually health checks began failing and containers were killed, putting the load on other containers which inevitably fell over and so on. We've seen similar issues with CPU starvation due to CPU-intensive tasks as well, though they were more straightforward to debug. We also continue to see runtime type errors because someone forgot to await an async function: `rsp = aiohttp.get() # oops, rsp is the promise, not the response!`.

As far as deployment goes, we've had good luck with pex files (executable zip files containing everything but the interpreter). https://github.com/pantsbuild/pex. Your deployment target still needs the right version of the Python interpreter and .so files that your dependencies might link against.

Personally, I've found that Go solves most/all Python issues without introducing too many of its own--and anyone writing Python (sans mypy) doesn't get to chastise Go for lacking generics! :)

Re: Drawbacks of Python

#67

Post by kstrauser »

t0mbstone wrote: post #53
smt88 wrote: post #32

Earlier quoted context omitted.

I agree with a lot of these things, but actually disagree that Python is good at exemplifying some of them. For example, semantic whitespace is arguably implicit, hard to read, invites density (compared to an extra line for braces), and (again arguably) is ugly. Yes, some of these things are subjective, but it's hard for me to confidently recommend Python to someone with these values.

I can't even tell you how many hours I've lost due to someone committing an incorrectly indented line in python. This often happens during merge conflicts, for example. Because logic in python is interpreted via indentation, it's very difficult for python to realize when a line is indented incorrectly. It just assumes that if a line is indented a certain way, it was intentional. In programming languages like Ruby or…

I've lost approximately zero hours to indenting or formatting issues in Python or other languages. Unit tests usually do a good job of catching unexpected behavior quickly.

Re: Drawbacks of Python

#68

Post by slykar »

t0mbstone wrote: post #53
smt88 wrote: post #32

Earlier quoted context omitted.

I agree with a lot of these things, but actually disagree that Python is good at exemplifying some of them. For example, semantic whitespace is arguably implicit, hard to read, invites density (compared to an extra line for braces), and (again arguably) is ugly. Yes, some of these things are subjective, but it's hard for me to confidently recommend Python to someone with these values.

I can't even tell you how many hours I've lost due to someone committing an incorrectly indented line in python. This often happens during merge conflicts, for example. Because logic in python is interpreted via indentation, it's very difficult for python to realize when a line is indented incorrectly. It just assumes that if a line is indented a certain way, it was intentional. In programming languages like Ruby or…

Using python for about 5 years or more now and never had an issue with the indentation.

If you are using notepad as an editor then maybe this could be an issue?

Every other editor I've used validates the syntax and quickly catches misaligned statements. Auto formatting works too.

Re: Drawbacks of Python

#69

Post by kyllo »

dragonwriter wrote: post #62
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…

> Why do I really need a class, Among other cases, you need a class where natural, convenient, consumer-friendly use of a data structure should leverage features like operators and standard protocols that rely on the existence of particular methods (often special methods.) > If I need a more performant data structure, I'm not writing it in Python in the first place. While Python is linearly slow, that’s no excuse to…

> you need a class where natural, convenient, consumer-friendly use of a data structure should leverage features like operators and standard protocols that rely on the existence of particular methods (often special methods.)

I understand and I can't disagree, this just seems much, much narrower in scope than what classes are used for in typical Python code I see every day. Which is perhaps due to influence from other languages like Java/C++ etc.

Re: Drawbacks of Python

#70

Post by kstrauser »

metalliqaz wrote: post #10
bobbylarrybobby wrote: post #5

Earlier quoted context omitted.

Python also has a bytes type that’s the same as python 2 strings. Why would you want your strings to not be Unicode?

Obviously nobody cares what I think, so perhaps you would prefer the words of Armin Ronacher, the creator of Flask. http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/

I have a lot of respect for Armin as a smart engineer and all around good guy, but I think he was and is wrong about this one.
Post reply on HN