Python too complex ?!?!?!

[Donn Ingle]

> Interesting idea, although it's not something I'd want included and
> turned on by default.  Should certainly be possible, though, with a
> little __import__ magic.
Well, since we're shooting the sh*t :), I tried in my one and only released
app (Fonty Python) to wrap the imports in try clauses and then print
helpful strings to the console to guide the user. 
 I'm really not too clued-up on the __deep__ magic of Python, so I can't say
what tricks there are, but a simple "catch a fail and then start a
solution" process is a general approach.
 
>> If you are online and the app runs, it can check the "freshness" of your
>> modules (those called from the app and recursively) and offer to fetch
>> the latest stable versions.
> Something similar to Java's webstart?  Implement an __import__ hook
> that downloads and caches the latest (stable) versions of libraries as
> needed.
I have also never touched Java, so I can't say, but something like that. 
 The main problem with having modules coming from the web is time. How long
is the life of a URL? The Cheese Shop seems pretty well established and
could serve the role. Perhaps there are already ways of making sure that a
hard-coded link in an app can reach a variable URL online.
 
> You wouldn't really *need* a GUI, although it probably should be a
> configurable option ... 
I'd agree, but then I grew up with commands lines. I can say with total
confidence that the command-line scares a lot of people and if there are
any questions that need answering during the automated process (and there's
always *something* that crops up ) then a gui is the natural way to reach
the user.

> No reason why it couldn't be totally
> automated.  easy_install already provides for automated installation
> of python apps/libraries, so you could build off that.
Totally automated would be the goal. I'd say a throbber or progress
animation of some kind would be needed. 

 Just thought of a wrinkle - say a new module is available and is installed
and then proves to be broken. How can the app recover? There'd have to be a
system of flags in a db that mark the situation and on re-run can roll back
to the last working module. Then we get feedback to the author of the
module.... 

And let's not forget all the joy that can be spread by having to compile
modules (on various platforms) from C/C++ and then worry about *their*
dependant libraries!

Oh fun times :p

(I think I can see why this has never been approached.)

> Merely using decorators is, IMHO, much easier
> to understand (but still requires a slight brain-warp).  
I'm still stuck with those things. I can't really find an example that I
want to use. My brain keeps saying "yeah, but that's so smoke and mirrors
and I could do it this way ... which seems much plainer."

> I think some 
> people try to understand decorators too completely too quickly, and
> end up labeling them one of those complex/unintuitive/"way out"
> things.
I have put them in the bag along with Design Patterns and Threads as "things
that I don't have to worry about because liff is too short. And like the
Spanish Inquisition, they're welcome to surprise me when I least expect it,
but I'm not going to lose my mind waiting :D

/d