Should I write a book on Python Metaprogramming ?

[andrew cooke]

ok, but none of those problems need be insurmountable in a particular
application.

the example i was thinking of was scripting the manipulation of large data
sets - the data volume is too large to move to the local machine, so
remote objects provide an interface to control the data processing
remotely.  in this scenario:

- processing on the remote machine could be logged.  if the same process
were requested a second time (if the script were restarted after crashing
due to network problems, say) then the work need not be duplicated.

- the granularity is coarse.  each method call describes data processing
at a high level and so only a small number of calls are required.

that seems like the kind of scenario where a fairly simple approach might
work (and error handling consists of "running the script again" if it
crashes).

does that seem reasonable?  (if not, i'd like to know!)

andrew


Andrew Bennetts said:

> On Mon, May 05, 2003 at 06:54:23AM -0400, andrew cooke wrote:
>>
> [..snip..]
>> For example, I may need to write an extension to Python that allows
>> people
>> to write/debug a script on one machine that then transparently lets them
>> manipulate objects on a remote machine (once the program is debugged the
>> library in use would have a switch flipped so that it used corba, say,
>> to
>> provide the same interface remotely).  A book that helped me do that
>> would
>> be great (and it seems like a good example of meta programming).
>
> There's no such thing as truly transparent remote objects.  Remote objects
> are unreliable (the network can go down) and slow (even the simplest
> remote
> method may take seconds to return a result if the network is congested).
> This breaks assumptions in code that treats remote objects as if they
> behaved exactly the same as local objects -- if "obj.getPrice()" worked 3
> lines ago, of course it will work now!  And of course the object's method
> calls are speedy enough that they won't affect the responsiveness of the
> GUI
> that blocks while calling the object's methods...
>
> That's not to say remote debugging is impractical, just that it can't
> possibly be transparent.  Remote method calls are inherently different to
> local method calls, and any system that assumes otherwise will cause you
> grief at some point.
>
> -Andrew.
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
>


-- 
http://www.acooke.org/andrew