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:
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.data types.text defines the implementation class
CodePhrase. The associated interface file
openehr.rm.data types.interface s.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.arch etype.creferenc eobject import
ICReferenceObje ct,CReferenceOb ject
should really be
from openehr.am.arch etype.constrain tmodel.creferen ceobject import
ICReferenceObje ct,CReferenceOb ject
Thoughts, opinions and jeers all gratefully accepted. :-)
--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*
*************** *************** *************** *************** **
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQBIWqvv2TF RV0OoZwMRAhE1AJ 44+ZFv/1fP/btpKT54Dukvkfkh XQCfboA9
yNbJVYMKg9qhThD NM7wZwRw=
=Cgb7
-----END PGP SIGNATURE-----
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:
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.data types.text defines the implementation class
CodePhrase. The associated interface file
openehr.rm.data types.interface s.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.arch etype.creferenc eobject import
ICReferenceObje ct,CReferenceOb ject
should really be
from openehr.am.arch etype.constrain tmodel.creferen ceobject import
ICReferenceObje ct,CReferenceOb ject
Thoughts, opinions and jeers all gratefully accepted. :-)
--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*
*************** *************** *************** *************** **
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQBIWqvv2TF RV0OoZwMRAhE1AJ 44+ZFv/1fP/btpKT54Dukvkfkh XQCfboA9
yNbJVYMKg9qhThD NM7wZwRw=
=Cgb7
-----END PGP SIGNATURE-----