6

I recently started using Python 2.6 for Ubuntu Server admin and have two minor issues concerning redundancy:

First thing are imports: They all look something like

import Class from Class

from class import Class

And the second thing are __init__ methods:

__init__(self,arg1,...,argn):
    self.arg1 = arg1
    ...
    self.argn = argn

Are there ways to avoid these duplications?

Lennart Regebro
  • 167,292
  • 41
  • 224
  • 251
Jasper
  • 1,971
  • 19
  • 34

3 Answers3

8

The second thing is not redundancy - it is setting instance attributes. You can do it also like this:

class Foo:

   def __init__(self, **kwargs):
       for name, value in kwargs.items():
          setattr(self, name, value)

But then you need to call Foo like this:

   Foo(arg1=1, arg2=2, arg3=3)

Also your import seems to have improper syntax. It should be from Class import Class. This looks redundant to you, because it seems, that you are storing each class in a separate file (module) - and that is exactly redundant. Python is not Java, you should usually hold more objects in one module. Keep in mind, that module itself is an object. Also you should name modules properly - the default code style guide says that modules should be all lowercase with no special chars. Like re or urllib for example.

mikej
  • 65,295
  • 17
  • 152
  • 131
gruszczy
  • 40,948
  • 31
  • 128
  • 181
  • Thanks already! I corrected my import and will keep modules lowercase from now on. How would one be handling/editing large modules effectively without dividing them? – Jasper Jan 27 '11 at 10:01
  • What do you mean by large modules? Is 3k lines of code a large module? Such a module can contain a lot of classes. You can code much more sparsely in python than in `Java`/`C++`, so keeping multiple classes in on module doesn't mean, that is is large. – gruszczy Jan 27 '11 at 10:16
2
from module import Class

It is common for class names to be different from their containing module's name. If you have just one class per module with an identical name, consider moving that class up a level in your hierarchy.

def __init__(self, a, b, c):
  self.a = a
  self.b = b
  self.c = c

This does often seem to be kinda annoying, but it's really not bad, readability-wise, compared to alternatives. However, if you have a lot of parameters that you merely assign as attributes with no other work in your init, then consider inheriting from a namedtuple or similar, which can generate such boilerplate for you. (Namedtuple in particular has other ramifications and will only be sometimes suitable. I'm using it as an example of a base class which can handle this type of boilerplate.)

Fred Nurk
  • 13,952
  • 4
  • 37
  • 63
1

Version for args:

class Foo:

   def __init__(self, *args):
       for index,arg in enumerate(args):
          setattr(self, 'arg%s'%index, arg)


Foo(1,2,3)
>>> Foo.arg0
1
Frost.baka
  • 7,851
  • 2
  • 22
  • 18
  • I agree, this is not Pythonic at all. Explicit is better than implicit, and this looks to me like a mild case of implicit magic. – Sasha Chedygov Jan 27 '11 at 10:03
  • 1
    *Hopefully* the actual attribute names aren't arg0 through argN, because if they are, they should be a sequence. If they're not, this answer doesn't apply. – Fred Nurk Jan 27 '11 at 10:03
  • this may be ugly and unpythonic, but this is also not a refactoring contest isn't it ? and the code answers authors question *literally* – Frost.baka Jan 27 '11 at 11:13
  • @Frost: Only if you literally interpret the OP's use of "arg1" as an actual variable name rather than a metasyntactic variable. If it had "foo" and "bar" instead, then the question remains the same but your answer is wrong. – Fred Nurk Jan 27 '11 at 11:27
  • And, actually, your answer is wrong anyway according to your interpretation: the OP starts with arg1, but you start with arg0. – Fred Nurk Jan 27 '11 at 11:28