I am an experienced software developer, specialized in Python, with extensive knowledge of modern database systems. I have developed and deployed several client-server applications, initiated numerous open source projects, and written a number of Python-related articles.

Over time, I've worked on several projects (both professional and personal) that deal with crawling the web and extracting data from web pages and other files, so this has become somewhat of a specialty of mine.

More information can be found in my resume (which also contains my contact info). I also wrote about many of my interests and programming projects in various weblogs (1, 2, 3, 4).

I'm in Florida, and interested in either local jobs or telecommuting (which I have been doing in my last two jobs), especially Python-related. I am willing to consider relocating if necessary.

My first impressions are... mixed.

I like the fact that I could upgrade from Tiger without much hassle. Everything still seems to work, including QuickSilver, Adium, Chicken, and Postgres. Most of my settings (like e.g. for Terminal) are preserved as well.

There were, however, a few changes that immediately stood out, and that I didn't like at all.

The new look of the dock is one of them. Fortunately, I knew this beforehand, and it's easily fixed.

I don't like the translucent menu bar either, but again, nothing a bit of poking around can't fix. :-)

X11 still doesn't work (I normally would not use this at all, except that there's a C64 emulator that depends on it). There are some articles that deal with this problem, I will have to look into that.

Something I haven't found a fix for (so far), and which bugs the hell out of me, is the new behavior of the little "view" icons in Finder windows. There are four of them now, and you can change a window's setting to use icon view, list view, columns, or Cover Flow. Great, except changing a view for one window means changing it *for all windows*.

In other words, let's say my default view is icons. I go to folder A, which has a lot of documents, so I want to change it to list view. I click on the icon, then open folder B. Surprise! It's in list view now too, and so are all other windows on your system.

Now, it's not completely impossible to change this and set views on a per-window basis, but it's so clumsy that you might as well forget it. In order to use icon view as the default, but use list view for folder A, I have to do the following:

1. Open folder A.
2. Press ⌘J to open the "Show View Options" dialog.
3. In the window for folder A, click the "list view" icon.
4. In the "Show View Options" dialog, now check the "Always open in list view" option. (Notice that this will initially show whichever view is the default, so it starts out as "Always open in icon view".)
5. Open folder B (this can be any folder that does not have custom settings associated with it). You'll notice it's in list view too now.
6. In the window for folder B, click the "icon view" icon.

This is pretty lame, IMHO... unless I'm misunderstanding things, it was *much* easier to do this in Tiger and its precursors. So far, from what I've read online, this indeed seems to be the new behavior: "Leopard also has new logic for views. Unless you've ticked the option to open in icon view, all windows will show whatever view you have just selected in whatever window. Like it or not, that's the way it is." [link]

(Strangely enough, other options like colored backgrounds, seem to be automatically on a per-window basis.)

More impressions will follow as I continue to work with the system. I haven't checked out the shiny new features yet (Time Machine, Spaces, etc). More about that later...

Scheme/Arc aficionados already knew this, of course, but to me it was news since I've never really used cut much. Here's a short explanation.

Scheme's cut produces an anonymous function that takes as many arguments as there are <> symbols at the "top level". E.g.

> (cut + 1 <>)
#<procedure (? g3)>
; has one argument

> (cut + 1 <> <>)
#<procedure (? g4 g5)>
; has two arguments

; etc...

However, any <> that is found in a nested expression, is not considered as a parameter. Therefore:

;this works...
> (map (cut + 1 <>) '(1 2 3))
(2 3 4)

; but this does not:
> (map (cut + 1 (* 2 <>)) '(1 2 3))
Error: bad argument count - received 1 but expected 0: #<procedure (?)>

By contrast, Arc's [ ] syntax produces an anonymous function that expects one and only one argument, which is represented by a single underscore. As a result, it's simultaneously more and less limited than cut:

arc> (map [+ 1 _] '(1 2 3))
(2 3 4)
arc> (map [+ 1 (* 2 _)] '(1 2 3))
(3 5 7)
; no problem

; but two parameters doesn't work:
arc> (map [cons _ _] '(1 2 3) '(4 5 6))
Error: "#<procedure>: expects 1 argument, given 2: 1 4"

Of course, for anonymous functions that are more complex than this, it's probably better to just use lambda... :-/ Or a named function.

Heck, it has even been added to Planet Python again, which wouldn't have been the case if I wrote about Scheme all the time.

But really, I want to learn more about Scheme as well, *and* be able to use it in a pragmatic way. I just need a bit of focus. Right now I'm wondering what to look at next. Maybe object systems?

Say you have a list, how is a beginning supposed to follow/comprehend the bigger picture when faced with code like this:

mylist = [1,3,2]
print len( mylist )
print sorted( mylist )
print mylist.sort()
print mylist.reverse()
print mylist[0]

Honestly, what is going on here? Why different syntaxes for slightly different ideas?

This gives many people the feeling that OO in Python was added later, or "bolted on", as Taw puts it.

I figure the reasons for the discrepancy are like this:

In 1991, when Python was first released, *pure* object-oriented languages were rare. Sure, there was Smalltalk, but it was fairly obscure. Other languages that called themselves object-oriented, like C++ and ObjectPascal, were actually hybrids; objects were indeed "bolted on" to an existing language.

In this light, it makes sense that Python 0.9.1 did the same. It had built-in types, and user-defined objects. Some of the types, like lists and dictionaries, had methods, possibly because were mutable and therefore contained "state". Other types, like numbers, strings and tuples, did not have methods (and were therefore not "perceived" as objects, even though behind the scenes they were). (In fact, back in the early 90s, the idea of calling a method on a number seemed like a really odd idea (if you were not a Smalltalker :-).)

As a result, in order to take the length of a string or a tuple, you needed a *function* (because you could not call a method on these types). While list and dict could easily have had such a method, for consistency's sake this was omitted; instead, the len() function was to be used on them too.

And so it still is. But the world has changed since then. OO has become much more mainstream, and the notion of using methods for everything is no longer odd, but expected by many. I can understand why someone coming from Ruby (or maybe Java) would wonder why in some cases functions are required, where a method would seem more natural. It makes Python seem inconsistent, when initially the use of len() actually improved consistency.

This is something that *could* have been fixed in Python 3.0, but won't, as far as I understand it. I'm not sure if this is a missed opportunity, or that it will keep Python closer to its original spirit (i.e., a multi-paradigm language).

(Note: I am aware of the __len__ method of course, but honestly, who is really going to use that instead of len()? __len__ is a hook to make len() work, not an alternative for it.)

So a while ago I got it into my head to give the Cube another try. Bought one last weekend, and tried to figure it out. So far these videos have been very helpful:

I'm saving it here because it's probably not going to last. :-)

I sometimes wonder what old folks homes will look like 60 years from now... I imagine it will have scores of 80-somethings with tattoos and piercings drooping from their floppy, wrinkled skin. And the young people taking care of them will be like, WTF were you thinking?

It seems eBay is a better bet in this case...

(If you don't know Cubivore (which is likely), check out this video. There's many more on YouTube, worth watching if you are into odd games. ^_^)

As far as I know, in the Python world, an abstract base class used to mean, a base class that cannot be instantiated. Kind of like:

class Foo:
    def __init__(self):
        raise NotImplementedError, "Foo cannot be instantiated"

It would, however, be perfectly possible for an abstract base class to have valid, working methods, to be used by classes inheriting from Foo.

Apparently this isn't the case any longer. If I read PEP 3119 correctly, in Py3K-speak, an abstract base class is a way to trick isinstance() and issubclass() into believing that a given class derives from another class, when this actually isn't the case. For example:

>>> list.__bases__
(<class 'object'>,)
>>> object.__bases__
()

list derives from object, which in turn derives from nothing else. But:

>>> issubclass(list, collections.Sequence)
True

In other words, list *pretends* to derive from Sequence, but it really doesn't, and so any methods defined in Sequence will not be inherited by list.

Filtered through my old-school-Python-riddled brain, this implies the following:

• abstract base classes mean something different now, and
• they break isinstance and issubclass, and
• methods defined in the ABC cannot be used by the "subclass".

Seriously, the more I read about Python 3.0, the harder it becomes for me not to be appalled. The language makes a heroic effort at fixing warts and problems and trimming fat, but at the same time it's becoming more and more complex.

I'd love to be proven wrong though. I like Python a lot, and I am (and have been) worried about what it's evolving into. But maybe Python 3.0 will actually be easy and intuitive to use, like the Python of old, and all the overly complex stuff will stay in the back rather than get in the way. I guess time will tell. (Or maybe I'm misunderstanding things... feel free to point that out. :-)

(This is mostly a matter of personal preference, of course -- for the last few years I've been gravitating toward languages with little syntax, that allow powerful new constructs to be written in the language itself. Think Scheme and Io. Python, however, has steadily been moving in the other direction.)