467,130 Members | 1,392 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

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

Package organisation question.

Hello!

I maintain a small package for talking to the API of BulkSMS.co.uk. I
have been adding support for some new features recently, and found
myself slightly indecisive over how best to lay out the modules
internally.

I have a 'BulkSMS.Exceptions' module, which contains a base class and
(currently) all derived exceptions that my package throws. This has
been fine up until now, as the exceptions were generated by only one
monolithic module. I am now adding support for 2-way SMS to the
package, and found a need to define some more exceptions.

I suspect this is close to purely being a style question, but I'm not
sure and wondered if people knew of any practical pros or cons of
either of the options I have.

My question is this: for extended functionality, implemented as a
sub-module on top of the core package, should extended exceptions be
defined in the main 'BulkSMS.Exceptions' (since they are distributed
together anyway), or should I 'import Exceptions' from the sub-module
and define my new exceptions there?

From what I can see:

- With the former, a person need only 'help(BulkSMS.Exceptions)' to
get comprehensive information on errors they should expect to see.

- With the latter, software using the package need only import one
submodule to get both exceptions and functionality, eg.:

import BulkSMS.InboxClient as InboxClient
...
try:
...
except InboxClient.AuthenticationError, error:
...

- Latter: makes organisation of the module a little messy, since the
'Exceptions' module does not represent all of the exceptions in the
package.

- Latter: code and exceptions loaded in the interpreter more
accurately represent the functionality in use.

- Latter: splitting submodules out into their own packages is easier,
since they are already self-contained. There would be less changes
required to existing code to make them work with any changes in the
namespace layout.
I think I am tending towards the latter, as I think the small amount
of disorganisation the split-up exceptions causes reaps quite useful
benefits elsewhere.

The question is really quite simple, however I'm trying hard not to
turn this little package into a mess. It's the first thing I've
written in ages that I've been even moderately happy with the design
of, and I don't want to loose the therapeutic effect modifying it has.
:)

There is at least one other feature I would like to add in this way,
so getting it right would be a good thing. A very old version of the
package is on http://botanicus.net/dw/.

Thanks,
David.
[Woah, you're still here? Yes, I'm aware it is quite a boring
question. :)]
Jul 18 '05 #1
  • viewed: 1006
Share:

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

8 posts views Thread by Georg Brandl | last post: by
30 posts views Thread by Stuart Turner | last post: by
10 posts views Thread by datapro01@yahoo.com | last post: by
4 posts views Thread by Thornmastr@NOSPAM.earthlink.net | last post: by
3 posts views Thread by shorti | last post: by
reply views Thread by phanipep | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.