Python in a Nutshell 246
| Python in a Nutshell | |
| author | Alex Martelli |
| pages | 636 pages |
| publisher | O'Reilly |
| rating | Excellent, superb, 5 stars |
| reviewer | Ron Stephens |
| ISBN | 0596001886 |
| summary | Complete reference book for the Python programming language |
Written by my favorite author and Pythonista, Alex Martelli, this book manages to fill three roles in extremely pleasing fashion. First and foremost to me, it is a great read, straight through. Mr. Martelli's prose is always sparkling and always keeps the reader interested. No matter how many Python books you have read, you will learn some nuances from this book, and it is about the best review of the whole Pythonic subject matter that I can imagine. While there is absolutely no fluff whatsoever in these 636 pages, it still makes for rather easy reading because the explanations are so clearly thought out and explored as to lead one gently to understanding, without in any way being verbose. It is obvious that Alex Martelli took his time and put in sufficient thought, effort, and intellectual elbow-grease to make this work a classic for all time.
Secondly, this book is the ultimate Pythonic reference book, the best fit to this role I have yet seen. You will keep this book in the most cherished spot on your book shelf, or else right at your side on your computer desk, because you can almost instantly find any topic on which you need to brush up, in the midst of a programming project.
Third, Python in a Nutshell is the most up-to-date book on Python (as of April 2003) and includes the best and most complete expositions yet on the new features introduced in Python 2.2 and 2.3. These topics are not only covered in depth, they are integrated into the text in their proper positions and relationships to the language as a whole. They are explained better here than I have seen anywhere else, so much so as to make them not only understandable to me (a duffer), but indeed so that they appear seamlessly Pythonic, as if they had been a part of the language since version 1.0. Topics explored in depth include new style classes, static methods, class methods, nested scopes, iterators, generators, and new style division. List comprehensions are made not only comprehensible but indeed intuitive.
The book is surprisingly complete. It covers the core language as well as the most popular libraries and extension modules. It is difficult to choose any one portion of the book to highlight for extra praise, as all topics are treated so well. It is a complete book, the new definitive book about Python.
Everything about this book speaks of quality. In addition to the top notch writing and editing, O'Reilly really did the right thing and published this book printed on the highest quality paper, paper so thin that the 636 pages are encompassed in a book much thinner than one would expect for such a size, but strong enough to resist wear and tear. The text is most pleasing to the eye. Holding the book, and turning its pages, gives one a feeling of satisfaction.
Any job worth doing is worth doing well. Alex Martelli and O'Reilly have done justice to a topic dear to our hearts, the Python programming language. Perhaps, in years to come, the passage of time may make this book to be no longer the most up-to-date reference on the newest features added to Python. But time can not erase the quality craftsmanship and the shear joy of reading such a well thought out masterpiece of Pythonic literature.
You can purchase Python in a Nutshell from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page. Ron Stephens would also like you to check out Python City, with "27+ reviews of books about Python. 67+ links to online tutorials about Python and related subjects Daily newsfeed of Pythonic web articles, new sourceforge projects, etc."
Where's the review? (Score:5, Insightful)
Could the author please respond in this thread and give some examples of the new content, rather than just "covers it all"?
A (hopefully) unbiased opinion on Perl v. Python (Score:5, Insightful)
First of all, I don't want to offend anyone, but Perl really is an example of the most horrible way to design a language. I say "design" with tongue-in-cheek, because the language wasn't really designed so much as thrown together from pieces of odd scripting languages (many of which should have been put to rest long ago). The implementation itself is rather unfortunete; because of how it's built you can't really implement perl in terms of itself (well I suppose you could, but not with a slight measure of self-respect), the entire system needs to be scrutinized by security experts before any program written in Perl can be considered secure, and it is doubtful that Perl will ever be re-implemented ever again.
That being said, Perl is at least useful for many things ("practical," I believe it's called). People always tell me how they use it for system-administration tasks (for some reason I don't seem to engage in enough adminitration tasks to require perl's help, or if I do they're all suitibly mundane), and it does have an impressive ability to cope with string data (not something I'd base a language on, but at least it stopped people from using SNOBOL).
Now Python on the other hand is almost completely a different story. It's supremely orthagonal and elegant in its design, with support for functions as first-class types, an enforcement of clean coding standards through whitespace sensitivity (most Perl coders object vehemently to this because it infringes on their ability to write really ugly code), etc.
But the problem is that Python suffers from a lot of Perl's problems and adds a few of its own: you can't implement it in itself, it has no strong typing (even Perl's use strict is ridiculously better), an OO system with no support for data hiding, etc. etc. And that brings me to the biggest problem: Python doesn't really have a niche to fill. The CGI space has been seemingly co-opted completely by Perl (at least until people start using PHP), and it's too dog-slow to be used for real CS applications. As a beginner's language it's ideal, but that's not going to help it be taken seriously when it comes to real computing tasks.
If the python developers made some tweaks to the type system and added a real compiler, then I would advocate that most software engineering be moved there. As it stands it's an original language which is a lot of fun to program in, and still has lots of unmapped potential to it.
So where does that leave us, now that I've managed to piss EVERYBODY off? Well, I guess I conclude by saying that if you read this and got a sudden urge to throw a molotov cocktail through my window, then you're really taking one language too seriously. If you blind yourself so much that you can't see the faults in Perl or , then you're really no use to anyone in your community, in particular the users who depend on you to build solid, well-rounded applications. Don't be a Python zealot or a Perl zealot; be a programming zealot, learn as many languages as possible, and which one to use in a given situation. That's all I have to say.
Oh, well. (Score:5, Insightful)
636 PAGES.
This review is quite positive. I'm sure some faults could be found in this book, but suppose for a moment that I take your word for it and assume that this book is perfect. In such a case, I wish that more programming books would be published like this one.
I don't currently use Python in my work but I increasingly find that language reference and instruction books are either too darn complicated or too darn simple. You either have to be a complete idiot, who has never seen a computer, let alone programmed one, in order to read a book written for such idiots; or you have to be an unnaturally staid and steadfast compiler writer to understand the endless maze of technical details published into thick volumes intended for such stalwart masters.
I find that some of the slimmer, older volumes on C are written in a very readable fashion that require neither of the above virtues. However, newer books make the subject too complicated. Books on C++ are beyond help. Sometimes I wonder if our programming languages are much too complicated and perhaps should be reduced to a small number of basic elements, such elements being combined through the use of multiple languages in order to accomplish a specified goal. On the other hand, doing so will make development much too difficult. As such, it is up to the authors of explanatory volumes to make available a desired level of detail while keeping the material readable. It is this balance that I seek in programming books. Until then, well, I'll have to keep writing small "test" programs to probe the features of the language and of the compiler.
Oh yeah... and of course, I would like these volumes to be of allowable length for reading in an afternoon or so. 636 pages sounds like a good length.
Perl v. PHP (Score:2, Insightful)
what, PHP doesn't suffer from the same problems as perl? whitespace? data hiding? real objects?
people use these languages because the fluidity at which they can be written (albeit crappily). conversley, a good programmer will write good code regardless of the pro-active design constraints imposed by the language.
etc.
excellent troll btw!
O'Reilly's "Nutshell" books are their worst (Score:5, Insightful)
Learning Python was great, as was the Python Cookbook. They had something to offer beyond a documentation of Python features (an explanation and an exploration of them, respectively).
Unless you have no internet connection or just greatly prefer dead trees, I can't see why you'd get any of the "brown" books.
Has anyone here been pleased with O'Reilly & Associates' ever-present "... in a Nutshell" books? I'd be curious to hear what the appeal is.
Re:A (hopefully) unbiased opinion on Perl v. Pytho (Score:5, Insightful)
The biggest problem with Python, IMHO, is the online documentation. It's the worst I've ever seen, so abstract that it's of no use to anyone except maybe as a reference for someone who wants to write real documentation.
I can only assume that like Python itself, the documentation is the result of an author who wanted to do things "the best" way, without being willing to look outside his own head to determine what that might be. For the language itself, the result was okay - if slightly annoying at times. For the documentation, it's unacceptable. New and different languages can be learned. But with indecipherable and oddly-organized documentation, that's very difficult to even start doing. I had several "false starts" with Python, abandoning it quickly because the documentation (and installation process) were so opaque. If not coerced by my employer into giving it another try, I never would have touched it again. The only reason I stuck with it this last time was because my employer had a stack of Python books for me to use.
In the "heavy scripting" domain, I've put a lot of time into Perl, Python, and PHP. PHP's online documentation is the exact opposite of Python's; entirely focused on the practical, with lots of examples and very little theory or background. Perl's is somewhere in the middle. Overall, as a learner I found Perl's documentation to be the best, and as an advanced developer I find PHP's to be supreme, bar none. Python's is a disgrace, useful to neither beginning nor advanced users.
It's great that people are writing good books about the language. But in this day and age, it shouldn't be necessary to buy a book just to make sense of an open-source tool.
Re:Oh, well. (Score:3, Insightful)
Re:A (hopefully) unbiased opinion on Perl v. Pytho (Score:3, Insightful)
You have a point there, but I'd put it in a slightly different way. I'd not tell people to learn as many languages as possible, but rather learn programming and its basics (knowing the architecture behind the scenes, the CPU, is really a lot of fun).
There isn't much point in knowing every programming language, but a much better deal to know the syntax used in those languages. Also, when learning programming it's important to have a certain sense of logic (especially for object-oriented and/or heavily nested functions) because you need to keep things apart.
Why do you want to learn the syntaxes?
Let's use me as an example (not a very good one as I don't know very many languages, but I cope)... I've started programming using simple QBasic (where one learnt horrible spaghetti programming since one was 8 yrs old at the time) and Pascal (where I learnt about functions and procedures, something very important for any programmer).
I've then moved on to C and asm (PIC16F84) where I've learnt about pointer arithmetics, references and the joys of loose pointers.
I have since then learnt C++ and asp (vbscript/visual basic/com)...
Later on when you need to use another language (in my case PHP) it's very easyto just utilize the knowledge you already have. For PHP it was just for me to learn how they handled arrays and strings. That's it. All I needed then was a list of functions (php.net is most excellent), because I already knew its syntax (being based on among others C). Macromedia Flash and Javascript (ECMAScript) were also very easy to use...
That said I know I have to test Python... I've never actually used it, but since they all say it's very nice I should really try it out... ^^
I hope this was a far too long comment for most people to put up with, but I don't really care.
Re:A (hopefully) unbiased opinion on Perl v. Pytho (Score:5, Insightful)
In general, I've noticed Python makes writing programs very fast and very easy to modify later to add new features. It takes me a little longer to write equivilent programs in Perl, but the Perl programs probably run a little faster although they take a bit more effort to modify later. Finally, if I really need a program to run very fast, I can port it to C where it'll run extremely fast, but that will naturally take the longest to write and modify.
Having said all that, I use Python programs for those day-to-day administration duties where plenty of tweaks are required. Python works great for CGIs too, and should scale up to a reasonable load. But, if speed or extreme scalability are a requirement, porting a Python prototype over to C is often a good idea. Still, I have no shortage of tasks that require quick programming but don't require great speed - and Python fits those quite well.
But if I could compile it to native code, now that would be pretty sweet.
Re:A (hopefully) unbiased opinion on Perl v. Pytho (Score:1, Insightful)
>
I think you answered yourself here. The very reasons that make Python easy for beginners (clean design, interpreted, simple tasks require minimal effort etc) make it an ideal prototyping language.
Python is a language whereby you can be running a test implementation of an idea within seconds, rather than minutes. If it's really necessary, you can always move to C/Java/YourPetLanguage for the production version.
Re:A (hopefully) unbiased opinion on Perl v. Pytho (Score:5, Insightful)
Uhh.... you are seriously misinformed.
data hiding: trivial to implement by overriding the standard accessors and limiting the set of things that can be accessed externally. Since you have full access to the scope and stack, you can even limit things in a fashion similar to java's private/public/protected. I have used this many times to force attributes to be set only through a particular path that involves certain chunks of business logic.
implement it in itself: Not sure what your point is, but you can certainly implement the Python VM in itself. The Python VM is actually quite portable as is demonstrated by the excellent Java based implementation found in Jython.
strong typing: yes -- python has no strong typing, but it is trivial to check types and constrain APIs to particular types. At times, it would be nice to have strong types, but weak typing also has some extremely powerful uses and patterns.
Too dog slow? Uh, no. See the Twisted project for an example of an "internet event server" whose web server implementation is faster-- and more flexible-- than apache. Not that apache is fast, mind you, but something that is faster than apache while maintaining flexibility can certainly claim to have better performance than the server used by, what, 50+% of the world's web servers?
Python scales well, it is extremely reliable, and has excellent performance for an interpreted language. Python is used in many mission critical situations in both commercially saleable products as well as in embedded markets.
Personally, I have built trading systems in Python. If you have ever been around a Trader when their technology doesn't work, you know that using technology that is fundamentally broken is exceedingly unpleasant (unless you enjoy being yelled at and having heavy things thrown at you). Python proved to be extremely reliable and allowed us to roll out new versions of the software very rapidly.
Note that I am not a Python Zealot -- I program in some random combination of Python, C, Objective-C, Java and Lisp on a daily basis. Of all the languages, I prefer to use Python because I can get things done more quickly and with lower maintenance costs than any of the other languages. However, I'm not going to berate a client simply because they insist on using Java-- and certainly not if they have a good reason for doing so....
Re:Where's the review? (Score:4, Insightful)
I mean Martelli's the man and all, but don't drop shit like:
* "Perhaps the best book about Python ever written"
* "my favorite author
* "Mr. Martelli's prose is always sparkling and always keeps the reader interested"
* "It is obvious that Alex Martelli took his time and put in sufficient thought, effort, and intellectual elbow-grease to make this work a classic for all time."
* "You will keep this book in the most cherished spot on your book shelf"
* "It is difficult to choose any one portion of the book to highlight for extra praise, as all topics are treated so well."
* "Everything about this book speaks of quality."
* "Holding the book, and turning its pages, gives one a feeling of satisfaction."
* "Time can not erase the quality craftsmanship and the shear joy of reading such a well thought out masterpiece of Pythonic literature."
People want to know "What's good and bad about this book" and not "How many ways can I kiss ass".
Re:A (hopefully) unbiased opinion on Perl v. Pytho (Score:1, Insightful)
I don't have much against Python. It's a nice language. If I wouldn't already know Perl, I'd certainly code a lot in Python. Main reason I hardly code in Python is that it doesn't offer me much that Perl hasn't, and it just isn't worthwhile to become as fluent in Python as I'm currently in Perl. Two big plusses for Perl compared to Python: better error messages and warning (personally, I find Pythons errors cryptic and less suitable for beginners, although it by default gives a trace where Perl doesn't), and Perl has better documentation. Python 1.5.1 doesn't even come with any documentation by default; you have to install that separately. This is specially important since "core Python" is much smaller than "core Perl", even for simple things, you'd need to pull in a module. And unless you know your modules very well, you need to consult the documentation to find out which module to pull in. (Recently, I wanted to use sleep. It wasn't in os, or sys, or even in posix, but in timer (IIRC), which took me half an hour to find out.)
Big wins for Python: a much, much cleaner OO system. While Perl took Python's OO system as a basis, in its implementation it took every wrong turn possible. Also, Python has less of "it is this way because it's the way of the C API" as Perl has. Python is probably easier to learn than Perl, certainly for people without a Unix background. For a coding project that consists of a group of relative novice programmers, from a varying background, I'd prefer to use Python than Perl. But then, because Python doesn't have something like use strict; (as mentioned by Chip), other options like Ada or Eiffel should be looked into as well.
For individual programmers, I do not think the question "which is better Python or Perl?" is a reasonable question. To be a good coder in Perl, you need a specific mindset. Perl is a rich language, full of special cases and shortcuts. It's great for large groups of people. But that isn't good for an even larger group of people. Many people are much better of with a language that forces you to do things in a specific way, that has stricter rules on doing things. For those people, Python is much better. Frankly, I think that many of the people currently struggling with Perl are much better of coding in Python. The Python community should do more advocacy. (And of a different kind than "Perl sucks")
-- Abigail
Re:A (hopefully) unbiased opinion on Perl v. Pytho (Score:4, Insightful)
How is the ability to write a Python compiler in itself practially relevant to most users?
Lack of strong typing and no support for data hiding can be thought of as a feature by those so inclined. This is just analogous to objections against 'whitespace sensitivity'.
I more closely agree with one of the replies: that Python suffers from horrible documentation. I recommend looking at ActiveState Python for a slight improvement from the web manual.
Some _personal_ highlights using python:
- learning curve duration: 1.5 hours to start writing moderate complexity RE file parsing scripts.
- ability to write a cgi enabled http server in approx 3 lines of code
- ability to write a decent cross-platform opengl demo in approx 200 lines of code. using PyGame, PyOpenGL, Numeric etc.
Also, please just ignore the zealots, don't acknowledge them with so much disclaimer.
all the best,
mbaranow
Re:O'Reilly's "Nutshell" books are their worst (Score:2, Insightful)
I have a Java Nutshell book and a Linux Nutshell book. The Java Nutshell is next to useless since Sun's Java Documentation is superb and is easier to navigate. The Linux Nutshell book is extremely handy since I'm not aware of any comparable online reference and there are so many obscure commands with random syntax to wade through.
So, you would probably find subjects with useful Nutshell books lack a strong, easy to navigate online reference for the same material. I've heard great things about Python's online reference and website, so a Python Nutshell may just take up space on your shelf.
Consequently, I've never found an excellent C online reference, and didn't enjoy using K&R for quick reference. So, a C in a Nutshell could be useful.
Writing a language in itself (Score:3, Insightful)
I won't claim to understand it. It certainly doesn't do anything for the general populace. It ought to be enough to say that a language is Turing complete [wikipedia.org] to say it can be used "for real". For some reason, it just gives the CS crowd big warm fuzzies when they do stuff like that.
Explain Python to me (Score:2, Insightful)
Combines the flexibility of syntax of C with the efficiency of Javascript. Python can't realistically support Lisp-style macros, doesn't support true closures, and many other things of Goodness that make Lisp languages so good for rapid coding. On the other hand, Python's dynamicism makes it very very slow. It's bad enough that the Python zealots [twistedmatrix.com] apparently don't know how to program Java -- as minor corrections to their broken test code result in Java code that just stomps Python.
So let's be honest here. Python is slow. So we have a slow language. So what? That's okay. I'm all for slow languages as long as they have features which make up for them. But Python's missing many of the goodies that make slow languages great. Macros. Closures. A good, scientifically-oriented numerical facility.
I get this very strong feeling that Python has the worst features of both Lisp and C, while not having the best features of either of them. No wonder it appears, from my reading, that the vast majority of people pushing for Python are ex-Perl programmers. In other words, they're arguing for Python as a replacement scripting language for Perl. Not as a language for large-scale development or maintainability. But Perl is an easy target. It's a grotesque language, only popular because it was first to bat in the full-featured-scripting-language game.
A malformed object oriented system. My other major beef with Python is that it has, to my mind, the single worst-conceived OOP system of any language I can think of at the moment.
There are two basic families of OOP: class-based (C++/Java/CLOS/etc.) and prototype-based (JavaScript/Self/NewtonScript). The advantage of a class-based language is that you can equate classes with types, and the compiler knows exactly where a slot should be in an object, even an inherited slot. So they're fast. A great choice for a performance program on a desktop. The advantage of a prototype-based language is that it only keeps around the diffs: objects don't need to store tons of slots they don't use -- they just point to a superobject and say "go there for anything else". So they're highly memory efficient. Prototype languages are also highly dynamic, elegant, and small. A great choice for a scripting language, or a language for a PDA (like the Newton).
Python is odd: it has both models. Underneath the model is prototype-based. Kludged on top of this is a class model. What the heck? Do not think this is a good thing. Each model has made sacrifices from the ideal -- by using both models, you're making all the sacrifices at the same time. It appears to me that Python has managed to achieve the worst of both features: it's not as dynamic or small and elegant as a prototype OOP language, and it's not nearly as fast as a class-based OOP language. It has no advantages over a prototype-based model at all. In reality, the kludge means that Python programmers have to keep more syntax rules in their brains in order to achieve less than a prototype language would provide.
I get the feeling that what happened was Python started as a procedural Perl-style language, then hacked on a prototype model, then due to, I dunno, misinformed "customer complaints", hacked on another class-based model on top of that. What a mess.
Anyway, this is how I see the current state of the Python world. Why do people use this language? My guess is that it's because they're ex-Perl programmers, and made an incremental jump to the next slightly better language.
Re:Writing a language in itself (Score:3, Insightful)
You're right. But I wasn't really addressing this. By implementing a "language in itself", I was really referring to more dynamic languages like Python, Perl, TCL, LISP, Smalltalk, etc. A Python program could run a Python interpreter, which could run a Python interpreter, etc. and it could change at run-time as per the user. Doing the same think in C, C++, Ada, Pascal, etc. doesn't even make sense unless you're talking about some sort of interpreted versions of those languages. I would say that bootstrapping is quite different from "dynamic re-entrancy" (my term, yeah it's not a real term).
At any rate, either of these techniques are of little interest to non-nerds (see my above definition).
Also, I wouldn't say that just because I can implement a language in itself, that the language is mature. Any Turing complete language can, theoretically, be implemented in any other Turing complete language. To me, a real developer who develops real solutions for real customers, a language is "mature" when I can use it for a client and not be let down by the language and the accompanying tools and environment. That's a far more difficult thing to measure and the measure is much more demanding to satisfy, once it is measured.
Re:Explain Python to me (Score:2, Insightful)
> other things of Goodness that make Lisp languages so good for rapid coding.
Strange that Python doesn't support Fortran type line numbers or BASIC type OPEN statements either. If you want to use Lisp, use Lisp. Python is its own animal.
> Python is slow. So we have a slow language. So what?
Exactly. So what. The speed of the interpreter is usually not the bottle-neck in most app domains. If it is, use a different language. Python is fast enough for most uses, and can easily bind to libraries in C or what-have-you for those parts of your app that need performance.
In the meantime, you can develop your program faster and more error-free, by a factor of 5x or 10x depending on which study you believe. Getting a project done, on time, on budget, and working correctly is more impotant than speed almost always.
> A malformed object oriented system.
I am not a purist. I like to get work done, and have other people understand what I am doing and why. Python has a highly usable object-oriented architecture that works very easily for 99% of what I need, and can be hacked (thanks to its marvellous introspection) for the other 1%.
Python is easy to learn, easy to write, easy to read, and produces bug-free code faster than any language I have ever used. The number of rules I have to keep in my head is approaching zero.
Really, your comments demonstrate that either a) you have never programmed a real-world project in Python, or b) you are too attached to Lisp to give Python a fair shot.
Either way, you apparently care more for theoretical concerns than practical, and so are not a good candidate for Python anyway.
robin
Re:Explain Python to me (Score:2, Insightful)
Not having macros was a deliberate design decision. One of Python's key stengths is easy readability and adding the ability to add/modify language contructs might compromise this.
A good, scientifically-oriented numerical facility.
What facilities are you looking for, in particular? Python has a double-precision floating point type, unbounded integers and complex numbers as part of the core language. Are you looking for something else, like rationals?
Or is it libraries that you are looking for? If so, here are the docs for
Numeric [pfdubois.com]
Python is odd: it has both models. Underneath the model is prototype-based. Kludged on top of this is a class model. What the heck?
I don't understand your complaint. Can you discuss it in terms of semantics e.g. I would expect method to get resolved like this but they get resolved like that....
I get the feeling that what happened was Python started as a procedural Perl-style language, then hacked on a prototype model, then due to, I dunno, misinformed "customer complaints", hacked on another class-based model on top of that. What a mess.
Python is fundamentally object-oriented. Even integers are treated as objects.
Cheers,
Brian
Re:A (hopefully) unbiased opinion on Perl v. Pytho (Score:4, Insightful)
Other than Performance?
and adds a few of its own: you can't implement it in itself
Hmm? Its quite trivial to parse Python code in Python, and its qutie trivial to interpret it with Python code, so where's the problem?
it has no strong typing (even Perl's use strict is ridiculously better),
You're confusing "strong typing" with "static typing". Python has no Static Typing, but indeed has Strong Typing (try '5 + "Hello"' in your Python interpreter). Perl, on the other hand, has no strong typing at all ("Hello" + 5 is perfectly valid in Perl, albeit senseless).
Not having Static Typing is not a bad thing - its a concious decision by the language designers. The designers of Python wanted the language to be just-explicit. If you want the program code to express an idea, you express it once - Which is more than implicit, and less than redundant. Static typing is redundant - and avoided in Python as a design goal of minimizing programming time of any task.
Another idea behind the lack of static typing is that all lines of code MUST run at least once anyway for any minimal level of reliability, so the compilation-level check adds no value.
an OO system with no support for data hiding, etc. etc.
Python supports data-hiding, but simply does not enforce it. This is because Python is not a BDL (Bondage and discipline langauge). Instead, there are extremely well-established and documented Python conventions. The prefix underscore that denotes private/protected, The double underscore that
denotes private (avoiding namespace clashing by name mangling), etc.
And that brings me to the biggest problem: Python doesn't really have a niche to fill. The CGI space has been seemingly co-opted completely by Perl (at least until people start using PHP), and it's too dog-slow to be used for real CS applications.
Python isn't a niche language. Its a general-purpose language - and no - its far from being too slow for real CS applications. That's why its successfully used in Search engines, 3d engines, system administration, compilers, games, etc.
As a beginner's language it's ideal, but that's not going to help it be taken seriously when it comes to real computing tasks.
Python is taken very seriously in many many places, with increasing seriousness.
If the python developers made some tweaks to the type system
Like what? Static typing conflicts with the Python design goals.
and added a real compiler
Python already has the Jython compiler to Java, psyco compiler to native code, and others.
then I would advocate that most software engineering be moved there.
Many already advocate it for all software engineering except for the inner loops which are exported to Python from C code. This proves for many people to be the most effective way to write fast, reliable maintainable code.
As it stands it's an original language which is a lot of fun to program in, and still has lots of unmapped potential to it.
The unmapped potential is discovered by more people every day