On many forums, discussions between devs and several blogs, I saw a lots of articles in which Python is mentioned as a bad or ugly language; but why is it so?
I find Python awesome: building everything fast, easy to read and to learn the basis, etc.
But whenever I ask to my fellow developers, nobody gives me a constructive answer; so what is your opinion about it?
Happy coding !
Latest comments (68)
Python is certainly my favorite language for pretty much every project, large or small. I've been using it very effectively as my primary language for over 20 years.
However, I find that I agree with much of the criticisms of python.
The two main weaknesses of python are:
This is a horrible combination.
The problem is that people can quickly become quite productive with python before gaining an understanding of the essence of the language, and before learning what does and doesn't work.
For a project to be a success it is extremely important to have expert python engineers on the team, and make sure there is a policy of code review on all commits. Code review is the most important, because most bad habits in python would be spotted by an extra pair of eyes.
Experience in other languages doesn't necessarily help. Python is unique. Many of the most common pitfalls in python are indeed considered best practice in other languages.
A couple examples of this:
Java makes a clear distinction between data attributes and methods. If you think you need encapsulation, you must hide data attributes and use getters and setters to manipulate them indirectly. Otherwise when you change the implementation, you will have a huge refactoring task in front of you.
In python, there is absolutely no reason whatsoever to preemptively wrap your data attributes in getters and setters. You just use the attributes. Change them to properties later if it becomes necessary. Python's flexibility allows you to do this seamlessly without any refactoring outside the class being modified. In python, your best bet is to keeps things simple and concise.
In one project I found over 3000 lines of code specifically dedicated to completely unnecessary encapsulation of ordinary attributes. There was no benefit, and it made the resulting code brittle and slow.
In C++ any medium to large project has a build as a centerpiece. The model is that you have source code which you process to create something that you run. In python you basically just run the source code. Sure it's compiled to bytecode, but that's a hidden caching operation that you usually don't need to think about. And yes, in many cases you have some kind of deployment, but it need not be complicated, that shouldn't significantly impact how you think about the architecture.
So there was this project involving a million or so lines of code. The architecture involved an ad hoc package manager that would concatenate a bunch of python modules into various larger files, encrypt the result, and then use a messy import hook implementation that would load these monstrosities. The order in which things got imported was critical because lots of code would execute on import. When it came time to upgrade to python3, a nightmare was at hand.
On the other hand, I've seen plenty of beauty in python projects. The most successful always involved keeping code quality as a high priority, ubiquitous unit testing, and a high level of collaboration including code review.
Python is kinda all over the place syntax-wise in my opinion. I like languages that make use of parentheses and braces and that sort of thing. Python was actually where I started learning too.
For me, clarity over cleverness is the primary feature of a programming language. I favor object oriented languages because OO matches how I think about the world (and with Python OO is a crude afterthought).
More reasons I find python confusing and inelegant:
The syntax for lambdas in python is very clunky. Only a comma indicates where the block ends, and it has to fit on one line.
A class name is sometimes required as a function parameter in order to call a base class.
Python users often abbreviate unnecessarily, making it hard to know exactly what modules you’re including
There are some magic built in global functions, like len() which should be member functions of the relevant classes.
Standard libraries are also inconsistent in their naming conventions, like unittest which uses setUp instead of set_up
Decorators like @staticmethod are used to retrofit common language features.
A python dictionary (a very common data structure) has odd initialization semantics.
Here are code examples of the reasons why I hate python.
I like Python for prototypes and small batch.
I would like it more, but too many coders seem to assume that python means that you have permission to write bad code.
So my grief isn't against python, but against bad engineering practices.
The good thing about python is that any idiot can use it.
The bad thing about python is that any idiot can use it.
Ahah, true !
I oftenlty talk about Python as "Easy to learn, hard to master"
Easy to read?!
Did you just say python is easy to read?!
Are you joking?!
Python is the most unreadable language i have encountered!
(i mainly program in c++ in VS)
If we're not counting "Brainfuck" that is.
Python is just confusing.
Variables have no defined types, you can write code outside functions, it doesn't use curly brackets, so it relies solely on insets. Also the default ide is more than shit. No line numbers, not even auto correction suggestions or anything like intellisense.
I once had to program in python because of a certain Library Wrapper. After two hours of missing my dearest c++, i just resorted to call my script.py via the system() function in c++ storing the return value in a textfile...
Over all 1/10.
And this one point is just because i love how easily you can import libraries via pip3
The types of variables are constrained by the operations you use in the function definition, and of course its name. For example,
def myadd(a, b):
----return a + b
Rather than thinking about a and b as numbers [isinstance(a, Number)], think of them as variables that have the +(add) operator i.e: ['add' in a.class or hasattr(a, 'add')]. Another thing you can do is look at its callers, or setting a break point inside the function.
I don't know a line of Python. But I have been using undergraduate students---hundreds of undergraduates--to write research analysis code for me since 2013. Most of them are pretty darn good---I have high standards for entry into my research class.
Most of them have learned Python because that's what our university teaches as a first programming language.
So, you ask, how can I hate Python if I don't know how to write a single line of it?
Because pretty much every python program ever written by any of my students either doesn't work on another machine in the same cluster that's supposed to be configured identically, or stops working on the VERY SAME machine within a few months when some minor version number changes. Really, people. Does it really matter whether I'm using Python 3.6.4 or 3.6.5? REALLY? The third digit in the version number changes, and the code stops working?
I've been told by the local experts, "oh, it's easy to write portable code in Python". They must be using some alien definition of "easy" that's not found in the dictionary, because this is a recurring problem. Every quarter, every time I try to re-run some code that was written more than a few months ago, it fails. Traceback errors, missing library errors...
This is completely unacceptable. I have written code in 1991 that still runs. (In C. And Bourne Shell. And awk, if you must know.) Now I'm not trying to say that C or Bourne Shell or awk or f77 are better....but I'm saying that if students in their 3rd or 4th year of a Computer Science program at a decent university still can't figure out how to write code that lasts longer than a month... there is something seriously wrong.
My only saving grace is that I continue to recruit new undergrads every year, and they are able to "fix" the code.... that quarter. But pretty much guaranteed it'll die again.
This is why I hate Python. In fact, it is rare that I speak of the language without the F-word---usually in ALL CAPS---as a prefix. All my students know I hate Python, but I continue to let them use it because if I want them to do work with me, I have no choice.
Is it easy to learn? Probably. Easy to master? Clearly not. Easy to maintain? HELL NO. (Less politely... give me a f*cking break, no friggin' way.)
That's my 5 years of experience.
End of rant.
Refactoring is a nightmare. Add an extra argument to a function and expect to get errors in the distant future when an infrequent condition is met during execution and some remote part of the code calling the function with the old argument list will break.
If you add the extra argument as an optional it will work nice much of the time.
def func1(a, b, extra = 5):
----func2(5, a+b, extra=extra)
Doctests are good documentation and easy to write (just copy and paste your console session), but its true its hard to exercise EVERY code path. You can also automatically create some doctests by doing using a createTest decorator i.e: f = createTest(f) for all f in user defined modules, but no guarantees.
As long as your not doing some complex polymorphism, pylinters can catch many although not all errors. I believe some of them use "Type Inference".
I wonder how do Smalltalk and Lisp solve this problem? Did they go the Erlang route and reload code on errors?
I do not like python for several reasons (even though I have to use it sometimes because certain unnamed IoT people only supply python libs that work). For me, python is like visual basic (or basic) a pigeon language that is missing everything from proper grammar to syntax. Currently, my favorite language is C#, especially after xamarin and mono made it portable. But I'd take C/C++ any time over python if at all possible.
The indentation: The indentation in python is plainly terrible. It makes the whole code unreadable. Don't get me wrong, I like indentation, but there has to be something around it to delimit a block, like {} that everybody else uses. Makes it more readable.
command delimiter: There really should be something to delimit a command on the end of a line. I so love the C style ';'
The typing: This is like speaking without articles... do I have to say more? (this is actually one gripe I have with C# since they introduced a var type)
And finally: Interoperability. While python supposedly works well with C/C++, it is a heavenly PITA to implement an interface to it. Calls that should work, like importing a module, crash the program for no apparent reason and so on.
I see this is a very old post, but I got here from Google and I have a few criticisms of Python that aren't already here.
I come from a Common Lisp background, and I've spent the past year programming in Ruby. This means I will not be complaining about Python's lack of static typing like most other respondents.
Recently I've been pushed into Python development because the rest of my team adopted it because of a single library that is marginally better than what we had in Ruby.
I find Python to be absolutely awful. First of all, it is NOT easy to read. Programs that would be simple in Ruby (and even simpler in Lisp) turn into mangled nests of for loops in the blink of an eye, because in Python absolutely EVERYTHING has to be written out by hand as for loops. Reading Python code is hard work.
Python has list comprehensions, like Haskell, but I've found that unless the expressions in the list comprehension are completely trivial, using them leads to even less-readable code than if you just wrote a for-loop that does a bunch of appends to a list (or lists) you initialize before entering the loop.
In Ruby and Lisp, you can do a lot by combining functions like "map", "reduce", and "select" (or its Lisp equivalent, "remove-if-not"), and the code stays readable, even if the lambdas/blocks being passed to each of them have several lines of code each.
Python has equivalents to map, reduce, and select, but the language only provides these crippled one-line lambdas (also, no closures), so you end up writing hard-to-read nests of for loops instead. Or worse, somebody throws in a generator! Or you can split the code up into 50 separate functions, but that still doesn't give you the readability you would have had for free in Ruby or Lisp.
So far, I haven't gotten deep enough into Python to have to think about what I'd do in a situation where my Ruby/Lisp solution would involve closures stored in data structures. But I have seen what I end up doing to compensate for the lack of symbols: I create empty classes just so I can use the name as a value.
Python is supposedly a "batteries included" language, but every time I Google for a Python equivalent to a Ruby method that I use all the time, the Stack Overflow answer is always "Just write out the implementation inline, bro!" That implementation always includes a for loop or an even less readable list comprehension.
Example: stackoverflow.com/questions/952914...
I haven't written this many for-loops since my BASIC days.
There are mostly 2 things I don't like about python.
The second point is my main gripe with the language. So much of it seems to be different just because it can. There's a common phrase discussing learning new languages in that learning a new one becomes easier the more you know. And this is true for natural languages, as well as programming languages. Except python.
Consider the following code from the front page of python.org. I'm going to go over it line by line.
def fib(n):This line is kinda okay actually and the most "normal". By looking at the rest of the snippet we can see thatdefis used to define a function, it's going to be calledfib, and it takes a parametern. (I use JavaScript a lot so I'm not offended by the loose type system, although I do enjoy languages with one.) The:here I'm also a fan of because one thing I do appreciate about python is the tab structure for code blocks. It forces a style guide at the compiler level helping the portability of scripts in a huge way.a, b = 0, 1I thing this assignsato0andbto1but that's honestly a guess. I guess python supports SIMD but I'd much rather these assignments on different lines as the current syntax brings in a lot of unnecessary confusion.while a < n:thea < nshould be inside parentheses but that's more of a pet peeve I guess, so you do you, pythonprint(a, end=' ')is an alias forprint(a, end='\n')but I did not know that until I had to look it up in the documentation to help a friend.a, b = b, a+bI don't even know where to begin on how much this doesn't make any sense.print()According to python.org, the output of this little script is0 1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987so this line seems useless.fib(1000)We called a function. Yay!All this is only the tip of the iceberg when it comes to how much I don't like python's syntax. But that is the clarification I want to make. I don't hate python or anyone who uses it. If it gets your job done and you enjoyed making it, then I'll love python right with you. But, me personally, I never want to write python.
One more note I want to add before I close because it's probably the thing I hate most about the syntax is this:
In any other language this does not work variables are supposed to have a concept of scope, which python seems to have forgotten about because it just lets you define variables out of thin air.
While I like Python, it has some major flaws which prohibit me from using it
I haven't heard the hate you mention. I love the language, though of course there are things that annoy me sometimes, or things that I would change. In my mind it strikes the right balance between beauty and pragmatism, and between performance and usability.
I think its ability to be used as a JavaScript replacement, especially in the browser in the browser, will grow with things like Brython, but I'm currently focusing my learning on JavaScript stuff, because I don't think it's there yet (at least not among the employers I'm likely to be applying for soon).
Python as a language is mostly fine. I've used it for plenty of tasks. It's especially great for simple projects where you just need to get up and running quickly.
But I find it cumbersome for larger projects. As insane as the JavaScript ecosystem is, I really love the ease of using npm or yarn and a package.json to manage and install dependencies. Virtualenvs and requirements.txt are clunky and confusing by comparison. Also, importing modules from different directories is much more troublesome in Python than in JavaScript, where you can just give the file path.
Python has strengths, but it's also got weaknesses. For some things, it's my goto. For others, I really don't want to touch it.
Ok, here we go (puts on fire-resistant coveralls) ...
For reasons that no one understands, all of the sudden python acquired this
enormous library structure which allowed people to say "I'll make a thing
that does this, that or the other thing" and they found all the stuff that
they wanted, in particular they could make a robot move around.
Python is an extraordinarily successful language, especially for one created as a hobby project named after sketch-comedy with a design philosophy that is a nineteen line poem.
Python got the holy grail (pun intended) early on - a big set of reusable and well-maintained libraries that you can just grab off the shelf and save yourself thousands of lines of code reinventing the wheel. Its better than a great static type system, better than automated testing, better than object-oriented, functional, or any paradigm one can imagine. With a few great libraries that you can actually use, your massive complex project might just reduce to a 50 line script.
I don't claim to know why python is so enormously successful. I really like python, and I could speculate on some of the properties of modules as a basic unit of encapsulation, iteration and other basic protocols, and so on. But at the end of the day I don't fully understand why, and neither does Gerald Sussman.
This lack of understanding is frustrating to the idea of software engineering. I think that much of the field would like to believe that we can enumerate - at least in part - what properties a language should have in order to result in rapidly developed software which is reusable and maintainable by teams of human beings. Python is missing one of the big ideas here, which is a strong static type system. If that is so important, then how is python so successful? How are teams writing python not drowning in uncaught type errors? How are there so many good libraries available?
There are two major differences between software engineering and traditional engineering fields:
First, software engineering is generally not a regulated profession - at all. There are no standard proficiency tests, degree requirements, or even a truly agreed upon curriculum.
Second, there is no basic theory or set of equations to tell you if a given design will result in a software that is successful in the sense that it can be delivered on time and maintained with a reasonable level of effort by a team of humans. Electrical engineers can use Maxwell's Equations and derived formulas to state clearly and definitively if a given design will generally work. Civil engineers have Newtonian Mechanics. Aerospace Engineers can rely on various approximations of the Navier-Stokes Equation. I would argue that software engineering does not have, and may not ever have, some sort of equivalent set of laws to tell you how successful a project will really be. It's fundamentally a harder problem as it involves human behavior.
So python, with its arguably haphazard success, serves as a reminder of the inherent difficulty in determining a working and general theory of what properties are required to make a software development project a success.
TLDR - python lacks many language features considered by many to result in successful software projects, static typing being a major example. While this may make the language unsuitable for some teams of humans, a great many teams of humans have found success using the language and built a huge ecosystem of usable libraries. There is no commonly agreed upon theory of why this has happened. That's kinda frustrating.
Really liked your comment ! I actually have one thing that deeply troubles me with python, from my stubborn must-do-anything(like must prove this theorem kind-of-stuff...) : well, trying to do something really scientific in python without Numpy is slow, and it just seems so nice to actually WRITE those things and see they work then just say: Hi, give me that! But not everyone is into this all I-want-to-prove that the fundamental theorem of calculus actually is real thing :-) . Interested how do you think I'll be able to reconcile with python? maybe try to write python like Rust?(even possible)
Teams of humans, as opposed to... teams of ducks?