'Once' properties.

[menomnon]

Does python have a ‘once’ (per class) feature?

‘Once’, as I’ve know it is in Eiffel. May be in Java don’t.

The first time you instantiate a given class into an object it
constructs, say, a dictionary containing static information. In my
case static is information that may change once a week at the most and
there’s no need to be refreshing this data during a single running of
the program (currently maybe 30 minutes).

So you instantiate the same class into a second object, but instead of
going to the databases again and recreating the same dictionary a
second time, you get a pointer or reference to the one already created
in the first object – copies into the second object that is. And the
dictionary, no matter how many instances of the object you make, is
always the same one from the first object.

So, as we put it, once per class and not object.

Saves on both time and space.

 

[Chris Rebert]

Does python have a ‘once’ (per class) feature?

In Python, `class` is an executable statement, so you can put whatever
code you want in the class body (along with your method definitions)
and it will be run exactly once, at the time the class is defined
(that is, when the `class` statement is encountered by the
interpreter). In this way, you could create class variables containing
such static information.

Cheers,
Chris

 

[Carl Banks]

Does python have a ‘once’ (per class) feature?

‘Once’, as I’ve know it is in Eiffel.  May be in Java don’t.

The first time you instantiate a given class into an object it
constructs, say, a dictionary containing static information.  In my
case static is information that may change once a week at the most and
there’s no need to be refreshing this data during a single running of
the program (currently maybe 30 minutes).

So you instantiate the same class into a second object, but instead of
going to the databases again and recreating the same dictionary a
second time, you get a pointer or reference to the one already created
in the first object – copies into the second object that is.  And the
dictionary, no matter how many instances of the object you make, is
always the same one from the first object.

So, as we put it, once per class and not object.

Saves on both time and space.

Sounds like Borg Pattern:

http://code.activestate.com/recipes/66531/


Carl Banks

 

[Carl Banks]

Sounds like Borg Pattern:

http://code.activestate.com/recipes/66531/

BTW, for your problem you'd probably want to add some kind of
conditional initialization code:


class Borg(object):
_shared_state = { 'initialized' : False }

def __init__(self):
self.__dict__ = self._shared_state
if self.initialized:
return
# perform initialization here
self.initialized = True


Carl Banks

 

[Jean-Michel Pichavant]

Mea culpa: Here super is _not_ a good idea,

[…]

Why is ‘super’ not a good idea here?

class Initialized(ClassBase):
@classmethod
def _init_class(class_):
class_.a, class_.b = 1, 2
ClassBase._init_class()

What makes this implementation better than the one using ‘super’?

a possible answer:
- explicit >> implicit

I'm not sure this is the correct one though

JM

 

[alex23]

a possible answer:
- explicit >> implicit

I'm not sure this is the correct one though

To me, the explicit reference to the base class violates DRY. It also
means you need to manually change all such references should the base
class ever change, something that using super() avoids.

 

[Jean-Michel Pichavant]

To me, the explicit reference to the base class violates DRY. It also
means you need to manually change all such references should the base
class ever change, something that using super() avoids.

I found the correct answer
(http://www.artima.com/weblogs/viewpost.jsp?thread=236275)

" super is perhaps the trickiest Python construct: this series aims to
unveil its secrets"

"Having established that super cannot return the mythical superclass, we
may ask ourselves what the hell it is returning The truth is that
super returns proxy objects.Informally speaking, a proxy is an object
with the ability to dispatch to methods of other objects via delegation.
Technically, super is a class overriding the __getattribute__ method.
Instances of super are proxy objects providing access to the methods in
the MRO."


Jean-Michel

 

[alex23]

I found the correct answer
(http://www.artima.com/weblogs/viewpost.jsp?thread=236275)

I'm not entirely sure how an opinion + explanation of the underlying
mechanics is more or less "correct" than a development principle...

 

[Jean-Michel Pichavant]

I'm not entirely sure how an opinion + explanation of the underlying
mechanics is more or less "correct" than a development principle...

The correctness applies to my answer, not the super mechanism. The super
mechanism is correct and properly documented since python 2.6, so anyone
is free to use it.
I'm just trying to give arguments in favor of using the explicit base
class name instead of super.

And in my opinion, explicit names are (slightly) better because there's
no underlying explanation required when using the base class name
instead of super.

JM