Looking for Python programmers--where to search?

[Eric Lee Green]

Mats Wichmann wrote:
> On Mon, 14 Aug 2000 23:48:28 -0700, Paul Schreiber <paul at magic.ca>
> wrote:
> >You can pick up python in a hour; all you need is a good reference book
> >to look stuff up in. _Python Essential Reference_ is that book. :)
> >(Typically people get confused about lists and tuples; or strings being
> >immutable -- minor junk.)
> 
> I really think you're slightly overstating the simplicity.  You still
> have to get used to things like namespaces and how modules impact
> them, import/from/reload,  etc. - i.e. there are some subtleties; and
> you have to gain some kind of familiarity with the tools that are
> available - standard modules and how to make effective use of them;
> connectors to other languages, etc.  

I'm training a C++ programmer to program in Python as we speak. The thing that
seems to give him willies is the sheer dynamic nature of the language. C++, as
you know, is statically typed (nevermind the STL ball-of-cruft). We assigned
him to write a database access class that incorporated self-reflection, i.e.,
it created its attributes at run-time based upon the contents of a list of
attribute/type pairings in the subclass that was inheriting the database
access class, and you could almost see the fuses blowing in his mind.

So far he has been plugging away for two weeks, and still takes 2 days to do
what I could do in the course of an hour, and still has trouble dealing with
the fact that he can, e.g.,  operate upon lists without having to write oodles
of list-manipulation code and etc. (e.g. there was one database operation
where the most efficient way of handling things was to query all the data out
into one list then iterate over the list with a 'for' loop, and he went
through a bunch of hooplah with cursors to implement the same thing -- because
in "C", you can't work on lists without writing a bunch of code). My only
conclusion can be that while C++ programmers can learn the basics of the
Python language in an hour, it takes them a lot longer than an hour to be able
to write real programs in a timely manner using the language.

> (Hint to employers:  there are lots of competent folks who are willing
> to help on projects - part-time or full-time, consulting or permanent,
> who don't understand why that should mean being tied to the SF Bay
> Area... think: telecommuting.  I've done it productively for years.
> If you bend a little on location your lives will get a whole lot
> easier trying to fill those difficult spots!  

A few years ago I would have agreed with you. The problem is that projects are
becoming more and more complex, and as they become more complex, interactions
become more complex. A typical project ten years ago had one component type --
a client program, that maybe communicated with a centralized database server
via a socket if it were particularly sophisticated (but usually it used an
ISAM library and relied on a Novell network's built-in file locking mechanisms
to provide consistency control). The various screens could be broken into
independent programs, none of which knew about any other program or
communicated with any of them. Today's projects have multiple "thin" clients
(CLI, GUI, web), a very sophisticated server that incorporates the actual
business logic, they perhaps access an LDAP server and an SQL server, etc.
etc. etc.... if I am writing the server, I need to communicate swiftly with
the person writing the GUI interface, because when something comes up that is
not incorporated in the design documents, I need to know how we can handle it
so that I can create output that he can parse (and vice-versa). If he is in
the cubicle across from mine, I can poke my head over the wall and ask him. If
we are hundreds of miles away and in different time zones, that becomes a
problem. The last time I successfully telecommuted was 5 years ago, working on
a database application that consisted of numerous standalone modules hooked
together via a menu program. I would not even dream of attempting that with
the current project, where the interactions between the various components are
critical despite every attempt on my part to keep things as isolated and
independently-testable as possible.  

-- 
Eric Lee Green                         eric at estinc.com
Software Engineer                      "The BRU Guys"
Enhanced Software Technologies, Inc.   http://www.estinc.com/
(602) 470-1115 voice                   (602) 470-1116 fax