Looking for Python programmers--where to search?

[Alex Martelli]

"Eric Lee Green" <eric at estinc.com> wrote in message
news:39A6EAA6.1E6FC421 at estinc.com...
    [snip]
> 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.

A real C++ programmer, as opposed to a C one, would not have had a problem
in your example, since in C++, as opposed to C, you *can* work with
sequences
and mappings without writing much extra code.  The standard C++ library
promotes the 'generic programming' paradigm, which has very close parallels
with Python's ways.  Sure, lots of so-called C++ programmers aren't -- they
have never bothered exploiting the standard language features; those will
take
a bit more time to get up to speed in Python.


> > 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 --

Funny, the trend as I've noticed it is exactly the other way around -- our
company has been opening development labs in a lot of sites around the
world, to maximize our chances of getting the best people on board even
if they want to live far from our main location, and my experience is that
the technology's progress is making it easier, not harder, to handle.  That
little word 'component' is the key.  A few years ago our applications were
rather monolithic -- interactions between theoretically separate subsystems
rather "thick", etc.  Now, there are a lot of components, their interactions
constrained to architected interfaces.  We're not all the way there yet,
but,
as a trend, it's getting much more feasible, not less, to move development
to a bunch of separate locations.


Alex