@ Larry, As much as I like to follow the idiom that Python has, I do not see the usefulness of making an add function that checks the interface that other objects might need. Besides the fact it is a bit overhead and not to mention performance draining, in an application that I develop myself, without plugin architecture (not yet) etc, it is a bit much to do that.
I agree with the writing C in Python, it is all I know, because that is the language I started with. This is my first big project and most certainly when evaluating this when it is finished I will come to the conclusion it was all for nothing ;-) I will change to extend() and maybe drop the type safety, but I do wish to keep the list functionality as I find it more logical to write song.categories.append() Then creating a method in song called AddCategory() and kind of duplicating the list functionality there. Thank you for the guide lines and the nice comments! They are really helpful. @ Bruno, > list. The right solution IMHO is to *not* expose these lists as part of > the interface - after all, the fact that tabs and tunes are stored in > lists is an implementation detail -, and to add the necessary API to the > Song object - ie : Song.add_tune, Song.add_tab, Song.iter_tunes, > Song.iter_tabs, etc. Then you just have to add some assert statements in > the add_XXX methods so you'll be warned at the right time when some part This is how I did it before, I created Song.AddTab, Song.DeleteTab, then there was a category class which also needed adding, deleting, clearing, and soon my whole Song object was filled with relational methods which were basically a copy of the list, with a check on the presence of the class in the list. Then I realized, a managed list with self-check capability solves this because I do not like to duplicate code, but now that I think of it, the type check might be a bit too much. Like said, the list solution you described and the solution I use, are basically the same, I encapsulated a list [] in a class, with some extra methods to warn the 'owner' of the list that something is changed. > Oh, yes, while we're at it, and in case you don't know yet: the Python > idiom for implementation attributes (including methods - remember, > everything is an object) is to prefix them with a single underscore. Ok, but why is that? I do know semi-private symbols can be realised using two underscores, and if I wish to hide a list / index / etc so it cannot accidentally changed, would I not use double underscores? Thanks for your extensive help! - Jorgen -- http://mail.python.org/mailman/listinfo/python-list
