first try with python class, suggestion for improvement please

[ichabod801]

1) is it good practice to have multiple class in single script?
2) how can i return converted values within class?
3) Guide me for improvement

1) Yes, if they are all related. For example, I have a cards.py file in my t_games project, which has two classes for different kinds of cards, a class for a deck of each of those card objects, and a class for a hand of cards. But then all of the classes for board games are in another file, and the different player classes are in a third file, and so on.

2) I'm not sure exactly what you mean, but by converted values do you mean things like get_fanstatus on line 22? If so, you can return that value into another method:

class Foo(object):

    def __init__(self, num):
        self.id = self.get_id(num)

    def get_id(self, num):
        return num + 1 * 2 ** 3

3) Here's what I noted skimming through your class, not really trying to understand what the code is doing:

3a) Comment your code. Each method or function should have a docstring explaining what it does and what it's parameters are. Each class should have a docstring explaining what it's for, what's it's methods do, and what it's attributes are for. The way I do it is like this:

class Foo(object):
    """
    A object for demostrating conversion of values. (object)

    Attributes:
    id: An ID number for the foo meeting the Scotty criteria. (int)

    Methods:
    get_id: Convert a number to a valid ID. (int)
    """

    def __init__(self, num):
        """
        Set up the foo's ID. (None)

        Parameters:
        num: The integer basis for the foo. (int)
        """
        self.id = self.get_id(num)

    def get_id(self, num):
        """
        Convert a number to a Scotty ID.  (int)

        Parameters:
        num: The base number for the Scotty ID. (int)
        """
        return num + 1 * 2 ** 3

That may seem like too much, but that's because it's just a ditzy little test class. If it still seems like too much after you do it with your code, that's because you haven't yet had to deal with other people's undocumented code. And other people includes you six months ago. Just because it's totally clear to you now doesn't mean it's totally clear to someone else or somewhen else.

In addition to the docstrings, methods longer than 4 or 5 lines, or that go through multiple steps (as you conceive steps), should have an outline of what they are doing mixed in with the code using # comments.

3b) Be consistent with your variable names. Generally you have different styles for variables, functions/methods, classes, and global constants. You see this a lot in Python: variable_names, function_names, ClassNames, CONSTANT_NAMES. That's PEP 8 style, which is common but not mandatory. However, being consistent with whatever style you use helps make the role of each name clear in the code.

3c) FanSpeed and fanstatus should be class variables. They're don't change but they are closely related to the class. I would do something like this:

class Fan:
    fan_speed = { '0':'Not Applicable',
                 '1':'Unknown',
                 '2':'Half Speed',
                 '3':'Full Speed',
                 '4':'Low Speed'
               }
    fan_status = { '1':'Unknown',
                  '2':'Fan Removed',
                  '3':'Up',
                  '4':'Fail',
                  '5':'Out of Service'
                }
                
    def __init__(self,host,community,version,timeout):
        self.host = host
        self.community = community
        self.version = version
        self.timeout = timeout

    def get_fan_speed(value):
        return self.fan_speed.get(value,"other")

    def get_fan_status(value):
        return self.fan_status.get(value,"other")

Likewise your Record namedtuple should either be a class attribute or a module level constant. As it is you are reprocessing these objects every time you call those methods. There is no need to do that.

3d) Try/except blocks should be tight and specific. Try to limit the code in the try block to just what will cause the error. If you have one or two lines to process if there is no error, they can go in there. If there's more than a couple of lines to process if there is no error, the except block should return, continue, or break, or there should be an else block for that code. The except statement should specify the specific errors you are expecting. Otherwise they might hide unexpected errors as expected errors, making it harder to debug the unexpected ones. The try/except block is especially heinous.