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

81–90 of 117 posts

Re: Drawbacks of Python

#81

Post by prewett »

metalliqaz wrote: post #28
beagle3 wrote: post #17

Earlier quoted context omitted.

The thing about "just works" in 2.7 is that it does ... until it doesn't, and when it doesn't, it's often way harder to resolve. If you're only using the original ASCII (ordinals 0-127), all is well, and the py3 distinction between strings and bytes seems to get in the way. But as soon as you have a single character in your input or data which is not ASCII, a lot of things stop working and it isn't even clear why, or…

Maybe you're right. Maybe there are applications where this really matters. All I can say is that I have never once had that problem since I started using Python (circa version 2.4). It has always been fine. For example, when dealing with .csv files created with MS Excel, you get strange characters because Excel uses CP1252 encoding, not ASCII. They never tripped up my app in python 2.7. It happily passed them along.…

You're reading non-Unicode into strings that expect Unicode, and since there's no way to auto-detect CP1252, you get bad results. If you want to stay in CP1252 you should clearly use bytestrings. You could convert to Unicode, I expect that:

text = file.read().decode('cp1252')

would work (haven't tried it, though).

I frequently work with CJK text, and Python 2 was a real pain. You had to do things one way to output to a terminal, but a different way to output to a pipe, and all your code had to remember to encode('utf8') every time you printed a string (unless you were using pipes, if I recall correctly). The situation is much better with Python 3, especially if you keep your files in UTF-8. Unfortunately, I think Windows is still stuck in their own world, so it might be harder to get UTF-8 by default. In Unix pretty much everything writes UTF-8 files by default, so everything has pretty much just worked for me (macOS/Linux).

Re: Drawbacks of Python

#82

Post by _never_k »

saagarjha wrote: post #48
dragonsh wrote: post #22

I like Python because of zen of python [1]. This fits my brain and had been very helpful. Indeed in 2004 I chose Django instead of Ruby On Rails just because explicit is better than implicit. Overall Python is productive and good. Yes it has some warts and corner case, but than its evident. Among programming language python has a humble community and very approachable. Also most programmer in Python will not hesitate…

Having a bit of experience with Python, I’d say it doesn’t exemplify > Special cases aren't special enough to break the rules. > There should be one-- and preferably only one --obvious way to do it. Python is complicated enough that the language and standard library often have multiple ways of doing the same thing. And there are still a number of “special cases” in the language, or at least non-intuitive results. Cer…

This is the way I feel too. Python is both redundant and inconsistent at a basic level. The APIs for `map`, `filter` and `reduce`, the inversion between `split` and `join`, `sort` vs `sorted` -- it's all very weird. And these aren't advanced features.

When I hear people describe Python as simple and elegant, it feels like they're using a different language than the one I know.

Re: Drawbacks of Python

#83

Post by ummonk »

dragonsh wrote: post #40
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.

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

Re: Drawbacks of Python

#84

Post by _never_k »

wolf550e wrote: post #47
rjmunro wrote: post #9

The main drawback of python for me, compared to NodeJS is the whole sharing projects onto different machines with virtualenv or whatever. package.json and node_modules just works by default in so much cleaner a way. You can use npm or yarn or just a zip of the node_modules to share the environment with a colleague or to deploy.

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.

Re: Drawbacks of Python

#85

Post by ummonk »

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…

Yeah namedtuple is the standard thing now but it is much heavier and boilerplatey compared to e.g. a struct in Typescript.

Re: Drawbacks of Python

#86

Post by privateSFacct »

weberc2 wrote: post #66
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 issue…

PEX looks interesting! Thanks for the link. I have this same issue

Re: Drawbacks of Python

#87

Post by smt88 »

kstrauser wrote: post #67
t0mbstone wrote: post #53

Earlier quoted context omitted.

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.

For some of those issues, you could type brackets instead of unit tests. Brackets are a lot less work.

Re: Drawbacks of Python

#88

Post by coldtea »

weberc2 wrote: post #80
fizzybeetle wrote: post #79

Earlier quoted context omitted.

> anyone writing Python (sans mypy) doesn't get to chastise Go for lacking generics! :) Why do you say this point in particular? Python's duck typing makes generics very easy, no? i.e., you can write an algorithm in python that just assumes a particular method is callable and you don't have to code gen individual implementations for different types. plus the dunder (e.g., `__iadd__`) methods give a lot of useful basi…

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 ceremony), but that's not the real issue.

Python is inherently a dynamic typed language, so not having types and generics is expected and idiomatic.

For Go, you have a type system and static type checking, but you can't properly use it when you resort to interface{} to make generic algorithms.

So while for Python not having types/generics is business as usual (and that's part of the very promise of the language), for Go not having generics means losing two of it's main promises, static type checking and speed.

Re: Drawbacks of Python

#89

Post by coldtea »

smt88 wrote: post #32
dragonsh wrote: post #22

I like Python because of zen of python [1]. This fits my brain and had been very helpful. Indeed in 2004 I chose Django instead of Ruby On Rails just because explicit is better than implicit. Overall Python is productive and good. Yes it has some warts and corner case, but than its evident. Among programming language python has a humble community and very approachable. Also most programmer in Python will not hesitate…

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.

>For example, semantic whitespace is arguably implicit, hard to read

How is it implicit and hard to read? If anything it's very explicit, instead of just a single { and } to denote "the next part is the body", it explicitly requires visibly indenting the body.

That's easier to read, and is the expected "good practice" in C and similar "brace" languages anyway (you're not supposed to use { and } without also indenting your code there either).

Python's semantic whitespace is more visible than having a { and } in C e.g. and not indenting, or having a for/if/etc without braces with a single statement attached and not indenting.

Not sure what's ugly about:

  def double(n):
      return n*2
compared to:

  function double(int n) {
      return n*2;   
  }
or worse:

  function double(int n) {return n*2;}
(especially with larger bodies -- in fact this non-required whitespace property is where 90% of the "obfuscated-C" ability is based on)

Re: Drawbacks of Python

#90

Post by nemetroid »

metalliqaz wrote: post #28
beagle3 wrote: post #17

Earlier quoted context omitted.

The thing about "just works" in 2.7 is that it does ... until it doesn't, and when it doesn't, it's often way harder to resolve. If you're only using the original ASCII (ordinals 0-127), all is well, and the py3 distinction between strings and bytes seems to get in the way. But as soon as you have a single character in your input or data which is not ASCII, a lot of things stop working and it isn't even clear why, or…

Maybe you're right. Maybe there are applications where this really matters. All I can say is that I have never once had that problem since I started using Python (circa version 2.4). It has always been fine. For example, when dealing with .csv files created with MS Excel, you get strange characters because Excel uses CP1252 encoding, not ASCII. They never tripped up my app in python 2.7. It happily passed them along.…

> Even regular expressions worked.

Did you try doing regular expressions for non-ASCII characters? For example, given a file "latin1file" containing the string "L£", encoded in Latin-1, Python 2 will fail silently:

  $ python2 -c 'import re; s = open("latin1file").read(); print(re.search("L", s));'
  
  $ python2 -c 'import re; s = open("latin1file").read(); print(re.search("£", s));'
  None
Python3 forces you to deal with the problem to handle the first case, but if you do, the second case will work as well:

  $ python3 -c 'import re; s = open("latin1file").read(); print(re.search("L", s));'
  Traceback (most recent call last):
    File "", line 1, in 
    File "/usr/lib/python3.7/codecs.py", line 322, in decode
      (result, consumed) = self._buffer_decode(data, self.errors, final)
  UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa3 in position 1: invalid start byte

  $ python3 -c 'import re; s = open("latin1file", encoding="latin1").read(); print(re.search("L", s));'
  
  $ python3 -c 'import re; s = open("latin1file", encoding="latin1").read(); print(re.search("£", s));'
Post reply on HN