Duncan Booth wrote:
> bruno at modulix wrote:
>
>
>>It's *already* split : __new__ construct the object, __init__
>>initialize it.
>>
>>>That's why I would go for the 2-phase construction:
>>
>>But that's already what you have.
>
> Very good point.
>
>
>>>after the first phase
>>>you have an object which is fully initialised, just not yet
>>>used/connected/running. For example httplib.HTTPConnection does this:
>>>you construct the object with a host and port, but the actual
>>>connection is triggered by a separate object.
>>
>>If you look at file objects, they do try and open the file at init
>>time. Is a net or db connection that different ?
>
>
> Well, yes, since the whole point is that we are discussing overriding
> methods and I bet you haven't subclassed Python file objects recently.
And you win !-)
Anyway, I didn't suggest that opening a connection to whatever should be
done in the __init__ - I just wanted to point that acquiring a resource
in the initializer (and freeing it in the finalizer) can sometimes be
perfectly sensible.
wrt/ initializer as a template method, I still fail to see why this
should be a problem. The fact that one should avoid doing anything else
than initialization in the initializer is just plain old common sense
IMHO - the use of calls to other methods that can possibly be overriden
in a subclass is orthogonal. And if the guy writing the subclass do
stupid things when overridding these methods, well, too bad for him -
but as the author of the base class, that's definitively not my problem
(given proper documentation of course)
Trying to protect stupid programmers from doing stupid things is a total
waste of time anyway.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
