I've heard from reliable sources that Python is a great language that every programmer can learn, but I've heard so much good about it that I'm clearly not getting the whole picture. I'm considering spending more time to learn it, and I've heard more than I need about its virtues (to the point where I've started recommending it having never really used it), so I want to know its drawbacks, flaws, issues, and every single minor point of irritation you've ever had (preferably with explanations readable to one who doesn't program Python, such as with an example in another language).

Convince me not to try it out.

+32  A: 

One anti-python school of thought is that forcing style such as indentation is wrong. However, as I cannot convince myself, I guess I would fail at convincing you.

I've heard plenty of arguments about how wrong it is. I personally really like it because, for once, at least everyones indentation styles match. I count it as a positive feature personally.
Yes. You don't need a company policy for coding style when you code python, you just go ahead and code :)
And use spaces, not tabs. /me ducks.
Christopher Mahan
@Chirstopher: Why spaces over tabs? Just curious because I see that option on every editor. Why would you want to do that?
Luis Soeiro
@Luis - The Python Style Guide highly recommends spaces over tabs. Mostly a push to coding by convention. But whatever you do, just don't mix spaces and tabs.
Well if there's a reason not to code in python I think this is the worst one. "Me: Hey boys we are going to develop in python!, Them: No no, please we hate the indentation" ... That won't happen.
I find the indentation a virtue, as it helps to highlight logical blocks, and forces good style. It usually doesn't get in the way as long as you don't mix tabs with spaces. An editor will mitigate this to 0 though.
Josh Smeaton
@Chirstopher: I used to prefer tabs since its a single character over 4 (anything other than 4 spaces per tab is just weird, hah), but then I switched to using better editors and now generally use spaces (or rather, the editor converts my tabs to spaces).
@Luis: I'm personally a big fan of hard tabs, in theory. In practice, no one seems to get it right, so the best option is to stick with PEP-8.
Jeremy Cantrell
When I first started using python, the indentation thing made me cringe, because I thought it would cause me all sorts of problems. Honestly, I can't recall ever having a problem with it.
Jeremy Cantrell
@Jeremy: the one problem it can cause is when you go to paste a chunk of one function somewhere else. The meaning of the pasted chunk can change depending on how indented it is. With a curly-brace language, you just paste and say "reformat". Not a huge deal, but something.
This is a big one for me. Every time *standard support* for braces is proposed it's mocked, and I don't find it funny in the slightest.Many times I've missed it. When I'm using a terminal and I can't install my editor, when working with others code, when using 3rd-party code analyzing tools...
Also, see this: http://stackoverflow.com/questions/118643/is-there-a-way-to-convert-indentation-in-python-code-to-bracesIf I was blind, I would find the jokes even less amusing.There are parsers already in the code. Include the option for Kthulu's sake.
from my experience with reading others' python code, I should say that indentation syntax (although odd at first) is great!
of all reasons to not use python, this is the absolute worst.
Dustin Getz
I love indenting code, and I don't usually mind that the indentation is syntactically significant, but a couple of times I have been bitten when rewriting loops or conditionals and forgetting to indent or dedent a statement to bring it into or out of the block. I guess with experience I have learned to watch for this.
+6  A: 

Here are some points on Why to use it : http://www.amk.ca/python/howto/advocacy/

And this is about stupid people trying python: http://mail.python.org/pipermail/python-list/2003-February/190906.html

Have fun.

Either way, its programming and we all love it.

Filip Ekberg
+8  A: 

sometimes I get lost trying to figure out where variables are coming from, because you don't have to declare them. I guess experienced Pythonistas don't have the habit of scanning a function's variable definitions to determine what's going on.

If the block of code is short enough, there's no mystery. If it's so long that there's confusion. Well, that says it's too complex and needs to be broken up into pieces you can read and understand.
global for global scope. outside of all blocks for module scope. prefixed with 'self' for class scope and inside whatever method/function for local scope. It doesn't hurt to initialize them with a value, even if just for clarity. Really, it's not that hard.
Evan Plaice
+4  A: 

Usually a language isn't good or bad by itself. The point is, is it the language to get your job done? If the answer is "maybe", spend some time trying it, and you'll discover.

mmhh that's a good comment, but not an answer.
lol you are silly
+27  A: 

Python does not require variables to be declared in the scope they're in. Or indeed, anywhere. Therefore, it can't check this at compile-time.

This is bad - even Perl (with "use strict") or VB (with "Option Explicit") do this.

This means that the compiler cannot even detect a trivial typo- it will produce a working program anyway which will continue working until it reaches the typo - THEN go boom. It would be a lot nicer to require variables to be declared, then the compiler could detect this and complain upfront.

Worse still, in some circumstances, failing to define a variable in a given scope (for instance, because it was defined with a typo) causes it to be picked up out of a higher scope - even if this wasn't what the programmer intended - again because variables don't need to be declared.

If this is confusing to you, note that I have used the terms "delcare" and "define" as accurately as possible.

This is what unit tests are for. Plus comparing Python to VB without Option Explicit simply isn't fair. There are a lot of type safety features that python adds above VB.
Jason Baker
I actually quite like Python, I think it's a great language. VB is not. However, this is one of the few things I don't like about Python. I mostly use Perl, and in most respects, that's much less nice.
In practice, I have never once found that a bug was caused because something couldn't be type checked statically. The duck typing paradigm works exceptionally well, IMHO. Then again, I often find myself coding in the interactive shell and then pasting working tested code into my main program.
I found something like PyFlakes, PyChecker, or PyLint will help you find your typos.
Using variables without having to "declare" them before usage is one of the things I would think most people find nice with Python.If you can't figure out where your variable is coming from then you are probably writing to large blocks of code or isn't naming your variables in a good way.
++ The biggest problems I've had with python have all related to the typing. The worst is building a data structure with lists or dictionaries: a simple typo and your program explodes. A defined structure would be a lot safer. You can do this with classes, but with more work than C would require.
typo fyi: delcare
+1  A: 

You cannot be absolute when considering a language. Python isn't bad or good, it's just better or worse than other languages in some areas.

The Python community is big and active and the language is actively supported. You won't waste your time playing with it, especially because the time invested will not be lost when you learn to another.

I would maybe suggest to have a look at Ruby to see if you don't prefer Ruby over Python.

Edouard A.

Far from it that it actualy suck, but I'm not using it for the following reason.

To me, it looks too sterile . I just don't like it.

Dev er dev
I guess you like languages that look like a explosion in an ASCII factory? =)
It does have that Hobbits/The Dutch sensibility going for it, doesn't it. :)(I keep the library reference on a thumbdrive so I can wear it on a chain around my neck.)
J.T. Hurley
Hey, we Dutch don't have hairy feet!
Ruben Steins
+1  A: 

Many subscribe to the school of thought that good language design means concise ways of describing the language. For example, Java is a language about Objects. Everything is either an Object or a blueprint for making an Object. In Scheme, everything is an expression which can be evaluated or passed to another function. In Python however, there are many different paradigms at work. To some, it seems to be a mish-mash of useful features thrown together with no unifying concept.

Dylan White
+7  A: 

I suppose the biggest (realistic) argument is python's dynamic typing, which can cause some needless errors if you're not careful. Of course this can be helped by good unit testing, but no matter what you do, there's always the possibility of typing errors that you wouldn't run into in a more statically typed language (Java/C#).


One thing I see people saying is that you don't have to declare variables in Python. This is true in the strictest sense. You have to think differently about declarations though. For example, take the following code in a C like language:

int x = 0;

Think about it this way: why do you need the int keyword and the semicolon? Can't that be inferred? So just change the above to this:

x = 0

And use that format whenever you would declare a variable.

Jason Baker
Good comments. The risk with implicit declaration is if you ever misspell the variable's name while giving it a new value (or perhaps even when accessing its value, depending on how the language handles this case), you will end up with an extra variable and incorrect behavior.
Neil Whitaker
As I stated elsewhere, in practice I have never ever been in a situation where static typing would have saved me from mistakes. I do however agree with your point on type inference - ideally, a language should be statically typed by default BUT it should still not require me to declare my ...
... variables and should infer their types. This way I get the best of both worlds. Of course, this feature should be over-ridable too. OCaml does this pretty well.
Static typing and variable declarations are orthogonal - Perl under 'use strict' requires variables to be declared, but they are still dynamically-typed.
Dave Sherohman
...And, in practice, I have never encountered a case where not declaring variables has provided any advantage other than allowing the programmer to be lazier.
Dave Sherohman
I don't think it's fair to state a negative of python as being 'dynamically typed'. Dynamic and Static typing is a different argument altogether and not Python specific.
Josh Smeaton
+11  A: 

My biggest irritation with Python is the lack of an enum type. I know there are ways to emulate the functionality but I haven't found one that suits my sense of style.

David Locke
While not perfect, set or frozenset types can be a worthwhile alternative to enum.
Adam K. Johnson
actually I found that you don't really need enums, there's almost a pythonic way to solve things that you would use enums for in C.
hasen j
Use dictionaries. Enums are nothing but OOP code smell limited/hackish implementation of a dictionary set.
Evan Plaice
+27  A: 

Python can be called slow.

By slow, I mean slower than C and slower than Java with a JiT run-time.

On balance, this rarely matters.

If you really really need performance (scientific apps, games, whatever) you could try implementing performance critical code in pyrex or cython - or as a C module, I guess. Then again, if performance is more important than development time, perhaps a different language is a better fit after all.
@Dan: Since 10% of the code is usually 90% of the run-time, a small bit of performance-critical code is all you ever need. If rewriting critical sections with Pyrex or Cython doesn't do it, you have the wrong algorithm in the first place.
@Dan: Games? Please inform the Eve Online people that Python could be too slow for their large multiplayer online game.
@Slott - there are software problems where the 90/10 rule doesn't matter. For example, many realtime systems need deterministic behavior.
@Tom: When I worked in real-time software, I was well aware of the difference between deterministic, flexible and fast. Some things needed one, some things needed another. And, the 90/10 rule applied even in radar software.
@Tom, Slott - this is also the case for computation intensive applications. While it is possible to write low level functions in C and call them from Python (e.g. NumPy) this sometimes makes the code unnatural -- see for example Matlab code that usually must be vectorized for performance.
In many cases, Python provides primitives like list comprehensions and the NumPy nimrodm mentioned that can largely negate the most common cases of performance bottlenecks.
Good algorithm design generally helps more than essential language speed. Nonetheless -- the only sensible complaint about Python is "it can be called slow".
+24  A: 

Another point to make: Python is a difficult language to write good editors for. There are just too many backdoors and roundabout ways to do things to make features like Intellisense or syntax error highlighting. There are some tools that do make reasonably good attempts at this stuff, but it's definitely not what you're going to be used to if you use a language like Java or C#.

Jason Baker
+1 and this also extends to debugging
Robert Gould
And like other reasonable scripting languages, somehow it doesn't really seem to matter much. Which continues to surprise me.
Mike Woodhouse
+1, but I think this is something that will improve a lot in the future. There's a lot of interesting research going on in this area.
intellisense is silly, and i think no reason to limit language flexibility. the code should be hit anyway unless you're coding standard is to distribute untested functionality.

Python is popular and relatively easy to learn. Language comparisons can tend to get religious fairly quickly, but there's a few points worth making:

It's a dynamic language, and generally considered to be a scripting language. This means that it's less verbose than something like java.

It has functional constructs. Python was actually how I first became familiar with these concepts (lambdas, map & reduce functionality, etc, etc). If you've never worked functionally that's a nice way to transition easily into a different paradigm.

Duck typing.

A downside I've found is that the dynamic nature of the language makes it harder to build in the large, harder to keep track of larger-scale projects. Then again, maybe I haven't worked with it enough.

Partly because of these reasons, idiomatically written python tends to be simpler than typed/compiled languages, which can be a refreshing viewpoint, especially if you're coming from anything attached to the word "enterprise". As others have noted on this page, many of these same benefits are true of Ruby, which is also quite nice, and IMHO occupies the same language "niche".

Steve B.
+8  A: 

I have some points in the answer to Five things you hate about your favorite language. There are a couple of others who have posted five of their own things about Python, too.

My favourite point is the one about accidentally permanently changing the default arguments to a function at runtime.

Greg Hewgill
+44  A: 

The main implementation uses a GIL (global interpreter lock), which means that you cannot fully utilize your CPUs with Python threads, because threads serialize on object access.

This is a feature of the implementation, not the language, so you can get around that by using Jython, IronPython or maybe some other implementation (something PyPy based maybe?).

Also, support for process-based parallel processing is getting better and better in Python, so the GIL issue gets somewhat less important.

Rafał Dowgird
I believe you can use the multiprocessing module which in turn uses subprocessing to utilize different CPUs. (correct me if I'm wrong)
You are right. That's what I meant by support for process-based processing getting better.
Rafał Dowgird
+5  A: 

There are lots of good reasons not to use Python, but they're all dependent on what you intend to use it for. The complaints about whitespace (oh, please) or duck typing or broken IntelliSense are (maybe) problems with the language, but they don't rise to the level of reasons not to use it.

Here are some actual circumstances in which you wouldn't want to use Python:

  • You're writing code for a piece of hardware that has only 64K of memory.
  • Your code has to manipulate very large matrices of integer values as fast as possible.
  • You're writing a web application that has to process extremely large numbers of hits, and your hosting provider doesn't support WSGI.

Those are, for the most part, not reasons not to use Python: they're reasons not to use the entire class of interpreted scripting languages that Python belongs to.

Robert Rossney
In case you only have 64K.. http://www.philhassey.com/blog/2008/01/31/tinypy-64k-bootstrapped/ Courtesy of having a large, very large community - everything is possible. :))
Shouldn't scipy handle large integer matrices just fine?
not only scipy, but pycuda and cython's new buffer notation.
+1  A: 

The best reason I can see someone not wanting to use python would be to demonstrate that they are Luddites.

Definitely. Ruby users = luddites.
Ellery Newcomer
So... when the next new language comes along tomorrow, will you jump on that bandwagon, too, or will you be a Luddite and stick with Python?
Dave Sherohman
@Ellery + Dave: In all fairness, "not wanting to use Python," "wanting to use Ruby," and "preferring Ruby over Python" are three different states that don't necessarily overlap.
J.T. Hurley
+4  A: 
  1. Lack of static checking requires that section of code to be hit to find out there is a problem. Essentially this forces you to write unit tests.

For example, this code will run up until the dog() function is called:

def dog ():

print "Hello World\n"

2. Use of duck typing can lead to surprises to how variables are treated

As a further to this you can redefine the function later without any warning, a pain if you are making use of code split across multiple files
"Lack of static checking and Use duck typing"? I suppose both are 'features' of dynamic-typed language with all teh consequences. This answer is better for question like: Why I should not use dynamic-typed language
+1  A: 

I've seen one mention of this, but the thing that turned me off of Python is the part where indentation and white space matters.

I just could not get past the fact that your code (aside from white space) could be correct but just because of some small white space issue it does not work. Maybe if I stuck with it more it would be a non-issue but I know when learning it it drove me crazy and I ended up giving up.

At some point I opened my file in a different editor and something happened and I ended up having to re-indent everything. That was the point where I realized I'm not going to do that anymore.

I like indenting code but I don't like my code not working just because of white space.

Someone mentioned Ruby. I see Python and Ruby compared a lot. Because I didn't do so well with Python I tried Ruby and I like it. For me Ruby feels a lot more natural and somehow calm.

Agreed. I just can't bring myself to trust a language with syntactically-significant whitespace.
Dave Sherohman
yeah, whitespace is a big issue for many, but once you get used to it, it's a non-issue. I can't remember the last time I had an unexpected indent exception.
A good editor can help immensely. IDLE, among others, offers a set of keyboard shortcuts that indent and dedent code in blocks, which can help with "wrapping your head around" the system.
J.T. Hurley
Uhm, I have never had problems with indentation.It's the most fundamental part of the syntax, so how can it be hard to remember and do right? The interpreter also gets inyour face every time you do it wrong, so you should have no problem learning it really quick.
You're code broke when switching editors because you used tabs instead of spaces. Tabs are not standardised. They are interpreted differently between editors/OS's. If recommendations were followed, you probably wouldn't of had that problem
Josh Smeaton
Guys.. Python does NOT care about whitespace. It does, however, enforce indentation.
Jeremy Cantrell
I guess if I stuck with it longer I would have gotten used to it. But still it's a reason I ended up not using Python. And yes, using Tabs was my problem. I've always been used to using tabs. I should probably use spaces...
+1  A: 

Python's a nice language. I can think of only a few weak reasons not to try it:

  • Maybe you really, really hate objects?

  • Perhaps you will be one of those people who hates significant whitespace (I love significant whitespace).

  • It is a big system (language and libraries), so you will never master it completely.

  • Maybe you prefer to wait for Python 3.0 to become widespread before learning it?

As noted, these are all weak reasons :-)

Norman Ramsey
Python does not have significant whitespace. s/whitespace/indentation/g
Jeremy Cantrell
If you hate objects, you don't have to use them. Just write your code without objects!

unless you are thinking of using libs that are found only in Python. I would advise against using learning it.

Better go for Delphi as the language to learn. You will be instantly productive and you will get true RAD IDE which is yet non existent in the Python World!

Yogi Yang 007
downmodded for total irrelevance.
Josh Smeaton

Good: The language is named after Monty Python

Bad: All the doc's are riddled with snakes (cute snakes)

Good: Stable with very large memory apps

Bad: Somewhat funky for web apps (see Zope)

Good: a lot of libraries to extend the capabilities

Bad: no solid IDE (do you love text editing? vim or emacs? so does python)

Good: Used by very large software houses (Google, etc)

Bad: Not common in the business world

TIP: Pick a basic programming assignment close to your target application and see how far you get towards a working app in 60 minutes using the web for docs. Was it good for you?

How can it be not common in business world?
+3  A: 

You must not use Python when (assuming Python is not your main language) :

  • You are in a rush and the languages you know will do the job.

  • You are looking for speed and have not time to create C extensions.

  • You want obfuscation.

  • Your code will be reused by people that you know, will not use Python and don't know it.

  • Quality is a main issue, therefor the language you master the best will be the best shot.

  • You know you will use features that have a better implementation in other language (I am looking at the FTP lib here...).

Anyway, Python pays my bill and am really happy about it.

Thanks for IMHO, the first real answer to the OP's question :)

Multithreading in Python is a big problem, due to GIL (global interpreter lock).


The colons. Honestly. If the next line is indented from the current one, why do I need to use a colon as well? Drives me nuts.

To steal an example from another answer:

def dog ():

It's obvious (and necessary) from the indentation/white-space that the second line is part of the dog function.

Trivial, I know, but it really bothers me.

Oh, and I don't like the need to pass "self" as the first argument to a method within a class, but I understand that part's going to disappear in 3.0?

Mike Woodhouse
you're allowed to put things like "if" statements on the same line. how would you do this without the colon?
Jeremy Cantrell
I'd do it without the colon... ;-)
Mike Woodhouse
The need to pass self is a good thing (that's not going away any time soon). Here are the BDFL's arguments: http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay.html.
Jason Baker
But what you have to keep in mind is that Python isn't C++, C#, or Java. The ability to bind methods to different classes makes it so that you can't have an implicit self like you do in other languages.
Jason Baker
Explicit self is necessary in Python, as the article explains. But being necessary does not make it a good thing.
Roy Peled
jeremy: it's possible the colon could be used for this case but not the two-line case. I think [a better argument is] the colon is minimal excess (compared to braces) and prevents ambiguity when continuing lines with open brackets / braces / parens / foreslahes.
+50  A: 

The problem is that it is not as good as it is made out to be, in other words it suffers from a degree of hype. I'll try to argue this point.

Potential detractors of the language usually lack the experience to criticize it authoratively. This is more true for python as it is not (yet) common that people are coerced (by work,school) into learning and working with the language. So the detractors are few and drowned out by the vocal supporters.

The top answer cites 'indentation' and then says but its not an issue for him, this is a strawman argument 'this is the worst problem and its not really a problem'. Indentation is a matter of taste and is more noticeable than bad. This answer has been voted up presumably by people who like the language, because it certainly does not answer the question, which is give a good reason not to use the language.

Python is open source, and community driven from the beginning, attributes which give it support amongst people such as vocal blogger-developers (not necessarily the people who get the most done) who are credible proponents. Compare to java or C# whose main proponents have a commercial interest and as such have such devalued words that they can't credibly make any positive assertions about their products, and being commercial there are any number of detractors.

People often say google use it a lot, the 'language of google', so it must be good. Now I suspect google use it a lot, but probably mainly for scripting and web programming. Remembering that

  • as a replacement for shell scripting (truely awful for significant development) python is infinitely better
  • web development and even the frameworks are not that complex

My experience is that dynamic languages are less maintainable, and not very good for 'systems' programming and dealing with complexity. The evidence is in the lack of sophisticated and successful programs. For example eclipse and its brethren. I am not convinced that it is feasible to create as sophisticated a framework in a dynamic language (if so, which ones?). Here checkable interfaces are an indispensable part of a self documenting, yet organically grown module structure.

Another example might be games. I think performance is an issue, but its also maintainability.

So the main issue for me is the dynamic typing, cited as a feature, but in reality just a really easy way to implement a language (I maintain a JS interpreter). Its definitely good for scripting, but if you could have type inference you would.

static typing is meta information, its like html vs. plain text, and when you've used a decent specialist IDE (eclipse, netbeans, vs.net - not emacs which is general) you will appreciate this, as you will be able to navigate your code, see compile errors immediately. Combined these are a massive productivity gain, albeit with an extra learning curve, that is completely unavailble in python.

I am far from an expert at python, but I have done a couple of semi-serious projects in the language and will try to recall specifically what I didn't like, aside from the general to all popular dynamic scripting languages weakness, the of lacking any static typing (not necessarily mutually exclusive with duck typing).

  • save on typing library naming mentality, I personally think the fully qualified (com.sun.xxx) package names are a good thing, as they contain a lot of information. Spending time typing them is not an issue for most java/c# developers. This makes it harder to know the provenance of code, and causes name space clashes
  • installation mentality, python has inherited the idea that libraries should be installed, so it infact is designed to work inside unix package management, which basically contains a fair amount of baggage (library version issues) and reduced portability. Of course it must be possible to package libraries with your application, but its not conventional.
  • quite quirky e.g. __init__
  • doesn't perform all that well
  • no switch (why not??)
  • poor utf support
  • no outstanding feature (that I know of). closures and duck typing (all objects are hashes) are just dynamic language bread and butter.

Lack of static typing results in

  • reduced maintainability, different developers will find it harder to work with each others code -> reduced productivity as projects scale*
  • less informative api documentation/autodocs
  • much less powerful ide support

*I feel these assertions are confirmed by looking at what complex projects are out there.

At the end of the day I wouldn't consider it for more significant/complex projects, however by all means learn it, but you may be disappointed if you have exagerated expectations of how good python is.

mike g
There's plenty of complex projects in Common Lisp, a dynamically typed language. Obviously, if you look at mainstream products you'll see that they're mostly mainstream.
David Thornley
__init__ might sound quirky but it's actually much more "pure" than "specialized" constructors: it's just a function.
This answer really nails it for me, having worked with several languages on large projects, including Python). It's a great language for whipping up small apps, but I concur that it quickly becomes less productive for more complex/large apps for all the reasons mentioned above (I find Ruby has similar issues too). My least favorite Python quirk has to be the way division is implemented...
I love python but it was a please for me to give this its 25th upvote because it is a GREAT answer.
+1 A great response, well thought out and delivered. Despite the fact I love Python.
Tom Leys
python package management doesn't have anything to do with or depend upon unix package managers (e.g. dpkg or rpm). Python's package management tools, like easy_install and virtualenv work in windows or *nix. And, using viritualenv, for example, it's quite possible "to package libraries with your application" and it's also a very conventional practice in the python world. I'd agree about the "installation mentality", but given that it's quite possible to avoid portability and library version problems with existing python package management tools, can you explain why that's bad?
re: the age-old static v. dynamic debate, I think we should quantify what we mean when we say "large", "or "complex" projects. I've worked on python projects that were several hundred thousand LOC. The equivalent Java version would probably have been 1.5x bigger. Do you only get to "complex" when you pass 1 mill LOC? Anyway, I'd recommend a blog post by Steve Yegge: http://steve-yegge.blogspot.com/2008/06/rhinos-and-tigers.html scroll down to the "Static Typing's Paper Tigers" section and give it a read. He makes some good points.
Miss switch? Use a dict with callable values.
@mazelife - dependencies: I probably ought to defer to your experience in these matters, but I do have experience and strong opinions on dependency management in general. Possibility of a decent environment (i.e sanely handle all dependency eventualities) was never disputed, but I am still not convinced the situation is great.Python suffers from it's lack of backwards compatability and this complicates matters. easy_install and virtualenv are both python programs which install themselves (the mentality again) in the shared environment.
mike g
Personally I feel they should both have bitten the bullet and delivered themselves as complete programs (including the python runtime) instead. Then they could even manage the installed python versions (possibly in concert with the underlying packaging system).
mike g
@mazelife - static vs dynamic: I took an outsider view on what is achievable by looking at what has been achieved (taking into account access to resources/community size), which you left unaddressed. Size is a poor metric, really the question is the nature of the program. In a project of the size you describe, a pure Java approach would usually be a mistake. Breaking the program up into a core part in Java + one or more DSLs (for repeated patterns) would be a better comparison (and closer to what is actually done when tools are used correctly).
mike g
If there are no repeated patterns and it is all system code (which I doubt) then I'd maintain that you'd be better of with more lines of Java. In any case lines of Java are not generally 100% typed out (autocomplete,wizards ... etc.) and most of the extra ones take up space but not brainpower. No I don't think java is perfect (lack of convenient multiple dispatch, no attempt at type inference ...), but to my mind it shares better.
mike g
@delty: Yes, but some syntax to hide this would be nice.
mike g
And of course they are not directly comparable. A default case would be the most often missed feature and sometimes falling through is useful. All possible of course, but creating variables to do control flow is not quite right.
mike g
For a default case you can use dict.get(key, defaultfunc)(). Personally I don't miss the syntax, despite using it a fair bit when writing C. I think I just switch (heh) to "Python mode" and don't even notice the differences, if you know what I mean.
Point 1: Fully qualified names are supported in Python just not used much because of the decentralized nature of library develpment in Python. Point 2: Installation is as simple as getting pip and typing sudo pip <packagename> package info can be found on PYPI and it's pretty easy to submit your own projects to PYPI. Package revisions are simple, when you submit a new version the index uses that as the default. Python maintains all installed versions of a library. Point 3: __init__ for the constructor is different but no more quirky than the alternatives.
Evan Plaice
Point 4: According to what. I don't see a benchmark. Python is a 'glue' language, that's why it's so easy to call c or c++ code using it. Point 5: You can accomplish the same with a Dictionary. Point 6: Python3k is all UTF all the time. Python actually has some of the best UTF encoding support of all the languages. Most languages just ignore UTF and use ASCII. Point 7: What about slices, tuples, and multiple return values? Point 8: Reduced maintainability is pure BS, python is one of the, if not, the easiest language to read. Point 9: Docs are a weak point. Point 10: I agree fully
Evan Plaice
A switch is only useful in low level languages where it acts as a data structure (because it's too much work to write the structure in that language), say for a finite state machine. In Python, we make a dict for this. I'd have to agree with fully qualified package names though.

Python is not backwards compatible with previous version. This means the person running the scripts must have the correct version installed. If you have the latest version, you may need to uninstall it and install an older version for some scripts to work. It's quite silly.

Joe Philllips
All versions of Python 2.x are backwards compatible with previous versions. It's Python 3.0 where the compatibility breaks.
+3  A: 

I'm only going to list negative things here, as that's what the OP asked for. Of course there are also many great things about Python :-)

  • Can't pass parameters by reference (The canonical example, you can't write a method that swaps the values of 2 parameters. You have to return a tuple instead).

  • Python 3 breaks backward compatibility

  • You can easily, accidentally, over-write system variables with anything else.

For example, type:

time.sleep = 4

instead of:


and you just destroyed the system-wide sleep function with a trivial typo. Now consider accidentally assigning some method to time.sleep, and you won't even get a runtime error- just very hard to trace behavior. And sleep is only one example, it's just as easy to override ANYTHING.

  • Lacking support for interfaces, method requirements defined in terms of ambiguous "X-like-object". This is getting better with Python 3, but the new ideas in Python 3 will take a long time to catch on.

  • If you define 2 classes\methods with the same name at the same scope, the latter silently hides the former. This can lead to insane new classes of bugs. Speaking from experience here :-)

  • Explicit "self" is an annoyance.

  • Every object is automatically convertible to Boolean, and it is idiomatic to use this feature often, such as doing if(L), where L is actually a list and you're asking if it has items. Doing this in a low-level language like C is one thing, doing it in Python is... confusing. Is L a boolean? a list? a number? Why not just ask if L "has_items"?

Roy Peled
@Roy: with great power comes greater responsibility :)
actually I found overwriting names to be quite powerful and sometimes useful. And well, of course, you have to be responsible for what you do.
same; once you use it you'll appreciate it :)
@elo80ka-"with great power comes greater responsibility" is my favorite quote about this topic. In programming, "responsibility" grows exponentially in regards to "power". The conclusion is that you should try to limit power to the minimal, so you have less things to worry about, and to minimize risks.That's why you don't login as "root" for everyday work, but as a LESS POWERFUL user, and that's why overriding a system method should not have the same syntax as trivial variable assignment.
Roy Peled
Global overwriting has some wonderful benefits as well... like in testing where time.time = some_fake_time_function is very helpful.
Gregg Lind

As a long-time PHP user, I did notice the following issues when I started using Python:

  • Because everything goes into one namespace (functions, classes, global variables, local variables, even imported modules), you can accidentally replace a class or function with anything else really easily. In my first month I created some variables named 'min' and 'max' not realizing I was replacing the builtin min() and max() functions.

  • It's alot harder to make a string from local variables. You have to use the printf() notation which is usually not easier but sometimes quite longer to write.

too much php
@Peter: one global namespace? Not true - packages, modules, classes and functions all define their own namespaces. See http://www.network-theory.co.uk/docs/pytut/PythonScopesandNameSpaces.html for more info.
If you don't know about min() and max() means you won't use it anyway.
What I meant was, in PHP functions, classes and variables cannot possibly overwrite each other because they are stored in different tables and accessed in different ways, and once they are defined they are immutable.
too much php
in re. second comment, are you referring to http://docs.python.org/library/stdtypes.html#string-formatting? If you're looking for templating there's Jinja 2 and Cheetah.
as far as overriding builtins, it might help to use an editor with syntax highlighting. I like kate, but of course everyone has their favorite. Python is widespread enough you should be able to find one. cheers, Nicholas
Yes, the '%' operator is not as simple to use as PHP's.
too much php
  • If you make a typo your app will run to the place of the typo then crash (some IDEs will catch this thankfully)
  • Threads are not good ATM
  • Missing features people may call essential (switch and enums are essential for me)
  • Very hard to debug. Maybe its my IDE but i havent found a good solution. This current IDE breaks in the main .py file but not in others

I'll have more reasons when i have more experience.

+1  A: 

I love Python but some things bug me after doing mostly C# development:


    print 'You entered an invalid number.'

Oops, my typo has become a runtime error, and I've hidden it with the try/except block. That wouldn't be a huge problem if my IDE caught this for me, but...

2) There's decent IDE support, but nothing I like nearly as much as Visual Studio with Resharper.

3) Generators feel like a half-assed version of LINQ.

4) Passing self everywhere makes writing objects feel like a hack.

5) When I go back to C# I forget to put parentheses around my conditionals.

Python is a beautiful language, and it's worth learning despite it's flaws.

You should never EVER use naked except!
Same, and dynamic name resolution can be quite powerful! use it :)
+3  A: 

Sure. It will spoil you so hard that you will have a very miserable time if you have to go back to your previous language, be it Java or C# or something else. So don't do it! I warned you!

yea, it spoils really bad!
You are my hero.

I think the only reason not to learn any language is if you know something similar, or you don't have enough time. In the free software world, I don't think there's anything quite like python (in that it has such a nice standard library, readability, extremely simple grammar -- esp. with 3.0, expressiveness, etc.).

While I don't advocate looking for reasons not to learn it, here are my bad experiences:

  • Python MT support is not as good as it should be.
    I tried to write a simple multi-threaded image loader, and found that I occasionally got fatal errors "GC object already tracked" as well as problems during interpreter shutdown, where the main thread would exit and modules would go as well even if other threads were using them. There's also the GIL, as others mentioned.

    Even if the language is still very useful, these issues (sans GIL, that's just annoyance, and Cython has a nogil construct) just makes the language not seem mature, which is a major issue of faith for me. Imagine Java not implementing the synchronized keyword correctly.
  • Garbage collection doesn't handle circular references.
    I want objects to be deleted when the main thread's locals() and globals() lose reference to the object. Occasionally this needs to happen at a certain point for correctness, not just efficiency (pycuda API calls for me). I would like [at least a per-class option] to have exceptions thrown on circular references [which don't use weakrefs] than have memory leaks and correctness issues.
  • Local and global scopes are unintuitive.
    Having variables leak after a for-loop can definitely be confusing. Make sure to name variables well! List constructs in Py3k operate within their own scopes. Worse, binding of loop indices can be very confusing; e.g. "for a in list: result.append(lambda: fcn(a))" probably won't do what you think it would.
  • It's not incredibly slow, but it doesn't have the latest-greatest optimizations in cPython (the default interpreter), like some of the dynamic optimization in the latest web browsers for Javascript. Learning Cython and C extensions takes time.
  • Imports are nice in that they're dynamic, but also haphazard
    Circular imports take some time to get right. I don't think practical code should be forced to be hierarchical: breaking things out into modules should be encouraged as much as possible.


  1. Not as fast as C/C++, Java, or even PHP.
  2. Everything you write will be open source.
  3. No great IDE's. I'm using KATE to write Python.
  4. Somewhat annoying portability if you use non-standard modules.


  1. Very easy to write applications
  2. You don't have to worry about compiling.
  3. You can make great use of IDLE to test drive your solutions.
  4. Your applications will be very stable without any effort!
How can Python be slower than Java or even PHP? Where did you get that bencmark from?
@jpartogi The highly technical and accurate 'Texas Profiler.' Take a male cow (preferably a large one for better accuracy) insert large amounts of hay, and eventually you'll have a fantastic pile of steaming results.
Evan Plaice
+17  A: 

It has a lot of WTFs:

print x   # does one thing
print x,  # does another

x = "hello everybody"
s = x.split(" ")  # does what you would expect
y = s.join(" ")   # does NOT do what you would expect

import re
x = "The sky is red"
r = re.compile("red")
x.sub(r, "blue")  # oops, that causes an error
r.sub(x, "blue")  # there, that should do it
print x           # prints "The sky is red" -- what!?
y = r.sub(x, "blue")  # maybe that will do it
print y               # nope, now it just prints "blue"

referrer = "http://foobar.com"
if override():
    referer = "overridden"
print "Referrer: " + referrer
# Do you see the bug?
# There was a typo in a variable name.
# No warning. No error.
# Because you can't enforce variable predeclaration.
Most of the WTFs of print are fixed int Python 3.x
Really? Which ones?
As for - x = "hello everybody" wtf, x is a string, so we have x.split(), drawing an analogy, I would expect a string to have a join() member function, so a " ".join(s) would make sense. Since join() and split() seem to go together, why should one of them reside in string and the other in a list, not so much of a WTF.
Abhishek Mishra
Interactive programming using the python console will quickly teach you what to expect from python, including all your examples. To try all this in the console will take you less time than setting up a project in many other languages.
Tom Leys
I like this concept of WTFs. I think anyone getting started with a new language should look at those lists for a big head start!
well if you care to do `re.sub('red', 'blue', 'The sky is red')` there will be no WTF. I understand you may not remember order of params but can you tell me with straight face you expect "import re" to add method sub to str (x.sub attempt) or that you expect r.sub(x, "blue") to be destructive (print x)? I agree re join - logically should have been `list.join(str)` but i guess both split and join were considered utility string functions and hence shoehorned to fit
Nas Banov

If you are a programmer charging by the hour, you SHOULD NOT use Python, because it ensures you won't be able to charge your customer much.

When using Python I almost always find myself finishing a project earlier than expected, which is the exact opposite of when I use other languages where I ALWAYS take more time than expected.


Aside from the fact that like all languauges, Pyhon as gotchas as quirks that could be easily defined as something that does not behave as it does in xxx, where xxx is some other language the write is familiar with, Python does have a few painful points, mostly related to the libraries than to the language itself. In my experience they are:

  1. Deployement: There are four, five different third-party libraries that should help you with that, and each of them sucks in different ways. Unless your deployment is limited to workstations with the right version of python with the right version of all the needed libraries already installed, packaging your application in a self-contained distributable will eat up as much time as the rest of the development did.

  2. GUI toolkits: many options, none of which is fantastic: Tkinter (part of the standard library, gets the job done, but it's ugly to look at and to work with), pygtk (which is fine if you're targeting X11 platforms, but becomes painful for everything else), pyqt (peculiar licensing arrangements, and the clear feeling that you're writing C++ without the braces), WxWidgets (Well, I gave up after a couple of crashes).

  3. Memory consumption: technically, you cannot speak of memory leak, but the effect can be similar: it's not the system that leaks memory, it's you the programmer that forget variables that still have a reference, because that stack frame is still in use even if the variable is not. Typically, somewhere in a callback you still have a reference to a dict with a reference to some other variable that you forgot about and that cannot be garbage collected and you end up with hundreds of megabytes per process. Also, CPU profiling is decent, RAM profiling is halfway between impossible and non-existent.

Christopher W. Allen-Poole
I really wish that people had to give comments about down-votes. I stand by everything I've said and feel that it is all worth saying.
Christopher W. Allen-Poole

Python is slow. very slow. And I am not comparing it with C or other compiled languages or statically typed languages. Python is slow even compared with other interpretive or dynamically typed languages.

Python is touted as a very powerful and advanced language, and indeed it is. Advanced but slow? It does not make sense to me.

+2  A: 

Python isn't the best option for proprietary applications/libraries.

Python third-party library licensing is very liberal and overly complex

Most of the libraries not included in the core fall under open source licenses. Licenses like MIT or, as I like to call them, 'truly free' licenses allow you to create derived works without limitation as long as you maintain attrubution; GNU GPL, or other 'copyleft' licenses don't allow derived works without inheriting the same license (viral licensing). To inherit the benefits of an open source culture you also inherit the complexities of the licensing cluster%&*#

Python's OOP structure isn't strict enough

The notion of private/internal/public isn't nearly as well defined in python as it is in the statically typed languages (C#/Java). In statically typed languages, when linking between libraries/classes the rules for such interactions are very strict, mostly for security purposes. There may be some very important instances where a business wouldn't want anybody to see the internal implementation of their modules and having such strict control over levels of access are necessary.

Python GUIs suck

Not to say that there aren't any good options. wxWidgets and Glade are great options. You just won't find the same level of ease in GUI development that you'd find in Visual Studio or Eclipse. When it comes to GUI development a drag-and-drop idiot-proof IDE can be an essential requirement. The reason you probably don't see a lot of massive python apps with GUIs is, it's easier to create front-ends in other languages.

The Python language itself is in a transition

Sure, there are thousands of awesome libraries. I'd be willing to bet that Python will eventually replace PHP for server-side scripting and it's already taking steps in that direction (see WSGI, Pylons, PyHP, Django, mod_python, etc...) but the core is in a transition period. The core development team has put tons of time and effort to revise the language as a whole and eliminate a lot of the long-standing WTFs of the language itself. Right now there's Py2x (making up most of the written libraries in the wild) and Py3x representing the new version of the language with all of the great new fixes. Most serious library developers have conservative estimates that the language itself won't make a full transition to py3x for years. Mostly because 2x works really well as is and all of the the third-party libraries already support it. If you're expecting to use a lot of third-party libraries learn 2x first, OTOH if you're just getting your feet wet start with 3x.

Developing in Python on Windows can be a pain

If you've never used linux, concepts like the PYPI package repository probably don't make much sense. What does that mean? In linux lets say you wanted to download the wxPython library for GUI development, you'd just go to the package manager search for wxpython, select the package and hit install. In windows, you could check the PYPI (Python Package Index) but there's no guarantee that there will be an .exe installer included in the project. Getting a handle on acquiring third-party modules can be a little confusing at first but that's the open source nature of Python. I submitted a module called pypreprocessor to the PYPI a week ago (after taking a few hours to figure out how package submission works) and it's already nearing 100 downloads on PYPI alone. Hopefully, the up-and-coming release of distuils2 will make it even easier to submit/acquire packages.

Rant: Open Source projects generally don't care about Windows, most open source developers work in linux because Windows sucks to develop on. Any platform that requires an antivirus application to periodically break your mode of concentration to nag about updates is unacceptible.

Other notes about migrating from another language

If you have never used python, first make sure tabs are converted to spaces (4 spaces) in your editor. Tabs are bad because they aren't standard across text editors; meaning, if you open a source module in another editor it might break your code.

There are a lot of options for everything. This is a positive and a negative. Too much choice can be daunting and multiple implementations of similar libraries mean that the development effort isn't concentrated in one place. In such an environment documentation and/or stability can be lacking; it's pretty common among open source development. Of course, if you don't like the implementation you're using, there'll usually be a viable alternative.

Some code features of Python may seem like voodoo. Once you understand some of the core features like slices you'll wonder how you ever lived without them but they can look strange at first. It's amazing how much can be done in python with very little code but it takes a little time to adjust.

Collections like lists, tuples (immutable lists), and dictionaries are used everywhere in python code. Without the limitations of strong typing, lists inherently become really flexible and versatile tools. It might take a little time to adjust to the style.

There is no single 'mega library' like C#/Java. While Python touts it's 'batteries included' philosophy, it'll still take a little time to figure out what libraries to import for certain specific situations.

There are multiple ways to import modules:

  • import module - to access the members of module all of the calls need to be prefixed with module's name (ex. module.example_method).
  • from module import * - this imports all of the imported module's members into the current module. This would make it so you could call 'example_method' directly without the 'module.' prefix. This practice is looked down upon though because of the obvious name collision implications and difficulty to track errors.
  • import module as somethingelse - this essentially renames the module. to call the 'example_method' call 'somethingelse.example_method'

It's generally best to use the standard import unless you have a compelling reason to use one of the other imports. Performance considerations of imports are generally negligent because python actively caches everything that's imported.

Personally I love coding in python. It isn't perfect but it's damn good. After coding in C# for a year and a half, the style of python was like a breath of fresh air. It is really a fun language to code in. It's ironic that, even though python has a slightly unique syntax, the biggest issues with the language itself are mostly political/social. I guess I'm supposed to convince you not to try it. Hopefully my suggestions will be enough to scare you away. Otherwise, you might become a raging, monkey patching, duck punching, python evangelist like the rest of us.

Evan Plaice