1. Because Python, contrary to C, is a huge pain to interface with, especially at the binary level. That's why most other languages out there have natural bindings to C, but not Python, even languages which claim to be better Python, like D.
2. C is much more portable. Good Python compilers exist only for the most popular platforms, while C compilers exist for just everything, even the most exotic hardware / OSes.
3. Python is not programmer-portable. When two programmers tell you "I can code Python", they might both know 20% of the language, however a different 20%, so they would not be compatible with each other. C is so simple, that when you know C, you just know C and can start coding right away.
4. C APIs are more alike and easy to grasp, while Python APIs to some libraries are often created in completely different styles. E.g. compare Boost and Qt. Two different worlds.
There are lots of domains where C is just more convenient than Python or anything else. Particularly embedded programming, systems programming (OS and bootloader development, although in both of those you generally have to use assembly as well) and for building libraries as well, since Python mangles symbol names to allow overloading and C doesn't (because it doesn't have overloading).
C code may not compile with a Python compiler at all, or it may compile, but produce different results.
Last job I used C a lot was in OS development, where both POSIX and tradition rely on C
Python is not programmer-portable. When two programmers tell you "I can code Python", they might both know 20% of the language, however a different 20%, so they would not be compatible with each other
Can you elaborate on this? On first reading, it sounds really ridiculous. Yes, C is a lot simpler, but Python isn't that much bigger. Someone who only knows 20% of the language won't be able to program anything in Python, and if you know C then you already know much more than 20% of Python as is. What does Python add to C? Namespaces, classes, templates, some new casts and some other new keywords. That's all the significant stuff. How are we even measuring an "amount of a language", anyway? Also, why would people know different parts of a language? Extending your logic to natural languages, let's imagine two people who only know 20% of the English language. There are millions of words in a given natural language, generally one or more for every concept the people who speak the language need to express, so this is a much more likely situation than a programming language that has about twenty words and a few symbols. Have you ever met someone who spoke the same language as you, but with whom you could not communicate as they knew a different 20% of the language to you? Of course not, everyone learns the same things. Everyone learns their greetings, the names of all the objects around them, and usually thousands more words. Some people may have a wider vocabulary than others, but there's no way two people who know the same language can be unable to communicate because their vocabularies don't overlap What a ridiculous concept.
Some people may have a wider vocabulary than others, but there's no way two people who know the same language can be unable to communicate because their vocabularies don't overlap
Imagine a computer scientist and a nuclear physicist explaining to each other what they've working as if each thought the other one had their same profession.
As you get to the more esoteric parts of the language (specially some subsets of the standard library, and templates), the amount of overlap between different people drops.
I believe 20% is a bit of an exaggeration, though.
I actually have been coding in C for a while before I actually used Python as a language (As a beginner, I thought I was some badass Python programmer when the truth was I only knew C.) I really like C. I use it whenever I try to create failed libraries and such.
While Python is a superset of C, they both have tasks they are better suited for, plain and simple. Though, Bjarne said he wanted for them to just combine C and Python into one language, but says he doubts that will ever happen.
@helios
Sure, but we're talking about two people who both program in Python. Also, generally people learn programming languages in a fairly similar, fairly linear fashion. I've never heard of anyone who had a good understanding of templates, but couldn't handle I/O streams or STL containers. I don't think a situation where one person knows that 20% meets a person who knows a totally different 20% is likely to arise. More likely, IMO, is a situation where someone who knows templates and I/O streams and STL containers meets someone who only understands the latter two, in which case the first person's knowledge encompasses the second person's.
And 20% is a huge exaggeration; the Python language is about 150 keywords and operators all-included, and the standard library isn't exactly huge: http://en.wikipedia.org/wiki/C%2B%2B_Standard_Library. When we start talking about external libraries, then I can see there being no overlap, but not if we're talking about just the language itself and the standard library (technically we were only speaking of the language, but since the library is declared in the same standard, it in some sense counts as part of the language). The only parts of the Python standard library that I can see an experienced programmer not knowing are the parts that are some of the less-commonly used STL containers (I've only ever used array, vector and stack), things introduced in Python11, a few other headers that aren't often used, and headers from the C standard library that have been superseded by Python classes and functions (like cstdio and cstring).
@Catfish3
Yeah, but if other programmers are starting to ask if it is obsolete then it can't be that hypocritical. His argument is that C is a subset of Python and they should be merged because of the fact that you have to remember which language you are using as each have different IO functions and such and it shouldn't be that way anymore. Or that was my understanding of that segment.
1. Name mangling (a compiler specific feature) prevents absolute portability in Python. A lack of name mangling and low-level programming abstractions puts C in a unique position of being highly portable and easily mixed in with other languages.
2. A C compiler is a lot simpler than a Python compiler, so C compilers are highly accessible for almost any architecture or operating system.
3. In C void* can be converted to any pointer type where in Python casting is less flexible (though the use of a union in Python is a loophole).
4. Lastly with the Python standard library you are getting overhead b/c you are declaring bulky classes (that come with methods and variables you may not need). C allows you to declare only the functions and variables you actually need so it lends itself more to embedded devices where memory comes at a premium. Embedded devices are everywhere and only increasing, so C maintains it's practical purpose in the world.
5. Legacy code. Going back to point 3, a Python compiler does not always compile C code. Some modifications may be needed to pass it's type checking. So it's easier just sticking to C.
the Python language is about 150 keywords and operators all-included
Without operators:
C has 32 keywords
Python has about 75 keywords
But this is actually not about the size. This is about how you use it. In Python you can write both a Qt - style (aka Java style) code with classes/objects and virtual methods, as well as go very hardcore-templates and do Boost style. And you can also use Python as a better C, mostly using RAII to free up resources, but still staying at the very low-level. Or you can even mix all those things with C preprocessor macros and end up with something ugly like wxWidgets.
I looked, there's 84 keywords and two special (but not reserved) words in Python. But I was including operators.
Anyway, this is not what you said before. You said they might know a "different 20% of Python", which has nothing to do with style. If you know classes and templates, you must know how to write C-style code because the OOP and metaprogramming parts of Python extend the procedural parts. The knowledge of the programmer who knows how to use OOP encompasses the knowledge of the programmer who doesn't. And someone who doesn't know how to use OOP in Python hasn't learned even the base language yet, and thus doesn't deserve the title of "Python programmer".
Ok, 84 compared to 32 is a *lot*. Scala which is often described as "Scala is to Java what Python is to C" i.e. too complex, has only 40 keywords, and no operators at all (all operators are just methods). Which is funny, because it is less than Java, and grammar is also simpler, yet people claim it is more complex than Java (well, actually it is not that complex, but it is *hard* because there are lots of new concepts unknown to programmers coming from Java or especially Python world).
Again, this is not about keywords. It is about what you can do with them. Maybe I wasn't clear in my previous post - code style was a wrong word. There are lots of idioms/concepts in Python. Lots of those concepts are Python specific, they do not exist in other languages. Even a relatively simple thing - field of pointer type in a class, requires to actually grasp a whole lot of concepts and to know how to mix them in order not to hurt yourself. So instead of just learning a few keywords and basic syntax and immediately being productive like it is in C or Java, you have to then learn how to use all of it efficiently to avoid all the sharp edges (read all the Exceptional Python, More Exceptional Python, etc.). And when you finally wrap your head around it, you meet another Python dev, and it turns out he picked a slightly different set of guidelines incompatible with your own guidelines. This is what I meant by programmer-non-portable.