[SAGA-RG] SAGA Python language binding naming.

Fisher, SM (Steve) S.M.Fisher at rl.ac.uk
Fri Aug 15 10:39:36 CDT 2008


 

> -----Original Message-----
> From: PFA van Zoolingen [mailto:pzn400 at 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



More information about the saga-rg mailing list