Slashdot Mirror
Foundations of Python Network Programming
First of all, 'Network' means 'Internet.' Everything in the book concerns protocols running over IP, which is almost anything useful these days. That said, this is a lot of ground to cover -- there's FTP, HTTP, POP3, IMAP, DNS, a veritable explosion of acronyms, and this book does a great job of hitting all the ones you're likely to need.
Foundations assumes you already know Python, but nothing about network programming. The first 100 pages covers the basics of IP, TCP, UDP, sockets and ports, server vs. daemon, clients, DNS, and more advanced topics like broadcast and IPv6. And in case you already know all that, how Python deals with them. This is the only part of the book you will probably read in order. After that you pick what you need.
Find a topic you need to know how to deal with, such as using XML-RPC, and locate the appropriate section of the book. There he'll cover the basics of the topic, show you how to use the correct Python module(s) to implement it, explain any gotchas (this is key!), and write a short but functional application or two that uses it. I'm not sure why this book isn't called 'Practical Python Network Programming.' It's eminently Practical. It won't make your heart race, but it tells you exactly what you need to get the job done.
All this information is out there to find for free, but having it all collected and summarized is worth every penny. And the real value is having the edge conditions and not-so-obvious practical details explained by someone who's obviously used this stuff in the field. Python and its excellent libraries make Internet tasks relatively easy, but it's even easier with some expert help, and the libraries assume you already know what you're trying to do. For example, if you're doing a DNS.Request() record query and using a DNS.Type.ANY, it (for good reason) returns information cached by your local servers, which may be incomplete. If you really need all the records you need to skip your local servers and issue a query to the name server for the domain. This is isn't hard; you just have to know what's going on. Or do you know which exceptions can get raised if you're using urllib to fetch web pages? It's here. Exception handling is not neglected.
So you know what you're getting, here's a laundry list of topics: IP, TCP, UDP, sockets, timeouts, network data formats, inetd/xinetd, syslog, DNS, IPv6, broadcast, binding to specific addresses, poll and select, writing a web client, SSL, parsing HTML and XHTML, XML and XML-RPC, email composition and decoding, MIME, SMTP, POP, IMAP, FTP, MySQL/PostgreSQL/zxJDBC (though you won't learn SQL), HTTP and XML-RPC servers, CGI, and mod_python. As a bonus you get some chapters on forking and threading (for writing servers) and handling asynchronous communication in general.
Just to find something to complain about churlishly, I wish Goerzen had managed to do all this and make it scintillatingly brilliant and witty from cover to cover (all 500 pages); perhaps dropping juicy bon mots of gossip from the Debian project. And while I'm at it I'd like a pony. No, seriously. If you program in Python, intend to do anything Internet related, and aren't already a Python networking god, you need Foundations of Python Network Programming. In terms of 'hours I could have saved if only I had this book sooner' it would have paid for itself many times over.
You can purchase Foundations of Python Network Programming from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
"All this information is out there to find for free, but having it all collected and summarized is worth every penny."
Is it? If you are, as the author says, someone familiar with Python but you have no clue about network concepts or programming, perhaps this book isn't for you. The first 100 pages or so are all intro to networking; after that, you have specific Python networking programming topics. Perhaps you'd be better suited with a networking book and then this book (sans the first 100 pages).
I've read a few books on programming languages and when they decide that the reader needs an intro to something, they usually provide pretty poor coverage of that topic. You end up being lost after you get done with the intro section. I did this when I was learning some encryption programming... before I could start actually writing code that deals with encryption, I needed a solid base. Instead of trying to teach me all I needed to know, the reference I was using pointed me at the industry's best encryption and security books and authors (like Bruce Schneier).
Disclaimer: Not having read this particular book, maybe this one is different. I don't know.
Why not? It doesn't cost you a thing and so if you're going to be buying the book through Amazon, why not let him shave a little off the top. Are you really worried Amazon's losing money, or is this some dumb shit about him selling out? Who cares?
Because Apple doesn't make damn good computers and amazon doesn't provide a service that allows people from anywhere to get pretty much any book. Good call. We, in general, don't like Sco because Sco is trying to make money by exploiting Linux (and doesn't really do much else), which is one of the greatest triumphs of free software/open source. We don't like the RIAA because they (at least attempt to) infringe upon fair use. It's not because they're sue-happy that they've caught the ire of many slashdotters. If that were the only criterion half of the United States alone would be the subject of slashdot rage. I don't know of Apple or amazon.com trying to keep me from doing something I want or pay for something that should be free, so I'm not all that fussed.
If you choose to program in Perl, the poor suckers who are going to have to read, maintain, clean up and modify the code you wrote will hate your guts.
Programming languages should be designed primarily for PEOPLE to read, understand, write and maintain reliably, and only incidentally for computers to interpret and execute.
Perl goes against every rule in the book about readability, simplicity, learnability, maintainability, integrity, responsibility to the community and style. And for no good reason!
The naively celebrated fact that Perl always has 2 dozen special case syntaxes, idioms, implicit rules and perverted styles to write the same thing, adds absolutely no power to the language whatsoever, and just makes it harder to read, write and maintain.
Even if you're just writing "throw away" Perl code, not working on anything important enough to reuse or share with other people, you're still crippling yourself with lazy bad habits that will doom you when you get a real job or start working on a project worth sharing with other people.
-Don
Take a look and feel free: http://www.PieMenu.com
At least, for a month or so.
Knowing multiple languages increases your value as a programmer quadratically. I like to think that languages follow a square law. By doubling the number of languages you know, you quadruple your total skill and marketability as a programmer.
I've done significant stuff in both languages and there are definitely tasks where Python is better -- for example, command-and-control, super-high-level types of apps, which coordinate large systems of smaller programs. And Perl is vastly superior in other situations, such as processing enormous wads of data and formatting output. I've even written hybrid programs where Python and Perl code intertwine.
Step outside your box. You don't have to love the language you're learning, but consider it an investment in yourself. Saving money sucks too, but it's still a good idea.
I really think that if you're coming from Perl you'll prefer
Ruby to Python. No indentation hassles with Ruby, for example. You'll also like the way Ruby does OO compared to Perl OO. More Rubilicious links...
Also, The Pragmatic Programmers have released a new edition of Programming Ruby that's a great intro and reference to the language - go buy it from their website.
Ruby: Because I can't wait around for Perl 6 to get finished
don't know of Apple or amazon.com trying to keep me from doing something I want or pay for something that should be free
Try starting a small company that makes Apple clone hardware and see if Apple keeps you from doing something that you want.
I don't know of Apple or amazon.com trying to keep me from doing something I want or pay for something that should be free, so I'm not all that fussed.
Unless of course you want to use something like an affiliate program or 1-click ordering, which Amazon has patented.
Amazon is still on my shitlist, but the great thing about the internet is you can "shop" at amazon and then click-click, buy your book somewhere else, with a clear conscience.
Python isn't a Swiss Army Chain saw-more like a table saw. Both Python and Perl have their place. I've used Perl happily when doing my own projects-but I've found that Python is _much_ easier to adapt newbies to using-and much easier for process oriented managers to deal with who otherwise might consider Java. I have personally seen older Cobol programmer who were utterly intimidated by VB,Java and other newer languages look and Python and relate easily to Python.
I don't use Python for much, but one of the primary reasons when I do is that a small, hacked together, uncommented python script is way easier to read months or years later than a similar Perl script or C source.
Play Command HQ online
Regardless of the merits of the languages I think you'll severely miss CPAN if you switch to python. CPAN is the best thing about perl and python has nothing really like it. There are a couple of so called repositories but they don't hold a candle to CPAN.
evil is as evil does
The first thing you get from a "solid base" of encryption knowledge is the concept that doing your own encryption algorithms except as an exercise is a really bad idea.... But that doesn't mean that you can write application programs that use standard libraries like OpenSSL without a solid understanding of what the encryption technology's doing - you really do want to be more than a script kiddie in this field.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
If you consider yourself to be a $LANGUAGE programmer, then there's something wrong.
:-)
As the parent post says, knowing multiple languages is good. One of my pet annoyances is hearing people describe themselves as a programmer for a specific language -- there are many more out there, and to say you only do one speaks volumes about the lack of breadth of experience you posess.
And don't just stick with imperative object-oriented languages. Try a few declarative languages, like Haskell (functional) or Prolog (logic). Yes, getting your head around them is hard. But you'll be glad you did.
Disclaimer: I'm a student doing an MSc in Computer Science, and by lines of code, most of what I wrote in the last twelve months was Perl, and was completely unrelated to my thesis
Pretend that something especially witty is here. Thanks.