-----Original Message----- From: PFA van Zoolingen [mailto:pzn400@few.vu.nl] Sent: 15 August 2008 11:08 To: Fisher, SM (Steve) Cc: Andre Merzky; SAGA RG Subject: RE: [SAGA-RG] SAGA Python language binding naming.
On Fri, 15 Aug 2008, Fisher, SM (Steve) wrote:
I don't find that: bytes_read = f.read (buffer, len) is very pythonesqe. Surely it should be buffer = f.read() and len(buffer) will tell you what you have got.
But how can you then specify that you want to read 20 bytes, instead of the whole 20GB file?
buffer = f.read(20)
I feel that the proposed calling sequence looks too C like
But how is the distinction made between saga-implementation managed buffers and application managed buffers?
I don't think there is any need for a saga managed buffer. The call f.read(20) returns a string of maximum length 20. In other words "f" behaves just like a normal python file object. I think it is important to make python libraries work like python rather than C. Also bear in mind that there may be places in the API where it is useful to take advantage of the ability to return a tuple rather than a single object.
If buffer is a saga managed one and you did a f.read(20), where does the data go?
It goes into a newly allocated python string.
This seems an unnecessary complication - why not just change the PYTHONPATH to change implementation. I like the way the email package is structured into modules. You import what you need and you don't have strange things going on behind your back - potentially polluting your namespace.
Well, I use the environment variable for the name of the library. So multiple python-saga language bindings can exist in the same path. And for some reason jython does not use the PYTHONPATH variable. It uses a -Dpython.path flag which is given to the jvm. A separate variable is usable by everyone.
The Jython behavious is to be expected as JVMs don't like to access env variables. Whether you are using compiled python or Jython you have to tell it where to load your modules from. This can be modified in the code of course - but it is quite normal to set the path externally before running.
There is not much magic going on. It cuts the implementation name from saga.<imp_name>.package.class(). So you don;t have to rewrite your python program if you use a different implementation.
What do you mean with polluting the name space? All the saga classes might (well, probably are going to) be defined and loaded, but they all stay behind saga. I don't expect any other saga library to be loaded.
I get the feeling that implementation ideas are intruding into the API design. I would really like to see the description of the API for one small package and an example or two of its use - it makes things much clearer for me. It seems that I am a lone voice of dissent. Steve