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.

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.

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.

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.

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

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.

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.

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.

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.

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.

I have some points in the answer to Five things you hate about your favorite language ^[1]. 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.

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

NOTE

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.

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.

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!

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 ():
  falkdfjlkdfj

print "Hello World\n"
dog()

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

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.

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:

time.sleep(4)

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"?

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.

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

The only problems I have with python is that strings are immutable so running this would throw an error:

a = 'A string'
a[0] = 'B'

And because there are no semicolons it's sensitive to indention so your code will act strange if you don't indent it properly. Other than that I love it!

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.

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.

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 :-)

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 ^[1]. 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".

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

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.

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

1)

try: 
    prase(getUserInput())
except: 
    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.

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.

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.

I've just started using Python and I have to say that my overall impression is a good one: Python does a lot of things which make sense.

That said, there are some things which need to be said:

• Forced spacing should be considered a non-issue. If you are formatting your code correctly to begin with, you will be doing this anyway, and it will also ensure a uniformity to code structure
• The lack of switch is irrelevant because elif can accomplish the same effects.

As to the real cons:

• There is no way to type *any* variables. This includes function parameters. To me, this is a big issue because you are in a constant state of uncertainty about the nature of what is coming into the function.
• There are no truly private variables.
• There is not a lot real documentation on the most recent version of Python. Nor does it appear that there is any quick adoption of Python 3. This would not be an issue if Python 3 were backwards compatible, but it isn't.
• There isn't a true multi-line comment syntax save creation of multi-line str's
• Static variables are present on instances of a function. EG:

    class Foo:
        myStaticVar = 7;

    f = Foo();
    print( f.myStaticVar ); # prints 7

Look at slices; in python the statement:

X = y[2:4]

Assigns a 2 element sequence to x containing the values of x[2] and x[3]. Now someone compare that against other languages that support slices, e.g. Ada, Occam etc, and explain to me how that could possibly make sense. Programming is generally a logic-related task; those semantics are completely illogical.

Concurrency is 'appended' on like most traditional languages instead of built into the language design. As a result there is little to no in-built support for determinancy like the Ada language has.

Immature support for compilation of native code 'executables'.

Python doesn't natively support backtracking ^[1] (not many traditional languages do) which is the basis of the logic programming paradigm. Also it cannot manipulate it's abstract syntax tree like Lisp can with it's macros.

Defining low level data types like a c-struct is a mess compared to say C. Also doesn't support inline assembly coding.

Python is revolutionary in it's own way but it can't do everything. There are many reasons to use Python but also there are reasons to not use it. It's not perfect like everyone likes to claim it to be but it's a step in that direction.

Due to it's inherent imperfections it may in time turn out to be just another trend language as better languages are developed.

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?

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 ():
  falkdfjlkdfj

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?

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

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.

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.

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.

Cons

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.

Pros

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!

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!

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.