More __init__ methods

[Mr.SpOOn]

Re: More __init__ methods

On Fri, Nov 7, 2008 at 4:16 PM, Duncan Booth
<duncan.booth@i nvalid.invalidw rote:

There is a really big advantage to being explicit in this situation: you no
longer have to make sure that all your constructors use a unique set of
types. Consider:
>
class Location(object ):
def __init__(self, lat, long): ...
>
@classmethod
def from_city(name) : ...
>
@classmethod
def from_postcode(n ame): ...
>
'from_string' is a bad name here for your factory method: you should try to
make it clear what sort of string is expected.

Yes, that's what I was going to do.
But, for example, I have a parse method to create such object from a
string. So I need to call this method to actually create the object.
Now I must put the code of the parse method into the @classmethod
constructor.

What if I need the parse method to be called in other parts of the program?

[Marc 'BlackJack' Rintsch]

Re: More __init__ methods

On Fri, 07 Nov 2008 17:23:21 +0100, Mr.SpOOn wrote:

On Fri, Nov 7, 2008 at 4:16 PM, Duncan Booth
<duncan.booth@i nvalid.invalidw rote:

>There is a really big advantage to being explicit in this situation:
>you no longer have to make sure that all your constructors use a unique
>set of types. Consider:
>>
>class Location(object ):
> def __init__(self, lat, long): ...
>>
> @classmethod
> def from_city(name) : ...
>>
> @classmethod
> def from_postcode(n ame): ...
>>
>'from_string ' is a bad name here for your factory method: you should
>try to make it clear what sort of string is expected.

>
Yes, that's what I was going to do.
But, for example, I have a parse method to create such object from a
string. So I need to call this method to actually create the object. Now
I must put the code of the parse method into the @classmethod
constructor.

You can still spread it over other `classmethod()` \s or `staticmethod() `s
or even plain functions at module level.

What if I need the parse method to be called in other parts of the
program?

I don't understand!? Then you call it from those other parts.

Ciao,
Marc 'BlackJack' Rintsch

[Terry Reedy]

Re: More __init__ methods

Duncan Booth wrote:

Mr.SpOOn <mr.spoon21@gma il.comwrote:
>

>Now I must pass a and b to the main constructor and calculate them in
>the classmethods.
>>
>class foo:
> def __init__(self, a, b):
> self.a = a
> self.b = b
>>
> @classmethod
> def from_string(sel f, ..):
> ...
> ...
>>
>What I mean is: I can't use anymore __init__ as the default
>constructor, but I always have to specify the way I'm creating my
>object. Am I right? I'm asking just to be sure I have understood.

>
There is a really big advantage to being explicit in this situation: you no
longer have to make sure that all your constructors use a unique set of
types. Consider:
>
class Location(object ):
def __init__(self, lat, long): ...
>
@classmethod
def from_city(name) : ...
>
@classmethod
def from_postcode(n ame): ...
>
'from_string' is a bad name here for your factory method: you should try to
make it clear what sort of string is expected.

One built-in model for .__init__ + .from_data is dict. __init__ can
take either one iterable or several keywords. In either case, it gets a
set of key:value pairs. .from_keys take a set of keys and an optional
value to override None that is matched with all keys.

[Mr.SpOOn]

Re: More __init__ methods

On Fri, Nov 7, 2008 at 7:02 PM, Marc 'BlackJack' Rintsch <bj_666@gmx.net wrote:

>What if I need the parse method to be called in other parts of the
>program?

>
I don't understand!? Then you call it from those other parts.

Yes, you're right. Don't know why, but I was thinking to use
@classmethod just for the alternative constructors.