From: kj on






I need to create a class solely for the purpose of encapsulating
a large number of disparate data items. At the moment I have no
plans for any methods for this class other than the bazillion
accessors required to access these various instance variables.
(In case it matters, this class is meant to be a private helper
class internal to a module, and it won't be subclassed.)

What is "best practice" for implementing this sort of class
*succinctly* (i.e. without a lot of repetitive accessor code)?

Also, one more question concerning syntax. Suppose that i represents
an instance of this class. Is it possible to define the class to
support this syntax

val = i.field
i.field += 6

....rather than this one

val = i.get_field()
i.set_field(i.get_field() + 6)

?

TIA!

~K
From: Chris Rebert on
On Sat, Mar 20, 2010 at 3:15 PM, kj <no.email(a)please.post> wrote:
> I need to create a class solely for the purpose of encapsulating
> a large number of disparate data items.  At the moment I have no
> plans for any methods for this class other than the bazillion
> accessors required to access these various instance variables.
> (In case it matters, this class is meant to be a private helper
> class internal to a module, and it won't be subclassed.)

If it's just a completely dumb struct-like class, you might consider
something like:
http://docs.python.org/library/collections.html#collections.namedtuple

> What is "best practice" for implementing this sort of class
> *succinctly* (i.e. without a lot of repetitive accessor code)?

Is there any good reason you can't just use straight instance
variables? Python ain't Java; vanilla, boilerplate accessor methods
should almost always be avoided.

> Also, one more question concerning syntax.  Suppose that i represents
> an instance of this class.  Is it possible to define the class to
> support this syntax
>
>  val = i.field
>  i.field += 6
>
> ...rather than this one
>
>  val = i.get_field()
>  i.set_field(i.get_field() + 6)
>
> ?

Yes, using the magic of the property() function:
http://docs.python.org/library/functions.html#property

Cheers,
Chris
--
http://blog.rebertia.com
From: Steven D'Aprano on
On Sat, 20 Mar 2010 22:15:54 +0000, kj wrote:

> I need to create a class solely for the purpose of encapsulating a large
> number of disparate data items.

There's a built-in for that. It's called "dict". Syntax for item access
is a tiny bit different, but still very common:

data['foo']

instead of

data.foo

If you need to customize item access, you need to modify __getitem__,
__setitem__ and __delitem__ instead of __getattr__ etc., but otherwise
they are nearly identical. Ignoring a few complications due to slots and
inheritance, attribute access is built on top of item access, so you
won't notice any performance hit (and you might see a tiny performance
benefit).


> At the moment I have no plans for any
> methods for this class other than the bazillion accessors required to
> access these various instance variables.

Huh? If you have instance variables, why don't you refer to them by name?

x = MyClass() # create an instance
y = MyClass() # another variable bound to an instance
z = MyClass() # etc.
print x, y, z



> (In case it matters, this class
> is meant to be a private helper class internal to a module, and it won't
> be subclassed.)
>
> What is "best practice" for implementing this sort of class *succinctly*
> (i.e. without a lot of repetitive accessor code)?

Leave the repetitive accessor code out. Python isn't Java.

http://dirtsimple.org/2004/12/python-is-not-java.html


> Also, one more question concerning syntax. Suppose that i represents an
> instance of this class. Is it possible to define the class to support
> this syntax
>
> val = i.field
> i.field += 6

Classes already support that.


>>> class C(object):
.... pass
....
>>> i = C()
>>> i.field = 42
>>> val = i.field
>>> i.field += 6
>>> print (val, i.field)
42 48



> ...rather than this one
>
> val = i.get_field()
> i.set_field(i.get_field() + 6)
>
> ?

Good grief! No wonder Java coders are so unproductive :(




--
Steven
From: Diez B. Roggisch on
kj <no.email(a)please.post> wrote:
>
>
>
>
>
>
> I need to create a class solely for the purpose of encapsulating
> a large number of disparate data items. At the moment I have no
> plans for any methods for this class other than the bazillion
> accessors required to access these various instance variables.
> (In case it matters, this class is meant to be a private helper
> class internal to a module, and it won't be subclassed.)
>
> What is "best practice" for implementing this sort of class
> *succinctly* (i.e. without a lot of repetitive accessor code)?
>
> Also, one more question concerning syntax. Suppose that i represents
> an instance of this class. Is it possible to define the class to
> support this syntax
>
> val = i.field
> i.field += 6
>
> ...rather than this one
>
> val = i.get_field()
> i.set_field(i.get_field() + 6)
>
> ?


You don't. Python is not Java. So just use instance attributes, and if
you need bhavior when accessing an attribute, introduce a property.

Diez
From: kj on
In <639908184290880449.447600deets-nospam.web.de(a)news.hansenet.de> Diez B. Roggisch <deets(a)nospam.web.de> writes:

>You don't. Python is not Java. So just use instance attributes, and if
>you need bhavior when accessing an attribute, introduce a property.


Just accessing attributes looks a bit dangerous to me, due to bugs
like typing

i.typo = 'foo'

when what you meant is

i.type = 'foo'

I tried fixing this by mucking with __setattr__, but I didn't hit
on a satisfactory solution (basically, I couldn't find a good,
self-maintaining, way to specify the attributes that were OK to
set from those that weren't). Is there anything built-in?

Regarding properties, is there a built-in way to memoize them? For
example, suppose that the value of a property is obtained by parsing
the contents of a file (specified in another instance attribute).
It would make no sense to do this parsing more than once. Is there
a standard idiom for memoizing the value once it is determined for
the first time?

Thanks!

~K