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* > ************************************************************** > -- http://mail.python.org/mailman/listinfo/python-list