- 64 bit issue is going to be the same for all languages. Twice the pointer size, twice the data size (unless you're using a very specific type)
- No code generators? You could complain that they're not good enough, don't support some specific extensions, don't play nice with threading, or something else, but there are many versions of python which work as compilers. Just google a bit.
- Lack of type safety is there by design. If you want type checking, why are you even looking at duck-typed scripting languages? It's a basic design decision, not something that could be changed / improved.
- Why is whitespace even an issue in patches? If anyone submits a patch, they should use exactly the same style as the rest of the file. If they don't, patch should be rejected. The same thing happens in projects where indentation doesn't really matter. Also, it's hard to "silently" screw up code covered by tests. Any big enough project should have those...
The 64 bit issue is definitely not the "same for all languages". Programs get slightly bigger, but don't double in size as happens for Python programs. Most Linux 64 bit C programs will be using 32 bit 'int'. Python consumes 24 bytes to store any single int on 64 bit.
Code generators: I mean ones which anyone uses.
Lack of type safety: it may well be "by design", but it's a dumb design which causes lots of problems. Search Bugzilla for Python tracebacks and you'll see hundreds of bugs caused by lack of basic compile-time type checks. It's easy for a compiler to check that a function you're calling requires 3 arguments of type foo, bar and baz, and not doing that simply causes lots of errors.
The whitespace issue is also real: if/else changes its meaning completely if you're not hyper-careful about how you apply patches (especially when you have to make manual fixes to patches to get them to apply).
Those two implementations don't have to have the same types, can accept any number of parameters, can be wrapped in something else, etc. etc. Compiler cannot figure it out ahead of time.
On the other hand, it opens a lot of new possibilities that are not available in compile-time type checks. For example mocking objects in other modules:
Whether it introduces other bugs is a different discussion... Sure, it's worse than Haskell where things tend to work the first time they compile, but on the other hand I get more annoyance from Java-style types than they're worth in practice. YMMV
I've been doing python and ruby full time for the past 8 years. In that time I can count on one hand the number of bugs which got into production because of a lack of static typing. The gain in productivity from using dynamic languages in that time far far exceeds the cost of those few bugs.
Different types of software have different needs and we shouldn't generalize about all software development based on our particular niche. Writing code that runs on other peoples systems is much harder than writing code that will run on servers I control. Python and ruby are great for the latter. I've never done the former at the scale of redhat.
Writing code with a lot of collaborators is harder than writing it with a few collaborators.
What language do you prefer for your type of work?
you don't get more bugs in python vs statically typed languages, you just get different types of bugs
also - there are code parsers like pylint that help you sanity check your source code in that manner.
speed - python is slow. We use python in scientific computing in extremely CPU intensive problems because python makes it very easy to control C and C++ layers that do the underlying work. that power in an interactive environment, complete with good visualization tools is great for science
I'm a huge proponent of dynamic typing, but I don't think your statement about bugs is true.
If I typo something in ruby, I will not know unless that code path gets executed through a test. This would never happen in a statically typed language.
However I think the productivity benefits of dynamic typing far outweighs this risk in my experience.
To say that dynamic typing is dumb is rather misguided. I mean you may not like it, but it is very powerful, and a lot of languages are based on this principle (not just python and ruby).
The argument that there are hundreds of bugs because of it does not mean anything - you make the wrong assumption that everyhing else is equal. Of course, if dynamic typing was only about not checking types, it would be dumb. But it also gives you flexibility and avoids a lot whole lot of other kind of bugs, so you are trading one kind of bugs with another kind. For me, complaining about dynamic typing is like saying that exception cause a lot of bugs compared to error codes, because your application crashes if you don't catch exception. It is true in some sense, but the argument is rather stupid.
As for memory consumption: running an application in 64 bits, even if programmed in C, often requires much more memory, at least statistically speaking and in my experience. For example, running a simple ubuntu desktop in 64 bits takes easily 50 % more memory than in 32 bits (and it is not because of python :) ). Int, floating points are indeed the same, but structures, pointers and alignement requirements almost inherently increase memory in a significant way.
The problem with Red Hat is it's stuck on Python 2.4. Altho' the hassle of persuading the SAs to install ActiveState too was what led me to OCaml, so it's not all bad :-D
... which is another saga. Python 3 is "close" but incompatible with Python 2.x, and the way around this is to have two installed copies of everything. Sheesh, brilliant plan.
(In case it's not obvious, I really dislike Python).
I'd like to have seen /usr/sbin/python (this is the one the OS uses itself) and /usr/bin/python (this one's for users). So you could patch them independently without straying outside of "official" RPMs.
Not that I'm aware of. In practice we leave /usr/bin/python untouched (on 2.4) and install ActivePython in /opt. That makes the estate slightly less manageable because now Red Hat isn't doing all the integration and maintenance for us (and RH costs a fortune, as in more than Windows) but what can you do? People want to use 2.6 features at the very minimum.
I really like python, and FWIW, I find the whole python 3 saga a disaster. The small improvements really did not justify breaking backward compatibility.
- generally poor choices for implementation: inefficient storage of values
- 64 bit version approximately doubles the size of all data
- interpreted, no code generator so it's very slow
- lack of type safety is a constant source of bugs that just wouldn't appear in other languages
- whitespace layout screws up patches silently
Edit: don't downvote, comment on what I have to say.