By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,035 Members | 1,984 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,035 IT Pros & Developers. It's quick & easy.

Package organisation question.

P: n/a

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

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

- 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

[Woah, you're still here? Yes, I'm aware it is quite a boring
question. :)]
Jul 18 '05 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.