Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Books Media Book Reviews

Foundations of Python Network Programming 144

Sarusa writes "This may be the easiest book review I've ever written. If you program in Python and you want to write Internet applications, go buy Foundations of Python Network Programming by John Goerzen. There. What, you wanted more? Well, okay, but then I'm back to playing Katamari Damacy." Read on for the rest of Sarusa's review.
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.

This discussion has been archived. No new comments can be posted.

Foundations of Python Network Programming

Comments Filter:
  • Amazon (Score:2, Informative)

    The book is cheaper through Amazon [amazon.com]
    • Re:Amazon (Score:5, Informative)

      by justMichael ( 606509 ) on Thursday October 14, 2004 @03:57PM (#10528836) Homepage
      Or you could actually shop around [allbookstores.com] or go to bookpool [bookpool.com], where it is $28.50 they don't show up on all book stores.

      -- Sex Toys... [secondnirvana.com]
      • even cheaper at overstock and walmart via shopping.com [shopping.com]
      • Put your sig in the sig box rather than in the body of your message. I shut those off for a reason.
      • NightGoat has solved a mystery for me... I emailed you guys (secondnirvana) a while ago about changing your "go away youngins" link to scarleteen. and you did! yay! I just happened upon the email I got back from you a few days ago and was wondering where i'd seen it. I guess it was on here :-)

        -Leigh
  • Twisted Framework (Score:5, Interesting)

    by BridgeBum ( 11413 ) on Thursday October 14, 2004 @03:56PM (#10528808)
    Another good Python network resource: Twisted Matrix [twistedmatrix.com], a networking framework for Python.

    For those interested in starting in network programming in Python, I'd recommend checking it out.
    • I'm familiar with the Twisted Framework (TF), and was about to ask: does this book cover TF? TF is quite nice, but if I remember correctly, it's quite a bit piece of software, and has a steep learning curve. Does this book go over TF or just 'raw' network programming with Py?
      • Re:Twisted Framework (Score:5, Informative)

        by Phoukka ( 83589 ) on Thursday October 14, 2004 @05:04PM (#10529521)
        The book makes extensive use of Twisted in covering IMAP programming, and also in its exploration of how to design a server, specifically the asynchronous, call-back approach. It does not cover the entirety of Twisted, that would be a book all to itself.

        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.
        • Whoever makes an actual book about twisted (a good one), let me know and I'll buy it.

          I've been hoping for someone to do this for a long time... Not very likely to happen though...

          The documentation is huge and pretty good but it just doesn't cut it for me...
  • Typos (Score:5, Informative)

    by 2.7182 ( 819680 ) on Thursday October 14, 2004 @03:56PM (#10528819)
    I liked this book a lot, but there are an awful lot of annoying typos. Also my binding broke after a week.
    • Re:Typos (Score:3, Informative)

      by Phoukka ( 83589 )
      There are a fair number of typos, mainly in the text from what I saw. All the code looks good (though I haven't tested it all). It seems to me that John Goerzen made sure the code all worked, and wrote the text around it, maybe before it. Unfortunately, it looks like it was rushed to meet a deadline at some point, and the text did not get reviewed and edited as thoroughly as it might have needed.

      On the other hand, the content is excellent, truly a good book. And so far, my binding hasn't broken, FWIW.
    • Re:Typos (Score:4, Interesting)

      by legirons ( 809082 ) on Thursday October 14, 2004 @05:14PM (#10529611)
      "Also my binding broke after a week"

      As practicalities go, the one thing I really liked about the last APress book I got ('Dive into Python') was that when I wanted to refer to it at work, I didn't have to carry the book in, I just read the section I wanted on their website.

      It was one of those "never going to buy another book without this facility" moments... how could we have missed something so useful for so long?

      So back on topic, this book only has one chapter available for download, and it's in PDF rather than anything useful, so I guess it's not general policy to make all APress books downloadable.

      I did find it amusing how Visual Basic, C#, and .NET each get their own top-level section at the APress website, while PHP, Perl and Python are down in the "Open-Source" section next to books describing products (Apache, Linux, Plone, MySQL, etc.)
  • And I see no need to switch to Python. My question is: How easy is it to wrap your code in a library/module and call it your own so you can call it your way? When I tried Python, my first impression was that this was a really readable and relatively easy language to program in, but it just wasn't a Swiss-Army chain saw. You were doing things over and reinventing the wheel all the time. This might have been just me. I admit to being a bigot and a classic pig-headed perl person, but with the nightmare that is
    • by kevin_conaway ( 585204 ) on Thursday October 14, 2004 @04:00PM (#10528875) Homepage
      I learned perl before I learned python and I found that the OOP constructs in python were better than perl. In perl they just feel bolted on while in python, they are built in from the ground up. Other than that, not much difference in my opinion
    • by Quixotic137 ( 26461 ) <pjennings-slashdot2.pjennings@net> on Thursday October 14, 2004 @04:22PM (#10529097) Homepage
      Put your code in a file called MyModule.py. Then you can use it just like modules in the standard library:

      import MyModule
      MyModule.SomeFunction()

      Or:

      from MyModule import *
      SomeFunction()
    • Do you want to call modules you wrote from a python program? Or do you want to call python modules from perl. For the latter look no farther than cpan [cpan.org]

      For the former, first check out the python package index [python.org], which is the equivelent of CPAN to see if someone else has created a relevant package. If not, creating a python module from C code from python is easy [python.org]. As far as calling perl modules from python, that is one of the things Parrot is intended to do, so your savior will come with the apoclypse.
      • by SimHacker ( 180785 ) on Thursday October 14, 2004 @04:50PM (#10529399) Homepage Journal
        SWIG [swig.org] is an excellent open source tool for plugging C++ and C code and libraries into Python and other programming languages.

        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

      • You can also embed perl and use pretty much any perl module from python through PyPerl...
        http://www.python.org/moin/PyPerl
    • Programming in Perl is terribly irresponsible and foolishly self indulgent. It's like maturbating in public and not cleaning up after yourself.

      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

      • 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!

        O.K. Why don't you start with listing a single specific?
      • Have you ever written a single line of code?
      • by Anonymous Coward

        It's like maturbating in public and not cleaning up after yourself.

        Yes! whenever I masturbate in public I always wipe it up afterwards! The cashier at the supermarket really appreciated that!

    • by pclminion ( 145572 ) on Thursday October 14, 2004 @04:41PM (#10529300)
      And vice versa: Every Python programmer should switch to Perl.

      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 am a python bigot but one thing Perl taught me was how to quickly take advantage of regular expressions (looking at other peoples code).

        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.
      • I agree with you, but I don't think you go far enough. Going from Python to Perl isn't stepping very far out of your box. Why not try Lisp, Haskell, Erlang, Scala, Smalltalk, or ...?

        Different syntax and different libraries will open your mind a little. But when a language encourages (or forces) you to think differently, that's where your "square law" starts to kick in.

      • by don.g ( 6394 ) <<zn.gro.sid> <ta> <nod>> on Thursday October 14, 2004 @09:35PM (#10531602) Homepage
        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 :-)
        • by Anonymous Coward
          Try a few declarative languages, like Haskell (functional) or Prolog (logic).

          You're a little bit off there. Haskell is not declarative. It's just functional, as you said. Prolog is declarative though.

          If you want to try a nice variety of languages here's what I suggest:

          C - 'nuf said.

          Java or C# - Good application programming languages. Similar enough for learning purposes that it doesn't matter which you use. If you want to get into the inner workings, both are very interesting systems to learn about.

          Pe
      • My experience with Python and the community is that most people that use Python already know a number of languages.

        It doesn't take much googling to figure out a growing number of very experienced programmers are "discovering" python and the most common comment is something similiar to "...fun to program again..."

        Python is a main stay at my work place. A language that doesn't get in your way, you can just solve problems and create solutions.

        But, perl isn't going away. It's simply magic for one liners.
    • by Colonel Panic ( 15235 ) on Thursday October 14, 2004 @04:50PM (#10529394)
      I really think that if you're coming from Perl you'll prefer
      Ruby [ruby-lang.org] to Python. No indentation hassles with Ruby, for example. You'll also like the way Ruby does OO compared to Perl OO. More [rubyforge.org] Rubilicious [ruby-doc.org] links... [rubygarden.org]

      Also, The Pragmatic Programmers [pragmaticprogrammer.com] 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
      • by ciw42 ( 820892 ) on Thursday October 14, 2004 @07:06PM (#10530570)
        Although I've used seeming every language under the sun at some point during the past 20+ years, my language of choice for most projects these days is Python.

        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 -
        • The availability of additional packages is currently rather limited.

          The new second edition Programming Ruby by Dave Thomas & co. has an excellent section on built-in classes and modules that starts at page 427 and goes to page 777 - and even it is not exhaustive. I've done Ruby programming for pay and I've not found that Ruby was lacking any functionality that I've needed. Sure, Perl's CPAN is bigger than Ruby's RAA, but there's quite a bit of redundancy in the CPAN as well. I suspect that we're ga
          • If the ruby folks can make something like jboss but without the insanity that's J2EE that would be amazing. The python people have zope at least which is nice but I would say equally as insane as J2EE.

            A nice clean container for publishing objects and frameworks for logging, testing, cron, and remote objects.
          • One of my earlier points was that there has to be a good reason to move from one langauge to another, and for most people there is nothing lacking in the langauge they are using, so a change makes very little sense. Blocks and lambdas may well be a killer feature of the Ruby language for you, but I've coded in plenty of different languages over a period of 20+ years, using most of them in a commercial environment, and haven't needed or ever felt the desire to use them. So for me they're not a reason to cha
        • "Good range of libraries (but nowhere near as many as Perl) which all stick closely to a well established "pythonic" way of doing things."

          Unlike perl they are scattered all over the web and you'll have to google for the module you think you need. There is no equivalent of perl -MCPAN so installation of the modules can be a pain if there there are dependencies.

          "You don't have to choose from a dozen different libraries that all claim to do the same job."

          This is flat out false. There are lots of SOAP libr
          • I specifically mentioned that Python had no equivalent to CPAN, and that this was a negative. Whilst the libraries themselves are scattered over the net, python.org has a package index which acts as a kind of simpler, but still useful version. I've coded in Perl commercially, and know plenty of Perl programmers, many of which treat Perl a religion. There's certainly nothing wrong with that, but they all say the same when it comes to finding a library to do a specific job - whilst they are easy to find, the
      • No indentation hassles with Ruby, for example

        This is always brought up - oh no, Python enforces indentation. This is not a hassle - five minutes using Python and you won't even notice!

        • Sorry, it's not _not_ a hassle. It's just not a big one.

          Indentation sometimes gets screwed up when you move a chunk of text around. Sometimes you 'fail to proceed' when you run tests and it's because of a screwed up indentation. It's easy enough to diagnose and pretty easy to fix, but it is a hassle.

          Also, if you have a crappy text editor (or if you have crap skillz) you can get in trouble when you have to indent a chunk of text. Not a big hassle, just a little one.

          Despite these two exception, python's me
    • 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.
    • One word for ya. RUBY.
    • 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.

    • My question is: How easy is it to wrap your code in a library/module and call it your own so you can call it your way?

      For python code: insanely easy, modules and packages are just files and directories, and your own libraries snap into the place just like they were part of the stdlib.

      For C/C++: still rather easy, even if you do it manually, with pyrex or swig, it's even better. The best part is, you call C extension just like you a python module, there's no difference in whatsoever, programmer using the
  • by lukewarmfusion ( 726141 ) on Thursday October 14, 2004 @04:00PM (#10528864) Homepage Journal
    "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.
    • 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.

      If you are doing your own encryption, it's going to be easily crackable. Encryption is definitely something that needs to be done in a peer-reviewed library.

      What's wrong with, say, SSL?
      • 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.
      • To clarify, I was referring more to the implementation of existing encryption tools and algorithms. I was programming basic stuff for a long time before I ever needed to think about encrypting data for transmission (say with SSL or PGP) or storage (including hashing). I'm no expert (I know enough not to try creating my own algorithm), but without the fundamentals it's really easy to make mistakes. Costly mistakes.
    • by Anonymous Coward
      I totally have to disagree with you. I hate when I spend good money on a book about a subject and then there is a bunch of extra crap thrown in there I feel ripped off. For example: just about half of all the security books I own waste a whole chapter on TCP/IP going over the fucking OSI model and crap. True you should understand TCP/IP if you want to understand security but one chapter in the front of the book is not going to teach you all you need to know about TCP/IP. You'd be better off just buying a se
    • by Phoukka ( 83589 ) on Thursday October 14, 2004 @04:54PM (#10529420)
      Okay, I have read the book, and the review author is correct in his statement. No, the book will not teach you the OSI model, nor will it teach you general networking theory to an expert level. However, I came to the book with a general knowledge of Python and a poor-to-middlin' understanding of network programming in particular. I've built web apps using pre-existing frameworks, for example, but I've never written code to work with sockets.

      Having read the book, I understand socket programming, general network programming, and could probably design and implement my own application protocol -- badly, of course, but still... Could I have done this prior to reading this book? No. Did this book make it easy to pick up the necessary background, as well as make it easy to pick up the specifics of network programming in Python? Yes.

      This is a great book, and is a must-have for Python programmers.
  • by mslinux ( 570958 ) on Thursday October 14, 2004 @04:05PM (#10528926)
    I use Python to administer computers... lots and lots of computers. It runs on Macs, Windows, Linux and all variants of Unix. It's one of the most portable languages around.

    I used to be a huge Linux buff (and still am when it comes to servers), but intelligent tools like Python make using Windows XP Home a much more fruitful and fun experience as I can actually get stuff done programmatically. Go Python developers and keep up the good work!!!
  • by Anonymous Coward
    I found Python Web Programming [amazon.com] a few years back covered almost all of what the review mentioned.

    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.

  • by ultrabot ( 200914 ) on Thursday October 14, 2004 @04:09PM (#10528968)
    Incidentally, Civilization IV is going to be moddable with Python [civfanatics.com]
    • How would you play roguelikes with a Dvorak layout on a laptop, since movement keys are based on Qwerty?
      • Can't you remap the keys in most roguelike games?
        • I'm thinking of Nethack with the number-pad turned off, and Angband with the "Rogue Keyset" option turned on, and Linlay's Dungeon Crawl. Maybe there is a way to remap in these games, but I've never run across it.
          • If they're all open source (which I think they are), you might have to get your hands dirty, but it's probably doable. You could probably find others to help, as the crossover between programmers and users of alternate keysets is probably higher than the average.

            I never really got into 'hjkl' as navigation keys, as even when playing the ports on my Amiga 500 I had a numberpad to use instead :) (Those keys were used in the early Unix editors for left-up-down-right, weren't they, thus the adoption by the gam
    • wow, thanks for the info.

      A bunch of friends and I were talking about civ 3 the other day, and how the biggest feature it lacks is some player useable scripting engine. I hope that it will be flexible and allow things such as iterating through all cities and setting production to cavalry where net shields are greater than 15 per turn, except if the city has no barracks, in which case set production to that. It's a pain to do by hand.
  • this a post that was done based on the book hope you find it to be a help the psot was done by John Goerzen (jgoerzen@complete.org)

    http://groups.google.com/ groups?q=Foundations+of+Python+Network+Programming &hl=en&lr=&selm=mailman.3337.1095202643.5135.pytho n-announce-list%40python.org&rnum=1

  • by PCM2 ( 4486 ) on Thursday October 14, 2004 @04:20PM (#10529069) Homepage
    Foundations assumes you already know Python, but nothing about network programming.
    Ah, but what of the Mule? Doesn't the presence of an advanced mutant of his scale defeat this whole premise?

  • For a minute there I really did think the title "Foundations of Python Network Programming" indicated that a new Python Network was being created for television and that they were laying the foundations and discussing what the programming schedule would be.

    Seriously, no joke. And by the way, a Python Network would be beat the Game Show Network [gsn.com] hands down !!!
  • by Anonymous Coward
    For anybody who has had to deal with this wretched monstrosity, python is a blessing thanks to the SOAPpy package.

    The usual way involves a pageful of obscure code, and having to use obtuse WSDL descriptor files and code generators to give you classes.

    But, hey, python can generate classes and methods on the fly. So getting the temperature at zip code 90210 becomes a one-liner after some standard imports:

    SOAPpy.WSDL.Proxy('http://www.xmethods.org/sd/2001 /TemperatureService.wsdl').getTemp('90210')

    I'm n

  • Python == good (Score:3, Interesting)

    by mcrbids ( 148650 ) on Friday October 15, 2004 @01:32AM (#10532770) Journal
    I spent some time learning a bit of Python, only to abandon it. Not because of Python, but because I had too much inertia going in various PHP projects that pulled me back.

    Python caused me to change my layout for code, almost instantly eliminating a big problem with c-like code: the missing brace.

    Most code is structured like this:
    Function fubar {
    statement a;
    do (b);
    if (c()) {
    performfunction(x);
    }
    }
    In this small segment, notice that there are to sets of braces - and they don't line up at all. You have to mentally follow the code after "fubar" and see that after the condition "if (c())" in order to mentally track the state of the braces.

    Compare this to
    Function Fubar
    {
    statement a;
    do (b);
    if (c())
    {
    performfunction(x);
    }
    }

    (slashdot's ECODE filter sux0rs)

    If you could see it, you'd notice that the braces line up. The opening and closing braces for the condition "if (c()))" are indented one more than the braces for function Fubar() which are indented more than the line "Function fubar()" itself.

    Thus, you merely have to follow the indents to match the opening/closing braces. As a result of this change, I spend less than 5 minutes per week matching up braces without the need for an IDE to match them up for me.

    Python seems to be a good language (I like that you can compiles sections of a Python program in c to improve performance without rewriting the whole program) but it's concepts of layout certainly carry beyond Python itself!

    • Or you could use K&R style:

      void function(args){
      if (<cond>) {
      <body>
      }
      }

      See how the closing brace for the if lines up with the if itself?
    • Uh... You make it sound like python invented that style. It didn't. Most java coders i know put braces like that. Alot of c-coders too, or well at least the smart ones ;)
  • Comment removed based on user account deletion

One good suit is worth a thousand resumes.

Working...