At 10:36 AM 7/28/2005 -0700, Alec Flett wrote:
Phillip J. Eby wrote:
One of the 0.6 developer platform goals is to flatten our Python package
hierarchy a bit,
This is really great - I've been looking forward to this kind of change
for a while. The only thing I see that I'd like changed slightly from your
list is this:
osaf.contentmodel.calendar.Calendar.* -> osaf.pim.calendar.*
osaf.contentmodel.calendar.Recurrence.* -> osaf.pim.recurrence.*
Recurrence is really part of the Calendar and the filename split is really
just to break apart the logic within the module. Ideally we'd have
osaf.pim.calendar.CalendarEventMixin, osaf.pim.calendar.RecurrenceRuleSet,
and so forth. Is there an obvious convention in python (like import *
from... inside of __init__.py) to allow this to happen while still letting
Calendar.py and Recurrence.py remain seperate files within the
osaf.pim.calendar module?
Note that what I was proposing is to rename calendar/Calendar.py to just
calendar.py, and the same for recurrence. I was under the impression,
however, that recurrence was supposed to be able to be used for tasks as
well at some point, so maybe I'm confused...?
On a related note, why osaf.pim? why not just "chandler"? I'm guessing the
argument is that you could reuse these objects outside of chandler, which
seems nice.. though even the osaf prefix seems superfluous to me..
It's common practice in Python projects of this size that also expose a
development platform or framework to use a namespace package to prefix
package names, e.g. twisted.*, zope.*, peak.*. The second level name then
usually exposes major functional areas, and then the third level is
preferably all modules, and no further packages except for "*.tests" packages.
The namespace prefix allows the use of rather general names, while
lessening chances of collision with projects that want to reuse code from
the platform.
In the long term I'd like to see package names like 'crypto' and
'application' also get folded under the 'osaf' umbrella for this reason,
but that needs to wait until our parcel management is no longer dependent
upon the 'parcels/' directory system and we have good support for namespace
packages.
So on a related note, I'd like to propose some future renames after you're
done with this one
(and maybe you've already thought about this)
A little bit. I'm reluctant to take on too much at once, before the areas
in question have "settled" enough to allow choosing good names. I think
osaf.contentmodel is a no-brainer, but a lot of other pacakges I don't feel
nearly as certain about, and would like to give any renaming ideas some
time to develop further. We really don't want to thrash names, and I would
hate to change a bunch of stuff only to discover a month later that we made
a mistake and need to change it all again. I've been thinking about the
contentmodel->pim thing for like 4 or 5 months now and only in the last
month or two have I been seriously proposing it. So, lets give these other
ideas a little time to mature, and we should get some experience about what
we actually like/dislike from doing the contentmodel and using the result.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
