Slashdot Mirror
Python in a Nutshell
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."
That's a pretty goddam big nutshell, if you ask me!
Congratulations! Now we are the Evil Empire
Gentoo Linux is an interesting new distribution with some great features. Unfortunately, it has attracted a large number of clueless wannabes who absolutely MUST advocate Gentoo at every opportunity. Let's look at the language of these zealots, and find out what it really means...
"Gentoo makes me so much more productive."
"Although I can't use the box at the moment because it's compiling something, as it will be for the next five days, it gives me more time to check out the latest USE flags and potentially unstable optimisation settings."
"Gentoo is more in the spirit of open source!"
"Apart from Hello World in Pascal at school, I've never written a single program in my life or contributed to an open source project, yet staring at endless streams of GCC output whizzing by somehow helps me contribute to international freedom."
"I use Gentoo because it's more like the BSDs."
"Last month I tried to install FreeBSD on a well-supported machine, but the text-based installer scared me off. I've never used a BSD, but the guys on Slashdot say that it's l33t though, so surely I must be for using Gentoo."
"Heh, my system is soooo much faster after installing Gentoo." .debs can be rebuilt with a handful of commands,
my box MUST be faster. It's nothing to do with the fact that I've disabled
all startup services and I'm running BlackBox instead of GNOME or KDE."
"I've spent hours recompiling Fetchmail, X-Chat, gEdit and thousands of other programs which spend 99% of their time waiting for user input. Even though only the kernel and glibc make a significant difference with optimisations, and RPMs and
"...my Gentoo Linux workstation..."
"...my overclocked AMD eMachines box from PC World, and apart from the third-grade made-to-break components and dodgy fan..."
"You Red Hat guys must get sick of dependency hell..." .rpms together on the command line, and that problems
hardly ever occur if one uses proper Red Hat packages instead of mixing
SuSE, Mandrake and Joe's Linux packages together (which the system wasn't
designed for)."
"I'm too stupid to understand that circular dependencies can be resolved by specifying BOTH
"All the other distros are soooo out of date."
"Constantly upgrading to the latest bleeding-edge untested software makes me more productive. Never mind the extensive testing and patching that Debian and Red Hat perform on their packages; I've just emerged the latest GNOME beta snapshot and compiled with -09 -fomit-instructions, and it only crashes once every few hours."
"Let's face it, Gentoo is the future."
"OK, so no serious business is going to even consider Gentoo in the near future, and even with proper support and QA in place, it'll still eat up far too much of a company's valuable time. But this guy I met on #animepr0n is now using it, so it must be growing!"
-
Could the author please respond in this thread and give some examples of the new content, rather than just "covers it all"?
No, but it does handle julian calendars: http://www.pauahtun.org/julian_period.html
You know, when I saw that title, I just knew that there was a joke in there involoving Monty Python, nuts and hell (nutshell, nuts hell).
If I had the time I'd come up with it, and I'm sure it would be the funniest joke in the world, much better than the German joke, "two peanuts were walking down the street and one was assorted".
Unfortunately, I have to go out for a silly walk, and then onto a mouse club, so I'll have to leave it to someone else to inject some much needed hilarity into these proceedings.
"Accept that some days you are the pigeon, and some days you are the statue." - David Brent, Wernham Hogg
Let me start off by saying that I don't usually read this site. I was pointed here by a python programmer who wanted more python people to join this dicussion. However I'm not exactly a "python person." I'm most comfortable in C, with a smattering of Java, Perl, Asm, Lisp and Python (in no particular order). That being clarified, I'd like to say a few words.
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.
As opposed to what? (If you say "Perl" or "C++", you may well have found the fatal joke from the Monty Python sketch.)
I mean hey, those guys were off their rockers, all of 'em! Have you seen that Silly Walks bit? And the one where the Society puts things on top of other things? Nuts!
What? Programming language? Um...
Nevermind!
Little girls, like butterflies, need no excuse. -- L. Long
Actually I looked at this book in the store and it does not seem to have much at all about Python. There are not any pictures, and all the episodes are missing somehow. There is not even anything on Michael Palin, John Gleese or Eric Idle.
I had a hard time reading the rest of the book as it was about some obscure stuff that no one ever heard of before.
Other than all that, it is probably a pretty good book for some chaps somewhere to perhaps enjoy.
I got 2 big nutshells for ya, and a python to go with em. If you're lucky, I'll even give you a Perl necklace.
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!
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.
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
I've been using Python for a few months now. I hope people won't mind if I post a shopping list of what seem to be missing features in the language, and ask if there is a way round them.
- Python has 'break' and 'continue' like C. But these only affect the innermost loop. Is there a way to break out of an enclosing loop? (In Perl you can label a loop and then say 'next LABEL', etc.)
- Failing that, is there a way to get goto statements in Python? They can sometimes be an elegant way to express something, contrary to popular myth. (Eg tail recursion.)
- How can I pass a variable by reference? For example, to take a reference to a string, pass it to a function and have that function modify the string passed in. More generally, is there a way to store references?
- Python advertises its support for first-class functions, but I can't seem to get closures to work. The 'lambda' keyword won't accept assignment or even sequencing inside the function body. So anonymous functions you might want to pass around can't do much beyond trivial operations. You can get around this to some extent by making named functions in every case and passing those around, but even then they don't seem to act properly as closures, picking up variables from their local scope. (I'm using Python 2.2.1 BTW.)
- Is there a do/while statement in Python? Plain 'while' is there but occasionally an 'at least once' loop is what you need. Is there an addon package or library for Python that provides a 'do' construct?
As you may have guessed, these are the things I really miss in going from Perl to Python. The cleaner syntax isn't a big enough payoff for going without some fairly important language features. The project Vyper sounded very promising in its attempt to add real lexical scoping and functional programming features to Python, but it doesn't seem to be active any longer. A real pity. In the meantime, where I have a choice, I'll keep using Perl, despite its syntactic oddities and historical baggage.
-- Ed Avis ed@membled.com
I think he's just bitter about the indented code blocks.
I know tons of people who think that Python is the best thing since sliced bread, though my personal preference leans towards PHP. But then again, I'm only working with web interfaces currently, so (IMO) PHP is a tad better-suited to that.
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.
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.
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.
Ita erat quando hic adveni.
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
Actually, one of these is being worked on: There's an active project to write Python in itself. I believe they're taking the same tack as Squeak.
John Roth
I would call you a karma whore if you weren't AC. If anybody would like to see the unplagiarized version of this post and the thread it came from Here it is.
> Python doesn't really have a niche to fill. ... As a beginner's language it's ideal
>
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.
I couldn't agree more w/ both this post and the one before it. I have yet to find a use for Python that isn't already covered by a language I know (PHP for web apps, Java for more complicated server or GUI stuff), and the few times I have tried to learn more about Python, I run up against the online documentation, which does more to talk about how cool Python is than actually explain how to use it (just like you said - the opposite of PHP's online documentation, which is hands-down superb). This isn't meant to be a troll post, just my experience. Glad to hear I'm not the only developer who has run into those 2 issues w/ using Python (the Why and What, so to speak).
Ok...
but how did you like the bookreview?
I didn't have this experience at all, I found a lot of their documentation very helpful and certainly more helpful than the free documentation on Perl that you can find.
I didn't have any problem with false starts, I went to the python website one day to check it out and the next day I went to one of the online books about python they linked to and I learned a shitload and within a couple hours I began to appreciate and love Python.
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
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....
python is not slower than perl
python can handle large apps like Zope easily. imagine something like zope in perl!
I used to think Python documentation sucks. The truth is that it's not bad. It's just not for beginners, imho. Once you get into the language, the documentation somehow transforms into a useful, intuitive thing. Of course, it's probably a bad thing that newbies can't understand the docs that well, but as a rather experienced Python user now I find them very useful and not "unacceptable", "oddly-organized" or "indeciperable" at all. The language and the docs might be a bit weird at first, but once you take a few steps forward, you'll find you love (or possibly hate) them both.
I'd have to say that more than a few people are using PHP. In fact, of the available Apache modules, guess which one is the most popular? (Hint: it's not PyApache or even mod_perl by a long shot)
My journal has hot
My history is similar, I learned VB with which I learned diddly about good code, but let me catch the bug, I learned Javascript which is a horrible language, but got me using C-style syntax and is fun to play around in (there are all kinds of stupid scripts you can do in javascript that you can't do in any other language), then I learned PHP, C and since then a few other languages. Choosing to learn PHP instead of Perl was a great decision because it's simple but powerful -- well fitted for what it's used for. Choosing to learn instead of Perl was an even better decision as I realized once I attempted to learn Perl.
I swear, 90% of the Perl zealots have never used Python and 90% of the Python zealots have used Perl and dropped it.
I've never seen much point in the discussion "Perl or Python"? And unfortunally, most participants in the discussion know at least one of the languages not well enough to contribute something worthwhile. Many Pythoners don't come further than "too much punctuation", while many Perlers don't come further than "the mandatory white space". I don't know about others, but if all you can come up with against a language is "mandatory white space", I wouldn't program in any other language anymore.
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
the entire system needs to be scrutinized by security experts before any program written in Perl can be considered secure,
#/usr/bin/perl -T
Learn your terminiology:
Python has STRONG DYNAMIC typing.
C has WEAK STATIC typing.
Perl5 has WEAK DYNAMIC typing (Argh!)
Common Lisp has STRONG DYNAMIC and OPTIONAL STRONG STATIC typing.
This is the damn good post. Mod this post up
Maybe I have to ask this in comp.lang.python,
but anyway...
The other day I gave python a try for the first
time. I was a bit surprised by how the for loop
is done. Rather than "for i from 1 to 600" that
I expected, it is "for i in range(1,600)"
That made wonder about how "range" is implemented.
Is the whole range generated beforehand -- like
is shell sctipting (when you do
"for i in `seq 1 100000`", it generates the
sequence first, and then i starts taking
values from it); or it does it the smart way,
generating the values one by one?
Thanks!
My own opinion, like yours, is biased by the specific problem domain I applied Python to. For me that has been sys-admin scripts and network/cgi automation scripts.
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
Lifted whole cloth from Daily Python-URL
Python is an excellent rapid prototyping language. Because of its neat syntax and simple philosophy, programmers can quickly create a working protoype in Python. Later, if needed, it can reimplemented in a faster programing language (like C++).
From your comment i get the impression that you have not touched serious code in your life.
How much hand holding do u need ?
Or is it that you have some problem with reading english?
The perl provides good documentation on how to use the features and libraries and has an efficient way of organising it. I dont have any thing against the python documentation or the language. It is different from other language and i like the difference. But that is not to say that other languages are full of shit.
If you really want to compare things , please do us a favour and try using the things first.
~561
I'm glad you found the online Python documentation helpful. However, you are mistaken if you think it's "certainly better than the free documentation on Perl." The online (that is, man page) documentation for Perl is very good indeed, and is highly practical even for nontrivial tasks. I learned Perl largely by printing out these man pages and reading them through. I've never encountered better free documentation except maybe for erlang.
demi
Python == Snake Oil
Python == Snake
Snake Oil can be a Python Oil
can be
Python == Python Oil
Oil == NULL!
For those who didn't really "get" the previous comment - Python is a full OO language that (depending on the support on your platform) provides you with much the same capabilities as C++ et al. The same can certainly not be said of PHP.
In this context, the advantages become clear.
I really don't see what the problem is. I learned Python TOTALLY from the documentation that is included with the Python package. I went through the tutorial to get the 'flavour' for the language, then browsed the library documentation to see what kinds of libraries there were, and the same with the language documentation. I go back to the library and language documentation when I need more information.
It's, for the most part, fine.
Yes, there ARE some holes here and there, as there are with a lot of the other types of documentation too. but it's hardly 'useless'.
FYI, I used to be a avid Perl programmer until I had to reverse-engineer a Python program to modify it. (Xerox DocuShare)
Sorry, but this is just baiting. My problem with a lack of block endings is that it makes it hard to see a complete or incomplete block when there is a large one--this is not a theoretical problem but one I've faced more than once, and is supremely frustrating.
demi
Ridiculous. Taint checking doesn't guarantee security any more than Java's sandbox does. Security is a process that requires an entire system (of which the Perl interpreter is just a part) to be scrutinized on a continuing basis; security is not a product, compiler flag or interpreter argument.
Ita erat quando hic adveni.
you can't implement it [Python] in itself
:-)
Actually, there are people who are in the process of implementing Python in Python right now. The project is called "Minimal Python".
it has no strong typing (even Perl's use strict is ridiculously better)
Actually, Python is strongly typed.
an OO system with no support for data hiding
Most Python developers consider data hiding a misfeature. Unless you are operating in a secure environment or can enumerate every possible usage case for your code and prove that no one could ever need access to a private method, you should allow access. Just document the fact that the implementation could change in the future.
If anyone is interested I'm willing to share my stories about being burned by C++ library developers who were too fond of data hiding
and it's too dog-slow to be used for real CS applications
I'm not sure what "real CS applications are" but Python is frequently used for scientific computing.
Cheers,
Brian
Not too bad for a (supposedly) first time /. troll... You've got potential.
Says the C coder. *chuckle*
I partially disagree: I think that the library reference is excellent but that the language reference is terrible for beginners. I would suggest that you find a tutorial to learn the language and use the official documentation to learn the libraries.
Take a look at:
http://www.python.org/doc/Intros.html
abandoning it quickly because the documentation (and installation process) were so opaque
What part of the installation process is opaque?
The Windows installer is a GUI installer that only asks you the install location.
The UNIX install process uses the usual autoconf process. On Linux, for example, all you have to do is:Cheers,
Brian
Sounds delightful. My abortive experiences were back in Python 1.5 days, and I was unable to get it to run on Linux or FreeBSD. I had problems with missing libraries (both system libraries and internal Python libraries) and other random make errors. Finally I installed RedHat on a new machine and used the RPMs, which worked (though later failed to work on another machine that was not a fresh install).
Installing v2 from RPM this time around was easy.
"Patriotism is your conviction that this country is superior to all other countries because you were born in it." -- GBS
Too Slow? Depends on your application.
I use it for ETL (Extract/Transform/Load) in data warehouse environments where millions of rows (and sometimes hundreds of millions) have to be transformed daily. These transformations range from simple text substitution to binary searches on large arrays. In this environment python performs adequately. More importantly however, it allows these applications to be developed quickly, tested quickly and maintained easily.
Back in the day, these applications would have been written in C. Today a few are, or a few pieces of a larger python framework are, but given the cost of hardware it's simply cheaper to just buy a slightly larger box than spend another few weeks on development.
I've used a wide variety of languages and vendor products for this activity, so far python has proven to be the best solution by far.
You would have to be nuts to use Python as your shell!
I too don't think that Python's documentation is bad, in fact I actually think that its excellent. Much like the K&R C book. One thing that I admire about Pythons documentation, is that you could recreate the language from "Language Reference" section.
I find that there are 2 (if not many more) kinds of documentation. Documentation that is meant to be read (more like a book), and documentation that is meant to be used (looked up while using like manpages and msdn). I believe that Python is that of the former, while PHP is that of the latter.
Conceptually, a for loop always iterates over the members of a sequence. range is just an example of generating a sequence. This is actually quite nice, because if you have a sequenence of lines in a file, you can do stuff like "for line in file:" and loop over them easily. You aren't stuck looping only over integers.
As for your actual question: range does generate the entire list. xrange generates an object instead that calculates the items on the fly. Newer versions of python will be changing things (if they haven't already) so that range generates on the fly as well, and gets rid of the xrange object.
Benchmarks have shown over time that xrange is not appreciably faster than range; you have to spend the time generating that number somewhere, either up front or one at a time. The only reason to use xrange is if you have a very large sequence to loop over, and can't afford the storage for the temporary list.
It's a nerd thing (I would say it's a geek thing, but a geek is a nerd that can actually function well in society and I'm not convinced people who do these things have actually graduated to geek). If a language can be used to create an implementation of itself, and that implementation can in turn be run on itself, then it's considered proven that the language is sufficiently useful for "real" usage.
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 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.
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
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 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.
I've got to recommend Dive Into Python as a great, free, online Python book.
(PS. I own the dead-tree version of Python in a Nutshell, I think the above is nice to use as a while-programminng guide)
This comment will probably make it obvious, but I'm not a programmer (not by profession at least). Anyway, here's my question: Why would someone want to implement Python in itself?
That's a good question! There are two answers besides the technical flourish. One is that it demonstrates that the language is able to handle system level tasks (as opposed to, for example, RPG.)
The other is that being able to write the interpreter in Python vastly simplifies the task of evolving the language. You not only have a reasonably straightforward Python to C translator for the production interpretor, but you can also run the interpreter under itself for testing and debugging. See Squeak for another example where this has a real payoff.
John Roth
I cannot agree with the reviewer that M. Lutz's O'Reilly "Python" book is good. I disliked this book nearly all the way through. It jumped around too much, used too many words, and had insufficient detail on more advanced topics. Given that the book is about three inches thick (from memory -- I gave away my copy), there's enough room for details on everything.
I concur with other posters that the "Essential Reference" (white and red from New Riders, written by D. Beazley who did SWIG) is an awesome book. It is concise, making it a good reference. I wouldn't think it was a good book for those who have never programmed. If you have some programming experience, though, I expect you'll appreciate this book.
The "Quick Python" book from Manning is nice, too. This was my wife's preferred book for learning Python. I've looked through it a bit, and it seems decently concise but with more explanation than "Essential Reference". I used its section on extending Python through C, and found it very useful. That section didn't have everything bit of reference that I needed for conversion specifiers, but their examples were dead-on what I needed to get started.
I recently finished reading through "How to Think Like a Computer Scientist: Learning With Python" from Green Tea Press. This book is not a complete reference or guide for Python, nor will it be particularly 'useful' for people who have taken university-level programming and data structures classes. However, it seems to be an AWESOME book for people who don't yet program, or whose only experience is web programming or VB or Perl programming (I'm not saying those things are bad, but very often they don't encourage reasonable programming discipline and methodology). I write "it seems" only because I'm not a beginner or an instructor for intro to programming courses.
This book ("How to Think...") is aimed at classroom use, so it doesn't include info about installing Python or starting the Python interpreter under Windows, etc. It does preach solid computer science. Parts of their approach seemed a bit unusual to me, compared to my more classical training, but after a few gripes I always was forced to conclude that their approach was valid and as concise and clear as it could be. The authors are aware of the book being used in high schools and community colleges. I expect that mature students, or any adult intrested in learning proper programming, would benefit from starting with this book.
-Paul Komarek
I just don't see the problem.
The perl provides good documentation and the python provides good documentation too.
*yawn*
In sounds like common sense, if you want performance, port it to C, C++, etc. In practice, you may as well port it to assembly language to gain some performance.
Python has many high level data types such as tuple, list and dictionary as well as operators to make them useful. These datatype prove to be useful for a lot of programming tasks. This is why programmers find it so productive with Python. A simple pythonic operation such as getting an indexed item from a dictionary would be translated into many many lines of C code. Perhaps hundreds of lines if you want an efficient implementation. It just wouldn't be the same program if you rewrite it in C.
Nothing against rewriting code in different language. I just want to point out that one is lot more high level then the other. For me Python is a good choice for tasks where programmer's time is more important than CPU time.
Ruby looks quite nice, but I haven't tried it yet.
:wq
That being said, Perl is at least useful for many things ("practical," I believe it's called).
Python is useful for many things as well, as evidenced by the number of people who use it, including Boeing, Disney, Hewlett-Packard, Industrial Light & Magic, Intel, JPL, Lawrence Livermore Labs, NASA, and Yahoo. Programmers at places like these are usually allowed to make their own decsions about their tools, and they chose Python. These guys are good. They don't use tools that they don't like. This is not to say that Python is their only scripting language. I know NASA makes good use of TCL, and probably uses Perl as well.
Peter Norvig says "Python has been an important part of Google since the beginning, and remains so as the system grows and evolves. Today dozens of Google engineers use Python, and we're looking for more people with skills in this language." Norvig is director of search quality at Google. Look at his home page (www.norvig.com/. When a guy who writes AI books talks up a language, it means something. I'm not saying it means everything. It's another piece of data to put on the scales.
More details on use of Python:www.python-in-business.org/success/
http://www.python.org/Quotes.html
Finally, I note that the Google jobs page mentions Perl 11 times and Python 15 times, for what it's worth. I didn't read the job descriptions.
Just out of curiosity, do you have some link to this "trading system" of yours?
Thanks.
> 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.
:-)
Yep, I've come to those exact same conclusions. Take a look at the "win32*" API docs hosted at ActiveState, for example win32net.DriveAdd()
The docs basically say "Wrapper for the win32 call -- see MSDN for details".
No examples of usage? Thanks! OK, I go to MSDN and see a C data struct for arguments. I'm not a total moron so I deduce the gist of it, but I spend 30 minutes in the debugger (going mad).
The problem?
One of the dictionary keys this Python wrapper expects is password. Fine. But someone decided the wrapper should call it "passwd" -- not "password", like the MSDN documentation indicates.
If you pass in data['password'], the wrapper will accept this, use a NULL password, and not raise an exception. WTF?
The docs are not only incomplete and a little too terse, but they can be *wrong*. That blows.
I bought "Python Programming with Win32", but it glosses over the wrappers. A lot of trial and error is needed.
I *still* prefer Python over Perl for a general-use language. Python may have a fanatical enforcement of whitespace and coding style, but that's fantastic for reading someone else's code. Perl has lots of unintentionally obfuscated code.
Python's biggest weakness is it's a learning language, which in itself is fine... but no one seems to push the boundries. It could be a great language for application prototyping/automation/etc, if we hadbetter documentation for modules. End rant.
If you need more speed than native Python provides, you can always write code in C and wrap it so it is callable from Python. The wrapping is really easy to do, once you have understood the general concepts involved in it. The product I currently work on has about 10000 lines of C code (crypto and networking) which is used this way, and it works perfectly. For more information about extending Python with C, see:
Extending and Embedding the Python Interpreter
Python/C API Reference Manual
try again.
how about:
learning to program using python
a much better book for first, learning to program and second, learning the basics of python.
THEN moving to learning python.
I am the Alpha and the Omega-3
Great book. I have read several of the OReilly titles. They are great to understand how historically some features got into the language, etc. They also greatly contributed to the Python advocacy. But in a way, it's also their downfall: they tend to be dated.
The only Python book I read now is the New Riders title. I can find just about anything in it as fast as I can search Google. OK, *almost* as fast.
there's no place like ~
Now, with that in mind, and being a Python user for years, I do have something to say about the shortcoming of Python's design:
I think it's important to get stackless to merge with the main Python. Some Python developers argue continuation does not bring enough benefit. I think it's shortsighted - for web development, Squeak Smalltalk have Seaside, Cocoon uses Rhino/continuation, all use first class continuation as the next generation web development model. The advantage will soon show. BTW, "continuation" solves the multi-level break problem easily, exception, generator, lightweight thread can all be implemented on top of it.
Use Ruby - the best of both worlds, fully OOP (on a par with SmallTalk) with regexp/string handling of Perl.
Python 1.5.1 doesn't even come with any documentation by default; you have to install that separately
You are basing your experience on a Python release that is over five years old!
Cheers,
Brian
I have never gotten around this. I probably never will get around this.
With braces, as in perl or C, I can bounce on the % key and find the ends of a block unequivocally. I can cut and paste from one editor to another, and it still works. I can change tabstops and everything still works.
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
>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.
Yep, I've come to those exact same conclusions. Take a look at the "win32*" API docs hosted at ActiveState, for example win32net.DriveAdd()
I tried to find win32 bindings for Perl and couldn't. Could someone point them out to me please? I did notice that the only Perl COM solution seems to involve paying money. The Python solution is free.
Which might be why the Python win32 documentation isn't very strong: it is not done by the core Python team, nor by a company that charges you money, but by one really smart guy (Mark Hammond) who, in addition to doing work that pays the bills, develops and documents the Python win32 bindings pretty much by himself.
I think that the core Python library reference is excellent.
Cheers, Brian
I don't know if I'd throw it into the "learning language" category. After all, that's throwing it into the same bin as BASIC and Pascal. Python's core language is just as good as any other. The problem with Python is the modules. Like you said, the documentation for these is HORRIBLE. For those that don't know, the documentation consists of whatever the programmer decided to put into triple quotes in the source. You can then run another program to go in and retrieve these, and format them appropriately. This sucks. I like Python, but the documentation definitely needs a kick in the ass.
'Standards' in computing only impress those who are impressed by things like 'standards'.
Your blocks are obviously too large, then.
You need to divide into smaller, more trivial pieces of code.
Python is so expressive that functions/methods rarely need to exceed 5-8 lines.
Show me any example of a long Python function where you have experienced what you speak of, and I'll explain how and why its too long.
But the problem is that Python suffers from a lot of Perl's problems
:)
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
Twisted Web is "fast enough", and nobody seems seriously interested in optimizing it, but I would hesitate to boldly claim it's "faster than" something else if it doesn't have a clear advantage. I'd have no problem if you said it was faster than Jigsaw, for example: if you want to talk about dog-slow systems, that's a good example.
With a real production webserver like Apache, though, there are a lot of variables to tune. There are obscure interactions to be taken into account. Twisted will surely be slower than well-configured Apache on an SMP system, for example, unless you've got 2 processes working in parallel behind a proxy... and of course, then there's dynamic content, which is an entirely different set of measurements.
The issues are complex, and it doesn't help to advocate the project by oversimplifying them.
Glyph Lefkowitz - Project leader, Twisted Matrix Labs
Writer, Programmer - Not a member of the TSU
Well, relocating all the logic into a dozen separate function calls doesn't necessarily help readability either--sometimes you want to see a bit of sequential logic. There was some of that going on, and a couple of large here-documents.
But of course I'm not claiming that the problem can't be solved or even that there's anything wrong with Python, just that the poster was clearly baiting people with the claim that Perl coders don't like Python's indenting-based blocks because it doesn't allow them to write ugly code, which is clearly an insult.
I appreciate your offer to write some code for me though :)
demi
I love O'Rielly books. I have not seen the python book this review addresses, but I didn't like O'Rielly's previous Python books. Assuming you already know how to program in some language, the Python book I would recommend is _Python Essential Refernce_ by Beazley published by New Riders. It is the book O'Rielly doesn't have. I agree with the others who have recommended it.
(This post probably would have been more coherant if I had spent more attention writing it.)
You can address this problem with one or more of the following:
...)
...
...
- a folding editor (SciTE, PythonWin, jEdit,
- block delimiters placed in a comment, like:
if x: #{
#}
- a preprocessor that Tim Peters wrote to strip block delimiters automatically before the code is sent to the interpreter
Python has its quirks (what doesn't?!) but the key thing to remember is that it's been designed with practicality as the #1 design metric. Sure, you can complain about the object model not being pure in one way or another, or any number of other things. But that is missing the point. The bottom line is that it's a phenomenally easy language to work with, and it results in clear and very maintainable code.
It's a language for people that focus on results and not for language lawyers or people that think complexity or obfuscation is cool. It requires some willingness to learn and understand how to work in it, but the rewards are well worth breaking through the "yuck, white space = syntax" and related mindsets.
I personally learned it from the online docs and by working with a real application that I needed to write as fast as possible. It's quick to get started that way tho I realize now that I missed the point often enough that reading a "real" book might have helped me take better advantage of the language earlier on.
Anyway, it's a very well thought out language and deserves study through actual use. Quick to learn, rewarding very early on, but also does take some time to use optimally. This is particularly true in learning how to write performance critical code, and in figuring out how to take advantage of the dynamic nature of the language. The latter can be very powerful w/o danger of reducing code maintainability; something quite surprizing that I've never seen in any other language design.
I know nothing about this book, but hopefully this perspective of an ex-skeptic is useful.
I'm not sure what "real CS applications are" but Python is frequently used for scientific computing.
"Real CS applications" are programs written by Real Programmers--the "anything less efficient than asm is an abomination" crowd.
Some Python developers argue continuation does not bring enough benefit. I think it's shortsighted...
This isn't the primary reason that stacklessness hasn't become standard. The foremost reason is that the Java Virtual Machine (upon which Jython is implemented) can't handle tail recursion efficiently.
Guido wants to avoid significant divergence between CPython and Jython; he argues that people would be much more likely to write Jython-incompatible code if they were able to take advantage of stackless features in CPython.
Like you, I don't agree with his decision.
Another book for adults...
Learning Python is getting rather dated (version 1.5 or sumthin). As an alternate, I can recommend Peachpit's Visual Quickstart Guide Python by Chris Fehily. It's a thorough, well designed introduction for people who like to learn while doing. Most of the examples are done at the interactive prompt.
The chapters are well laid out and progress rationally: the separate chapters on Numbers, Strings, Lists, and Dictionaries are followed by Control Statements. Eventually Modules, Classes, and Exceptions are introduced.
At first impression, the visual quickstart layout is mostly wasted here. There aren't many screenshots to show. Most of the visuals are the interactive sessions explained in the surrounding text. However, the double column style of the quickstart guide flows better than a single column with examples peppered thoughout. For example, if you get the text description, you can just keep reading. You can cut over to the figures when you need more claification.
The Python book is newer, larger, and cheaper than O'Reilly's Learning Python. I think it's also a better introduction to the language. Programming students will appreciate the logical pace, and experienced programmers that are new to Python will like the well-organized chapters.
As regards to Python in a Nutshell, if you want a dead-tree reference, that covers all of the main concepts of the language thoroughly (and frequently insightfully), then this book is for you.
My father is a blogger.
Ok, so your problems with perl are how it's designed, that it can't be implemented in terms of itself (wtf?), that you have to security audit it (what do you usually do? hope really hard that it's secure?) and apparently it would be better off being whitespace sensitive. Oh and I am sure that first type functions are somehow supremely better than sub refs.
Then you proceed to sneer at the concept of "practical". Hm, can you tell me how any of that affects software development (that which we, in the real world, use programming languages to accomplish)?
Out of curiosity, when you say "The CGI space has been seemingly co-opted completely by Perl", do you believe that everyone else is just stupid, and only you can see that this awful, awful language shouldn't be used at all? Incidentally, your assertion that PHP is somehow the logical successor to Perl to completely take over webapps leaves me doubting if you are as familiar with either, as you claim to be ("smattering" is a pretty strong term, after all).
Of course Perl has it's share of faults, every language has faults, posting long diatrabes about how certain languages are useless based half on stupid cliches and half on really esoteric "problems" is a fetish even worse than being a language zealot.
be a programming zealot, learn as many languages as possible, and which one to use in a given situation.
This is all nice and dandy, but at some point you come to realize that there are only about half a dozen commonly used languages out there, and that at any one place of employ you are likely to be using only two or three of them, at most; and that at some point you have to start worrying about getting shit done (and quickly) rather than selecting a language most perfectly ideal to the task at hand; because in the end, the time they are paying you for is more valuable than your arbitrary aesthetics.
For those wondering why I took the time to answer a stupid clueless diatribe with an angry "biased" diatribe - I'm waiting for clustalw to finish running before I go home, and have little else to do :)
sic transit gloria mundi
As a grad student who may someday be teaching introductory CS courses and thinks the current C-or-Java approach is lacking, I think quite a lot about pedagogical languages. As much as I may enjoy programming in Python, I have serious doubts about its suitability in this area. Lets evaluate the languages you mention:
I think Python needs two things before I'd reconsider it as a teaching language:
As a CompSci grad student, I don't fully trust something until I understand what it's doing under the hood or see at least semi-formal justification. If Python wants to be a serious teaching language, it either needs massive industry use (Java), simple implementation (Scheme & C), or very elegant semantics (Scheme & Haskell) -- right now it is nowhere close to having any of these.
and it is doubtful that Perl will ever be re-implemented ever again. It's obvious you don't read Slashdot, or even keep up with the latest programming news. Perl is under heavy reimplementation right now. Indeed, Larry Wall publishes a new tome of information about the rearchitecture every few months. The Parrot team are working on a VM for the language, upon which other languages like Ruby are even planned to be re-implemented. Get with the times :-)
have you not tried any functional languages at all?
If pythons can eat pigs, how can they fit in nutshells? But then again, how does cowboy neal fit in that chair?
Patent: from Latin patere, to be open
Nail on the head.... I got half way thru the thing and wanted to tell him to get a room already...
Too bad an otherwise positive review got lost in a fan-boy parade.
I think it was the contrast between nutshell and 600+ pages that threw me first...then the full-frontal fandom sunk in and I signed off an any credibility.
Oh well, one man's Grey Poupon, another man's Shoe-Goo.
Granted, MORE documentation is always helpful but the """ convention itself is awesome.
you can access the text using:
modulename.__doc__
This is VERY convenient.
I can document my code --and-- give others a hook for getting additional info, generating reports, etc. It's good for outputting -help, usage, higher loglevels, etc.
I think Perl has the same mechanism, but I don't see it in common use within commercial groups.
I may be overstating the "horrible documentation" a bit also. There's bad documentation for Perl also, particulary thirdparty modules (which is what I was using for my Python example... win32 isn't exactly core Python).
Also, by "learning language" I wasn't attempting to deride Python -- which I love. It's appealing to novices because it's clean and safe to experiment with. Python just needs a bigger user base.
As to the object system: my general feeling, and I think the feeling of most people who've used both class-based and proto-based models, is that proto-based models are much more flexible and intuitive. You need a good reason to use a class-based model. Typically the reasons are either (1) speed or (2) compile-time bug-checking via strong typing. Both are good reasons.
You are complaining about the implementation of one Python interpreter, known as CPython. Jython compiles Python classes to Java classes. Anyhow, I don't share your impression that prototype-based inheritance is so wonderfully flexible and intuitive. After all, Smalltalk uses classes and is widely cosnidered to be both flexible and intuitive.
Python is absolutely not an experimental language. At the time Python was invented Javascript didn't even exist, and Javascript has hardly shown off the beauty of prototype-based inheritance. How many programmers do you know who have tried any of the other prototype languages? Python makes the same choice as Simula, Smalltalk and the various languages inspired by those two including C++, Java, C#, Ruby, Perl. On the other side of the issue we have what, JavaScript and Self (and several other experimental languages)?
I'm not saying that class-based is necessarily better than prototype-based. I'm saying that you need more evidence than simply asserting that "people who know" say that prototype-based is better.
I've actually used this sort of exception-handling at work, for an unexpected but not fatal condition in a program where next and last weren't suitable. You don't need $SIG{__DIE__} hooks, and in fact they're officially frowned upon by the Perl 5.x developers - instead, you wrap the whole thing in an "eval", which catches exceptions, then test a special "error" variable which contains the exception, or a false value if there wasn't one.
... ....
/home/smcv/foo.log line 345" to the error message, and re-throws the exception.
Catching all exceptions is bad (I still wanted my program to die on I/O errors), so you have to be a bit selective.
eval { # this is like "try"
while()
{
if($need_to_terminate)
{ # this is like "throw"
die "Terminating loop";
}
}
}
# this next bit is like "catch"
# I forget exactly what the punctuation is; I *think* it's $? you need to look at though
if($?)
{
if($? eq "Terminating loop")
{
warn "Non-fatal exception, carrying on";
# or whatever else you want to do
} else {
die; # re-throw the exception to let someone else handle it
}
}
The exceptions can be objects instead of strings, too.
I've also used this mechanism for a sort of more user-oriented "stack trace": the parse_line function (which doesn't know where its data came from) dies on errors, with a message which includes the offending line of a file, while the parse_file function catches exceptions provided by parse_line, adds something like "Error was in
(It's generally useless to users of a logfile-mangling program to see where the error happened in your code, unless they start debugging your program, in which case they can turn on Carp for themselves; what's useful is to see where the error was in the format of their input file.)
Python is a powerful language, with excellent object oriented behavior as well as good features for functional style programming. It is also quite easy to learn and use. Using Python, many programmers can improve their productivity by 5 to 10 times compared to using, say, C++ or Java. These productivity savings are real. Python is used to produce large, complex systems such as Zope. It is well worth your time to look into Python.
>...might be why the Python win32 documentation isn't very strong: it is not done by the core Python team, nor by a company that charges you money, but by one really smart guy (Mark Hammond) who, in addition to doing work that pays the bills, develops and documents the Python win32 bindings pretty much by himself.
:-)
>I think that the core Python library reference is excellent.
I back away from my statement. I'm one of those people who bitches about missing Linux manpages, or manpages that refer only to the INFO pages. I am an ass, OK?
I realize - now - there's only a small group on win32-python. For some reason I though ActiveState and others were funding efforts to make the environment better documented and more formal.
I don't know who Mark works for, but I can say he IS helping me with my question which I posted to the list. I also bought his book to further my efforts (but it doesn't cover this API in question).
I may have worded things poorly, but the intent was to say there are a lot of rough edges, and a lot of "learning" users (like me), but it would probably improve if more power/commercial users started using it. Most people on Win32 just use VB so there's tons of independent docs.
wow.
i'm fascinated by your post because i find myself *wishing* that other languages had documentation like python's. aside from java (whose online documentation just flat-out rocks, imho), i can't think of another language that has better documentation available.
i'd be very interested in hearing some specific examples that would explain your vehement hatred of Python's documentation. is it the format of the docs? do you feel the docs don't provide enough info?
in my experience (i've been using python for six years; since v1.3), the documentation is top-notch and one of the main reasons i am able to develop rapidly in the language. can you offer a more in-depth description of the problems you find in it?