Dive Into Python

AccordionGuy writes "If you've ever spent an afternoon in the "Computers" section of a bookstore going through the programming language books, you've probably noticed that most of them seem to exist only to boost a publishing company's fortunes by capitalizing on the hot new programming language of the moment. These books -- essentially glorified bookends -- seem to follow the same format, cover the same subjects and aside from the tiny flourishes that are part of each author's particular writing style, are indistinguishable from each other. Reading them, one gets the feeling that its primary purpose is to allow the author to make some payments on a car or mortgage. I have a few of these books and they're gathering dust on the bookshelf farthest away from my desk." For deVilla's review of Dive Into Python, a book that inhabits a completely different category, read on below. Dive Into Python author Mark Pilgrim pages 432 publisher Apress rating 9 reviewer Joey deVilla ISBN 1590593561 summary The "desert island" Python book

However, from time to time, you can find a programming language book that stands apart. You can tell from the way the author writes, the topics s/he covers, the unique presentation style and insight that s/he brings that the book is a labor of love. These books enjoy placement on the shelf closest to my desk -- that is, if they're not propped open beside my computer. Dive Into Python is such a book.

One thing that sets Dive Into Python apart from many other programming language books is that its author, Mark Pilgrim, didn't originally plan to make any money from it. As we often say in Open Source circles, he simply had an itch and decided to scratch it. Mark explains this in a story on his weblog in the form of a dialog between him and his manager after showing him a rough 20-page draft:

Manager: "This is really good. You could probably make some money off this someday."
Mark: "Maybe, but I'm not going to. I'm giving it away for free."
Manager: "Why would you do that?"
Mark: "Because this is the way I want the world to work."
Manager: "But the world doesn't work that way."
Mark: "Mine does."

First released in late October 2000 and published in online and downloadable forms under the GNU Free Documentation License, Dive Into Python had grown in fits and starts until 2003, when Mark declared the project closed. Even as an unfinished work, it was held in such high regard by the Python community that developers consistently recommended it; it was also included with ActiveState's Python and FreeBSD's ports distributions. When Mark announced that Apress had decided to pay him to finish the book and publish it, it became the most-anticipated book on Python ever. Even better, Apress has been gracious enough to allow Mark's world to work way it always has: Dive Into Python is still available for free download and is still under the GNU FDL.

What's in Dive Into Python

Many programming language books follow what I like to call the "Computer Science 101 Format", with the first few chapters devoted to covering basic concepts that any moderately experienced programmer already knows. Whenever I leaf through such a book and encounter a chapter that tries to reintroduce me to data types, looping or branching, I feel cheated; I'm essentially paying for a big chunk of book that I'll never read. If you've ever been annoyed by such filler, you'll find Dive Into Python a refreshing change. Rather than wasting time and trees devoting whole chapters to rehashing Computer Science 101, Mark chose to build each chapter after the first around a program that illustrates a number of Python features and programming techniques.

The programs upon which Dive Into Python's chapters are based strike a carefully-maintained balance. They are rich enough to illustrate a number of points and be the basis for some "real world" code, yet small enough to be comprehensible tutorials. For example, chapters 2 and 3 are based on "Your First Python Program", which is a mere six lines of code. However, in those six lines, you are introduced to function declarations, documentation strings, objects and their attributes, importing modules, Python's indentation rules, the "if __name__" idiom, dictionaries, lists, tuples, string formatting and list comprehensions. Within the first hundred pages, a point where many books are re-acquainting you with the "else" keyword, Dive Into Python covers the aforementioned topics as well as Python's reflection capabilities, list filtering, the "and-or trick", lambda functions, OOP and exception handling, all with enough thoroughness to be useful. After reading Dive Into Python, you may have trouble reading other programming language books because they'll seem glacially slow and fluff-laden in comparison.

For the first two-thirds of the book, Mark continues with this approach, presenting a program and then analyzing it to see what makes it tick, teaching Python and oftentimes a programming technique along the way. Each program covers useful tasks that you're likely to run into while programming and does so in an interesting way. At the same time, concepts are introduced in a way that makes sense. For instance, chapter 4 covers two topics that mesh together quite well -- exceptions and file handling -- and it does this by exploring an interesting application: a program that displays the ID3 tag information about each file in your MP3 collection. Later chapters explore regular expressions, HTML and XML processing and Web services. By the time you've finished the first two-thirds of Dive Into Python, you'll have been introduced to enough Python to start writing a wide array of "real world" applications. The book might have benefited from having a chapter covering database access, a task that's at least as common or as useful as accessing Web services, but that's a minor complaint.

While the first two-thirds of the book concerns itself with helping the reader become a Python programmer, the final third is about elevating Python programmers above mere competence. It covers useful topics (albeit rarely-covered in language books) such as refactoring and performance optimization as well as ones that may be new to even some experienced programmers: unit testing, functional programming and dynamic functions. Each chapter in this section is still based on an example program, but rather than analyzing a completed program, its evolution is traced. Although you can get by as a Python programmer without ever reading the material in this section, you'll be a much better one for having done so.

In keeping with the spirit of Python, Mark writes the chapters to present the material as completely and clearly as possible without extra clutter. If there's any additional material that doesn't apply directly to what he's trying to explain, he provides references or links to that material rather than attempting to "fatten up" the book.

The book's long gestation period, assisted by years of reader feedback and James Cox's editing has paid off. It doesn't have the rushed feel that many language-of-the-moment books have (especially the ones written by an army of authors, each one taking a chapter). As far as I know, there isn't any of the sloppiness that pervades many programming books these days, save one instance of the popular typo "teh" (and really, what truly 1337 book doesn't have one of these?).

Mark is aware that Python is likely not to be the reader's first programming language; it's more likely to be some descendant of ALGOL (or more precisely, a language that borrows heavily from either C or BASIC). He also knows that many programmers tend to misapply techniques from the languages with which they're familiar to the language they're learning. With these in mind, he's taken great care to introduce Python idioms as soon as possible. If you follow his advice, you'll be writing "real" Python and taking advantage of what the language has to offer rather than just writing Python-flavored version of whatever programming language you're most comfortable with.

Dive Into Python's Audience

The "user level" specified on the back cover of this book says "Beginner - Intermediate", which I feel is a little misleading. As I mentioned earlier, the book takes great care not to rehash topics with which programmers with some experience are already familiar and is written with the assumption that the reader is proficient in at least one object-oriented programming language. I think many programming novices would be overwhelmed with the speed with which Python features are introduced.

Experienced programmers, whether they are new to Python or are fluent with the language will benefit the most from the book. One programmer I know works with Python daily and and even submitted a patch to wxPython; even he said that Dive Into Python showed him things about Python that he never knew. If you're tired of books aimed at "Introduction to Computer Science" students, you're going to love this book. This doesn't mean that people who don't normally program can't benefit from the book: Joi Ito, who is a tech entrepreneur and not a programmer, learned enough from Dive Into Python to put together jibot, a bot for the IRC channel that bears his name. If you're new to programming, you might want to make Dive Into Python your second book or supplement it with an introductory text such as Apress' own Practical Python, O'Reilly's Learning Python or the free online book How To Think Like a Computer Scientist (the Python edition).

Conclusion

Dive Into Python may be one of the thinnest programming language books on my shelf, but it's also one of the best. Whether you're an experienced programmer looking to get into Python or grizzled Python veteran who remembers the days when you had to import the string module, Dive Into Python is your "desert island" Python book. If you're new to programming but have heard all the wonderful things about Python, make sure that this is the second programming book you read. My congratulations to Mark Pilgrim on an excellent book and authorial debut!

(Remember, you don't have to just listen to my effusive praise. Dive Into Python is available for free at diveintopython.org. Read it for yourself and if you like it, vote with your dollar!)

You can purchase Dive Into Python from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Don't forget the author's website

[Anonymous Coward]

Dive Into Mark. Lots of interesting/useful stuff.

Re:Don't forget the author's website

[Charvak]

May I also suggest using BoostPython library to embed python into your c++ program(or viceversa)

Re:Don't forget the author's website

[Pig Hogger]

Dive Into Mark. Lots of interesting/useful stuff.

WARNING! This is a link to GOATSE.CX !!!

Re:Don't forget the author's website

[mcovey]

goatse is dead. They have a new domain at ... ahem. Goat.cx. Great, now Im one of those people who links to goatse on slashdot.

Re:Don't forget the author's website

[Anonymous Coward]

Dive into Cindy at www.cindypucci.com.

She's like borderline homely.

php style documentation

[karl_marzd]

Any chance we'll get php style documentation to accompany this wonderful book?

Re:php style documentation

[timts]

well, I dont see fundemental difference of this book comparing to normal programming books

talk about freeware, why doesnot people PAY to buy a book to learn the language when he can read the tutorials and examples and learn it himself for FREE?

not to mention for guy who claims "mine does", he still cant get 1Gallon of milk for free, in OUR world.

Broken Link

[keiferb]

Here's a good link to diveintopython.org. The one at the end of the review is horked.

Re:Broken Link

[St. Arbirix]

I think the link at the end of the review was one of those /. mirrors we've all been complaining about needing so that the real link, which you've just posted, doesn't get "horked" itself.

Sad story though, the /. mirror is indeed bad and the original site is /dotted all to hell.

Anyone got a mirror?

Re:Broken Link

[Anonymous Coward]

You can find the pdf like this.

'a mere 6 lines'?

[Neil Blender]

With perl, you can learn all that with 6 characters.

Re:'a mere 6 lines'?

[Y2]

With perl, you can learn all that with 6 characters.

You're thinking of APL. Perl would take you at least 16 characters.

Re:'a mere 6 lines'?

[Lehk228]

Brainfuck does everything with just 8 charcters

Re:'a mere 6 lines'?

[saintp]

Yeah, but it sucks for posting code on ./. The lameness filter won't let me post my killer 452-character "Just another Brainfuck hacker" sigline unless I pad it with an UNGODLY amount of filter-circumvention text.

Re:'a mere 6 lines'?

[FuzzyBad-Mofo]

But Whitespace takes only three..

Re:'a mere 6 lines'?

[Lehk228]

whitespace uses three characters structually, but allows variables etc to use regular characters, brainfuck will only accept 8 different characters in source files.

Re:'a mere 6 lines'?

[Filip Maurits]

To stay on-topic, a Brainfuck interpreter written in Python:
http://p-nand-q.com/humor/programming_lan guages/br ainfuck/bf-py.txt :-)

Re:'a mere 6 lines'?

[Mr Europe]

And it includes all the documentation !

No, really, writing a lot of code in very few characters or lines is not the target, it is not good practice, it only makes code fuzzy.

Re:'a mere 6 lines'?

[rthille]

Well, sure, but that's only if you 'use English;' to make the perl more readable.

Finally!

[bblazer]

I have been waiting a long time ti find a book like this. It is a breath if fresh air. Similar (as far as fresh air goes, not writing style) to the Head First series. While the Oreilly 'animal' books take up most of my shelf space, this one will find a place there too.

Great Book

[wackysootroom]

It's the first thing I recommend to read after the official python tutorial to my co-workers who are just starting to learn python.

This book, Python in a nutshell, and the online python library reference are the 3 tools that I always recommend for python newbies

Re:Great Book

[Anonymous Coward]

I learned python using this book in the first place. I had prior experience with a lot of java and some c.

Great thing, I read it online first, which was the additional beauty of it. I have been looking for books like these for other languages I want to learn, ones that do not take 100 pages to tell you about the else statement, as the reviewer said.

Awesome

[izakage]

This book was awesome, I've been using it for awhile, and it's a really good python guide.

Re:Awesome

[Anonymous Coward]

> This book was awesome, I've been using it for awhile, and it's a really good python guide.

This was modded "informative"? Waste of mod points.

Re:Awesome

[Abreu]

Dont worry, theres an excess of mod points...

At least I get mod points 2-3 times a week

Re:Python and Perl...

[haluness]

Is there a point to this?

Not suprising; I hope the book's good

[Donny Smith]

If writing a book like that could get me $60K a year kind of job, I'd write one for free too.
(I hope the author makes enough money - I just want to point out a possible reason for doing that kind of thing).

From the article I noticed one interesting thing - his world didn't quite work out until that company chipped in some money for him to finish the thing.
The same is with music and software - if it weren't for companies and/or sponsors....

Just in case the site crashes, you should be able to get the book via eMule( "diveintopython" the current version is 5.4.)

Re:Not suprising; I hope the book's good

[janbjurstrom]

I guess you could see it that way. But I read his weblog semi-often, and from what I've learned, Mark did a sort of 'project house-cleaning' a while back (sometime after his marriage?). He talked about wanting to use his time in the most meaningful way, and therefore listed a few time-consuming things he would

a) stop doing altogether
b) keep maintaining but not work actively on
c) spend his 'new-found' time on.

I believe the Diveintopython project was put in group a). So IIRC this would mean that APress gave him an offer to finish it after he chose to abandon the project himself.

I could be mistaken but I'm too tired to check his site now.. You do it ;).

Re:Not suprising; I hope the book's good

[Jason Earl]

Dive into Python has always been a good book for some time now. The difference is that now it is available in a dead tree version, and it has had some professional editting.

His world worked out just fine. In fact, his free edition was good enough that he's getting paid to make a dead tree version while still giving away the electronic version.

It just goes to show that there is money to be made in this kind of stuff. Not huge piles of money probably, but enough to make it worth your while.

Re:Not suprising; I hope the book's good

[nessus42]

From the article I noticed one interesting thing - his world didn't quite work out until that company chipped in some money for him to finish the thing.

So? His world still worked out the way that he wanted it to. He still gives out the book for free if you don't want to pay for it. Proponents of free information have never said that the creators of the information shouldn't also be able to make money from it.

|>oug

Re:Not suprising; I hope the book's good

[Matheus Villela]

From the article I noticed one interesting thing - his world didn't quite work out until that company chipped in some money for him to finish the thing.

For what i understood his world works, he's giving the book for free. If someone is paying or not to he finish the book doesn't seen to be the question, he said that maybe he would make money but giving the book for free, he doesn't said that he would not make money.

Re:Not suprising; I hope the book's good

[4of12]

If writing a book like that could get me $60K a year kind of job, I'd write one for free too.
(I hope the author makes enough money - I just want to point out a possible reason for doing that kind of thing).

I'd bet the money making part is one level of indirection from writing the book.

That is, when you put out a resume looking for consulting jobs, etc. being able to list yourself as the author of a widely-recognized and lauded work is helpful.

Re:Not suprising; I hope the book's good

[Anonymous Coward]

So?

The grandparent post wasn't arguing whether or not money should be made from it. Instead the argument was focused on whether or not the book would have gotten finished had a commercialized entity not helped out. This is an interesting theory.

Re:Not suprising; I hope the book's good

[Anonymous Coward]

I could be mistaken but I'm too tired to check his site now.. You do it ;).

I did. You are right.

Re:Not suprising; I hope the book's good

[Anonymous Coward]

Ah, good digging+sharing. (So it was before, not after, his marriage.) /jb

a series of well planned coincidences.

[knowles420]

strange that this article should pop up today when just last night, i was digging through the local barnes & nobles looking for a good python book and went home with nothing more than another work of fiction.

i've been meaning to get further into computer programming than the basic knowledge i already have, and this book seems worthy of a purchase. i have suffered through quite a few "intro" books that do little more than teach how to code math equations and silly text manipulations.

what i am really in need of is either a series of problems to be solved (with solutions, natch) or a good book suggestion that actually makes me want to write programs.

the how-to books are easy, but i tend to get bored with huge compilations of instructions pretty quickly. perhaps what i need is a good "why-to" book. any suggestions?

Re:a series of well planned coincidences.

[bhsurfer]

Have you read The Practice of Programming by Brian Kernighan & Rob Pike? I thought it was a pretty good "why-to" sort of book that didn't spoon feed you anything, plus it gives examples/assignments in multiple languages so you can see the differences between them. If you haven't read this one, check it out. They probably have it at the library if you don't want to read it, but I'm glad I own a copy.

Re:a series of well planned coincidences.

[bhsurfer]

I meant "...if you don't want to BUY it..."

Re:a series of well planned coincidences.

[Hatta]

If you don't want to read it, they probably still have it at the library.

Re:a series of well planned coincidences.

[claytongulick]

The "Why-to" question is the core of what separates good programmers from bad.

Inadvertantly, you question strikes to the core of modern IT, it is not language specific, but it is the root driving force behind all "geeks".

For too many people, the "Why-to" is "because I heard you can make lots of money as a programmer". To answer this demand, colleges and universities churn out rank and file incompetent and ambivalent programmers, weilding their Microsoft inspired toolchest of Visual Basic 6 or MS Access, they flood the resume pool, and pollute the code base with their lazy half-hearted attempts at development, causing project failures and frustration on a massive scale and dramtically increasing the costs of corporate IT.

These are the type of programmers who react with anger and fear when anyone mentions exploring different languages or technology. Who, when confronted with a problem or issue they don't understand are willing to shrug and say "I don't know" and pass the problem off to the true "geek" on the team.

On the other hand, you have the type of coder to which the "Why-to" question is like breathing... to whom coding grants god-like powers of creation, who is willing to stay up late solving obscure problems just for the rush of satisfaction when s/he gets the answer.

To this type of coder, the question is not so much "Why-to" but more, "How could I not?". Coding is not a job, it is a system of thought, the logical structuring of the chaotic real-world into discrete lines of code.

To this type of programmer, there is nothing more exhilarating than a new project, a blank file, a clean slate, from which they can craft the perfect solution. Starting from scratch and creating from nothing is the ultimate expression of their intellect, and they judge themselves critically by the result.

This is a quality that can not be taught in a univeristy, or measured by a multiple choice exam. These are the "basement geeks" who clutter their shelves with gadgets and obscure books.

They may have started on the IRC with the classic question "How do I make a game?", or as a sysop of a dial-up BBS who needed to add functionality.

The point is, for the true coder, the "Why-to" question was answered BEFORE the language question... they had some sort of need that could only be solved by learning to code... and after that they were hooked. They constantly evaluate new languages and more effecient/elegant methods of solving their problems.

There is no book that will make you _want_ to code, first you want to code _then_ you buy the book.

Asking "Why should I program?" is similar to picking up a shovel and saying "Why should I dig?". Unless you have a need, there is no point, and you will never understand why all those ditch-diggers keep debating the finer points of different shovels. You are out of context. For you, the answer is "You shouldn't".

That is, until you need a ditch.

Re:a series of well planned coincidences.

[knowles420]

That is, until you need a ditch.

that was awesome. it was fun to read and insanely informative. it also made me question why i want to take my programming knowledge further. why? because it's fun to create something (that works!) out of nothing. it just feels like there is such a huge gap between what i know and what i want to know that i'll never catch up.

i'm looking for a finger pointing in the right direction so i can go in that direction, not to get all caught up with the finger.

i also don't want to end up in a situation where i need a ditch and can't operate a shovel, let alone a back-hoe.

Re:a series of well planned coincidences.

[justasecond]

Unfortunately I have. The authors have no humor and a totally unengaging style, and the book comes across nothing more than a long apology for C. It's full of pointless trivia on the language-of-choice for the PDP-11 -- completely uninteresting to anyone working in a more modern environment. (Oh, but the little weiner dog on the cover is cute.)

Try The Pragmatic Programmer for a more up-to-date and interesting "craft of programming" book, especially if you are fortunate enough to not be stuck working with creaky old C.

Re:a series of well planned coincidences.

[bhsurfer]

Oddly enough I kind of liked the style of the book. Perhaps I just tend toward the unexciting, I dunno. I'd like to think that's not the case, but wouldn't we all? I suppose this is just a good example of why it's nice that there are options in reading -> different folks have different opinions about what's "boring" and what's not. I stand by what I said before, I thought it was a pretty good book. Maybe I just got pulled in by the weiner dog...

I've heard that the Pragmatic Programmer is good too, so I think I'll give it a read when I get some time. Grad school ends for me in December, so I guess January will have to do.

Re:a series of well planned coincidences.

[justasecond]

Pragmatic Programmer is, well...more pragmatic. Good real-life advice. For me, it was right up there with Design Patterns, Code Complete and About Face in terms of changing the way I approach programming.

But, you're right: different tastes=good. I know many other people enjoy Practice of Programming so maybe it's just me...

Re:a series of well planned coincidences.

[mewphobia]

Okay, then what do you want to code? What do you want to know?

All you have to do, is try to do it. Focus on a task at a time.

What is a task you want to do, that you have (or nearly have) all the skills to do. Then do it. You'll learn heaps from that - programming never goes as smoothly as anyone would like.

You'll get ideas for improvments and additions, and the next thing you know, you'll have learnt heaps more than you thought you would have.

If you run out of ideas, try implementing an RFC. Make an ident daemon. Pretty easy stuff, but you'll learn heaps.

if you're ever in a situation that you need a ditch and you can't operate a shovel, then you'll have two choices.
1) Pay someone to dig you a ditch.
2) Learn to use a shovel first.

That applies to all of life.

Re:a series of well planned coincidences.

[bhsurfer]

yeah, for sure. if NOBODY wants to read it then it's likely they'll always have a copy there, alone, gathering dust, binding in beautiful condition, weiner dog aging gracefully in the cool darkenss of the stacks until some space conscious librarian has finally had it with this damned freeloading book anyway and it finally makes it's way to the periodic book sale where some unsuspecting victim will pick it up for a fraction of what i paid for it...

Re:a series of well planned coincidences.

[Anonymous Coward]

And also Jon Bentley's "Programming Pearls". It doesn't matter that it is primarily written for C audience; it has interesting insights into the approach to solve problems. The first chapter itself took me off guard in the novelty of the problem solving approach.

--Hemanth P.S.

Re:a series of well planned coincidences.

[Hockney Twang]

To this type of programmer, there is nothing more exhilarating than a new project, a blank file, a clean slate, from which they can craft the perfect solution.

I actually got a little misty eyed when I read that.

Re:a series of well planned coincidences.

[Profound]

I have read both Practice of and Pearls and noticed a significant overlap in content (even to the extent that both use as an example text generation using Markov chains). Both are good but I had more fun reading Bentley and he got into more hardcore algorithms etc.

Re:a series of well planned coincidences.

[Anonymous Coward]

Y'know - I keep hearing that from geeks. Being a geek myself, I think it's full of shit.

There are plenty of people for whom "why-to" is a perfectly reasonable question - they have a lot of problems that would be great for them to solve with programming, and they'd be delighted to do so for themselves, if geeks like you would get off your fucking high-horse and tell them what they could use it for IN THEIR OWN LIVES!

I agree with the OP that it's nice to see a book that addresses real world problems and suggested ways people can use this stuff. What we really need next is a book for the folks who don't program yet, but would if they only knew that it would be useful for stuff they already want to do but just didn't realize they could program for themselves.

Programming is presented as this wizardry that requires years and years of locking yourself in the basement studying, sacrificing everything else: family, social life, hygiene. Get over it!

Python means that real people can learn to program for stuff that *they* want to do - and they don't have to give up the rest of their lives to do so.

Yeah - they may not meet *YOUR* criteria for "true" geekhood, but they can still learn to program perfectly well.

Boy, did THAT ever go wrong!

[Anonymous Coward]

Time to back off on the cold medication! Mod to you hearts' content :(

Re:Boy, did THAT ever go wrong!

[Anonymous Coward]

i don't care if i can do it with sed, awk and grep - i can do it with perl too :) - if you do it with those then your the m3g@ 1337, aren't you?
come down man - world is evoluing, even if you don't like it (or cannot follow)

My 2 cents

[KillaKen187]

Python is great very robust, easy to use, and capable to do a lot of things quickly. I also know that Mark is a great guy. I have sent him emails on trouble I have had on things and he has given great responses to them. Very upstanding guy. All blessings to Mark Pilgrim and his contribution to OSS with Python.

Re:My 2 cents

[Paulrothrock]

I don't know... I don't want a language that sees a difference between a space and a tab. If nothing's there, then it should mean nothing.

But, then again, I'm lazy, impatient, and full of hubris.

Re:My 2 cents

[gipsy boy]

If you hate that about Python, try Ruby.
I went berserk for Ruby first, in much the same as people here for Python..I think my first script in it was an irc quiz bot. But for more advanced things than simple parsers, I like Python better. It's also faster and has a lot more support in the form of wrappers for other libraries. I pretty much gave up on Ruby now, although it's a pretty language.
I'm quite sure you can do the things at the end of chapter 17 in Ruby too though, they're very similar in that respect.

Re:My 2 cents

[cpeterso]

If whitespace has no meaning, then why does your code include whitespace?

Re:My 2 cents

[William Tanksley]

Try it. You'll like it.

And anyhow, every programmer knows the difference between a space and a tab. And that neither one is "nothing". Anyone who tells you otherwise should try looking at C code written by hardware engineers someday (NO indentation at all).

The beauty of Python is that merely doing the responsible thing -- indenting your program -- makes it work. Someone who wants to "just make it work" (like, for example, a hardware programmer modifying C code) will automatically write approachable code; they HAVE to. No burden is added, since Python _replaces_ tracking curly braces with tracking indentation. And indentation is FAR more noticeable and visible.

-Billy

Re:My 2 cents

[Anonymous Coward]

You obviously haven't read my code!

Re:My 2 cents

[arkanes]

The thing that sucks about Python and it's indentation-awareness is that it makes it very hard to keep code intact on web pages, in emails, etc. With C (or other) languages, the indentation is for human-readability only and is trivially recreated mechanically. With Python if a file gets borked up you have to fix it by hand and it can be a real pain.

The surprise factor of mixing tabs and spaces can be annoying, too.

I've come to like Python a lot and I do most of my coding in it now, but I still think the indetation thing was the wrong choice.

Re:My 2 cents

[Anonymous Coward]

I normally defend Python like a mid level zealot. However, today I spent 6 hours tracing shitty little indentation errors in Python imbedded in a web form. Really pissed me off. The worst part, is the code worked fine, until I had to place the resulting HTML output into a table, then it all fell apart. Really gay. That rant out of the way, I really do like Python, and find it fun and easy to code, most times.

Re:My 2 cents

[ahdeoz]

Is there a patch to python that can alter that syntax?

Re:My 2 cents

[Anonymous Coward]

I am not sure why so many people keep bringing this up as a major issue.

1.) Python uses indentation for delimiting blocks.
2.) If you mix tabs and spaces there is no way for the interpreter to know what a tab meant in your editor (2/4/8 spaces?).

Re:My 2 cents

[Anonymous Coward]

Python and it's indentation-awareness

"its".

Re:My 2 cents

[William Tanksley]

Is there a patch to python that can alter that syntax?

Yes. Actually, it turns out the code's been in Python for a long time, but Guido only recently started documenting it, and like the metaclass hack, it has a lot of untapped potential.

Unlike the metaclass hack, it's surprisingly simple. :-)

Here's a typical Python function in the old style:

x = 3
if x == 3:
print "Hello"

Here's one using a bit of the new, optional syntax:

x = 3
if x == 3:
#{
print "Hello"
#}

As you can see, this offers all of the advantages of curly braces. In fact, it only starts here. There's much more; so powerful are these "hash" prefix characters that they can be used to form other languages' block delimiters as well. Here's some examples:

Ada:

x = 3
if x == 3: # then
print "Hello"
#end if

Ruby:

x = 3
if x == 3:
print "Hello"
#end

A plethora of possibilities is present. Alliteration initially unintentional.

Some are working on making the "hash" syntax marker work with natural language, to form a type of code documentation we're calling "comments" (named after a similar, rarely used construct that appeared in Fortran-77). These people are misguided, of course, and such constructs will certainly never be widely used; but in theory such capabilities would add a lot to a language.

-Billy

Re:My 2 cents

[migurski]

If whitespace has no meaning, then why does your code include whitespace?

For the same reason it has comments. I don't expect those to be meaningful to the interpreter or compiler, either.

Re:My 2 cents

[angel'o'sphere]

Well,

I don't like Python, I don't program Python. but EVEN *I* know that there is a Python script which reformats a Python file by replacing indention with {} or what ever the BEGIN/END markers in python are.

Such a file can easy be mailed or published on web pages and there is a similar script reformitting a Python file from BEGIN/END markers to an indented version.

angel'o'sphere

Re:My 2 cents

[TuringTest]

But Python is a language intended to be meaningful to humans. That's the difference with your usual programming language, and that's why Python needs the tab/space awareness.

Re:My 2 cents

[migurski]

But Python is a language intended to be meaningful to humans.

True... but there's nothing stopping me from using meaningful (to humans) whitespace in other languages, too - it's a cornerstone of any programming effort to be clear, concise, and verbose in your explanations, so no argument there. I'm not totally comfortable with Python's explicit enforcement of white-space without brackets or parentheses or what-have-you. Just the simple fact that I can't use my editor to automatically select a block by paren-matching, for example, really bugs. It's cute that python's syntax is so crisp-looking, but sometimes all that matching-char ASCII gobbledygook in other languages is truly helpful.

I dove into python...

[bludstone]

...and got covered in spam. ...bloody vikings

Re:I dove into python...

[Anonymous Coward]

That's because its not supposed to be a Spanish Inquisition.

Nobody expects the Spanish Inquisition!

Sweet Jumping Jehovah...

[Anonymous Coward]

The first two posts modded up to 3+ on this article, and BOTH of them are pimping their free iPod links in their sigs.

Moderators: Down with the "free iPod" spammers!

Sure, I could turn off sigs, but occasionally people actually do have interesting/informative links. But these iPod referral crap links are just too much.

Now go ahead and mod me down. Argh.

Joy of programming...

[powerlinekid]

A few years back I needed to develop a program to download all of UserFriendly's archives (ok need is a strong word but thats not important). At the time I was familiar with the normal languages; java, C, C++, etc. I had heard about Python and figured this was something I could use to learn it.

I was blown away. Having never touched the language within a couple of hours of going through the online documents I had picked up enough to write the full script. Once that was done I didn't want to stop. I found Python to be an absolute wonderful language that made programming fun again. Since then I've written my fair share of Python apps to do nearly everything. Infact anytime I need a program that I can't quickly find or isn't out of it's realm, it gives me an excuse to use Python. A lot of the time I lookup a way to do something and sit there smiling to myself going "now thats freaking cool".

I haven't read this book, but from my experience Python is an awesome language. I'm sure the Perl people feel the same way about their language. To me Python feels clean, flexible and productive. Most importantly its fun.

Re:Joy of programming...

[Osty]

A few years back I needed to develop a program to download all of UserFriendly's archives

You're either a masochist, or this was some form of cruel and unusual punishment. Perhaps you could enlighten us as to why someone would willingly subject himself to UF's brand of mind-numbing "art" (requires quotes because I can't call it real art with a straight face) and "humor" (same reason for the quotes).

Re:Joy of programming...

[DarkFencer]

Yep, the above poster was one of the people who get me to look into python. I love it now. I hate when I have to go back and look at perl code that I or others have written now.

Re:Joy of programming...

[Anonymous Coward]

Amen brother.
Even after working at an ISP for *way* too long I still find UF about as funny as a dose of the clap.

Re:Joy of programming...

[Anonymous Coward]

Try Ruby next..

I had the same feeling going from Ruby to Python that I had going from C to Python..

that feeling of "whoa, that's *it*? I just accomplished my goal with one line of readable code?"

At this point I consider Python the "java" of the OSS world, better than whatever I was using 5 years ago, but not very interesting.

Re:Joy of programming...

[Anonymous Coward]

I get it, it's just not funny. I actually feel bad for those comic characters, silly as it sounds.

Re:Joy of programming...

[Miffe]

Wow, You to.

Re:Joy of programming...

[powerlinekid]

haha

Well this was a few years back when I had just started doing help desk and thought it was hysterical. Now it can be rough, although Illiad does manage to slip in the occasional gem.

Re:Joy of programming...

[Lodragandraoidh]

My language experience going back 24 years:

Basic, Fortran, Assembly (Intel and Sparc), Pascal, C, C++, Java, Lisp, shell(sh,awk,sed), Perl, and most recently Python. (roughly in that order; I saw some COBOL code once when a young programmer, but was immediately repulsed - thank heavens)

I actively use Perl and Python myself for everything now for several reasons:

1. All of the machines at my job (800+) are all preloaded with Perl - so I have to use it for automation (better than shell scripts particularly for mission critical one-off applications that have to be fault tolerant but deployed at the whim of our marketing and operations staff). If I didn't have to maintain Python myself on all of those machines, I would port everything over to Python in a heartbeat. However it took me 2 years to get management to agree to loading Perl in the first place - and there is no reason to incur the costs associated with validating a new scripting language for use in our production environment. So I live with it - and keep the footprint small.

2. For all other tasks - I use python.

Some neat things fall out of python that even as a neophyte I can appreciate:

a) clean syntax (if I only had all the time spent finding dangling semicolons in perl, I could take a sabbatical)

b) full featured web development tool (Zope - provides a framework for developing and hosting full service applications - designed to make building products to run under Zope easy - seperates the presentation from the logic using ZPT cascading style sheets and DTML for presentation, and python for the program logic [unless you are masochistic enough to depend upon DTML alone] - has a built-in database for managing Zope objects - and built-in httpd and ftpd servers - which can be further frontended using Apache as desired - can communicate with other databases [oracle, ODBC, postgreSQL, etc... many database plugins available] - has a large library of predeveloped products [modules for you perlmongers] that you can load and be up and running, or modify to your heart's content - and did I mention that its GPL'd?)

c) platform independent (just as with java and perl, python scripts can run without modification on many operating systems - keeping porting costs down to a bare minimum.

d) built-in documentation functionality - not as full featured as Perl's perldoc - but I might not have found the right product yet to do that (ideas anyone? or, is this a python project waiting for me to jump on - perhaps something that ouputs XML?)

The only drawbacks (and I use this term with trepidation - because they can seem positively refreshing after 10 years with perl) that I can see are:

A. Does not have the sheer amount of user contributed products (modules) when compared to CPAN^. Of course I wouldn't judge the quality of my carreer based on the weight of all of my program printouts either. Quantity does not equate to quality.

B. Slower than Perl and Java. Again, something I can throw hardware at to rectify. Squid goes along way to making web pages generate faster too - so you can ameliorate some of the problems without having to kill yourself.

C. Sometimes it takes longer to find resources online than with other languages because of the difference in popularity. However, the time spent needing to refer to reference material for Perl and Java is many times larger than the time spent doing the same with Python.

D. Because of my long experience with Perl, I find myself immediately jumping to a predetermined algorithm/function that is implemented differently in Python and thus create syntax errors in my code. This last is really a personal problem that time will erase.

My whole programming paradigm has changed. The advent

Re:Joy of programming...

[slittle]

B. Slower than Perl and Java.

Got psyco?

Re:Joy of programming...

[Lodragandraoidh]

Sadly, I am running Sun boxen (Solaris) - not supported by psyco. :(

Re:Joy of programming...

[slashpot]

Comics don't have to be funny - hell - I don't think its funny. My point (spelled out for the dubmasses) was that people read UF because they can identify with it.

Same reason people read Dilbert - or any of the sunday comics - once you identify with a comic your more likely to follow the story line.

As to the assholes who modded me down as a Troll and up'd the Troll fucker that started this thread bashing UF... I can't help it my slashdot id is a whole lot lower that yours (and my dicks bigger to). Wannabel33tFuckers.

Python: The Movie

[PissingInTheWind]

For all of you who still haven't seen it, I strongly recommend this 'propaganda' gem from the Python community:

Video: Introducing Python

Features GvR, ESR, etc.

It's so bad it hurts. You'll want to show it to all your friends.

Re:Python: The Movie

[vivek7006]

It's so bad it hurts

Oh come on. I think t was really funny. Note that this movie was aimed for high-school kids.

Re:Python: The Movie

[smallpaul]

It isn't so much from the Python community in general as from a particular set of high school students. You're picking on high school students you meanie!

Re:Python: The Movie

[Anonymous Coward]

I enjoyed the professional commentary, but otherwise this really gave me a headache.

It's this kind of geek labeling that makes me feel bad as a programmer. We're not all jolt drinking, Star Trek loving, skinny, pale skin, glasses wearing, no social or love life having, ex-hippie freaks of society.

I'm 6'4" played football in high school, and was an ACM world finalist.

Re:Python: The Movie

[Webmonger]

No wonder you're posting as an Anonymous Coward.

Re:Python: The Movie

[Anonymous Coward]

If I had seen that in high school, I never would have gotten into programming.

I'm scared.

Re:Python: The Movie

[Anonymous Coward]

Yes, he is a meanie. I didn't realise how amazing Python was until a saw that cool hippie guy and realised, "Hey, that's me!". There's nothing like seeing someone like yourself enjoying life to the full to make you realise just how sad and lonely life as a Lisp programmer really is.

Seriously, this video has changed my life. If only more people would watch it. There's a stereotype to fit the entire Slashdot audience I'm sure. They all have one thing in common though. They're all happy. You can tell by the smile on their little faces. Except that Eric guy. He looks a litte glum. Poor Eric.

Downloaded and loved

[GoClick]

I've been using Python for years and I like to read all the books I can get my hands on. Yeah I'm one of those Python Zealots.

This book is quite good, although the PDF has odd little gray icond behind some of the text for some reason. It doesn't bother me really but I'm not sure what their for.

The book does have some great chapters and some not so hot ones but it's probably not the best read if you don't already have some Pygramming (that's Python Programming) experiance.

Lots of fun and by far one of the best free books I've ever read.

Re:Downloaded and loved

[cryptochrome]

I've been programming pretty much exclusively in python lately - but as my programs have become more advanced the downsides are becoming more obvious. I ended up writing a python extension in C (painful when you've been programming in python). Specifically, you can't compile python - and interpreted it's just too slow for anything computationally expensive. Also you have to load the interpreter, (or embed w/extra modules) it's slow and uses more memory than it should.

PyObjC is a start, but the little differences in how things are implemented between Python and Objective C makes using it a bit difficult to learn. Plus it's mac-only. Pyrex looks interesting but I've yet to try it. PyPy seems to have been in development forever.

For starters, I think the distutils module needs an option to produce a package/binary that is runnable on any similar machine whether python is installed or not.

Python is amenable to a variety of programming styles, is very readable, has well developed libraries, and is quick to write. But I've found myself wanting more than it can deliver, in terms of raw speed and number-crunching power, and even occasionally the need for typing and assignment by reference. I hope they find some way to deliver it someday, or make a language that retains the ease and efficiency of python but is also compilable.

Re:Downloaded and loved

[eidechse]

I ended up writing a python extension in C (painful when you've been programming in python).

Bridging between languages with totally different type systems is usually tedious. Try SWIG, or PyRex, or Boost Python.

Specifically, you can't compile python - and interpreted it's just too slow for anything computationally expensive.

Are you trolling or just ignorant? Sorry for being harsh but this statement is wrong, misleading, and overly broad all at the same time.

First, Python is NOT interpreted (yes I know some of the docs refer to the "Python Interpreter"...read on). It's compiled to byte code and then executed in a VM (just like Java and C# and etc). The closest thing to interpretation is using the interactive environment or maybe (if you really want to stretch) using 'exec' or the other functions that run strings as code. Even then it's still compiled and run in the VM. Just because there's no compile button or makefile doesn't mean compilation isn't happening.

As for being to slow because it's interpreted...re-read the above. If you think it's to slow because it's not native the same goes for Java and C#. Either way, what do you mean by "computationally expensive"? What application, specifically, have you found Python to be too slow. Are you talking about built-ins or libraries? A good portion of anything where speed would be a concern is already written in C. Highly optimized C at that. This is not to imply that you should write a 3D rendering engine in Python, but to point out that saying "it's too slow" without qualification is an old, tired, and disproven argument.

Also you have to load the interpreter, (or embed w/extra modules) it's slow and uses more memory than it should.

Again, what SPECIFICALLY are you talking about? Are you trying to embed or extend? If there are "extra modules" why don't you rebuild Python without them? How much memory was used in what situation and why do you think it was too much?

...even occasionally the need for typing...

Ugh...now I'm really starting to think this is just a troll...that notwithstanding:

Typing? Python is a strongly and dynamically typed language. If you don't know what that means than you shouldn't use "typing" as a reason for anything.

and assignment by reference.

Yet again, what are you talking about? Python always uses reference semantics.

Re:Downloaded and loved

[cryptochrome]

Try SWIG, or PyRex, or Boost Python
I started with SWIG, and eventually decided it was easier to just write my one function myself instead of trying to learn all the ins and outs of swig. I didn't discover pyrex 'til later, and haven't really looked into boost.

compiled to byte code and then executed in a VM
Then I'd prefer that it not require a VM.
If you think it's to slow because it's not native the same goes for Java and C#.
Correct.
to point out that saying "it's too slow" without qualification is an old, tired, and disproven argument
The inner loop of my program as written in python was too slow for my purposes, therefore I rewrote it in c. Possibly I could have sped things up using some of the tricks I used to get around the lack of dicts in c to speed up the python problem as well - maybe I'll try it sometime, but I'm pretty much done with that program.

For the record, I think that saying "It's fast enough with modern machines" is a patently untrue argument that I hear far too often with less efficiently executed/compiled languages (Haskell for instance); a program may not be performance-demanding, but it will still be using system resources that are frequently in short supply.

what SPECIFICALLY are you talking about
That if I want to put a python program on a different computer than my own I have to either a) ensure that python and the necessary modules are already installed and are of the correct versions or b) install python of the correct version and necessary modules (often not an option) or c) make a distribution that includes all necessary modules, up to and including the standard ones, via freeze or bundlebuilder or py2exe.

That last option is not bad - it allows you to make single executable binaries/apps. I was under the impression it worked somewhat differently from that based on prior versions.

By computationally expensive, I mean analyzing many genomes for repetitions, and recording their frequency by distance and length, over a hundred times each. Hence the need for the inner loop to be as fast as possible, as most genomes took a about a day to process even with my c routine - when it was written in python they would have taken over a week each.

typing
What I meant to say was compile-time rather than run-time type-checking, i.e. there's no way to declare what type an argument should be and have inconsistencies be caught before you run.

Re:Downloaded and loved

[JohnFluxx]

I've been looking at learning python for a while.. Just one thing has been holding me back - doing GUI work with it.
I don't really understand how I would do a kde GUI with python. I assume I would use pyqt and pykde bindings. Then I have two toolkits in my program to switch between - qt's and python's? So which do I use?

Also I couldn't find any good help on python + kde. It seems that for a totally newbies to python it's going to be a bit difficult to get up and running. And kdevelop at the moment doesn't seem to support python yet :(

I keep meaning to actually give it a try. I just wish there was a pykde book, like there is a pyqt book :)

I beg to differ with AccordianGuy's assessment

[BuzzLY]

As an author of one of those "bookends," I'd have to assume that AccordianGuy has never written one. The money is certainly not a huge draw -- it's not enough to live on, for sure. I can't speak for all authors, but for me, it was an opportunity to do two things that I love - play with one of my favorite programming languages, and write. Perhaps it really is crap, but at least I enjoyed writing it!

Re:I beg to differ with AccordianGuy's assessment

[Gaetano]

I agree. That part of the review seemed ill-informed. May I ask which book you wrote?

Re:I beg to differ with AccordianGuy's assessment

[AccordionGuy]

Are you sure I classify your book among the "bookends"? I never made reference to any specific books.

Hey, if you got a book deal and got to write about one of your favourite programming languages, you've gone farther along the publishing trail than I have. More power to you! I'm merely saying what kind of books I like.

Re:I beg to differ with AccordianGuy's assessment

[BuzzLY]

I didn't mean to imply that you called my book a bookend :)

Beginning PHP, Apache, MySQL Web Development is the name of the book -- not a plug, just answering the question. I only wrote 35% of the book -- it was a collaboration (Wrox Press book).

I'll be the first to admit that my book is not necessarily the best one about PHP. But hey, it was fun to write, and it looks cool on my resumé :D

Python, prototyping, and gmailfs

[HungSquirrel]

The developer of gmailfs wrote it in Python. He claims it is his first jump into Python, and apperently he learns fast--two days from zero Python knowledge to a working prototype of gmailfs. Odds are decent that he learned from this book. If everything people are saying about Python is true, I might have to give it a go. I can already tell from Chapter 2 of this book that it's my kind of programming guide, so I shouldn't have any trouble.

Re:Python, prototyping, and gmailfs

[Anonymous Coward]

That's the weirdest endorsement I've ever seen for a book. "This guy, who's not remarkably good at X, but claims to have picked it up quickly, may or may not have learned X from this book. However, I'm assuming that he did! What a great book!"

Re:Python, prototyping, and gmailfs

[nkh]

I hate to troll but Gmailfs what not the most difficult project ever. It is written on top of the libgmail library (which was the hard part to write).

Re:Python, prototyping, and gmailfs

[platypus]

I'd say that FUSE, which is the other package gmailfs is very dependend on, is even a bigger programming venture. One day I'll have to take a sharp look at it.

Re:Python, prototyping, and gmailfs

[Anonymous Coward]

Indeed, it's like saying, wow, the guys at Apple did a great job making Safari using Cocoa. The must have read "Learning Cocoa" from Oreilly. Well, maybe but we can't be sure of that, so how can this be relevant to the book necessarily?

Re:Python, prototyping, and gmailfs

[idlemachine]

Still, going from nothing to proof-of-concept in 2 days does say a lot about the usefulness of the language, IMO :) Whether that's due to the accessiblity of the language, comprehensive libraries or the convergence of both isn't as important, to me, as the fact that it's possible.

Re:Python, prototyping, and gmailfs

[follower-fillet]

As the author of libgmail--while I appreciate the comments of the parent--I have to agree that FUSE is a bigger programming venture. :-) (Which is not to say libgmail wasn't an effort...)

Having said that, I do feel obliged to point out the author of GmailFS did say (quoted with permission):

"libgmail is the main reason Gmailfs is Python." :-)

--Phil.

Apress

[static0verdrive]

How very, very cool of Apress. Nice to see - now I'll probably buy the book to show them the GNU FDL can work - you can make money with open works.

Re:Python and Perl... (take two!)

[Anonymous Coward]

How do you do sql db access via those tools? What about multithreaded/multiprocess tcp/udp servers?

Re:Python and Perl...

[Anonymous Coward]

What a Tool. What drives awk, sed grep with ease? It's bash, ksh, csh, or what ever the hell shell you use.

Re:Python and Perl... (take two!)

[Anonymous Coward]

Python and Perl are for amateurs

YEAH! Google is just a bunch of amateurs, using languages like Python! OTOH, it is now your duty never to use Google anymore. Do you think you can do it?

Example 2.6

[Anonymous Coward]

Why is this example function named 'fib' when it computes the factorial of a number, not the nth fibonacci..?

Re:Example 2.6

[Scaba]

It's called 'fib' because he's lying to you about its purpose.

Re:Python and Perl...

[static0verdrive]

I like your style clown-shoes, but isn't OSS all about choice? I agree with you, but let the proverbial baby have his bottle; shit, if I wanted NO choice I'd use windows!

Thoughts of Python...

[Golthur]

I wasn't a Python Zealot(tm) until I tried it... in fact, just the opposite.

When I heard about the whitespace-is-significant, I had nightmarish flashbacks of MVS JCL (thoughts of which still cause me to twitch uncontrollably). As such, I refused to even look at Python seriously for quite some time.

However, that being said, once I actually did get over my (admitted) prejudice and gave it a serious test - it earned an official "WOW", something which few languages have ever done for me. Never mind that I was as productive while just learning Python as I am as an expert in any of the other languages I use regularly.

Now, I'm an official convert. Python gives you all the tools you need, but never forces you to use the wrong one for the job.

All I need to do now is find a shop that actually uses Python...

Re:Thoughts of Python...

[ashultz]

Interesting to hear this, because that is exactly my reaction to python.

"Wow, sounds interesting but when you cut and paste chunks of don't you run the risk of shooting a hole in your foot and then somehow choking to death on the fountain of blood?"

I'd be interested to know whether you still dislike the significant whitespace, or have somehow come to like it. And if so, why?

Re:Thoughts of Python...

[nkh]

Indentation to create blocks is stupid when you begin to learn Python. And after a day or two you don't think about it anymore. The language is cool, and tabulation is just a detail when you've got OOP, regexpes...

Re:Thoughts of Python...

[Anonymous Coward]

"Wow, sounds interesting but when you cut and paste chunks of don't you run the risk of shooting a hole in your foot and then somehow choking to death on the fountain of blood?"

Get a smart text editor; one that can handle this. When I cut'n'paste Java code in Eclipse, for example, it makes all of thew whitespace perfect. Indenting and outdenting code should be no more than a few keystrokes. ("<<" or ">>" in vim's visual mode. ctrl-[ or ctrl-] in Eclipse. etc.)

This is something I always did in other languages anyway, so Python's whitespace handling never bothered me. Improper whitespace drives me nuts (too hard to read), so a language that enforces proper whitespace is perfect to me.

Re:Thoughts of Python...

[iguana]

I use it daily in my job (http://www.mobl.com/handheld/cradles). Our test fixture (tests new boards coming off the line at our custom manufacturer) is written in shell scripts and Python on an embedded SiS-550 Linux board running 2.4.9, uClibc, BusyBox, etc.

I rewrote our Windows-based management tools into Python for myself. Using that protocol library, I've sent quick and dirty py2exe wxWindows programs to customers. "Just unzip and run." Unless they look closely, I'm sure they don't know (and don't care) they're running Python apps.

It's not exactly "in your face" like Zope but it glues together my day.

Re:Thoughts of Python...

[Anonymous Coward]

Yes, it's a PITA to copy and paste python from the web, but emacs will make it more or less painless. The whitespace thing sort of fades away at that point, and you're left with even more irritating things that are fundamental about python. Like crippled lambda, read-only closures, and syntax that really isn't all that flexible (want to create new block structures? too bad). Good language, but I can't help but think that a couple hours of tooling around with syntax macros in lisp or scheme would produce nearly identical results with a much more powerful runtime to boot.

Re:Thoughts of Python...

[Cro Magnon]

I'm still a beginner in Python, but in languages that ignore whitespace, incorrect indentation is the quickest way to turn me into a raving madman! A language that FORCES you to indent properly is GREAT!

Re:Thoughts of Python...

[ashultz]

I tend to use emacs, which can handle indenting in any of twenty different ways, but anyway...

My conceptual problem is that when I cut and paste a block of code to a new place, there is no acceptible default indent level - I might want to end the previous block and start a new one, or I might want to stick this under the if, or maybe it should go outside it, and there's no way for the editor to automatically know and do the right thing. I often in emacs select the whole file and tell it to correct the identation... which is impossible in python?

Re:Thoughts of Python...

[Golthur]

I'd be interested to know whether you still dislike the significant whitespace, or have somehow come to like it. And if so, why?

The honest truth is that I don't even notice it. I use VIM, which handles Python whitespace admirably - although any other reasonably Python-aware editor would do (not to start a VIM vs. Emacs flamewar or anything). Actual Python code is written either spaces-only (usually) or tabs-only (more rare), so the dreaded mixed-spaces-and-tabs situation rarely occurs in practice. I've never had it happen to me, personally.

Re:Thoughts of Python...

[grumbel]

Incorrection indention is corrected with almost a single click in any better editor, I really don't see it as a problem unless people are using notepad to write their programms of course.

The problem with pythons whitespace is that it causes quite a bit more problems than it solves in my view. Especially when one refactors function and classes (make a local function a global or visa verse) it is just way to easy to break the code, since once you have broken the indention you have broken the programm and its quite hard to recover from that (no hint left at where the code block ends). That whitespace issue was together with the lack of proper closures the reason why I switched from python to ruby.

Re:Thoughts of Python...

[tjkslashdot]

All I need to do now is find a shop that actually uses Python...

Google, ILM, and NASA all use Python. See the Python Quotes page.

Re:Thoughts of Python...

[Anonymous Coward]

Emacs python-mode makes adjusting indent levels for blocks trivial:

Paste or select a block, C-> indents, C- outdents

Don't bother selecting your whole file & re-indenting the whole thing.

Note that with a brace/delimiter oriented language, you often have to manually insert/delete delimiters...

C-M-\ (indent-region) still works to adjust indent levels (i.e., if somebody indented blocks w/ 2 spaces and your setup is 4 spaces), but it won't move code between blocks.

Entering new code in python-mode is also easy - it knows when to begin a block, to end a block you just backspace once-per-desired-outdent level.

TAB still indents a line to where emacs thinks it should go, backspace jumps back an indent level.

But the real power of python-mode is in executing code blocks in an interactive interpreter:
C-c C-c to execute the buffer
C-M-x to execute a function/class definition
C-| to execute the selected region

Nice. :-)

kb

Re:Thoughts of Python...

[NullProg]

A language that FORCES you to indent properly is GREAT!
Then you need to look at RPG.

The more things change, the more they stay the same:)

Enjoy,

Re:Thoughts of Python...

[ashultz]

Huh. Interesting to know. It's one of those things that seems very scary, and all the various posts about how you can use various indent commands are like saying that you can always move your foot when you point the gun at the ground, not actually helpful. It's good to here from someone who had The Whitespace Fear and now just doesn't care.

Python will have to go next on the list.

Re:Thoughts of Python...

[Anonymous Coward]

My conceptual problem is that when I cut and paste a block of code to a new place, there is no acceptible default indent level - I might want to end the previous block and start a new one, or I might want to stick this under the if, or maybe it should go outside it, and there's no way for the editor to automatically know and do the right thing.

A good algorithm is just to put the first line at the current indent level and follow the indent/outdent patterns from there. So you position the cursor correctly and then it goes from there. If you make a mistake, you just hit the indent/outdent button after pasting.

I often in emacs select the whole file and tell it to correct the identation... which is impossible in python?

Which is unnecessary in Python. The indentation is always correct, and that's that.

Re:Thoughts of Python...

[BasilBrush]

Such a reformatting command will only reformat you YOUR preferences, not necessarily anyone elses. There is no universal standard for an editor to reformat to. Braces on lines by themselves itself, or hanging on the end of the line above? Indent the braces with the code, or just the code itself?

When you are maintaining code that you didn't write on a version control system, you almost certainly shouldn't be changing code just to reformat it. It causes diffs that are unrelated to meaningful changes in the source, and there is a danger of 2 or more coders flip-flopping between their personal preferences. Sure this can be counteracted with a house coding standard, but then you get the beligerant who won't change and the newcomers.

With python it's not an issue. You have to indent, and the only choices are a number of spaces or tabs. And if someone inserts new code that doesn match the existing format, all they'll get is a error message for their trouble.

I don't get your point about moving blocks and breaking the code. You need to be indented by the appropriate amount for the block level you are in. Conceptually, that is no different from needing the correct number of closing braces. And the significant indenting actually makes any mistakes easier to spot. If you have genuinly found this a significant problem, then I'd suggest that your functions are way too long.

Re:Thoughts of Python...

[RichN]

I often in emacs select the whole file and tell it to correct the identation... which is impossible in python?

I use python-mode in emacs and it works well. It has totally removed my reservations on using Python (due to whitespace.) The trick was to use the 'pass' keyword in Python to signify the end of a block. 'pass' is a no-op and the python-mode.el module will unindent a level when it reaches it.

Re:Thoughts of Python...

[j.leidner]

When I heard about the whitespace-is-significant, I had nightmarish flashbacks ... As such, I refused to even look at Python seriously for quite some time.

Right, and even worse, its inability to encapsulate class-local methods (no data hiding => no OO!). On the nice side, Python code is terse (unlike Java) yet readable (unlike Perl), and the libraries are rich enough.

I wonder if the book contains a chapter on C++/Python interoperability (site looks slashdotted right now, so I can't check).

--
Try Nuggets , the mobile search engine. We answer your questions via SMS, across the UK.

Re:Thoughts of Python...

[grumbel]

### With python it's not an issue.

Well, you still have the choice between tabs and spaces, so if somebody indents with lots of tabs you are in the same throuble as in any other language too. Python does neither enforce any special naming or such, so people can still write unreadable code if they like, I really don't see how just enforcing idention helps here much, since you still need a common coding style.

### I don't get your point about moving blocks and breaking the code.

Try to move some local helper function up into a higher level, with any non-indention driven language I copy&paste and click 'C-c C-q', job done. With Python on the other side I have to remove the exact right amount of indention, if done manually you have a very good chance of messing stuff up. It gets worse if it comes to web-forums, email and such where indention gets easily broken. With a non-whitespace driven language I can just copy&paste, with Python I have to manually reinsert the indention and if I am unlucky the code doesn't even contain any hints on where a block ended.

Re:Thoughts of Python...

[grumbel]

### Right, and even worse, its inability to encapsulate class-local methods (no data hiding => no OO!).

I don't think that data hiding is all that important for OO, after all it doesn't add any functionality, it just restricts access a little bit and is in languages like C++ even easily workarounded via raw pointers or even more evil '#define private public' hacks. Worse of all, data hiding can make it actually impossible or very ugly to workaround bugs in a library.

Anyway, as far as I know Python does data hiding via '__' prefixes infront of the variable name, should be good enough to tell anybody 'don't touch this' while still allowing access if absolutly necesarry.

Re:Thoughts of Python...

[BasilBrush]

>Well, you still have the choice between tabs and spaces, so if somebody indents with lots of tabs you are in the same throuble as in any other language too.

No, because with Python that misformatting is an error, and you are directed to the line where you made it. The misformatting never makes it past a single sucessful compile.

>Python does neither enforce any special naming or such, so people can still write unreadable code if they like, I really don't see how just enforcing idention helps here much, since you still need a common coding style.

There's little point bringing in an extra issues that are common in all languages when we are talking specifically about the indentation issue.

>Try to move some local helper function up into a higher level.... With Python on the other side I have to remove the exact right amount of indention, if done manually you have a very good chance of messing stuff up.

I don't know what you are talking about in reference to Python. Functions are at one of two levels, module scope or class scope. There's only 1 indentation level difference between one and the other. 1 key to indent it or 1 key to outdent it on my editor. If you are going to mess that up in python, then you have no business refactoring the code in the first place.

>It gets worse if it comes to web-forums, email and such where indention gets easily broken.

Yes, that's a pain. But it's the web-forums that are broken, not python. Any sane forum, expecially a programming or geek forum, should have a means of entering preformatted text respecting tabs, spaces and newlines. That you can repair snippets in languages that use braces is not really the point. Certainly this is not a reason that should have any bearing on language design.

I've done many years of programming in C++ and only a few months in python, but there is not a shred of doubt in my mind that Python's indentation based blocks are easier, pleasanter and more consistent to read and write. It's the future.

We'll have to agree to differ, unless you change your mind at some time in the future. ;-)

Re:Thoughts of Python...

[ashultz]

Well, the indentation is always meaningful.

I mean, almost anywhere I put the close bracket on my if statement is syntactically correct. It's just that most of them result in code that doesn't actually do what I want.

Re:Thoughts of Python...

[Hugonz]

Yeah, with Emacs you can never complain about "lack of Control"

Sorry, I really really had to do it....

Re:Thoughts of Python...

[Anonymous Coward]

http://www.verachem.com/Vdisplay.html
That was written in wxPython. Some places are starting to use it!

Re:Thoughts of Python...

[Ian Bicking]

Double-underscore should only be used if you are somehow worried about name collisions with subclasses, or you are otherwise a control freak. A single underscore is the proper way of indicating something is a private variable. There's nothing stopping you from accessing such a variable, but Python does not assume Python programmers are idiots, so it lets you choose. Except in the case of double underscore, which is why many Python programmers find them obnoxious (myself included).

There are a variety of other data-hiding techniques. Enforced encapsulation isn't really an essential aspect of OO anyway; Smalltalk has no private methods (except by convention, like Python), and Smalltalk is quintessentially OO. Smalltalk does make all instance variables private; I'd probably agree that it would have been better if Python instance variables were private, but you can use property if you later decide to make a public attribute calculated, or one of the other cases where public attributes cause problems.

Re:Thoughts of Python...

[LittleDan]

Note that with a brace/delimiter oriented language, you often have to manually insert/delete delimiters...
You obviously don't have much experience using brace/delimeter oriented languages. If whitespace means nothing, the emacs or vi mode pretty much always handles indentation for you, with a single commmand to autoindent the whole file. With Python, you have to manually choose the indentation. I'm not saying the Python version is bad, it's definitely acceptable, you just can't say that it's more automatic, because the non-Python version is more automatic.
I have no idea what an interactive interpreter has to do with automatic indentation; most new languages have it, and most new languages don't have signifcant indentation.

Daniel Ehrenberg

Re:Thoughts of Python...

[LittleDan]

Which is unnecessary in Python. The indentation is always correct, and that's that.
Well, the indentation is always meaningful.
The indentation is always meaningful, but it's not always correct, if the indentation is incorrect, it's an error. Here's an example: you want to copy code from some other program. The code in the other program is in an if statement in a function, indented 2 levels, but you want it to just be in a function, indented one level. You copy and paste the code, and the indentation is wrong no matter what language you're using. Innocently, you try to run it, but you get an indentation error. But in a language with explicit delimiters, it will just work. Isn't that DWIM? So then, you want to make the program look better, no matter which language you're using. In the language with explicit delimiters, emacs can tell where to indent because the delimiters are good clues, but without explicit delimiters, emacs has no idea where to indent the python code and you have to reindent it manually. Emacs might have commands to make it so you can un/indent a block in just 2 keystrokes, but you still have to do it all manually, putting the work of emacs on the programmer. I don't see how this is good.

Very useful

[sparkywonderchicken]

Python might be the most useful language since scheme.

python's list processing rules

[graveyhead]

For those who haven't tinkered yet, or are just getting started with Python, I've found one of it's greatest strengths is it's ability to munge lists.

e.g, look at this super-terse, but still legible, sub-array code:

l = l[1:]

List comprehensions are another great feature:

l = [ do_something(x) for x in l ]

This is so amazingly compact when compared with list processing in Java or C++.

Anyhow, hats off to Guido Van Rossum for such a great language. I'll have to check this book out... I've been using the python cookbook (OReilly) and the documentation on the site almost exclusively...

Re:python's list processing rules

[nkh]

Actually, I have a problem with lists comprehensions:

With Python: [ x ** 2 for x in xrange(100000) if x % 2 == 0 ] (8 seconds)
With Ruby: (1..100_000).select { |x| x % 2 == 0 }.map { |x| x ** 2 } (2 seconds)
but Ruby is supposed to be 10 times slower (not compiled, bigger...) What's happening? (it's not a troll, it's a real question)

Re:python's list processing rules

[Greyfox]

Does that include the spiffy stuff that you can do using boost? I haven't done C++ in a while so I haven't had a chance to really play with boost yet, but I'm led to believe that it lets you get the language down to about that level of compactness.

Personally I'm a fan of (mapcar (lambda (x) ...))

Re:python's list processing rules

[necrognome]

Here's something else that's cool:

>>> a = 'slashdot'
>>> a[::-1]
'todhsals'

mylist[::-1] returns a list with the elements of mylist in reverse order.

Re:python's list processing rules

[Mendenhall]

Actually, that took me a while to figure out, too. If you try it with 50000 instead of 100000, on my machine python takes 0.384 seconds while ruby takes 0.537 seconds. With 100000, the comparison is much as you show (except about twice as fast in both cases). If, instead of squaring x, you take x alone, python is also faster.

Apparently, there is something quite different about ruby's handling of long integers (>32) bits from python's. In the python case, this expression automatically switches to infinite-precision integers (at least for python 2.3). I don't use ruby, so I don't know what it is producing when the numbers get beyond 32 bits. Does it automatically go to long integers?

Anyway, the speed difference in this pair of examples seems contrived to get ruby to do something much faster than python, since it requires 'special' values including integer overflow to exercise this effect. Maybe ruby really has better long integer handling than python. Can any on who knows ruby comment on the result of the overflow?

Re:python's list processing rules

[Anonymous Coward]

Ruby more than likely is doing enough dataflow analysis to know you don't want the list result, and thus might not bother to build it up. 'course, a little more analysis would optimize away all benchmarks like that ;)

Could be python's memory management (not great) or list concatenation behavior (only recently made tolerable in recent versions). Grab python 2.4 and try this generator expression

for i in ( x ** 2 for x in xrange(100000) if x % 2 == 0 ): pass

Re:python's list processing rules

[Anonymous Coward]

I don't use ruby, so I don't know what it is producing when the numbers get beyond 32 bits. Does it automatically go to long integers?

Yes:

puts 10.class # => Fixnum

puts 1000000000000.class # => Bignum

No idea which is faster in general, though. Ruby seems slower more often, but who cares, if I want speed I just write a C library and load it from Ruby (Ruby has a cool feature that lets you load arbitrary C libraries on the fly... I'm sure Python has something similar but I can program so much faster in Ruby).

Re:python's list processing rules

[Anonymous Coward]

What exactly is so great about that?

It's not readable. 'string'.reverse() is more readable (but it doesn't work on strings, and it would reverse it "in place" anyway).

Re:python's list processing rules

[necrognome]

The parent's comment was about terseness, not readability. Why must a programming language be pitched toward the lowest common denominator. Not having to poop out five lines of code to reverse a list or string is IMHO a cool feature of a terse language.

Re:python's list processing rules

[Black Perl]

Just wanted to add one more for reference:

With Python: (8 seconds)

[ x ** 2 for x in xrange(100000) if x % 2 == 0 ]

With Ruby: (2 seconds)

(1..100_000).select { |x| x % 2 == 0 }.map { |x| x ** 2 }

With Perl: (<= 1 second)

map { $_ ** 2 } grep { $_ % 2 == 0 } (1..100000);

Re:python's list processing rules

[entrox]

List processing, huh? Witness what a _real_ list processor can do:

(loop for x from 1 to 100000
when (zerop (mod x 2))
collect (* x x))

0.16 seconds on my 1Ghz G4.

Re:python's list processing rules

[Anonymous Coward]

l = l[1:]

that's something to be excited about?

Ruby:

l = l[1..-1]
or
l.shift

Perl:

shift @l

Lisp (sorta, you usually don't need to save it in a variable, just use it):

(cdr l)

l = [ do_something(x) for x in l ]

It would be a lot cooler if it wasn't just bolted onto the language as new syntax. In Ruby this kind of thing is just methods on the Array class, you can write your own, and you can do more than just "do_something()" you can pass arbitrary code:

l.each { |x|
do_something(x)
do_something_else(x)
return if x.funky?
}

List comprehensions are a bizarre thing to me. They have very limited use (once they go longer than one line, they become unreadable) and they are just tossed into the language. And they make Python's distinction between expressions and arbitrary code that much more noticable.

And unlike HAskell's, which use punctuation, Pythons use alphabetic characters! which makes it all that much harder to read:

bar = [ni.foo() for fi in inp if fi > baz]

Oh well, if it works for you..... but list comprehensions are a violation of Python's design principles if you ask me, and were just thrown in to make less stuff to type.

Re:python's list processing rules

[Anonymous Coward]

=====
e.g, look at this super-terse, but still legible, sub-array code:

l = l[1:]
=====

Well, kind of legible... might I suggest that you avoid using a lone lowercase "L" as an identifier, especially when the number 1 is involved! :-)

Re:python's list processing rules

[Anonymous Coward]

Actually, Python's list comprehensions are more about readable code than speed. Which of those two examples are more readable to:

A) An experieinced Python progammer
B) An experienced Ruby programmer
C) Someone who knows neither language
D) Someone who knows both languages equally well

I'm willing to bet the python example is more readable to all but B, and maybe even to B.

By the way, Python has map() and filter(), which look to be similar to Ruby's .select and .map, and used to be faster than list comps, for the most part. I think with recent versions of Python, this is no longer the case, which is born out by a test on this example.

However, if you are dealing with 1000's of numbers in python, and want speed, you really want to use the Numeric (or Numarray) module. Is there such a thing for Ruby?

Numeric does not support infinitely long ints, so I used floats (C doubles) instead. I also did a version with floats and list comps, to see what a difference that made. Here's some results with various methods:

N = 1000
With List Comps it took: 0.001167 seconds
With map and filter it took: 0.003289 seconds
With List Comps and float it took: 0.002762 seconds
N = 10000
With List Comps it took: 0.013235 seconds
With map and filter it took: 0.025666 seconds
With List Comps and float it took: 0.029298 seconds
N = 100000
With List Comps it took: 1.407138 seconds
With map and filter it took: 1.495419 seconds
With List Comps and float it took: 0.276335 seconds
With Numeric it took: 0.070795 seconds

So you can see that map and filter are a little bit slower than the list comp, there is a big jump at N = 100,000, when we get into long ints, using floats helps that, and Numeric is much faster with large N. I tried to post all my code, but I couldn't get it to format in a readable fashion (ECODE didn't work). Here's the map and filter version:

map(lambda x: x**2, ( filter(lambda x: not (x % 2), xrange(N) ) ) ) and here's the Numeric version:

a = Numeric.arange(float(N))
( Numeric.compress(((a % 2) == 0 ), a) ) ** 2

Re:python's list processing rules

[Black Acid]

I would guess Perl is optimizing away the map in a void context, but this doesn't seem to be the case. I recall a while back some discussion about optimizing the .. operator to not always create a full-blown list unless necessary; these changes must have been implemented.

On my system (using 1,000,000), Python takes 10 seconds, Perl takes 3. Even using @a=map { $_ ** 2 } grep { $_ % 2 == 0 } (1..1_000_000), forcing Perl to compute the list, Perl finishes in a mere 3-4 seconds. I ran these informal benchmarks in the debugger to discount any possibility of inclusing times being factored in.

Second benchmark, from the command line:

$ time perl a.pl
3.113u 0.488s 0:07.15 50.2% 10+96966k 0+0io 0pf+0w
$ time python a.py
14.209u 0.309s 0:18.55 78.1% 792+12392k 0+0io 0pf+0w

Looks like Python could use some optimization.

Also, there is a caveat with Python list comprehensions. In Perl, this (admittedly contrived) example prints 42:
$x=42;
@a=map( my $x=1; $_ ** 2 } grep { $_ % 2 == 0 } (1..10);
print $x;

In Python, you don't have a $_ variable, so you have to make your own--usually x:
x = 42
a = [ x ** 2 for x in xrange(10) if x % 2 == 0 ]
print x
Prints 9, not 42 because of Python's static lexical scoping.

Re:python's list processing rules

[graveyhead]

Yeah, I never said it was the *best* list processor. LISP (the List Processor) is of course great at processing lists.

But do you know what it sucks at? Everything else :P Anyone who's been lost in stupid parenthesis knows what I mean.

Python is a very nice language because it combines great ideas from both functional and procedural languages.

Re:python's list processing rules

[Anonymous Coward]

The optimization is utterly trivial: since from a certain point onwards, x**2 will no longer fit into a 32-bit integer, python has to coerce some ints into longs. If you do this beforehand, the difference is rather large: compare the original:

a = [ x ** 2 for x in xrange(1000000) if x % 2 == 0 ]

to

a = [ long(x) ** 2 for x in xrange(1000000) if x % 2 == 0 ]

using time, I get:

[real: 0m21.790s; user: 0m20.290s; sys: 0m0.110s] for the first one, and [real: 0m3.637s; user: 0m3.310s; sys: 0m0.070s] for the second. For good measure, I get [real: 0m4.084s; user: 0m3.500s; sys: 0m0.400s] with perl: that is slightly _slower_ than the python version.

I agree that perl apparently does this automatically, and python doesn't. That doesn't mean you can't it to go fast, but manual intervention is needed at this point.

Maarten

Re:python's list processing rules

[Anonymous Coward]

There is another very nifty way to instantly optimize python: psyco

http://psyco.sourceforge.net/index.html

all you need is:
import psyco
psyco.full()

to get a more than 30% or so speed up:
without Psyco:
N = 100000
With List Comps it took: 0.346352 seconds
N = 1000000
With List Comps it took: 3.468986 seconds

With psyco:
N = 100000
With List Comps it took: 0.197049 seconds
N = 1000000
With List Comps it took: 2.186394 seconds

Re:python's list processing rules

[Anonymous Coward]

l = l[1:]

Granted. But

l = l.subList(1,l.length()-1);

...isn't horrible. And in Lisp:

(setf l (subseq l 1))

...is pretty good.

List comprehensions are another great feature:

l = [ do_something(x) for x in l ]

Where the hell did Pythoners (and others) start using the incomprehensible term "list comprehensions"? Isn't the correct term ("function mapping" -- from Lisp, Scheme, Prolog, Mathematica, etc.) still sufficient?

BTW, here's some simple code for doing mapping in Java. Yes, it can be more efficient and general. No, I don't care.

public interface Mappable { public Object map(Object o); }
public class FMap
{
public static List over(Collection c, Mappable m)
{
List l = new ArrayList(c.length());
Iterator i = c.iterator();
while(i.hasNext()) l.add(m.map(i.next()));
return c;
}
}

You use it like this:

l = FMap.over(l, new Mappable() { public Object map(Object x) { do_something(x); } );

Ugly? Yes. But not all that long. It's just syntactical sugar. And in Lisp it's quite purty.

(setf l (mapcar #'do-something l)) ; for Lisp lists
(setf l (map 'vector #'do-something l)) ; for vectors (like Python)

Point is: these arguments are just syntactical arguments, and they're helpful but not all that much. Indeed, without a whole lot of work, Lisp can be modified to have EXACTLY the same syntax for maps and slices as Python does! Not the other way around though. Heck, Python is a language which only recently got true CLOSURES, for goodness sakes, and only with an additional module! As the Lisp guys used to say, here's a dime kid, come back when you've got yerself a better programming language. :-)

Re:python's list processing rules

[BasilBrush]

Mod AC parent up. Add 2 lines to invoke psyco and Python trounces the others in the benchmark.

Re:python's list processing rules

[BasilBrush]

The grandparent was about pointless terseness. The sort of terseness that can so easily go unspotted. When Python lets you code it as a.reverse() Why would anyone not entering an obfuscation contest write: a[::-1]

Re:python's list processing rules

[Anonymous Coward]

Don't you mean (mapcar #'(lambda (x) ....))?

Re:python's list processing rules

[Anonymous Coward]

Since when has Lisp not been good for imperative programming? Most of the Lisp code that I write makes extensive use of things like loop and do, both of which express iteration. It's not like it's Haskell or something....

Re:python's list processing rules

[Anonymous Coward]

hmmmm... I get about 3 seconds on Python, under 2 on Ruby... and 0.05 seconds on Java! Okay, 0.152 the first time around, while it's still bytecode-compiling. :-)

ArrayList i = new ArrayList();
for(int x = 1; x < 100001 ; x++) if (x % 2 == 0) i.add(new Integer(x));

My experience is that well-coded Java is generally about 10-15 times faster than well-coded Python, but 60 times faster is just ridiculous. Are comprehensions really that slow?

Re:python's list processing rules

[davegaramond]

Sorry, your post is kind of stupid. You confessed you never use Ruby but you proclaim that Python 2.3 is better. WTF? Ruby has been converting int-bigint automatically since waaaaay before Python 2.3.

Re:python's list processing rules

[Mendenhall]

I didn't say anything of the sort! I in fact speculated that ruby might have better long integer handling than python. This appears to be the case, after a little more fiddling around on my part to check the numbers.

All I did was present some numbers showing why a particular test case (to which my message was a reply) got the result it did.

Although I like python very much, I am open to the fact that other languages might implement different things with very different efficiencies.

Re:python's list processing rules

[Anonymous Coward]

Where the hell did Pythoners (and others) start using the incomprehensible term "list comprehensions"? Isn't the correct term ("function mapping" -- from Lisp, Scheme, Prolog, Mathematica, etc.) still sufficient?

From Haskell, since you ask, where a list comprehension is a very powerful feature: I don't know how they work in Python, but in Haskell, for example,

evens l = [ x | x <- l, even x ]

means "the function 'evens' builds a list of those elements 'x' for which 'x' is a member of the list 'l' and 'x' is even". Elegant, huh?

It's not called function mapping because it does more than just map a function over a list. Modern languages have features built in that Lisp doesn't have built in - get over it, kid.

Re:python's list processing rules

[LittleDan]

There are good reasons why Python is great, but this isn't one of them. Scheme can do this much more tersely. for the first example,

l = l[1:]

This could be done in HTDP's Scheme dialect as

(rest l)

(that didn't do the same thing, but in good Schemely style, you probably wouldn't be updating a variable for something like that). The Python version would be O(n), while the Scheme version would be O(1). This is because Python uses arrays and annoys the rest of the programmer world calling them lists. Scheme, OTOH, uses linked lists, where the rest operation doesn't require copying most of the structure like Python does.

For the second example, the list comprehension, the Python version

l = [do_something(x) for x in l]

is again longer than the scheme version (which I'm leaving out assignment for):

(map do-something l)

Don't like the parens? You might want to check out Haskell, which is similar to Scheme in many respects but has significant indentation and list comprehensions. Python is very un-unique in its ability to do these things you've listed.

Daniel Ehrenberg

good and bad

[rjnagle]

Funny, I have been reading both the online version and the print version over the weekend.

It is in many ways an excellent book, but geared towards more experienced programmers than I. The style is readable, but the program illustrating introspection (chapter 4 I believe) is really hard to get into. Mark could have chosen a better example.

I particularly liked the way that Pilgrim annotated the code. He started out a chapter with the raw code, broke them into blocks with annotations and then concluded the chapter with a review.

The approach of these diveinto books is to introduce unfamiliar concepts and then dissect them one by one. My only complaint is that sometimes he introduces a lot of things all at once. It would have been better (though less succinct) to use more examples with fewer concepts thrown together all at once. On the other hand, I can appreciate the succinctness of the example programs by presenting them without first dumbing them down. The good thing about diveintopython is that it helped me to read a program pretty easily --although that doesn't imply that I can apply this knowledge..Give me another week or two:) The key question is at what point do I feel like coding on my own? I tried the examples in chapters 1 and 2, and then didn't feel like I could start coding until I finished the first 8 chapters. (and am slowly getting the hang of it).

Interestingly, when I started out, I found that I was referring to Oreilly's Python in a Nutshell more and more. Didn't look that user friendly at first, now seemingly more useful.

My sense is that programming is a matter of incremental mastery. (First read Fun with Dick and Jane, then read Wizard of Oz, then Melville, then Shakespearean sonnets). This book starts out by throwing out the Shakespearean sonnets at us and then explaining piece by piece until we have a sense of the whole.

Guido von Rossum's tutorial is more of a stepping stone approach, though the example code is more academic than practical.

One advantage of the online book: great hyperlinked references to Rossum's tutorial and other sources.

Despite my griping, this was still a good instructive read (though challenging). And way to go Mark for putting this online for free!

Re:Python and Perl...

[tiptone]

Yawn...stretch...Database access.

Just looked in the man pages (cause i'm not a real Unix developer) and none of those programs (sed, awk, grep) have any kind of network connection. So add to database access any type of networking...

It's also in Debian.

[jonathan_atkinson]

If you use Debian, you can just:

# su
# apt-get install diveintopython

And the book will be downloaded and placed into /usr/share/doc/diveintopython/

--Jon

diveintomark slashdotted

[Anonymous Coward]

Anyone got a mirror?

We need a Dive into Zope book

[ikhalil]

I think someone should write us a Dive into zope book with the same quality as Dive into python!

Re:We need a Dive into Zope book

[Anonymous Coward]

Dive into Python still refers you back to the excellent Python documentation in order to learn more. Zope ... I've given it three tries, and given up because of its CRAPPY documentation.

Re:We need a Dive into Zope book

[Anonymous Coward]

Its ok, if you took more time to learn it, you'd find its very limiting and not nearly as nice as it seems when you first play with it. Plus its slow as all hell. Stick to apache+mod_python.

Re:We need a Dive into Zope book

[dagnabit]

The San Diego Open Source Software Assoc/Linux Users Group just had the architect of the local paper's website in to give a Python/Zope/Plone talk.

At the end of the meeting, he said there were a couple of Zope books coming out this fall. Not sure if they'll be the same caliber as the Dive Into... book, but it's a start.

The presentation he gave should be on the SDOSS website soon... and as an aside, they primarily use Debian for their servers, desktops, etc.

Re:We need a Dive into Zope book

[cpghost]

Yes, The Zope Book is not that bad, but something much more practical would be nice to have.

Re:Python and Perl...

[GuardianAngus]

It seems to have been a while since you have had to do some quick file parsing on a windows box as well. There is much to be said of the common syntax that can be supported on all of the platforms that I need to touch.

Well, ok... nothing is really "supportable" on WinCE, but besides that...

shrinking shelf space

[Anonymous Coward]

Not to troll, but has anyone else noticed that the total shelf space is much smaller than it was just a few years ago for computer books and specifically programming books ?

Re:shrinking shelf space

[Jugalator]

No, since I rarely look for those books. Not to brag and pretend I know so much, but Internet has replaced a whole lot of my book needs.

The thinner, the better

[mwood]

Fat language books are just, well, fat. I learned 98% of FORTRAN IV from a book about .75" thick, and my ALGOL 68 book is even thinner. It takes very little space to thoroughly introduce the programmer to Modula or Icon. Even COBOL books don't have to be wordy even though most COBOL code is.

When I see a slender volume sitting among the telephone-directory-sized tomes, I usually pick it up on the assumption that it should be good if it's so lean. I am not often disappointed.

(I just realized that LISP books *all* tend to be rather slender. McCarthy, Siklossy, and Steele all managed to say quite a lot in very little space. Hmmm.)

Re:The thinner, the better

[Mr. Bad Example]

> (I just realized that LISP books *all* tend to be rather slender. McCarthy, Siklossy, and Steele all managed to say quite a lot in very little space. Hmmm.)

It's because the chapters are recursive.

Re:The thinner, the better

[njdj]

The thinnest language manual I've ever used was the BCPL manual, which described the full language and its library (with examples) in an A4-size manual less than 2mm thick. This was in the mid-1970s. Developed by Martin Richards at Cambridge (not sure when - 1970??), the language became popular at CERN and was used at the Lawrence Berkeley Laboratory and elsewhere, and influenced the design of C.

Re:The thinner, the better

[booch]

(I just realized that LISP books *all* tend to be rather slender. McCarthy, Siklossy, and Steele all managed to say quite a lot in very little space. Hmmm.)

(Insert joke about parentheses (()) (here))

I suspect that the Lisp books are so small because the number of concepts in Lisp is rather small. It's just that each concept in Lisp goes a long way.

Re:The thinner, the better

[FuzzyBad-Mofo]

Hmm, you may be on to something there.

(Glances over at 'The C Programming Language' and 'Learning Perl', both < 1" thick. Then the 800-page, 2" thick 'Learning Java'. Ouch.)

Re:The thinner, the better

[BigGerman]

Very true.
I did a lot of Cobol when I started out ( I am old) and I had this 600+ page Cobol book but I never went past page 18 and it was well worn out all the way to page 18. What was on page 18? First example of more-or-less complex complete program.

Re:The thinner, the better

[Anonymous Coward]

(Insert joke about parentheses (()) (here))

I think you mean

(insert
here
(about
(parentheses
joke)))

Re:The thinner, the better

[Anonymous Coward]

Not true about the Lisp books. It's well known that the Symbolics manuals were much too thick and quite a problem for users.

Steele's CLtL2 book is some 1029 pages. I wouldn't call that slender. As for McCarthy, I'm not sure what he has to do with the programming language Lisp. He made LISP (and was involved w/ LISP 1.5) some time ago, but that's definately not what people refer to by the name "Lisp" today.

Re:The thinner, the better

[Alsee]

Cringe. I just had a vision of a Basic book filled with a hundred-odd Goto's jumping between and even within paragraphs.

-

Re:The thinner, the better

[mwood]

You bring up a worthwhile point: the runtime library. One reason ALGOL manuals are so small is that there *is* no standard runtime library, at least none for programmers to use. By contrast, the Java language is fairly small but the standard class libraries are *enormous*, so Java books *must* be fairly hefty. (One could of course split the language and the libraries into separate volumes.)

I'm still not sure that could account for *all* the difference in books on, say, Simula vs. C++.

Re:The thinner, the better

[mwood]

You're missing a few (QUOTE x) there.

Re:The thinner, the better

[horza]

Fat language books are just, well, fat. I learned 98% of FORTRAN IV from a book about .75" thick, and my ALGOL 68 book is even thinner.

I learned all my C from the original K&R book, around the same thickness, and it also doubled as my only reference manual thereafter. It also appears to be the same price as it was 10 years ago. :-/ You won't get away with that so easily these days with languages containing huge amounts of built-in or standard libraries.

Phillip.

Re:The thinner, the better

[drudd]

It's the "choose your own adventure" style of learning!

Doug

Python

[jefu]

A few years back I wrote some scripts for web input processing. I knew a smattering of Perl so wrote them in Perl. They worked ok as far as I could tell . I had other things to do so stopped working on them, then went back after a while to add some functionality and discovered that I had no idea what I had done or how. Eventually I worked it out and added the functionality I wanted (and comments, yup) and went away again. The next time I went back I had to learn the whole thing again and my comments and cleaned up code didn't help.

So I'd heard about Python and that it was good, so (since I like the process of learning new languages) I decided to try rewriting the scripts in python. In about two days I had them doing everything the perl had done and the added functionality as well and with remarkably few bugs.

Eventually I went back to add on more functionality and "Lo!" I had no trouble reading my Python code and even better adding in the new stuff was simple.

The biggest problem with Python has been the lack of a good book, I'll be considering "Dive into Python" carefully - being in the education biz I'm looking for a really good Python book for students.

Re:Python

[Anonymous Coward]

I would very very strongly suggest getting this book.

I am a high school student with experience in java and some c. Then one of my friends told me about the coolness of python and I decided to give it a try. Lucky me, this was the online tutorial google pointed to and I learned and now use python whenever I have a choice of language.

Very very good instructional book as all the others and reviewer said. It doesn't dumb things down for you at all, which is the best feature of this book IMO.

Re:Python

[Elamaton]

I'm not sure how well suited it would be for students specifically, but I've found O'Reilly's Learning Python, 2nd Edition to be an excellent book for, well, learning Python.

I recently completed reading it from cover to cover, and while I didn't yet even code the examples myself (I plan to do that on my second read), every chapter felt like a series of revelations.

Highly recommended. Combine that with other books (Dive into Python looks very nice) and a few extra resources, and you and/or your students should be positively churning out code. A couple of nice ones:

Python Sidebar (originally for Mozilla, but works on at least Opera as well)
Python 2.3 Quick Reference (utterly brilliant)

Why Are These People So Naive?

[reallocate]

>>... one gets the feeling that its primary purpose is to allow the author to make some payments on a car or mortgage...

Geez, how did some people become so naive? Just figuring out that professional authors write for money? And you're offended by it?

Re:Why Are These People So Naive?

[fred fleenblat]

No, writing for money is fine. The big fat "intro to whatever" books that are 1200 pages are a problem and that is precisely because the authors are paid by the page. $20/page for the low end. Higher for more reputable tech authors. It's as laughable as paying programmers per line, but that's what they do.

Re:Why Are These People So Naive?

[reallocate]

>> The big fat "intro to whatever" books that are 1200 pages are a problem...

Why are they a problem? Is someone forcing you to buy them?

It's my impression that authors sign contracts with publishers that set the price, rather than some open-ended deal that sees a publisher agree to pay a fixed price per page. (What's a "page", anyway?) A publisher could not control its costs if it allowed writers to determine what it paid for manuscripts.

Frankly, it's my impression that all those huge books exist because people buy them. If they didn't, publishers would stop trying to sell them.

Re:Why Are These People So Naive?

[fred fleenblat]

The problem is that quite often a smaller book is more readable and informative than a larger book. Publishers who emphasize quanity over quality probably have sound business reasons, but this simultaneously does a disservice the craft of writing and the pastime of reading.

Re:Why Are These People So Naive?

[Anonymous Coward]

$20/page for the low end.

And if a page takes more than 3 hours to complete, you're better off working at McDonald's.

Re:Why Are These People So Naive?

[Anonymous Coward]

mcdonalds: free food
writing a book: free toilet paper

tough call, you need them both!

Re:Why Are These People So Naive?

[reallocate]

Again, what's the problem?

If you think a book is too long, don't read it. On the other hand, I might think it's just about right, and wonder why you bought that puny little thing you're reading. You and I don't have any right to decide for others what is worth reading or not.

It is nice to know you're worried about "the craft of writing and the pastime of reading". but I'm pretty certain those aren't uppermost in the minds of commercial authors and publishers. Nor in mine. We're talking computer books here, not works of literature.

Re:Why Are These People So Naive?

[Anonymous Coward]

It's not an issue of reading large books or an author wanting money. The issue is mass triviality becoming the norm rather than the exception.

Re:OT--Gmail invite fairy

[anethema]

Alrite, well, that was fun but thats the end of those invites, ill find someone more diserving i guess.

I had no idea

[Cereal Box]

Mark Pilgrim works down the hall from me. I had no idea he wrote this particular book.

Small world.

Re:I had no idea

[transient]

Sounds like you two are best buds. ;-)

mirror

[Kedder]

here is a mirror

Re:mirror

[wnarifin]

It works. But, can't seem to wget this one...

It's just shorthand

[Anonymous Coward]

If there is no numerical rating, just assume a "9". Almost all book reviews are a "9" under the Slashdot Book Rating System.

Re:OT--Gmail invite fairy

[Anonymous Coward]

THANK YOU!

The actual dialogue...

[nusratt]

...you would expect to go more like this:

"...a dialog between him and his manager after showing him a rough 20-page draft:

Manager: "This is really good. You could probably make some money off this someday --
but you did it while employed by us, so now it belongs to us.
Cough up the rest.
You have a month."

http://yro.slashdot.org/article.pl?sid=04/08/03/ 22 5217

Torrent for book?

[CaptainPinko]

site seems down to me so I'm wondering if anyone has started a torrent for the book?

Python Compiler

[nurb432]

There is a python compiler for Win32.. i dont have the name handy but a quick search on Guido's site should bring it up for you..

Re:Python Compiler

[cryptochrome]

there's py2exe... but that's just an executable with the python interpreter and all necessary modules and code included, IIRC.

Re:Python Compiler

[arkanes]

py2exe is exactly what you asked for. There's similiar packagers for both Linux and OS X (Py_Freeze for linux, I'm not sure what the name of the OS X one is).

As for writing C extension modules, take a look at Weave.

Re:Python Compiler

[BasilBrush]

The one I tried was called psyco. Pretty transparent, and it speeded up my app about 10 fold.

Also in the ActivePython docs

[jalefkowit]

If you use ActiveState's free distribution of Python for Windows, ActivePython, the electronic version of Dive into Python is included in the documentation file under "Helpful Resources". Very handy!

Try it, I just did....

[gr8_phk]

I finally decided to try Python about a week ago. My goal was to scrape some information from a web page for easy/compact display. Pulling the raw HTML from a given URL is simple with the urllib. Python string handling makes parsing text fun and easy. The interactive mode actually allows you to define functions on the fly and try them without editing/saving/compiling files. And lastly, the thing I feared most... The "indentation matters" concept is fantastic.

Using Tkinter for a GUI is not as simple as I had hoped, but that's because the Python documentation doesn't cover much TK and I'm new to it - hence I need to learn that too.

Re:Try it, I just did....

[gomoX]

You don't have to: in fact, the only advantage Tk has is it's included with the python installation.
My personal choice is PyGTK, but PyQt and wxPython both are pretty nice.

Practical Common Lisp

[entrox]

If you like the more practical approach of books like this and always wanted to see what the fuss about Common Lisp is all about, then Practical Common Lisp is for you. The book isn't finished yet, but some chapters are already online for review.
Learn CL while writing a flexible MP3 database, a spam filter or a generic parser generator for binary files. How about a streaming MP3 server or a unit test framework? It's all in there without the boring stuff, which usually accompanies books like these.

Re:Practical Common Lisp

[Anonymous Coward]

And in the book he uses Allegro which is proprietary and non-free.

Well, it's really non-free. But how can a conforming ANSI Common Lisp system be proprietary?

Take a look at CLiki if you are looking for a free Common Lisp.

Re:Practical Common Lisp

[Anonymous Coward]

(I'll leave aside your contradiction in the very first two statements, that Peter refuses to suggest only "one" implementation, and in the next you say that he uses Allegro only).

Actually, instead of being stupid like you suggest, the free implementations are moving towards broad compatibility with each other instead.

It is dumb to insist there only be one Lisp implementation because there are different trade-offs to be made in terms of CPU, memory, convenience, etc. The point of the ANSI standard is to make this possible.

Thankfully, people with more vision than your limited Python-mindset are working and making the open source Lisp compilers very strong.

Python barely counts as a programming language, in my eyes. If no one cares to provide a proper compiler for a language, then the language doesn't matter!

P.S. Peter uses Allegro in his book because he will be distributing a copy of Allegro 7.0 Personal edition on CD with the book; courtesy of Franz Inc. However, all of his advice should pretty much carry over to any other Lisp implementation. So tell me, Free Software zealot, does it matter which implementation you use WHEN THERE IS A STANDARD? Go back and cry to Guido, your Python-mommy, if you can't handle that amount of freedom. The rest of us prefer having choice.

Re:Practical Common Lisp

[Anonymous Coward]

I don't know if any Common Lisp implementation wants to be the de-facto open source lisp, but SBCL is very popular in the News, Web, and IRC. Throw Emacs and SLIME into the mix and you get a really nice system.

Re:Practical Common Lisp

[Anonymous Coward]

That might be nice for *Common Lisp*, but in terms of user interfaces and technology of IDEs for programming in general, it is *way* behind the times.

Re:Practical Common Lisp

[Anonymous Coward]

Here's a little hint: people can do the same things Common Lisp can do, but faster, easier, and quicker in Perl and Python. Compiled or not. You don't need compilation of those to easily beat CL. And the place where compilation really matters, CL is too inefficient to handle those applications. In other words, CL uses compilation as a *crutch*. The tasks Perl and Python are good for (quick GUI, throwaway scripting, etc.) do not demand speed, and are already quite efficient interpreted.

I would love to be proved wrong on the speed issue, but I'm confident claiming that it is impossible to write something like mplayer in any CL system today.

About the only thing CL can do today is play with files, albeit, in a not-so-nice way. Networking? Nope. It's all non-standard. There is no defacto standard like BSD sockets even. You can't even draw widgets half-way portable (and reliable) as you can in C/C++, Java, Perl, Python, etc. etc. It is simply not possible in *any* CL system today. The point of a standard like CL is to *ensure* portability, but what does that really matter when you can't do anything *with* that portability?

The standard issue is moot. Java has proved that language standards are dead. Guy Steele knows this. He helped Java. You don't see him preaching the virtues of ANSI Common Lisp.

If I had to use a Lisp today, it would have to be Scheme. Simply because most Scheme systems are fairly quick and can actually do useful things outside the language (of course, totally incompatible with other Scheme systems, just like CL). I wouldn't dare think of making any substantial application in either CL or Scheme, however. There is little to be had for whatever expressive power you think you get. Why fix something if it's really not broken?

Re:Practical Common Lisp

[pkhuong]

Here's what it does well: solve complex problems while you are discovering them. When i'm solving math problems, i really couldn't care less about I/O. Format is more than good enough.

Re:Practical Common Lisp

[Anonymous Coward]

[[(I'll leave aside your contradiction in the very first two statements, that Peter refuses to suggest only "one" implementation, and in the next you say that he uses Allegro only).]]]]

He doesn't say "here, download this and install it, that's all there is to it". He says there are many implementations, and he chooses a useless "demo"/personal/"free advertising" Allegro version for the book. Right away that probably turns off 50% of the readers. If you really think that non-Lisp-fanatics really want to figure out the difference between the versions, or that they will *pay money* for a system that does the same thing as what they can get for free, well, you must be a Lisp fanatic.

After I learn Lisp with the Allegro version, how do I use it to run my business? I can't probabably. I have to buy it, or retool it for CLISP or SBCL or whatever.

Many implementations to choose from == no uptake. Why on earth would someone go out of there way to download lisp, let alone figure out which implementation to use?

I *love* Lisp in the abstract, but I do most of my work in Ruby. I tried writing a program in Lisp just recently that would just run a unix command and capture the output and split it on whitespace. After a few *hours* and switching implementations, I managed to get it working.. but it left behind a bunch of zombies. In Ruby, one line of code, no zombies.

Without a single, Free, quality "brand" of Lisp, Lisp is doomed to failure. The Lispers can't seem to figure this out. They all want to converge on a bloated yet incomplete standard stuck in the 80's.

One day, a Matz or a Guido or a Larry Wall will come along and say "fuck the common lisp standard". He'll make an awesome Lisp with regular expressions, sockets, threads, everything working out of the box. He'll push it hard on newsgroups, slashdot, whatever. Then maybe Lisp will succeed.

And no, this person is not Paul Graham. The fact that he wants to retain car and cdr in his new Arc Lisp puts him in the lisp weenie category.

PS: if Lisp is so well-standardized, how come the Lisp Cookbook on sourceforge has exceptions in so many packages for different Lisp implementations? Why is there an "allegro common lisp compatibility package"? Why are there special conditionals that let you choose different code for different implementations? You guys are in an academic dreamland.

Re:Practical Common Lisp

[Anonymous Coward]

Is that the one that can't be compiled unless you have an existing implementation already running?

Gotta love Lisp. Or rather, love it but never use it for anything in the real world.

Re:Practical Common Lisp

[Anonymous Coward]

and I knew someone would say that.

Of course, there are much better utilities for solving math problems. Lisp might be dynamic, but what you write is still very much a static, rigid system. Not very good for the *solving* problems part (hint: the problem should be solved before you sit down and try to program anything). It tries to do everything perfect, but does nothing really really well. It's a nice glue language, but not much else I'm afraid.

Re:Practical Common Lisp

[reflective recursion]

Thank you for saying this. I finally know that I'm not the only one who thinks CL should be dumped for something nicer.

Re:Practical Common Lisp

[Anonymous Coward]

Kind of like any C-compiler...

Re:Practical Common Lisp

[Anonymous Coward]

Is that the one that can't be compiled unless you have an existing implementation already running?

How do you compile GCC?

Re:Practical Common Lisp

[Patrik Nordebo]

SBCL requires a (reasonably compliant) ANSI Common Lisp compiler to build, just like gcc requires a C compiler to build. One compiler that can be used to compile SBCL is CLISP, which in turn can be built with a C compiler, so if you want to you can bootstrap from gcc.

It's a lot easier to just download a binary version of SBCL and using that to build with, though.

Re:Practical Common Lisp

[Anonymous Coward]

I would love to be proved wrong on the speed issue, but I'm confident claiming that it is impossible to write something like mplayer in any CL system today.

Take a look at Success Stories.

About the only thing CL can do today is play with files, albeit, in a not-so-nice way. Networking? Nope. It's all non-standard. There is no defacto standard like BSD sockets even. You can't even draw widgets half-way portable (and reliable) as you can in C/C++, Java, Perl, Python, etc. etc. It is simply not possible in *any* CL system today. The point of a standard like CL is to *ensure* portability, but what does that really matter when you can't do anything *with* that portability?

This simply isn't true. Where have you been the last year? There are sockets, GUIs, anything. And people make it work with more than one implementation of Common Lisp. And where is the GUI in the ISO standard of C?

Re:Practical Common Lisp

[Anonymous Coward]

Which also seems like it will be published by Apress, does anyone know when??

Re:Practical Common Lisp

[Anonymous Coward]

Nice success stories, but there are only nine of them. And there is no proof that any needed the efficiency that mplayer would have. Which was my entire point. "Naughty Dog" just used CL to create yet-another Lisp compiler that was *not* CL.

Yes there are sockets. Sockets for one implementation. Half-assed GTK+ bindings for another. SDL bindings for yet another. All of which need hand-tweaking to work.

And people make it work with more than one implementation of Common Lisp

It's called *denial*. At least face the faces for crying out loud. It is a complete bitch getting the bindings to a *C* GUI library working (GTK+). Yet Python or nearly anything else is a breeze.

And it's annoying when people put words into my mouth. I *never* said a word about ISO standard GUI libraries. I'm talking about software that *works*. Not some pipedream, construct-your-own-if-you-have-a-thousand-hours-to -spend crap.

Who really cares if ANSI or ISO says "yes this is what we call a standard"? People are getting along *great* using Python, Perl, etc. without ISO/ANSI support. ANSI, ISO, and W3C are *bought* organizations. Do you really assume that because Microsoft can buy a standard that it makes it better than software that is not a "standard"? Please.

Re:Practical Common Lisp

[reflective recursion]

Ha. Looks like I pissed off some CL kiddies. Really, folks, grow a clue. I just said one fucking line--my opinion. That's not flamebait. This entire thread should be modded "off topic." This is a python story...

Re:Practical Common Lisp

[Lodragandraoidh]

Is there anything mainstream, other than emacs (and considering emacs mainstream is a stretch at that), that uses Lisp as the implementation/macro language? There are probably good reasons for this.

I've used Lisp in the past; however there is nothing I can't do in other languages that I can do in Lisp. To me Lisp is very much like Cobol - you still see it around from time to time doing important things, but would never consider choosing it in preference to other more modern tools for any new projects.

Finally, and this is probably more important to me: ease of use. It takes me longer to write working Lisp code - primarily because I have to translate how my mind normally thinks in a structured/object oriented way, into a functional realm. IANAM (I am not a mathematician) - so do not feel drawn to Lisp, or limited by my lack of embracing Lisp as my general purpose programming language. I have been to the river, drank the water, and it was bitter to me. This is my experience informing my choices - not zealotry. It would be a pretty boring world if we all thought alike, and there was only one programming language.

Re:Practical Common Lisp

[Anonymous Coward]

Nice success stories, but there are only nine of them.

You sure have a reading (counting?) problem.

Re:Practical Common Lisp

[Anonymous Coward]

Is there anything mainstream, other than emacs (and considering emacs mainstream is a stretch at that), that uses Lisp as the implementation/macro language?

Google can help you. Some stuff is on the server side. As a programmer you certainly know The Regex Coach

It takes me longer to write working Lisp code - primarily because I have to translate how my mind normally thinks in a structured/object oriented way, into a functional realm.

Are you sure you have tried Common Lisp? It's not a functional language. It's a multi-paradigm language. Heck, you can even have a GOTO! :-) And yes, Common Lisp is object oriented.

Re:Practical Common Lisp

[Anonymous Coward]

Nine *recent* ones. Seems like CLers are pedant assholes who like to avoid the fucking point I'M MAKING. No evidence given that any of those need the efficiency of mplayer. Nice way to dodge the issue dickhead.

Re:Practical Common Lisp

[reflective recursion]

Don't worry about getting modded flamebait. I like Lisp and use it (not CL, of course), however I know there are a few CL'ers with mod points going crazy here. They don't seem to grasp the fact that they are, themselves, trolling on a *python* story in the first place.

Everything you say is right. Using something like Lisp does force you to think in a different way, and much of the "elegance" of something like Scheme can be lost on those who aren't mathematicians (and a few of those don't like Scheme for reasons of inelegance.. go figure).

Some people just don't like the parenthesis. If the CLers I know would have it their way everyone would be forced to use the parens... "once you get used to it they disappear!" they would say. What crap. To each their own, I say.

Completely Slashdotted!!

[chris_sawtell]

So here's the contents page from Google's cache:-
Dive Into Python Table Of Contents

Re:Completely Slashdotted!!

[Anonymous Coward]

Even the google cache is Slashdotted...

Yet another reason to love Ruby.

[Anonymous Coward]

It's not readable. 'string'.reverse() is more readable (but it doesn't work on strings, and it would reverse it "in place" anyway).

It works in Ruby exactly the way you wrote it!

What for almost absolute beginner?

[sznupi]

What would you recommend for learning Python for almost absolute beginner (only little vey simple c; without understanding of object oriented programming)? And one more thing - written in very simple language (as you can tell from my errors, English is far from beeing my native languge...in which there are'nt any good Python books for begginers)

Re:What for almost absolute beginner?

[Anonymous Coward]

The book 'Learning Python' is excelent for someone like you. It costs a little money (not that much really), but it will save you a lot of time and will set you off in the right direction.

Re:What for almost absolute beginner?

[Anonymous Coward]

I would recommend How to Think Like a Computer Scientist for an absolute beginner. I've used it myself and it explains concepts really well.

Python's a great language. Good luck!

Re:What for almost absolute beginner?

[Macrobat]

Learning Python by Mark Lutz worked for me. It's a quick survey of the basic syntax, and common operations. There's a chapter or two on Object Oriented Programming, but it's not as daunting as it sounds, at least in Python. Another winner from O'Rielly (as opposed to, say, Learning XML, but that's a discussion for another day...)

Re:What for almost absolute beginner?

[Anonymous Coward]

practical python by magnus lie hetland. good stuff. written by a norwegian dude

Re:What for almost absolute beginner?

[Anonymous Coward]

See www.awaretek.com/plf.html for Python book reviews oriented to the absolute beginner, as well as links to 70+ free online Pythonic tutorials and other learning Python resources...

Re:What for almost absolute beginner?

[Anonymous Coward]

bembry.org/tech/python/notes/index.php

Bembry has created a high school course in Python. He gives enough to get stuff done and omits a whole bunch of confusing details.

I'm not dumb (I'm the local dsp hardware guru.) but some Python documentation hurts my brain. Two pages of options for a command with no useful examples mean that it takes a half hour to figure out what you should get in five minutes. Bembry gives you the simple effective version. He also covers Tkinter effectively. This makes it quite easy to get a nice graphical interface in Python.

If I have one complaint about Python, it is that I spend hours tracking down modules to do stuff that should be trivial (like getting the computer to make a beep sound). Python really should have a built in getch, beep, etc..

Re:What for almost absolute beginner?

[bindlestiff]

As a small and simple tutorial guide I've enjoyed this book.

Python: Visual QuickStart Guide
ISBN:0201748843
Peachpit Press

Most of the examples are for the command line. This will encourage you to experiment and play. Creative play is where good programmers come from. It's not going to teach you how to write a big app or become a graphics wizard. It's certainly not suitable as your only reference book. It will give you an excellent introduction to the language in simple prose. It's small, lightweight, inexpensive and brief. It'll get you started, and you'll occasionally go back to it when you want a simple understandable explanation of a concept. I've bought some other tomes that weigh 10 times as much, cost 3 times and came with a CD, that aren't as useful. I like it, maybe it'll help you. I suspect it would be ideal for anyone who has trouble with english.

mod_python/PSP

[noselasd]

You guys discovered mod_python ?
Which now comes with PSP. That is, server side web scripting using
Python as the language. Similar in spirit to PHP, just using Python.
Amazingly much more fun than PHP.

You Nerds....

[kc_cyrus]

How Ironic...You nerds /.ed both DiveIntoMark.com and DiveIntoPython.org!

Talking about how great Python can be, I imagined this kind of sites run on a more stable servers.

teh type-o

[Anonymous Coward]

"and really, what truly 1337 book doesn't have one of these"

Books written by Dvorak users, of course :)

Creating reports

[Anonymous Coward]

Anyone know of libraries for creating printable reports with python in windows?

Right now for database clients apps for windows I am using java with jasper reports. I would not mind trying python with either QT or WXwindows but I need robust printable report creation in windows and I have not found an viable python solutions.

Making money from technical books - not happening

[otisg]

As a co-author of an upcoming technical book (Lucene in Action - not a plug, just providing context), let me just address this:

Reading them, one gets the feeling that its primary purpose is to allow the author to make some payments on a car or mortgage.

Unless we are talking about a book that really interests a LARGE portion of the geeks out there, the above statement is really missing the point. I don't know any technical book authors who do it for the money. I am certainly not writing for the money. Royalties are nice, but they are really small in the end, especially when you consider the time and effort that you put in writing technical books. In addition, think about the 'life expectancy' of a book that covers a technical topic - not much longer than firefly's.

Long story short, one doesn't write this type of stuff to make money, and Mark certainly didn't write Dive into Python for $$$ - I've had it bookmark in my Simpy account (URL in sig) for 6+ months now. I just wanted to get this straight, so there is no confusion. This may also be interesting to those considering writing a book on a technical topic.

a series of well planned coincidences-Sour Fruit.

[Anonymous Coward]

"For too many people, the "Why-to" is "because I heard you can make lots of money as a programmer". To answer this demand, colleges and universities churn out rank and file incompetent and ambivalent programmers, weilding their Microsoft inspired toolchest of Visual Basic 6 or MS Access, they flood the resume pool, and pollute the code base with their lazy half-hearted attempts at development, causing project failures and frustration on a massive scale and dramtically increasing the costs of corporate IT."

Gee I will never understand why people ruin an otherwise good post with a political agenda.

Here's a couple things for you.

1) Project failure, frustrations and cost overuns predate the VB and MS Access era. But it is nice to have a scapegoat, instead of looking at the real reasons.

2) There's nothing wrong with asking for money for your work. Disregard those whom are envious of you, and wish to bring you down by implying your a bad person for asking to get paid for your work (you'll hear things like "do it for the love").

Python, prototyping, and gmailfs-Add-ons.

[Anonymous Coward]

There's another reason to learn it. Quite a few OSS programs have python as their scripting language.

Kind of hard to extend them without knowing it.

With so many links in one article...

[Just6979]

why didn't the author think to utilize NYU's Coral content distribution network (covered here on /. just a couple weeks ago) to keep the bandwidth off diveintopython.org? Now it's too late, since Coral can't access the site to get it in the cache.

Working for money is bad-Do it for the love.

[Anonymous Coward]

"Long story short, one doesn't write this type of stuff to make money, and Mark certainly didn't write Dive into Python for $$$ - I've had it bookmark in my Simpy account (URL in sig) for 6+ months now. I just wanted to get this straight, so there is no confusion. This may also be interesting to those considering writing a book on a technical topic."

I think a more insightful question about the human condition is. Why do people keep saying things like that? Is it ignorance? Is it envy? Is it apathy?

For all our talk about being an advanced species, sometimes we can be rather backwards.

yuk

[Anonymous Coward]

i stopped reading after i read this from the book...

"Automatic datatyping is a double-edged sword. It's convenient, and it can be extremely powerful. But it places an additional burden on you to understand when and how Python coerces data into different types."

i can't code in a language that does this.

Re:yuk

[Anonymous Coward]

i can't code in a language that does this.

I agree. Better to use Perl, in which you don't need to care about types. :-)

SICP

[Anonymous Coward]

You should check out Structure and Interpretation of Computer Programs, published by MIT Press. It's available online at http://mitpress.mit.edu/sicp/

You mean Go Slashdot Mark?

[billstewart]

Toasted for now. Hope it's back later...

OSS supremacy

[Anonymous Coward]

The funny thing: I've been reading this book online and in dlownoadet html since it had 4 chapters. And now I bought it through amazon.co.uk.

Open Source makes it easier to distinguish shit from cinnamon, that's why certain someone is so afraid.

Python

[Anonymous Coward]

python

Don't worry about object oriented programming.

[Anonymous Coward]

What would you recommend for learning Python for almost absolute beginner (only little vey simple c;

I'd start with command line proceedural programming[1], which is likely what you were doing in C. You can write quite useful programs while ignoring 80% of the core language, and that should give you a good base to build on. Unfortunately I don't know any good tutorials.

[1]
i/o: input, print
flow control: if, while, for [...] in [...],
functions: def foo()
data types: strings, lists, tuples, dictionaries, numbers (don't worry about comprehensions)
operations on data: slicing, indexing ...
classes: just the basics. to some extent these function like C's structs.
This is enough to take you quite far in python.

Unslashdotted link to the book

[Anonymous Coward]

http://www.artfiles.org/freebsd.org/distfiles/dive intopython/diveintopython-pdf-5.4.zip

Ok, I'll bite...

[Big Sean O]

It's probably flamebait, but here goes...

Instead of working for the man, Mark did what he wanted to do. Now the 'FLOSS-zealot' has written a well-respected book and the manager looks like a selfish loser.

I'd rather be a well-respected author than a manager with no imagination.

Seems like Mark decided to be the change he wanted in the world. Good for him.

Re:Ok, I'll bite...

[gujo-odori]

Maybe its more of a troll than flamebait, but I'll bite too :-)

While that's not entirely true( supporters of Free and Open Source Software do become managers a lot more often than some people might think), there is something else they do quite a lot: they become entrepreneurs.

I'm a believer in Free software, and while I'm more likely to become a manager than an entrepreneur (I'm already on the ladder), I do hope to become an entrepreneur one day. Not necessarily in IT; I'd like run a nice little coffeehouse bookstore with great connectivity, a great selection of technical books, live acoustic blues and other "real" music, and espresso that'll make your hair stand up for a week :-)

My wife owns her own business, so I've gotten a good look at the ups and downs of being a small business owner, and I've got to say that it still looks like something I'd like to do.

In conclusion, I'll just state that the GP says "[they] do not become managers" like that's a bad thing :-) And of course, I'll bet that he's not a manager either and won't become one with such narrow thinking.

/.'ed but mirrored (sort of)

[starkaudio]

Drooling to give it a read, but can't get to the site? The previous link was to a version from 2002. If you go to google and search for anything along the lines of "diveintopython_5.4.orig.tar.gz" you'll find the May 20th, 2004 version is on many linux distro sites. Enjoy!

That's too easy

[Anonymous Coward]

I wanna see the Python interpreter written in Brainfuck...

Python Hosting

[Anonymous Coward]

For those looking for some decent Python hosting (or PHP 5 even for that matter), I use http://www.a2webhosting.com/. They seem to know what they're doing.

Python IDEs

[earlgreen]

Here are lists of Python Editors and Python IDEs.

My bias is towards Wing IDE (note 2.0 is still in beta tho).

Re:a series of well planned coincidences-Sour Frui

[Anonymous Coward]

You're right. Project failures did occur before Visual Basic and MS Access. But then again, so did all the tools inadequate for the jobs they were supposed to solve. As did wannabe programmers who never coded for fun.

If you do it for money, and money alone, you'll never become great at what you do. Good, possibly, but you'll never be *great*. That goes for all professions in life. 'Nuff said.

Re:NIGGER OWNER'S MANUAL

[angrykeyboarder]

How am I a troll? I was asking how we can get rid of this stuff....

Re:The Apocalypse is Nigh!

[rusty0101]

e of pi

Good programming books

[ralejs]

My thesis on programming books:
No matter how many books there are in a particular subject you can only find about 5 books that are good.

My colleauges thinks that 5 is an overestimation. Anyway, it's nice to hear about yet another good programming book. I'll make sure to check it out.

Python is great

[sad_]

But i keep finding myself to use Perl at work all the time. Why? Well, i'm a sysadmin and all my colleagues have some knowledge of Perl as well, but no Python and they certainly don't have any interest in learning it. Even when looking for a job i have found the interviewer to act surprised when i say i prefer Python over Perl.
But no question about it, when i'm working on personal projects i go for Python all the time.
This book is excellent, although i used the 'learning Python' from O'Reilly and ofcourse the online documentation (which is also more then excellent!)

Perl Props

[doodaddy]

I agree with the author of this review that this kind of book can be very useful and refreshing.

Giving props where due, this review reminds me of another book: "Learning Perl" by Larry Wall. Or actually maybe it's "Programming Perl" by Schwartz and Phoenix, but I'd guess Larry Wall to write the different kind of book. I know Python lovers will never, ever admit to any Perl roots, but the Perl book was very similar to "Diving into Python" in that it taught you by examples full of diverse concepts. Maybe this is where the author of the Diving book gots the idea?

(Also I followed the link in this review to regular expressions, and thought that Python-lovers should really love Perl since it makes this topic similar but even easier. Nyah nyah.)

P.S. Also the book "Programming Windows With MFC" by Prosise had a similar holistic approach. The Perl and MFC books are a couple of my favorites for that reason.

P.P.S. After Perl 4, though, it got so complicated that I never did use Perl 5. I did, however, learn a lot about objects by the way Perl 5 implemented them in a twisted new way. And that I didn't really need everything to be an object (another Python slam? You young kids should learn something from the old school now and then) I also learned that a "scripting" language can be as expressive as a complete language, which ruined all the fun.

It's ironic

[tubegator.com]

Good programmers are too busy to write books.

The whitespace nazis

[khallow]

This is something I always did in other languages anyway, so Python's whitespace handling never bothered me. Improper whitespace drives me nuts (too hard to read), so a language that enforces proper whitespace is perfect to me.

I at least can understand the reason for enforcing whitespace as Python attempts to do, misguided as it is. But enforcing effectively incompatible forms of whitespacing? That is annoying.