Looking for Python programmers--where to search?

[gbp]

I learned to use Python's lists and dictionaries fairly fast.

I think it helps to have gone through a university system where they
make you learn 'strange' langauges.

I'll never forget the Lisp class I took.  We all laughed at lisp like it
was a bad joke when we saw it.  We were all pissed off when we got the
programming assignment.  It had to be written all in a 'pure' subset of
lisp with NO loops.  Loops = F.  
We didn't laugh anymore when we saw the a 5 line lisp program could do
what a 5 page c program could do.  I don't remember the assignment now,
but I'll never forgot how short that program was!

I think you got to let each langauge be itself.

Eric Lee Green wrote:
> 
> 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