[Fwd: Re: managed lists?]

[Bruno Desthuilliers]

Jorgen Bodde a écrit :
> Hi Bruno,
> 
> Thanks for your answer.
> 
> Well what I am after is a list of relations to some class type. And in
> that list I do not wish to have accidentally put ints, strings,

So don't do it !-)

> only
> one type of object, or interface. Now I can make the list interface
> safe, but it is only meant for relational purposes only. So to
> illustrate:
> 
> Song <>---->> Tab
> Song <>--->> Tuning
> 
> I want a "tabs" collection only consisting of Tab objects. They are
> very specific so "mimicing" a tab interface is not something that will
> be done anytime soon.

Yes, probably. As usual, there's the general rule and the reality. But 
still, while I understand both your use case and your fears, I think 
you're not solving the problem the right way - at least the pythonic way !-)

> I'm a traditional C++ programmer, and maybe I go through some
> transitional phase 

s/maybe/certainly/

> I don't know but exposing my list as read /
> (over)write property to the "outside world" being the rest of my
> object model, is just asking for problems.

Not necessarily. I came to Python from a C/Java (and bits of C++ FWIW) 
background, with the firm belief that coding with no static typing and 
no access restriction was "just asking for problems". It turned out that 
it usually just works - even if it sometimes requires to think about the 
problem in a different way.

> So this "strong" typed list
> will ensure me at "add" time the exception occurs, rather then
> somewhere in my applciation who knows much later that something blows
> up because the "object" from that list is retrieved and something
> unpredictable goes wrong. Is that so weird to do?

Nope, not at all. The goal is perfectly legitimate : ease debugging. 
It's the solution that is wrong IMHO - even in your particular case.

Let's restate your problem : you want to simplify debugging by knowing 
ASAP when some incompatible object is added to a Song's tunes or tabs 
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 
of the client code pass something wrong. Then it's just a matter of 
re-compiling this code with the -o flag to turn off assertion when 
deploying the finished product - by this time, you should be confident 
enough in the fact that the client code is doing right. As an added 
bonus, you gain clean encapsulation and respect the law of Demeter.


> As I said earlier I
> am a python newbie, I love the language, but the fact it can blow up
> at unpredictable times, gives me shivers.

Any program in any language can crash at unpredictable time. Better 
learn to live with it. At least Python saves you from a lot of common 
C/C++ problems related to memory management...

>> Everything in Python is an object. Including integers. And there's no
>> 'char' type in Python.
> 
> 
> The array type by the way says in the API that it can be constructed
> with a simple type like a char as in a "c" type, an int as in a "i"
> type etc..

Yes, I know. As you noticed, this is a somewhat peculiar module - not 
intended to be use as a replacement of C++ template containers. I just 
wanted to emphasis the fact that in Python itself everything is an 
object (at least anything you can bind to a name).

> As I said, I might be going through a transitional phase, but exposing
> my relation list as simply a list class where all kinds of objects can
> be dumped in, seems too much for me at this point ;-)

As I said, the problem is (IMHO) more about exposing the list *as part 
of the interface* than about the fact that a list can contain any kind 
of object.

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.

HTH