beginner, idomatic python 2

[bambam]

Would someone like to suggest a replacement for this? This is a
function that returns different kinds of similar objects, depending
on what is asked for. PSP and PWR are classes. I don't really
want to re-write the calling code very much: I'm just wondering
if the function can be replaced with some kind of OOP pattern.

def Device(DeviceType):
if DeviceType=='PSP':
return PSP()
elif DeviceType=="Power Supply"
return PWR()
etc...
Thanks!

[Dan Bishop]

On Aug 23, 10:21 pm, "bambam" <[e-mail]:

Would someone like to suggest a replacement for this? This is a
function that returns different kinds of similar objects, depending
on what is asked for. PSP and PWR are classes. I don't really
want to re-write the calling code very much: I'm just wondering
if the function can be replaced with some kind of OOP pattern.

def Device(DeviceType):
if DeviceType=='PSP':
return PSP()
elif DeviceType=="Power Supply"
return PWR()
etc...

Thanks!

Typically, you'd use a dictionary:

DEVICE_DICT = {
'PSP': PSP.
'Power Supply': PWR,
# etc.
}

and your function would simply return DEVICE_DICT[device_type]()

[Bruno Desthuilliers]

bambam a écrit :

Would someone like to suggest a replacement for this? This is a
function that returns different kinds of similar objects, depending
on what is asked for. PSP and PWR are classes. I don't really
want to re-write the calling code very much: I'm just wondering
if the function can be replaced with some kind of OOP pattern.

Dan already answered to this. Just as a side note, and since you're
trying to be "idiomatic", Python's naming convention is to use all_lower
for functions, MixedCaps for classes (except - mostly for historical
reasons - the builtin types...), and ALL_LOWER for symbolic (pseudo)
constants.

def Device(DeviceType):
if DeviceType=='PSP':
return PSP()
elif DeviceType=="Power Supply"
return PWR()
etc...
Thanks!

[Bruno Desthuilliers]

Bruno Desthuilliers a écrit :
(snip)

and ALL_LOWER

That's 'ALL_UPPER', of course :(

for symbolic (pseudo)
constants.

[bambam]

trying to be "idiomatic"

....I hope that if a python programmer looks at my code it
won't be an excuse to discard it. Less of an issue with Python
than with C/C++, but since I'm just starting...

def device(DeviceType):
if DeviceType=='PSP':
return Psp()
elif DeviceType=="Power Supply"
return Pwr()

What about the parameter "DeviceType"?

Also, I see what you mean now, DEVICE_DICT is upper
case because it is a 'constant' -- I'd missed that point.

Steve.

"Bruno Desthuilliers" <br********************@wtf.websiteburo.oops.com >
wrote in message news:46*********************@news.free.fr...

bambam a écrit :

>Would someone like to suggest a replacement for this? This is a
function that returns different kinds of similar objects, depending
on what is asked for. PSP and PWR are classes. I don't really
want to re-write the calling code very much: I'm just wondering
if the function can be replaced with some kind of OOP pattern.

Dan already answered to this. Just as a side note, and since you're trying
to be "idiomatic", Python's naming convention is to use all_lower for
functions, MixedCaps for classes (except - mostly for historical reasons -
the builtin types...), and ALL_LOWER for symbolic (pseudo) constants.

>def Device(DeviceType):
if DeviceType=='PSP':
return PSP()
elif DeviceType=="Power Supply"
return PWR()
etc...
Thanks!

[Bruno Desthuilliers]

bambam a écrit :

>trying to be "idiomatic"

...I hope that if a python programmer looks at my code it
won't be an excuse to discard it.

Hopefully not - and nothing forces you into adopting the common
convention !-) But it's a fact that Python relies heavily on naming
conventions, and that it greatly helps readability.

Less of an issue with Python
than with C/C++, but since I'm just starting...

def device(DeviceType):
if DeviceType=='PSP':
return Psp()
elif DeviceType=="Power Supply"
return Pwr()

What about the parameter "DeviceType"?

DEVICE_TYPES = {
'PSP' : Psp,
'Power Supply' : Pwr,
}

def get_device(device_type):
cls = DEVICE_TYPES.get(device_type, None)
if cls is not None:
return cls()
# implicitly returns None, which may or not be a GoodThing(tm)

HTH

[bambam]

Thank you. I didn't reply earlier because I was trying to get my
head around what you wrote, which was strange and foreign
to me.

It seems to me that the dictionary object you suggested is a
direct replacement for the function code, only more efficient
because the case table is internalised with a hash table, and
the original if/elif/else case table was unlikely to be implemented
as a hash table.

And presumably, it is idiomatic because Python programmers
expect to use dictionaries for their lookup tables.

You have answered a question I didn't know enough to ask :~)
--which is why I started with the general question, so I don't
feel too stupid about that --.

And now I wonder about the 'other' question. Should I consider
dynamically overriding the methods in my 'Device' class, instead
of creating separate classes for the Psp and Pwr devices?
I could create an object of the base Device class, and at init
I could make sure the methods were connected for a Psp or
a Pwr device. When (if ever) is that a good idea?

Steve.


"Dan Bishop" <da*****@yahoo.comwrote in message
news:11**********************@e9g2000prf.googlegro ups.com...

On Aug 23, 10:21 pm, "bambam" <[e-mail]:

>Would someone like to suggest a replacement for this? This is a
function that returns different kinds of similar objects, depending
on what is asked for. PSP and PWR are classes. I don't really
want to re-write the calling code very much: I'm just wondering
if the function can be replaced with some kind of OOP pattern.

def Device(DeviceType):
if DeviceType=='PSP':
return PSP()
elif DeviceType=="Power Supply"
return PWR()
etc...

Thanks!

Typically, you'd use a dictionary:

DEVICE_DICT = {
'PSP': PSP.
'Power Supply': PWR,
# etc.
}

and your function would simply return DEVICE_DICT[device_type]()

[Steve Holden]

bambam wrote:
[but he top-posted]

"Dan Bishop" <da*****@yahoo.comwrote in message
news:11**********************@e9g2000prf.googlegro ups.com...

>On Aug 23, 10:21 pm, "bambam" <[e-mail]:

>>Would someone like to suggest a replacement for this? This is a
function that returns different kinds of similar objects, depending
on what is asked for. PSP and PWR are classes. I don't really
want to re-write the calling code very much: I'm just wondering
if the function can be replaced with some kind of OOP pattern.

def Device(DeviceType):
if DeviceType=='PSP':
return PSP()
elif DeviceType=="Power Supply"
return PWR()
etc...

Thanks!

Typically, you'd use a dictionary:

DEVICE_DICT = {
'PSP': PSP.
'Power Supply': PWR,
# etc.
}

and your function would simply return DEVICE_DICT[device_type]()

Thank you. I didn't reply earlier because I was trying to get my
head around what you wrote, which was strange and foreign
to me.

It seems to me that the dictionary object you suggested is a
direct replacement for the function code, only more efficient
because the case table is internalised with a hash table, and
the original if/elif/else case table was unlikely to be implemented
as a hash table.

And presumably, it is idiomatic because Python programmers
expect to use dictionaries for their lookup tables.

You have answered a question I didn't know enough to ask :~)
--which is why I started with the general question, so I don't
feel too stupid about that --.

And now I wonder about the 'other' question. Should I consider
dynamically overriding the methods in my 'Device' class, instead
of creating separate classes for the Psp and Pwr devices?
I could create an object of the base Device class, and at init
I could make sure the methods were connected for a Psp or
a Pwr device. When (if ever) is that a good idea?

The fact that it's technically possible in Python doesn't mean it's
always a good idea. I prefer to reserve that kind of behavior for when
the effective behavior of an object needs to change after it's been
created. Here you know at creation time which type you want, so it makes
sense to me to create exactly that kind of object. Otherwise you are
obscuring your program's structure by using dynamic type modification
unnecessarily.

Just my $0.02, others will have different opinions.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------

[Bruno Desthuilliers]

bambam a écrit :

<OT>Steve, could you please stop top-posting ?-) TIA </OT>

"Dan Bishop" <da*****@yahoo.comwrote in message
news:11**********************@e9g2000prf.googlegro ups.com...

>On Aug 23, 10:21 pm, "bambam" <[e-mail]:

>>Would someone like to suggest a replacement for this? This is a
function that returns different kinds of similar objects, depending
on what is asked for. PSP and PWR are classes. I don't really
want to re-write the calling code very much: I'm just wondering
if the function can be replaced with some kind of OOP pattern.

def Device(DeviceType):
if DeviceType=='PSP':
return PSP()
elif DeviceType=="Power Supply"
return PWR()
etc...

Thanks!

Typically, you'd use a dictionary:

DEVICE_DICT = {
'PSP': PSP.
'Power Supply': PWR,
# etc.
}

and your function would simply return DEVICE_DICT[device_type]()

Thank you. I didn't reply earlier because I was trying to get my
head around what you wrote, which was strange and foreign
to me.

It seems to me that the dictionary object you suggested is a
direct replacement for the function code,

Almost, yes !-)

only more efficient
because the case table is internalised with a hash table, and
the original if/elif/else case table was unlikely to be implemented
as a hash table.

And presumably, it is idiomatic

It is. Dicts are probably the central data structure in Python, and are
highly optimised. You'll find quite a lot of dict-based dispatch in
Python code.

because Python programmers
expect to use dictionaries for their lookup tables.

Indeed - that's what dictionnaries are for.

You have answered a question I didn't know enough to ask :~)
--which is why I started with the general question, so I don't
feel too stupid about that --.

And now I wonder about the 'other' question. Should I consider
dynamically overriding the methods in my 'Device' class, instead
of creating separate classes for the Psp and Pwr devices?
I could create an object of the base Device class, and at init
I could make sure the methods were connected for a Psp or
a Pwr device. When (if ever) is that a good idea?

While it's technically possible, I wouldn't advise such a design (which
looks pretty close to the Prototype pattern) unless you need to have
something *highly* extensible and customisable (and even then, there are
other - possibly better - ways, depending on the context). If the Device
taxonomy is stable and well defined, you're certainly
DoingTheSimplestThing (here, a dict-based dispatch encapsulated in a
factory function...).

As a side note, in Python, inheritance is mostly an implementation
detail, and should usually not be used for typing.

My 2 cents...

[bambam]

Thank you.

I'm glad to see that I don't need to choose between two
opposing viewpoints :~)

Steve.

[bambam]

"Bruno Desthuilliers" <br********************@wtf.websiteburo.oops.com >
wrote in message news:46*********************@news.free.fr...

>
As a side note, in Python, inheritance ...
... should usually not be used for typing.

:~(
I'm sorry, I don't even know what that means... The code I
have inherited from someone only a little more knowledgeable
than me, and is still full of development artifacts anyway.

The Pwr and Psp classes inherit from the Device class not
neccessarily because that is a Good Thing, more because
the development process led to them being thought of that
way. All devices have a mixture of common and differing
attributes.

What is 'typing'?

Steve.

[Bruno Desthuilliers]

bambam a écrit :

"Bruno Desthuilliers" <br********************@wtf.websiteburo.oops.com >
wrote in message news:46*********************@news.free.fr...

>As a side note, in Python, inheritance ...
... should usually not be used for typing.

:~(
I'm sorry, I don't even know what that means... The code I
have inherited from someone only a little more knowledgeable
than me, and is still full of development artifacts anyway.

The Pwr and Psp classes inherit from the Device class not
neccessarily because that is a Good Thing, more because
the development process led to them being thought of that
way. All devices have a mixture of common and differing
attributes.

What is 'typing'?

Mmm... Most CS experts don't really agree on this, and I'm certainly not
one (expert). So I won't even try to explain it by myself, and let you
google for "type system", "static typing", "dynamic typing", "duck
typing" etc...

Now what I meant here is that in Python, you don't have to make class B
inherit from class A to let you use an instance of B where an instance
of A was expected - all you need is that both objects share the set of
attributes and methods you're going to use. Inheritence is only useful
for sharing common code.

HTH