Learning Curves

gnat on 2005-11-04T16:23:29

"Learning Curves" sounds like the title of the O'Reilly beginner's guide to soft porn, but that's not what this is about. I'm writing my first Python program. It is quite the adventure, and I'm learning a lot about learning (always good).

Things I have learned include, in no particular order:

  • Learning Python and Programming Python aren't what I expected them to be. They're not the direct translation of their Perl equivalents. This goes double for the Python Cookbook, which seems to assume you already know everything in the standard library and so only covers stuff outside the standard library. I lost a non-trivial amount of time trying to find the StringIO class. Apparently Python in the Nutshell is the book I should be looking for.
  • Working sample code is real important in documentation. It's not ubiquitous in the Python documentation, which gave me grief. And when it is there, sometimes it's misleading. For example:
    f = StringIO()
    won't work. You need to use StringIO.StringIO() or you get a message about not being able to call a class as function. Twitch, twitch. Fortunately, the nice people on #python were able to set me straight.
  • Python has different behaviour for compile- and run-time binding of names to code. There is no compile-time binding of function names to code. The Python equivalent of sub foo {} is identical to *foo = sub {}. There's no compile-time binding of function names to code, so you can't call a subroutine until the subroutine definition has been "executed". This tripped me up ("what do you mean the function isn't defined! It's right bloody there!"). Again, #python to the rescue.
  • CPAN is fantastic. Not that Python doesn't have amazing libraries, it does. But the one-step CPAN shell is just a treat. As much as I've been cursing it as I drag in 3/4 of CPAN just to build one of Jesse's modules, it's a damn sight better than having to download and install each module by hand from a separate location .... I'd hate to do something big. I wonder how widespread is the use of Activestate's Python Package Manager.
  • Indentation versus curlies is, as I'd long suspected, a bogus issue. You lose a little context when you close many blocks at once (without lines of close curlies, it can be hard to tell whether that's three or four blocks being closed) but that's not as big a problem in practice as I'd thought.

It's been fun to do something new, though I'd have found it quicker to just port the library I wanted (the Universal Feed Parser) to Perl than to learn the Python I need around that library. That's okay, I'm doing this to learn another language and not to get the job done in the shortest possible time.

--Nat


omg

geoff on 2005-11-04T19:24:32

he lives! :)

Re:omg

gnat on 2005-11-05T00:10:00

Rumours of my life are greatly exaggerated :-)

Talking about pythons indeed.

dha on 2005-11-04T21:56:56

So does this mean ORA isn't doing an into to soft porn?

Re:Talking about pythons indeed.

gnat on 2005-11-05T00:12:10

Nope, only hard core. "Nutsacks in a Nutshell", I believe is the working title.

What book would Learning Curves be?

n1vux on 2005-11-05T00:23:51

I thought Learning Curves would be ORA's intro to graphic programming with Splines, possibly part of the Learning ePiX series.

Re the question
  So does this mean ORA isn't doing an into to soft pr0n?
the covers are getting racier since they branched out. http://www.oreilly.com/catalog/jds/index.html http://www.oreilly.com/catalog/linuxckbk/index.html http://www.oreilly.com/catalog/1933097043/index.html

I'm just surprised the SELinux books don't have a Bondage & Discipline cover theme.

<EOJ/>

Re:What book would Learning Curves be?

gnat on 2005-11-05T00:31:54

Hoop skirts are racy? Wow, my first Amish Perl coder! (other than Ziggy, of course)

--Nat

Re:What book would Learning Curves be?

ziggy on 2005-11-07T17:18:38

Sorry, dude. I've been clean shaven for years now. ;-)

Re:What book would Learning Curves be?

gnat on 2005-11-07T18:50:43

I need to get my ass to PyCon so I can see you again :-)

Re:What book would Learning Curves be?

ziggy on 2005-11-07T20:04:02

Don't bother. It's going to be in Dallas next year. I stopped by one year or two because it was local, and I wasn't doing anything important that day. ;-)

Beards and racy

n1vux on 2005-11-07T18:08:51

Hoop skirts are racy? Wow, my first Amish Perl coder!

No, merely ironic.

But one of the three links wasn't Prairie folk ... one had decolletage!

Some locals might think your comment prescient, as the latest adjustment to my beard does evoke some Amish comments (especially with a summer straw hat) from those who don't know what Amish beards really look like (ear-to-ear jaw-fringe). It's really more old Yankee (chin cover); consider the linked picture (which matches what you probably don't remember seeing at LinuxWorld Boston ORA booth just before close of show) and subtract the mustache. New look not online yet, that I know of.

Python *shudder*

n1vux on 2005-11-05T00:08:17

Indentation versus curlies is, as I'd long suspected, a bogus issue.

There are a couple of real issues with indentation, but mostly in Python's favor.

Indentation without line noise is a major convenience for those typing with their voice or quite possibly other adaptive technologies.

Indentation without line-noise lacks the redundancy that braces and a "tidy" reformatter can provide, but gets a similar effect directly. Editors that have been trained to match brackets may have a harder time skipping back to the top of the loop or block, although the eye can do it easier if it is on page. At least the lack of redundancy avoids the infuriating "missing close-bracket and die" message. (Having had PL/C systems try to repair syntactically flawed programs to ill result, I don't really wish Perl would insert the missing } for free, as Internet Exploder does with malformed HTML. But it still is annoying.)

Most tellingly, the Ubuntu team feels the simpler visually obvious syntactic indenting is a major feature of making the language end-user friendly, which is why they've selected Python and not GAMBAS or Perl or Ruby or BASH as the single scripting, install, and extension language for Ubuntu. See long essay which this comment reminded me to make.

Re:Python *shudder*

gnat on 2005-11-05T00:23:50

the eye can do it easier if it is on page.

Not these eyes, alas. It was messing me up bigtime when I closed a bunch of blocks at once (if in a loop in a loop). No doubt I'll get used to it, but don't make the mistake of confusing familiar for intuitive. Nothing about these infernal machines is actually intuitive, and eyes can no doubt learn to see the invisible indents the same way that fingers can learn to hit the match-curly key sequence.

Most tellingly, the Ubuntu team feels the simpler visually obvious syntactic indenting is a major feature of making the language end-user friendly, which is why they've selected Python and not GAMBAS or Perl or Ruby or BASH as the single scripting, install, and extension language for Ubuntu.

That's nice for the Ubuntu folks, but I remain skeptical that Python is any better than Perl or Ruby in the newbie department. I've had new programmers revel in Perl the same way I've seen new programmers revel in Python. I believe firmly that diversity and not uniformity is good for software development: Perl, Ruby, Java, etc. won't just wither away to be historical footnotes to the almighty conquest of Python. Regardless of who is behind Ubuntu and how well they've done, people are different and prefer different things.

I say this because in the late 90s we were agitating against the spread of Java. And the Java bubble burst in 2001. Perl's bubble burst with PHP 3 (or was it 4?). Python's bubble will burst, too.

--Nat

Re:Python *shudder*

Ian Bicking on 2005-11-08T22:14:04

I've had new programmers revel in Perl the same way I've seen new programmers revel in Python.
As a new programmer I revelled in QBasic, but it doesn't meant that was a good language. Programming is fun, people can enjoy it in nearly any language. Maybe not COBOL... submitting batch jobs isn't satisfying. But all languages that aren't soul-eating are fun.

But new users aren't all equally successful in what they are trying to do. Moreso, they don't even know how to judge their success; they don't have a good feeling for how hard a problem really is, or for the quality of the thing they produce. Which is just to say that self-evaluation is not a good way to judge.

CPAN?

melo on 2005-11-05T13:02:44

Are going to release your port of universal parser to cpan? I would like to use it, if possible.

Right now, I'm using a bunch of modules from CPAN but they don't match the breadth of stuff that universal parser catches.

Thanks,

Re:CPAN?

gnat on 2005-11-07T18:44:00

You misunderstand me. Sadly there is no port of Universal Parser--I did my coding in Python because of this. Sorry!

Couple of tips

throwaway on 2005-11-05T15:17:11

It wouldn't have helped with the fundamental issue in the example you mentioned (you probably got a "'module' object is not callable" error, there) but as far as working code is concerned, many modules contain useful examples in their test code. "help(StringIO)" tells you the file containing the StringIO module, and then you can read the "test()" function in there. In the same directory there is also a "test" subdirectory, which contains "test_StringIO.py". Those test files can also be worth looking at sometimes. (I agree, this is a poor substitute for working code in documentation.)

When you close a block in emacs's python-mode, it briefly reports the text at the top of the block being closed. You may find this helpful for keeping track.

Python does have a CPAN, actually

PJE on 2005-11-08T19:20:14

Python CPAN = CheeseShop + EasyInstall:

http://cheeseshop.python.org/ - a repository of links and downloads for Python projects

http://peak.telecommunity.com/DevCenter/EasyInstall - a simple package manager for automatic find/download/build/dependency resolution. For example, running "easy_install SQLObject" will search the Cheese Shop for the "SQLObject" object-relational mapping package, then download and build it for you, along with any dependencies it needs.

Both the Cheese Shop and EasyInstall are fairly new, and EasyInstall's certainly got a good way to go before it offers all of the comforts of CPAN or Gems. But there's already no need to manually download and build most Python packages, and EasyInstall can scan web pages for links to Python-built Windows installers, source tarballs, and its own "egg" (zip-based) binary format, as well as deal with Subversion URLs and Sourceforge mirrors. (Many packages can in fact be installed and run in zipped form without ever extracting the files to disk, using less space and speeding up imports.)

PLEAC

Ian Bicking on 2005-11-08T22:20:38

Anyone looking for the analog of Perl in some language, or at least the equivalent of Perl Cookbook recipes, should check out PLEAC, which is a (not always complete) translation of the Perl Cookbook into different languages (including Python)