
Drawbacks of Python - iflywithbook
https://www.quora.com/Python-programming-language-What-are-some-of-the-drawbacks-of-Python/answer/Dave-Wade-Stein?ch=10&share=9ec1027c&srid=43O3
======
roland35
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 or things like that. I
know that there are some tools to help compile but they aren't easy to use.

Also, it is hard to create GUI applications vs languages like C#!

Other than that I love using python and I think it is a great tool to use in
embedded development along with c/c++.

~~~
wlesieutre
I have the same two complaints. I’ve automated some large tasks at my job with
Python, and avoided external dependencies because while I’m sure I could deal
with it, nobody else here is a programmer and it don’t think it would go well
if someone had to try and figure that out later. “Install python (3.6 or
later), point script at the csv file” avoids that complexity.

It’d be better if it were a self contained executable with a GUI but not worth
the time to figure that out.

I messed around with TkInter a while back, not sure if anything's new since
then. For executables there was py2exe, cx_freeze, and PyInstaller, but the
situation with packaging DLLs into an executable that would actually work on
someone else's computer was iffy last I checked.

~~~
dec0dedab0de
if you just want to make a self contained executable for windows users I've
used py2exe a few times and it always works well. It's basically one command
and it gives you an exe of your .py file

[https://pypi.org/project/py2exe/](https://pypi.org/project/py2exe/)

~~~
metroholografix
py2exe and anything else that uses Joachim Bauch's memory loader is loading
DLLs in a broken fashion that is bound to bite you sooner or later, assuming
it works in the first place.

Reimplementing - in a buggy incompatible way - the Windows loader (which is
what that code is doing) from scratch, is a gross hack and should not be used
to build anything that's meant to be reliable.

Note that pyinstaller and cx_freeze do not suffer from these issues. Do not
use py2exe.

------
kyllo
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):` is an anti-
pattern because it's a duck-typed language

\- Interfaces are neither available nor necessary due to late binding.
Abstract Base Classes are the closest thing to an interface, but they're also
unnecessary because again, it's duck-typed.

\- Inheritance is widely considered to be a mistake ("Prefer composition over
inheritance" etc)

\- Classes tend to complicate testing

I can use classes to write custom data structures, I guess, but in a language
as high-level as Python, I can just model trees and graphs with dicts. If I
need a more performant data structure, I'm not writing it in Python in the
first place.

I've seen some very experienced Pythonistas recommend using namedtuple instead
of classes for most use cases, and I tend to agree with them. That gets you
immutability as well as dot notation for accessing fields.

Clojure programmers seem perfectly happy with just lists and maps, and after
experiencing that, classes feel like a bolted-on misfeature in Python.

~~~
sebastos
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?

~~~
kyllo
Yes, exactly. Nail on the head.

When I do have a datatype that needs to be handled differently based on some
condition, I tend to use ABC's with only one level of concrete subclasses,
just to make that implicit method interface explicit.

------
dragonsh
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 to use low level language and
interface with Python when necessary. It's not considered bad.

    
    
      >>>import this
    

" _Beautiful is better than ugly.

Explicit is better than implicit.

Simple is better than complex.

Complex is better than complicated.

Flat is better than nested.

Sparse is better than dense.

Readability counts.

Special cases aren't special enough to break the rules.

Although practicality beats purity.

Errors should never pass silently.

Unless explicitly silenced. In the face of ambiguity, refuse the temptation to
guess.

There should be one-- and preferably only one --obvious way to do it.

Although that way may not be obvious at first unless you're Dutch.

Now is better than never.

Although never is often better than right now.

If the implementation is hard to explain, it's a bad idea.

If the implementation is easy to explain, it may be a good idea.

Namespaces are one honking great idea -- let's do more of those!_"

[1]
[https://www.python.org/dev/peps/pep-0020/](https://www.python.org/dev/peps/pep-0020/)

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

~~~
t0mbstone
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 Javascript, indentation is stylistic and
has no effect on the logic. You can actually use the "auto-indent" feature of
many editors, and you can use linting tools to ensure formatting. If you have
an extra "end" or an extra ending bracket, your IDE can immediately warn you.
Not so with python!

~~~
psv1
> 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?

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

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

~~~
smt88
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 of saving keystrokes, but it does have value in
practice.

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

 _Flat is better than nested_

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

------
psv1
So this just links to someone's opinion on Python 2 vs 3 instead of an actual
discussion on the drawbacks of Python, right?

~~~
misterdoubt
To be fair, it also highlights a benefit of Python 2.2 over 2.1. (I.e.,
improvements made in the language eighteen years ago.)

------
brbrodude
Dunno if Ruby locked my mind into a certain mode, but I've never felt good
doing anything with python :( 2 different projects I tried participating with
a lot of years in between, still felt the same. Granted, I can't say I've
really studied it properly.

------
canada_dry
Quora click bait. A dull and benighted article that adds nothing to the
discussion.

------
mikece
"No language is perfect" is the perfect reply to asking about the drawbacks.
The ability to get things done in a language is what allows someone to deliver
VALUE to a client (or for their own projects). A workable solution now trumps
a perfect solution that will take too long to implement.

~~~
collyw
JavaScript is a pretty bad language in my opinion, but does have the universal
deployment problem solved a lot better than any other.

~~~
noobiemcfoob
JavaScript is the perfect example of give hackers a bit and they'll take a
damned terabyte.

~~~
SketchySeaBeast
JavaScript is like Buckley's cold medicine - It's awful, but it works.

~~~
neural_thing
Unrelated to this comment, based on your earlier comment - check this out:

[http://www.classicshell.net/](http://www.classicshell.net/)

This transforms the start menu on Windows into any version of it you like.

------
PythonicAlpha
I actually expected some elaborate work about the imperfection of Python.

What I got was a list that started with at least three points that are already
obsolete, because only valid for Python 2, which is already declared obsolete.

Every language with some history has its humble start and is evolving. To
carry the errors of the past is just not fair. You could of course drag along
the first Java version and conclude that Java is bad -- but you would really
invalidate your own opinion.

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

~~~
beagle3
conda solves that for python at least as well as npm/yarn does. I don't
understand while it is not in wider use (except for lack of PR).

~~~
physicsguy
If you want to add your own project to Conda, you need to use conda forge,
because Anaconda itself is a curated distribution.

Maintaining a conda forge package has been, for us, a complete nightmare. If
you depend on another conda-forge package you can have the issue that the
library is configured to suit whoever first wrote the conda-forge package -
i.e. by disabling parallelism or providing only shared/static libraries, and
have that maintainer be completely unresponsive or unwilling to change it.

~~~
msarahan
That is a downside of community maintenance, for sure. Conda-forge probably
needs official policies and suggested workflows to have multiple varieties of
recipes where feasible. There is never a one-size-fits-all solution when a
community serves so many different people with so many different use cases.
Spack fits the "my way and only my way" mentality better. Conda is more "close
enough, and already ready for me to use."

------
skrause
I have to deploy web applications written in Python on Windows... no uWSGI, no
Gunicorn and no easy multiprocessing because no fork(). It's painful quite
often and it makes me loathe the GIL, but I still enjoy writing Python code.

~~~
kerkeslager
I'm curious what what your approach to this is. Relying heavily on Twisted
seems to be the obvious choice?

------
anm89
Maybe I'm naive, but in my mind besides their ecosystems and superficial
syntax differences there isn't that much functionally different between Python
and Ruby, with the major to exception of blocks in Ruby.

In which case the decision between the two seems to be between a thing and a
slightly better version of itself. I totally respect that many people see this
differently and probably exactly opposite but to me it always feels really
hard to justify using python for this reason.

Just for fairness sake I'm not trying to trash python. I think it's a great
language.

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

------
kerkeslager
Almost every discussion of programming languages falls into bike-shedding[1]
and this is no exception. The _only_ thing he mentions worth talking about is
the GIL. Syntax and small API gotchas can be learned by a beginner programmer
in a matter of days of using the language, and are fairly irrelevant to your
overall experience. If whitespace and using the division operator are big
problems for you, significant software development probably isn't within your
abilities.

In addition to the GIL, other problems I'd point out with Python:

1\. At one point, Python was "batteries included". This is largely no longer
the case any more--most projects are largely dependent on PyPI, and there's
been a growing sentiment in the last few years that "the standard library is
where modules go to die". PyPI libraries are of inconsistent quality and have
a high turnover rate; the "standard" for what to use changes fairly rapidly.
And if you manage to make good choices of mature libraries and not have to
change them every year or so, you still have to manage dependencies, which
complicates deployments.

2\. Fracturing community: there are now a bunch of different non-standard ways
to install Python and Python dependencies, which conflict with each other, and
none of which fit all use cases, so you have to use all of them and deal with
conflicts. This exacerbates issues with 1.

3\. Increasing dependency on non-pure-Python dependencies which don't build
trivially. There are reasons for this: Python often isn't performant enough
for certain tasks, and other languages have some very good tools. However,
this means you can't just `pip install` a library and expect it to work--even
very common libraries like Pillow don't without fiddling. Again, this
exacerbates problems with 1.

4\. Lack of a good desktop UI framework. It's apparent that not as many people
are using Python for native UIs any more. tk is cludgy and doesn't result in
pretty UIs, and despite being part of the standard library, it doesn't work
out of the box on MacOS. wxWidgets doesn't build on MacOS without significant
work, and documentation is for the C++ version of the library. This is sort of
the intersection of 1, 2, and 3, but in desktop UIs they combine to form a
perfect storm. If you're developing a desktop UI, there are better languages,
but I'm not going to post them here because I'd rather keep this as a
constructive criticism of Python than a language competition.

5\. Introspection being used to change language syntax without solving the
problems the language syntax solves. I'm really looking at Django here, but
they're not the only guilty ones. When you call a function, i.e.
route_on_http_method(GET=get_handler, POST=post_handler), functions can fairly
easily check arguments and throw an exception from a logical spot--i.e.
route_on_http_method(GIT=get_handler) throws an exception immediately. But
when you have `class MyView(GenericView): def git(self, request): ...` you get
no exception until you try to call the view, in which case you get a wonderful
cornucopia of meaningless line numbers in a useless stack trace. Sure, Django
code looks nicer and more organized, but as I said, syntax isn't that
important. Debugging IS important. Using the bikeshedding example, this is
breaking the nuclear power plant to fix a problem with the bike shed. And this
is a generous example: it's fairly simple and Django is one of the libraries
that does a _better_ job of this. If you really want configuration-oriented
programming, you'd be better off parsing in JSON files and doing explicit
error checking when you parse them in, rather than introspecting out a syntax
that's not really code and not really configuration. Introspection hasn't
played out well as a Python feature.

You'll note that all these problems are CULTURAL problems, rather than
problems with the language itself. And that's my point, because those are the
problems you can't easily work around, and it's the problems you can't easily
work around that make or break the language.

I say all this because I love Python. I've worked in Python for the last 6ish
years, and don't see that changing any time soon.

[1]
[https://en.wiktionary.org/wiki/bikeshedding](https://en.wiktionary.org/wiki/bikeshedding)

~~~
saagarjha
> Syntax and small API gotchas can be learned by a beginner programmer in a
> matter of days of using the language, and are fairly irrelevant to your
> overall experience.

I agree with the first part but not the second. One can only write

    
    
      arraylist.add(arraylist.size() - 1, arraylist.get(arraylist.size() - 1) + 1)
    

before wondering if there’s a better way to do this.

~~~
kerkeslager
Even if your language doesn't support a better syntax, it probably supports
functions, so you don't have to write this over and over again. Just pull out
into `appendLastIncremented(ArrayList a)` and call that.

You'll have forgotten the pain of writing that function within an hour. I'll
_never_ forget the pain of debugging a {bar: 1}.baz returning undefined
(failing silently) and then going into a future inside a minified 0.0.2
versioned library that doesn't do any constraint checking before finally
throwing an exception. Nor will I forgive JavaScript for this.

~~~
saagarjha
I don’t _want_ to write a random free function for one line of code. I want
nice syntax:

    
    
      list[-1] += 1
      array.last += 1
      *(vector.end() - 1)++;
    

Having reasonable syntax and a strong type system are not mutually exclusive.

~~~
kerkeslager
> I don’t want to write a random free function for one line of code. I want
> nice syntax

 _shrug_ Sure, me too, everybody wants nice syntax.

What I'm saying is that syntax is _never_ the most important problem with a
language. People talk about problems with syntax because they're easy to
understand, and the more important problems with a language are much harder to
understand and talk about.

If a genie told me I could wish for three problems with Python to be instantly
fixed, none of them would be syntax. I can't think of a language I've used
where syntax would be on the list.

------
partizanos
Sorry but it just seemed odd I didn't see a mention for GIL (global
interpreter lock).

Because of this mechanism that ensures concurrency safety Python does not
support parallel execution of threads. I am wondering if the rest of the HN
community finds it as a major disadvantage.

------
makz
I love python and it is my main language for almost everything.

However, yesterday I was playing with python’s async/await and I came to the
conclusion that it is a bit... useless.

Not a big deal, because i can use other stuff to accomplish the same I was
trying to do.

Or maybe I was doing it wrong.

------
m4r35n357
Python is the simplest language I know of that does operator oveloading. If I
had to write my pet maths project in c++ I would not even have got started.
Sometimes abstract "drawbacks" are irrelevant!

------
abakus
_Simple is better than complex._

 _There should be one-- and preferably only one --obvious way to do it._

[https://xkcd.com/1987/](https://xkcd.com/1987/)

~~~
yen223
Also, here are 4 different ways to do string formatting

------
metalliqaz
From the article:

> Strings were just a sequence of bytes in Python 2, but now are Unicode by
> default. Much better.

whelp, not trusting this guy's judgement anymore

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

~~~
metalliqaz
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/](http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/)

~~~
joshuamorton
I've been using python for years now, I don't know the last time I had to use
`sys.stdin`. I (like most people) deal with `open`, and unicode-only file apis
(or the very nice things like flask that mitsuhiko and others have built). For
most people, this isn't a problem.

I've migrated literally, 10s of thousands, of files from py2 to 3. I've yet to
encounter an issue with surrogateescapes or sys.stdin. Unicode issues yes, but
mostly because we were previously being fast-and-loose with unicode vs. bytes,
and mishandling, for example, emojis.

~~~
c0ff33
I certainly wouldn't trust Python to open the standard streams correctly,
explicitly check the mode/encoding or reopen the descriptor.

