469,640 Members | 1,560 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,640 developers. It's quick & easy.

AW: [Zope3-Users] Python Package Construction

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
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:

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.

(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

should really be

from openehr.am.archetype.constraintmodel.creferenceobj ect
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.



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.
Roger Ineichen

Timothy Cook, MSc
Health Informatics Research & Development Services LinkedIn
Skype ID == timothy.cook
************************************************** ************
*You may get my Public GPG key from popular keyservers or *
*from this link http://timothywayne.cook.googlepages.com/home*
************************************************** ************
Jun 27 '08 #1
0 902

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

10 posts views Thread by Debian User | last post: by
reply views Thread by Aroldo Souza-Leite | last post: by
reply views Thread by JZ | last post: by
8 posts views Thread by Jean | last post: by
2 posts views Thread by Mir Nazim | last post: by
7 posts views Thread by Markus Wankus | last post: by
reply views Thread by Chris Calloway | last post: by
2 posts views Thread by Paul McGuire | last post: by
11 posts views Thread by Grzegorz Staniak | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.