3

NOTE: My question may be more heavily based in coding convention than anything else.

I'm working on a personal project and I am looking for as clean and 'Pythonic' a way to return object variables for display.

I'm currently implementing my objects like this...

class MyChildObject(MyParentObject):
  'An example object'

  def __init__(self, attr_a, attr_b, attr_c):
    self.attr_a = ('Attribute A', attr_a)
    self.attr_b = ('Attribute B', attr_b)
    self.attr_c = ('Attribute C', attr_c)

  # Return a list of tuples with display names and values for each attribute
  def list_attributes(self):
    return [self.attr_a, self.attr_b, self.attr_c]

... (which is seems ugly and just plain wrong) and displaying their attributes with this (from MyParentObject)...

  # Displays attributes of a given object
  def display_attributes(an_object):
    for i, attr in enumerate(an_object.list_attributes()):
      print '%s. %s: %s' % (i, attr[0], attr[1])

Setting my objects' attributes as tuples of their display and value doesn't seem right. I also thought of setting my class up like this...

class MyChildObject(object):
  'An example object'

  def __init__(self, attr_a, attr_b, attr_c):
    self.attr_a = attr_a
    self.attr_b = attr_b
    self.attr_c = attr_c

  # Return a list of tuples with display names and values for each attribute
  def list_attributes(self):
    return [('Attribute A', self.attr_a), ('Attribute B', self.attr_b), ('Attribute C', self.attr_c)]

... but that doesn't seem to be any cleaner. Is there some 'best practice' or convention for doing this?

Hill
  • 71
  • 5
  • 4
    Generally, labels for attributes should be part of the *presentation layer*, not the business objects. – Martijn Pieters Oct 11 '15 at 12:58
  • *"Display"* to whom? If this is for debugging, you should implement `__repr__`. – jonrsharpe Oct 11 '15 at 13:41
  • @MartijnPieters How would I implement a "presentation layer" – Hill Oct 11 '15 at 13:56
  • @jonrsharpe It's for eventual use in some sort of UI not representing the object. I want to be able to call `display_attributes(an_object)` and have the object return its `list_attributes()` for a formatted display to the user. – Hill Oct 11 '15 at 14:08
  • Then Martijn's right, that should live in the UI, where you can e.g. internationalise it more easily. – jonrsharpe Oct 11 '15 at 14:10
  • @hsc36: that depends on the users and the medium; a web application and a desktop GUI will handle that differently, as well as how things are presented. That way you can always swap out presentation, translation, etc. depending on the changing needs of the applications without having to redesign the business layer objects. – Martijn Pieters Oct 11 '15 at 14:11
  • @MartijnPieters It'll be a desktop GUI. Wouldn't that require the interface to know "too much" about the objects? My understanding was that this would cause strong coupling, making the UI aware of the objects details. – Hill Oct 11 '15 at 14:16
  • @hsc36: you can still model views separate from the GUI framework itself. The [Django admin interface](https://docs.djangoproject.com/en/1.8/ref/contrib/admin/) uses introspection and dedicated view models to couple a generic presentation with specific business objects, for example. – Martijn Pieters Oct 11 '15 at 14:18
  • @hsc36: at the same time, the admin interface is targeted at site administrators, while you are expected to produce your front-end with different tools; the admin view models are thus not limiting how that is going to be implemented. – Martijn Pieters Oct 11 '15 at 14:19

0 Answers0