[Pytables-users] FileNode: new interface proposal.

[Ivan V. i B. <iv...@ca...>]

      Hi all!  On the process of adding write support (overwriting, not
  appending, 'r+') support to tables.nodes.FileNode, I have come across
  a difficulty with the splitting between newNode() and openNode().  In
  the beginning, it seemed a good idea, since the kind of objects passed
  as arguments were quite different (h5file and creation arguments in
  the first function, only node and mode in the second one).  However,
  the possibility of creating a new file node in either append or write
  mode would make necessary the addition of a 'mode' argument.  It would
  be fairly easy to add a second 'mode =3D 'x'' argument to newNode(),
  which would not break interface compatibility.  Semantic compatibility
  would imply 'x' being 'a+'.

      However, I have pondered adding suport for 'w', 'a' and 'w+' modes
  in addition to the supported 'r' and 'a+', and the mentioned 'r+'.
  Right now, RWFileNode.__init__() does all node creation tasks (with an
  admittedly ugly argument list treatment).  The addition of those new
  modes would imply more cases of node creation, as well as some cases
  of node replacement or emptying.  This would complicate __init__()
  methods for the new classes.

      To avoid the problem of __init__() diversity of arguments and
  implementation complexity, I have considered moving all node creation
  and emptying to newNode() and openNode().  In this way, new classes
  would only have to handle existent nodes.  Using some mix-in classes
  for readable, writable and appendable behaviours of the file methods,
  FileNode classes would be fairly simple to implement.  New classes
  should not cause compatibility problems, since they keep the same file
  interface, and the current __init__() methods for the current FileNode
  classes should not have been used directly (in theory).

      However, moving node creation to newNode() and openNode() would
  most probably cause duplicate behaviour.  Both functions should end
  up calling a same function.  In this way I have got to the idea of
  dumping newNode() and using a new definition of openNode (in a similar
  way as file() or open()).  The new signature would be:

	openNode(h5file, path, mode =3D 'r', title =3D '',
	         filters =3D None, expectedsize =3D None)

      By taking out arguments only related to FileNode, the signature
  could be reduced to:

	openNode(h5file, path, title =3D '', options =3D FileNodeOptions())

  Where 'path' would be the full, absolute path of the (maybe new) node.
  This signature could be shared with future tables.nodes subpackages
  (of course, changing the default value for 'options').  XXXOptions
  would be a simple container object for node-dependent options ('mode',
  'filters' and 'expectedsize' for a FileNode object).  If name clashing
  was preferred to be avoided, the function could be named
  openFileNode() for the FileNode object.  In any case, a new function
  tables.nodes.openNode() could be used to open eny kind of *existing*
  node defined in tables.nodes, by mapping its '_type' attribute to its
  opening function.

      There is also the question of emptying or replacing the node of
  the file when truncating ('w', 'a' and 'w+').  Is replacing the node
  with a new one a valid solution?  Emptying the file without replacing
  it is not possible right now, since EArray objects can not be
  truncated (ummm, this would be a _very_ useful addition!)

      Sorry for the long message.  It also helped me to sort some things
  out.  So, what's your opinion on the new openNode() function and the
  truncation issue?

  Thank you,
      Ivan


=66rom ivan.opinion import disclaimer
--=20
Ivan Vilata i Balaguer   >qo<   http://www.carabos.com/
          C=E1rabos Coop.  V  V   Enjoy Data
                          ""