Foundations of Python Network Programming 144
| Foundations of Python Network Programming | |
| author | John Goerzen |
| pages | 500 |
| publisher | Apress |
| rating | 9 of 10 |
| reviewer | Sarusa |
| ISBN | 1590593715 |
| summary | If you program in Python, and you want to write Internet applications, you need this book. |
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.
Amazon (Score:2, Informative)
Typos (Score:5, Informative)
Re:Amazon (Score:5, Informative)
-- Sex Toys... [secondnirvana.com]
Python Web Programming (Score:2, Informative)
It also had a brief Python tutorial in it, but I kind of skipped over that, so I can't vouch for that part. The rest of the book will definitely teach you a bit about network programming, web/database programming, and things of that nature. For most of the /. programmers it might be pretty old hat since they were doing this stuff in the womb, but for unexperience programmers such as myself, I found it helpful.
Re:Look, I program in Perl (Score:4, Informative)
import MyModule
MyModule.SomeFunction()
Or:
from MyModule import *
SomeFunction()
SWIG rocks for plugging into C/C++/Libraries. (Score:5, Informative)
I can't say enough good things about SWIG. It's an amazing piece of work that has saved me years of menial labor and enabled me to integrate all kinds of compex code into Python, from hairy C++ templates to third party Win32 libraries for which there is no source code. It works extremely well with Python, and many other languages too.
Here is the blurb from the web site www.swig.org [swig.org]:
SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages. SWIG is primarily used with common scripting languages such as Perl, Python, Tcl/Tk and Ruby, however the list of supported languages also includes non-scripting languages such as C#, Common Lisp (Allegro CL), Java, Modula-3 and OCAML. Also several interpreted and compiled Scheme implementations (Chicken, Guile, MzScheme) are supported. SWIG is most commonly used to create high-level interpreted or compiled programming environments, user interfaces, and as a tool for testing and prototyping C/C++ software. SWIG can also export its parse tree in the form of XML and Lisp s-expressions. SWIG may be freely used, distributed, and modified for commercial and non-commercial use.
-Don
Re:Twisted Framework (Score:5, Informative)
The bonus to Mr. Goerzen's use of Twisted in IMAP is that I came away with a much better understanding of how to use Twisted generally -- I grokked Deferreds for the first time. And I'd read all (ALL) the Twisted documentation I could get my hands on prior to that. That probably gave me the proper background, but the book really kicked in to place those final pieces necessary to get what was going on in Twisted.
The book doesn't just cover "raw" network programming, but covers multiple domain-specific areas and points you to the best libraries and modules to use for the area.
Good stuff, I highly recommend the book.
Re:Typos (Score:3, Informative)
On the other hand, the content is excellent, truly a good book. And so far, my binding hasn't broken, FWIW. But it was stiff, and doesn't want to lay flat on its own.
Re:Every Perl programmer should switch to Python. (Score:2, Informative)
Now I use Pythons re() module which takes a little getting used to. While I'm at it, for those of you that write complex or deep regular expressions where re() craps out, there is a much more stable legacy module called pre() that seems to be undocumented. It works exactly like re(). The only difference, it trades speed for stability.
Re:Have you tried Ruby? (Score:5, Informative)
As a background to my choice, here's what I use it for:
I tend to write primarily for the Win32 platform and most of my applications have GUI front-ends they speak to MySQL databases, and often also control third party applications via COM. Aside from the COM stuff (the apps I'm controlling are only available for Win32 anyway) my software is fully cross-platform which is desireable. I love and use GNU/Linux extensively, and am starting to see an interest from the SME market which is encouraging.
I've used Python a lot and Perl a fair bit, plus I've looked at and thoroughly expected to fall in love with Ruby and Lua. I didn't.
I've realised that all four languages are so similar in many respects, that it's very difficult to convince a person using one to convert to another unless they have a very specific need. So it's just not worth trying.
If the language you are using does the job for you, then stick with it. Once you know the work-arounds for its deficiencies (and they all have them) then there is even less reason to change.
Trying to be objective, here's how I find each of the languages:
Python - Extremely easy to pick up, which is actually good for experienced programmers as well, but at the same time very flexible and powerful. Very readable and easily maintainable code. Good range of libraries (but nowhere near as many as Perl) which all stick closely to a well established "pythonic" way of doing things. You don't have to choose from a dozen different libraries that all claim to do the same job. The interactive shell is also remarkably useful for experimentation and debugging. Most good programmers indent their code anyway, and I don't know anyone that found the forced indentation a problem unless they were deliberately being arguamentative. The concept of packages is very simple and neat - you don't need to do anything special to allow importing of your code. Object orientation is very flexible, straight-forward and powerful. There are a large number of precompiled libraries with installers for Win32 platforms - don't ever underestimate how important this is in when using scripting languages in the current commercial environment. Extensive and uniform use of dot notation. Good range of freely available cross-platform IDEs. Like most Python bindings, those to GUI libraries are generally much easier to work with than the original C libraries.
Perl - Very powerful but extensive use of special characters rather than keywords can tend to result in code which needs reading several times to fully comprehend. Having built-in regular expressions is both useful and powerful, but only adds to the problem of making code less readable. Th eobject orientated aspects of the language are very much bolted on, and far from elegant. Functionaly they're quite capable, but certainly not pretty. It's very easy to code in your own style with several ways of doing the same thing, not necessarily a bad thing, but it does means there is more to learn of the core language if you want to be confident about being able to maintain code written by others. You do feel that you have flexibility in your choice of coding style which is always nice. Immense number of additional libraries, available from one source - the wonderful CPAN - but there is also a good deal of duplication, and you need to spend time evaluating the options to find one that has the features you need and works the way you'd like. Packages have to be written or at least bundled up as such. That said, it's available by default on *nix systems, it's also very closely tied into the operating system and shell which makes OS related stuff in Perl a breeze. Win32 support is available, but Perl is only truly at home in a *nix environment. The bindings to most cross platform GUIs are aften more complicated and difficult to use than the C equivalents.
Ruby -