[Nexus] 2D character arrays in python binding?

[Akeroyd, FA (Freddie)]

Paul,

The HDF interface should be OK with '\0'; however I expect the XML
interface might need a little bit of work to handle this

Regards,

Freddie

> -----Original Message-----
> From: Paul Kienzle [mailto:paul.kienzle at nist.gov]
> Sent: 30 January 2009 19:17
> To: Akeroyd, FA (Freddie)
> Cc: Carlos Pascual Izarra; nexus at nexusformat.org
> Subject: Re: [Nexus] 2D character arrays in python binding?
> 
> 
> On Jan 29, 2009, at 10:44 AM, Akeroyd, FA (Freddie) wrote:
> 
> > Carlos,
> >
> > The 4.2 release candidate of the NeXus API supports two dimensional
> > character arrays for HDF4 and HDF5 - XML might suffer problems if
> > there
> > are embedded newlines etc. The API is expecting a square array of
> > characters i.e. it will not pad short strings with spaces. I got the
> > python API to work by using:
> >
> > {{{
> > filenames=['bar1      ','longerbar2','bar3      ']
> > ...
> > f.makedata('filenames','char',[3,10])
> > f.opendata('filenames')
> > f.putdata(''.join(filenames))
> > ...
> > }}}
> >
> > However it should be possible for us to get the python API to spot a
> > string list and do the necessary space padding and joining for you
> > automatically.
> 
> The natural numpy translation of the above example is as a length 3
> array of type '|S10', not a 3x10 array of '|S1'.  If you do
> ascontiguousarray(['a','perfect','day'],'|S10') for example, then it
> will record the correct information.  This should scale to
> multidimensional string arrays if they are needed.
> 
> The pad character in this case will be '\0' rather than ' '.  Is this
> going to be a problem for the HDF backend?
> 
> - Paul
-- 
Scanned by iCritical.