Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > What do you call a class not intended to be instantiated

Reply
Thread Tools

What do you call a class not intended to be instantiated

 
 
Steven D'Aprano
Guest
Posts: n/a
 
      09-21-2008
I have a class which is not intended to be instantiated. Instead of using
the class to creating an instance and then operate on it, I use the class
directly, with classmethods. Essentially, the class is used as a function
that keeps state from one call to the next.

The problem is that I don't know what to call such a thing! "Abstract
class" isn't right, because that implies that you should subclass the
class and then instantiate the subclasses.

What do you call such a class?



--
Steven
 
Reply With Quote
 
 
 
 
James Mills
Guest
Posts: n/a
 
      09-21-2008
Hi,

Wouldn't a normal class called State
suffice for storing state between calls ?
And ... Creating a state instance ?

For example:

class State(object):
"""State() -> new state object

Creates a new state object that is suitable
for holding different states of an application.
Usefull in state-machines.

The way this works is rather simple. You create a new
state object, and simply set the state. If the state
doesn't exist, it's added to it's internal data
structure. The reason this is done is so that
comparing states is consistent, and you can't just
compare with a non-existent state.
"""

def __init__(self):
"initializes x; see x.__class__.__doc__ for signature"

self._states = {}
self._next = 0

# Default States

self._add("START")
self._add("DONE")

def __repr__(self):
try:
return "<State: %s>" % self._state
except AttributeError:
return "<State: ???>"

def __str__(self):
return self._state

def __eq__(self, s):
return s in self._states and self._state == s

def __lt__(self, s):
return s in self._states and self._state == s and \
self._states[s] < self._states[self._state]

def __gr__(self, s):
return s in self._states and self._state == s and \
self._states[s] > self._states[self._state]

def _add(self, s):
self._states[s] = self._next
self._next = self._next + 1

def set(self, s):
"""S.set(s) -> None

Set the current state to the specified state given by s,
adding it if it doesn't exist.
"""

if s not in self._states:
self._add(s)

self._state = s

cheers
James

On Mon, Sep 22, 2008 at 8:39 AM, Steven D'Aprano
<(E-Mail Removed)> wrote:
> I have a class which is not intended to be instantiated. Instead of using
> the class to creating an instance and then operate on it, I use the class
> directly, with classmethods. Essentially, the class is used as a function
> that keeps state from one call to the next.
>
> The problem is that I don't know what to call such a thing! "Abstract
> class" isn't right, because that implies that you should subclass the
> class and then instantiate the subclasses.
>
> What do you call such a class?
>
>
>
> --
> Steven
> --
> http://mail.python.org/mailman/listinfo/python-list
>




--
--
-- "Problems are solved by method"
 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      09-21-2008
Fixing top-posting.

On Mon, 22 Sep 2008 08:54:43 +1000, James Mills wrote:

> On Mon, Sep 22, 2008 at 8:39 AM, Steven D'Aprano
> <(E-Mail Removed)> wrote:
>> I have a class which is not intended to be instantiated. Instead of
>> using the class to creating an instance and then operate on it, I use
>> the class directly, with classmethods. Essentially, the class is used
>> as a function that keeps state from one call to the next.


[...]

> Hi,
>
> Wouldn't a normal class called State
> suffice for storing state between calls ? And ... Creating a state
> instance ?
>
> For example:

[snip]

That's a rather big example for a rather small question.

Yes, a normal class would work in many cases. In this case, the class
itself is being produced by a factory function, and it's output is an
iterator. Having to call:

cls = factory()
instance = cls()
result = instance()

to get anything done seems excessive, even if you write it as a one-liner
result = factory()()().

I'm not wedded to the idea, there are alternatives (perhaps the factory
should instantiate the class and return that?) but I assume others have
used this design and have a name for it.


--
Steven
 
Reply With Quote
 
James Mills
Guest
Posts: n/a
 
      09-21-2008
On Mon, Sep 22, 2008 at 9:05 AM, Steven D'Aprano
<(E-Mail Removed)> wrote:
> I'm not wedded to the idea, there are alternatives (perhaps the factory
> should instantiate the class and return that?) but I assume others have
> used this design and have a name for it.


The problem is, I don't see why you're using a class
to store state in the first place.

cheers
James

--
--
-- "Problems are solved by method"
 
Reply With Quote
 
bearophileHUGS@lycos.com
Guest
Posts: n/a
 
      09-21-2008
Steven D'Aprano:
> I have a class which is not intended to be instantiated. Instead of using
> the class to creating an instance and then operate on it, I use the class
> directly, with classmethods. Essentially, the class is used as a function
> that keeps state from one call to the next.


You may use a module too for that, with normal functions inside, plus
module variables that keep the state. Modules can't be instantiated, I
think.

Bye,
bearophile
 
Reply With Quote
 
James Mills
Guest
Posts: n/a
 
      09-22-2008
On Mon, Sep 22, 2008 at 9:39 AM, Calvin Spealman <(E-Mail Removed)> wrote:
> I call it an obvious misuse and misunderstanding of why you'd use a class in
> the first place. Either create an instance and not make these things
> classmethods or just share the stuff in a module-level set of variables. But
> the instantiating is the best options. Your class attributes might not be
> globals, but you're still using global state and you should avoid it where
> you can.


I concur. Use a _proper_ state object that you share
amongst your other objects. For instance, in many of
my systems and applications I write, I often have
an "Environment" instance, which is a container
object that holds other objects required by parts
of the system. Every other component/object in the
system that is instantiated recievees exactly one
instnace of thie "Environment" called, "env".

Accessing shared states amongst components/objects
within the system is as simple as this:

class Foo(object):

def __init__(self, env, *args, **kwargs):
self.env = env

def foo(self):
if self.env.some_state:
print "Do something useful"

env = Environment()
foo = Foo(env)
foo.foo()

cheers
James

--
--
-- "Problems are solved by method"
 
Reply With Quote
 
Aaron \Castironpi\ Brady
Guest
Posts: n/a
 
      09-22-2008
On Sep 21, 6:05*pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote:
> Fixing top-posting.
>
> On Mon, 22 Sep 2008 08:54:43 +1000, James Mills wrote:
> > On Mon, Sep 22, 2008 at 8:39 AM, Steven D'Aprano
> > <(E-Mail Removed)> wrote:
> >> I have a class which is not intended to be instantiated. Instead of
> >> using the class to creating an instance and then operate on it, I use
> >> the class directly, with classmethods. Essentially, the class is used
> >> as a function that keeps state from one call to the next.

>
> [...]
>
> > Hi,

>
> > Wouldn't a normal class called State
> > suffice for storing state between calls ? And ... Creating a state
> > instance ?

>
> > For example:

>
> [snip]
>
> That's a rather big example for a rather small question.
>
> Yes, a normal class would work in many cases. In this case, the class
> itself is being produced by a factory function, and it's output is an
> iterator. Having to call:
>
> cls = factory()
> instance = cls()
> result = instance()
>
> to get anything done seems excessive, even if you write it as a one-liner
> result = factory()()().
>
> I'm not wedded to the idea, there are alternatives (perhaps the factory
> should instantiate the class and return that?) but I assume others have
> used this design and have a name for it.
>
> --
> Steven


Do you want anything from it that a dictionary doesn't have, besides
the dot-member access?
 
Reply With Quote
 
Rhamphoryncus
Guest
Posts: n/a
 
      09-22-2008
On Sep 21, 4:39*pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote:
> I have a class which is not intended to be instantiated. Instead of using
> the class to creating an instance and then operate on it, I use the class
> directly, with classmethods. Essentially, the class is used as a function
> that keeps state from one call to the next.
>
> The problem is that I don't know what to call such a thing! "Abstract
> class" isn't right, because that implies that you should subclass the
> class and then instantiate the subclasses.
>
> What do you call such a class?


If defining it as a normal class, it is a namespace. Just a way to
cluster multiple globals into a single global. The borg pattern does
the same thing, but with a 12 page treatise on why it shouldn't do
exactly what it's doing.

If using a factory you should probably be using an instance; the fact
that your instance is a class is a relatively minor implementation
detail. Indeed, the only reason to have a class is to have your
methods bound when looked up.

You might want a metaclass to cripple it, preventing subclassing and
whatnot. *shrug*.
 
Reply With Quote
 
Bruno Desthuilliers
Guest
Posts: n/a
 
      09-22-2008
Steven D'Aprano a écrit :
> I have a class which is not intended to be instantiated. Instead of using
> the class to creating an instance and then operate on it, I use the class
> directly, with classmethods. Essentially, the class is used as a function
> that keeps state from one call to the next.
>
> The problem is that I don't know what to call such a thing! "Abstract
> class" isn't right, because that implies that you should subclass the
> class and then instantiate the subclasses.
>
> What do you call such a class?
>


<nitpick>
Err... A possible design smell ?-)
</nitpick>


More seriously: this looks quite like a singleton, which in Python is
usually implemented way more simply using a module and plain functions.

Do you have a use case for specializing this class ?

 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      09-22-2008
On Mon, 22 Sep 2008 10:12:38 +1000, James Mills wrote:

> On Mon, Sep 22, 2008 at 9:39 AM, Calvin Spealman <(E-Mail Removed)>
> wrote:
>> I call it an obvious misuse and misunderstanding of why you'd use a
>> class in the first place. Either create an instance and not make these
>> things classmethods or just share the stuff in a module-level set of
>> variables. But the instantiating is the best options. Your class
>> attributes might not be globals, but you're still using global state
>> and you should avoid it where you can.

>
> I concur. Use a _proper_ state object that you share amongst your other
> objects.



But that's precisely what I want to avoid: I don't want the objects to
share *any* state, not even their class. I'm not trying for a Borg or
Singleton: the user can call the factory as many times as they want, but
the objects returned shouldn't share any state. I don't know if what I
want has a name. Judging from people's reactions, I'd say probably not.

(For the pedantic: the "instances" will all have the same methods, but
I'm not including methods as state.)



> For instance, in many of my systems and applications I write, I
> often have an "Environment" instance, which is a container object that
> holds other objects required by parts of the system. Every other
> component/object in the system that is instantiated recievees exactly
> one instnace of thie "Environment" called, "env".
>
> Accessing shared states amongst components/objects within the system is
> as simple as this:
>
> class Foo(object):
>
> def __init__(self, env, *args, **kwargs):
> self.env = env
>
> def foo(self):
> if self.env.some_state:
> print "Do something useful"


Seems wasteful to me. Why give every instance it's own instance-level
reference to the shared object? Why not make env a class attribute, set
once, instead of every time you instantiate the class?


class Foo(object):
env = env

But in any case, this is not the behaviour I want. It's the opposite of
the behaviour I want. I don't want the objects to share state. I'm not
exactly sure what I said that has given so many people the impression
that I do.




--
Steven
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Decision (if, else) routine is not working as intended with CGImodule epsilon Python 2 01-29-2008 11:34 PM
Globalization not working as intended when using da-DK Basildk ASP .Net 8 08-31-2007 08:26 AM
LoginView - I'm probably trying to use it in a way that's not intended... Homer J. Simpson ASP .Net 0 08-29-2007 07:52 PM
is asynchat broken or just not intended to work like other dispatchers? [PATCH] Martin Maney Python 1 04-11-2007 07:34 PM
nested includes not working as intended Mike ASP General 4 08-05-2003 02:59 PM



Advertisments