AW: [Zope3-Users] Python Package Construction

[Roger Ineichen]

Hi Tim

> Betreff: [Zope3-Users] Python Package Construction
> 
> Hi All,
> 
> I would like feedback on the proper/best 'Pythonic' approach.
> 
> This is a rather subjective question. Where is the trade-off 
> between package name lengths and faithfulness to the specifications?
> 
> [Discussion follows]
> 
> I am implementing a set of specifications for healthcare IT 
> for Python programmers to be able to develop interoperable 
> healthcare applications.
> I am using ZCA (aka.Zope3) extensively.  
> 
> My desire is to implement the specs as faithfully as possible for two
> reasons:
> 1) teachability -  how easy/difficult is it to teach the 
> framework and specifications to new developers?
> 2) maintainability - which approach, if either, will make it 
> easier to maintain the framework if/when the specifications change?
> 
> My first pass was to develop a skeleton of the specs using 
> Interfaces from the ZCA approach and then the implementations 
> following the document structure of the specs.  
> 
> The specs are available via SVN at:
> http://www.openehr.org/svn/specification/TRUNK/publishing/arch
> itecture/ 
> 
> It is best to probably use real examples. Following the 
> document structure for packaging AND using the ZCA convention 
> of having a sub-directory for interfaces caused massive 
> circular import issues due to some classes being used in the 
> interface definition of classes inside the same interface 
> file being imported into the implementation file.  If that 
> sounds confusing; it is.  It was confusing to write too. :-)  
> If anyone has questions I'll try to expand.
> 
> It is best to probably use specific, real examples.
> http://www.openehr.org/svn/specification/TRUNK/publishing/arch
> itecture/rm/data_types_im.pdf
> 
> (note class names are converted from the upper case, 
> underscore separated style to CamelCase)
> 
> The package openehr.rm.datatypes.text defines the 
> implementation class CodePhrase.  The associated interface 
> file openehr.rm.datatypes.interfaces.text needed CodePhrase 
> as an attribute type in  DvCodedText and TermMapping needs 
> both CodePhrase and DvCodedText.  This quickly got out of control.
> 
> So my solution to solving the circular imports is to take 
> each interface and implementation and put them into one file. 
> Research tells me that this is probably the second mostly 
> popular ZCA approach.  So, ICodePhrase and CodePhrase are now 
> in openehr/rm/datatypes/codephrase.py, DvCodeText and 
> IDvCodedText in openehr/rm/datatypes/dvcodedtext.py, etc.  
> 
> But wait, now I don't have a 'text package'.  So if 
> codephrase.py and dvcodedtext.py were in 
> openehr/rm/datatypes/text/ that would solve the problem.  
> BUT! Throughout the specs many of the names are VERY long 
> already.  Adding another package name that is from 4 - 15 (or 
> more) characters long adds to the length of already long 
> import statements, i.e.
> 
> (sorry for the email line wraps)
> 
> from openehr.am.archetype.creferenceobject import 
> ICReferenceObject,CReferenceObject
> 
> should really be
> 
> from openehr.am.archetype.constraintmodel.creferenceobject 
> import ICReferenceObject,CReferenceObject
> 
> Thoughts, opinions and jeers all gratefully accepted.  :-)

For a usecase like this, I personaly recommend to 
defina all interfaces in one module which probably
is a namespace if you need alot of interfaces to define.

e.g.

openehr.interfaces.foobar.IFooBar

the reason why:

- spearate interface from implementation. That's an 
  important aspect in a component architecture. If you
  define your implementation and interfaces in one file,
  then you don't need a component architecture.

- interfaces are separated in a well know place.

This means if you define a module and you like to import 
an interface you can import just one line:

from openehr import interfaces

Which makes it very simple.


Regards
Roger Ineichen

> --Tim
> 
> 
> 
>  
> 
> 
>  
> 
> 
> --
> Timothy Cook, MSc
> Health Informatics Research & Development Services LinkedIn 
> Profile:http://www.linkedin.com/in/timothywaynecook
> Skype ID == timothy.cook
> **************************************************************
> *You may get my Public GPG key from  popular keyservers or   *
> *from this link http://timothywayne.cook.googlepages.com/home*
> **************************************************************
>