Slashdot Mirror


The Python Cookbook

Nice2Cats writes "Python is something of a programmer's dream and an author's nightmare. What started life as a scripting tool for the Amoeba operating system has matured into a full-blown programming language with such speed that every book seems to be outdated in a year or two. To make matters worse for publishers, the crew around Python's creator Guido van Rossum keeps adding higher-level constructs such as iterators with every new release, reducing reams of code to single-line idioms at half-year intervals. Because not everybody has been able to keep up -- RedHat 7.3 infamously still ships with version 1.5.2 as the default, while SuSE 8.0 is hanging in there with version 2.2 -- authors are forced to cover stone age variants as well as modern forms. Python is cross-platform (Unix/Linux, Mac, Microsoft), has two underlying languages (C for Python, Java for Jython) and works with various GUIs (Tkinter, wxWindows, Qt, GTK, curses, Swing). Given this breadth of material, the idea of writing that most fragmented form of a programming book, a 'Cookbook,' seems as crazy as, say, nailing a dead parrot to its perch." Read Nice2Cats's review below of The Python Cookbook to see how well O'Reilly deals with dead parrots. The Python Cookbook author Alex Martelli and David Ascher pages 574 publisher O'Reilly rating 8 reviewer Nice2Cats ISBN 0596001673 summary A recommended book for the language with no Slashdot icon.

Beautiful plumage. O'Reilly, fortunately, has all kinds of experience with animals.

The Python Cookbook consists of seventeen chapters that contain between eight and twenty-six individual recipes. Chapters and recipes are roughly ordered by increasing complexity, length, and required background knowledge, starting with the simple "Swapping Values Without Using a Temporary Variable" and ending with the complete module "Parsing a String into a Date/Time Object Portably." The chapters are mostly organized by subject -- "Text," "Files," "Object-Orientated Programming," "User Interfaces" -- but also include "Python Shortcuts" and "System Administration." The background required varies: Whereas the chapter on "Text" starts off with Fred L. Drake reviewing the most basic string operations such as slicing and concatenation, Paul F. Dubois can only sketch the core concepts of lexing and parsing in "Programs About Programs."

This of course is a hallmark of all cookbooks, programming- or food-wise: Nobody will like everything, but everybody will like something. The worst fragmentation occurs, as expected, between examples of Python 1.5.2 and Python 2.2. Most recipes give preference to one version, and then point out how the problem could have been solved in the other version. This is more useful than the code that was written for all versions, because it gives a deeper insight into the changes that Python has gone through. The result is that after a few chapters, you start wondering why anybody in their right mind would keep using Python 1.5.2 instead of 2.2.* with its iterators, list comprehensions, new classes, and expanded module library.

Martelli and Ascher have done a good job balancing the different forms. Only one chapter struck me as lopsided: "System Administration", where ten of the sixteen recipes are Windows-only. Even though there is a good reason for this -- Microsoft's native administration tools just aren't like those provided with Unix -- the editors might want to rethink the selection of recipes in this chapter for future editions.

Generally helpful. The "Python Cookbook" has helped me in three ways. First, I found quite a lot of the examples themselves, especially those in the chapters "Python Shortcuts" and "Object-Orientated Programming" useful for everyday work. Second, reading more than 500 pages of peer-reviewed and well-commented code gave me a greater feeling for common idioms and constructs that are rare in this clarity in wild-type code. However, the book is strongest when more general principles of "Pythonic" programming are discussed, for example when Martelli demonstrates the merits of the "Look Before You Leap," "Easier to Ask Forgiveness than Permission," and "Homogenize Different Cases" methods.

My favorite recipe is Sebastien Keim's "Implementing a Ring Buffer," where an object carries a class deep in its bowels, and changes into this class in a rather cool Dr.-Jekyll-to-Mr.-Hyde transformation on the fly. The one recipe I found downright evil was "Sending HTML Mail," which should have been implemented as "Turning HTML Mail into Plain Text" with a note on how people who send HTML mail are going to be the first against the wall when the revolution comes. The best quote in the book comes from Tim Peters: "We read Knuth so you don't have to" -- Python's promise of programming power for the people, expressed in (dare I say it) a nutshell.

Conclusion:

I can recommend the "Python Cookbook" wholeheartedly to anyone who has passed into the advanced stage of language learning and is willing to actually sit down and work through the code. Anybody who is looking for a deeper understanding of Python, solutions to common coding problems, or starting points for their own projects will also profit. This book should have RedHat customers hammering at the gates of Raleigh, demanding the power of iterators and list comprehensions that their SuSE counterparts already enjoy by default; it demonstrates the superiority of Python 2.2.* over 1.5.2 in great detail.

Because of this, however, my guess is that 2.2.* will quickly replace 1.5.2, turning large parts of this book into historical footnotes in two years at the latest. This is no fault of O'Reilly's, but rather a current fact of Python life. The editors have done a good job of nailing the parrot, and until this Pythonic Norwegian Blue does the inevitable backflip, it should give its owner much pleasure.

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

82 of 221 comments (clear)

  1. They don't eat pythons, do they? by Darth+RadaR · · Score: 5, Funny

    The title "Python Cookbook" has gotta look weird to people bopping around Barnes & Noble who aren't in the know. :)

    --
    /*drunk.. fix later*/
    1. Re:They don't eat pythons, do they? by wirefarm · · Score: 5, Funny

      I was at a bookstore years ago and this old preacher-type guy came up to me and started saying how pleased he was to see a young guy like me interested in religion -

      I didn't have the heart to tell the guy exactly what "Linux Bible, the Gnu Testament" was about...

      (Then again, I probably do as much preaching about Linux as he does about God - maybe we should get it declared a religion and get tax-free status...)

      Cheers,
      Jim in Tokyo

      --
      -- My Weblog.
    2. Re:They don't eat pythons, do they? by Nailer · · Score: 2

      (Then again, I probably do as much preaching about Linux as he does about God - maybe we should get it declared a religion and get tax-free status...)

      Hey, it worked for Scientology ;)

  2. Alternative Cookbooks by WIAKywbfatw · · Score: 4, Funny

    And for those of you that can't get your hands on a python, the adder, asp, boa, cobra, diamondback, etc cookbooks are just as well packed with tasty recipes.

    --

    "Accept that some days you are the pigeon, and some days you are the statue." - David Brent, Wernham Hogg
    1. Re:Alternative Cookbooks by sielwolf · · Score: 5, Funny

      Huh, I looked on O'Reilly's website and I couldn't find the ASP or Corba Cookbooks any- oh wait...

      --
      What is music when you despise all sound?
  3. Darn... by Kierthos · · Score: 2, Funny

    And here I was hoping for the recipe for crunchy frog.

    Kierthos

    --
    Mr. Hu is not a ninja.
  4. Python cookbook by gowen · · Score: 2, Funny
    As Mrs Beeton might have written: First catch your python

    Or, as Homer might add: "...mmm...python"

    --
    Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
  5. Not sure about cooking up a Python, but... by qurob · · Score: 5, Funny


    Cornmeal Crusted Rattle Snake with Cactus-Corn Succotash

    Recipe courtesy Joey Altman, Copyright 2001

    2 1/2 pounds rattle snake, dead
    1 cup buttermilk
    1 cup cornmeal
    1 cup flour
    1 tablespoon salt
    1 tablespoon chile powder
    1 tablespoon garlic powder
    1 tablespoon paprika
    1 teaspoon cayenne pepper
    1 teaspoon ground cumin
    1 cup vegetable oil
    Cactus-Corn Succotash, recipe follows
    Using a sharp boning knife remove the meat from the snake by cutting down the back, just slightly to 1 side of the spine from the head to the rattle. Using the tip of the knife peel the meat from the ?rib cage?. Once you removed the 2 long strips of meat, lightly pound them with the back of the knife to tenderize them. Cut the strips of meat into 1-inch pieces and place in a bowl with the buttermilk. Mix to coat well. In a large bowl combine the cornmeal with the flour and the spices. Heat the oil in a large skillet on medium high heat. Dredge the snake pieces in the flour mixture and fry for 2 minutes or until golden brown and then transfer to a paper towel lined plate. Repeat until all the snake pieces are cooked. Serve with Cactus-Corn Succotash.

    Cactus-corn succotash:

    2 tablespoons olive oil
    1 cactus pad, thorns scraped off, cut into small dice
    2 ears corn, shucked
    1 red onion, peeled, sliced in rings, grilled with olive oil and chopped in small dice
    1 bunch scallions, grilled and chopped
    1 chayote squash, sliced 1/4-inch thick, grilled with olive oil and chopped in small dice
    1 tablespoon minced garlic
    2 tablespoons minced jalape?o
    1/2 cup diced red bell pepper
    4 tablespoons butter
    1 cup chicken stock
    1 cup diced, peeled and seeded tomatoes
    1/2 cup chopped cilantro
    Salt and pepper

    Grilling the vegetables first gives another great layer of flavor, however, it is not absolutely necessary. Just omit that step and cook the vegetable right in the pan. In a skillet on high heat saute the vegetables except the tomatoes in the olive oil for 2 minutes. Add the stock and butter and cook until mixture reduces by half. Add tomatoes and seasoning and serve with the warm snake ?nuggets? on top.

    Yield: 4 servings
    Prep Time: 30 minutes
    Cook Time: 10 minutes
    Difficulty: Medium

    1. Re:Not sure about cooking up a Python, but... by cjsnell · · Score: 2


      Gotta love the New-York-attorney-goes-to-the-dude-ranch sound of "Cactus-Corn Succotash". You find this sort of crap at upscale eateries in places like Aspen and Telluride. This recipe is proof that any mediocre ingredient can be dressed up enough to taste good. I've had cactus and rattlesnake. While both are edible, I'd rather have Cornmeal-crusted Amberjack with a Roasted Polenta Succotash any day.

    2. Re:Not sure about cooking up a Python, but... by BlackBolt · · Score: 2, Funny
      The best part of the recipe is of course
      2 1/2 pounds rattle snake, dead
      Dead? I was planning on having 2 1/2 pounds of LIVE rattlesnake roaming around my kitchen. Of course, if the snakes were still alive, I don't think they could honestly give this recipe a
      Difficulty: Medium
      I would hope for at least
      Difficulty: Fatal
      But for me, Kraft Dinner is almost fatal.

      BlackBolt

  6. I love python by paRcat · · Score: 3, Insightful

    There are those out there that hate any language that allows spaces to effect it's running...

    But Python just rocks. Throw pySQL, wxPython and Twisted into the mix, and you can have a full blown server with gui front-end that is just as stable as any other. I have a server that I wrote for wireless devices performing a few hundred SQL queries/changes and file writes per hour, and the speed is surprisingly very good for a language most people refer to as a 'script'.

    Not to mention, the tab requirement makes reading the code so easy. You just know where functions begin and end without having to deal with {'s and }'s.

    1. Re:I love python by William+Tanksley · · Score: 2

      Equally easy to misplace a }, as you mention; and much less visible.

      -Billy

    2. Re:I love python by Xtifr · · Score: 2

      But my editor will make it obvious when I misplace a }, as the indenting will automatically change. That is one thing I definitely miss when working with python -- the feedback I get from my editor is missing, which means I have to manually verify all of the indentation, and make sure it does what I want/mean.

      In practice, this proves to be a smaller problem than I originally expected (especially with good python bindings for my editor), and python is a beautiful language despite this minor wart, but I still consider it a problem with the language.

  7. Debian also has 2.2 by psgalbraith · · Score: 3, Informative

    RedHat 7.3 infamously still ships with version 1.5.2 as the default, while SuSE 8.0 is hanging in there with version 2.2

    Debian unstable also has 2.2 as the default python, although the stable release has 2.1. But with the huge number of packages which depend on it, it takes a while to migrate all of them. So testing still has 2.1.

    1. Re:Debian also has 2.2 by InodoroPereyra · · Score: 2

      And according to rpmfind.net, RedHat 8.0 too, and I can tell Mandrake 9.0 does (and 8.2 did), and the list goes on ... but yes, I never understood why RH 7.3 would ship Python1.52. They actually use python a lot for their config tools (which I consider a smart decision). Anyways ...

    2. Re:Debian also has 2.2 by Ian+Bicking · · Score: 2
      Their tools depended on Python 1.5.2. Which would be fine if they had just used #!/usr/bin/python1.5 at the top of their scripts.

      The real problem was they used #!/usr/bin/python , and if you wanted to use a more modern Python as the system python (i.e., named simply "python") then you'd break system scripts. It's never been a problem otherwise to have two different versions of Python installed.

  8. how well O'Reilly deals with dead parrots by wiredog · · Score: 2
    Here's the answer to that one.


    Parrot is a new, dynamic programming language, intended to merge the indubitable strengths of the twin Open Source scripting giants, Perl and Python. Stemming from the Open Source conferences, and culminating in the unprecedented meeting of minds at the new ActiveState Technical Advisory Board, Parrot was conceived jointly by Larry Wall, the original creator of Perl, and Guido van Rossum, the inventor of Python. By uniting the unparalleled flexibility of Perl with the simplicity and maintainability of Python, Parrot is destined to become the premier application development language of the twenty-first century.
  9. Swapping Values Without Using a Temporary Variable by SloppyElvis · · Score: 2, Offtopic

    I have to ask (given my Python illiteracy), does Python have built-ins for such an operation? Or is this just "how to implement an old trick" to "get your feet wet" with Python?

    If my coffee is working correctly this morning, I'd assert that any language with an XOR-assign could accomplish this feat (with the added restriction that the vars be of the same size, or operations are performed iteratively on byte pointers).

    Below is chapter 1 of my new C cookbook:

    A ^= B;
    B ^= A;
    A ^= B;

    Short chapter.

  10. Python Cookbook? by loconet · · Score: 2, Funny


    Pythons? I heard they taste like chicken!

    --
    [alk]
  11. No Slashdot icon! by wiredog · · Score: 5, Interesting
    Something must be done! I request, nay, demand, that the Fearsome Slashdot Cabal develop a Python Icon immediately!

    Some sort of snake, perhaps...

    1. Re:No Slashdot icon! by Sloppy · · Score: 4, Interesting
      It's not just a Slashdot thing, either. Even outside the scope of Slashdot, Python surprisingly doesn't seem to have a logo or mascot or anything. You would think that over the years, some artisitic person would have drawn a cute (Tux-like cute, if you know what I mean) snake or something, and everyone would have latched onto it. But it hasn't happened. Oh sure, I have seen some snakes here and there, but none of them have been widely adopted.

      If someone pulls it off, they might become famous. ;-)

      --
      As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
  12. Perl comparisons by goombah99 · · Score: 3, Insightful
    What I would like to have would be a merger of the perl and python cook books. I know my own understanding of perl exploded when I discovered the perl cookbook. I am now convinced that understanding a languages idioms is the secret to fluency.

    It would be very instructive to me to be able to see how the two languages handle each other's idioms. I have my brain wrapped around perl and when I try to think in python I get frustrated cause things I think should be simple aren't. Of course the reverse would be true if I knew python better (I guess).

    At present I think my python programming is too formal, like someone who just learned say french trying to speak it and saying "To The beloved person who bore me onto this earth; please to be informed that I have translocated my corpus into the domicale that lies here" instead of just saying "mom, I'm home".

    --
    Some drink at the fountain of knowledge. Others just gargle.
    1. Re:Perl comparisons by snowbike · · Score: 2, Informative

      Check out Perl to Python Migration by Martin Brown. Sure, it isn't O'Reilly, and it doesn't have "cookbook" in the title, but I've found it a good start for the type of thing you are asking about.

    2. Re:Perl comparisons by goombah99 · · Score: 2, Insightful
      Have not read that one. However I have seen similar concepts on line like "python for perl programmers." And generally these are not filled with examples of pithy worked translations. THe cook book contains the true idioms of a language hence i'd like to see a true cookbook-cookbook cookoff.

      for example, consider an indexed sort. in both perl and python you could do this by writing a loop to add an index field to each value then sort it then loop to gather the ordered indices. The only difference is the loops and indexing and sorting would have different grammar.

      But in perl one would probably instead do a map-sort-map idiom on a single line operation. And in python I suspect there is probably some simmilar idiom using iterators.

      its the idioms, not the formal grmammar crossovers that are important to learning to learning a new language.

      --
      Some drink at the fountain of knowledge. Others just gargle.
  13. Re:Swapping Values Without Using a Temporary Varia by Anonymous Coward · · Score: 5, Informative

    a,b = b,a

  14. This is a fine book.... by nob · · Score: 3, Funny

    The perfect companion piece to Bake a Snake.

    --
    daed si luap
  15. Re:asdf by Phoukka · · Score: 4, Informative

    Much more to the point, Red Hat 7.3 has 1.5.2 as "python", but has 2.1 (IIRC) as "python2". And Red Hat 8 has 2.2.1 as its "python". And, as you said, it is eminently possible to download and compile the latest version, though you do have to be careful that you link in 2.2.x as "python2" rather than "python" on Red Hat 7.3, or many of the system apps break (up2date comes to mind...).

  16. 2.2 for RedHat by redfenix · · Score: 5, Informative

    This book should have RedHat customers hammering at the gates of Raleigh, demanding the power of iterators and list comprehensions that their SuSE counterparts already enjoy by default; it demonstrates the superiority of Python 2.2.* over 1.5.2 in great detail.

    Of course, installing a new version of Python in RedHat is pretty painless, download the rpm and install it. You can find them here.

    --
    "It's a very tangled subsystem." --Windows kernel guru
    1. Re:2.2 for RedHat by Linux_ho · · Score: 3, Informative

      RedHat 8.0 installs Python 2.2.1 by default.

      --
      include $sig;
      1;
    2. Re:2.2 for RedHat by disappear · · Score: 2

      Ah, but that was never the issue.

      The issue is that third-party packages depend on particular versions of Python, and you thus can't change the default version of Python between point releases.

      That is, when 7.0 was released, Python 1.5.2 was the clear choice, given how little Python 2.x code existed at that point. So for the entire 7.x series, Red Hat needed to stick with Python 1.5.x as the default version. Now with the 8.x series, Python 2.2.x is the default version.

      This is Red Hat's policy, and is quite sensible when you think about their userbase. They did a similar thing with Sendmail: 7.x used 8.11.x, even though 8.12 came out in the middle of the 7.x series, 7.2 and 7.3 both stuck with 8.11, because there were substantial changes with 8.12 (like no longer requiring that everything run as root...)

      The goal is to make transitions within a major release as painless as possible, not only for us dumb sysadmins but also for third-party software developers: anything built against 7.0 should ideally run against 7.3 without so much as a recompile. Less ideally, you shouldn't have to port it but just rebuild it.

    3. Re:2.2 for RedHat by disappear · · Score: 2

      Yeah, but for Red Hat to blame the customer (as they'd be doing: "Your scripts are the problem, not our distribution!") would be suicidal in the marketplace.

  17. Try Ruby! by Hornsby · · Score: 5, Interesting

    I used to code in Python, and now I use Ruby in it's place. I've found it to be just as readable but more terse. It's also extremely consistent in the way that everything is an object. You can say things like

    5.times {|n| puts n}

    and all kinds of other crazy things. I'm not saying it's better than Python(not trying to start a flame war). I'm just saying to try it and see if you like it.

    --
    A musician without the RIAA, is like a fish without a bicycle.
    1. Re:Try Ruby! by bwt · · Score: 2

      I certainly like Ruby, but I can't wait until parrot gets evolved enough so that Ruby and Python (and of course Perl) can all interoperate (and perform better to boot). Perl has absolutely huge collections of modules, but when you move to Python you give up some of them (Python has many equivalents, but not all). Moving to Ruby you give up even more. Why? We are triplicating our work. Everybody should compile to parrot.

      Compare Jython, which allows Python to use Java classes (and JRuby does the same for Ruby, but isn't as far along). This is a pretty powerful combination, but it suffers from the problem that Java isn't free software (free work-a-likes are slowly emerging, but aren't feature complete).

      I really think people should get excited about parrot. It has the potential to compete as a 100% open source solution with .net and java.

    2. Re:Try Ruby! by Hornsby · · Score: 4, Informative

      The "." is needed because 5 is an object of type Fixnum. times is a method available to Fixnum objects. I used that example to demonstrate that EVERYTHING in Ruby is an object. For instance, you can do the following:

      "hello world".upcase
      "HELLO WORLD"

      Not to mention method cascading

      "hello world".upcase.reverse
      "DLROW OLLEH"

      Once you get used to having these features, it's hard to go back(to Perl that is...). There are a number of other very nice features as well. Iterators for example(which Perl 6 is going to include).

      list = ["foo", "bar", "car"]
      list.each do |elem|
      # do something with elem
      end

      For a quick walkthrough of the languages features, go here: http://rubycentral.com/book/intro.html

      I do know when I see a language which does not have an intuitive syntax or grammar.

      And what language does? Any new language requires an adjustment period. The important thing is consistency once you get over the initial learning curve. Lisp doesn't necessarily have an intuitive syntax either; however, few would argue that it's not a powerful language. The consistency of having everything represented as a list makes it's syntax extremely simple.

      --
      A musician without the RIAA, is like a fish without a bicycle.
    3. Re:Try Ruby! by Fweeky · · Score: 2
      iterators:

      mylist=['foo','bar','car']
      for item in mylist:
      # do something with item

      Iterators are an expression of a deeper construct in Ruby; passing code blocks to methods. Example:

      File.open('foo') do |file|
      # do some file operations
      # maybe raise some exceptions
      end # file is automatically closed the the File.open method

      But it starts getting interesting when you start using the 'yield' statement (generators)...

      Funnily enough, something Python grew after Ruby had been using it for years.
    4. Re:Try Ruby! by Fweeky · · Score: 2
      I do know when I see a language which does not have an intuitive syntax or grammar.

      Intuitive is highly subjective. Ruby comes from the perspective of objects and method calls and passing code blocks around.

      While the "5.times" is rather obvious, if not leaving one wondering why a "." is needed

      "times" is a message sent to the 5 object; a Fixnum instance. Ergo it is the same as:

      class Foo
      def times
      # some code
      end
      end

      i = Foo.new
      i.times

      The code block being passed to it (the {|i| .. }) is incidental, and seperate from the method call itself.

      |n| would be read by your average degreed professional developer as "the absolute value of n", given its visual similarity to the well known and standard mathematical notation for this operation

      That's a SmallTalk thing; Ruby chose to reuse it. Typical use is more like:

      [1,2,3,4].each do |i|
      # do something with i
      end

      It's also fairly common to see:

      {'a' => 1, 'b' => 2}.each do |key, value|
      # do something with hash element
      end

      I guess the alternative would be something like:

      hash.each do(key, value)
      # ...
      end

      But since you can also use braces, you'd then get:

      hash.each {(key,value) .. }

      Which looks a bit nasty to me.

      Anyway, it doesn't take much to work out what it means even if you've never seen SmallTalk and friends. People are very good at handling different meanings in different contexts.
    5. Re:Try Ruby! by Fweeky · · Score: 2
      Does Ruby still have the perl-style variable warts?

      Yes it does; they're very tame, and no, they're not going away:
      $foo = 'bla' # global variable (not seen much)
      @foo = 'bla' # object instance variable
      @@foo = 'bla' # class variable (not seen much)
      Most of the time you only see @foo, and you can hide them behind accessors and just use self.foo if you don't like them. Ala:

      class Foo
      attr :foo

      def initialize(bla)
      if (coder_hates_at?)
      self.foo = bla
      else
      @foo = bla
      end
      end
      end

      @foo bypasses the accessor 'attr' produces, so is a bit faster.

      The $1..$9, $_ etc vars are still there, but you don't have to use those either. They're sometimes handy writing quick scripts and oneliners.
    6. Re:Try Ruby! by Ian+Bicking · · Score: 2
      I think the reason people aren't getting excited about Parrot is that it hasn't had any significant progress. Skepticism among Python developers has been high (by Python developers I mean the people who work on writing the Python interpreter), and there's been criticism that work has been directed towards optimization before any real language can be targetted for Parrot.

      Parrot would be cool, but a free CLR might come around a lot faster.

      I'm also unclear also how languages with significantly different semantics will interact. Ruby and Python, for instance, could interact very easily, since they have similar semantics. But Perl, for instance, considers "12" and 12 to be pretty much equivalent. But when you have some function written in Python, and you pass a string instead of a number, you're likely to get an error (or worse). So now the Perl programmer has to be aware of the languages he's interacting with, which is part of what we were trying to avoid.

      It's a hard problem, and I don't know that it's easy to solve.

    7. Re:Try Ruby! by Fjord · · Score: 2

      I also fnd it mor rdbl but mor trs

      --
      -no broken link
    8. Re:Try Ruby! by HiThere · · Score: 2

      The grammar of FORTH is intuitive. The grammar of the early LISPs was also intuitive (before they started adding things like macros).

      Problem is, if you have a simple, intuitive, grammar, then you need to have lots of words that don't have a simple, intuitive, meaning. In FORTH a good example is " (i.e., the word signified by a double-quote). This needs to do some fancy manipulation, because the language doesn't understand anything but see-it, do-it. (An even better example is (COMPILE), but that requires knowing the guts of the language.)

      So, if I remember correctly, the FORTH hello-world program would be:
      " Hello, World" .
      The first " siezes the input stream until it encounters a ", and places the address of the stuff on the top of the stack. The period prints whatever the top of the stack is pointing at. (Period might be the wrong command here, though. Which command to use where has long slipped from my memory.)

      But the grammar is as simple and intuitive as possible.

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
  18. Re:Swapping Values Without Using a Temporary Varia by thomas.galvin · · Score: 2

    Ah, fond memories. I remember showing that to a friend a while ago. He looked at it all cross-eyed, then ran off to see if it actually worked. Five minutes and a "holy s**t!" later, I knew he got it.

    And there isn't anything wrong with implementing an old trick to get your feet wet in a new language. "Hello, world!" is a classic for a reason. When you are learning somethign new, any tie you can make with what you already know is helpful.

  19. Re:Might actually be an interesting book to check by AndrewHowe · · Score: 2

    No, he doesn't, although he could have worded it better.
    QuArK is not implemented in Python.
    Scripting is implemented in QuArK, using an embedded Python interpreter.
    Smack!

  20. Re:asdf by lunenburg · · Score: 2

    Come on, you know it's not a Slashdot story without a ignorant jab at Red Hat! It's the new trendy thing to do!

  21. perl/python phrasebook by mcc · · Score: 5, Informative

    Try this site.. it's basically a "phrasebook" that shows common tasks being done in both perl and python. It's a great introduction to the language, and it helps a lot in terms of getting the python-idiom-y ways to do lots of commonthings embedded into your head.

    It isn't *very* long, and doesn't go too deep, and the formatting's not great, but it's a quick read, and if it doesn't fit your needs there's always that book Snowbike recommended.

    At present I think my python programming is too formal

    The catch about the funkiness of python's syntax is not that it demands formalism; it's just that it demands you will do only one thing per line. It's kind of hard to get yourself thinking this way, and it's really irritating to write code this way (i never write python without pining for a ?: construct, a single-line version of "except", or a less-crippled lambda construct).

    The thing is, though, that obeying python's rule basically comes down to seperating each expression into unnecessary variables, and mercilessly abstracting all those potentially-repeated 'common tasks' that somehow always seem to wind up taking five lines in python into functions. However, i find when i write perl, most of the time i spend revising code is spent going back and doing the above two things-- splitting overly-complex expressions into subvariables, pulling out bits of code and making them subexpressions. Python just forces you to do these things ahead of time, and you benefit greatly in the long run. (Whether that's worth all the irritation, though, i don't know :))

    1. Re:perl/python phrasebook by ameoba · · Score: 2

      The catch about the funkiness of python's syntax is not that it demands formalism; it's just that it demands you will do only one thing per line.
      -----------------

      counterexample:

      print (lambda A,D,B,C,E,F,G,H,Q:"\n".join(["".join([(Q[int(__imp ort__("math").log((reduce(lambda x,y:abs(x[1])<=D and (x[0]+1,x[1]**2+y[1]) or x,[(0,complex(r/B,i/B))]*A))[0]+1))%len(Q)]) for i in range(F*B,G*B,H)]) for r in range(C*B,E*B,H)]))(1500,4,100.0,-2.25,1.5,-1.25,1 .25,4,".^:/I&@*%$#")

      --
      my sig's at the bottom of the page.
    2. Re:perl/python phrasebook by steveha · · Score: 2

      it demands you will do only one thing per line. It's kind of hard to get yourself thinking this way

      No, I write code like that all the time.

      When single-stepping in the debugger, I really hate having multiple things happen in a single-step. It's so much nicer to be able to see things happen one step at a time.

      Back in the really bad old days, compilers might have been dumb enough that you would get worse code when you only did one thing per line, but that hasn't been true in a long time. Your single-statement lines will be folded by the compiler. With optimizations enabled, the compiler will generate the same code from

      x = foo();
      if (x)
      return;

      as from

      if (x = foo()) return;

      And I know which one I'd rather single-step.

      steveha

      --
      lf(1): it's like ls(1) but sorts filenames by extension, tersely
    3. Re:perl/python phrasebook by steveha · · Score: 3, Funny

      Thanks! You just made me laugh out loud, and that's always fun.

      Having to use a debugger at all is a sign that the code doesn't clearly express what it's going to do.

      No, it's a sign that the code isn't doing what you want it to do. Sometimes that's due to a flaw in your code. Sometimes it might even be due to something else, like an API call that doesn't do what you expect, or even an API call that is downright buggy.

      It's as silly to say that one should never need a debugger, as to say that one cannot do without a debugger.

      a debugger that can't even tell you which expression is about to be evaluated

      So, when you have a project on a platform with primitive development tools, what do you do? Refuse to work on the project?

      Tell me, what development tools do you use? They must be wonderful. Maybe I should use them.

      steveha

      --
      lf(1): it's like ls(1) but sorts filenames by extension, tersely
    4. Re:perl/python phrasebook by Peter+Harris · · Score: 2

      Cool! A functional declaration for a close-up rear view of a goat. ;)

      --

      -- What do you need?
      -- Gnus. Lots of Gnus.
  22. Re:Swapping Values Without Using a Temporary Varia by swingkid · · Score: 2

    Yes, it is: look here

  23. Re:Don't click on Slashdots book link by Gramie2 · · Score: 2, Informative

    Or $24.50 from www.bookpool.com, which is almost always better than other online bookstores, although I'm not sure how it does once shipping is factored in.

  24. Buying from evil companies by yerricde · · Score: 2, Insightful

    Get it from Amazon for [$3.99 cheaper]

    And fund enforcement of a patent that should never have been granted. If you want to preserve balance in the Force, you have to give to EFF every time you give to a company that employs "evil" practices with respect to statutory monopolies. That's why I don't buy more than $65 a year from Disney, Time Warner, Universal, or the other big nine copyright companies, and that's also why I don't buy from Amazon or use Unisys products.

    --
    Will I retire or break 10K?
  25. It had to be said by Torgo's+Pizza · · Score: 3, Funny
    Read Nice2Cats's review below of The Python Cookbook to see how well O'Reilly deals with dead parrots.

    No no he's not dead, he's, he's restin'! Remarkable bird, the Norwegian Blue, idn'it, ay? Beautiful plumage!

  26. Re:Swapping Values Without Using a Temporary Varia by AndrewHowe · · Score: 2

    I believe swingkid may be referring to the fact that if a and b are aliased to the same location in memory, the "trick" will go wrong (zeroing the value).
    But why would you swap something with itself?
    It would be almost impossible to achieve the aliasing in C, the only ways I can think of are:
    1) swap(a,a);
    2) union {int a; int b;} u;
    3) #define b a
    [or anything similar, i.e. int* b; b= swap(a,*b);]
    I would say that if you are swapping something with itself, you have a problem with your algorithm.

  27. Re:Swapping Values Without Using a Temporary Varia by PythonOrRuby · · Score: 2

    The parens aren't necessary. They are in Perl5, however.

  28. Language Development Speed by Bouncings · · Score: 4, Informative
    Actually, the rapid change in the language is pretty new. For the longest time, 1.5.x was stable, and years before 1.4.x was mostly the same. Then, 1.6 happened. Python hit some kind of critical mass where Guido decided to more or less open the flood gates of third party suggestions (called PEP's in Pythonlore). Another key factor was the rapid increase of XML libraries and concerns, as well as other quickly changing technologies.

    The author of this article doesn't mention it, but many Python programmers are upset with the rapid changes in the language, and it is very contrary to Python's history and philosophy. It looks like for now though, Python is slowing back down after implementing a new system of object orientation that really implements each variable/function/whatnot as an object. 2.2, hopefully, is here to stay for a while.

    --
    -- Ken Kinder ken@_nospam_kenkinder.com http://kenkinder.com/
  29. Re:Python icon by TeknoHog · · Score: 5, Funny
    > If someone pulls it off, they might become famous. ;-)

    Yeah, like the guy who drew Tux, whatshisname..

    --
    Escher was the first MC and Giger invented the HR department.
  30. Perl Python by PythonOrRuby · · Score: 2

    In my own experience, I've experienced the opposite. I was pretty good at procedural programming, but the OO stuff always seemed rather intimidating.

    Then a friend twisted my arm and made me learn Python, and it wasn't necessarily that Python does OO well, but that it makes it really quick and easy to experiment. Doing so gave me sufficient understanding to go back into Perl and figure out how packages and modules and such work.

  31. Re:Arghh Python by Rob+Riggs · · Score: 2

    Oh, blow it out your arse. Python is an object-oriented procedural language with some functional aspects thrown in for good measure. Python was never trying to be Lisp. And thank Guido for that!

    --
    the growth in cynicism and rebellion has not been without cause
  32. Re:Swapping Values Without Using a Temporary Varia by sql*kitten · · Score: 2

    a,b = b,a

    Pretty sure it works the same way in MATLAB, too, but I don't have mine here to check...

  33. HTML Email by DrSkwid · · Score: 2

    people who send HTML mail are going to be the first against the wall when the revolution comes.

    Congratualations on a thoroughly short-sighted viewpoint.

    HTML email is not just for spammers.

    The ability to send HTML forms to employees is a boon among other benefits.

    Maybe you've never shared the joy of sending an HTML birthday card to your child or parent.

    Perhaps sending A4 pngs around would be more to your liking?

    The ability to communicate with the richness of HTML expression should be embraced and standardised not spurned.

    aw, well. smash the HTML presses

    --
    There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
    1. Re:HTML Email by dvdeug · · Score: 3, Insightful

      HTML email is not just for spammers.

      No; it's also for people who want me to want a half hour to get my mail over my modem, so I can get the exact same message but with lots of HTML tags. (And invariablly lots of HTML tags - it never bears any resemblence to clean hand-written HTML.)

      The ability to send HTML forms to employees is a boon among other benefits.

      And what happens when you need to make a change to that form? Why not just stick it your own private webspace?

      Maybe you've never shared the joy of sending an HTML birthday card to your child or parent.

      Ah, yes; the wonderous feeling of "you crossed my mind, but I couldn't be bothered to walk to the store for a _real_ birthday card".

      It's a little more valid, but it's still something that can be done via web.

      The ability to communicate with the richness of HTML expression

      To be or not to be; that is the question. Whether 'tis greater to suffer the slings and arrows of outrageous fortunes, or by dying, end them. . . .

      I fail to see how this could be made richer by adding HTML. In general, just straight plain text is an extraordinarily powerful medium for communication. Frequently, HTML seems to be used as a means to doodle on the email, rather then add any information or emotional empact.

  34. Re:Swapping Values Without Using a Temporary Varia by ameoba · · Score: 2

    too bad that only works on things that XOR makes sense for. What happens when you have lists of sockets? Or want to swap objects that aren't the same size?

    Tuple assignment is much more interesting, and, while showing "a,b=b,a" is trivial, showing how & where tuple assignment can be used is an important thing to pick up if you're comming from languages which don't allow such constructs.

    --
    my sig's at the bottom of the page.
  35. Slashdot topics by fm6 · · Score: 5, Insightful
    Slashdot icons are just designators for Slashdot topics, and these desperately need an overhaul. There are topics for companies that no longer exist (Digital, Compaq, LinuxCare; Be should probably be renamed "BeOS"); topics that are extremely low volume and should really be folded into other topics (Comdex, E+, Englightenment), topics that are just plain redundant (Bugs, Linux Business), topics that we need only because they're part of a more general topic we don't have (we have America Online, but no ISP topic; topics for various Desktops, but no general Desktop topic; topics for specific Linux distros, but no Distro topic). And why on earth do we have ten specialized Apple topics?

    Rather than a new topic for Python, I'd rather see a Scripting topic. So, yeah, that means no cute Python icon, but it does put all the scripting issues in one place for people to select or ignore.

    1. Re:Slashdot topics by elemental23 · · Score: 2

      Rather than a new topic for Python, I'd rather see a Scripting topic. So, yeah, that means no cute Python icon, but it does put all the scripting issues in one place for people to select or ignore.

      You mean like the current Developers section? True, it's a lot more than language related stories, but that's where you'll typically find them (except book reviews, which are usually in the Book Reviews section)

      You're welcome :)

      --
      I like my women like my coffee... pale and bitter.
  36. Re:An indictment of the Python programming languag by Da+VinMan · · Score: 4, Insightful

    Aside from the point about lack of declaration of variables, you're points against Python all reduce down to syntax issues.

    It's a good thing you posted AC. I wouldn't want to take credit for that dreck either.

    Oh, and if Python were only two years old, then I wouldn't have been able to do the Python project I did for a client when I did.

    Have you even used Python? I didn't think so. I guess that if you want to be cynical and condescending about a language just because you're a self-appointed language guru, then please go ahead. But I think we would all prefer that you keep your opinion under wraps until it is informed and rational.

    --
    Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
  37. Re:Python icon by rafa · · Score: 2
    --
    [Science] is one of the very few things that raises human life a little above farce and gives it the grace of tragedy.
  38. Re:An indictment of the Python programming languag by Ian+Bicking · · Score: 2
    Oh! A language debate! I love those, though a more thoughtful and informed critique would have made for a better starting point... and this is just a troll (moreso since it's an AC) but I'm feeling bored.

    Python provides no apparatus--other than indentation--to delimit the scope of a control flow construct (loop, conditional branch, etc.).
    No one who actually spends time writing Python code has any real problem with the indentation. Some like it more than others, but anyone can learn to deal with it. If you don't indent your code properly anyway, then you are the poor programmer.

    The issue of tabs and spaces being mixed is well known and debated in the Python community, and mixing is considered very poor form. There are code checkers to avoid this, and Python can be run to reject mixing as a syntax error (personally, I hope this becomes the default in a later release).

    I was shocked ... there was no means to determine to what class an object belongs based upon its handle.
    I'm not entirely clear what you mean by this, "handle" is not clear term. Perhaps you mean, based on the variable name, you cannot tell the class? (Neither by name, nor by looking back in the code for a declaration on that name)

    This is true. Perhaps you do not understand the style of programming that Python encourages -- it's roots lie in Lisp and Smalltalk, not C or Fortran. I.e., fully dynamic typing, where an object's type is incidental, but it's properties are essential. If you don't understand that kind of programming, lack of typing will seem like a deficiency.

    Almost incredibly, Python does not support declarations of variables: variables merely spring into being when they are first referenced.
    Not true. Variables spring into being when you initialize them. Python is not like PHP or Perl in this regard -- there is no default value for an uninitialized variable.

    Lack of declarations is not a large source of bugs in actual use, and those bugs that do exist are shallow and easy to fix. Deep bugs are dangerous, but this does not often lead to deep bugs (though language that allow uninitialized variables can get themselves into trouble).

    The author of Python has the nerve to trumpet the amazing flexibility of its data structures ... I hate to burst his bubble, but he doesn't offer anything that LISP didn't offer forty years ago.
    It's built-in data structures are useful, and C (and even Java) are simply lame not to include them directly in the language. Lisp is another matter (though, again, the literal data types available are slim). Python tends to have fairly Lisp-like semantics, and that's okay. Designers of Python have never claimed to be revolutionary -- rather, they have tried to take the best features of languages that have come before, and create a language that puts them together in a pleasing way (unlike, say, Perl that takes every feature, throws them into a big heap, and calls it freedom).

    ( ) delimits tuples as well as expressions leads to the need to write ( x , ) ... With a bit more thought, something more professional could have been conceived.
    Such as? [ ] and { } are taken (and by data structures that are used more often than tuples). It works, and you get over the (x,) thing really quickly.

    Obviously from this critique, you have never seriously used the language. You only are able to critique its outermost veneer of syntax, and you don't have the knowledge to make any comment on the power of its semantics. The wise language designer knows semantics are more important than syntax (though syntax can get in the way, Lisp being the primary example).

  39. Re:Slashdot topics - scripting - not by Splork · · Score: 2

    Don't make a scripting topic and expect all talk of python and perl to be done there. they are both full programming languages. (as are others such as tcl)

    scripting is something can can easily do with them but should not be portrayed as a limitation.

  40. Re:Why such confusion over something so simple? by Jerf · · Score: 2

    I'm not certain if this is some sort of obscure joke, but you misunderstand the future statement. It turns on language features that are being phased in on a particular release. It does not and cannot activate those features in a language version that does not support it. 1.5.2 doesn't have the __future__ directives at all.

    Really, do you think these experts would have missed something that obvious?

  41. Has nothing to do with language speed by metalhed77 · · Score: 2

    I'd wager that since that averages out to 12 seconds per query that your metric is useless, besides DB queries reflect the database more than anything else, all the language does is send a string off to a C API which then queries the DB and gets the info. Same thing with the GUI. A better metric for the language would be say processing large amounts of data.

    --
    Photos.
  42. Re:Swapping Values Without Using a Temporary Varia by ChadN · · Score: 2

    You forgot the part where A and B are declared as 'float', and so this clever trick is really stupid and/or invalid, a lot of the time.

    --
    "It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
  43. Re:An indictment of the Python programming languag by Da+VinMan · · Score: 2

    Ah yes, another attack from yet another person too cowardly to actually own up to their writing. I don't normally make mistakes like that, but I am big enough to own up to them and correct myself when needed. I can't say the same thing about most ACs.

    For the record (without even using a dictionary):
    their = possessive
    they're = they are
    there = not here

    It's a typo that's all. I made a mistake.

    --
    Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
  44. Re:Swapping Values Without Using a Temporary Varia by dvdeug · · Score: 2


    b = a + b;
    a = b - a;
    b = b - a;


    In the case where you're using unsigned integers with wrap around semantics, yes. In the case that a,b are floats, integers on some systems (this won't work on signed magnitude systems, or in programming languages (like Ada) that have overflow checking), it doesn't work. It's nowhere as clear as "a,b = b,a", and doesn't work on general variables.

  45. It isn't about them eating the pythons... by Anonymous+Brave+Guy · · Score: 2

    Trust me, it's not nearly as funny if a snake really did want to eat you when you were younger.

    (Yes, one actually did, during a visit from a zookeeper to my school to show us what reptiles were really like. I was sitting at the end of a line of small children, and it started coiling around me... :-o I can handle spiders, or enclosed spaces, or high altitudes, but to this day, snakes scare the living **** out of me -- unless I'm programming in one, of course.)

    --
    If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
  46. Obligatory Enterprise joke by Anonymous+Brave+Guy · · Score: 2

    T'Pol: It's a Klingon delicacy... But only when it's alive.

    Hoshi: [Winces]

    --
    If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
  47. Oops :-( by Anonymous+Brave+Guy · · Score: 2
    more concise: a^=b^=a^=b;

    And even more wrong, in just about every language I know that supports an xor-assignment operator, because it modifies the same variable multiple times in one statement. :-(

    --
    If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
  48. Scripting is cool by fm6 · · Score: 2

    You make it sound as if "scripting language" is some kind of negative term. Hey, scripting languages have their strengths and weaknesses. You couldn't run the WWW without them, but I'd never use them to write CPU-intensive programs. And it's interesting to compare them to each other.

  49. Worse than I thought by fm6 · · Score: 2
    Oh lord, there's a "developers" topic? Which is not on the topics page? And is different from "programming"?

    Anyway, you seem to be saying that next time we get a story about Ruby or TCL, we should lump them together with all the "other" programming languages, despite their kinship to other scripting languages, such as Perl, Python, and PHP.

  50. I like python... by Anonymous+Brave+Guy · · Score: 2

    ...But I couldn't eat a whole one.

    SCNR. :-)

    --
    If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
  51. Topics? Sections? by fm6 · · Score: 2
    That's because we have a specialized apple section [slashdot.org] of slashdot. What, should every story on that page have the same generic apple icon?
    I guess not. But then somebody needs to explain the different between topics and sections.
  52. Re:HTML Email whining by DrSkwid · · Score: 2

    No; it's also for people who want me to want a half hour to get my mail over my modem, so I can get the exact same message but with lots of HTML tags. (And invariablly lots of HTML tags - it never bears any resemblence to clean hand-written HTML.)

    so you'd prefer me to send you a png attachement,
    or maybe an html document in a gzip?
    It seems like you are troubled by the poor use of HTML email not HTML email par se.

    And what happens when you need to make a change to that form? Why not just stick it your own private webspace?

    It's a little thing called 'convenience'. It aids workflow. I know it's only a little step but imagine getting a letter saying "there's a picture on the noticeboard, go look at it". HTML improves the flow of communication. People are not always great at mentally task switching and when they are "reading their email" firing up a browser breaks that task.

    Ah, yes; the wonderous feeling of "you crossed my mind, but I couldn't be bothered to walk to the store for a _real_ birthday card".

    I'll take that as a "no". Last time I looked I couldn't embed sound and video in a store bought card.

    Again, it's the immediacy that's makes the difference. Imagine opening your card and getting a note "your card is on the table" and looking to the table there is your card on public display.

    Email is a provate thing, the web is a public thing. Even if it's on the LAN the psychology of it makes a difference.

    I fail to see how this could be made richer by adding HTML.

    For in that sleep of death, what dreams may come

    HTML seems to be used as a means to doodle on the email, rather then add any information or emotional empact.

    So what? Should we be disallowed enjoyment because *you* can't see any benefit?

    Why do webs sites use colour, graphics, mark up, tables etc. etc. ?

    because people like them

    Now I do concur that having HTML mail on by default is a crazy idea. 99% of the HTML mail I receive is either better as plain text or better to not get at all.

    but to suggest I should be "the first against the wall" because I want to send an HTML christmas card to my friends is short sighted, rude, offensive and promotes banality.

    --
    There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
  53. Re:HTML Email whining by dvdeug · · Score: 2

    so you'd prefer me to send you a png attachement,

    Yes, if what you want to send is a bitmap graphic.

    or maybe an html document in a gzip?

    Yes, if what you want to send me is an html document.

    It seems like you are troubled by the poor use of HTML email not HTML email par se.

    Yes, but as you say

    99% of the HTML mail I receive is either better as plain text or better to not get at all.

    If it weren't for that 99%, there wouldn't be enough reason to support HTML email in most email clients, especially as it has had so many security holes and privacy leaks.

    there is your card on public display.

    Why would it be? All the webcard services give you cookies in the link to make sure it's not on public display.

    Should we be disallowed enjoyment because *you* can't see any benefit?

    Should we all fall silent when you enter the room, because we may offend you? It brings me absolutely no benefit, and I feel free to bitch about it. Feel free to ignore it, but I don't see why I should shut up, because you like it.